Before you automate a factory, understand the system it belongs to

Knowledge is distributed

A factory can work remarkably well without anyone inside it having a complete explanation of how it works.

The founder knows the business, its customers and its economics. The production manager knows the schedule and the constraints on the line. Purchasing knows which suppliers can be trusted to deliver. Operators know which parts need a little more attention, which machine behaves differently in the afternoon, and what to do when something that should fit does not.

None of those people is missing something obvious. They are seeing different parts of a system that is too large and too changeable to fit inside one person's head.

Yet that is exactly what many automation projects implicitly assume: that the factory can first be reduced to a complete process map, and then redesigned around a collection of machines.

I don't think that is a very useful starting point.

The factory you can describe is not the whole factory

Think about what happens when a customer changes an order after production has been scheduled.

Sales may update the customer record. Planning changes a spreadsheet. Purchasing calls a supplier. Someone on the floor finds out during a shift meeting, or later, when the material that was expected doesn't arrive. An experienced operator finds a workaround that keeps part of the line moving.

The official process might say that the order moves from sales to planning to procurement to production. That description is not wrong. It is simply incomplete. The real operation also includes the delays, conversations, exceptions and individual decisions that hold everything together when events do not follow the plan.

This is part of why established factories are so interesting. They are achievements of coordination. They survive not because everything is perfectly specified, but because people continuously adapt to what the formal system missed.

That adaptability has value. It also creates a problem for anyone trying to automate the business.

If you install a machine based only on the documented process, the machine may perform exactly as specified while the operation around it becomes less flexible. A human used to recognize an unusual part, call the supervisor and change the sequence. A new automated cell may simply stop, or continue doing the wrong thing very efficiently, unless those exceptions have been accounted for.

The problem was never just the motion the machine had to perform. It was the information and judgment that made the motion appropriate in the first place.

A factory doesn't stop at its walls

Manufacturing is connected to a much larger network. Customers change their priorities. Suppliers change their delivery dates or prices. Financing costs move. Transport is interrupted. Regulations change. A material that was available yesterday becomes difficult to obtain.

Those events happen outside the factory, but their consequences appear inside it: in schedules, margins, inventory, quality decisions and delivery commitments.

That is why I hesitate whenever someone speaks about automating an entire factory as if it were a self-contained machine. The factory is not simply a set of repetitive operations. It is one participant in a larger economic system, responding to conditions it does not control.

No one can predict all those conditions. Nor does anyone need to. What matters is whether the business can notice a relevant change, understand what it affects and respond without having to rediscover the same information every time.

This changes where I think an automation project should begin.

We start in the office

At Quindart, our preferred starting point is not the robot catalog. It is the information that already moves through the business.

Orders, quotations, purchasing records, inventory, ERP systems, CRM tools, spreadsheets, messages and accounting software together contain a partial history of what the factory has promised to do, what resources it expects to have, and where reality has diverged from those expectations.

The information is usually scattered. Some of it is duplicated. Some arrives late. Some exists only in an email chain or in the memory of the person who knows which supplier to call. Connecting those records is often an easier and more informative first intervention than connecting every machine in the building.

But office records are only half the story. We have to compare them with the people and processes on the floor. When a status says an order is complete, what does complete mean? When a shift reports downtime, which events are included? When a purchasing record says material is available, can production actually use it?

The discrepancies are not inconveniences to be cleaned away. They tell us where the business is relying on invisible work.

Our aim is not to collect every possible data point. It is to develop a useful operating picture: how a commercial commitment becomes a production decision, where the dependencies are, which exceptions recur, and who has the information needed to act.

That picture does not have to be perfect to be valuable. It has to be accurate enough to guide the next decision, and honest about what it cannot see.

Then we decide what deserves automation

Imagine a factory where management is considering an automated packing station because orders are frequently leaving late.

A machinery-first approach studies packing cycle time and calculates how quickly a new station could work. Those calculations may be entirely sound.

A systems-first investigation may reveal a different pattern. Packing spends much of its day waiting for the correct labels, a revised order quantity, or confirmation that an upstream quality check is complete. The bottleneck visible at the end of the line is partly created by decisions elsewhere.

In that situation, a faster packing machine might help during peak hours. It might also do very little for delivery performance. Connecting order changes to production, clarifying the release decision and making missing information visible may be the better first investment.

Now suppose the information flow is fixed, and packing still limits output. The case for physical automation becomes stronger. The team can specify the equipment against real volumes, variations and exceptions rather than an idealized cycle. They can connect its status to the software already in use, define who handles interruptions, and measure whether the whole operation improves.

That is the sequence I care about. Understand enough of the system to identify the right intervention. Make that intervention small enough to test. Connect it to the wider operation. Keep the people who understand the work able to supervise and recover it.

Sometimes the answer will be a robot. Sometimes it will be software. Sometimes it will be a change in the way information passes between two departments. If we decide the answer before looking at the system, we are no longer investigating; we are just looking for a justification to buy something.

What an abstraction layer can, and cannot, do

There is an analogy from software that I find useful.

Most programmers no longer need to think about the individual processor instructions executed when they write a few lines of Python. Higher-level languages and libraries give them a more useful interface to the underlying complexity. The complexity has not disappeared. It has been organized behind abstractions that make certain kinds of work possible.

A factory needs something similar, although the problem is much less predictable than a program running on a computer.

A founder should not have to reconcile five systems or chase ten people to understand why an important order is at risk. They should be able to see the relevant exception, its likely causes, who is responsible and what choices are available. The production team should still be able to examine the underlying detail. An abstraction is only useful if the people running the operation can see through it when needed.

And unlike software executing within a defined environment, a factory has to deal with changing people, materials, customers and external conditions. No layer of software will make those uncertainties go away. It can help the organization respond to them with less confusion.

That is the kind of system we want to build around a factory: not an imaginary control panel that knows everything, but a dependable way for the right people to understand and act on what matters.

Automation does not have a finish line

This is also why I do not think of factory automation as a one-time installation.

A new product arrives. A supplier changes a component. Demand moves to a different mix. A machine ages. An operator discovers a better way to handle a difficult case. An integration that was correct six months ago needs to be revisited.

If the system is treated as finished on the day the equipment is commissioned, the factory slowly becomes harder to operate again. A real automation program needs owners, maintenance, monitoring, documentation and a way to accommodate change. The handover is not the last administrative task. It is part of the engineering.

For an owner, the reward is not simply a higher number on a production dashboard. It is attention.

When every missing update, delayed order and unusual exception has to pass through the founder, the business is using its most scarce management resource to compensate for disconnected systems. Better software and carefully chosen automation can move some of that routine burden back into processes the organization can reliably operate.

The owner still makes difficult decisions. The external market remains uncertain. The factory still needs experienced people. But fewer routine problems have to be solved by searching for information that should already be connected.

That is what I want industrial automation to accomplish: not the fantasy of a factory without complexity, but a factory whose complexity no longer demands the owner's attention at every turn.