Sept. 15, 2026

A Machine Goes Down. How Should Your Production Plan React?

Key Takeaways

A machine stoppage is not automatically a planning event; planners must separate minor shop floor noise and short recovery windows from meaningful capacity losses.
Accurate production planning relies on working with a recovery window and confidence level rather than forcing an uncertain maintenance repair timestamp into the schedule.
Machine availability is not equivalent to executable production capacity, as valid alternate routes require aligned tooling, qualified operators, material readiness, and quality approvals.
Not all orders assigned to a failed resource carry the same risk, requiring planners to analyze running quantities, upstream queues, and downstream dependencies to evaluate true exposure.
Generating a small number of realistic response scenarios—such as keeping work, moving orders, or adding overtime—prevents false confidence compared to seeking one single perfect schedule.

A machine goes down. Maintenance receives the alarm. The operator stops production. The MES records an interrupted operation. But your ERP may still believe that the machine has capacity. And your production schedule may still promise that every order will be completed on time. That is where a machine breakdown stops being only a maintenance problem and becomes a production planning problem. In this episode, we explore what should actually happen to a production plan when a critical machine becomes unavailable — from detecting the disruption and estimating lost capacity to identifying affected orders, evaluating alternative resources, rescheduling with finite capacity, and releasing a production plan the factory can actually execute.

NOT EVERY MACHINE STOP REQUIRES REPLANNING
Modern factories generate enormous numbers of operational signals. PLCs report faults. IoT systems detect machine-state changes. MES platforms track interrupted operations. Maintenance systems record incidents. But a machine stopping for a few minutes does not automatically mean the entire production schedule should change. A short interruption might be caused by an operator clearing a jam. It might be a normal tool change. The machine could simply be waiting for material. Or a sensor could report a state that does not represent the actual production situation. The important distinction is between a machine signal and a planning event. A production plan should react when the interruption creates a meaningful loss of capacity that normal shop-floor recovery can no longer absorb. That threshold depends on the production environment. A ten-minute stop on a resource surrounded by large buffers may have almost no impact. The same ten-minute interruption on a bottleneck resource producing a make-to-order component with a tight customer deadline could require immediate attention. Good production planning therefore does not react to every signal. It reacts to operational consequences.

HOW LONG WILL THE MACHINE REALLY BE DOWN?
Once downtime becomes significant enough to affect production, one question becomes critical: How long will the capacity be unavailable? Unfortunately, maintenance rarely knows the exact answer immediately. A technician may know that a drive has failed but not whether a reset will solve the problem, whether a component needs replacement, or whether additional safety checks will be required. Production planning should therefore avoid building an entire schedule around an uncertain repair timestamp. Instead, planners can work with a recovery window and confidence level. For example: A short outage may require no schedule change. A medium outage may require selected orders to move. A full-shift outage may require active rescheduling. A longer outage may threaten customer commitments and require escalation. This turns maintenance information into a useful planning input without pretending that an early repair estimate is a guarantee.

A MACHINE IS MORE THAN AVAILABLE HOURS
One of the biggest mistakes in production planning is assuming that another machine with an empty calendar automatically provides replacement capacity. It does not. A resource needs the correct capability. The right fixture may be required. A qualified production program may need to exist. An operator with the necessary skills must be available. Quality may need to approve the alternate process. Material needs to be physically available. Tooling and inspection capacity may also be required. This creates an important distinction: Machine availability is not the same as executable production capacity. An empty four-hour window on another machine means very little if the product cannot actually be produced there. Production planning therefore needs a model connecting Product, Process and Resource. The product defines what needs to be manufactured. The process defines the operations required. The resource defines where those operations can actually run and under which constraints. That context becomes essential when production is disrupted.

WHICH ORDERS ARE ACTUALLY AFFECTED?
Once a machine failure is confirmed, planners need to identify the work that genuinely depends on that resource. Start with the order currently running. How much has already been completed? What quantity remains? Can the partially processed material safely wait? Does interrupted work require inspection, rework, or scrap approval? Then examine the queue. Which orders are physically waiting? Which orders are released? Which ones have tight downstream dependencies? Which have alternative routings? Which rely exclusively on the failed resource? Not every order scheduled on the machine carries the same risk. Some may easily move. Others may have enough delivery buffer to wait. Some may depend on a customer shipment. Others may feed a critical assembly operation. And some may have no realistic alternative at all. The goal is not to declare every order an emergency. The goal is to identify real production exposure.

THE BOTTLENECK CAN MOVE
Suppose Machine 4 fails. Machine 6 has available capacity. Moving urgent orders to Machine 6 appears to solve the problem. But what happens next? Perhaps Machine 6 feeds an inspection station that is already operating near capacity. The orders move successfully — and simply create another queue somewhere else. A machine breakdown can therefore move the production constraint. The new bottleneck could become another machine, an inspection station, a qualified operator, a furnace, a fixture, a transport resource, or even a tool. This is why production planners need to evaluate the entire local production flow, not simply find another empty machine slot. Moving work can move the problem. A good rescheduling decision considers what happens downstream and upstream after every significant schedule change.

WHAT SHOULD THE PRODUCTION PLAN PROTECT?
When capacity disappears, not every order can necessarily remain exactly where it was. Production therefore needs clear priorities. Customer delivery commitments matter. But so do internal milestones. Safety stock can matter. Material shelf life can matter. Campaign rules can matter. Setup costs can matter. Quality requirements can matter. An urgent-looking order may require a long changeover and material that has not yet arrived. Another order with a slightly later due date may already have material staged and require almost no setup. Blindly sorting everything by due date can therefore produce a worse production schedule. Priority rules should exist before the machine breaks down. Otherwise, disruption planning becomes a competition between whoever calls first, whoever complains loudest, and whoever has the most senior manager copied into an email. Production planning needs policy, not panic.

POSSIBLE CAPACITY VS EXECUTABLE CAPACITY
Before moving an order to another resource, planners need to test the full chain of constraints. Can the machine technically perform the operation? Is the tooling available? Is a qualified operator available? Is the material physically ready? Has quality approved the alternative? Does the production sequence allow the change? Are batch rules respected? Does shelf life create another time constraint? Has maintenance actually released the resource for production? A resource can be theoretically capable without being operationally available. This distinction between a possible move and an executable move is fundamental to realistic manufacturing scheduling. A possible move says that another machine could perform the operation. An executable move means that machine, tooling, operator, material, process approval, sequence, safety requirements, and available time all align. Only then does that empty slot become real capacity.

BUILD SCENARIOS INSTEAD OF SEARCHING FOR ONE PERFECT ANSWER
Machine downtime introduces uncertainty. Trying to calculate one perfect replacement schedule can therefore create false confidence. A better approach is to generate a small number of realistic response scenarios. One scenario might keep the work on the failed resource and wait for repair. Another might move selected orders to approved alternative resources. A third could use overtime or an additional shift. Another possibility might involve splitting an order where production and quality rules permit it. Each scenario should explain: What changes? Which orders move? Which customer commitments are protected? Which setups are added? Which resources are required? What assumptions does the scenario depend on? And what happens if the repair takes longer? The objective is not to create dozens of simulations. Usually, production needs a preferred response, a fallback, and perhaps a more aggressive option if delivery risk becomes unacceptable.

WHY EXCEL REPLANNING BREAKS UNDER PRESSURE
Excel remains extremely useful for local analysis. But problems begin when the spreadsheet becomes the new production schedule while the actual production environment continues changing elsewhere. Maintenance updates the repair estimate. A supervisor moves an order. Customer service changes a priority. MES records new production progress. Material moves. Another resource becomes unavailable. Suddenly several people have several different versions of the production plan. And everyone believes their version is correct. Then come the familiar filenames: Final. Final_v2. Final_v2_revised. The factory version of archaeology. The underlying problem is not Excel itself. The problem is the absence of a shared, controlled source of truth. Production needs one released schedule that clearly shows which facts were used, which orders changed, when the schedule was calculated, and which version the shop floor should actually execute.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

🚀 Want to be part of m365.fm?

Then stop just listening… and start showing up.

👉 Connect with me on LinkedIn and let’s make something happen:

🎙️ Be a podcast guest and share your story
🎧 Host your own episode (yes, seriously)
💡 Pitch topics the community actually wants to hear
🌍 Build your personal brand in the Microsoft 365 space

This isn’t just a podcast — it’s a platform for people who take action.

🔥 Most people wait. The best ones don’t.

👉 Connect with me on LinkedIn and send me a message:
"I want in"

Let’s build something awesome 👊

Frequently Asked Questions

What should trigger a production plan reaction when a machine breaks down?

A production plan should react when an interruption creates a meaningful loss of capacity that normal shop-floor recovery can no longer absorb within the agreed operating window.

How should uncertainty in maintenance repair times be handled in production planning?

Instead of building an entire schedule around an uncertain repair timestamp, planners should work with a recovery window, a confidence level, and multiple scenarios for short, medium, and long outages.

Why is machine availability not the same as executable production capacity?

An empty time slot on another machine does not mean the product can actually be produced there; successful execution also requires the correct capability, fixtures, qualified operators, approved programs, and available materials.

How do you determine which orders are truly affected by a machine failure?

Planners should evaluate the order currently running, inspect the queue of waiting or released orders, and assess downstream dependencies rather than treating every order assigned to the resource as an equal emergency.

1
00:00:00,000 --> 00:00:02,240
When a machine stops, maintenance gets the alarm

2
00:00:02,240 --> 00:00:03,640
and that parts familiar.

3
00:00:03,640 --> 00:00:05,560
But here's the part most people skip,

4
00:00:05,560 --> 00:00:08,160
that outage also changes the production plan,

5
00:00:08,160 --> 00:00:10,440
even if nobody's touched the planning system yet.

6
00:00:10,440 --> 00:00:12,880
Your ERP still sees capacity that doesn't exist.

7
00:00:12,880 --> 00:00:15,000
The MES might show an interrupted operation,

8
00:00:15,000 --> 00:00:17,480
a supervisor might already be moving people around.

9
00:00:17,480 --> 00:00:19,640
Meanwhile, the customer promise sits on the order

10
00:00:19,640 --> 00:00:20,680
like nothing happened.

11
00:00:20,680 --> 00:00:22,840
So the real question isn't just how fast we can repair

12
00:00:22,840 --> 00:00:24,600
the machine, it's what production should do

13
00:00:24,600 --> 00:00:26,520
while the machine is unavailable.

14
00:00:26,520 --> 00:00:28,920
A useful response starts with detection,

15
00:00:28,920 --> 00:00:32,000
then checks the impact, tests realistic schedule options,

16
00:00:32,000 --> 00:00:34,840
and releases a plan, people can actually run.

17
00:00:34,840 --> 00:00:37,720
Not another report, not a spreadsheet sent by email,

18
00:00:37,720 --> 00:00:39,920
but a plan that fits the physical factory.

19
00:00:39,920 --> 00:00:42,160
Keep in mind, a disruption starts with a signal,

20
00:00:42,160 --> 00:00:45,040
but not every signal should trigger a new schedule.

21
00:00:45,040 --> 00:00:47,600
Separate a real disruption from shop floor noise.

22
00:00:47,600 --> 00:00:51,200
Take a typical line with older PLCs, a newer IoT layer,

23
00:00:51,200 --> 00:00:54,280
and operators who know the equipment better than any dashboard.

24
00:00:54,280 --> 00:00:57,080
A fault signal appears and the machine reports a stop.

25
00:00:57,080 --> 00:00:58,520
Does that mean planning should react?

26
00:00:58,520 --> 00:00:59,360
Not always.

27
00:00:59,360 --> 00:01:01,800
A machine can stop because an operator clears a jam,

28
00:01:01,800 --> 00:01:04,600
pause during a normal tool change, or wait for material.

29
00:01:04,600 --> 00:01:06,960
A planned maintenance window takes it out of service

30
00:01:06,960 --> 00:01:09,520
with zero surprise, and sometimes a sensor tells a very

31
00:01:09,520 --> 00:01:12,280
confident story about a machine state that's just wrong.

32
00:01:12,280 --> 00:01:14,800
The raw signal matters, but it isn't the planning event.

33
00:01:14,800 --> 00:01:16,720
Think about four different situations.

34
00:01:16,720 --> 00:01:19,600
A fault code from the PLC tells you something abnormal,

35
00:01:19,600 --> 00:01:21,280
likely happened near the equipment.

36
00:01:21,280 --> 00:01:23,360
A short stop means the line pauses,

37
00:01:23,360 --> 00:01:26,440
and then resumes before lost time reaches any meaningful level.

38
00:01:26,440 --> 00:01:28,480
Planned downtime follows a maintenance calendar

39
00:01:28,480 --> 00:01:30,200
that planning should already know.

40
00:01:30,200 --> 00:01:33,200
Confirmed loss of capacity means the machine can't do its assigned

41
00:01:33,200 --> 00:01:35,200
work long enough that the plan has to change.

42
00:01:35,200 --> 00:01:38,480
Only that last case should reliably start a re-planning process.

43
00:01:38,480 --> 00:01:42,120
That sounds obvious until you connect the dots between IT and OT.

44
00:01:42,120 --> 00:01:44,640
Plants collect machine signals at high frequency,

45
00:01:44,640 --> 00:01:46,480
while planning works on a different clock.

46
00:01:46,480 --> 00:01:49,240
If every stop creates a new alert, a new impact list,

47
00:01:49,240 --> 00:01:52,080
and a new proposed schedule, planners will start ignoring

48
00:01:52,080 --> 00:01:52,840
the whole system.

49
00:01:52,840 --> 00:01:55,320
The system becomes very good at creating noise.

50
00:01:55,320 --> 00:01:57,320
And factories already have enough of that.

51
00:01:57,320 --> 00:02:00,480
So you need thresholds, and those thresholds should match the process.

52
00:02:00,480 --> 00:02:03,960
A brief stop on a machine with large buffers upstream and downstream

53
00:02:03,960 --> 00:02:05,480
may need no planning action,

54
00:02:05,480 --> 00:02:09,480
because the shift team can recover the lost units before the end of the shift.

55
00:02:09,480 --> 00:02:11,720
Yet the same brief stop on a bottleneck resource

56
00:02:11,720 --> 00:02:14,080
running a make-to-order product with a tight due date

57
00:02:14,080 --> 00:02:15,360
deserves attention immediately.

58
00:02:15,360 --> 00:02:18,120
So don't define disruption solely by elapsed time.

59
00:02:18,120 --> 00:02:21,160
Define it by expected capacity loss, recovery window,

60
00:02:21,160 --> 00:02:22,960
and the orders exposed to that loss.

61
00:02:22,960 --> 00:02:24,320
A stop becomes a planning event

62
00:02:24,320 --> 00:02:28,120
when normal recovery no longer looks realistic within the agreed operating window,

63
00:02:28,120 --> 00:02:31,800
whether that's the rest of the hour, the end of the shift, or the next dispatch cycle.

64
00:02:31,800 --> 00:02:33,560
It depends on how your planned runs.

65
00:02:33,560 --> 00:02:34,880
Here's a practical rule.

66
00:02:34,880 --> 00:02:37,640
If a machine stops, let the local team handle it first.

67
00:02:37,640 --> 00:02:40,120
If the stop continues beyond a defined threshold,

68
00:02:40,120 --> 00:02:43,200
check whether the machine carries work that can't recover within the shift.

69
00:02:43,200 --> 00:02:46,520
If the answer is yes, send a disruption event to the planning process.

70
00:02:46,520 --> 00:02:50,200
That rule needs context, though, and context comes from more than one source.

71
00:02:50,200 --> 00:02:52,760
The PLC or the IoT layer connected to it

72
00:02:52,760 --> 00:02:54,720
can report that the machine entered a fault state

73
00:02:54,720 --> 00:02:57,480
with a code, a timestamp, and whether the cycle stopped.

74
00:02:57,480 --> 00:03:01,000
That's useful because it comes close to the equipment and arrives quickly.

75
00:03:01,000 --> 00:03:02,800
The MES adds the production meaning.

76
00:03:02,800 --> 00:03:05,600
It tells you whether the machine was running an active work order,

77
00:03:05,600 --> 00:03:08,400
whether the operation had started, whether units are complete,

78
00:03:08,400 --> 00:03:12,640
and whether the resource was already waiting for material or quality release.

79
00:03:12,640 --> 00:03:15,120
A machine reporting stopped means something very different

80
00:03:15,120 --> 00:03:16,920
if no order is assigned to it.

81
00:03:16,920 --> 00:03:19,560
Maintenance adds another check because a technician might know

82
00:03:19,560 --> 00:03:21,560
that a reset clears the issue in a few minutes,

83
00:03:21,560 --> 00:03:24,320
or that the equipment needs isolation in a spare part.

84
00:03:24,320 --> 00:03:26,600
An operator might know the machine is technically available,

85
00:03:26,600 --> 00:03:29,560
but blocked because a fixture hasn't returned from inspection.

86
00:03:29,560 --> 00:03:31,920
Systems don't always capture that distinction clearly.

87
00:03:31,920 --> 00:03:33,920
That's why a fully automatic trigger needs care.

88
00:03:33,920 --> 00:03:35,440
You can automate the first part.

89
00:03:35,440 --> 00:03:37,960
Capture the event, compare it with the planned state,

90
00:03:37,960 --> 00:03:40,760
and identify when the stop crosses a defined threshold.

91
00:03:40,760 --> 00:03:44,640
When the state remains unclear, ask for confirmation from the people closest to the work.

92
00:03:44,640 --> 00:03:47,120
The operator confirms whether production can resume,

93
00:03:47,120 --> 00:03:49,680
maintenance confirms whether the equipment can return,

94
00:03:49,680 --> 00:03:52,320
and the MES confirms whether work is actually at risk.

95
00:03:52,320 --> 00:03:54,080
That isn't a weakness in the architecture.

96
00:03:54,080 --> 00:03:55,720
It respects how factories work.

97
00:03:55,720 --> 00:03:58,360
A production plan shouldn't churn because a sensor twitched,

98
00:03:58,360 --> 00:03:59,760
a network connection dropped,

99
00:03:59,760 --> 00:04:02,320
or a machine paused for a normal recovery action.

100
00:04:02,320 --> 00:04:05,240
Planning changes affect people, material movements, set up work,

101
00:04:05,240 --> 00:04:07,480
and the order in which supervisors run the shift.

102
00:04:07,480 --> 00:04:10,640
Once you move orders around, reversing those moves also carries a cost.

103
00:04:10,640 --> 00:04:12,840
So the first job isn't to react fast at any price.

104
00:04:12,840 --> 00:04:16,080
It's to decide whether the event deserves a planning response at all.

105
00:04:16,080 --> 00:04:17,560
Once downtime is confirmed, though,

106
00:04:17,560 --> 00:04:20,920
the planner still knows very little about the production impact.

107
00:04:20,920 --> 00:04:23,840
The first question, how long is the capacity gone?

108
00:04:23,840 --> 00:04:25,800
Once the outage hits the planning threshold,

109
00:04:25,800 --> 00:04:27,600
the first question sounds simple.

110
00:04:27,600 --> 00:04:29,840
How long will this machine be unavailable?

111
00:04:29,840 --> 00:04:33,240
In practice, that single question drives almost every decision that follows,

112
00:04:33,240 --> 00:04:36,520
and the honest answer may change several times during the repair.

113
00:04:36,520 --> 00:04:39,680
A machine down for 15 minutes creates one kind of problem.

114
00:04:39,680 --> 00:04:42,960
A machine lost for the rest of a shift creates another kind entirely,

