OK, let’s explore one of the fundamental reasons why different user groups in our organization need different tools from the SharePoint BI stack. It boils down to the ‘degree’ of self-service functionality they are comfortable/capable of using.
Several years ago the promise of ‘pervasive BI’ meant the information worker would not only have all core analytics at their fingertips, but could perform their own analysis on interesting subsets of data and mine nuggets of hidden information from the corporate gold mine of heterogeneous sources.
Uuhhh… ok.
So let’s see, I’m an I.T. manager, I have a BI steam shovel at my disposal, but now I’m supposed to give the business users access to the controls as well? Do they even want to learn how to run the steam shovel? Are they capable of learning it? What if I just give them access to a push cart? Better yet, I have a gardening set in the garage, can I just give this to them and call it a day?
Fortunately the BI vendors answered this problem with an onslaught of ‘self-service’ tools and platforms. Self-service BI was the new answer. Push functionality to the information workers desktop; relieve the pressure from the I.T. department; live in harmony; overall a good plan. The problem that still plagues our clients however is deciding which technologies are best for which user groups. Why is this? We don’t all agree on what the definition of ‘self-service’ is.
To help answer this question, let’s define a new term. In the previous post we segmented our user groups by ‘degree of power user’. This designation helped us define what a particular group is not only capable of using, but what they are most likely to use (think adoption). So it only seems logical that we should segment our self-service capabilities across some spectrum as well. We’ll use the term ‘Flavors of Self-service’ to help us further define what ‘self-service’ means to us.
Self-service BI has the same definitional problem as ‘real-time data’ does. When clients state they want real-time data I immediately go through a laundry list of options for them:
“Do you want updates sooner than a week?” “Yes”
“Updates every second?” “No”
“Bigger than a bread basket?” “Maybe”
…until we settle on our definition of real-time. Self-service is no different which is why we need to think about the different flavors and which is best for our user groups.
Typically I go into demo mode at this point to illustrate what I mean by ‘flavors’ but considering the two-dimensional nature of this blog, I’ll have to leave to following diagram to your imagination.
As you can see, we’ve taken the previous capabilities framework and modified it.
First, we’ve changed it from a ‘capabilities’ framework into a ‘usage’ framework. That is, we’ve adjusted the overlay of technologies to more accurately reflect what a particular user group may actually use.
Secondly, we’ve introduced the idea of self-service variations as defined below:
- Drag and Drop – hardly a new concept but one that users are most familiar and comfortable with. The user has a small degree of freedom but is limited by what has been preloaded into their spreadsheet.
- Free-from – much more powerful as this flavor not only allows for drill-down but for cross-drilling as well. That is, the deliberate deviation out of one dimension into another dimension (while keeping the context of the previous drill path); both of which may or may not have natural hierarchies. This functionality implies there is an OLAP engine (cube) running the relationships and aggregations behind the scene.
- Modeling – this concept gives the business user the power to create relationships across disparate sources (much like data modeling), which sets up a data set with which to perform business/problem modeling. This is the precursor to creating predictive analytics.
As you can see, with an expanded definition of ‘self-service’ we can now apply the appropriate flavor to the appropriate user group; avoid over/under-whelming those groups and affect long-term adoption.
