A common manufacturing system promises a welcome kind of order. Colleagues can use the same definitions, compare work across plants and stop translating between several versions of an apparently identical record. I have spent much of my career pursuing that benefit. I have also learnt that a difference in records is not always a defect in discipline. It can be the visible trace of equipment, tooling or an engineering condition that the common model has not yet represented. Removing the difference without understanding it may improve the appearance of the data while making the factory harder to describe accurately.
The practical challenge is to distinguish the differences that should end from those that should remain explicit. A local convention may have survived long after its original purpose disappeared. Another may still describe a real constraint. Neither deserves automatic protection merely because a plant uses it, and neither should be removed simply because the enterprise application prefers one value. I want the programme to investigate the reason and identify who can decide. That is a more demanding form of standardisation than selecting a common entry, but it produces an agreement the organisation can actually use.
Ask what the difference represents
In a work-order migration rehearsal we examined 420 orders. Of those, 336 agreed across the proposed route and eighty-four did not. Fifty-two conflicts concerned engineering revisions; thirty-two concerned routing. A conversion rule could have made the records match. It could not determine which instruction was authorised or why a plant used a particular route. We kept the conflicting versions available and took the questions to engineering and production owners. The three-week phased introduction and JPY430 million cost were consequences of deciding to resolve the meaning before declaring the transfer ready.
That experience is useful because it makes the issue more precise than a disagreement between central technology and local practice. The migration team had a legitimate delivery task. Plant colleagues had legitimate operating knowledge. Engineering owners had authority over revisions that neither group could absorb merely by agreeing a convenient value. Once those responsibilities were clear, the discussion became less personal. The question was no longer which team should win an argument about standardisation. It was which explanation supported the instruction that the next person would receive through the system.
I ask teams to preserve enough context to make an exception examinable. What differs? Where did each version come from? Which operating condition is said to require the difference? Who can confirm whether that condition still applies? The answers do not need to become an encyclopaedia of every local habit. They need to support a decision and leave a usable account of it. Without that discipline, exception lists tend to divide into two unhelpful groups: items nobody wants to challenge and items scheduled for removal without a credible understanding of their consequences.
Give agreement an authorised owner
Data ownership can become a vague label if it is separated from the decision involved. A person may maintain a field without having authority to change the engineering instruction it represents. Another may approve a route without controlling the application that distributes it. I prefer to make those responsibilities visible together. The technical team needs an authorised decision it can implement, while the operating owner needs to understand where the result will appear and who will rely on it. A common system increases the reach of a decision, which makes the source of its authority more consequential.
The eighty-four rehearsal conflicts were eventually reconciled through that process, and the relevant orders were tested again. The outcome gave us evidence about the examined records. It did not prove that every future order would be correct, nor did it establish a productivity increase. We also needed a continuing route for new disagreements. Engineering changes and operating conditions do not stop at programme closure. If the system has no intelligible way to represent a later exception, users may return to private notes and informal explanations, leaving the enterprise with a polished but incomplete account.
There is an economic question as well. Investigating differences consumes experienced people's time and can extend parallel operations. I do not treat that cost as automatically justified by invoking accuracy. A programme should explain which disagreements are consequential, why the proposed review is proportionate and whether a narrower stage can proceed while another group is examined. The right decision may be phased. What matters is that the remaining scope stays visible and supported. A staged introduction becomes misleading when its report quietly describes the completed cohort as if it covered the whole operating estate.
I also want common definitions to be challenged by practical use. If a category repeatedly forces plant colleagues to choose an entry that misdescribes the work, the problem may lie in the category rather than the users' willingness to adopt it. That does not mean every local preference deserves its own field. It means the enterprise should examine recurring disagreement as evidence about the model. A useful common language can develop through those observations. A language protected from challenge may achieve consistent entries while becoming less informative about the business it is meant to coordinate.
Keep the explanation after introduction
The decision behind a record should not depend entirely on the memory of the migration team. I want the next engineer or production planner to understand why a difference was removed or retained. A concise explanation linked to the responsible owner can prevent an old issue from returning as a new debate. It can also make a later change easier: when the operating condition ends, the organisation knows what previously justified the exception. That is more useful than a permanent label saying local requirement with no account of what the requirement actually was.
Measures of adoption should follow the same logic. A high proportion of records in the common system may show reach, but it does not necessarily show agreement about meaning. I ask for a small set of observations that examine use: whether people can locate the authorised instruction, identify an unresolved condition and route a correction to the appropriate owner. These observations do not replace all quantitative measures. They help explain what those measures represent. The aim is to avoid a programme that reports impressive participation while leaving the most consequential interpretation work outside the visible process.
My ambition is not a factory without differences. It is an enterprise that can explain which differences matter and act on them coherently. Common data can make that possible when the system represents the work faithfully enough to support a conversation across functions and sites. The CIO's contribution is partly technical and partly organisational: provide a route through which operating knowledge can improve the shared account, while keeping authority and cost explicit. Standardisation then becomes a continuing agreement about the business, rather than a finished conversion whose apparent neatness nobody feels able to question.