You drive adoption of BI through three approaches; firstly you set adoption as a goal, secondly you make your content compelling and ONLY THIRDLY do you think about tools. Too many people focus on item 3 and their BI doesn’t penetrate the organisation like they wanted it to and therefore doesn’t deliver the benefits they sought.
It may sound strange to set adoption as a goal, however we have all worked in organisations that have taken an IT-led or procurement-led approach to BI without sitting back and working out what the BI is for. In the NHS we have a lot of BI projects that work like that. The goal might be to recreate the old reports on a new platform that looks more shiney and therefore will be used. The goal might be to implement something the CEO saw at a trade fair. Sometimes the goal might be to implement something that should deliver a performance framework (people, processes and technologies) that will show how a division is making a contribution to a national strategic agenda, local operations or delivery of service line responsibilities.
When you get into this area you are starting down the right road but the wheels come off if this top-level intention is not enshrined in operational delivery methods.
I often meet organisations that bought a reporting solution because they were going to implement service line reporting. There is a particular reporting application vendor that is doing quite well out of this trend just now, with a high number of wins but a questionable level of adoption. Their software looks cool. It has in-memory BI and therefore you can get going with it pretty quickly. The licensing model means it is quite attractive for PoC work. Moreover the pitch really talks to the value of self-service BI as an enabler of behavioural change and therefore performance improvement.
Obviously I am not talking about the Microsoft stack here.
Contrast this with the perception of the Microsoft stack, though, for a minute. Enterprise-class solution, feature rich and therefore perceived as expensive, not nimble and therefore not suited to quick PoC work – often we here this story. Not true, my friends. Not true. We have done a fair few PoCs on the platform and scaled them out quickly and relatively inexpensively – so it can be done. But in terms of this blog the point is that the reporting solution I was talking about is very costly to scale and therefore that is a barrier to adoption.
So, we agree. The best way to achieve adoption is to set it is a target and focus on delivery. Put information in the hands of decision makers and they will make better decisions – give them a shiney tool and they may or may not.
The key point is achieving the link between the evidence and the decision – in other words creating compelling content. Compelling content will provide decision-makers with what they feel they need in order to do their job. It’s not difficult to understand that. I favour the agile software development approach of collecting a user story, such as:
As A |
I want to |
So that |
Theatre scheduler |
- Prevent session over-runs
- Monitor session utilisation
- Help Consultants keep their log book of work done in theatre
|
- Sessions do not cost more money than they should
- The available time is used to treat the most patients, to the highest quality, in a way that maximises Trust revenue
- I can help them with their professional development
|
This tells me what the Theatre Scheduler considers to be compelling so that I can work out the data he needs (session times, staff, work done etc) and then how to render it in the fewest clicks.
After all that I can then worry about tools……guess which ones I would use blog-readers!
Disclosure: The company I work for is a Microsoft Partner
*Disclosure: I am a real user, and this review is based on my own experience and opinions.