End-User Segmentation
“If it weren’t for these end users …!”
There are two distinct ways of defining BI users: by skill and by processing requirements. In the previous chapter we discussed some of the user segmentation criteria to ponder. Now we will spend more time defining users by specific BI tools and processing requirements.
Ever have an irrational urge to buy one of those weird gadgets you see on late night television? Sometimes a user will react that way when they see a BI tool. “I’m not quite sure what I’ll do with it, but I sure want one!” Part of a vendor’s modus operandi is to convince everyone in the audience they not only need the tool being shown, but they can use it to cure all their processing ills.
All business people have to deal with data in some form and with computing technologies to get their jobs done. Some can work with tools such as spreadsheets and some are quite ‘dangerous’. The varying degree of skills and knowledge base among users can be staggering. People tend to learn from others and along with this come the bad practices with the good.
Even if you only use a word processing program there are some things that you might not know how to use that would have saved you time if you knew how to do them. You may say, “Like what?” Well, did you know that you can use the CTRL key then the A key (while holding the CTRL key down) to perform a select all? Yes you can also use the EDIT action bar etc. but this is one of the many fast-path operations that many PC users know about. We live in a cut & paste world if we dabble in PCs. Ctrl + C performs a copy of what we have highlighted. Ctrl + V performs a paste of what we have copied.
There are many, many shortcuts and tricks involved with tools and systems. In BI there will be people who know how to do things with the same tool you are using that you are not aware of. We can all be “out geeked”. The BI tools of today offer more and more function while printed manuals appear to be going the way of the dinosaurs. How is one supposed to find and use all this advanced functionality? It simply takes time and a need to go deep.
Those of us who do not have the time or technical background to play with a tool, read all the help, check out the website and more are often just locked into being able to perform a few simple operations with it or we are forced to rely upon others. If this is not going to keep you awake at night or diminish your self worth … so what? The more important things to consider are whether or not your BI tools can be used to make your job easier, more efficient, or change the way the business operates.
Will an executive user become proficient with a BI tool? Will a mid-tier decision maker spend hours learning how to tweak a report to get a different result? Will our company use 1/10th of the functions we saw in that neat new BI tool demonstrated last week? Will I spend an additional 5 hours trying to get that bar chart to look the way my users want it to? The only one of these deserving a “yes” is the last question and that is debatable. If the interpretation of the chart is incorrect due to some limitation in its formatting capability out of the box … then extra time may be warranted. Otherwise we have taken our eyes off the ‘BI prize’ and are tied up in window dressing exercises.
Here is another real world example. A customer had a BI query and reporting tool installed that had been spreading into several business areas where the users were pleased with its capabilities. Most of the analysis had been developed and delivered via IT since the user’s needs were far beyond what most non-technical individuals could produce. This particular tool vendor had fallen on tough times and the customer was getting nervous about their long-term viability.
Major industry pundits were recommending customers switch from the old tool to one of several new ones. A new vendor was brought in to perform a proof of concept and replace the old tool if they could. There were a series of charts, which were very, very difficult to produce in the new tool and had been abominable to produce with the old one as well.
It turned out that the user’s output made no logical business sense … in any tool! The IT support people were constantly railing about how silly this entire exercise was but they had been forced to produce this rather useless output. Hundreds of hours had been invested getting the output together the first time despite the fact it had no real value anyway. No one would step forward and tell the users, “Look, if you want this output to look like this do it yourself. It makes no business sense and it’s way out of the design specifications for this product anyway!”
Had our example application delivered significant and difference-making results it would make sense to either stick with a tool and beat the truth out of the data, or to perform the same work with a new tool due to the business value. In light of the rather senseless exercises involved, there was no business benefit with the original tool and a very poor first application selected for the second.
Were there other applications that may have provided a higher ROI? There was no way to know, we couldn’t get past creating these worthless exercises in output. The final kicker was that the budget was cut in mid-project and the original tool was kept. New projects were curtailed due to the concern over the viability of the existing vendor, but the same meaningless application is probably spewing out worthless output to this day.
