I gave a webinar on Smarter ERP with Decision Management and one of the tweets during the presentation – “Standard processes, custom decisions” prompted a few requests for more details. So, here goes.
I gave a webinar on Smarter ERP with Decision Management and one of the tweets during the presentation – “Standard processes, custom decisions” prompted a few requests for more details. So, here goes.
When I talk to companies about their ERP implementations we often end up discussing the balance between standardization/globalization and flexibility/localization. These companies invested in an ERP system or other enterprise application in part (sometimes in large part) to get a standard system – standard data, standard processes, globally enforced. But when they come to implement it they find that local variations or product-specific exceptions undermine this attempt at standardization. They end up as one company said to me with a “worldwide standard process with hundreds of local exceptions”. This is far from idea as they know have to manage a much more complex process – the actual process has hundreds more elements than the original “simplified” process that was envisioned. This reduces agility, increases risk of errors and problems, reduces the ability of the various groups involved in the process to share and collaborate, and makes it harder to spot opportunities to improve the core process. Plus the process diagram is ugly.
In many of these cases, though, it is not the process that needs local exceptions but a decision within the process. Because the original process design did not explicitly identify the decisions within the process (they were probably pretty simple in the global version anyway), exceptions are seen as exceptions to the process. But if the decisions are called out, often the exceptions are clearly related to a decision. In a standard order to cash process with a “what is the customer discount?” decision might have local exceptions while in the supplier onboarding process the local variations might be in the “is this a complete, valid set of supplier data?” decision. In fact this last one was a concrete example I came across while writing the chapter on business rules and decision management for Applying Real-World BPM in an SAP Environment
. This company found that if it externalized the decision that validated the supplier data as complete it could use a standard onboarding process (and a much simpler one) while still allowing different countries to have different tax IDs or company types for example. All the local variation was encapsulated as rules in the validation decision.
Of course this does not make the exceptions go away. But it does help you separate concerns – process in process management, decision in decision management – and use a technology ideally suited to handling lots of rules and figuring out the right ones to apply (a business rules management system).
Other relevant posts include this one on using business rules in stable business processes, this one on using decisions and decision management to simplify business processes and this webinar on simplifying processes with decision management.
@skemsley @intelligentform @alecsharp – that enough?
