What are the rules for building a successful model-driven DSS?
by Dan Power
It is important to discuss what impacts the success of computerized Decision Support Systems. My DSS book (2002) discusses 5 recommendations for finding success in building data- and document-driven DSS (p. 137). In general those recommendations hold for model-driven DSS as well. My recommendations included 1) identify an influential project champion, 2) prepare for technology shortfalls, 3) tell everyone as much as you can about the costs of creating and using the proposed DSS, 4) invest in training, and 5) market and promote the new DSS.
Other authors have written on this topic in the context of building model-driven DSS. In a 1978 book, Andrew McCosh and Michael Scott Morton discussed some rules for building successful decision support systems. I must confess I didn't read their book until 2004 when I bought a used copy at Amazon.com. I had read material from both authors, but not this book. Based upon a "quick" read, much of the material on technology and the examples of DSS are dated, but the conceptual material still seems useful and relevant. In this column I'll share, update and supplement McCosh and Scott Morton's rules (see pages 217-218).
"The first rule is keep it simple. Attempts to handle problems which are outside the experience of the people involved are bound to fail no matter what expertise they bring to bear on them. Attempts to jump immediately from a very straight forward procedure ... to a computer-based solution which deals completely with all aspects of the solution are equally pre-doomed." This rule is similar to the KISS principle of design that prescribes avoiding unnecessary complexity, "Keep it Simple, Stupid" or "Keep it Small and Scalable". But McCosh and Scott Morton emphasize that DSS designers need to have experience with making the decision and the existing process prior to designing computerized support.
"The second rule is tackle significant problems. It is vastly more meritorious to make a simple model that provides a small step toward solving a problem that is strategically important to the overall success of the organization than to produce a sophisticated, mathematically complex model which totally solves a triviality." Some examples of significant problems for DSS from McCosh and Scott Morton circa 1978 include a profit planning support system, budgeting, financial analysis of merger opportunities, and pricing decisions.
McCosh and Scott Morton focused on model-driven DSS and their rules demonstrate the tension between DSS theorists and Operations Research and Information Technology professionals. They argue in rules 3 and 4 "don't let the computer people design the model" and "don't let the operations research staff design the model." The issue is, who should "design" the model in a model-driven DSS? McCosh and Scott Morton's rule 5 states "the manager who is responsible for the subject should be the person who designs the model in its gross form using such help and specialist guidance as he needs." I agree managers must have a sense of ownership of any DSS and especially DSS with a prescriptive model. DSS designers, whether they have been primarily trained in operations research/management science, computer science or software engineering need to understand and involve the targeted users of the proposed DSS in its design.
Rule 6 states "use the staff people to make the model, interacting continuously with the manager as they go." Rule 7 is to "test the model and adjust it." Finally, rule 8 is a corollary of rule 1. McCosh and Scott Morton note "while initial simplicity is essential, it also implies that the manager will, with experience, want more complex models built." Rule 8 "regard the replacement of models by better ones as evidence of vitality, not of earlier errors." After almost 30 years of DSS development many simple models have probably been replaced. So where are we today?
Rule 1: Novel, innovative model-driven Decision Support Systems should be initiated by the managers who would use them.
As technology and circumstances change, we can expect that managers will have ideas for "new" model-driven DSS. The advent of handheld computers and wireless technologies are examples of technologies that managers may choose to adopt for decision support.
Rule 2: Users and technical specialists should periodically review, evaluate and adjust existing model-driven Decision Support Systems.
Many model-driven DSS are "legacy" applications that potentially could be upgraded and improved.
Rule 3: Decision Support System projects must meet a need and provide benefits that justify the ongoing cost of operating, maintaining and upgrading the system as well as the cost of building them.
While the most strategically significant DSS projects should still receive the highest priority, many potential DSS applications are now feasible that would not have been cost effective in 1978.
Rule 4: Model-driven DSS should be built by teams that include potential users and technical specialists.
Conceptualizing a model in its "gross form" for a model-driven DSS is not the major issue it once was. We understand various categories of models much better than we did 30 years ago. Using heuristic models peculiar to a specific manager is a different matter. If a manager wants to build such a model, they need to help a model builder understand the relationships and rules they want to use in making a specific decision. Such models should then be tested and validated.
Rule 5: In every case, all things being equal, choose the path of least resistance when building and implementing DSS.
This final rule is troubling to me and I doubt if it is necessarily true for building successful DSS. I include it to create some controversy. What do you think?
Perhaps this Ask Dan! will stimulate discussion about factors that lead to success in building Decision Support Systems of all types. As always your comments and suggestions are welcomed. Many thanks to Andrew McCosh and Michael Scott Morton.
McCosh, A. and M. S. Scott Morton, Management Decision Support Systems, Macmillan Press, 1978 (1980 reprint).
Power, D. Decision Support Systems: Concepts and Resources for Managers, Westport, CT: Quorum/Greenwood, 2002.
Last update: 2006-10-22 16:32
Author: Daniel Power
You cannot comment on this entry