115
00:04:42,960 --> 00:04:45,560
and if maintenance can't yet estimate a return time,

116
00:04:45,560 --> 00:04:47,440
because they're still diagnosing the fault,

117
00:04:47,440 --> 00:04:49,640
planning faces a different problem altogether.

118
00:04:49,640 --> 00:04:51,680
Don't force an exact answer too early,

119
00:04:51,680 --> 00:04:54,640
picture a forming machine that stops during a production run.

120
00:04:54,640 --> 00:04:56,800
The technician knows the fault effects are drive-unit,

121
00:04:56,800 --> 00:04:58,880
but not yet whether a reset will clear it,

122
00:04:58,880 --> 00:05:00,680
whether a component needs replacement,

123
00:05:00,680 --> 00:05:03,480
or whether the machine needs a safety check before restart.

124
00:05:03,480 --> 00:05:06,560
Saying it will return in two hours at that point might calm people down,

125
00:05:06,560 --> 00:05:08,880
but it doesn't give planning a sound basis for action.

126
00:05:08,880 --> 00:05:12,000
What planning needs first is a recovery window and a confidence level.

127
00:05:12,000 --> 00:05:14,160
Maintenance might report that the likely repair time

128
00:05:14,160 --> 00:05:16,600
sits somewhere between 30 minutes and two hours,

129
00:05:16,600 --> 00:05:19,560
with low confidence until the drive cabinet is inspected.

130
00:05:19,560 --> 00:05:22,880
That is far more useful than a single neat timestamp that nobody can defend.

131
00:05:22,880 --> 00:05:26,320
The range tells the planner how much capacity could disappear.

132
00:05:26,320 --> 00:05:28,560
The confidence tells them whether they should act now,

133
00:05:28,560 --> 00:05:30,120
or wait for another update.

134
00:05:30,120 --> 00:05:31,640
Let's think about the response in layers.

135
00:05:31,640 --> 00:05:34,200
If the likely downtime lasts only 15 minutes,

136
00:05:34,200 --> 00:05:36,240
the planner may leave the schedule alone,

137
00:05:36,240 --> 00:05:38,800
and ask the supervisor to recover the work inside the shift.

138
00:05:38,800 --> 00:05:41,680
There's no reason to disturb several downstream decisions,

139
00:05:41,680 --> 00:05:44,480
when the team can absorb the loss through a small change in pace,

140
00:05:44,480 --> 00:05:46,760
a shorter break, or available buffer time.

141
00:05:46,760 --> 00:05:49,240
If the machine will likely remain down for a full shift,

142
00:05:49,240 --> 00:05:50,840
the plan needs active review.

143
00:05:50,840 --> 00:05:53,040
Work assigned to that machine may need a new sequence,

144
00:05:53,040 --> 00:05:55,360
another resource, or a managed delay.

145
00:05:55,360 --> 00:05:57,360
Customer service may also need an early warning

146
00:05:57,360 --> 00:05:59,880
if the lost shift threatens a promised date.

147
00:05:59,880 --> 00:06:01,640
Unknown downtime needs its own treatment.

148
00:06:01,640 --> 00:06:04,600
This is where many planning systems become oddly confident.

149
00:06:04,600 --> 00:06:06,520
They take one rough estimate, treated as fact,

150
00:06:06,520 --> 00:06:08,040
and create a schedule around it.

151
00:06:08,040 --> 00:06:09,680
Then the repair estimate changes,

152
00:06:09,680 --> 00:06:12,400
and the new schedule collapses before anyone has released it.

153
00:06:12,400 --> 00:06:14,800
A better approach treats uncertain repair time

154
00:06:14,800 --> 00:06:17,240
as a constraint with several possible states.

155
00:06:17,240 --> 00:06:19,880
You hold a short outage case, a medium outage case,

156
00:06:19,880 --> 00:06:21,600
and a longer outage case.

157
00:06:21,600 --> 00:06:23,400
Each case answers a practical question.

158
00:06:23,400 --> 00:06:26,000
If the machine returns soon, what work stays put?

159
00:06:26,000 --> 00:06:28,600
If it misses the shift, which decisions need to change,

160
00:06:28,600 --> 00:06:31,640
if repair extends beyond that, which commitments face a real risk?

161
00:06:31,640 --> 00:06:32,960
That isn't over-engineering.

162
00:06:32,960 --> 00:06:35,120
It's a way to avoid rebuilding the entire plan

163
00:06:35,120 --> 00:06:37,200
every time maintenance learns something new.

164
00:06:37,200 --> 00:06:39,840
The repair estimate should also have an update rhythm.

165
00:06:39,840 --> 00:06:42,320
Maintenance doesn't need to send planning a message every time

166
00:06:42,320 --> 00:06:44,480
someone opens a panel or tests a sensor,

167
00:06:44,480 --> 00:06:47,080
but planning does need agreed escalation points.

168
00:06:47,080 --> 00:06:48,360
Here's a concrete example.

169
00:06:48,360 --> 00:06:50,840
When the machine crosses the first recovery threshold,

170
00:06:50,840 --> 00:06:52,840
maintenance confirms whether it can return

171
00:06:52,840 --> 00:06:54,680
within the current dispatch window.

172
00:06:54,680 --> 00:06:56,960
If the repair runs beyond that window,

173
00:06:56,960 --> 00:06:59,720
they provide a revised range and the reason for the change.

174
00:06:59,720 --> 00:07:01,000
When the estimate crosses a point

175
00:07:01,000 --> 00:07:03,400
where delivery or staffing decisions may shift,

176
00:07:03,400 --> 00:07:04,800
the planner receives another update

177
00:07:04,800 --> 00:07:06,480
without chasing people by phone.

178
00:07:06,480 --> 00:07:08,040
The actual timing depends on your plant.

179
00:07:08,040 --> 00:07:10,280
A high volume line with a short dispatch cycle

180
00:07:10,280 --> 00:07:12,640
needs faster updates than a low volume process

181
00:07:12,640 --> 00:07:14,080
running longer campaigns.

182
00:07:14,080 --> 00:07:15,960
What matters is that maintenance and planning

183
00:07:15,960 --> 00:07:18,960
agree on the moments when a new estimate changes a decision.

184
00:07:18,960 --> 00:07:21,280
Maintenance diagnosis isn't input to the plan.

185
00:07:21,280 --> 00:07:22,280
It isn't a promise.

186
00:07:22,280 --> 00:07:23,840
That distinction helps both teams.

187
00:07:23,840 --> 00:07:25,600
The maintenance team can report what they know

188
00:07:25,600 --> 00:07:27,160
without pretending they know more.

189
00:07:27,160 --> 00:07:29,760
The planning team can prepare options without releasing work

190
00:07:29,760 --> 00:07:31,400
based on a hopeful repair time,

191
00:07:31,400 --> 00:07:33,920
and the supervisor doesn't receive a revised dispatch list

192
00:07:33,920 --> 00:07:35,920
only to reverse it 20 minutes later.

193
00:07:35,920 --> 00:07:37,360
There's also a human part here.

194
00:07:37,360 --> 00:07:39,080
A technician working through a difficult fault

195
00:07:39,080 --> 00:07:40,760
needs room to diagnose safely,

196
00:07:40,760 --> 00:07:42,400
while a planner needs enough information

197
00:07:42,400 --> 00:07:44,560
to protect the work already committed.

198
00:07:44,560 --> 00:07:46,720
Neither team can solve the other team's job

199
00:07:46,720 --> 00:07:48,320
by sending more urgent messages.

200
00:07:48,320 --> 00:07:49,640
So ask for a range.

201
00:07:49,640 --> 00:07:51,240
Ask how confident that range is,

202
00:07:51,240 --> 00:07:52,920
and agree when the estimate will be reviewed.

203
00:07:52,920 --> 00:07:54,360
That creates a planning response

204
00:07:54,360 --> 00:07:56,440
that can adapt as facts improve.

205
00:07:56,440 --> 00:07:58,440
Instead of one that depends on a repair time,

206
00:07:58,440 --> 00:07:59,440
nobody really knows.

207
00:07:59,440 --> 00:08:02,240
Still, duration only describes the missing capacity.

208
00:08:02,240 --> 00:08:05,400
The machine may sit inside a much larger production flow,

209
00:08:05,400 --> 00:08:07,560
and that flow decides which part of the plan

210
00:08:07,560 --> 00:08:09,280
actually feels the outage.

211
00:08:09,280 --> 00:08:11,600
Start with the physical production context.

212
00:08:11,600 --> 00:08:13,120
Before anyone changes a schedule,

213
00:08:13,120 --> 00:08:15,560
they need to understand what the failed machine

214
00:08:15,560 --> 00:08:17,560
does in the real process.

215
00:08:17,560 --> 00:08:19,160
A machine name and a downtime estimate

216
00:08:19,160 --> 00:08:20,360
won't tell you that.

217
00:08:20,360 --> 00:08:22,320
You need the production context around it.

218
00:08:22,320 --> 00:08:23,480
Picture a machining cell.

219
00:08:23,480 --> 00:08:26,080
The stopped machine may sit in Workcenter 120

220
00:08:26,080 --> 00:08:28,440
and the ERP may label it as CNC3.

221
00:08:28,440 --> 00:08:29,600
That identifies the asset.

222
00:08:29,600 --> 00:08:31,680
It doesn't tell you which product families it can run,

223
00:08:31,680 --> 00:08:34,000
which fixtures fit it, which programs have approval,

224
00:08:34,000 --> 00:08:36,680
or which operations require that exact spindle range.

225
00:08:36,680 --> 00:08:38,880
Those details decide whether work can move.

226
00:08:38,880 --> 00:08:41,080
Think of the production model as a chain between product,

227
00:08:41,080 --> 00:08:42,400
process, and resource.

228
00:08:42,400 --> 00:08:44,400
The product tells you what you need to produce.

229
00:08:44,400 --> 00:08:46,000
The process tells you which operations

230
00:08:46,000 --> 00:08:47,960
turn raw material into that product.

231
00:08:47,960 --> 00:08:50,840
The resource tells you where each operation can run

232
00:08:50,840 --> 00:08:53,240
under what conditions and with which limits.

233
00:08:53,240 --> 00:08:55,320
That sounds like master data, because it is.

234
00:08:55,320 --> 00:08:57,600
But during an outage, it becomes the difference

235
00:08:57,600 --> 00:09:00,440
between a useful plan and a very confident guess.

236
00:09:00,440 --> 00:09:01,800
Let's make this concrete.

237
00:09:01,800 --> 00:09:03,200
Say the machine has stopped halfway

238
00:09:03,200 --> 00:09:05,160
through an order for a precision component.

239
00:09:05,160 --> 00:09:06,920
The operation needs a specific fixture,

240
00:09:06,920 --> 00:09:09,200
a qualified cutting program, and an inspection route

241
00:09:09,200 --> 00:09:10,320
tied to that product.

242
00:09:10,320 --> 00:09:12,320
Another machine may look similar, and it may even

243
00:09:12,320 --> 00:09:13,320
have free time.

244
00:09:13,320 --> 00:09:14,840
But it can't become an alternate resource

245
00:09:14,840 --> 00:09:16,640
just because both machines cut metal.

246
00:09:16,640 --> 00:09:18,800
The alternate machine needs the right capability.

247
00:09:18,800 --> 00:09:19,800
It needs the fixture.

248
00:09:19,800 --> 00:09:21,760
The program needs approval for that machine.

249
00:09:21,760 --> 00:09:24,120
The operator may need a specific qualification.

250
00:09:24,120 --> 00:09:25,800
Quality may need to approve the transfer,

251
00:09:25,800 --> 00:09:28,200
especially if the move changes the process conditions

252
00:09:28,200 --> 00:09:29,280
that affect the part.

253
00:09:29,280 --> 00:09:31,440
A blank space in a calendar isn't capacity.

254
00:09:31,440 --> 00:09:33,960
It's just unused time until those facts line up.

255
00:09:33,960 --> 00:09:35,560
The same applies to the work already

256
00:09:35,560 --> 00:09:36,880
around the stopped machine.

257
00:09:36,880 --> 00:09:38,520
You need to know what order it was running,

258
00:09:38,520 --> 00:09:41,440
where the operation stopped, and what quantity can move forward.

259
00:09:41,440 --> 00:09:43,960
You also need to know what sits in the queue, what arrives next,

260
00:09:43,960 --> 00:09:46,040
and where the work in progress can wait without damage,

261
00:09:46,040 --> 00:09:46,960
or extra risk.

262
00:09:46,960 --> 00:09:49,440
Work in progress means material that has started its route

263
00:09:49,440 --> 00:09:50,960
but hasn't finished the product.

264
00:09:50,960 --> 00:09:53,280
In some processes, it can wait for hours or days.

265
00:09:53,280 --> 00:09:55,320
In others, it has a limited time before it needs

266
00:09:55,320 --> 00:09:56,560
the next operation.

267
00:09:56,560 --> 00:09:58,960
A coating process, a heat treatment step,

268
00:09:58,960 --> 00:10:00,800
or a material with a shelf life limit

269
00:10:00,800 --> 00:10:03,640
can turn a machine outage into a much tighter problem

270
00:10:03,640 --> 00:10:05,440
than the schedule first suggests.

271
00:10:05,440 --> 00:10:07,480
Downstream work belongs in the same picture.

272
00:10:07,480 --> 00:10:09,200
If the stopped machine feeds assembly,

273
00:10:09,200 --> 00:10:11,600
you need to know whether assembly has a buffer of parts,

274
00:10:11,600 --> 00:10:14,280
whether the next step needs the output in a fixed sequence,

275
00:10:14,280 --> 00:10:16,520
and whether a delay creates idle time for people

276
00:10:16,520 --> 00:10:19,120
or another expensive resource.

277
00:10:19,120 --> 00:10:21,200
If the machine follows a prior operation,

278
00:10:21,200 --> 00:10:23,280
you need to know whether that earlier process

279
00:10:23,280 --> 00:10:26,120
should keep producing or slow down before the buffer fills.

280
00:10:26,120 --> 00:10:28,480
This is where local machine data stops being enough.

281
00:10:28,480 --> 00:10:31,200
The machine sits inside a flow of material, tools, people,

282
00:10:31,200 --> 00:10:32,720
and approved work steps.

283
00:10:32,720 --> 00:10:35,520
That flow often crosses systems, which explains why a planner

284
00:10:35,520 --> 00:10:38,120
can have a clean machine status and still lack the information

285
00:10:38,120 --> 00:10:39,920
needed to make a sound decision.

286
00:10:39,920 --> 00:10:43,120
A proper resource record should describe more than available hours.

287
00:10:43,120 --> 00:10:45,440
It should describe what the resource can produce,

288
00:10:45,440 --> 00:10:47,680
what it cannot produce, and under which rules.

289
00:10:47,680 --> 00:10:49,720
Capacity matters, but so do physical limits,

290
00:10:49,720 --> 00:10:51,960
product approvals, tooling links, process settings,

291
00:10:51,960 --> 00:10:53,320
and quality restrictions.

292
00:10:53,320 --> 00:10:54,720
Some limits are fixed.

293
00:10:54,720 --> 00:10:56,800
A smaller machine can't run a larger part.

294
00:10:56,800 --> 00:10:58,400
Other limits change with the shift.

295
00:10:58,400 --> 00:11:00,080
A qualified operator may not be available.

296
00:11:00,080 --> 00:11:01,600
A fixture may be in use elsewhere.

297
00:11:01,600 --> 00:11:04,240
A program may be valid only after a certain setup.

298
00:11:04,240 --> 00:11:06,360
You need both kinds of facts if you want an architecture

299
00:11:06,360 --> 00:11:08,920
that actually scales beyond a simple daily plan.

300
00:11:08,920 --> 00:11:10,800
There's a useful distinction to keep in mind.

301
00:11:10,800 --> 00:11:13,440
Machine identity answers, which assets stopped?

302
00:11:13,440 --> 00:11:15,560
Production capability answers, which work

303
00:11:15,560 --> 00:11:17,760
can this asset perform with which conditions,

304
00:11:17,760 --> 00:11:19,800
and what can take over if it can't.

305
00:11:19,800 --> 00:11:21,800
Many systems store the first answer well.

306
00:11:21,800 --> 00:11:24,560
The second answer often lives partly in routing data,

307
00:11:24,560 --> 00:11:28,000
partly in MES settings, partly in maintenance records,

308
00:11:28,000 --> 00:11:30,280
and partly in the experience of the supervisor

309
00:11:30,280 --> 00:11:33,600
who knows which workaround will create trouble later.

310
00:11:33,600 --> 00:11:36,040
That knowledge shouldn't all stay in people's heads.

311
00:11:36,040 --> 00:11:37,840
People will always apply judgment,

312
00:11:37,840 --> 00:11:41,160
especially when a situation falls outside the normal rules.

313
00:11:41,160 --> 00:11:43,200
But the repeatable links need a shared model,

314
00:11:43,200 --> 00:11:44,920
or every breakdown starts with a search

315
00:11:44,920 --> 00:11:47,760
through different systems and a few calls across the plant.

316
00:11:47,760 --> 00:11:49,560
You don't need to model the entire factory

317
00:11:49,560 --> 00:11:51,280
in perfect detail on day one.

318
00:11:51,280 --> 00:11:52,800
Start with the resources where failure

319
00:11:52,800 --> 00:11:55,000
creates real delivery or flow risk.

320
00:11:55,000 --> 00:11:57,200
Link those resources to the products, operations,

321
00:11:57,200 --> 00:11:59,120
tools, fixtures, and approval rules

322
00:11:59,120 --> 00:12:00,880
that matter for the planning decision.

323
00:12:00,880 --> 00:12:04,000
Then test the model against real shop floor questions.

324
00:12:04,000 --> 00:12:06,280
Can it tell you which operation the machine performs?

325
00:12:06,280 --> 00:12:08,360
Can it tell you which fixture is needed?

326
00:12:08,360 --> 00:12:10,520
Can it separate a technically similar machine

327
00:12:10,520 --> 00:12:12,400
from a genuinely approved alternate?

328
00:12:12,400 --> 00:12:13,960
If the answer depends on a spreadsheet

329
00:12:13,960 --> 00:12:17,640
or a single expert's memory, you found a gap worth fixing.

330
00:12:17,640 --> 00:12:19,360
Once that production context exists,

331
00:12:19,360 --> 00:12:21,120
planners can trace the effect of an outage

332
00:12:21,120 --> 00:12:22,680
instead of guessing from a machine name

333
00:12:22,680 --> 00:12:24,360
and an empty time slot.

334
00:12:24,360 --> 00:12:26,760
Trace the orders that actually depend on the machine.

335
00:12:26,760 --> 00:12:28,600
Now here's where a lot of teams go wrong.

336
00:12:28,600 --> 00:12:30,160
Once you know what a machine can actually do,

337
00:12:30,160 --> 00:12:32,400
you ask which orders really depend on it right now.

338
00:12:32,400 --> 00:12:33,360
That sounds straightforward,

339
00:12:33,360 --> 00:12:36,640
but most people pull every order assigned to that work center

340
00:12:36,640 --> 00:12:38,720
and treat them all as equally exposed.

341
00:12:38,720 --> 00:12:39,480
They aren't.

342
00:12:39,480 --> 00:12:41,960
Start with the order already running when the fault hit.

343
00:12:41,960 --> 00:12:44,440
Check its operation status, the quantity completed,

344
00:12:44,440 --> 00:12:45,600
what's still waiting,

