SAP Business Rules Management (SAP BRM) is a relatively newer product from SAP to address the important challenge of managing the run time execution of business rules. In this blog, we provide the basic background of the need to have BRM capability in our business applications. SAP BRM forms a core part of the business process platform and provides integrations to all SAP products.

An initiative taken from SAP to cater to a new framework while working with Business Process Automation (BPA), yields with BPM(business process management) and BRM(business rule management). Most organizations today are looking forward to use of SAP technologies for automation of business process. Many technical feature enhancements tried by SAP over time to address the business need in terms of process automation, BRM stands a good chance to provide a new perspective in this area.

At Apprisia,we successfully modeled and designed BRM to solve and automate the complex business workflows and integrated with the BPM.

Now, coming to simple language, I can say BRM is new way of understanding the business environment and structuring solutions for the business. Till date, the business process understanding was looked into from control flow, data flow, event flow. The same was used to design the workflows and that worked very well. Making flow charts, creating UI’s, Modeling DB, implementing business logic, system integration with other working frameworks, grouping user control, authorization and access and much more were major functional tasks involved in solution design.
People involved from technical, non-technical, functional non-functional, users, designer, and maintainers backgrounds were addressing their respective role-responsibilities and catering to bug free solution to the working enterprise application. Over a period realizations came resulting in a good list of the challenges that needs to be addressed by each group and role. This lead to a thought for process of designing changes which in turn affect the other roles involved to cater to their own parts in clear operations and comfortable interaction with system (enterprise application) as such.

With above in background, BRM introduces “decision making” as starting point for the workflow design. Consider any business process, thinking on higher perspective the control flow, data flow and many system level validations are actually decisions that are performed by the workflow engine. While designing workflow designer will gather requirement from organization and after analysis decision to be made are coded as part of the solution design. Some of these are configurable e.g. configuration data file, but many things that can be / could have made configurable are left out. The process (work flow) works fine with current time and operation policy.
When the policy/operative procedure changes are adopted in organization, normal work flow design not necessarily always is adaptable to the change. These changes impose a new change and or upgrade to be applied to existing system. Many times making changes is extremely tedious and cost-expensive. These changes/ enhancements also add to net down time for the system in production. These issues are actually makes workflow process clumsy to be accepted by business.

Secondly Functional / business people who plan, control and design business processes find it difficult to tweak and change the application in execution. Every change needs a support from the technical person.
With BRM approach, it is easier to separate out business decision logic to make it more comfortable for business user and functional staff to manage, monitor and maintain. The solution design now needs to think of the decision making logic blocks as separate entity that is configurable and the respective decision are to be pulled on runtime. This separation of decision logic is expected when working with BRM. Simply put, now the solutions designers need to think from a perspective where every small decision criteria of decision making in the operations is identified and technically separated out from design.

BRM concept becomes easy to understand with an example. Surely I will come to it fast. Before that one thing needs to understand is BRM provides a way technical and functional to rearrange coding, management and maintenance of enterprise solutions.

Starting with a solution, let me consider a work flow where one needs to decide if applicant is eligible or not for a given loan. The first condition is applicant should not be minor i.e. age of applicant should be above 18. Here we can have this validation hardcoded in our solution either at UI level in java script or in DB level by not allowing any applicant record below age of 18, or we can have this logic coded in business layer to validate the application. Take my word this application works fine. Now, can we see the problem scenarios in here?
First, where ever coded the age limit is hard coded, if tomorrow policy comes for minor loans, the application will technically impose the limitation to handle the change. In some designs we cannot make this change or in some case this is possible but with large impact on the application operation. Secondly, if organization can have few schemes /products where different ‘age criteria’ for eligibility is to be considered. E.g. student loan cannot be given above age of 40+ or vehicle loan not to be given above age of 50 or certain scheme can have an age range from 30-40 for eligibility.
In this scenario, the hard coding of same in application is tedious and risky work. Also consider that these age limits are going to change for each scheme individually and independently. This is big mess from maintenance perspective. The turnout time for changes is heavy too. Here if we think of a technical module development in the system which caters to only age criteria eligibility and given any scenario will always result in simple decision about eligibility, life would be much simpler.
The same independent technical module would also care for the separate maintenance facility, providing functional people simplicity to understand and maintain it. BRM does the same work. We can create a simple Rule logic and define all different criteria in it and in work flow when and where we need it we just give call for particular module and the complete eligibility will be evaluated.
Need Help:
In case you need assistance on BRM and BPM technology and implementation, please contact us. Please send us your questions, comments or assistance request, and our team would be glad to assist you.

By Mahesh Janugade (on behalf of SAP Consulting Team)

SAP :: Streamlined

We offer variety of services including SAP ECC ,SAP HR,SAP BW,SAP CRM, SAP SCM,SAP BPM, Business Objects, SAP ABAP DevelopmentSAP BASIS and SAP NetWeaver consulting. We have expertise in providing implementation,development, SAP Migration and SAP support services to SAP customers across diverse industries at a global level.
Have a question on SAP? Write to our SAP Architect.

(We promise a no-obligation consulting reply)