What Happens When Sales Promises an Urgent Order

1
00:00:00,000 --> 00:00:04,080
picture this. A customer calls sales late in the day because they need an order fast,

2
00:00:04,080 --> 00:00:08,080
whether because the supplier failed their own line is nearly stopping, or the order set in their

3
00:00:08,080 --> 00:00:13,360
process too long and they need a firm date before the next call. Sales recognizes an account

4
00:00:13,360 --> 00:00:17,920
that matters, a customer problem that feels real, and an opportunity to step in so they promise

5
00:00:17,920 --> 00:00:23,120
a delivery date and that order lands in ERP with one word attached, priority. That word travels

6
00:00:23,120 --> 00:00:27,600
fast, reaching a production planner before anyone's checked material, machine time, tools,

7
00:00:27,600 --> 00:00:31,840
labor skills, quality rules, or the work already committed to other customers. The new order is

8
00:00:31,840 --> 00:00:37,440
urgent, but it doesn't land in an empty plant. It enters a schedule already full of existing promises.

9
00:00:37,440 --> 00:00:42,240
Instead of asking if we can squeeze it in, the real question is which existing commitment absorbs

10
00:00:42,240 --> 00:00:46,240
the disruption. I'm not arguing against sales. A factory needs sales to listen to customers,

11
00:00:46,240 --> 00:00:50,160
especially when a customer has a real problem and production can't just say no to everything.

12
00:00:50,160 --> 00:00:54,800
The problem starts when urgency becomes a label on one order instead of a change to the whole

13
00:00:54,800 --> 00:01:00,080
production system, because that order has to use something. Material, machine time, maybe a skilled

14
00:01:00,080 --> 00:01:04,880
setter, an inspector, a fixture, a test bench, a packing slot, and a truck leaving before a carrier

15
00:01:04,880 --> 00:01:09,680
cut off. If those resources are already supporting planned work, the urgent order doesn't just move

16
00:01:09,680 --> 00:01:14,160
itself forward, something else moves back. That hidden cost often stays invisible at first.

17
00:01:14,160 --> 00:01:19,120
The salesperson sees a customer date, the planner sees a crowded schedule, and the supervisor sees

18
00:01:19,120 --> 00:01:24,160
what's actually on the shop floor, the setup that ran long, the job waiting for first off inspection,

19
00:01:24,160 --> 00:01:28,000
customer service sees a firm promise, each person sees a real piece of the problem,

20
00:01:28,000 --> 00:01:31,760
but no single view tells you what that promise will truly cost. In this episode,

21
00:01:31,760 --> 00:01:36,480
we'll trace that chain reaction. One hypothetical urgent order from the customer promise into

22
00:01:36,480 --> 00:01:41,520
the schedule, through capacity and material pressure, into shifting bottlenecks, and finally into

23
00:01:41,520 --> 00:01:46,480
the delivery dates that start shifting for other customers. Not every urgent order should be rejected,

24
00:01:46,480 --> 00:01:50,800
some clearly deserve priority, but someone needs to see the trade-off before the plant discovers

25
00:01:50,800 --> 00:01:55,760
it by accident. Let's make it concrete. Picture a plant already running close to plan

26
00:01:55,760 --> 00:01:59,360
with very little spare time hiding in the day, the factory scenario.

27
00:01:59,360 --> 00:02:04,480
This is a hypothetical scenario, but the mechanics will feel familiar if you work in discrete

28
00:02:04,480 --> 00:02:10,080
manufacturing. Picture a plant making machine and assembled industrial components. Raw stock and

29
00:02:10,080 --> 00:02:16,080
purchase parts come in, CNC machines cut and mill, parts move into assembly, inspection checks

30
00:02:16,080 --> 00:02:20,400
dimensions and paperwork, and finally packing gets the order ready for shipment. Nothing

31
00:02:20,400 --> 00:02:25,120
unusual about that flow, the plant doesn't run one product on one machine from start to finish.

32
00:02:25,120 --> 00:02:29,120
Different products share machines, people, tools, inspection and material handling.

33
00:02:29,120 --> 00:02:34,000
A single CNC cell may support multiple product families and assembly might wait for parts from

34
00:02:34,000 --> 00:02:39,120
several machining routes. Inspection can work smoothly most days, then turn into a queue when

35
00:02:39,120 --> 00:02:44,480
several complex jobs finish at once. The schedule already has confirmed work, orders with due dates

36
00:02:44,480 --> 00:02:49,600
next week, some needing to ship in a few days because of transport time, some already started,

37
00:02:49,600 --> 00:02:54,240
some waiting for components, some waiting for a certified operator. The plan also accounts,

38
00:02:54,240 --> 00:02:59,680
at least on paper, for machine calendars, shifts, setup, maintenance windows and inter-operation

39
00:02:59,680 --> 00:03:04,880
travel time. No planar starts from a blank page, now sales gets a request from a long-standing customer.

40
00:03:04,880 --> 00:03:09,120
They need a fixed quantity of a component the plant already makes, but in a much shorter

41
00:03:09,120 --> 00:03:13,200
lead time than normal, and they need a firm date because it supports their own production.

42
00:03:13,200 --> 00:03:18,000
Sales agrees to help so the urgent order enters the system with a requested chip date and a priority flag.

43
00:03:18,000 --> 00:03:23,280
The message to planning sounds simple, please fit this in, the customer needs it. Planning sees

44
00:03:23,280 --> 00:03:28,400
that same order very differently, it comes with a quantity, a product number, a date and commercial

45
00:03:28,400 --> 00:03:33,520
pressure, but it doesn't bring free machine time or material already set aside, or an extra operator

46
00:03:33,520 --> 00:03:38,720
on the next shift. Changing a priority field color in ERP won't create hidden capacity,

47
00:03:38,720 --> 00:03:43,120
that sounds obvious when you say it out loud, yet a lot of expedite work starts with the assumption

48
00:03:43,120 --> 00:03:47,520
that the plant will somehow find room. And often the plant does find room, good planners and shopfloor

49
00:03:47,520 --> 00:03:52,560
teams are experts at adapting, they know which job can wait, who can stay late, which supplier might

50
00:03:52,560 --> 00:03:57,280
answer a call, and which sequence can change without causing chaos. But experience and effort

51
00:03:57,280 --> 00:04:01,680
don't remove the constraint, they only decide where it will appear. In this scenario, the urgent

52
00:04:01,680 --> 00:04:06,560
product needs two machine parts, a purchased seal kit, assembly, final inspection and packing.

53
00:04:06,560 --> 00:04:11,440
The seal kit shows available in ERP. One CNC can produce the first part quickly, but already has

54
00:04:11,440 --> 00:04:15,600
workbooked, while the second part can run on several machines, though, not all have the right

55
00:04:15,600 --> 00:04:20,720
tooling installed. Assembly has capacity later in the week, but inspection is tight because another

56
00:04:20,720 --> 00:04:25,360
order needs a documented final release. From a distance, the order looks simple, but up close,

57
00:04:25,360 --> 00:04:30,480
it touches most of the plant. A planner now has practical questions, which work order loses time

58
00:04:30,480 --> 00:04:34,880
if the urgent order runs first? Does that displaced work contain a component needed by another

59
00:04:34,880 --> 00:04:39,760
assembly order? Can the material balance support both orders or does one customer lose allocated stock,

60
00:04:39,760 --> 00:04:44,240
who sets up the machine, and can that person do it on the shift with the slot? If the urgent

61
00:04:44,240 --> 00:04:48,800
job reaches inspection first, which inspection job waits, the plant needs facts, not drama,

62
00:04:48,800 --> 00:04:53,600
and those facts can change while the planner checks them. A machine finishes early, a setup runs

63
00:04:53,600 --> 00:04:58,400
long, material arrives late, or an operator reports an issue that never hit the system.

64
00:04:58,400 --> 00:05:02,800
That's why urgent order decisions create so much pressure. People are trying to make a commercial

65
00:05:02,800 --> 00:05:07,920
commitment while the physical system keeps moving. For this scenario, assume sales has already promised

66
00:05:07,920 --> 00:05:13,040
the customer a delivery date. That date sits in the order record looking firm, but a promised date

67
00:05:13,040 --> 00:05:16,720
and a feasible date aren't the same thing. A promise is not a production plan.

68
00:05:16,720 --> 00:05:22,320
When sales gives the customer a date, that's a commercial commitment. It tells the customer what

69
00:05:22,320 --> 00:05:26,720
the business intends to deliver. A production plan answers a completely different question. It asks

70
00:05:26,720 --> 00:05:31,040
whether there's a real path from raw material to shipped product inside the time available,

71
00:05:31,040 --> 00:05:35,360
while all the existing work keeps moving through the plant. Those two things should connect,

72
00:05:35,360 --> 00:05:40,160
but in practice, they often don't. An ERP system can hold three dates, requested, promised,

73
00:05:40,160 --> 00:05:44,160
and planned production. It can calculate requirements from bills of material,

74
00:05:44,160 --> 00:05:49,200
lead times, and rooting data. That gives the business a demand signal, purchasing needs it,

75
00:05:49,200 --> 00:05:53,520
planning needs it, and finance and customer service all need a common commercial record,

76
00:05:53,520 --> 00:05:57,920
but a date in ERP doesn't prove the plant can actually meet it. Here's the difference between

77
00:05:57,920 --> 00:06:02,720
an appointment in a calendar and a room that's actually reserved with the right people, equipment,

78
00:06:02,720 --> 00:06:07,760
and materials inside it. One is an intention, the other is a workable arrangement, a finite capacity

79
00:06:07,760 --> 00:06:12,320
schedule deals with that second problem. Finite capacity means the scheduler treats each resource

80
00:06:12,320 --> 00:06:17,920
as limited. A CNC machine only has so many usable hours in a shift. An inspection bench only works

81
00:06:17,920 --> 00:06:22,400
when an inspector and test equipment are both available. A packing station still needs enough time

82
00:06:22,400 --> 00:06:26,800
before the carrier collection. The schedule doesn't magically get extra hours, just because an order

83
00:06:26,800 --> 00:06:31,920
feels urgent. So when someone asks, can we make it? The planner can't answer from one date field,

84
00:06:31,920 --> 00:06:36,000
they need to break the question apart. Is all the material ready for this exact order?

85
00:06:36,000 --> 00:06:40,000
Does the approved process route match the product revision and customer rules? Is there booked

86
00:06:40,000 --> 00:06:44,800
capacity at every operation? Can qualified people run, set, inspect and release the work?

87
00:06:44,800 --> 00:06:49,680
Do the quality checks fit within the required window? And can the finished goods still leave in time?

88
00:06:49,680 --> 00:06:53,920
Each answer can change the final answer. You might have raw stock but lack of purchase component.

89
00:06:53,920 --> 00:06:58,080
You might have a machine slot, but no release program for that revision. You might complete the

90
00:06:58,080 --> 00:07:02,640
product on time, then miss the dispatch cut off by an hour. From the customer's point of view,

91
00:07:02,640 --> 00:07:06,720
the order is still late. This is where many ERP planning models need a careful reading.

92
00:07:06,720 --> 00:07:11,520
Some systems plan with what people call infinite capacity. The system takes demand, routing times

93
00:07:11,520 --> 00:07:16,000
and dates, then creates planned work without first proving that every work centre has enough room.

94
00:07:16,000 --> 00:07:20,240
That approach works well for rough planning. It helps you see expected load, helps purchasing,

95
00:07:20,240 --> 00:07:25,200
see future need, and can show rising demand before the shop floor feels it. But infinite capacity

96
00:07:25,200 --> 00:07:29,520
planning doesn't actually resolve collisions. If five work orders all require the same machine

97
00:07:29,520 --> 00:07:34,640
on the same afternoon, the plan can place all five there. On paper each order may look on time.

98
00:07:34,640 --> 00:07:38,400
In the plant, one runs first, another waits and the rest form a queue.

99
00:07:38,400 --> 00:07:43,440
The conflict doesn't disappear because the system calculated a date. It simply moves from

100
00:07:43,440 --> 00:07:47,920
planning into daily firefighting. A finite capacity schedule forces the collision into the open

101
00:07:47,920 --> 00:07:52,560
earlier. It puts operations onto actual resource calendars and asks what must move

102
00:07:52,560 --> 00:07:56,720
when a new operation takes a slot that doesn't make the decision easy, but it makes the consequence

103
00:07:56,720 --> 00:08:01,280
visible while somebody can still choose. Choice matters. The urgent order might deserve the slot

104
00:08:01,280 --> 00:08:05,840
if the customer faces a line stop. Another order might move with little customer impact.

105
00:08:05,840 --> 00:08:09,600
Over time might change the answer. The commercial promise might need revision before it reaches

106
00:08:09,600 --> 00:08:13,680
the customer. Those are business decisions, but they need a production fact base to stand on.

107
00:08:13,680 --> 00:08:17,840
A red priority flag doesn't create another machine, a qualified operator,

108
00:08:17,840 --> 00:08:22,080
an approved inspection route or a truck that waits after the loading gate closes.

109
00:08:22,080 --> 00:08:25,840
It tells people to examine the order sooner. That's useful, but it isn't capacity.

110
00:08:25,840 --> 00:08:30,400
So let's start with the first resource everybody tries to move when the urgent order lands.

111
00:08:30,400 --> 00:08:34,960
Machine time. The first schedule move. The planar starts with the route.

112
00:08:34,960 --> 00:08:40,000
Not the final ship date or the priority label, but the first operation that can physically begin

113
00:08:40,000 --> 00:08:45,280
the work. In our scenario, that means finding time on the CNC machine for the first machine part.

114
00:08:45,280 --> 00:08:49,040
The schedule already holds booked operations on that machine. Some may be running,

115
00:08:49,040 --> 00:08:53,200
others may sit in a queue. The planar looks for the earliest workable slot and inserts the

116
00:08:53,200 --> 00:08:57,840
urgent operation there. That word workable does a lot of work. A blank space in a machine calendar

117
00:08:57,840 --> 00:09:02,000
doesn't always mean usable time. The machine may need a different setup. The tool package might sit

118
00:09:02,000 --> 00:09:06,080
on another machine. The program might not be released yet. A maintenance window may block the

119
00:09:06,080 --> 00:09:10,880
apparent gap even if nobody has placed a work order there. So the planar doesn't just drag an order

120
00:09:10,880 --> 00:09:15,200
into an empty looking space. They check the sequence around it. Let's say the machine currently runs

121
00:09:15,200 --> 00:09:20,160
a family of parts that use the same fixture and similar tools. Incerting the urgent order may mean

122
00:09:20,160 --> 00:09:25,040
stopping that run, removing the fixture, loading another, calling the setter, loading tools,

123
00:09:25,040 --> 00:09:30,240
checking offsets and proving the first part. Then after the urgent batch, the team may need to set

124
00:09:30,240 --> 00:09:34,960
the machine back again. The order has consumed more than cycle time. It has consumed setup time,

125
00:09:34,960 --> 00:09:39,440
attention and sequence stability. A schedule that only counts the minutes when a tool cuts metal can

126
00:09:39,440 --> 00:09:44,240
look very efficient right up until somebody has to perform the change over. Final capacity scheduling

127
00:09:44,240 --> 00:09:48,480
puts this onto a real machine calendar. Think of the calendar as booked blocks of time on a named

128
00:09:48,480 --> 00:09:52,560
resource during actual shifts with known rules around when that resource can run.

129
00:09:52,560 --> 00:09:58,080
An operation needs a block long enough fitting after the previous operation releases the work

130
00:09:58,080 --> 00:10:02,560
and before the next operation can start. If the urgent order takes a block on the CNC machine,

131
00:10:02,560 --> 00:10:08,240
another booked operation can't occupy that same block. The system or the planar has to move something.

132
00:10:08,240 --> 00:10:12,640
Suppose the urgent operation takes Tuesday morning. That slot originally belonged to an order due

133
00:10:12,640 --> 00:10:17,680
later that week. The displaced operation doesn't disappear. It moves to Tuesday afternoon or Wednesday,

134
00:10:17,680 --> 00:10:22,480
or the next point where the machine tools and setup sequence permit. That looks like a small adjustment

135
00:10:22,480 --> 00:10:27,040
from a distance, but the original order may not move by the same number of hours. If it loses a

136
00:10:27,040 --> 00:10:31,520
morning slot and resumes after a different setup, it might lose the whole day. A maintenance break

137
00:10:31,520 --> 00:10:36,560
can sit in the next open period, or another high priority job may already hold the following slot.

138
00:10:36,560 --> 00:10:41,440
The calendar contains constraints not just gaps. Planners often face a choice between two imperfect

139
00:10:41,440 --> 00:10:46,000
moves. They can place the urgent job in the earliest available slot, which creates extra setups

140
00:10:46,000 --> 00:10:50,000
and interrupts a stable run. Or they can wait until the next natural sequence change,

141
00:10:50,000 --> 00:10:54,960
which may reduce disruption, but push the job later. Neither answer comes from a priority flag.

142
00:10:54,960 --> 00:10:59,760
It comes from the actual state of the machine schedule. Program release can change the picture too.

143
00:10:59,760 --> 00:11:04,960
A routing may show that the part runs on this CNC machine, and the standard time may look reasonable.

144
00:11:04,960 --> 00:11:09,680
Yet if engineering hasn't released the correct CNC program, the slot isn't ready. If the program

145
00:11:09,680 --> 00:11:13,680
exists but the revision doesn't match, the order still can't run. A planning system needs that

146
00:11:13,680 --> 00:11:18,560
status to claim the job fits. Maintenance deserves the same respect. A machine scheduled for planned

147
00:11:18,560 --> 00:11:23,520
maintenance isn't spare capacity. Moving maintenance to fit an urgent order may sound tempting when

148
00:11:23,520 --> 00:11:28,160
the machine runs well, but that decision creates a different type of risk. It should be visible

