When many organizations invest in new Business Intelligence (BI) tools and systems, much of the focus is put into the technical requirements of connecting the tool to the data source. However, these steps are only a bare minimum for successful business analytics. It is equally important to create a comprehensive plan for the day-to-day usage of the BI solution. This is especially true in large enterprise deployments, where there can be many different stakeholders, goals and requirements involved in the implementation.
After the technical requirements are met, the final phase of BI implementation begins. This phase requires working with a more business-oriented team, such as executive management and financial analysts. It is up to business analysts to elicit requirements from the BI tool stakeholders, to develop meaningful business outcomes, and to write business requirements which clearly communicate all relevant technical and design details to report writers.
Identify relevant stakeholders
No matter the application of your BI tool, the most insightful business requirements will come from the stakeholders of the reports. While in a smaller organization this might be just a few people, within larger enterprise deployment there might be dozens or hundreds of dashboard consumers, analysts and others involved.
Stakeholders can be broadly categorized into three groups:
- Management: Typically management – in the departmental or organizational level – will be the most critical stakeholders in your implementation. As the primary recipient of reports, management will list their requirements and needs, and approve report content and format.
- Analytical team: After all the technical requirements have been met, the analytical team is the one that will be modeling the data, creating dashboards and performing deeper exploratory analysis. The analytical team’s familiarity with the data will help management decide the best way to visualize data. The analytical team will also help management refine their requirements. For instance, if management wants to develop a dashboard with data that does not exist, or is in a format that does not enable analytical processing, the analyst team can inform management of the information gap, and plan to modify the database accordingly.
- Employees: While not every person in the company will spend her entire day crunching data, the organization may wish to open dashboards up to a broad audience of internal viewers (for example, by showing them on large television monitors). In this case, it’s important to understand which metrics are relevant for teams or departments as a whole. Employees that will be measured by the reports are also stakeholders of reports. Clear communication about metrics evaluation notifies employees how their work is measured, and how they can be the most productive in their position.
In a typical enterprise BI implementation, you want to have several rounds of stakeholder meetings:
- Executive: including the CEO, COO, and CTO
- Finance: Including the CFO, manager of FP&A, senior accountant, and AR/AP specialists
- Sales: Including the CFO, VP of sales, and senior sales associates
- Marketing: Including the VP of sales, director of marketing, and marketing analysts
Focus on business outcomes
When thinking about developing a BI solution, many teams are not entirely sure where to begin. As a result, they try to “explore all options” and create as many new dashboards and reports as possible. However, this can lead to “flavor of the week” reports or “report-o-mania.” Reports in this phase often have multiple formats of the same information, with increasing levels of detail and complexity, but delivering no additional business value. While the prospect of developing new views of data is exciting, it is important to focus on the business value of each report. Each additional report adds additional cost in development and maintenance.
For example, during a recent BI implementation of Sisense Business Analytics Software, one of our clients discovered there were six different versions of the income statement. Each had their own unique variation of time periods, account summation rules, and financial ratios. At one point in time, each report format had a necessary function. However, management and investors were frequently confused by the differing versions of the reports, and finance analysts were frequently tasked with report maintenance and information requests. They eventually decided to use one internal format going forward, and provide other versions only on an as-needed basis.
Frame the discussion for good requirements
All dashboards must serve at least one of three primary functions:
- Executive reporting: Executive reports deliver a summary of the financial and budgetary status of the company. These reports are targeted for senior management with an acute interest in the financial performance of the company. Executive reports typically include cash balance statements, accounts receivable collections items, month-over-month expense comparisons, or forecasts through the end of the fiscal year.
- Customer reporting: Customer reports deliver a quick view of customer-related activity, primarily in sales, marketing activities, and customer service. These reports are targeted for sales and marketing management who are focused on generating new revenue and retaining current customers. Customer reports typically include sales reports, marketing campaign statistics, product returns, support tickets, and customer opinion survey results.
- Operations reporting: Operations reports deliver a “scoreboard” view of daily value-added activity. These reports are targeted for employees and their direct supervisors. Operations reports typically include production outputs, downtime or work stoppages, quality reports, and efficiency ratios.
If a requested report does not meet one of these three criteria, the business requirement for the report should be re-investigated, before investing into development and maintenance of the dashboard.
Develop good requirements by asking great questions
BI implementation requirements coming from business executives can often be vague. Features such as “slice-n-dice capabilities,” “reports shared online,” and “month-over-month comparison”, while useful, are usually not enough to define the exact dashboards or views that will need to created.
During requirements elicitation, wh-questions are probably the most useful to get the most actionable information. Questions like these should help business analysts gather the required detail within the initial stakeholder meetings:
Who
- Who will receive each report?
- Who should be able to access which information?
- Who will develop and maintain the report?
- Who is responsible for the report’s data?
What
- What information will be on each report?
- What reports currently exist in another format?
- What changes might be made to existing reports?
- What new data views should be included?
- What formatting should apply to each report?
- What design specifications should each report have?
- What snapshotting or historical functionalities should this report have?
- What interactive, drilldown, and “slice-n-dice” capabilities should this report have, if shared online?
- What ETLs or stored procedures need to be developed, if any?
- What database enhancements might have to be added to meet reporting requirements?
When
- When will each report be delivered?
- When will the analytical team receive training on the new BI system?
Where
- Where will recipients access the report? Online in a shared environment? A shared drive? Email attachments? Email screenshots?
- Where will recipients access snapshots or historical versions of the report?
Why
- Why should the receiver view the report?
- Why is this report critical to the business?
By asking these questions and conducting a thorough requirements elicitation process, a vague business requirement such as —
“The BI tool will share dashboards online with slice-n-dice capabilities”
Should be translated into something more concrete such as:
“This dashboard will contain the income statement in the approved internal format, showing year-to-date in monthly buckets, with a comparison to the previous month. Users will be able to change reporting periods (years), with a radio button for each year. Users will also be able to click on each account category to see a detailed drill-down of individual GL accounts. On a separate page, this report will also include a line graph of net profit by month, with a color gradient showing green for positive net income and red for negative net income. The BI tool will share this report to the BI tool’s server. The online report will be refreshed on a weekly basis, and will be refreshed automatically by a scheduled job in the report server. Only executive management and finance user accounts can access this report, and other users will be prohibited from accessing this report.”
Do you have your own best practices for requirements elicitation to share? Tell us in the comments! Finished gathering requirements and want to jump into dashboard design?
