Skip to Content
Author's profile photo Former Member

How to Blueprint Your BRFplus Project: Part 1

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.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Otto Gold
      Otto Gold
      even though the topic is interesting, I don`t see SDN as a marketing channel. I am not sure about your relationship to that product or company, but we don`t do presales here.
      I have some interesting products to offer too, but SDN is not The place for that.
      Cheers Otto
      Author's profile photo Former Member
      Former Member
      Blog Post Author
      Hi Otto,
      It's up to the reader to go and figure out how they want to ultimately document their rules and what tool they use, and I advise not to try and use spreadsheets as their flexibility works well initially but becomes unmanageable after 100 rules or so.

      Up until now every BRFplus project I have been on has used spreadsheets for documenting their rules, and I am sharing my lesson learned that spreadsheets don't work in the long term.  Wiki's are as common as spreadsheets in organizations nowadays, and utilizing them will yield a much better rulebook than spreadsheets can.

      Readers should understand there is other tools available too which are dedicated to rules only.  These tools can have an edge over using a wiki but it comes at a higher cost, and usually organizations that use these kinds of tools are quite mature with their business rules.

      That said this is certainly not a pre-sale activity, it's simply showing BRFplus customers that there is some tools available for documentation that will work better than others.