What Integration Cannot Fix

A connected estate makes good processes faster and bad processes faster. It changes nothing about which they are.

Rules nobody has decided

If it is unclear whether the walk from the gate is paid, no system resolves it.

It will encode whatever was configured, consistently, which makes an undecided question look like a decision.

What works: decide it, write it down, then configure it.

Data nobody maintains

Integration moves data. It does not make it correct.

Stale availability, wrong cost centres and duplicate people propagate faster through a connected estate than through a disconnected one.

Which is why identity and reference data come first, and why a project that starts with interfaces fails.

A process that does not work

A rota built badly, published late, and now transmitted automatically to three systems is a badly built rota in three places.

The subjects of scheduling, attendance and absence are separate for a reason.

Fix the process, then connect it.

Understaffing

No chain produces coverage from a headcount that is insufficient.

It will show the shortfall more clearly, which is worth something, and it is not a solution.

A vendor relationship that has gone wrong

Integration effort does not compensate for a product that cannot do what was promised.

And a bad join is frequently a symptom of a product that was never going to fit, rather than of insufficient integration work.

Check which before spending more.

Disagreement between departments

When operations and finance disagree about a number, connecting their systems makes the disagreement precise rather than resolving it.

Which is progress, and the resolution is still a decision someone has to take.

Using this during procurement

For each requirement, ask what would change if the integration worked perfectly.

Where the answer is "nothing, unless we also decide X or hire Y", the requirement is a decision or a staffing question in disguise.

Taking those out shortens the specification considerably, and what remains is what integration can actually deliver.

Check whether it predates the product

The question that identifies a boundary problem.

Did this problem exist with the previous system?

If yes, replacing the current one will not fix it, because the cause is in the identity mapping, the reference data or the rule split — all of which survive a migration.

Almost nobody asks, and the answer is available from anyone who was there.

A practical configuration prompt

During configuration, use a boundary-testing reference to prompt questions about identifiers, ownership and output. Treat the page as a starting point and document each assumption.