Home/MU·01/Enterprise integration
MU·01 Technology
Metering, ERP, payroll and carrier networks joined so that one number survives the whole chain. A produced volume, a crew member’s certification, an invoice line — each should mean the same thing in every system that touches it.
Integration is often sold as plumbing: move data from A to B. The difficult part is almost never the transport. It is that A and B disagree about what the data means, and the disagreement is invisible until someone reconciles a month-end and finds two defensible numbers.
A produced volume measured at a metering point, allocated to an entitlement, invoiced to a partner and reported to a regulator passes through four systems that each have a legitimate definition of the same quantity. Joining them is a modelling exercise before it is an engineering one.
We start by writing down the definition each system is actually using — not the definition its documentation claims. That exercise routinely surfaces disagreements that predate any software and have been absorbed by manual adjustment for years. Once the definitions are explicit, the integration itself is comparatively ordinary work.
Then we make corrections first-class. A restatement upstream has to be able to travel the whole chain, because the alternative is a permanent reconciliation ritual performed by someone with a spreadsheet.
This capability grew out of the group’s hydrocarbon accounting chain, where the consequence of a broken join is a misstated entitlement rather than a cosmetic reporting error. It now applies equally to crew rotation travel, where a certification, a roster and a ticket have to agree before anyone boards.
What this covers
Questions
Joining the operational and financial systems in a chain so that a single quantity — a volume, a certification, an invoice line — carries the same meaning in each. The work is as much definitional as technical.
No. We are not selling a connector platform. We model the disagreement between systems and then build the joins, using whatever transport the client already runs.
A warehouse gives you the numbers side by side. It does not resolve which one is right, and a reconciliation performed in a warehouse is still a reconciliation.
Almost always, and usually that is the situation. The chain generally includes at least one package nobody wants to touch.
Shorter than clients expect once definitions are agreed, and longer than they expect if they are not. The definitional phase is where the schedule risk sits.
Continue
That is a definition problem before it is a data problem.