Technology and Policy in Decision Support Systems

by Marc Demarest,
CEO of Noumenal, Inc.

Abstract

Data warehousing, data marting, online analytical processing (OLAP) – these terms dominate discussions of enterprise decision support systems (DSS). At the same time, it is becoming increasingly clear that none of these product categories has a particularly stellar track record for improving the quality or quantity of commercial decisions. This is so because none of the technological answers to the commercial decision-making problem focuses on decision-making processes themselves -- on the entirety of the decision-making problem – which are as much matters of policy as they are of technology. This article discusses the evolution of the data warehousing marketplace from data infrastructure to enterprise decision support systems, focusing on the decision-making process as the design center for effective DSS environments.

Introduction: Plumbers or Decision Process Designers?

Examining the terms a community uses to describe its work can tell us a great deal about what that community believes about its mission, focus and objectives.

Consider the “data warehousing market”. In 1995, a survey of key terms used in well over 75,000 articles from approximately 150 IT trade press publications in Computer Select revealed the following statistics for that database. Over a 12 month period, data warehouse averaged 21 articles per month, data warehousing, 20 articles per month, decision support, 66 articles per month, DSS, 12 articles per month, and OLAP, 7 articles per month. A similar analysis, run on the same database in December 1997 for the prior 12 months, revealed different statistics. In that search, the term data warehouse averaged 72 articles per month, a 246% increase, data warehousing, 89 articles per month, a 336% increase, decision support, 64 articles per month, a 3% decrease, DSS, 20 articles per month, a 59% increase and OLAP, 31 articles per month, a 339% increase.

In the second analysis, we see that technology terms -- data warehousing and OLAP -- have increased greatly in terms of their use in our collective discussions, but that decision support and DSS were used at about the same frequency. This trend has continued and new terms like business intelligence are now also common.

From this, we can draw a simple conclusion that is borne out by nearly every firm’s experience in the marketplace: the “data warehousing” marketplace is concerned largely with plumbing – with technology associated with data movement and storage – rather than business value: with the building of decision support systems that materially effect the quality and quantity of commercial decisions. In other words, from a bright beginning in the early 1990s, when “DSS” meant the promise of real returned business value from open systems technology, we have retreated to a largely technical, largely insular state in which the objective of DSS is not decision support, but dumping data on the Windows desktop in hopes that the person using that desktop knows what to do with that data.

It’s easy to understand why the DSS marketplace has retreated to a position where plumbing is the order of the day. Decision-making processes, like any other kind of business process, are difficult to model, difficult to support, somewhat variable and often deeply submerged in an organization’s soft, anecdotal “standard operating procedure.” By contrast, technical infrastructure, data management, data transformation and transport are crisp technical topics that have – or purport to have – right answers, clean lines, and definitive shapes. Clearly, faced with a choice between dealing with the prickly realities of decision-making processes and the cool, clean lines of a technical architecture, one would be mad to choose the more intractable problem area.

Unfortunately, in order to make good on the promise of decision support systems – in order to actually deliver material returned business value to the organization – DSS designers and implementers have no such choice. Every day, as numerous studies have shown, customer and shareholder value are created – or destroyed – at each point in the organization where a decision is made. Not at the point where data is dumped into an n-dimensional pivot table on a Windows desktop.

In fact, if we examine decision theory with an eye to returned business value, we’ll see that the data dumping that is the objective of so many in-house DSS projects is in fact the beginning of the decision-making process, and that the majority of the decision-making process takes place today in an environment that DSS technology simply ignores.

Modeling Decision-Making

Decision support systems (DSS) disciplines deal with the use of information technology to support human decision-making processes. Michael Scott-Morton, who virtually invented the discipline in the early 1970s, offered this definition of DSS:

Decision support systems couple the intellectual resources of individuals with the capabilities of the computer to improve the quality of decisions. It is a computer-based support system for management decision-makers who deal with semi-structured problems.[1]

Even this founding definition – like all definitions – presents us with problems: who is the decision-maker? What kinds of data serve as inputs to the decision-making process? What does the decision-making process itself look like? What kinds of risks and constraints are associated with the decision-making process? How is the output of the decision-making process – a decision – evaluated, implemented and tracked?

Ultimately, no matter where we ground ourselves in a discussion of decision support systems, we have to develop and employ a model of decision-making: the set of activities that DSS environments support. The key elements of this model are fairly common, and include:

  • a decision-maker: an individual or group charged with making a particular decision
  • a set of inputs to the decision-making process: data, numerical or qualitative models for interpreting that data, historical experience with similar data sets or similar decision-making situations, and various kinds of cultural and psychological norms and constraints associated with decision-making
  • the decision-making process itself: a set of steps, more or less well-understood, for transforming the inputs into outputs in the form of decisions,
  • a set of outputs from the decision-making process, including the decisions themselves and (ideally) a set of criteria for evaluating decisions produced by the process against the set of needs, problems or objectives that occasioned the decision-making activity in the first place.