345
00:12:45,600 --> 00:12:47,960
and whether the part can pause safely at that stage.

346
00:12:47,960 --> 00:12:49,800
If the operator finished most of the batch

347
00:12:49,800 --> 00:12:51,200
before everything stopped,

348
00:12:51,200 --> 00:12:54,320
the real risk might only sit with a small remaining quantity.

349
00:12:54,320 --> 00:12:55,600
If the machine stopped mid-cycle,

350
00:12:55,600 --> 00:12:57,520
you need to know whether that part needs rework,

351
00:12:57,520 --> 00:12:59,120
inspection, or scrap approval

352
00:12:59,120 --> 00:13:01,240
before anyone plans the next operation.

353
00:13:01,240 --> 00:13:02,320
Then look at the queue.

354
00:13:02,320 --> 00:13:04,560
These are the orders physically waiting for this resource

355
00:13:04,560 --> 00:13:06,600
or released and expected to arrive soon.

356
00:13:06,600 --> 00:13:07,520
Sequence matters here,

357
00:13:07,520 --> 00:13:09,280
but don't assume the first order in line

358
00:13:09,280 --> 00:13:10,960
creates the biggest business risk.

359
00:13:10,960 --> 00:13:12,560
One order might have room in its due date.

360
00:13:12,560 --> 00:13:14,520
Another could be feeding a customer shipment,

361
00:13:14,520 --> 00:13:15,760
a later assembly step,

362
00:13:15,760 --> 00:13:17,720
or a process that only runs on certain days.

363
00:13:17,720 --> 00:13:18,680
They're not the same thing.

364
00:13:18,680 --> 00:13:20,200
After that, check further ahead

365
00:13:20,200 --> 00:13:22,640
at orders scheduled later in the planning horizon.

366
00:13:22,640 --> 00:13:23,920
Some appear on the stock machine

367
00:13:23,920 --> 00:13:25,680
because the original plan selected it

368
00:13:25,680 --> 00:13:28,240
while the routing already permits another approved route.

369
00:13:28,240 --> 00:13:30,760
Others depend on that machine in a much stricter sense.

370
00:13:30,760 --> 00:13:32,320
No alternate route exists,

371
00:13:32,320 --> 00:13:34,960
or the product needs a process condition available nowhere else.

372
00:13:34,960 --> 00:13:36,440
Those are completely different cases

373
00:13:36,440 --> 00:13:38,640
and your planning system needs to keep them separate.

374
00:13:38,640 --> 00:13:41,000
A routing tells you the planned path through production.

375
00:13:41,000 --> 00:13:43,280
It defines the operations an order must pass through

376
00:13:43,280 --> 00:13:45,360
and where the data supports it,

377
00:13:45,360 --> 00:13:46,680
the resources or work centers

378
00:13:46,680 --> 00:13:48,440
that can perform each operation.

379
00:13:48,440 --> 00:13:49,600
But a routing doesn't always mean

380
00:13:49,600 --> 00:13:50,960
every order can move freely.

381
00:13:50,960 --> 00:13:52,240
There may be alternate routes,

382
00:13:52,240 --> 00:13:54,040
but those routes include rules.

383
00:13:54,040 --> 00:13:57,200
Take a batch that needs a controlled sequence of operations.

384
00:13:57,200 --> 00:13:59,320
You might move the first operation to another machine,

385
00:13:59,320 --> 00:14:02,160
but only if the batch stays together through a later step.

386
00:14:02,160 --> 00:14:04,480
Or you could split the order across approved resources,

387
00:14:04,480 --> 00:14:06,120
but only above a certain batch size

388
00:14:06,120 --> 00:14:08,480
and only of traceability keeps the lot separate.

389
00:14:08,480 --> 00:14:10,520
In another process, splitting the order

390
00:14:10,520 --> 00:14:11,600
creates a quality problem

391
00:14:11,600 --> 00:14:15,000
because all parts need identical settings from one run.

392
00:14:15,000 --> 00:14:17,480
The planner needs those rules before proposing a move.

393
00:14:17,480 --> 00:14:19,960
Material status belongs in the impact check too.

394
00:14:19,960 --> 00:14:21,160
An order may look urgent,

395
00:14:21,160 --> 00:14:23,880
but the material might not be available at an alternate resource.

396
00:14:23,880 --> 00:14:25,400
It could still sit in receiving.

397
00:14:25,400 --> 00:14:27,120
It might be allocated to another order.

398
00:14:27,120 --> 00:14:30,000
Or the material may already be staged at the stopped machine,

399
00:14:30,000 --> 00:14:31,760
which creates a physical movement task

400
00:14:31,760 --> 00:14:34,480
that the planning system shouldn't pretend happens by itself.

401
00:14:34,480 --> 00:14:35,480
Due dates matter,

402
00:14:35,480 --> 00:14:37,360
though not all dates mean the same thing.

403
00:14:37,360 --> 00:14:39,760
A customer promise deserves attention, obviously.

404
00:14:39,760 --> 00:14:41,800
But internal milestones can matter just as much.

405
00:14:41,800 --> 00:14:45,080
A component may need to reach assembly before a scheduled build.

406
00:14:45,080 --> 00:14:47,680
A batch may need to clear inspection before transport leaves.

407
00:14:47,680 --> 00:14:49,160
Some orders feed safety stock,

408
00:14:49,160 --> 00:14:51,680
which gives you more room than a direct customer shipment,

409
00:14:51,680 --> 00:14:54,080
unless that stock already sits near its minimum level.

410
00:14:54,080 --> 00:14:56,520
This is why an impact list needs more than order number,

411
00:14:56,520 --> 00:14:58,040
quantity and due date.

412
00:14:58,040 --> 00:14:59,680
It needs to explain the dependency.

413
00:14:59,680 --> 00:15:01,160
Is the order currently interrupted?

414
00:15:01,160 --> 00:15:02,600
Is it queued at the resource?

415
00:15:02,600 --> 00:15:04,000
Does it have an approved alternate route?

416
00:15:04,000 --> 00:15:04,840
Can it split?

417
00:15:04,840 --> 00:15:07,400
Does material exist where the alternate work would run?

418
00:15:07,400 --> 00:15:09,120
Which date or downstream commitment

419
00:15:09,120 --> 00:15:11,080
comes under pressure if nothing changes?

420
00:15:11,080 --> 00:15:12,520
That explanation stops the team

421
00:15:12,520 --> 00:15:15,000
from treating every scheduled order like a crisis.

422
00:15:15,000 --> 00:15:16,800
Here's a dependency that often stays hidden

423
00:15:16,800 --> 00:15:18,440
until a breakdown.

424
00:15:18,440 --> 00:15:20,680
The machine may not directly process an order,

425
00:15:20,680 --> 00:15:22,640
but it might share a fixture, a test device,

426
00:15:22,640 --> 00:15:24,800
a program license, or another limited resource

427
00:15:24,800 --> 00:15:26,120
with the machine that does.

428
00:15:26,120 --> 00:15:27,520
Moving work away from the outage

429
00:15:27,520 --> 00:15:29,880
could claim that shared item and disrupt an order

430
00:15:29,880 --> 00:15:31,960
that never appeared on the first impact list.

431
00:15:31,960 --> 00:15:34,120
So trace direct dependence first,

432
00:15:34,120 --> 00:15:35,600
then inspect shared dependencies

433
00:15:35,600 --> 00:15:37,880
around any proposed alternate route.

434
00:15:37,880 --> 00:15:40,040
You don't need to scan the whole plant for every stop.

435
00:15:40,040 --> 00:15:42,560
You need enough context to separate real exposure

436
00:15:42,560 --> 00:15:43,880
from assumed exposure.

437
00:15:43,880 --> 00:15:46,320
A good impact assessment narrows the decision.

438
00:15:46,320 --> 00:15:48,360
It shows which work needs attention now,

439
00:15:48,360 --> 00:15:50,360
which can wait and which only looks affected

440
00:15:50,360 --> 00:15:52,960
because the original schedule placed it on that machine

441
00:15:52,960 --> 00:15:54,520
that keeps re-planning focused.

442
00:15:54,520 --> 00:15:56,320
And it matters because moving one order away

443
00:15:56,320 --> 00:16:00,120
from a failed machine can shift the constraint somewhere else.

444
00:16:00,120 --> 00:16:02,520
Find the bottleneck after the breakdown.

445
00:16:02,520 --> 00:16:05,360
The affected orders tell you where the immediate risk sits.

446
00:16:05,360 --> 00:16:07,360
They don't tell you where the new constraint will appear

447
00:16:07,360 --> 00:16:08,600
after you move the work.

448
00:16:08,600 --> 00:16:10,680
Picture a line where machine four stops

449
00:16:10,680 --> 00:16:13,160
and the planner finds spare time on machine six.

450
00:16:13,160 --> 00:16:15,240
Moving two urgent orders sound sensible

451
00:16:15,240 --> 00:16:17,680
until machine six also feeds a final inspection station

452
00:16:17,680 --> 00:16:20,200
that already runs close to its limit for the shift.

453
00:16:20,200 --> 00:16:21,760
The work leaves one blocked resource

454
00:16:21,760 --> 00:16:23,640
and builds a queue in front of another.

455
00:16:23,640 --> 00:16:25,080
The breakdown change the flow.

456
00:16:25,080 --> 00:16:26,680
A bottleneck is the part of the process

457
00:16:26,680 --> 00:16:29,000
that limits how much work can pass through

458
00:16:29,000 --> 00:16:30,040
during a given period.

459
00:16:30,040 --> 00:16:31,800
It isn't always the machine with the fault.

460
00:16:31,800 --> 00:16:33,360
In fact, once you move work around,

461
00:16:33,360 --> 00:16:35,400
the bottleneck can shift to a different machine

462
00:16:35,400 --> 00:16:37,640
and inspection step, a skilled operator,

463
00:16:37,640 --> 00:16:39,240
a furnace, a forklift route,

464
00:16:39,240 --> 00:16:42,000
or a tool that only one person can set up.

465
00:16:42,000 --> 00:16:43,520
That shift needs a proper check

466
00:16:43,520 --> 00:16:45,640
before the planner releases a new sequence.

467
00:16:45,640 --> 00:16:48,160
Start with the buffer around the stop machine.

468
00:16:48,160 --> 00:16:50,040
If downstream operations hold enough work

469
00:16:50,040 --> 00:16:51,760
to keep running for most of the shift,

470
00:16:51,760 --> 00:16:53,600
they may not feel the outage straightaway.

471
00:16:53,600 --> 00:16:55,040
That gives the team some room.

472
00:16:55,040 --> 00:16:56,640
On the other hand, a thin buffer means

473
00:16:56,640 --> 00:16:58,880
the next process could run out of parts quickly

474
00:16:58,880 --> 00:17:01,840
even if the failed machine only loses a few hours.

475
00:17:01,840 --> 00:17:03,360
Upstream conditions matter too.

476
00:17:03,360 --> 00:17:06,000
If the prior operation keeps producing into a full buffer,

477
00:17:06,000 --> 00:17:07,120
you're creating another problem

478
00:17:07,120 --> 00:17:09,600
by moving material that has nowhere sensible to go.

479
00:17:09,600 --> 00:17:12,240
You may need to slow that operation, hold its release,

480
00:17:12,240 --> 00:17:15,160
or use available storage if the product and process allow it.

481
00:17:15,160 --> 00:17:18,080
Physical flow doesn't follow the neat logic of an ERP date,

482
00:17:18,080 --> 00:17:20,640
then check the resources around the alternate route.

483
00:17:20,640 --> 00:17:22,720
Can the alternate machine really process

484
00:17:22,720 --> 00:17:24,600
the added work within its available windows?

485
00:17:24,600 --> 00:17:27,120
Does it need a setup that pushes other orders late?

486
00:17:27,120 --> 00:17:28,640
Will it create a queue at inspection?

487
00:17:28,640 --> 00:17:30,080
Can transport move the material

488
00:17:30,080 --> 00:17:31,400
when the new sequence requires it?

489
00:17:31,400 --> 00:17:33,040
Is the operator on that shift qualified

490
00:17:33,040 --> 00:17:35,920
for both the normal work and the work you're trying to move?

491
00:17:35,920 --> 00:17:37,360
Those questions may sound basic.

492
00:17:37,360 --> 00:17:39,080
Under pressure, they often get skipped.

493
00:17:39,080 --> 00:17:40,160
I've seen planning discussions

494
00:17:40,160 --> 00:17:41,840
where someone points to an open machine slot

495
00:17:41,840 --> 00:17:43,120
and treats it like an answer,

496
00:17:43,120 --> 00:17:44,800
but spare machine time doesn't equal

497
00:17:44,800 --> 00:17:46,480
usable production capacity.

498
00:17:46,480 --> 00:17:48,400
A machine may be open because it lacks labor.

499
00:17:48,400 --> 00:17:49,560
It might wait for a tool.

500
00:17:49,560 --> 00:17:51,720
It could need a cleaning cycle between product groups,

501
00:17:51,720 --> 00:17:53,800
or the time may sit in the wrong part of the day

502
00:17:53,800 --> 00:17:56,480
after the material needs to leave for the next operation.

503
00:17:56,480 --> 00:17:59,080
Capacity only helps when it exists at the right resource

504
00:17:59,080 --> 00:18:01,240
at the right time with the right conditions.

505
00:18:01,240 --> 00:18:03,240
This is why rough averages can mislead.

506
00:18:03,240 --> 00:18:05,800
A work center might show enough capacity across the week,

507
00:18:05,800 --> 00:18:07,880
while the actual problem sits in a narrow window

508
00:18:07,880 --> 00:18:09,040
on Tuesday afternoon.

509
00:18:09,040 --> 00:18:10,560
The orders that need the resource arrive

510
00:18:10,560 --> 00:18:11,520
at the same time,

511
00:18:11,520 --> 00:18:13,680
the qualified operator works only one shift

512
00:18:13,680 --> 00:18:16,880
and inspection can accept the parts only after a setup change.

513
00:18:16,880 --> 00:18:18,240
Weekly capacity looks fine.

514
00:18:18,240 --> 00:18:19,760
The dispatch plan still fails.

515
00:18:19,760 --> 00:18:22,400
Finite capacity thinking forces the harder question.

516
00:18:22,400 --> 00:18:24,840
Can this operation fit into a real time slot

517
00:18:24,840 --> 00:18:27,240
without claiming the same person, machine, tool,

518
00:18:27,240 --> 00:18:28,640
or material twice?

519
00:18:28,640 --> 00:18:29,960
That isn't an argument for building

520
00:18:29,960 --> 00:18:32,360
a huge mathematical model before anyone acts.

521
00:18:32,360 --> 00:18:34,480
It means the team should test the local consequences

522
00:18:34,480 --> 00:18:37,080
of each move against the limits that govern production.

523
00:18:37,080 --> 00:18:38,520
Start where the failure lands,

524
00:18:38,520 --> 00:18:40,800
then trace forward to the next constraint step

525
00:18:40,800 --> 00:18:42,880
and backward to the material feeding it.

526
00:18:42,880 --> 00:18:44,760
Sometimes the best response is to leave an order

527
00:18:44,760 --> 00:18:46,720
where it is an accept or control delay

528
00:18:46,720 --> 00:18:48,880
because moving it would cause a larger delay elsewhere.

529
00:18:48,880 --> 00:18:50,240
That can feel counter-intuitive

530
00:18:50,240 --> 00:18:52,200
when a machine has spare hours.

531
00:18:52,200 --> 00:18:54,680
Yet an alternate route that blocks final inspection

532
00:18:54,680 --> 00:18:57,560
creates an extra setup and displaces a more urgent order

533
00:18:57,560 --> 00:18:58,960
doesn't improve the plan.

534
00:18:58,960 --> 00:19:00,720
It just spreads the disruption more widely.

535
00:19:00,720 --> 00:19:03,200
There's a dry factory rule worth remembering.

536
00:19:03,200 --> 00:19:05,240
Moving work often moves the problem.

537
00:19:05,240 --> 00:19:07,520
The plan also needs to separate temporary pressure

538
00:19:07,520 --> 00:19:09,000
from a genuine bottleneck.

539
00:19:09,000 --> 00:19:10,400
A queue can grow for an hour

540
00:19:10,400 --> 00:19:13,160
and then clear if the shift has enough recovery room.

541
00:19:13,160 --> 00:19:15,040
A true constraint keeps accumulating work

542
00:19:15,040 --> 00:19:16,480
because the process cannot catch up

543
00:19:16,480 --> 00:19:17,920
under the current conditions.

544
00:19:17,920 --> 00:19:20,240
That distinction affects whether you change the schedule

545
00:19:20,240 --> 00:19:22,880
at local support or simply monitor the flow.

546
00:19:22,880 --> 00:19:25,480
So don't ask only where you can place the affected orders.

547
00:19:25,480 --> 00:19:27,880
Ask what each move does to the next limited resource,

548
00:19:27,880 --> 00:19:30,560
the buffer before it, and the people needed to execute it.

549
00:19:30,560 --> 00:19:31,800
Before changing the schedule,

550
00:19:31,800 --> 00:19:34,160
protect the commitments that carry the most consequence.

551
00:19:34,160 --> 00:19:36,120
Decide what the plan must protect.

552
00:19:36,120 --> 00:19:37,760
Once you know where the pressure will land,

553
00:19:37,760 --> 00:19:40,640
you need a rule for deciding which commitments take priority.

554
00:19:40,640 --> 00:19:41,640
Without that rule,

555
00:19:41,640 --> 00:19:43,640
the re-planning meeting turns into a contest

556
00:19:43,640 --> 00:19:46,000
between whoever calls first, whoever speaks loudest

557
00:19:46,000 --> 00:19:49,080
and whoever has the most senior person copied into an email.

558
00:19:49,080 --> 00:19:50,520
That isn't a planning policy.

559
00:19:50,520 --> 00:19:52,520
It's just noise with a calendar attached.

560
00:19:52,520 --> 00:19:54,840
Start with the commitments the plant has already chosen

561
00:19:54,840 --> 00:19:55,840
to protect.

562
00:19:55,840 --> 00:19:58,720
Customer orders with fixed ship dates sit at the top,

563
00:19:58,720 --> 00:20:00,440
but even that needs more detail.

564
00:20:00,440 --> 00:20:03,320
A late replacement part for a customer whose line is stopped

565
00:20:03,320 --> 00:20:04,760
carries a different consequence

566
00:20:04,760 --> 00:20:06,960
from an order that can ship with a later load.

567
00:20:06,960 --> 00:20:09,480
So planning needs a clear way to capture that difference

568
00:20:09,480 --> 00:20:11,000
before the machine fails.

569
00:20:11,000 --> 00:20:14,040
Some work protects safety stock rather than a direct shipment.

570
00:20:14,040 --> 00:20:14,960
That buys you room,

571
00:20:14,960 --> 00:20:17,280
but only if the stock level genuinely covers demand

572
00:20:17,280 --> 00:20:18,360
during the outage.

573
00:20:18,360 --> 00:20:20,880
A planner shouldn't treat every stock replenishment order

574
00:20:20,880 --> 00:20:23,400
as low priority because the stock may support

575
00:20:23,400 --> 00:20:25,160
a high-risk product family

576
00:20:25,160 --> 00:20:27,840
and already sit close to its agreed floor.

577
00:20:27,840 --> 00:20:29,560
Campaign rules matter too.

578
00:20:29,560 --> 00:20:32,200
In many plants, changing the sequence creates costs

