What we actually find in an operations assessment

Data entered more than once

It shows up in almost every business. The same customer information typed into a quote, then an invoice, then a scheduling tool, then a spreadsheet somebody keeps for reporting. Four entries of one fact.

Each retype is a chance to introduce an error, and every downstream report inherits it. Worse, the copies drift, so when two systems disagree there is no principled way to decide which is right.

Nobody designed this. It accumulated, one reasonable decision at a time, as the business grew faster than the systems connecting it.

Knowledge that lives in one person

There is usually one person who knows how the exceptions work. Which client needs a call before arrival, which job type always takes longer than quoted, which supplier will accept a late order. None of it is written down, because they have always been there.

This is an operational risk long before it is a software problem. It surfaces the first time that person takes a holiday, and it becomes acute the day they leave.

They are usually very good at their job, which is part of the trap. Because they handle it well, nobody has ever needed to formalise it, so the dependency deepens quietly.

Reports nobody trusts

When two systems disagree about a number, people stop believing either and revert to instinct. Once that happens, the reporting infrastructure is a cost with no benefit, because decisions are being made without it.

The root cause is almost never a bug. It is that both systems are correct according to their own definitions, and nobody has decided which definition is the company one.

Fixing that is a business decision rather than an engineering one, and restoring trust in the numbers is often worth more than any single automation on the roadmap.

Software paid for and not used

Licensed modules sitting unconfigured turn up in most assessments. Something was bought to solve a specific problem, configured narrowly, and renewed annually by somebody comparing this year invoice to last year.

Meanwhile the vendor ships features into your tier and nobody is assigned to notice. It is a process gap, not negligence, and it stays open indefinitely because no role owns it.

It is also the cheapest finding to act on, which makes it a good early win in any programme.

The number that justified the project is usually wrong

Most businesses arrive with a figure attached to the problem. Lost revenue from missed calls, hours lost to paperwork, deals lost to slow response. That number is what got the budget approved.

It is very often derived from a report that cannot distinguish between similar-looking events. Unanswered calls that were immediately called back get counted as lost customers. Time spent on paperwork gets estimated from how long the work feels.

Testing that number against actual records is frequently the highest-value thing an assessment does, because it either confirms the plan or redirects the budget before it is spent.

Work that should not exist at all

Every operation carries vestigial processes. A report produced for a decision nobody makes anymore. A form completed for a person who left. An approval step added after an incident a decade ago.

These survive because stopping requires someone to take responsibility for stopping, and continuing requires nothing. So they continue.

Deleting a process is the highest return available, and it is the one thing no vendor will ever recommend, because there is nothing to sell attached to it.