Everybody has a story like this. You are in the supermarket and you choose what you think is the shortest line to check out. You slowly inch forward. Finally, you are next in line. You are almost out of there.
Oops. One of the items in the basket of the person in front of you doesn’t have a price tag. “Price check in aisle one,” you hear. You stand and wait. Oops, the person chose skim milk instead of one percent and dashes off to exchange it. Oops, the person doesn’t know how to work the credit card machine, can’t find the store card or otherwise has trouble negotiating the payment. You stand and wait. Meanwhile, the people in the other lines move forward. Should you jump to a new line or wait there? You jump. Oops, the person in your line finishes up and the line moves forward, while your new line stalls.
One of the key assumptions of business process management is that routine processes can and should be automated. Moreover, with routine processes, the human factor should be eliminated as much as possible. The premise of straight-through processing, for example, is that data should be automatically handed off from one information system to another until the process is complete. An order entered from the Web goes directly to the warehouse; to shipping; to billing, without any manual interventions.
As more processes become automated, what happens when exceptions occur? In manual, human-based processes, the person on the spot manages the exception. The cashier calls for a price check or helps the customer negotiate the payment apparatus.
But as human involvement in routine processes is minimized, managers and system designers have to think about how to handle exceptions to the rules. Of course, many automated systems issue alerts when certain parameters are met or not met. These alerts may or may not be directed to a person, depending on the specific application. In all cases, however, issuing an alert is not sufficient. The system has to be engineered in a way that the exception can be managed promptly and, ideally, with no impact on the ongoing routine processing. An exception should not be allowed to become a chokehold for routine processes.
The move to service-oriented architectures and the proposed integration of information systems up and down the supply chain promises to make exception management all the more complicated. As systems become more complex, it becomes more challenging to identify where in the system an exception is even defined, much less how an exception should be managed and by whom.
While all this may seem very obvious, one very interesting aspect about exception management is how poorly it is often handled even when you have an intelligent agent (i.e., a real live person dealing with the exception). Form example, I recently changed my cell phone service and noticed that the store I was in, which was operated by a service provider, was charging $10 more for the phone I wanted than a consumer electronics retailer nearby. I asked the sales person to match the price but was told that he couldn’t. The manager also refused to match the price. I observed the company lose a $2000 annual order because it would not cut the price of one phone by $10.
In that scenario, I became an exception. I was asking for a discount, but no discounts were being given. Because the rules were rigidly applied, the company found itself in a situation in which it saved $10 and lost a sale worth $2000 a year. Addressing those kinds of possibilities is going to tax the ingenuity of process architects and systems designers. The solutions they devise will be critical to the success of these specific projects.
