In many companies employees are busy capturing their operations in "business processes". In defining these you face a few challenges:
- What standard do you use, for example BPMN 2.0?
- What drawing tool do you use, Visio or a more sophisticated tool?
- Which level of abstract do you choose, descriptive level 1, Level 2 analytical or Level 3 executable?
- Will you also record the business rules in the processes and if so, how?
- How do you harmonize the processes across the locations/units/countries/etc.?
- How do you deal with exceptions?
To start with the last point. How to handle exceptions? Often the first draft of a business process is drawn in a workshop. During the workshop a discussion with "yes-but" will occur. In other words, the right process is drawn, unfortunately there are some exceptions. After some discussion comes the liberating quote: "Let's not model exceptions, but the main process. We aim for a 95% coverage”. For the drawing process this approach is fine, unfortunately for implementation it’s not. The automated systems to support the processes must 'understand' when it’s permissible to deviate from the 95%. Software does not understand this automatically, so there should be clear rules for that. As a result, all transactions will be enforced through the drawn process or there is a loophole created for exceptions. When and how the loophole is used is often ambiguous.