579
00:20:32,200 --> 00:20:35,160
that don't show up in the simple due date sort.

580
00:20:35,160 --> 00:20:37,080
You may need to run similar grades together

581
00:20:37,080 --> 00:20:39,560
to avoid cleaning, keep a process warm,

582
00:20:39,560 --> 00:20:40,920
or avoid breaking a campaign

583
00:20:40,920 --> 00:20:44,000
because restarting at risks, scrap, extra testing,

584
00:20:44,000 --> 00:20:46,880
or lost time that affects far more than one order.

585
00:20:46,880 --> 00:20:50,000
Then there are materials that don't wait politely.

586
00:20:50,000 --> 00:20:51,880
Some materials expire after mixing,

587
00:20:51,880 --> 00:20:53,800
throwing, coating, or preparation.

588
00:20:53,800 --> 00:20:56,800
Some batches must stay within a defined process window.

589
00:20:56,800 --> 00:20:58,560
If an outage puts that material at risk,

590
00:20:58,560 --> 00:21:00,560
the plan may need to protect it even when another order

591
00:21:00,560 --> 00:21:02,040
has an earlier customer date.

592
00:21:02,040 --> 00:21:04,200
The aim isn't to ignore customer commitments.

593
00:21:04,200 --> 00:21:06,440
It's to avoid saving one shipment

594
00:21:06,440 --> 00:21:07,920
while creating avoidable waste

595
00:21:07,920 --> 00:21:09,920
or equality issue somewhere else.

596
00:21:09,920 --> 00:21:13,360
This is why priority needs more than one field in an ERP order.

597
00:21:13,360 --> 00:21:16,000
A useful planning policy can weigh the customer promise,

598
00:21:16,000 --> 00:21:17,760
the internal production milestone,

599
00:21:17,760 --> 00:21:19,040
the risk of material loss,

600
00:21:19,040 --> 00:21:21,080
and the effect on the wider schedule.

601
00:21:21,080 --> 00:21:22,760
You might also include the cost of delay,

602
00:21:22,760 --> 00:21:24,320
though I'd keep that practical.

603
00:21:24,320 --> 00:21:26,400
If the estimate depends on a complicated formula

604
00:21:26,400 --> 00:21:28,720
nobody trusts, people will go back to gut feel

605
00:21:28,720 --> 00:21:30,240
the moment the pressure rises.

606
00:21:30,240 --> 00:21:32,640
The policy needs to exist before the disruption.

607
00:21:32,640 --> 00:21:35,160
During a breakdown, the planner, production supervisor,

608
00:21:35,160 --> 00:21:37,080
customer service team, and maintenance lead

609
00:21:37,080 --> 00:21:38,320
already have enough to deal with.

610
00:21:38,320 --> 00:21:39,640
They shouldn't need to make up the rules

611
00:21:39,640 --> 00:21:40,960
for which order moves first.

612
00:21:40,960 --> 00:21:42,520
When those rules aren't agreed in advance,

613
00:21:42,520 --> 00:21:44,720
every incident becomes a separate negotiation

614
00:21:44,720 --> 00:21:46,760
and the schedule changes based on relationships

615
00:21:46,760 --> 00:21:48,640
rather than operating intent.

616
00:21:48,640 --> 00:21:50,440
That doesn't mean you can remove judgment.

617
00:21:50,440 --> 00:21:53,480
A planner might know a customer has accepted some flexibility

618
00:21:53,480 --> 00:21:54,800
while customer service could know

619
00:21:54,800 --> 00:21:57,320
a partial delivery solves the immediate problem.

620
00:21:57,320 --> 00:22:00,560
A production supervisor might know a normally low priority order

621
00:22:00,560 --> 00:22:02,320
can run with almost no setup loss

622
00:22:02,320 --> 00:22:04,640
because the machine is already prepared for it.

623
00:22:04,640 --> 00:22:07,400
Good planning leaves space for that kind of local knowledge,

624
00:22:07,400 --> 00:22:09,480
but judgment should work with invisible rules,

625
00:22:09,480 --> 00:22:10,480
not replace them.

626
00:22:10,480 --> 00:22:12,840
Take two orders waiting for an alternate resource.

627
00:22:12,840 --> 00:22:14,560
One has an urgent looking due date,

628
00:22:14,560 --> 00:22:16,520
but needs a long change over a material

629
00:22:16,520 --> 00:22:18,120
that hasn't reached the area.

630
00:22:18,120 --> 00:22:20,760
The other has a slightly later date, material already staged,

631
00:22:20,760 --> 00:22:22,640
and can run straight after the current job.

632
00:22:22,640 --> 00:22:24,040
If you force the first order through

633
00:22:24,040 --> 00:22:25,680
because its date appears earlier,

634
00:22:25,680 --> 00:22:28,000
you lose hours, push both orders late,

635
00:22:28,000 --> 00:22:30,760
and create overtime the plant never approved.

636
00:22:30,760 --> 00:22:32,960
Priority answers what the plan should protect,

637
00:22:32,960 --> 00:22:35,200
but it doesn't erase physical limits.

638
00:22:35,200 --> 00:22:37,120
Over time belongs in the same discussion.

639
00:22:37,120 --> 00:22:38,680
It can protect a shipment,

640
00:22:38,680 --> 00:22:40,800
but it carries cost, fatigue, labor rules,

641
00:22:40,800 --> 00:22:43,240
and sometimes a quality risk if the team asks people

642
00:22:43,240 --> 00:22:46,280
to run an unfamiliar process at the end of a long shift.

643
00:22:46,280 --> 00:22:48,920
A good policy lays out when overtime is acceptable,

644
00:22:48,920 --> 00:22:51,720
who can approve it, and what type of order justifies it.

645
00:22:51,720 --> 00:22:53,000
The same goes for changeovers,

646
00:22:53,000 --> 00:22:55,080
a plan that saves a few hours on one order

647
00:22:55,080 --> 00:22:56,920
but causes repeated product switches,

648
00:22:56,920 --> 00:22:59,600
consumes the very capacity it tries to recover.

649
00:22:59,600 --> 00:23:01,760
If changeover loss matters on that resource,

650
00:23:01,760 --> 00:23:03,840
planning needs to treat it as part of the decision,

651
00:23:03,840 --> 00:23:06,160
not as an unpleasant surprise for the next shift.

652
00:23:06,160 --> 00:23:08,160
Make these priorities visible across planning,

653
00:23:08,160 --> 00:23:09,920
production, and customer service.

654
00:23:09,920 --> 00:23:12,480
People don't need to agree with every outcome in the moment,

655
00:23:12,480 --> 00:23:14,760
but they need to understand why the plan

656
00:23:14,760 --> 00:23:16,760
protects one commitment before another,

657
00:23:16,760 --> 00:23:18,800
that makes difficult choices easier to explain,

658
00:23:18,800 --> 00:23:21,000
and it stops the shop floor from receiving a sequence

659
00:23:21,000 --> 00:23:22,000
that feels random.

660
00:23:22,000 --> 00:23:24,240
Priorities point the plan in the right direction,

661
00:23:24,240 --> 00:23:25,800
but the factory constraints decide

662
00:23:25,800 --> 00:23:28,960
whether any proposed response can actually run.

663
00:23:28,960 --> 00:23:31,440
Map the constraints behind every alternative.

664
00:23:31,440 --> 00:23:33,880
Once priorities point to the order's worth protecting,

665
00:23:33,880 --> 00:23:35,600
the next step gets less comfortable.

666
00:23:35,600 --> 00:23:37,440
You have to test whether each proposed move

667
00:23:37,440 --> 00:23:39,240
can actually run in the real plant.

668
00:23:39,240 --> 00:23:41,440
An alternate machine might look available in the plan,

669
00:23:41,440 --> 00:23:43,200
but the order still needs a chain of conditions

670
00:23:43,200 --> 00:23:44,040
around that machine.

671
00:23:44,040 --> 00:23:45,240
Break any link in that chain

672
00:23:45,240 --> 00:23:46,720
and the move stays theoretical.

673
00:23:46,720 --> 00:23:48,040
Start with machine capability.

674
00:23:48,040 --> 00:23:49,800
Not every alternate resource can produce

675
00:23:49,800 --> 00:23:51,560
the same part to the same process rules,

676
00:23:51,560 --> 00:23:54,120
even when the routing groups them under one work center.

677
00:23:54,120 --> 00:23:56,080
The machine might lack the right travel range,

678
00:23:56,080 --> 00:23:58,200
pressure range, temperature control, spindle speed

679
00:23:58,200 --> 00:23:59,400
or program version.

680
00:23:59,400 --> 00:24:00,800
Those are physical limits,

681
00:24:00,800 --> 00:24:02,720
and no schedule can negotiate with them.

682
00:24:02,720 --> 00:24:03,920
Tooling comes next.

683
00:24:03,920 --> 00:24:05,720
You might have an approved alternate machine,

684
00:24:05,720 --> 00:24:08,040
but the fixture is mounted on another resource

685
00:24:08,040 --> 00:24:10,320
in calibration or waiting for repair.

686
00:24:10,320 --> 00:24:13,320
In some plans, the tool itself creates the constraint.

687
00:24:13,320 --> 00:24:15,440
There might be only one mold, one test adapter,

688
00:24:15,440 --> 00:24:16,760
or one gauge set.

689
00:24:16,760 --> 00:24:19,400
The machine can wait, but the order can't run without the tool.

690
00:24:19,400 --> 00:24:20,400
Then there are people,

691
00:24:20,400 --> 00:24:22,400
an operator might know the normal machine well,

692
00:24:22,400 --> 00:24:24,800
while the alternate resource needs a separate qualification.

693
00:24:24,800 --> 00:24:26,400
That isn't paperwork for its own sake.

694
00:24:26,400 --> 00:24:28,560
The qualification might cover safe setup,

695
00:24:28,560 --> 00:24:30,640
process control, inspection steps,

696
00:24:30,640 --> 00:24:33,200
or a machine behavior that affects part quality.

697
00:24:33,200 --> 00:24:34,480
A plan that assigns the work

698
00:24:34,480 --> 00:24:37,400
without that skill available doesn't solve the outage.

699
00:24:37,400 --> 00:24:39,160
It just hands the supervisor a problem

700
00:24:39,160 --> 00:24:41,160
five minutes before the shift starts.

701
00:24:41,160 --> 00:24:43,440
Material status needs the same level of care.

702
00:24:43,440 --> 00:24:45,080
You need to check if the correct material

703
00:24:45,080 --> 00:24:46,280
is physically available,

704
00:24:46,280 --> 00:24:48,120
if it has passed incoming inspection,

705
00:24:48,120 --> 00:24:49,880
if it's reserved for another work order.

706
00:24:49,880 --> 00:24:51,320
If the material needs drying,

707
00:24:51,320 --> 00:24:53,840
throwing, mixing, or pre-treatment before it can run,

708
00:24:53,840 --> 00:24:54,960
you need to know if that can happen

709
00:24:54,960 --> 00:24:56,400
within the new schedule window.

710
00:24:56,400 --> 00:24:57,880
Those questions turn an apparent option

711
00:24:57,880 --> 00:24:59,280
into an actual option.

712
00:24:59,280 --> 00:25:01,600
Quality approval narrows the choices further.

713
00:25:01,600 --> 00:25:03,880
A product might run on another resource only after

714
00:25:03,880 --> 00:25:06,560
a process engineer or quality team approves the route.

715
00:25:06,560 --> 00:25:08,800
The reason could be a different heat profile,

716
00:25:08,800 --> 00:25:10,160
a different cutting condition,

717
00:25:10,160 --> 00:25:11,760
or a different inspection method.

718
00:25:11,760 --> 00:25:13,320
If that approval doesn't exist,

719
00:25:13,320 --> 00:25:15,480
planning should mark the option as conditional,

720
00:25:15,480 --> 00:25:18,320
not treated as available capacity without marking it.

721
00:25:18,320 --> 00:25:19,520
Now consider sequence.

722
00:25:19,520 --> 00:25:21,560
Many resources don't lose the same amount of time

723
00:25:21,560 --> 00:25:23,000
between every pair of orders.

724
00:25:23,000 --> 00:25:24,880
Moving from one material grade to another

725
00:25:24,880 --> 00:25:26,240
might need a long cleanup,

726
00:25:26,240 --> 00:25:28,440
changing a color, a chemical, a coating,

727
00:25:28,440 --> 00:25:30,120
or a tooling setup consumes time

728
00:25:30,120 --> 00:25:31,680
and creates scrap risk.

729
00:25:31,680 --> 00:25:34,920
In food, farmer, chemical, and many process plants,

730
00:25:34,920 --> 00:25:37,200
that sequence involves formal cleaning rules

731
00:25:37,200 --> 00:25:38,800
rather than a quick operator decision.

732
00:25:38,800 --> 00:25:40,920
So an open slot has a history before it

733
00:25:40,920 --> 00:25:42,440
and a consequence after it.

734
00:25:42,440 --> 00:25:45,080
The plan needs to ask what runs before the move order,

735
00:25:45,080 --> 00:25:46,320
what setup the move needs,

736
00:25:46,320 --> 00:25:48,720
and what it forces the resource to run next.

737
00:25:48,720 --> 00:25:50,360
A schedule that inserts an urgent job

738
00:25:50,360 --> 00:25:52,480
without checking the sequence might look fine

739
00:25:52,480 --> 00:25:54,240
until the team spends half the shift cleaning,

740
00:25:54,240 --> 00:25:56,320
changing tools, validating settings,

741
00:25:56,320 --> 00:25:59,080
and trying to recover the sequence it broke.

742
00:25:59,080 --> 00:26:01,280
Batch rules create another hard boundary.

743
00:26:01,280 --> 00:26:03,000
Some products need a minimum run length

744
00:26:03,000 --> 00:26:05,880
because the setup cost is too high for a tiny batch.

745
00:26:05,880 --> 00:26:07,560
Others must stay together because the batch

746
00:26:07,560 --> 00:26:10,680
has a common lot number, common process settings

747
00:26:10,680 --> 00:26:12,960
or a traceability rule that links every unit

748
00:26:12,960 --> 00:26:15,400
to the same material and test result.

749
00:26:15,400 --> 00:26:17,720
You might want to split the order across two machines,

750
00:26:17,720 --> 00:26:19,240
but the process might only allow that

751
00:26:19,240 --> 00:26:21,000
after quality review or not at all.

752
00:26:21,000 --> 00:26:23,200
Shell life adds a different kind of time pressure.

753
00:26:23,200 --> 00:26:26,240
A prepared material might need processing within a set window,

754
00:26:26,240 --> 00:26:28,520
a semi-finished item might need its next step

755
00:26:28,520 --> 00:26:31,480
before moisture, temperature, or cure state changes.

756
00:26:31,480 --> 00:26:34,480
In those cases, moving an order later isn't a harmless delay,

757
00:26:34,480 --> 00:26:36,360
it can remove the option completely.

758
00:26:36,360 --> 00:26:39,040
Maintenance conditions also belong in the constraint model.

759
00:26:39,040 --> 00:26:41,520
A machine returning from a fault might need a safety lockout

760
00:26:41,520 --> 00:26:43,880
removed, a functional test, a warm-up cycle,

761
00:26:43,880 --> 00:26:45,520
or a formal handback from maintenance

762
00:26:45,520 --> 00:26:47,880
before production can claim the time.

763
00:26:47,880 --> 00:26:49,960
A plan should never place work into the gap

764
00:26:49,960 --> 00:26:53,280
between repair work finished and machine released for production.

765
00:26:53,280 --> 00:26:54,640
Those are not the same state.

766
00:26:54,640 --> 00:26:55,880
This part often causes tension

767
00:26:55,880 --> 00:26:57,640
because people want an answer quickly.

768
00:26:57,640 --> 00:27:00,480
A planner asks, "Can we run this order on machine six?

769
00:27:00,480 --> 00:27:02,400
"The honest answer might be possibly,

770
00:27:02,400 --> 00:27:04,160
"once we confirm the fixture operator,

771
00:27:04,160 --> 00:27:07,440
"program approval, material location, and sequence impact."

772
00:27:07,440 --> 00:27:09,280
That can sound slow, but it's actually faster

773
00:27:09,280 --> 00:27:11,440
than sending an impossible plan to the floor

774
00:27:11,440 --> 00:27:13,880
and discovering each missing condition one by one.

775
00:27:13,880 --> 00:27:15,400
There's a difference between a possible move

776
00:27:15,400 --> 00:27:16,800
and an executable move.

777
00:27:16,800 --> 00:27:18,840
A possible move means the resource could

778
00:27:18,840 --> 00:27:20,760
in principle perform the operation.

779
00:27:20,760 --> 00:27:23,400
An executable move means the machine, tool, operator,

780
00:27:23,400 --> 00:27:26,480
material, process approval, sequence, and safety conditions

781
00:27:26,480 --> 00:27:29,040
all line up in the time window you intend to use.

782
00:27:29,040 --> 00:27:31,800
That distinction needs to appear clearly in the planning process.

783
00:27:31,800 --> 00:27:34,400
Don't show every possible alternate route as equal.

784
00:27:34,400 --> 00:27:36,680
Mark the conditions that still need confirmation,

785
00:27:36,680 --> 00:27:38,960
assign an owner where a check remains open

786
00:27:38,960 --> 00:27:41,200
and prevent release until those checks close.

787
00:27:41,200 --> 00:27:44,320
The purpose isn't to turn re-planning into a long approval ritual,

788
00:27:44,320 --> 00:27:46,080
it's to expose the few constraints

789
00:27:46,080 --> 00:27:48,680
that would stop the work when it reaches the shop floor.

790
00:27:48,680 --> 00:27:51,960
Most plants already know these constraints.

791
00:27:51,960 --> 00:27:54,160
They just don't always sit in the same system

792
00:27:54,160 --> 00:27:57,640
or appear at the moment someone drags an order into a new slot.

793
00:27:57,640 --> 00:28:00,120
Once the constraints sit behind each alternative,

794
00:28:00,120 --> 00:28:01,720
the team can generate response options

795
00:28:01,720 --> 00:28:05,200
without pretending every open slot solves the problem.

796
00:28:05,200 --> 00:28:06,800
Build response options.

797
00:28:06,800 --> 00:28:08,600
Instead of one fragile answer,

798
00:28:08,600 --> 00:28:10,680
here's the thing most planners don't talk about.

799
00:28:10,680 --> 00:28:12,480
Once you know which moves can actually run,

800
00:28:12,480 --> 00:28:14,480
don't ask the system for one perfect answer.

801
00:28:14,480 --> 00:28:16,640
A breakdown rarely gives you enough certainty for that,

802
00:28:16,640 --> 00:28:19,320
especially while maintenance is still working through the repair.

803
00:28:19,320 --> 00:28:21,280
Instead build a small set of response options.

804
00:28:21,280 --> 00:28:23,880
Each option should show what work stays on the failed machine,

805
00:28:23,880 --> 00:28:26,040
what moves elsewhere, what commitments change,

806
00:28:26,040 --> 00:28:28,400
and what the shop floor needs to do differently.

807
00:28:28,400 --> 00:28:30,480
One option might keep the current work where it is

808
00:28:30,480 --> 00:28:32,720
and accept the delay that can be the right call

809
00:28:32,720 --> 00:28:34,280
when the repair window looks short.

810
00:28:34,280 --> 00:28:36,080
No approved alternate route exists

811
00:28:36,080 --> 00:28:38,280
or moving the work would consume more time than waiting.

812
00:28:38,280 --> 00:28:39,320
That's not doing nothing.

