Based on the experience of many business rules projects using multiple technologies including BRFplus, we have developed a set of best practices that are proven to work. These best practices are part of an overall approach, Decision Management, that has become the de-facto best practice for implementing business rules. At the heart of the approach is an explicit focus on decisions and this is reflected in the decision-centric approach taken in NetWeaver Decision Service Management.
EDIT: Here's a recording of our webinar: Managing and Evolving Decisions with DecisionsFirst Modeler and SAP NetWeaver Decision Service Manag....
There's also a great paper on Social Benefit Determination with SAP NetWeaver Decision Service Management available on SCN.
Our team at Decision Management Solutions, an SAP Consulting Partner, has taken these best practices and embedded them in a cloud-based, social and collaborative platform for capturing decision requirements called DecisionsFirst Modeler. In this article, and a follow-on article about blueprinting, I'll show you how these best practices increase your likelihood of success and boost ROI. By the way, if you are not clear on the value proposition for business rules with SAP,check out this white paper. If you want to see how this approach work with SAP NetWeaver Decision Service Management, check out our upcoming webinar May 16 at 7am PT/10am ET/16:00 CET Managing and Evolving Decisions with DecisionsFirst Modeler and SAP Netweaver Decision Service Manag....
The first step is to scope your project. A typical BRFplus or NW DSM project has an existing process defined that contains some kind of decision making task. This task might be to validate something, calculate something, check or approve something. These task are described using decision words and show where decision making can and should be implemented. Particularly when the policies or regulations that must be implemented are numerous, when there is real complexity to these policies or regulations, or when the policies or best practices for these tasks change often, a business rules platform like BRFplus or NetWeaver Decision Service Management is essential.
As Lee Chisholm wrote in his great piece on scoping - How to Scope Your BRFplus Project the first step is to be clear what your business goals are for the project. These might be to improve a standard metric, such as customer retention rate, or to hit a particular project objective such as to reduce the number of manual referrals. Understanding this is critical to any business rules project. We being by using DecisionsFirst Modeler to capture both objectives and metrics, storing them in the database so everyone on the team can be clear what they are and so they can be linked into the rest of your scope as you develop it.
Many projects actually target several decision tasks and one of our best practices is to establish which decisions will impact which business objectives or metrics. Often it becomes clear that there are several distinct groups of decisions, each impacting some of the project's metrics and objectives. DecisionsFirst Modeler allows you to clearly identify each of your top level decisions with you business objectives.
As Lee correctly points out, to effectively estimate and scope the business rules in each decision you will need to decompose the decision-making a little. Rarely if ever is the top-level description of a decision going to be enough to give you a true sense of the complexity of the decision-making involved. By far the most effective way to do this is to turn your decision into a question and see what other questions would have to be answered first. Even a simple pass through the decision points will yield a set of sub-decisions that will tremendously clarify what it is your are proposing to automate.
Rather than the mind map that Lee uses, DecisionsFirst Modeler revolves around a diagram designed for just such modeling. It allows you to rapidly build what is known as a decision requirements diagram (based on an emerging standard called Decision Model and Notation). Nodes representing decisions can be dragged onto the diagram and then linked to show which decisions are dependent on which other decisions. In Lee's example, shown also in the diagram below, the decision "Should we give this student money" is dependent on decisions including "how much money does the student need", "does the student have good credit" and "does the student need to send in any documentation." We can continue to decompose decisions to give ourselves an increased view of the decision-making, breaking down our "how much money does the student need" decision into "what resources doe the student need" and "what costs is the student incurring."
Not only does this diagram clarify our decision-making, it does so in a way that business and IT users alike can understand and discuss, maximizing the precision of your scope document. It also provides a framework for the critical estimation step. As Lee points out you need to estimate both the number of rules and their complexity. Experience is that this is very hard to do for a "lumpy" or top-level decision. By breaking down the decision making into its component pieces, as we showed above, we can identify which parts of the decision making will involve complex rules, lots of rules or both.
These diagrams are not limited to showing decision-making, however. As Lee also points out, building a vocabulary is going to be a critical task in the blueprint phase. Using DecisionsFirst Modeler you can also specify the information needs of your decisions. Using information sources you can show the logic blocks of information that each decision requires, defining a scope for your vocabulary work and again making it clear which decisions, and therefore which rules, will require what information. In this next version of the diagram the business objects required have also been documented:
Finally, as you draw these diagrams you can also identify knowledge sources for your decision-making. These are the policy documents, regulations, best practices or SME expertise that you are going to need to describe the rules in these decisions. While it is common to document this in the scoping phase, the decision decomposition allows you to link specific decisions to specific knowledge sources, making it clear which decisions will require which SMEs, which SMEs or policies have the broadest impact etc. All of this is a great help when it comes to estimating and scheduling your blueprint work. This is shown in the final version of the diagram:
One note at this point. Every object in DecisionsFirst Modeler can be described in detail. It allows you not only to draw the diagrams and build the links between objects, it lets you detail those objects as much as you need to fully scope your project.
As you build out this diagram you can also continue to refine the associations with business objectives and metrics. As you break down a decision into its component pieces it may become clear that one particular sub decision is critical for hitting a particular objective or that only part of the decision-making really has an impact on a metric. Understanding this will give you clear guidance on how to measure success. When you are all done with this step, DecisionsFirst Modeler lets you package up all the information you have entered and generate a detailed Word document for inclusion with your scope documentation.
One question we often get at this point is "why can't I just use Visio or PowerPoint to draw the diagrams and write a Word document directly?" Well, of course, you could do that. But these tools have serious limitations when it comes to effectively scoping business rules projects:
- First they are single user when scoping is a collaborative, multi-user problem. When your project team is in multiple locations, when SMEs are remote or based in several offices, when onshore and offshore teams must be coordinated, a cloud-based true multi-user platform is far more effective. Add in the ability to comment on any object, to get alerts when someone works on an object you are also working on and clear information about who is working on which objects and the power of DecisionsFirst Modeler should be clear.
- Secondly DecisionsFirst Modeler integrates the diagrams and the supporting documentation. Instead of manually checking that your names are consistent between diagrams and documentation, manually making sure your decomposition is the same in both places, DecisionsFirst Modeler keeps everything synchronized. Even if you build many diagrams, each showing a different perspective or element of your scope, DecisionsFirst Modeler keeps track and presents a complete, coherent view.
- Finally by using DecisionsFirst Modeler you build a living model, one you will be able to extend and develop during the blueprint phase. Instead of a one-shot, often "throwaway" scoping document you are beginning to create a true requirements model.
In the next article we'll discuss how to extend this approach into blueprint.
EDIT: Here's a recording of our webinar: Managing and Evolving Decisions with DecisionsFirst Modeler and SAP NetWeaver Decision Service Manag....
- SAP Managed Tags:
2 Comments
