Digitalisation as operating infrastructure

Define the process before selecting software

A European order can create records in a commercial system, an enterprise resource planning system, a warehouse platform, a transport platform, a customs application and the customer portal. Connecting those systems does not establish which record management should trust when they disagree.

The transaction design should already state the commercial and physical events that the operation intends to perform. Digital design has a more specific responsibility: translate those events into states, critical fields, authority and evidence that systems can preserve.

We begin where records disagree. The enterprise system may show available stock while the warehouse has placed it in quarantine. A warehouse may label an order "shipped" when loading is complete while the carrier has not accepted it. Finance may treat a transaction as complete before proof required for reporting has returned.

Each disagreement is traced to the status definition, source field and decision that created it. The review includes corrections performed through email, spreadsheets or personal knowledge because those workarounds reveal where the formal record cannot support daily operation.

The company can then decide which state needs a shared record, which transition can be automated and which decision still requires authorised judgement.

Establish the authoritative record by state

There may be no single system that owns every fact throughout an order. Authority can change as the transaction progresses.

The commercial system may own the customer promise. The enterprise system may own the approved sales order and financial posting. The warehouse system may own the physical pick and dispatch events. The customs declaration remains authoritative for the data accepted by customs. The design challenge is to define those boundaries and reconcile them.

We use a state model for material transactions. For an outbound order, states might include accepted, credit released, stock allocated, compliance cleared, released to warehouse, picked, dispatched, delivered and financially closed. Each state has:

• an entry condition;
• a source record;
• a timestamp definition;
• a party authorised to create or reverse it;
• downstream actions that rely on it;
• an exception when the expected transition fails.

This prevents a familiar problem in multi-provider operations. The warehouse labels an order "shipped" when loading is complete, the carrier labels it "collected" after scanning, and the commercial system treats shipment confirmation as proof of dispatch. All three statuses can be internally consistent while management measures different events under one name.

The state model also determines what a change invalidates. If quantity changes after customs data has been prepared, the process should know whether allocation, declaration, transport booking and invoice preparation must return to an earlier state. Without that rule, systems can continue from incompatible versions.

Give critical fields an owner

A complete data catalogue can contain thousands of fields. Operational design starts with the smaller group that can stop movement, change legal treatment, distort stock or alter the customer commitment.

Typical examples include product identifier, description, classification, origin, value, weight, owner, customs status, seller, buyer, delivery condition, ship-from location and destination. Each field needs a business owner who can define it, approve a change and resolve conflicting evidence.

The system administrator is rarely the appropriate business owner. An administrator can control access and configuration. Product, commercial, customs, fiscal or logistics knowledge determines whether the field is correct for the transaction.

We record four responsibilities for each critical field:

1. who creates the source value;
2. who verifies it and against which evidence;
3. which systems may copy or transform it;
4. who decides when two sources conflict.

Data quality then becomes an operating responsibility. A missing country of origin is not an abstract quality percentage when it stops a declaration. A weight difference is not a system issue when it causes a carrier rejection or changes freight cost. The effect determines the priority.

Design the exception record

Normal transactions leave structured events. Exceptions often move into unstructured channels precisely when management needs better information.

An employee sees that an order will miss cut-off, sends an email and calls the warehouse. The immediate problem may be solved, but the decision, cost and cause are absent from the operating record. The same condition returns because the organisation cannot see recurrence.

We require an exception record for events that affect customer service, compliance, inventory or material cost. It should contain the affected transaction, detection time, current owner, decision deadline, verified facts, action, approval where required, customer effect and closure evidence. Cause classification can follow after containment, since early guesses are often wrong.

The record must remain light enough for daily use. Asking the operating team to complete a long investigation form before acting will push work back into calls and private notes. We separate live control from root-cause review. The live record supports the next decision. Repeated or material failures trigger a structured investigation.

Give automation a stable rule

Repetitive work is suitable for automation when the input, decision rule, output and exception route are defined. A task remains unstable when staff apply an unrecorded judgement each time the input is incomplete.

Before automating a step, we ask:

• What starts it?
• Which data is required and which source is trusted?
• What result is permitted?
• Who owns an exception?
• How can the decision be reversed?
• Which evidence must be retained?

