Can You Simulate Your Factory Before Changing It?

1
00:00:00,000 --> 00:00:02,360
Here's a problem most manufacturers don't talk about.

2
00:00:02,360 --> 00:00:05,460
A production change often starts with a sentence that sounds harmless.

3
00:00:05,460 --> 00:00:07,020
Let's add a shift.

4
00:00:07,020 --> 00:00:09,100
Let's move this work to another machine.

5
00:00:09,100 --> 00:00:10,680
Let's reduce the buffer.

6
00:00:10,680 --> 00:00:13,040
Let's accept more orders from this product family.

7
00:00:13,040 --> 00:00:14,680
And then the factory has to live with it.

8
00:00:14,680 --> 00:00:16,740
You're not changing a line in a planning file.

9
00:00:16,740 --> 00:00:20,520
You're changing the daily work of operators, planners, maintenance teams, quality staff,

10
00:00:20,520 --> 00:00:24,000
material handlers, people who already carry the weight of customer dates.

11
00:00:24,000 --> 00:00:28,480
A change can hit machines, but it also hits cues, handovers, inspection capacity, material flow,

12
00:00:28,480 --> 00:00:31,200
and the next order waiting behind the first one.

13
00:00:31,200 --> 00:00:34,800
That's why a factory change is often a live experiment, even if nobody writes that on the

14
00:00:34,800 --> 00:00:36,200
change request.

15
00:00:36,200 --> 00:00:39,960
More demand can trigger it, late orders can trigger it, a new product mix can trigger it.

16
00:00:39,960 --> 00:00:43,640
Maybe one machining cell keeps becoming the bottleneck, or maybe staffing gaps force

17
00:00:43,640 --> 00:00:45,640
the same people to cover too much work.

18
00:00:45,640 --> 00:00:48,840
The pressure feels immediate, so the answer usually feels immediate too.

19
00:00:48,840 --> 00:00:52,320
Add capacity, add overtime, add stock.

20
00:00:52,320 --> 00:00:55,720
But before you ask the factory to absorb a change, there's a better question can you test

21
00:00:55,720 --> 00:00:56,720
it first?

22
00:00:56,720 --> 00:01:00,240
Test it in the abstract, test the actual operating conditions you expect.

23
00:01:00,240 --> 00:01:03,360
What happens if demand rises, but inspection stays flat?

24
00:01:03,360 --> 00:01:06,320
What happens if the extra shift has fewer qualified operators?

25
00:01:06,320 --> 00:01:08,160
What happens if you reduce work in progress?

26
00:01:08,160 --> 00:01:10,320
Then a supplier delivery arrives late.

27
00:01:10,320 --> 00:01:13,880
Simulation gives you a way to ask those questions before the consequences become overtime,

28
00:01:13,880 --> 00:01:15,840
expediting, and misdelivery dates.

29
00:01:15,840 --> 00:01:20,640
Let me give you a concrete example, a capacity change that looks obvious at first, but isn't.

30
00:01:20,640 --> 00:01:23,720
A simple capacity change with non-simple consequences.

31
00:01:23,720 --> 00:01:26,440
Picture a plant with a machining cell that feeds final assembly.

32
00:01:26,440 --> 00:01:30,600
The cell contains a constrained resource, and then maybe a CNC machine, maybe a specialist

33
00:01:30,600 --> 00:01:33,000
process that only a few people can run.

34
00:01:33,000 --> 00:01:35,680
Orders collect there, planners keep moving dates around.

35
00:01:35,680 --> 00:01:39,600
Sales are started asking why lead times keep stretching, someone proposes an extra shift,

36
00:01:39,600 --> 00:01:41,160
the logic sounds reasonable.

37
00:01:41,160 --> 00:01:44,120
If the machine runs for more hours, it should produce more parts.

38
00:01:44,120 --> 00:01:45,800
More parts should feed assembly.

39
00:01:45,800 --> 00:01:47,360
Assembly should ship more orders.

40
00:01:47,360 --> 00:01:48,360
Problem solved.

41
00:01:48,360 --> 00:01:50,440
Except factories don't work as a straight line.

42
00:01:50,440 --> 00:01:53,440
Say the machining cell adds a late shift from Monday through Thursday.

43
00:01:53,440 --> 00:01:57,760
The machine can run, but the cell needs a qualified operator, materials ready at the point

44
00:01:57,760 --> 00:02:02,680
of use, the right tools available, and a maintenance plan that still protects the equipment.

45
00:02:02,680 --> 00:02:06,480
If the extra shift eats into the normal maintenance window, the plant may gain output this

46
00:02:06,480 --> 00:02:08,520
week and lose availability later.

47
00:02:08,520 --> 00:02:12,760
So already, it's not as simple as "more hours equals more capacity".

48
00:02:12,760 --> 00:02:14,760
Now follow the parts downstream.

49
00:02:14,760 --> 00:02:18,840
Assembly receives more machine components, but can assembly absorb them at the same rate?

50
00:02:18,840 --> 00:02:21,120
Maybe the assembly team works only two shifts.

51
00:02:21,120 --> 00:02:24,660
If you've finished units wait for a final test station, maybe the test station needs an

52
00:02:24,660 --> 00:02:28,960
engineer to release certain product variants, and that engineer isn't on the late shift.

53
00:02:28,960 --> 00:02:33,080
The machining cell then looks busy, its utilization rises, yet the customer still doesn't

54
00:02:33,080 --> 00:02:34,720
receive the order any earlier.

55
00:02:34,720 --> 00:02:38,280
This is more common than most planners want to admit because local output and customer

56
00:02:38,280 --> 00:02:40,200
service are different measures.

57
00:02:40,200 --> 00:02:44,200
A machine can run flat out, while the factory creates a bigger queue somewhere else.

58
00:02:44,200 --> 00:02:46,440
You haven't removed the constraint, you've moved it.

59
00:02:46,440 --> 00:02:47,560
Let's add another detail.

60
00:02:47,560 --> 00:02:50,320
The machining cell processes several part families.

61
00:02:50,320 --> 00:02:52,400
One family runs quickly with minimal setup.

62
00:02:52,400 --> 00:02:55,840
Another needs a fixture change, a tool check and an inspection step before assembly can

63
00:02:55,840 --> 00:02:56,920
use the part.

64
00:02:56,920 --> 00:03:00,640
When demand shifts to what the harder family, the extra shift may produce fewer completed

65
00:03:00,640 --> 00:03:02,800
parts than the simple calculation predicted.

66
00:03:02,800 --> 00:03:04,560
The calendar showed available hours.

67
00:03:04,560 --> 00:03:07,040
It didn't show the work inside those hours, then there are people.

68
00:03:07,040 --> 00:03:11,520
A plant may have enough head count on paper, but not enough coverage, where the work actually

69
00:03:11,520 --> 00:03:12,520
happens.

70
00:03:12,520 --> 00:03:15,280
One operator can load material but can't approve a setup.

71
00:03:15,280 --> 00:03:19,360
Another can run the machine, but needs a second person for certain lifting or quality checks.

72
00:03:19,360 --> 00:03:23,160
A supervisor may need to be present before a new employee can work independently.

73
00:03:23,160 --> 00:03:27,080
A staffing plan based only on names and shift totals misses all of that.

74
00:03:27,080 --> 00:03:29,200
Materials apply can also break the simple plan.

75
00:03:29,200 --> 00:03:33,840
More machining output creates higher and earlier demand for raw material, cutters, inserts,

76
00:03:33,840 --> 00:03:35,600
fixtures and consumables.

77
00:03:35,600 --> 00:03:40,320
If purchasing stores or internal logistics still replenish on the old rhythm, the extra shift

78
00:03:40,320 --> 00:03:42,120
spends part of its time waiting.

79
00:03:42,120 --> 00:03:44,400
You paid for hours, but the machine didn't cut metal.

80
00:03:44,400 --> 00:03:45,760
Then think about inspection.

81
00:03:45,760 --> 00:03:48,400
Some factories treat inspection as a final gate.

82
00:03:48,400 --> 00:03:49,680
Others inspect during the route.

83
00:03:49,680 --> 00:03:55,000
Either way, releasing more work from machining can create a hidden pile of parts waiting for checks.

84
00:03:55,000 --> 00:03:58,880
That queue may not show up in the original capacity proposal because the proposal focused

85
00:03:58,880 --> 00:04:01,080
on the loudest bottleneck, not the full flow.

86
00:04:01,080 --> 00:04:02,600
There's also the customer promise.

87
00:04:02,600 --> 00:04:05,640
Imagine two planners looking at the same extra shift proposal.

88
00:04:05,640 --> 00:04:07,640
One sees higher output at the machining cell.

89
00:04:07,640 --> 00:04:12,000
The other sees orders with fixed ship dates, limited assembly slots and a shortage of packing

90
00:04:12,000 --> 00:04:13,480
capacity at month end.

91
00:04:13,480 --> 00:04:14,960
Both are looking at the same factory.

92
00:04:14,960 --> 00:04:16,520
They're just asking different questions.

93
00:04:16,520 --> 00:04:18,920
The first asks, can we run more hours?

94
00:04:18,920 --> 00:04:21,960
The second asks, can we deliver more orders on time?

95
00:04:21,960 --> 00:04:23,120
Those answers can differ.

96
00:04:23,120 --> 00:04:24,920
This doesn't mean the extra shift is a bad idea.

97
00:04:24,920 --> 00:04:28,400
It might be exactly the right choice, but it needs testing against the constraints that

98
00:04:28,400 --> 00:04:31,920
shape the actual result, not against a simple rate calculation.

99
00:04:31,920 --> 00:04:34,120
Think of the proposed change as the first domino.

100
00:04:34,120 --> 00:04:39,280
The hard work is tracing where the next domino's fall, where work waits, who needs to act,

101
00:04:39,280 --> 00:04:42,840
and which customer commitments move when the system comes under pressure.

102
00:04:42,840 --> 00:04:45,040
That's the role of factory simulation.

103
00:04:45,040 --> 00:04:47,480
That factory simulation actually means.

104
00:04:47,480 --> 00:04:51,200
When I say factory simulation, I don't mean a glossy 3D model with animated forklifts

105
00:04:51,200 --> 00:04:53,360
driving around a virtual plant.

106
00:04:53,360 --> 00:04:56,720
That kind of thing helps communicate an idea, but it's not the point.

107
00:04:56,720 --> 00:05:02,640
A useful simulation is a controlled model of how work moves through part of your factory.

108
00:05:02,640 --> 00:05:04,360
It takes the rules you run under today.

109
00:05:04,360 --> 00:05:08,600
The resources you depend on, the orders you need to process, and the normal variation

110
00:05:08,600 --> 00:05:10,160
that disrupts every plan.

111
00:05:10,160 --> 00:05:13,000
Then you change one condition and see how the system responds.

112
00:05:13,000 --> 00:05:17,000
You can test an extra shift without asking anyone to work it, test a new machine without buying

113
00:05:17,000 --> 00:05:21,360
it, test a smaller buffer without starving a real assembly line, and test a different product

114
00:05:21,360 --> 00:05:25,560
mix without putting customer delivery dates at risk just to see if the plan actually holds

115
00:05:25,560 --> 00:05:26,560
up.

116
00:05:26,560 --> 00:05:29,800
Think of it as a flight simulator, but with fewer buttons and much more material waiting

117
00:05:29,800 --> 00:05:30,800
in queues.

118
00:05:30,800 --> 00:05:34,840
The goal isn't to produce a perfect copy of every bolt, person, and pallet in the plant.

119
00:05:34,840 --> 00:05:39,280
It's to model enough of the real operating rules, so a decision can be tested in a believable

120
00:05:39,280 --> 00:05:40,280
way.

121
00:05:40,280 --> 00:05:42,440
That word believable matters more than perfect.

122
00:05:42,440 --> 00:05:44,520
No factory model knows the future.

123
00:05:44,520 --> 00:05:48,560
Demand can change, a supplier can miss a delivery, and a tool can fail at the least helpful

124
00:05:48,560 --> 00:05:50,680
moment as tools always do.

125
00:05:50,680 --> 00:05:51,680
Simulation doesn't remove uncertainty.

126
00:05:51,680 --> 00:05:55,360
It gives that uncertainty a place in the decision before it shows up on the shop floor.

127
00:05:55,360 --> 00:05:59,880
So instead of asking what will happen next Tuesday at 10/17, you ask a more useful question.

128
00:05:59,880 --> 00:06:03,320
If we change this operating rule, what range of outcomes should we expect under normal

129
00:06:03,320 --> 00:06:06,160
conditions and what happens when the day goes badly?

130
00:06:06,160 --> 00:06:08,080
That's a different kind of planning conversation.

131
00:06:08,080 --> 00:06:10,440
A simulation contains the things that shape flow.

132
00:06:10,440 --> 00:06:12,920
It knows and order needs a route through operations.

133
00:06:12,920 --> 00:06:17,840
A resource has a calendar and may not run all the time, and it can represent setup time, queues,

134
00:06:17,840 --> 00:06:22,240
batch rules, material readiness, inspection holds, and labor availability, where those things

135
00:06:22,240 --> 00:06:23,840
affect the decision you're testing.

136
00:06:23,840 --> 00:06:25,240
It also needs decision rules.

137
00:06:25,240 --> 00:06:28,120
When two work orders wait for the same machine, for example, what happens?

138
00:06:28,120 --> 00:06:30,120
Does the earliest due date go first?

139
00:06:30,120 --> 00:06:33,600
Does the planner group parts by product family to reduce changeovers?

140
00:06:33,600 --> 00:06:35,920
Does a customer priority override the queue?

141
00:06:35,920 --> 00:06:39,640
Or does the machine wait until a full batch arrives before starting?

142
00:06:39,640 --> 00:06:41,040
Those rules shape output.

143
00:06:41,040 --> 00:06:42,560
They aren't just admin detail.

144
00:06:42,560 --> 00:06:46,400
A model without them can still produce numbers, but those numbers don't describe how your

145
00:06:46,400 --> 00:06:47,640
factory actually behaves.

146
00:06:47,640 --> 00:06:51,520
They describe a cleaner factory with fewer arguments and fewer exceptions than the one you

147
00:06:51,520 --> 00:06:52,520
run.

148
00:06:52,520 --> 00:06:55,240
Most production teams would recognize that factory immediately.

149
00:06:55,240 --> 00:06:57,040
It's the one that exists in PowerPoint.

150
00:06:57,040 --> 00:07:00,000
The point of simulation is not to find one magic answer.

151
00:07:00,000 --> 00:07:01,320
You compare choices.

152
00:07:01,320 --> 00:07:05,080
Maybe you run the same demand through the current setup, then an extra shift plan, then

153
00:07:05,080 --> 00:07:07,040
a plan with a different release rule.

154
00:07:07,040 --> 00:07:08,720
You don't ask the model to decide for you.

155
00:07:08,720 --> 00:07:13,880
You ask it to expose the likely effects, the trade-offs, and the weak points in each option.

156
00:07:13,880 --> 00:07:18,080
One option might increase total output, but push more orders past their due dates.

157
00:07:18,080 --> 00:07:20,920
Another might protect on-time delivery but require more setup work.

158
00:07:20,920 --> 00:07:24,680
A third might work only if a qualified operator covers a specific period.

159
00:07:24,680 --> 00:07:28,120
Those are practical findings that give planners and production leaders something concrete

160
00:07:28,120 --> 00:07:29,120
to discuss.

161
00:07:29,120 --> 00:07:31,280
That's also why simulation differs from a dashboard.

162
00:07:31,280 --> 00:07:33,840
A dashboard reports what happened or what is happening now.

163
00:07:33,840 --> 00:07:38,480
It can tell you a machine stopped, backlog increased, or a work center produced fewer units than

164
00:07:38,480 --> 00:07:39,480
planned.

165
00:07:39,480 --> 00:07:42,920
Those facts matter, but the dashboard doesn't run an alternative future where you change

166
00:07:42,920 --> 00:07:44,960
the shift pattern and compare the result.

167
00:07:44,960 --> 00:07:46,240
It describes the factory.

168
00:07:46,240 --> 00:07:47,600
It doesn't rehearse the decision.

169
00:07:47,600 --> 00:07:48,960
A spreadsheet can go further.

170
00:07:48,960 --> 00:07:54,240
You can calculate capacity, load, labor hours, and planned output, and for a stable process

171
00:07:54,240 --> 00:07:56,720
with few constraints that may be enough.

172
00:07:56,720 --> 00:08:00,200
Spreadsheets stay popular because they let experienced people test ideas quickly, and they're

173
00:08:00,200 --> 00:08:03,360
often the only place where local knowledge has been written down.

174
00:08:03,360 --> 00:08:06,240
But spreadsheets tend to struggle when timing and interaction matter.

175
00:08:06,240 --> 00:08:10,200
They can calculate that two operations each have enough hours across a week, but they

176
00:08:10,200 --> 00:08:13,560
don't naturally show what happens when work reaches the second operation in the wrong

177
00:08:13,560 --> 00:08:17,840
sequence, waits for an inspection release, then blocks the first operation from sending

178
00:08:17,840 --> 00:08:19,120
more work forward.

179
00:08:19,120 --> 00:08:22,920
You can build that logic into a spreadsheet, but eventually you've built a simulation engine

180
00:08:22,920 --> 00:08:23,920
in cells.

181
00:08:23,920 --> 00:08:28,280
At that point, Excel has quietly become the factory platform Microsoft Never Planned.

182
00:08:28,280 --> 00:08:30,640
A simulation model follows events over time.

183
00:08:30,640 --> 00:08:35,280
When order arrives, a machine becomes free, material becomes available, a shift ends, a

184
00:08:35,280 --> 00:08:37,040
quality hold stops a batch.

185
00:08:37,040 --> 00:08:39,960
The model applies the rules you gave it and records the result.

186
00:08:39,960 --> 00:08:43,680
Then you repeat the same scenario with a change condition and compare what changed.

187
00:08:43,680 --> 00:08:46,480
That comparison is where the decision value comes from.

188
00:08:46,480 --> 00:08:50,200
Before anyone trusts a model with a large capacity decision, start with a real production

189
00:08:50,200 --> 00:08:52,200
question people already care about.

190
00:08:52,200 --> 00:08:55,120
Not, can we model the whole factory?

191
00:08:55,120 --> 00:08:58,840
That question can consume a lot of time and produce a very expensive conversation.

192
00:08:58,840 --> 00:09:02,600
First, instead, what decision do we need to make and what would we change if the model

193
00:09:02,600 --> 00:09:03,960
showed us a risk?

194
00:09:03,960 --> 00:09:06,560
That keeps the model tied to work that matters.

195
00:09:06,560 --> 00:09:08,200
The question's worth simulating.

196
00:09:08,200 --> 00:09:13,040
A simulation earns its place when it sits beside a decision someone must make soon, not

197
00:09:13,040 --> 00:09:16,440
a broad question like how can we digitize the plant?

198
00:09:16,440 --> 00:09:18,000
Ask something more direct.

199
00:09:18,000 --> 00:09:21,200
Should we add a weekend shift at this work center, can we take this new order mix without

200
00:09:21,200 --> 00:09:24,800
missing current commitments or would an extra buffer protect the line or just create

201
00:09:24,800 --> 00:09:26,480
more work in progress?

202
00:09:26,480 --> 00:09:30,840
The decision should have an owner, the production manager, the planner, the operations director,

203
00:09:30,840 --> 00:09:33,480
or the person responsible for a specific product family.

204
00:09:33,480 --> 00:09:37,800
That person needs to know what action the model can inform because a simulation that answers

205
00:09:37,800 --> 00:09:42,080
no real decision eventually becomes another report people stop opening.

206
00:09:42,080 --> 00:09:45,560
Capacity questions often come first because they carry cost and pressure.

207
00:09:45,560 --> 00:09:50,000
You might be considering a new machine, an alternate resource, subcontracting one operation

208
00:09:50,000 --> 00:09:52,920
or changing the available hours on a constrained process.

209
00:09:52,920 --> 00:09:57,480
The model can test the proposal against real order flow rather than a broad weekly capacity

210
00:09:57,480 --> 00:09:58,480
total.

211
00:09:58,480 --> 00:10:01,640
That changes the question from, do we have enough hours?

212
00:10:01,640 --> 00:10:05,680
To which orders finish earlier, where does the queue move and what happens to the orders

213
00:10:05,680 --> 00:10:07,040
already in the system?

214
00:10:07,040 --> 00:10:08,720
Staffing questions need the same discipline.

215
00:10:08,720 --> 00:10:13,240
A plant can add head count, approve overtime, change break cover, or cross train people for

216
00:10:13,240 --> 00:10:14,440
another operation.

217
00:10:14,440 --> 00:10:16,960
But people aren't interchangeable capacity units.

218
00:10:16,960 --> 00:10:20,840
A person may work a shift but lack the approval, training or experience needed at the

219
00:10:20,840 --> 00:10:22,600
operation causing the delay.

220
00:10:22,600 --> 00:10:24,080
So test the coverage that matters.

221
00:10:24,080 --> 00:10:28,320
If you add an operator to a shift, can that person run the bottleneck resource?

222
00:10:28,320 --> 00:10:32,120
Complete the inspection check and cover a break without stopping the process.

223
00:10:32,120 --> 00:10:35,760
If cross training becomes part of the plan, what work can move immediately and what still

224
00:10:35,760 --> 00:10:37,160
needs supervision?

225
00:10:37,160 --> 00:10:39,240
That produces a more honest labor discussion.

226
00:10:39,240 --> 00:10:43,000
You stop talking about total heads in the building and start talking about qualified coverage

227
00:10:43,000 --> 00:10:44,720
when and where the work needs it.

228
00:10:44,720 --> 00:10:47,960
Buffers deserve testing too, although they often get changed by instinct.

229
00:10:47,960 --> 00:10:51,200
When lead times grow, people add stock between operations.

230
00:10:51,200 --> 00:10:53,960
When inventory becomes uncomfortable, people remove it.

231
00:10:53,960 --> 00:10:57,520
Both reactions can make sense depending on the process, but the right buffer depends on

232
00:10:57,520 --> 00:11:01,200
where variation enters the flow and what the next operation can absorb.

233
00:11:01,200 --> 00:11:05,120
You can test a smaller work and progress buffer and ask whether the downstream process runs

234
00:11:05,120 --> 00:11:07,720
short when an upstream machine slows down.

235
00:11:07,720 --> 00:11:11,440
You can test a larger buffer and see whether it protects output or berries quality issues

236
00:11:11,440 --> 00:11:12,840
and stretches lead time.

237
00:11:12,840 --> 00:11:17,240
A buffer can protect flow, but it can also hide a planning problem behind a growing pile

238
00:11:17,240 --> 00:11:18,240
of parts.

239
00:11:18,240 --> 00:11:19,920
Product mix needs the same treatment.

240
00:11:19,920 --> 00:11:23,960
Two demand plans can contain the same number of units and put very different pressure on

241
00:11:23,960 --> 00:11:24,960
the factory.

242
00:11:24,960 --> 00:11:28,360
One mix might have parts with short roots and familiar setups.

243
00:11:28,360 --> 00:11:32,800
Another might need longer cycle times, specialist tools, extra inspections or more rework

244
00:11:32,800 --> 00:11:33,800
capacity.

245
00:11:33,800 --> 00:11:38,400
The total volume looks stable while the load on the actual constraint changes sharply.

246
00:11:38,400 --> 00:11:41,920
A simulation helps you test that shift before the orders hit the floor.

247
00:11:41,920 --> 00:11:45,680
You compare the current mix with a proposed mix and see what happens to throughput, queue

248
00:11:45,680 --> 00:11:48,200
time, resource load and due date risk.

249
00:11:48,200 --> 00:11:52,120
If the answer depends on sequencing certain families together, that becomes visible before

250
00:11:52,120 --> 00:11:54,200
the planers start fighting the schedule.

251
00:11:54,200 --> 00:11:57,600
Then there are disruption questions, which are often the most useful ones.

252
00:11:57,600 --> 00:12:01,960
What happens if a machine stops during the busiest period, a supplier shipment arrives late,

253
00:12:01,960 --> 00:12:06,280
a batch sits on quality hold, or an urgent customer order enters the queue halfway through

254
00:12:06,280 --> 00:12:07,600
the week.

255
00:12:07,600 --> 00:12:09,520
You're not trying to predict every problem.

256
00:12:09,520 --> 00:12:13,400
You're testing whether the operating plan can absorb normal bad days without turning

257
00:12:13,400 --> 00:12:15,560
every interruption into a crisis.

258
00:12:15,560 --> 00:12:18,400
For each scenario, decide what outcome you care about.

259
00:12:18,400 --> 00:12:23,440
It might be customer delivery performance, total output, lead time, overtime exposure,

260
00:12:23,440 --> 00:12:27,000
queue growth or the risk of starving a downstream operation.

261
00:12:27,000 --> 00:12:31,120
Pick measures that relate to the decision, not measures that are simply easy to collect.

262
00:12:31,120 --> 00:12:33,800
You also need to state the constraints that cannot move.

263
00:12:33,800 --> 00:12:36,480
Safety rules don't disappear because the model wants more output.

264
00:12:36,480 --> 00:12:41,440
Quality release steps, maintenance needs, labor agreements, material limits and customer

265
00:12:41,440 --> 00:12:44,920
commitments all shape the choices that remain available.

266
00:12:44,920 --> 00:12:46,880
And ask who's risk the proposal moves.

267
00:12:46,880 --> 00:12:50,680
An extra shift might relieve a machining queue while loading pressure onto quality.

268
00:12:50,680 --> 00:12:54,440
A smaller buffer might reduce stock while giving planners less room to recover from a late

269
00:12:54,440 --> 00:12:55,440
delivery.

270
00:12:55,440 --> 00:12:59,320
The model should make those transfers plain because someone will carry the consequence.

271
00:12:59,320 --> 00:13:02,560
Many planning tools can show demand, planned load and due dates.

272
00:13:02,560 --> 00:13:07,440
They often stop before they reach these shop floor choices, web time, sequence, people,

273
00:13:07,440 --> 00:13:09,080
and constraints collide.

274
00:13:09,080 --> 00:13:12,120
Why ERP planning doesn't answer the shop floor question?

275
00:13:12,120 --> 00:13:15,200
Your ERP system has one job, plan the business.

276
00:13:15,200 --> 00:13:19,360
It holds demand data, customer dates, bills of material, inventory positions, purchasing

277
00:13:19,360 --> 00:13:21,400
needs, routines and planned orders.

278
00:13:21,400 --> 00:13:24,160
Without it, you're flying blind on the commercial and material plan.

279
00:13:24,160 --> 00:13:25,320
That work matters.

280
00:13:25,320 --> 00:13:29,040
When sales accepts an order, procurement needs to know what to buy.

281
00:13:29,040 --> 00:13:31,440
Finance wants a view of supply and cost.

282
00:13:31,440 --> 00:13:33,360
Production needs work orders to execute.

283
00:13:33,360 --> 00:13:38,160
ERP pulls those decisions into one place, often across plants, warehouses and long supply

284
00:13:38,160 --> 00:13:39,000
chains.

285
00:13:39,000 --> 00:13:41,800
It pans the factory a plan with dates and priorities.

286
00:13:41,800 --> 00:13:45,600
But here's the thing, a plan at that level can't always tell you what to do on the floor during

287
00:13:45,600 --> 00:13:46,600
the next shift.

288
00:13:46,600 --> 00:13:47,600
Take a plan routing.

289
00:13:47,600 --> 00:13:52,560
It might show that part A needs machining, then cleaning, then assembly, then final test.

290
00:13:52,560 --> 00:13:53,840
That's the intended path.

291
00:13:53,840 --> 00:13:57,160
But what the routing won't tell you is that machining needs a particular fixture that

292
00:13:57,160 --> 00:14:01,840
fixture is already booked and only one operator on the shift can sign off the setup for that part

293
00:14:01,840 --> 00:14:02,840
family.

294
00:14:02,840 --> 00:14:05,480
Those details decide whether the planned order can actually move.

295
00:14:05,480 --> 00:14:08,120
ERP also tends to work with capacity at a broad level.

296
00:14:08,120 --> 00:14:11,800
A work centre has a calendar and a planned number of available hours.

297
00:14:11,800 --> 00:14:14,080
That's fine for rough cut capacity planning.

298
00:14:14,080 --> 00:14:16,600
Checking whether demand broadly exceeds what the site can handle.

299
00:14:16,600 --> 00:14:19,160
A finite shop floor runs under tighter limits.

300
00:14:19,160 --> 00:14:22,680
Two orders both need the same machine but only one can run first.

301
00:14:22,680 --> 00:14:24,600
One job might require a long setup.

302
00:14:24,600 --> 00:14:26,840
Another might share tooling with a job already running.

303
00:14:26,840 --> 00:14:31,640
A third has all parts available except for one bought in component, still on a truck somewhere.

304
00:14:31,640 --> 00:14:33,400
The calendar says there's capacity.

305
00:14:33,400 --> 00:14:35,080
The floor has a sequence problem.

306
00:14:35,080 --> 00:14:39,400
In sequence changes the answer, consider a machining resource with 8 available hours.

307
00:14:39,400 --> 00:14:43,320
ERP sees two jobs that each need four hours, load looks fine.

308
00:14:43,320 --> 00:14:46,880
But if each job needs a two hour change over and only one operator can do those changes,

309
00:14:46,880 --> 00:14:47,880
the day doesn't fit.

310
00:14:47,880 --> 00:14:52,200
The machine can't process 16 hours of work inside 8 hours just because the routing rates

311
00:14:52,200 --> 00:14:53,200
looked clean.

312
00:14:53,200 --> 00:14:57,360
This is why planned capacity and capacity that can actually run on the same thing, available

313
00:14:57,360 --> 00:14:59,520
capacity depends on more than the machine.

314
00:14:59,520 --> 00:15:03,520
It depends on the operator, tool, fixture, program, material, maintenance window, quality

315
00:15:03,520 --> 00:15:06,640
support and the work already waiting in front of that resource.

316
00:15:06,640 --> 00:15:09,040
Some of those constraints sit in different systems.

317
00:15:09,040 --> 00:15:11,040
Some live in local work instructions.

318
00:15:11,040 --> 00:15:14,680
Some live in the heads of experienced people who know which combinations create trouble.

319
00:15:14,680 --> 00:15:16,520
None of that means ERP has failed.

320
00:15:16,520 --> 00:15:17,880
It means ERP has a different job.

321
00:15:17,880 --> 00:15:21,880
It should plan, demand materials, supply and broad production needs.

322
00:15:21,880 --> 00:15:25,280
It should provide the commercial frame that production works within.

323
00:15:25,280 --> 00:15:29,280
Asking it to model every dispatching decision setup rule, labor qualification, shortstop

324
00:15:29,280 --> 00:15:34,440
and local exception turns a useful enterprise system into a poor imitation of a shop floor

325
00:15:34,440 --> 00:15:35,440
engine.

326
00:15:35,440 --> 00:15:37,480
You can add more detail to ERP.

327
00:15:37,480 --> 00:15:40,800
Many organizations do and sometimes that helps, but there's a practical limit.

328
00:15:40,800 --> 00:15:45,480
Each extra rule needs data, ownership, maintenance and a clear reason to exist.

329
00:15:45,480 --> 00:15:48,920
If plan is still override the result every morning because the system can't see what they

330
00:15:48,920 --> 00:15:51,320
see, then more fields haven't solved the problem.

331
00:15:51,320 --> 00:15:52,920
They've just given it a larger form.

332
00:15:52,920 --> 00:15:54,160
Think about a late order.

333
00:15:54,160 --> 00:15:57,920
ERP can show the due date, the planned route, the material demand and perhaps the work

334
00:15:57,920 --> 00:15:58,920
center load.

335
00:15:58,920 --> 00:16:01,080
A planner still needs to decide.

336
00:16:01,080 --> 00:16:05,640
Release the order now, hold it for missing material, place it ahead of another job, group

337
00:16:05,640 --> 00:16:10,280
it with a similar setup or send part of the route to an approved alternate resource.

338
00:16:10,280 --> 00:16:12,720
Those choices depend on the state of the factory right now.

339
00:16:12,720 --> 00:16:16,520
They also depend on the rules that govern the next few hours, not just the planned result

340
00:16:16,520 --> 00:16:17,880
at the end of the week.

341
00:16:17,880 --> 00:16:22,000
That's where a simulation model can take the ERP plan as an input and test how it performs

342
00:16:22,000 --> 00:16:23,520
under finite conditions.

343
00:16:23,520 --> 00:16:25,480
ERP provides the work to be done.

344
00:16:25,480 --> 00:16:28,600
Dates, quantities, routes and material demand.

345
00:16:28,600 --> 00:16:32,320
The simulation asks whether that work can actually flow through the real constraints without

346
00:16:32,320 --> 00:16:34,240
creating a new problem somewhere else.

347
00:16:34,240 --> 00:16:36,880
Keep that distinction in mind when we bring mess into the conversation.

348
00:16:36,880 --> 00:16:38,840
ERP tells you what the business planned.

349
00:16:38,840 --> 00:16:42,600
MES can tell you much more about what production actually executed.

350
00:16:42,600 --> 00:16:45,120
Why mess history still isn't a future model?

351
00:16:45,120 --> 00:16:47,200
Your mess sits much closer to the work.

352
00:16:47,200 --> 00:16:50,760
It records what happened as an order moved through production.

353
00:16:50,760 --> 00:16:56,560
Start and finish times, quantities produced, scrap, quality results, machine stops, work

354
00:16:56,560 --> 00:17:00,040
order status and sometimes operator activity.

355
00:17:00,040 --> 00:17:03,040
That record matters because it replaces guesswork with evidence.

356
00:17:03,040 --> 00:17:07,640
If a routing claims an operation takes 20 minutes but MES history shows, it usually takes

357
00:17:07,640 --> 00:17:11,160
longer once setup, inspection and normal stops into the picture.

358
00:17:11,160 --> 00:17:13,680
You've found something worth investigating.

359
00:17:13,680 --> 00:17:17,440
Same deal when a machine appears available in a plan but production history shows recurring

360
00:17:17,440 --> 00:17:20,440
delays around tools, material or changeovers.

361
00:17:20,440 --> 00:17:24,040
MES gives you the trace of execution, but a trace isn't a future model.

362
00:17:24,040 --> 00:17:25,560
It tells you an order weighted.

363
00:17:25,560 --> 00:17:29,720
It doesn't tell you what would happen if you changed the Q rule, added a late shift, moved

364
00:17:29,720 --> 00:17:34,080
work to an alternate resource or released a different product mix into the same area.

365
00:17:34,080 --> 00:17:38,120
That difference can seem small until a planner needs an answer by the end of the day.

366
00:17:38,120 --> 00:17:40,560
Think about a machine that stopped several times last month.

367
00:17:40,560 --> 00:17:45,440
MES may record each stop, its duration and maybe the reason code selected at the time.

368
00:17:45,440 --> 00:17:48,440
You can calculate lost time and review patterns with the maintenance team.

369
00:17:48,440 --> 00:17:49,880
That supports better decisions.

370
00:17:49,880 --> 00:17:54,040
Still, the history alone can't decide how a proposed production plan behaves when the

371
00:17:54,040 --> 00:17:55,920
same kind of stop occurs next week.

372
00:17:55,920 --> 00:17:58,600
For that, you need more than a list of past events.

373
00:17:58,600 --> 00:18:01,000
You need rules for what work does when the resource stops.

374
00:18:01,000 --> 00:18:02,560
Does the queue remain in place?

375
00:18:02,560 --> 00:18:04,480
Can approved jobs move to another machine?

376
00:18:04,480 --> 00:18:05,840
Does a setup need to restart?

377
00:18:05,840 --> 00:18:07,960
Does the shift supervisor release overtime?

378
00:18:07,960 --> 00:18:11,080
Does inspection become the next constraint once the machine recovers?

379
00:18:11,080 --> 00:18:13,080
The MES may hold parts of those facts.

380
00:18:13,080 --> 00:18:15,120
The decision logic often sits somewhere else.

381
00:18:15,120 --> 00:18:16,480
OE makes this point clearly.

382
00:18:16,480 --> 00:18:20,840
OE combines availability, performance and quality into a measure of how effectively

383
00:18:20,840 --> 00:18:23,160
equipment ran against its planned time.

384
00:18:23,160 --> 00:18:26,360
It helps you spot lost patterns and focus improvement work.

385
00:18:26,360 --> 00:18:28,960
It gives teams a common way to discuss equipment performance.

386
00:18:28,960 --> 00:18:32,080
Yet, an OE result isn't a promise of future throughput.

387
00:18:32,080 --> 00:18:37,160
A machine with a strong OE result can still fail to protect customer dates if the wrong

388
00:18:37,160 --> 00:18:39,040
work arrives at the wrong time.

389
00:18:39,040 --> 00:18:43,320
A skilled operator isn't available or parts wait for a quality release.

390
00:18:43,320 --> 00:18:46,960
On the other side, a machine with lower OE may not threaten delivery if it has enough

391
00:18:46,960 --> 00:18:50,160
planned slack and a healthy buffer before the next operation.

392
00:18:50,160 --> 00:18:51,840
The measure tells you something real.

393
00:18:51,840 --> 00:18:54,480
It just doesn't contain the whole operating decision.

394
00:18:54,480 --> 00:18:57,320
This is where teams sometimes make an understandable mistake.

395
00:18:57,320 --> 00:19:01,560
They collect more MES data, add more reason codes and build a better report, hoping the future

396
00:19:01,560 --> 00:19:03,840
answer will appear through volume alone.

397
00:19:03,840 --> 00:19:07,120
Better history helps and poor history creates blind spots.

398
00:19:07,120 --> 00:19:10,400
But data collection can't replace a model of how choices affect flow.

399
00:19:10,400 --> 00:19:12,280
You need to describe the decision points.

400
00:19:12,280 --> 00:19:14,880
When demand enters the plant, which orders can start first.

401
00:19:14,880 --> 00:19:18,560
When materials arrive late, which jobs stay on hold and which can proceed, when a skilled

402
00:19:18,560 --> 00:19:21,960
operator goes home, which tasks can another person take over.

403
00:19:21,960 --> 00:19:25,080
When quality blocks a batch, how does that change the next queue?

404
00:19:25,080 --> 00:19:26,080
Those are behavior rules.

405
00:19:26,080 --> 00:19:29,720
They turn recorded events into a testable view of how the factory responds.

406
00:19:29,720 --> 00:19:33,360
A good simulation can use MES history to set realistic assumptions.

407
00:19:33,360 --> 00:19:36,280
Actual cycle time ranges can shape, process, duration.

408
00:19:36,280 --> 00:19:38,880
Recorder downtime patterns can inform disruption cases.

409
00:19:38,880 --> 00:19:42,800
Quality records can expose rework parts that the clean routing never captured.

410
00:19:42,800 --> 00:19:45,400
Work order progress can show where queues tend to build.

411
00:19:45,400 --> 00:19:48,540
But the model needs a conscious choice about what to do with those conditions.

412
00:19:48,540 --> 00:19:49,880
That's not a weakness in MES.

413
00:19:49,880 --> 00:19:52,480
It's a boundary between systems with different jobs.

414
00:19:52,480 --> 00:19:54,520
MES records and coordinates execution.

415
00:19:54,520 --> 00:19:58,440
A simulation uses operational evidence plus agreed rules to test a future operating

416
00:19:58,440 --> 00:20:00,000
choice before people carry it out.

417
00:20:00,000 --> 00:20:02,300
So when someone asks, can we trust the model?

418
00:20:02,300 --> 00:20:05,580
Don't answer by pointing only to the amount of MES history behind it.

419
00:20:05,580 --> 00:20:06,840
Ask a sharper question.

420
00:20:06,840 --> 00:20:10,140
Does the model behave like this part of the factory when conditions change?

421
00:20:10,140 --> 00:20:12,840
That brings us to the distinction underneath all of this.

422
00:20:12,840 --> 00:20:14,000
Data describes events.

423
00:20:14,000 --> 00:20:15,980
A factory model describes behavior.

424
00:20:15,980 --> 00:20:17,560
Data describes events.

425
00:20:17,560 --> 00:20:19,560
Data describes behavior.

426
00:20:19,560 --> 00:20:21,880
A factory generates facts constantly.

427
00:20:21,880 --> 00:20:23,200
An order enters the system.

428
00:20:23,200 --> 00:20:24,500
A machine changes state.

429
00:20:24,500 --> 00:20:25,660
An operator books time.

430
00:20:25,660 --> 00:20:26,500
A palette moves.

431
00:20:26,500 --> 00:20:28,020
A batch fails inspection.

432
00:20:28,020 --> 00:20:29,900
Inventory shifts location.

433
00:20:29,900 --> 00:20:33,260
Each fact might be correct, but the planning question still sits unanswered.

434
00:20:33,260 --> 00:20:36,020
Think about the data sitting across your systems right now.

435
00:20:36,020 --> 00:20:38,740
ERP knows the order, the due date, and the planned route.

436
00:20:38,740 --> 00:20:41,460
MES records operation status and quantity.

437
00:20:41,460 --> 00:20:44,100
The maintenance system flags a resource that needs work.

438
00:20:44,100 --> 00:20:46,020
Quality holds a failed test result.

439
00:20:46,020 --> 00:20:48,460
Labor records show who worked with shift.

440
00:20:48,460 --> 00:20:50,700
Those systems describe parts of the same factory.

441
00:20:50,700 --> 00:20:53,940
They don't automatically describe how those parts depend on each other when you change a

442
00:20:53,940 --> 00:20:56,020
rule that dependencies the model.

443
00:20:56,020 --> 00:21:00,180
Say a planner wants to move work from machine 12 to machine 14 because machine 12 has a

444
00:21:00,180 --> 00:21:01,020
growing queue.

445
00:21:01,020 --> 00:21:04,020
The data shows both machines can process the same product family.

446
00:21:04,020 --> 00:21:05,100
That looks promising.

447
00:21:05,100 --> 00:21:07,700
But can machine 14 run the current revision of the part?

448
00:21:07,700 --> 00:21:09,020
Does it need a different fixture?

449
00:21:09,020 --> 00:21:10,460
Is the correct tool available?

450
00:21:10,460 --> 00:21:13,580
Does the operator on that shift hold the right qualification?

451
00:21:13,580 --> 00:21:16,700
Does the route require an inspection step before or after the move?

452
00:21:16,700 --> 00:21:19,020
A list of records won't answer that by itself.

453
00:21:19,020 --> 00:21:23,300
The model needs to link the product to its approved process, the process to the resource,

454
00:21:23,300 --> 00:21:27,340
the resource to the tools and people it requires, and the order to its material and quality

455
00:21:27,340 --> 00:21:28,340
state.

456
00:21:28,340 --> 00:21:31,540
Then it can test the proposed move under the same rules people face on the floor.

457
00:21:31,540 --> 00:21:33,220
That's context, but it's also behavior.

458
00:21:33,220 --> 00:21:36,260
A factory model needs to know what happens over time.

459
00:21:36,260 --> 00:21:39,980
A job doesn't simply appear at every operation when the plan says it should.

460
00:21:39,980 --> 00:21:41,060
It waits for material.

461
00:21:41,060 --> 00:21:42,180
It waits for a machine.

462
00:21:42,180 --> 00:21:46,220
It may wait for a setup, a forklift, a first of approval, or the next shift.

463
00:21:46,220 --> 00:21:47,860
Those waits shape lead time.

464
00:21:47,860 --> 00:21:49,020
Queue rules matter as well.

465
00:21:49,020 --> 00:21:52,100
Some plants release work as soon as material becomes available.

466
00:21:52,100 --> 00:21:55,540
Others limit work in progress because too much released work creates a queue.

467
00:21:55,540 --> 00:21:56,740
Nobody can control.

468
00:21:56,740 --> 00:21:58,580
Some areas process by due date.

469
00:21:58,580 --> 00:22:02,620
Others run campaigns by family because cleaning, tooling, or setup takes too long between

470
00:22:02,620 --> 00:22:03,620
variants.

471
00:22:03,620 --> 00:22:05,620
None of those rules are just background detail.

472
00:22:05,620 --> 00:22:08,900
They create the factory behavior that the model needs to reproduce.

473
00:22:08,900 --> 00:22:10,100
Take a shift hand over.

474
00:22:10,100 --> 00:22:12,900
On paper, one shift ends and the next begins.

475
00:22:12,900 --> 00:22:17,740
In practice, work may pause while people exchange information, review quality concerns,

476
00:22:17,740 --> 00:22:21,700
confirm tool condition, or decide whether a partly completed batch can continue.

477
00:22:21,700 --> 00:22:23,620
Some processes can hand over cleanly.

478
00:22:23,620 --> 00:22:26,100
Others need the same operator to finish a critical stage.

479
00:22:26,100 --> 00:22:29,340
A model that treats every hour as identical will miss that.

480
00:22:29,340 --> 00:22:30,820
Transport also affects flow.

481
00:22:30,820 --> 00:22:35,100
Especially where the root crosses a large plant, a warehouse boundary, or a shared logistics

482
00:22:35,100 --> 00:22:36,100
team.

483
00:22:36,100 --> 00:22:38,660
A part can finish machining and still wait before it reaches inspection.

484
00:22:38,660 --> 00:22:41,700
The machine finished its work, but the order didn't move.

485
00:22:41,700 --> 00:22:45,800
This is how local performance reports can look healthy, while customer lead times keep

486
00:22:45,800 --> 00:22:46,800
stretching.

487
00:22:46,800 --> 00:22:49,460
Timing rules turn isolated facts into a working model.

488
00:22:49,460 --> 00:22:51,140
You also need to handle batch size.

489
00:22:51,140 --> 00:22:54,620
A process may run one piece at a time, or it may wait until enough work collects for a

490
00:22:54,620 --> 00:22:58,220
furnace load, a wash cycle, a paint run, or an inspection batch.

491
00:22:58,220 --> 00:23:02,220
Larger batches can reduce setup effort, but they can also hold urgent work in a queue longer

492
00:23:02,220 --> 00:23:03,540
than anyone expected.

493
00:23:03,540 --> 00:23:06,860
The model lets you test that trade off under a realistic demand pattern.

494
00:23:06,860 --> 00:23:10,400
That's where the term "digital twin" often enters the conversation and I think it needs

495
00:23:10,400 --> 00:23:11,600
a plain definition.

496
00:23:11,600 --> 00:23:16,420
In this context, a digital twin is a model connected to real operational facts, so it can

497
00:23:16,420 --> 00:23:19,940
represent the current condition and relationships of a physical process.

498
00:23:19,940 --> 00:23:22,380
It doesn't need to look like a virtual factory tour.

499
00:23:22,380 --> 00:23:26,900
A useful digital twin might know which resources are running, which orders wait in front of them,

500
00:23:26,900 --> 00:23:30,700
which materials are released, and which routes are valid for a product.

501
00:23:30,700 --> 00:23:34,700
It may feed a simulation with the current starting position, then test a capacity or staffing

502
00:23:34,700 --> 00:23:35,820
decision from there.

503
00:23:35,820 --> 00:23:38,500
The visual layer is optional, the operational model isn't.

504
00:23:38,500 --> 00:23:43,220
This also means a twin needs maintenance, products change, routing versions change, machines

505
00:23:43,220 --> 00:23:47,500
gain or lose capability, new fixtures arrive, people gain qualifications.

506
00:23:47,500 --> 00:23:51,220
If the model still follows last year's rules, it can calculate very quickly and still send

507
00:23:51,220 --> 00:23:55,060
people to what the wrong decision, fast, wrong answers, remain wrong answers.

508
00:23:55,060 --> 00:23:58,900
So don't start with a question like, where can we store all the factory data?

509
00:23:58,900 --> 00:24:03,020
Start with which relationships and timing rules decide whether this flow succeeds.

510
00:24:03,020 --> 00:24:07,220
That brings you from data collection to an operating model people can test.

511
00:24:07,220 --> 00:24:11,500
To see what that looks like in practice, let's follow one work order through the factory.

512
00:24:11,500 --> 00:24:13,500
Follow one work order through the factory.

513
00:24:13,500 --> 00:24:17,020
Take one work order for a machine component needed in a customer assembly.

514
00:24:17,020 --> 00:24:21,020
The order enters from ERP with a quantity, a due date, a routing and a list of required

515
00:24:21,020 --> 00:24:22,020
material.

516
00:24:22,020 --> 00:24:24,500
That sounds complete until you ask a simple question.

517
00:24:24,500 --> 00:24:26,300
Can this order actually start today?

518
00:24:26,300 --> 00:24:28,020
First, the model checks material status.

519
00:24:28,020 --> 00:24:31,740
The main raw material may sit in stock, but that doesn't automatically release the order.

520
00:24:31,740 --> 00:24:35,340
Perhaps the material needs a quality release, perhaps it has been allocated to a higher

521
00:24:35,340 --> 00:24:36,820
priority order.

522
00:24:36,820 --> 00:24:40,580
Or a bought-in, insert, seal or electronic part may still be missing.

523
00:24:40,580 --> 00:24:43,660
The order exists in the plan, but it can't yet enter the queue.

524
00:24:43,660 --> 00:24:47,420
Once the material clears, the routing tells the model where the work can go.

525
00:24:47,420 --> 00:24:50,300
Maybe the first operation normally runs on machine 12.

526
00:24:50,300 --> 00:24:54,340
That machine has a queue, a shift calendar and a setup state.

527
00:24:54,340 --> 00:24:57,980
The order can't simply jump to the front because the model knows the dispatch rule used

528
00:24:57,980 --> 00:24:58,980
in that area.

529
00:24:58,980 --> 00:25:02,780
If due date drives the queue, the work might move ahead of less urgent jobs.

530
00:25:02,780 --> 00:25:07,260
If the plant groups by product family, it may wait behind a similar part already on the

531
00:25:07,260 --> 00:25:08,260
machine.

532
00:25:08,260 --> 00:25:09,940
Neither choice is automatically right.

533
00:25:09,940 --> 00:25:13,700
One can protect the customer date while the other can cut change over time and preserve

534
00:25:13,700 --> 00:25:15,620
capacity for the rest of the week.

535
00:25:15,620 --> 00:25:20,700
That is where simulation starts to look like factory work, not a generic capacity calculation.

536
00:25:20,700 --> 00:25:24,500
The order reaches the machine, but the machine still needs the correct conditions.

537
00:25:24,500 --> 00:25:26,380
A fixture may need to be installed.

538
00:25:26,380 --> 00:25:28,020
The cutter may need replacement.

539
00:25:28,020 --> 00:25:30,660
The program revision must match the product revision.

540
00:25:30,660 --> 00:25:33,940
And the operator must have approval to complete the setup and first off check.

541
00:25:33,940 --> 00:25:37,060
A resource listed as available on a routing is only a possible route.

542
00:25:37,060 --> 00:25:40,140
The model needs to test whether it is a usable route at this moment.

543
00:25:40,140 --> 00:25:44,420
Imagine the planned operator is present, but their qualification only covers the standard

544
00:25:44,420 --> 00:25:45,740
version of the part.

545
00:25:45,740 --> 00:25:48,860
This order has a customer specific change that needs senior approval.

546
00:25:48,860 --> 00:25:51,940
The machine has free time, the person is there, yet the order waits.

547
00:25:51,940 --> 00:25:56,460
Because the actual constraint isn't machine time or headcount, it's qualified release.

548
00:25:56,460 --> 00:26:00,740
That kind of wait often gets lost in broad planning views after setup the part runs.

549
00:26:00,740 --> 00:26:03,060
Cycle time matters, but it isn't the only clock running.

550
00:26:03,060 --> 00:26:05,100
A batch may need a first off inspection.

551
00:26:05,100 --> 00:26:07,700
A process may create scrap or require rework.

552
00:26:07,700 --> 00:26:11,700
The model can represent those parts where they affect the decision rather than assuming

553
00:26:11,700 --> 00:26:15,420
every piece exits the operation in perfect condition because the routing would prefer

554
00:26:15,420 --> 00:26:16,420
quiet life.

555
00:26:16,420 --> 00:26:20,380
Suppose the first batch passes machining but inspection places it on hold.

556
00:26:20,380 --> 00:26:23,060
Maybe a measurement sits near a limit and quality needs to review it.

557
00:26:23,060 --> 00:26:25,380
The parts are physically complete at that operation.

558
00:26:25,380 --> 00:26:27,380
But they aren't available for the next one.

559
00:26:27,380 --> 00:26:28,580
Assembly can't use them yet.

560
00:26:28,580 --> 00:26:31,100
Visible stock and usable stock can differ quite a lot.

561
00:26:31,100 --> 00:26:34,540
Once the quality hold clears, the work moves to the next operation.

562
00:26:34,540 --> 00:26:39,020
That movement may depend on internal transport, a scheduled collection run or space in the

563
00:26:39,020 --> 00:26:40,020
receiving area.

564
00:26:40,020 --> 00:26:44,700
If the next operation has no room, the finished batch blocks the earlier process.

565
00:26:44,700 --> 00:26:48,580
Suddenly, the machining cell has worked done, but nowhere to put it.

566
00:26:48,580 --> 00:26:50,900
Local output can rise while flow slows down.

567
00:26:50,900 --> 00:26:52,820
Then assembly receives the components.

568
00:26:52,820 --> 00:26:56,940
Once assembly needs a matching component from another route, a kit of purchased parts,

569
00:26:56,940 --> 00:26:58,860
and an available test slot after build.

570
00:26:58,860 --> 00:27:03,340
The original work order now affects another order sequence, another team's labour plan,

571
00:27:03,340 --> 00:27:05,060
and potentially another customer date.

572
00:27:05,060 --> 00:27:08,180
A delay of 30 minutes at machining might not matter on its own.

573
00:27:08,180 --> 00:27:12,820
But if it misses the last inspection release before shift end, assembly may lose a full shift.

574
00:27:12,820 --> 00:27:16,220
If assembly then misses its test slot, packing moves to the next day.

575
00:27:16,220 --> 00:27:18,220
The customer sees a late shipment.

576
00:27:18,220 --> 00:27:21,460
Even though no single team saw a dramatic problem in its own area.

577
00:27:21,460 --> 00:27:25,140
That is how a small local delay turns into a delivery issue elsewhere.

578
00:27:25,140 --> 00:27:27,500
Behind every step, sit product process resource links.

579
00:27:27,500 --> 00:27:29,180
This product needs this routing version.

580
00:27:29,180 --> 00:27:31,020
This operation can run on these resources.

581
00:27:31,020 --> 00:27:33,620
This resource needs these tools and these qualified people.

582
00:27:33,620 --> 00:27:37,220
This batch needs this inspection before the next operation can begin.

583
00:27:37,220 --> 00:27:39,740
The order needs all of those conditions at the right time.

584
00:27:39,740 --> 00:27:43,740
A factory model connects those links and lets you test what happens when one of them changes.

585
00:27:43,740 --> 00:27:48,100
So if you propose an extra shift, a new machine, or a different Q rule, you aren't only

586
00:27:48,100 --> 00:27:50,900
asking whether one operation can produce more.

587
00:27:50,900 --> 00:27:53,900
You're asking whether the full order can reach the customer sooner.

588
00:27:53,900 --> 00:27:56,460
Under the rules and limits the factory already lives with.

589
00:27:56,460 --> 00:28:00,140
Before major decisions depend on that answer though, the model needs to earn trust.

590
00:28:00,140 --> 00:28:03,420
It should start with a decision people know well enough to challenge rather than trying

591
00:28:03,420 --> 00:28:06,340
to explain every corner of the plant in one attempt.

592
00:28:06,340 --> 00:28:08,620
Start with one decision, not the whole plant.

593
00:28:08,620 --> 00:28:13,100
Once you can trace a single work order through the model, the obvious next move is to go big.

594
00:28:13,100 --> 00:28:17,060
At every work centre, every product, every system, until you've built a digital twin

595
00:28:17,060 --> 00:28:18,060
for the entire site.

596
00:28:18,060 --> 00:28:19,460
I'd resist that urge.

597
00:28:19,460 --> 00:28:23,540
A factory wide model might become useful later, but it's a terrible first target.

598
00:28:23,540 --> 00:28:28,660
Every extra area you pull in brings more roots, more exceptions, more ownership squabbles,

599
00:28:28,660 --> 00:28:31,140
and more arguments about which rule is actually current.

600
00:28:31,140 --> 00:28:35,140
You can burn months mapping complexity before anyone learns whether the simulation actually

601
00:28:35,140 --> 00:28:37,020
helps make a real decision any better.

602
00:28:37,020 --> 00:28:39,100
So start where the pressure already sits.

603
00:28:39,100 --> 00:28:42,860
Maybe it's a constrained machining cell that keeps pushing work late.

604
00:28:42,860 --> 00:28:46,500
Maybe there's a shift change planned for one assembly line, or perhaps one product

605
00:28:46,500 --> 00:28:49,580
family creates unstable cues whenever demand rises.

606
00:28:49,580 --> 00:28:53,340
Pick a flow people know, a decision they revisit, and a boundary you can explain without

607
00:28:53,340 --> 00:28:55,580
needing to pull out a map of the whole plant.

608
00:28:55,580 --> 00:28:58,620
Keep the first question narrow enough that you can actually answer it.

609
00:28:58,620 --> 00:29:02,580
For example, if we add a late shift at the cell can we improve due date performance for

610
00:29:02,580 --> 00:29:07,860
this product family without creating an unmanageable cue in the next process?

611
00:29:07,860 --> 00:29:09,580
That gives the work a purpose.

612
00:29:09,580 --> 00:29:13,420
It also tells you what belongs in the model and what can stay outside for now.

613
00:29:13,420 --> 00:29:16,780
The model needs a clear starting point which means getting agreement on the current operating

614
00:29:16,780 --> 00:29:22,900
rules, the product mix, the staffing pattern, and the service target the team wants to protect.

615
00:29:22,900 --> 00:29:26,660
If people disagree about how the area works today that's actually useful, it exposes

616
00:29:26,660 --> 00:29:31,380
the assumptions that normally sit below the planning conversation, don't hide those assumptions.

617
00:29:31,380 --> 00:29:33,220
A planner might release work by due date.

618
00:29:33,220 --> 00:29:37,420
A production lead might hold work back until material and capacity looks stable.

619
00:29:37,420 --> 00:29:40,980
An operator might group jobs differently because they know a certain setup causes trouble

620
00:29:40,980 --> 00:29:42,100
late in the shift.

621
00:29:42,100 --> 00:29:45,940
All three views can contain part of the answer but the team needs to decide which rule the

622
00:29:45,940 --> 00:29:47,540
first scenario should test.

623
00:29:47,540 --> 00:29:50,700
Otherwise, the model becomes a debate with a spreadsheet attached.

624
00:29:50,700 --> 00:29:52,900
You also need a decision owner before you build much.

625
00:29:52,900 --> 00:29:56,260
Someone has to be able to say if the model shows this outcome, I'll consider changing

626
00:29:56,260 --> 00:29:57,660
the shift pattern.

627
00:29:57,660 --> 00:30:02,980
Or if this option reduces late orders but creates too much overtime, we'll reject it.

628
00:30:02,980 --> 00:30:06,420
Without that link to action, simulation becomes an interesting technical exercise that

629
00:30:06,420 --> 00:30:08,180
doesn't change how production runs.

630
00:30:08,180 --> 00:30:10,020
That happens more often than people admit.

631
00:30:10,020 --> 00:30:11,940
Define the output in plain terms too.

632
00:30:11,940 --> 00:30:16,660
The owner might need to compare late orders, queue time, resource loading or overtime exposure.

633
00:30:16,660 --> 00:30:19,460
They might need a range rather than one forecast.

634
00:30:19,460 --> 00:30:22,100
They might need to know which condition causes the plan to fail.

635
00:30:22,100 --> 00:30:26,540
Those needs shape the model more usefully than a broad request for better visibility.

636
00:30:26,540 --> 00:30:27,660
Visibility is easy to ask for.

637
00:30:27,660 --> 00:30:29,180
A decision needs a sharper question.

638
00:30:29,180 --> 00:30:34,260
Suppose the first project focuses on one constrained line and a planned weekend shift.

639
00:30:34,260 --> 00:30:37,820
You don't need every warehouse rule in the company model if the decision depends mostly

640
00:30:37,820 --> 00:30:43,980
on routing, line calendars, qualified coverage, upstream release and the capacity of the next

641
00:30:43,980 --> 00:30:45,020
process.

642
00:30:45,020 --> 00:30:48,900
You can represent external conditions at the level needed for this decision, then test

643
00:30:48,900 --> 00:30:51,380
whether the proposed shift changes the result.

644
00:30:51,380 --> 00:30:53,100
That scope boundary protects the project.

645
00:30:53,100 --> 00:30:56,780
It also gives operators and planners a chance to challenge the model while the problem is

646
00:30:56,780 --> 00:30:57,780
still familiar.

647
00:30:57,780 --> 00:31:02,660
They can spot a missing setup rule, an unrealistic handover assumption or an exception that happens

648
00:31:02,660 --> 00:31:04,620
often enough to change the result.

649
00:31:04,620 --> 00:31:07,020
Fixing those gaps in one area is manageable.

650
00:31:07,020 --> 00:31:10,340
Fixing them after you've modeled an entire plant is much less pleasant.

651
00:31:10,340 --> 00:31:13,980
Everyone wants a digital twin of everything, almost nobody wants to own the thousands of

652
00:31:13,980 --> 00:31:14,980
rules that follow.

653
00:31:14,980 --> 00:31:19,700
A focused model can earn trust because people can compare its behavior with work they already

654
00:31:19,700 --> 00:31:20,700
understand.

655
00:31:20,700 --> 00:31:23,260
Does it create queues in the places where queues usually build?

656
00:31:23,260 --> 00:31:24,980
Does it react sensibly when a shift ends?

657
00:31:24,980 --> 00:31:27,860
Does it show the same type of delivery pressure that planners see today?

658
00:31:27,860 --> 00:31:32,340
If it doesn't, you've learned where the model needs work before using it for a costly change.

659
00:31:32,340 --> 00:31:34,980
That's a good outcome, not failure, but learning.

660
00:31:34,980 --> 00:31:38,340
The first simulation project shouldn't prove that the factory is digital, it should help

661
00:31:38,340 --> 00:31:41,900
one accountable person test one change with less guesswork.

662
00:31:41,900 --> 00:31:44,980
Once that works, you can extend the model from a stable base instead of trying to repair

663
00:31:44,980 --> 00:31:47,180
a giant one, nobody fully understands.

664
00:31:47,180 --> 00:31:52,340
Next, you need to define normal operations well enough for the model to behave plausibly.

665
00:31:52,340 --> 00:31:55,100
Build a baseline that looks like normal operations.

666
00:31:55,100 --> 00:31:58,580
Before you test the proposed change, the model needs to handle today's operation in a way

667
00:31:58,580 --> 00:32:00,500
that the people running it recognize.

668
00:32:00,500 --> 00:32:01,660
Not perfectly.

669
00:32:01,660 --> 00:32:04,100
No model captures every small exception.

670
00:32:04,100 --> 00:32:08,140
And plausibly enough that a planner, operator or production lead can hear the result and

671
00:32:08,140 --> 00:32:10,820
say, yes, that's broadly how this area behaves.

672
00:32:10,820 --> 00:32:11,820
That starts with rootings.

673
00:32:11,820 --> 00:32:15,100
For the product family you're focusing on, document the root each order follows, including

674
00:32:15,100 --> 00:32:17,580
approved alternate roots where they really exist.

675
00:32:17,580 --> 00:32:21,420
Don't add an alternate machine just because it looks similar in a master data table.

676
00:32:21,420 --> 00:32:25,420
Confirm whether it can actually run the part with the current process revision, tooling,

677
00:32:25,420 --> 00:32:27,740
quality requirements, and normal labor coverage.

678
00:32:27,740 --> 00:32:29,900
Then capture the time behind each step.

679
00:32:29,900 --> 00:32:34,140
Normal time is often the first number people reach for, but a single average can hide the condition

680
00:32:34,140 --> 00:32:35,460
you're trying to understand.

681
00:32:35,460 --> 00:32:39,200
A part might run quickly once the process settles, while a first piece after a change over

682
00:32:39,200 --> 00:32:40,300
takes longer.

683
00:32:40,300 --> 00:32:43,660
Another part might run at different speeds depending on material grade, tool condition, or

684
00:32:43,660 --> 00:32:44,740
operator experience.

685
00:32:44,740 --> 00:32:46,220
Use a range where the work varies.

686
00:32:46,220 --> 00:32:50,020
That doesn't mean you need to turn every process into a statistical research project.

687
00:32:50,020 --> 00:32:53,260
It means the model should allow for the normal spread people see on the floor.

688
00:32:53,260 --> 00:32:58,460
If an operation usually takes somewhere between 18 and 25 minutes, a fixed 21 minute assumption

689
00:32:58,460 --> 00:33:01,780
might create a need plan that no shift ever experiences.

690
00:33:01,780 --> 00:33:03,260
Setups need the same treatment.

691
00:33:03,260 --> 00:33:07,060
Record what triggers a setup, how long it normally takes, and whether the sequence changes

692
00:33:07,060 --> 00:33:08,060
that time.

693
00:33:08,060 --> 00:33:11,380
A change from one part family to another might take much longer than moving between two

694
00:33:11,380 --> 00:33:12,620
related variants.

695
00:33:12,620 --> 00:33:17,080
Some setups require a qualified person, a first off inspection, or a fixture that has to

696
00:33:17,080 --> 00:33:18,420
arrive from another area.

697
00:33:18,420 --> 00:33:21,540
Those conditions affect when the machine can actually start.

698
00:33:21,540 --> 00:33:24,780
Calendars also need more detail than a weekly total of available hours.

699
00:33:24,780 --> 00:33:28,940
Local working shifts, planned breaks, shift handovers, scheduled maintenance, and known periods

700
00:33:28,940 --> 00:33:31,020
when support functions aren't available.

701
00:33:31,020 --> 00:33:35,180
If quality only releases a certain process during defined hours that belongs in the baseline,

702
00:33:35,180 --> 00:33:38,780
if material handling slows down during a handover included where it affects the flow you're

703
00:33:38,780 --> 00:33:39,780
testing.

704
00:33:39,780 --> 00:33:42,380
The model should use the factory's actual operating rhythm.

705
00:33:42,380 --> 00:33:43,940
Down time deserves careful handling too.

706
00:33:43,940 --> 00:33:47,100
You don't need to reproduce every historical stop one by one.

707
00:33:47,100 --> 00:33:51,060
Instead, use production evidence and local knowledge to define the patterns that matter.

708
00:33:51,060 --> 00:33:54,720
A resource might suffer short interruptions often or a longer stop less often and recovery

709
00:33:54,720 --> 00:33:58,260
might depend on who's present and where the spare parts are available.