149
00:11:28,160 --> 00:11:32,880
as a conscious trade, not quietly erased from the calendar. Now the earliest machining slot

150
00:11:32,880 --> 00:11:36,960
still doesn't guarantee the earliest completed order. The urgent part may leave the CNC machine

151
00:11:36,960 --> 00:11:40,640
quickly, then wait because the next operation can't take it. Perhaps the next machine has its own

152
00:11:40,640 --> 00:11:45,120
booked work or the order requires a later process step that only runs on a certain shift.

153
00:11:45,120 --> 00:11:49,920
The first available slot only solves the first operation. Flow depends on the whole route. This is

154
00:11:49,920 --> 00:11:54,080
where a schedule stops being a list of work orders and starts behaving like a connected chain.

155
00:11:54,080 --> 00:11:58,960
One operation moves, then its successor needs a new time, and the order that lost its original slot

156
00:11:58,960 --> 00:12:03,440
needs a new path as well. A moved operation becomes a moved order, and the effects begin to spread.

157
00:12:03,440 --> 00:12:05,840
The order that gets pushed aside.

158
00:12:07,440 --> 00:12:11,920
When an urgent operation jumps the queue on the CNC machine, the order you had scheduled for that slot

159
00:12:11,920 --> 00:12:16,240
inherits the delay, it might sound straightforward, but the displaced order doesn't just lose

160
00:12:16,240 --> 00:12:20,800
machine time, it loses its entire planned path through the plant. Every later operation

161
00:12:20,800 --> 00:12:24,960
depended on the earlier one finishing when the schedule expected. Let's say that order needed

162
00:12:24,960 --> 00:12:29,280
machining on Tuesday morning, assembly later that day, inspection on Wednesday, and packing before

163
00:12:29,280 --> 00:12:33,440
Thursday's carrier collection. The schedule lined up those operations because the machining step

164
00:12:33,440 --> 00:12:38,320
was supposed to release parts on time. Once machining shifts, assembly may have nothing to work on.

165
00:12:38,320 --> 00:12:42,320
The assembly team might still have an open period on paper, but without the required machined

166
00:12:42,320 --> 00:12:47,040
components, that slot doesn't help anyone. They sensibly move to other work. Then when the displaced

167
00:12:47,040 --> 00:12:50,960
order reaches assembly later, the original slot is already taken. Here's where the confusion

168
00:12:50,960 --> 00:12:56,720
between a plan start date and an actual ready date shows up. A plan start date tells you when

169
00:12:56,720 --> 00:13:01,360
the schedule expected an operation to begin. An actual ready date tells you when the order or the

170
00:13:01,360 --> 00:13:05,840
required component can really arrive at that operation with all prior work complete. After one

171
00:13:05,840 --> 00:13:10,000
disruption, those dates can diverge very quickly. The next routing step cannot begin just because

172
00:13:10,000 --> 00:13:14,720
its calendar slot exists. It needs the work from the prior step, maybe an operator with the right

173
00:13:14,720 --> 00:13:19,360
skill, maybe a released inspection result before a subassembly can move forward. When the input isn't

174
00:13:19,360 --> 00:13:23,920
ready, the operation waits. When it waits, the time reserved for it may be used by another job

175
00:13:23,920 --> 00:13:28,000
that is ready. That's just normal shop floor behavior. Nobody should leave a capable assembly

176
00:13:28,000 --> 00:13:32,560
station idle for hours to preserve a booking for an order that hasn't arrived. But once another

177
00:13:32,560 --> 00:13:37,280
order fills that slot, the displaced order enters a queue, waiting behind work that got there first,

178
00:13:37,280 --> 00:13:41,520
that waiting is queue time, not processing time. The machino station might only need a short period

179
00:13:41,520 --> 00:13:45,760
for the operation, but the order may wait much longer because other work already sits ahead,

180
00:13:45,760 --> 00:13:51,120
and the resource can only process one job at a time. A small insertion creates a larger delay.

181
00:13:51,120 --> 00:13:55,760
The urgent order might take four hours on a CNC machine, but the displaced order may lose far

182
00:13:55,760 --> 00:14:00,640
more than four hours. It misses an assembly window, waits for the next available skilled operator,

183
00:14:00,640 --> 00:14:04,240
and arrives too late for an inspection booking. The delay grows at the handoffs.

184
00:14:04,240 --> 00:14:08,400
Thin buffers make this worse. A buffer is time, stock or available capacity that absorbs

185
00:14:08,400 --> 00:14:12,560
variation without changing the next commitment. Many plants run with deliberately small buffers

186
00:14:12,560 --> 00:14:18,000
because excess WIP, idle resources, and long lead times all cost money. That approach works

187
00:14:18,000 --> 00:14:22,800
well when the plan holds, but a tightly timed route leaves little room to recover. If the displaced

188
00:14:22,800 --> 00:14:27,360
order had half a day of slack before assembly, it might absorb the lost CNC slot without affecting

189
00:14:27,360 --> 00:14:31,520
its customer date. If it had no slack, every hour of delay becomes visible downstream.

190
00:14:31,520 --> 00:14:36,080
The order misses one planned handoff, then another, until a local scheduling move becomes a delivery

191
00:14:36,080 --> 00:14:40,960
risk. Take inspection as a common example. The displaced order reaches final inspection after

192
00:14:40,960 --> 00:14:45,360
its original window has passed. An inspector may already have a sequence of jobs arranged around

193
00:14:45,360 --> 00:14:50,080
customer documentation, test equipment, and release requirements. The order can't simply step

194
00:14:50,080 --> 00:14:54,400
in front of all of them without creating another set of displacements. Packing works the same way,

195
00:14:54,400 --> 00:14:58,400
though people tend to treat it as an afterthought. A product can be physically complete and still

196
00:14:58,400 --> 00:15:04,000
mischipment if packing capacity, export documents, customer labels, or the planned dispatch slot no longer

197
00:15:04,000 --> 00:15:09,680
fit. The customer doesn't see almost shipped. They see late delivery, so the planner needs more than

198
00:15:09,680 --> 00:15:14,400
a revised start time for the first operation. They need to ask step by step, when is this order

199
00:15:14,400 --> 00:15:18,720
truly ready for the next routing operation? Does that operation still have room, and if not,

200
00:15:18,720 --> 00:15:23,280
which work now moves? And does the latest completed operation still leave enough time for inspection

201
00:15:23,280 --> 00:15:27,840
and packing? That chain can run through several orders at once. One urgent order displaces order A

202
00:15:27,840 --> 00:15:33,040
at machining, order A arrives later assembly and takes a place that order B expected. Order B misses

203
00:15:33,040 --> 00:15:38,480
inspection nobody did anything irrational. Each team used the best available option in its own area.

204
00:15:38,480 --> 00:15:43,440
The trouble comes from the connections between areas. A local decision can preserve output at one

205
00:15:43,440 --> 00:15:48,640
work centre, while moving delivery risk to another part of the plant. That's why a schedule needs to

206
00:15:48,640 --> 00:15:53,920
follow the order across its entire route, not just report whether the first machine found a gap,

207
00:15:53,920 --> 00:15:57,680
and the schedule doesn't live on machines alone. Material doesn't obey priority flags.

208
00:15:57,680 --> 00:16:04,160
Machine time only tells part of the story. The urgent order also needs physical things and those

209
00:16:04,160 --> 00:16:09,200
things don't move just because you change the field in ERP. In our scenario, the order needs raw stock

210
00:16:09,200 --> 00:16:14,080
for the machined parts, a purchased seal kit, cutting tools and coolant, the correct fixture,

211
00:16:14,080 --> 00:16:18,880
protective packing, labels and the documents that travel with the shipment. Each item has its own

212
00:16:18,880 --> 00:16:23,920
availability rule, some sit in the warehouse, some wait at a supplier, and some exist on site but

213
00:16:23,920 --> 00:16:28,160
belong to work already planned. That distinction changes the answer. A stock balance might show

214
00:16:28,160 --> 00:16:32,400
enough seal kits for the urgent order, but when the planner checks the detail, most of those kits are

215
00:16:32,400 --> 00:16:37,040
already allocated to another work order with a near term ship date. The parts are on the shelf,

216
00:16:37,040 --> 00:16:41,760
but they aren't truly free. Taking them for the urgent order creates a second problem. The new

217
00:16:41,760 --> 00:16:47,040
customer gets the kits. Another customer now faces a shortage, unless purchasing can replace the stock

218
00:16:47,040 --> 00:16:51,920
before that original order reaches assembly. The plant hasn't solved the material constraint,

219
00:16:51,920 --> 00:16:56,080
it has transferred it from one commitment to another. This is why material packing matters. It links

220
00:16:56,080 --> 00:17:00,400
the specific supply such as a purchase order receipt, lot or stock quantity, to the work order that

221
00:17:00,400 --> 00:17:04,800
needs it. In plain language, it answers the practical question of which stock supports which customer

222
00:17:04,800 --> 00:17:09,680
commitment. Without that link, a planner sees a total quantity and may assume the order fits.

223
00:17:09,680 --> 00:17:14,640
With the link, they can see that using 20 seal kits for the urgent job removes 20 kits from an order

224
00:17:14,640 --> 00:17:18,320
already promised to someone else. That doesn't mean the urgent order can't go ahead. It means

225
00:17:18,320 --> 00:17:22,320
the decision needs an owner who can accept the other customer's risk, and even a visible stock

226
00:17:22,320 --> 00:17:26,720
balance doesn't prove the material is usable. A batch might still wait for incoming inspection,

227
00:17:26,720 --> 00:17:31,120
a lot may only be approved for a certain customer or product revision and shelf life can rule out

228
00:17:31,120 --> 00:17:35,920
older stock, especially with adhesives, coatings or seal materials. A customer specification may

229
00:17:35,920 --> 00:17:40,400
require traceability to an approved source. You may physically hold a substitute part,

230
00:17:40,400 --> 00:17:44,240
but it could need engineering approval, a quality review, or a change to the bill of material

231
00:17:44,240 --> 00:17:49,280
before production can touch it. Available inventory is account, but usable inventory is material

232
00:17:49,280 --> 00:17:54,400
that can legally and technically go into this order at this point in the process, with the required

233
00:17:54,400 --> 00:17:59,440
quality and traceability. Those aren't the same number, and many urgent order decisions fail

234
00:17:59,440 --> 00:18:03,680
in that gap. Fictures create a similar issue, though they are easy to overlook, the urgent product

235
00:18:03,680 --> 00:18:08,000
may need a fixture that exists only once. Another machine might look open, but it can't produce the part

236
00:18:08,000 --> 00:18:13,040
if the fixture is still bolted onto a different machine, waiting for inspection, or scheduled for repair.

237
00:18:13,040 --> 00:18:17,760
The same applies to special gauges, test adapters, returnable packaging, and even clean containers

238
00:18:17,760 --> 00:18:22,400
where the process requires them. A work order doesn't consume only material. It consumes access

239
00:18:22,400 --> 00:18:26,880
to resources. At this point, somebody usually calls the supplier. An expedite can be the right

240
00:18:26,880 --> 00:18:31,280
response. The supplier may hold stock, bring forward a delivery, split a shipment, or a range special

241
00:18:31,280 --> 00:18:36,000
transport, but an expedite doesn't erase risk. It can raise purchase cost, create pressure to accept

242
00:18:36,000 --> 00:18:40,400
a part before quality checks finish, or arrive after the internal receiving cutoff. That means the

243
00:18:40,400 --> 00:18:45,600
material reaches the gate but not the line. Transport can create its own false confidence. A supplier

244
00:18:45,600 --> 00:18:49,920
may confirm that the parts leave their site today, but that's not the same as confirming that

245
00:18:49,920 --> 00:18:55,120
they arrive, clear receiving, pass inspection if required, and reach the point of use before the

246
00:18:55,120 --> 00:19:01,520
operation needs them. A truck on the road isn't usable inventory either. A good material check follows

247
00:19:01,520 --> 00:19:05,680
the order all the way through. It checks what the urgent job needs, what is physically present,

248
00:19:05,680 --> 00:19:10,880
what is approved for use, what already supports another work order, and what supply can arrive in

249
00:19:10,880 --> 00:19:16,000
time with enough confidence to schedule against it. If material moves from one order to another,

250
00:19:16,000 --> 00:19:19,920
the schedule should show the newly exposed shortage immediately, otherwise the plant just

251
00:19:19,920 --> 00:19:24,960
postpones a difficult customer conversation. This is also where static lead time start to look thin,

252
00:19:24,960 --> 00:19:29,600
a purchase lead time tells you the normal replenishment pattern, but it doesn't tell you whether a supplier

253
00:19:29,600 --> 00:19:34,880
can respond today, whether a substitute meets the specification, or whether an allocated lot can

254
00:19:34,880 --> 00:19:40,880
safely change hands. Those details live across purchasing, warehouse, quality, engineering, and production.

255
00:19:40,880 --> 00:19:45,840
The urgent order has now pulled on machine time and material. Once material moves, labor often

256
00:19:45,840 --> 00:19:53,360
becomes the next pressure point. The labor constraint nobody sees in ERP. Here's the problem. Most

257
00:19:53,360 --> 00:19:57,840
manufacturers don't talk about. The material can be ready, the machine calendar shows open time,

258
00:19:57,840 --> 00:20:02,000
and you still can't run the urgent order because nobody with the right skills is available to do the

259
00:20:02,000 --> 00:20:07,760
work. Factories schedule real people with real knowledge, approvals, shift assignments, and limits,

260
00:20:07,760 --> 00:20:13,280
not anonymous labor. A CNC machine needs more than someone to press cycle start. It needs a

261
00:20:13,280 --> 00:20:18,240
setter who knows that specific machine, the fixture, the control, and the product family. A well cell

262
00:20:18,240 --> 00:20:22,560
needs a certified welder, final inspection needs a person approved to release that customer's

263
00:20:22,560 --> 00:20:26,880
documentation and maintenance may need a specialist before a machine goes back into service.

264
00:20:26,880 --> 00:20:31,040
ERP often records headcount, but that doesn't always tell planning who can actually perform a

265
00:20:31,040 --> 00:20:35,760
specific operation on a specific shift with the current product revision under the rules that

266
00:20:35,760 --> 00:20:40,560
apply in that plant. You might have 10 people on site according to the roster, but 0 people who can

267
00:20:40,560 --> 00:20:45,520
set up the urgent job safely and correctly. That skill-based capacity, the overlap between an

268
00:20:45,520 --> 00:20:50,720
available resource and an available person who is allowed and able to use that resource.

269
00:20:50,720 --> 00:20:55,120
Open time on a machine means very little if the qualified operator is on another shift,

270
00:20:55,120 --> 00:21:00,160
already committed to a set-up, absent, or tied up with a quality approval. The schedule needs both.

271
00:21:00,160 --> 00:21:04,960
Picture the urgent order taking a slot on a CNC machine overnight. On paper the slot looks good,

272
00:21:04,960 --> 00:21:10,240
machine runs material is staged, but the one setter who can prepare the special fixture works

273
00:21:10,240 --> 00:21:15,440
the day shift and is already assigned to recover a delayed order on another cell. Planning now has

274
00:21:15,440 --> 00:21:20,400
choices, none of them free. You can move the urgent operation to the day shift, ask the setter to

275
00:21:20,400 --> 00:21:24,800
work overtime, bring in someone else who may need support, or delay a different set-up and take

276
00:21:24,800 --> 00:21:29,280
that risk. The machine capacity never changed, but the usable capacity changed the moment the people

277
00:21:29,280 --> 00:21:33,440
constrained entered the picture. Certifications add another layer, a person might know how to do

278
00:21:33,440 --> 00:21:38,320
the work, but lack current approval for a regulated weld, a safety sensitive test, or a customer-specific

279
00:21:38,320 --> 00:21:43,280
inspection. In some plants that approval sits in a separate system, and in others, a supervisor

280
00:21:43,280 --> 00:21:47,520
just knows it from experience. Either way, a schedule that ignores it can create a plan that looks

281
00:21:47,520 --> 00:21:52,320
feasible right until the job reaches the station and then someone has to stop it. Shift patterns matter

282
00:21:52,320 --> 00:21:56,720
too. A work centre may run across several shifts while the required inspector only works

283
00:21:56,720 --> 00:22:01,040
certain hours, so a production order can finish at night, then wait until the next day for

284
00:22:01,040 --> 00:22:05,520
first off approval or final release. That wait is fine when it's planned, but it becomes a

285
00:22:05,520 --> 00:22:10,080
delivery risk when the schedule assumed a person would appear the exact moment the work finished.

286
00:22:10,080 --> 00:22:14,240
Absence changes the same calculation, people take leave, get sick, attend training, or get pulled

287
00:22:14,240 --> 00:22:18,640
into safety work, maintenance support, or a problem job that can't wait. Good planning doesn't

288
00:22:18,640 --> 00:22:23,280
pretend those things never happen. It gives supervisors and planners a way to see which skills are thin,

289
00:22:23,280 --> 00:22:28,400
where backup exists, and where one person creates a single point of failure. Local work rules need

290
00:22:28,400 --> 00:22:33,680
the same respect. Over time limits, rest periods, union agreements and sight rules aren't annoying

291
00:22:33,680 --> 00:22:38,960
details to work around after the schedule fails. They define the labour capacity the plant can actually

292
00:22:38,960 --> 00:22:43,840
use. If an urgent order requires a second shift but the plant can't staff that shift,

293
00:22:43,840 --> 00:22:48,160
lawfully or safely, then that capacity isn't available. Over time can still help, sometimes it's the

294
00:22:48,160 --> 00:22:52,480
best choice. A short overtime window may protect an important customer date without pushing several

295
00:22:52,480 --> 00:22:56,960
other orders back, but over time should be a controlled decision because it carries cost,

296
00:22:56,960 --> 00:23:02,160
fatigue risk, and often a follow-on effect the next day when the same people need recovery time

