From time to time, I get requests for new reports or adjustments to existing reports.
Using case study examples as fodder for my business analysis blogs, I have come up with the following use case:
Case: Peter (not real name) has asked IT for a report on the number of inquiries made by customers on a certain product line for the past year.
On the surface, this seems like a straightforward request. As a business analyst, I will be the first to say that it isn’t. IT has asked for my help to get more information. As the BA, I am the liaison between the technologists and the user community. It is my job to clarify the requirements.
First, I write down the problem statement: “User does not have access to customer inquiries about a certain product line for the past 365 days.”
Here are my initial questions, using a breakdown technique, about the request in order to demonstrate the depth of analysis for a simple report (imagine if the request was complex!) in order to deliver value to the customer:
- Does the user alone need the information or do others need it?
- Are there other users within the organization that could use this information?
- Which customers? All customers? If so, what customer data attributes are required for the report?
- What data attributes are missing that the organization may not have that needs to be pulled from open data sources?
- How is the data to be structured in the report? What are the drill down filters that the user requires?
- Which product line?
- What the are data attributes about the product line to which the user needs access?
- Does the user need to see other inquiries about products lines for which the customer made a purchase? If so, does the user need to see inquiries 365 days back for those product lines?
- Does the past year mean all inquiries from today back 365 days? What is the date range?
- How is the report to be delivered to the customer? Excel? Is there a centralized reporting service to which the report can be sent?
- When does the user need the report? Is the need urgent or can it wait? What are the perceived service levels for each level of urgency?
- From the technology perspective, I don’t care where the data is stored, but who is the person that will generate the report or make it available to a central reporting service? Is this person available over the timeframe in which the report is needed? What if there aren’t available?
- How does the report allow the user to contribute to the overall success of the organization and its key strategic objectives?
- What is the actionable intelligence to which the user is going to act? What decisions are expected to be made with the information in the report? Will this lead to better business processes later? Will this lead to a need to revamp the way the organization collects data in the future? Will this lead to a new way of marketing and sales promotion?
Understanding the details of perceived, simple reporting requirements can lead the analysis down a path to ensuring a quality output is generated that meets not only the immediate need of the user but also to inspire the conversation to inquire about information the user may not have thought about, and perhaps yield insights into how peripheral processes, methods and actions are affected. This is the role of the business analyst.
Ask the deeper questions that come to mind during an analysis of the problem statement. You will not only continue to demonstrate the importance of the BA role, but inform the discussion between IT, stakeholder and you in a value-added way.
When it comes to data, Smoothcube understands the trials and tribulations when it comes to data analysis.
Smoothcube offers a course in data modelling for the business analyst, as it relates to the business intelligence domain. The principles of asking questions about data applies to the simplest of reporting requirements, not just BI.
To learn more about that course, please visit the BI page.
Innovate. Implement. Inspire.
Copyright © 2017.