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
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?
Comments on this entry are closed.
James, a great post and I agree with what you say, but I do wonder whether we could go further.
The methodology that your examples infer is still process led – that is, we are still looking at extracting decisions from processes and externalizing them.
Why not turn it on its head, and look at the required decisioning first, and then figure out what are the best processes to implement it. The decision requirement can’t be wrong – it is the essence of the business. Decision making must be correct, complete, and consistent or the business will fail. But the process, well, any process will do provided that it delivers the data and responds to the decisions made. A completely different set of attributes define a good process, eg fast, cheap, easy to use, automated, robust, fewest transformations, etc but these are not imperative the way that the decision qualifiers are. Decisions first, process second!
A similar subtle distinction is also implied by this phrase: “and use a technology ideally suited to handling lots of rules and figuring out the right ones to apply (a business rules management system)”. In my view, a BRMS is a technical solution to a problem which arises when you come ‘bottom up’ from the process. By extracting decisions from processes you detach the decisions from their context, which means that you then need to reconnect them at execution time through an inferred (inferenced?) context.
If the business is to be in control, then business defined decisions should be used to determine appropriate decision making paths for any given event, not a BRMS inferencing (unless of course the problem is so complex that the business is unable to determine the required decisions, which leads us directly to analytics, but I don’t think that is the intent of your example, is it?).
Regards,
Mark
The example and methodology I describe are process-led because the vast majority of companies looking at improving their enterprise applications are doing so in a process-centric way and this was the context for the discussion.
I don’t think anyone would mistake me for someone who did not think decisions were important. But processes matter too. If I cannot PROCESS your order it does not help if I can decide that it is complete, eligible for a discount etc. I need to decide what should be done and have processes to get those things done. Without both I don’t have a functioning company.
Thanks for commenting
Hi James, a belated follow up.
Just a thought re your second paragraph. Actually, I can name many organization who will process your order. In the software business for instance, there are whole sites simply dedicated to processing on behalf orders using THEIR process, not yours.
But do they decide your price and discount policy for you? – the decisions are yours, the process theirs. Personally, I think this is the way of the future. The precedent is well established with vendor applications, which provide generic processes.