297
00:23:02,160 --> 00:23:06,960
or can't work another extended shift. Treating overtime as the automatic answer creates a

298
00:23:06,960 --> 00:23:11,040
schedule that only works if people keep absorbing the gaps. That approach eventually breaks.

299
00:23:11,040 --> 00:23:15,280
The planner may see a recovery path while the supervisor sees a team already stretched across

300
00:23:15,280 --> 00:23:19,760
changeovers, checks, handoffs, and problems that never fit neatly into standard times.

301
00:23:19,760 --> 00:23:24,480
Sometimes the most experienced person creates the largest ripple. Move a senior setter to the

302
00:23:24,480 --> 00:23:28,800
urgent machine and another cell may wait for setup. Move the only qualified inspector to release

303
00:23:28,800 --> 00:23:33,200
the urgent order and a different order loses its final release window. Pull maintenance support

304
00:23:33,200 --> 00:23:37,920
into one recovery action and another planned intervention slips. Each decision can look sensible

305
00:23:37,920 --> 00:23:42,800
in isolation, but taken together they change the flow across the plant. Routing changes and they're

306
00:23:42,800 --> 00:23:49,280
hidden cost. Once the planner sees pressure on the original machine, the obvious question becomes,

307
00:23:49,280 --> 00:23:53,840
can't we run it somewhere else? Sometimes you can. A second CNC machine may have the range,

308
00:23:53,840 --> 00:23:58,320
spindle speed, and work envelope to process the part or another assembly cell may look similar.

309
00:23:58,320 --> 00:24:02,480
A root sheet may even list an alternate resource, so the decision looks simple, move the

310
00:24:02,480 --> 00:24:06,880
urgent work there and protect the original schedule, but an alternate resource is not automatically

311
00:24:06,880 --> 00:24:11,040
an alternate production route. A rooting can list machine B as an option because the machine can

312
00:24:11,040 --> 00:24:15,440
physically perform the operation. That tells you something useful, but it doesn't tell you whether the

313
00:24:15,440 --> 00:24:20,480
machine has the correct fixture, loaded tools, approved program, trained people, and inspection

314
00:24:20,480 --> 00:24:25,440
method ready for this exact order today while still keeping the quality and cycle time assumptions

315
00:24:25,440 --> 00:24:30,800
behind the schedule. Think about a machine component that normally runs on one cell. Machine B may cut

316
00:24:30,800 --> 00:24:36,000
the same material, but maybe it uses a different chuck, needs a fixture that's currently committed elsewhere,

317
00:24:36,000 --> 00:24:41,040
or requires tool offsets that nobody has proven for this product revision. The program might exist,

318
00:24:41,040 --> 00:24:45,360
but it may have been written for a prior revision. It might run the part, but nobody has approved the

319
00:24:45,360 --> 00:24:49,680
part from that machine under the current customer requirement. Technically possible and approved for

320
00:24:49,680 --> 00:24:54,320
production are different states. That distinction feels slow when a customer needs parts, but those

321
00:24:54,320 --> 00:24:59,360
controls exist because the cost of a rushed routing change can appear later, after the work has

322
00:24:59,360 --> 00:25:05,360
consumed time and material. A part may fail inspection, a new setup may create variation that the normal

323
00:25:05,360 --> 00:25:10,160
cell controls well, or the team may produce a batch, only to discover that a customer traceability

324
00:25:10,160 --> 00:25:15,680
rule requires a process record, the alternate route can't provide. Now the urgent order hasn't

325
00:25:15,680 --> 00:25:20,960
recovered anything. It has created rework, scrap, equality hold, and another schedule problem.

326
00:25:20,960 --> 00:25:25,520
The original order still waits, while the expedited job returns to the front of the conversation.

327
00:25:25,520 --> 00:25:29,680
That's not a failure of the alternate machine, but a failure to treat the route as more than a name

328
00:25:29,680 --> 00:25:34,320
in a master data field. Routing flexibility needs evidence. Approve an alternate route has known

329
00:25:34,320 --> 00:25:39,600
tooling, a released program, documented process capability, approved quality checks, known material

330
00:25:39,600 --> 00:25:44,480
handling, and a realistic cycle time. People know how long the setup takes, where the first part goes

331
00:25:44,480 --> 00:25:48,800
for approval, and whether the machine produces the same result at the same rate, or whether the

332
00:25:48,800 --> 00:25:53,760
schedule needs different assumptions. That's usable flexibility. A listed alternate resource may only

333
00:25:53,760 --> 00:25:58,080
be a theoretical option, a reminder that engineering once believed the work could run there.

334
00:25:58,080 --> 00:26:02,320
It might even be correct under normal conditions, but a planner needs to know whether it's ready now,

335
00:26:02,320 --> 00:26:06,720
on this shift for this order, without moving a hidden set of constraints somewhere else.

336
00:26:06,720 --> 00:26:10,960
Material handling often exposes that gap. The alternate machine may sit in another part of the plant,

337
00:26:10,960 --> 00:26:15,760
so the work needs a different trolley, lifting device, staging area, or longer transfer path.

338
00:26:15,760 --> 00:26:20,320
If the product needs controlled handling, that move may need extra checks. None of this sounds dramatic,

339
00:26:20,320 --> 00:26:24,800
but it still changes the actual time from start to finish. Cycle time can change as well.

340
00:26:24,800 --> 00:26:29,440
Machine B might run the part but more slowly, or it may run faster at the cutting operation while

341
00:26:29,440 --> 00:26:34,000
needing a longer setup and more frequent inspection. A planner who substitutes the standard cycle time

342
00:26:34,000 --> 00:26:38,560
from machine A into the new route can produce a neat schedule that falls apart on the shop floor.

343
00:26:38,560 --> 00:26:43,360
Local speed can also create a downstream problem. Suppose the alternate machine releases the

344
00:26:43,360 --> 00:26:48,000
urgent parts earlier than expected. That sounds like progress until those parts arrive at a shared

345
00:26:48,000 --> 00:26:52,320
wash station, inspection bench, or assembly area that already has worked cute against it.

346
00:26:52,320 --> 00:26:57,200
The urgent order has escaped one constraint, and added pressure to the next shared process.

347
00:26:58,320 --> 00:27:02,640
Or consider the opposite case. The alternate route keeps the original CNC machine stable,

348
00:27:02,640 --> 00:27:06,240
but produces parts with a different finish that needs an extra inspection step.

349
00:27:06,240 --> 00:27:10,560
The change protects one work centre and adds work elsewhere, so if nobody models that added step,

350
00:27:10,560 --> 00:27:14,640
the recovery plan only looks better because the schedule stopped counting part of the work.

351
00:27:14,640 --> 00:27:19,120
This is why planners need more than root names and nominal capacity. They need to ask practical

352
00:27:19,120 --> 00:27:24,320
questions. Which tooling moves with the order? Is the program released for this machine and revision?

353
00:27:24,320 --> 00:27:29,440
Does quality accept this process path? Can the work move through the plant safely and on time?

354
00:27:29,440 --> 00:27:34,560
What cycle time should planning use and which shared operation now receives the load?

355
00:27:34,560 --> 00:27:39,600
A good alternate route can save an urgent order. While a week one can turn a late order into a

356
00:27:39,600 --> 00:27:43,680
quality problem, the difference comes from whether the route is proven under the conditions where

357
00:27:43,680 --> 00:27:47,440
the plant wants to use it, not whether a system drop down contains another machine name.

358
00:27:47,440 --> 00:27:52,320
So let's follow the urgent order into the point where all these choices start to concentrate.

359
00:27:52,320 --> 00:27:57,440
The bottleneck. The bottleneck moves. So here's what happens when an urgent order drops in.

360
00:27:57,440 --> 00:28:01,920
At first glance it looks like a machining problem. The planner needs a slot on a CNC machine,

361
00:28:01,920 --> 00:28:05,520
so that machine gets all the attention. But the minute those parts leave machining,

362
00:28:05,520 --> 00:28:09,840
the pressure doesn't just disappear. It moves somewhere else, and that's where things get interesting.

363
00:28:09,840 --> 00:28:14,160
That's how bottlenecks behave. A bottleneck is whatever limits the flow of work during a given

364
00:28:14,160 --> 00:28:19,280
period. It could be a machine, but just as easily an assembly cell, a test bench, an inspection area,

365
00:28:19,280 --> 00:28:24,240
a fixture, or even one person who has to approve a certain process. That resource determines how fast

366
00:28:24,240 --> 00:28:29,360
the whole system can turn available work into finished, shippable product. And it's not a permanent

367
00:28:29,360 --> 00:28:33,600
label stuck to one machine. On a normal week, the constrained point in this plant might sit in

368
00:28:33,600 --> 00:28:38,160
machining. Demand for one product, family fills a CNC cell and work weights in front of it.

369
00:28:38,160 --> 00:28:42,560
Then the urgent order shows up, takes priority at that cell, and the planners find a way to squeeze

370
00:28:42,560 --> 00:28:47,120
its parts through. So far so good. But now those parts arrive earlier, assembly. And assembly has

371
00:28:47,120 --> 00:28:51,280
to drop everything to handle the urgent components while still dealing with its original workload.

372
00:28:51,280 --> 00:28:54,640
The assembly team might complete the urgent order, but everything else starts waiting.

373
00:28:54,640 --> 00:28:59,600
A queue forms in front of assembly. That original machining constraint becomes less visible because

374
00:28:59,600 --> 00:29:04,640
assembly now controls the flow, or the shift could happen at inspection. The urgent order has a strict

375
00:29:04,640 --> 00:29:09,200
release requirement. It needs inspection before packing, and the inspection team gives it priority.

376
00:29:09,200 --> 00:29:14,560
That might protect the customer date, but it pushes several normal jobs into a growing inspection queue.

377
00:29:14,560 --> 00:29:18,960
From a production standpoint, those products are complete, but they aren't released. They can't

378
00:29:18,960 --> 00:29:24,000
ship, cash, space, and customer commitments all sit in the same queue. That's a bottleneck shift in

379
00:29:24,000 --> 00:29:28,480
action. The resource that limited flow yesterday may not be the one limiting it today.

380
00:29:28,480 --> 00:29:33,040
An urgent insertion changes the sequence of work, the arrival times at later operations,

381
00:29:33,040 --> 00:29:37,680
and the mix of products moving through the plant. You can't just assume the old constraint still

382
00:29:37,680 --> 00:29:41,760
tells you where to focus. And a utilization report won't give you the full picture either.

383
00:29:41,760 --> 00:29:46,480
A machine can show very high utilization and still not be the reason customer deliveries are late.

384
00:29:46,480 --> 00:29:51,120
Meanwhile, another resource might run at a lower average utilization while holding up every

385
00:29:51,120 --> 00:29:55,680
urgent job because each order needs it near the end of its route. The percentage tells you how

386
00:29:55,680 --> 00:29:59,840
busier resource was. It doesn't tell you which queue is actually controlling delivery dates.

387
00:29:59,840 --> 00:30:04,800
That distinction matters. Imagine inspection runs at a moderate load across the week. On Tuesday afternoon,

388
00:30:04,800 --> 00:30:08,880
four jobs arrive at once because machining and assembly both released work late, and then the

389
00:30:08,880 --> 00:30:14,080
urgent order jumps to the front. Inspection might have spare time on Thursday, but those spare hours

390
00:30:14,080 --> 00:30:18,560
can't help the orders that needed release before Wednesday's carrier collection. Average load hides

391
00:30:18,560 --> 00:30:22,960
timing. You spot a bottleneck when work starts collecting in front of a resource when orders

392
00:30:22,960 --> 00:30:27,760
miss planned handoffs and when people start asking why completed parts aren't moving. Work in process

393
00:30:27,760 --> 00:30:32,160
climbs. Supervisors may shuffle people, reorder jobs, or ask one department to hold finished work

394
00:30:32,160 --> 00:30:35,600
because the next department can't take it. Those are the operational signals the plant might

395
00:30:35,600 --> 00:30:39,520
still produce a decent number of parts that day. Equipment might still report good performance.

396
00:30:39,520 --> 00:30:44,320
Yet customer orders can still become late because the wrong work is waiting in the wrong place

397
00:30:44,320 --> 00:30:48,800
at the wrong time. Throughput is not the same as activity. This is where the theory of constraints

398
00:30:48,800 --> 00:30:53,600
gives planners a practical frame. Find the resource that's currently restricting flow. Protect

399
00:30:53,600 --> 00:30:57,680
its time from avoidable disruption. Make sure it receives ready work with material, tools,

400
00:30:57,680 --> 00:31:02,320
instructions, and people prepared. Then watch the system again because once that resource improves

401
00:31:02,320 --> 00:31:07,040
or the work makes changes the constraint can move. The urgent order can trigger exactly that movement.

402
00:31:07,040 --> 00:31:11,680
If machining used to hold the plant back and the team forces urgent work through machining first,

403
00:31:11,680 --> 00:31:16,320
the next shared step may become the new limit. Assembly inspection and packing don't suddenly

404
00:31:16,320 --> 00:31:20,240
have more room just because machining recovered. The pressure travels downstream with the work,

405
00:31:20,240 --> 00:31:24,400
so your schedule response needs to keep checking where the queue builds. Not just once at the start of

406
00:31:24,400 --> 00:31:29,120
the day and not only after an order misses its date. The planner needs current status from the shop

407
00:31:29,120 --> 00:31:33,440
floor plus a model that follows the route and shows where the next collision will happen. Otherwise,

408
00:31:33,440 --> 00:31:37,280
people keep solving yesterday's constraint while today's orders wait somewhere else and you can't

409
00:31:37,280 --> 00:31:41,920
protect a bottleneck you identified too late. Why OEE doesn't answer the urgent order question?

410
00:31:41,920 --> 00:31:47,760
When a plant starts talking about capacity, somebody will usually bring up OEE,

411
00:31:47,760 --> 00:31:52,800
overall equipment effectiveness. That makes sense. OEE measures how well equipment performs through

412
00:31:52,800 --> 00:31:58,400
three angles. Availability, performance, and quality. Availability asks whether the machine was ready

413
00:31:58,400 --> 00:32:02,960
to run when it should have run. Performance compares actual running speed with the expected speed.

414
00:32:02,960 --> 00:32:07,440
Quality looks at how much output met the standard without scrap or rework. Put those together

415
00:32:07,440 --> 00:32:11,920
and you get a useful view of how an asset performed over a given period. For equipment teams,

416
00:32:11,920 --> 00:32:17,040
that view can be genuinely helpful. If a CNC machine loses hours to unplanned stops, OEE can

417
00:32:17,040 --> 00:32:21,600
expose that loss. If the machine runs slower than its expected cycle time, the measure can start a

418
00:32:21,600 --> 00:32:26,960
useful investigation. If scrap rises after a tool change or a process adjustment, quality loss

419
00:32:26,960 --> 00:32:32,160
becomes visible in the same conversation, but OEE answers an equipment question. An urgent order

420
00:32:32,160 --> 00:32:37,440
creates an order question. A machine can report strong OEE while customer orders still miss their

421
00:32:37,440 --> 00:32:42,400
promised dates. In fact, a plant can run equipment efficiently all week and still send late shipments

422
00:32:42,400 --> 00:32:46,880
because the work that needs to move first can't get through the full production route at the right

423
00:32:46,880 --> 00:32:52,080
time. Think about a machine producing good parts at the expected rate. Its availability looks good.

424
00:32:52,080 --> 00:32:57,520
The operator runs it well, scrap stays low. The OEE report looks healthy. Yet the urgent order may

425
00:32:57,520 --> 00:33:03,360
still wait. Its material hasn't cleared inspection. Its first operation depends on a different resource.

426
00:33:03,360 --> 00:33:08,080
Or the machine is busy producing parts for work that doesn't support the urgent customer date.

427
00:33:08,080 --> 00:33:13,280
The asset performs well. The order remains at risk. OEE doesn't know the commercial meaning of a work

428
00:33:13,280 --> 00:33:18,080
order unless you connect that information to the equipment data. It doesn't know that one batch

429
00:33:18,080 --> 00:33:23,120
supports a customer with a line stop risk while another batch supports a delivery due next month.

430
00:33:23,120 --> 00:33:27,840
It doesn't know that a part completed at this machine still needs assembly, final inspection

431
00:33:27,840 --> 00:33:32,800
and packing before it becomes shipable. That context sits outside the OEE calculation. The measure

432
00:33:32,800 --> 00:33:36,880
also can't tell you which operation should run next. It can show that a machine has been productive.

433
00:33:36,880 --> 00:33:40,480
It can't decide whether you should interrupt the current sequence for the urgent job,

434
00:33:40,480 --> 00:33:44,800
keep running to reduce changeovers or reserve the next slot for an order that protects several

435
00:33:44,800 --> 00:33:50,160
downstream assemblies. Those decisions need order priorities, routing links, material status,

436
00:33:50,160 --> 00:33:55,280
labor availability and due date exposure. OEE contains none of those on its own. This doesn't

437
00:33:55,280 --> 00:33:59,360
make OEE less useful. It just means you need to put it in the right part of the decision.

438
00:33:59,360 --> 00:34:04,080
If a machine has a history of reduced availability or if current machine events show it's down,

439
00:34:04,080 --> 00:34:08,400
that information should affect the capacity assumption in your schedule. Don't book eight

440
00:34:08,400 --> 00:34:12,800
productive hours on a resource that only delivers five usable hours under current conditions.

441
00:34:12,800 --> 00:34:16,880
That's a sensible use of OEE related data. You can use equipment performance to improve

442
00:34:16,880 --> 00:34:21,840
standard times, expose loss patterns and test whether a schedule relies on capacity, the plant rarely

443
00:34:21,840 --> 00:34:26,480
achieves. The scheduler can then work with a more honest view of what each resource can deliver,

444
00:34:26,480 --> 00:34:31,280
but the schedule still needs to decide which order uses that capacity in what sequence

