BPM + BRM = Greater than the Sum of the Parts
Last month I listened to a webinar hosted by the International Business Rules Forum. It was one of the few webinars before the forum starts on October 26 in Orlando. The BRF’s theme this year is "all around agility". This includes all topics around Business Rules Management, Business Process Management, Business Performance Management, Business Intelligence, Decision Management and other analytic activities.
In this webinar, Sandy Kemsley presented the combination of BRM and BPM and talked about true agility within this combination. This sounds very interesting to me, because my experience is that there is a strong relationship between business process and business rules definition and of course of the management of these assets.
So let’s have a look at what Sandy pointed out in her presentation.
First she defined the BPM discipline as
- a management discipline for improving cross-functional business processes (independent of the technology), and
- the methods and technologies tools used to manage and optimize business processes
Sandy talked about the goals behind all BPM initiatives. She said that the main goal in the last 8 years behind the most BPM activities is to become more efficient. This means increasing automation steps and handoffs and integration systems and data sources throughout all business processes.
After this is achieved, compliance is the next step: with the explicit representation of process definition you can show that you are compliant, because the business processes are now transparent and can be used for meeting new compliance requirements. Since 2005, agility and visibility have been the real important requirements inside the BPM activities. This means to be agile and visible brings the real benefit to organizations to reach their business goals.
This is exactly the reason why I see today a need to take a more in-depth look at the business rules inside the business processes, i.e., identify the business rules and describe this real corporate asset in a complete way: management information, business need, system relationship, rule statements, etc.
Sandy also defined BRM as a
- discipline for discovery and management of business rules, and a
- set of methodologies and tools to manage rules.
What she means is that there is a misunderstanding in many discussions inside the Business Rules context. BRM is much more than technology (or a rule engine). Like the name says, it is both a management discipline and a methodology.
This is what I also have seen in a lot of Business Rules projects: many IT professions see a benefit for their work, but the business department is often outside of those project activities. Often the discussions are tool-based. And often the methodology how to discover, describe, formalize and implement, and deploy business rules is the key factor to deliver successful business rules projects and implement the corresponding governance.
Does your company see that real agility is only reachable by separating BPM and BRM by extracting decisions from processes? Do you think using BPM on the one hand and using BRM on the other hand is enough? In my experience, you need an organization with an enterprise architecture skill to bring both parts seamless together.
What is your experience?