So, you created your enterprise-wide, state-of-the-art, metadata driven data warehouse with a user layer of reporting tools and analytical tools and everything else anyone could ever need. You have everything. Except one thing. Users. Well, who needs them?
What you need to understand is that launching a Business Intelligence solution (BI-solution) is nothing at all like launching an ERP or email-system. The ERP or email is a necessary tool for almost all employees and no matter how bad a system you have for those purposes, people will still use them. They simply have to use them in order to do their everyday job.
BI-solutions on the other hand, employees don’t need to use at all. Sure, most people agree that BI and good information is crucial in order to become a successful organization. But, what is important for the organization in the long run might not be the same as what is important for the individual employee in a specific situation.
So, while they don’t have to use your BI-solution, you have to sell it to them. You have to deliver true business value and you have to do it in a way that makes it easy to access and use. This means that to be successful in your ambition to transform your organization into an organization of information hungry knowledge workers, you need to act as if you were developing and selling a product to customers.
With than in mind, here are some of my thoughts on important key points in creating and selling your BI-solution to your users. I will focus on the issues that I think need special attention when dealing with BI-solutions, compared to other IT-systems.
The key points include
- Data quality
- Information relevance
- User service
The first two points will be included in this blog post and the remaining two in my next blog post.
Everyone agrees that data quality is really important. Still, too often I have heard the term “Garbage in – garbage out”, or that “our data is structured this way so this is what we can give you”. This is not good enough. It might work if your primary goal is to close your BI project successfully, but if you want your users to actually use your BI-solution, you need to do more than stating the obvious. What you do when you say things like the above is like trying to sell a wrecked car to someone, claiming it was like that when you got it from your supplier.
My view on this is that you are responsible for making sure that what you deliver is of good quality. So, if you create the user interface application, you cannot blame the data warehouse for lacking data quality and if you are in charge of the data warehouse, you cannot blame the source system. You make sure to fix the data quality problems in one way or another, or you do not deliver at all.
This issue has many aspects and I am not saying that data quality needs to be perfect, but it has to be good enough for the users. If they cannot trust the information, why should they use your BI-solution at all?
Also, the information needs to be relevant to the user, which is not always the case. One simple and common example is organizational changes. Assume you create a BI application for analyzing sales over time, using slowly changing dimensions so you can capture organizational changes. Then the sales manager says that he/she does not understand why you have different historical organizational structures in your solution. He/she only wants to see the sales figures using the current organization, otherwise it will be pointless. Another similar example is when the sales organization has grouped the organization or product hierarchy in a way that is not available in the source system or the data warehouse. They will need their product grouping in order to make meaningful analysis.
In these examples, your solution will not be relevant for the users until you make it relevant, by following their wishes or by convincing them that your way is better in some way. What you cannot do is to say that “this is how it should be”, because then the sales manager will explain to you that his/her business controller delivers sales figures with the correct product hierarchy in a spreadsheet every month. After that they will continue using the spreadsheet solution until you have changed your solution.
Another thing about relevance is that if you want users, the information need to be relevant for the users, not for their managers. This means that if you create a high level enterprise dashboard for the management team, you should not expect the employees to come running to your application. Instead, focus on tactical applications with detailed information that is relevant for the employees on a daily basis. Then the management can have the high level dashboard as well, but don’t expect it to generate too much traffic.
So, deliver what the users need, or they will happily continue to use their spreadsheets and you will keep looking for users.
In my next blog post I will go through my remaining points and sum it up. Until then, thank you for reading and feel free to comment.
Part II of this post can be read here.