710
00:33:58,260 --> 00:34:02,660
Those patterns shape capacity more honestly than a theoretical machine rate.

711
00:34:02,660 --> 00:34:05,380
Next comes the rules that decide how work waits and moves.

712
00:34:05,380 --> 00:34:08,060
Does the area release orders as soon as material clears?

713
00:34:08,060 --> 00:34:10,940
Does it hold work until a downstream resource can accept it?

714
00:34:10,940 --> 00:34:12,900
Does it process in fixed batches?

715
00:34:12,900 --> 00:34:16,180
Or can it run smaller lots when a due date starts to slip?

716
00:34:16,180 --> 00:34:20,100
Those choices affect queue lengths and lead time, inspection holds, and rework loops need

717
00:34:20,100 --> 00:34:21,500
to place in the model too.

718
00:34:21,500 --> 00:34:25,260
If a process regularly sends some work back for correction, removing that path creates

719
00:34:25,260 --> 00:34:26,260
false capacity.

720
00:34:26,260 --> 00:34:30,340
If inspection occasionally holds a batch until the next day, the model must show that delay

721
00:34:30,340 --> 00:34:31,820
when it changes downstream flow.

722
00:34:31,820 --> 00:34:35,100
Nobody needs a model that only works when every part behaves.

723
00:34:35,100 --> 00:34:37,700
This is also where you need to separate unknown from assumed.

724
00:34:37,700 --> 00:34:41,020
Teams sometimes feel pressure to fill every blank with one clean number.

725
00:34:41,020 --> 00:34:43,380
That creates a calm looking model built on guesses.

726
00:34:43,380 --> 00:34:47,100
It's better to record the gap, state the assumption, and test whether the decision changes

727
00:34:47,100 --> 00:34:49,940
when that assumption moves within a sensible range.

728
00:34:49,940 --> 00:34:53,660
And certainly doesn't disappear just because you type a number into a field.

729
00:34:53,660 --> 00:34:57,660
Once the baseline contains the main rules, compare it with the past production period.

730
00:34:57,660 --> 00:35:01,980
Choose a period that represents normal operation for the area, not an unusually quiet week

731
00:35:01,980 --> 00:35:03,500
or a major shutdown.

732
00:35:03,500 --> 00:35:07,860
Feed the model the same order pattern, staffing calendar and relevant starting conditions,

733
00:35:07,860 --> 00:35:10,620
then compare its output with what production experienced.

734
00:35:10,620 --> 00:35:13,980
You're looking for behavior, not a perfect replay.

735
00:35:13,980 --> 00:35:16,780
Did queues form in roughly the places where they usually form?

736
00:35:16,780 --> 00:35:19,540
Did the model produce a similar flow of completed work?

737
00:35:19,540 --> 00:35:23,500
Did it show pressure around the same shifts, process steps, or release points that planners

738
00:35:23,500 --> 00:35:24,500
remember?

739
00:35:24,500 --> 00:35:28,580
If it misses badly, don't tune the output until the numbers look attractive.

740
00:35:28,580 --> 00:35:32,500
Find the rule, timing assumption, or missing constraint behind the difference.

741
00:35:32,500 --> 00:35:34,660
Planar judgment belongs in this review.

742
00:35:34,660 --> 00:35:38,060
Experience planners might not describe their logic as a formal rule, but they often know

743
00:35:38,060 --> 00:35:39,940
why an apparently good schedule fails.

744
00:35:39,940 --> 00:35:42,660
They know that a supplier delivery needs checking before release.

745
00:35:42,660 --> 00:35:46,020
They know that a certain job should never follow another without extra cleaning.

746
00:35:46,020 --> 00:35:49,980
They know which resource only looks interchangeable until a difficult order arrives.

747
00:35:49,980 --> 00:35:54,020
Turn that knowledge into an explicit assumption where it affects the decision.

748
00:35:54,020 --> 00:35:55,780
Operators should review the baseline too.

749
00:35:55,780 --> 00:35:59,940
They can spot practical gaps that data alone won't expose, like a setup that requires two

750
00:35:59,940 --> 00:36:00,940
people.

751
00:36:00,940 --> 00:36:05,180
A material move that only happens on a regular route or a quality check that blocks a process

752
00:36:05,180 --> 00:36:07,620
longer than the system timestamps suggest.

753
00:36:07,620 --> 00:36:09,460
This isn't a challenge to the data team.

754
00:36:09,460 --> 00:36:11,180
It's how the model gets closer to the work.

755
00:36:11,180 --> 00:36:14,180
A baseline gains trust through those conversations.

756
00:36:14,180 --> 00:36:18,700
As the model improves, keep a record of the routing version, calendar, time ranges,

757
00:36:18,700 --> 00:36:21,740
queue rules, and assumptions used for each test.

758
00:36:21,740 --> 00:36:24,700
Factories change, and the model needs to change with them.

759
00:36:24,700 --> 00:36:27,860
Without that discipline, people eventually compare results from different rule sets and

760
00:36:27,860 --> 00:36:31,020
wonder why the same scenario produces a different answer.

761
00:36:31,020 --> 00:36:33,180
The baseline doesn't need to predict every single day.

762
00:36:33,180 --> 00:36:37,220
It needs to behave credibly under normal conditions, with its known gaps visible and its assumptions

763
00:36:37,220 --> 00:36:38,780
open to challenge.

764
00:36:38,780 --> 00:36:44,060
Only then can you test a capacity proposal without confusing a clean model with a real factory.

765
00:36:44,060 --> 00:36:49,700
Once your model behaves like normal production, you can finally test the question that usually

766
00:36:49,700 --> 00:36:51,620
starts the whole conversation.

767
00:36:51,620 --> 00:36:53,620
Do we actually need more capacity?

768
00:36:53,620 --> 00:36:55,380
And if so, where?

769
00:36:55,380 --> 00:36:57,700
Buying a machine feels like the direct answer.

770
00:36:57,700 --> 00:37:01,660
Faster resource, more output, less pressure, and sometimes that's the right call.

771
00:37:01,660 --> 00:37:02,660
But here's the problem.

772
00:37:02,660 --> 00:37:07,100
A capital request built on theoretical rate alone can send your money toward the wrong

773
00:37:07,100 --> 00:37:12,060
constraint, while the actual delay sits in a queue, an approval step, or a downstream

774
00:37:12,060 --> 00:37:14,940
process that has no room to absorb more work.

775
00:37:14,940 --> 00:37:19,020
So test your options before you commit, take a constrained operation where demand regularly

776
00:37:19,020 --> 00:37:21,260
exceeds available time.

777
00:37:21,260 --> 00:37:26,060
You have options, add a new machine, improve cycle time on the existing one, add more operating

778
00:37:26,060 --> 00:37:30,620
hours, root work to an alternate resource, or send part of it to a subcontractor.

779
00:37:30,620 --> 00:37:34,380
Each one changes the flow differently, and the first option that adds hours isn't always

780
00:37:34,380 --> 00:37:36,340
the one that improves delivery.

781
00:37:36,340 --> 00:37:39,420
Start with the current case by running the expected order pattern through the baseline

782
00:37:39,420 --> 00:37:43,740
model using the normal calendars, routing rules, and variation the production team already

783
00:37:43,740 --> 00:37:45,060
signed off on.

784
00:37:45,060 --> 00:37:46,580
That gives you a point of comparison.

785
00:37:46,580 --> 00:37:50,660
You can see current throughput, lead time through the affected area, queue growth, late

786
00:37:50,660 --> 00:37:53,580
orders, and resource load, then change one condition at a time.

787
00:37:53,580 --> 00:37:56,500
For a new machine, don't just plug in its nominal hourly rate.

788
00:37:56,500 --> 00:38:00,900
Give it a real calendar, with setup requirements, valid product families, tooling needs, plant

789
00:38:00,900 --> 00:38:03,460
maintenance, and the people needed to run it.

790
00:38:03,460 --> 00:38:06,620
If it can only process part of the demand, model that boundary.

791
00:38:06,620 --> 00:38:10,780
A machine that handles the easy work might free up the constrained resource for the difficult

792
00:38:10,780 --> 00:38:15,820
work, which can help a lot, but it could also create a new queue at a shared inspection point.

793
00:38:15,820 --> 00:38:20,540
For a faster cycle, test the full effect instead of just looking at saved minutes.

794
00:38:20,540 --> 00:38:23,620
Maybe a new tool cuts runtime but needs more frequent checks.

795
00:38:23,620 --> 00:38:27,300
Maybe a process improvement shortens one operation, but creates a smaller batch that arrives

796
00:38:27,300 --> 00:38:29,180
more often at the next station.

797
00:38:29,180 --> 00:38:32,860
Faster processing can improve flow, but it can also expose a limit the slower process

798
00:38:32,860 --> 00:38:34,380
had quietly masked.

799
00:38:34,380 --> 00:38:36,380
A few hours need the same discipline approach.

800
00:38:36,380 --> 00:38:41,060
A plan for more shifts can increase available time, but productive time depends on what can

801
00:38:41,060 --> 00:38:42,580
happen during those hours.

802
00:38:42,580 --> 00:38:46,700
If materials arrive only on the normal shift, if quality release stops before the late shift

803
00:38:46,700 --> 00:38:50,700
begins, or if maintenance loses its planned window, the new calendar may not produce the

804
00:38:50,700 --> 00:38:52,980
output people expect.

805
00:38:52,980 --> 00:38:54,980
Available hours aren't the same as productive hours.

806
00:38:54,980 --> 00:38:58,300
The model should separate theoretical rate from the time that actually produces released

807
00:38:58,300 --> 00:39:00,060
usable parts.

808
00:39:00,060 --> 00:39:03,500
Theoretical rate starts with the machine's best case cycle, while available productive

809
00:39:03,500 --> 00:39:08,700
time subtracts the hours lost to planned breaks, setup, maintenance, missing work, normal

810
00:39:08,700 --> 00:39:12,620
stops, and support constraints that stop and order from moving.

811
00:39:12,620 --> 00:39:15,300
That difference alone can change the entire investment case.

812
00:39:15,300 --> 00:39:18,820
Imagine the model shows a new machine lifts output at the first operation, but the queue

813
00:39:18,820 --> 00:39:20,820
before final inspection grows every day.

814
00:39:20,820 --> 00:39:25,220
The factory processes more work, yet customer orders still wait for the same release step.

815
00:39:25,220 --> 00:39:28,220
In that case, the new machine still has a purpose, but it doesn't solve the delivery

816
00:39:28,220 --> 00:39:29,500
problem on its own.

817
00:39:29,500 --> 00:39:30,500
The constraint has moved.

818
00:39:30,500 --> 00:39:34,580
This is why capacity testing needs to watch the whole affected flow, not just the resource

819
00:39:34,580 --> 00:39:35,740
under review.

820
00:39:35,740 --> 00:39:38,740
Track throughput, completed work that can proceed or ship.

821
00:39:38,740 --> 00:39:41,820
Track lead time, because more output at one point can still mean longer time through the

822
00:39:41,820 --> 00:39:42,820
factory.

823
00:39:42,820 --> 00:39:46,700
Watch queue growth and queue age, an ageing queue can expose future late orders before the

824
00:39:46,700 --> 00:39:48,420
missed dates even appear.

825
00:39:48,420 --> 00:39:52,260
Also track resource load, but don't treat high utilization as success by itself.

826
00:39:52,260 --> 00:39:56,260
A resource running near full load creates fragile flow because normal variation has nowhere

827
00:39:56,260 --> 00:39:57,260
to go.

828
00:39:57,260 --> 00:40:02,300
Stop, a late job or a long changeover can push work into the next shift.

829
00:40:02,300 --> 00:40:06,740
Some spare capacity at the right point protects delivery better than chasing maximum utilization

830
00:40:06,740 --> 00:40:07,740
across every machine.

831
00:40:07,740 --> 00:40:09,980
I know that sounds uncomfortable in a plant under pressure.

832
00:40:09,980 --> 00:40:14,180
Idol time looks wasteful when a backlog sits right there, but a resource with no recovery

833
00:40:14,180 --> 00:40:17,460
room can turn a minor disruption into a schedule problem.

834
00:40:17,460 --> 00:40:20,900
The model lets you compare that trade off with evidence instead of instinct.

835
00:40:20,900 --> 00:40:25,020
Run several plausible cases, one assumes expected demand and normal conditions, another

836
00:40:25,020 --> 00:40:27,940
tests higher demand or less favorable product mix.

837
00:40:27,940 --> 00:40:32,300
A third includes the new machine or extra shift but with realistic downtime and downstream

838
00:40:32,300 --> 00:40:33,300
limits.

839
00:40:33,300 --> 00:40:37,700
You're not after the most optimistic output figure, you want the option that still protects

840
00:40:37,700 --> 00:40:42,100
the outcome you care about when the plant hits ordinary factory variation.

841
00:40:42,100 --> 00:40:46,260
Sometimes the result says yes by the capacity, sometimes it points to a different answer.

842
00:40:46,260 --> 00:40:50,180
Better sequencing, targeted subcontracting or changing where work enters the flow.

843
00:40:50,180 --> 00:40:54,180
Either way the decision gets clearer because you can see exactly where the pressure moves,

844
00:40:54,180 --> 00:40:57,620
and capacity still depends on the people who can operate the process.

845
00:40:57,620 --> 00:40:58,900
Staffing is more than headcount.

846
00:40:58,900 --> 00:41:02,780
A capacity model can show a machine has time available, but that doesn't mean the operation

847
00:41:02,780 --> 00:41:04,020
can actually run.

848
00:41:04,020 --> 00:41:08,060
People turn planned capacity into productive capacity, and in many factories the real limit

849
00:41:08,060 --> 00:41:09,060
isn't the headcount.

850
00:41:09,060 --> 00:41:12,620
It's whether qualified people cover the right operation on the right shift when a specific

851
00:41:12,620 --> 00:41:14,740
order reaches that point in the route.

852
00:41:14,740 --> 00:41:16,180
Headcount can hide that problem.

853
00:41:16,180 --> 00:41:18,620
Picture a production area with ten people on a shift.

854
00:41:18,620 --> 00:41:22,940
On paper, the labour plan looks fine, but only two of them can set up the constraint machine,

855
00:41:22,940 --> 00:41:27,220
and can approve the first off-part, and another holds the certification for a special process

856
00:41:27,220 --> 00:41:29,540
several urgent orders require.

857
00:41:29,540 --> 00:41:34,140
If one of those people is absent, the area doesn't lose one tenth of its capacity.

858
00:41:34,140 --> 00:41:37,180
It may lose the ability to release certain work entirely.

859
00:41:37,180 --> 00:41:39,700
That's the distinction a useful simulation needs to capture.

860
00:41:39,700 --> 00:41:43,860
A person present in the building isn't always able to perform the task that controls flow.

861
00:41:43,860 --> 00:41:49,180
The model needs to represent skills, approvals, certifications, shift coverage, and sometimes

862
00:41:49,180 --> 00:41:50,380
supervision rules.

863
00:41:50,380 --> 00:41:54,980
The sketch practical very quickly, say you want to add output at a machining cell by assigning

864
00:41:54,980 --> 00:41:56,100
another operator.

865
00:41:56,100 --> 00:42:00,860
The first question isn't just whether they have free hours, can they load the machine independently,

866
00:42:00,860 --> 00:42:05,220
change the tooling, respond when the process drifts, and complete the checks to release first

867
00:42:05,220 --> 00:42:06,540
production parts.

868
00:42:06,540 --> 00:42:09,220
If the answer is no, you haven't added the same type of capacity.

869
00:42:09,220 --> 00:42:13,340
You may have added support capacity, which can still help, but the model needs to show

870
00:42:13,340 --> 00:42:14,580
that difference.

871
00:42:14,580 --> 00:42:17,660
A training matrix becomes part of the operating model here.

872
00:42:17,660 --> 00:42:19,620
It doesn't need to become an HR project.

873
00:42:19,620 --> 00:42:24,180
It just needs to state which work a person can perform under what conditions and whether

874
00:42:24,180 --> 00:42:26,180
they can work alone or need backup.

875
00:42:26,180 --> 00:42:28,380
That matters when you test changes.

876
00:42:28,380 --> 00:42:30,580
Cross training often sounds like the obvious answer.

877
00:42:30,580 --> 00:42:35,660
Train more people, create more flexibility, reduce dependency on a few experienced operators.

878
00:42:35,660 --> 00:42:39,740
I agree with the direction, but the model needs to treat cross training as a real operating

879
00:42:39,740 --> 00:42:40,740
change.

880
00:42:40,740 --> 00:42:41,740
Not a check box.

881
00:42:41,740 --> 00:42:45,900
A person in training works more slowly, needs supervision, and can't approve certain product

882
00:42:45,900 --> 00:42:46,900
variants.

883
00:42:46,900 --> 00:42:50,900
A experienced operator training them also spends time away from their normal work.

884
00:42:50,900 --> 00:42:55,060
And if quality risk rises during the learning period, that needs attention too.

885
00:42:55,060 --> 00:42:56,940
None of that argues against cross training.

886
00:42:56,940 --> 00:43:00,900
It just tells you what it costs in the short term and what flexibility it can create later.

887
00:43:00,900 --> 00:43:02,620
Break coverage creates a similar issue.

888
00:43:02,620 --> 00:43:06,500
A line may appear staffed for the full shift, but the bottleneck station stops whenever

889
00:43:06,500 --> 00:43:08,900
the one qualified operator takes a break.

890
00:43:08,900 --> 00:43:12,700
That pause could be harmless if a buffer protects the next operation, or it could trigger

891
00:43:12,700 --> 00:43:14,940
a delay that keeps expanding through the day.

892
00:43:14,940 --> 00:43:18,660
The answer depends on the actual flow, not the head count total.

893
00:43:18,660 --> 00:43:20,500
Shift handover needs a place in the model too.

894
00:43:20,500 --> 00:43:24,420
Some work transfers cleanly between operators, but other work needs continuity.

895
00:43:24,420 --> 00:43:27,940
Because in in process check, a difficult setup or a quality concern sits with the person

896
00:43:27,940 --> 00:43:28,940
who started it.

897
00:43:28,940 --> 00:43:32,700
When a plan assumes every handover works perfectly, it treats people like a resource calendar

898
00:43:32,700 --> 00:43:33,700
with legs.

899
00:43:33,700 --> 00:43:35,060
Production doesn't work that way.

900
00:43:35,060 --> 00:43:36,620
Fatigue deserves a careful approach.

901
00:43:36,620 --> 00:43:39,660
I wouldn't claim a simulation can measure how tired someone feels.

902
00:43:39,660 --> 00:43:40,940
That's false precision.

903
00:43:40,940 --> 00:43:44,900
But you can model the labor rules and operating limits that affect the decision.

904
00:43:44,900 --> 00:43:50,460
Systemum over time, rest periods, restricted tasks, need for extra supervision and planned

905
00:43:50,460 --> 00:43:52,820
coverage for longer hours.

906
00:43:52,820 --> 00:43:55,740
Those limits protect both people and process stability.

907
00:43:55,740 --> 00:43:56,740
Absence works the same way.

908
00:43:56,740 --> 00:44:01,700
A workforce plan might tolerate one absence in a general assembly area, but fail when the

909
00:44:01,700 --> 00:44:03,860
absent person holds a rare approval.

910
00:44:03,860 --> 00:44:07,380
Test a normal absence case, then ask which order stop which work can move and how much recovery

911
00:44:07,380 --> 00:44:08,380
time the plan needs.

912
00:44:08,380 --> 00:44:11,740
That's more useful than treating absence as a flat percentage removed from total labor.

913
00:44:11,740 --> 00:44:14,260
Here's another point that often gets missed.

914
00:44:14,260 --> 00:44:17,260
Most roles constrain production, just as much as direct operators.

915
00:44:17,260 --> 00:44:22,060
A late shift might need material handling, tool support, quality release, maintenance cover,

916
00:44:22,060 --> 00:44:23,980
or a supervisor for escalations.

917
00:44:23,980 --> 00:44:27,540
If those roles stay on the old calendar, the new operating hours just create work that

918
00:44:27,540 --> 00:44:28,540
waits for help.

919
00:44:28,540 --> 00:44:30,220
The machine might run, but the order may not move.

920
00:44:30,220 --> 00:44:34,620
So when you simulate staffing, map the roles that control release and recovery, not just

921
00:44:34,620 --> 00:44:36,820
the people who touch the product.

922
00:44:36,820 --> 00:44:41,060
Identify where work needs a specific skill, where two people must overlap, and where an

923
00:44:41,060 --> 00:44:45,940
absence removes a decision or approval rather than just reducing hands on the floor.

924
00:44:45,940 --> 00:44:50,140
That gives you a model of usable labor that also changes the discussion with managers.

925
00:44:50,140 --> 00:44:53,900
Instead of asking for more heads, you can ask for qualified coverage at the operation that

926
00:44:53,900 --> 00:44:55,340
shapes delivery performance.

927
00:44:55,340 --> 00:44:58,620
Instead of treating overtime as a broad answer, you can test whether it covers the actual

928
00:44:58,620 --> 00:45:01,620
constraint or just creates more work waiting downstream.

929
00:45:01,620 --> 00:45:05,900
A staffing decision should show who can do what, when they can do it, and which limits

930
00:45:05,900 --> 00:45:07,220
still apply.

931
00:45:07,220 --> 00:45:10,540
Anything less produces a schedule that looks fully staffed until the first order needs

932
00:45:10,540 --> 00:45:12,900
a person who isn't actually available.

933
00:45:12,900 --> 00:45:14,940
Test shift patterns and labor rules.

934
00:45:14,940 --> 00:45:19,020
Once you know which skills actually control the flow, you can test how the shift design

935
00:45:19,020 --> 00:45:20,020
itself holds up.

936
00:45:20,020 --> 00:45:22,860
This is where a lot of capacity plans get oversimplified.

937
00:45:22,860 --> 00:45:26,580
Someone sees a calendar and says, add a late shift, approve overtime, run Saturday, or

938
00:45:26,580 --> 00:45:28,140
stagger the starts.

939
00:45:28,140 --> 00:45:29,980
And that can feel like the obvious answer.

940
00:45:29,980 --> 00:45:33,900
More hours can help, but they only work if the work can actually move through the full

941
00:45:33,900 --> 00:45:36,220
process during those extra hours.

942
00:45:36,220 --> 00:45:39,620
Picture a constrained assembly operation running two standard shifts.

