In How to Blueprint Your BRFplus Project: Part 1 we began the discussion of blueprinting your BRFplus project, and to kick it off we determined that we need to create a repository to hold our rules, aka, rulebook management. The next thing we need to do before we start cranking out rules is make sure we're speaking the language of the business.
One of my current clients is a private health insurance organization which is embarking on a project to share its claim management system with a public health insurance organization. This is leading to an array of terminology conflicts which we have been trying to address since the beginning of the project. In the public organization they use the word 'tariff', whereas the private organization uses the word 'benefit'. Standardizing this terminology is important because if you do not, there will be a bunch of business rules harvested using the wrong terms which makes the rules inconsistent and harder to implement.
In my experience with SAP projects I see terminology as something that nobody ever spends enough time on getting right. Sometimes people will start to keep a list of terms somewhere in the blueprint, but nobody uses that list in real life and it's rarely updated after it's initially written. This is a huge problem because in many SAP modules the screens use different terms than what the business uses. For example, on a student loan project which used Grants Management, the term 'student' is not seen anywhere in SAP. Instead the term 'business partner' is seen everywhere. Similarly the term 'school' is not seen anywhere. In fact 'business partner' also represented the school depending on which screen you are on! You can see where things can get confusing in this situation.
One of the first steps in blueprinting should always be an exercise of creating a standardized vocabulary of the business. At a bare minimum the output of this exercise is:
- Create a living terminology repository which will be actively used on and after the project
- Identify key terminology the business uses in day to day speak
- Make sure the terminology is used within all created rules and processes
Our list of goals and decisions from scoping is a great starting point to building a proper business vocabulary. We can use these to create the first list of important terms. For example, in a student loan project the goals will probably use the words 'student', 'university' or 'disbursement' so we need to capture these. It's not possible to capture every single term in one workshop (nor should you try), but the initial term gathering is to ensure the core business terms are discovered and then standardized. Later as we begin harvesting business rules the number of terms will quickly grow. These terms should be maintained in the same repository as the business rules, so that when rules reference specific terms the reader can click through to see the definition. It would also be a good idea to collect the technical details of terms so the link from business to system can be made with each term.
Example term in a wiki.
It is absolutely critical to gather an understanding of how terms relate to one another. For example, the terms 'student' and 'application' are connected by the relationship 'submits', which gives us 'student submits application'. Knowing relationships will precipitate a data model, which itself will be a source of many business rules. Many business analysts like to fact model these relationships (which works very well), but I find that using a standard Chen Entity Relationship Diagram works just as well and is more familiar to people. I won't go into the details of how to build these models since they are either already well known or better covered by other people.
So we now have a repository and are beginning to enter our business terminology into it. These terms will be reused among all of the business rules we write later on as well as precipitate some actual rules themselves. Keeping terms in a respository will enforce consistent term usage within rules which simplifies our later BRFplus implementation (as well as the rest of the SAP implementation).
In my next entry I will show how to take our goals and decisions from How to Scope Your BRFplus Project and begin some preliminary business rule harvesting.
- SAP Managed Tags:
