Sprague (1980)“Framework for Developing DSS”

Understanding Decision Support Systems: A Framework

We are seeing a major push in how computers help organizations, and it’s called Decision Support Systems, or DSS. Some people think it’s a big new step, while others just see it as a new trendy phrase.

One idea is that computer systems have naturally grown from focusing on daily tasks (like EDP) to managing information (like MIS), and now to DSS. In this view, DSS takes over where MIS leaves off. However, another perspective is that DSS is just a specific part of what MIS already is and will continue to be. There’s also the idea that these systems have been around for a while, and now they just have a name. Skeptics, though, worry that DSS is just a “buzz word” created by computer companies to sell more products.

This article aims to look at these different views and offer a way to understand DSS better. It presents a framework that brings together the main concerns of the people involved with DSS, including the managers who use them, the people who manage the computer departments (MIS managers), the specialists who build the systems, the designers who create the technology, and the researchers who study DSS.

What is a DSS? Different Ideas and Key Features

In the early 1970s, the idea behind DSS was first called “management decision systems”. These early systems were described as computer systems you could interact with, designed to help decision makers use data and computer models to solve problems that were not clear-cut or well-defined. The key words here were interactive, computer based, help decision makers, utilize data and models, and solve unstructured problems.

However, this definition was quite narrow, and not many actual systems completely fit it. Some people then broadened the definition to include any system that helps in decision making, meaning almost any computer system except those just processing basic transactions could be called a DSS.

The problem with both the narrow and broad definitions is that they don’t really help us understand the value of DSS, what technology is needed, or how to build one. It’s also confusing because people from different backgrounds, like managers and computer experts, often see DSS very differently.

Instead of just definitions or lists of examples, looking at the capabilities or characteristics of a DSS is more helpful. These are the abilities needed for a DSS to achieve its goals. Some key characteristics observed in systems often labeled DSS include:

• They are often aimed at the less structured, fuzzy problems that managers, especially at higher levels, deal with.
• They try to combine the use of computer models and analytical tools with the ability to access and retrieve regular data.
• They focus specifically on being easy for people who aren’t computer experts to use and work with the system directly.
• They emphasize being flexible and able to change easily to keep up with changes in the business environment and how the user prefers to make decisions.

So, is DSS really different, or just a new term?

DSS Compared to EDP and MIS

A lot of the confusion between terms like “DSS” and “MIS” comes from the difference between a formal, textbook definition and the common understanding based on what systems are actually used. The common understanding often sees DSS as the next step after EDP and MIS.

Using a simple organizational chart as a model, this common view can be explained:

• EDP (Electronic Data Processing) first focused on the lowest levels of the organization, automating basic paperwork. Its features included focusing on data processing for daily tasks, efficient handling of transactions, running computer jobs on a schedule, organizing related files, and producing summary reports for management. Over time, EDP became very efficient at processing transactions.
• The MIS (Management Information Systems) approach moved the focus higher in the organization, adding emphasis on connecting different systems and planning how information is used. In reality, MIS often meant focusing on information for middle managers, having structured information flow, organizing computer tasks by business areas (like production or marketing), and allowing users to ask questions and generate reports, usually using a database. MIS added a new level of information for managers but was still largely based on information flows and data files.
• According to this common view, DSS is aimed even higher in the organization, with features like focusing on decisions (often for top managers), being flexible and quick to respond, being started and controlled by the user, and supporting the individual ways managers make decisions.

This view makes sense because it roughly matches how computer systems have developed over time. However, this common view has some big drawbacks and can be misleading:

• It suggests decision support is only for top managers, but decision support is needed at all levels of management.
• Decisions at different levels often need to be coordinated, so a DSS should also help people communicate and work together across different levels and within the same level.
• It implies that top managers only need help with decision making, but managers do many things that can be helped by information systems.

Also, many computer professionals see MIS as covering all the systems and activities needed to manage and use information in an organization, not just the narrow view.

A Broader View: The Role of DSS in Information Systems

Looking at the bigger picture, the main goal of information systems in an organization is to improve the performance of people who work with information (“knowledge workers”) by using information technology. This includes managers, professionals, analysts, and clerical staff whose main job is handling information. The goal isn’t just storing data or producing reports, but helping people perform better.

A helpful way to picture this broad view is using a triangle model. Traditionally, this showed management levels vertically and business areas horizontally, with transaction processing at the base. The source extends this with a depth dimension showing major technology areas that support knowledge workers.

Three main areas are shown:

1. Structured Reporting Systems: These provide the regular reports needed to manage the organization and meet outside requirements, evolving from EDP and the narrow view of MIS.
2. Communication Systems: These are developing quickly from advances in telecommunications, office automation, and word processing.
3. DSS: This seems to be growing from combining information technology and methods from operations research and management science, often in the form of computer models you can interact with.

So, a DSS is not just a replacement for EDP or MIS, and it’s not only for top management. It’s a type of information system that uses data from transaction systems and works with other parts of the overall information system to support the decision making of managers and other knowledge workers. DSS requires a new mix of technology to meet needs that haven’t been addressed before. It has the potential to be a powerful tool to improve effectiveness in organizations.

The Framework Explained

To understand this evolving area better, the article presents a “framework”. A framework helps organize a complicated topic, show how the different parts relate, and point out areas needing more development. This framework has two main parts:

1. The first part looks at:
   • Three levels of technology that have been called DSS.
   • The way of developing DSS that is emerging.
   • The roles of key people in building and using DSS.
2. The second part describes a model to look at the goals and capabilities of a DSS from the perspective of three main groups involved: users, builders, and technology developers.

Three Levels of DSS Technology

It’s helpful to think about DSS technology at three different levels, used by people with different technical skills and for different types of tasks:

1. Specific DSS: This is the actual computer system that a specific decision maker or group uses to handle a particular set of problems. It’s like a specialized application. Examples include a system to manage investments or a system used by a police officer to analyze crime data and plan patrol areas. The police system used maps and data interactively to help the officer try different patrol plans, effectively giving tools to support judgment. Interestingly, a traditional mathematical model wasn’t as helpful as the system designed by the police officer.
2. DSS Generator: This is a software “package” or system that provides tools to quickly and easily build a Specific DSS. The police system example was built using a system called GADS (Geodata Analysis and Display System). GADS could be used to build another system, like one for routing repairmen, by loading different maps, data, and commands. Building this new system took less than a month. Other examples include systems that integrate different tools like report writing, data inquiry, modeling languages, and graphics under one easy-to-use command system, especially for financial decisions. Many DSS Generators have evolved from planning or modeling languages with added features.
3. DSS Tools: This is the most basic level of technology. These are the hardware and software components that help develop a Specific DSS or a DSS Generator. This area has seen a lot of recent development, including new programming languages, better operating systems for interactive use, and advanced graphics hardware and software. For instance, the GADS system was built using programming tools like FORTRAN, graphics software, special monitors, and a powerful database system.

Relationships Between Technology Levels

The DSS Tools can be used directly to build a Specific DSS, similar to how traditional applications are built. However, this approach is difficult for DSS because they need to change constantly, not just due to outside changes, but also because managers change how they approach problems. This requires involving the user directly in changing the system.

Using a DSS Generator helps create a base from which Specific DSS can be built and changed easily with the user’s help, without requiring a lot of time and effort. The vision is that all three levels of technology will be used together over time.

Evolving Roles in DSS Development

The development and use of DSS involve different roles for people, especially managers and technical staff. Figure 4 in the source shows a spectrum of five roles across the three technology levels:

1. Manager (User): The person who has the problem or decision to make and is responsible for the outcome.
2. Intermediary: Someone who helps the user, possibly just by operating the computer, or by acting as a “staff assistant” to interact with the system and offer suggestions.
3. DSS Builder: This person uses the capabilities of a DSS Generator to put together a Specific DSS that the user or intermediary will use. They need to know a bit about the problem area and also be comfortable with the computer technology.
4. Technical Supporter: This role develops extra computer abilities or parts needed for the DSS Generator, such as new databases, analysis models, or ways to show data. This person needs to be very knowledgeable about technology and have some understanding of the problem area.
5. Toolsmith: This person creates new core technology, like new programming languages, hardware, or software, and makes the connections between different computer parts more efficient.

These roles might not be filled by separate people; one person could take on several roles, or multiple people might share a single role. Who does what depends on the problem, how comfortable the user is with computers, and how user-friendly the technology is. Some managers use the system themselves, taking on multiple roles.

These roles are somewhat similar to traditional system development roles, but there are subtle differences. The user of a DSS plays a much more active role in designing the system. The DSS builder is increasingly found within the business department rather than the traditional computer (MIS) department. The toolsmith is often employed by computer hardware or software companies, not the company using the DSS. This means traditional computer professionals in the EDP/MIS department might have less direct involvement in the DSS process.

The DSS Development Approach

Because DSS deals with problems that are not clearly defined and conditions that change quickly, the traditional way of developing systems (planning, designing, building, installing) doesn’t work well. Designers often can’t even start because the user can’t fully say beforehand what the system needs to do. A DSS needs to be built quickly, getting frequent feedback from users, and must be easy to change.

This leads to Iterative Design. Instead of separate steps, the main steps are combined into a single cycle that is repeated over and over. The user and builder agree on a small part of the problem, build a basic system to help with that, use it for a short time (like a few weeks), then evaluate it, change it, and add more features. This cycle is repeated several times over a few months until a relatively stable system for a group of related tasks develops. “Relatively” is key, because the system will always keep changing, not just when the environment forces it, but as a planned strategy by the user and builder.

This process can be seen as cycling between the DSS Generator and the Specific DSS (as shown in Figure 4), adding or removing capabilities from the Generator to the Specific DSS in each cycle. This approach requires the manager (user) to be very involved in the design. The manager is actually the one doing the iterative designing, with the systems analyst helping implement the changes.

This is different from just building a temporary “prototype”. The initial system is real and usable. The ability to change is built into the DSS as it is used over time; the development process itself becomes the system.

The Adaptive System

In a broader sense, a DSS is an adaptive system. This means it includes all three levels of technology and the people using them, and the entire system changes and adapts over time. Developing a DSS is really about creating and putting in place this adaptive system. Such a system adapts to changes over different time periods:

• In the short term, it helps the user search for answers within a specific problem area.
• In the medium term, it “learns” by changing its capabilities and scope.
• In the long term, it evolves to handle very different ways of working and new capabilities.

The three levels of DSS technology are similar to this adaptive system idea. The Specific DSS gives the manager tools to explore a problem within certain limits. Over time, as the task or environment changes, the Specific DSS must adapt by rearranging parts from the DSS Generator, with the help of the DSS Builder. Over an even longer time, the basic DSS Tools improve, providing new technology for changing the Generators themselves, thanks to the Toolsmith.

While fast feedback and system changes aren’t entirely new, shrinking the typical system development time from years to months or weeks has major effects. This changes the traditional view of how systems are built and managed.

What DSS Must Achieve: Goals and Capabilities

The second part of the framework looks at what a DSS needs to do and what features it must have. This can be viewed from the perspective of the three main “stakeholders” mentioned earlier, related to the technology levels:

• The Manager (User) is focused on what the Specific DSS can do to help with their problems and decisions. They care about the help they get in doing their job.
• The Builder uses the DSS Generator‘s tools to create a Specific DSS for the manager. They are concerned with the capabilities the Generator offers and how they can be put together.
• The Toolsmith develops the basic technology components and puts them together to form a DSS Generator with the necessary capabilities.

Let’s look at the goals and features from each viewpoint.

Manager’s View: What a DSS Should Do

From the manager’s point of view, a Specific DSS should ideally meet certain performance goals. While not every DSS will do all of these, they represent the full value of the DSS concept:

1. Support for Semi-Structured and Unstructured Decisions: DSS should primarily help with decisions that are not routine or clearly defined. These are the types of problems that traditional systems haven’t helped much with. It’s about supporting managers when dealing with “tough” or unclear problems.
2. Support Managers at All Levels: Decision support is needed by managers throughout the organization. The DSS should also help connect decision making across different levels when needed.
3. Support Interdependent Decisions: A DSS should handle decisions made by groups or by several people in sequence, not just decisions made by one person alone. The source identifies three types: Independent (one person makes the whole decision), Sequential Interdependent (part of a decision is passed to someone else), and Pooled Interdependent (decisions require negotiation and interaction). Different types of support are needed for each.
4. Support All Phases of Decision Making: A common model of decision making has phases: Intelligence (finding problems), Design (creating possible solutions), and Choice (selecting a solution). EDP and traditional MIS helped mainly with the Intelligence phase (getting data), and management science models helped with the Choice phase. A key potential contribution of DSS is supporting the Design phase. Some experience shows DSS can also help with the Implementation phase (putting the decision into action).
5. Support Various Decision Processes, Not Be Limited to One: There isn’t one single best way that managers make decisions, and people have different styles. A DSS should offer a set of tools and capabilities that the user can apply in a way that fits their own thinking style. It should be flexible about the process used and controlled by the user.
6. Be Easy to Use: This includes being flexible, user-friendly, and not intimidating. Since users have a choice about whether to use a DSS or not, it must be valuable and convenient to gain their acceptance.

Builder’s View: Technical Capabilities Needed

The DSS Builder needs to use computer tools to provide the support the manager requires. Using a DSS Generator is usually more effective than starting from basic tools. The Generator must have capabilities that allow quick and easy building and changing of a Specific DSS as the manager’s needs change.

Thinking of the DSS as a “black box” and then looking inside reveals three main components (Figure 6):

1. Database: Where the data is stored.
2. Model Base: Where the computer models and analytical tools are stored.
3. Software System: Connects the user to the data and models. This software system includes abilities for managing the database (DBMS), managing the models (MBMS), and managing the interaction between the user and the system (Dialogue Generation and Management Software or DGMS).

These three areas represent the key technical capabilities a DSS must have.

The Data Subsystem

While database technology is well-developed, a DSS needs some specific data capabilities:

• Variety of Data Sources: Data should come from external sources (outside the organization) as well as internal ones, especially for higher-level managers. It also needs to include non-accounting and non-transaction data that might not have been computerized before.
• Flexible Data Extraction: The process of getting data from these various sources needs to be flexible so data can be added or changed quickly based on unexpected user requests.
• Separate DSS Database: Many successful DSS systems have a database just for the DSS, which is logically separate from the main databases used for daily operations.
• User-Friendly Data View: Users should understand the structure of the data in terms they relate to, so they know what data is available and can ask for changes.
• Handling Personal Data: The system should allow users to include their own judgment or unofficial data for testing alternatives.
• Full Range of Management Functions: It needs comprehensive abilities to manage this diverse data.

The Model Subsystem

A key feature of DSS is its ability to integrate data access with decision models. It connects models through the database. This combines the strengths of data retrieval from traditional systems with the power of management science models in a way managers can use.

Often, model builders focused just on the model itself, assuming data and output delivery would happen. Also, it was hard to build one big model for related decisions, so users had to manually connect the results from separate models.

A better approach is to embed models within an information system, using the database to link them and facilitate communication. The model creation process needs to be flexible, using a strong modeling language and reusable “building blocks”. Just like with data, there are functions needed for managing models. Key capabilities in the model area include:

• Quick Model Creation: Ability to build new models easily.
• Catalog and Maintain Models: Keep track of a wide range of models for different management levels.
• Interrelate Models: Link related models together through the database.
• Access Building Blocks: Use reusable parts to build models.
• Model Management Functions: Abilities similar to database management for storing, cataloging, linking, and accessing models.

The User System Interface

The ease of use and flexibility of a DSS largely depend on the capabilities of the interface that connects the user to the system. This interface involves the user, the computer terminal, and the software that manages the interaction. The interaction itself has three parts:

1. Action Language: How the user tells the system what to do (e.g., typing commands, using special keys, touch screen, voice).
2. Presentation Language: How the system shows information to the user (e.g., text on a screen, graphics, color, charts, audio).
3. Knowledge Base: What the user needs to know to use the system effectively (e.g., information in their head, reference guides, help commands).

The quality of the interface depends on the strength of these capabilities. Different ways of interacting, like questions and answers, command languages, or menus, also affect the interface, and the best style depends on the user and task.

Desirable capabilities for the user interface include:

• Handling different ways of interacting, possibly letting the user switch between styles.
• Accepting user input through various means.
• Showing data in many different formats and using different display methods.
• Providing flexible support for what the user needs to know.

Toolsmith’s View: The Technology Underneath

The “toolsmith” is concerned with the core technology – the science behind creating the computer parts of a DSS and how to build them into a working system. They also look at dialogue, data, and model handling, but from the perspective of creating the underlying technology.

Dialogue Management: Researchers have studied what makes a good human-computer interface. This has led to ideas for the software needed to manage the user dialogue, like using data structures to store screen layouts and rules for how users can move between them.

Data Management: Most database work has focused on handling large amounts of data for daily transactions. While this provides capabilities like searching and reporting, it often has a limited view of what the user needs. A DSS user interacts creatively with a smaller set of data that might change frequently. They need better ways to handle data that changes over time (time series data), include judgmental or uncertain data, and quickly get specific data out of existing large systems. The technology needs to be extended to directly support these specific DSS needs.

Model Management: This area holds great potential for DSS. Currently, analytical capabilities often come from statistical or financial calculation tools. Modeling languages allow users to build simulation models to ask “what if” questions. Some Generators have evolved from these, adding features for sensitivity testing or goal seeking.

Model management could also potentially use ideas from artificial intelligence (AI), like using “production rules” (if-then statements) as models for guiding decisions. More complex ideas like “knowledge management” or using semantic networks are also being explored, but may be less practical with current technology. In the near future, model management is more likely to come from improvements in modeling languages and reusable calculation tools.

Issues for the Future

As the DSS area grows, several important questions and challenges arise:

• What Is a DSS? Although there’s substance behind the term, there’s a risk that the term becomes overused and loses meaning. The information technology industry tends to label new ideas quickly. It’s important for users to understand what DSS capabilities are really needed and ask challenging questions to vendors.
• What is Really Needed? Despite years of computer advancements, we still don’t fully understand what managers and other information workers truly need from a system. The DSS approach, focusing on providing “capabilities” (things a manager can do with the system) rather than just “information needs” (data points on a report), helps shed light on this. It’s not practical to wait for a complete theory of decision making before developing DSS. Developing and using DSS in an iterative way can help reveal what is needed and valuable. Evaluating the value of a DSS is difficult, similar to evaluating MIS, but involving users directly offers hope.
• Who Will Build It? Often, the push for DSS comes from the users themselves, not the traditional computer department (EDP/MIS). While technical support is still needed, the DSS builder might work directly for a business department. This trend towards distributing system development outside the central MIS department is supported by many DSS tools that aim to reach the end user directly. While some MIS managers see this as a threat, enlightened ones see it as a healthy trend and provide support. Some companies create dedicated teams of “DSS Builders” to develop these applications.
• How Should It Be Done? The iterative design approach, a core part of DSS success, is very different from the traditional multi-step system development process. It combines all the stages into quick, repeated cycles. This requires redefining project milestones, documentation, and management methods. A way is also needed to decide when to use this new iterative approach versus the traditional one. This is more complex when supporting groups rather than just individuals.
• How Much Can Be Done? Finally, it’s important to remember that technology can’t solve all management problems. Managers will always face complexity and uncertainty; that’s the nature of their job. Information technology can help improve effectiveness significantly, but it’s not a complete solution. Unlike traditional systems that are built to meet specific, frozen requirements, a DSS involves the user constantly pursuing an ill-defined problem, so there’s never a “complete” solution. Computer professionals need modesty about technology’s ability to solve everything.

Conclusion

The framework described here aims to show the different aspects of DSS to help guide its development.

• DSS is one of several important technology areas for improving organizational performance and must work together with other systems like EDP and MIS.
• Thinking about the three technology levels and the roles of people helps organize the development effort.
• The iterative design approach leads to the creation of an adaptive system that evolves over time with its users and technology.
• The performance objectives show the types of decisions DSS should support and the kind of help it should provide.
• The technical capabilities highlight the need for abilities in managing dialogue, data, and models.
• The issues point out challenges that need to be addressed for DSS to continue developing successfully.

DSS is more than just a “buzz word,” but calling it a new “era” might be too strong. It’s perhaps better seen as a “DSS Movement,” where users, vendors, researchers, and builders are all becoming aware of its potential and the many questions that still need answers. With careful effort, these groups can work together to develop systems that significantly help organizations and the people within them.