Have you ever worked on a project where the rules to be automated were very complex? Where the business representatives described the rules differently (but essentially used the same logic)? Where the rule inter-relationships made it seem like the rule logic was circular? Where they were difficult to document in a clear and precise format? Where it seemed like the stakeholders each spoke a different language? Where defining the concrete rules to be automated seemed impossible? Well, you are not alone.
I recently completed a project that fit these characteristics. The project implemented regulations and enterprise policies into our processes across a large enterprise. These regulations and policies included independence, conflicts, risk management, financial risks, contracts and a complex approval process. The global regulations and policies had to be augmented with local country policies and regulations across approximately one hundred and forty countries. Up to that point, these complex polices and regulations were implemented in a variety of automated and manual silo systems.
This was the organization’s first BPM project so we hired the best consultants the vendor had on staff. At this time, BPM had matured to the point where it could be used in large scale applications. We were excited that it would provide the process capabilities and flexibility we needed. We followed the vendors’ recommendations, but we ran into gaps because the methodology lacked the ability to present complex rules in a format that the business and IT could easily understand. We used several different approaches, and each of them provided improvements, but they did not provide the clarity in a common technology independent language that would have enabled the rules to be implemented like a well-tuned machine.
We spent a lot of time documenting the business rules but, over time, it became clear to me that they were becoming buried in the documentation, or the code, or the brains of a few key project personnel. As the leader on this project, I came to realize that anyone that did not have the benefit of my in-depth knowledge would have difficulty understanding how the system worked.
Based on these concerns, I decided to search for answers. There had to be a better way to document rules and processes. I found many answers at a BPM Institute training course called “Business Rules 101”. This course teaches a technology independent methodology for documenting business decisions called the Decision Model. The Decision Model addressed my issues because it provided a representation for business logic that:
1. Created a standard for a stable normalized model of business logic2. Provided a missing link in today’s technologies, methodologies, and business practices3. Bridged the communication gap between business and technology professionals4. Functioned as the first step for automation on various technology platforms5. Lead to technology advances that preserve the technology-independent view of business logic6. Enabled faster changes and better impact analysis7. Encouraged better practices whereby non-technical people could create models of business logic
I’m a big proponent of the “keep it simple” philosophy, but policies, regulations and operating decisions are often complex by nature and business personnel typically want to automate everything. I did not want to be in a position where I’m telling a business owner that their business rules should not be implemented because they are too complex. You can document and manage very complex operating decisions in a technology independent language that everyone understands by using the Decision Model.
Once the business decisions are documented, the next step is to document which rules will change and separate them into a BR service. This will give you the ability to change the rules without having to go through a development cycle. I implemented a business rules editing suite for a portion of this application prior to fully understanding these principles. I did this because I knew that portions of the rules would change frequently, and without this flexibility it would be impossible to keep up with the changes. This was a big success, but my assumptions that the rules in the rest of the process would not change were incorrect. They changed more frequently than anyone imagined.
While this project was too far along to fully implement BDM, a window opened when we had to upgrade a major portion of the application. The upgrade involved implementing rules that were considerably more complex. I was able to take a small step forward and the results were impressive. The decision model created the visibility and clarity that we needed to reduce the development cycle (we estimated that this saved us 10% to 25% development time). Rule ambiguities and context became much easier to discuss and resolve. One of the project members told me that it would have been close to impossible to document the complex rules in a traditional format, and I had to agree.
When I listen to deployment teams and users, their questions typically focus on the process (steps, tasks and sequence), the business decisions and related rules. Based on this, I recommend that the Process Model and the Decision Model be the cornerstone of your documentation. Traditional narrative documentation takes a lot of time to create and maintain (if done properly). Using these models will reduce the volumes of words needed to explain your process and rules into a concise and precise format that is easy to understand.
I have a recommendation for regulators. Because of the limitations of describing rules in narrative form, I propose that regulators should be required to document their rules in the decision model (in addition to narratives). The Decision Model speaks a thousand words in a very concise and precise format. This will reduce the time it takes companies to implement regulations into their systems and improve implementation accuracy.
Because of the challenges of this project (which are common to most projects), I’ve dedicated a considerable portion of my time over the last year studying and evangelizing and implementing enterprise business architecture, the decision model and business process management. I recommend that you don’t wait for a complex project to motivate you to implement these disciplines in your organization. Create a plan to evangelize and build a culture that embraces them. This will save you time and money, as well as increase customer satisfaction, improve quality, flexibility and competitiveness.
