Insights

Neha Dave

Senior Training & Business Change Consultant
Bluefin Solutions

If a system is deployed and no one uses it, does it exist? – Part II: Knowing the beast

In my last blog I described some factors that would facilitate user adoption. These were...

1. Knowing the beast
2. Training
3. Strong user community
4. Metrics

This blog is about the first factor – knowing the beast and is based on my personal experiences in this space. 

Knowing the beast

I'm not a ‘techie’. I don't spend my time pondering over codes and functional modules, nor do I know every transaction code off the top of my head. When I see an error dump or the classic ‘this page cannot be displayed’, I panic just like the rest of you. So when I was expected to engage and gain the trust of over 1000 users on a BI system, my first reaction was...you guessed it...panic!

My first move

Sounds rather dramatic for an IT consultant to call a BI system a beast I know but this is exactly how I felt. Here I was tasked to drive enthusiasm and train users on a system I had not designed. Sure I could throw some terminology around and pretend like I knew what I talking about but I doubt the 1000 users would buy that.

That’s when it occurred to me - what do the 1000 users want to know? What components of the system would excite them (or me for that matter?). This is when I stared the system down and broke it down into 2 major components – perceived usefulness and perceived ease of use (I borrowed these factors from the Technology Acceptance Model by Fred Davis and Richard Bagozzi (Bagozzi et al., 1992; Davis et al., 1989). According to this model, "if a user perceives a specific technology as useful, she/he will believe in a positive use-performance relationship. Since effort is a finite resource, a user is likely to accept an application when she/he perceives it as easier to use than another".

Perceived usefulness

This rather academic concept relates to the concept of business benefits in our world – how will this system help you? By focussing on the benefits I was able to understand the system mechanics better. For example: One obvious stated benefit for any BI system is the fact that it helps reduce time for data collection. This led me to understand the process of data loading, transformation and the wonderful world of the administrative workbench .By peeking into the backstage I was able to understand the performance on the stage – and of course use this to paint a rather exciting picture to my very captive audience during a training session. Suddenly it was not all about the time of data loads and the error stack, but the narrative behind how these loads are fed into BW from various data sources and how you no longer need to log into multiple systems to get pockets of data (I did a bit of role play to exaggerate an irate end user at the mercy of a spreadsheet as well!)

Stated benefit two: Information readiness. This led me to explore the extraction and monitoring activities in BW. For my users this meant translating how and when their information will be made available to them, particularly demonstrating the user friendly way in which this information will be presenting (The world of BEx Analyser)

The system no longer felt intimidating and I was able to explore the BW architecture by keeping my benefits hat on.

Perceived ease of use

This translates to basic user navigation and the user experience. How easy is it for the user to access the report? How easily can he/she manipulate the report to get the information they need? Keeping this in mind, I explored BEx Analyser and the features of the context menu that allow for the slicing and dicing of the information. I learnt how the reports can be designed, or how key figures can be restricted. Users could see how easily free characteristics can be dragged into a report and how they could draw comparisons between using query designer and creating a pivot table in Excel

So, not only did I use these basic tenets of perceived usefulness and perceived ease of use to understand BW (remember I am not ‘techie’), I used these principles in designing my training sessions. And this is what I'll be covering in my next blog.