Digitisation
Most digitisation projects fail at the process, not the platform
The instinct is to start with the tool. Pick the platform, buy the licences, then work out what to build on it. It feels like progress because something has been decided.
What we see far more often is a process nobody has actually written down. Three departments each hold a piece of it, the exceptions live in one person’s head, and the approval that takes four days takes four days for a reason nobody can name. Put a platform on top of that and you get the same process, now with a login screen.
So we map the process before choosing anything - who touches it, where it waits, and what happens when it goes wrong. It is slower to start and it is the only reason the thing works two years later.
AI adoption
AI that cannot show its source will not be trusted twice
The first wrong answer is survivable. What is not survivable is a wrong answer nobody can trace - because from then on every correct answer gets checked by hand, and the system has cost more time than it saved.
This is why we ground assistants in approved content only, and why the source is part of the answer rather than a feature we add later. The point is not that the model sounds confident. The point is that someone can verify it in ten seconds.
Data & reporting
A dashboard nobody opens is not a reporting problem
When a dashboard goes unused, the usual response is to redesign it. More charts, better colours, a mobile view. It rarely helps.
A dashboard gets opened when it answers a question someone is already being asked. If the plant head is asked every Monday why three orders slipped, a view that shows planned against actual by phase gets opened every Monday. If nobody is being asked anything, no amount of design will create the habit.
Start from the meeting, not the data. Find out what gets asked, and who has to answer it.
Digitisation
Excel is not the enemy. Unowned Excel is.
Every proposal to replace a spreadsheet should start by admitting why the spreadsheet won. It was available on a Tuesday, it did exactly what one person needed, and it did not require anyone’s approval. That is a hard product to beat.
The problem is never the file. It is the fifth copy of the file, the version somebody emailed out, and the fact that the person who built the formulas has left. What replaces it has to be as fast to change as the spreadsheet was, or people will quietly go back.
Delivery
The system that survives is the one built around how the work already happens
There is a version of every project where the software is correct and the rollout still fails, because the design assumed a process the business does not actually follow. The exceptions were treated as edge cases. They were not edge cases; they were most Fridays.
We would rather find that in week two than at handover. It is why the uncomfortable questions come early, and why we build in phases you can look at rather than describing them in a document you have to imagine.
Modernization
Modernization is not a rewrite
The proposal to rebuild a working system from scratch is usually a proposal to spend eighteen months reproducing behaviour nobody documented, in order to arrive back where you started.
Most of the value sits in a much smaller set of moves: getting it somewhere it can scale, putting an API in front of it so other systems can reach it, and modernising the parts people actually touch. The rest can keep running until there is a business reason to change it - not a technical one.
Digitisation
Approval chains are where the time actually goes
Ask where a process is slow and you will usually be pointed at the work. Measure it, and the work is rarely the problem. The waiting is.
A quotation takes an hour to prepare and four days to approve. A gate pass takes two minutes to write and sits on a desk until someone comes back from the plant. Automating the hour saves an hour. Fixing the four days is the project.