445
00:34:31,280 --> 00:34:36,000
and with what consequence for every other order. OEE doesn't perform that work. Another OEE dashboard

446
00:34:36,000 --> 00:34:40,320
won't produce a feasible recovery plan. It may tell you that the machine ran at a high rate

447
00:34:40,320 --> 00:34:44,640
while the planner tries to explain why three customer dates moved anyway. Both statements can be

448
00:34:44,640 --> 00:34:49,440
true and neither cancels the other. The distinction is simple, asset performance tells you what a resource

449
00:34:49,440 --> 00:34:54,880
delivered. Scheduling needs to decide how limited resource time should support customer commitments.

450
00:34:54,880 --> 00:34:59,840
One view helps estimate capacity. The other manages the consequences of using it, so planners need

451
00:34:59,840 --> 00:35:05,760
order context, not just asset performance data. The second order effects. Here's the problem most

452
00:35:05,760 --> 00:35:11,200
manufacturers don't talk about. The first order effect is easy to spot. An urgent order moves ahead in

453
00:35:11,200 --> 00:35:16,000
the queue. Someone changes its priority, reserves a machine slot, releases material and tells the next

454
00:35:16,000 --> 00:35:20,560
department to expect it. On a local schedule that can look like a clean recovery, the urgent job is

455
00:35:20,560 --> 00:35:25,280
moving and people can point to that as progress. But the second order effect sits right behind that

456
00:35:25,280 --> 00:35:29,840
first move and that's where the real damage starts. Other orders lose the path they were supposed

457
00:35:29,840 --> 00:35:34,880
to take through the plant, though not always their entire path at once. Sometimes they lose

458
00:35:34,880 --> 00:35:39,840
one operation, one fixture, one inspection slot or one material allocation. A production order relies

459
00:35:39,840 --> 00:35:44,960
on those things arriving together at the right time. Take an assembly order that needs four components,

460
00:35:44,960 --> 00:35:49,200
three show up on time, but the fourth belong to an order that lost its machining slot when the

461
00:35:49,200 --> 00:35:53,680
urgent job entered the plan. Assembly cannot complete the kit. Now the line builds what it can,

462
00:35:53,680 --> 00:35:58,000
stages incomplete work and moves on to another order. That response keeps people busy,

463
00:35:58,000 --> 00:36:02,320
but the customer order still waits for one missing part. At this point, the delay is no longer just

464
00:36:02,320 --> 00:36:07,520
a scheduling change. The plant holds work in process and material sits in partial assemblies.

465
00:36:07,520 --> 00:36:11,760
The team may need to handle the same work twice. Planning starts looking for a way to expedite the

466
00:36:11,760 --> 00:36:16,400
missing component while customer service asks whether a partial shipment could help. None of that

467
00:36:16,400 --> 00:36:21,520
appeared in the original request to fit in the urgent order. That's a third order effect. A late

468
00:36:21,520 --> 00:36:26,640
component creates an incomplete kit which creates extra handling and a possible partial shipment.

469
00:36:26,640 --> 00:36:31,680
That partial shipment brings extra packing, documents, transport decisions and a customer conversation.

470
00:36:31,680 --> 00:36:36,160
If the missing part needs special approval, the order may wait even after production catches up.

471
00:36:36,160 --> 00:36:40,480
The disruption spreads through dependencies. A dependency is simply a link where one thing cannot

472
00:36:40,480 --> 00:36:44,960
proceed without another. A product depends on its components. A routing operation depends on the

473
00:36:44,960 --> 00:36:50,800
prior operation finishing. A work center depends on the right tool, fixture, material and person.

474
00:36:50,800 --> 00:36:54,720
A shipment depends on the finished order reaching packing with its required documents.

475
00:36:54,720 --> 00:37:00,000
Each link can carry a delay forward. This is why work centers can look independent when they aren't.

476
00:37:00,000 --> 00:37:03,760
Machining may appear separate from assembly and assembly separate from inspection,

477
00:37:03,760 --> 00:37:08,560
yet they share physical resources and timing. A fixture can only support one job at a time.

478
00:37:08,560 --> 00:37:13,280
A gauge may need calibration before a specific inspection. A scarce material lot may only

479
00:37:13,280 --> 00:37:18,080
suit one product version. A tool setter may move between cells. Those shared resources create hidden

480
00:37:18,080 --> 00:37:22,400
coupling. Picture two orders with different product numbers and different routes. They may never

481
00:37:22,400 --> 00:37:26,480
touch the same CNC machine but both need the same special fixture before their first operation

482
00:37:26,480 --> 00:37:30,960
or the same inspection equipment before release. Move one job forward and the other job may wait

483
00:37:30,960 --> 00:37:35,760
without anybody seeing the connection in a simple work center load report. The recovery in one area

484
00:37:35,760 --> 00:37:40,080
can become a disruption somewhere else. A supervisor protects the urgent order by moving a fixture to

485
00:37:40,080 --> 00:37:44,880
another cell. That gets the urgent work started. The original cell then cannot run its next plant

486
00:37:44,880 --> 00:37:49,280
job so it switches to something else. Later the fixture returns but the original job has missed

487
00:37:49,280 --> 00:37:53,680
its plant handoff and now joins a queue at the next operation. Nobody made a bad decision.

488
00:37:53,680 --> 00:37:58,240
Each person responded to the pressure in front of them. The problem comes from seeing those decisions

489
00:37:58,240 --> 00:38:03,040
as separate when the factory experiences them as one connected system. Shared inspection

490
00:38:03,040 --> 00:38:07,680
equipment creates another common example. The urgent order reaches final inspection and needs a

491
00:38:07,680 --> 00:38:12,640
test rig. Inspection gives it priority because the ship date is close so a normal order misses its

492
00:38:12,640 --> 00:38:16,800
release. That normal order may support a larger assembly at the customer or it may need a

493
00:38:16,800 --> 00:38:20,800
carrier pickup that only runs on certain days. The inspection team protected one promise and

494
00:38:20,800 --> 00:38:25,600
exposed another. This is not a reason to never prioritize work. It's a reason to make the trade visible.

495
00:38:25,600 --> 00:38:30,800
If the urgent customer faces a real line stop that order may deserve the test rig but somebody

496
00:38:30,800 --> 00:38:34,800
should know which confirmed order lost its release, how far its date moved and who owns the

497
00:38:34,800 --> 00:38:39,440
customer conversation that follows. The same pattern appears with scarce material. Pull a controlled

498
00:38:39,440 --> 00:38:43,760
lot, a special coating, or a purchased component from one work order to support the urgent job and

499
00:38:43,760 --> 00:38:48,320
the first job may keep moving. The order that lost the material now waits. Its downstream operations

500
00:38:48,320 --> 00:38:52,640
may continue with other parts but sooner or later the missing item blocks completion. A factory

501
00:38:52,640 --> 00:38:57,920
does not run as isolated departments. It runs through product links, process links, and resource

502
00:38:57,920 --> 00:39:02,320
links. An urgent order changes all three. The visible move is the order at the front of the queue.

503
00:39:02,320 --> 00:39:07,040
The hidden moves are the jobs that lose access to the route, tools, material, and release capacity

504
00:39:07,040 --> 00:39:11,760
they expected. By the time customer service asks for an update, the original ERP dates may no

505
00:39:11,760 --> 00:39:16,720
longer describe anything useful. Delivery dates now need recalculation, not reassurance.

506
00:39:16,720 --> 00:39:22,080
When delivery dates start to cascade. Once the urgent order takes a place in the schedule,

507
00:39:22,080 --> 00:39:26,960
every displaced order needs a new feasible completion date, not a copied date from the ERP record,

508
00:39:26,960 --> 00:39:30,960
but a date that follows the work through the remaining operations based on when each operation

509
00:39:30,960 --> 00:39:36,880
can actually begin. That sounds like a small distinction, it isn't. A customer due date may mean

510
00:39:36,880 --> 00:39:40,880
the day the customer needs the goods. An internal due date tells production when the order should

511
00:39:40,880 --> 00:39:45,440
finish to protect that customer date. The promised chip date may sit somewhere between those two,

512
00:39:45,440 --> 00:39:49,440
then you have the carrier cutoff, which decides whether a finished order actually leaves the

513
00:39:49,440 --> 00:39:53,760
side that day. Those dates can all differ. Suppose a customer needs the order on Friday morning,

514
00:39:53,760 --> 00:39:57,840
your plant may need to ship on Thursday afternoon, packing may need the finished goods by midday

515
00:39:57,840 --> 00:40:02,000
for labels, documents, loading, and collection. Production may need to complete final

516
00:40:02,000 --> 00:40:06,880
inspection even earlier, so if a displaced order loses time at machining, the risk doesn't begin

517
00:40:06,880 --> 00:40:11,200
on Friday, it begins when the order misses its inspection window on Thursday morning or when

518
00:40:11,200 --> 00:40:15,760
it can't reach packing before the carrier closes its collection list. That's why a revised completion

519
00:40:15,760 --> 00:40:19,760
time alone isn't enough. The planner needs to calculate the remaining path. When can machining

520
00:40:19,760 --> 00:40:23,760
now finish? When will the components reach assembly? Can assembly complete the order before

521
00:40:23,760 --> 00:40:27,760
inspection needs it? Does inspection have a real slot? And once the product is released,

522
00:40:27,760 --> 00:40:31,680
can packing and dispatch still meet the shipment cutoff? Each answer moves the next answer.

523
00:40:31,680 --> 00:40:35,600
Cascading lateness happens when a delay changes the readiness of work that depends on it.

524
00:40:35,600 --> 00:40:40,080
The first order slips. A later operation then loses its expected input, that operation either

525
00:40:40,080 --> 00:40:44,880
waits or takes other work that is ready. The delayed order arrives later and meets a new queue.

526
00:40:44,880 --> 00:40:49,760
The date keeps moving because the route keeps reacting, take an assembly order that needs a late

527
00:40:49,760 --> 00:40:54,400
machine component. The assembly line may have open time people may be ready, and the work instructions

528
00:40:54,400 --> 00:40:58,800
may be released. None of that completes the order if one required part hasn't arrived. The open

529
00:40:58,800 --> 00:41:03,280
assembly time doesn't travel backward and produce the missing component. Instead the line uses the

530
00:41:03,280 --> 00:41:08,320
time for other work or the team begins partial assembly if the process permits it. When the missing

531
00:41:08,320 --> 00:41:13,040
component finally arrives, the original order needs a new assembly slot, a new material issue,

532
00:41:13,040 --> 00:41:17,760
a new check, and it now competes with orders that were already waiting. A visible gap in one

533
00:41:17,760 --> 00:41:22,160
department doesn't prove the order can recover. This catches people out because capacity is often

534
00:41:22,160 --> 00:41:26,480
viewed by area. The assembly shows free time, inspection shows a late slot, and packing has room

535
00:41:26,480 --> 00:41:31,520
tomorrow morning. But the order can only use those slots if its prior work reaches each stage in

536
00:41:31,520 --> 00:41:36,160
the right sequence. An order moves through time as well as through departments. The urgent order

537
00:41:36,160 --> 00:41:40,800
can also create a delayed date that looks technically acceptable but commercially useless. Imagine the

538
00:41:40,800 --> 00:41:45,040
displaced order finishes on the same day as its original customer due date. The schedule might show

539
00:41:45,040 --> 00:41:50,000
zero days late, yet if the carrier left several hours earlier, the customer receives the goods a day

540
00:41:50,000 --> 00:41:54,880
later. Production completed the work, but delivery still failed. Customer service needs that level of

541
00:41:54,880 --> 00:41:59,120
detail when they speak to the customer. They don't need a date copied from a planning field that nobody

542
00:41:59,120 --> 00:42:04,160
has checked since the urgent order arrived. They need to know what changed, how confident the plant is in

543
00:42:04,160 --> 00:42:09,280
the revised date, and what assumptions still carry risk. Confidence matters because schedules work

544
00:42:09,280 --> 00:42:14,160
with uncertain inputs. A material receipt may still wait for confirmation a machine may be running

545
00:42:14,160 --> 00:42:18,800
behind plan, or an inspection release may depend on a test result. In those cases the best answer

546
00:42:18,800 --> 00:42:24,160
may not be it will ship Thursday. A more honest answer could be Thursday is feasible if the material

547
00:42:24,160 --> 00:42:29,040
clears incoming inspection by Tuesday afternoon. If it doesn't, Friday becomes the earliest realistic

548
00:42:29,040 --> 00:42:33,440
ship date. That gives customer service something useful. They can explain the position clearly,

549
00:42:33,440 --> 00:42:38,000
ask whether a partial shipment helps, and decide when to alert the account team. Most of all,

550
00:42:38,000 --> 00:42:42,560
they stop passing on a promise that the plant has already lost confidence in. This is not about

551
00:42:42,560 --> 00:42:46,720
giving customers excuses, it's about stopping the organization from treating dates as fixed after

552
00:42:46,720 --> 00:42:50,640
the conditions behind them have changed. A feasible date should move when the route, material,

553
00:42:50,640 --> 00:42:56,400
capacity, or dispatch path changes. Otherwise, the date becomes a wish with a customer name attached.

554
00:42:56,400 --> 00:43:01,200
Most plants discover all of this through manual effort first. Excel becomes the emergency control room.

555
00:43:02,480 --> 00:43:07,440
Here's the problem most manufacturers don't talk about. A planner sits down with Excel because the other

556
00:43:07,440 --> 00:43:12,000
systems won't talk to each other. They pull open orders from ERP, check the MES for actual operation

557
00:43:12,000 --> 00:43:15,840
status, call the machining supervisor to find out what's really on the machine instead of what

558
00:43:15,840 --> 00:43:21,040
the schedule thinks, then call assembly and receiving about that expedited material. It might start as

559
00:43:21,040 --> 00:43:26,800
a few columns. Order number, customer date, current operation, material status, next constraint,

560
00:43:26,800 --> 00:43:31,600
a revised ship date. Within an hour, that spreadsheet becomes the only place where the chain reaction

561
00:43:31,600 --> 00:43:36,000
makes sense to the person trying to manage it. The planner isn't avoiding the systems or choosing manual

562
00:43:36,000 --> 00:43:40,480
work, each system holds one piece of the puzzle and nobody has connected those pieces well enough

563
00:43:40,480 --> 00:43:45,600
to answer the urgent question in one place. ERP carries the commercial order and its dates,

564
00:43:45,600 --> 00:43:50,240
MES logs execution events though those can arrive late or need confirmation, and the supervisor

565
00:43:50,240 --> 00:43:54,880
knows the machine shown as available is actually tied up with a difficult setup. Purchasing says

566
00:43:54,880 --> 00:43:59,120
the supplier promised a delivery, but receiving says nothing has reached the gate, so the spreadsheet

567
00:43:59,120 --> 00:44:03,920
becomes a working model of the factory for that moment, the only one that reflects reality. The planner

568
00:44:03,920 --> 00:44:09,920
adds notes, no standard reporting clues, material on truck, not received, inspector only available

569
00:44:09,920 --> 00:44:15,760
after lunch. Alternate route needs approval, customer may accept part shipment, those notes carry

570
00:44:15,760 --> 00:44:20,000
the context behind the numbers and without them the schedule sounds far more certain than the plant

571
00:44:20,000 --> 00:44:24,080
actually feels. Here's the thing, Excel is not the problem, plenty of plants still use it because

572
00:44:24,080 --> 00:44:29,040
it's fast, flexible and close to the work. A good planner can test a sequence, sought by risk,

573
00:44:29,040 --> 00:44:33,600
drop in a phone call update and share a clear view with the team in minutes. Excel is one of the most

574
00:44:33,600 --> 00:44:37,600
successful manufacturing tools Microsoft never intended to be a production control system,

575
00:44:37,600 --> 00:44:41,520
the real problem starts when the spreadsheet becomes the only place where the real decision lives.

576
00:44:41,520 --> 00:44:46,320
Sales sees the original promised date in ERP, the planner sees a revised date in their recovery

577
00:44:46,320 --> 00:44:51,600
file and the supervisor follows a printed dispatch list or a whiteboard sequence changed on the

578
00:44:51,600 --> 00:44:56,560
last shift. Each person acts on a date that made sense when they last checked and the dates no

579
00:44:56,560 --> 00:45:01,440
longer agree. Picture customer service calling sales for an update, sales checks ERP and tells the

580
00:45:01,440 --> 00:45:06,480
customer it ships Thursday, but the planner's workbook puts the earliest likely ship date on Friday,

581
00:45:06,480 --> 00:45:11,200
assuming material clears inspection. Meanwhile, the supervisor has moved the urgent job again because

582
00:45:11,200 --> 00:45:15,840
a tool problem interrupted the planned run. Nobody is trying to mislead anyone, they're working from

583
00:45:15,840 --> 00:45:20,960
different versions of a moving situation. The issue isn't effort, the decision path has split across

584
00:45:20,960 --> 00:45:25,760
systems, files, calls and local knowledge and the manual recovery view starts aging the second

585
00:45:25,760 --> 00:45:31,920
it gets saved. A machine can stop after the planner exports MS data, scrap can change the available

586
00:45:31,920 --> 00:45:37,360
quantity for a component, a supplier receipt can arrive, fail inspection or come incomplete,

587
00:45:37,360 --> 00:45:42,640
and an operator might report a setup problem that shifts the next workable slot. Every new event

588
00:45:42,640 --> 00:45:47,200
invalidates part of the spreadsheet and changes delivery risk for several orders, so the planner

589
00:45:47,200 --> 00:45:51,520
exports again, edits again, calls again, sends another file. That cycle works fine for a small

590
00:45:51,520 --> 00:45:55,840
number of exceptions, especially with experienced people who know the planned well, but it breaks down

591
00:45:55,840 --> 00:46:00,400
when urgent orders come off and product routes share scarce resources or several people change the

592
00:46:00,400 --> 00:46:04,640
schedule at the same time. You end up with a recovery plan that lives inside one person's head.

593
00:46:04,640 --> 00:46:08,560
If that person isn't available, nobody can explain it, that's a risky operating model,

594
00:46:08,560 --> 00:46:12,960
spreadsheets aren't the problem. The problem is the factory has outgrown a disconnected view of

595
00:46:12,960 --> 00:46:18,240
its own commitments. The workbook carries links between orders, materials, machine slots and

596
00:46:18,240 --> 00:46:23,600
customer dates that should exist as shared facts, not private knowledge in a file. I wouldn't start

597
00:46:23,600 --> 00:46:27,840
by trying to ban Excel, but that usually just removes a tool before you replace the reason people

598
00:46:27,840 --> 00:46:32,640
needed. Start by asking what the planner has to assemble manually during an urgent order event,

599
00:46:32,640 --> 00:46:38,160
which data comes from ERP, which execution facts come from MES, which constraints only show up

600
00:46:38,160 --> 00:46:42,960
through a supervisor call, and which date becomes the agreed customer date and who owns it.

601
00:46:42,960 --> 00:46:48,240
Those questions expose the gap. The deeper issue isn't missing data, it's missing relationships.

602
00:46:48,240 --> 00:46:54,560
Data tells you what exists, context tells you what breaks. A machine status says machine 12 is running,

603
00:46:54,560 --> 00:46:59,200
a work order says order 7-H4 is due this week, inventory shows 80 units in stock,

604
00:46:59,200 --> 00:47:03,680
and the labor roster tells you who's assigned to the next shift. Those are useful facts,

605
00:47:03,680 --> 00:47:07,680
but on their own they don't explain the urgent order decision. None of those records tells you

606
00:47:07,680 --> 00:47:12,800
where the machine 12 runs an operation for order 7-H4, whether those 80 units are allocated to that order,

607
00:47:13,120 --> 00:47:17,120
or whether the person on the next shift has the approval needed to run that product.

608
00:47:17,120 --> 00:47:20,880
The facts exist, but their links sit in different places or inside people's heads,

609
00:47:20,880 --> 00:47:23,600
and that's exactly the gap that makes urgent orders difficult.

610
00:47:23,600 --> 00:47:26,960
Context connects a customer promise to the route required to fulfill it,

611
00:47:26,960 --> 00:47:31,040
linking each operation to the one before it, and each operation to the machine, tools,

612
00:47:31,040 --> 00:47:35,920
material, and qualified people it needs. It also connects a stock quantity to the work order

613
00:47:35,920 --> 00:47:40,320
that expects to consume it. Without those links, you can ask, do we have capacity?

614
00:47:40,320 --> 00:47:44,240
With those links, you can ask if we put this urgent order ahead of the current job,

615
00:47:44,240 --> 00:47:47,600
which confirmed orders lose a feasible path to their promised chip date.

616
00:47:47,600 --> 00:47:52,240
That's a much better question. Here's the architecture view, simplified. Think of a factory

617
00:47:52,240 --> 00:47:56,640
fact as a noun, a machine, an order, a material lot, an operator, a customer date,

618
00:47:56,640 --> 00:48:01,280
and context as the verb between them. This operation runs on this machine, this material lot

619
00:48:01,280 --> 00:48:05,920
supports this work order. This operator can approve this inspection. This work order supports

620
00:48:05,920 --> 00:48:10,080
this customer commitment. The plant runs through those relationships. A knowledge graph gives you

621
00:48:10,080 --> 00:48:15,120
one way to model them. In plain terms, it's a map of linked factory facts. Instead of storing

622
00:48:15,120 --> 00:48:20,480
machine 12 order 784 and a stock record as isolated rows that only meet inside the report,

623
00:48:20,480 --> 00:48:24,240
the model records how they relate and let's the system follow those links.

624
00:48:24,240 --> 00:48:28,480
You don't need to treat this as a mysterious AI concept, picture maintenance event that takes

625
00:48:28,480 --> 00:48:33,200
machine 12 out of service. The graph can follow from that machine to the operations plan there,

626
00:48:33,200 --> 00:48:37,120
then to the work orders waiting for those operations. From each work order, it can follow

627
00:48:37,120 --> 00:48:42,000
to require tools, allocated material, qualified operators, downstream operations, and the delivery

628
00:48:42,000 --> 00:48:46,560
dates attached to the customer order. That's how a machine outage becomes a list of consequences

629
00:48:46,560 --> 00:48:50,720
rather than a red status light. The system might identify an urgent order that can't start because

630
00:48:50,720 --> 00:48:55,280
its fixture is still on the stock machine. Another order could move to a qualified alternate resource,

631
00:48:55,280 --> 00:49:00,160
but only if a specific operator works that shift. A third order has no alternate route and now threatens

632
00:49:00,160 --> 00:49:05,040
a carrier cut off. Each answer comes from connected facts. A rules engine uses those links to

633
00:49:05,040 --> 00:49:10,000
apply defined policies. For example, it can flag every customer commitment exposed by a resource

634
00:49:10,000 --> 00:49:14,640
outage or block a material reassignment when it creates a shortage on another confirmed order.

635
00:49:14,640 --> 00:49:20,000
Those rules are only as good as the context they can inspect, and AI has the same requirement.

636
00:49:20,000 --> 00:49:24,640
You can ask an AI assistant to explain schedule risk, summarize the orders affected, or prepare a

637
00:49:24,640 --> 00:49:28,960
draft update for customer service. But if it only receives an order list and a machine alarm,

638
00:49:28,960 --> 00:49:34,000
it can produce fluent language around incomplete information. It cannot reliably reason about

639
00:49:34,000 --> 00:49:38,800
the impact because it doesn't know the root dependencies allocation rules or qualifications behind

640
00:49:38,800 --> 00:49:44,000
the records. Fluent isn't the same as informed. The same goes for available to promise logic. It sounds

641
00:49:44,000 --> 00:49:48,880
simple. Can we commit a quantity to a customer on a given date? But the answer depends on the quality

642
00:49:48,880 --> 00:49:53,520
of the assumptions underneath. Does the inventory count include stock reserved for another customer?

643
00:49:53,520 --> 00:49:57,840
Does the purchase receipt date still hold? Does the bill match the current revision? Does the

644
00:49:57,840 --> 00:50:02,960
root use real cycle times and capacity? Can the plant actually complete, inspect, pack, and shift

645
00:50:02,960 --> 00:50:07,520
before the promise date? If those assumptions drift, available to promise becomes available to hope,

646
00:50:07,520 --> 00:50:12,320
that doesn't mean ERPS failed. It gives you the commercial rules, demand signal, supply records,

647
00:50:12,320 --> 00:50:17,520
and master data that any serious promise process needs. The work is to keep those facts governed,

648
00:50:17,520 --> 00:50:22,800
then combine them with what production knows right now. Ownership helps. Commercial rules,

649
00:50:22,800 --> 00:50:27,760
customer commitments, product definitions, purchasing records, and inventory policy belong in the ERP

650
00:50:27,760 --> 00:50:33,520
domain, while execution status, production completions, scrap, holds, and actual operation events belong

651
00:50:33,520 --> 00:50:39,280
in the MES domain. Neither system owns the full feasibility decision on its own. That decision

652
00:50:39,280 --> 00:50:44,640
crosses both. A feasible, urgent order response needs the business commitment from ERP and the

653
00:50:44,640 --> 00:50:49,680
current production truth from MES, then a model that connects product, process, resources,

654
00:50:49,680 --> 00:50:55,120
material, and dates without quietly changing the meaning of any of them. Once those sources connect,

655
00:50:55,120 --> 00:50:59,280
a data platform can help, but it can't invent meaning the organization has never defined.

656
00:50:59,280 --> 00:51:05,600
Microsoft fabric as the shared data layer. So here's the reality. When your ERP and MES data

657
00:51:05,600 --> 00:51:10,400
need to talk to each other, Microsoft fabric can give you that shared data layer that ties orders,

658
00:51:10,400 --> 00:51:15,040
events, machine signals, planning, and supply info together. But it's not about dumping everything

659
00:51:15,040 --> 00:51:19,760
into one big store and hoping the answers pop out. You're creating a governed space where data gets

660
00:51:19,760 --> 00:51:24,560
prepped, linked, and used under consistent rules, and that takes discipline. You'll need separate

661
00:51:24,560 --> 00:51:30,000
pipelines for ERP order changes, MES events, and maybe a third for machine signals or quality results.

662
00:51:30,000 --> 00:51:35,120
Each one has to know exactly what it's moving, how often, what happens when a source record changes,

663
00:51:35,120 --> 00:51:39,360
and who owns the meaning of that data. If you skip that, you're just centralizing confusion.

664
00:51:39,360 --> 00:51:44,320
A lakehouse pattern handles both raw operational history and prepared data the planners can trust.

665
00:51:44,320 --> 00:51:49,280
So you keep the source event as received, and then build a prepared view linking each operation

666
00:51:49,280 --> 00:51:55,200
completion to the correct work order, product revision, resource, and time. That separation

667
00:51:55,200 --> 00:52:00,240
matters because source data inevitably brings gaps, duplicates, late updates, and naming differences

668
00:52:00,240 --> 00:52:05,520
across systems. Take a typical scenario. A machine has an internal asset code, MES calls it a

669
00:52:05,520 --> 00:52:10,080
work center name, and ERP uses a cost center code. If those names don't map to the same physical

670
00:52:10,080 --> 00:52:14,560
resource, the shared layer can tell a very convincing story about the wrong machine. That's a problem

671
00:52:14,560 --> 00:52:19,600
when you're making urgent order decisions. You can't afford that ambiguity. Event identity needs

672
00:52:19,600 --> 00:52:23,760
the same care. When MES sends an operation completion, can you tell if it's a new completion

673
00:52:23,760 --> 00:52:28,080
or correction or retry from the interface? When quality releases a batch, does that release

674
00:52:28,080 --> 00:52:32,400
apply to the full quantity or just part of it? The decision model needs a clear answer before

675
00:52:32,400 --> 00:52:37,200
treating that event as available capacity or material. Time handling brings its own headaches,

676
00:52:37,200 --> 00:52:42,240
because ERP stores a planned finish date with no time. MES logs events down to the second,

677
00:52:42,240 --> 00:52:46,320
and machine data arrives in a different time zone all on top of shift boundaries that ignore

678
00:52:46,320 --> 00:52:52,000
calendar days. If your data model treats all those as the same type of time, a report could show work

679
00:52:52,000 --> 00:52:56,640
as available before it actually is. Now here's where it gets interesting. Fabric can help you prepare

680
00:52:56,640 --> 00:53:01,200
and govern that data, but it can't decide what a completion means in your plant. Keep that boundary

681
00:53:01,200 --> 00:53:07,120
clear. Microsoft Fabric connects, stores, transforms, manages access, and supports analysis.

682
00:53:07,120 --> 00:53:11,680
It provides the shared foundation for decision making. But dropping production data into a

683
00:53:11,680 --> 00:53:16,480
lake house doesn't turn Fabric into a finite capacity scheduler. Scheduling needs its own logic,

684
00:53:16,480 --> 00:53:21,920
operation sequences, machine calendars, setup rules, labor skills, material readiness, maintenance,

685
00:53:21,920 --> 00:53:26,480
and the policies that decide which order goes first. In some plants that logic lives in a dedicated

686
00:53:26,480 --> 00:53:31,600
system, in others it's a custom service or a mix. Fabric can supply trusted inputs and retain

687
00:53:31,600 --> 00:53:35,840
the results. It shouldn't quietly pretend to solve a constraint problem it wasn't designed for.

688
00:53:35,840 --> 00:53:39,920
The same goes for power BI semantic models. They give everyone shared definitions.

689
00:53:39,920 --> 00:53:45,280
So order means the same thing to sales, planning, quality, and customer service. You need

690
00:53:45,280 --> 00:53:50,800
agreed rules for late order, material available, operation complete, and promised ship date.

691
00:53:50,800 --> 00:53:56,000
Without those, your report might look clean, but teams will still argue about the numbers.

692
00:53:56,000 --> 00:54:01,360
As a Microsoft MVP, I work with Fabric, Azure, and Power BI architectures every day. The technology

693
00:54:01,360 --> 00:54:05,920
can support serious manufacturing decisions. But the real work starts after the connector succeeds.

694
00:54:05,920 --> 00:54:10,000
You still need to define identities, dates, ownership, and the rules behind each status.

695
00:54:10,000 --> 00:54:13,840
That's where architecture that actually scales starts. It's not about another report.

696
00:54:13,840 --> 00:54:17,920
It's about business definitions, stable enough that a planner can ask a hard question.

697
00:54:17,920 --> 00:54:21,360
Sales understands the answer, and the plant acts on the same facts.

698
00:54:21,360 --> 00:54:26,160
Reporting becomes useful when the model can actually answer operational questions.

699
00:54:26,160 --> 00:54:27,840
From dashboard to decision models and

700
00:54:27,840 --> 00:54:33,120
once your data has shared definitions, power BI gives you a much clearer operational view.

701
00:54:33,840 --> 00:54:38,640
Current load at a work center orders at risk, material running late, cues building up.

702
00:54:38,640 --> 00:54:43,280
For sales, planning, production, and customer service, that shared view stops a lot of debate

703
00:54:43,280 --> 00:54:46,880
because they're no longer working from different extracts and personal assumptions.

704
00:54:46,880 --> 00:54:52,240
That alone changes the urgent order conversation. Picture a planner getting a new priority order.

705
00:54:52,240 --> 00:54:56,160
The Power BI view shows the work center it needs, the hours already booked,

706
00:54:56,160 --> 00:55:00,320
the jobs waiting, and material status for each. It can also show that the urgent order

707
00:55:00,320 --> 00:55:04,720
has stock ready, while two confirmed orders behind it depend on the same constrained resource.

708
00:55:04,720 --> 00:55:08,160
Now everyone sees the pressure before anyone starts moving work.

709
00:55:08,160 --> 00:55:12,240
A report can also highlight where a delivery date is losing credibility by combining the

710
00:55:12,240 --> 00:55:17,120
planned end of an operation with its actual status, comparing the remaining route to the internal

711
00:55:17,120 --> 00:55:21,360
ship target, and putting material that hasn't cleared inspection next to the orders meeting it.

712
00:55:21,360 --> 00:55:25,600
A late purchase receipt appears beside the work at will delay, that gives teams real-time

713
00:55:25,600 --> 00:55:30,160
visibility, or at least as current as the source events allow, but a dashboard only describes the

714
00:55:30,160 --> 00:55:35,200
situation. It doesn't pick a response. This matters because a clean report can create false confidence.

715
00:55:35,200 --> 00:55:39,600
Someone sees a red-laid order count, clicks into affected orders, and assumes they understand the

716
00:55:39,600 --> 00:55:43,760
recovery plan, they understand the current problem, but they still don't know which schedule change

717
00:55:43,760 --> 00:55:47,760
produces the least damaging result. Those are different questions. A dashboard can answer which

718
00:55:47,760 --> 00:55:53,040
work center has the most load, but a planner needs to ask, if I place this urgent operation ahead of

719
00:55:53,040 --> 00:55:58,480
the queue, which orders move, and when does each finish? That question needs sequence, capacity,

720
00:55:58,480 --> 00:56:03,360
route dependencies, calendars, and work rules. A report alone can't test those conditions.

721
00:56:03,360 --> 00:56:08,000
Underneath that reporting layer sits the semantic model, and it matters more than most people realize.

722
00:56:08,000 --> 00:56:12,720
In plain terms, it's the shared set of definitions that tells every report and app what an order,

723
00:56:12,720 --> 00:56:18,560
operation, resource, inventory, and date actually mean. If sales calls an order on time because

724
00:56:18,560 --> 00:56:23,440
it hasn't passed the customer due date, but production calls it late. Because it missed the internal

725
00:56:23,440 --> 00:56:27,920
finish point, you don't have a reporting issue, you have two business definitions fighting over the same

726
00:56:27,920 --> 00:56:32,960
word. The semantic model should make that difference explicit. This model can distinguish a customer

727
00:56:32,960 --> 00:56:37,280
request date from a confirmed ship date, separate physical stock from allocatable stock, and define

728
00:56:37,280 --> 00:56:42,240
an operation state, planned, released, started, complete, or quality released, rather than lumping

729
00:56:42,240 --> 00:56:46,880
them all together. Those definitions let people ask better questions. For an urgent order,

730
00:56:46,880 --> 00:56:51,840
asking, "Do we have free capacity this week?" is too broad. Free capacity on Wednesday doesn't help

731
00:56:51,840 --> 00:56:56,240
if the order needs set up on Tuesday, material release before that, and inspection before

732
00:56:56,240 --> 00:57:00,880
carrier collection on Thursday. Instead, ask, "Which confirmed orders get delayed if this work

733
00:57:00,880 --> 00:57:06,320
centre takes the urgent job?" Then the system has to trace the impact through the actual schedule.

734
00:57:06,320 --> 00:57:10,480
Identify the displaced operation, follow the remaining steps, check for new constraints,

735
00:57:10,480 --> 00:57:14,720
and calculate revised finish and ship dates. That's decision work. Clearly presented results in

736
00:57:14,720 --> 00:57:20,160
Power BI can help a commercial manager compare affected commitments. See the risk of each option,

737
00:57:20,160 --> 00:57:24,800
and understand why a trade is recommended. It can also give a supervisor a focused view of jobs

738
00:57:24,800 --> 00:57:29,040
needing action on the next shift, but the report shouldn't pretend it's created a feasible schedule

739
00:57:29,040 --> 00:57:33,280
just because it looks tidy. A schedule becomes feasible only when the proposed sequence respects

740
00:57:33,280 --> 00:57:38,000
real resource time, operation dependencies, material state, and the plant's working rules.

