For the purpose of this discussion, I am including all facets of the decision making process in the term "decision support." That includes: data, information availability, analysis, reporting, and distribution. It is a pretty wide range of offerings, but if you think about it, it makes sense. In order for someone to make an informed decision about anything - ranging from where to go to dinner tonight to whether to launch a new product - you need to go through each of these steps in the process.
Just for fun, if you take the dinner example, the process might look like this: data (a list of what restaurants are nearby); information availability (access to information on each of the restaurants and the dining preferences of your guests); analysis (is there a match between what we want and what is available?); reporting (tell the group, here are our options which should we choose?); and distribution (inform everyone of the decision including when and where to meet).
Fortunes have rarely been lost deciding where to go to dinner, however, the same cannot be said about the decisions made as part of business strategy and day-to-day operations. So how can you optimize your organization to support these decisions?
It all boils down to two things: how you are organized to handle decision support and the tools you put in place to enable decision making to happen.
First, your organizational structure has to facilitate decision support. Both IT and the business need to work in tandem to create a structure that eliminates redundancy and provides clarity of responsibilities; otherwise, you're pouring a lot of money down the drain and creating confusion before you even enter the decision-making process. The activities surrounding decision support can be lumped into three main areas:
Let's look at each one in more detail and discuss what tools, in general, are involved.
Analysis and Reporting
This includes all scheduled and ad hoc reporting including data analysis and distribution. It includes all the non-recurring, spur-of-the-moment type requests that cannot reasonably be automated or systematized. This sort of activity is ideally a business function because it is heavy on the use of technology tools and much lower on the programming scale. Not to mention, the analysis and design is better handled by the people with the business knowledge to make what is developed and used more relevant and useful for key decision makers.
This group of people leverages existing systems and data repositories to mine data and slice and dice it in a way that makes business sense. In an ideal scenario, you have business people with strong IT backgrounds or, at a minimum, technical savvy. They are the people who know the ins and outs of reporting packages (ranging from Microsoft Access to Cognos to Crystal Reports to reporting modules within ERP solutions just to name a few). They are power users of these tools and able to create meaningful lists, charts, and pivot reports in their sleep.
Once they have worked their magic with the analysis and reports, they coordinate distribution of this information. Distribution can range from a simple e-mail to complex and customized distribution organization wide. Again, it requires working hand in hand with the technology gurus to make this happen reliably and seamlessly.
Information Availability (Systems)
This is the area we most often think about as IT professionals. It involves system development and/or implementing purchased products to service ongoing, regular, and predictable information needs. It includes things such as Intranet applications, desktop applications, and client-server applications that are there, on-demand, for people to use regularly.
In an ideal world, the information we need most often would be available at our fingertips and in the perfect format we need to make whatever decision needs to be made at that moment. Since reality is a little less than ideal, and it doesn't make cost-effective or business sense to build systems to handle every last possible scenario, it is even more important to do a good job with requirements gathering and impact analysis.
It is equally important to eliminate any duplication with the analysis and reporting group while ensuring that recurring tasks are systematized, as appropriate. Again, communication and coordination is the key.
The quality of your data is the foundation of all decision making. It needs to be timely, complete, accurate, and up to date. Without that, decision making becomes a crap shoot and it is like building a brick-and-mortar structure on a house-of-cards foundation. The technologies most often associated with data quality include relational databases and data warehouses.
What can you do to ensure your data is up to snuff? Follow this checklist:
Y/N Do you receive your data (inputs) from reliable sources and systems that have their own built-in checks and balances to ensure data integrity?
Y/N Do you have a validated process for combining and cleaning the data?
Y/N Is data received and cleaned in a timely and consistent manner and is the process documented?
Y/N Is your data secure? Do you have the necessary hardware, software, and procedural security measures in place?
Y/N Does an independent group perform quality control on the data to ensure data integrity?
Y/N Are there proper checks and balances in place to ensure that systems that use the data maintain transactional integrity when updating the data and are displaying the information accurately?
The Balancing Act
The key to decision support success is keeping these three components of decision support functioning effectively on their own while ensuring communication, coordination, and consistency between the groups. Whenever you encounter a challenge in any of these three areas, simply pause and ask yourself, "Would I be comfortable making a key business decision based on this information?" If the answer is yes, you're in fine shape. If you find some doubt creeping in, it is time to step back and look at how the different components of decision support are handled within your organization.
This article was first published on IntranetJournal.com.