Ask a management team to list the systems the business runs on and you will get eight to fifteen names. Ask the people doing the work how they actually get through a Tuesday and the real number is usually several times that. The gap is made of spreadsheets, shared documents, scripts, browser extensions, personal automations, a Access database from 2014, and one workbook that quietly calculates something important.
None of this is a discipline problem. Every one of those tools exists because somebody had a real job to do and the sanctioned systems did not do it. Approaching the exercise as an audit of rule-breaking is the reliable way to get an incomplete answer, because the tools that carry the most risk are precisely the ones people suspect they were not supposed to build.
How to actually find them
The single most important technique is to ask about work rather than about software. If you ask people to list the tools they use, they will list the applications with logos. They will not mention the workbook, because to them the workbook is not a tool. It is just how the job is done.
- 1
Walk a full cycle of the main workflows with the people who run them, from the order arriving to the money landing, and write down every place information is entered, copied, or checked.
- 2
Ask what they would do if a named system were unavailable this morning. The answer names the backups, the private trackers, and the offline fallbacks.
- 3
Ask what they do at month end and quarter end. Periodic work hides an enormous amount of undocumented tooling that never appears in a normal week.
- 4
Pull the expenditure records for software, including personal card reimbursements, and look at what is being renewed by individuals rather than by the company.
- 5
Review file shares and collaboration spaces for workbooks with macros, dated filenames, or many recent editors, and check the automation platforms already in use for flows nobody owns.
- 6
Ask engineering what runs on a schedule, and specifically what runs on a machine that is not managed infrastructure.
What to record for each one
Keep this short. An inventory that takes an hour per tool will not get finished, and the useful signal comes from a handful of fields.
- What it does, in one sentence, in the language of the business rather than of the technology.
- Who depends on it, and how often. One person monthly is a very different item from twelve people daily.
- What breaks if it stops, this week rather than eventually.
- Who can change it, and whether anyone else could work out how.
- What data is in it, specifically whether it holds personal, payment, or customer-identifying information.
- Whether it writes to another system, because a tool that only reads is a much smaller problem than one that posts entries.
That last field is the one most often skipped and most often decisive. A read-only reporting workbook being wrong produces a bad conversation. A tool that writes into the accounting system being wrong produces a restatement.
Ranking by real risk
The instinct is to rank by how bad the tool looks. That correlates poorly with risk. The right axes are what happens when it stops and how many people could put it back.
| Tier | Looks like | Action |
|---|---|---|
| Critical | Revenue or payroll stops within days. One person understands it. Rules exist nowhere else. | Address now. Document the rules, remove the single point of failure, get it into managed infrastructure. |
| High | A team is badly slowed. Holds sensitive data, or writes into a system of record. | Plan within the quarter. Usually ownership, access control, and backup rather than a rebuild. |
| Medium | Annoying to lose. Several people could reconstruct it. No sensitive data. | Record it and revisit. Consolidate opportunistically if you are already working nearby. |
| Low | One person's convenience. Nothing depends on it downstream. | Leave it alone. Formalizing this is pure cost. |
The tier that surprises people is Critical, because the items in it are usually quiet. Nobody complains about a tool that works. The spreadsheet everyone moans about is visible precisely because it is painful, and pain is not the same as risk.
Deciding what to do
There are only four reasonable outcomes per item, and the most common one is the last.
- Absorb it. The capability belongs in a system you already run, and the tool exists because that system is configured badly. Fixing the configuration is cheaper than any build.
- Formalize it. The tool is right but the ownership is not. Move it to managed infrastructure, give it a named owner, write down the rules, control access. This is usually days rather than months.
- Replace it. The tool has hit a real ceiling, several tools cover overlapping ground, or the rules inside it need to be testable. This is the only outcome that justifies a build.
- Leave it alone. It works, someone owns it, and nothing important depends on it. A large share of any healthy estate belongs here permanently.
It is worth being explicit that consolidation for its own sake is not a goal. An estate of forty small tools that each work, with clear ownership on the ones that matter, is a better position than one platform that half the business quietly works around.
Keeping it from happening again
Shadow IT regenerates, and it should. The objective is not prevention but visibility: making the sanctioned path fast enough that people use it, and making it safe to mention when they have not.
- Give people a supported way to build small tools, because banning it just moves the activity somewhere you cannot see.
- Make asking for a change to a core system fast enough to be worth doing. Most workarounds are a response to a slow queue rather than to a missing feature.
- Treat any tool crossing into Critical as a normal event that triggers ownership rather than a failure that triggers blame.
- Refresh the inventory annually, and always before a platform replacement, because the estate around a system tells you what that system is failing to do.
Common questions
- How long does an inventory take?
- Two to three weeks for a mid-sized operation, most of which is conversation rather than analysis. It is deliberately time-boxed: an inventory that aims for completeness never finishes, and one that captures the Critical and High tiers accurately has delivered nearly all the value.
- Should we ban shadow IT?
- No, and attempts to do it tend to make the risk worse rather than smaller. The tools do not stop being built, they stop being mentioned, which removes your visibility while leaving the dependency in place. Making it safe to declare a tool is worth considerably more than a policy prohibiting one.
- We found something critical that one person owns. What now?
- Remove the single point of failure before doing anything more ambitious. Get a copy into managed storage with backups, have that person walk someone else through it while recording what they say, and write down the rules it encodes. That is usually a few days and removes most of the exposure. Whether to rebuild it is a separate and much less urgent question.
- Is this something you do, or should we run it ourselves?
- Either works. Internal teams often do it well and cheaply, and the main risk is that people are more candid with an outsider about workarounds they think might get someone in trouble. If we run it, the output is a written inventory and ranked recommendations you own outright, structured so that hiring us for whatever follows is a choice rather than a consequence.
- How does this relate to replacing an ERP or core platform?
- It should come first. The tools built around a core system are the most reliable available evidence of what that system does not do, and that evidence is worth more than a requirements workshop because it reflects behaviour rather than opinion. Starting a replacement without it means specifying against what people say they need rather than what they have already built.