741
00:57:38,000 --> 00:57:42,480
A visual might show a machine looking likely loaded, but it can't prove the urgent job fits

742
00:57:42,480 --> 00:57:47,200
between a maintenance window, a tool change, and the next operation without running the logic to

743
00:57:47,200 --> 00:57:51,600
test it. That distinction protects you from dashboard theatre, everyone sees the same problem in

744
00:57:51,600 --> 00:57:57,120
high definition, but nobody can tell the plant what to do next. The next layer tests those choices

745
00:57:57,120 --> 00:58:02,320
before the plant commits to them. Simulation before you move the worker. Before you touch the

746
00:58:02,320 --> 00:58:06,480
live schedule, you need a place to test the change, and that's what simulation does. It builds a safe

747
00:58:06,480 --> 00:58:10,480
model using the real constraints the plant works with every day, then lets planning compare options

748
00:58:10,480 --> 00:58:14,960
before a supervisor starts stopping jobs, moving tools, or calling people in for overtime.

749
00:58:14,960 --> 00:58:20,080
Think about that urgent order from the plant's perspective. The customer needs a fixed quantity

750
00:58:20,080 --> 00:58:24,640
by a fixed date, and the work has to go through machining, assembly, inspection, and packing.

751
00:58:24,640 --> 00:58:28,800
Your first instinct might be to jam it at the front of the queue, but simulation lets you ask what

752
00:58:28,800 --> 00:58:33,040
that decision actually does to every other order already competing for the same capacity.

753
00:58:33,040 --> 00:58:37,840
The model needs finite capacity, meaning a machine, person or test station only has the time

754
00:58:37,840 --> 00:58:42,320
that actually exists on its calendar. It can't process two jobs at once just because both carry a

755
00:58:42,320 --> 00:58:47,920
priority flag, and it also needs root rules. An order must follow approved operations in the required

756
00:58:47,920 --> 00:58:53,280
sequence, period. Material readiness matters just as much because a root might look open,

757
00:58:53,280 --> 00:58:58,240
while the parts needed for the first operation are still stuck at a supplier. Labor skills count

758
00:58:58,240 --> 00:59:03,680
two. A machine slot without a qualified operator isn't a workable slot. Calendar limits catch people

759
00:59:03,680 --> 00:59:08,880
off guard. Shifts end. Maintenance windows take equipment out of use, and some approvals only

760
00:59:08,880 --> 00:59:12,720
happen during certain working hours. Those details turn a rough schedule into something you can

761
00:59:12,720 --> 00:59:17,680
actually test. Now compare a few possible responses. You could move the urgent order ahead of existing

762
00:59:17,680 --> 00:59:22,080
work at controlled overtime on the constrained operation, or rooted through an approved alternate

763
00:59:22,080 --> 00:59:26,640
path. You could also split the shipment, sending the quantity the customer needs first, while the

764
00:59:26,640 --> 00:59:31,440
balance follows later. Or you could return a later date, or even decline the promise. That last

765
00:59:31,440 --> 00:59:36,160
option can feel uncomfortable, but it belongs in a serious feasibility process. If accepting the

766
00:59:36,160 --> 00:59:40,720
urgent order breaks several confirmed customer commitments, requires an unsafe work pattern,

767
00:59:40,720 --> 00:59:45,280
or depends on material that can't arrive in time, then yes, isn't automatically the responsible

768
00:59:45,280 --> 00:59:50,560
answer. Simulation gives that conversation evidence instead of gut feel. Take the option of moving

769
00:59:50,560 --> 00:59:54,800
the urgent order forward. The model might show it meets the urgent date, but pushes two existing

770
00:59:54,800 --> 00:59:59,680
orders past their ship cutoffs. Add overtime instead, and the urgent order might fit without moving

771
00:59:59,680 --> 01:00:04,640
those dates while labor cost and fatigue risk go up. Use an alternate route and capacity may open up

772
01:00:04,640 --> 01:00:10,000
the cycle time, quality approval, or rework exposure may shift. Each option moves risk somewhere.

773
01:00:10,000 --> 01:00:14,400
That's the whole point. A simulation doesn't tell you one option is morally correct. It shows the

774
01:00:14,400 --> 01:00:18,560
conditions and consequences attached to each option based on the rules and data you gave it.

775
01:00:18,560 --> 01:00:23,520
It's a model, not a guarantee. A production schedule always meets real world variation.

776
01:00:23,520 --> 01:00:28,560
A supplier misses a delivery, a first off part fails inspection, a machine stops,

777
01:00:28,560 --> 01:00:32,080
or an experienced supervisor spots a problem the model can't represent.

778
01:00:32,080 --> 01:00:36,720
So simulation should support a decision, not create a false sense that the factory has become

779
01:00:36,720 --> 01:00:41,600
predictable. Still, it's far better to test a choice before committing people and material to it,

780
01:00:41,600 --> 01:00:45,680
and the quality of the result depends on the quality of the inputs. If the routing claims

781
01:00:45,680 --> 01:00:49,680
any CNC machine can run apart, but only one has the right fixture and program,

782
01:00:49,680 --> 01:00:54,480
the simulation can create a neat schedule that can't run. If standard cycle times ignore normal

783
01:00:54,480 --> 01:00:59,680
setup work, the plan can look feasible until the first shift tries to execute it. Bad routing

784
01:00:59,680 --> 01:01:05,040
data creates very tidy fiction. The same applies to material status, labor rules, machine calendars,

785
01:01:05,040 --> 01:01:10,160
and quality holds. A model needs production rules that reflect how the plant really operates.

786
01:01:10,160 --> 01:01:14,240
You don't need perfection before you start, but you do need to know which assumptions could change

787
01:01:14,240 --> 01:01:19,440
the decision and which source owns each fact. Then the results become useful in a practical way.

788
01:01:19,440 --> 01:01:24,000
Planning can show sales which customer dates move under each choice. Production can see where the

789
01:01:24,000 --> 01:01:29,360
new queue forms. Finance can see where over time, supplier expedites, extra freight, or additional

790
01:01:29,360 --> 01:01:33,520
handling enters the picture. Customer service can prepare for commitments that need a conversation

791
01:01:33,520 --> 01:01:37,280
before the customer discovers the issue through a lay shipment. That changes the question from,

792
01:01:37,280 --> 01:01:41,920
can we squeeze it in or to which schedule option do we accept and which customer commitments

793
01:01:41,920 --> 01:01:47,200
does that option change? Simulation asks what could happen. Optimization selects among acceptable

794
01:01:47,200 --> 01:01:52,880
choices. Prediction, simulation, and optimization. People often use prediction simulation and

795
01:01:52,880 --> 01:01:57,520
optimization as if they mean the same thing, but they don't. Each one answers a different question.

796
01:01:57,520 --> 01:02:02,000
And mixing them up creates bad expectations very quickly. Prediction estimates what may happen.

797
01:02:02,000 --> 01:02:07,520
For example, a model might estimate a late supplier delivery, detect a machine running over cycle

798
01:02:07,520 --> 01:02:12,800
time after a specific setup, or identify a rising chance that a work order will miss its completion

799
01:02:12,800 --> 01:02:17,920
target. That can help planning act earlier, but a prediction doesn't decide what the plant should do.

800
01:02:17,920 --> 01:02:21,760
It can tell you that material may arrive late, but it can't decide whether you should protect

801
01:02:21,760 --> 01:02:25,840
the urgent order, move another order, approve overtime, or change a customer date.

802
01:02:25,840 --> 01:02:30,560
Simulation comes next, taking a stated option and testing the likely schedule result under the

803
01:02:30,560 --> 01:02:35,200
assumptions in the model. You say put the urgent order first on this machine, and the model follows

804
01:02:35,200 --> 01:02:40,720
the effect through the root, the resource calendars, the available material, and the work already planned.

805
01:02:40,720 --> 01:02:45,680
It answers a practical question. If we choose this option, what does it do? Maybe the urgent order

806
01:02:45,680 --> 01:02:50,240
reaches packing in time, but two other orders move beyond their ship cut off. Maybe the same order

807
01:02:50,240 --> 01:02:54,960
fits if the plant adds a shift on one operation, or maybe neither option works because final

808
01:02:54,960 --> 01:03:00,160
inspection becomes the new constraint. Simulation doesn't search every possible answer for you.

809
01:03:00,160 --> 01:03:05,040
It tests the scenario you choose. Optimization takes a different approach. You give the system a set of

810
01:03:05,040 --> 01:03:10,000
goals and a set of rules, and it searches for a schedule that meets those rules as well as possible,

811
01:03:10,000 --> 01:03:14,400
but it might test many sequence changes, alternate resource choices, and timing options that a planner

812
01:03:14,400 --> 01:03:19,840
would struggle to compare manually under pressure. But optimization needs clear instructions. What are you

813
01:03:19,840 --> 01:03:24,320
trying to optimize? Is the goal to meet the urgent customer dated any cost? To reduce total

814
01:03:24,320 --> 01:03:28,800
lateness across all customers, to avoid over time, to reduce changeovers, to protect revenue,

815
01:03:28,800 --> 01:03:33,280
or to distribute disruption fairly, instead of always pushing the same lower priority customers to

816
01:03:33,280 --> 01:03:38,560
the back. Those goals can collide. A schedule that reduces setup time may keep similar products

817
01:03:38,560 --> 01:03:43,280
together, but delay an urgent order. A schedule that protects the urgent customer may add over time

818
01:03:43,280 --> 01:03:48,160
and move several smaller orders. A schedule that maximizes revenue may not feel fair to a long-term

819
01:03:48,160 --> 01:03:53,280
customer whose order repeatedly gets displaced by larger accounts. The math can search, but it cannot

820
01:03:53,280 --> 01:03:57,520
choose the business policy for you. That policy needs to come from people who understand the commercial

821
01:03:57,520 --> 01:04:02,800
commitment, production risk, customer relationship, and cost of each choice. The scheduler can then

822
01:04:02,800 --> 01:04:08,320
work within those rules, instead of trying to guess what the organization means by, do whatever it takes.

823
01:04:08,320 --> 01:04:12,960
Generative AI belongs in a different part of this picture. An AI assistant can help a planner

824
01:04:12,960 --> 01:04:18,400
ask the right question, summarize the assumptions behind the scenario, explain why one option creates

825
01:04:18,400 --> 01:04:22,960
more late orders than another, or turn a scheduling result into a clear draft message for sales or

826
01:04:22,960 --> 01:04:27,600
customer service. Those are bounded tasks. The AI needs current, approved schedule facts, and a clear

827
01:04:27,600 --> 01:04:32,400
limit on what it can access, and it should point to the source information behind its answer. A person

828
01:04:32,400 --> 01:04:36,560
should review any recommendation before it turns into a machine change, an overtime request,

829
01:04:36,560 --> 01:04:41,280
or a new customer commitment. What it should not do is improvise deterministic schedule math from a

830
01:04:41,280 --> 01:04:46,080
chat prompt, because a fluent answer that sounds plausible is not proof that an order fits through a finite

831
01:04:46,080 --> 01:04:51,920
capacity route. Scheduling depends on exact constraints, sequence logic, calendars, material status,

832
01:04:51,920 --> 01:04:56,800
and rules that need formal checking. An AI can sit beside that logic and help people work with it,

833
01:04:56,800 --> 01:05:01,680
but it should not replace it with confident text, so think of the rules clearly. Prediction warns

834
01:05:01,680 --> 01:05:07,040
that a problem may be coming. Simulation tests are chosen response, optimization, searches for the

835
01:05:07,040 --> 01:05:13,040
best response against stated goals and constraints, and generative AI helps people understand, query,

836
01:05:13,040 --> 01:05:18,000
and communicate around those results when the context is controlled. None of those tools can settle

837
01:05:18,000 --> 01:05:22,800
the hardest part on their own. Who gets to define priority? The governance problem behind urgent

838
01:05:22,800 --> 01:05:28,240
who actually gets to call something urgent? That sounds political, but it's really a process question.

839
01:05:28,240 --> 01:05:32,560
When sales slaps an urgent label on an order, that label can mean half a dozen different things,

840
01:05:32,560 --> 01:05:37,600
maybe the customer, legitimately stops production without it. Maybe it makes up for a missed contractual

841
01:05:37,600 --> 01:05:41,920
promise. Maybe it protects the strategic account, or maybe the request just showed up late with a

842
01:05:41,920 --> 01:05:46,160
louder email than the rest. Those cases shouldn't all get the same response. A plant needs urgency

843
01:05:46,160 --> 01:05:50,480
categories, people can apply consistently, and each category needs enough detail to explain why

844
01:05:50,480 --> 01:05:54,640
this work deserves to jump ahead of confirmed orders. That doesn't mean building a committee for

845
01:05:54,640 --> 01:05:59,680
every exception. It means replacing a vague red flag with a reason that planning, production, and

846
01:05:59,680 --> 01:06:05,040
customer service can all understand. Take a safety related requirement that may demand immediate

847
01:06:05,040 --> 01:06:09,360
action even when it disrupts the plan. The customer outage might justify over time a different

848
01:06:09,360 --> 01:06:13,840
route or expensive freight. A contractual recovery may need a defined response because the business

849
01:06:13,840 --> 01:06:18,240
already missed a commitment. Each category carries a different trade off. A strategic account matters

850
01:06:18,240 --> 01:06:22,640
a lot, but that still doesn't create extra capacity. The decision might be right, yet somebody has

851
01:06:22,640 --> 01:06:27,440
to accept the commercial impact on the orders that get pushed. If urgency has no stated reason,

852
01:06:27,440 --> 01:06:31,920
planning can only react to whoever applies the most pressure, and that turns the schedule into a

853
01:06:31,920 --> 01:06:37,760
volume contest. Production needs the authority to return a feasibility result. Not a polite will try,

854
01:06:37,760 --> 01:06:42,560
but not an automatic rejection either. A feasibility result should state what the plant can do under

855
01:06:42,560 --> 01:06:47,040
current conditions, what assumptions it depends on, and which commitments change if the business accepts

856
01:06:47,040 --> 01:06:52,160
the request. Sometimes the answer is yes. Sometimes it's yes, but this other named order moves by

857
01:06:52,160 --> 01:06:56,720
this amount. Sometimes the plant can ship part of the quantity. Sometimes the requested date

858
01:06:56,720 --> 01:07:01,920
can't work without a supplier expedite, overtime approval, or a risk the business needs to own.

859
01:07:01,920 --> 01:07:06,000
That's not production resisting sales. That's production supplying the facts needed for a real

860
01:07:06,000 --> 01:07:11,360
customer promise. If planners only absorb every promise after it hits the schedule, the business hides

861
01:07:11,360 --> 01:07:15,600
the cost of that promise until somebody else discovers it later. Usually customer service,

862
01:07:15,600 --> 01:07:20,720
usually close to a mischipment. Customer service needs one agreed date. More than that, they need the

863
01:07:20,720 --> 01:07:25,120
reason behind any changed date. A person speaking to a customer shouldn't have to translate conflicting

864
01:07:25,120 --> 01:07:29,760
notes from sales, planning, and the shop floor into something that sounds confident. They need a date

865
01:07:29,760 --> 01:07:34,640
that the responsible teams have accepted plus the condition that could still alter it. The explanation

866
01:07:34,640 --> 01:07:39,520
can stay simple. The urgent request took capacity from this order, and the revised ship date depends

867
01:07:39,520 --> 01:07:44,480
on material release by Wednesday. That's far more useful than a date that looks certain in one system,

868
01:07:44,480 --> 01:07:48,800
while the factory treats it as wishful thinking. There also needs to be an escalation path when the

869
01:07:48,800 --> 01:07:54,160
trade gets serious. Some decisions involve revenue, others involve contractual penalty exposure,

870
01:07:54,160 --> 01:07:58,880
a customer outage, the cost of premium freight, quality risk, or the risk of pushing another

871
01:07:58,880 --> 01:08:03,920
customer beyond a hard commitment. No single planner, sales manager, or supervisor should have to

872
01:08:03,920 --> 01:08:08,960
carry every one of those choices alone. The escalation path defines who decides. It should be

873
01:08:08,960 --> 01:08:12,960
fast enough for an urgent request, but clear enough that people know when a choice moves beyond

874
01:08:12,960 --> 01:08:17,280
normal scheduling authority. The decision owner needs the affected orders, the likely dates,

875
01:08:17,280 --> 01:08:21,600
the cost and risk conditions, and the options still open. Then they can accept the trade with their

876
01:08:21,600 --> 01:08:27,440
eyes open. Without that process, urgent slowly loses its meaning. If every late request becomes

877
01:08:27,440 --> 01:08:32,320
urgent, normal work becomes the work that nobody defended loudly enough. The plant still has the same

878
01:08:32,320 --> 01:08:37,200
machines, people, material, and hours. It just has more red flags competing for the front of the queue.

879
01:08:37,200 --> 01:08:42,080
Urgent, without a decision rule, becomes a louder form of normal, and formal governance only works

880
01:08:42,080 --> 01:08:49,200
when every team sees the same current facts. A shared promise process. A shared promise process starts

881
01:08:49,200 --> 01:08:54,000
before the customer ever receives a date. Sales should enter the request with enough facts

882
01:08:54,000 --> 01:08:58,400
for the plant to assess it properly. That means the product and revision, the quantity, the

883
01:08:58,400 --> 01:09:04,320
requested delivery date, the delivery location, and any customer condition that changes the decision.

884
01:09:04,320 --> 01:09:08,720
Maybe the customer needs a partial shipment, maybe they need a full quantity in one delivery.

885
01:09:08,720 --> 01:09:12,880
Maybe a missed date stops their line. Those details change the feasible response.

886
01:09:12,880 --> 01:09:17,920
Urgent on its own tells planning almost nothing. It says someone wants an answer quickly. It doesn't say

887
01:09:17,920 --> 01:09:21,760
which route applies whether a substitute product is acceptable whether the order needs a special

888
01:09:21,760 --> 01:09:26,800
inspection or whether the customer can accept an earlier partial quantity. Sales holds much of

889
01:09:26,800 --> 01:09:31,440
that commercial context, so it needs to enter the process with the order. Then planning can run a

890
01:09:31,440 --> 01:09:36,160
fast feasibility check. This doesn't always need a full rescheduling exercise across every order in

891
01:09:36,160 --> 01:09:40,400
the plant. The response should match the size and risk of the request. But planning does need to

892
01:09:40,400 --> 01:09:46,880
test the current path. Material status, approved route, constrained resources, remaining capacity,

893
01:09:46,880 --> 01:09:51,680
and the order's place in the active schedule. The question isn't simply, can we produce this?

894
01:09:51,680 --> 01:09:56,560
A better version is, can we produce and ship this quantity by the state under current conditions

895
01:09:56,560 --> 01:10:00,720
without creating a trade that nobody has approved? That pushes the discussion beyond a standard

896
01:10:00,720 --> 01:10:04,960
lead time and into the work that actually needs to happen. Production then adds the practical

897
01:10:04,960 --> 01:10:09,760
limits that rarely fit into a sales request. A planner can see a machine calendar. A supervisor may

898
01:10:09,760 --> 01:10:14,160
know that the next available slot follows a complex setup, that the fixture needs checking,

899
01:10:14,160 --> 01:10:18,960
or that a scheduled maintenance task can't safely move. Quality may need to confirm whether the

900
01:10:18,960 --> 01:10:24,240
product needs first of approval, extra sampling, or a release before packing. Shift conditions matter

901
01:10:24,240 --> 01:10:29,200
too. A slot late in the day may look open, yet the qualified person may not work that shift.

902
01:10:29,200 --> 01:10:34,320
An overtime option may exist, but it may need approval or create fatigue concerns the plant

903
01:10:34,320 --> 01:10:38,800
doesn't want to normalize. The feasibility check needs those facts before the promise hardens.

904
01:10:38,800 --> 01:10:43,360
This is where capable to promise becomes useful. Capable to promise means, the date comes from what

905
01:10:43,360 --> 01:10:47,840
the factory can currently do, given material, root, resource, labor, and shipping limits.

906
01:10:47,840 --> 01:10:53,040
It doesn't come from a static lead time copied from a master data field, and it doesn't come from

907
01:10:53,040 --> 01:10:58,560
optimism because the customer matters. A standard lead time still has its place. It helps set expectations

908
01:10:58,560 --> 01:11:03,360
for normal demand. It helps sales plan. It gives customers a starting point, but an urgent request is

909
01:11:03,360 --> 01:11:07,520
not normal demand. It asks the plant to change the sequence of work already committed so the answer

910
01:11:07,520 --> 01:11:12,160
needs current constraints rather than a generic number. Think about the possible outcomes. The plant

911
01:11:12,160 --> 01:11:16,960
may accept the date because the work fits without moving an existing commitment. It may accept the date

912
01:11:16,960 --> 01:11:21,600
with a named trade where another order moves and the business accepts that impact. It may propose a

913
01:11:21,600 --> 01:11:25,600
partial shipment that solves the customer's immediate need while protecting the rest of the plan.

914
01:11:25,600 --> 01:11:30,320
Or it may return a later date. In some cases it should decline the requested commitment, not because

915
01:11:30,320 --> 01:11:34,800
the plant lacks ambition, but because the evidence shows the promise depends on material that isn't

916
01:11:34,800 --> 01:11:40,400
usable, capacity that isn't real, or a risk nobody should hide from the customer. The commercial owner

917
01:11:40,400 --> 01:11:45,600
then communicates the answer. That owner might sit in sales, customer service, or account management

918
01:11:45,600 --> 01:11:50,400
depending on how the business works. What matters is that one person owns the customer message and

919
01:11:50,400 --> 01:11:55,120
receives a decision backed by production facts, not a vague internal hope. They can state the accepted

920
01:11:55,120 --> 01:11:59,360
ship date. They can explain a partial delivery option. If the request can't fit, they can offer

921
01:11:59,360 --> 01:12:04,080
the earliest feasible alternative rather than waiting for the plant to fail silently against an

922
01:12:04,080 --> 01:12:09,680
impossible date. The customer may not like every answer, but customers usually prefer a clear answer

923
01:12:09,680 --> 01:12:14,720
early over a confident date that starts falling apart after materials move, machines queue,

924
01:12:14,720 --> 01:12:19,440
and the carrier deadline has passed. A promise earns trust when the business can explain the

925
01:12:19,440 --> 01:12:24,400
conditions behind it. This also changes the relationship between sales and production. Sales brings

926
01:12:24,400 --> 01:12:29,280
the customer need and commercial stakes. Planning tests the schedule. Production confirms what can run

927
01:12:29,280 --> 01:12:34,000
safely and reliably. The commercial owner takes the evidence back to the customer. Each group has a

928
01:12:34,000 --> 01:12:39,120
defined part in the decision instead of passing an urgent request over the wall and hoping the factory

929
01:12:39,120 --> 01:12:44,240
absorbs it. For that flow to work at speed, the factory needs a connected decision path. The decision

930
01:12:44,240 --> 01:12:50,160
architecture, layer by layer. Here's the thing most people skip when they talk about shared promise

931
01:12:50,160 --> 01:12:55,200
processes. A meeting and a handful of agreed rules won't cut it. You need a decision path that

932
01:12:55,200 --> 01:12:59,200
moves real-time facts from the shop floor to the person who owns the customer commitment,

933
01:12:59,200 --> 01:13:04,080
without turning every urgent order into a round of calls, exports, and private files. I think of it

934
01:13:04,080 --> 01:13:09,040
as layers. Each layer answers a different part of the question. Closest to production, the shop floor

935
01:13:09,040 --> 01:13:13,840
layer tells you what can physically happen. MES events show where work sits in its root, what

936
01:13:13,840 --> 01:13:18,480
quantity has completed, and where scrap or holds change the next step. Machine signals add run

937
01:13:18,480 --> 01:13:24,080
state, alarms, stop events. Quality status tells you whether parts can move, labor and maintenance

938
01:13:24,080 --> 01:13:29,440
input tells you whether a plant slot is actually workable. This layer needs trust, not volume. A

939
01:13:29,440 --> 01:13:33,280
thousand machine signals won't help if the planner can't tell whether an operation is ready for the

940
01:13:33,280 --> 01:13:37,440
next resource. And no schedule should assume a machine is free just because an interface

941
01:13:37,440 --> 01:13:42,080
stopped reporting. The shop floor layer needs clear states that planning can use with people able

942
01:13:42,080 --> 01:13:47,040
to correct the system when the physical situation doesn't match what was recorded. Above that sits

943
01:13:47,040 --> 01:13:52,240
the enterprise layer. This is where ERP brings in customer orders, product definitions, bills of

944
01:13:52,240 --> 01:13:57,280
material inventory, supplier commitments, purchase orders, and the dates sales promised. It also

945
01:13:57,280 --> 01:14:02,240
carries financial rules that affect the decision. A late order might carry a contractual penalty,

946
01:14:02,240 --> 01:14:06,320
an expedited shipment might need approval. A high cost material allocation might need a commercial

947
01:14:06,320 --> 01:14:11,120
decision before anyone moves it. The enterprise layer explains what the factory is trying to fulfill.

948
01:14:11,120 --> 01:14:16,240
It provides the demand, supply, and commercial conditions the decision must respect. The shop floor

949
01:14:16,240 --> 01:14:20,560
layer tells you what's happening. The enterprise layer tells you what's owed, but it doesn't decide

950
01:14:20,560 --> 01:14:25,200
whether the work actually fits. Between those layers and the schedule sits the context layer. This is

951
01:14:25,200 --> 01:14:29,600
where you model the links between product process and resources. The product needs a route, the route

952
01:14:29,600 --> 01:14:35,680
contains operations. Each operation needs resources, tooling, material, quality checks, and sometimes a

953
01:14:35,680 --> 01:14:40,240
person with a named skill or approval. A digital twin or knowledge graph can record those links

954
01:14:40,240 --> 01:14:44,800
so the system can follow the path from an urgent customer order to the resources it consumes

955
01:14:44,800 --> 01:14:49,760
and the other commitments it might disrupt. This layer turns records into a connected operating

956
01:14:49,760 --> 01:14:54,800
model. Without it, an urgent order shows up as a sales line, a work order, and maybe a resource

957
01:14:54,800 --> 01:14:58,960
booking. With it, the system can trace the order through the real conditions around it,

958
01:14:58,960 --> 01:15:03,280
which material supports it, which resource runs it, which operation has to finish first,

959
01:15:03,280 --> 01:15:07,680
and which later commitment loses time when that resource changes. Then comes the decision layer,

960
01:15:07,680 --> 01:15:11,600
and this is where finite scheduling checks whether the work fits into real calendars instead of

961
01:15:11,600 --> 01:15:16,480
theoretical capacity. Simulation tests possible responses before the plant actually moves anything.

962
01:15:16,480 --> 01:15:20,560
Optimization can search through permitted options when the rules and business goals are clear.

963
01:15:20,560 --> 01:15:24,880
Alerts can bring an exception to the right people before the schedule damage spreads,

964
01:15:24,880 --> 01:15:29,840
but the output should guide a person, not replace them. An alert that says urgent order risk isn't

965
01:15:29,840 --> 01:15:34,400
enough. The planner needs to see the affected orders, the assumptions, the available options,

966
01:15:34,400 --> 01:15:38,960
and the consequence of each one. A commercial owner needs the customer impact, a supervisor needs

967
01:15:38,960 --> 01:15:43,920
to know what has to change on the floor. Guided human approval connects those roles to one decision

968
01:15:43,920 --> 01:15:48,720
record instead of a chain of informal messages. The final layer is the experience layer. This is where

969
01:15:48,720 --> 01:15:53,360
people interact with the process through tools that suit their job. Power BI can give sales,

970
01:15:53,360 --> 01:15:57,760
planning, and production a shared view of order exposure and capacity pressure. Power apps can

971
01:15:57,760 --> 01:16:03,600
provide a focused form for an urgent order request, a feasibility review, or an approval. Workflow tools

972
01:16:03,600 --> 01:16:08,960
can root the decision to the right owner, record the outcome, and notify the people whose work changes.

973
01:16:08,960 --> 01:16:13,040
The design should fit the role. Sales doesn't need every machine alarm, a supervisor doesn't need a

974
01:16:13,040 --> 01:16:17,520
finance view of every customer commitment. Customer service needs an agreed date and a clear reason

975
01:16:17,520 --> 01:16:21,840
behind it. The planner needs the full constraint picture. Generic alerts send to everyone usually

976
01:16:21,840 --> 01:16:26,800
create noise, then get ignored with impressive consistency. Each layer has a job and none should pretend

977
01:16:26,800 --> 01:16:31,680
to do the job of the others. The MES does not replace ERP, fabric or another data layer does not

978
01:16:31,680 --> 01:16:36,720
replace finite scheduling, a dashboard does not replace a decision model, and a workflow does not turn

979
01:16:36,720 --> 01:16:41,440
an impossible date into a feasible one. Microsoft can fit across this architecture from integration and

980
01:16:41,440 --> 01:16:46,240
data management through reporting, apps workflow, and AI support, but specialized manufacturing logic

981
01:16:46,240 --> 01:16:51,680
still matters because the factory runs on real constraints, not just connected data, where Microsoft

982
01:16:51,680 --> 01:16:58,000
fits and where it doesn't. Microsoft fits well across the decision path, but it doesn't remove the

983
01:16:58,000 --> 01:17:03,200
need for manufacturing logic, operating rules, or human ownership. That part matters. Let's walk

984
01:17:03,200 --> 01:17:07,440
through where each piece belongs. Start with Azure and Microsoft fabric. They provide the technical

985
01:17:07,440 --> 01:17:13,040
foundation for bringing data together from ERP, MES, quality systems, planning tools, and selected

986
01:17:13,040 --> 01:17:18,640
shop floor sources. Azure supports integration services, identity security controls, storage,

987
01:17:18,640 --> 01:17:24,400
and AI services. Fabric supports shared data preparation, governed access, analytics, and the

988
01:17:24,400 --> 01:17:29,440
history needed to understand how a schedule changed over time. That foundation matters because an

989
01:17:29,440 --> 01:17:34,480
urgent order decision crosses many systems. A planner might need the current operation state from

990
01:17:34,480 --> 01:17:39,360
MES, the customer commitment from ERP, material status from quality and inventory, and a machine

991
01:17:39,360 --> 01:17:43,680
availability event from the floor. Those facts need a controlled route into the decision process.

992
01:17:43,680 --> 01:17:47,840
They also need access rules, not everyone who can view a production order should see customer

993
01:17:47,840 --> 01:17:52,720
pricing, supplier terms, or every workforce detail. Identity and governance aren't sidework. They

994
01:17:52,720 --> 01:17:57,680
decide who can see the data, who can approve a schedule override, and who can change a customer

995
01:17:57,680 --> 01:18:02,880
commitment. If an urgent order moves three confirmed orders, the system should show the impact to the

996
01:18:02,880 --> 01:18:07,520
people responsible for those orders. It should not turn a sensitive production decision into a shared

997
01:18:07,520 --> 01:18:12,560
spreadsheet with unclear access. Azure and Fabric can help build that controlled data and integration

998
01:18:12,560 --> 01:18:17,680
layer. They can retain source events, prepare consistent data sets, support analysis, and connect

999
01:18:17,680 --> 01:18:22,080
systems that were never designed to talk to each other directly. But they don't contain the factory's

1000
01:18:22,080 --> 01:18:26,400
decision policy by default. They don't know which customer agreement overrides normal sequencing.

1001
01:18:26,400 --> 01:18:30,640
They don't know whether over time needs a manager's approval, whether a process route has been

1002
01:18:30,640 --> 01:18:36,080
qualified for a product revision, or whether a supervisor can safely move a maintenance task.

1003
01:18:36,080 --> 01:18:40,400
Those rules need to come from the organization and the production systems that own them.

1004
01:18:40,400 --> 01:18:45,040
The power platform fits closer to action. A power app can give sales a structured way to submit an

1005
01:18:45,040 --> 01:18:49,680
urgent order request. Instead of sending a message marked urgent and hoping it finds the right person.

1006
01:18:49,680 --> 01:18:55,200
The request can collect the customer need, quantity, require date, delivery conditions, and reason

1007
01:18:55,200 --> 01:18:59,600
for the exception. That gives planning something they can actually assess. Power automate can

1008
01:18:59,600 --> 01:19:04,560
route a request through an approval flow when the proposed schedule change crosses an agreed threshold,

1009
01:19:04,560 --> 01:19:08,720
maybe a normal expedite stays with planning. Maybe a change that risks a contractual date

1010
01:19:08,720 --> 01:19:13,040
goes to a commercial owner. The workflow can record the decision, the conditions attached,

1011
01:19:13,040 --> 01:19:17,760
and the people who need to know. Let's be clear, a workflow is not a scheduler. It can move the

1012
01:19:17,760 --> 01:19:21,920
right information and approval to the right role. It can make a decision traceable. But it still

1013
01:19:21,920 --> 01:19:26,960
needs a feasibility result from planning logic that has checked real capacity, sequence, materials,

1014
01:19:26,960 --> 01:19:31,440
and production constraints. Power BI fits at the shared operational view. It can give sales,

1015
01:19:31,440 --> 01:19:35,200
planning, production, and customer service a common view of the urgency request,

1016
01:19:35,200 --> 01:19:39,840
affected work, delivery exposure, and approved decision. Because the view rests on governed

1017
01:19:39,840 --> 01:19:44,960
definitions, teams can discuss the same order state and date rule instead of debating whose export

1018
01:19:44,960 --> 01:19:49,360
looks more current. That changes the tone of the discussion. Instead of sales asking whether

1019
01:19:49,360 --> 01:19:54,080
the plant can somehow fit the order in, the conversation focuses on a visible choice. This

1020
01:19:54,080 --> 01:19:59,200
state can work under these conditions. This customer order moves, if we accept it, this material

1021
01:19:59,200 --> 01:20:03,840
shortage blocks the option unless purchasing changes the supply plan. Power BI makes that

1022
01:20:03,840 --> 01:20:08,880
information easier to use. But it does not calculate a feasible sequence just by displaying a resource

1023
01:20:08,880 --> 01:20:14,080
calendar. For that work, specialized scheduling or optimization tools often belong in the architecture.

1024
01:20:14,080 --> 01:20:19,840
A finite capacity scheduler handles real calendars, operation order, setups, resource

1025
01:20:19,840 --> 01:20:24,400
alternatives, labor limits, and constraint rules. An optimization engine can compare permitted

1026
01:20:24,400 --> 01:20:28,720
schedule options against business goals that people have defined. Those tools solve a different

1027
01:20:28,720 --> 01:20:32,800
problem from a data platform. Fabric can prepare the data that scheduling needs and store the

1028
01:20:32,800 --> 01:20:37,840
schedule results for broader analysis. Power BI can present the impact. Power platform can guide

1029
01:20:37,840 --> 01:20:42,320
approvals and follow-up work. The scheduling tool tests, whether the order can actually move through

1030
01:20:42,320 --> 01:20:48,000
the plant without quietly breaking something else. That separation keeps the design honest. It also

1031
01:20:48,000 --> 01:20:53,280
keeps responsibility in the right place. No Microsoft service, no planning system, and no AI

1032
01:20:53,280 --> 01:20:58,080
assistant can clean up weak master data on its own. Product routes need ownership. Resource calendars

1033
01:20:58,080 --> 01:21:02,640
need upkeep. Material status needs clear rules. Customer priorities need defined categories.

1034
01:21:02,640 --> 01:21:06,320
Somebody needs the authority to accept a trade between one commitment and another.

