Landscapes paint the big picture. The eye moves along the tips of peaks and the valleys below. Decision inventories function the same. They allow everyone to understand the breadth of what’s in place today and they make it clear what’s missing—especially if half the canvas has no paint. That part of the canvas is ripe for the next steps.
Who cares about decision inventories? Anyone that is new to a leadership role in IT, Enterprise Architecture or someone responsible for Digital Transformation strategies. Taking an inventory is a powerful input for investment, planning and impact.
Where do we find these decisions? In short, decisions are everywhere. For the purpose of an inventory, we sharpen the focus to the areas below:
Existing Decision Services
Decisions are implemented with the care and practices of a seasoned rule author using a decision management capability.
Decisions in code
Automated decisions occur in lots of places. The most common place is code. A bespoke departmental application might contain the automation required for its purpose; however, if the team didn’t open up its key capabilities via an API the decisions they contain remain trapped. Look for behavior that’s useful for other applications. Multi-channel demands on logic are a key driver for value.
Decisions in the expert’s head
Pay close attention to operational decisions that occur with people in a business process. Underwriting decisions are the classic example; however, there are likely eligibility and/or triage decisions lurking around in exception scenarios. If there is a large body of BPMN diagrams, look through them for exception flows.
Decisions in BPMN
Look closely for decisions automated inside a business process. Some BPMN tools support scripting or even light facilities for decision-making. There are always good reasons for this; however, more than likely some of these decisions should be shared. Ignore routing logic in the search. If you see a gateway, look up-stream for the actual decision task.
Decisions as platform script
These decisions do real work. They are often close to the data like a database stored procedure, CRM script, or even an Azure function. If these decisions impact operations, they should be inventoried.
Self-service channels are smarter than ever. More than likely, mobile experiences and consumer portals have duplicate logic or already depend upon a decision. Be on the lookout for disconnected scenarios where the logic must run without network connectivity.
Business events flow through organizations all the time. Look for time-based (windowing) logic that correlates events for the purpose of taking action. While event monitoring and detection is interesting, the action that carries the reusable decision.
Data pipelines and feature engineering
Data ingestion often requires reusable decisions to transform data, establish new data or generate categories. Look inside notebooks, python scripts or third-party products that orchestrate these activities.
Machine learning models are a specific type of decision in their own right. The inventory should make special note of them paying careful attention to models used for discovery (clustering) and models used for operations.
How do we determine good candidate decisions for the inventory? Most relevant decisions impact business operations in significant ways – often they are at the heart of core revenue streams. Stated another way, they are non-trivial. Such is the case with underwriting within a loan origination process. The Loan Origination System (LOS), and all of its parts, determine outcomes. Validation of loan data, for any purpose (completeness, inaccuracy, compliance, qualification, or even assignment to a team member) should be considered a decision of interest.
While ultimately we want to model many of our decisions in DMN, our initial findings are brief. We simply want to understand what the decision is and its impact on the organization. We suggest placing the following columns into a spreadsheet for the initial list:
- Decision Name
- Purpose Description
- Team Size
- Implementation (Code/Script, Human, Decision/ML Platform/Name, )
- KPIs (process cycle time, revenue target, exception count)
- Consumers (Customer Portal, Line of Business Application, External Customer)
- Platforms (Salesforce, Dynamics, Snowflake, SQL Server, Azure App Service, Embedded)
- Status (Live/Production, Under Development, POC, Human/Active)
- Scale (decisions per hr/day/week)
- Mode (Real-time/API, Batch/Simulation)
- Rule count (rule count across rule applications)
Once the list exists (no small feat for a large enterprise) the strategy work begins. We recommend the following although there may be others more specific to your organization:
Any decision in operation without a KPI is not telling its story. The relative value and impact cannot be determined. In the short term, it is possible to quickly workshop the team into KPIs that make sense. KPIs are social and it’s best to do the work with the team.
High-impact human decisions
This is the lowest-hanging fruit. Most enterprise organizations no longer have high-impact manual decisions; however, digging into exception processes is the next step for impact. What percent of straight-through processing can be achieved to reduce exceptions?
High-impact decisions in code/script
This is the most common starting point for decisions. High-impact decisions should be prioritized and scheduled for migration into a rule application.
High-impact and trapped
Be on the lookout for decisions trapped inside other applications from third parties. As organizations scale, they outgrow packaged capabilities for more control and distribution of responsibilities across teams. In some cases, it might make sense to implement duplicate decisions in preparation for a bold move. Shore up gaps in processes that need only a portion of a complete decision.
Are any decisions surfacing across platforms (Java, .NET, JS, CRM, iOS/Android)? What special alignment is required to make these decisions happen if the KPI/ROI is significant?
ML Models not in production
Operational ML models that cannot find their way into production are not driving impact. Prioritize the effort according to impact. Consider combining the data science team members with teams that know how to deploy rules-based decisions.
The decision inventory achieves its value when it starts conversations and has teams aligning together on priorities. As a next step, it helps to move through the inventory for decision modeling activities. DMN models will help the teams understand similarity at other levels – shared data schema, lower level decisions, and more opportunity.