The
first article in this two-part series opened with a scenario of a quarterly business review that goes sideways in the first five minutes.The article illustrated three teams, with three different engagement numbers, and a meeting that never gets past arguing whose figure is right.
That situation isn’t rare. It’s the default state of a lot of pharma commercial organizations, and it doesn’t happen because anyone is careless.
It happens because reporting overload isn’t one problem. It’s four, and they compound.
Naming it as "too many dashboards" points you at the wrong fix. Retiring old reports helps for a quarter, then the estate grows back, because the forces that built it in the first place are still running underneath.
That
opening piece named those four forces in a single paragraph: business-led proliferation, KPI fragmentation, technology-led duplication and governance gaps. This piece is where each one gets unpacked, one at a time, before we get to what actually stops them from reinforcing each other.
Force 1: Business-Led Proliferation
Every new brand, market or function arrives with its own reporting need, and building something new is almost always faster than finding, understanding and adapting a report that already exists.
A brand launch is the clearest example. Under launch pressure, the team building performance tracking rarely has time to check whether an existing report could flex to fit, so a new one gets built. A year later, that launch report is often still running unchanged, long after the commercial model it tracked has matured into something the standard suite could handle.
Market entries follow the same pattern from a different angle. Global reports are built to a global standard, but local markets have local realities: different payer structures, different competitive dynamics, different naming conventions for the same product family. Rather than requesting a variant through a shared process, a market team builds its own version, and a single global metric can quietly end up with a dozen local implementations within a few years.
Each of these decisions is reasonable in isolation. None of them comes paired with a decision about what gets retired, which is exactly why the estate only ever grows.
Force 2: KPI Fragmentation
Even when the report count is under control, the numbers inside those reports can still disagree, because the same metric gets defined differently by whoever builds the next report that uses it.
HCP engagement is the clearest example. One team counts every logged interaction. Another can only see completed calls, so that becomes their definition by necessity. A third measures engagement against a target. Each definition is technically valid, and each team built it independently, with no shared process requiring them to coordinate.
The disagreement doesn’t always start at the definition. Sometimes two teams agree on what a metric means and still diverge on how it’s calculated: one refreshes weekly, another monthly, so the numbers never land on the same date; one rolls up to the territory level, another to the account level. These mismatches are harder to spot than an outright definitional fight, and they erode trust just as effectively over time.
The result is a leadership team that can’t agree on what happened, before they’ve even discussed what to do about it. That’s a more expensive problem than a redundant dashboard: a fragmented KPI costs decision-making time, while a duplicate report mostly just costs maintenance effort.
Force 3: Technology-Led Duplication
Reports also get rebuilt because of the tools underneath them. The business need driving a report and the platform it gets built on are two separate decisions, and the second one goes wrong just as often as the first.
A migration to a new BI platform gets declared complete once most teams have moved over, but the teams left behind, often the ones with the most customized reports, keep running the old platform indefinitely, because migrating their reports is the hardest and most expensive part of the project.
Spreadsheets tell a similar story. A tracker one analyst builds for a single question is often the fastest tool available, until it gets shared. Then it quietly becomes an unofficial second version of a report that already exists elsewhere, refreshed by hand and understood only by the person who built it. In organizations that grew through acquisition or rapid expansion, different teams sometimes chose different BI platforms independently, long before anyone set an enterprise standard, and both platforms simply stay in use once one finally gets picked.
Neither choice looks unreasonable from inside the team that made it. The organization still ends up paying for the same reporting capability more than once, in licensing, in maintenance and in the analyst time needed to keep every version current.
Force 4: Governance Gaps
The fourth force is why the first three don’t self-correct. Most reports have a builder. Few have an owner in the sense that matters: someone accountable for confirming, on a regular cycle, that a report’s definitions, data sources and audience still make sense.
Without that role, a report’s survival depends on inertia, not on an active decision that it still earns its place. The gap runs in both directions. There’s usually no structured check on a new report before it gets built, so proliferation happens unchecked, and there’s usually no structured question asked of an existing report either, so nothing ever gets retired. A local team can introduce its own definition of a standard metric without it passing through any review, simply because there’s no mechanism requiring anyone to check.
Fixing the other three forces without fixing this one is temporary. A rationalized set of reports and standardized KPIs will drift back toward sprawl within a year or two if nobody owns keeping it that way.
Why These Four Forces Compound
None of these forces operates alone. A launch report becomes the template a new market copies. A spreadsheet tracker becomes the version a new function inherits. An informally defined KPI becomes the default everywhere it gets reused. Because no one owns the decision to intervene, they run unchecked until the estate looks like the meeting that opened this series, whether that takes a few years at a large pharma organization or a few months at a smaller one.
Fixing one force, or fixing them one at a time, gets undone by the ones still running underneath. Closing the gap means making reuse the default, certifying KPI definitions, setting a hard cutover date for every migration, and naming an owner for every report the moment it's built.
The ProcDNA Perspective
Fixing reporting sprawl one symptom at a time rarely works, because the four forces behind it don't operate in silos. ProcDNA works with commercial analytics and planning teams to build reuse into the moments where proliferation usually starts: launch planning, market entry and reorganization. It works with data science teams to trace how core metrics are actually being calculated across an organization's reports, often the first time anyone has mapped it end to end, and to agree on a single certified definition each team can reference going forward. And it works with technology and managed services teams on the harder, last-mile parts of platform consolidation that earlier migrations left unfinished.
Naming these four forces doesn't fix them, but it does tell you where to look, and why no single tool, cleanup project or retired dashboard was ever going to be enough on its own. The organizations that get ahead of reporting sprawl don't chase it force by force. They put one structure in place that catches all four at once and keeps catching them after the first cleanup is done: a smaller, better-governed reporting estate that leaders can trust without checking twice.
That structure, and what it produced for one pharma organization that put it to work, is what our companion playbook lays out in full.
Want the full framework and the results behind it? Speak to our experts now.
,Suraj Gupta
