I have never seen research documenting what percentage of a corporate IT budget is spent on BI. Based on my 30 years of experience of being active in this area (first as a controller and later in various BI-related roles with a large system integrator), I dare to state that BI only accounts for a relatively small percentage – maybe five percent. In organizations that heavily rely on direct marketing activities to support sales in the business to consumer market, this percentage is probably higher. 

I may be biased by my 30 years, but I believe that in spite of BI’s relatively small share of the budget, there is probably no other area where the same level of confusion exists between users and the IS department regarding the role that either side has to play. It is also an area where a lot of discontent exists with respect to the applications provided by the IS department.  But why? To find the answer we have to look at a number of issues.

In the Beginning

Let’s start with a look at the history of BI. The first products to provide information to managers were a kind of 4GL “program language” on the mainframe. But strangely, these products were not used by the IS department but directly by the users (mostly analysts or junior controllers). You could say that these products were used not thanks to the IS department, but in spite of. IS reluctance to support such products was partly because the tools were quite demanding of mainframe resources. 

Oddly enough, it took the advent of the PC and Windows 3.1 to change this. The original players on the market had prepared their tooling for IBM’s OS/2, and that proved to be a costly mistake. A new class of vendors came to market, and this time the IS department got involved. IS involvement also increased due to the work of Bill Inmon and Ralph Kimball on the subject of data warehouses, which became popular as a result of the scattering (some might say proliferation or even pollution) of decentralized and independently running applications. Also,  making and keeping applications sustainable and well-managed is a task that most users were not skilled to accomplish on their own.

So users and IS came to an arrangement where the users defined the needs and paid the bill and IS took care of the applications and underlying infrastructure. And this was the typical model for applications to support operational processes.

But as recent history has shown, the results were not very impressive. Yes, a lot of data warehouses and even more BI applications have since been developed and put into use. However, user satisfaction is still not very high, but why?

IS departments used to work via a so-called waterfall approach, which is  just too time-consuming to produce timely available information, even when applied in an adapted manner. To complicate use of this model, it sometimes seems that analytical and managerial users only know what they want once they see the results. Additionally, business conditions can change from one moment to another, as we have recently seen, so information needs change just as quickly, whether the users know what they want or not.

A Call for Change

When we keep in mind that BI is only a small subset of the IS department’s activities, it’s no wonder that the prevailing way of working is based more on the bulk of the activities, which is still the support of operational processes.

Additionally, the way BI is financed is not helpful. Users are only interested in the front-end application and are not really interested in the back end (the first pedestrian doesn’t want to pay for the whole bridge); they don’t see it and it takes too much time to develop the infrastructure for the solution. If pursued through back channels (shadow IT) the result is often a multitude of systems that are not aligned or cooperating and are sometimes even working against existing back-end solutions. This disjointed approach and lack of agreement about which solutions require investment makes it increasingly difficult to get happy users.

So what we observe now is the call for “self-service BI,” however user wishes are not terribly different from those of the 1970s and 80s. IS departments can have their objections, but this type of user (i.e., management) has the power, money and the attitude to get things done as they like it. IS hasn’t  met their needs, so they try to establish means to do so on their own, hence “self” service.

The observant reader may have concluded that I am a bit skeptical about the chances of long-term sustainable success of this revival of the “do it yourself” approach. I believe that IS and business users can’t fully function without each other, and that there is quite a bit of marketing speak involved. When people can’t live without each other, they have to find a way to live with each other.  

Living with each other, even if it is against your will, means that the first thing you have to do is develop a good set of arrangements with respect what each of the parties has to do and, maybe more importantly, has to leave to the other. It is also important to agree on what you can expect from the other.

As the game starts with the users, they have to ask them themselves initial questions to determine what they want. I believe that we can summarize these questions with the 7 W’s of the business:

  1. Why do we need information? It is always good to know what you want to achieve with whatever you want to have and to share this idea with the one who is responsible for the answer.
  2. What information is needed? Even if you don’t have a clear answer to this question yet, you probably have some idea, or perhaps the person responsible for the answer to question number one may have some good ideas.
  3. Who needs the information? It is quite logical to have an answer to this question, and it is wise to consult anyone involved so information can be delivered to all the appropriate parties.
  4. When do we need information? This is the real tricky one. It is always tempting to say “yesterday,” which is impossible. It is important to be to be flexible in terms of expectations and feasible delivery approach.
  5. Where do we need the information? In the end, the information must catch the eyes (or the ears) of the person(s) identified earlier. And there is more to consider than just paper versus computer monitor.
  6. What is the price we are prepared to pay for the information? This is always a big issue in literature about BI applications, but surprisingly this is often the least of the concerns of the person requesting the information, even though he or she is conceptually aware of a limit on appropriate cost and the value of the solution. 
  7. What is the frequency and level of change in the answers to these questions? This is also a tricky one. Change is the name of the game, and frequent changes require that we readdress the previous tricky question, “When do we need the information?”

That was the easy part. The questions are asked and enough information has been provided for the IS department to start its work. But what does the work of IS exactly encompass in the case of BI?  Of course it is to provide answers to the users’ questions while taking into account the answers given with respect to the 7 W’s. Simply stated, with BI the IS department takes data that is hidden in various (mainly internal) source systems and, through some intermediate storage and processing, reworks that data to information and then displays the information to users via various methods. And that is exactly what every provider of value added logistics services in the world of physical goods has been doing for decades: bringing produced goods via intermediate storage and processing to the buyers (users) of these goods.    
Thus, what IS has to do can be summarized with the 7 R’s of IS (which are the same as the 7 R’s of value-added logistics).  The challenge for IS is to establish a value- added information logistics process that is based on an adequate architecture and is supported by the right technology to develop applications that are aimed at bringing the:

  1. Right quantity. It sounds perfectly natural, but you should have to pay a respectable rate for all the hours spent reading lots of redundant data.
  2. Right goods. Relevance of the information for the question at hand is key.
  3. Right time.  Perfect information received one hour after the decision had to be made is as good as no information at all.
  4. Right condition. The quality and precision of the information must conform to the decision being made (e.g., the last digits behind or before the decimal point are not always necessary).
  5. Right price. Why spend a dollar to save or earn a dime?
  6. Right places. Information must be delivered to the eyes or ears of the person who must make or prepare for the decision.
  7. Right product. Information: What and where is the information I’m looking for?

The key measure of success for these 7 R’s lies with the first appraisal of the users. A key enabler for this success lies in a value-added information logistics process that is based on an adequate architecture and supported by the right technology.
Some recommendations can be found via this link.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access