What is decision-oriented diagnosis for building DSS?
by Dan Power
Editor, DSSResources.com
Decision-oriented diagnosis is an approach and a way of analyzing the need for computerized decision support. It has been discussed in the academic literature for more than 25 years (cf., Stabell, 1983). I am concerned that today too many Information Systems analysts trained to work with transaction processing systems neglect this task and too many managers do not understand how important diagnosis is for building useful DSS.
Why am I concerned? I receive hundreds of email questions related to DSS each year and a frequent question is "How do I build a DSS for X?" or "What kind of DSS do we need?" My response is "you are asking the WRONG questions." If you want to start a decision support project, begin by diagnosing problems and opportunities associated with current decision processes.
According to Aberdeen Sales and Marketing Advisor e-newsletter (August 22, 2007), "Executives and line-of-business management are increasingly feeling the pressure to enable timelier and more accurate decisions, and to align the organization to more effectively address KPIs." Building new, innovative decision support systems will be a priority and many inappropriate DSS will likely be built.
Sadly, it is very easy to buy a software package before diagnosing and identifying the "real" problem and the extent and nature of the need and requirements for a new decision support system.
Increasing decision-making effectiveness through changes in how decisions are made should be the major objective for any DSS project (cf., Stabell in Bennett 1983, p. 225). Stabell proposes a decision-oriented design approach for DSS. He argues "analysis and diagnosis prior to design are key activities in a decision-oriented approach" for actually building DSS (p. 232)."
Stabell's writings have had a major impact on my approach to building computerized decision support systems. He asserts that diagnosis of current decision-making and the specification of changes in decision processes are the activities that provide the key input to the design of computerized DSS. Diagnosis is the identification of problems with or opportunities to improve current decision behavior and decision processes. Diagnosis should involve determining how decisions are currently made, specifying how decisions should be made, and understanding why decisions are not made as they should be. A specification of changes in decision processes involves choosing what specific improvements in decision behavior are to be achieved. These statements of improvements provide the objectives for the DSS development.
He notes "The choice of improvements to be achieved reflects a trade-off between: (1) the benefits of resolving/removing the different problems identified in the diagnosis of the current decision behavior, and (2) the costs of the necessary changes in the decision situation. It means considering not only what is desirable, but also what can possibly be achieved (p. 233)."
Stabell prescribes three activities for diagnosing problems with decision processes and behaviors:
1. Collect data on current decision-making and processes using techniques like interviews, observations, questionnaires and analysis of historical records;
2. Establish a coherent, detailed description of the current decision process;
3. Specify a norm or "best practice" for how decisions should be made.
These analysis activities are interdependent and provide a focus for the decision support technical analyst and for managers. The description is evaluated to create a diagnosis which leads to developing formal requirements for building a new DSS or changing an existing DSS. It can be difficult to determine how a current decision process differs from an effective process, but that is a major goal. Once a diagnosis is made it is important to determine if a computerized decision support system is an appropriate solution.
Stabell argued "diagnosis must necessarily depend on the level and scope of the analysis of decision processes (p. 246)." That is especially true in modern, complex global organizations with many existing computerized decision support systems.
Stabell notes that good diagnosis is difficult and we must all remember the challenges of the task. On a hopeful note, he asserted diagnosis "involves skills that can be developed and sharpened (p. 246)." Many decision support teachers and trainers try to foster skills in decision process data gathering, decision process description, and prescribing effective decision processes.
Decision processes are often entrenched in organization practices, routines and policies and managers and the DSS analysis team must examine constraints. In general there are usually some elements of any organization decision process that can be improved (cf., Stabell p. 247). A computerized DSS is not however always the way to achieve significant results.
For 40 years, analysts have had to make a "trade-off between (1) the depth of the capabilities that a system might bring to bear on any single phase of the decision process and (2) the scope of the process that the system is designed to support (Stabell, 1983, p. 249)." A narrowly defined process with a single decision is much easier to support than a more broadly defined process with multiple interdependent and possibly sequential decisions all supported by the same DSS.
Today, with web-based DSS and work flow software, it is much easier to build a comprehensive decision support environment involving multiple steps, people and multiple subsystems; but it remains difficult to analyze, design and build such broad, complex computerized systems.
Another decision-oriented approach to evaluating decision support needs is to conduct a Decision Process Audit (cf., Power, 2002, p. 58). In general, auditing operational and managerial decision processes can be very useful. An audit is a first step in identifying opportunities to redesign decision processes and include new decision aids and decision support systems in business processes. In some situations, an audit suggests changes in decision technologies that can improve performance and reduce costs. When an audit is complete the central questions should be how can we do better and what changes if any should have the highest priority.
Decision Process Audit Plan Steps
Step 1. Define the decisions, decision processes and related business processes that will be audited. Define the authority of the auditor, purpose of the audit, scope of the audit, timing of the audit, and resources required to perform the audit. Identify the owner and primary contact for each major decision process.
Step 2. Examine the formal design of each major process. Diagram each process and specify the decision criteria currently used.
Step 3. Examine the actual use of the decision process. Observe the process. Interview decision makers and collect data. Is the process implemented and used as it was intended?
Step 4. Assess performance of actual decision processes. What works? Can cycle time be reduced? Are decisions appropriate? Timely? Cost effective? Is the process producing value in achieving business objectives? If not, why? Determine if a decision process is effective and efficient.
Step 5. Reporting and recommendations. Summarize steps 1-4 in a written report. Discuss what is working well and what needs to be improved. Develop recommendations for improving major decision processes. Hold an exit meeting with decision makers.
Both managers and MIS staff need to work on completing the diagnosis task. Does diagnosis always provide sufficient information for specifying a DSS? No. In most cases the diagnosis does provide sufficient information for specifying several alternative designs. DSS design usually involves a number of difficult tradeoffs. The first tradeoff is whether the DSS should support both the existing process and a prescribed new process. There is also a trade-off in the extent of the capabilities of the DSS and the scope of the process the DSS is designed to support. In most cases the initial version of a DSS focuses on either extensive capabilities for a narrow scope process or few capabilities for a broad scope process.
I agree with Stabell that a decision-oriented approach can "counter the tendency for information systems to be developed as an end in themselves (p. 232)." We should strive to build decision support systems that will lead to better, more timely decisions.
As always your comments, suggestions and questions are appreciated.
References
Power, D., Decision Support Systems: Concepts and Resources for Managers, Westport, CT: Quorum/Greenwood Books, 2002.
Stabell, Charles B., "A Decision-Oriented Approach to Building DSS," in John L. Bennett, Building Decision Support Systems,Reading, Mass.: Addison-Wesley, 1983, pp. 221-260.
Last update: 2007-08-22 08:11
Author: Daniel Power
Print this record
Show this as PDF file
You cannot comment on this entry
