Last week we completed the main phase of a proof of concept project at a client, one based in Jakarta Indonesia. After the report out, I tweeted
Loving watching a Dr at one of my clients explain (in Bahasa) the decision model for claims handling they built #dmn #decisionmgt
Tweets are great for this kind of quick heartfelt observation but I thought a blog post to explain why this is such a breakthrough was called for.
First, some background. This project was to develop a proof of concept decision service for claims handling. The client was already processing claims and integrating a Business Rules Management System. Our project was to build on that, introduce decision modeling, and show them how this decision-centric approach could help them maximize the value of their BRMS investment by engaging business owners, clarifying requirements, and enabling continuous improvement of the decision. Two things made this project exciting for me:
- By this point in the project, the business SMEs have not only worked with us to create the model, they have also been using the model to discuss their own business. What makes a claim complex or risky? How do we want to handle this type of claim from this type of customer? This has brought clarity to their decision-making, making it possible for us to automate it but also enabling them to improve the manual aspects of the decision-making and the role of the decision-making in the overall claims process.
In our experience, decision models provide a unique vehicle for this kind of debate and engagement among business SMEs. They give SMEs a way to deeply understand and build agreement about they way they want to make decisions.
- Having worked with this decision model, these SMEs can now stand up in front of a crowd of their peers and colleagues and explain the decision model, discussing exactly what it meant for how claims are going to be processed. This is transformative: This is not a group of business users who understand their requirements but a group that understand the system, the algorithm that will drive their decision making.
The sense of ownership, the clarity, the degree of detail with which they understand this new system component are amazing. This is not a black box to them. They understand and can explain how they will monitor and improve it. This understanding and their willingness to assign one of their number to monitor and improve the rules in this decision service every week – is truly inspiring.
I am looking forward to seeing this in production, and looking forward further to working with this very impressive group moving forward. Now if only I spoke Bahasa…
Drop us a line if this is something you would like to know more about.
Some other notes on the project for the more geeky among you:
- We worked directly with the subject matter experts to build a decision model using the Decision Model and Notation (DMN) standard and our DecisionsFirst Modeler and methodology. These models are very effective at eliciting requirements for decision-making systems, helping the subject matter experts clarify their approach
- We (partially) implemented this model in a commercial BRMS to show how this would work. All the artifacts created were linked back to the decision requirements we modeled. This enables the business users to easily find the rules they want to change, take advantage of the impact analysis of a decision model and still use the governance, version control and security features of a modern BRMS.
- The decision model identified clear opportunities for predictive analytic models, modeling the decision-making that would leverage those predictions. This means that the analytics team has a clear goal as it analyzes data and knows exactly how to operationalize models they build.
- A dashboard was then designed to show how the data produced by this could be used to monitor and continuously improve the decision and the rules that automate it. The data created by executing the decision model -all the sub-decision outcomes – is exactly the data needed to analyze the overall decision-making approach when it fails to deliver the business outcome desired. No additional design work is required for the dashboard – all the work has been done by designing the decision