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.
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:
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:
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.
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:
Similarly, Peter Drucker notes that:
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:
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:
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:
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:
There are a few interesting things to note about this model:
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
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
How do DSS environments support decision-making?
DSS environments support the generic decision-making model above in a number of ways:
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
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.
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:
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.
 Keen, P.G. and M.S. Scott-Morton, Decision Support Systems: An Organizational Perspective, Reading, Massachusetts: Addison-
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.
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.