Syndicated from ebizQ
My friend Jerome had a post this week on finding decision points – the spots in a business process where you make a decision – that was prompted by discussions he and I had with a joint client. Jerome focuses on certain kinds of activities and the words that describe them like analyze, check, validate, evaluate, verify – all good decision-making words.
When Neil and I wrote Smart (Enough) Systems we identified a number of different ways to find the operational decisions that are the decision points in your business processes in addition to this kind of use case analysis. These included:
- Micro decisions
Opportunities to make a decision specific to a single transaction or customer. - Manual decisions
Opportunities to replace manual decision making. - Default or fixed decisions
Opportunities where a single, invariable decision could be replaced with a variable, targeted, context-specific one. - Overrides
Opportunities to better manage decisions that are often overridden, perhaps because the decision has become inappropriate in many circumstances. - Missing decisions
Opportunities to make a decision where no decision is made today.
These different kinds of decisions often overlap – a regular override might show that a micro decision is called for say – and these decisions can be found as part of your regular analysis. For instance you can analyze reports to see what actions are taken when those reports are received, see what transactions are referred to supervisors or to management or detail the manual reviews in a process. All of these will identify decision point for you.
Another friend (Scott Sehlhorst) blogged on Business Rules Hidden in Use Cases and I wrote about keeping business rules out of your use cases using decisions.
Comments on this entry are closed.
James, all good points of course, but this post emphasizes a bottom up approach, sorting through a morass of low level detail to find opportunities for rule centric process improvement. What about turning the telescope around and looking at the business policy instead, a top down approach to determine definitively what rules SHOULD be implemented. A policy driven rules analysis will also of necessity identify the relevant facts that need to be collated, and these can be used to track down implemented rules – if there are any. If the implemented rules do not agree with the policy derived versions, or they are not found at all, then this approach has just identified a significant gap in IT alignment and an opportunity to deliver some real value.
If you use a tool for capturing and fully testing the policy driven rules, and then generating a relevant implementation, does it even matter what the existing low level rules implementation, the result of years of tinkering, has achieved or not achieved?
I do agree with Mark. It is good to classify the decisions but how about implementing? It is often in the rules that are already existing that one have to take a look. I mean that a bit of action is often better than a lot of talking and thinking!
Mark,
We are not excluding the business policy and business rule approach. What I do observe is that a top down approach of policy driven rules analysis does not conduct to understand where the derived business rules are enforced. The search for decision point, attached to a business process description (done with use case or with BPMN does not matter), helps to drive the analysis, and help the business to focus at enforcement of business rule. If not the business team can spend months defining business rules, that IT does not understand where to put them. The decision point can help drive the discovery of the business policies and rules, for an implementation point of view, as well as a way to organize the top down approach. A decision point support multiple rules, and if implemented with a rule engine, the rules are packaged as rule set.
At the implementation level the business rules should reference the business policy it supports.