X hits on this document





4 / 8

Lets take this last example a few steps further. When the inventory system indicates a product is in stock and the accounting system says a payment has been made, a pick order is automatically printed in the warehouse and a mailing label is automatically printed out in the shipping department. In this scenario the policy is inherent in the system and cannot be violated.

Policy Rigidity and Process Automation

There is a special consideration to be aware of when assigning the computer to enforce policy. Depending on your philosophy this can be a godsend or a curse.

This special consideration is policy rigidity. You could consider perfect policy as that which does not need exceptions. It is firm, solid, and works every time. Unfortunately, humans seem incapable of creating perfect policy. One way of grading the quality of policy is to consider the number of exceptions required. The phrase ‘The exception defines the rule” is simply a way of saying that the rule isn’t perfect. Management often codifies exceptions into the policy. If a policy gets very complicated as a result of its list of exceptions and branches, it is bad a policy and will not be strictly followed. A new policy should be formed.

The computer is extremely stupid and literal. It will enforce the policy you teach it without evaluation or exception. If your policy is not perfect (most of the time) you will need to either improve it or codify the exceptions into the policy and teach them to the computer. If, at a later date, the policy fails to accommodate what you want to accomplish, the process automation system you have put in place will reject it.

There are

a few


at this point.

accommodate really

what I

want to

do?” You have

First, ask yourself the policy in place for

“Is the a reason

policy exception I want to and you should either follow

it or decide that it is automation system the

inadequate new policy.
















Here is a classic example. You have two different pricing models for your software product. First is per user licensing and second is megahertz licensing (your software costs more to run on a 700mhz processor than it would on a 500mhz processor). Your ordering, accounting, and packaging systems all recognize these models and strictly enforce them. Your top salesman has landed a major new account but the client wants per processor licensing as it expects to upgrade its computers in a year and does not want to pay a lot more.

Now, your ordering and accounting systems simply cannot handle this model. Do you modify the ordering and accounting systems to accommodate this one request? Add this model to your accepted pricing models and change the software? Deny the request? Or the most popular (and most dangerous) option, put false information into the system to trick it into accepting an order and creating an invoice along with copious verbal or written notes to make sure the order is handled per the exception?

Companies do not want to lose a big order, so this is a tricky decision and I cannot tell you the right answer. I will however try to dissuade you from picking the last option. As soon as you put information into the process automation system that does not match what it expects it becomes that much less valuable. Statistics will be wrong. It can cause unexpected results. And it sets a bad precedent. If you allow one policy violation, it will encourage others and you slide down that slippery slope. It does not look very steep from the top, but I speak from painful experience. It is.

So you need to have very well formulated policies and procedures before you even attempt to automate your processes. It is expensive to provide a lot of exceptions and very expensive to constantly change the system. Putting in a process automation system will force an organization to codify its policy and will very quickly point up bad policy.

Now it is possible to design a process automation system that minimally enforces policy. This may be the right decision for a new organization that simply does not yet know what policies and procedures will work. They can learn on this system and then create a better system later on. An organization with established policies and procedures should not do this. They lose 1/3 of the benefit of process automation right from the start.

Requirements and Characteristics of Process Automation

Page 4

Document info
Document views26
Page views26
Page last viewedTue Jan 17 23:45:37 UTC 2017