Home Contact Us Site Map
Why you should read this

Many Time Management software applications provide excellent award interpreters to generate employee payments.

Read this article to discover why TimeFiler does it better than the others.


What makes the
TimeFiler business rules engine unique?

We doubt that there is a single concept in our business rule engine that hasn’t been figured
out by many vendors in the past. There are probably a dozen or concepts in our business
rules engine like that.

However it is all to do with balance and how these are blended together that make things special.

Business rules engine back-end

The back end of our business rules engine is based around scripting, and its basic constructs
are based around a subset of the VBA language (Visual Basic for Applications). Most consultants and expert employees of our customers already understand this language perfectly well. We’ve made this very specific to Time Management though, and in the process stripped out a pile of things that we don’t think will ever be needed and just clutter things up.

We want the business rule scripting language to just be the glue that binds things together, and offers a lot of flexibility, but we’ve deliberately avoided trying to over-do the choices that end up making one feel like ‘they are doing development’. This is definitely NOT a developer’s tool (and this is meant in a totally positive way). It is for business savvy people who wish to configure business rules for customers which is another set of expertise altogether. So as examples, we don’t even allow iteration concepts like ‘while’ and ‘for’ loops. Technically this is easily achievable, but our belief is that if a consultant has to worry about that sort of stuff, we haven’t offered rich enough business rule functions.

Configuring rules for Consultants & Clients

We also allow consultants to easily create user-defined parameters that can be changed at the front end which the business rules refer to in their logic.

For complex implementations this can mean that there are quite a few parameters to be set up. But what is good about this is that the customer can see these parameters and maintain them into the future. In effect the customer often thinks of these parameters as ‘the business rules’ and sees them as simple things that they can easily understand and maintain.

We make it easy for clients to maintain aspects of their business rules that are likely to change in the future.

They often forget that there are also some
‘bones’ underneath produced for them by the Consultant, but the idea is that these bones should be written in a maintainable enough way
so that they rarely need to be changed.

It’s all good stuff.

And as a result, those ‘bones’ are simpler to understand. This makes it easy for one person to understand what was done often years ago when these rules change (as they tend to). You don’t want someone tasked with changing a rule or two in the future suggesting that it all has to be rewritten again for the simple reason that no-one can understand what on earth is going on.

Usually you might change the odd number or link in some more reason codes into one of the parameters for example, that the business rules will reference. This makes updating client rules that much safer because you can have people involved in business rules, who might not be otherwise comfortable changing the lower level ‘bones’.

Less implementation costs using TimeFiler

Business rules, and the parameters they reference are stored in xml within the SQL Server database. It is very easy to copy out to a fellow consultant, and much easier to re-use rules for different clients where there may be lots of similarity within certain industries.

In traditional ‘Time & Attendance’ systems, getting consultants to develop rules can be incredibly expensive because they more often than not have to re-invent the wheel every time. And this cost is always passed onto you, the customer. Usually this isn’t an overtly deliberate strategy on their part, it’s just a consequence of antiquated tools that don’t make the consultant productive who is helping you, the customer, configure the rules. And there usually isn’t a lot of pressure to improve those tools.

Bad consulting vs Good consulting

TimeFiler distinguishes between ‘good consulting’, and ‘bad consulting’, and we have stamped out any chance of ‘bad consulting’ occurring. Bad consulting is any consulting that you as the customer are paying for because of inefficient tools seen in our competitors' products to get your organisation up and running.

‘Good consulting’ is unavoidable, extremely important, and always a good experience for all involved. Configuring TimeFiler to meet the most complex needs of your organisation requires good business skills to fully understand your employee payments, conditions and processes. Your employee rules and conditions need to be worked through with an expert who has done this time and again over the years. Some organisational rules will still be a little ambiguous which means they need to be clarified. It does help to have expertise here, and experience and smarts count.

Don't pay another software vendor to simply reinvent the wheel when it's been done countless times before.

If you are paying just for that, then you are getting extremely good value for money.
If you are paying to have someone reinvent the wheel, and at times be glorified typists then
you aren’t. TimeFiler avoids the latter, with extremely efficient tools that make short work
of configuration, and make it highly maintainable
going forward into the future.

Don’t forget about these extra costs as you evaluate products.

We’ve thought about them heavily as we developed TimeFiler so that you will never have to pay for them.

 

Avoiding vendor lock-in Leave requests: how we got it right