Never-ending On-the-Job Training
|This column originally appeared in the May/June 1997 issue of the Data Base Newsletter.|
Everyone is talking these days about the accelerating rate of change and the urgent need to build business systems that prove more adaptable. The business rule approach clearly addresses that need. The Newsletter talks about that on a regular basis. I believe there is a flip side to the issue of change, however, which has received very little attention. That flip side has to do with training.
Remember the old story about telephone operators? Use of the telephone has grown at such a rate, that if automatic switching had not been invented, it is said that by now everyone would be a telephone operator. I believe that the rate of change in business today is just as fast. Workers are being thrown into new responsibilities and procedures at an ever-increasing rate. That means they must be trained -- by other workers. If this keeps up, sooner or later, everyone will have to become a trainer.
Clearly, that cannot happen. The only solution is to make training automatic -- that is, built right into the information systems that support the workers' day-to-day responsibilities and procedures. I believe business rules can make that happen. Here's how.
The business rule approach features declarative expression of rules. This declarative expression is associated with a simple textual statement (e.g., a rush order may include no more than 5 items). When a worker violates this rule performing any procedure, what error message should pop up on the screen? Not some obscure system code, or any message in computerese, but the business rule text itself! I like to say that business rules are the error messages.
Another way to look at this is that the business rule represents a requirement that is pure 'business logic.' In the business rules approach, this type of requirement gets input directly in building the system, then gets output directly to inform the worker when a violation in his work is detected. Think of that as a communication from a worker who knows the 'business logic' to a worker who must follow the business logic -- without these workers ever communicating directly.
A friendly business rule system goes a step further. When an error is detected,
not only does the business rule system materialize the original business logic for
the worker but can offer a canned procedure to the worker so that he can correct
the violation. In that way the user not only learns the business logic but
also learns how to correct mistakes. The very same applies even for experienced
workers who encounter changes to the business policies they already knew.
For these reasons, I think of the business rule systems as instructional. Think of it as never-ending on-the-job training.
# # #