Usually, BI/Reporting is considered as an afterthought in ERP implementations. However, this is one of the most important outcomes of the project. Executives will be looking for reports to run their business.
Oftentimes, the business asks, "Where is my report"? And the answer that they get is, "Data is there…". That's not enough; you need to deliver reports or information in a form that the business can use. It's not uncommon to hear business leaders complain, "We are flying blind" due to the lack of reports or accuracy of reports. With cut-throat competition against low-margin businesses, it's important to have real-time visibility of the business for the respective business owners to react quickly in the changing business environment.
In this chapter, we will cover the following topics:
- Gathering BI and reporting requirements
- The many reporting tools available
- Mapping reports and identifying gaps
- Custom report development
It is important to start working on reports and the BI stream early on, along with the rest of the functional areas. Most of the time, reporting is not addressed as part of the analysis state. However, one of the most important goals of a new ERP implementation is to get better and real-time visibility into the business.
To start this process, work with the business to compile a list of reports—dashboards, kpis, operational reports—that are currently used to run the business. Document their use and the actions that are driven by those reports. Also, spend time to learn about the vision of the business leaders and the information that they would like to see, which they don't have currently. A combination of the current and future states would help you define the BI/reporting road map.
When gathering and documenting reporting requirements, make sure you ask the business users the following questions so that you can evaluate the need and be prepared to offer alternate solutions. Most of the time in projects, business users want to see all the reports that they have in their old system in the same format:
- Who's using the report?
- Be mindful of your customer's needs.
- Focus on the end-user experience. The audience would drive your delivery methods.
- What information is needed?
- Avoid information overload
- Find the right balance
- What actions are driven by this report?
- Engage them with interactive solutions
- Use reports to help drive navigation
- Is this report even necessary in the new system?
- Can we consolidate the multiple reports?
As part of requirement gathering, collect report samples that are used in the current system as well as manually generated reports. This will help in mapping standard AX reports and in identifying the gaps.
All the reports identified should be documented and categorized with the report name, the type of report, whether the report is internal or an externally used report, and how the report will be supported in AX. Remember, "No longer needed with the new system" is viable and, often, the preferred solution! The Sure Step Gap/Fit spreadsheet can be used to help document the reports just as with the other requirements.
Pay extra attention to mapping each column and formatting external-facing reports, such as invoice templates, customer statement, extracts going to banks, and so on. Invoice templates may show different information based on the product lines, customers, and so on.
The following table shows the categorization of sample reports based on their use and importance:
|
Type of report |
Sub type |
Examples |
|---|---|---|
|
Operational |
External |
Purchase order Sales packing slip Sales invoice AP check printing |
|
Internal |
GL trial balance Segment P&L Open purchase orders Purchase receiving log Vendor payment history Shipped not invoiced Accrued Purchases | |
|
Statutory and financial reports |
Balance sheet P&L Tax payable 1099 | |
|
Financial consolidation |
Consolidated financial statements | |
|
Analytics |
Internal/Management Reporting |
Financial KPIs Sales by Region Spend by legal entity Budget versus actual P&L customer, product line Trend analysis |
When working on report requirements, it is important to understand the common complaints or issues that business users face. Collect information early on to address these pain points.
Work with the business users on the calculations and logic needed on the reports and document them. Come up with scenarios and examples to explain the business logic and formulas in the requirement document. Many times, these issues would help in identifying the gaps in the overall design. For example, say the users want to see the financial values/costs by batch number in a manufacturing environment. However, if you are not set up to track financial postings by the batch number dimension, you won't have the data to build the report.
Understand how frequently the reports will be used and the acceptable runtime. Gather information regarding the common filter parameters that need to be added to the report. This also ties back to the volume of data that would have to be processed to generate the report. For example, if you are building a monthly commission report, it needs to consider the volume of sales orders during that month, including returns and the calculations involved in calculating the commissions.