943
00:45:39,620 --> 00:45:43,860
Everything goes up, backlog grows, and the natural proposal is a third shift.

944
00:45:43,860 --> 00:45:45,740
On paper, that looks easy.

945
00:45:45,740 --> 00:45:48,860
More hours at the assembly benches means more capacity, right?

946
00:45:48,860 --> 00:45:51,500
But the third shift doesn't just need assembly operators.

947
00:45:51,500 --> 00:45:53,740
It needs material available at the point of use.

948
00:45:53,740 --> 00:45:57,260
It might need someone who can resolve a quality issue as soon as it shows up.

949
00:45:57,260 --> 00:46:01,260
It might need test equipment support, maintenance cover, and a supervisor with authority to

950
00:46:01,260 --> 00:46:04,700
release a deviation or decide what to do when an order can't continue.

951
00:46:04,700 --> 00:46:08,140
If those support rolls finish at the end of the second shift, the extra assembly hours

952
00:46:08,140 --> 00:46:10,180
may just produce partly completed work.

953
00:46:10,180 --> 00:46:11,420
The labor plan looks full.

954
00:46:11,420 --> 00:46:12,980
The customer order still waits.

955
00:46:12,980 --> 00:46:16,980
That's why I'd model the shift as an operating system, not as an extra block of time.

956
00:46:16,980 --> 00:46:20,540
You include the bottleneck operation, sure, but you also include the support functions that

957
00:46:20,540 --> 00:46:22,780
let that operation actually release work.

958
00:46:22,780 --> 00:46:25,060
In some areas, material handling controls the pace.

959
00:46:25,060 --> 00:46:28,220
In others, it's test, inspection, maintenance, or the tool room.

960
00:46:28,220 --> 00:46:31,500
The whole shift needs enough coverage to complete the work it starts.

961
00:46:31,500 --> 00:46:32,860
Overtime needs the same kind of test.

962
00:46:32,860 --> 00:46:36,500
It can recover a short term problem, especially when the work, material, and approvals are already

963
00:46:36,500 --> 00:46:37,660
sitting ready.

964
00:46:37,660 --> 00:46:42,020
But Overtime can also extend a queue into an area that doesn't have the same coverage.

965
00:46:42,020 --> 00:46:45,340
You work longer at one resource, then create a bigger pile in front of the next one, but

966
00:46:45,340 --> 00:46:46,500
that might still be the right call.

967
00:46:46,500 --> 00:46:49,580
At least you can see the trade-off before people commit to it.

968
00:46:49,580 --> 00:46:52,260
Staggered shift starts can produce a different result.

969
00:46:52,260 --> 00:46:55,900
Instead of everyone arriving and leaving at the same time, you can extend coverage around

970
00:46:55,900 --> 00:46:57,700
the process that causes delays.

971
00:46:57,700 --> 00:46:59,940
A material handler might start earlier.

972
00:46:59,940 --> 00:47:03,020
Quality support might overlap the busy part of the day.

973
00:47:03,020 --> 00:47:06,140
Maintenance might use a quieter period without taking the bottleneck offline during peak

974
00:47:06,140 --> 00:47:07,140
flow.

975
00:47:07,140 --> 00:47:11,140
The model can test those choices against the same demand and the same operating rules.

976
00:47:11,140 --> 00:47:15,020
That comparison matters because a shift pattern changes more than labour hours.

977
00:47:15,020 --> 00:47:19,900
It changes handovers, break timing, the timing of material moves, and the point when support

978
00:47:19,900 --> 00:47:21,220
becomes unavailable.

979
00:47:21,220 --> 00:47:26,220
A schedule that looks fine at the weekly level can fail every day at the same 2 hour gap.

980
00:47:26,220 --> 00:47:29,060
And those gaps rarely show up in a broad labour total.

981
00:47:29,060 --> 00:47:31,260
We can work needs careful treatment too.

982
00:47:31,260 --> 00:47:34,820
Saturday capacity can look attractive when demand pressure builds, but it may depend

983
00:47:34,820 --> 00:47:39,900
on temporary cover, limited maintenance support, reduced logistics activity, or a delayed

984
00:47:39,900 --> 00:47:41,260
quality release.

985
00:47:41,260 --> 00:47:45,460
You need to test which work can truly finish over the weekend and which work just waits

986
00:47:45,460 --> 00:47:47,900
until Monday for the next approved step.

987
00:47:47,900 --> 00:47:49,620
Temporary staff create a similar question.

988
00:47:49,620 --> 00:47:53,540
They can help with packing, material movement, basic assembly or work that follows a stable

989
00:47:53,540 --> 00:47:54,540
instruction.

990
00:47:54,540 --> 00:47:57,500
That can free up experience people for the constrained task.

991
00:47:57,500 --> 00:48:01,620
But the model shouldn't treat temporary staff as fully interchangeable from day one.

992
00:48:01,620 --> 00:48:05,020
All the work they can perform, the support they need, and the points where an experienced

993
00:48:05,020 --> 00:48:06,540
person must step in.

994
00:48:06,540 --> 00:48:10,300
This helps you avoid a common mistake, planning labour at plant level when the constraint

995
00:48:10,300 --> 00:48:11,580
sits at one operation.

996
00:48:11,580 --> 00:48:14,820
You can have enough people across the building and still miss customer dates because one

997
00:48:14,820 --> 00:48:18,220
inspection station lacks qualified cover for part of the shift.

998
00:48:18,220 --> 00:48:19,620
That's the coverage you need to test.

999
00:48:19,620 --> 00:48:22,100
Think about the result you actually want from the scenario.

1000
00:48:22,100 --> 00:48:24,980
More output is one measure, but it may not be the right one.

1001
00:48:24,980 --> 00:48:28,500
You may care more about late order risk, work released through final inspection, or the

1002
00:48:28,500 --> 00:48:30,980
time needed to clear a backlog after disruption.

1003
00:48:30,980 --> 00:48:34,700
A third shift that raises machine hours but pushes more work into a Monday morning queue

1004
00:48:34,700 --> 00:48:36,300
may not improve service at all.

1005
00:48:36,300 --> 00:48:40,220
Here's where simulation helps production and labour planning speak the same language.

1006
00:48:40,220 --> 00:48:44,180
Instead of debating whether a shift should work, you can compare what each patent does to

1007
00:48:44,180 --> 00:48:48,820
completed orders, queues, support load and recovery time under realistic conditions.

1008
00:48:48,820 --> 00:48:53,140
You still need judgment, labour rules, safety limits, fatigue management and local agreements

1009
00:48:53,140 --> 00:48:56,620
remain real constraints, not variables to optimize away.

1010
00:48:56,620 --> 00:48:58,980
The model tests options inside those boundaries.

1011
00:48:58,980 --> 00:49:00,860
It doesn't give permission to ignore them.

1012
00:49:00,860 --> 00:49:04,380
And once the team starts changing schedules, another instinct often follows.

1013
00:49:04,380 --> 00:49:07,060
If work keeps waiting, add stock between operations.

1014
00:49:07,060 --> 00:49:08,220
That can protect the flow.

1015
00:49:08,220 --> 00:49:12,220
It can also cover up the reason the flow needs protection in the first place.

1016
00:49:12,220 --> 00:49:15,220
Buffers, protect flow, until they hide a problem.

1017
00:49:15,220 --> 00:49:19,420
When a line starts missing pace, someone usually suggests more buffer, put more material

1018
00:49:19,420 --> 00:49:24,380
before the process, release work earlier, keep extra stock nearby, just in case.

1019
00:49:24,380 --> 00:49:28,220
That instinct comes from experience because buffers can protect flow when normal variation

1020
00:49:28,220 --> 00:49:29,220
hits.

1021
00:49:29,220 --> 00:49:32,500
It only helps when you know what risk they are meant to absorb and how much protection

1022
00:49:32,500 --> 00:49:33,820
the process actually needs.

1023
00:49:33,820 --> 00:49:35,580
A buffer can take several forms.

1024
00:49:35,580 --> 00:49:39,820
It can be raw material held before the first operation, work in progress between two operations

1025
00:49:39,820 --> 00:49:43,140
or finished goods held for customer demand.

1026
00:49:43,140 --> 00:49:44,660
Sometimes the buffer is time.

1027
00:49:44,660 --> 00:49:47,580
An order released early enough to absorb a normal delay.

1028
00:49:47,580 --> 00:49:51,820
Sometimes it's spare capacity, where resource has enough room to recover after a stop.

1029
00:49:51,820 --> 00:49:55,420
All of these create options when something doesn't go to plan.

1030
00:49:55,420 --> 00:49:57,220
Consider two connected operations.

1031
00:49:57,220 --> 00:50:00,100
The upstream process runs with small frequent interruptions.

1032
00:50:00,100 --> 00:50:04,260
The downstream process needs steady feed and can't easily restart after it runs out of

1033
00:50:04,260 --> 00:50:05,260
work.

1034
00:50:05,260 --> 00:50:08,580
A controlled amount of work in progress between them can keep the downstream process running

1035
00:50:08,580 --> 00:50:10,540
while the upstream team resolves a short problem.

1036
00:50:10,540 --> 00:50:14,820
In that case, the buffer protects flow, but the buffer also changes what people can see.

1037
00:50:14,820 --> 00:50:18,900
When work piles up between operations, the upstream team may keep reporting strong output

1038
00:50:18,900 --> 00:50:23,300
while the downstream team struggles with old jobs, changing priorities, and parts that

1039
00:50:23,300 --> 00:50:25,500
no longer match the schedule.

1040
00:50:25,500 --> 00:50:29,580
The factory has more inventory, it doesn't automatically have more usable capacity.

1041
00:50:29,580 --> 00:50:30,900
That distinction matters.

1042
00:50:30,900 --> 00:50:32,620
Two little buffer can create starvation.

1043
00:50:32,620 --> 00:50:37,140
A machine, line, or operator reaches the next task and finds nothing ready.

1044
00:50:37,140 --> 00:50:41,460
The cause might be a late material move, an inspection delay, or a small upstream stop.

1045
00:50:41,460 --> 00:50:44,260
The result is lost time at a resource that could otherwise run.

1046
00:50:44,260 --> 00:50:46,380
Too much buffer creates another set of problems.

1047
00:50:46,380 --> 00:50:48,820
Lead time grows because orders sit in wait.

1048
00:50:48,820 --> 00:50:51,380
Cash stays tied up in work that can't ship yet.

1049
00:50:51,380 --> 00:50:55,580
Many issues can stay buried inside a large queue, sometimes until the affected parts reach

1050
00:50:55,580 --> 00:50:57,460
a downstream process days later.

1051
00:50:57,460 --> 00:51:01,900
The pile may feel safe, it can also become a storage system for unresolved problems.

1052
00:51:01,900 --> 00:51:04,420
This is why a universal buffer target rarely works.

1053
00:51:04,420 --> 00:51:08,540
A few hours of work in front of one process may protect a sensitive constraint.

1054
00:51:08,540 --> 00:51:12,940
The same amount in another area may only add waiting time, hide poor, release discipline,

1055
00:51:12,940 --> 00:51:14,300
and consume floor space.

1056
00:51:14,300 --> 00:51:18,860
The right answer depends on variation, recovery time, process sequence, and the consequence

1057
00:51:18,860 --> 00:51:20,980
of a resource running short.

1058
00:51:20,980 --> 00:51:24,060
Then let's you test those conditions instead of relying on a fixed rule.

1059
00:51:24,060 --> 00:51:28,060
You can change the buffer size and then observe how the flow responds under normal operating

1060
00:51:28,060 --> 00:51:29,060
variation.

1061
00:51:29,060 --> 00:51:32,380
Does the downstream process run short-list often, does the queue stay within a limit the

1062
00:51:32,380 --> 00:51:37,140
team can manage, do late orders fall, or do orders simply spend longer in the factory?

1063
00:51:37,140 --> 00:51:38,460
Those are different outcomes.

1064
00:51:38,460 --> 00:51:40,780
Release rules matter as much as physical stock.

1065
00:51:40,780 --> 00:51:44,620
If planners release every available order early, the buffer may fill with work that has

1066
00:51:44,620 --> 00:51:47,420
no near term paths through the next operation.

1067
00:51:47,420 --> 00:51:51,900
It becomes harder to manage because urgent orders enter a queue already packed with less

1068
00:51:51,900 --> 00:51:52,900
urgent work.

1069
00:51:52,900 --> 00:51:54,780
A controlled release rule can work differently.

1070
00:51:54,780 --> 00:51:57,100
It might release work only when material is ready.

1071
00:51:57,100 --> 00:52:01,420
The next stage has capacity within a defined period and the order has a real chance of moving

1072
00:52:01,420 --> 00:52:02,420
through the root.

1073
00:52:02,420 --> 00:52:04,660
That doesn't mean the plant runs with no inventory.

1074
00:52:04,660 --> 00:52:06,260
It means inventory has a job.

1075
00:52:06,260 --> 00:52:08,580
Think of the buffer as protection with a purpose.

1076
00:52:08,580 --> 00:52:14,220
For example, a buffer before a constrained process may absorb short variation upstream.

1077
00:52:14,220 --> 00:52:18,940
A buffer after a quality release step may protect assembly from the timing of inspections.

1078
00:52:18,940 --> 00:52:22,780
Finished goods may protect customer service where demand changes faster than production

1079
00:52:22,780 --> 00:52:23,780
can respond.

1080
00:52:23,780 --> 00:52:26,900
Each case needs its own reason, its own limit and a clear owner.

1081
00:52:26,900 --> 00:52:28,900
Without those buffer decisions turn into habit.

1082
00:52:28,900 --> 00:52:31,020
There is also a human side to this.

1083
00:52:31,020 --> 00:52:34,100
Large queues can make daily priorities harder to trust.

1084
00:52:34,100 --> 00:52:38,740
Operators see many jobs waiting, planners keep expediting, and supervisors spend time asking

1085
00:52:38,740 --> 00:52:40,540
which pallet should move next.

1086
00:52:40,540 --> 00:52:44,500
The lack's work, yet the wrong work can still arrive at the wrong point in the process.

1087
00:52:44,500 --> 00:52:45,500
That is not flow.

1088
00:52:45,500 --> 00:52:49,700
So when you test a buffer change, don't ask only how much stock should we hold?

1089
00:52:49,700 --> 00:52:53,820
Ask where variation enters, which operation needs protection, how long recovery normally

1090
00:52:53,820 --> 00:52:58,020
takes, and whether the buffer protects customer delivery or merely makes the backlog less

1091
00:52:58,020 --> 00:52:59,020
visible.

1092
00:52:59,020 --> 00:53:00,300
The model should show both sides.

1093
00:53:00,300 --> 00:53:03,980
It should show when a smaller buffer starves a process and when a larger one creates longer

1094
00:53:03,980 --> 00:53:05,860
lead times with no service gain.

1095
00:53:05,860 --> 00:53:10,500
It should make the waiting visible, not treat every completed upstream operation as progress.

1096
00:53:10,500 --> 00:53:13,540
Because sometimes the most expensive part in the factory is the one that has already been

1097
00:53:13,540 --> 00:53:17,860
worked on, can't move forward, and nobody can explain why it's still waiting.

1098
00:53:17,860 --> 00:53:19,740
The buffer before the bottleneck.

1099
00:53:19,740 --> 00:53:22,380
Let me make this buffer question concrete for you.

1100
00:53:22,380 --> 00:53:25,700
Picture an upstream machining cell feeding a heat treatment process.

1101
00:53:25,700 --> 00:53:27,380
Heat treatment is the constraint step.

1102
00:53:27,380 --> 00:53:31,740
It runs in batches, has a fixed operating calendar, and takes time to recover when a load,

1103
00:53:31,740 --> 00:53:34,260
furnace, or quality check causes a delay.

1104
00:53:34,260 --> 00:53:38,340
The machining cell can produce parts faster than heat treatment can accept them at certain

1105
00:53:38,340 --> 00:53:41,300
points in the week, and that creates a familiar debate.

1106
00:53:41,300 --> 00:53:45,700
One group once a large cube before heat treatment because the furnace must never sit empty.

1107
00:53:45,700 --> 00:53:49,140
Another group once tighter work in progress limits because the queue keeps growing, priorities

1108
00:53:49,140 --> 00:53:52,420
keep changing, and parts wait longer than anyone planned.

1109
00:53:52,420 --> 00:53:53,860
Both positions can make sense.

1110
00:53:53,860 --> 00:53:55,380
The answer depends on the flow.

1111
00:53:55,380 --> 00:53:59,020
Suppose the machining cell produces batches through the day while heat treatment accepts

1112
00:53:59,020 --> 00:54:00,820
work at defined loading times.

1113
00:54:00,820 --> 00:54:04,660
If the queue before heat treatment is too small, a short stop in machining can leave the

1114
00:54:04,660 --> 00:54:07,100
furnace waiting without a full approved load.

1115
00:54:07,100 --> 00:54:11,020
The furnace loses time, and because it controls the pace of the route, the delay spreads

1116
00:54:11,020 --> 00:54:12,220
to everything behind it.

1117
00:54:12,220 --> 00:54:16,300
A buffer can protect against that, but now increase the buffer without changing the release

1118
00:54:16,300 --> 00:54:17,300
rule.

1119
00:54:17,300 --> 00:54:18,820
Planners release more work early.

1120
00:54:18,820 --> 00:54:22,460
Machining keeps producing the area before heat treatment fills with pallets, and every

1121
00:54:22,460 --> 00:54:25,940
pallet looks like progress because machining has completed its operation.

1122
00:54:25,940 --> 00:54:27,740
Some of that stock may not be ready to run.

1123
00:54:27,740 --> 00:54:31,900
A batch could still wait for a quality release, need a certificate for its material, carry

1124
00:54:31,900 --> 00:54:36,020
a routing status that prevents it from entering heat treatment, or belong to a product family

1125
00:54:36,020 --> 00:54:39,980
that needs a different furnace recipe than the one currently scheduled.

1126
00:54:39,980 --> 00:54:42,820
Visible inventory and usable inventory are different things.

1127
00:54:42,820 --> 00:54:45,180
A simulation model can represent that distinction.

1128
00:54:45,180 --> 00:54:47,740
It doesn't only count pallets waiting in a physical area.

1129
00:54:47,740 --> 00:54:51,660
It checks whether each batch has the material, quality status, route approval, and process

1130
00:54:51,660 --> 00:54:53,580
condition needed for the next step.

1131
00:54:53,580 --> 00:54:57,060
That changes the conversation from, do we have enough work in the buffer?

1132
00:54:57,060 --> 00:55:00,940
Two, do we have enough released work that the bottleneck can actually process?

1133
00:55:00,940 --> 00:55:03,100
Those questions lead to different decisions.

1134
00:55:03,100 --> 00:55:06,820
In the model, you can test a smaller buffer with a strict release policy.

1135
00:55:06,820 --> 00:55:10,020
Only work that has passed, the required checks can enter the queue.

1136
00:55:10,020 --> 00:55:13,420
Then you can see where the normal variation upstream starves heat treatment, and how often

1137
00:55:13,420 --> 00:55:14,420
that happens.

1138
00:55:14,420 --> 00:55:17,540
Next, test a larger buffer under the same demand pattern.

1139
00:55:17,540 --> 00:55:21,180
Watch whether the furnace remains supplied more often, but also watch queue age.

1140
00:55:21,180 --> 00:55:24,820
If parts wait for days, you may protect furnace use while damaging lead time and due date

1141
00:55:24,820 --> 00:55:25,820
performance.

1142
00:55:25,820 --> 00:55:27,780
A full queue doesn't mean healthy flow.

1143
00:55:27,780 --> 00:55:31,660
Machine needs attention too.

1144
00:55:31,660 --> 00:55:33,740
Machining may not have space to put completed work.

1145
00:55:33,740 --> 00:55:37,540
The machining cell then stops even though the machine operator and material are ready.

1146
00:55:37,540 --> 00:55:39,500
That stop isn't caused by a machining problem.

1147
00:55:39,500 --> 00:55:42,300
It comes from the next step being unable to absorb the output.

1148
00:55:42,300 --> 00:55:45,540
This is why the model needs both sides of the bottleneck.

1149
00:55:45,540 --> 00:55:49,380
It needs to show when heat treatment becomes starved because upstream cannot provide released

1150
00:55:49,380 --> 00:55:50,380
work.

1151
00:55:50,380 --> 00:55:54,340
And also when upstream becomes blocked because heat treatment cannot accept more work.

1152
00:55:54,340 --> 00:55:58,300
Those two states can alternate during the same week, priority adds another layer.

1153
00:55:58,300 --> 00:56:02,340
Say an urgent customer order enters the plant after a queue has already built before heat

1154
00:56:02,340 --> 00:56:03,340
treatment.

1155
00:56:03,340 --> 00:56:06,300
The order may have a close due date, but it may not match the recipe currently planned

1156
00:56:06,300 --> 00:56:07,300
for the furnace.

1157
00:56:07,300 --> 00:56:11,580
Do you interrupt the campaign except more setup and process risk or let the urgent order

1158
00:56:11,580 --> 00:56:14,980
wait behind lower priority work that already fits the next load?

1159
00:56:14,980 --> 00:56:16,460
There isn't a universal answer.

1160
00:56:16,460 --> 00:56:18,500
A simulation can compare the choices.

1161
00:56:18,500 --> 00:56:22,780
It can test the customer impact of preserving a stable campaign against the effect of inserting

1162
00:56:22,780 --> 00:56:23,980
the urgent batch.

1163
00:56:23,980 --> 00:56:27,820
It can show whether the urgency really protects the shipment or whether another missing component

1164
00:56:27,820 --> 00:56:29,780
means the order cannot finish anyway.

1165
00:56:29,780 --> 00:56:31,900
That stops expediting from becoming a reflex.

1166
00:56:31,900 --> 00:56:34,380
You can also test the release policy itself.

1167
00:56:34,380 --> 00:56:38,220
Perhaps work should enter the buffer only when the next heat treatment slot sits within

1168
00:56:38,220 --> 00:56:39,700
a defined time window.

1169
00:56:39,700 --> 00:56:44,140
Perhaps the buffer needs separate limits by product family or recipe rather than one shared

1170
00:56:44,140 --> 00:56:45,740
pile of work.

1171
00:56:45,740 --> 00:56:50,300
Maybe a small protected space for urgent orders prevents them from fighting with normal production.

1172
00:56:50,300 --> 00:56:52,900
Each rule changes how the constraint behaves.

