Why ERP projects fail at the integration layer
TechnoVision Engineering
Publication date pending · 12 min read
Every ERP programme has a diagram with a box labelled "integration". It is usually drawn last, sized smallest, and estimated most optimistically. It is also where the project will be decided.
The contract is the domain
When two systems exchange an order, they must agree on what an order is: when it exists, who may change it, what happens to a partial fulfilment, and which side owns the identifier. Those are not technical questions. They are the business model, written down under pressure - and if nobody writes them down, each side invents its own answer.
An integration is not a pipe between two databases. It is a treaty between two models of reality.
Make the contract explicit
Write the schema before the code, version it, and treat a breaking change as a product decision rather than a deployment detail.
{
"orderId": "string · owned by ERP",
"externalRef": "string · owned by caller",
"state": "draft | confirmed | partial | done | cancelled",
"lines": [{ "sku": "string", "qty": "decimal" }],
"version": "int · optimistic lock"
}Failure modes, ranked
| Failure | Root cause | Cost |
|---|---|---|
| Duplicate records | No identity owner | High |
| Silent data loss | Fire-and-forget writes | High |
| Reconciliation drift | No versioning | Medium |
None of these are exotic. All of them are cheap to prevent at design time and expensive to unwind after go-live - which is the whole argument for designing the integration first.