The first wave of business process reengineering failed for an honest reason: the technology of the day could not deliver what the theory promised. In 1993 a firm could redraw a process on a whiteboard, but the systems underneath were rigid, batch-bound and difficult to integrate, so the redesign either stalled at the boundary of the mainframe or degenerated into a cost-cutting exercise dressed in the language of transformation. The idea was sound and the tooling was not, and the two were remembered together.

That constraint has largely dissolved. Application programming interfaces are now a standard expectation rather than a bespoke project. Event streaming, cloud data platforms and orchestration engines make it feasible to compose a process that runs across several systems of record without hand-carrying data between them. What was once a heroic integration is now ordinary engineering. The consequence is that the reengineering question, long deferred because it was too expensive to answer, has become tractable again, and it is returning in most organisations under other names: order-to-cash redesign, customer onboarding, supply resilience, finance close acceleration.

The temptation to defer the reengineering question is understandable and no longer safe. For years the rational course was to wait, because the integration cost of any serious redesign outweighed the benefit, and firms accumulated workarounds in the confident expectation that they would be resolved by the next system upgrade. They rarely were. Each upgrade preserved the old process shape because migrating the shape was cheaper than questioning it, and the accidental design hardened into apparent permanence. What has changed is that competitors who do ask the question can now act on the answer, and a process that takes twice as long or costs twice as much is no longer hidden by everyone else being equally slow.

There is a second reason the question matters now. Three decades of enterprise software adoption have left most large firms with a CRM that models the customer, an ERP that models the transaction and finance, and a supply chain suite that models material and capacity, each configured by a different function at a different time to a different logic. The processes that actually create value, taking an order and fulfilling it, acquiring a customer and serving them, planning supply against real demand, run straight across all three. The organisation is arranged by function; the work is arranged by flow; and the gap between the two is where cost, delay and error collect. Reengineering is the discipline of closing that gap deliberately rather than papering over it with spreadsheets and goodwill.

The founding insight of reengineering, and still the one that does the most work, is that a business is more truthfully described by its processes than by its organisation chart. A function-centric firm optimises each department against its own targets: sales maximises bookings, operations minimises unit cost, finance protects working capital. Each is locally rational and the sum is often globally poor, because the hand-offs between functions, where the customer actually waits, belong to no one. A process-centric firm inverts this. It names the end-to-end flows that matter, gives each an owner with real authority across functional lines, and measures the flow as a whole: elapsed time, first-pass yield, cost to serve, cash conversion.

From this follows a hard prior question, which we insist on answering before any redesign begins: reengineer, or improve incrementally? The two are not interchangeable, and confusing them is expensive in both directions. Incremental improvement is the correct choice when a process is fundamentally sound and merely encrusted with waste; here the tools of lean and continuous improvement pay back quickly and safely. Reengineering is warranted only when the process embodies assumptions that no longer hold, when the sequence of steps exists because of a constraint that has since disappeared, or when the desired outcome is unreachable by any amount of tuning of the existing design. The test we apply is blunt. If you could not have arrived at this process by designing for today's outcome from a blank sheet, it is a candidate for redesign. If you could have, it is a candidate for improvement.

The third principle is that a process spanning CRM, SCM and ERP cannot be redesigned in one of them alone. The customer master, the product master, the pricing logic and the order state are shared facts that live, redundantly and often inconsistently, in all three systems. A genuine redesign has to decide where each fact is authored, how it propagates, and which system is trusted when they disagree. This is why we treat data and integration not as a downstream implementation concern but as the substance of the design itself. The process model and the data model are two views of the same thing, and a reengineering effort that produces beautiful process diagrams and leaves the data ownership unresolved has not actually reengineered anything.

A fourth principle underpins the other three: a process, a system and an organisation are not three things to be aligned but one thing seen from three angles. When they are treated as separate workstreams with separate governance, each optimises for its own completion, and they meet at go-live in mutual contradiction. The system enforces a flow the organisation is not staffed to run against data the process assumed was clean. Designing them as one decision is more demanding intellectually and far cheaper in practice, because the contradictions are found on paper rather than in production.

The field is moving, and not always in the direction the vendors advertise. A few patterns are worth naming plainly because they change how a redesign should be approached.

Composability over the monolith. The assumption that a single ERP suite should own most of the process is giving way to an architecture of specialised systems joined by integration. The customer engagement layer, the planning engine, the financial core and the fulfilment systems are increasingly distinct, chosen on their merits and composed into a flow. This is liberating for process design, because you are no longer bound to one vendor's opinion of how order-to-cash should work, but it moves the difficulty into the integration and governance layer, which now carries the coherence the monolith used to provide.

Process mining as evidence. For most of its history reengineering began with workshops in which people described how they believed the process worked, which was reliably a fiction. Process mining reconstructs the actual process from the event logs the systems already emit, showing every variant, rework loop and bypass as it truly occurs. We now regard starting a redesign without this evidence as close to negligent. It replaces opinion with a measured baseline and, later, provides the instrument that tells you whether the redesign is behaving as intended in production.

Cloud ERP and the two-tier reality. The move to cloud ERP is often sold as a chance to return to standard processes and abandon years of customisation, and for genuinely common work that is sound advice. But the same move frequently hardens into a two-tier landscape, a standardised core surrounded by the specialised systems that carry a firm's actual distinctiveness. The design question is therefore not whether to customise but where distinctiveness legitimately lives, keeping the core close to standard while allowing the edge to differ, and integrating the two deliberately rather than by accident.

Automation moving from task to process. The first generation of automation, robotic process automation in particular, mostly imitated a human clicking through screens, which entrenched the existing process rather than redesigning it. The more useful pattern now is to automate the redesigned flow at the level of the process, using orchestration and native integration, and to reserve screen-level automation for the genuine edges where no interface exists. Automating a bad process only lets you perform it faster.

A reengineered process is only as good as the architecture that carries it. Several design principles separate redesigns that hold from those that quietly revert.

Single source of truth per fact, not per system. The instinct to declare one system the master of everything is as wrong as having no master at all. The discipline is finer: for each significant entity and attribute, name exactly one system that authors it, and let the others subscribe. The CRM may own the customer relationship while the ERP owns the legal account and credit position; what matters is that the ownership is explicit, agreed and enforced, so that reconciliation stops being a monthly ritual.

Integration as a contract, not a connection. Point-to-point interfaces built in haste become the most brittle part of the system landscape, because each encodes assumptions that no one wrote down. We design integration as versioned contracts with defined events, payloads and semantics, mediated through a layer that can absorb change on either side. The aim is that a system can be replaced behind its contract without every neighbour needing to know.

Design the process to be observable. A process that cannot be measured in flight cannot be managed, and most cannot. We build the redesigned flow so that its state, its timings and its exceptions are emitted as events by construction, feeding the same process mining that established the baseline. Observability is not instrumentation added afterwards; it is a property designed in, and it is what allows the process to keep improving after the project ends.

Design for reversibility. A redesign that can only go forward is a redesign that will be resisted, because the cost of being wrong is catastrophic. We build the migration so that each increment can be paused, run in parallel with the incumbent, and unwound if the evidence demands it. This is not timidity; it is what makes boldness affordable. When a change can be reversed cheaply, an organisation will attempt changes it would never risk under an all-or-nothing cut-over, and it is precisely those attempts that compound into real transformation.

Design for the exception, not the happy path. Most redesigns are drawn for the transaction that behaves, and most of the cost sits in the ones that do not: the partial shipment, the disputed invoice, the customer who exists twice under slightly different names. A process that routes its exceptions to a spreadsheet and a willing individual has not been designed; it has been half-designed and left to human goodwill for the remainder. We model the exception paths explicitly, decide which are common enough to deserve a first-class route through the system and which are genuinely rare enough to hand to considered manual work, and we make that distinction a deliberate choice rather than an accident of whatever the software happened to support. The true measure of a redesign is how it behaves on its worst Tuesday, not its best.

The ways these programmes fail are consistent enough to be catalogued, and most are failures of judgement rather than technology.

Big-bang ERP replacement. The most expensive single mistake is to replace the ERP and reengineer the processes in one simultaneous cut-over across the whole enterprise. The theory is that a clean break avoids the cost of running two worlds; the practice is that risk compounds, because every problem surfaces at once with no way to isolate cause, and the business loses the ability to fall back. We favour redesign delivered by process and by domain, with the new flow proven on a bounded scope before it is widened. A staged migration is slower and far more likely to arrive.

