IT Archaeology: Whatever Happened to SDS?
I've been digging through some ancient texts (in IT terms) over the past week or so, looking at the issue of IT governance and how it relates to the development of decision support systems. In doing so, I read again an article from 1971 in Sloan Management Review that first coined the term 'decision support system' written by two academics from MIT: Anthony Gorry and Michael Scott Morton.
In defining DSS, they also designed a second class of information system that I'd completely forgotten about, known as a 'structured decision system' (SDS). The term 'structured' comes from an adaptation of a model of decision-types by Nobel laureate Herbert Simon. In Gorry & Scott Morton's terms, decisions are either structured (well-understood, fairly easy to resolve, lend themselves to well-defined workflows or decision-rules), unstructured (difficult, high levels of ambiguity, no clear process for making the decision) or somewhere in-between (semi-structured).
Gorry & Scott Morton argued that such systems are designed to support semi- and un-structured decision problems. For structured decisions like inventory control, short-term forecasting and so on, they coined the term SDS.
This got me thinking. I had always seen today's BI systems as the inheritor of the DSS concept - basically the latest term in a long string of marketing names for systems designed to support managerial decision making. Now, I'm not so sure. In looking at Gorry & Scott Morton's definitions, most BI tools seem to be targetted more at structured, rather than unstructured decisions. Couple this with efforts by people like Howard Dresner to shift the BI concept more and more to enterprise reporting, and I reckon that BI is more about SDS than DSS.
Which is a problem.
There is a class of decisions that really need the support of systems that can help the decision-maker through the decision-making process by embedding principles of good decision-making in the system, and helping them make sense of the information they have. These decisions tend to be strategic and important, and the potential ROI for a system that can improve decision-making in this area goes way beyond being able to run an operational report that used to take hours in 30 seconds. In other words, there is a real need for the decision support systems that Gorry & Scott Morton described 36 years ago, and I don't think that BI tools are currently being used to build them.
This is not to say that they're not being built, of course. Instead, I think they tend to fly under the radar more, as individual strategic decision-makers throw together systems to answer specific questions in a way that they're comfortable with: witness the continued pervasion of Excel in the upper echelons of organisations despite the flash-wizardry of the latest 3D-pie-charting engine; skunk-works projects for individual managers; the explosion of independent data marts.
As I said above, the impact of the effective use of a DSS far outstrips that of a SDS because the decisions made fundamentally and directly affect the strategic direction of a firm. It's critical that good quality DSS are developed, and I don't think we're going about it in the right way at the moment. Excel can be dangerous if not used properly, but because everyone is focused on the highly-visible SDS-like BI projects, the DSS-needs of an organisation are often addressed in an ad hoc way.
It's a pity that we don't pay attention more to what was written in the past about IT. Not only do you realise that we keep making the same mistakes despite the changing technology, you come across interesting ideas that can change the way you perceive today's industry.
5 comments:
I see gigabyte-sized spreadsheets used to support critical decision making processes with only individuals understanding (defining) the business rules within them, and how to use them; and the expanded functionality of Excel 2007 is only going to compound this.
It's a critical business risk, and it's recognised by business as a critical business risk. But it's also a critical business asset.
One of the catalysts of the "rise of the spreadsheet" has been the limited ability of IT shops to deliver solutions that provide equivalent flexibility and functionality in a timely manner. In many cases, users either cannot articulate their requirements effectively to IT, or IT isn't able to correctly interpret them - the meaning and intent get "lost in translation".
Users invariably build and continue develop these tools "under the radar" - often duplicating existing functionality, replicating and sustaining data sets that are potentially no longer current, or perhaps just plain wrong.
The broader issue (in my opinion) is the continuing view by many business executives that the IT function has an operational focus - it simply keeps things ticking along. This is supported by the focus of most IT-related SLAs. How often do you see words "strategy" and "innovation" in these documents? IT is simply viewed as a necessary cost of doing business. IT is MUCH more than that.
As IT professionals we have not done a particularly good job of promoting ourselves (either in principle or by our actions), and the challenge for the current and future professional is to change that perception. It's as much of a cultural issue as an issue of credibility and reputation.
IT needs to promote itself as a strategic asset - a key contributor to the process of creating margin opportunities (e.g. process efficiencies, more timely and effective decision support capabilities) and generating business value.
Back on point ...
I recall writing somewhere in a submission on data warehouse governance about the gap between unstructured and semi-structured problems and the tools used to solve them (or perhaps I am simply extending on the definitions in the paper - I don't honestly recall).
Isn't this the quintessential argument between Kimball's and Inmon's methodologies? That you either use a bounded system that allows you to learn more about a known problem or opportunity, or you use a boundless[1] system that can tell you pretty much anything within the scope of the dataset it has access to.
[1] Boundless in the context that you are not explicitly predefining the dimensionality or relationships of the data.
Hey Bruce, great comment yet again.
This dilemma between the flexibility provided by Excel (1GB, really!? My God...) versus the potential risk of poorly developed systems leading to bad decisions is a tricky one. The common approach is to lock it all down, put in place a 'proper' reporting tool and lock it down so IT control it, but this is just wrong. It satisfies the central IT need to control and manage, but stifles the learning process that should be the whole point of DSS usage. If there's no learning, there's no support - you just end up with a well-managed, fault free white elephant.
My current thinking is that you need a team of skilled decision support personnel, trained in decision making, business analysis and IT savvy who have an organisational mandate to ensure a good quality system (ie. error-free, reliable, etc.) that provides good advice to decision-makers. Don't forget that the development process itself can be just as effective at helping someone make a decision, as the resulting system itself.
The challenge is that this kind of DSS governance necessarily operates outside of (but would need to interact with) the rest of the organisational IT governance structures. This could be a major worry for some people, especially when you throw political turf-wars into the mix (IT would see it as encroaching on their territory). All tricky stuff, but capitulating to these hurdles (a mixed metaphor?) means that, at best, you end up with Gorry & Scott Morton's SDS-type systems, rather than a true DSS that can provide strategic decision support.
The reason I was reading the 1971 article was for a paper I'm writing about governance of DSS (as opposed to IT in general), and the argument is shaping up along the lines you mentioned in your submission on DW governance: the difference in the requirements for systems to support structured versus semi-structured decision problems. If it's real, and exists, it would be great to have a chat about it.
Cheers,
Rob.
I guess one of the key issues in the DSS/BI/SDS/{insert tomorrow's acronym here} space is that the design and development process does not fit neatly into the conventional IS SDLC. The approach is (and really has to be) far more fluid - "evolutionary". If it wasn't, it would perhaps be better classified as a transactional processing system - with inputs, processes, and outputs of a known (and relatively fixed) dimension.
So from that perspective, I tend to agree that you need something in business more akin to a SWAT Team - a mix of capabilities from a broad cross-section of the business, able to develop solutions capable of keeping pace with the ever-evolving strategic analysis and decision support requirements of the business. This has to be balanced with IT governance requirements, with sufficient freedom (through senior management support) to enable the group to innovate and evolve (somewhat) independently of conventional (IT) project management methodologies (and who's to say these work all that well anyway?).
As a case in point, we're currently researching multi-agent systems based on game theory as an alternative to using Excel models which have been developed by a small user group for logistics planning. Can Excel accommodate such complex modelling tasks? In this case, yes. Is it the best platform? A matter of perspective - but in my opinion no. Is it an SDS or a DSS? Is it a strategic system? A tactical system? An operational system? Likely all of the above, because it is used in so many different ways.
An SDS or DSS "SWAT Team" capable of building and sustaining bridges both vertically and horizontally across the business, bilingual in business and technical tongues, will undoubtedly add (either directly or indirectly) significant business value to any organisation sufficiently committed to challenge.
I wonder if BI isn't already splitting out, functionally at least, into those three different decision-types, albeit under new names.
* SDS. Perhaps as the Enterprise Decision Management touted by certain credit bureaus. Often billed as automated BPM, it focuses on optimising decision yield for high-volume nearly-identical decision problems (eg credit scoring, direct marketing).
* Semi-SDS. Enterprise reporting, of the interactive, collaborative, slice-and-dice variety. Focusing on milking new managerial insights out of existing sources.
* DSS. Unstructured decision-making using multiple (new?) sources and (possibly) statistical and data mining methods. Often ad hoc and one-off. Focuses on supplementing human judgement.
Strategically, it makes sense for these three different systems to share the same data, infrastructure and operational groups. You know: common data model, "one version of the truth", single sign-on, one point of call for support etc.
It would be interesting to see how the three very different requirements for information and system quality could be melded into something that is economically efficient and politically palatable.
Hi Greg,
I think you're right about the split. It might even match up with what the article uses to describe the different levels of management decision making - operational control, management control and strategic planning.
I'm not so sure about the use of data mining for DSS. It may play a role, but other than in niche areas like CRM, I haven't seen it work particularly well at the strategic DSS level. I think the problem with it is that it tends to be a 'black box.' What you're aiming for at the DSS level is a learning process: it's almost more important to understand why you have a particular answer as it is to have the answer itself.
You're right about having a data warehouse too, in that having a good source of data around makes building DSS a lot easier. However, it's by no-means mandatory, and in some cases it's not worth the effort. The problem is anticipating information requirements - with a DSS you don't know what you need before you build; it's a process of discovering requirements as the system is used. In other words, if the data is there in the warehouse, great, but having one doesn't guarantee that you'll have the data you need.
Post a Comment