As soon as we look at this model, which is deceptively simple in itself, we realize that talking about decision support systems outside of a particular domain of decision-making is not particularly useful. If we considered only the timeframe in which a given decision has to be made and the risks and constraints associated with the decision-making process, we would recognize that there is a great deal of qualitative and quantitative difference between governmental agencies, not-for-profit (NFP) organizations, and commercial firms. Put simply, commercial decisions, in the aggregate, have the shorter timeframes and higher associated risks (including extinction) than either public sector or not-for-profit decisions, and as such would presumably require the most assistance from information technology.

For this reason alone, this essay limits its scope to commercial decision support systems: IT infrastructure designed to support the decision-making processes in publicly-held and private firms that compete in open markets for customers, revenue and market share.

Commercial Decision-Making

Who makes commercial decisions?

There is a deeply-seated and pervasive notion among DSS practitioners that decision-making in commercial settings is an individual activity: that isolated managers or analysts, often using personal computers, make business decisions. This notion confuses responsibility or accountability with process and activity; although it is quite common for a single, named individual to be responsible or accountable for the effects of a decision, almost all commercial decisions worth talking about are made by groups of people.

John Kenneth Galbraith, in The New Industrial State, describes this group-based decision-making process this way:

The modern business organization, or that part which has to do with guidance and direction, consists of numerous individuals who are engaged, at any given time, in obtaining, digesting or exchanging and testing information. A very large part of the exchange and testing of information is by word of mouth – a discussion in an office, at lunch or over the telephone. But the most common procedure is through the committee and the committee meeting. One can do worse than think of a business organization as a hierarchy of committees….Decision in the modern business enterprise is the product not of individuals but of groups. The groups are numerous, as often informal as formal, and subject to constant change in composition.[2]

Similarly, Peter Drucker notes that:

Most businessmen still believe that decisions are made by top management. Indeed, practically all textbooks lay down the dictum that “basic policy decisions” are “the prerogative of top management.” As most, top management “delegates” certain decisions. But this reflects yesterday’s rather than today’s reality, let alone that of tomorrow. It is perfectly true that top management must have the final say, the final responsibility. But the business enterprise of today is no longer an organization in which there are a handful of “bosses” at the top who make all the decisions while the “workers” carry out orders. It is primarily an organization of professionals...exercising autonomous, responsible judgment. And every one of them -- whether manager or individual expert contributor -- constantly makes truly entrepreneurial decisions, that is, decisions which affect the economic characteristics and risks of the entire enterprise.[3]

Once said, this fundamental characteristic of commercial decision-making is obvious. No one who works in a commercial environment can point to many significant decisions she has made as an individual, and everyone who works for or with commercial firms can supply ample evidence of the communal nature of commercial decision-making. So why do we persist in behaving, as IT and business professionals, as if individuals make commercial decisions? There are at least two technical reasons. The first is historical; contemporary decision support systems derive many of their fundamental models from an earlier technological genre, executive information systems (EIS) that adopted the decision-making model Galbraith and Drucker argue against, and focused on providing data in highly graphical forms to individual senior managers and executives. The second is contemporary; most DSS environments today end, from a technological perspective, at the personal computer, after data is dumped onto “the desktop” of individual knowledge workers. All work that occurs after that data dumping operation is outside the bounds of conventional DSS technologies, and so, from a technical perspective, doesn’t exist.

What is the objective of commercial decision-making?

Ultimately, all commercial decisions are supposed to produce, directly or indirectly, positive changes to the firm’s balance sheet or income statement. That means, generically, that all interesting commercial decisions are in one way or another monetary decisions, and all have, in some combination, three fundamental business objectives:

  • revenue enhancement: the production of more and/or better revenue for the firm, whether through new product or service introduction, product or service line refinement or retirement, or customer care.
  • cost control, containment or reduction: the limitation or control of expenditures related directly or indirectly to the firm’s market activities and infrastructure.
  • risk management, including both the risk to the firm’s capital and market (external, competitive) risk.

In short, one of the conclusions we can draw about all decision-making in commercial settings is that the decisions in question are financially-informed: financial data serves as an input to the decision-making process, a set of constraints on the decision-making process itself, and/or the target output-for-change of the decision-making process. Ultimately, commercial decision-making is about “the numbers”.

