Why Your Production Schedule Is Wrong Before It Even Starts

Your production schedule looks solid when it leaves the ERP system. Order dates line up, rooting times make sense, capacity seems available, and material status says you're good to go. But here's the problem. That plan is still an assumption. It treats yesterday's data as if it describes the factory right now. Before the first operator even starts the first order. The real question is what changed since the last planning run? You don't need another dashboard. You need a feedback loop that adjusts the decision when the factory actually changes. Let's follow one order from the plan to the shop floor and see what happens. The familiar Friday afternoon scenario. Picture a plant running mixed products across three shifts. Shared machines, some specialist tools, and people who know from experience that a rooting can look clean in the system while causing real trouble on the floor. Let's Friday afternoon, the ERP system already released the schedule based on the demanded new the rooting times in master data, material status from purchasing, and the capacity calendar for the week. Nobody did anything wrong. That was just the information available when it ran. Now here's the catch. Much of that information already belongs to yesterday. A delivery that looked on track this morning now arrives late. The material for one order may come through the gate, but it won't reach the point of use when the schedule expects it. Receiving needs to check it, quality needs to inspect it, and the work order can't run just because a purchase order line says the material is coming. At the same time, a tool issue shows up at a shared machine. Maybe it needs adjustment, or the team needs a different tool from the tool room. Either way, a job that looked ready in the ERP system can't start at the plant time. Then an experienced operator calls in sick for the evening shift. The replacement can run several machines, but not all of them, and not every product family without support. That detail lives in someone's head, a skills matrix, or a spreadsheet on a shared drive. It usually doesn't travel into the released schedule. Meanwhile, a short stop hits a machine upstream. Nothing dramatic, a sensor fault, a jam, a reset, a few checks. Then production starts again. On its own, it takes a small slice out of the shift, but that machine feeds a shared cue that supports work due later in the day. Small changes build on each other. The planner now faces a schedule that still looks official, even though the sequence has drifted away from what people can physically execute. One order needs material that isn't at the line, another needs a tool that isn't ready, a third needs a person who isn't on shift, and the upstream delay threatens a job that will later need the same resource as a higher priority order. So the planner opens Excel. Nobody should be surprised by that Excel responds fast. A planner can move orders, add notes, color cells, call a supervisor, and send a revised file within minutes. When a plant needs to recover from a real constraint, waiting for a slow system update isn't an option. On the floor, supervisors start doing what good supervisors do. They use local knowledge. They know which order can run without a long changeover, which operator can help, and that a customer order looking urgent may actually be missing apart while another job keeps the bottleneck busy for the next hour. That local knowledge keeps production moving, but it can create a gap. The ERP still shows the customer promise date. Sales still see the same committed shipment, management still sees a plan assuming the original sequence, but the people closest to the work already know the plan has changed. Changes don't always get recorded in the same place. A sequence change goes through a quick conversation, a material issue shows up in an email, a revised priority lands in a spreadsheet, a supervisor tells the next shift during handover. By Monday, several people each have a reasonable version of what happened, and those versions don't fully match. This isn't a criticism of planners or supervisors. It's the normal result of a factory reacting faster than the systems that describe it. And yes, this is where Excel becomes the unofficial manufacturing control system. It fills the space between a static schedule and a changing shop floor because it moves faster than the formal process. Excel holds the exceptions, the calls, and the practical decisions that the formal process couldn't capture quickly enough. Through all of this, the customer date in ERP remains visible, but it starts to look less like a commitment and more like a hopeful memory from the last planning run. Think about that gap. The first schedule didn't contain bad intentions or bad logic. The problem is that a schedule document can't react on its own when material tools, people, and machines change around it. So we need to separate two things that often get treated as the same thing, the schedule you release, and the scheduling process that keeps decisions current once work begins. A production schedule is a decision about the future. You look at a production schedule and see columns, order number, due date, quantity, maybe a machine assignment, straight forward enough. But each one of those rows is actually a bet on what should happen next. Even if it just looks like a table someone exported from ERP, a line on the schedule says, "Job A runs before job B." It picks a start time, chooses a machine or work center, names the material, and counts on having the right people with the right skills available. All those promises sit inside a single decision to take a single order, due next week. The schedule might place its first operation on a machine at 8 in the morning, send it to inspection, then push it to the next process later that day. For that to actually work, the machine has to be free. The previous operation needs to finish on time. Material has to arrive at the right spot, and someone qualified has to be standing there ready to go. And the schedule also assumes that order won't collide with another one that needs the same resource more urgently. It assumes the cycle time you plan is still realistic. It assumes the setup fits in the time you allow it, and the next operation won't sit in a queue longer than expected. That's a lot of hidden assumptions packed into one line of work. People often talk about the schedule as if it reports what production is actually going to do. Here's a better way to think about it. The schedule chooses what production should try to do, based on whatever facts and rules were available at that moment. That distinction changes the whole conversation, because a decision about the future always runs into constraints. A machine can only process one job at a time. A fixture might only fit one product family, an operator may need a specific qualification, a batch might have to stay together. And a long changeover can make a perfectly sensible due date sequence impossible to run in practice. Capacity isn't an empty block on a calendar, it's usable time on real resources under real conditions. And those conditions shift, a plan start time gets less certain when the prior job runs long. A material promise gets less certain when that material needs inspection. A resource assignment gets less certain when the work centers actual state changes mid shift. None of this means planning failed. It means planning deals with the future that hasn't happened yet. There are also different levels of planning and mixing them together creates confusion. A plan usually works at a broader level. It answers questions like, what demand do we need to cover? Which week should we produce this product family? And do we have enough capacity and material across a longer horizon? A detailed schedule moves closer to the floor. It decides which operation runs on which resource in what order and within a more precise time window. Now you're dealing with finite capacity, not just broad demand coverage. Then you have a dispatch list. That's the immediate instruction for the floor. It answers a much more practical question, given the current situation, what should this person or this machine run next? Those are related decisions, but they aren't the same decision. The plan may say an order belongs in this week's production. The detailed schedule may reserve time for it on a resource tomorrow. The dispatch list may need to decide whether it can run in the next hour. If you treat all three as one fixed document, the floor ends up carrying the burden of resolving the gaps. A static schedule still has a place. You need a starting point. You need a shared intent about demand, priorities, capacity and customer commitments. Without that, every shift starts from scratch and nobody wants to run a factory by collective guesswork. But a static schedule is weak as a control loop. A control loop takes a planned action, watches what happens, compares the result with the intent and changes the next action when conditions call for it. A schedule that only gets published does the first part. It creates an instruction. It doesn't have a built-in way to revise that instruction when the factory produces new facts. That leaves people with an awkward choice. They can follow a schedule they no longer fits the work. Or they can adapt locally, which often keeps production moving but can detach daily decisions from the wider plan. So when execution changes who changes the decision, is it the planner after hearing about the issue later? Is it the supervisor at the resource? Is it a spreadsheet someone updates between calls? Or does the operating model give the right people current information clear constraints and a controlled way to issue the next dispatch decision? That question takes us directly to the limits of ERP planning. An ERP system can plan demand and commitments really well, but the factory changes at a pace and level of detail that broad planning cycles don't always capture. What ERP knows and what it cannot know alone. ERP earns its place at the centre of the business. It holds demand, customer orders, bills of material, purchase status, due dates, inventory records and the commercial commitments that teleplant why a given order matters. Without that information, production planning turns into guesswork. When an ERP planning run creates a proposed schedule, it works from the data the business has agreed to use. It reads lead times, it reads routing standards, it reads work centre calendars, material records, order priorities and the planned relationships between components and finished goods. That logic can be sound, but it only knows what reaches the model. Here's the thing, a routing might allow 40 minutes for an operation because that figure entered the system years ago or because it represents a standard rather than the current day-to-day result. The calendar might show eight hours of capacity for a work centre while the real resource needs a long setup, a tool check and an experienced operator who only works one shift. Those aren't small details when you're trying to decide what runs next. ERP can tell you that a purchase order has a due date. It can show that material has been ordered, received or allocated according to the business process, but the system may not know whether that material sits at the point of use waits for inspection, belongs to the correct batch, or can support the exact operation that needs it right now. The same gap appears with capacity. A work centre in ERP often represents a useful planning unit. It might refer to one machine, several similar machines or a broader area of the plant that helps with demand and broad load planning. Still, it doesn't automatically describe the current queue in front of each resource, the real setup already underway, or the tool condition that could stop the next job. And it usually can't see the human detail unless someone has built and maintained that connection. Who on this shift holds the right qualification? Who knows the process well enough to run a difficult product? Who has already been pulled to solve a problem elsewhere? Those facts change what capacity means. This isn't an ERP defect. It describes a system boundary. ERP manages the business view of production. It connects customer demand, supply, finance, inventory, purchasing, and order commitments. That role matters because production can't decide an isolation from the orders it needs to fulfill or the material it needs to consume, but shop flow control deals with a different clock. Planning may run overnight, once per shift, or at defined points during the day. A factory can face a disturbance between two machine cycles. A tool can wear out during a run. A material issue can appear when a batch reaches inspection. An operator can discover that the actual setup doesn't match the rooting assumption. The planning run doesn't become wrong because the ERP failed. It becomes older than the factory. That sounds obvious, but many operating models still act as if the released plant stays authoritative until the next formal update. People then create their own workarounds because the physical process can't wait for the next cycle. I think the more useful view is simple. ERP owns the business intent. It tells you what demand exists, what commitments matter, what material should support the work, and what the organization plan to produce. It should remain the backbone. It just shouldn't pretend to be the person standing next to the machine. For a schedule to stay usable, the business intent needs to meet the current production state. That means moving closer to where the schedule turns into physical work, where orders enter cues people set up resources and the factory starts producing facts rather than plans. Execute where the schedule meets the real factory. Here's where the plan hits reality. Once an order lands on the shop floor, planning hands off to execution. And that's when the MES, the operators, the machines, quality teams and maintenance all converge around the same physical work. The MES releases the work order and tracks progress. The operator reads the instructions, grabs the material, sets up the machine, and starts the operation. The machine runs, stops, alarms or waits. Quality inspects the first off-part or puts a batch on hold. Maintenance steps in because a fault needs attention before production can continue. None of that is theory. That's the factory deciding, minute by minute, whether the plan can actually turn into product. Think about one work order entering a machining area. The schedule says it starts at 10, but the prior order finishes late because the actual cycle time drifted. The operator needs a few extra minutes for setup. The fixture needs adjustment. Then the first part goes to quality, and quality spots something that needs clarification before the full batch can run. So the order didn't start at 10. It started when the conditions allowed it to start. That sounds simple, but it changes how you should think about execution data. Those actual start and finish times aren't just time stamps for a report later. Their facts about the capacity, the factory really used. The queue it created, and the choice is still available for every order behind it. Scrap changes the picture to. A quantity that looked available in the plan might no longer cover the next operation. A quality hold can pause work that technically looks complete from the machine's perspective. Rework can send material back through part of the routing, where it competes for the same resources as planned work. Changeovers tell a similar story. A schedule might reserve a standard amount of time for a product change, but the actual change depends on the product pair, the tool state, the material, and sometimes the person doing the work. A short delay in a changeover can shift the whole queue when the resource is already running near its limit. And then there are the small interruptions. A jam gets cleared, a sensor needs a reset. An operator waits for a forklift, someone checks an unusual part. Each event may look too small to trigger an urgent meeting, but the accumulated time can change what the shift can actually finish. That's why a work order produces facts the planning model couldn't fully predict. Planning estimates. Execution reveals. Execution has hard physical limits. One machine can't run two jobs at once, even if both look urgent in a priority report. One fixture can't support two parts at once. One qualified operator can't stand at two work centers during the same half hour, no matter how optimistic the calendar looks. The shop floor resolves those collisions every single day. Picture a supervisor at the start of a shift. Two orders need the same machine. One order has an earlier due date, but its material hasn't arrived at the line. The other order can run now, uses the same setup family, and keeps the resource productive. The supervisor has to decide whether to wait, switch, or prep something else. That decision usually happens in a call with the planner, a note on a whiteboard, or a quick discussion next to the machine. In many plans, that's not poor discipline. Its experience people handling conditions the formal scheduled in capture in time. Experience carries practical detail. A supervisor might know a machine can technically process an order but will struggle with the current tool. An operator might know a product needs extra care after a recent issue. Maintenance might know a resource can run, but only until a planned inspection later in the shift. The problem comes when those decisions disappear after the conversation ends. If a revised dispatch choice only lives on a whiteboard, the next shift may not know why the sequence changed. If a quality hold reaches the operator through a verbal message, the planner may not see the capacity effect until much later. If maintenance changes the usable condition of a resource, the schedule may keep assuming capacity that no longer exists. So execution needs more than a released work order. It needs a way to capture what actually happened around that work order with enough detail to support the next decision. That doesn't mean recording every human movement or flooding the cloud with raw machine signals. Factories already generate enough data to keep several consultants busy for years. The point is to capture the events that change your ability to execute work. A job started late, a machine stopped, a quality check blocked release, a change over took longer than expected. A maintenance action removed a resource from service. Those aren't just production records. They change the schedule's assumptions, while the schedule is still supposed to guide the day. Execution produces the signals, signals alone don't close the loop. Measure means more than collecting machine data. A machine can produce a lot of signals without telling you much about the production decision. It might report speed, temperature, vibration, current draw alarms, run state, and dozens of tags that matter to maintenance or process control. That telemetry has a purpose. But a machine event only becomes a production fact when you can connect it to the work that event affected, who or what perform that work, and where that work sits in the current flow of orders. Say a machine reports a 20-minute stop on its own that tells you a resource lost time. But you still can't tell whether the stop affected a rush order, a low priority replenishment run, a batch waiting downstream, or a job that had enough buffer to absorb the delay. The production system needs that surrounding detail. Tie the event to the work order, tie it to the operation within the routing, the product and batch involved, the specific resource, the shift, and a reason code people can trust. Then that same 20-minute stop starts to answer practical questions. Which order lost capacity did the stop interrupt a setup or a production run? Did it affect one batch that needs to stay together? Did it happen during a shift with limited labor? Was the cause of planned change? Material waiting, a quality check, a machine fault, or something else? That may sound like data modeling detail. It's not. It determines whether a planner can act on the event without calling half the plant to reconstruct the story. Think about an operator marking an order complete. Complete can mean many things, unless the event definition is clear. It might mean the machine cycle ended, it might mean the full quantity passed inspection, it might mean the operator finished their step and moved the batch to a queue. Each meaning changes the state of the next operation. So event definitions need agreement. Not perfect agreement in a workshop slide deck, but agreement that survives a Friday shift, a system update, and a handover between teams. Time matters too. You need timestamps that identify when an event actually occurred, not just when someone entered it later. If a job started at 9, stopped at 10, resumed at 11, and finished at 1. That sequence tells you far more than a single completion entry posted at the end of the shift. It shows actual runtime. It shows lost time. It may expose a weight before the job began. And it helps separate a routing estimate from the time the resource truly consumed. This is where many OEE conversations become incomplete. Overall equipment effectiveness can help you see availability, performance, and quality at a resource. It can show that a machine lost time, ran below its expected pace, or produced reject parts. That's useful. Nobody should dismiss it. But OEE doesn't decide which order should run next. A machine can show a good OEE result while the plant still misses a customer commitment because the wrong work set in front of the bottleneck. It can also show a poor result for a reason that has little impact on the current delivery risk. OEE measures how a resource performed. Scheduling needs to decide how limited resources should be used across competing work. For that, you need measures at the level where decisions happen. Q-time tells you how long work waits between operations. Actual cycle time tells you whether the routing still fits the process. Yield tells you whether the expected output will reach the next step. Availability tells you whether a resource can take work. Constraint use tells you whether the resource limiting flow spends its usable time on the work that matters most. Each measure answers a different part of the same question. Can this schedule still happen? A long queue may point to a blocked downstream resource. A cycle time drift may quietly consume the capacity the next order is expected. No yield may turn a material plan into a shortage. A resource might show available time on paper while a required tool, person, or support process limits the work in practice. Measure at the grain of the decision that usually means order, operation, resource, and time with enough context to explain the variance later. You don't need every signal from every device for that. You need reliable events with clear names, clear time logic, and a link to the production work affected. If operators, maintenance, quality, and planning all record the same event differently, the data moves faster, but the factory doesn't understand more. And that leads to the next problem. Data without shared meaning creates faster confusion. The data problem is usually a context problem. Here's what most factories actually run into. Plenty of data, but no shared way to describe what any of it refers to. Take one machine. In ERP, it shows up as a work center with some business-friendly code, while MES calls it a resource ID, maintenance tracks it by asset number, and the IoT layer sends signals under whatever controller tag or gateway name the engineer used when the system went live. Each of those systems is correct inside its own world, but none of those names talk to each other. And when the names don't connect, you cannot reliably link a production delay to the machine condition, the maintenance record, and the orders that were waiting for that machine. So people end up doing the joining manually. A planner sees an overloaded work center in ERP, a maintenance technician sees an alarm against an asset ID, and an engineer sees a stop event from a tag stream. Then, someone who knows the plant translates between all three, usually over the phone. That person essentially becomes part of the integration architecture. It works fine until they take a holiday. The naming problem is only one piece. The harder issue is that words that seem obvious end up meaning different things once multiple systems have to act on them. Take the word complete. To a machine, complete means the last cycle finished. To mess, it means the operator recorded the produced quantity. To quality, it means inspection cleared the batch. To the warehouse material reach storage. To planning, it means the next operation can actually start. Those are all different states, and treating them as one creates false confidence. Available creates the same problem. A machine may show as available because it isn't in an active production run, while maintenance has already marked it for a check. Material may show as available in inventory while it sits in quarantine. An operator may appear available in the workforce system while they lack the certification for the order waiting at the machine. And planned can mean a demand forecast, a released production order, a slot in a detailed schedule, or a supervises decision about the next job. If a team uses the same word for all those things, people can agree on the word while disagreeing on the work. This is why more event data doesn't automatically fix the problem. You can stream thousands of events from machines into Azure, store them in Microsoft Fabric, and build reports that refresh quickly. Yet a stream of timestamps and machine states can't tell you what an event means for the schedule, unless it connects to the product, the process, and the resource involved. Let's look at that stop event from a planning perspective. A system receives a message that resource A17 entered a fault state at 1412. That fact matters, but it doesn't yet answer the real planning question. Which operation was actually running? Which order sat in the queue? Which products can use another resource? Does the next operation depend on a batch rule? Is a specialist tool installed elsewhere? Does moving the work break a sequence rule that protects quality or reduces setup time? The event stream gives you a signal, but context gives you a decision path. In practical terms, the common language for that context sits in product, process, and resource relationships. Product means what you're trying to produce, including the material, batch, variant, and specification where those details affect the work. Process means the route through production, which operation comes first, what conditions release the next step, where rework returns and what sequence rules apply. Resource means more than a machine name. It can include the machine, the tool, the fixture, the operator skill, the inspection station, and the time when each one can support the work. When you connect those relationships, the factory starts to describe itself in a form that both people and systems can use. Now, a production order needs a particular operation that operation can run on certain resources, understated rules, and those resources need tools, materials, and qualified people. The order also connects to a due date and other orders competing for the same capacity. So when a stop event comes in, you can route it through those links. Instead of asking machine A17 stopped, should we turn the status red, you can ask, which released work faces a risk? What alternative work can run now? And which commitments change if this resource stays down for the rest of the shift? That's a much better question. It doesn't guarantee an easy answer. Factories have real limits, but it turns the issue from a disconnected alarm into a planning problem you can actually reason about. Here's the thing, this doesn't require one giant model of the entire company before you start. That approach can turn into a long data program that doesn't help the people running today's orders. Instead, begin where a recurring decision depends on facts, scattered across systems, then build the relationships needed for that decision. The model needs to be clear enough that a planner, supervisor, quality engineer, and data team can all recognize the same production state. If they can't, the system will only automate confusion faster. Once the factory can connect an event to the work at effects, it can do more than just react to each disruption. It can start asking what each disruption should teach the next planning decision. Learn, turn events into better planning assumptions. Once you can connect events to the work they affected, the factory can start learning from the gap between the plan and reality. Not by pointing fingers after a late order, but by asking which assumptions keep failing in the same way. One late job might come from a one-off problem. A supplier truck breaks down, a tool gets damaged, someone enters the wrong quantity, things happen. But patents tell you more, say an operation repeatedly takes longer than the routing time in ERP, not once, but across shifts, operators, and weeks. The standard might still describe how the process ran when the product launched, or how long it takes under ideal conditions, the right material, a clean setup, no normal interruptions. But production doesn't run under ideal conditions. If the routing expects 30 minutes and the work regularly consumes 50, every schedule built on that routing starts with capacity that doesn't exist. The planner sees a feasible week, the supervisor sees a queue that grows before the second shift begins. Both people may be working from correct information in their own system, but the planning assumption no longer matches the process. That gap needs a response. Sometimes the routing time needs updating, sometimes the work needs a different standard for a certain product variant, tool condition, or resource. Sometimes the issue isn't cycle time at all. The operation may wait for inspection, material movement, or an approval that sits outside the formal routing. Learning means finding the condition behind the gap. Set-up loss often exposes the same issue. A system may reserve a fixed change over time for a work center, while the real effort depends on the sequence of products, the tools needed, the cleaning task, or the amount of adjustment after the first piece. If the same product transitions keep taking longer, that's not just a bad day on the floor. It's a planning fact that hasn't reached planning yet. Quality creates another source of repeated loss. A hold can look like an isolated quality event until you see that the same product family, operation, tool, or material source keeps creating work that waits for review. Then the schedule needs to account for more than expected yield. It needs to account for the time and capacity tied up while the work remains blocked. Resource reliability needs the same treatment. A machine doesn't have to fail completely to create planning trouble. A resource that regularly loses short periods of usable time may still show broad availability in a capacity calendar while the work assigned to it keeps slipping in practice. That's the difference between a resource existing and a resource delivering usable capacity. Be careful though. Factories contain normal variation. A process may take longer because one order includes an unusual specification. A setup may run late because a new operator needs support. A quality hold may follow a genuine rare event. If you change planning data after every variance, the system starts chasing noise. The question isn't, did actual differ from planned? It will. The real question is, does this difference repeat often enough under clear enough conditions that the next plan should treat it differently? You need people from different parts of the factory to answer that well. The planner sees the effect on orders, capacity, and customer commitments. Production sees the work as it happens and can explain where a standard no longer fits. Maintenance understands whether lost time points to equipment, condition, or ordinary operating behavior. Quality knows whether a hold signals a repeat issue or an exception. Engineering can determine whether the process, tooling, or routing itself needs revision. No single team owns the whole learning loop. That shared ownership also stops a familiar argument. Planning says the floor didn't follow the schedule. The floor says the schedule ignored the work. Both statements can contain part of the story but neither repairs the assumption that caused the next schedule to drift. A useful review stays close to the decision. Take a repeated plan versus actual gap. Trace the conditions around it, agree what should change and record who owns that change. Maybe the response updates a routing standard, maybe a change is how a resource gets treated in planning. Maybe it exposes a process issue that needs engineering work before anyone edits master data. Either way, learning needs a path back into the next decision. Otherwise, the factory collects lessons, files them away, and rebuilds tomorrow's schedule from the same assumptions. Replan is not copy the spreadsheet and try again. Here's the thing about learning and manufacturing. It only matters when it changes what you actually do next. When a material delay hits, a machine drops out, quality holds a batch, or demand shifts overnight. The real question isn't whether someone can shuffle a few rows in a spreadsheet. It's whether the factory can produce a new, feasible decision from the state it knows right now. Picture a machine that fails halfway through a shift. The first reaction is usually simple. Move the work to another machine. But what about the second machine? It might already be loaded with work that's due sooner, need a different fixture, or have its required tool, still sitting on the failed machine. And the person available might not even hold the qualification for that product. Moving an order only solves a problem if the new sequence still works. The same logic applies to material. Say a late component blocks one order. A planner might pull another order forward to fill the gap, but that replacement order needs enough released material, the right batch status, and a route that can continue after the first operation. Otherwise, the plan just moves the waiting point downstream without solving anything. Quality holds create an even harder version of this. A batch can't simply disappear from the schedule because inspection stopped it. It might need a decision from quality, a rework path, more machine time, and possibly a different inspection step before it can re-enter production. The schedule has to represent that changed condition instead of quietly assuming the original quantity will show up at the next operation. So re-planning starts with the constraints that remain true. Which resources can run this operation, which tools and fixtures they need, which operators can perform the work. Whether this batch must stay together, if a product can run after another without a cleaning step, and whether product rules prevent a simple resource swap. These details stop a schedule from becoming wishful thinking. An effective re-plan compares options before anyone releases another dispatch decision. One option might protect the highest priority customer order, but delay several lower priority orders. Another might keep the bottleneck loaded while waiting for material, but create a larger queue later. A third might require overtime and approved substitute material or a change to the customer promise. None of those are just scheduling choices. They are operational trade-offs. The system should show the effect in plain terms, which order now finishes late, which resource moves beyond its usable capacity, which work gets displaced, where recovery happens, and what assumption that recovery depends on. If the answer is, "We'll catch up later," then it isn't an answer yet. This is where many spreadsheet-based revisions become fragile. A planner might create a sensible local sequence without realizing the downstream work center now carries more work than it can complete. Another person might change a priority without seeing the tool conflict it creates. The sheet can hold a revised order of work, but it can't reliably test every condition unless someone has built those conditions into the process around it. And even then, the human decision still matters. No system can decide by itself whether a strategic customer should take priority over a group of smaller orders. No algorithm owns the commercial impact of accepting a late delivery, the workforce impact of overtime or the process risk of a rushed recovery. Those decisions belong to people with the authority to make them. What technology can do is bring the facts, rules, and consequences together before that person approves a change. The planner should see the choices. The supervisor should confirm whether the proposed sequence can run. Quality and maintenance should provide the conditions that limit release or capacity. Then somebody owns the decision and releases a revised dispatch instruction that the floor can trust. That approval needs to leave a record, not as bureaucracy for its own sake, but because the next shift needs to know what changed, why it changed, and which assumptions now sit behind the new sequence. A replan is not a pretty aspred cheat. It is a controlled response to a changed factory state. And once you treat it that way, the five stages stop looking like separate activities. Planning starts the decision, execution tests it, measurement captures the result, learning updates the assumptions, and replanning turns the current state into the next workable instruction. The closed loop from plan to replan. Think of the loop as a continuous operating process, not a chain of software handoffs. It begins with planning, using the best facts available about demand, due dates, materials, routes, capacity, and the rules that constrain the work. That plan gives everyone a shared direction, but it should also state what it assumes about resource time, material readiness, and the order in which work can flow. Those assumptions need to stay visible, not buried in a document nobody reads. Then production executes against a clear dispatch decision. Not a vague priority list that leaves each shift to interpret what urgent means, but a practical instruction about what a resource should run next, with the conditions needed to run it. As work moves, the factory records events that change the decision. An operation starts, a job completes, a batch waits, a resource loses usable time, or an expected output doesn't arrive. The loop depends on the link between that event and the work. If an event cannot connect to an order, operation, resource, and point in time, it might still help maintenance or engineering, but it cannot reliably update a production decision. A schedule needs facts at the same grain as the choices it asks people to make. That means measuring at the level of order, operation, resource, and time, not at the department level. A daily total can tell you that a department finished less than planned, but it cannot tell a planner which operation consumed unexpected time, which order created a queue, or whether a resource can still support the next dispatch instruction. For the loop to work, the measurement follows the work through the factory at the level where capacity and sequence decisions actually happen. Those facts then support learning. But learning should not mean a weekly meeting where everyone explains why last week went badly. It means comparing what the plan expected with what execution repeatedly delivers, then tracing the conditions behind the gap. Maybe a route only works within its planned duration when a certain tool is ready. Maybe a resource loses capacity during a recurring handoff. Maybe material reaches the plant on time but becomes usable too late for the order sequence. The factory learns which conditions change its ability to make a promise, and that learning needs to update the next decision. Not live in a report nobody acts on. Replanning then starts from the current production state. It asks what work is complete, what work is blocked, which resources can actually run, which material is ready, and what constraints still apply. From there, it compares feasible choices and issues a new dispatch decision with a clear owner. The word feasible matters. A new schedule does not become useful because it improves a delivery date in a spreadsheet. It becomes useful when the people running the work can execute it without discovering hidden conflicts one hour later. That means the replan must respect the conditions learned from prior execution along with the conditions that exist right now. Over time, better assumptions feedback into planning. The next plan does not start from a fantasy version of capacity and it starts from a closer view of how the process performs where the recurring limits sit and which rules shape the order of work. You will still face disruptions and no data model can remove machine faults, late deliveries, or quality issues. But the plan gets less detached from the factory each time the loop closes. This also changes what success looks like. You are not trying to create one perfect schedule at the start of the week and defend it against reality. You are trying to run a controlled cycle where plans, facts, decisions, and revised instructions remain connected. Planning sets intent execution produces evidence, measurement gives that evidence a usable form, learning changes the assumptions and replanning turns the current state into action. That is the feedback loop most factories actually need. Yet many plans still operate through a much less connected pattern. The ERP releases a schedule, the floor adapts around it and the real decisions happen outside the systems meant to govern them. The broken loop ERP static schedule excel firefighting. Here is the problem most manufacturers don't talk about. ERP releases a schedule and that schedule takes on a life of its own the moment it leaves the system. Sometimes it gets printed and taped beside a work center. Sometimes someone exports it into a spreadsheet. Sometimes a planner emails a file to supervisors who turn it into a shift plan people can actually act on. The format changes but the pattern stays the same. A planning decision leaves the system and then the factory has to scramble to catch up. And the factory almost never follows it exactly. Material shows up later than planned. A machine takes longer to come back online, a job hits the floor with instructions nobody can follow. A priority customer calls so a supervisor sees a practical sequence that keeps work moving even though it doesn't match the released order. People adapt locally because they have to and that local adaptation is often what keeps the plant running. A supervisor might move an available job ahead of blocked work and operator switches to another task while waiting for a quality check. A planner protects a customer order by changing the sequence for one resource. Each choice makes sense in the moment, especially when the person making it understands current conditions better than the original schedule did. But the formal schedule doesn't always hear about the change. Instead the exception ends up in a spreadsheet. It starts as a few notes beside work orders, then grows into a color coded file that tracks what actually ran, what couldn't run, which orders need attention and which promises now look shaky. Before long the spreadsheet holds the most current version of production reality. Not the ERP schedule, the spreadsheet. That file might be maintained by a very capable person but it sits outside the systems that hold order, material, quality and capacity records. Its rules depend on formulas that only one or two people understand. Its latest version could live in a shared folder, an email thread, or on someone's desktop with a name like production plan final final Friday. Manufacturing has seen worse file names but not by much. The problem isn't that a spreadsheet exists. The problem is the production decision splits across different places. ERP carries the original intent, the spreadsheet carries the exceptions, the shop floor carries the immediate sequence. None of those views fully represent the other two. Then the revision start traveling. A planner emails an updated file, a supervisor calls another area for help. Someone messages about a material issue. At shift handover, an operator explains the next order shouldn't run yet even though it looks ready in the schedule. Another person remembers a tool needs attention before a certain product comes back to the machine. Critical scheduling knowledge becomes something people carry in their heads. That creates a time gap between the real factory and the view seen by people further from the work. Leadership opens a report showing late orders, output against plan and resource performance. That report may be accurate based on the latest approved data load but by the time it appears operators have changed the sequence twice. A report might show order 4-8-12 scheduled on a resource this afternoon while the supervisor knows the order moved, the material is still blocked, and another job now occupies that slot. Leadership sees a lagging picture of the plan. The floor deals with the live consequences. That leads to some frustrating meetings. One group asks why the schedule wasn't followed. Another group explains why following it would have stopped production. Both groups have reasonable information just from different moments and different systems. The argument sounds like a discipline issue but the deeper issue is that the decision path broke after the schedule left ERP. A printed schedule can't absorb a changed condition and exported schedule can't test whether each local adjustment still fits the wider production picture. Email notifies people but it doesn't create a shared current state and memory works surprisingly well right until the person holding it goes home so the broken loop doesn't fail because people refuse to use systems. It fails because the system of record and the system people use to react become two different things. The official schedule describes the plan. The actual production sequence emerges through exceptions, calls, local judgment and files trying to keep pace with the day. That's inefficient and sensible people keep using this pattern because it solves a real problem faster than the formal process does. Why Excel survives on the shop floor? So why does Excel stick around on the floor? Because it solves an immediate problem. A planner can change a sequence in seconds, add a note the local team understands and try a different order of work without waiting for an interface, a workflow or an overnight planning run. People already know how to use it and that matters when the shift has started. A customer is waiting and the person making the decision needs something more useful than a ticket in an IT backlog. A spreadsheet handles exceptions well because it doesn't ask many questions. You can add a column for a tool issue, write a comment about a material check, mark an order as only run after approval and move on. Formal systems tend to need a defined field, a status, an owner and a process step before they accept the same information. That discipline helps later, but it rarely helps when somebody needs to decide what runs in the next hour. There's another reason Excel hangs around. It holds knowledge the formal model never captured. A senior planner knows two products technically share a resource but shouldn't follow each other without extra cleaning. A supervisor knows one setup only runs smoothly with a certain fixture and a person who has done it before. Someone in the tool room knows a tool marked as available is really available only after a quick inspection. That knowledge lives in people, habits, notes and old spreadsheets. It's very accurate, but it isn't visible to everyone who needs it. If a system takes too long to react, people work around it and they should. Production can't pause just because the approved workflow needs three screens, two approvals and a sync job that finishes after the shift ends. The flow needs answers as fast as the work moves, so I wouldn't frame Excel as the enemy. That misses the point. A spreadsheet often shows you where the factory has a real decision problem with no formal way to handle it. If planners keep maintaining a separate list of material ready orders, the issue isn't that they enjoy typing into cells. The issue is the official process doesn't give them material readiness in a form they can trust for dispatch. If supervisors maintain their own skill matrix, system adoption isn't the problem. The system may not describe who can run what under actual shift conditions. When someone tracks setup families outside the schedule, they're protecting capacity, the planning logic doesn't yet understand. Excel is the symptom, missing knowledge is the condition, but the risks are real. Two planners can open the same file and create two different futures for the same work center. A supervisor acts on a printed copy while another version sits in a shared folder. A formula changes, a filter hides an order and the person who built the logic is the only one who can explain why a job moved. Then there's the audit problem. When a delivery date slips, you need to know who changed the sequence, what information they used, and what trade-off they accepted. A spreadsheet can record that if the team has a disciplined process, but in practice, many changes arrive through edits, comments, calls, and handovers that leave no clear trail. That becomes fragile when shifts change. The day shift understands why an order moved behind another one. The evening shift sees an order that looks late, a schedule that looks outdated, and maybe a note with no context. People then spend time rebuilding the reasoning instead of running the work. None of this means you should ban Excel. Banging it usually drives the same behavior into private files, paper notes and messages, and that's not progress. It just makes the decision path harder to find. The better goal is to absorb the knowledge Excel carries. Find the recurring exceptions. Listen to the planner who changes the same field every week. Ask the supervisor why they ignore a sequence rule. Look at the notes around the work that always creates confusion. Those aren't annoying edge cases. They're clues about constraints, states, and decision rules. Your formal systems don't yet represent. Some spreadsheet work will remain useful. People need room to explore options and think through a problem. But the facts behind a release production decision, the rules that shape it, and the reason for a change shouldn't depend on a file only one person can interpret. That missing capability sits between collecting production data and telling the floor what to run next. The factory needs a shared way to turn current conditions and practical knowledge into a decision people can execute. The missing layer, production context, and decision logic. So here's the real issue. Excel holds all that knowledge the formal systems never catch, which means you need a model that replaces that hidden layer. I'm not talking about another dashboard or a bigger pile of machine data. You need something that answers a direct production question. What can run on which resource at what time and under what conditions? That model connects the work to everything required to perform it. Every production order has one or more operations and each operation needs a process route, suitable machines, material, a tool of fixture, and sometimes a person with a specific skill or certification. Those links have to exist before an exception ever happens. If you try to build them after the fact, you're already behind. Think about an order for a particular product variant. It needs machining, then cleaning, then inspection. The machining operation might run on two machines, but only one has the right fixture installed right now. The other machine can still run it, but only after a tool change and only if a qualified operator is on shift, that's production context. Without it, your system sees two identical machines. With it, you see one machine that can run the order now and another that could run it later if several conditions come together. Those are very different scheduling options. Product, process, and resource relationships give the factory a common language for all of this. The product tells you what you're making and the rules that follow that product. The process gives you the route, the operation sequence, and any conditions that control movement through the route. And the resource tells you what can perform the work, but also what that work depends on. Machines, tools, fixtures, people, inspection stations, and available time. Now, a resource is rarely just a machine. Take a furnace. It may have open calendar time, but it can't accept every job waiting outside. Load size and temperature profiles matter. Certain materials may not share load and a batch may require traceability rules that prevent mixing. The schedule needs those conditions. If it wants to propose a load, people can actually run. Without them, you're just guessing. The same pattern shows up in food, chemicals, medical devices, aerospace, and discrete assembly. An allergen rule can force a cleaning sequence. A certification rule can limit an operation to certain people or resources. A setup family can make one job a better next choice than another, even when the second job has an earlier due date. These aren't annoying exceptions around the schedule. They are the schedule. That changes how we think about constraints. A constraint isn't just something that blocks an ideal plan. It describes the real conditions that make a production decision safe, legal, practical, and possible. Some constraints come from the product, some from the process, others from the resource, the workforce, quality rules, or the order sequence already in progress. The model doesn't need to make every rule mathematically complex. It just needs to make them explicit enough that people can see them, challenge them, and use them consistently. There's another distinction that matters here. Plan state versus current state. Plan state describes what the schedule expects. A machine to free up at a certain time, a tool to be ready, an operator assignment, an available batch, and a sequence of work that should fit the capacity model. Current state describes what the factory can support now. A machine might still be occupied, a tool might be an inspection. A person may have moved to another area. A batch may wait for release, the plan state can stay useful as intent, but dispatch decisions need the current state. Otherwise, the schedule keeps reserving capacity the plant can't use. That brings us to decision logic. Decision logic takes a change condition, checks it against the product process and resource relationships, then produces alternatives that respect the rules. It can ask if this order cannot run now, which other released order can run on this resource without creating a material conflict, breaking a sequence rule, or consuming capacity needed for a higher priority commitment. That's a lot more useful than a red alert beside a machine name. The result doesn't need to be one automatic answer. In many cases, it should present a small number of feasible choices, explain the conditions behind each and leave the trade-off with the planner or supervisor who owns it. You're not trying to model every thought in an experienced supervisor's head. You're moving the recurring parts of that reasoning, out of private memory, and into a shared decision process. Once that model exists, one disruption can travel through the factory in a much more useful way. Let's make the whole idea concrete with a single machine stop. A machine stops, and the schedule starts lying. Picture a critical machine stopping halfway through an afternoon shift. The operator reports a fault, maintenance starts diagnosis, and the machine that carried a large share of a product family can no longer produce. The first dashboard status might turn red. That part is easy. The useful question begins one level later. Which operations depend on that machine? Which orders sit behind them? And which customer commitments now depend on how long the machine stays unavailable? Say the resource currently runs order 4.8.12, which needs another two hours of machining before it can move to its next operation. Behind it sits order 486 due tomorrow, and then a smaller order for a customer shipment later in the week. The schedule may show all three as planned and even continue to show expected finish times. But those finish times now describe a factory that no longer exists. A machine stop doesn't just remove capacity. It changes the sequence of decisions around that capacity. The order in progress may need to restart, continue somewhere else, wait for repair, or move into a recovery path that consumes time not included in the first plan. And the effect moves quickly. The plan needs to know whether other resources can perform the affected operation. Can run the same product is not enough. One alternative machine may process the product only with a certain fixture. Another may need a tool currently in use, and a third may have the technical capability but lack an operator with the right qualification until the next shift. So the list of alternative resources gets shorter as the actual conditions enter the decision. Picture two machines that look interchangeable in a broad capacity model. The first has the right tooling and an open window after its current job. The second has a queue of work that feeds a different customer commitment. Moving the failed machine order there pushes that queue into the next shift. Both machines may look like capacity, but only one may create a workable recovery option. Even that option needs checking. If the affected order moves to the first machine, what happens to the job that machine was supposed to run? Does it wait safely? Does it need to reach a downstream process by a certain time? Does postponing it create an empty period at another constrained resource later in the day? This is why local rescheduling can create a second bottleneck without anyone noticing it first. You solve the machine problem at one work center, then move the pressure to inspection assembly, coating, packing, or another process further along the route. The order may finish the failed operation, but it can still miss its customer date because the recovery decision created a queue where the original schedule expected open capacity. A red status icon cannot reason through that chain. It can tell you the resource stopped, but not which order should move, which should wait, or which customer promise takes the least damage that needs a set of feasible options. One option might keep the order on the failed machine and protect its queue position if maintenance expects a short recovery. Another might move the order to an alternative resource, accepting a slip on a different order. A third might change the sequence across several resources to protect a customer date, while clearly showing the displaced work. None of those choices is automatically right. The right one depends on the current queue, actual capability, available tools, qualified people, and the commitments the business has decided to protect. That's the level where a planner and supervisor need support, not a system that claims it can optimize the factory with a button press. Factories tend to object to that sort of confidence. They need a system that shows the available choices, the constraints behind them, and the consequence of each choice before someone releases a new instruction. The machine fault then becomes a controlled scheduling question rather than a chain of calls and guesses. Material disruptions follow the same pattern. A component can look available in a purchasing view, yet still block the work that needs to run next. Material availability is a scheduling constraint, not a purchasing report. Material sets the same trap. An ERP status can look perfectly fine, but that doesn't mean the material can actually support the next production operation. Now here's where the disconnect shows up. A buyer sees a purchase order arrived, or an expected receipt falls inside the delivery window. The ERP shows the quantity as on hand, allocated, or due today. But none of that guarantees an operator can walk over, pick the material and start the job. The material has to be physically whether work happens with the right quantity and quality status, and it has to arrive at the point of use before the operation needs it. That seems basic, but the single word available hides all those conditions. Take a typical scenario, a work order due to start after lunch. Purchasing reports the component arrived first thing in the morning, so the planner sees a receipt. But part of the delivery sits on the receiving dock, part waits for incoming inspection, and the usable quantity at the line doesn't cover the full order. The component arrived, but the production material didn't. Partial deliveries create the same problem in a different form. You have enough material to begin the order, but not enough to complete the batch or feed the next operation. Starting anyway, burnt setup time creates work in progress and leaves half-finished product waiting for the balance. Sometimes that's the right call. Often it isn't. A substitute material can look like an easy fix, until you ask whether it has approval for the product, needs a different process setting, or requires separate batch trays. A material planner sees an inventory alternative. Quality, engineering, or the customer agreement sees a restriction that stops the substitution cold. Then you run into batch rules. In many factories, material can't move through production as one anonymous quantity. A batch may need full traceability through a route, a lot may be locked to a specific customer order, and material can sit blocked because inspection hasn't released it, shelf life changed, or a deviation needs review. The schedule has to know the difference. For a work order release material readiness is more than a green status against a bill of material line. The system or planner has to check the quantity needed now, the quantity needed to finish the work, the storage location, the quality release state, and the timing of when the operation will consume it. Consumption timing matters more than most people realize. A job might need one component at the start, another part way through, and packaging only near completion. If the schedule treats all material as a single yes or no condition, it may hold a job unnecessarily, or start work that hits a preventable stop later, that changes how you replan after a material problem. The easy move is to pull any order forward that appears ready, but that creates future starvation. You could use the last available material on a lower priority order and then discover the order tied to a firm customer commitment can no longer run when its resource becomes free. That's why the decision has to look beyond the next open slot, which orders can really run with the material physically released today, which material allocation protects the customer commitments the business cares about most. If you pull one order forward, does the remaining material still support the next constraint in the route, or do you simply shift the shortage to a later shift? A material aware schedule can answer those questions in a practical way. It doesn't need to predict every delivery perfectly. It needs to distinguish confirmed physical readiness from a purchasing promise, and then show the consequence of each sequencing choice. That gives the planner a more honest view of the customer day too. A due date in ERP is a commercial commitment. The factory can only meet it if the work receives usable material at the right time, moves through the route, and finds capacity at each required operation. When material status changes, the commitment risk changes with it. That connection should travel both ways. Production needs to see which orders carry the greatest customer exposure, and commercial teams need to see when a material restriction has changed what the factory can honestly promise. Material isn't just a purchasing detail. It shapes what work can happen next. Once material can block, delay, or redirect work, quality needs to enter the same feedback loop. Quality events change more than yield. Quality events change the schedule long before you see them in a yield number at the end of a shift. Take an inspection that finds a defect in a batch after its first production step. The affected quantity sits on hold while quality investigates. That work can't move to the next operation, can't count as available output, and may prevent the next resource from receiving the load it expected. A non-conformance changes the state of the work in a real, measurable way. The batch needs a disposition decision. It could be scrapped, accepted under a defined deviation, sent for rework, or split into good and suspect quantity. Each path changes the schedule differently because each path changes both the available inventory and the capacity still required. Re-work is where the first schedule often loses contact with the factory. A routing assumes the product moves from operation one to operation two then into finished goods. But a quality issue can send it back to an earlier step add cleaning add inspection require a different machine or hold it until an engineer approves a path forward. The work returns to the factory, but it returns with a new demand for time and capacity and that demand competes with planned work. If rework needs the same constrained resource that already carries a full queue, somebody has to decide what moves. You can't simply add the rework order to the end and assume the customer date stays intact. You also can't treat the quantity as available just because the first operation finished. Until the batch meets its release condition, it remains uncertain that release condition needs a clear definition it might be an inspector approving the result, quality signing off on a deviation or a rework operation finishing and a second inspection clearing the batch. Different products and processes need different conditions and planning needs access to them. Otherwise the schedule sees output where the factory sees blocked work. Inspection lead time matters too. A batch might finish an operation at 10 in the morning but if inspection can't review it until the afternoon the next step can't start until then that waiting time becomes a hidden part of the route especially where inspection capacity or specialist approval limits flow. You don't have to turn every quality check into a scheduling crisis. Many checks happen quickly and predictably so they can sit inside a normal routing assumption. The problem begins when the plan treats variable release time as if it were instant. Then the scheduled borrows capacity from a future that may never arrive. The same goes for disposition. If a batch sits on hold for two days because the decision path is unclear, that delay isn't just a quality concern. It affects work in progress, available stock, downstream machine loading and any order that expected the batch to feed the next stage. Quality status needs to travel with the production state. For each relevant event capture enough detail to support a real decision. What failed? Which product and batch it affects? What quantity is blocked? The planned disposition? The route if rework is required? The expected inspection or approval lead time and the condition that releases the work back into the schedule. That gives the plan something usable. Instead of a vague note saying quality issue they can see whether the order needs another operation, whether it can continue after approval, whether a substitute batch exists, and what extra capacity the recovery path consumes. Quality still owns the technical decision. Planning can then model its operational consequence. Over time, those records also reveal repeated disruption. You might see a certain product variant repeatedly waiting for a specific inspection, a tool producing defects after certain run length or one process step, sending work into rework far more often than the routing assumes. You don't need to assign blame to see the pattern. You just need to connect the quality condition to the product process and resource involved. That learning can change the next plan. It may lead to a better process standard, a different inspection assumption, a maintenance action, or a more realistic route for work that carries no risk. The idea isn't to schedule failure as normal. It's to stop pretending that repeat quality conditions have no effect on capacity and dates. A customer commitment only becomes credible when the plan includes the conditions required to release the product. Material needs to be ready, yes. Capacity needs to exist, yes. But the work must also meet the quality conditions that allow it to move through the route and become usable output. People and tooling create the same kind of limits even when the machine calendar looks wide open. Finite capacity means real resources, not calendar hours. People talk about capacity like it lives inside a calendar. A machine has eight hours in a shift, maybe three shifts a day, and the schedule treats those hours as available production time. That sounds fine on paper. But the factory knows better. Capacity comes from a working combination of resources. You need the machine, sure. But you also need the right operator, the correct fixture, a tool that passed inspection, material ready at the point of use, and support from quality, maintenance, or internal logistics. If any one of those pieces is missing, the machine calendar may look wide open while the operation simply can't run. A work center doesn't produce on its own. Let's zoom out for a second. Picture a machining cell with six hours of unassigned time. On paper that looks like free capacity. But the job waiting for that cell needs a fixture that stuck on another machine until late afternoon. The operator on the next shift can run the cell, but they're not certified for this product. Meanwhile, the first piece inspection needs a quality technician whose shift ends before setup finishes. Those six hours are not usable capacity for that job, not even close. That's where nameplate capacity and usable capacity part company. Nameplate capacity describes what a resource could produce under ideal conditions. Usable capacity is what the factory can actually commit after you account for planned maintenance, shift patterns, tool availability, staffing, product rules, setup time, and the ordinary operating limits that come with real production. Both numbers matter, but they answer different questions. Nameplate capacity helps with long-term investment and broad demand planning. Usable capacity needs to drive the daily production decision. If the schedule fills every calendar hour based on nameplate time, you start the week with no room for changeovers, checks, planned maintenance, handovers, or the smaller delays that come with actual work. Then every disturbance looks like poor execution even when the plan left no realistic space for execution in the first place. Maintenance windows make this really clear. A machine may show is available every weekday, but the maintenance team needs regular access to keep it running well. That work protects the machine's ability to run later. If you put it off the plan to build a prettier schedule for one day, you end up with a less reliable resource for the next month. Maintenance time isn't lost production by default. It's part of the capacity model. People bring another limit that enterprise calendars tend to flatten. A person can be present, trained, and assigned to a department, but that doesn't mean they can release every operation. Some work needs formal certification. Some needs experience with a specific process or product family. Some needs two people working together for safety reasons. A schedule that ignores those rules creates false choices. You can assign an order to a machine that has free time, then discover a dispatch that no qualified person can run it. The machine stays empty, the order stays late, and the schedule reports capacity that only existed in a database. That's why WorkForce Data needs more than a headcount. It has to describe who can perform which work, under which conditions, and during which shift. High Mix production adds another complication. The sequence changes capacity. If ten jobs need the same resource, the order you run them in can change the total time required. Two products might share tooling, setup settings, cleaning conditions, or inspection steps. Running them together can cut, change over time significantly. Separating them can eat hours that a simple rooting standard never captures. The opposite can happen too. Two jobs might look similar, but require a full clean down between them. Slap them back to back because their due dates are close together, and you turn an apparently open day into one dominated by changeovers. The sequence isn't just a preference, it changes the capacity available to everything else on the schedule. That doesn't mean every due date should bow to the most efficient setup pattern. Customer commitments matter, and sometimes a less efficient sequence protects the right order. But the tradeoff needs to be visible. You should know when you're choosing a due date priority that consumes more usable capacity and which other work that choice displaces. Feasibility comes first. You can rank orders by due date, customer priority, margin, or any business rule you like, but it still has to pass the physical test. Can the factory actually run this work with the people, machines, tools, fixtures, support steps, and time that's really available? If it can't, the due date remains a request, not a production promise. That distinction leads into another common mistake. Many manufacturers can see the gap between plan and actual in a report. Spotting the gap helps, but it doesn't tell the planner which move to make next with the capacity that's left. Dashboards explain yesterday, the loop must guide the next move. A Power BI report can tell you a lot about production. It can show plan versus actual output cues that keep growing, orders at risk of being late, and overall equipment effectiveness across the resources that matter. That shared view helps team stop arguing over whose number is right and start asking why the number changed. But here's the catch. A dashboard usually answers a backward-looking question. What changed? Where did output fall behind? Which work centre missed its planned hours? Which orders now look exposed? These are useful questions and plenty of factories still struggle to answer them with confidence, but they don't automatically answer the next one. Which sequence can still run? Consider a planner staring at a report that shows a cue building in front of a bottleneck resource. The same report reveals a drop in OEE, a rise in actual cycle time, and several orders moving toward their due dates. That tells the planner where the pressure sits. It does not tell them which job should run next without breaking a material rule consuming a needed tool or pushing another customer commitment into danger. A dashboard describes the current condition. Decision support needs to test a choice against that condition. That means it needs constraints. The rules that limit what can happen. It needs objectives because not every order carries the same business consequence. And it needs a way to compare scenarios before someone tells the floor to change direction. Say you have two realistic options after a delay. One sequence protects the earliest customer date, but creates more setup time. The other groups similar work reduces the setup burden and still leaves one lower priority order late. A report can show the late risk around both orders, but decision support should show the consequences of choosing either path. This distinction matters because manufacturers often respond to a visibility gap by building another dashboard. Then another appears for maintenance, another for quality, another for material shortages, soon there's a report for every pain point and the planner still opens Excel when the shift needs a decision. More reports don't close the loop. Reports should help the factory build trust in the facts. They can expose where the plan and actual work diverge. They can reveal where event timing is missing, where resource names don't match across systems, or where a status means different things to different teams. That is useful work. Now here's where it gets interesting. If a Power BI report shows that a queue grows every time a certain product family reaches inspection, the report has done its job. It pointed to a condition worth investigating. The next part requires a decision process that can account for inspection capacity, current work, priorities, and the choices available to the planner. Think of reporting as the place where the factory can agree on the question. It should not pretend to be the place where every answer appears automatically. A chart may identify the constraint, but it won't necessarily decide whether to move work, wait for capacity, approve overtime, or change a customer promise. Those actions need context, rules, and accountable people. That also keeps the conversation around dashboards more honest. Power BI can give production teams real-time visibility when the data arrives with enough speed and meaning. It can support daily management, exception reviews, and plan versus actual analysis. It can make hidden gaps visible. Still, a dashboard doesn't become a scheduling engine just because it uses live data. The factory needs both. It needs reporting that people trust, and it needs a path from reported conditions to test it, approve production decisions. Without that path, the dashboard becomes a very polished way to watch the same firefighting happen again and again. So now let's connect this to Microsoft, but keep the roles clear. The data foundation can bring ERP, MES, quality, maintenance, and operational data into a shared place. That helps the loop. It doesn't replace the factory knowledge and decision logic that turn data into the next executable instruction. Microsoft fabric as the data foundation, not the factory brain. Microsoft fabric gives you that shared data foundation. It pulls together data from ERP, MES, quality systems, maintenance records, and IoT sources into govern data products. So your teams work from the same set of facts instead of building a new extract for every question. Here's why that matters. The loop crosses system boundaries. A plan might start in ERP while the actual work comes from MES and a quality hold might sit in the quality system while a maintenance event sits somewhere else as a machine signal arrives through IoT. If each team only sees their own slides, nobody can trace a change condition all the way to a production decision. Fabric gives those sources a common place to meet. Getting the data in one place is only half the job. The records need common identifiers. So the production order in ERP actually links to the order reported by MES, the machine identifier in maintenance connects to the resource used in planning and material lots, work centers, product codes, and shift definitions all need rules people can trust. Without those links, you just have more data in one place and the same old disagreement. Time logic needs the same attention. An event time, a system posting time, and the time a person enters the status can all differ, but that doesn't mean any of them is wrong. They describe different moments. When you compare plans start against actual start, you have to define which time counts as actual start and apply that definition consistently because otherwise plan versus actual analysis becomes an argument about timestamps. Lineage matters too. If a planner asks why an order now shows a delay risk, the answer should trace back through the data. A confirmed machine stop, a revised material receipt, an MES event that marked an operation incomplete or a manually entered quality hold. People need to know where the fact came from, when it arrived, and whether it changed after the first load. Share business definitions help with words that sound simple until several systems use them. Complete might mean a machine finished processing or it might mean quality released the batch or that the next operation accepted it, and available might mean material exists in stock or that production can consume it now. Fabric can support governed definitions so the same term doesn't quietly mean different things in different reports and decisions. Once those foundations exist, you can build a history of plan versus actual that goes beyond a report showing where the last month met plan does. It becomes a record of what the schedule expected, what execution produced, which conditions changed, and how the decision changed in response. That history gives learning somewhere solid to live. You can examine repeated gaps between planned and actual cycle time, trace where orders waited longer than expected, compare the original dispatch sequence with what actually ran, and look for patterns around material release, quality status, resource loss, or recurring replans. The point isn't to build a data lake full of factory regret, it's to give planners, production teams, and engineers a dependable history they can use to test assumptions. If a routing time keeps missing under a known set of conditions, that should become visible. If a schedule repeatedly depends on workarounds that never reached the formal record, the data should expose that gap too. Still, I'd keep the role of fabric very clear. Fabric supports data access, governance analysis, and shared data products, but it does not automatically understand a factory just because you loaded ERP tables, MES events, and sensor readings into the same platform. They can't infer every capability rule, sequence restriction, tool requirement, or approval condition that experienced people use when they decide what should run next. Those relationships need explicit modeling. You need to describe which product operations can run, on which resources, which conditions affect release, and which rules apply when the state changes. Some of that information may already exist in source systems, while some lives in documents, work instructions, spreadsheets, or the heads of people who know the process well. Fabric can hold and connect the data, but your manufacturing model gives it meaning. That distinction protects you from a common mistake. A well-governed data platform can give you a trusted view of the factory, but it does not replace MES execution, ERP ownership of commercial demand, or the decision logic needed to create a feasible revised schedule. Each part has a job. With that in mind, let's follow the data from operational technology through the decision loop and keep the boundary between machine control and production intelligence clear. Azure and OT move data without pretending the cloud runs the machine. The data foundation needs facts from the factory, but that does not mean the cloud should take over machine control. Programmable logic controllers, or PLCs, remain close to the equipment because they handle control tasks where timing, safety, and predictable behavior matter. And an edge system may collect signals, normalize protocols, buffer events, or connect older equipment to newer systems that work belongs near the machine for good reasons. A cloud service should not sit in the path of a safety stop. If a network link drops, the machine still needs to stop safely, run its local control logic and keep operators protected, and if a cloud service takes longer than expected to respond, the production cell cannot simply wait and hope the connection recovers. Physical production has different failure modes than a web application, and that boundary needs to stay clear from the beginning. Now here's how factory data actually moves into the wider feedback loop. It happens through approved OT pathways, with agreement from the people who own the equipment and the people who own the data. And depending on the plant, that may mean an industrial gateway, an edge platform, an MS integration, or a controlled interface from an existing historian. The route matters as much as the event. OT teams need to know what connects to the network, which systems can read data, who can change a configuration, and what happens during a fault, while IT teams need identity, access control, audit records, and a way to move trusted data into the data platform. Neither side can treat the other as an obstacle. They are protecting different parts of the same production system. A useful design assumes connectivity will fail sometimes. A plant may have weak coverage in one area, a machine network may sit behind strict security controls or an edge device may need to store events locally until it can reconnect. Clocks can drift, and a message can arrive late, arrive twice, or arrive after the production state has changed again. Those are normal engineering conditions. The system needs to record enough time and source detail to deal with these conditions, and it also needs to distinguish a live signal from a confirmed production event. A machine may indicate that it is running, for example, but that does not automatically prove a specific order produced acceptable output during that time. The production context still matters. Security boundaries deserve the same care. Reading a machine status and writing a machine command are completely different permissions, so a service that supports planning should not gain the right to alter a PLC just because both systems connect through Azure. Keep control actions local, controlled, and owned by the operational teams responsible for the process and cloud connectivity should support awareness and decisions not bypass plant governance. This is also where people collect far too much data without a clear question behind it. A machine can produce a huge stream of tags, counters, states, temperatures, alarms, and diagnostic values, some of those signals matter for maintenance, others matter for quality, and a smaller set may affect a production dispatch decision. Send the event with the meaning needed upstream, rather than pushing every raw change into a central platform and asking someone to find a use later, define the events the feedback loop actually needs. A resource entered an unavailable state, an operation began, a count changed a tool, reached a condition that blocks use, or a batch completed a process step by the way it's released. Each event should carry the right context where possible, which resource produced it, which order or operation it relates to, when it occurred, which source reported it, and whether it's a machine observation, an MES confirmed event, or a manual status entered by an operator. Those details let the rest of the architecture treat the event as evidence instead of noise. That doesn't mean every source system needs to become perfect before you start. It means you should know the limits of each signal and avoid turning a technical data feed into a false production claim. OT and IT convergence works when both sides contribute to a shared decision process while keeping their own responsibilities. OT protects safe, reliable operation of equipment. IT provides governed data, identity, integration, and access across business systems and production owns the decision about what work should run under the current conditions. No single team owns the whole loop alone, as you can provide services for ingesting, processing, securing, and connecting operational data with enterprise data. But the design still needs plant-approved pathways, clear ownership, and a firm line between observing a machine and controlling it. Identity can tell you that several systems refer to the same machine, order, or material lot, which is helpful, but relationships tell you why a change in one of those things should alter a production decision. Digital Twin and Knowledge Graph two ways to model factory meaning. Once you can match the same order, machine, material, lot, and operation across different systems, you can start building meaning out of those pieces. Two concepts come up a lot in that conversation. Digital Twin and Knowledge Graph people sometimes throw them around like they're interchangeable. They're not. They can work together, but they answer completely different questions about production. A digital twin is a live digital snapshot of something physical on the floor, a machine, a cell, a line, a tool, or even a batch moving through a process. Take a machining center. Its twin holds the state that matters for production right now, available, running, stopped, under maintenance, waiting for a tool or blocked by something else. It can also connect that state to things like capability, current setup, maintenance status, and whatever work is assigned to it at the moment. The entire focus is the state of the asset right now. That makes a digital twin useful when you need to monitor something physical and understand its current condition in operational terms. Is the resource ready for dispatch? Is it occupied? Did a maintenance event cut into its usable time? Is the line producing, waiting, or stopped? A twin gives that status structured home instead of leaving it buried across machine tags, MES statuses, maintenance logs, and sticky notes. A knowledge graph starts from a completely different angle. It models relationships between things. For production planning, those things include products, routes, operations, work orders, machines, tools, people, material lots, quality conditions, and business rules. The graph records how they connect. An order needs an operation. That operation can run on certain resources, and each resource might need a specific tool. A tool may only support one product family. A person needs a certification to run a certain process. A quality hold blocks a batch from moving to the next operation. That network of relationships is what a knowledge graph captures. It becomes useful when your question involves dependencies. Imagine a machine goes down unexpectedly. With a knowledge graph, you can trace the work affected by that change. Which current orders depend on it? Which jobs can move to an alternative resource? What if that alternative also needs a tool already in use? Which downstream commitments are at risk? If nothing changes. You aren't just looking at the machine anymore. You're following the links around it. That's where the two models complement each other. The digital twin holds a current state. Say, a machine becomes unavailable. The knowledge graph helps you trace what that state affects across the product, process, and resource model. But I'd be careful not to treat either term as a replacement for the systems you already use. An MES still owns and records execution activity. ERP still carries demand, commercial commitments, and core business records. A scheduling tool, whether it sits inside a broader platform or comes from a specialist provider, still needs to calculate and manage the sequence of work. A digital twin doesn't replace an MES because it only describes current state. A knowledge graph doesn't replace scheduling software because it maps relationships instead of sequencing work. Both can give those systems better context and both can support the decisions that happen between them. The model you choose should follow the problem you're trying to solve. If you need a clear picture of operational state, start with a digital twin approach. You want to know whether a bottleneck resource can take work, what state it's in, and how that state changes through the shift. If you need to trace dependencies, investigate impact, or reason across rules and relationships, a knowledge graph might fit better. It can answer questions that look simple until the factory enters the conversation. Like, what else changes if we move this order? You don't need to model the entire enterprise to begin. Pick a bottleneck where planners already spend time chasing updates or choose one product family with complex resource rules, tooling dependencies, and recurring schedule changes. Model the resource's operations, orders, and conditions around that small area first that gives you a practical test. Can the model explain why a job cannot run? Can it trace the impact of a change resource state? Can it show feasible alternatives that match how experience production people think about the work? If it can't, adding every other factory asset won't help. Once the feedback loop has current facts and explicit constraints, AI becomes a much more grounded discussion. Before that point, it mostly has fragments of the factory and a confident way of arranging words around them. Industrial AI, where it helps, and where it should not decide. Industrial AI becomes useful when it works on a specific production question with facts you can trace and constraints your team agrees on. Without that, it can sound convincing while recommending work that cannot actually run. Take duration forecasting. If an operation has taken longer than its routing standard under certain conditions, a model can estimate a more realistic finish time for work in progress. It can account for patents in actual cycle time, product type, resource state, and maybe a known setup condition. If those facts exist in the data, that doesn't replace the standard time in the route. It gives the planner a better warning when current work is likely to miss it. AI can also flag schedule risk before the order becomes officially late. Suppose the remaining work needs more time than the open capacity left in its route, or the cycle time on a bottleneck resource starts drifting above the normal range for that product family. The system can point to the risk early while the team still has choices. Detecting abnormal patterns works the same way. A machine might keep running, so a simple availability status stays green, but its cycle time begins to stretch. A process might produce more small stops than usual. An operation might enter inspection later than similar orders. None of those events alone proves a problem, but the pattern may deserve attention before the schedule absorbs the delay as though nothing changed. That's a sensible use of industrial AI. It watches for conditions people miss when they are busy running production. Generative AI has a different role. It can help people ask questions in normal language and retrieve governed operational context. A planner might ask why a customer order now faces risk, and the response can bring together the linked facts. An operation ran longer than expected, an alternative resource lacks the required tool, and the remaining route includes a queue at a constraint process. The answer still needs sources. A useful response should tell the planner which event, record, rule and time stamp, support the explanation. If it cannot do that, it may be a well-written guess. Production teams don't need more guesses, even if the guess uses perfect grammar. Generative AI can also help explain the effect of a proposed change. If someone asks what happens when order 4812 moves ahead of another order, the assistant can retrieve the affected route, current resource conditions, and stated business priorities, then explain the likely impact in plain language. But explanation and decision are different jobs. Constraint sequencing needs a different kind of engine. An optimization engine works through defined choices, rules and objectives. It can test sequences against finite capacity, material conditions, tool limits, sequence restrictions, and due date priorities. It can compare one feasible schedule against another and show the trade-offs. Generative AI doesn't replace that work simply because it can describe a schedule. Think of it this way. One system may explain why a recommendation exists. Another may calculate which recommendations remain feasible when the factory has hard constraints. In some designs, they work together. The optimization engine produces tested options. While generative AI helps a planner understand the reasoning and ask follow-up questions, that split is healthy. A production recommendation should show more than a final answer. It needs traceability. Which current facts did it use? Which rules removed other options? Which assumption shaped the projected finish time? When did the data last update? And if uncertainty exists? How confident is the system in its forecast? Confidence does not mean the system gets to hide doubt behind a percentage. It means the planner can see when the recommendation rests on thin evidence missing data or a condition that changed recently. Human review remains part of the design. A system may identify the sequence that protects the most due dates, but a supervisor may know a practical condition that hasn't reached the model yet. A planner may accept one late order to protect a customer relationship. Quality may block a route that looked available an hour ago. Those are operational choices, not defects in the system. So before anyone gives AI authority over dispatch decisions, ask a blunt question. What does it actually know? Does it know the current order state or only yesterday's plan? Does it know the product and process rules? Does it know which resources can perform the operation? Which tools are available and which conditions prevent release? Does it know the business priority behind the due date? If the answer is unclear, the AI should advise, not decide. The technology matters, but the next problem sits with people, authority, and how the factory acts when the recommendation arrives. The planner's role changes, it doesn't disappear. Here's the question I keep hearing. With all this buzz about better scheduling, data models, and AI in planning, does the planner's job go away? That's the wrong question to ask. A working feedback loop gets rid of the worst part of planning. The hours spent hunting for facts across ERP, MES, emails, phone calls, and that spreadsheet someone updated during the night shift. Instead, the planner's focus moves to the decisions that actually need human judgment. You stop manually piecing together the current state of the factory from fragments and start dealing with exceptions and trade-offs. Which customer date to protect, whether overtime makes sense if a recovery option introduces too much risk, or if the data is complete enough to release a new sequence? That's not less planning, that it's a smarter use of planning skill. A good planner knows a schedule is full of conflicting promises. The customer wants delivery, production needs a sequence, people can actually run, maintenance needs time to keep equipment dependable, quality needs the right release conditions, and finance cares about inventory and expediting costs. Software can test the rules it knows, but the planner decides which trade-off the business is actually willing to accept. And the supervisor, there's still very much in the loop. A supervisor sees conditions that might be real, but not yet formal. A changeover team stuck longer than expected. An operator who knows a job will need extra attention because the last batch caused trouble, a machine that's physically blocked by material handling. That knowledge should not stay as a private correction after the schedule reaches the floor. The supervisor needs a practical way to feed that condition into the decision and then confirm whether the revised dispatch instruction can actually run. That confirmation matters because a schedule can be technically feasible in a system but still fail on a busy shift if it ignores something visible on the floor. Maintenance and quality play similar roles from different angles. Maintenance changes capacity when a resource becomes uncertain, when a planned intervention needs protection or when a repair estimate changes. Quality changes release when material, work in progress or finished output, enters a hold, needs rework or waits for approval. Those teams don't need to become schedulers. They just need to provide the conditions that change the schedule clearly enough so planning can act on them. This brings us to clear authority. Who decides that a machine loss requires re-planning rather than local recovery? Who decides when a material issue changes the dispatch order who can accept the impact of moving a lower priority order behind a more urgent one? If nobody owns those calls, the plant still replants. But through side conversations and personal influence, the loop needs name decision rights. For example, a supervisor might handle minor sequence swaps within a defined window, a planner owns changes affecting the next shift or customer exposure. Quality controls whether held work can re-enter, maintenance provides resource status and repair outlook and production decides how the capacity loss changes the plan. The exact split depends on the plant but ambiguity doesn't help. Trust also determines whether people use the system or find ways around it. A recommendation that says move order 4-8-12 to machine-b invites resistance because people immediately ask questions the system hasn't answered why this order, why that machine, which work moves out, what assumption did it make about the tool operator material and repair time? A recommendation earns trust when it explains itself, showing the facts it used, the rules that shaped the option and the consequence of approving it. And it should state uncertainty directly. If the repair estimate is still unconfirmed, the recommendation should say so. Pretending certainty around incomplete shop floor facts is one of the fastest ways to send everyone back to Excel that same explanation gives experienced people a way to correct the model. If a supervisor rejects a proposal because a fixture is unavailable, that becomes a useful question. Was the fixture state missing? Was the rule absent? Or did the condition change after the data arrived? Over time, the system improves because the people doing the work can see where its reasoning falls short. Which leads to the next practical question, how often should this loop act without turning every small event into a new schedule? Event driven re-planning without constant schedule? Chaos. A working loop doesn't mean the schedule changes every time a sensor sends a message. If it did, the floor would stop trusting the schedule altogether. Machines produce normal noise, a short stop that clears in minutes, an operator correcting a minor issue, a cycle running slightly longer, without affecting any customer commitment or blocking the next operation. Re-planning leads a reason, not just an event. The plant needs trigger rules to decide when an operational change becomes a scheduling review. A machine stop might trigger that review only after it passes a defined duration or once maintenance confirms recovery will extend beyond the available slack in the current plan. A material event might trigger it when a required component enters a quality block when the usable quantity falls below what an operation needs or when a confirmed delivery moves past the time when work must start. Quality needs its own triggers, a small inspection delay stays inside the normal flow but a hole that blocks a batch feeding a constrained resource needs action immediately because the effect reaches multiple orders. Demand can also trigger a review, a customer escalation, a change shipment priority or a commercial decision to protect one order can alter the sequence. That should not happen through an informal phone call and a quiet change in Excel. The change needs a visible decision path. Trigger rules don't remove judgment. They give it a starting point. You might define a threshold for a resource loss, then let the planner and supervisor decide whether the current queue can absorb it. You might flag a material shortage automatically, then check whether an approved substitute or another released batch removes the problem. The rule says stop and review this. It does not claim the answer is already known. That distinction protects the factory from two bad extremes. One plant waits too long because nobody knows when a disturbance becomes serious enough to raise, another rebuilds the entire schedule for every small change. So people stop following the latest version because a newer one is always coming. Neither approach gives production control. Freeze Windows help create stability. Close to execution, the schedule should only change for real operational reasons, not because a model found a slightly tidier sequence. Think about the next few hours. Operators have stage material, a tool sits at the machine, a changeover is underway, someone has started first piece checks. Moving that work around to gain a small improvement on paper can create more disruption than it removes. Near term work needs protection. The size of the freeze window depends on the process. A high volume line with fastest batch decisions might use a shorter window, a complex process with long setups, batch rules, or strict material handling needs more stability around the work already prepared. The point is not to freeze the factory. It's to stop the schedule from behaving like a nervous spreadsheet. Outside that protected period the replant needs a horizon. If you only look at the next open slot, you might recover one delayed order and create pressure later in the route. If you try to rebuild every order for the next month after a small stop, you create work without improving the decision. The horizon should match the consequence of the event. A brief issue on a non-constrained resource might only need a local review through the end of the shift. Lots of a bottleneck machine, a blocked material batch, or a changed customer priority may require a broader look across the next few days and through the affected downstream operations. That's how the factory balances local recovery with the wider production flow. You don't need a global answer for every event. You need enough view to avoid solving today's problem by quietly creating tomorrow's. Every approved change should leave a record. Which schedule version changed? What event triggered the review? Which option did the team select? Who approved it? What assumptions shaped the decision? Like an expected repair time or a planned material receipt? This isn't paperwork for its own sake. When the next shift asks why its dispatch list changed, the answer should not depend on finding the person who took the phone call. The record also supports learning later. If the factory repeatedly changes the sequence for the same reason, that pattern becomes visible. If a decision worked poorly because a repair estimate changed or a material promise failed, people can examine the assumption rather than argue from memory. A scheduled version is a production decision with a history and you don't need to build this across every plant line, product and order at once. Start with a smaller scope, where replanting already hurts enough that people feel the gap every day. Start with one decision that hurts today. Here's the problem most manufacturers don't talk about. Don't kick off with a factory wide program called closed loop scheduling. That name sounds great in a steering meeting, but when the bottleneck sequence shifts at 10 in the morning, it doesn't give anyone on the shop floor a better answer. Start with one decision that already causes friction. Maybe it's the sequence at the bottleneck resource. Every day, somebody decides which job runs next, often with incomplete facts and a lot of pressure from due dates. Or maybe the real pain sits in late order recovery, where planners spend hours working out whether an order can still ship without creating a worse problem somewhere else. Material ready dispatch is another place to start. Some plants lose time because work reaches the resource before all required material has been released and staged. People reshuffle jobs locally, usually for sensible reasons, but the formal schedule never learns from the change. Choose the decision people already argue about. Look for one with a repeat pattern, a clear owner, and a consequence everyone recognizes. If every shift handles it differently, that's useful. That means there's probably knowledge worth capturing, even if it currently lives in calls, whiteboards, and files called final schedule, really final v7. Excel does not survive by accident. So once you have the decision, map how it happens today. Not the process shown in a procedure document. Follow the real path from the first trigger to the dispatch instruction that reaches the floor, who notices the problem first.