1173
00:56:52,900 --> 00:56:56,460
The purpose isn't to find a perfect buffer size that stays fixed forever.

1174
00:56:56,460 --> 00:57:00,020
Demand changes, product roots change and process reliability changes.

1175
00:57:00,020 --> 00:57:04,500
The purpose is to understand how much protection the bottleneck needs, what type of work belongs

1176
00:57:04,500 --> 00:57:08,020
in that protection and where the queue begins to hurt more than it helps.

1177
00:57:08,020 --> 00:57:11,780
That becomes even harder when the product mix changes because average capacity assumptions

1178
00:57:11,780 --> 00:57:17,140
break down very quickly once different products compete for the same constrained process.

1179
00:57:17,140 --> 00:57:19,460
Product mix changes the factory you think you know.

1180
00:57:19,460 --> 00:57:23,380
A factory can receive the same total demand this month as last month and still behave like

1181
00:57:23,380 --> 00:57:24,700
a different factory.

1182
00:57:24,700 --> 00:57:26,340
That happens when the mix changes.

1183
00:57:26,340 --> 00:57:30,500
Total units may look stable in the ERP plan while the load on machines, people, tools,

1184
00:57:30,500 --> 00:57:35,340
inspection and shared support shifts in ways that a simple capacity total cannot explain.

1185
00:57:35,340 --> 00:57:37,740
Think about two product families moving through the same plant.

1186
00:57:37,740 --> 00:57:41,780
One family has high volume, a stable root, short cycle times and few change overs.

1187
00:57:41,780 --> 00:57:46,100
The other family has lower volume, but longer machining time, more setups, a higher inspection

1188
00:57:46,100 --> 00:57:48,940
load and a tighter need for a skilled operator.

1189
00:57:48,940 --> 00:57:50,420
All in order are not always ten orders.

1190
00:57:50,420 --> 00:57:54,540
If demand moves from the first family toward the second, the plant may produce fewer finished

1191
00:57:54,540 --> 00:57:57,060
units even though the order count barely changes.

1192
00:57:57,060 --> 00:58:01,140
The bottleneck may run longer, the shared fixture may become harder to schedule.

1193
00:58:01,140 --> 00:58:04,580
Quality may receive more first off checks and more complex inspection work.

1194
00:58:04,580 --> 00:58:08,420
The people who know the difficult setup may spend their week supporting one process rather

1195
00:58:08,420 --> 00:58:09,580
than covering several.

1196
00:58:09,580 --> 00:58:11,740
That's why average capacity can mislead you.

1197
00:58:11,740 --> 00:58:15,860
A broad plan may say the machining area has enough hours for the monthly demand.

1198
00:58:15,860 --> 00:58:19,540
It may even use a sensible average cycle time across the whole product range.

1199
00:58:19,540 --> 00:58:22,380
But averages smooth out the very differences that create pressure.

1200
00:58:22,380 --> 00:58:25,940
They turn a mix of easy and difficult work into one imaginary product that nobody actually

1201
00:58:25,940 --> 00:58:26,940
builds.

1202
00:58:26,940 --> 00:58:28,540
Production doesn't run imaginary products.

1203
00:58:28,540 --> 00:58:29,620
Let's make this practical.

1204
00:58:29,620 --> 00:58:33,020
Say a plant normally produces a high volume of standard components.

1205
00:58:33,020 --> 00:58:38,060
They move through a familiar root, use common tooling and fit well into a repeatable sequence.

1206
00:58:38,060 --> 00:58:40,300
Then a customer changes the demand profile.

1207
00:58:40,300 --> 00:58:43,020
Standard demand falls, but several lower volume variance rise.

1208
00:58:43,020 --> 00:58:45,460
The total number of units stays close to the plan.

1209
00:58:45,460 --> 00:58:47,380
And paper, nothing dramatic happened.

1210
00:58:47,380 --> 00:58:51,500
On the floor, the team now changes tools more often, runs more first off checks, waits

1211
00:58:51,500 --> 00:58:55,100
for different material and needs more inspection time for each batch.

1212
00:58:55,100 --> 00:58:59,420
A machine that seemed lightly loaded through an average capacity view now spends much

1213
00:58:59,420 --> 00:59:01,580
more of its calendar in setup and approval.

1214
00:59:01,580 --> 00:59:04,300
The pressure comes from the mix, not from volume alone.

1215
00:59:04,300 --> 00:59:06,380
Scrap and rework can also change with mix.

1216
00:59:06,380 --> 00:59:10,820
A stable mature product may run with predictable yield, a complex variant, a newer design or

1217
00:59:10,820 --> 00:59:15,420
product with tighter tolerances may create more rework or more time in quality review.

1218
00:59:15,420 --> 00:59:20,020
If that family grows, the downstream load changes, even if the original machining time does

1219
00:59:20,020 --> 00:59:21,020
not.

1220
00:59:21,020 --> 00:59:24,260
You can't treat every completed operation as the same amount of future work.

1221
00:59:24,260 --> 00:59:25,940
Shared resources expose this quickly.

1222
00:59:25,940 --> 00:59:29,980
A special fixture might support several product families, but only one job can use it at

1223
00:59:29,980 --> 00:59:30,980
a time.

1224
00:59:30,980 --> 00:59:33,460
A skilled programmer may need to approve a revised process.

1225
00:59:33,460 --> 00:59:37,380
A test stand may handle a limited range of products, while another test stand accepts

1226
00:59:37,380 --> 00:59:38,860
only the standard range.

1227
00:59:38,860 --> 00:59:41,100
The resource map changes when the mix changes.

1228
00:59:41,100 --> 00:59:44,580
That's why a good simulation needs product level differences where those differences affect

1229
00:59:44,580 --> 00:59:45,580
the decision.

1230
00:59:45,580 --> 00:59:49,140
It should know that one product family takes longer at a bottleneck.

1231
00:59:49,140 --> 00:59:53,180
It should know that another family needs a special tool, a different root or an extra quality

1232
00:59:53,180 --> 00:59:54,180
step.

1233
00:59:54,180 --> 00:59:56,220
It should represent the conditions that alter flow.

1234
00:59:56,220 --> 00:59:58,740
You don't need to model every part number from day one.

1235
00:59:58,740 --> 01:00:00,420
Start with families that behave differently.

1236
01:00:00,420 --> 01:00:04,820
Group products where they share similar roots, run times, setup needs, material risk and

1237
01:00:04,820 --> 01:00:05,820
inspection demand.

1238
01:00:05,820 --> 01:00:09,780
If 20 part numbers all follow the same path with near enough the same constraints, one

1239
01:00:09,780 --> 01:00:12,780
family model may be enough for the first capacity test.

1240
01:00:12,780 --> 01:00:15,460
But don't group products just because their descriptions sound similar.

1241
01:00:15,460 --> 01:00:18,780
A small design change can put a part into a different process world.

1242
01:00:18,780 --> 01:00:22,260
It may need another machine, another fixture, a longer test or an operator with a different

1243
01:00:22,260 --> 01:00:23,260
approval.

1244
01:00:23,260 --> 01:00:26,140
The sales description might still call it the same product family.

1245
01:00:26,140 --> 01:00:29,380
The factory may experience it as a separate workload entirely.

1246
01:00:29,380 --> 01:00:31,100
That difference needs a place in the model.

1247
01:00:31,100 --> 01:00:34,020
The point isn't to produce a perfect catalog of every product.

1248
01:00:34,020 --> 01:00:37,380
The point is to capture the mix drivers that change the result.

1249
01:00:37,380 --> 01:00:39,500
Which products consume the constrained resource?

1250
01:00:39,500 --> 01:00:43,820
Which ones create long setups?

1251
01:00:43,820 --> 01:00:46,460
Which ones compete for a rare tool or skilled person?

1252
01:00:46,460 --> 01:00:48,860
Those are the questions behind the capacity number.

1253
01:00:48,860 --> 01:00:52,140
Once you test the expected mix, test a few plausible shifts around it.

1254
01:00:52,140 --> 01:00:55,620
What if demand for the complex family rises faster than expected?

1255
01:00:55,620 --> 01:00:57,420
What if the standard product drops?

1256
01:00:57,420 --> 01:01:00,500
Removing the long production runs that normally absorb setup time?

1257
01:01:00,500 --> 01:01:04,620
What if urgent customer orders arrive mainly from the family that already creates the most

1258
01:01:04,620 --> 01:01:05,620
pressure?

1259
01:01:05,620 --> 01:01:08,820
The result may show that your current capacity plan works for the total volume, but only

1260
01:01:08,820 --> 01:01:09,820
for the mix you assumed.

1261
01:01:09,820 --> 01:01:13,180
That's a much more honest answer than saying the plant has enough hours.

1262
01:01:13,180 --> 01:01:15,900
It also changes how you talk about demand with commercial teams.

1263
01:01:15,900 --> 01:01:20,300
Instead of only asking for volume forecasts, you can ask for the expected mix by family

1264
01:01:20,300 --> 01:01:23,020
and the range of changes production needs to handle.

1265
01:01:23,020 --> 01:01:25,540
Sales does not need to become a scheduling department.

1266
01:01:25,540 --> 01:01:30,060
But production needs a view of demand that matches the way work consumes factory resources.

1267
01:01:30,060 --> 01:01:33,500
This can connect the dots between IT and OT in a very practical way.

1268
01:01:33,500 --> 01:01:35,180
ERP holds the demand signal.

1269
01:01:35,180 --> 01:01:39,700
MES history can show the actual effort and root behavior by product family.

1270
01:01:39,700 --> 01:01:42,900
Quality and maintenance data may reveal where certain products create extra load.

1271
01:01:42,900 --> 01:01:46,900
A simulation model brings those facts into a test of how the flow behaves when the mix

1272
01:01:46,900 --> 01:01:47,900
changes.

1273
01:01:47,900 --> 01:01:51,900
Microsoft Fabric can help bring that data together later, but data collection alone won't

1274
01:01:51,900 --> 01:01:53,100
answer the question.

1275
01:01:53,100 --> 01:01:57,660
The model still needs the product process resource links that explain why one order consumes

1276
01:01:57,660 --> 01:02:00,340
a very different amount of factory time than another.

1277
01:02:00,340 --> 01:02:04,620
And once different products compete for the same equipment and people, the order in which

1278
01:02:04,620 --> 01:02:08,660
you run them starts to matter just as much as the volume you plan.

1279
01:02:08,660 --> 01:02:10,420
Sequence matters more than average load.

1280
01:02:10,420 --> 01:02:13,980
When different product families start competing for the same equipment and people, average

1281
01:02:13,980 --> 01:02:15,980
load stops telling you the whole story.

1282
01:02:15,980 --> 01:02:20,180
Two schedules can use the same number of machine hours in a week and still produce completely

1283
01:02:20,180 --> 01:02:23,300
different results for output, due dates and overtime.

1284
01:02:23,300 --> 01:02:26,260
The difference almost always sits in the sequence.

1285
01:02:26,260 --> 01:02:30,140
Picture a machining area handling several related product families.

1286
01:02:30,140 --> 01:02:33,700
On Monday, the planner groups similar jobs together, so the machine stays on the same

1287
01:02:33,700 --> 01:02:38,260
fixture longer, the same tools stay in place and operators avoid repeated setup work.

1288
01:02:38,260 --> 01:02:42,580
That makes the weekly load look manageable because the machine spends more time cutting parts

1289
01:02:42,580 --> 01:02:44,380
and less time changing over.

1290
01:02:44,380 --> 01:02:47,980
That schedule may work well for efficiency, but it could still push an urgent order past

1291
01:02:47,980 --> 01:02:49,260
its customer date.

1292
01:02:49,260 --> 01:02:53,300
Now take the same demand, the same people, the same total hours, but sequence the work by

1293
01:02:53,300 --> 01:02:54,300
due date.

1294
01:02:54,300 --> 01:02:56,380
The urgent jobs move first.

1295
01:02:56,380 --> 01:03:00,100
Customer dates might improve for a few orders, but the area changes between product families

1296
01:03:00,100 --> 01:03:01,100
more often.

1297
01:03:01,100 --> 01:03:05,540
Setup time grows, tool changes rise and first off checks appear more frequently.

1298
01:03:05,540 --> 01:03:10,340
By Thursday, the machine has used the same weekly hours but completed less total work.

1299
01:03:10,340 --> 01:03:13,700
Both schedules look reasonable if you only look at average load, this is where planning

1300
01:03:13,700 --> 01:03:15,380
turns into a real trade off.

1301
01:03:15,380 --> 01:03:17,900
Grouping work into campaigns can protect capacity.

1302
01:03:17,900 --> 01:03:21,980
A campaign means running related products together before changing the machine, toolset,

1303
01:03:21,980 --> 01:03:23,700
process settings or material.

1304
01:03:23,700 --> 01:03:26,020
In some processes, that's not simply a preference.

1305
01:03:26,020 --> 01:03:30,260
Cleaning, validation or a long changeover can make frequent switching impractical.

1306
01:03:30,260 --> 01:03:32,940
But campaign logic can also make work way too long.

1307
01:03:32,940 --> 01:03:36,820
A job with an early due date might sit behind a larger batch of less urgent work because

1308
01:03:36,820 --> 01:03:38,300
it belongs to another family.

1309
01:03:38,300 --> 01:03:41,380
The planner can reduce changeovers and still lose service performance.

1310
01:03:41,380 --> 01:03:45,860
Meanwhile, pushing every urgent job to the front can create a factory where everything becomes

1311
01:03:45,860 --> 01:03:50,580
urgent, setups consume the calendar and nobody can predict when the normal work will run.

1312
01:03:50,580 --> 01:03:52,660
That's not a planar problem, it's a rule problem.

1313
01:03:52,660 --> 01:03:54,740
Now here's where assimilation becomes useful.

1314
01:03:54,740 --> 01:03:58,780
You put those rules under the same demand pattern and compare the outcomes.

1315
01:03:58,780 --> 01:04:02,380
One scenario might group by product family wherever possible.

1316
01:04:02,380 --> 01:04:04,620
Another could use due date as the main rule.

1317
01:04:04,620 --> 01:04:09,260
A third might apply customer priority, but only when material is ready and the job can

1318
01:04:09,260 --> 01:04:12,580
move through the next stages without creating a new blockage.

1319
01:04:12,580 --> 01:04:14,260
The rules decide the behavior.

1320
01:04:14,260 --> 01:04:16,540
Material readiness needs a place in sequencing as well.

1321
01:04:16,540 --> 01:04:20,700
There's little value in moving a work order to the front of a queue if a bought in component,

1322
01:04:20,700 --> 01:04:23,980
approved material or a required tool still isn't available.

1323
01:04:23,980 --> 01:04:28,140
A schedule can look responsive while repeatedly reserving time for work that cannot start.

1324
01:04:28,140 --> 01:04:31,180
With dispatch logic checks whether a job is truly ready.

1325
01:04:31,180 --> 01:04:34,340
Some plants need fixed campaign runs because of process conditions.

1326
01:04:34,340 --> 01:04:38,820
Paint lines, furnaces, chemical processes and complex cleaning steps may need a controlled

1327
01:04:38,820 --> 01:04:41,700
sequence to avoid long resets or quality risk.

1328
01:04:41,700 --> 01:04:45,340
In those cases the question isn't whether campaigns are good or bad, it's how much delivery

1329
01:04:45,340 --> 01:04:49,780
risk the campaign rule creates and whether a controlled exception can protect an important

1330
01:04:49,780 --> 01:04:51,180
customer commitment.

1331
01:04:51,180 --> 01:04:54,380
You want to test the cost of that exception before the order arrives.

1332
01:04:54,380 --> 01:04:56,900
Consider two schedules with identical weekly load.

1333
01:04:56,900 --> 01:04:59,820
Material one runs long campaigns and achieves fewer changeovers.

1334
01:04:59,820 --> 01:05:02,900
Schedule two interrupts the campaigns for selected urgent orders.

1335
01:05:02,900 --> 01:05:06,980
The second schedule may use more setup time but it could avoid several late shipments or

1336
01:05:06,980 --> 01:05:11,260
it may only move the delay because the urgent order still wait later for test inspection

1337
01:05:11,260 --> 01:05:12,980
or a matching assembly component.

1338
01:05:12,980 --> 01:05:16,020
The model can show the full effect, not just the first machines calendar.

1339
01:05:16,020 --> 01:05:19,180
This also gives planners a safer way to challenge old habits.

1340
01:05:19,180 --> 01:05:22,900
Maybe the team has always grouped by family because setups used to take most of a shift.

1341
01:05:22,900 --> 01:05:27,580
If setup time has improved, the old campaign rule may now delay orders more than it protects

1342
01:05:27,580 --> 01:05:32,220
capacity or perhaps due date dispatch worked when the product range was simple but the current

1343
01:05:32,220 --> 01:05:34,700
mix now creates too many changeovers.

1344
01:05:34,700 --> 01:05:37,980
Rules need testing when conditions change, I wouldn't expect the model to replace the

1345
01:05:37,980 --> 01:05:39,460
planner's judgment.

1346
01:05:39,460 --> 01:05:43,260
Planners see customer relationships, supplier concerns and local conditions that may sit

1347
01:05:43,260 --> 01:05:45,100
outside the formal schedule.

1348
01:05:45,100 --> 01:05:47,700
But simulation can make the recurring choices visible.

1349
01:05:47,700 --> 01:05:52,300
It can show how a queue rule affects setup time, throughput, order lateness and the pressure

1350
01:05:52,300 --> 01:05:54,060
passed to the next operation.

1351
01:05:54,060 --> 01:05:56,220
That gives judgment a stronger starting point.

1352
01:05:56,220 --> 01:06:00,060
Before changing planner behavior, run the current sequencing rule as a baseline.

1353
01:06:00,060 --> 01:06:04,580
Then test the proposed rule against the exact same orders, calendars and resource limits.

1354
01:06:04,580 --> 01:06:05,900
Keep the comparison fair.

1355
01:06:05,900 --> 01:06:09,380
If one rule only looks better because it received a kind of demand pattern, you haven't

1356
01:06:09,380 --> 01:06:10,380
learned much.

1357
01:06:10,380 --> 01:06:13,660
The sequence should earn its place through the outcomes it creates.

1358
01:06:13,660 --> 01:06:17,620
And even a well chosen sequence can fall apart when normal factory disruption enters the

1359
01:06:17,620 --> 01:06:18,620
week.

1360
01:06:18,620 --> 01:06:21,060
A plan without disruptions is a demo.

1361
01:06:21,060 --> 01:06:25,700
A schedule can look perfect when every machine runs, every delivery arrives on time and every

1362
01:06:25,700 --> 01:06:27,580
operator shows up as planned.

1363
01:06:27,580 --> 01:06:29,380
That schedule belongs in a demo.

1364
01:06:29,380 --> 01:06:32,420
Real production includes interruptions and most of them aren't dramatic.

1365
01:06:32,420 --> 01:06:34,340
A machine stops for a sense of fault.

1366
01:06:34,340 --> 01:06:37,340
A tool reaches the end of its life earlier than expected.

1367
01:06:37,340 --> 01:06:39,940
Material arrives at the gate but waits for incoming inspection.

1368
01:06:39,940 --> 01:06:41,980
A batch moves into a quality hold.

1369
01:06:41,980 --> 01:06:45,860
Someone with a rare qualification calls in sick, an urgent order arrives and suddenly

1370
01:06:45,860 --> 01:06:47,620
changes the day's priorities.

1371
01:06:47,620 --> 01:06:49,020
You don't need to assume disaster.

1372
01:06:49,020 --> 01:06:50,700
You need to include normal factory life.

1373
01:06:50,700 --> 01:06:54,700
If you test a capacity increase only under ideal conditions, the answer will almost always

1374
01:06:54,700 --> 01:06:55,700
look good.

1375
01:06:55,700 --> 01:07:00,380
Add a shift, add a machine, reduce the cycle time and the model produces more parts.

1376
01:07:00,380 --> 01:07:03,500
But the factory already knows how to look good on a quiet day.

1377
01:07:03,500 --> 01:07:06,460
The decision needs to survive the days when conditions are less kind.

1378
01:07:06,460 --> 01:07:08,820
That's where the simulation earns its place.

1379
01:07:08,820 --> 01:07:11,780
Start with the disruptions that production teams recognize.

1380
01:07:11,780 --> 01:07:13,860
Not every exception belongs in the first model.

1381
01:07:13,860 --> 01:07:17,860
You're looking for events that occur often enough or hurt enough to change the decision.

1382
01:07:17,860 --> 01:07:21,180
A short machine interruption may matter a lot at the constrained process.

1383
01:07:21,180 --> 01:07:25,860
The same interruption on a resource with spare time may barely affect the customer date.

1384
01:07:25,860 --> 01:07:27,420
Location matters.

1385
01:07:27,420 --> 01:07:29,500
For each disruption describe three things.

1386
01:07:29,500 --> 01:07:30,500
How often does it occur?

1387
01:07:30,500 --> 01:07:32,100
How long does it usually last?

1388
01:07:32,100 --> 01:07:34,340
And what rule does the factory follow once it happens?

1389
01:07:34,340 --> 01:07:35,540
Think about a machine stop.

1390
01:07:35,540 --> 01:07:39,460
The model doesn't need a mythical average breakdown that treats every failure as identical.

1391
01:07:39,460 --> 01:07:42,260
Instead, it can represent a pattern people recognize.

1392
01:07:42,260 --> 01:07:45,940
Short stops that happen regularly, along with less frequent longer repairs.

1393
01:07:45,940 --> 01:07:46,940
Recovery also needs rules.

1394
01:07:46,940 --> 01:07:48,740
Can maintenance respond on every shift?

1395
01:07:48,740 --> 01:07:50,780
Does the machine need a qualified restart?

1396
01:07:50,780 --> 01:07:53,620
Does quality need to release the first part after a repair?

1397
01:07:53,620 --> 01:07:57,060
A machine doesn't return to normal just because the alarm disappears.

1398
01:07:57,060 --> 01:07:59,180
Late material needs the same care.

1399
01:07:59,180 --> 01:08:04,780
The ERP plan may show an expected receipt date, but the order only becomes usable when the material arrives,

1400
01:08:04,780 --> 01:08:08,620
passes the checks it needs and reaches the point where production can consume it.

1401
01:08:08,620 --> 01:08:12,660
If the missing item belongs to one product family, the scheduler may switch to another job.

1402
01:08:12,660 --> 01:08:16,780
That sounds simple until the alternate job needs a different setup, fixture or worker.