Of course, not all particular decisions can directly affect any of these top-level objectives. In fact, one of the most complicated aspects of commercial decision-making is that many things can interfere between the intent of a decision-maker (to control cost, raise revenue, mitigate risk) and impact the decision’s effects, particularly:

  1. Multiple stakeholders: in commercial environments, multiple constituencies have stakes in decisions, and have different agendas, desired outcomes, and criteria for evaluation and judgement
  2. Far-reaching consequences: unlike decisions studied in game theory and decision science, commercial decisions have far-reaching, non-local effects, some (or many) of which cannot be known in advance. Who would have forecast, for example, that Apple’s decision not to license its operating system technology would have led Oracle to make a bid for Apple (because Microsoft established OS dominance in the vacuum Apple left, Ellison rose to power, and Ellison dislikes Gates and Microsoft)?
  3. Dynamic decision-making environments: inputs to the decision-making process, and the structure of the decision itself, can change several (or many) times during the decision-making process.
  4. Uncertainties: some of the critical input factors are either unknown, incompletely known or unreliable, requiring “finesse” or “insight” or “intuition”
  5. Multiple objectives: the constraints on any given commercial decision-making environment are (a) very tight , (b) often conflicting and (c) normative (we ‘know’ what the answer is supposed to be before we engage in the decision-making process).

In other words, decision-making in commercial environments is a nested phenomenon. A firm’s top-level decision to enter or exit a market, for example, is typically broken down into a host of more granular decisions that can be characterized more easily, and the effectiveness of the resulting market entrance or exit strategy is almost completely dependent upon:

  • the quality and effectiveness of each decision made as a part of the larger decisional frame
  • the implementation of those decisions completely, properly and in the correct sequencing
  • the stability of the overall external market environment during the process of making and implementing the set of relevant decisions
  • the way in which other factors influence, and interfere with, decisions and decision-makers.

What does the commercial decision-making process look like?

Once we accept that commercial decisions are made by groups of people within commercial firms, and not be individuals, we immediately feel the need for a model of the typical commercial decision-making process. Who does what when? Using what tools, methods and practices?

Decision theorists have, over the last decade, developed a fairly useful generic model of decision-making that makes sense, as a normative model, for commercial decision-making, Any decision, these theorists argue, can be understood as a six-phase process:

  1. decision preparation, which is initiated in response to the desire for a change in the state of the business, and during which the individual or collective decision-maker gathers the inputs required to structure, evaluate and make a decision
  2. decision structuring, during which the decision is framed, modeled and examined for implications, dependencies and links to other decisions
  3. context development and exploration, during which scenarios – each of which might serve as the answer to a particular question – are developed and filled out
  4. decision making, during which one or a few scenarios are selected as optimal solutions to the problem at hand. This phase typically involves multiple cycles, during which scenarios are shared among a group or groups, modified, tested and enhanced or even discarded.
  5. decision propagation, during which selected scenarios are published or distributed to all areas of the organization that have roles to play in implementing the decision at hand.
  6. decision management, during which the implementation of a particular decision is tracked and its effects on the business state relative to its objectives are measured and evaluated.

There are a few interesting things to note about this model:

  • First of all, some theorists argue that this model is not normative. In other words, they suggest that all decisions are actually made according to this model, even when a decision happens “in a split second” in the mind of a decision-maker who is unaware that he or she is using a model of this sort.
  • The first four phases of the model, up to decision-making itself, are susceptible to support by technology. The last two are less so, but they are the phases where a decision either “pays off” or doesn’t. This is a conundrum. If, as a marketeer, I make a wise decision (to enter the DSS market for example) based on good inputs, but I cannot orchestrate the rest of the company to execute on that decision, the benefits I sought in making the decision (revenue, market position, etc.) don’t accrue. It is for this reason that people in the DSS business speak about decision-making policy: the models companies use to make decisions, and the mechanisms they have in place to implement decisions and track their implementations. Companies with good DSS technology (the first half of the model above) and bad decision policy (no follow-through) get, not surprisingly, little benefit from their DSS environment over the long haul.

What classes of commercial decisions get made?

