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.
Subscribe to this blog by RSS
Good stuff, James. We need more of this kind of material. I'd like to offer an orthogonal suggestion that helps in eliciting the knowledge underlying decisions exposed by use cases. The essence is to identify the actions taken in the course of handling a use case rather than why. For example, "add a risk premium to the quote". This is an action. It does not concern itself with the knowledge in the decision but exposes the existence of the decision. Once the decisions are exposed it is straightforward to answer the recursive questions as to "why". This exposes requisite knowledge and policy, which may be expressed at a higher level than we normally conceive of rules, btw. Note that this approach agrees with you that knowledge (e.g., business rules) can (should) be derived from understanding how the business wants to handle use cases rather than being embedded within the use cases themselves.
Best,
Paul