You run the duplication analysis over your capability-to-application mapping. Fourteen capabilities have three or more applications mapped to them. You take the worst one to the owning executive and she says the three systems do completely different things. You check two more with their owners and get the same answer. The mapping was built by the application owners themselves and you have no reason to think they lied. What is going on, and what would you look at first?

The first three things I would look at, and why in that order

1. The decomposition level of the flagged capabilities, compared with the level at which an investment decision is actually made. This is first because it is the cheapest check and it explains the pattern. Read the fourteen names aloud: if they sound like "Customer Communications", "Reporting" or "Payments", they are category headings, not capabilities.
2. Whether the three applications under one flag share a data entity, or only share a verb. Three systems that all "communicate with customers" - transactional email, marketing campaigns, statutory notices - share a verb and share nothing else: different data, different owners, different regulators, different failure consequences.
3. Whether the duplication claim survives a shared-user test. Do the same people use two of these systems to do the same job? If no two user populations overlap, there is no consolidation case regardless of what the map says.

The diagnosis

The mapping is correct and the analysis is wrong, because the unit of analysis is wrong. Duplication is a property of a capability at the level where work is actually done. Applied to a level-1 or level-2 heading, "three or more applications mapped" is close to a tautology - broad headings attract many systems by construction, and the count measures the breadth of the label rather than redundancy in the estate. In a 180-application estate mapped to a 40-box level-2 model, the average capability carries 4 or 5 applications before any duplication exists at all, so a threshold of three flags well over 30% of the model on arithmetic alone.

The executive is not being defensive. She is reading the systems at the level she manages them and you are reading them at the level the map happens to be drawn. Both descriptions are accurate.

The misleading signal and why it misleads

"The owners built the mapping themselves." It pulls you towards a data-quality investigation - inconsistent interpretation, people mapping to whatever box looked closest, self-reporting bias. That investigation will find some genuine noise, consume a month of two analysts' time, and leave the fourteen flags exactly where they were, because the data is not the problem. Self-mapping is in fact the right way to build the mapping; it is the thing you would keep. The cost of chasing it is not only the month - it is the credibility spent on three executive meetings that ended with you being corrected.

The second misleading signal is the count itself. Three applications to one capability feels like a finding because it has a number attached. A number derived from the wrong grain is still the wrong answer.

The fix

Raise the bar for what counts as a duplication claim. Three conditions, all of which must hold:

• A shared data entity both systems create or master in production - not merely reference.
• A shared user population doing the same job in both.
• A shared trigger - the same business event causes work in both.

One condition is a coincidence. Two is worth a conversation. Three is a consolidation case you can take to a CFO without being corrected in the room. Applied to the fourteen flags, this typically leaves two or three, and those two or three are real.

Then fix the instrument: do the duplication analysis only at the decomposition level where capabilities have a single accountable owner, which in most organisations is level 3. Above that, the map is for orientation and funding conversations and should not be joined to the application inventory at all.

The alert that would have caught it earlier

Not an alert on duplication - an alert on the map. A capability with more than a handful of applications mapped to it is a signal to check its decomposition, not to open a consolidation case. Had that check run before the executive meeting, the fourteen flags would have been read as fourteen capabilities drawn too broadly, which is a map defect with a cheap fix.

When this is the wrong answer

When the three systems genuinely are the same thing. Three notification services built by three teams because the shared one was hard to adopt will pass all three tests, and then the granularity explanation is an excuse for inaction. Choose the granularity explanation only when at least one of the three tests fails; if all three hold, the map is fine and the estate is not. Run the tests honestly - they are designed to let real duplication through. And if real duplication is what you find, the next question is not how to consolidate but why the shared option was harder to adopt than to rebuild - because consolidating without answering that produces the same three systems again in four years.