In addition, decision theorists can identify five distinct classes or types of decision-making problems, which may appear in any combination inside a given commercial decision-making process:

  • description: problems associated with the accurate characterization of the current state of the business. Classic examples include the characterization of product sales by geography, channel or market segment – how much of product X are we selling in geography Y?
  • investigation: problems associated with relationships between two or more data elements or phenomena. Classic examples include field-replaceable unit failure analysis – what is the relationship between ambient air temperature and unit failure? -- and consumer spending analysis – what is the relationship between five-day weather forecast projections and unit sales?
  • explanation: problems associated with the establishment of a cause and effect relationship, as in: Why is Product A doing so well in Asia and so badly in Europe?
  • prediction: forward-looking projection based on historical data, as in “If we raise sales quota by 25%, what will happen to revenue in Q2?”
  • prescription: normative projection based on historical data, as in “What ought we to do about sales quota for next year, given our need to lower cost per order dollar and increase our market share?”

Decision Support Systems Technology and Decision-Making Policy

We have described a very complex, indirect, multi-party commercial decision-making process, one so complicated that it is difficult to model or to understand in its concrete incarnations. This might appear to make the process of using IT to support decision-making processes – Michael Scott Morton’s founding definition of DSS – very difficult. But that’s not necessarily so.

What is required is to

  • pick the class of decision-making processes to focus on,
  • narrow the range of inputs, the range of activities and the differences in models and methods,
  • and most importantly to understand where technology ceases to play any meaningful role in decision-making, and where policy becomes the determinant of the quality and quantity of decisional effectiveness.

How do DSS environments support decision-making?

DSS environments support the generic decision-making model above in a number of ways:

  • In decision preparation, DSS environments provide data required as input to the decision-making process. This is interestingly enough, about all most data mart and data warehousing environments do today.
  • In decision structuring, DSS environments provide tools and models for arranging the inputs in ways that make sense to frame the decision. These tools and models are not pivot tables and other aspects of data presentation found in query tools. They are actual decisionmaking tools, like fault tree analysis, Bayesian logic and model-based decision-making based on things like neural networks.
  • In context development, DSS environments again provide tools, and provide the mechanisms for capturing information about a decision’s constituencies (who’s affected by this decision), outcomes and their probabilities, and other elements of the larger decisionmaking context.
  • In decision-making, DSS environments may automate all or part of the decision-making process and offer evaluations on the optimal decision. Expert systems and artificial intelligence environments purport to do this, but they work only in very limited cases, because of some fundamental flaws in the technology (namely, their inability to deal with non-binary, or fuzzy, choices, like “it’s more likely that we’ll lose market share than win it,” which is a rule that no traditional AI-based system can code).
  • In decision propagation, DSS environments take the information gathered about constituencies and dependencies and outcomes and drive elements of the decision into those constituencies for action.
  • In decision management, DSS environments inspect outcomes days, weeks and months after decisions to see if (a) the decision was implemented/propagated and (b) if the effects of the decision are as expected.

So, what commercial products do this today? Outside of very limited cases, focused on specific problems in very high-risk areas (like bomb disposal, scheduling airplanes into airports, arranging railroad cars on trains), none do. Most commercial DSS products don’t do anything except decision preparation: they dump data on the desktops of decision-makers, saying in effect, “You must know what to do with this.”

The challenge for DSS vendors

The challenge for the DSS market is simple: vendors must step up to the decision-making problem, having now pretty much solved the “data access” problem conceptually, by targeting their technology on specific classes of decision-making problem rather than on issues of plumbing, infrastructure or functionality.

As a trivial but illuminating example, consider the ubiquity of the “pivot table” as a feature of OLAP applications. This feature is in any particular decision-making environment potentially gratuitous; it:

  • may or may not be of use to a marketeer performing an historical analysis on the performance of multiple products in multiple markets over time as a prelude to making a decision about which product lines to retire
  • is probably of minimal use to a cost center manager attempting to diagnose the root causes of a significant over-budget condition
  • is of no value to a financial analyst attempting to perform a forward-looking, risk-assessed cash flow analysis on a new line of over-the-counter drugs slated for introduction in three years.

If the OLAP tool in question were focused on a particular decision-making constituency, the inclusion of pivot table functionality might make perfect sense. As a feature of a horizontal tool, sold as plumbing components, the feature is gratuitous: designed to produce good demonstrations, not good decisions.

The challenge for DSS implementers

The challenge for IS and business professionals implementing DSS environments is equally simple: to keep the project focused on explicit support for a class of decisions the implementation team (a) understands and (b) knows how to support in order to achieve improvements in the quality and quantity of decisions made within that class.

This suggests that all DSS projects have to delve deeply into the models, methods and practices used by the constituencies for which the DSS environments are being built, that those decision-making processes have to be explicitly documented, and that the choice of technologies for the DSS environment must be based primarily on the ability of those technologies, in an ensemble, to explicitly support the decision-making processes in question.

The challenge for organizations