1403
01:08:16,780 --> 01:08:18,540
The recovery action creates its own effect.

1404
01:08:18,540 --> 01:08:21,460
Quality holds can change the flow in a less visible way.

1405
01:08:21,460 --> 01:08:27,020
A batch may finish an operation and appear as produced yet it cannot move because somebody needs to review the result.

1406
01:08:27,020 --> 01:08:29,780
If the hold clears quickly, a buffer may absorb it.

1407
01:08:29,780 --> 01:08:34,460
If it extends into the next shift, the effect can reach assembly, test, packing or shipping.

1408
01:08:34,460 --> 01:08:37,180
The model should represent the hold where it blocks the route.

1409
01:08:37,180 --> 01:08:39,580
Operator absence often gets simplified too much.

1410
01:08:39,580 --> 01:08:43,820
Removing a percentage from the labor plan doesn't tell you which tasks can no longer happen.

1411
01:08:43,820 --> 01:08:50,060
The more useful question is which approvals, setups, checks or recovery actions lose coverage when that person isn't there.

1412
01:08:50,060 --> 01:08:52,220
That gives you a scenario people can act on.

1413
01:08:52,220 --> 01:08:54,060
Tool issues belong in the same group.

1414
01:08:54,060 --> 01:09:00,700
A warn cutter, missing fixture, calibration problem, or unavailable test device can delay work even when the main machine has time.

1415
01:09:00,700 --> 01:09:06,140
These events might sit outside the machine state data, which is one reason a model needs input from the people who run the process,

1416
01:09:06,140 --> 01:09:08,020
not only timestamps from systems.

1417
01:09:08,020 --> 01:09:11,260
The factory contains more constraints than the event log can name.

1418
01:09:11,260 --> 01:09:18,300
Once you describe plausible disruptions, test the plan under them, run an expected case where normal variation occurs at a manageable level,

1419
01:09:18,300 --> 01:09:21,820
then run a strained case where a few ordinary problems arrive close together.

1420
01:09:21,820 --> 01:09:28,620
You can also test a severe but still believable case such as a longer outage at the constrained resource while a material delay affects an urgent order.

1421
01:09:28,620 --> 01:09:31,100
Don't call that pessimism, call it preparation.

1422
01:09:31,100 --> 01:09:33,820
The question isn't whether every bad event can be prevented.

1423
01:09:33,820 --> 01:09:34,500
It can't.

1424
01:09:34,500 --> 01:09:37,700
The question is whether the proposed plan has enough room to recover.

1425
01:09:37,700 --> 01:09:41,060
Does the extra shift still improve customer delivery after a short stop?

1426
01:09:41,060 --> 01:09:43,180
Does the larger buffer protect the constraint?

1427
01:09:43,180 --> 01:09:46,220
Or does it only create more aged work when quality holds a batch?

1428
01:09:46,220 --> 01:09:50,100
Does the new sequence provide a sensible fallback when material fails to arrive?

1429
01:09:50,100 --> 01:09:51,780
A good plan has recovery paths.

1430
01:09:51,780 --> 01:09:53,740
This also changes how you read efficiency.

1431
01:09:53,740 --> 01:09:58,860
A plan that fills every hour with productive work may deliver the highest output in the ideal case.

1432
01:09:58,860 --> 01:10:02,980
Yet if one interruption turns it into a week of expediting overtime and missed dates,

1433
01:10:02,980 --> 01:10:06,380
it may be more fragile than a plan with modest recovery room at the right point.

1434
01:10:06,380 --> 01:10:09,660
The model can expose that difference before the shop floor pays for it.

1435
01:10:09,660 --> 01:10:11,020
Keep the result honest.

1436
01:10:11,020 --> 01:10:14,860
Simulation doesn't tell you that a machine will fail at 10 past 11 on Thursday.

1437
01:10:14,860 --> 01:10:18,980
It tells you how a chosen operating model tends to behave when failures, delays and holds

1438
01:10:18,980 --> 01:10:21,380
occur within the ranges you consider credible.

1439
01:10:21,380 --> 01:10:24,180
That is a much better question than pretending certainty.

1440
01:10:24,180 --> 01:10:28,780
When a scenario performs well only if nothing interrupts it, you haven't found an efficient plan.

1441
01:10:28,780 --> 01:10:31,100
You've found a plan that depends on luck.

1442
01:10:31,100 --> 01:10:35,740
When one machine goes down, a constrained machine stops for three hours in the middle of the day.

1443
01:10:35,740 --> 01:10:39,260
Nobody needs a simulation to tell you that three hours of loss production hurts.

1444
01:10:39,260 --> 01:10:43,340
But the harder question is what the rest of the factory should do while that machine is down.

1445
01:10:43,340 --> 01:10:47,980
Because the best local response can still create a worse result for customer orders.

1446
01:10:47,980 --> 01:10:50,980
Picture a resource that runs a part family with a tight route.

1447
01:10:50,980 --> 01:10:53,300
Several orders already wait in its queue.

1448
01:10:53,300 --> 01:10:57,620
Some belong to customers with near due dates and others still need the same inspection station,

1449
01:10:57,620 --> 01:11:00,700
a special tool and assembly capacity after machining.

1450
01:11:00,700 --> 01:11:02,740
Then the alarm comes in and the machine stops.

1451
01:11:02,740 --> 01:11:04,100
The first choice is to wait.

1452
01:11:04,100 --> 01:11:07,220
Maintenance works on the fault, the queue stays where it is,

1453
01:11:07,220 --> 01:11:09,860
and the planner protects the schedule as much as possible.

1454
01:11:09,860 --> 01:11:12,420
That can make sense when the repair has a known short duration,

1455
01:11:12,420 --> 01:11:16,700
and the work behind the machine can still recover within the shift or through approved overtime.

1456
01:11:16,700 --> 01:11:20,140
But waiting consumes recovery room and that room doesn't come back.

1457
01:11:20,140 --> 01:11:21,940
The second choice is re-sequencing.

1458
01:11:21,940 --> 01:11:25,100
The planner looks for orders that don't need the failed resource right now,

1459
01:11:25,100 --> 01:11:27,660
or for work already ready at another operation.

1460
01:11:27,660 --> 01:11:31,140
That keeps people busy and stops a wider part of the route from running dry.

1461
01:11:31,140 --> 01:11:35,700
But it can also pull tomorrow's work forward, leaving less flexibility after the machine returns.

1462
01:11:35,700 --> 01:11:37,180
You haven't removed the pressure.

1463
01:11:37,180 --> 01:11:39,020
You've just moved it through time.

1464
01:11:39,020 --> 01:11:40,460
Then there may be an alternate route,

1465
01:11:40,460 --> 01:11:43,140
maybe another machine can process some of the affected parts.

1466
01:11:43,140 --> 01:11:46,580
Before treating that as an answer, the model needs to ask practical questions.

1467
01:11:46,580 --> 01:11:48,940
Is the alternate machine approved for this process revision?

1468
01:11:48,940 --> 01:11:50,780
Does it have the fixture program and tooling?

1469
01:11:50,780 --> 01:11:52,780
Is a qualified operator available on that shift?

1470
01:11:52,780 --> 01:11:55,900
Can quality accept output from that route without another delay?

1471
01:11:55,900 --> 01:11:59,140
An alternate resource only counts when the full route supports it.

1472
01:11:59,140 --> 01:12:01,340
Suppose it can run the work but at a slower rate.

1473
01:12:01,340 --> 01:12:04,540
Moving the urgent orders may still protect a customer date,

1474
01:12:04,540 --> 01:12:09,220
but at the same time the alternate machine might displace other work that had its own deadline.

1475
01:12:09,220 --> 01:12:11,460
It may also feed the same inspection station,

1476
01:12:11,460 --> 01:12:14,300
creating a queue that wasn't visible when everyone focused on the breakdown.

1477
01:12:14,300 --> 01:12:17,260
That's why a machine outage is never only a machine problem.

1478
01:12:17,260 --> 01:12:19,460
A simulation can take the orders already released.

1479
01:12:19,460 --> 01:12:21,900
Their due dates available material, approved routes,

1480
01:12:21,900 --> 01:12:25,140
labor cover and downstream limits, then compare the choices.

1481
01:12:25,140 --> 01:12:26,620
One case waits for the repair.

1482
01:12:26,620 --> 01:12:28,180
Another moves selected orders.

1483
01:12:28,180 --> 01:12:30,660
A third uses overtime after the machine returns,

1484
01:12:30,660 --> 01:12:36,220
and a fourth accepts a delay for lower priority work to protect the orders that still have a real path to shipment.

1485
01:12:36,220 --> 01:12:38,740
The results need to stay tied to the whole flow.

1486
01:12:38,740 --> 01:12:42,020
You might find that moving every possible order to the alternate machine

1487
01:12:42,020 --> 01:12:43,540
creates the most activity,

1488
01:12:43,540 --> 01:12:45,380
but does little for customer delivery,

1489
01:12:45,380 --> 01:12:48,060
because final inspection becomes overloaded.

1490
01:12:48,060 --> 01:12:50,460
Or you may find that leaving a small group of jobs in place

1491
01:12:50,460 --> 01:12:51,940
and moving only one product family

1492
01:12:51,940 --> 01:12:54,180
protects more shipments with less disruption.

1493
01:12:54,180 --> 01:12:56,340
More movement isn't always better recovery.

1494
01:12:56,340 --> 01:12:58,620
Material status matters during the outage too.

1495
01:12:58,620 --> 01:13:00,420
A job may look ready in the queue,

1496
01:13:00,420 --> 01:13:03,140
but a required bought-in component might arrive later,

1497
01:13:03,140 --> 01:13:05,940
or its material certificate may still wait for approval.

1498
01:13:05,940 --> 01:13:09,060
If the planner moves that job into the alternate machine slot,

1499
01:13:09,060 --> 01:13:12,340
they lose scarce time that another truly ready order could use.

1500
01:13:12,340 --> 01:13:14,980
The model needs to distinguish planned work from runnable work.

1501
01:13:14,980 --> 01:13:17,420
Inspection limits can decide the outcome as well.

1502
01:13:17,420 --> 01:13:20,020
After repair, some processes need a first off check

1503
01:13:20,020 --> 01:13:22,180
before regular production resumes.

1504
01:13:22,180 --> 01:13:24,940
If the inspection team cannot respond until the next shift,

1505
01:13:24,940 --> 01:13:28,420
a three hour equipment stop may become a longer production stop.

1506
01:13:28,420 --> 01:13:31,540
The same applies when an alternate route needs extra verification

1507
01:13:31,540 --> 01:13:33,100
before parts can proceed.

1508
01:13:33,100 --> 01:13:35,420
That's the sort of detail that changes a recovery plan.

1509
01:13:35,420 --> 01:13:36,740
There's also a customer choice.

1510
01:13:36,740 --> 01:13:38,980
Sometimes no option protects every order.

1511
01:13:38,980 --> 01:13:41,780
The model can show which promise breaks under each response,

1512
01:13:41,780 --> 01:13:45,060
how much work moves, and where recovery capacity disappears.

1513
01:13:45,060 --> 01:13:47,220
Then the production lead planner and commercial team

1514
01:13:47,220 --> 01:13:50,180
can make a conscious call instead of discovering the effect

1515
01:13:50,180 --> 01:13:51,420
after the data's passed.

1516
01:13:51,420 --> 01:13:53,060
A late order is bad enough.

1517
01:13:53,060 --> 01:13:56,020
A late order nobody wants the customer about is usually worse.

1518
01:13:56,020 --> 01:13:58,660
The point isn't to automate a breakdown response from a distance.

1519
01:13:58,660 --> 01:14:01,340
People close to the work still need to judge safety,

1520
01:14:01,340 --> 01:14:04,340
machine condition, quality risk, and customer priority.

1521
01:14:04,340 --> 01:14:06,460
Simulation gives them a tested set of options

1522
01:14:06,460 --> 01:14:07,940
with the constraints visible.

1523
01:14:07,940 --> 01:14:11,380
That matters because a three hour outage rarely arrives alone.

1524
01:14:11,380 --> 01:14:13,100
Its effect depends on the other variation

1525
01:14:13,100 --> 01:14:14,980
already moving through the factory.

1526
01:14:14,980 --> 01:14:17,620
Simulation should use ranges not pretend certainty.

1527
01:14:17,620 --> 01:14:19,220
A factory model should never pretend

1528
01:14:19,220 --> 01:14:21,020
it knows the future down to a single number.

1529
01:14:21,020 --> 01:14:24,220
You might run a scenario and hear that the proposed shift pattern

1530
01:14:24,220 --> 01:14:26,780
will produce exactly a certain number of completed orders

1531
01:14:26,780 --> 01:14:29,580
with a precise lead time and no late work.

1532
01:14:29,580 --> 01:14:31,620
That can sound reassuring, especially when someone needs

1533
01:14:31,620 --> 01:14:33,340
to approve a budget or defend a plan.

1534
01:14:33,340 --> 01:14:35,460
But factories don't operate on fixed cycle times,

1535
01:14:35,460 --> 01:14:38,340
fixed repair times, fixed yields or fixed attendance.

1536
01:14:38,340 --> 01:14:39,660
They operate inside ranges.

1537
01:14:39,660 --> 01:14:43,020
A machining operation may usually finish within a narrow time band,

1538
01:14:43,020 --> 01:14:46,260
but material condition, toolware, setup quality,

1539
01:14:46,260 --> 01:14:48,660
and the product variant can shift that time.

1540
01:14:48,660 --> 01:14:50,500
A maintenance repair may take a short period

1541
01:14:50,500 --> 01:14:52,340
when the fault is familiar and the spare parts

1542
01:14:52,340 --> 01:14:53,180
sits in stores.

1543
01:14:53,180 --> 01:14:55,500
The same fault can take longer when diagnosis takes time

1544
01:14:55,500 --> 01:14:57,420
or support isn't available on that shift.

1545
01:14:57,420 --> 01:15:00,540
The model should reflect that spread, yield works the same way.

1546
01:15:00,540 --> 01:15:02,660
A route may normally produce acceptable parts

1547
01:15:02,660 --> 01:15:05,620
at a predictable rate, but not every batch follows the average.

1548
01:15:05,620 --> 01:15:08,180
If you model yield as perfect, you remove rework

1549
01:15:08,180 --> 01:15:09,900
and scrap pressure from the plan.

1550
01:15:09,900 --> 01:15:11,500
If you use one fixed yield value,

1551
01:15:11,500 --> 01:15:13,540
you may still hide the difference between a normal week

1552
01:15:13,540 --> 01:15:14,580
and a difficult one.

1553
01:15:14,580 --> 01:15:16,660
The point isn't to make the model gloomy.

1554
01:15:16,660 --> 01:15:19,780
It's to give the decision an honest shape.

1555
01:15:19,780 --> 01:15:21,020
Think about incoming work.

1556
01:15:21,020 --> 01:15:23,380
Customer demand may arrive in uneven patterns.

1557
01:15:23,380 --> 01:15:25,580
Material receipts may arrive early, late,

1558
01:15:25,580 --> 01:15:26,940
or in partial quantities.

1559
01:15:26,940 --> 01:15:29,780
Absence can affect a general work area very differently

1560
01:15:29,780 --> 01:15:32,860
from a constrained operation with only one person approved

1561
01:15:32,860 --> 01:15:33,700
for a task.

1562
01:15:33,700 --> 01:15:37,220
A plan needs to handle the variation that the factory already sees.

1563
01:15:37,220 --> 01:15:38,700
So instead of asking what will happen,

1564
01:15:38,700 --> 01:15:40,660
I'd frame the question differently.

1565
01:15:40,660 --> 01:15:43,260
Under expected conditions, what result is likely?

1566
01:15:43,260 --> 01:15:45,820
Under strained conditions, where does the pressure appear?

1567
01:15:45,820 --> 01:15:48,500
And under a severe but believable combination of events

1568
01:15:48,500 --> 01:15:51,660
which customer commitments or internal targets become exposed?

1569
01:15:51,660 --> 01:15:53,220
Those are decisions you can use.

1570
01:15:53,220 --> 01:15:56,780
An expected case might use normal demand, normal operating time,

1571
01:15:56,780 --> 01:15:59,180
and the usual range of small interruptions.

1572
01:15:59,180 --> 01:16:01,060
It gives you a view of how the proposal behaves

1573
01:16:01,060 --> 01:16:03,260
when the factory runs in a broadly familiar way,

1574
01:16:03,260 --> 01:16:04,980
not in an imaginary perfect week.

1575
01:16:04,980 --> 01:16:07,140
Then build a strained case, maybe demand,

1576
01:16:07,140 --> 01:16:09,540
includes more of the difficult product family.

1577
01:16:09,540 --> 01:16:11,220
Maybe a repair takes longer than usual,

1578
01:16:11,220 --> 01:16:13,180
while a quality hold delays one batch.

1579
01:16:13,180 --> 01:16:15,260
Maybe an absence removes qualified coverage

1580
01:16:15,260 --> 01:16:16,460
for part of a shift.

1581
01:16:16,460 --> 01:16:18,900
None of those conditions needs a disaster plan.

1582
01:16:18,900 --> 01:16:20,580
They are ordinary sources of pressure

1583
01:16:20,580 --> 01:16:22,020
that can arrive close together,

1584
01:16:22,020 --> 01:16:24,740
and that's usually when a weak plan reveals itself.

1585
01:16:24,740 --> 01:16:26,980
A severe case should still stay plausible.

1586
01:16:26,980 --> 01:16:29,420
Don't invent a sequence of failures that nobody has seen

1587
01:16:29,420 --> 01:16:31,100
and then reject every change proposal

1588
01:16:31,100 --> 01:16:32,900
because the model produces chaos.

1589
01:16:32,900 --> 01:16:34,740
Use events the team recognizes,

1590
01:16:34,740 --> 01:16:36,500
then combine them in a way that tests,

1591
01:16:36,500 --> 01:16:39,060
whether the proposed operating model has recovery room.

1592
01:16:39,060 --> 01:16:41,700
The scenario should challenge the plan, not rig the result,

1593
01:16:41,700 --> 01:16:44,460
because variation includes chance one run doesn't tell you enough.

1594
01:16:44,460 --> 01:16:46,140
Run the same scenario many times

1595
01:16:46,140 --> 01:16:48,580
with different draws from the cycle time, repair time,

1596
01:16:48,580 --> 01:16:50,260
yield arrival and absence ranges.

1597
01:16:50,260 --> 01:16:52,020
In some runs, the week may flow well.

1598
01:16:52,020 --> 01:16:55,500
In others, ordinary variation may stack up at the wrong time.

1599
01:16:55,500 --> 01:16:57,660
That spread tells a better story than one answer.

1600
01:16:57,660 --> 01:16:59,740
You may find that an extra shift clears the backlog

1601
01:16:59,740 --> 01:17:01,180
in most expected runs,

1602
01:17:01,180 --> 01:17:03,180
but creates a growing queue in a meaningful share

1603
01:17:03,180 --> 01:17:05,820
of strained runs because inspection cannot keep up.

1604
01:17:05,820 --> 01:17:08,580
Or a new machine may reduce late orders on a normal demand,

1605
01:17:08,580 --> 01:17:10,740
but only if a trained operator and shared fixture

1606
01:17:10,740 --> 01:17:11,620
remain available.

1607
01:17:11,620 --> 01:17:13,780
Now you can see the conditions behind the result.

1608
01:17:13,780 --> 01:17:16,300
This is where scenario outputs need careful language.

1609
01:17:16,300 --> 01:17:18,220
Don't present one number as a promise.

1610
01:17:18,220 --> 01:17:21,020
Present a range, the assumptions behind it and the trade-offs.

1611
01:17:21,020 --> 01:17:23,540
You might say that a proposal improves the expected outcome,

1612
01:17:23,540 --> 01:17:26,780
but delivery risk rises when a given resource loses coverage

1613
01:17:26,780 --> 01:17:30,260
or when demand shifts toward a harder product family.

1614
01:17:30,260 --> 01:17:32,980
That gives decision owners something real to discuss.

1615
01:17:32,980 --> 01:17:34,700
Confidence also needs a practical meaning.

1616
01:17:34,700 --> 01:17:37,260
It doesn't mean the model has somehow removed uncertainty.

1617
01:17:37,260 --> 01:17:39,580
It means the team understands the input ranges,

1618
01:17:39,580 --> 01:17:41,820
has checked the model against normal behavior,

1619
01:17:41,820 --> 01:17:44,860
and knows where the result becomes sensitive to an assumption.

1620
01:17:44,860 --> 01:17:46,660
A sensitive assumption deserves attention.

1621
01:17:46,660 --> 01:17:48,700
Perhaps the recommendation changes completely

1622
01:17:48,700 --> 01:17:51,580
if a repair takes longer than the maintenance plan assumes.

1623
01:17:51,580 --> 01:17:54,540
Perhaps the result depends on quality release during a late shift.

1624
01:17:54,540 --> 01:17:56,180
Those are not flaws to hide.

1625
01:17:56,180 --> 01:17:58,980
They tell you where a small improvement in process knowledge,

1626
01:17:58,980 --> 01:18:02,100
staffing cover or operating rule could reduce risk.

1627
01:18:02,100 --> 01:18:04,460
The model becomes a way to find fragile assumptions

1628
01:18:04,460 --> 01:18:06,540
before they turn into real disruption.

1629
01:18:06,540 --> 01:18:08,140
And there's a temptation at this point

1630
01:18:08,140 --> 01:18:10,380
to ask an AI system for the best answer.

1631
01:18:10,380 --> 01:18:12,060
That can be useful in the right place,

1632
01:18:12,060 --> 01:18:14,140
but a language model shouldn't invent certainty

1633
01:18:14,140 --> 01:18:17,980
around a schedule, a safety rule, or a customer promise.

1634
01:18:17,980 --> 01:18:20,220
Where industrial AI fits and where it doesn't.

1635
01:18:20,220 --> 01:18:22,700
So you're probably wondering, can AI just figure out

1636
01:18:22,700 --> 01:18:24,340
the best production plan for me?

1637
01:18:24,340 --> 01:18:25,980
It can help, but here's the thing.

1638
01:18:25,980 --> 01:18:28,260
AI covers a bunch of different kinds of work.

1639
01:18:28,260 --> 01:18:30,740
And when you lump them together, you get trouble fast.

1640
01:18:30,740 --> 01:18:32,940
Industrial AI can spot patterns in machine signals

1641
01:18:32,940 --> 01:18:34,820
that point to abnormal behavior.

