Automation has played a fundamental role in enabling businesses to make better, more consistent and more strategically sound decisions. Increasingly sophisticated cloud-based software has given organizations the capacity to define the policies and regulations that drive decisions, and then to incorporate analytics into models – decision services – that can be refined to account for changing conditions.
But software is only the toolset. Decision automation can be effective only as an enabler for an effective process to decide what decisions to support using decision services, and how those services will be used to drive business processes. For that purpose, a proven, documented process is required.
FICO facilitates decision service development for its clients using a methodology called Decision Requirements Analysis (DRA), developed by Dr. Alan Fish, Principal Consultant, FICO Decision Solutions.
DRA focuses decision-makers’ attention on a domain of decision-making and decomposes it into a network of decisions, which are documented in the form of a Decision Requirements Diagram. The work is done during a facilitated Decision Requirements Analysis Workshop (DRAW).
“An organization may have millions of business rules, and only a small fraction of them will ever need to be represented in a decision service,” Dr. Fish explains. He designed DRA as a top-down method to scope and direct decision service development so that the actual design work can be done in an agile fashion.
Dr. Fish has conducted numerous DRA workshops himself; he laid out the methodology in a 2012 book, Knowledge Automation: How to Implement Decision Management in Business Processes (John Wiley & Sons, Inc.).
A DRAW proceeds in five discrete stages:
- Identify the decision points. The group examines the points in the business process where automated decisions will be required, names each decision point, and documents where in the business process it point occurs. The team defines the role of the decision service and the roles of users or other system components.
- Define the top-level decisions. For each decision point, the group identifies the main decisions to be made by decision services. They formulate a question that characterizes the decision, with a defined set of answers, along with any other results that must be returned with the answer.
- Decompose the decision-making. At this stage, the group builds a complex graphical representation called a Decision Requirements Diagram (DRD), capturing all of the knowledge, data or decisions that will be needed to define the decision service in scope in the form of “nodes.”
- Describe the nodes in detail. For each decision node, the group deep-dives into how the relevant knowledge and data are used in reaching the decision.
- Define the decision service boundaries. Having defined the decision structure, the group decides which nodes are to be implemented as part of a decision service and which are to remain in external systems. They determine which nodes are required to define a decision service and draw a line around them to define the service boundaries.
This approach can define the entire decision service development project, and further, it enables the project to be broken down coherently in to chunks or “sprints” for organizations that use an agile development approach.
Dr. Fish explains this process component of decision service development in a new “Hot Topic Q&A” report published recently by FICO. Download the report here. If you’re interested in learning more about advanced implementation and usage approaches to decision modeling, be sure to visit our user community.
