Why manufacturing businesses spend so much time moving information between systems

A manufacturing business can invest considerable effort in making its production operations more efficient while paying rather less attention to the work required to keep those operations supplied with the right information. A customer enquiry becomes a quotation, a quotation becomes an order, the order generates requirements for materials and production, and eventually somebody needs enough reliable information to dispatch the product and raise an invoice. None of this is incidental to manufacturing. It is part of how the business makes and fulfils its commitments.

Yet the information supporting that work does not necessarily travel as smoothly as the process description suggests. Details arrive in emails and attachments, are entered into a customer or accounting system, copied into a spreadsheet, checked against an engineering drawing and confirmed in a conversation with somebody on the shop floor. A manager asks for an update and someone assembles the answer from several places. The organisation may have invested in perfectly capable software, but employees still spend time moving information between systems and checking that it means the same thing when it arrives.

It is tempting to describe this as a problem of disconnected software. Sometimes it is. But I think that explanation is often incomplete. Before deciding that two systems need integrating, it is worth understanding what people are actually doing when they move information between them.

The work between the systems

Imagine following a customer order through a small manufacturing business. Sales records the requirements, engineering confirms what is feasible, purchasing checks material availability, production plans the work, and finance eventually needs to know what can be invoiced. Each function has a legitimate interest in the order, but not necessarily the same interest. Sales needs to understand the customer’s commitment. Engineering needs an unambiguous specification. Production needs a workable instruction. Finance needs an accurate commercial record.

It is quite possible for each department to have a system that serves its own needs reasonably well while the overall flow of work remains awkward. An order number may exist everywhere, but the meaning of its status may differ. A delivery date might be an estimate in one place and a commitment in another. A change agreed with the customer might be recorded promptly by Sales but reach Production only after someone notices an inconsistency.

What looks like repeated data entry may therefore contain several different activities. Some information is simply being copied. Some is being translated into a form another department can use. Some is being checked because the recipient has learned that the source cannot always be relied upon. And some is being supplemented by judgement that the software does not capture.

Those distinctions matter. Copying a value twice may be unnecessary. Confirming that the value is still correct may be an essential control. If we treat both activities as waste and remove them together, the apparent efficiency gain may be accompanied by a less reliable process.

Why people keep their own records

Spreadsheets are often presented as evidence that a business needs better systems. They can be, but I would be cautious about reaching that conclusion too quickly. A spreadsheet may exist because an employee needs a particular view of the work, because the main system cannot represent an exception, or because two sources of information disagree. It may also exist simply because it was the quickest practical solution to a problem that nobody had time to address properly.

Over time, these arrangements can become quite sophisticated. A spreadsheet acquires additional columns, notes and colour codes. Someone learns which entries can be trusted and which need checking. A colleague becomes the person everyone asks when an unusual order arrives. The arrangement is fragile in some respects, but it may also be doing important work that a replacement system would need to preserve.

The useful question is not whether the spreadsheet should be eliminated. It is why it became necessary, what information it contains that the organisation needs, and what would happen if people stopped maintaining it tomorrow.

This is closely related to the distinction I explored in The process map is not the work. A documented process can describe the formal movement of an order without showing the checking, chasing, reconciling and remembering that make the process succeed in practice. Those activities are often where the real difficulties, and some of the most valuable human contributions, become visible.

When faster information creates a different problem

Modern automation tools make it relatively straightforward to move data between applications, notify colleagues when something changes, or generate a document from information held elsewhere. These capabilities can be extremely useful. A reliable transfer between two systems may remove repetitive work and reduce transcription errors. An appropriately designed notification may prevent an important handover from being overlooked.

But faster movement is not necessarily better information.

Suppose a production team regularly checks delivery dates with Sales before releasing work. An automated integration could transfer the date immediately and remove the need to re-enter it. That would be helpful if the problem were simply the act of copying. It would be less helpful if the date were frequently provisional, changed informally or meant something different to the people using it. In that situation, the integration could distribute uncertainty more efficiently without resolving it.

This is one reason why I argue in Before you automate, understand the work that the appropriate starting point is not what the technology can do. It is what the work is trying to achieve, where the existing arrangements struggle, and which activities are necessary to protect the outcome.

The same reasoning applies to AI. A system that can summarise orders, answer questions about documents or draft updates may make information easier to access. It cannot, by that capability alone, establish whether the underlying information is complete, current or consistent. The questions we raised in Before you introduce Microsoft Copilot, get your information in order are therefore relevant well beyond Copilot itself.

Follow one real piece of work

A useful investigation need not begin with a large transformation programme. I would start with one workflow that people already recognise as troublesome. It might be the passage from quotation to confirmed order, the handling of engineering changes, the preparation of production information, or the assembly of a weekly management report.

Then I would follow a small number of actual examples through the organisation. Where did the information originate? Who needed it next? What did they have to check or change before they could use it? Where did they wait? Which details were recorded in systems, and which were carried in emails, spreadsheets or people’s memories? What happened when the case was not straightforward?

It is important to speak to the people doing the work, not only to those responsible for the process. Someone may say that an order takes five minutes to enter, but the entry itself may be preceded by half an hour of checking and a day waiting for clarification. Conversely, a manual check that appears inefficient may be preventing an expensive mistake. We need to understand the purpose of the activity before judging its value.

The aim is to distinguish several causes that can look similar from a distance: unnecessary duplication, poor information quality, unclear ownership, incompatible definitions, avoidable handovers, legitimate controls and decisions requiring experienced judgement. Different causes call for different responses.

Decide what needs to change

Once the work is understood, the options usually become more interesting than a choice between doing things manually and automating them. Perhaps the information should be captured correctly once, at the point where it first becomes known. Perhaps two departments need to agree what a status or date means. Perhaps a routine approval adds little value, while another check is essential and should be made more visible. Perhaps the existing systems can be configured differently, or a modest integration can remove repeated entry without disturbing necessary controls.

There may also be opportunities for AI to help people interpret documents, locate relevant information or prepare decisions. But these should be evaluated against the same questions as any other change: what improves, how will we know, what might go wrong, and who remains responsible?

For a manufacturing SME, this approach has a practical advantage. It does not require the business to decide in advance that it needs a new ERP system, an automation platform or an AI strategy. It begins with a recognisable difficulty and builds enough evidence to make the next decision sensibly.

I would also want to establish a baseline before making changes. How often does the workflow require rework? How long does information wait between stages? How much employee time is spent checking or reconciling it? How often do errors reach the next department or the customer? Not every measure needs to be elaborate, but without some account of the current position it becomes difficult to distinguish a genuine improvement from a convincing demonstration.

Start with the problem, not the software

Manufacturing businesses are accustomed to thinking carefully about material flow, production constraints and quality. Information deserves similar attention because it shapes what the organisation can promise, plan, produce and deliver. Much of the effort involved in moving information between systems is a signal about how the wider organisation works.

Sometimes the right answer will be integration or automation. Sometimes it will be clearer responsibilities, a better information structure, a change to the way an order is accepted, or the removal of a workaround whose original purpose has disappeared. Often the useful intervention combines several of these.

The starting point is to find one troublesome workflow and understand it properly. Not the idealised sequence of boxes and arrows, but the actual work: the information people need, the judgements they make, the checks they perform and the things they have learned to do to keep the business running. Once those are visible, the decision about what to improve becomes considerably more grounded.