Designing a Decision Support System

OK, we’ve compiled our knowledge base. Now we have to decide how to evaluate and compare the models. Finally we start designing the DSS. It is not just enough to create one (a spreadsheet, an Access database, a table in a word processor), it is important to discern what we need, what it should be based on, what we want to derive and how. On top of that, we need to be sure that it is user-friendly and flexible. While doing all of that, we have to be sure that it is cost-effective to develop it at all, in both fees and/or time.

In truth there are no rules, evaluations, etc. – the decision maker does what s/he is comfortable with. So for the sake of objectivity, I will be looking at the whole process as a third party seeking to develop the DSS for a decision maker.

One good way to approach the blank canvas is to look at a failed system. If a person comes to a poor decision based on information from a DSS, then part of the blame might belong to the DSS – did it evaluate the information wrong? Was it missing pertinent information? Was its knowledge from a bad source?

The first step then is to find out what is needed. As with any software development this would start with a ‘needs assessment’ interview with the decision maker him/herself. Unfortunately these people tend to ramble on about a dozen different things; the interviewer must keep the conversation on topic to get the answers to the following questions:

1. What is the actual decision to be addressed?
2. What information do we need to base the decision on?
3. What sources do we have for this decision?
4. Are there any electronic sources, and can we convert the electronic information into the DSS format?
5. What weight (value) does the decision maker place on different types of knowledge? For instance, we may find that a move to new headquarters is feasible – there are enough employees in the new area to man it – but the taxes and rent of the new location may be over budget. Which is more important?

Evaluation of the ROI (return of investment) of a DSS is quite a challenge. How does one quantify efficiency? It can be done, and must be done if the developer must write up a proposal for acceptance of the contract to do such development. Things which can be quantified:

• Lack of expertise in the decision maker – will s/he have to hire an expert analyst for the information? This cost would be compared to the cost of the new DSS.
• Manpower costs – having a team of employees spend their time dredging up information would be more expensive.
• Data conversion – is the knowledge needed in hard copy form or an incompatible format, where the decision maker would have to re-enter the information in a different form to view it from the right angle? It might be more feasible to have electronic ‘automatic’ data conversion.
• Possible alternate uses for the DSS would add to its value.

A DSS must be user-friendly. In many ways this is a heuristic evaluation. Names for the language system to be used – GUI, interface, query language… either way, it means you have to be clear about what information you need as input and clear in the output. In MS Access this would mean writing out clear questions on forms and labeling everything clearly in reports and forms. In a spreadsheet this means clear and frequent labels. For this reason, it might be a good idea to develop a ‘prototype’ with all the input and output in place. The decision maker could put in a small number of answers (possibly fictitious) and see what kind of results s/he gets, to be sure the DSS is working right.

One idea might be to add shortcuts, so that if the system is being used a lot (perhaps to see the results of different choices), the user would not have to go through 4 levels of menus each time. While ‘natural language’ queries would be great, they are very code-consuming; better to offer multiple choices. There are many variations of requests, from the almost cryptic C++ to SQL to natural language.

Some ways to help the interaction is to offer ‘tips’ (those little drop-down notes when your cursor is over a term or icon), or explanations in the status bar when the user is at a particular field. And certainly, if the user is impaired in any way, the interface may need to be specially designed.

Some good criteria for determining if the DSS is user-friendly:

• Simplicity – the user should be walked through all steps
• Conciseness -- don’t waste the user’s time with unrelated interactions
• Obviousness – the user should never have to guess what information you seek (or found)
• Consistency – use the same phrases and terms throughout

Some texts suggest prolific documentation before design. This sounds quite backwards to me. Certainly there should be a detailed design plan, but beyond that a lot may change during the development.

Rarely will you find a company that uses PFS or Microsoft Works. And today’s applications are so powerful, the decision as to whether to use Word or Excel or Access can be quite blurry – you can set up formulae for calculations in all three.

A good example of reasons to use more than one tool – while Access can generate graphs, it is a limited selection, and very difficult to manipulate. Better to create graphs in Excel and embed them in the reports or presentations.

Sharing information between tools must be seamless – as it were, transparent to the user. Whenever you task yourself or a user to move knowledge from one tool to another whether directly or via clipboard, there is always the chance that an opportunity to do so will be missed. I would only recommend this approach if the DSS were a one-shot deal (and then I’d make a list for myself of all types of knowledge that have to be shared, and where they have to be copied to).

Back to common knowledge bases – any “suite” does this, from MS Works to the Norton Suite. The design of the suites does allow us to trade and share data between various tools by embedding them.

Once developed, the results have to be returned to the decision maker. At this point we return to all the advice for input – make it clear and concise. If you have a graph, also give the statistics in table or grid form.

So we have to find a way to compare apples and oranges, preferably in a series of formulae. We can at the same time (or separately) weight each one – for instance, the safety rating may be more important than the price.

One method for weighting options is to assign a specified number of ‘points’ to each criterion which is met.

Then, assign an order of preference (in reverse – least important is 0 or 1) or other arbitrary point system which reflects the decision-maker’s value system.

I recommend we find a way to bring all facets to a common denominator in one step, then weight the results. Let’s say the total points of all strongest choices in the decision totaled 70; each selection by the user would rate 1-10 and there are seven questions to choose for. Then each question would have a value of x/70. As each of these choices is calculated, the decision maker’s evaluation of importance for that particular facet would then be multiplied against the question’s rating. The DSS would then select the highest 3 scores and display them.

For instance, let’s say the user’s evaluation of location in the seven selections was a 2, and he chose one of ten locations – Texas is number 5 in choice of location. Five times two would result in 10 points. On the other hand the user evaluated availability of resources as a ten and selected three as the choice for the question (raw materials available, not people); therefore availability of resources would equal thirty. Obviously, the ability of the user to set up an evaluation list beforehand strongly affects the outcome.

The DSS does not make the decision – only offers a limited number of solutions based on the user’s value system. The user then makes the decision.