Loading
Process mapping · Integration · Automation · Modernisation
Nothing here involves a workshop about culture. It involves finding the eleven manual handoffs that cost you a week each month, and removing them in an order that does not stop the business while you do it.
The problem
The phrase has been ruined by consultancies selling a slide deck, so it is worth saying what the work actually consists of. A business that has been running for fifteen years accumulates a set of processes that made sense when they were designed and now exist because they exist. A form that gets printed, signed, scanned and emailed. A number re-typed from one screen to another because the two systems were bought four years apart. An approval that waits three days for a person who approves everything anyway.
None of that is a technology problem in isolation. It becomes one because the workarounds are load-bearing: the business genuinely depends on the spreadsheet, and the person who maintains it has never been asked to document it. Remove it carelessly and something stops.
It is also rarely one project. It is a sequence of changes, each of which has to be introduced while the operation continues to run, which is the constraint that makes this different from building a new system for a new process. There is no greenfield here and there is no acceptable pause.
The other reason these programmes fail is adoption. A better system that people work around has not replaced anything, it has added a system. If the people doing the work were not involved in shaping it, they will keep the spreadsheet, and they will usually be right to.
What is included
7 areas of work. Most engagements start with one or two and widen once the first release is in use.
Sitting with the people doing the work and documenting what actually happens, including the workarounds nobody put in a manual. Volumes, handoffs, rework rates and where the process waits, written down as evidence rather than opinion.
Connecting the ERP, CRM, accounting package, spreadsheets and shop-floor systems that currently exchange data through people. Master data ownership decided per field, so there is one authoritative answer to what a customer's credit limit is.
Approval routing, document generation, data re-entry, scheduled reconciliation and notification chains. Rules-based automation where the logic is deterministic, and AI only where the input is genuinely unstructured and a rules engine would fail.
An assessment per system rather than a blanket policy. Wrap a stable system behind an API and leave it alone, replatform where the code is sound and the environment is not, rewrite only where the business rules have changed beyond what the system can express.
What has to move, what should stay, and what must be replaced before either. Network, identity, backup and access control brought to a state where new systems can be deployed and supported without an ageing server in a cupboard being a single point of failure.
Involving the operators in design so the new process fits how the work is really done, training on the real system with their own data, a named internal owner per process, and a support path for the first weeks when the questions are constant.
Baselines captured before anything changes, because otherwise improvement is a matter of opinion. Cycle time, rework rate, manual touches per transaction and time to close the month, measured the same way before and after.
How we work
Phase one is assessment and it is deliberately short. Two to four weeks mapping the current state with the people who operate it, quantifying where time and rework actually go, and producing a ranked list of changes with the effort and the disruption of each one stated. You get a plan you could hand to someone else, which is the test of whether it is a real plan.
Then we sequence by payback and risk rather than by ambition. The first change is usually something small, visible and low risk, because a programme that delivers nothing for two quarters loses the goodwill it needs for the harder changes later. Each phase is scoped to be independently useful, so stopping after phase two leaves you better off rather than half-migrated.
Old and new run in parallel wherever the process allows, with reconciliation between them until the new path is trusted. Training happens with the actual team on the actual system before cutover, and we measure adoption afterwards, because a rollout that is technically complete and behaviourally ignored is not finished.
In practice
Phase one is assessment and it is deliberately short. Two to four weeks mapping the current state with the people who operate it, quantifying where time and rework actually go, and producing a ranked list of changes with the effort and the disruption of each one stated. You get a plan you could hand to someone else, which is the test of whether it is a real plan.
Where it comes up
Stack
We pick from a stack we actually run in production. Where your team already has a preference and it is a reasonable fit, we work in yours instead of arguing for ours.
Sector context
Domain knowledge shortens discovery. These are the sectors where we already understand the vocabulary and the failure modes, so the first version of the build is closer to right.
Shift-based production data, downtime causes, quality records and the daily gap between what the ERP holds and what the floor actually did.
Lot and parcel movement, job-work with karigars, grading records and the reconciliation that follows a stone through five pairs of hands.
Appointments, records, billing and reporting, where patient data handling and clinical workflow set the constraints before anything is designed.
We have not published a case study for this service yet. When we do, it will name the client with written permission and quote numbers the client can defend. Nothing else is worth reading.
Until then, the useful version of proof is a conversation about your problem. Ask us how we would approach it, what we would refuse to do, and where the estimate is soft.
Ask about comparable workQuestions
With the process that costs the most time and carries the least risk to change. That combination matters: starting with the highest-value and highest-risk process is how programmes stall in month three. A short assessment identifies both dimensions, and the first phase is normally something visible enough that people believe the rest will happen.
Some disruption is unavoidable and the plan is built to keep it contained and scheduled. Parallel running means the existing process continues while the new one is proven. Cutovers happen at low-volume times with a rehearsed rollback. The disruption people actually feel is mostly the learning period, which is why training uses real data on the real system before go-live rather than a demo afterwards.
Usually not, and replacing one is among the most expensive and risky things a mid-sized business can undertake. Most of the pain attributed to an ERP comes from processes it was never configured for and from the absence of integration around it. Building the missing pieces alongside it and connecting them properly is often a fraction of the cost of replacement, and we would rather establish that first than sell the larger project.
By taking the resistance seriously, because it is usually informed. People who have used a system for years know where it fails and have often been ignored before. Involving them in the mapping phase produces a better design and removes most of the opposition. Where resistance persists after a genuinely better process, it is a management question rather than a technical one, and we will say so instead of pretending software solves it.
The constraint is that the business is already running. A software project starts from a blank state and a defined scope; this starts from a live operation, undocumented rules, real people with existing habits, and a requirement that nothing stops. Much of the work is sequencing, reconciliation and adoption rather than construction. The code is often the smaller half.
Works well with
Send a paragraph about what is not working today. You will get a written reply from someone who would be on the build, covering how we would approach it, roughly what a first phase looks like, and whether digital transformation is even the right place to spend the budget.
What happens next
