No process ownership

This is the failure that does not look like a failure. Nothing crashes. Every meeting is attended, every question is answered, and the project slips a month at a time until someone asks why.

The cause is that a decision needs an owner, and cross-departmental processes usually have none. Order-to-cash touches sales, warehouse, finance and support. Each has an opinion on how the customer master should work. None of them owns the customer master.

What it looks like

Decisions that get made twice. Sales agrees a credit-limit rule in one meeting; finance reverses it in another, because neither knew the other had authority.

Requirements that arrive after configuration. Not because anyone withheld them, but because the person who knew was never asked — nobody was responsible for knowing who to ask.

A steering committee that steers nothing. Everyone is senior, everyone is consulted, and the meeting produces minutes rather than decisions.

Go-live that slips without a blocker. Ask what is blocking it and you get four different answers, none of them a specific unresolved question.

The fix is boring and it works

Name one owner per process. Not a committee — a person, who can make a decision that sticks and who will personally feel it if the process is wrong after go-live.

Two properties matter more than seniority. The owner must understand the work, so a department head who has never raised a purchase order is the wrong choice. And they must have authority to say no, because most of the job is declining requests that would make the process worse for one team's convenience.

Write the decision down

Every process decision gets recorded with the reasoning: what was decided, who decided it, and what alternatives were rejected. Not ceremony — the reasoning is what stops the same argument recurring in month four, and what tells a future implementer whether a constraint is deliberate or accidental.

Why this outranks the technical failures

Bad master data can be cleaned. Over-customisation can be unwound. Both are expensive and both are fixable by people who know what they are doing.

An implementation with no process ownership produces a system that nobody agrees with, and that is not a technical problem. It gets worked around rather than used — orders raised outside it, spreadsheets kept alongside it, the ERP demoted to a system of record that records what already happened somewhere else. Which is the outcome the project was bought to prevent.