Before you grow, understand how orders get out the door.
The Person Beside the Conveyor
Imagine a deliberately ridiculous situation. Two automated operations are connected by a conveyor. Product comes out of the first operation and travels down the conveyor toward the second. Between the two operations stands a person. Their job is to pick up each product, turn it 90 degrees, and put it back on the conveyor so it enters the next operation in the correct orientation.
Anyone who has spent much time in manufacturing would notice the person immediately.
Why automate both operations and leave someone standing between them turning every product?
But imagine the line is running well. Output is on target, quality is within spec, and the downstream operation rarely waits. The person turning the product seems to be good at the job.
Maybe putting someone there was the easiest way to solve the problem when the line was installed.
It’s possible that changing the equipment would have required more time or money than the problem justified.
What if someone was supposed to stand there temporarily and the temporary solution became permanent?
There may be absolutely nothing wrong with the solution. At today's volume.
Now imagine the company plans to grow substantially. The machines have additional capacity. There is room for more production. Sales expects considerably more demand.
What else has to scale with the output?
The person standing beside the conveyor is easy to see. Nobody evaluating the capacity of that line would leave them out of the calculation. If substantially more product has to move between those two operations, the employee’s work must be included in the discussion. The person is part of how the process produces its result.
What if the same thing is happening as an order moves through the company, except the people helping aren't standing where leaders can see them?
Before the Order Ships on Time
An order can receive a surprising amount of help before it ever ships on time.
Customer Service may need to figure out what lead time to assign because the system does not provide one.
Inventory may technically be available, but everyone knows that part of it has been set aside for a particular customer.
A planner may need to rearrange the queue for the new order to fit into the schedule.
Purchasing may call a supplier to see whether material can arrive sooner.
None of these actions is necessarily a problem. Some may be exactly the right response to the situation. Some may be part of how the company has chosen to operate. Other interventions may have started as temporary solutions and become part of how orders routinely move through the business.
The difference that matters here is visibility.
The person turning the product is standing in the middle of the process. Anyone walking through the plant can see that the line depends on that work. The people helping an order are scattered across the organization.
As the order moves through the workflow, one person may change a date. Another protects inventory. A third person changes the schedule. A fourth makes a phone call. The order may appear in a priority meeting or on a special list that is reviewed by not a small group of people. (Distribution lists for order exception reports tend to be long.) An experienced employee may simply know that this type of order requires a special pallet and send a message to the packaging supervisor.
Eventually, the order ships. On time and in full.
Another order may also ship on time and in full while requiring almost none of this additional attention. From an OTIF perspective, both orders are successful.
And they are. But they did not get out the door the same way.
This is where a strong on-time, in-full (OTIF) number can give leaders less information than they may think they have.
OTIF tells leaders whether the company kept its promise to the customer. It does not tell them how the company kept it. An order that moved routinely through the operating system and an order that required repeated discussion, schedule changes, special allocation, or individual intervention can produce exactly the same result on the dashboard.
That distinction may not matter much when the company is satisfied with current sales revenue.
It does matter when leaders expect the business to become substantially larger. Fast-paced growth is a good problem to have. But before assuming today's delivery performance will scale with the business, leaders need to understand how much help today's orders require to get out the door.
How Did the Order Get Out the Door?
Once leaders start investigating different orders, they may discover that orders take many more paths through the company than anyone realized.
Some orders may simply flow. The lead time is established, inventory is available, the order enters the schedule, production runs it, and the product ships.
Other orders take shortcuts. Someone moves the order ahead, bypasses a normal step, or makes a decision that gets it moving faster.
Maybe certain orders take long cuts. They require additional checks, conversations, approvals, handoffs, or decisions before they can continue.
Some of these “helps” become safety pins.
A safety pin may be a spreadsheet someone maintains because the information is not available elsewhere. It may be a standing meeting used to decide which orders should receive priority. It may be inventory that production segregates because it happens to meet tighter specifications for particularly demanding customers.
Safety pins are not necessarily bad. A safety pin can be an inexpensive and effective solution to a real problem. The important question is how much of the business depends on them. Sometimes the dependency is a person.
I have worked with schedulers who changed the production schedule based on who was going to run the line that day. They knew that line output depended partly on the operator, so they adjusted the schedule using information that wasn't reflected in the formal scheduling process.
I have worked with other planners who were expert jugglers. When there wasn't enough inventory to comfortably cover demand and customer lead times did not provide much room, the planners had to adjust. As more products competed for available capacity, they had to move orders around. When inventory accuracy wasn't quite what it could be or customer requirements changed, the planners just had to make it work.
Leaders relied on their skill and knowledge.
And it did work.
It can also happen on the production floor. A supervisor may spend part of the day making sure the lines have what they need to keep running. Material is not where it is supposed to be, so the supervisor finds it. A component is running short, so they move material from another line. Something expected from the warehouse has not arrived, so they track it down.
A good supervisor can make this look remarkably smooth. The line keeps running.
Part of the material-handling system may actually be the supervisor knowing what is missing, where to find it, and what can be moved without creating a bigger problem somewhere else.
The same dependency can sit in Customer Service. An experienced representative may know that inventory showing as available is really being held for a customer who hasn't ordered yet, or that a particular order requires special packaging or paperwork.
The order system may contain part of the information. The rest lives with the people who know how the customer is actually served.
These kinds of helps happen in manufacturing companies all the time. An occasional workaround, adjustment, safety pin, or special case does not tell leaders much about the operating system.
The picture changes when the helps become the normal way work gets done.
Imagine a company where the schedule starts changing more and more. Materials are routinely moved to keep lines running. Orders are discussed and reprioritized. Customer requirements are carried in people's heads. People become very good at recognizing what needs attention next.
Eventually, asking which orders simply flowed through the operating system and which ones were juggled becomes difficult because everything is moving all the time.
At some point, repeated adjustment stops being an exception to the operating system and becomes the operating system.
This does not mean the people making these adjustments are doing anything wrong. The opposite may be true. They may be exceptionally good at their jobs.
But a company can become dependent on its employees' ability to continually fill in what the operating system does not provide. They do this in addition to their regular jobs. They figure out how today's orders will move through the business because what is needed today can be very different from how yesterday's orders flowed.
The operating system does not need to know every answer in advance. Complex businesses will always require judgment. But a well-designed operating system should know how the answer will be reached.
That can be true even when the answer is complicated.
Consider Starbucks. People can order almost any kind of coffee or tea drink imaginable. There are variations in roast, flavor, size, milk, temperature, preparation, and who knows what else. A Frappuccino requires something different from a Matcha, which is different again from a Venti iced blonde vanilla latte with oat milk, three pumps of vanilla, two pumps of caramel, an extra blonde espresso shot, light ice, vanilla sweet cream cold foam, caramel drizzle, and cinnamon powder.
A complicated drink does not ordinarily require a meeting to figure out how Starbucks is going to make it. The barista works with standard sizes, ingredients, equipment, sequences, and a defined way to communicate what the customer ordered. Sure, it takes training and practice. But the operating model gives a trained barista a reliable way to determine how to fill the order.
The Starbucks operating model is designed to handle complexity.
It's not designed specifically to make a Venti iced blonde vanilla latte yada yada. It's designed so someone can, should the need arise.
In manufacturing, when people repeatedly have to reconstruct the information, priorities, relationships, rules, and decisions required to move individual orders, the organization can effectively begin creating an operating system for each order.
That is very different from an operating system that already knows how to process the complexity the company has chosen to serve.
What Exactly Is Scaling?
A highly assisted operating system can work extremely well at its current size. The challenge comes when the business grows enough that the people carrying part of the operating system run out of capacity.
Consider the expert planner. One planner may be able to juggle hundreds of orders, remember the important tradeoffs, adjust the schedule, and keep everything moving.
Then volume grows.
At some point, the answer cannot simply be for that person to work harder. The company needs more planning capacity. It is tempting to say, "Hire another planner." But what exactly needs to be duplicated?
The planner's job title is easy to duplicate. Their judgment may not be.
The experienced planner has learned which tradeoffs matter. They know which customer can wait and which cannot. They understand which supplier commitments are reliable, which products create problems on particular lines, and which schedule change is likely to create three more problems tomorrow. A smart new planner can learn those things. But not instantly.
The same issue can appear on the production floor. Adding another line or another shift may require another supervisor. The company can hire someone with the right skills, and it still takes time for that person to learn the operation well enough to recognize when to intervene and make the same kinds of tradeoffs.
If that knowledge is expected to reside with supervisors, the company needs a way to develop it. Or leaders may decide that some of the material availability, information, and decision making should be handled differently before the operation grows.
Customer Service can reach the same point. A small team may rely heavily on experienced representatives who know the customers and their requirements. As the business grows, the company must decide how the next person will know what the experienced representative knows.
Some of that knowledge may belong in training and experience. Some may belong in customer records, inventory rules, standards, or other parts of the operating system.
None of this means a scalable operating system should eliminate individual expertise. Some businesses deliberately depend on deep expertise. They simply design for the fact that expertise takes time to develop.
Law firms and engineering firms build businesses around expertise that can take years to develop. They know they cannot simply replace a professional with 20 years of experience.
Instead, they build depth. A person with 15 years of experience can take some of the load from the 20-year person. Someone with 10 years handles work appropriate to their experience while continuing to develop. Building expertise is part of the operating model, and so is the process for developing more of it.
Manufacturing leaders face the same design question.
Some complexity may belong with experienced people exercising judgment. If so, the company needs a deliberate way to develop enough of that expertise to support the growth plan.
Other complexity may be better moved into standards, information, tools, decision rules, training, inventory, capacity, or another part of the operating system.
For example, Customer Service may rely on one experienced person to determine the appropriate lead time for each order. Leaders could decide to establish standard lead times and have them automatically assigned when orders are entered.
Or the problem may be bigger than assigning a date. If planners are continually juggling orders because lead times, inventory, and available capacity do not provide enough room to fulfill demand reliably, the answer may be to rebalance those parts of the operating system rather than teach another planner how to juggle.
On the production floor, if supervisors routinely move material between lines to prevent shortages, leaders can ask what would need to change so the right material reaches the right line at the right time without depending on the supervisor to make it happen.
Usually, the answer will be some combination of interventions.
The important question is not whether people should use judgment. They should. The question is whether leaders have deliberately decided where the complexity will be handled and how that capability will grow with the business.
There is an informal warning sign worth noticing:
If the growth plan requires duplicating a pivotal person, leaders need to know whether they have a process for growing that expertise or whether they need to redesign the work that made the person pivotal.
The person beside the conveyor may still be the right solution. But if doubling the business means adding another person beside the conveyor, and then another, it may be time to reconsider where that work belongs.
Growth does not only scale orders and revenue. It scales the operating system required to produce them.
The whole operating system, not just the part that is visible most of the time.
What OTIF Leaves Unanswered
Strong OTIF is good news. It means the company is keeping its promise to customers.
But before using today's delivery performance as evidence that the operating system is ready for substantial growth, leaders may want to look underneath the number.
Follow a handful of ordinary orders that shipped on time and in full.
How did they actually get out the door?
Did they move through the operating system without attracting much attention?
Did they take a shortcut or a long cut?
Did someone have to change the schedule, protect inventory, find material, remember a customer requirement, or make a decision the normal process did not resolve?
Look for the helps and the safety pins. Then look beyond the handful of orders. How much of the company's order volume and sales revenue depends on this kind of assistance?
There is no universal percentage that separates a scalable operating system from one that is not. The complexity may be intentional. The people providing the help may be exceptionally good at what they do. Keeping some of the safety pins may be exactly the right decision.
The goal is to understand what is producing today's performance before assuming the same operating model can produce the same result with substantially more volume.
Two companies can have the same OTIF while relying on very different operating systems to produce it. Those differences matter when leaders decide how to scale the business.
In one, the capability required to process most orders is already built into the way the company operates. In the other, successful delivery depends on specific people repeatedly reconstructing the information, priorities, relationships, and decisions each order requires.
Before substantially growing the business, leaders should understand not only how the operating system fulfills today's orders, but what mix of orders is expected to produce tomorrow's revenue.
How well can the design of the current operating system support 10%, 20%, 50%, or 100% growth in revenue?