Table of contents for BBC2013
- #BBCCon Session: Refining BRM Policies and Practices at Unum
- #BBCCon Session: A Practical Approach to Decision Management/Modeling at Principal Financial
- #BBCCon Session: Trends and Directions in Transformational Processes
- #BBCCon Session: Case Management: Where Rules Meet Process and Content
- #BBCCon Session: Ron Ross on What makes your company smart
- #BBCCon Session: Closing thoughts from the chairs
I am going to attend and blog a few sessions at the Building Business Capability conference. First up are folks from Unum talking about how they are evolving their business rules management policies and practices. Unum is a group of life and health insurance companies, mostly in the US but also in the UK and Ireland. Unum insures 22M people and a third of the Fortune 500 uses Unum for insurance.
Unum have been using business rules for a while and began this effort to refine their approach by trying to solve a documentation challenge where rules were inconsistently documented and largely implemented in code. It was very hard to see what the rules were and even harder to manage them as an agile, usable asset. Separating requirements from business rules was key.
Improving all this has turned out to be complex, partly because change is hard and partly because Unum is a complex company with many products and subsidiaries.
For this effort Unum focused on three critical success factors
- One source of truth to describing how they did business
- Traceability from rule to use case to implementation
- Consistency of usage and approach across roles and groups
They have created a rule inventory with consistent approaches to keywords, traceability etc. They have invested heavily in training, in leveraging their existing enterprise glossary and in a rule governance approach to ensure consistency across groups and projects. All good things.
They have struggled a little with using natural language rules and with rule integrity. It was difficult to find all the rules for a complete decision as they did not group their rules enough – the classic “big bucket of rules” problem. They also struggled to keep traceability from rules to use cases.
- It’s essential to focus on knowing which rules go with which decisions
- Tracebability to use cases steps has to be insisted on
- Not describing decisions as use cases as decisions are part of use cases
- Important to get people to focus on decisions not just rules.
They walked through some interesting examples where trying to map rules to use cases caused confusion, showed how sub-decisions were embedded in rules and rules were assigned to the wrong steps.
Moving forward they are being explicit about the decision they are trying to make, specifying the question and allowed answers very clearly. The decisions can be broken down into sub-decisions and these can be mapped to rules very clearly. These decisions are then explicitly linked to the use case. They are making sure that all the use cases that extend or include the use case also have a link to the decision.
They also focused on their rule analysis approach as they wanted to identify rules earlier in the lifecycle and be consistent about the artifacts they needed for implementation. They standardized their implementation and design around decision services with templates and standard approaches. This helped clarify how they would design the implementation.
However they found there was inconsistency around rule requirements and that too many were being left too late. They also found that the design phase focused too much on requirements implementation not rule implementation. As a result they have extended their training to IT, making sure that the design and implementation teams understand business rules. They have focused heavily on describing rules more fully earlier in the project. They have added rules team members earlier in projects and have educated widely on what a decision service is. There’s clear value in having both business AND IT working on business rules together through the project.
Their focus on decision services, on developing templates and sequence diagrams for decision services has really helped but they have also aligned their rule developers to their delivery teams and focused on more detailed code review that includes the rules experts.
At the end of the day Unum is very sure that Business Rules Management is delivering the agility and value that they need. For all their challenges they see value clearly.
What would they do differently:
- Focus on business decisions and manage decisions not just rules.
- Avoid boiling the ocean by trying to find all the rules before anything else was done.
- Involve critical practitioners earlier.
I found it interesting that Unum is trying to fix its challenges in business rules by gradually taking a more decision-centric approach. Managing decisions, decomposing decisions, mapping decisions to business rules and use cases for traceability, focusing on Decision Management not just Business Rules Management.