What is a Decision Support System?
The Decision Support System (DSS) is a very specialized application. The decision involved can be any decision a person or manager should need to make. Support means that this system will do the tedious, time-consuming, number crunching, information gathering parts of knowledge-collecting, allowing the user a full and impartial view of the facts from which to make an informed decision. Your spouse is a Decision Support Person – s/he listens to your ideas to move to Albuquerque, then says, “But, dear…you are allergic to yucca plants!”
At one time if an executive wanted information to aid his decision, he had to go to a computer operator to have the operator phrase the questions to a mainframe by punch card. Now executives keep their own computers and develop their own software. Now query languages are easier to learn, and applications software is a standard element of the desktop. There is a natural progression from EDP to MIS to DSS. An MIS system was used to help make decisions simply because the regular reports and metrics showed trends, successes and failures, as long as the manager using them remembered the results of the past ones and the points of change. But they couldn’t ‘predict’.
What does a person have to do to make a decision?
If the decision is more important or more complicated, one may need to devote more time and effort into making that decision. So let’s take a real-life example – Mrs. A got a good job offer to work in Maryland for a “Beltway Bandit”; her company was closing the local offices. She can either move to Maryland or stay here and get a different job. Her husband has been thinking of opening a business, and has started inquiring about office space and equipment. Mrs. A needs to do more than list the pros and cons; she needs to weight these pros and cons according to how important each item in the list is.
The SDLC (life cycle) of a DSS may follow these steps:
1. Determine the decision that must be made.
2. Determine the facts (knowledge) that need to be collected that might affect the decision.
3. Collect the knowledge into a knowledge base.
4. Determine the processes that need to be calculated from the facts.
5. Run the processes on the knowledge.
6. Determine the best way to present this derived information to the decision maker.
7. Often, as a sort of post-mortem, people look at the collected knowledge and see other decisions that could use support by applying different processes.
One of the challenges I give to students who are learning spreadsheets is to write a spreadsheet that replaces their check register. While it sounds simple enough, the only way to do it is to break down functions we normally do “without thinking” (heuristics). How do we make decisions when we enter something in a check register? We look to see if we wrote a check or made a deposit, in order to know whether to add or subtract the amount from the running balance.
Codewise, we’d have to create a field that says ‘this is a deposit’ or ‘this is a check’, then write an IF statement that checks that field and then decides whether to add or subtract. Very awkward. Wouldn’t it be easier to understand that the spreadsheet recognizes a blank cell as zero? So if it adds everything in the “deposit amount” field and subtracts everything in the “check amount” field at every line, wouldn’t this work?
To support a decision we must also simplify until we understand the tools we are using, the value the decision maker puts on certain results, and the extent to which our system can help.
Today’s CIOs must understand business as well as technology. Pfizer resolves this by having two Project Managers on a system development team – one from the technology group, and one from the business group.
Take a look at your organization – where are decisions being made? Are they to influence planning, organizing, directing, coordinating, forecasting or investigation? Often we don’t recognize “decisions” unless it’s obvious, but actually each of these functions involves the analysis of knowledge and a decision to be made. Whenever a person develops a spreadsheet or a table, s/he is trying to organize knowledge in order to come to a decision – every “what if”; every “let’s look at the big picture”; every time someone compares two things. One only analyzes things when one wants to make a decision about them.
Do we have to classify and define such ethereal concepts as knowledge or decision power centers? Yes, viewing of types of knowledge and decisions, etc., helps us to look at the possible ways in which computers may assist decision making. The extent to which a computer can help a manager plan, organize, command, coordinate or control depends on reaching a more detailed and precise understanding of the functions and their interrelationships.
An anecdote about knowledge: When my father was working at Sperry (now Unisys) he had a little black box that had blinking lights running on batteries. He’d take it into staff meetings, and as he spewed out statistics of the state of the company, he’d pause, peer at the box, then recite the statistics. Everyone thought he had gotten his hands on a remarkably tiny mainframe, chock full of information. This was long before flash drives!
Most people don’t recognize “knowledge” per se. If you have ever had to graph a data flow diagram, as opposed to a process flow chart, you have experienced the dilemma of identifying a single type of knowledge. How can a single piece of knowledge shift an entire organization? Think back on your workplace – changes in personnel can completely realign the priorities (as when a new CEO takes over an ailing company). A shift in industry can greatly affect the knowledge needed and handled, as when networking made personal computers a standard business accoutrement, which caused IBM to do a reversal on their whole production scope. Changes in the clientele of a business can alter the knowledge base. With the economic crunch, many companies that had been diversifying had to reverse the process and start divesting – a decision had to be made as to where the company wants to go and what to let loose.
While we easily say “a computer could do this” when it comes to crunching numbers, or reporting on data, it is much harder to recognize how a computer can come to a decision. It sounds like science fiction.
In reality, computing systems rarely come to decisions. But they can be a tool for coming to a conclusion or decision yourself.
An example is a program a friend of mine just built in XML – it’s a GUI for the intranet which lists all the personnel of the CRi department, whether they are fulltime employees or contractors, who they answer to, and how long they have worked there. The purpose of the GUI – the department has been hiring contractors without restriction whenever a supervisor requested them. So this application is taking specific HR information and creating an ‘organization chart’ of sorts to help them get a view of the sub-departments, balance out the roles and establish a personnel budget.
Let’s look at a decision – what to have for breakfast? Some of you may have the privilege of just sitting down to a table festooned with goodies prepared by another. OK, now for reality – what are the influences on our decision? Whether you have to watch your cholesterol. Whether you have to watch the calories. How much preparation time do you have. Whether others must also be fed. And, of course, what’s in the refrigerator.
A manager must play interpersonal (getting one team member rolling so the other team members can get to work), informational (notifying users that there will be server down time) and decisional roles (where shall we build the new warehouse?). Interpersonal work is rarely a computerized function, whereas informational work is almost always supported by computerization. Actually, a lot of decisions use computer-based tools to help, without even realizing it – writing a white paper on the merits and disadvantages to a decision, developing a spreadsheet with the variables of a problem and changing the values to see the results, or extracting data from factory machines and downloading it into a database. I recently took a bunch of sales records that came in an ASCII (unformatted text) file for a pharmaceutical company, converted the data into tables, and did a variety of business analysis reports on the profitability of the company and the possible areas of change (including the outcome of those changes).
An example of a team decision maker – the President and his cabinet. The cabinet members are supposed to be experts in their fields. A good manager also works this way, trusting his/her finance people, HR people, etc., to input the specific knowledge of their specialties, so that the manager can come to the “informed decision.”
Ever notice that office personnel are named after furniture? Secretary, bureau, chair, cabinet, bar … curious.
There are applications out there which actually evaluate a decision maker’s value system, to determine which shift s/he has. The manager answers a series of questions such as “Which would you prefer to do – buy a daily lottery ticket for $1 which pays out $50, or a weekly $5 lottery ticket which pays off $500?” The answer is given a numerical value, and the manager’s willingness to take risks is calculated. Then the DSS designed for that manager knows which solutions to drop and which to include, depending on the risk factor.
The design of a DSS depends on the decision context and decision type, as well as the nature of the decision maker. This is where you need to concentrate. You must also watch for sources of knowledge, such as databases you can tap into for information, rather than relying on input each time, which is time-intensive.
When designing a DSS, try to incorporate as much flexibility as possible, rather than working toward a single decision. Make it as user-friendly as possible. Be sure it uses reliable materials – remember the GIGO saying – Garbage In, Garbage Out. Determine the What, the How and the Why of any knowledge you want to incorporate.
Ad hoc reports encouraged the development of DSSs. A lot of times a “DSS” is developed on the spot for support of a decision, but it is simply not recognized as such. For example, I datawarehouse for a particular clinic, with monthly, quarterly and annual analyses generated for the agencies which support the clinic. Every once in a while the agencies ask for additional information, to view the effectiveness of this or that – for this purpose I have a database called “ad hoc reports”, which links to the general knowledge base used for the other reports; it is there that I develop specific queries to look at the data from a different angle to generate these ad hoc reports. It’s a great deal faster than the clinic dragging out all the old reports, or all the files for their 500 active patients, to figure out the answers. These reports are used by the funding agency to develop guidelines for its clinics, as well as determining which clinics get which funds.
The cost to develop an ideal DSS often outstrips its utility for a one-shot deal. It would only be feasible if it was flexible enough to handle a series of decisions. For that to occur, it might be better to develop an Expert System and query from there.
I’ve developed DSSs with a collection of variables – The user selects/fills in whatever variables the user wants to use, then selects the type of report s/he wants to generate. To allow this amount of flexibility, the DSS gets pretty darn large – a single module of code may be over 4 MB in size.
There are managers who will ask their direct reports for decision support development, regardless of the ‘cost’ in time involved. But in reality, there is an ROI (return on investment) – time saved in research, accuracy of information, access to information bases, speed of solution proposals, the opportunity to look at things from a different angle, and it can be used to stimulate the decision maker’s thoughts about the problem. Recognize that it is currently not possible (and may never be) for a computer to use imagination; that’s why it is preferable to create a support system than a decision maker – let the manager earn his/her Big Bucks by adding creativity to the results from a DSS.
How does a DSS “communicate”? It is that which separates an interactive model from a static one – questions to fill in and/or answer. Take an online survey on your shopping practices. It not only asks you a series of questions to answer, usually multiple choice, but it then looks over your answers; if you fail to answer, or select more than one when only one is acceptable, the survey stops, and notifies you of the error in your input; once you answer it correctly, it continues. If you answer a particular way on a particular question, more questions or a text box will pop up for expansion of your answer. At the end, it looks at your answers and, following a set of predetermined rules, comes to the conclusion you should get a larger car and presents its findings to you. Input – clarification – evaluation – presentation.
Text-oriented DSSs appear at first to be simply libraries, but that is no longer true. Two examples of these are two companies I’ve worked with.
The first is a company that emerged originally to assist General Dynamics prepare for a lawsuit. Designed by GD employees, the object was to scan the documents involved and create a database which indexed each document (content, keywords, whose signature is there, names, dates, etc.). The attorneys could then find the documents they needed quickly. Without this system, I’ve seen attorneys actually roll an entire hand truck of boxes of documents into trial. Save a tree…shoot a lawyer. This was so successful that the developers broke off on their own and set up such databases for other attorneys.
The second example is Pfizer’s electronic submissions for new drugs to the FDA. While they still need to truck the 2-3 semis of documentation to Washington, it is all scanned and indexed, so an FDA investigator can ask for any single or related set of documents and they are generated from the servers sent with the documentation. This has changed acceptance of a drug from the original 2-1/2 years to a matter of 3-4 months – generating literally tens of millions of dollars of revenue.
While the term Decision Support System is not that well known, they are great fun to develop and it’s amazing how handy they can be.
