Talk to the Hand

A common issue  with any kind of BPM implementation or distributed application is the problem of what to do with errors. The most important thing is to direct errors to the correct system or person. “Correct” meaning a system that can actually do something about the error.

Take our internal timesheet application as an example. I’m sure your system is similar, where an administrator sets up a project along with various business rules such as who can enter time against a project, or what is the valid date range for the project. When I enter my time records, I invariably run afoul of one of these rules – who could have guessed the project would run late?

The problem arises when I get a (usually very obscure) error message about one of these constraints. I can’t actually do anything about incorrect dates or ad hoc resource assignments because I don’t own the project.  So it’s no good erroring out to me, the user. The really brain-dead thing is that I have to discard the timesheet entries, send an email to the project owner (whoever that may be) and enter the data later…if at all. It certainly doesn’t help collect accurate and timely information.

A better approach would be to accept the entered data and refer the errors to the project owner who is in a position to do something about it. This person can review the errors and correct the project rules accordingly. Alternatively they can reject the entry because I may have actually broken some valid rules.

This process flow is much more user friendly and streamlined. It requires a couple of important facilities:

You need to suspend business rules for part of the process. My timesheet entries initially break the business rules but we don’t know if that is because I have err’d or because the rules/reference data are in error. We need to accept the entries in an invalid state until the right authority can decide. This represents an example where data validity rules are not absolute, but depend on the process.

Secondly you need an error service…a facility whereby errors when detected can be routed to the appropriate person or system for resolution.

Our timesheet system is based on the old database paradigm – a monolithic data-centric application with only one place for rules to be applied.  The “workflow-based” solution I describe is slightly more complicated than the monolithic application but the payoff in terms of a better user experience leads to more accurate and timely records. And if your a services organization with thousands of billable timesheet records each day, then you know what takes priority.


#1 Richard Veryard on 11.11.08 at 7:55 pm

Hi Saul

I think the problem starts when your perfectly reasonable data gets labelled as “error” because it is inconsistent with your project manager’s data. This happens in a lot of old bureaucratic systems because they are designed on the implicit (hierarchical, top-down) assumption that the manager (or systems designer) is always right and the worker (or data entry clerk) is always the one that gets things wrong.

I prefer to label such inconsistencies as anomalies, because that doesn’t imply anyone in particular being at fault.

It would be crazy to have a business rule saying that anomalies are not allowed. Anomalies happen. What makes sense is to have a business rule saying how anomalies are recognized (i.e. what counts as an anomaly) and resolved (i.e. what options are available to whom).

Then you never have to suspend the rule. It is just a different, more intelligent kind of rule.

See also “Post Before Processing”.

#2 Lyndon on 11.20.08 at 2:13 pm

Is there anyone who actually likes their current timesheeting system ?

Also, I find it disappointing when ‘managers’ push off management tasks to technical people. What exactly is left for management to do when employees are logging their time at the micro level 🙂

#3 Progressive Data Constraints | soabloke on 11.21.08 at 3:17 pm

[…] ← Talk to the Hand […]

#4 Saul Caganoff on 11.21.08 at 3:27 pm

Yes and while we’re bashing timesheet systems, I love the way people create “chargeable” activities and “unchargeable” activities as if the lowly data entry clerk (consultant whatever) understands what may or may not be chargeable under the work-order.

Leave a Comment