1642
01:18:34,820 --> 01:18:38,540
It can classify quality notes, pull data from supplier documents,

1643
01:18:38,540 --> 01:18:41,540
find demand patterns, or let a planner ask a plain language

1644
01:18:41,540 --> 01:18:43,540
question instead of digging through reports.

1645
01:18:43,540 --> 01:18:46,020
Those are solid practical uses, especially

1646
01:18:46,020 --> 01:18:48,460
when the data is governed and the question stays sharp.

1647
01:18:48,460 --> 01:18:51,100
But a simulation model and an optimization engine

1648
01:18:51,100 --> 01:18:52,580
do a completely different job.

1649
01:18:52,580 --> 01:18:53,900
They work with explicit rules.

1650
01:18:53,900 --> 01:18:56,620
They need to know which machine can run which operation,

1651
01:18:56,620 --> 01:18:59,180
how long setup takes, whether a tool is available,

1652
01:18:59,180 --> 01:19:01,180
which operator has approval, and what

1653
01:19:01,180 --> 01:19:04,300
has to happen before a part moves to the next step.

1654
01:19:04,300 --> 01:19:07,220
They test the effect of choices against those constraints.

1655
01:19:07,220 --> 01:19:08,180
That's not a limitation.

1656
01:19:08,180 --> 01:19:09,660
That's the whole point.

1657
01:19:09,660 --> 01:19:11,260
A language model can help someone explore

1658
01:19:11,260 --> 01:19:13,140
what a scenario actually means.

1659
01:19:13,140 --> 01:19:16,300
It might answer which assumption drives most of the late order

1660
01:19:16,300 --> 01:19:19,180
risk, or which product family puts the most load

1661
01:19:19,180 --> 01:19:21,860
on final inspection in the strained case.

1662
01:19:21,860 --> 01:19:25,140
If it can access approved scenario results and model facts,

1663
01:19:25,140 --> 01:19:27,140
that makes analysis a lot faster for people

1664
01:19:27,140 --> 01:19:29,460
who don't live inside the planning system all day.

1665
01:19:29,460 --> 01:19:31,420
But the model still provides the answer space.

1666
01:19:31,420 --> 01:19:34,100
Think about a co-pilot style assistant in the setting.

1667
01:19:34,100 --> 01:19:37,260
It should not get a vague prompt like fix next week's schedule

1668
01:19:37,260 --> 01:19:39,220
and then invent a plan from incomplete data

1669
01:19:39,220 --> 01:19:40,380
and general knowledge.

1670
01:19:40,380 --> 01:19:43,700
Production schedules contain safety rules, process approvals,

1671
01:19:43,700 --> 01:19:46,460
labor agreements, customer commitments, and local constraints

1672
01:19:46,460 --> 01:19:47,940
that can change our shift.

1673
01:19:47,940 --> 01:19:50,140
Those rules need a controlled source, a better patent

1674
01:19:50,140 --> 01:19:51,140
looks like this.

1675
01:19:51,140 --> 01:19:52,620
The simulation and scheduling tools

1676
01:19:52,620 --> 01:19:56,020
run approved scenarios using known inputs and clear constraints.

1677
01:19:56,020 --> 01:19:59,380
The results show possible outcomes, risk ranges, queues,

1678
01:19:59,380 --> 01:20:01,660
resource load, and customer data exposure.

1679
01:20:01,660 --> 01:20:03,300
Then the AI assistant helps the planner

1680
01:20:03,300 --> 01:20:05,900
understand those results, compare documented options,

1681
01:20:05,900 --> 01:20:08,380
or produce a clear briefing for the production meeting.

1682
01:20:08,380 --> 01:20:09,660
That keeps the roles clean.

1683
01:20:09,660 --> 01:20:12,460
Generative AI works well with language, documents,

1684
01:20:12,460 --> 01:20:15,220
explanation, and guided access to information.

1685
01:20:15,220 --> 01:20:17,580
It can turn a maintenance note into structured data.

1686
01:20:17,580 --> 01:20:19,020
It can search operating procedures.

1687
01:20:19,020 --> 01:20:22,220
It can explain why a selected scenario performs poorly.

1688
01:20:22,220 --> 01:20:23,940
Provided the reason actually exists

1689
01:20:23,940 --> 01:20:26,100
in the model output or source data.

1690
01:20:26,100 --> 01:20:28,420
What it should not do is create process facts

1691
01:20:28,420 --> 01:20:30,780
just because a prompt sounds confident.

1692
01:20:30,780 --> 01:20:32,660
Optimization tools work differently again.

1693
01:20:32,660 --> 01:20:35,180
If you define the objective and the hard constraints

1694
01:20:35,180 --> 01:20:37,020
an optimizer can search through tons

1695
01:20:37,020 --> 01:20:39,940
of possible combinations of assignments, sequences,

1696
01:20:39,940 --> 01:20:41,380
or resource choices.

1697
01:20:41,380 --> 01:20:43,300
For example, it might look for a schedule

1698
01:20:43,300 --> 01:20:46,140
that reduces late orders while respecting approved roots,

1699
01:20:46,140 --> 01:20:49,700
finite capacity, shift calendars, and setup rules.

1700
01:20:49,700 --> 01:20:51,940
That can be powerful, but it depends entirely

1701
01:20:51,940 --> 01:20:53,100
on the rules you gave it.

1702
01:20:53,100 --> 01:20:55,940
If the model treats an operator as qualified when they're not,

1703
01:20:55,940 --> 01:20:57,580
the optimizer might produce a schedule

1704
01:20:57,580 --> 01:20:59,700
that looks mathematically clean, but fails

1705
01:20:59,700 --> 01:21:01,060
at the first shift handover.

1706
01:21:01,060 --> 01:21:02,540
If it ignores inspection release,

1707
01:21:02,540 --> 01:21:04,580
it may promise output that can't ship.

1708
01:21:04,580 --> 01:21:07,020
An optimizer doesn't know which assumptions are wrong.

1709
01:21:07,020 --> 01:21:09,100
It just follows them with impressive discipline.

1710
01:21:09,100 --> 01:21:12,380
Computers are very good at being consistently wrong at scale.

1711
01:21:12,380 --> 01:21:15,540
So I separate prediction, simulation, optimization,

1712
01:21:15,540 --> 01:21:18,660
and generative AI instead of treating them like one thing.

1713
01:21:18,660 --> 01:21:21,460
Prediction estimates what may happen based on past patterns.

1714
01:21:21,460 --> 01:21:23,260
Simulation tests how the factory behaves

1715
01:21:23,260 --> 01:21:24,580
under stated conditions.

1716
01:21:24,580 --> 01:21:26,660
Optimization searches for a preferred option

1717
01:21:26,660 --> 01:21:28,060
within those conditions.

1718
01:21:28,060 --> 01:21:30,380
Generative AI helps people work with language

1719
01:21:30,380 --> 01:21:31,980
and knowledge around the decision.

1720
01:21:31,980 --> 01:21:33,100
Each has a place.

1721
01:21:33,100 --> 01:21:35,740
There's another useful role for AI in simulation work.

1722
01:21:35,740 --> 01:21:38,020
It can help identify model gaps.

1723
01:21:38,020 --> 01:21:39,740
If historical data shows that a routing

1724
01:21:39,740 --> 01:21:41,740
takes longer for a certain product family

1725
01:21:41,740 --> 01:21:44,460
or that a queue grows after a specific quality event,

1726
01:21:44,460 --> 01:21:47,900
analytics might point the team toward a rule they need to examine.

1727
01:21:47,900 --> 01:21:49,420
Then people who understand the process

1728
01:21:49,420 --> 01:21:51,860
decide whether that pattern belongs in the model,

1729
01:21:51,860 --> 01:21:53,540
that judgment can't disappear.

1730
01:21:53,540 --> 01:21:56,540
A planner may know that a customer order needs special handling.

1731
01:21:56,540 --> 01:21:58,780
A maintenance lead may know that a repeat fault

1732
01:21:58,780 --> 01:22:01,100
only occurs after a particular setup.

1733
01:22:01,100 --> 01:22:04,180
A quality engineer may know a root change is pending approval.

1734
01:22:04,180 --> 01:22:06,460
These facts may not sit neatly in a database,

1735
01:22:06,460 --> 01:22:08,340
yet they can change the right decision.

1736
01:22:08,340 --> 01:22:10,660
AI should help bring those facts into the discussion,

1737
01:22:10,660 --> 01:22:12,300
not pretend they don't exist.

1738
01:22:12,300 --> 01:22:14,460
As a Microsoft MVP, I spend a lot of time

1739
01:22:14,460 --> 01:22:16,340
looking at where tools like Azure AI,

1740
01:22:16,340 --> 01:22:18,300
Co-Pilot, Fabric, and Power Platform

1741
01:22:18,300 --> 01:22:20,220
fit in an industrial architecture.

1742
01:22:20,220 --> 01:22:22,660
They can connect the dots between IT and OT,

1743
01:22:22,660 --> 01:22:24,500
give teams better access to information

1744
01:22:24,500 --> 01:22:25,900
and support decision work.

1745
01:22:25,900 --> 01:22:28,140
But none of them replaces the factory model.

1746
01:22:28,140 --> 01:22:30,500
The model defines the relationships, constraints,

1747
01:22:30,500 --> 01:22:32,060
and approve choices.

1748
01:22:32,060 --> 01:22:35,140
AI can make that model easier to query and easier to explain.

1749
01:22:35,140 --> 01:22:36,620
It can support a planner.

1750
01:22:36,620 --> 01:22:38,820
It cannot take responsibility for releasing work

1751
01:22:38,820 --> 01:22:40,140
into a real factory.

1752
01:22:40,140 --> 01:22:42,660
Before putting AI near a production decision,

1753
01:22:42,660 --> 01:22:43,980
ask a simple question,

1754
01:22:43,980 --> 01:22:47,380
what does it actually know and where did that knowledge come from?

1755
01:22:47,380 --> 01:22:50,780
If the answer is a mix of reports, notes, and whatever it can find,

1756
01:22:50,780 --> 01:22:52,620
keep it away from schedule changes.

1757
01:22:52,620 --> 01:22:55,620
If the answer includes controlled data, explicit rules,

1758
01:22:55,620 --> 01:22:57,620
versioned assumptions, and human approval,

1759
01:22:57,620 --> 01:22:59,940
it can become a useful part of the decision process.

1760
01:22:59,940 --> 01:23:01,420
Now connect that to Microsoft.

1761
01:23:01,420 --> 01:23:03,140
The first requirement isn't an AI prompt.

1762
01:23:03,140 --> 01:23:05,100
It's a data foundation that teams can trust.

1763
01:23:05,100 --> 01:23:07,220
Microsoft Fabric as a data foundation.

1764
01:23:07,220 --> 01:23:09,980
If you want to test factory changes with any confidence,

1765
01:23:09,980 --> 01:23:12,220
the model needs inputs people can trace.

1766
01:23:12,220 --> 01:23:13,820
That starts with data from the systems

1767
01:23:13,820 --> 01:23:15,940
that already run the business and the plant.

1768
01:23:15,940 --> 01:23:19,260
Microsoft Fabric can provide a shared data foundation for that work.

1769
01:23:19,260 --> 01:23:20,620
It can bring data from ERP,

1770
01:23:20,620 --> 01:23:22,820
MES, IoT sources, quality systems,

1771
01:23:22,820 --> 01:23:24,660
maintenance records, and labor systems

1772
01:23:24,660 --> 01:23:27,220
into a governed environment where teams can prepare it,

1773
01:23:27,220 --> 01:23:29,540
compare it, and use it for analysis.

1774
01:23:29,540 --> 01:23:31,700
That sounds simple, but it rarely is.

1775
01:23:31,700 --> 01:23:34,220
Your ERP might identify a work order one way.

1776
01:23:34,220 --> 01:23:38,540
MES may record the same work through an operation record or production lot.

1777
01:23:38,540 --> 01:23:40,620
Maintenance may know the machine by an asset tag

1778
01:23:40,620 --> 01:23:42,820
that doesn't match the name used in the schedule.

1779
01:23:42,820 --> 01:23:44,580
Quality may track a batch number

1780
01:23:44,580 --> 01:23:46,700
while material data follows a supply a lot.

1781
01:23:46,700 --> 01:23:48,820
Fabric can bring those records into one place,

1782
01:23:48,820 --> 01:23:52,140
but it can't decide on its own whether they refer to the same real world thing.

1783
01:23:52,140 --> 01:23:53,660
So the first job is data engineering.

1784
01:23:53,660 --> 01:23:55,140
You need to extract the records,

1785
01:23:55,140 --> 01:23:57,580
manage refresh timing, check data quality,

1786
01:23:57,580 --> 01:23:59,260
and keep a trace back to the source.

1787
01:23:59,260 --> 01:24:03,420
You also need rules for identities, time stamps, units, and status values.

1788
01:24:03,420 --> 01:24:06,740
If one source means complete when machine processing finishes,

1789
01:24:06,740 --> 01:24:09,020
while another means final quality release,

1790
01:24:09,020 --> 01:24:12,340
a simulation fed by both needs to preserve that difference.

1791
01:24:12,340 --> 01:24:15,500
Otherwise, the model starts with an argument about what happened.

1792
01:24:15,500 --> 01:24:17,620
Think about the flow from the shop floor upward.

1793
01:24:17,620 --> 01:24:20,180
A machine or PLC creates operational signals.

1794
01:24:20,180 --> 01:24:22,740
MES records execution quantities and stops.

1795
01:24:22,740 --> 01:24:25,260
ERP contributes demand, work orders, due dates,

1796
01:24:25,260 --> 01:24:30,220
rootings, and material plans. Quality adds holes, inspections, and release status.

1797
01:24:30,220 --> 01:24:33,940
Maintenance adds planned downtime, failure history, and repair activity.

1798
01:24:33,940 --> 01:24:35,580
Fabric can bring those streams together

1799
01:24:35,580 --> 01:24:38,700
so the team doesn't build every analysis from disconnected extracts

1800
01:24:38,700 --> 01:24:40,060
and manually maintain files.

1801
01:24:40,060 --> 01:24:42,860
That doesn't mean every signal needs to enter the simulation model.

1802
01:24:42,860 --> 01:24:45,300
In fact, loading every available data point into a model

1803
01:24:45,300 --> 01:24:47,860
usually creates noise and slows the work down.

1804
01:24:47,860 --> 01:24:50,300
You need data that explains the decision you are testing.

1805
01:24:50,300 --> 01:24:52,300
For a staffing scenario at a constrained cell,

1806
01:24:52,300 --> 01:24:55,060
you may need shift calendars, skill coverage,

1807
01:24:55,060 --> 01:24:59,500
routing steps, cycle time ranges, set up rules, current queue state,

1808
01:24:59,500 --> 01:25:02,140
and downstream release limits.

1809
01:25:02,140 --> 01:25:04,660
High frequency vibration readings from an unrelated asset

1810
01:25:04,660 --> 01:25:06,180
might help a maintenance team,

1811
01:25:06,180 --> 01:25:08,500
but they probably don't change that staffing decision.

1812
01:25:08,500 --> 01:25:10,700
Use the data because it answers a question.

1813
01:25:10,700 --> 01:25:14,500
Governance becomes part of this as soon as scenario results affect production planning.

1814
01:25:14,500 --> 01:25:16,860
People need to know which routing version the model used,

1815
01:25:16,860 --> 01:25:18,140
when the source data refreshed,

1816
01:25:18,140 --> 01:25:20,260
which assumptions came from operational judgment,

1817
01:25:20,260 --> 01:25:22,940
and who approved a change to the inputs.

1818
01:25:22,940 --> 01:25:25,980
A model with unclear inputs can produce an impressive result

1819
01:25:25,980 --> 01:25:27,940
and still create a bad decision.

1820
01:25:27,940 --> 01:25:31,420
Fabric can support governed data access, managed pipelines,

1821
01:25:31,420 --> 01:25:33,740
and a shared place for curated tables.

1822
01:25:33,740 --> 01:25:36,380
But your organization still needs to assign ownership.

1823
01:25:36,380 --> 01:25:37,860
Someone must own the root data,

1824
01:25:37,860 --> 01:25:39,740
someone must own the resource calendar,

1825
01:25:39,740 --> 01:25:43,300
someone must decide whether the quality status means a batch can move.

1826
01:25:43,300 --> 01:25:46,060
Technology cannot settle those process responsibilities.

1827
01:25:46,060 --> 01:25:48,660
Power BI fits naturally on top of this foundation,

1828
01:25:48,660 --> 01:25:50,740
but its role needs to stay clear.

1829
01:25:50,740 --> 01:25:52,660
You can use it to review the baseline.

1830
01:25:52,660 --> 01:25:55,220
Inspect cycle time variation, downtime patterns,

1831
01:25:55,220 --> 01:25:56,780
QAGE order lateness,

1832
01:25:56,780 --> 01:26:00,140
and the data quality issues that affect the simulation.

1833
01:26:00,140 --> 01:26:01,540
After a scenario runs,

1834
01:26:01,540 --> 01:26:04,700
Power BI can help a planner or production lead compare the options.

1835
01:26:04,700 --> 01:26:07,420
One view might show completed orders by scenario.

1836
01:26:07,420 --> 01:26:09,060
Another might show where Q's build,

1837
01:26:09,060 --> 01:26:10,540
which resource carries the load,

1838
01:26:10,540 --> 01:26:13,380
or where late order risk rises under strained conditions.

1839
01:26:13,380 --> 01:26:15,220
That makes the results easier to discuss,

1840
01:26:15,220 --> 01:26:17,060
but Power BI does not simulate a factory.

1841
01:26:17,060 --> 01:26:19,940
It reports and explores the data and outputs you provide.

1842
01:26:19,940 --> 01:26:22,380
Microsoft Fabric does not generate routing logic,

1843
01:26:22,380 --> 01:26:23,940
understand a worker qualification,

1844
01:26:23,940 --> 01:26:26,500
or decide how a bottleneck responds to a release rule.

1845
01:26:26,500 --> 01:26:28,420
Those behaviors need to come from the factory model

1846
01:26:28,420 --> 01:26:30,340
and the people who understand the process.

1847
01:26:30,340 --> 01:26:32,860
This distinction keeps the architecture honest.

1848
01:26:32,860 --> 01:26:34,300
Fabric can become the data layer

1849
01:26:34,300 --> 01:26:36,820
that connects the dots between IT and OT.

1850
01:26:36,820 --> 01:26:38,820
It can support repeatable data preparation,

1851
01:26:38,820 --> 01:26:41,460
control access, and a common view of source facts.

1852
01:26:41,460 --> 01:26:44,500
As your services and integration tools may sit around it,

1853
01:26:44,500 --> 01:26:46,620
depending on how data enters from plant systems

1854
01:26:46,620 --> 01:26:48,380
and where the simulation engine runs.

1855
01:26:48,380 --> 01:26:51,020
Yet bringing data together still leaves a harder question.

1856
01:26:51,020 --> 01:26:53,940
When the model asks whether an order can move to another resource,

1857
01:26:53,940 --> 01:26:56,340
it needs more than a table of orders and machines.

1858
01:26:56,340 --> 01:26:58,580
It needs to know the relationships between the product,

1859
01:26:58,580 --> 01:27:01,020
process, resource, worker, tool, material,

1860
01:27:01,020 --> 01:27:02,740
and current production state.

1861
01:27:02,740 --> 01:27:05,860
Digital Twin and Knowledge Graph for factory context.

1862
01:27:05,860 --> 01:27:08,500
That missing layer often gets called a digital twin,

1863
01:27:08,500 --> 01:27:10,260
even though the term gets used for everything

1864
01:27:10,260 --> 01:27:13,060
from a 3D building model to a live machine view.

1865
01:27:13,060 --> 01:27:16,140
For factory simulation, I use it in a more practical sense.

1866
01:27:16,140 --> 01:27:18,300
A digital twin is a current model of the factory

1867
01:27:18,300 --> 01:27:20,780
and all the relationships that let work move through it.

1868
01:27:20,780 --> 01:27:23,500
It needs to know the present state, which orders are waiting,

1869
01:27:23,500 --> 01:27:26,820
which resources can run, which materials have cleared the required checks,

1870
01:27:26,820 --> 01:27:30,780
which tools are in use, and which workers have the approval for a given operation.

1871
01:27:30,780 --> 01:27:33,500
But current state alone doesn't answer a planning question,

1872
01:27:33,500 --> 01:27:36,460
because the model also needs the rules that connect those facts.

1873
01:27:36,460 --> 01:27:39,460
Think about the question, can this order move to another machine?

1874
01:27:39,460 --> 01:27:41,500
That sounds simple until you break it down.

1875
01:27:41,500 --> 01:27:43,620
The part may need a certain process revision,

1876
01:27:43,620 --> 01:27:47,100
the alternate machine may physically handle it but lack an approved program,

1877
01:27:47,100 --> 01:27:50,100
a fixture might be required and already booked elsewhere,

1878
01:27:50,100 --> 01:27:52,820
the order may need an operator with a named qualification,

1879
01:27:52,820 --> 01:27:54,620
and even if the operation finishes,

1880
01:27:54,620 --> 01:27:58,100
the next inspection step may only accept output from approved routes.

1881
01:27:58,100 --> 01:28:01,060
Those links are exactly what a knowledge graph captures, a knowledge.

1882
01:28:01,060 --> 01:28:03,740
Graph gives you a way to represent those connections clearly.

1883
01:28:03,740 --> 01:28:06,540
It treats the factory less like a pile of separate tables

1884
01:28:06,540 --> 01:28:08,820
and more like a network of connected facts.

1885
01:28:08,820 --> 01:28:13,140
A product links to a process, a process links to one or more approved resources,

1886
01:28:13,140 --> 01:28:17,220
a resource links to tools, capabilities, calendars, and maintenance state,

1887
01:28:17,220 --> 01:28:18,980
a worker links to qualifications.

1888
01:28:18,980 --> 01:28:22,860
An order links to its current route, material, due date, and quality status.

1889
01:28:22,860 --> 01:28:25,700
That context turns a machine record into a production decision.

1890
01:28:25,700 --> 01:28:28,420
Say the planner sees an order waiting at machine A.

1891
01:28:28,420 --> 01:28:32,940
Without the graph, they might see two machines with similar names and similar rated capacity.

1892
01:28:32,940 --> 01:28:37,620
With the graph, the model can test whether machine B supports the exact operation,