Properly Designing Exceptions in Business Processes: it depends on the Circumstances

Posted on: August 26, 2016 by Robert-Jan Streng

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.

Share this blog article

  • Share on Linked In

About Robert-Jan Streng
Business & Management Consultant
Robert-Jan Streng is leading the Business Performance Improvement (BPI) activities for Atos Consulting in the Netherlands. He is managing partner of the Business Process Management (BPM) competence centre. He is working on improving business processes – following the Lean Six Sigma methodology, for which he holds a black belt certification – and where appropriate implement them in Dynamic Case Management tools such as Pega or using Robotic Process Automation. He obtained a PhD in process redesign from Delft University of Technology, on a seminal case study project to improve the supply chain processes of Heineken from the Netherlands to the US, connecting all parties in the value chain. He has carried successful business process improvement projects for renowned organizations in industry sectors such as Energy, Banking, Electronics, Telecom, Public and the United Nations.

Follow or contact Robert-Jan