1035
01:21:06,320 --> 01:21:11,360
Technology can make that work visible and faster. It cannot decide without a business rule which

1036
01:21:11,360 --> 01:21:16,480
customer should take the delay. It cannot know that a routing alternative exists only on paper,

1037
01:21:16,480 --> 01:21:20,160
and it cannot create trust if teams keep different definitions in separate systems.

1038
01:21:20,160 --> 01:21:24,320
Once that architecture exists, co-pilot becomes a more useful and safer interface.

1039
01:21:24,320 --> 01:21:28,320
Co-pilot an industrial AI. Ask better questions first.

1040
01:21:29,520 --> 01:21:34,560
Once the data, scheduling logic and approval path are in place, co-pilot becomes a genuinely

1041
01:21:34,560 --> 01:21:38,640
useful tool, a quick answer system for people who need to know what's happening right now.

1042
01:21:38,640 --> 01:21:43,440
It can tell you why an order moved, what risks come with a proposed change,

1043
01:21:43,440 --> 01:21:48,000
and where to find the real facts instead of trusting a black box AI response.

1044
01:21:48,000 --> 01:21:52,320
That's a much better fit than asking it to make decisions. Picture a sales manager asking,

1045
01:21:52,320 --> 01:21:55,600
if I accept this urgent order by Friday which confirmed orders go late.

1046
01:21:55,600 --> 01:21:59,040
That question looks simple, but behind it is a chain of checks.

1047
01:21:59,520 --> 01:22:04,560
Accepted date, urgent order quantity, approved route, current schedule, material state,

1048
01:22:04,560 --> 01:22:09,200
and dates already committed to other customers. Co-pilot can help turn that into something actionable.

1049
01:22:09,200 --> 01:22:13,360
It might come back with a short explanation. Accepting the urgent order pushes it ahead of two

1050
01:22:13,360 --> 01:22:18,400
planned operations at a constrained resource. It identifies the affected orders, shows the projected

1051
01:22:18,400 --> 01:22:23,200
ship dates, and links each statement back to the schedule result, the ERP commitment and the current

1052
01:22:23,200 --> 01:22:28,000
M.S. status. Those links matter because a planner should be able to ask where a date came from.

1053
01:22:28,000 --> 01:22:32,400
A customer service person should be able to check if the order is still waiting for quality release.

1054
01:22:32,400 --> 01:22:36,240
And a production manager should be able to see if the assumption depends on a machine calendar

1055
01:22:36,240 --> 01:22:40,400
that changed mid-shift. Without source facts, an AI answer is just a polished guess.

1056
01:22:40,400 --> 01:22:44,560
Let me break this down. There's a difference between retrieval, reasoning, and optimization.

1057
01:22:44,560 --> 01:22:47,840
Retrieval finds approved information. The sales order, the work order status,

1058
01:22:47,840 --> 01:22:52,720
the material allocation, the last approved schedule. Reasoning connects those facts into an explanation.

1059
01:22:52,720 --> 01:22:57,760
For example, it can tell you that order 482 is at risk because its next operation shares an

1060
01:22:57,760 --> 01:23:02,800
inspection station with the urgent work and the new sequence pushes it past the carrier cutoff.

1061
01:23:02,800 --> 01:23:08,400
That explanation needs to stay grounded in the schedule result and the linked production facts.

1062
01:23:08,400 --> 01:23:13,440
Optimization does something else. It searches for a feasible plan against stated rules.

1063
01:23:13,440 --> 01:23:16,800
It tests timing, sequence, resource choices, labor limits,

1064
01:23:16,800 --> 01:23:19,840
co-pilot can call or present the output of that process.

1065
01:23:19,840 --> 01:23:23,680
But conversational text should never replace the formal schedule calculation.

1066
01:23:23,680 --> 01:23:26,720
A smooth paragraph doesn't mean the machine time is actually booked.

1067
01:23:26,720 --> 01:23:30,080
The same distinction applies when people ask co-pilot for a recommendation.

1068
01:23:30,080 --> 01:23:34,000
You might ask, what's the least damaging way to meet this customer request?

1069
01:23:34,000 --> 01:23:37,600
The assistant can present approved scenario results in plain language.

1070
01:23:37,600 --> 01:23:42,400
It can compare over time with partial shipment. It can explain which dates move under each case.

1071
01:23:42,400 --> 01:23:45,680
But it should never invent an option that the planning model hasn't checked.

1072
01:23:45,680 --> 01:23:47,920
There's also a practical communication use case.

1073
01:23:47,920 --> 01:23:52,640
After the business accepts a schedule trade, co-pilot can draft a customer update for review.

1074
01:23:52,640 --> 01:23:56,000
It turns the approved facts into a message stating the delivery date,

1075
01:23:56,000 --> 01:23:58,720
any partial shipment planned, and the condition behind it.

1076
01:23:58,720 --> 01:24:02,400
That saves time, especially when the same decision affects several teams.

1077
01:24:02,400 --> 01:24:04,720
Still, the draft must reflect the approved decision,

1078
01:24:04,720 --> 01:24:07,280
not the assistant's guess about what sounds reassuring.

1079
01:24:07,280 --> 01:24:12,080
Customer communication creates a new commitment and new commitments belong under the same controls

1080
01:24:12,080 --> 01:24:14,080
as the original urgent request.

1081
01:24:14,080 --> 01:24:18,480
Grounding isn't just a connection to a data store. The assistant needs approved data sources,

1082
01:24:18,480 --> 01:24:21,120
current schedule context, and role-based permissions.

1083
01:24:21,120 --> 01:24:24,640
A sales user may need to see customer dates and the approved impact.

1084
01:24:24,640 --> 01:24:28,880
They may not need to see supplier terms, detailed labor data, or every quality note.

1085
01:24:28,880 --> 01:24:32,080
A supervisor may need the flow actions but not the commercial margin.

1086
01:24:32,080 --> 01:24:33,600
Access should follow the job.

1087
01:24:33,600 --> 01:24:35,600
The system also needs a clear point in time.

1088
01:24:35,600 --> 01:24:40,000
If co-pilot answers from yesterday's schedule while planning approved a new sequence an hour ago,

1089
01:24:40,000 --> 01:24:43,520
that creates confusion at exactly the moment people need confidence.

1090
01:24:43,520 --> 01:24:48,080
Responses should identify the schedule version, the data time, and any open assumptions.

1091
01:24:48,080 --> 01:24:49,440
That makes uncertainty visible.

1092
01:24:49,440 --> 01:24:51,280
Human approval remains part of the design.

1093
01:24:51,280 --> 01:24:53,120
A person should approve a schedule override.

1094
01:24:53,120 --> 01:24:55,840
A person should approve overtime where policy requires it.

1095
01:24:55,840 --> 01:24:57,920
A person should approve a customer message.

1096
01:24:57,920 --> 01:25:00,400
Co-pilot can prepare, explain, and root work,

1097
01:25:00,400 --> 01:25:03,200
but the accountable decision owner still accepts the trade.

1098
01:25:03,200 --> 01:25:05,600
Autonomous action needs hard limits.

1099
01:25:05,600 --> 01:25:08,880
It may be reasonable for an assistant to create a draft exception record

1100
01:25:08,880 --> 01:25:11,440
or notify the right planner when a risk threshold is crossed.

1101
01:25:12,160 --> 01:25:14,400
It is a different matter to release a work order,

1102
01:25:14,400 --> 01:25:16,880
move a production sequence, consume reserve material,

1103
01:25:16,880 --> 01:25:18,880
or tell a customer a new date without review.

1104
01:25:18,880 --> 01:25:21,920
Those actions change the factory, so ask co-pilot better questions

1105
01:25:21,920 --> 01:25:23,920
and expect it to show its work.

1106
01:25:23,920 --> 01:25:26,640
Ask which orders become late, why they become late,

1107
01:25:26,640 --> 01:25:28,320
what assumptions drive the result,

1108
01:25:28,320 --> 01:25:30,640
and which approved scenarios remain available.

1109
01:25:30,640 --> 01:25:33,440
That turns AI into a practical part of the decision flow

1110
01:25:33,440 --> 01:25:37,120
rather than another voice producing confident text around incomplete facts.

1111
01:25:37,120 --> 01:25:41,120
No AI layer fixes a process that accepts promises without constrained checks.

1112
01:25:42,080 --> 01:25:43,840
Exceptions need human judgment.

1113
01:25:43,840 --> 01:25:47,440
Even with good schedule logic and current data,

1114
01:25:47,440 --> 01:25:49,760
some urgent order choices need human judgment.

1115
01:25:49,760 --> 01:25:50,240
Here's why.

1116
01:25:50,240 --> 01:25:53,440
A scheduler can compare capacity, material,

1117
01:25:53,440 --> 01:25:55,120
root rules, and promised dates,

1118
01:25:55,120 --> 01:25:59,040
but the model may not know that one customer has accepted delays before

1119
01:25:59,040 --> 01:26:00,800
and another will face a line stop.

1120
01:26:00,800 --> 01:26:03,840
It may not know that a supplier has promised an expedite five times

1121
01:26:03,840 --> 01:26:05,280
but only delivered twice.

1122
01:26:05,280 --> 01:26:07,680
It may not know that a senior operator sees a quality risk

1123
01:26:07,680 --> 01:26:09,520
in a route that looks fine in the rooting master.

1124
01:26:09,520 --> 01:26:11,200
Those facts still affect the decision.

1125
01:26:11,200 --> 01:26:12,880
Think about a proposed alternate machine.

1126
01:26:12,880 --> 01:26:15,520
The model may show capacity, the right tooling,

1127
01:26:15,520 --> 01:26:16,960
and an approved process route,

1128
01:26:16,960 --> 01:26:19,520
but a supervisor may know the machine has been running unstable

1129
01:26:19,520 --> 01:26:20,960
since a recent repair,

1130
01:26:20,960 --> 01:26:23,760
or the next setup will take longer because a tool holder

1131
01:26:23,760 --> 01:26:26,240
has where that isn't in the maintenance records yet.

1132
01:26:26,240 --> 01:26:28,000
The machine looks available in the system,

1133
01:26:28,000 --> 01:26:29,600
but it may not be a sensible choice.

1134
01:26:29,600 --> 01:26:32,480
That isn't a failure of data science of finite scheduling.

1135
01:26:32,480 --> 01:26:33,520
It's how production works.

1136
01:26:33,520 --> 01:26:36,160
The plant contains formal rules, measured facts,

1137
01:26:36,160 --> 01:26:37,200
and practical knowledge

1138
01:26:37,200 --> 01:26:39,440
that people build through repetition, problems,

1139
01:26:39,440 --> 01:26:41,040
and close contact with the process.

1140
01:26:41,040 --> 01:26:43,440
A good decision process gives that knowledge a place.

1141
01:26:43,440 --> 01:26:46,560
Quality risk is another area where human judgment matters.

1142
01:26:46,560 --> 01:26:48,800
A schedule can show that an urgent order fits

1143
01:26:48,800 --> 01:26:51,040
if it moves through a faster sequence.

1144
01:26:51,040 --> 01:26:53,120
Quality may know that this product revision,

1145
01:26:53,120 --> 01:26:56,480
material lot, or customer requirement, needs extra care.

1146
01:26:56,480 --> 01:26:58,240
The technical route may still be approved,

1147
01:26:58,240 --> 01:27:00,400
but the risk may not suit a customer deadline

1148
01:27:00,400 --> 01:27:01,600
with no room for rework.

1149
01:27:01,600 --> 01:27:03,920
Someone needs to weigh that risk before work moves.

1150
01:27:03,920 --> 01:27:05,520
Supply or trust is another one.

1151
01:27:05,520 --> 01:27:07,680
Purchasing may see a confirmed receipt date.

1152
01:27:07,680 --> 01:27:09,840
The planner may see material as expected,

1153
01:27:09,840 --> 01:27:12,160
but a buyer who works with that supplier every week

1154
01:27:12,160 --> 01:27:14,160
may know the date depends on a carrier collection

1155
01:27:14,160 --> 01:27:15,120
that often slips,

1156
01:27:15,120 --> 01:27:16,960
a document still waiting for approval

1157
01:27:16,960 --> 01:27:19,840
or a component that has failed incoming inspection before.

1158
01:27:19,840 --> 01:27:21,680
The supply signal carries a date.

1159
01:27:21,680 --> 01:27:24,320
The buyer carries context, sales carries context too,

1160
01:27:24,320 --> 01:27:26,800
but from the customer side, sales may know

1161
01:27:26,800 --> 01:27:29,520
the urgent request connects to a contract renewal,

1162
01:27:29,520 --> 01:27:31,600
a product launch, a service outage,

1163
01:27:31,600 --> 01:27:33,680
or a relationship that needs attention.

1164
01:27:33,680 --> 01:27:35,440
That knowledge belongs in the decision,

1165
01:27:35,440 --> 01:27:37,840
but sales also needs to see the cost of the request

1166
01:27:37,840 --> 01:27:38,960
in operational terms.

1167
01:27:38,960 --> 01:27:40,800
Not just production is busy.

1168
01:27:40,800 --> 01:27:42,800
They need to see which confirmed orders move,

1169
01:27:42,800 --> 01:27:43,680
how far they move,

1170
01:27:43,680 --> 01:27:46,160
whether overtime or premium freight enters the plan

1171
01:27:46,160 --> 01:27:48,320
and where quality or supply risk increases.

1172
01:27:48,320 --> 01:27:49,760
A customer relationship matters,

1173
01:27:49,760 --> 01:27:52,400
but so do the commitments already made to other customers.

1174
01:27:52,400 --> 01:27:55,280
That is why human judgment shouldn't mean informal chaos.

1175
01:27:55,280 --> 01:27:56,800
It should mean accountable choice,

1176
01:27:56,800 --> 01:27:58,080
supported by evidence.

1177
01:27:58,080 --> 01:28:00,320
The scheduler brings the tested schedule options.

1178
01:28:00,320 --> 01:28:02,560
The supervisor brings the conditions on the floor.

1179
01:28:02,560 --> 01:28:05,840
Quality and purchasing bring the risks behind apparently simple dates.

1180
01:28:05,840 --> 01:28:08,000
Sales brings the commercial reason for the exception.

1181
01:28:08,000 --> 01:28:10,240
Then someone with authority accepts the trade.

1182
01:28:10,240 --> 01:28:13,200
Sometimes that decision will override the best schedule result

1183
01:28:13,200 --> 01:28:14,560
that can be the right outcome.

1184
01:28:14,560 --> 01:28:17,200
A genuine customer emergency may justify disruption

1185
01:28:17,200 --> 01:28:18,960
that normal rules would reject,

1186
01:28:18,960 --> 01:28:20,480
but the override should be explicit,

1187
01:28:20,480 --> 01:28:24,160
because an exception that leaves no record quickly becomes a habit.

1188
01:28:24,160 --> 01:28:25,200
Nobody can explain.

1189
01:28:25,200 --> 01:28:26,320
Keep an override record.

1190
01:28:26,320 --> 01:28:28,400
Record who changed the priority, why,

1191
01:28:28,400 --> 01:28:29,760
which option they selected,

1192
01:28:29,760 --> 01:28:31,520
which orders absorb the impact.

1193
01:28:31,520 --> 01:28:32,960
Include the schedule version,

1194
01:28:32,960 --> 01:28:34,880
the assumption still leading checking,

1195
01:28:34,880 --> 01:28:37,440
and the person responsible for customer communication.

1196
01:28:37,440 --> 01:28:39,680
This doesn't need to become a paperwork exercise.

1197
01:28:39,680 --> 01:28:42,560
The record can sit in the workflow that handles the request.

1198
01:28:42,560 --> 01:28:45,440
What matters is that later the plant can trace an urgent order

1199
01:28:45,440 --> 01:28:46,880
back to a name decision,

1200
01:28:46,880 --> 01:28:48,960
rather than trying to reconstruct it from messages,

1201
01:28:48,960 --> 01:28:50,000
calendar invites,

1202
01:28:50,000 --> 01:28:52,160
and a schedule that has changed 10 times.

1203
01:28:52,160 --> 01:28:53,280
That also protects people.

1204
01:28:53,280 --> 01:28:55,440
A planner shouldn't carry blame for a commercial override

1205
01:28:55,440 --> 01:28:56,640
they didn't authorize.

1206
01:28:56,640 --> 01:29:00,400
The supervisor shouldn't have to explain why the floor changed sequence

1207
01:29:00,400 --> 01:29:02,880
when the decision came from a customer commitment.

1208
01:29:02,880 --> 01:29:05,040
Sales shouldn't need to defend an urgent request

1209
01:29:05,040 --> 01:29:06,960
without seeing the trade the plant accepted.

1210
01:29:06,960 --> 01:29:09,440
Clear records put responsibility where it belongs.

1211
01:29:09,440 --> 01:29:12,320
And over time, those records become more than an audit trail.

1212
01:29:12,320 --> 01:29:15,200
They show which types of urgent orders keep returning,

1213
01:29:15,200 --> 01:29:16,800
which assumptions repeatedly fail,

1214
01:29:16,800 --> 01:29:18,800
and whether plant keeps accepting disruption

1215
01:29:18,800 --> 01:29:20,400
without seeing the full cost.

1216
01:29:20,400 --> 01:29:22,560
That record becomes part of how the plant learns.

1217
01:29:22,560 --> 01:29:24,480
Learn from every expedite.

1218
01:29:24,480 --> 01:29:28,240
Here's the problem with most expedite processes.

1219
01:29:28,240 --> 01:29:30,960
An urgent order disappears from view the moment it ships.

1220
01:29:30,960 --> 01:29:33,040
You need to track it from the first customer request

1221
01:29:33,040 --> 01:29:34,480
through the final delivery.

1222
01:29:34,480 --> 01:29:36,960
Capture when sales are asked when the plant accepted,

1223
01:29:36,960 --> 01:29:38,480
what schedule changes happened?