So picking up from where we left off with How to Scope Your BRFplus Project, we have completed our scoping exercise and are ready to move into the blueprinting phase of our SAP BRFplus project, which is what this blog will now cover. I plan on releasing these next few blogs in chunks as the topic of blueprinting is too extensive to cover in a single entry.
Just to review, here are the artifacts we have coming out of scoping:
Business and project goals
High level list of decision points
Ball park estimate of the how long it will take to harvest and build the business rules
The first two items (goals and decisions) will be the largest input into blueprinting. Through blueprinting we are going to continue with the goals and decisions and create business processes. The processes will then allow us to identify business rules. For our blueprint we need to make sure we capture all required details of each business rule so that a BRFplus developer can later pick up our blueprint and begin working in the system. The process will be highly iterative and will most likely find gaps from scoping which were not picked up.
In the end we want to ultimately create a ‘rulebook’ which will become the master source of all business rule logic. This rulebook will be a large piece of the SAP blueprint but it will not likely be the exact same document for technical reasons.
The Right Tool for the Right Job
Before we begin blueprinting, we need to have a place to store all this information for both the duration of the project, and then for the business in the long term. This is called rulebook management. Most projects use Microsoft Word and Microsoft Excel to do this. While that works, it is highly unintuitive in many cases. For example, business rules and business terminology are not sequential in nature and are best stored in a format that resembles dictionaries and encyclopedias. This way terms and rules can link to each other logically speaking but require no sequence in order to make sense. A wiki is probably the cheapest and simplest tool to store rules and terms since it allows interlinking of logic via hyper-links, and most usually provide a powerful search for finding logic.
I strongly suggest avoiding Microsoft Excel as the tool for documenting business rules in the long term. Excel can be used to get the initial collection of rules as most likely the rules will be highly unstructured and the sorting/filters will come in handy to give the terms/rules their initial structure. However once the rules are in a semi-stable state, I would definitely move them into a more user friendly repository such as a wiki. Searching through a database of rules is much easier than searching through dozens of Excel documents scattered throughout a network.
There are also tools such as RuleXpress out there which are even better than wiki’s for this if your company has the budget for it. The key take away here is that we want the business to be able to manage their rules outside of the system in the long term, and something as simple as a wiki will allow them to do just that.
So now that we have the tools, we’ll tackle the business vocabulary in my next entry.