If the team cannot answer those questions, the process needs further design. Automating it can conceal the missing rule and multiply the effect across more transactions.

Some steps should retain human judgement. Product classification, unusual valuation conditions, allocation during scarcity or acceptance of a compliance exception may require facts and accountability beyond a fixed rule. Digital support can gather evidence, present options and record approval. The accountable decision remains with the authorised person.

A rejected option we see frequently is automating the final correction because it is visible and measurable. For example, a script can overwrite a recurring order-field error before warehouse release. That may provide temporary containment. It also hides the upstream source and makes later reconciliation harder. We accept such automation only with an owner, a control total and a plan to correct the source.

Translate compliance into transaction conditions

Compliance becomes operational when a requirement can stop, release or alter a transaction through a defined control.

A written conclusion may state that a product needs specific information, that a movement requires a particular document or that a tax treatment depends on transport evidence. The operating model should identify where the condition is checked, what evidence is accepted, who decides and how the result reaches the next party.

This work is becoming more data-intensive. The European Commission launched the Digital Product Passport Registry in July 2026. The Commission states that the registry supports unique product identifiers and metadata while detailed product information remains decentralised, with the first implementation deadline applying to certain large batteries in February 2027. The operating implication extends beyond registration. Manufacturers and economic operators need dependable source data, access rules and lifecycle events from suppliers, service partners and recyclers.

Technology can provide the identifier and exchange mechanism. The company still has to decide who warrants a supplier fact, who changes it after repair or repurposing, and how the physical item remains linked to the correct record. Those are process and authority decisions.

Use operating data while action remains possible

Management reports often measure final results because final results are easier to reconcile. Delivery performance, inventory accuracy and transport cost remain important. Operating control also needs leading events that preserve a recovery window.

Examples include orders waiting for compliance release, stock allocated before customs release, bookings without accepted data, returns awaiting disposition and exceptions without an owner. The measure should identify the affected transactions and the time remaining before customer or compliance impact.

We link each measure to a decision. A queue has an owner, an ageing rule and a threshold for escalation. A recurring data defect has a source owner and a correction plan. A manual adjustment has a reason and a reconciliation check.

The objective is not more reporting. It is a shorter interval between a condition becoming visible and an authorised response.

Protect access and continuity

Operating data crosses company and provider boundaries. Access should follow the role, transaction and period for which it is needed.

Shared accounts weaken accountability and make removal difficult. Informal supplier access can remain active after a project ends. Broad exports can expose commercial or personal information unrelated to the service. We include access approval, periodic review and removal in the provider onboarding and exit process.

Continuity deserves the same attention. Management should know:

• which systems are required to release and record a movement;
• how long the operation can continue without each one;
• which controlled fallback is available;
• how offline transactions will be reconciled;
• who may invoke and end the fallback;
• when recovery was last tested.

A backup confirms that data can be copied. A recovery test confirms that the process can resume with correct states, interfaces and authority.

Implement in a controlled sequence

We normally stabilise digital operating infrastructure in this order:

1. trace real transactions and exceptions;
2. agree states, critical fields and decision rights;
3. remove duplicate or conflicting rules;
4. configure the minimum shared records and controls;
5. test normal and exception scenarios;
6. automate stable, repeated work;
7. retire temporary bridges after reconciliation.

An all-at-once replacement may be justified when the current platform is unsupported or fundamentally unsuitable. It increases migration and continuity risk, so it requires explicit readiness gates and a fallback. A staged implementation reduces cutover exposure but can prolong dual records. The right choice depends on transaction criticality, data quality and the company's ability to reconcile during transition.

The digital output is an operating record

The result of this work is not a universal database. It is a governed path through the systems that hold different parts of the operation.

For each material state, management can identify the authoritative source, permitted changes, accepted evidence and next decision. An exception retains its owner and history after the immediate call has ended. A provider change does not erase the definitions on which the company depends.

This gives later readiness testing a precise object. The test can challenge a state transition, remove a system, introduce conflicting data and verify whether authority and reconciliation still work. It no longer needs to rediscover what "released", "shipped", "delivered" or "closed" was intended to mean.

Digitalisation becomes operating infrastructure when those definitions survive the individual application, dashboard and provider that happens to display them.