So I'm almost finished with my first Business Rule Framework plus project and ramping up on my second as we speak. My first project has been an immense joy and a challenge at the same time. For some project context, my outgoing client is using BRFplus alongside SAP's Grants Management module to build all of their business rules for an automated student loan processing solution. The main theme behind the rules component of the project was to get all those student loan rules into the hands of the business, so they can understand and control more of the business directly instead of having to rely on a programmer who is a couple years away from retirement. My next project is using BRFplus alongside SAP's Claims Management module for automating the rules around insurance claims.
I wanted to spend some time today and share my experiences I am having on these projects. I learned a lot of things about how to have great success with BRFplus, and also what doesn't work. I can't share everything in one blog though, so this entry will start off by sharing my experiences with getting the scope of a BRFplus project right during the project preparation phase. Considering that the product is so new to the SAP world, most people in the field don't really know how to get this kind of estimate right. The following points are not intended to be a guarantee for a 100% accurate estimate (that's impossible). They will however guide you to ask the questions which give you the input you need to understand how big your BRFplus project is. That input should then allow you to get a ballpark estimate.
I also want to mention before I start that I spent a lot of time collecting these lessons over the last few years. Although I'm well into the field of business rules now, I came into it as a programmer originally. A lot of the credit for my lessons learned around scoping should go to Gladys Lam and James Taylor as their books and presentations were extremely helpful in educating me on proper business rules scoping and analysis.
Understand the Business Goals
Understanding the business goals is the very first thing we need to do when getting into a rules project. We SAP professionals are the providers of business solutions, and the solvers of business problems. A lot of SAP projects seem to forget this though. People get too caught up in the blue and white logo and they don't even consider the actual business they are dealing with. People only see that they are 'implementing SAP', and forget about the actual business solution they are actually providing.
If the business says they want a 'rules engine' to solve all their problems, that doesn't really say much. Getting a proper understanding of the actual business problem first is critical before you can begin to understand how to provide a solution and consider a tool such as BRFplus.
How Many Rules?
The first really big question! How many rules do I need to build? How do I begin to estimate the size? James Taylor suggests beginning with the decision in mind. Simply put, you need to get a general breakdown of how many decisions, and how many rules are required to make each decision. Mind mapping is an easy way to do this kind of brainstorming. See below for an example mind map which breaks down a decision.
Once you get your decisions broken down, you need to estimate the number of rules that go into each decision. A simple approach would be to take a couple of larger decisions and work with the business to determine the rule count for them. You can then use that as a starting point to estimate your other decisions to get a ballpark rule count. Take note that at this point you don't know if the rules will be implemented in BRFplus, ABAP or customizing. All you are getting right now is the high level count.
Also keep in mind, that when counting rules you need to consider that a rule contains both a condition and a result. This certainly doesn't mean your rules are all IF/THEN statements, but in order for something to be a rule it must exert some sort of guiding behavior to the business.
How Complex are the Rules?
Some decisions are easier to make than others regardless of the number of rules. Some decisions might include a high volume of simple rules, and some might include only a few rules but are very complex. Rules which are very mathematical in nature will naturally be complex to harvest and build since it involves a high level of precision. From my experience global rules also become complex since they need to be written carefully for reuse by other steps in a business process. When analyzing the rule sample for estimation purposes, the complexity will naturally come out. In the end we need to understand per decision how many rules are high, medium and low complexity.
Estimate the Baseline Effort
At this point we have an initial rule count by decision, and an estimated complexity to those rules. Now we need to understand the actual effort of implementing those rules to estimate how big the bucket is. Gladys Lam suggests that it takes approximately 45 minutes to harvest a rule. What about implementation and testing though? Below is a simple matrix to come up with an initial estimate of effort.
| Effort (Minutes) | ||||
|---|---|---|---|---|
| Harvest | Blueprint | Realize | Test | |
| High | 90 | 60 | 50 | 100 |
| Medium | 45 | 45 | 35 | 75 |
| Low | 15 | 15 | 15 | 50 |
The columns are defined as follows:
- Harvesting is the facilitation and investigation work that goes into actually finding business rules from the source document or system.
- Blueprinting is the analysis and formal documentation of a business rule.
- Realizing is building the rule in the system. Update: This does not include effort to fetch and prepare input data to be used in the rules, nor any external ABAP behind custom built actions.
- Testing is unit testing only.
Now that we have a baseline, let's look at the other things we need to consider for this estimate.
How Many BRFplus Rules?
Technically speaking each decision that is discovered will ultimately have a percentage of rules implemented in either customizing, BRFplus or ABAP. Figuring out the percentage can only be estimated by somebody who has relevant module experience. For example the core SAP ERP modules such as FI, CO, MM, and HR etc have lots of customizing settings available. In these modules the scope of BRFplus is a lot less because a lot of rules can be covered by standard customizing. Some modules such as Grants Management don't have a lot of customizing available though, which means most business processes and rules are implemented in the customer name space. This will typically lead to more BRFplus and ABAP rules.
Low and medium rules can be implemented in either customizing or BRFplus. Medium and high rules can be implemented in ABAP or BRFplus, although if the rule is extremely complex and not likely to change over time then ABAP is the preferred tool. If a project has a mandate to implement every single business rule in BRFplus or customizing (no code) then extra hours must be added onto realization to compensate.
Scope of Rules Harvesting
There are different levels of harvesting that can go into a business rules project. For a BRFplus project it's very important to know if the business wants to harvest the rules and then document them for long term management, or if they just want to document enough information to get the rules into BRFplus. Although most SAP projects skip out on documentation, experience suggests the latter is not a sustainable endeavor for the business and that proper documentation for long term rule management is an absolute must. Add hours to harvesting and blueprinting if long term management in a repository outside SAP is required for the business rules.
How Much SME Time is Available?
The only people that know the rules of a business are the subject matter experts. A good consultant may be able to facilitate sessions to extract the business rules, but the SME's are the ones with all of the rules in their heads. If the SME's time is very limited or sporadic, add hours to all phases of the project as bottlenecks are bound to occur when rule questions cannot get answered.
State of the Source Materials
Are the rules being sourced from an existing COBOL system? Are the rules coming from legislation? Perhaps they are coming from people's heads? Generally speaking rules that already exist in policy documents are not too hard to extract, but rules coming from people's heads requires a bunch of facilitation. Rules coming from COBOL or other legacy systems require much more analysis, and potentially even other pieces of software to try and extract the rules. Add hours to harvesting and blueprinting depending on the state of the rule source.
Vocabulary
Another critical factor to the scope of a BRFplus project is the state of the businesses vocabulary. Business rules are only as accurate as the terminology used to write them. If one user says 'tariff', and one says 'procedure' and the other says 'benefit' then we have a problem. The business absolutely must have a strong and consistent vocabulary before any rules can be written. This is an effort that can take many weeks to accomplish. If the business does not have consistent terminology currently then the scope of the project increases since it will take longer to get that consistent terminology developed. Add hours to harvesting and blueprinting if a lot of work is required to get the vocabulary ironed out.
Experience
What is the level of experience on both the consulting side and the business side when it comes to business rules? Are there strong business analysts available to help discover the rules initially? Is there also at least one seasoned BRFplus resource that is available throughout the entire project life-cycle to work with both the business analysts and the technical team? Blueprinting is a lot of business analysis combined with strong functional SAP experience. Realization on the other hand requires people with both functional and strong ABAP experience.
Are the SME's on the business side going to be writing rules too, or are they only experienced enough to provide information through facilitation? If the SME's are more on the operational side of the business then the project will probably take longer since the implementation team will be doing the heavy-lifting on the analysis side.
Add hours to all phases where experience is lacking.
How Are the Rules Being Validated?
Its one thing to write a bunch of business rules that look and sound pretty good. It's another thing to write a bunch of business rules that both look and sound good, and also represent the actual business. Somehow while these business rules are being written we must have a way of validating how correct we actually are. A simple way would be to take some important mathematical rules and mock them up in Microsoft Excel. This will allow you to at least know if your calculation logic is right. For other rules though Excel doesn't always work.
Another option for validation would be actual BRFplus prototyping. This will add hours to your blueprint, but also minus a few from realization too since you're building working software. While this approach might represent the most accurate validation it's almost the costliest from a time perspective. Experience suggests some BRFplus prototyping alongside Excel prototyping is the best approach from a time and accuracy perspective.
Just to note as well, if you have a lot of budget on your project you can also use tools such as Corticon to input and validate your logic. I'm personally not a fan of this since it involves double-implementation of your rules. I.E. once in the validation engine and then again later in your actual rules engine.
What Kind of Metadata is Required?
So we're capturing some business rules, but there is more than just the rule itself we're capturing. Most likely we need to state the source of the business rule. Did it come out of a policy document, or did it come from legacy source code? What about the point(s) in your business processes where the rules are being called? There are a lot of different pieces of metadata which can be attached to a rule. Common sense dictates that the more metadata you add to your rules, the more effort that will be required to manage this during all phases of your project. Harvesting and subsequent blueprinting of a business rule usually involves numerous transformations and edits before the final rule is produced. The more tracing that is required through these edits, the longer it will take to do the work.
Rule Transformation, or Implement As Is?
Speaking of transformation above, the next question is related to the transformational goals of the rules project? The business rules will likely change a bit just to switch systems, but does this project want to fundamentally change the rules of its business? If we're just switching systems and not changing the rules, then you don't need to really worry. If we are switching systems and also transforming the business rules then extra hours must be added to all phases. The reason we add hours everywhere is because we'll need a lot more time to analyze the business and come up with the new rules during harvesting and blueprinting. In this scenario you would also have no comparison system during realization and testing, so parallel testing against the current system could be challenging.
What Tools Are Available for Harvesting?
Business rules are inherently declarative, and should be written like a Wikipedia entry in a nested structure. When it comes to implementation in BRFplus the rules are authored similarly, with declarative or nested statements. With that in mind, it's unfortunate that the most popular tool to document business rules is Microsoft Excel. This is mainly because people are used to Excel and have maximum control over it as a tool. Unfortunately though Excel is a very poor business rules documentation tool. Version management, team collaboration, and rule nesting is a nightmare. Trying to trace rule usage is extremely difficult as well since trace is essentially done with text filters or find commands.
If your company has a rules project of any complexity but will only be using Excel to harvest and blueprint the rules then add hours onto the harvesting and blueprinting phases. There will be alternatives to Excel discussed my next blog entry.
What KPI's are required for Measuring Success?
So I have spoken about a lot of different considerations to rule harvesting and implementation. After all that though, the business needs to find a way to measure the success of the rules. There are different ways to get key performance indicators for the rules. One would be through typical reporting on your business line. I.E. How many claims are being rejected? How many claims are actually fraudulent?
An additional method would be to analyze the outcomes of each decision made during rule execution. This would entail logging of all decisions that the business rules engine makes, and then analyzing those decisions afterwards to see what the system is doing. If the business wants to measure success using a decision log then hours must be added onto realization since a bunch of work is required to get the decision log into a reportable form.
Fudge Factor
Lastly, once you ask all these questions and update your estimate accordingly there is always going to be the unknown. Different people have different ways they like to handle this, through estimate multipliers and contingency. I'm not going to get into these details here, but it would be advisable to include room for the unknown in your estimate as well.
In Summary
So, as I mentioned above this is not your answer to a perfect estimate, but it should help you ask the questions you need to ask in order to create a pretty good estimate. Starting with a baseline estimate based on numbers and then adding on or subtracting time based on other requirements is a good way to get a ballpark figure. In upcoming blogs I will also be covering the blueprinting, realization, testing and cutover phases of ASAP in relation to business rules and BRFplus. In the end you should be armed with a plethora of lessons learned which will help your rules project immensely during all of its phases.
- SAP Managed Tags:
5 Comments
