Syndicated from ebizQ
There are lots of good reasons for adopting business process management as an approach, and a Business Process Management System as a technology. The benefits that can be gained are real but they can be undermined by over complex process designs. If the process you end up designing is the BPMN or BPEL equivalent of spaghetti code, then your process won’t be eligible and it won’t be cost-effective. It’s also unlikely to deliver a positive customer experience or to be easy to continuously improve. The benefits of BPM, in other words, are dependent on you developing processes that are reasonable, that are not over-complex.
In my experience working with clients, however, I find many over-complex processes are being designed. Often these processes are over-complex because the decisions within those processes are not being identified and separately modeled or managed. Instead, large numbers of process steps and branches are being used to manage gather the data a decision requires. More are used to manage some of the decision logic and/or cheat sheets or procedures are presented to users to guide them through the decision making.
Instead of mixing processes and decisions and applying a single approach (BPM) and a single tool (a BPMS), the clients I have been working with are separating them out. They find the decisions – the parts of the process that validate things, determine eligibility, calculate prices, select appropriate terms, assess risk – and design and manage these separately. They use a Business Rules Management System or a decision engine to manage these decisions. The combination of a separation of concerns and the use of a tool designed for managing decisions simplify both the process and decision. The resulting decisions and process collaborate, typically using SOA, to deliver the business result required.
When decisions are separated out like this, especially when they are also moved early in the process, a dramatic improvement in straight through processing and a matching reduction in process execution time/complexity is possible.
I recently gave a webinar on this topic and you can watch the recording – check out Simplifying over-complex processes.
Comments on this entry are closed.
Hi James, we see this happening too, and agree with your comments. But one aspect of your comment is reminding me of our recent ‘tweet debate’. You infer equality between process and decision – in your post it doesn’t matter which you do first, provided that you separate them. Our view is that if we do the decision design first, it provides insight into the process requirement – after the decision design, I know what data is required, and this is an important ingredient in the process design. The reverse is not true. Capturing and delivering data to a decision module does not infer that the data is required or even useful to the decision module. This dependency transits the data in only one direction – “decision requires data, process must deliver data”. Not “process delivers data, decision must require it”!
Just a thought – see you at the Business Rules Forum!