In the past, I've written a few posts that discuss dealing with the challenge of user adoption when introducing a new business intelligence solution.
Recently I have encountered some scenarios that have challenged my ego and my desires to produce solutions that I feel are extensible and efficient.
I continue to learn more about the psychology that is involved when users are asked to abandon their old processes and adopt a new (and in my opinion better) way to accomplish their tasks. So here is my dilemma: I can either continue with my stubborn ideas of implementing best practice solutions or I can bend (can you do the limbo?) and design a process that caters to the user's comfort levels.
Which one to choose? In this scenario, you would need a significant amount of power and influence within your organisation to override the user preferences for their work tasks (covering many departments throughout your organization) and replace those processes with your own design and plan. In addition, even if you happen to have this type of clout at your organization, this iron fist approach will likely just cause resentment and rebellion – resulting in little to no user adoption.
Baby step. You've done your research, you see multiple ways that tedious manual processes can be streamlined, but your users aren't quite ready to make this leap. If you are like me this may be challenging. You may be thinking "really? you want me to implement a design that I don’t think is the best solution?" and my humble reply is "yes, sometimes." I swallow hard as I write this because admittedly I am still having trouble accepting this concept.
Selling your solution to the users in your organisation is a psychological process as much as it is a technical process. Consider this scenario: Users currently present KPI trends and results to executives based on manual entry into spreadsheets. They may incorporate some charts and include some complex macros that beef up the technicality of the spreadsheet, but ultimately they are still relying on manual entry. To me this method screams risks of human error, potentially lost data, lack of historical storage, and difficult data retrieval… Ahhhhh!
From my perspective, I see the best solution for generating these KPIs in a consistent and reliable manner is to pull the data from the sources into the data warehouse and then generate automated reports or create dashboards for users and executives (seems obvious, right?). However the reality is that for most end users this would be a dramatic transition, even if it ultimately means less work. They may also be worried about their jobs no longer being necessary. So, it may be going against everything you feel is "right" about a business intelligence design but I recommend taking baby steps here.
First you may want to try a simple solution that utilises your data warehouse while still allowing the user to remain in complete control of the data that is inserted and reported on. If they are used to using a spreadsheet as their data entry point then a possible solution is to provide a SharePoint list that resembles their current data entry format.
Allow the users to continue their manual entry while also becoming familiar with the SharePoint structure (or other collaboration BI tools you may be using). You will be able to extract this data into your data warehouse and generate reports/dashboards while also maintaining history.
The lesson: Don't take away all of the users' control at once. Trust is a slow process and ultimately you need your users to trust the data that lives in your data warehouse. When they are able to create useful reports by pulling the data from the data warehouse (that they essentially manually entered) then they will slowly grow an affection for the structure and will hopefully over time begin to ask you how other processes can be streamlined. You may be the BI guru, but ultimately your users will end up being the ones who set the pace.
Phocas Software was an outstanding performer in BARC BI 2014, the world's largest business intelligence software survey.