The challenge for any organization considering DSS environments is the most complex. Organizations that deploy DSS technologies, but do not enforce decision-making policy, cannot expect to derive significant returned business value from their DSS environments, since the ultimate value of a decision is in its implementation and management: areas that DSS environments cannot, by definition, support.

It is true that certain classes of decision – for the most part those associated with cost control or reduction – are easily implemented and managed, and that DSS environments focused on financial data and on cost control and reduction – or for that matter on financial analysis generally – have a higher likelihood of delivering returned business value, because financial decisions are more easily implemented and managed. Everyone can see “the numbers” and what they mean for the organization, particularly where cost is concerned.

As we move away from the certitude of numbers toward the uncertainties of mergers and acquisitions, new product development intiatives and new market entries – all areas that DSS environments can support if designed properly – we move increasingly into areas where historically organizations have failed in their decision-making policy enforcement. Decisions were taken, but the consequences of decisions taken were not taken seriously, organizational and product or market portfolio changes were not made, and no one – including the initial decision-maker – took the responsibility to measure and manage the effectiveness of the decision in question seriously.

It isn’t just that decision-making policy is as important as decision support systems. It is the case that decision-making policy enforcement – a soft management discipline – guarantees the returned business value that decision support systems promise.

Conclusions

In our estimation, the data warehousing market is largely unconcerned with decision-making processes. This lack of concern, by itself, no doubt accounts for a large number of the “failed” data warehousing and data marting projects with which the IT and business trade press are recently becoming acquainted. The data warehousing market’s focus on plumbing – on dumping data on the Windows desktop – is ultimately a reflection of its own concerns, not those of its customers.

But even if the data warehousing market were to become focused on decision-making processes instead of on plumbing (which it must eventually as its customers become more sophisticated in their demands and use of technology), returned business value from DSS environments is not a sure bet for commercial firms. Assuming every organization had access to thoughtfully-designed well-implemented DSS components and packages that took as their explicit design center a named class of business decisions, organizations would still have two significant hurdles to overcome to produce world-class DSS environments that materially improve the firm’s decision-making capability:

  • The IS and business team responsible for deploying the DSS environment must become experts in the business decision-making processes they are targeted for IT support.
  • The organization as a whole must enforce a set of decision-making policies that ensure that decisions are made according to standardized models, methods and practices, and then implemented with measurement and management regimes in place so that the decision, once taken, is implemented and its effects on the organization monitored and assessed.

Overcoming these three hurdles – an unfocused data warehousing marketplace, disconnected project teams, and implicit rather than explicit decision-making policies – leads, inexorably, to material returned business value, to ROI measured not in mathematical terms, but in terms of increased revenue, decreased cost and more effectively-managed risk for the organization.


References

[1] Keen, P.G. and M.S. Scott-Morton, Decision Support Systems: An Organizational Perspective, Reading, Massachusetts: Addison- Wesley, 1978.
[2] Galbraith, J.K., The New Industrial State,New York: Signet, 1971, pp. 77-78.
[3] Drucker, P.F., “Long-Range Planning” in Technology, Management & Society, New York: Harper & Row, 1967.


About the Author

Marc Demarest is the CEO of Noumenal, Inc., a private consultancy focused on business turn-around and go-to-market services for intellectual property-based companies in technical and commercial markets. Prior to Noumenal, Marc was Chairman and CEO of DecisionPoint Applications, Inc., the industry's leading provider of packaged data warehousing software for financial, human resources, manufacturing and distribution analysis. Marc has also held executive positions with The Sales Consultancy, Inc., a high-technology sales and marketing consulting firm based in Dallas, Texas and the United Kingdom, and Sequent Computer Systems, Inc. in Portland, Oregon, where he led the development of worldwide sales and marketing process development and created an APQC award-winning knowledge management technology environment. Widely known as the father of data marting, Marc publishes and speaks regularly on topics ranging from knowledge management and decision support systems to IT technology futures and information ethics. He holds BA degrees in Political Science and English Literature from Bucknell University in Lewisburg, PA., an MA from the University of South Carolina, and is a graduate of the Stanford Institute's high-technology business management program.


Citation

Demarest, M., "Technology and Policy in Decision Support Systems", DSSResources.COM, 07/08/2005.


Marc Demarest provided permission to archive articles from the Noumenal website at DSSResources.COM on Friday, December 5, 2003 and he provided permission to archive and feature this specific article on Monday, June 27, 2005. This article is version 9 and it is revised from version 8 (10/12/98) at Noumenal URL http://www.noumenal.com/marc/techpoly.pdf. This article was posted at DSSResources.COM on July 08, 2005.