813
00:28:39,320 --> 00:28:41,880
It's a deliberate choice to protect the rest of the schedule

814
00:28:41,880 --> 00:28:43,280
from unnecessary disturbance.

815
00:28:43,280 --> 00:28:45,880
Say a machine is likely to return before the end of the shift

816
00:28:45,880 --> 00:28:48,680
and the order on it can still meet its next internal milestone

817
00:28:48,680 --> 00:28:50,040
with some recovery effort.

818
00:28:50,040 --> 00:28:52,280
In that case, holding the order may beat a move

819
00:28:52,280 --> 00:28:54,200
that needs a new setup, tool transfer,

820
00:28:54,200 --> 00:28:56,200
quality checks and a different operator.

821
00:28:56,200 --> 00:28:58,040
The plan absorbs the loss locally

822
00:28:58,040 --> 00:29:00,080
rather than spreading it across the plant.

823
00:29:00,080 --> 00:29:01,920
A second option can move selected orders

824
00:29:01,920 --> 00:29:03,680
to qualified alternate resources.

825
00:29:03,680 --> 00:29:05,400
Notice the word selected.

826
00:29:05,400 --> 00:29:08,600
You don't move the entire queue just because one machine stopped.

827
00:29:08,600 --> 00:29:10,880
Some orders may have a clean alternate route

828
00:29:10,880 --> 00:29:13,400
while others depend on the original resource entirely.

829
00:29:13,400 --> 00:29:16,400
Picture two orders waiting for the same failed machine.

830
00:29:16,400 --> 00:29:18,600
The first uses a standard process already approved

831
00:29:18,600 --> 00:29:21,360
on another machine and the required fixture is free.

832
00:29:21,360 --> 00:29:23,520
The second needs a special setup that exists only

833
00:29:23,520 --> 00:29:24,920
on the failed machine.

834
00:29:24,920 --> 00:29:26,720
Moving the first order can relieve pressure

835
00:29:26,720 --> 00:29:28,280
and protect the customer date.

836
00:29:28,280 --> 00:29:29,800
The second order may need to wait

837
00:29:29,800 --> 00:29:32,320
and the revised plan should state that plainly.

838
00:29:32,320 --> 00:29:34,760
Another option may use more operating time.

839
00:29:34,760 --> 00:29:36,080
That could mean overtime,

840
00:29:36,080 --> 00:29:38,800
an added shift or an approved external resource.

841
00:29:38,800 --> 00:29:40,080
None of those choices are free

842
00:29:40,080 --> 00:29:42,800
and none should enter the plan just because they look available

843
00:29:42,800 --> 00:29:43,800
on paper.

844
00:29:43,800 --> 00:29:46,320
Overtime needs people who can work it safely and legally

845
00:29:46,320 --> 00:29:49,600
along with material, support functions and supervision.

846
00:29:49,600 --> 00:29:52,400
An added shift needs labor, machine readiness

847
00:29:52,400 --> 00:29:54,960
and sometimes quality or maintenance cover.

848
00:29:54,960 --> 00:29:57,720
External capacity needs an approved supplier,

849
00:29:57,720 --> 00:29:59,600
a route that protects traceability

850
00:29:59,600 --> 00:30:02,000
and enough time for material movement and handoff.

851
00:30:02,000 --> 00:30:04,400
The option exists only when those conditions hold.

852
00:30:04,400 --> 00:30:06,720
There may also be a case for splitting an order.

853
00:30:06,720 --> 00:30:08,760
This can help when two approved resources

854
00:30:08,760 --> 00:30:10,720
can each process part of the demand

855
00:30:10,720 --> 00:30:12,520
and the process allows separate lots

856
00:30:12,520 --> 00:30:15,280
without creating a quality or traceability problem.

857
00:30:15,280 --> 00:30:17,840
But don't treat splitting as a default escape route.

858
00:30:17,840 --> 00:30:19,880
A split order can create extra setup work,

859
00:30:19,880 --> 00:30:21,640
more transport, more inspection

860
00:30:21,640 --> 00:30:24,560
and more places for quantity records to drift apart.

861
00:30:24,560 --> 00:30:26,440
If the product requires a common batch,

862
00:30:26,440 --> 00:30:29,720
matched process conditions or one final acceptance record,

863
00:30:29,720 --> 00:30:32,840
splitting may create more risk than the delay it avoids.

864
00:30:32,840 --> 00:30:34,960
The plan needs to show whether the split is approved

865
00:30:34,960 --> 00:30:37,080
and who owns the extra coordination.

866
00:30:37,080 --> 00:30:40,000
Each option should expose its consequence in simple language.

867
00:30:40,000 --> 00:30:42,680
Option one, wait for the repair accepted delay

868
00:30:42,680 --> 00:30:45,440
on these orders and keep the rest of the sequence stable.

869
00:30:45,440 --> 00:30:48,320
Option two, move these specific orders

870
00:30:48,320 --> 00:30:49,880
to an approved alternate machine

871
00:30:49,880 --> 00:30:51,760
with a two move and an extra setup

872
00:30:51,760 --> 00:30:53,760
while the remaining work waits.

873
00:30:53,760 --> 00:30:55,960
Option three, use extra operating time

874
00:30:55,960 --> 00:30:58,000
to recover output after the repair

875
00:30:58,000 --> 00:31:00,640
with the named workforce and support functions available.

876
00:31:00,640 --> 00:31:02,320
Those aren't just technical alternatives.

877
00:31:02,320 --> 00:31:04,600
They are different business and shop floor choices.

878
00:31:04,600 --> 00:31:06,600
This is where scenario comparison helps.

879
00:31:06,600 --> 00:31:08,600
You can compare the expected order completion,

880
00:31:08,600 --> 00:31:10,120
the exposure to customer commitments,

881
00:31:10,120 --> 00:31:11,840
the extra setup or labor demand

882
00:31:11,840 --> 00:31:14,400
and the operational conditions each option needs.

883
00:31:14,400 --> 00:31:16,600
You don't need to pretend that one number can capture

884
00:31:16,600 --> 00:31:17,680
every trade-off.

885
00:31:17,680 --> 00:31:20,360
A plan may choose an option with a slightly later date

886
00:31:20,360 --> 00:31:21,920
because it protects a high risk batch

887
00:31:21,920 --> 00:31:24,640
or avoids disrupting a larger group of orders.

888
00:31:24,640 --> 00:31:27,240
The value of scenarios is that they make the trade-off visible

889
00:31:27,240 --> 00:31:29,360
before the floor starts moving material.

890
00:31:29,360 --> 00:31:32,480
A single automatic recommendation can hide assumptions.

891
00:31:32,480 --> 00:31:34,560
It may assume the repair finishes on time

892
00:31:34,560 --> 00:31:36,320
that the alternate machine stays free

893
00:31:36,320 --> 00:31:38,080
or that overtime has no limit.

894
00:31:38,080 --> 00:31:40,720
A scenario approach puts those assumptions in the open.

895
00:31:40,720 --> 00:31:42,040
It lets the planner ask,

896
00:31:42,040 --> 00:31:45,800
"If this repair runs longer, which option still holds?"

897
00:31:45,800 --> 00:31:47,680
That is a much better question than asking a system

898
00:31:47,680 --> 00:31:49,640
to act certain when the plant isn't.

899
00:31:49,640 --> 00:31:51,440
The plan also needs a fallback.

900
00:31:51,440 --> 00:31:54,640
If you choose to wait for the repair, decide when you stop waiting.

901
00:31:54,640 --> 00:31:56,280
If you move work to another resource,

902
00:31:56,280 --> 00:31:59,040
decide what changes if that setup takes longer than expected.

903
00:31:59,040 --> 00:32:02,080
If you use overtime, decide which orders that overtime protects

904
00:32:02,080 --> 00:32:03,760
and when the team can stand it down.

905
00:32:03,760 --> 00:32:06,880
A response option without a trigger for changes just a polite guess.

906
00:32:06,880 --> 00:32:09,000
The goal isn't to create a thick pack of scenarios

907
00:32:09,000 --> 00:32:10,760
that nobody has time to read.

908
00:32:10,760 --> 00:32:13,560
Keep the set small and tied to decisions people can take.

909
00:32:13,560 --> 00:32:15,600
Usually, the team needs a preferred response,

910
00:32:15,600 --> 00:32:17,560
a fallback, if the repair extends,

911
00:32:17,560 --> 00:32:21,720
and perhaps a more severe option when delivery risk becomes unacceptable.

912
00:32:21,720 --> 00:32:23,720
Each choice changes more than the first order.

913
00:32:23,720 --> 00:32:25,320
Once the team picks a direction,

914
00:32:25,320 --> 00:32:27,200
the schedule needs a proper recalculation

915
00:32:27,200 --> 00:32:30,400
across the affected work, rather than a few manual date changes

916
00:32:30,400 --> 00:32:32,240
that look plausible for 10 minutes.

917
00:32:32,240 --> 00:32:34,400
Why spreadsheet re-planning breaks under pressure?

918
00:32:34,400 --> 00:32:36,760
Spreadsheets still have a place in production planning.

919
00:32:36,760 --> 00:32:40,160
A good planner can use Excel to test an idea, compare a few dates,

920
00:32:40,160 --> 00:32:42,600
or check whether a quick change looks sensible.

921
00:32:42,600 --> 00:32:45,840
Most factories rely on that kind of local judgment for good reasons.

922
00:32:45,840 --> 00:32:48,000
The trouble starts when the spreadsheet becomes the place

923
00:32:48,000 --> 00:32:49,560
where the new production plan lives,

924
00:32:49,560 --> 00:32:52,720
while machine status, order progress, material facts,

925
00:32:52,720 --> 00:32:55,800
and maintenance updates keep changing somewhere else.

926
00:32:55,800 --> 00:32:58,320
Picture the first hour after a confirmed outage.

927
00:32:58,320 --> 00:33:00,880
A planner copies the affected orders into a workbook,

928
00:33:00,880 --> 00:33:03,760
changes a few dates, then sends a version to production.

929
00:33:03,760 --> 00:33:06,400
Meanwhile, maintenance updates the repair estimate.

930
00:33:06,400 --> 00:33:08,760
A supervisor moves a job to protect the shift.

931
00:33:08,760 --> 00:33:12,360
Customer service changes the order priority after a customer calls.

932
00:33:12,360 --> 00:33:15,440
Before long, several people hold different versions of the plan,

933
00:33:15,440 --> 00:33:17,880
and each version may look reasonable on its own.

934
00:33:17,880 --> 00:33:19,120
Nobody is careless.

935
00:33:19,120 --> 00:33:21,520
The process just has no shared source of truth.

936
00:33:21,520 --> 00:33:24,880
Excel doesn't know by itself that a machine returned to service.

937
00:33:24,880 --> 00:33:28,000
It doesn't know whether an operator completed another order early,

938
00:33:28,000 --> 00:33:31,000
whether material was consumed, or whether the alternate resource

939
00:33:31,000 --> 00:33:32,520
now has a fault of its own.

940
00:33:32,520 --> 00:33:34,640
Someone has to bring those facts into the file,

941
00:33:34,640 --> 00:33:37,200
and during a disruption that usually means manual updates

942
00:33:37,200 --> 00:33:40,320
at exactly the moment people have the least time to make them.

943
00:33:40,320 --> 00:33:42,120
Then there are formulas.

944
00:33:42,120 --> 00:33:44,520
A workbook may contain years of planning knowledge.

945
00:33:44,520 --> 00:33:46,800
That can be useful, but it can also mean a formula

946
00:33:46,800 --> 00:33:49,840
depends on a hidden sheet, an old capacity assumption,

947
00:33:49,840 --> 00:33:52,440
or a cell that only one planner understands.

948
00:33:52,440 --> 00:33:56,320
When someone copies a row, filters a list, or changes in order sequence,

949
00:33:56,320 --> 00:33:58,120
the result may still look clean.

950
00:33:58,120 --> 00:33:59,800
The logic behind it may no longer hold.

951
00:33:59,800 --> 00:34:02,000
That's a risky way to issue work to a shop floor.

952
00:34:02,000 --> 00:34:06,080
The problem grows when the outage reaches beyond one machine or one department.

953
00:34:06,080 --> 00:34:09,920
A spreadsheet can show the direct move from the failed resource to an alternate resource.

954
00:34:09,920 --> 00:34:12,240
It struggles to keep a live view of the knock-on effects

955
00:34:12,240 --> 00:34:16,600
across rooting steps, shared tools, inspection cues, and perhaps another plant.

956
00:34:16,600 --> 00:34:19,960
The planner can inspect those effects manually, but the effort rises fast,

957
00:34:19,960 --> 00:34:22,280
and the plan becomes stale while the team checks it.

958
00:34:22,280 --> 00:34:24,400
That doesn't mean planners should stop using spreadsheets.

959
00:34:24,400 --> 00:34:28,760
A spreadsheet can remain a good support tool for local analysis, notes, and expert judgment.

960
00:34:28,760 --> 00:34:31,040
It can help a planner ask better questions,

961
00:34:31,040 --> 00:34:34,440
but it shouldn't become the uncontrolled schedule that everyone follows,

962
00:34:34,440 --> 00:34:37,080
especially when the plan changes, affect multiple teams,

963
00:34:37,080 --> 00:34:39,320
and physical work already sits in motion.

964
00:34:39,320 --> 00:34:42,640
A controlled schedule needs shared inputs, and a clear version.

965
00:34:42,640 --> 00:34:46,400
It needs to show which machine stated used, which orders it changed,

966
00:34:46,400 --> 00:34:50,120
and when those facts were last updated, it also needs a release process.

967
00:34:50,120 --> 00:34:54,600
So production knows which sequence is current, rather than choosing between a printout,

968
00:34:54,600 --> 00:34:57,280
a message, and three files with nearly the same name.

969
00:34:57,280 --> 00:34:58,520
You probably know the file names.

970
00:34:58,520 --> 00:35:02,840
Final, final V2, final V2 revised, the factory version of archaeology.

971
00:35:02,840 --> 00:35:04,640
Human planners still own the trade-offs.

972
00:35:04,640 --> 00:35:07,680
They understand customer relationships, local risks, and exceptions

973
00:35:07,680 --> 00:35:09,640
that no data model will capture perfectly.

974
00:35:09,640 --> 00:35:12,880
But they need a shared planning model that carries current facts

975
00:35:12,880 --> 00:35:16,160
and makes the consequences of a change visible to everyone involved,

976
00:35:16,160 --> 00:35:18,120
that changes the role of the spreadsheet.

977
00:35:18,120 --> 00:35:22,080
Instead of acting as the production plan, it becomes one tool around the planning process.

978
00:35:22,080 --> 00:35:24,280
The approved schedule lives in a controlled system,

979
00:35:24,280 --> 00:35:26,600
while local analysis can still happen where it helps.

980
00:35:26,600 --> 00:35:30,080
A revised plan also needs harder rules about time and capacity.

981
00:35:30,080 --> 00:35:33,560
Otherwise, even a shared schedule can promise the same machine hour,

982
00:35:33,560 --> 00:35:36,280
tool, or operator to more than one order.

983
00:35:36,280 --> 00:35:38,480
Reschedule with finite capacity, not hope.

984
00:35:38,480 --> 00:35:40,760
Here's the problem most reschedules don't solve.

985
00:35:40,760 --> 00:35:42,720
Once the team picks a response option,

986
00:35:42,720 --> 00:35:44,760
the schedule has to answer one hard question.

987
00:35:44,760 --> 00:35:47,680
Can every affected operation actually run in a real time slot?

988
00:35:47,680 --> 00:35:49,840
With real resources after the outage?

989
00:35:49,840 --> 00:35:51,960
That means finite capacity scheduling.

990
00:35:51,960 --> 00:35:57,160
Finite capacity means the plan treats every machine, person, tool, and time window as limited.

991
00:35:57,160 --> 00:35:59,720
If a machine can only run one operation at a time,

992
00:35:59,720 --> 00:36:02,120
the schedule can't place two operations there at 10 o'clock

993
00:36:02,120 --> 00:36:04,440
just because both orders carry urgent dates.

994
00:36:04,440 --> 00:36:05,760
That sounds obvious enough.

995
00:36:05,760 --> 00:36:10,000
Yet many production plans still rely on broad, daily, or weekly capacity numbers

996
00:36:10,000 --> 00:36:13,600
and leave the collision for the shop floor to sort out when it happens.

997
00:36:13,600 --> 00:36:15,120
The shop floor always figures it out,

998
00:36:15,120 --> 00:36:18,160
but usually by delaying something the plan claimed would run on time.

999
00:36:18,160 --> 00:36:19,760
Start with the machine that failed.

1000
00:36:19,760 --> 00:36:22,960
It's available time changes from the moment of the confirmed disruption

1001
00:36:22,960 --> 00:36:25,400
until maintenance releases it back to production.

1002
00:36:25,400 --> 00:36:28,520
That gap has to appear as unavailable capacity in the schedule,

1003
00:36:28,520 --> 00:36:30,880
not as a note beside an otherwise normal plan.

1004
00:36:30,880 --> 00:36:33,400
Then work forward through each affected operation.

1005
00:36:33,400 --> 00:36:36,280
For every order that stays on the machine or moves to another resource,

1006
00:36:36,280 --> 00:36:38,520
you need to ask when the material can arrive,

1007
00:36:38,520 --> 00:36:40,360
when the resource can actually run,

1008
00:36:40,360 --> 00:36:42,240
how long the operation takes,

1009
00:36:42,240 --> 00:36:45,160
and what must happen before the next operation can begin.

1010
00:36:45,160 --> 00:36:46,840
If the order moves to an alternate machine,

1011
00:36:46,840 --> 00:36:49,760
the schedule also needs to reserve the setup time and the resource time

1012
00:36:49,760 --> 00:36:50,760
that moves consumes.

1013
00:36:50,760 --> 00:36:53,040
A production plan is not a list of preferred dates.

1014
00:36:53,040 --> 00:36:55,160
It's a sequence of claims on limited time.

1015
00:36:55,160 --> 00:36:57,120
Resource calendars shape those claims.

1016
00:36:57,120 --> 00:36:59,120
A machine might operate across several shifts

1017
00:36:59,120 --> 00:37:02,720
while the qualified labor for a certain operation only works during one of them.

1018
00:37:02,720 --> 00:37:04,800
Another resource could have a planned maintenance block,

1019
00:37:04,800 --> 00:37:08,000
a cleaning window, or a period reserved for a specific product group.

1020
00:37:08,000 --> 00:37:09,520
If the schedule ignores those windows,

1021
00:37:09,520 --> 00:37:12,120
it creates capacity that simply does not exist.

1022
00:37:12,120 --> 00:37:13,800
The same logic applies to setups.

1023
00:37:13,800 --> 00:37:16,640
An order doesn't always start when the prior operation finishes.

1024
00:37:16,640 --> 00:37:19,000
The machine may need a tool change, a parameter adjustment,

1025
00:37:19,000 --> 00:37:21,400
warm-up time, cleaning, or a first-piece inspection.

1026
00:37:21,400 --> 00:37:24,000
Some setups depend entirely on the order sequence.

1027
00:37:24,000 --> 00:37:27,200
Moving from product A to product B might take 15 minutes,

1028
00:37:27,200 --> 00:37:31,400
while moving from product B back to product A could require an hour-long reset.

1029
00:37:31,400 --> 00:37:33,280
Those details belong in the recalculation

1030
00:37:33,280 --> 00:37:37,160
because they consume the same scarce resource time as production does.

1031
00:37:37,160 --> 00:37:40,520
Consider a machine that appears free for four hours after lunch,

1032
00:37:40,520 --> 00:37:42,880
on paper that looks like room for an urgent order.

1033
00:37:42,880 --> 00:37:45,120
But the prior run uses a different tool,

1034
00:37:45,120 --> 00:37:47,360
the new order needs an approved setup

1035
00:37:47,360 --> 00:37:51,280
and the operator with that approval doesn't start until the evening shift.

1036
00:37:51,280 --> 00:37:52,880
Those four hours exist on a calendar.

1037
00:37:52,880 --> 00:37:55,920
They do not exist as usable capacity for that specific order.

1038
00:37:55,920 --> 00:37:59,680
Finalized scheduling catches that mismatch before the plan ever reaches production.

1039
00:37:59,680 --> 00:38:01,320
Material creates another timing rule.

1040
00:38:01,320 --> 00:38:04,080
The schedule might find a resource slotted eight in the morning,

1041
00:38:04,080 --> 00:38:06,960
but the material might not leave a prior operation until noon,

1042
00:38:06,960 --> 00:38:09,480
or it might need inspection before it can move anywhere.

1043
00:38:09,480 --> 00:38:11,640
The system has to respect that order of events.

1044
00:38:11,640 --> 00:38:14,680
Nobody can run an operation before the work, the material,

1045
00:38:14,680 --> 00:38:17,960
and the required conditions all reach the resource at the same time.

1046
00:38:17,960 --> 00:38:21,040
This is where infinite capacity planning causes real trouble.

1047
00:38:21,040 --> 00:38:25,680
An infinite capacity plan can assign work to a machine regardless of its actual load.

1048
00:38:25,680 --> 00:38:28,080
It can show every order meeting its due date,

1049
00:38:28,080 --> 00:38:30,560
by placing too much work into the same period,

1050
00:38:30,560 --> 00:38:33,600
then leaving the physical conflict completely unresolved.

1051
00:38:33,600 --> 00:38:36,440
The plan looks fine because the late work hasn't disappeared.

1052
00:38:36,440 --> 00:38:38,760
It's just been hidden inside an impossible queue.

1053
00:38:38,760 --> 00:38:41,080
That approach may have a place at a rough demand planning level,

1054
00:38:41,080 --> 00:38:44,920
where the question is whether demand exceeds broad capacity over a longer horizon.

1055
00:38:44,920 --> 00:38:47,880
But during a machine outage, the team needs an executable sequence.

1056
00:38:47,880 --> 00:38:50,920
Broad averages cannot decide which order starts next,

1057
00:38:50,920 --> 00:38:52,480
which setup needs to happen first,

1058
00:38:52,480 --> 00:38:56,440
or which customer commitment loses when the available hours run out.

1059
00:38:56,440 --> 00:38:59,400
The recalculation should not disturb work that the outage does not affect.

1060
00:38:59,400 --> 00:39:00,800
If an order is already running,

1061
00:39:00,800 --> 00:39:04,240
has material staged and sits inside the short term dispatch window,

1062
00:39:04,240 --> 00:39:07,520
changing it without a strong reason creates more risk than it solves.

1063
00:39:07,520 --> 00:39:11,400
People may have prepared tools, printed instructions, positioned material,

1064
00:39:11,400 --> 00:39:13,560
or started quality checks around that work.

1065
00:39:13,560 --> 00:39:15,480
A good reschedule protects those stable areas

1066
00:39:15,480 --> 00:39:18,040
and only changes the part of the plan that actually needs to move.

1067
00:39:18,040 --> 00:39:20,200
That does not mean freezing the plan blindly.

1068
00:39:20,200 --> 00:39:22,320
If a stable order blocks a more urgent commitment

1069
00:39:22,320 --> 00:39:24,040
and the move can execute safely,

1070
00:39:24,040 --> 00:39:25,640
the planer should make the change.

1071
00:39:25,640 --> 00:39:27,320
But that change needs to earn its place.

1072
00:39:27,320 --> 00:39:31,280
Every order you move creates new setup work, new communication,

1073
00:39:31,280 --> 00:39:35,280
and another opportunity for execution to drift away from the schedule.

1074
00:39:35,280 --> 00:39:38,480
Think of the revised schedule as a set of reservations.

1075
00:39:38,480 --> 00:39:41,040
This order reserves this machine during this window,

1076
00:39:41,040 --> 00:39:43,240
with this setup, this labor coverage,

1077
00:39:43,240 --> 00:39:45,680
and the material available before work begins.

1078
00:39:45,680 --> 00:39:48,680
The next order follows only when those reservations do not collide.

1079
00:39:48,680 --> 00:39:53,360
That is far more useful than hoping the shift team can somehow fit everything in at the last minute.

1080
00:39:53,360 --> 00:39:56,240
A finite schedule can still look feasible while failing in practice

1081
00:39:56,240 --> 00:39:59,760
because the calendar does not always capture the local work required to run it.

1082
00:39:59,760 --> 00:40:01,760
Keep schedules stability in the decision.

1083
00:40:01,760 --> 00:40:06,840
A schedule can fit every operation into a valid time slot and still create a bad day on the shop floor.

1084
00:40:06,840 --> 00:40:10,120
That happens when the response to one machine outage changes far more work

1085
00:40:10,120 --> 00:40:12,120
than the outage itself actually requires.

1086
00:40:12,120 --> 00:40:15,400
All does get moved, setups change, material gets restaged,

1087
00:40:15,400 --> 00:40:17,600
supervisors have to brief operators all over again,

1088
00:40:17,600 --> 00:40:19,440
then the repair finishes earlier than expected

1089
00:40:19,440 --> 00:40:21,560
and half the changes no longer make any sense.

1090
00:40:21,560 --> 00:40:23,440
That is schedule nervousness.

1091
00:40:23,440 --> 00:40:26,800
In practical terms, nervousness means people stop trusting the dispatch sequence

1092
00:40:26,800 --> 00:40:28,640
because it keeps changing around them.

1093
00:40:28,640 --> 00:40:32,440
And operator starts preparing the next job, then here's it got moved.

1094
00:40:32,440 --> 00:40:35,760
A forklift driver stages material for an order, then planning pulls it back.

1095
00:40:35,760 --> 00:40:38,200
The supervisor receives an updated list at midday

1096
00:40:38,200 --> 00:40:41,080
and wonders whether another list will arrive before the shift ends.

1097
00:40:41,080 --> 00:40:43,520
A plan that changes all the time stops functioning as a plan.

1098
00:40:43,520 --> 00:40:45,360
So when you compare response options,

1099
00:40:45,360 --> 00:40:48,280
do not only measure due dates and available hours.

1100
00:40:48,280 --> 00:40:50,480
Measure the disruption each option actually creates.

1101
00:40:50,480 --> 00:40:52,800
How many orders move? How many setups change?

1102
00:40:52,800 --> 00:40:55,000
Which jobs already have material at the machine?

1103
00:40:55,000 --> 00:40:57,320
Which instructions or quality checks need to change?

1104
00:40:57,320 --> 00:41:00,200
How closes each affected order to actual execution?

1105
00:41:00,200 --> 00:41:03,200
Those are operational costs and they deserve a place in the decision.

1106
00:41:03,200 --> 00:41:06,520
Think about two schedules that both protect the same customer shipment.

1107
00:41:06,520 --> 00:41:09,160
The first one moves seven orders across two work centers,

1108
00:41:09,160 --> 00:41:13,560
creates extra tool changes and re-rides the afternoon dispatch list for three operators.

1109
00:41:13,560 --> 00:41:16,280
The second accepts a small local delay on one internal order

1110
00:41:16,280 --> 00:41:19,160
while leaving the near term sequence largely intact.

1111
00:41:19,160 --> 00:41:21,480
The second plan may look less clever in a planning tool

1112
00:41:21,480 --> 00:41:23,920
but it will probably work better in the actual plant.

1113
00:41:23,920 --> 00:41:27,400
This does not mean schedule stability should beat every customer commitment.

1114
00:41:27,400 --> 00:41:30,080
If a high-risk customer order needs a safe and approved move,

1115
00:41:30,080 --> 00:41:31,440
the plan should make it.

1116
00:41:31,440 --> 00:41:33,920
But the change needs a reason that people can explain.

1117
00:41:33,920 --> 00:41:37,960
You do not reshuffle work simply because an optimizer found a marginally cleaner date

1118
00:41:37,960 --> 00:41:41,040
or because a new machine estimate arrived five minutes ago.

1119
00:41:41,040 --> 00:41:43,480
A useful way to control this is with a freeze zone.

1120
00:41:43,480 --> 00:41:46,120
The freeze zone is the short period close to execution

1121
00:41:46,120 --> 00:41:49,040
where the plan only changes for a real operational reason.

1122
00:41:49,040 --> 00:41:51,200
The exact length depends on your process.

1123
00:41:51,200 --> 00:41:53,360
For one plant, it might cover the current shift.

1124
00:41:53,360 --> 00:41:57,840
For another, it might cover the next few hours because material tools and people need more preparation time.

1125
00:41:57,840 --> 00:42:00,560
Inside that zone, the default position is stability.

1126
00:42:00,560 --> 00:42:04,080
Outside the freeze zone, planning has more room to move work around.

1127
00:42:04,080 --> 00:42:05,920
Orders may still be days away from release.

1128
00:42:05,920 --> 00:42:07,280
Material may not have moved.

1129
00:42:07,280 --> 00:42:10,600
The production team may not have started setups or assigned people yet.

1130
00:42:10,600 --> 00:42:13,680
Changes there carry less cost, so the schedule can absorb the outage

1131
00:42:13,680 --> 00:42:16,160
without disturbing work that is already in motion.

1132
00:42:16,160 --> 00:42:18,960
That creates a practical planning horizon with different rules

1133
00:42:18,960 --> 00:42:22,960
rather than one large calendar where every order stays equally movable.

1134
00:42:22,960 --> 00:42:26,560
You may also want a second boundary between work that production has accepted

1135
00:42:26,560 --> 00:42:29,120
and work that remains only a planning intent.

1136
00:42:29,120 --> 00:42:31,600
Once a supervisor accepts a dispatch sequence,

1137
00:42:31,600 --> 00:42:34,480
that sequence carries a stronger presumption of stability.

1138
00:42:34,480 --> 00:42:38,320
Planning can still change it, but someone should own that decision and communicate why.

1139
00:42:38,320 --> 00:42:42,520
Otherwise, planners optimize the schedule while the flow executes a completely different one.

1140
00:42:42,520 --> 00:42:44,920
Operator trust matters more than people sometimes admit.

1141
00:42:44,920 --> 00:42:47,640
Experienced operators spot weak plans quickly.

1142
00:42:47,640 --> 00:42:49,240
They know when an order lacks a tool,

1143
00:42:49,240 --> 00:42:51,440
when a setup will take longer than the standard time,

1144
00:42:51,440 --> 00:42:54,240
or when a machine needs attention before it can take a new job.

1145
00:42:54,240 --> 00:42:56,000
If the schedule changes without restraint,

1146
00:42:56,000 --> 00:42:58,720
those operators will start managing from local knowledge instead,

1147
00:42:58,720 --> 00:43:00,160
sometimes that saves the shift.

1148
00:43:00,160 --> 00:43:03,280
Over time, it separates the real factory from the official plan,

1149
00:43:03,280 --> 00:43:06,800
so keep the revised schedule as stable as the situation allows.

1150
00:43:06,800 --> 00:43:10,880
Move the work that must move, protect the work that is already prepared for execution.

1151
00:43:10,880 --> 00:43:14,160
Treat every additional change as a cost that needs to justify itself.

1152
00:43:14,160 --> 00:43:16,080
That policy becomes even more important

1153
00:43:16,080 --> 00:43:20,560
when maintenance can only give you a repair range instead of a firm return time.

1154
00:43:20,560 --> 00:43:23,200
Plan for uncertainty, not one repair estimate.

1155
00:43:23,200 --> 00:43:27,280
When the repair time is uncertain, your plan can't just assume one version of the future.

1156
00:43:27,280 --> 00:43:32,160
Instead, define a few clear cases that let people act without pretending they know exactly

1157
00:43:32,160 --> 00:43:33,600
when the machine will be back.

1158
00:43:33,600 --> 00:43:35,040
Start with a short outage case.

1159
00:43:35,040 --> 00:43:36,800
That's where maintenance expects the machine back

1160
00:43:36,800 --> 00:43:39,600
before the current disruption creates any wider delivery risk.

1161
00:43:39,600 --> 00:43:41,280
The plan might hold work in place,

1162
00:43:41,280 --> 00:43:42,880
protect the near term sequence,

1163
00:43:42,880 --> 00:43:46,960
and prepare recovery actions without moving material or changing dispatch too early.

1164
00:43:46,960 --> 00:43:48,640
Then set up a medium outage case.

1165
00:43:48,640 --> 00:43:52,160
Here the machine misses enough production time that selected orders need action.

1166
00:43:52,160 --> 00:43:55,520
Maybe an approved alternate resource picks up a limited amount of work.

1167
00:43:55,520 --> 00:43:58,080
Maybe a later order shifts outside the affected window.

1168
00:43:58,080 --> 00:44:00,640
The point isn't to redesign the whole week.

1169
00:44:00,640 --> 00:44:05,120
It's to identify the smallest set of decisions that protects commitments under pressure.

1170
00:44:05,120 --> 00:44:07,200
You may also need a long outage case

1171
00:44:07,200 --> 00:44:10,000
that applies when the repair could extend beyond the shift,

1172
00:44:10,000 --> 00:44:11,840
beyond the next planned production window

1173
00:44:11,840 --> 00:44:14,480
or past a date where waiting stops making sense.

1174
00:44:14,480 --> 00:44:16,480
At that point you might need added labor,

1175
00:44:16,480 --> 00:44:19,040
external capacity, a customer discussion,

1176
00:44:19,040 --> 00:44:21,360
or a serious change to the production sequence.

1177
00:44:21,360 --> 00:44:23,600
Each case should connect to a clear decision.

1178
00:44:23,600 --> 00:44:26,320
The short outage case might mean keep the current sequence

1179
00:44:26,320 --> 00:44:28,480
and reassess at the next maintenance update.

1180
00:44:28,480 --> 00:44:32,480
The medium case might mean release the approved alternate route for these two orders

1181
00:44:32,480 --> 00:44:35,520
if the machine remains unavailable past the next dispatch point.

1182
00:44:35,520 --> 00:44:38,480
The long case might mean escalate the customer facing commitments

1183
00:44:38,480 --> 00:44:39,920
and approve the recovery plan.

1184
00:44:39,920 --> 00:44:42,560
That gives the team a way to react as facts change

1185
00:44:42,560 --> 00:44:46,400
instead of restarting a planning debate every time someone shares a revised estimate.

1186
00:44:46,400 --> 00:44:49,440
The repair estimate shouldn't drive every change by itself.

1187
00:44:49,440 --> 00:44:52,320
What matters is whether that estimate crosses a decision boundary.

1188
00:44:52,320 --> 00:44:55,280
Say maintenance first expects the machine back within the current shift

1189
00:44:55,280 --> 00:44:57,520
but the diagnosis later points to a part replacement

1190
00:44:57,520 --> 00:44:59,680
that pushes the return to the next shift.

1191
00:44:59,680 --> 00:45:01,040
That's not just a new time.

1192
00:45:01,040 --> 00:45:02,960
It may trigger a different response case

1193
00:45:02,960 --> 00:45:06,720
because work that could wait now needs an alternate route or a revised promise.

1194
00:45:06,720 --> 00:45:08,560
Keep the triggers plain.

1195
00:45:08,560 --> 00:45:11,040
If the machine doesn't return by a defined time,

1196
00:45:11,040 --> 00:45:13,840
the planner moves from the short case to the medium case.

1197
00:45:13,840 --> 00:45:17,440
If maintenance confirms a repair that exceeds the next available recovery window,

1198
00:45:17,440 --> 00:45:19,200
the team moves to the long case.

1199
00:45:19,200 --> 00:45:21,680
People should never have to interpret vague phrases like

1200
00:45:21,680 --> 00:45:24,640
"probably delayed" while deciding whether to move real work.

1201
00:45:24,640 --> 00:45:26,720
Confidence matters alongside duration.

1202
00:45:26,720 --> 00:45:30,720
A maintenance estimate with high confidence can support a firmer planning response.

1203
00:45:30,720 --> 00:45:33,360
One with low confidence should keep more options open.

1204
00:45:33,360 --> 00:45:35,360
If the diagnosis remains incomplete,

1205
00:45:35,360 --> 00:45:39,920
the plan might reserve a possible slot on an alternate resource without releasing it yet.

1206
00:45:39,920 --> 00:45:41,520
That slot acts as a contingency.

1207
00:45:41,520 --> 00:45:46,000
It buys decision time, though it also costs capacity that another order could have used.

1208
00:45:46,000 --> 00:45:49,360
You should only hold capacity where the consequence justifies it.

1209
00:45:49,360 --> 00:45:53,520
Reserving every alternative for every outage would create a plan full of empty promises.

1210
00:45:53,520 --> 00:45:56,160
But if a particular order has a tight customer commitment

1211
00:45:56,160 --> 00:45:58,000
and only one qualified alternate resource,

1212
00:45:58,000 --> 00:46:01,280
holding a short contingent slot can prevent a much harder problem later.

1213
00:46:01,280 --> 00:46:03,280
This is a trade-off, not a universal rule.

1214
00:46:03,280 --> 00:46:05,840
The planner needs to know what the reserved slot protects,

1215
00:46:05,840 --> 00:46:07,280
how long it stays reserved,

1216
00:46:07,280 --> 00:46:09,280
and when it returns to the normal schedule.

1217
00:46:09,280 --> 00:46:13,040
Otherwise, contingency capacity quietly becomes lost capacity,

1218
00:46:13,040 --> 00:46:16,720
and people start asking why a machine appeared open but never received work.

1219
00:46:16,720 --> 00:46:21,120
Repair uncertainty also changes how often you update the plan.

1220
00:46:21,120 --> 00:46:25,120
A minor change in estimated return time doesn't always deserve a new schedule release.

1221
00:46:25,120 --> 00:46:29,040
If the current scenario still works, leave the plan alone and wait for better information.

1222
00:46:29,040 --> 00:46:32,480
Frequent updates can create more disruption than the estimate itself.

1223
00:46:32,480 --> 00:46:34,640
When the estimate crosses a defined threshold,

1224
00:46:34,640 --> 00:46:36,720
update only the affected decisions.

1225
00:46:36,720 --> 00:46:40,320
Don't re-sequence every order because a repair moved by 30 minutes.

1226
00:46:40,320 --> 00:46:44,000
Change the work that now faces a different constraint and leave the rest stable.

1227
00:46:44,000 --> 00:46:47,360
That takes discipline because people naturally want one exact answer.

1228
00:46:47,360 --> 00:46:49,760
A single return time feels easier to communicate,

1229
00:46:49,760 --> 00:46:55,200
but a neat estimate with no basis causes more damage than an honest range with a clear response plan.

1230
00:46:55,200 --> 00:46:58,560
So treat the outage as a set of conditions, not a countdown timer.

1231
00:46:58,560 --> 00:47:00,960
Define the short, medium, and long cases.

1232
00:47:00,960 --> 00:47:03,520
Set the trigger that moves the plan from one case to the next.

1233
00:47:03,520 --> 00:47:05,920
Hold options only where they protect a real commitment,

1234
00:47:05,920 --> 00:47:08,720
then release them when the facts no longer support the hold.

1235
00:47:08,720 --> 00:47:11,920
The decision process now needs clean handoffs between maintenance,

1236
00:47:11,920 --> 00:47:13,840
the MES, and planning.

1237
00:47:13,840 --> 00:47:16,000
The information flow from machine to planner.

1238
00:47:16,000 --> 00:47:20,400
A response process only works if the right facts reach the right people in the right order.

1239
00:47:20,400 --> 00:47:22,640
The planner doesn't need every raw machine signal.

1240
00:47:22,640 --> 00:47:25,920
They need a confirmed disruption event that connects the equipment problem

1241
00:47:25,920 --> 00:47:27,680
to the current production situation.

1242
00:47:27,680 --> 00:47:28,960
Start close to the machine.

1243
00:47:28,960 --> 00:47:32,000
A programmable logic controller, a PLC,

1244
00:47:32,000 --> 00:47:33,840
controls and monitors the equipment.

1245
00:47:33,840 --> 00:47:37,200
It may detect a fault code, a safety stop, a cycle interruption,

1246
00:47:37,200 --> 00:47:38,480
or a machine state change.

1247
00:47:38,480 --> 00:47:41,680
An IoT layer can collect that signal and pass it into systems

1248
00:47:41,680 --> 00:47:43,600
outside the local control environment.

1249
00:47:43,600 --> 00:47:45,440
That signal starts the information flow.

1250
00:47:45,440 --> 00:47:46,560
It doesn't finish it.

1251
00:47:46,560 --> 00:47:48,640
A fault code can tell you that a machine stopped.

1252
00:47:48,640 --> 00:47:50,560
It may tell maintenance where to begin.

1253
00:47:50,560 --> 00:47:54,720
But it usually can't tell planning whether an operator had already completed the current cycle,

1254
00:47:54,720 --> 00:47:56,080
whether the order can move,

1255
00:47:56,080 --> 00:48:00,960
or whether the resource remains unavailable long enough to affect today's dispatch plan.

1256
00:48:00,960 --> 00:48:02,880
Those facts sit closer to execution.

1257
00:48:02,880 --> 00:48:05,600
The manufacturing execution system, the MES,

1258
00:48:05,600 --> 00:48:08,000
provides the production context around the event.

1259
00:48:08,000 --> 00:48:10,240
It can confirm which work order runs on the machine,

1260
00:48:10,240 --> 00:48:12,800
which operation is active, what quantity passed through,

1261
00:48:12,800 --> 00:48:14,480
and what quantity still waits.

1262
00:48:14,480 --> 00:48:17,360
It can also show whether the machine had already changed over,

1263
00:48:17,360 --> 00:48:19,200
whether an operator had started work,

1264
00:48:19,200 --> 00:48:21,440
and whether the order status needs attention.

1265
00:48:21,440 --> 00:48:24,560
That distinction matters when the stop happens in the middle of an operation.

1266
00:48:24,560 --> 00:48:27,200
Suppose the PLC reports a fault at 10+10.

1267
00:48:27,200 --> 00:48:29,280
The MES may show that the order began at 9,

1268
00:48:29,280 --> 00:48:32,000
with most of the planned quantity recorded as complete.

1269
00:48:32,000 --> 00:48:34,480
Or it may show that the operator never started the job

1270
00:48:34,480 --> 00:48:37,120
because the resource entered a fault state during setup.

1271
00:48:37,120 --> 00:48:39,760
Planning should react differently in those two cases,

1272
00:48:39,760 --> 00:48:42,080
even though both produce the same machine alarm.

1273
00:48:42,080 --> 00:48:43,760
Maintenance adds another part of the story.

1274
00:48:43,760 --> 00:48:45,680
The maintenance system records the fault,

1275
00:48:45,680 --> 00:48:47,440
the work activity, the diagnosis,

1276
00:48:47,440 --> 00:48:49,120
and the expected return to service.

1277
00:48:49,120 --> 00:48:50,880
It may track spare part needs,

1278
00:48:50,880 --> 00:48:53,680
safety work, and the person responsible for the repair.

1279
00:48:53,680 --> 00:48:55,520
Planning doesn't need every maintenance note,

1280
00:48:55,520 --> 00:48:59,200
and maintenance shouldn't need to turn every early diagnosis into a promise.

1281
00:48:59,200 --> 00:49:03,280
What planning needs is a clear equipment status and a current view of availability.

1282
00:49:03,280 --> 00:49:05,120
Is the machine stopped but under review?

1283
00:49:05,120 --> 00:49:05,920
Is it locked out?

1284
00:49:05,920 --> 00:49:07,200
Is repair work in progress?

1285
00:49:07,200 --> 00:49:08,640
Has maintenance completed the repair,

1286
00:49:08,640 --> 00:49:10,800
but not handed the machine back to production?

1287
00:49:10,800 --> 00:49:14,080
Those states need clear meaning because they lead to different planning actions.

1288
00:49:14,080 --> 00:49:17,520
The machine isn't available just because a repair ticket changed status.

1289
00:49:17,520 --> 00:49:19,520
Then the enterprise resource planning system,

1290
00:49:19,520 --> 00:49:22,320
ERP, contributes the business and planning facts.

1291
00:49:22,320 --> 00:49:25,040
ERP holds demand, order commitments,

1292
00:49:25,040 --> 00:49:27,200
planned material needs, master data,

1293
00:49:27,200 --> 00:49:29,280
and often the baseline production plan.

1294
00:49:29,280 --> 00:49:31,760
It gives the plan of the wider frame around the local event,

1295
00:49:31,760 --> 00:49:34,160
an outage only becomes a planning event

1296
00:49:34,160 --> 00:49:37,680
when the system can connect the unavailable resource with the worker signed to it

1297
00:49:37,680 --> 00:49:39,520
and the commitments attached to that work.

1298
00:49:39,520 --> 00:49:41,360
Material facts may come from ERP,

1299
00:49:41,360 --> 00:49:43,680
MES, a warehouse system, or a mix of them.

1300
00:49:43,680 --> 00:49:45,840
Customer commitments may sit in ERP

1301
00:49:45,840 --> 00:49:48,560
while the most current order progress sits in MES.

1302
00:49:48,560 --> 00:49:50,160
Maintenance owns the repair estimate.

1303
00:49:50,160 --> 00:49:52,560
No single source naturally contains the whole answer,

1304
00:49:52,560 --> 00:49:54,480
and forcing one system to pretend it does

1305
00:49:54,480 --> 00:49:56,080
usually creates a fragile setup.

1306
00:49:56,080 --> 00:49:59,520
So think of the planning service as the point where the current facts meet.

1307
00:49:59,520 --> 00:50:01,680
It receives the confirmed equipment event.

1308
00:50:01,680 --> 00:50:05,040
It checks the MES for the active operation and production status.

1309
00:50:05,040 --> 00:50:08,480
It reads the maintenance status and expected availability.

1310
00:50:08,480 --> 00:50:10,960
Then it combines those facts with the relevant order,

1311
00:50:10,960 --> 00:50:13,120
material, and demand records from ERP.

1312
00:50:13,120 --> 00:50:16,240
The output isn't another alarm, it is an impact event.

1313
00:50:16,240 --> 00:50:19,200
An impact event might state that a name resource cannot run

1314
00:50:19,200 --> 00:50:22,320
that a given work order stopped during a specific operation,

1315
00:50:22,320 --> 00:50:24,240
that a remaining quantity needs review

1316
00:50:24,240 --> 00:50:28,560
and that the estimated availability window now puts certain scheduled work at risk.

1317
00:50:28,560 --> 00:50:31,040
It carries timestamps and source references

1318
00:50:31,040 --> 00:50:33,280
so people can see which parts come from the machine,

1319
00:50:33,280 --> 00:50:34,720
which parts come from maintenance,

1320
00:50:34,720 --> 00:50:36,880
and which parts come from production execution.

1321
00:50:36,880 --> 00:50:38,560
That lets the planner start from facts

1322
00:50:38,560 --> 00:50:41,120
instead of chasing updates through calls and messages.

1323
00:50:41,120 --> 00:50:42,400
Timing still needs care.

1324
00:50:42,400 --> 00:50:44,720
The PLC may create signals in seconds.

1325
00:50:44,720 --> 00:50:46,720
A planning decision might only need an update

1326
00:50:46,720 --> 00:50:48,400
after the MES confirms the order state

1327
00:50:48,400 --> 00:50:50,160
and maintenance classifies the stop.

1328
00:50:50,160 --> 00:50:54,000
Sending every raw event straight into enterprise planning creates noise.

1329
00:50:54,000 --> 00:50:55,680
Not real-time visibility.

1330
00:50:55,680 --> 00:50:58,480
Match the information flow to the decision window.

1331
00:50:58,480 --> 00:51:02,320
For a short local stop, the information may stay within the cell and the MES.

1332
00:51:02,320 --> 00:51:05,280
For a confirmed loss of capacity that threatens the shift plan,

1333
00:51:05,280 --> 00:51:08,720
the planning service needs an event quickly enough for people to act.

1334
00:51:08,720 --> 00:51:11,520
For a longer disruption, ERP and customer service

1335
00:51:11,520 --> 00:51:13,840
may need a clearer view of the likely effect.

1336
00:51:13,840 --> 00:51:15,680
Each handoff should preserve ownership.

1337
00:51:15,680 --> 00:51:19,680
The PLC reports equipment behavior, MES records, what happened to the order,

1338
00:51:19,680 --> 00:51:23,280
maintenance reports repair status, ERP holds demand and planning records.

1339
00:51:23,280 --> 00:51:25,840
The planning layer brings those facts together for a decision,

1340
00:51:25,840 --> 00:51:28,800
but it shouldn't overwrite the source systems or invent a repair estimate.

1341
00:51:28,800 --> 00:51:31,360
This is IT and OT convergence in practical terms.

1342
00:51:31,360 --> 00:51:34,560
It isn't one giant platform replacing every system in the plant.

1343
00:51:34,560 --> 00:51:37,360
It's a reliable flow of current facts across systems

1344
00:51:37,360 --> 00:51:38,960
that each retain their own job.

1345
00:51:38,960 --> 00:51:41,760
Once you connect those facts, another problem appears.

1346
00:51:41,760 --> 00:51:45,200
Connected data still doesn't explain the relationships behind the planning decision.

1347
00:51:45,200 --> 00:51:48,640
Data is not the same as production context.

1348
00:51:48,640 --> 00:51:50,960
A connected event flow gives you facts.

1349
00:51:50,960 --> 00:51:53,680
A machine state changes, a maintenance estimate updates,

1350
00:51:53,680 --> 00:51:55,440
and order stays partly complete.

1351
00:51:55,440 --> 00:51:58,240
Those facts matter, but they still don't tell a planning system

1352
00:51:58,240 --> 00:52:00,640
what the outage actually means across the factory.

1353
00:52:00,640 --> 00:52:02,400
Data describes individual things,

1354
00:52:02,400 --> 00:52:05,680
while production context describes how those things depend on each other.

1355
00:52:05,680 --> 00:52:07,520
Think about a single machine down record.

1356
00:52:07,520 --> 00:52:11,760
It might contain a resource ID, fault state, time, and expected return window.

1357
00:52:11,760 --> 00:52:14,720
That tells you where to start, but it doesn't tell you which product families

1358
00:52:14,720 --> 00:52:18,560
that resource can process, which work orders need that capability next.

1359
00:52:18,560 --> 00:52:22,720
Whether another machine can run the same operation, or whether a tool blocks that move.

1360
00:52:22,720 --> 00:52:26,240
The real planning decision lives in those relationships, not in the raw event.

1361
00:52:26,240 --> 00:52:27,200
Take one work order.

1362
00:52:27,200 --> 00:52:30,800
It connects to a product, which connects to a routing defining the process steps.

1363
00:52:30,800 --> 00:52:33,520
One process step may connect to several approved resources,

1364
00:52:33,520 --> 00:52:35,680
though each resource can carry different limits.

1365
00:52:35,680 --> 00:52:38,800
The operation may also need a fixture, program, material, lot,

1366
00:52:38,800 --> 00:52:41,280
operator qualification, and quality plan.

1367
00:52:41,280 --> 00:52:44,400
None of those relationships live inside a simple downtime event.

1368
00:52:44,400 --> 00:52:48,320
This is why teams can collect lots of data and still struggle during a disruption.

1369
00:52:48,560 --> 00:52:52,240
The data may live in good systems, machine data in an OT source,

1370
00:52:52,240 --> 00:52:56,880
the MES recording operation progress, ERP holding order and demand data,

1371
00:52:56,880 --> 00:52:58,880
maintenance tracking repair work,

1372
00:52:58,880 --> 00:53:03,680
yet the links between those records remain unclear, incomplete, or buried in local knowledge.

1373
00:53:03,680 --> 00:53:07,440
A planner then has to rebuild the context by hand.

1374
00:53:07,440 --> 00:53:09,760
They ask maintenance whether the resource can return,

1375
00:53:09,760 --> 00:53:12,240
they ask the supervisor which order sits at the machine,

1376
00:53:12,240 --> 00:53:14,320
they call quality about an alternate route,

1377
00:53:14,320 --> 00:53:16,480
and they check whether the fixture can move.

1378
00:53:16,480 --> 00:53:19,760
That works for one incident with experienced people who know the plant,

1379
00:53:19,760 --> 00:53:24,000
but it doesn't scale and gets fragile when those people aren't available.

1380
00:53:24,000 --> 00:53:27,200
The system needs a working model of the production relationships.

1381
00:53:27,200 --> 00:53:31,440
People often hear digital twin and picture a detailed 3D model of a factory.

1382
00:53:31,440 --> 00:53:32,960
That can be useful for some tasks,

1383
00:53:32,960 --> 00:53:35,360
but it isn't the priority for disruption planning.

1384
00:53:35,360 --> 00:53:39,200
For this problem, a digital twin is a living model that connects production objects

1385
00:53:39,200 --> 00:53:40,560
and their current state.

1386
00:53:40,560 --> 00:53:44,400
It can represent that resource A performs operation B for product C

1387
00:53:44,400 --> 00:53:48,720
using tool D under a defined rule, link a work order to its current operation

1388
00:53:48,720 --> 00:53:50,160
and remaining quantity,

1389
00:53:50,160 --> 00:53:52,400
and show that an alternate resource exists,

1390
00:53:52,400 --> 00:53:55,600
but only for a certain product group with approved tooling

1391
00:53:55,600 --> 00:53:57,280
and a qualified operator present.

1392
00:53:57,280 --> 00:54:00,720
That is production context you can reason over.

1393
00:54:00,720 --> 00:54:03,520
A knowledge graph can help manage this relationship model.

1394
00:54:03,520 --> 00:54:06,000
In plain terms, it stores not just the things in the factory,

1395
00:54:06,000 --> 00:54:07,200
but the links between them,

1396
00:54:07,200 --> 00:54:09,520
so instead of asking only which machines are down,

1397
00:54:09,520 --> 00:54:13,520
you can ask which released orders depend on this resource or its shared fixture

1398
00:54:13,520 --> 00:54:17,360
and which approved alternatives remain available under the current conditions.

1399
00:54:17,360 --> 00:54:20,960
The graph doesn't replace your MES, ERP or maintenance system,

1400
00:54:20,960 --> 00:54:23,040
those still own their records and processes,

1401
00:54:23,040 --> 00:54:27,920
but it gives the decision layer a way to connect the dots between IT and OT

1402
00:54:27,920 --> 00:54:32,080
without pretending every source system uses the same structure or language.

1403
00:54:32,080 --> 00:54:33,600
That's an important distinction.

1404
00:54:33,600 --> 00:54:36,080
You don't need to model every asset, every sensor tag,

1405
00:54:36,080 --> 00:54:39,120
and every possible relationship before the first use case can work.

1406
00:54:39,120 --> 00:54:41,360
That path usually ends up as a big program

1407
00:54:41,360 --> 00:54:43,520
that doesn't help with the next actual outage,

1408
00:54:43,520 --> 00:54:45,920
start with the resources that create delivery risk,

1409
00:54:45,920 --> 00:54:47,600
the operations that depend on them,

1410
00:54:47,600 --> 00:54:51,360
and the constraints that repeatedly determine whether a replant can run.

1411
00:54:51,360 --> 00:54:53,040
Scope should follow the decision.

1412
00:54:53,040 --> 00:54:56,000
For example, if one machining group frequently creates late orders

1413
00:54:56,000 --> 00:54:57,280
when a resource fails,

1414
00:54:57,280 --> 00:54:59,440
model that group first by connecting the machines

1415
00:54:59,440 --> 00:55:00,960
to approved operations,

1416
00:55:00,960 --> 00:55:02,640
fixtures, programs,

1417
00:55:02,640 --> 00:55:03,840
operator skills,

1418
00:55:03,840 --> 00:55:06,000
and the order links needed for impact tracing.

1419
00:55:06,000 --> 00:55:08,880
Add the material and inspection relationships

1420
00:55:08,880 --> 00:55:12,160
that change the decision and leave unrelated parts of the plant outside

1421
00:55:12,160 --> 00:55:14,560
the first model until they become relevant.

1422
00:55:14,560 --> 00:55:17,520
A smaller model that people trust beats a grand factory model

1423
00:55:17,520 --> 00:55:18,800
that no one can keep current.

1424
00:55:18,800 --> 00:55:21,200
Once those relationships exist,

1425
00:55:21,200 --> 00:55:23,280
machine status stops being an isolated alert

1426
00:55:23,280 --> 00:55:25,600
and becomes a change in a connected production model,

1427
00:55:25,600 --> 00:55:28,560
so the system can trace where that change creates real exposure.

1428
00:55:28,560 --> 00:55:31,760
That shared decision layer can draw on Microsoft data services,

1429
00:55:31,760 --> 00:55:34,800
where Microsoft fabric fits and where it doesn't.

1430
00:55:34,800 --> 00:55:37,920
Once you've built enough production context to trace a disruption,

1431
00:55:37,920 --> 00:55:41,840
Microsoft fabric can help create a shared data foundation around that work,

1432
00:55:41,840 --> 00:55:44,480
but it doesn't create the production model for you

1433
00:55:44,480 --> 00:55:48,880
and it doesn't turn raw shop floor events into an executable schedule by itself.

1434
00:55:48,880 --> 00:55:50,720
That boundary is worth keeping in mind.

1435
00:55:50,720 --> 00:55:53,680
Think about the information needed after a machine goes down.

1436
00:55:53,680 --> 00:55:55,760
Event history from the equipment layer,

1437
00:55:55,760 --> 00:55:57,680
live or near live MES records,

1438
00:55:57,680 --> 00:55:59,920
order and demand facts from ERP,

1439
00:55:59,920 --> 00:56:02,080
maintenance status, and planning inputs.

1440
00:56:02,080 --> 00:56:04,160
Those records often sit in different systems

1441
00:56:04,160 --> 00:56:07,040
with different update cycles, identifiers, and owners.

1442
00:56:07,040 --> 00:56:10,080
Fabric can give those teams a common place to bring data together

1443
00:56:10,080 --> 00:56:12,080
for analysis reporting and decision support.

1444
00:56:12,080 --> 00:56:14,800
In practical terms, you can bring machine events,

1445
00:56:14,800 --> 00:56:17,040
downtime history, work order progress,

1446
00:56:17,040 --> 00:56:19,040
repair records, material status,

