We believe one of the main reasons that self-service tools have yet to be widely adopted within organizations, is that the most of the self-service tools on the market today are aimed at one type of person, typically either an IT technologist or a sophisticated data analyst.
However, that one-size-fits-all approach doesn’t satisfy the unique needs and skill sets of business users who are also looking to leverage self-service analytics.
Here are a few best practices for helping you determine what type of self-service tools your users need:
Define the Personas: It’s important to understand how your end users use data and what their decision environment looks like. Some users are “Consumers” and want to view static reports, while others, like “Creators,” may want to supplement existing self-service BI dashboards and reports with their own metrics and measures. Then you have the power “Analysts” who want a self-directed experience. Once you determine which personas you need to address, you can then map the right capabilities to their needs and abilities.
Deploy a portfolio of tools that support your personas: When looking for tools, you should strike a balance between optimizing the portfolio and optimizing fit to end-user needs. For instance:
Consumers: Deploy a highly scalable distribution of well-defined metrics in the form of dashboard and reports. By embedding analytics into these consumers’ workflows, you can help drive further adoption.
Creators: This persona is looking for guided data, secured distribution, and the ability to pick data and format visualizations to share.
Analysts: Want the ability to choose their own data sources, in addition to accesses corporate data. They want to collaborate to discover the best insights and push the results back up the chain for standardization as required.
Manage Exceptions: Even with good definition of your personas and the right portfolio of tools, you’ll never get to 100% without some exceptions. Standards aren’t about eliminating the exceptions, but carefully managing them. You should have standard tools that fit 80% of use-cases, and then deploy specialist tools in very tight, limited deployments to meet the demands of exception use-cases.
Read the other posts in this series: