Reporting — Building the same reports more than once

This is the tenth article in the series "Inside a Large ERP Program." Earlier chapters followed the program through build, testing, authorizations, and the data migration everyone underestimates. Reporting works the same way, except the bill arrives not once but several times, because it's the workstream most exposed to rework.

The more methodology you put in up front, the less you rebuild. That's true everywhere on a program, but reporting is where it shows most brutally. It's the workstream where missing groundwork doesn't fail quietly. It gets paid back in reconstructions, the same reports built a second time, a third time, because the first versions rested on something that hadn't stopped moving. Reporting is the workstream of rework, and most of that rework was avoidable.

This chapter is about the three reasons the same reports get built twice, at least, and what stops each one.

Greenfield and brownfield: two different traps

The shape of the problem depends on the kind of program. On a brownfield conversion, you carry the old reporting technology across. That means little rework and little risk of business regression, because the reports the business knows keep working. The trap there is performance: moving to S/4HANA, some of what used to be physical tables now sits behind views, and a report that ran fast on the old system can run slow on the new one. It's a performance watch, not a rebuild problem.

Greenfield is where the rebuild problem lives. You're not carrying anything across. You're changing the reporting technology, depending on data that's still being migrated, and absorbing a functional redesign whose rules are still moving, all at once. Three sources of instability stacked under one workstream. That's the program this chapter is about, and the rest of it follows the three reasons the reports get built more than once.

Reason one: a technology chosen too new

Reporting is the workstream where the technology moves fastest. Every year SAP and the surrounding vendors ship something new, and not all of it is mature. Pick the newest option for a greenfield build and you take on two risks at once: you become the one who works out the bugs on a solution that isn't reliable yet, or you watch that technology fade for lack of adoption and find yourself migrating a brand-new solution again within two or three years. The safer bet is a technology launched three to five years ago that has been widely adopted. Mature enough that the bugs are known, adopted enough that it isn't going to disappear under you.

Choosing between the options is easier with a clear decision matrix than with a vendor pitch. The dimensions that actually drive the choice are a handful. Is the reporting operational, close to the live transaction, or strategic, looking across history? Does it draw on one system or several? Does it need real-time data or a consolidated snapshot? And do you have the skills in-house to run the tool you pick? Mapping the main SAP options against those dimensions, as of mid-2026 and with the caveat that this landscape shifts fast:

Technology	Best for	Data scope	Latency	Skill barrier
Embedded analytics (CDS views)	Operational reporting, close to the process	Single system, live S/4HANA	Real-time	Low — accessible to business teams
SAP Analytics Cloud (SAC)	Dashboards, planning, visualization on top	Single or blended, via CDS/InA	Real-time (live connection)	Low to medium
BW/4HANA or Datasphere	Strategic reporting, history, consolidation	Multi-system, plus external data	Snapshot / consolidated	High — ABAP and data-warehouse modeling

A few things the table can't carry on its own. According to SAP's own integration guidance, the recommended data source precedence is ABAP CDS views first, then ODP extractors, then raw tables, and released CDS views are the recommendation because they stay stable across upgrades. SAC's live connections are only as good as the CDS views underneath them: SAP-aligned analysis is blunt that when the data foundation is messy, SAC surfaces the mess to users, so investing in CDS quality before building dashboards pays off downstream. And embedded analytics is included in the standard S/4HANA license, where BW/4HANA and Datasphere are separate builds with their own cost and skill demands.

To illustrate how continually this technology moves, one date worth holding in view when you weigh whether a tool is near end of life: the mainstream maintenance for the older BW 7.5 is reported to end in December 2027, which is exactly the kind of horizon that turns a chosen tool into a forced migration.

Once you know this matrix and use it, it isn't the hard part. The hard part is that even the right technology gets rebuilt if you report the wrong data too early.

Reason two: a build started on moving data

This is the same planning clash that runs through the authorization stream. You cannot test whether a report is reliable when the transactional flows and the business rules feeding it are still moving, and you certainly cannot when you aren't even sure the migrated data you're displaying is correct. A report built on that ground isn't a report yet. It's a draft that looks finished, and it gets redone once the ground settles.

The reports that suffer most are the big aggregates, the P&L-type statements that pull from everything. They're the most fragile precisely because they depend on the entire upstream being stable, every flow, every rule, every migrated balance. Build one of those early and you're almost guaranteed to build it again. The discipline here is to lower expectations on the big numbers at the start, and to sequence their construction after the upstream has stabilized rather than racing to show an aggregate that can't yet be trusted.

This is where change management and proper communication matter. You know how finance people work: they want the perfect report, and they want it now, or they'll raise their hand to stop the go-live. The pedagogy matters as much as the technology here. You have to reassure them, and help them accept an unfinished report, or fewer reports, for a short period. That conversation is far easier had early than discovered at the go/no-go.

That holds for any single report. The next reason is about what happens across all of them at once.

Reason three: no common foundation

The instinct, under deadline pressure, is for each report owner to charge ahead and build their own report in isolation. It feels faster. It isn't. When everyone builds alone, the same business logic gets recoded report by report, a margin definition here, a cost allocation there, each one slightly its own. Then a rule changes, as rules do all through a greenfield build, and the change has to be made in every report that encoded it. The rework multiplies by the number of reports.

The alternative is to take the time to build a common catalog of CDS views first, shared across all the reports that need the same logic. When the rule changes, you change it in one place. Released CDS views are stable across upgrades, which is what makes the catalog worth treating as an asset rather than scaffolding. It's slower to start and far faster across the life of the program, and it's the single most effective thing a reporting stream can do to stop building the same thing twice.

Concretely, how do you do it? It's easier than it sounds. Once the final list of reports for go-live is settled, you build all the mock-ups, and before coding anything, you sit down with the consultant to define the CDS views behind each one. That's where you see the common patterns, the views that can be shared across several reports. It won't be perfect, and the catalog will be amended over time, but you start on solid ground rather than on a pile of one-off reports.

Knowing what to mutualize depends on knowing what the reports are and which ones matter, which is where the organization comes in.

Define early, build late: the sequencing the business owns

There's a subtle move here that's easy to get wrong in both directions. The business has to define its reporting need as early as possible, not so the reports can be built early, but so the common CDS views and the technology choice can be shaped around real requirements rather than guesses. The need is the input to the foundation.

But defining early is not building early. Once the need is on the table, the next move is to rank it, and the ranking deserves a matrix of its own rather than a gut feel about what's urgent. Four tiers cover most cases:

Tier	What it covers	Timing
Statutory	Legal and regulatory reporting you cannot operate without	Required at go-live
Business critical	What's needed to invoice and keep the business running	Required at go-live
Important	Reporting the business relies on but can wait a few weeks	Shortly after go-live
Nice to have	Analysis that improves decisions but isn't load-bearing	When the foundation allows

The first two tiers are the go-live scope, the handful of reports genuinely required to operate on day one. The rest come afterward, in order. This is what reconciles the two pulls that otherwise look contradictory: you define the need early to get the foundation right, and you produce the reports late and ranked, so you're never building on data that hasn't settled. Early definition, late and prioritized production. The business owns both halves, and when it owns neither, reporting inherits all the downstream instability and gets built in a post-go-live scramble.

What to take from this

Reporting is the workstream most exposed to rework, which makes it the one that most rewards discipline in sequencing. The three reasons the reports get built twice come down to one principle: stabilize the foundation before you produce the reports. A mature technology rather than the newest one, a build that waits for the data to settle, and a common CDS catalog rather than a scramble of isolated reports. Define the need early to shape that foundation, then build late and in order of priority.

This chapter showed, with the finance population especially, that change management can be the deciding factor. It prepares the business process owners and key users first, so they can steer a greenfield program properly, and then the end users, so they adopt the new solution quickly. That's what the next chapter explores in detail: Change — Preparing the business.