Every rationalisation effort begins with the same sentence: we need a map. Six weeks later, a spreadsheet arrives. Two hundred rows, one application per row, columns for the vendor, the version, the number of users, the annual cost.
That spreadsheet is an inventory. It has its value — you cannot decide about what you do not know. But it enables no decision, because it says nothing about what matters: what breaks if you remove a row.
What an inventory does not tell you
An application has no cost in isolation. It has a cost, dependencies and a place in a chain. The inventory captures only the first:
- which business processes stop if it fails, and for how long
- which other applications call it, and by what means
- which data it holds itself, and which it copies from elsewhere
- who knows how to keep it running — and what happens the day that person leaves
Those four answers are what separate a list from a map. They are in no register: they are gathered from the people who use the tool every day.
The dependency you only see by cutting it
In most systems built up by accretion there is at least one link nobody can fully describe: an overnight export, a file dropped on a shared drive, a macro inherited from a machine that no longer exists. It works, so it is invisible.
The first merit of a serious map is making those links visible before a project breaks them. It is also the cheapest moment to deal with them.
An inventory tells you what you own. A map tells you what you risk by touching it.
The useful level of detail
The opposite mistake is trying to model everything. An exhaustive map is expensive, goes stale within months and stops being maintained the moment the supplier who produced it has gone.
The right level is the one that lets you decide: enough detail to keep, replace or retire an application, and no more. Which means knowing, before you start, which decisions you are preparing for.
What you then do with it
A map is not a deliverable, it is an instrument. It feeds the roadmap, it underpins the recovery plan, it makes the case the day a vendor announces end of support. Produced without those uses in mind, it ends up in a shared folder nobody opens.