Most analytics and business intelligence teams spend their time devoted to fielding requests from stakeholders within their organizations. They may be helping a product development team understand how a new mobile app is performing or they may be working with the marketing team to track new customer acquisition and lifetime value. Rarely does the BI team consider that what they have developed is something with an analytical need very similar to that mobile app product or customer acquisition process.
Analyzing your business intelligence users:
Each month the BI platform is receiving new users – new employees joining the company, new users within existing stakeholder teams, and new stakeholder teams entirely. We may have training programs or quick start guides to help new users get started, but we need to think about tracking the activity of those new users over time too. In the mobile app world, we might think of a cohort analysis to do this. Of the new users for a month, what was there initial activity, how many of them were still active after 1 month, after 2 months, etc. How many daily/weekly/monthly active users do we have and is that number increasing or decreasing? How many reports are they looking at? How much time are they spending in the BI system? Are they using multiple features offered by the platform (reports, filters, email notifications, ad-hocs, etc.).
Analyzing your business intelligence content:
Your business intelligence environment probably has dozens or hundreds of reports. How many of them are being actively used and need to be supported vs. which could be retired or don’t need support? How many of your reports are being viewed by many people vs. just a single person? Which reports do the executives look at? Which reports are viewed by the marketing team or the finance team? Could you quickly onboard a new team member by pointing out which reports and BI capabilities are key to their business function? When are people accessing your reports?
Analyzing your business intelligence environment performance:
Once you’ve zeroed in on the reports getting the most use and when they are being most utilized, it is important to make sure performance is at the level you want. Typical high usage times would be Monday mornings, end of the month, end of the quarter, but you might have other busy periods based on your use cases. For static reports, they can often be generated in advance to allow for instant access by the users. For more dynamic reports or ad-hoc query capabilities, users may be able to tolerate a few seconds of wait time but not more. One significant cost of a slow BI system is users not asking questions of the data because they know it will take too long to get the answers. Ultimately this will lead to reduced engagement with your BI system.
Paying attention to the users, content, and performance can help make for happy users, a successful business, and a solid BI system implementation.