Automating a broken process does not fix it. It produces the same defect, faster, at greater scale, and with the appearance of progress.
Tech enabled business process engineering · Process improvement
Ensures end to end processes are optimised to benefit from various technology interventions
The most expensive decision in an enterprise systems programme is usually taken quietly, early, and by nobody in particular: the choice to configure the new system around how work is done today. It feels pragmatic. It avoids an argument. It also guarantees that a decade of accumulated workaround is carried forward into a platform that will now be very difficult to change.
Process work therefore belongs ahead of configuration, not alongside it. Not a full re-engineering exercise on every process — that is rarely proportionate — but a deliberate decision, process by process, on what should be standardised, what should be genuinely redesigned, what should be automated and what should simply stop.
Processes are almost always measured within functions and fail between them. Order to cash is owned by nobody; sales, credit, fulfilment and finance each optimise their own segment, and the cumulative cycle time is longer than any participant believes. Measuring the whole chain, once, usually settles more argument than any workshop.
Where automation is the answer, the candidate has to earn it: high volume, stable rules, clean inputs. Where those conditions are absent, automation adds a second system to maintain and leaves the underlying defect untouched.
The full chain across functions — order to cash, procure to pay, record to report, plan to produce — measured as a whole rather than in segments.
Cycle time, touch count, rework rate and exception volume, established from data before opinion is invited.
Deciding which variants are genuinely required by market or regulation and which are simply historical, before configuration locks them in.
Rebuilding the process around the outcome rather than the org chart, with handoffs removed rather than digitised.
Testing each candidate against volume, rule stability and input quality — and declining the ones that fail.
Controls designed into the process rather than inspected after it, including segregation of duties that survives the new system.
Where work re-enters the process and why. Exceptions are usually a design signal rather than a training problem.
Where a process should sit — retained, shared, outsourced — and what each option demands of the organisation.
Measures that survive contact with the business, reported at a cadence that allows correction rather than commentary.
Typically six to twelve weeks per process domain, sequenced ahead of system configuration.
Define the process end to end, including the parts outside the sponsoring function. Where it starts and ends is itself a finding.
Cycle time, cost, touches, exceptions and rework, taken from system data wherever it exists rather than from estimates.
Almost always at handoffs, in exception routes, and where a control was added to compensate for a design fault upstream.
Process by process: eliminate, standardise, redesign or automate. Each with a stated reason and an expected effect.
The redesigned process with controls, measures, roles and system requirements specified together, so configuration has something to build from.
Implement, then measure the same baseline again. A redesign that cannot be shown to have moved the number has not finished.
Clients are described by sector rather than named.