There’s been a lot written and discussed recently about the democratization of Business Intelligence—a magical world where IT isn’t slaving over writing reports. But when presented with the idea of this for an organization, we’ve heard many IT leadership teams say that their users don’t want to create their own reports and dashboards.
Sound crazy? I know; it’s the difference between waiting on someone to create that report for you in six months, and completing it when you need it, the way you need it. While self-service BI is an incredibly impactful tool for your business, there is a learning curve. And let’s face it, we’re all busy.
Regardless of which tool you’re evaluating, most of the goals and preparations are the same, so let’s take a look at both:
What does it offer your organization?
If thought through and structured correctly, you should experience:
- Reduced load on IT resources to create reports and dashboards
- Significantly easier creation of dashboards, metrics and reports; a shift that puts data and powerful analytics tools into the hands that need it
In short, you’re putting a research tool in the hands of a researcher, so they can answer the ‘why’ question consistently.
What do you need to do to prepare?
Decide on a security model. If you are pulling data from a variety of sources, you need to decide how to secure that data in such a way that users who are creating ad-hoc reports, dashboards, etc. are only pulling the data they are permitted to see and not burdened and inundated by regular invasive security barriers.
Assess data quality. Can we actually produce the reports we need with the data in our source systems? Or do we need to massage it into better formats?
Simplify complex data structures. Some data sources may have data structures that import as-is into your data model, and users struggle to make any sense of it. Many times, it makes sense to aggregate and simplify the data into more manageable secondary sources to ease the training time with the ability to grow the complexity with advanced adopters.
Plan ingestion of data into BI engine. Many ERP systems aren’t built for reporting, and you may need to use advanced techniques to get the data out in a timely manner without jeopardizing the ERP system. After all, that BI query is not more important than getting the production floor the data it needs to produce product. To plan how your data needs to flow into the BI system, ask the following questions.
- What is the pace of change of our data?
- What are the needs of our business customers?
- How flexible and stable are our data sources?
Determine an adoption strategy. If you build it, they won’t always come. In fact, given a blank slate, sometimes you might find resistance. Growing by data source or by subsection of the user community might make more sense—from there you might find that some demand and some training spreads via users.
One final thought to consider in the decision process: Even if your user base is not ready for self-service BI, don’t discount a tool because it offers it as a feature. You may find that it saves IT resources an incredible amount of time in fulfilling the requests from your business customers. You can simplify the security model to start and grow into a more complex security model as you release to more users.
In fact, instead of releasing the system to everyone at the beginning, releasing to a select group of early adopters within the organization is a great way to “socially engineer” your way to the IT utopia of self-service. If you choose a tool that isn’t self-service capable, you may find that as you mature, you outgrow your existing tool as your user base becomes ready for self-service.
