The other day I met with a team from a biomedical company to discuss setting up a Business Process Center of Excellence. Their leadership realized that they could not advance their project much further without implementing a BPM Center of Excellence. They understood that they needed to change traditional silo business thinking to an end-to-end business processes approach. They have an excellent company, very bright staff, and a clear vision for using BPM to improve efficiency, reduce costs, and improve quality. My meetings included a VP, CIO, and Data Center of Excellence leader.

During one segment of the meeting, their enterprise architect showed me a high-level information/sotto process flow chart and he explained his thoughts on how to automate their manual processes to achieve significant savings and improve quality. As he walked me through an impressive chart, I had to bite my tongue because I realized that, while they understood their need for BPM, they did not realize that they had missed a strategic cornerstone of the project. Their processes were highly dependent on complex business logic and they did not have a solution for documenting the business decisions/rules. I took a deep breath, put on my least intimidating tone of voice and popped the question; "what are your plans for mining, documenting and implementing the business logic?" I must have delivered this question well because he calmly answered that they didn't have a solution.

I used the opportunity to walk him through the Decision Model and showed him how it organizes business logic (business rules) into well-formed structures that are predictable, maintainable, and normalized. It provides the ability to discover business logic that is incomplete, inconsistent, duplicated, and sometimes wrong. It also makes it possible to simplify processes and dramatically reduce the number of business rules.

I went on to show them that Process charts work well for documenting sequential tasks but they are not designed to document business logic. They are inherently different, processes are procedural and decisions/business logic is not sequential. A Decision Model is a structure of business logic that makes business sense, not an arbitrary collection of business rules written in an unstructured natural language.

The architect challenged my approach by pointing out that they may have over ten thousand business rules, insinuating that the Decision Model could not handle logic that complex. In my experience, that is exactly what we do with the Decision Model. When properly modeled, these thousands of business rules consolidate into what may only be a few hundred business decisions. Each of these business decisions is well-known by the business, who understand the business significance and operating impact of each of the decisions. The business can then manage each decision discretely and ensure that each decision is governed by business logic (or business rules, if you like) that meets the organizations objectives. Managing a few hundred business decisions, each with a clear business objective, is much easier than managing an amorphous mass of thousands of business rules. In fact, the Decision Model uses the time honored solution to the problem of complexity by the reduction to simpler, more understandable structures. The key to the Decision Model is that it uses the inherent structure of the logic to constitute these simpler structures so that they are predictable, verifiable and have logical integrity. The fact that the structures use the boundary of the business decision ensures that they also have business significance.

He looked at me skeptically, so I asked, "So, how are you going to do that?" There was a lengthy silence.

The CIO broke the tension by saying that they were thinking of using one of the popular business rules management systems (BRMS) to manage the business rules. While a business rules technology is great for separating the rules from the processes and executing business logic at run time, it is not a solution to the problem of discovering, documenting and managing the business rules from the business perspective.

A typical, and very recent experience springs to mind. I was part of a team that was brought in by a major health-care insurer to help with issues in their membership systems. It seems that across this very large enterprise there were no less than six membership systems, and with business changes looming, management needed to consolidate these systems. They learned that the business rules in each of these systems were "lost"--that is they were buried in the code. Two of these systems were implemented in a popular BRMS system, and the business rules in these were no less "lost" than in the other systems! In fact, as we implemented a methodology to discover the business logic in their processes, the business subject matter experts on the project team were constantly surprised (and not pleasantly!) to learn of some of the logic implemented in their BRMS systems.

A BRMS does not provide the ability to document business decisions/logic in a technology independent, rigorous and normalized method that everyone (IT and Business) can easily understand. In fact they are IT tools, and are most often employed as IT centric solutions.

I cannot throw stones or sit in judgment because years ago I had the same problem in a large global project that automated a significant number of complex regulations (business logic). Part way through this project I realized that the business logic was often miscommunicated, incorrectly interpreted by the technical staff, and the rules were getting buried in the code making the application difficult to update and maintain. In this project, the Business Logic was documented and programmed the same way it has been done since the inception of the computer using natural language. They wound up buried in the code even though we were using one of the popular BPM suites.

Until I implemented the Decision Model for the first time I did not realize how much the traditional methods (natural language business rules) were costing me in time and lower quality. From my experience and from talking with other companies, using a business-focused method of understanding, capturing and managing the business logic--regardless of which technology they are implemented in--enables system agility, and reduces project risk. The Decision Model is the best solution I have found to achieve this.

Conclusion: How are you going to organize and manage your business decisions/logic in a method that the business and IT can easily understand? How are you going to organize your business logic (business rules) into well-formed structures that are predictable, maintainable, normalized, and that are understandable by the business? How are you going to discover business logic that is incomplete, inconsistent, duplicated, and sometimes wrong? How are you going to simplify your business processes by removing the declarative logic out of the processes? How are you going to reduce costs and improve quality, competitiveness and agility?

The solution that I discovered is to no longer accept existing natural language methods for documenting business decisions/logic but rather implement the Decision Model. In my experience, the impact was dramatic. So, how are you going to do it?

About the Author: David Pedersen has over 25 years of experience in finance, technology and developing solutions for global infrastructure initiatives for industry and non-profit organizations. Prior to joining KPI he was director at Ernst & Young, LLP where he developed and implemented complex Global infrastructure systems. Prior to joining Ernst & Young, LLP, he developed solutions for the hazardous waste industry, legal profession, insurance and printing industries, and non-profit organizations. He is a CPA and a licensed pilot, who lives in Ohio.
BPM Institute