1447
00:56:19,040 --> 00:56:21,840
and plan schedules into a governed data layer,

1448
00:56:21,840 --> 00:56:24,560
then build data products around a real planning question.

1449
00:56:24,560 --> 00:56:27,840
Like which released orders face a delivery risk,

1450
00:56:27,840 --> 00:56:30,960
if this resource remains unavailable during the next production window.

1451
00:56:30,960 --> 00:56:32,720
That's a much better starting point

1452
00:56:32,720 --> 00:56:36,160
than collecting every signal because it might become useful one day.

1453
00:56:36,160 --> 00:56:38,160
Fabric can also help separate the operational record

1454
00:56:38,160 --> 00:56:39,600
from the wider decision record.

1455
00:56:39,600 --> 00:56:42,240
The MES continues managing production execution,

1456
00:56:42,240 --> 00:56:46,160
the maintenance system manages repair work, ERP manages demand in orders,

1457
00:56:46,160 --> 00:56:48,080
and Fabric brings selected facts together,

1458
00:56:48,080 --> 00:56:51,760
so planners, production leads, and data teams can work from a consistent view.

1459
00:56:51,760 --> 00:56:53,120
Each system keeps its job.

1460
00:56:53,120 --> 00:56:55,920
This matters because data platforms sometimes get presented

1461
00:56:55,920 --> 00:56:58,000
as if they replace every system around them,

1462
00:56:58,000 --> 00:56:58,880
but they don't.

1463
00:56:58,880 --> 00:57:02,080
A data platform can store and process information from many sources,

1464
00:57:02,080 --> 00:57:05,040
but it doesn't know whether a routing alternate is quality approved,

1465
00:57:05,040 --> 00:57:07,360
whether a setup is physically possible today,

1466
00:57:07,360 --> 00:57:11,040
or whether a supervisor can release a changed dispatch sequence.

1467
00:57:11,040 --> 00:57:14,400
Those rules need to come from the plants production model and planning process.

1468
00:57:14,400 --> 00:57:17,200
A common pattern is to use Fabric for the data foundation,

1469
00:57:17,200 --> 00:57:19,840
then connected to a scheduling or optimization service

1470
00:57:19,840 --> 00:57:23,200
that evaluates finite capacity and shop flow constraints.

1471
00:57:23,200 --> 00:57:26,400
That planning logic may live in a specialized manufacturing system,

1472
00:57:26,400 --> 00:57:28,880
a custom service, or another planning engine,

1473
00:57:28,880 --> 00:57:32,480
but the point is Fabric provides trusted inputs and shared history.

1474
00:57:32,480 --> 00:57:35,760
It shouldn't pretend to be the scheduling engine just because the data sits there.

1475
00:57:35,760 --> 00:57:37,840
Storage and decision logic are different jobs.

1476
00:57:37,840 --> 00:57:40,640
Power BI fits naturally on top of this shared foundation,

1477
00:57:40,640 --> 00:57:43,680
giving planners and managers a current view of confirmed outages,

1478
00:57:43,680 --> 00:57:46,880
affected order groups, repair status, capacity exposure,

1479
00:57:46,880 --> 00:57:48,640
and planning scenario results.

1480
00:57:48,640 --> 00:57:50,960
It can also help investigate recurring downtime patterns

1481
00:57:50,960 --> 00:57:54,080
or compare planned recovery with actual production later,

1482
00:57:54,080 --> 00:57:57,280
but a Power BI report doesn't issue a production plan.

1483
00:57:57,280 --> 00:57:59,280
A report can tell you that machine 4 is down,

1484
00:57:59,280 --> 00:58:00,960
that 5 orders depend on it,

1485
00:58:00,960 --> 00:58:03,760
and that an alternate resource has limited free time.

1486
00:58:03,760 --> 00:58:04,960
That's useful.

1487
00:58:04,960 --> 00:58:08,800
But someone or something still needs to apply routing rules,

1488
00:58:08,800 --> 00:58:11,440
sequencing logic, tooling limits, labor constraints,

1489
00:58:11,440 --> 00:58:14,720
and the planning policy you agreed before the incident.

1490
00:58:14,720 --> 00:58:17,440
If every disruption ends with another dashboard,

1491
00:58:17,440 --> 00:58:20,720
you may be reporting the problem more clearly without solving it.

1492
00:58:20,720 --> 00:58:22,720
The harder work sits underneath the report.

1493
00:58:22,720 --> 00:58:25,680
You need consistent resource IDs across ERP, MES,

1494
00:58:25,680 --> 00:58:27,440
maintenance and the equipment layer,

1495
00:58:27,440 --> 00:58:29,840
rules for which source owns each fact.

1496
00:58:29,840 --> 00:58:32,880
Time stamps that let people judge whether the data still applies,

1497
00:58:32,880 --> 00:58:35,280
and access controls because maintenance notes,

1498
00:58:35,280 --> 00:58:37,600
customer commitments, production records,

1499
00:58:37,600 --> 00:58:41,200
and operational signals shouldn't all be visible or editable by everyone.

1500
00:58:41,200 --> 00:58:42,320
That is governance work.

1501
00:58:42,320 --> 00:58:45,280
It doesn't disappear because the data moved into fabric.

1502
00:58:45,280 --> 00:58:48,320
Identity also matters across the IT and OT boundary.

1503
00:58:48,320 --> 00:58:51,200
A planning service needs controlled access to the data it reads

1504
00:58:51,200 --> 00:58:53,360
and a clear boundary around what it can write back.

1505
00:58:53,360 --> 00:58:56,080
A supervisor should see work relevant to their area,

1506
00:58:56,080 --> 00:58:58,240
a planner may need cross-planned visibility,

1507
00:58:58,240 --> 00:59:00,640
and maintenance may need to publish equipment status

1508
00:59:00,640 --> 00:59:03,200
without opening access to unrelated commercial data.

1509
00:59:03,200 --> 00:59:06,400
Those choices shape whether people trust the system.

1510
00:59:06,400 --> 00:59:11,280
As a Microsoft MVP, I spend a lot of time looking at where fabric fits into industrial architectures.

1511
00:59:11,280 --> 00:59:13,440
I see fabric as a strong shared foundation

1512
00:59:13,440 --> 00:59:14,880
when you use it for what it does well.

1513
00:59:14,880 --> 00:59:19,600
Connecting governed data, supporting analytics, retaining history,

1514
00:59:19,600 --> 00:59:22,560
and giving teams a common view of the facts behind a decision.

1515
00:59:22,560 --> 00:59:25,360
It won't repair poor master data,

1516
00:59:25,360 --> 00:59:29,040
create missing routing logic, decide which customer promise matters most,

1517
00:59:29,040 --> 00:59:31,520
or make an impossible alternate route executable.

1518
00:59:31,520 --> 00:59:33,520
The plan still has to define those things.

1519
00:59:33,520 --> 00:59:38,480
So use fabric to make disruption facts available across the people and systems that need them,

1520
00:59:38,480 --> 00:59:42,400
use Power BI to make the current situation and its impact understandable

1521
00:59:42,400 --> 00:59:47,280
and keep planning and optimization logic where it can properly evaluate production constraints

1522
00:59:47,280 --> 00:59:48,880
and produce a controlled schedule.

1523
00:59:48,880 --> 00:59:54,160
For a machine-down response, the goal isn't one Microsoft screen with every answer.

1524
00:59:54,160 --> 00:59:57,920
It's an architecture that lets the right decision use current trusted facts

1525
00:59:57,920 --> 01:00:00,480
before the next shift receives work it can't run.

1526
01:00:00,480 --> 01:00:02,960
Real-time visibility without over automation.

1527
01:00:02,960 --> 01:00:05,120
Here's the challenge with real-time visibility.

1528
01:00:05,120 --> 01:00:08,480
Everyone talks about it, but most implementations miss the timing.

1529
01:00:08,480 --> 01:00:12,080
Fabric can bring the facts together, but disruption response has a timing problem.

1530
01:00:12,080 --> 01:00:14,480
Data that arrives tomorrow might help you understand an outage,

1531
01:00:14,480 --> 01:00:17,920
but it can't help the planner decide what to release before the next shift.

1532
01:00:17,920 --> 01:00:20,320
In practical terms, real-time visibility means

1533
01:00:20,320 --> 01:00:23,440
the right people see a confirmed change soon enough to act.

1534
01:00:23,440 --> 01:00:28,000
Not that every sensor state change needs to travel through the enterprise and wake up half the plant.

1535
01:00:28,000 --> 01:00:31,760
Think about a machine that briefly stops because an operator clears a minor issue.

1536
01:00:31,760 --> 01:00:34,080
The PLC records the stop immediately,

1537
01:00:34,080 --> 01:00:37,200
but if production resumes a few minutes later and the order stays on track,

1538
01:00:37,200 --> 01:00:39,680
there's no reason to start a planning workflow at all.

1539
01:00:39,680 --> 01:00:41,840
A confirmed loss of capacity is different.

1540
01:00:41,840 --> 01:00:45,680
When the stop crosses the threshold, the plant has set for that resource and schedule,

1541
01:00:45,680 --> 01:00:47,680
the planning process needs current facts

1542
01:00:47,680 --> 01:00:50,560
and the event should tell the planner that capacity has changed,

1543
01:00:50,560 --> 01:00:54,880
which work faces exposure and whether the team needs to assess the plan now.

1544
01:00:54,880 --> 01:00:56,640
That brings us to event-driven updates.

1545
01:00:56,640 --> 01:00:59,520
Instead of waiting for a nightly load or a fixed report refresh,

1546
01:00:59,520 --> 01:01:04,000
a confirmed disruption can trigger a flow of current status into the decision layer.

1547
01:01:04,000 --> 01:01:08,160
The event passes from the equipment and execution side through checks that establish its meaning,

1548
01:01:08,160 --> 01:01:10,800
then updates the information used for impact analysis.

1549
01:01:10,800 --> 01:01:12,400
The word "confirmed matters".

1550
01:01:12,400 --> 01:01:15,200
A planning system should react to a state that people trust,

1551
01:01:15,200 --> 01:01:18,720
not to a raw signal that may disappear before anyone reaches the machine.

1552
01:01:18,720 --> 01:01:20,880
Data latency needs to match the decision window.

1553
01:01:20,880 --> 01:01:23,520
If a machine failure can affect the dispatch list within an hour,

1554
01:01:23,520 --> 01:01:25,680
a data refresh several hours later isn't enough.

1555
01:01:25,680 --> 01:01:28,400
If the next planning decision happens tomorrow morning,

1556
01:01:28,400 --> 01:01:32,240
forcing second by second data into that decision adds cost and noise

1557
01:01:32,240 --> 01:01:33,520
without helping anyone.

1558
01:01:33,520 --> 01:01:37,120
And let's be honest, faster data isn't automatically better data.

1559
01:01:37,120 --> 01:01:38,560
Ask a simple question,

1560
01:01:38,560 --> 01:01:42,320
how quickly must a person know this fact to make a better production decision?

1561
01:01:42,320 --> 01:01:44,800
The answer to that question sets the useful update cycle

1562
01:01:44,800 --> 01:01:47,760
and helps IT teams focus their integration work on the events

1563
01:01:47,760 --> 01:01:52,000
that carry operational consequence rather than trying to stream every tag value

1564
01:01:52,000 --> 01:01:54,560
into every downstream system.

1565
01:01:54,560 --> 01:01:58,240
Alerts need the same discipline and alert should reach someone who can take the next step.

1566
01:01:58,240 --> 01:02:00,320
That could be the maintenance lead for a machine fault,

1567
01:02:00,320 --> 01:02:03,120
the production supervisor when the current order stops,

1568
01:02:03,120 --> 01:02:06,640
or the planner only when the confirmed downtime threatens a scheduled commitment.

1569
01:02:06,640 --> 01:02:10,480
Sending every alert to every role creates the usual result.

1570
01:02:10,480 --> 01:02:12,960
People mute the alerts, build side channels,

1571
01:02:12,960 --> 01:02:15,840
and eventually discover the one message that matter too late.

1572
01:02:15,840 --> 01:02:18,640
A better approach links each event class to an action.

1573
01:02:18,640 --> 01:02:20,720
A short interruption may stay within the cell,

1574
01:02:20,720 --> 01:02:22,720
a confirmed outage pass the defined threshold

1575
01:02:22,720 --> 01:02:25,200
may create an impact assessment task for planning.

1576
01:02:25,200 --> 01:02:29,200
And a disruption that threatens a customer date may require a named escalation path.

1577
01:02:29,200 --> 01:02:32,480
The alert isn't the decision, it's a request for a specific action.

1578
01:02:32,480 --> 01:02:35,120
You also need clear rules for when analysis begins,

1579
01:02:35,120 --> 01:02:36,880
when a revised plan needs approval,

1580
01:02:36,880 --> 01:02:39,280
and when that approved change can reach operations.

1581
01:02:39,280 --> 01:02:40,560
Those steps can move quickly,

1582
01:02:40,560 --> 01:02:42,960
but they shouldn't blend into one uncontrolled chain

1583
01:02:42,960 --> 01:02:45,520
where a machine event silently changes the work sequence.

1584
01:02:45,920 --> 01:02:48,080
Production changes have physical effects.

1585
01:02:48,080 --> 01:02:49,840
Material may already sit at the machine,

1586
01:02:49,840 --> 01:02:51,760
an operator may already prepare a tool,

1587
01:02:51,760 --> 01:02:53,680
and a quality check may have started.

1588
01:02:53,680 --> 01:02:56,560
So the process needs a point where the system stops reporting

1589
01:02:56,560 --> 01:02:58,080
and people decide whether the evidence

1590
01:02:58,080 --> 01:02:59,760
justifies changing execution.

1591
01:02:59,760 --> 01:03:01,840
That boundary protects OT reliability too.

1592
01:03:01,840 --> 01:03:04,320
The control layer should keep doing its local job,

1593
01:03:04,320 --> 01:03:05,840
even if an enterprise service,

1594
01:03:05,840 --> 01:03:06,720
cloud connection,

1595
01:03:06,720 --> 01:03:09,360
or planning tool becomes slow or unavailable.

1596
01:03:09,360 --> 01:03:11,040
A PLC controls the machine,

1597
01:03:11,040 --> 01:03:13,280
local safety logic protects people and equipment,

1598
01:03:13,280 --> 01:03:15,920
and the MES manages execution close to the floor.

1599
01:03:15,920 --> 01:03:19,120
The planning layer can consume status and proposal response,

1600
01:03:19,120 --> 01:03:22,320
but it shouldn't become a remote control path into the machine.

1601
01:03:22,320 --> 01:03:25,280
That separation isn't all fashioned, it's sound engineering.

1602
01:03:25,280 --> 01:03:28,000
Real-time visibility works when it gives the right person

1603
01:03:28,000 --> 01:03:30,000
a timely, trusted reason to act,

1604
01:03:30,000 --> 01:03:32,560
and it fails when it turns the plant into an alert feed

1605
01:03:32,560 --> 01:03:34,880
with no clear owner, no decision threshold,

1606
01:03:34,880 --> 01:03:36,960
and no respect for local operations.

1607
01:03:36,960 --> 01:03:38,320
Detection can start the response,

1608
01:03:38,320 --> 01:03:41,040
but it shouldn't approve a new production plan by itself.

1609
01:03:41,040 --> 01:03:43,520
Automation boundaries and human approval.

1610
01:03:43,520 --> 01:03:46,000
A confirmed disruption can trigger analysis fast,

1611
01:03:46,000 --> 01:03:49,040
but it still shouldn't approve a revised production plan on its own.

1612
01:03:49,040 --> 01:03:50,240
There's plenty you can automate,

1613
01:03:50,240 --> 01:03:51,040
and you should.

1614
01:03:51,040 --> 01:03:52,960
The system can capture the equipment event,

1615
01:03:52,960 --> 01:03:54,880
pull the active work order from MES,

1616
01:03:54,880 --> 01:03:57,120
trace-affected orders through approved routes,

1617
01:03:57,120 --> 01:03:58,480
check current capacity,

1618
01:03:58,480 --> 01:04:00,480
and build a few feasible response options

1619
01:04:00,480 --> 01:04:02,480
against the rules you've already defined.

1620
01:04:02,480 --> 01:04:04,320
That removes a lot of manual chasing

1621
01:04:04,320 --> 01:04:07,200
and gives the planner a starting point based on current facts

1622
01:04:07,200 --> 01:04:09,920
rather than a set of calls, messages and best guesses.

1623
01:04:09,920 --> 01:04:12,320
But a schedule change reaches into real work

1624
01:04:12,320 --> 01:04:14,160
changing what an operator runs next,

1625
01:04:14,160 --> 01:04:15,680
where material moves,

1626
01:04:15,680 --> 01:04:17,040
which tool gets mounted,

1627
01:04:17,040 --> 01:04:18,400
when inspection happens,

1628
01:04:18,400 --> 01:04:20,720
and which customer commitment carries risk.

1629
01:04:20,720 --> 01:04:22,560
Those decisions often need judgment

1630
01:04:22,560 --> 01:04:24,320
that sits outside the data model.

1631
01:04:24,320 --> 01:04:26,480
Maintenance may know that a machine could return soon

1632
01:04:26,480 --> 01:04:28,240
but still want a cautious restart,

1633
01:04:28,240 --> 01:04:30,400
while a supervisor may know that an alternate machine

1634
01:04:30,400 --> 01:04:31,600
is technically free,

1635
01:04:31,600 --> 01:04:33,280
but the local team is dealing with an issue

1636
01:04:33,280 --> 01:04:34,800
the systems don't yet show.

1637
01:04:34,800 --> 01:04:37,760
Quality may accept an alternate route only with extra checks,

1638
01:04:37,760 --> 01:04:40,320
and planning may need to protect a customer relationship

1639
01:04:40,320 --> 01:04:43,200
that isn't visible in a normal order priority field.

1640
01:04:43,200 --> 01:04:45,040
That's why the system should generate options

1641
01:04:45,040 --> 01:04:46,640
not silently issue commands.

Mirko Peters

Founder of m365.fm, m365.show and m365con.net

Mirko Peters is a Microsoft 365 expert, content creator, and founder of m365.fm, a platform dedicated to sharing practical insights on modern workplace technologies. His work focuses on Microsoft 365 governance, security, collaboration, and real-world implementation strategies.

Through his podcast and written content, Mirko provides hands-on guidance for IT professionals, architects, and business leaders navigating the complexities of Microsoft 365. He is known for translating complex topics into clear, actionable advice, often highlighting common mistakes and overlooked risks in real-world environments.

With a strong emphasis on community contribution and knowledge sharing, Mirko is actively building a platform that connects experts, shares experiences, and helps organizations get the most out of their Microsoft 365 investments.

A Machine Goes Down. How Should Your Production Plan React?

Key Takeaways

Frequently Asked Questions

What should trigger a production plan reaction when a machine breaks down?

How should uncertainty in maintenance repair times be handled in production planning?

Why is machine availability not the same as executable production capacity?

How do you determine which orders are truly affected by a machine failure?

Listen On

Support On

Featured Episodes

Recent Episodes

Data Governance Episodes

Power Platform Episodes

Microsoft Security Episodes

Cloud Architecture Episodes

AI in Microsoft 365 Episodes

Dynamics 365 Insights Episodes

Developer Practices Episodes

Microsoft 365 Podcast – Teams, SharePoint, Office Apps & Productivity Episodes

Browse episodes by category

Related to this Episode

Why Excel Outages and Versioning Fail During Factory Machine Breakdowns