Automating the existing mess. A programme that maps the current process, automates it faithfully and calls the result transformation has spent a great deal to move faster in the wrong direction. Automation should follow redesign, never substitute for it.

Reengineering the diagram, not the organisation. A redesign that changes the system and the process but leaves the incentives, roles and reporting lines untouched will be quietly reversed by the people it inconveniences. If the process is now cross-functional but the bonuses remain functional, the functional targets win. Process ownership without authority is decoration.

Data debt deferred. Teams routinely postpone the master data and quality work as unglamorous, intending to address it later. Later the redesigned process, which assumed clean and consistent data, meets the real thing and stalls. Data quality is not a clean-up task adjacent to the project; it is a precondition of the process working at all. Consultant-led design without operators in the room compounds this: a redesign drawn entirely by specialists will miss the tacit knowledge of the people who run the work, the reason a step that looks redundant is actually load-bearing, the exception that occurs weekly and was never documented. When those operators first encounter the new process at training, they discover its gaps, and their trust, once lost, is expensive to recover.

Scope by system rather than by outcome. Programmes chartered as an ERP project or a CRM project inherit the boundaries of the software rather than the boundaries of the work, and the cross-system flows, which are precisely where the value sits, fall into the gaps between the streams. The charter should name an outcome and a flow, and let the systems fall inside it.

We begin from the flow and the outcome, not the system. Before proposing any change we establish what the end-to-end process is meant to achieve in terms the business will recognise, elapsed time, cost to serve, cash conversion, customer effort, and we measure the current state against it using the event data the systems already hold rather than the story people tell in workshops. That measured baseline settles the first argument, whether the process warrants reengineering or improvement, on evidence rather than enthusiasm.

Where redesign is warranted, we design the process, the data model and the integration together, treating them as three views of one decision rather than three sequential projects. We resolve the ownership of each shared fact across CRM, SCM and ERP explicitly, define the integration as versioned contracts, and make the orchestration of the flow an inspectable artefact rather than logic scattered through configuration. The redesigned process is built to emit its own state, so that it can be measured in production against the same baseline that justified it.

We deliver by domain and by flow, never by big-bang cut-over. A bounded slice of the redesigned process is proven in production, on real transactions, before it is widened, so that risk stays isolated and the business retains the ability to fall back. Throughout, we treat the organisational change, the ownership, the incentives, the roles, as part of the engineering rather than an afterthought, because a process that the organisation is not arranged to run will not survive. Our aim is a redesign that keeps improving after we leave, because the instruments to manage it were built in from the start.

We are candid about pace. A redesign that spans three systems of record cannot honestly be finished in a quarter, and any proposal that promises it is selling a cut-over rather than a redesign. We sequence the work so that each domain yields a measurable improvement on its own, which earns the confidence and the attention needed for the next, rather than asking the business to hold its breath through a multi-year programme for a single distant reward. That sequencing also disciplines the design itself: a flow obliged to prove its worth on a bounded slice cannot hide behind the promise that everything will cohere at the end. If a slice fails to improve the outcome it was chartered to improve, we would far rather discover it on one domain than on all three at once.

What distinguishes our work in process reengineering is that we refuse to treat CRM, supply chain and ERP as separate territories with separate redesigns. We hold the end-to-end flow, the data that runs through it and the organisation that operates it in a single view, and we resolve the hard questions of ownership and integration as design decisions rather than deferring them to implementation. That is a harder conversation to start and a far more durable result to finish.

There is also a practical corollary that changes what the work is permitted to assume. When an engagement calls for a capability that does not yet exist, it need not wait on a procurement cycle or a vendor's roadmap. The Nashua 360 Enterprise Platform is built to accommodate almost any feature at pace, through extreme vibe coding: what is needed is described in plain language and generated quickly, but always within firm architecture principles and under stringent quality assurance, so that speed never comes at the cost of coherence, security or control. The effect is strategic rather than merely convenient. It moves the make-or-buy line, keeps optionality cheap, and lets the architecture follow the strategy rather than the strategy bending to whatever happened to be on a shelf.

The reward for this discipline is a set of core processes that do what the business actually needs, measured against outcomes it cares about, carried by an architecture that can change without breaking, and run by an organisation arranged to run them. That is what reengineering was always meant to deliver, and with today's tooling it finally can.