May 11, 1999, Volume 2 - Number 7
Support for DSS Decisions
Intelligent Enterprise launches a special series of DSS Lab reports to help implementers and vendors make informed decisions
You who are painfully familiar with thecomplexities of selecting and building decision-support systems (DSSs) will welcome this new periodic variation from my normal column. Decision Support: From the Lab will provide in-depth, objective information aimed at addressing some of your specific, practical concerns.
As more people implement decision-support solutions and try to squeeze ever more value out of their data, questions naturally arise concerning the use of appropriate methods, tools, and technologies for the task. There is no simple set of answers, because different types of business problems yield different types of technical challenges. For example, customer churn analysis frequently involves overcoming the technical challenge of working with large dimensions. And product profitability analysis often requires the difficult process of allocating costs across multiple dimensions and creating analyses across time for changing dimensions.
What makes this addition to my usual column possible is the DSS Lab. My colleagues and I at Dimensional Systems in Cambridge, Mass., have been pulling together resources over the past several months to create a state-of-the art lab to test decision-support scenarios, methods, and products. Through its activities and reports in this column in Intelligent Enterprise, the DSS Lab will address four critical decision-support needs: articulation of user requirements, technology evaluation, leading-edge application feasibility, and DSS fusion. You will be hearing from not only myself but also other Lab members, each of whom has excellent DSS credentials as well as expertise in special areas.
We are focused on sparking industry dialog, showing how the tools do (or do not) serve business functions, and providing valuable empirical information. In each of our columns, we will discuss our specific testing methods, which will vary depending on the subject. I’d like to say at the outset that we welcome reader’s questions, suggestions, reactions, and ideas for techniques and technologies that you would like to see us test.
Addressing DSS Needs
Before you create a DSS you have to detail user requirements. Discovering those requirements demands asking all the right questions, and sometimes just knowing what questions to ask is half the battle. The DSS Lab will help you find the right questions. Say, for example, you want to implement a system to track product profitability. What should you do? First, you’ll need to ask some questions, such as: How many users will the system have? What kinds of calculations will be performed? How much data is there? Is your hardware architecture fixed?
It’s also important to know the technical criteria for evaluating the software you may use for a DSS solution. Each DSS Lab evaluation will specify the exact questions posed about technological criteria. Typical questions include: How long does it take to load 1, 10, or 100 million rows of data? Is the data indexed on load? How will the system’s performance change as you load more data and increase the number of users during the next 18 months?
In addition to working on articulating solutions requirements and technology evaluation criteria, the DSS Lab will test the degree to which leading-edge DSS problems are solvable with today’s technology. Let’s say I want to track the market by scanning journals to discover current discussion topics by author, publication, and vendor — and I want to integrate this marketing information into my promotion-development process, taking advantage of hot and not-so-hot topics. I want to integrate the output of a text-clustering effort with my online analytical processing (OLAP)-based decision-support work. I can describe what I want to do, but is such a plan possible? If so, how can I do it?
The DSS lab will also publish reports on DSS fusion; how to integrate popular DSS technologies effectively for common but challenging business problems. For example, what if you want to perform serious correlation analysis on your OLAP data? Of course, you can export a file from the OLAP system or establish a connection from the mining or visualization tool through ODBC or OLE DB, or possibly even through OLE DB for OLAP, but that’s just a one-time static connection. What you really want to do is see your OLAP space through a visualization tool, where each mouse click may bring new data. Or, you may need to perform some kind of data transformation prior to visualization. Alternatively, you may want to partially aggregate the data through data mining, look for patterns, conceivably build a predictive model, then generate predictions to feed back into the OLAP system for further aggregations and analysis. The question is, how does the metadata pass from the OLAP environment to the data mining environment and back? DSS Lab fusion reports will address these types of issues.
Additional Lab Focus
Too much information about good practice and technology suitability is anecdotal. Information gathered with objective criteria from vendors as well as end users is needed for these two factions to make informed decisions. We’ll ask what people are really doing for decision support. We’ll also find out what kinds of questions they are now answering that they didn’t answer before, what’s still challenging, how fast text analysis is being incorporated, and how well it is being exploited for corporate intranets or knowledge management. In addition, we’ll discover how corporations are learning, as well as whether there is a mismatch between the skills required for business analysis and the skills possessed by the workers.
The DSS Lab will make the results of its surveys available to vendors and end users in the hope of creating some kind of dialog. The Lab will explore what kinds of applications are successful and which are not, which ones bring the highest ROI, and which ones fail to pay for themselves. Within popular applications such as customer relationship management (CRM), budgeting, and planning, we will discover what areas are problematic. Users will benefit from help in discovering what they really need from vendors; vendors will benefit by learning what users truly need and what they don’t. Markets can then become more rational: Vendors can allocate resources more efficiently if they know how to focus their efforts.
As I’ve said before, there’s a continual tug-of-war between vendors and end users. End users want to solve problems; vendors want to sell products. The best way to sell a product is to position it as a solution. Thus, software tools are positioned as an “end” rather than a means to an end. Furthermore, vendors attempt to convince the public their software somehow defines a category. Then category battles erupt in the media, which further obfuscates the information critical to users.
The DSS Lab will analyze software by thinking in terms of a single, underlying, functional vocabulary. This unifying vocabulary will let us conceptually decompose higher-level business functions into lower-level functions and match those with component functions of software products, which we’ll similarly break down. For example, typical high-level business goals or functions include increasing revenues, earnings, customer retention, market share, and product quality. Drilling down on one of them, say customer retention, yields functions such as assembling a list of customers along with their attributes and historical interactions, as well as modeling the relationship between customer attributes and their interaction history with customer retention.
Drilling down on one of these functions, such as the last modeling function, yields such lower-level functions as creating partially aggregated customer data, scaling the fields in the customer attribute table, and joining the customer interaction and attribute tables. These last functions — the lower-level functions — represent what you would do as an analyst working on a customer retention problem. Although nothing is absolute about this particular level, you need to think about the appropriate software to use for your situation at whatever level you need control. Marketing terms such as OLAP, relational OLAP (ROLAP), and data mining are far too vague to be truly useful in helping you figure out which software to use.
The Lab will publish four basic types of reports: performance, usability, feasibility, and fusion. Reports we’re planning include a performance report on working with large dimensions in the context of customer analysis, a usability report on data mining, and a fusion report on the integration of OLAP, data mining, and visualization for financial analysis.
As we move into the second wave of computing, the DSS wave, users’ solution needs and vendors’ technology innovations are unfolding at ever accelerating rates. The DSS Lab will set its sights on the frontiers of both business and technology and — through analysis and synthesis of objective information — illuminate the path that joins them.
Erik Thomsen is an author, lecturer, researcher, and consultant focusing on OLAP and decision-support applications. He is cofounder of the Cambridge, Mass.-based consultancy Dimensional Systems and author of the book OLAP Solutions (John Wiley & Sons, 1997). You can reach him via email at erik@dimsys.com.
