When is "real-time" decision support desirable and needed?
My Ask Dan! column “What is ‘real-time’ decision support in DSS News (Vol. 3, No. 24) struck a chord with some readers. This column is a follow-on, expansion and discussion stimulus on the topic of "real-time" decision support. The following "answer" draws extensively on email comments from Nigel Pendse and Marc Demarest. Nigel Pendse is principal of OLAP Solutions and co-author of the OLAPreport.com. Marc Demarest is President of Noumenal, Inc. He served as CEO of DecisionPoint Applications and prior to that he held a number of positions with Sequent Computer Systems.
On
So in the next few paragraphs I'll quote from Nigel and Marc's email comments.
Nigel Pendse wrote "In the BI context, a common meaning of real-time is that you can change data or assumptions in a planning model and see the results more or less instantly. This is easy enough with small Excel spreadsheets, but much harder with larger, more complex multidimensional models, and harder still if multiple people are doing it at the same time, each doing 'what if?' analysis of their own parts of an overall plan. In fact, only a few tools can even do this. This is much more useful than real-time analysis of operational data, where management level decision-making depends on medium or long term trends, not what someone bought five seconds ago. Yes, real-time analysis is important for some operational decisions, but not for many that would fall into the BI category."
Nigel continues "The form of real-time data warehousing that is being currently pushed is, in my view, a somewhat cynical consequence of the fact that some ETL tools can do it, so the vendors are inevitably suggesting that there's a major business need for it. I think this is vendor-push, not market-pull. Most business decisions based on data warehouses are not damaged by being based on last night's (or even last week's) data. But real real-time planning is genuinely useful -- and one reason why Excel remains the number one planning tool. It isn't as thorough as a proper, large-scale tool, but the fact that it's fast (i.e., real-time) means that many people compromise their requirements in the interests of true interactivity."
Marc Demerest emailed me extensive comments. He made four major points:
1. Real-time means "as soon as things change"
To begin with Marc suggests we need a better definition. He notes "In every situation I have been in, in which real-time DSS is discussed, the adjective 'real-time' means that informational inputs to decision-making processes are available as soon as there are state changes in the environment that alter those informational inputs. Examples: as an inventory manager or purchasing manager, I can see SKU-level stock changes as items are picked; as a cost center manager, I can see the state of my cost center as soon as any credits or debits are applied against that cost center; as a sales person with territory responsibilities, I can see all customer support incidents logged for any customer in my territory as soon as the trouble ticket is opened."
2. There is always some latency in "real-time" DSS
According to Marc, "Real-time refers to data, not to user response rate experience and shame on the vendor for attempting to corrupt the definition that badly. Real-time also means 'near-real-time' in practice because there is always some latency between (a) the actual state change, (b) the reflection of that state change in data in one or more systems of record and (c) the availability of the changed data to decision-makers. In my cost center example below, when D.J. Power clears Invoice #12 from Marc Demarest, Inc., the $10,000 Power pays hits Marc Demarest Inc.'s bank account (typically) a couple of days before Cost Center 983 in Marc Demarest Inc.'s financial ERP system gets the update indicating that Invoice #12 has been paid and the Cost Center has a $10,000 credit. Some number of microseconds-to-days thereafter, the financial data mart used by the manager of Cost Center 983 is updated. Total lag time from receipt of payment to information-available-for-decision is 2+ days. In other environments -- SCM, inventory, and logistics, for example -- the total elapsed wall-clock time between business state change (truck leaves depot with package) and information-available-for-decision may be as little as a few milliseconds to a few seconds."
3. Is "real-time" decision support push-based or pull-based?
Further, Marc explains "Now, assume a system capable of making decisional data available to decision-makers as and when those data elements change. The first and obvious question is: HOW is that data made available? Do I have to ask for it? Or does it 'come to me'? If I have to ask for it, of what resource do I ask it? If it just comes to me, HOW does it just come to me? This brings us, right away, to the first interesting distinction in real-time, and near real-time, DSS: pull-based systems that make me, the decision-maker, go get the data I need, and push-based systems that 'know' I am a decision-maker for certain classes of decision, and push the changed-state data to me as and when that data changes. Pull-based systems are not, in my view, real-time DSS environments: they are in all likelihood classic DSS (with data warehouses in them as repositories) that employ real-time or near-real-time extraction, transformation and loading (ETL) infrastructure: technically interesting but of no real business value. Push-based systems, on the other hand, are potentially dynamite, but I have yet to see any commercially-available product that actually does role-based changed-state data pushing to decision-makers. Yes, there are systems that send reports around in e-mail, but that is not what I mean, nor I think what others mean, when they say 'real-time DSS'."
4. Is “twinkling data” and "real-time" decision support a good thing?
Finally, Marc noted "Real-time DSS has always troubled me. Maybe it's my upbringing under the care of Kimball and Inmon and others, all of whom made and make the very valid point that every type of decision -- in the commercial world at least -- has a stability profile to it. In other words, people making decisions see time differently in different contexts. As a controller, for example, I think in terms of reporting periods of months, quarters and years, because I must. As a product manager, I think in terms of milestones that span years, in all probability. As a warehouse manager on the downstream side of product fulfillment for a B2C e-business, I think in terms of minutes (particularly during this season). If we build a system that constantly updates all decisional data regardless of who uses it for what kinds of decisions, we run the risk of destabilizing whole classes of decision-making. For example, if a cost center manager runs a query at 10 AM on Tuesday that says her cost center is within variance boundaries, and her controller runs the same query three hours later (after a $150,000 debit has been mistakenly posted by a clerk to that cost center and automatically trickled through to the decisional data), we have a fight for sure....and an instability problem. When real-time ETL first became available, people did it "because we can" -- and warehouses were constantly struggling to keep up with load demand, and simultaneously experiencing falling user query demand, because users asking the same question three times in one day were getting three different answers and in many cases assuming the warehouse was unreliable. I think the same is likely to happen when companies try to implement real-time DSS, unless real-time DSS is restricted to those classes of decisions in which decision-makers actually measure time in the millisecond-to-hour range. Beyond those classes of decision, the nightly refresh on the good ol' data warehouse will continue to be 'soon enough'."
Conclusions
The concept of "real-time" decision support is a broad term that is evolving. Both Nigel and Marc raise good points that need to be reconciled. Nigel includes "what if?" analysis using a spreadsheet as an example of "real-time" decision support. Marc focuses on the data side of "real time" decision support. The issue of "push" versus "pull" for decision support is interesting, but my initial inclination is to suggest that both situations could qualify as "real-time" decision support. Thierauf (1982) argued that "any system that processes and stores data or reports them as they are happening is considered to be an on-line real-time system". His view is fairly consistent with Marc's position, but it doesn't seem to account for Nigel's position.
So when is "real-time" decision support desirable and needed? First, no matter what the definition "real-time" decision support is desirable when the decision-maker and organization can benefit. Second, "real-time" decision support must improve understanding rather than increase information load. Third, the support must be cost effective. Fourth, we don't what to provide any type of "real-time" decision support just because we can! Fifth, "real-time" information needs to "make a difference" and it must accurately reflect what is happening in the decision situation. Finally, "real-time" decision support and data analysis is definitely important for some operational decisions.
So I'm in general agreement with what both Marc and Nigel have written, but I want to continue to reflect on the issues and examples they cite. I want to give some consideration to what's possible and desirable in "real-time" decision support in crisis situations, for strategic control, during face-to-face business transactions, and for operations management and financial control. Real-time data gathering and decision support are closely linked in some decision situations, but not in others. Even a quick reading of this Ask Dan! and the one in DSS News, vol. 3, no. 24 shows more conceptual thinking is needed. Various divergent positions need to be reconciled and probably can be reconciled, but as of today I can't provide a rigorous general definition of "real time" decision support. As always your comments, suggestions and feedback are welcomed.
Thanks Marc, Neal, and Nigel for your various emails.
References
Demarest, M., "RE: DSS News: Vol. 3, No. 24," email,
Pendse, N., "RE: DSS News: Vol. 3, No. 24," email,
Thierauf, R. J., "Decision Support Systems for Effective Planning and Control,"
The above response is from Power, D., When is "real-time" decision support desirable and needed? DSS News, Vol. 3, No. 25,
Last update: 2005-08-06 21:40
Author: Daniel Power
Print this record
Show this as PDF file
You cannot comment on this entry
