A new ERP project should include a reporting strategy created as early in the process as possible. When it’s time to go live, you’ll know your business users have the data and tools they need.

We love new.

New clothes. New houses. New cars.

New gets the attention. New gets the buzz.

It’s no different with Enterprise Resource Planning (ERP) systems.

I’ve seen it many times during my twenty years of implementing Oracle, Peoplesoft, and SAP.

Companies get excited about improving business processes and saving money. To enjoy those benefits as soon as possible, they develop a singular focus on figuring out the best way to load data into the new system.

Eventually a brave soul will ask, “but what about reporting?” The standard answer is usually “it will come.”

Then the project goes live before any reporting work is done. The reporting team now must achieve miracles with meager resources. Business teams end up with a Frankenstein’s monster patchwork of legacy and new reports until the promised reports are developed.

What is reporting?

Reporting has matured and gone through several name changes since I started in 1997. Back then, there were limited options for reporting data from an ERP system. They required someone with knowledge of SQL (Structured Query Language) and relational databases.

One option to report data from an ERP system was to use SQL to extract raw data from the underlying database and put it in text files. Business users would then import this raw data into Excel or MS Access databases, enriching and transforming it into actionable insights.

Another option was to purchase SQL-based reporting tools like Crystal Reports or Impromptu, which produced retrospective, two-dimensional SQL reports.

We had to be careful when using these reporting approaches to provide real-time or near real-time results. We didn’t want to compromise database performance for other business users entering transactions into the system.

Nowadays, reporting has matured into distinctive types of reporting: operational reporting and analytical reporting.

Operational reporting supports day-to-day activities with live queries of targeted, granular data.

Analytical reporting facilitates strategic decision making. Analytical reporting might be referred to as business intelligence or reporting and analytics and runs the gamut from descriptive to predictive to prescriptive analytics and, in some cases, AI and machine learning (depending on the organization’s level of analytics maturity ).

Graphic showing reporting maturity levels.

 

Why having a Reporting Strategy Up Front is Key

Every business is unique and has its own KPIs for measuring business performance. Data is increasingly a business differentiator. It’s important to facilitate timely access to actionable and relevant data.

When rolling out a new ERP, it’s vital to design a reporting strategy as early as possible. When the big go-live day comes, you’ll want to ensure your business users have:

  • The data needed to measure business performance
  • The tools needed to visualize and interact with that data

Three Risks Caused By Not Having a Strategy

During the design phase, it’s critical to capture attributes needed to support reporting and analytics. There are three risks businesses incur if they don’t do this:

Unexpected development costs from adding these attributes later. Team members with the skills to customize the ERP system are often no longer available once the system has gone live.

Gaps in the data caused by making changes after go-live and being unable to retroactively update attributes. I’ve seen situations where there was a reluctance to “fix” the data in the ERP system and do it instead in the reporting tools. This led to differences between the system of record and the downstream reports, or multiple versions of the truth. A former colleague of mine always liked to say, “When the ERP system sneezes, reporting catches a cold.”

Running out of funds for reporting as the ERP system implementation winds down. As the project matures, focus and budgets can move from system design and configuration to user onboarding and training.

Avoid the Risks

If you represent an organization about to implement a new ERP system, you can avoid these risks. Consider adding the following steps to your planning:

  • Assess how mature your current reporting capabilities are
  • Document what reporting goals you have for the future
  • Research canned reports from the new system
  • Identify gaps where custom reports will be needed
  • Analyze your current reporting toolset
  • Decide what tools to retire or replace
  • Create a budget for your desired future reporting landscape
  • Embed reporting/analytics experts in requirements-gathering meetings

Parallel is Preferred

Gathering reporting requirements in parallel with other system requirements allows for report consumers to come prepared with questions while the ERP design is happening. This has a twofold advantage of allowing for assessment of what the ERP can provide for real-time reporting and where there might be gaps.

Rizing’s Star

Rizing STAR Methodology ensures that reporting and analytics requirements are assessed along the lifecycle of the project. The process curates a series of deliverables focused on reporting and analytics design.

The Methodology closely follows the phases of SAP’s Activate Methodology: Discover -> Prepare -> Explore -> Realize -> Deploy -> Run.

Reporting considerations start in the Discover phase and continue throughout the project.

During the Explore phase we capture operational and analytical reporting requirements. We partner with you to identify and activate the SAP Fiori apps that support your business’s operational reporting needs.

Architecture Document

To facilitate analytical reporting requirements gathering, we include a high-level architecture document that considers:

  • Report users and their locations
  • Report development models (IT creation, user creation, hybrid)
  • Security requirements
  • Data stores (EDW, Data Marts, Data Lakes, ODSs)
  • Integration methods (ETL/ELT, Table Replication, Service Calls, etc.)
  • Company standards

Metrics Library

The STAR methodology includes a metrics library that captures the measures, calculations, and Key Performance Indicators (KPIs) for your organization. After go-live, these deliverables become communications documents for the customer IT department for support.

Join the Dance

With Rizing, your reporting and analytics requirements aren’t wallflowers. They are given their proper place, out on the floor, in the spotlight.