I was working on my chapter for the forthcoming SAP BPM book (Applying Real-World BPM in an SAP Environment) and it occurred to me that I rarely write about where to start with business rules. After all, most IT departments like to do a low-risk first application of a new technique. So where to start?
Well first things first – begin with the decision in mind. Look at the business processes you know best and see what decisions are involved. Decisions will show up either as manual activities (worklist for approval or discount calculation for example) or as activities with names like “Choose…”, “Select…”, “Calculate”, “Determine”,”Assess” or “Validate” . Within these decisions you are looking for a decision or a closely related set of decisions:
- That impact a metric you are already tracking
- Are already being recorded – the action being determined is logged in the current process
- Meet the criteria for using business rules:
- Lots of policies, regulations or best practice to be applied
- Policies, regulations or best practices that change often
- Policies or regulations that need serious business domain expertise to understand
- Policies, regulations and best practices that are complex or interact in complex ways
- Some mix of these
At this point you should have a point in your process where a decision is required, a way to measure the effectiveness of how you make that decision today and a decision that will repay using business rules. Obviously for a pilot or first application you don’t want the decision to be too complex or too important but it must be serious enough to be a real proof point.
I can’t emphasize enough how important measurement is – if you cannot assess how well you currently make decisions, or how the decision impacts your current metrics, then it will not be possible to show the value of business rules and a business rules management system. For a decision currently being taken manually, look for errors, fines, delays to transactions, staffing numbers/costs and training time/costs. For an automated one, look for maintenance costs, time to implement required changes, hot fixes required due to errors and so on. But most of all, figure out the impact of the decision on business costs and metrics. Especially those that matter to two critical groups – executive sponsors and the actual users of the system. If it does not matter to an executive, you won’t get very far. If it makes life worse for the users, by reducing their bonus or similar, then it won’t get used.
There’s no one right first application – different industries, different processes, different companies will find a different place to start. Applying this thought process should help though.
Copyright © 2010 http://jtonedm.com James Taylor
