Properly Designing Exceptions in Business Processes: it depends on the Circumstances
It is a dilemma that every business process designer faces. Imagine that your beautiful, elegant, innovative, easy-to-understand, Lean-based process design – the result of several brown paper workshops with all relevant stakeholders present – covers more than 95% of all cases and situations. Many process architects would be inclined to say: let’s put aside the remaining 5%, as it will complicate the model. Let’s treat these as manual exceptions.
But the business will in many cases insist that the remaining 5% cannot be neglected. “1% of our clients are platinum members, they have a different process, and they are extremely profitable”, “this process runs well in all Member states except Germany, where they have special requirements on privacy, but Germany is an important country for us”, “this process runs fine the whole year through, except for the first week of September, when we have our Oktoberfeste discount. Our sales volume doubles in that week.”
In many situations, the process architect will respect these requirements. He or she will end up by adding processes, branches, activities, swimming lanes etcetera to the existing model to the extent that the coverage approaches the 100%. In many cases, this will double the size of the model, as exceptions are being added that require extra activities, extra decisions, extra sub-flows. The model becomes more difficult to understand, to maintain, to implement. A sad situation.
For several projects we have designed our new processes to be implemented in the Pega BPM system. Pega is the leader in the Gartner Magic Quadrant for Business Process Management systems and a strategic partner of Atos. The interesting thing is that they have solved – to a large extent – the problem described above. They have done so by implementing “Circumstancing”. Simply stated, it allows you– as the name suggests – to overrule a given element of your business process by another element based on some properties or a time interval.
For example, you can implement an activity “Calculate Discount” as the base activity (in Pega: base rule) and create a circumstanced rule that is only applied – automatically - in the first week of September, and that provides a different calculation mechanism. In a similar vein you can have an activity that sends a Notification E-mail to a “standard” client, but if the circumstance indicates that this is a “platinum” client, this activity is overruled by an activity that sends a text message as well.
We have been using circumstanced rules quite extensively in our projects, and we use it indeed for situations that occur in 5% of the cases or less, otherwise we implement the exception in the core process. That works well. If a rule is applicable in all 50 states of the US except for two, we use circumstancing. If there are two exceptional sales weeks per year, we use circumstancing. It appeals to our intuition that 1 out of 20 is still an exception to the rule.
We apply circumstancing now in all our process design activities, even if we don’t intend yet to implement a BPM system. By adding a “circumstanced” exception to an activity in a process flow chart, we acknowledge the business’ request for an exception, without changing the flow charts. The process design remains compact whilst the exceptions are taken care of.