When the process is the problem, not the technology

The incumbent system is blamed for everything slow, opaque, and frustrating. Leadership authorises a replacement. Consultants map workflows. Vendors promise transformation. Eighteen months later, the new platform is live and the same complaints return with different vocabulary. The work still stalls at the same handoff. The same manager still makes the same exception. The same report still arrives late because nobody agreed what 'complete' means.

Software encodes process. It does not invent discipline. When the operating model is contested, ambiguous, or dependent on heroics, a replacement system becomes a expensive mirror. Constrange sees replatforming programmes that would have delivered more value as a two-page decision rights document and a single owner for intake.

That does not mean technology never matters. It means technology is the wrong first move when the breakdown is in how work is assigned, measured, or escalated. Replacing the tool before fixing the model ships the confusion faster.

How process problems disguise themselves as system problems

Symptoms point at software because software is visible. Screens, tickets, error messages. Process problems are social: who can say no, who must approve, what happens when the policy and the emergency disagree. Teams describe the pain as 'the system won't let us' when the truth is 'we never agreed who owns the exception'.

• Multiple teams touch the same object with different definitions.
• Escalation paths exist on paper but not in practice.
• Volume is high but variance is handled by named individuals, not rules.
• Policy requires steps that operations routinely skip with tacit permission.
• Success metrics reward speed in one team and caution in another.

What a broken operating model looks like

A broken model is not chaos. It is often highly skilled improvisation. People know which inbox to use, which call to make, which version of the spreadsheet is current this week. That improvisation keeps revenue moving. It also hides risk. When those people leave, the model breaks visibly and leadership blames the tool.

If more than one row feels familiar, replacing software treats the symptom. You may still need new technology later. You need a readable model first.

Why replatforming repeats the pattern

Replacement projects copy the current workflow into a new tool because discovery is easier than negotiation. Political landmines are avoided by 'like for like' migration. Exceptions are described as edge cases rather than core work. Go-live dates dominate definition work.

Vendors are not incentivised to tell you the process is broken. Their product assumes a model. Implementation partners map what exists. Neither role is designed to stop the programme and fix ownership. So the new system launches with the old arguments baked in, now with higher switching costs.

Fixes that cost less than a platform

Name decision rights for the object that stalls. Write the definition everyone argues about. Collapse approval layers that add delay without reducing risk. Stop measuring conflicting outcomes in adjacent teams. Publish the unofficial path and decide whether to formalise or remove it.

Sequence before you sign with a vendor

1. Map the last ten exceptions. Who resolved them? By what rule?
2. Identify one handoff that fails weekly. Name an owner.
3. Agree one definition that would remove a recurring meeting.
4. Pilot a manual fix for thirty days. Measure whether work moves.
5. Only then scope what software must encode.

Thirty days of manual discipline sounds slow. It is faster than twelve months of platform configuration that encodes the wrong model.

When software is still the right move

Technology earns its place when the model is clear enough to encode, when the join is technical rather than political, or when the incumbent cannot meet a non-negotiable constraint. It is also right when manual fixes worked and now need scale. The sequence matters: clarity, then tool.

“You cannot automate a disagreement. You can only automate what people have already decided to do the same way.”Constrange

What leadership should ask

Ask whether the programme changes who can say no. Ask what happens to the ten most common exceptions. Ask which meeting disappears if this succeeds. Ask who loses a workaround they rely on. If answers are vague, the process is still the problem.

Constrange is not anti-software. We are pro-sequence. When the process is the problem, the honest move is smaller, earlier, and more political than a RFP. Fix the model. Then choose the tool that fits a world operations already recognises.

Replatforming red flags

• Discovery is mostly 'as-is' mapping without exception depth.
• Success metric is go-live date, not behaviour change.
• No stop list for parallel tools.
• Vendor statement of work owns configuration; operations owns outcomes without hours allocated.
• Training plan assumes documented process matches reality.

Two or more red flags suggest the programme will encode the current model faster, not fix it.

Process fixes that unlock later technology

Agreeing decision rights often removes half the automation debate. Retiring duplicate reports frees analysts to own definition. A thirty-day manual pilot proves whether volume justifies build. These moves are unmarketable and effective.

Leadership that funds process work before platform spend sends a signal: fit matters more than motion.