Now that we have began collecting vocabulary and identifying how terms relate to one another (see How to Blueprint Your BRFplus Project: Part 2) it's time to collect business rules. To do this we will use the business goals and decisions to form the business processes, and subsequently harvest the business rules. Please note that there is a lot more awesome stuff that is written about business motivation and business processes alone and that is not what I will be spending much time on. Rather I will simply highlight how these things ultimately lead to business rules.
A Strategy for Understanding the Flow
In order to harvest our business rules we need to have a starting point, and the business goals from How to Scope Your BRFplus Project will serve as that starting point. An example goal in could be to decrease manual workflow of student documentation by 80%. Below is an example diagram modeling how we get from goals to processes.
We can see above that our tactic to achieve the goal of workflow reduction has an impact on the documentation workflow process. That said, what exactly is the documentation workflow process? Our decisions that we modeled during scoping will serve to describe the initial process as shown below.
As you can see above we have details at the decision level. So from here the decisions must be sequenced into processes, which will become our inputs to harvest business rules. The below is a simple example of taking the decisions above and creating a simple business process.
Separating the Flow from the Know
Some people in the world of SAP don't know the difference between a business process and a business rule. To them everything is just blue screens powered by procedural ABAP code. However in order to harvest business rules it is critical to understand that business processes and business rules are two different things. As mentioned above, business rules are inherently declarative (no sequence), while processes are purely sequential. One step in a business process could be to fire off one or more business rules. Those rules however will fire off in no particular order. If they do require order, then they should be represented separately in the process as process steps instead of as business rules. Take the following example of determining required documents from the first step of our above process:
Since there is actually no sequence required for the steps above, this could be better represented as rules as follows:
- A student must show documentation of their student number if a student number is not specified on their application.
- A student must send in bank balance documentation if their bank balance changes.
These rules could then be fired off from within the 'Determine required documents for student' step itself, instead of spawning a sub process with lots of gateways. Usually when you see lots of gateways in your business process you will find opportunities to simplify with business rules.
Here lays most of the effort in documenting the blueprint now, as each step in the business process may yield one of more business rules. We must now document every rule we harvest in the rule repository as we iterate through the business processes. As you iterate through the business processes the different steps which call business rules must be highlighted in the process diagram as rule tasks. BPMN 2.0 offers an activity type called 'rule task' which is used to designate an execution of business rules.
This iterative process should yield the majority of the business rules to be documented. In my next entry I will show how to properly decompose and document those business rules in a way that makes it easy to implement them in Business Rule Framework plus, as well as other places to search for and harvest business rules.