Plenty of business systems are still working. Far fewer are genuinely supported. The difference rarely shows up until the day someone leaves, an assumption stops holding, or a change needs making and nobody can say what it will break.
A supported system has three things behind it: someone who owns it, a rhythm of review that isn't triggered by a fault, and documentation written for the next person rather than the last one. An abandoned system can look identical from the outside, right up until it doesn't.
The warning signs are usually ordinary. A refresh fails and only one person knows where to restart it. A user asks for a change and nobody knows whether the request belongs with finance, operations or IT. A field remains in a form because removing it might break something, although nobody can explain what. The system still runs, but confidence in changing it has already disappeared.
A named owner, not a general sense of responsibility
"The team looks after it" is the most common answer, and it usually means nobody does. Ownership has to be specific enough that one person's name is attached to it, and formal enough that the time it takes is acknowledged rather than absorbed quietly around other work.
The owner does not need to perform every technical task. They need to keep the purpose, users, risks and priorities visible, and know who can make each kind of change. They should be able to answer whether the system is still fit for its job, what depends on it, and which issue needs attention next. A supplier can support the technology, but a supplier cannot own the business decision the system exists to support.
Ownership needs a handover, not just a name
Naming an owner without transferring knowledge creates a label rather than support. A proper handover covers the system's purpose, critical routines, access, suppliers, known defects, current workarounds and the decisions behind its design. It also gives the new owner enough time to test that they can use the documentation before the previous owner leaves.
This is especially important for spreadsheets, low-code applications and reports built inside operational teams. Their value often comes from close knowledge of the work, but that same closeness can leave key logic in one person's head. Treating those tools as business systems makes the dependency visible while there is still time to reduce it.
A maintenance rhythm that isn't triggered by failure
If the only time a system gets looked at is when something breaks, then every review is done under pressure, by whoever is available, with the narrowest possible scope. A short scheduled review, even quarterly, is what catches the workaround that quietly became permanent and the exception nobody needs any more.
The review does not need to become a committee. Check recent failures, access changes, manual workarounds, pending requests and whether the system still supports the process it was built for. Record the decisions and assign the next action. Regular attention keeps small maintenance work from becoming an emergency project.
Documentation written for the next person, not the last one
Most documentation, where it exists at all, describes what the system does. Useful documentation explains why it was built that way, what assumptions it depends on, and what would need to change if those assumptions stopped holding. That's the difference between a manual and an explanation.
Screenshots of buttons age quickly. Decision records age better. Document the source of important fields, the calculation behind key measures, the reason an approval exists, the expected failure response and the people who can grant access. The next person can discover where a button sits. They cannot reconstruct an old decision from the screen alone.
Support includes safe change
A system is not supported if the only safe instruction is "do not touch it." Useful support includes a way to test changes, check their effect and reverse them when necessary. The owner should know which reports, workflows or downstream files depend on the part being changed.
This does not require enterprise change control for every small tool. It requires proportionate discipline: a backup, a test case, a record of what changed and someone who confirms the result. Without those basics, every improvement request carries enough uncertainty to be postponed.
What it costs when these are missing
None of this is abstract risk. Every workaround has a real cost, even when nobody calculates it: time spent doing something manually because the underlying problem was never fixed, multiplied across everyone who does it, every time they do it. That cost sits invisible in most budgets because no single instance of a workaround shows up as a line item anywhere.
The bigger cost shows up later: the system that "only makes sense if you ask the one person who built it," when that person is no longer available to ask. What should be a routine change becomes a multi-week investigation, because nobody can say with confidence what a change will break.
What good support actually looks like day to day
It's genuinely unglamorous. A named owner who reviews the system on a schedule, not just when it breaks. A short log of "why we did it this way" for the decisions that would otherwise get relitigated every time someone new joins. A habit of asking, periodically, whether a workaround that made sense two years ago is still the best available option, or has just become invisible through repetition.
None of that requires new software. It requires deciding that support is a genuine, ongoing responsibility, not a byproduct of whoever happens to still be around when something breaks. That is the heart of our systems support work, and the reason we treat ownership as a data and systems architecture question rather than an IT ticket.
What to check this week
| Question | If the answer is concerning |
|---|---|
| Can you name, in a few seconds, who owns this system? | Assign clear ownership before anything else |
| Has anyone reviewed it in the last six months without something being broken? | Build a maintenance rhythm, even a light one |
| Could a new person understand why it's built this way, not just what it does? | Start documenting the “why,” not just the “what” |
Where to go next
This week's tool, the System Support Health Check, walks through these three checks for one key system in about ten minutes. If the result concerns you, that's the useful outcome. Better to find out on a quiet Tuesday than the week someone hands in their notice. If you'd like a second opinion on what you find, get in touch.