Why Your ERP Can't Build an Optimal Production Schedule

1
00:00:00,000 --> 00:00:03,200
Picture this, a customer calls about an order promised for Friday.

2
00:00:03,200 --> 00:00:06,360
Your planner opens the ERP schedule and it looks fine.

3
00:00:06,360 --> 00:00:09,440
Every operation has a date, every work order is released,

4
00:00:09,440 --> 00:00:13,600
but one machining work center is carrying more load than any real shift could ever process.

5
00:00:13,600 --> 00:00:16,600
The schedule looks complete, but production just can't run it.

6
00:00:16,600 --> 00:00:19,400
That's the contradiction every manufacturer hits eventually.

7
00:00:19,400 --> 00:00:21,440
Your ERP can place work against a date,

8
00:00:21,440 --> 00:00:25,200
but the machine has finite hours, real downtime, and a physical limit.

9
00:00:25,200 --> 00:00:27,800
So why can't ERP just build an optimal schedule?

10
00:00:27,800 --> 00:00:32,400
Let's start with what the ERP schedule actually does and where it stops being useful.

11
00:00:32,400 --> 00:00:34,760
What ERP planning is built to do.

12
00:00:34,760 --> 00:00:38,200
ERP has a big job and it does it well when the data is maintained properly.

13
00:00:38,200 --> 00:00:42,600
It's the system of record for customer demand, sales orders, purchase orders, inventory,

14
00:00:42,600 --> 00:00:46,600
bills of material, production orders, and the financial trail around all of it.

15
00:00:46,600 --> 00:00:50,600
Think of the ERP as the place where the business agrees on what it needs to make,

16
00:00:50,600 --> 00:00:53,800
what it has bought, what it has promised, and what it still needs.

17
00:00:53,800 --> 00:00:58,000
That matters because without that shared record planning becomes a pile of local files, phone calls,

18
00:00:58,000 --> 00:01:01,200
and people trying to remember which version of an order is actually real.

19
00:01:01,200 --> 00:01:05,200
When a customer order arrives, the ERP connects that demand to a product structure.

20
00:01:05,200 --> 00:01:08,200
The bill of material tells it which components the product needs.

21
00:01:08,200 --> 00:01:11,200
The routing tells it which production steps the product should follow.

22
00:01:11,200 --> 00:01:13,400
Inventory records show what stock is on hand,

23
00:01:13,400 --> 00:01:16,200
and purchasing data shows what still do from suppliers.

24
00:01:16,200 --> 00:01:17,800
Now material requirements planning?

25
00:01:17,800 --> 00:01:20,000
MRP does the work it was designed for.

26
00:01:20,000 --> 00:01:22,600
MRP takes that demand and translates it into supply needs.

27
00:01:22,600 --> 00:01:25,400
It can propose a purchase order for a missing component,

28
00:01:25,400 --> 00:01:30,400
suggest a production order for an assembly and work backward through several levels of a bill of material.

29
00:01:30,400 --> 00:01:32,000
That logic solves the real problem.

30
00:01:32,000 --> 00:01:36,600
If you need a finished product in six weeks, MRP helps you figure out which parts must arrive first,

31
00:01:36,600 --> 00:01:40,600
which subassemblies need production, and when planning should release those orders to the floor.

32
00:01:40,600 --> 00:01:44,600
This is demand and supply coordination, not a minute by minute plan for the shop floor.

33
00:01:44,600 --> 00:01:47,400
Keep that distinction in mind, because it matters.

34
00:01:47,400 --> 00:01:49,600
Now let's talk about how dates enter the picture.

35
00:01:49,600 --> 00:01:53,800
A customer requests delivery on a certain day, or your sales team commits to one.

36
00:01:53,800 --> 00:01:56,400
The ERP works backward from that date through the routing.

37
00:01:56,400 --> 00:02:00,000
If final assembly takes one day, that operation needs to finish before shipment.

38
00:02:00,000 --> 00:02:02,800
If machining feeds assembly, machining needs to finish first.

39
00:02:02,800 --> 00:02:06,800
If raw material needs lead time, purchasing needs to act even earlier.

40
00:02:06,800 --> 00:02:08,200
That's backward scheduling.

41
00:02:08,200 --> 00:02:12,200
It starts with the required completion date and calculates earlier dates for each operation,

42
00:02:12,200 --> 00:02:15,200
based on standard durations, lead times, and calendars.

43
00:02:15,200 --> 00:02:17,400
At first that sounds exactly like scheduling,

44
00:02:17,400 --> 00:02:19,000
and it is scheduling in one sense.

45
00:02:19,000 --> 00:02:22,400
The ERP gives every operation a plan start and a plan finish.

46
00:02:22,400 --> 00:02:28,400
It accounts for a work center calendar, normal working days, shifts, weekends, and public holidays.

47
00:02:28,400 --> 00:02:32,400
It uses standard setup time, runtime, queue time, and move time from the routing.

48
00:02:32,400 --> 00:02:36,200
Those dates have a purpose. They tell purchasing when material demand appears,

49
00:02:36,200 --> 00:02:40,800
help production control see what should be coming, support rough capacity conversations,

50
00:02:40,800 --> 00:02:46,200
and give customer service a planning basis when someone asks whether a requested date looks possible.

51
00:02:46,200 --> 00:02:50,600
But a planned date isn't the same thing as a physically executable slot on a real resource.

52
00:02:50,600 --> 00:02:54,800
Here's where the trouble starts. That distinction disappears because the date looks precise.

53
00:02:54,800 --> 00:02:59,600
A work order that says machining starts Tuesday at 8 in the morning creates a false sense of certainty,

54
00:02:59,600 --> 00:03:03,200
even when five other orders point to the same machine at the same time.

55
00:03:03,200 --> 00:03:05,600
The ERP hasn't necessarily done anything wrong.

56
00:03:05,600 --> 00:03:08,200
It followed the planning rules and master data you gave it.

57
00:03:08,200 --> 00:03:10,200
It calculated dates through a routing.

58
00:03:10,200 --> 00:03:12,400
It exploded demand through the bill of material.

59
00:03:12,400 --> 00:03:17,400
It created proposals and transactions that keep purchasing, inventory, production, and finance connected.

60
00:03:17,400 --> 00:03:19,400
That's a large part of what a manufacturer needs.

61
00:03:19,400 --> 00:03:22,800
But detailed shop flow scheduling asks a different question entirely.

62
00:03:22,800 --> 00:03:27,600
Detailed scheduling asks whether a specific machine can run a specific job at a specific time

63
00:03:27,600 --> 00:03:29,600
while other jobs compete for that same time.

64
00:03:29,600 --> 00:03:34,000
It asks whether the resource calendar is realistic, whether the order can actually start when planned

65
00:03:34,000 --> 00:03:36,600
and whether the sequence of jobs changes the result.

66
00:03:36,600 --> 00:03:40,200
ERP planning coordinates what the business needs to supply.

67
00:03:40,200 --> 00:03:44,000
Detailed scheduling coordinates how the factory can actually execute that demand.

68
00:03:44,000 --> 00:03:46,600
You need both and one doesn't replace the other.

69
00:03:46,600 --> 00:03:51,600
So let's follow one order through the ERP logic because that's where the gap becomes easy to hear.

70
00:03:51,600 --> 00:03:53,400
A simple factory order scenario.

71
00:03:53,400 --> 00:03:56,200
Let's walk through a plant that builds industrial pump assemblies.

72
00:03:56,200 --> 00:03:58,000
Customer orders come in mixed.

73
00:03:58,000 --> 00:03:59,400
Some are standard units.

74
00:03:59,400 --> 00:04:05,200
Others need a different impeller, a special seal, or a tougher material grade for a harsher environment.

75
00:04:05,200 --> 00:04:09,000
All of them pass through a shared machining center before they hit final assembly.

76
00:04:09,000 --> 00:04:11,400
That machining center sits right in the middle of the flow.

77
00:04:11,400 --> 00:04:16,200
Parts arrive as raw stock or semi-finished blanks, machining shapes them, inspection checks them,

78
00:04:16,200 --> 00:04:18,600
and downstream assembly puts the finished pump together.

79
00:04:18,600 --> 00:04:23,000
The plant might own several machines, but this particular center handles a critical operation

80
00:04:23,000 --> 00:04:26,000
that many orders need and almost no other resource can perform.

81
00:04:26,000 --> 00:04:29,000
Now imagine a customer places an order and asks for delivery on Friday.

82
00:04:29,000 --> 00:04:31,000
The ERP pulls up the product routing.

83
00:04:31,000 --> 00:04:35,000
It sees final assembly, inspection, machining, and the material steps upstream.

84
00:04:35,000 --> 00:04:37,800
It starts from the requested delivery date and works backward.

85
00:04:37,800 --> 00:04:41,000
Shipment Friday means final assembly has to finish before that.

86
00:04:41,000 --> 00:04:44,200
Machined components need to reach assembly before assembly starts

87
00:04:44,200 --> 00:04:48,000
and raw material must be available before machining can begin.

88
00:04:48,000 --> 00:04:52,400
On paper that logic looks clean say the ERP creates a production order for the pump housing.

89
00:04:52,400 --> 00:04:57,000
It schedules machining for Tuesday, inspection for Wednesday morning, and assembly for Thursday.

90
00:04:57,000 --> 00:05:00,200
It also sees the required material needs to arrive before Tuesday

91
00:05:00,200 --> 00:05:03,000
so purchasing or inventory planning gets the right signal.

92
00:05:03,000 --> 00:05:04,400
So far nothing unusual.

93
00:05:04,400 --> 00:05:06,000
Then another order hits the system.

94
00:05:06,000 --> 00:05:11,400
This one also needs that same machining center and its due date drives its machining operation into Tuesday as well.

95
00:05:11,400 --> 00:05:16,000
A third order already set in the plan also needing the same machined during that same period.

96
00:05:16,000 --> 00:05:17,800
Each order gets its own set of dates.

97
00:05:17,800 --> 00:05:19,800
Each routing looks internally correct.

98
00:05:19,800 --> 00:05:23,600
Each customer promise might seem reasonable when you view orders one at a time.

99
00:05:23,600 --> 00:05:28,200
But you can't run all three machining operations on the same physical machine simultaneously.

100
00:05:28,200 --> 00:05:32,400
That's where plan is start seeing the difference between a date calculation and a real schedule.

101
00:05:32,400 --> 00:05:36,800
The ERP might place order A on the machining center from 8 until noon on Tuesday,

102
00:05:36,800 --> 00:05:41,200
order B from 9 until 2 and order C from 1 until the end of the shift.

103
00:05:41,200 --> 00:05:44,200
The individual order plans don't know how to negotiate with each other.

104
00:05:44,200 --> 00:05:47,400
A person looking at the plan spots the conflict immediately.

105
00:05:47,400 --> 00:05:52,000
One spindle, one work area, one actual clock and a limited number of usable hours.

106
00:05:52,000 --> 00:05:57,200
Yet the schedule contains overlapping demands because every order calculated backward from its own target date.

107
00:05:57,200 --> 00:05:59,400
The ERP can still show all three as planned.

108
00:05:59,400 --> 00:06:06,200
It can still show material requirements, tell you that raw stock for order A arrives on Monday and material for order B is in inventory

109
00:06:06,200 --> 00:06:10,800
and create purchase proposals and inventory reservations that keep the supply plan moving.

110
00:06:10,800 --> 00:06:13,000
The material picture might even look sensible.

111
00:06:13,000 --> 00:06:16,600
For order A, the raw material arrives before the planned machining date.

112
00:06:16,600 --> 00:06:18,600
For order B, material sits in stock.

113
00:06:18,600 --> 00:06:22,000
For order C, a supplier delivery lands just before its plan start.

114
00:06:22,000 --> 00:06:27,800
From a material planning view, the system has connected demand, supply and dates in a way that seems consistent.

115
00:06:27,800 --> 00:06:29,600
But the physical plan cannot exist.

116
00:06:29,600 --> 00:06:33,200
There's only enough time for one job at a time on that machining centre.

117
00:06:33,200 --> 00:06:36,400
And the rooting dates don't force a choice between competing orders.

118
00:06:36,400 --> 00:06:40,400
Someone still needs to decide which job runs first, which job waits,

119
00:06:40,400 --> 00:06:42,400
and whether a customer date has to move.

120
00:06:42,400 --> 00:06:43,800
That decision ripples downstream.

121
00:06:43,800 --> 00:06:47,600
If order B shifts from Tuesday morning to Tuesday afternoon, inspection moves.

122
00:06:47,600 --> 00:06:50,400
If inspection moves, assembly may lose its planned slot.

123
00:06:50,400 --> 00:06:53,600
If assembly loses that slot, the Friday shipment might no longer hold.

124
00:06:53,600 --> 00:06:57,400
A small conflict at one shared machine travels through the whole order.

125
00:06:57,400 --> 00:07:02,000
This is why a planner can open an ERP schedule on Monday morning and already know it won't survive the week.

126
00:07:02,000 --> 00:07:05,000
The issue isn't that the orders lack dates, they have plenty.

127
00:07:05,000 --> 00:07:08,200
The issue is that those dates describe demand against a resource.

128
00:07:08,200 --> 00:07:12,800
Without proving the resource can actually perform all that work when the dates claim it will.

129
00:07:12,800 --> 00:07:14,600
And here's another uncomfortable detail.

130
00:07:14,600 --> 00:07:17,800
The ERP plan looks more believable as you add more master data,

131
00:07:17,800 --> 00:07:21,600
standard runtimes, Q times, shift calendars, planned lead times.

132
00:07:21,600 --> 00:07:23,800
Those inputs improve the planning picture,

133
00:07:23,800 --> 00:07:28,800
but they don't automatically force the system to resolve two jobs claiming the same moment on the same machine.

134
00:07:28,800 --> 00:07:32,000
So let's unpack the assumption, sitting underneath those dates.

135
00:07:32,000 --> 00:07:33,800
The infinite capacity assumption.

136
00:07:33,800 --> 00:07:36,000
That assumption is usually called infinite capacity.

137
00:07:36,000 --> 00:07:40,400
The name sounds ridiculous when you say it out loud because nobody believes a machining center can work forever.

138
00:07:40,400 --> 00:07:43,800
But it doesn't mean the ERP thinks the machine has unlimited physical power.

139
00:07:43,800 --> 00:07:50,200
It means the planning calculation can place demand on a resource without first reserving a finite block of its actual available time

140
00:07:50,200 --> 00:07:52,600
against all the other orders competing for it.

141
00:07:52,600 --> 00:07:54,200
That choice exists for a reason.

142
00:07:54,200 --> 00:07:59,200
ERP planning needs to process a lot of demand, supply, product structures, lead times, inventory positions,

143
00:07:59,200 --> 00:08:01,600
and purchasing signals across a whole business.

144
00:08:01,600 --> 00:08:04,000
It needs to answer broad planning questions quickly.

145
00:08:04,000 --> 00:08:05,000
What should we buy?

146
00:08:05,000 --> 00:08:05,800
What should we produce?

147
00:08:05,800 --> 00:08:09,000
And when must those actions begin if we want a chance of meeting demand?

148
00:08:09,000 --> 00:08:12,600
Backward scheduling gives the business a useful target date for those questions.

149
00:08:12,600 --> 00:08:17,400
It doesn't have to solve every conflict between every operation on every machine while it creates that target.

150
00:08:17,400 --> 00:08:22,200
If it tried to do all that across an entire plant with every change in demand and supply,

151
00:08:22,200 --> 00:08:24,800
the job becomes a much harder scheduling problem.

152
00:08:24,800 --> 00:08:29,000
So infinite capacity isn't a defect and it isn't an attempt to mislead anyone.

153
00:08:29,000 --> 00:08:31,800
It's a boundary around what the planning logic is trying to do.

154
00:08:31,800 --> 00:08:35,000
The problem starts when people treat the output as more than it is.

155
00:08:35,000 --> 00:08:38,000
A work order date can look like a commitment from production.

156
00:08:38,000 --> 00:08:43,800
When it may only mean if capacity exists at this point, this operation needs to happen around this time.

157
00:08:43,800 --> 00:08:45,600
That word, if carries most of the risk,

158
00:08:45,600 --> 00:08:47,400
take Tuesday in our pump factory.

159
00:08:47,400 --> 00:08:53,800
The ERP can assign several machining operations to Tuesday because each order needs machining complete before its own downstream dates.

160
00:08:53,800 --> 00:08:55,800
It calculates those dates through each routing,

161
00:08:55,800 --> 00:08:59,600
but it doesn't enforce one shared clock across every order at that work center.

162
00:08:59,600 --> 00:09:01,000
The work orders land on the day.

163
00:09:01,000 --> 00:09:02,800
They may even land in the same shift.

164
00:09:02,800 --> 00:09:06,200
Nothing in the date itself proves the required machine hours exist.

165
00:09:06,200 --> 00:09:09,000
Some ERP systems include capacity requirements planning,

166
00:09:09,000 --> 00:09:10,000
CRP,

167
00:09:10,000 --> 00:09:12,800
that can aggregate the load against the work center calendar

168
00:09:12,800 --> 00:09:17,200
and show that Tuesday carries say far more planned hours than the work center can provide.

169
00:09:17,200 --> 00:09:18,200
That view helps.

170
00:09:18,200 --> 00:09:22,000
It moves the problem out of someone's memory and into a shared planning conversation.

171
00:09:22,000 --> 00:09:25,200
But detecting an overload and resolving an overload are different jobs.

172
00:09:25,200 --> 00:09:31,600
A capacity report might tell the planner that a machining center has 40 hours of demand against 16 usable hours.

173
00:09:31,600 --> 00:09:32,800
That report has done its job.

174
00:09:32,800 --> 00:09:34,200
It exposed the gap.

175
00:09:34,200 --> 00:09:37,400
But it hasn't selected which orders should run, which order should move,

176
00:09:37,400 --> 00:09:39,400
whether another resource can process the work,

177
00:09:39,400 --> 00:09:42,000
or how a change will affect all the operations that follow.

178
00:09:42,000 --> 00:09:43,000
It counted the collision.

179
00:09:43,000 --> 00:09:44,600
It hasn't untangled it.

180
00:09:44,600 --> 00:09:50,000
That distinction matters because people often respond to an overload report as though the report itself created a plan.

181
00:09:50,000 --> 00:09:50,800
It didn't.

182
00:09:50,800 --> 00:09:53,800
The same 40 hours still compete for the same 16 hours.

183
00:09:53,800 --> 00:09:59,000
Printing the report twice doesn't produce another shift, another operator, or another machine.

184
00:09:59,000 --> 00:10:03,000
An overloaded Tuesday cannot become feasible through a dashboard, a color code,

185
00:10:03,000 --> 00:10:04,800
or a more detailed spreadsheet extract.

186
00:10:04,800 --> 00:10:08,800
Somebody needs to take work out of that period, move it to a legal slot,

187
00:10:08,800 --> 00:10:10,800
and test the consequences of that move.

188
00:10:10,800 --> 00:10:14,200
Maybe one order can shift to Wednesday without harming its customer date.

189
00:10:14,200 --> 00:10:17,600
Maybe another has a firm delivery promise and must stay.

190
00:10:17,600 --> 00:10:19,600
Perhaps the third order could run elsewhere,

191
00:10:19,600 --> 00:10:22,800
but only if that alternative resource can actually perform the operation.

192
00:10:22,800 --> 00:10:24,800
Or maybe none of those choices work.

193
00:10:24,800 --> 00:10:28,000
And the business needs to decide between overtime, subcontracting,

194
00:10:28,000 --> 00:10:31,200
a change promise date, or a different commercial decision.

195
00:10:31,200 --> 00:10:32,200
Those are real choices.

196
00:10:32,200 --> 00:10:35,000
Infinite capacity planning can reveal where the choices sit,

197
00:10:35,000 --> 00:10:37,400
but it doesn't evaluate them as a connected schedule.

198
00:10:37,400 --> 00:10:38,800
There's also a human side to this.

199
00:10:38,800 --> 00:10:42,400
When planners see overload after overload, they often build their own workaround.

200
00:10:42,400 --> 00:10:45,800
A private priority list, manual moves, calls to supervisors,

201
00:10:45,800 --> 00:10:48,200
mental notes about which customer will accept the delay

202
00:10:48,200 --> 00:10:50,400
and which product tends to create trouble.

203
00:10:50,400 --> 00:10:52,200
That knowledge keeps factories moving.

204
00:10:52,200 --> 00:10:54,200
It also shows that the actual scheduling logic

205
00:10:54,200 --> 00:10:57,000
lives somewhere outside the ERP date calculation.

206
00:10:57,000 --> 00:10:59,200
None of this means ERP dates are useless.

207
00:10:59,200 --> 00:11:02,600
They remain useful signals for material planning, demand coordination,

208
00:11:02,600 --> 00:11:04,000
and rough load awareness.

209
00:11:04,000 --> 00:11:08,000
The mistake is asking those dates to carry a decision they were never built to make.

210
00:11:08,000 --> 00:11:10,800
And finite machine time is only the first constraint.

211
00:11:10,800 --> 00:11:14,200
Capacity is physical, not a field in a table.

212
00:11:14,200 --> 00:11:16,600
Most planners never stop to consider something basic.

213
00:11:16,600 --> 00:11:20,200
A work center calendar can tell you a machine runs two shifts Monday through Friday.

214
00:11:20,200 --> 00:11:22,200
That's genuinely useful planning data.

215
00:11:22,200 --> 00:11:26,400
But it's not the same as knowing how much production time that machine can actually give you this week.

216
00:11:26,400 --> 00:11:27,800
Start with the machine itself.

217
00:11:27,800 --> 00:11:30,200
A calendar may show 16 available hours in a day,

218
00:11:30,200 --> 00:11:35,400
but the real shift includes handover, warm-up, plan checks, breaks, cleaning,

219
00:11:35,400 --> 00:11:40,400
and all those small interruptions that never appear as a neat block in a master data record.

220
00:11:40,400 --> 00:11:42,400
Think about what maintenance takes, too.

221
00:11:42,400 --> 00:11:44,800
Sometimes it's a planned service window everyone expects.

222
00:11:44,800 --> 00:11:48,800
Other times, a technician needs the machine for a short inspection after recurring alarm

223
00:11:48,800 --> 00:11:51,200
and production can't pretend that slots still exists

224
00:11:51,200 --> 00:11:53,800
just because the ERP calendar says the machine is open.

225
00:11:53,800 --> 00:11:55,200
That isn't poor discipline.

226
00:11:55,200 --> 00:11:56,600
It's factory life.

227
00:11:56,600 --> 00:11:59,400
Take a CNC machine with a nominal eight hour shift.

228
00:11:59,400 --> 00:12:01,200
The machine may need a start-up routine.

229
00:12:01,200 --> 00:12:03,200
The operator may need to verify the first part.

230
00:12:03,200 --> 00:12:05,800
A tool could hit its replacement limit halfway through

231
00:12:05,800 --> 00:12:09,000
and quality might require an inspection after a defined batch.

232
00:12:09,000 --> 00:12:11,800
Once you account for all those conditions,

233
00:12:11,800 --> 00:12:14,800
the usable time can differ quite a lot from the rated time.

234
00:12:14,800 --> 00:12:17,200
Rate capacity is the number you plug into a table.

235
00:12:17,200 --> 00:12:20,400
Usable capacity is what actually remains after the plant applies

236
00:12:20,400 --> 00:12:23,400
every condition needed to run safely, correctly, and predictably.

237
00:12:23,400 --> 00:12:26,800
That gap between rated and usable changes planning decisions.

238
00:12:26,800 --> 00:12:30,400
If a planner assumes an eight hour shift produces eight hours of machining,

239
00:12:30,400 --> 00:12:33,200
every order will look slightly more achievable than it really is.

240
00:12:33,200 --> 00:12:35,200
Add that error across several days

241
00:12:35,200 --> 00:12:39,000
and the schedule starts with hidden delay baked in from the beginning.

242
00:12:39,000 --> 00:12:42,600
A finite schedule needs to work with the capacity you can actually use,

243
00:12:42,600 --> 00:12:44,400
not the capacity you wish you had.

244
00:12:44,400 --> 00:12:47,200
Here's another basic rule that systems sometimes blur.

245
00:12:47,200 --> 00:12:49,400
A machine usually runs one job at a time

246
00:12:49,400 --> 00:12:52,400
and one milling center cannot machine two housings at once

247
00:12:52,400 --> 00:12:54,600
simply because two orders have the same date.

248
00:12:54,600 --> 00:12:57,600
A heat treatment furnace may process many parts in a batch

249
00:12:57,600 --> 00:13:00,400
but that's a real process rule with a defined load limit,

250
00:13:00,400 --> 00:13:02,400
temperature cycle and batch duration.

251
00:13:02,400 --> 00:13:04,800
Parallel work has to come from the process itself,

252
00:13:04,800 --> 00:13:07,400
not from the planning system trying to force dates to fit.

253
00:13:07,400 --> 00:13:10,200
You also need to ask what else the operation actually requires.

254
00:13:10,200 --> 00:13:11,800
The machine may sit empty,

255
00:13:11,800 --> 00:13:14,400
but the qualified operator could be assigned elsewhere.

256
00:13:14,400 --> 00:13:16,800
The tool package might still be at another machine.

257
00:13:16,800 --> 00:13:19,200
A fixture could be in use or waiting for inspection

258
00:13:19,200 --> 00:13:23,600
and the gauge needed for first off approval may not be available until later in the shift.

259
00:13:23,600 --> 00:13:27,400
In practical terms, a machining operation doesn't just consume machine time.

260
00:13:27,400 --> 00:13:30,200
It consumes a machine, a person with the right skill,

261
00:13:30,200 --> 00:13:33,000
a fixture, a tool set and sometimes a quality resource.

262
00:13:33,000 --> 00:13:35,600
If any one of those is unavailable, the operation cannot start.

263
00:13:35,600 --> 00:13:38,400
That's why a resource calendar alone only gets you part of the way.

264
00:13:38,400 --> 00:13:41,400
It can describe scheduled opening hours, planned holidays,

265
00:13:41,400 --> 00:13:42,800
and maybe a maintenance block,

266
00:13:42,800 --> 00:13:46,800
but it usually can't express every condition that turns a free hour

267
00:13:46,800 --> 00:13:51,000
into a productive hour without much deeper modeling and scheduling logic.

268
00:13:51,000 --> 00:13:54,000
Even when the data exists, someone needs to apply it altogether.

269
00:13:54,000 --> 00:13:56,800
The schedule has to reserve the machine for the operation duration,

270
00:13:56,800 --> 00:13:58,600
confirm the operator qualification,

271
00:13:58,600 --> 00:14:01,400
check that the fixture doesn't conflict with another order,

272
00:14:01,400 --> 00:14:04,400
and leave room for the inspection rule that production actually follows.

273
00:14:04,400 --> 00:14:09,000
Otherwise, the system creates a slot that looks available only because it sees one part of the job.

274
00:14:09,000 --> 00:14:12,800
I've seen planning discussions get stuck on whether a work center calendar is accurate,

275
00:14:12,800 --> 00:14:14,600
that matters, but it's the wrong place to stop.

276
00:14:14,600 --> 00:14:18,200
The better question is whether the planning model describes the real conditions

277
00:14:18,200 --> 00:14:21,800
that decide if this operation can begin and finish in that time window.

278
00:14:21,800 --> 00:14:24,400
If the answer is no, the calendar is still useful.

279
00:14:24,400 --> 00:14:26,400
It just isn't enough to build a schedule,

280
00:14:26,400 --> 00:14:28,400
people can execute without manual repair.

281
00:14:28,400 --> 00:14:31,200
So when someone tells you a machine has capacity on Wednesday afternoon,

282
00:14:31,200 --> 00:14:33,200
pause for a second, capacity for which job,

283
00:14:33,200 --> 00:14:35,200
with which operator using which tooling,

284
00:14:35,200 --> 00:14:38,400
after which maintenance activity, under what production rules.

285
00:14:38,400 --> 00:14:41,200
A free machine may still not be ready for the next job.

286
00:14:41,200 --> 00:14:44,200
Sequence changes the result.

287
00:14:44,200 --> 00:14:47,000
Even when the machine, operator, and fixture are already,

288
00:14:47,000 --> 00:14:49,600
another question remains, what should run first?

289
00:14:49,600 --> 00:14:52,800
That question sounds simple until you actually look at the work itself.

290
00:14:52,800 --> 00:14:56,200
The time between jobs can change based on product-family material-grade color,

291
00:14:56,200 --> 00:14:59,600
coating, toolset, or the cleaning standard that applies before the next part

292
00:14:59,600 --> 00:15:00,800
can enter the machine.

293
00:15:00,800 --> 00:15:03,600
A routing might tell you that a job needs 20 minutes of setup

294
00:15:03,600 --> 00:15:05,400
and that's often a useful average,

295
00:15:05,400 --> 00:15:08,000
but an average can hide the part planners care about most.

296
00:15:08,000 --> 00:15:10,400
The setup cost from which job to which next job,

297
00:15:10,400 --> 00:15:11,800
let's make this concrete.

298
00:15:11,800 --> 00:15:15,000
Say the machining center runs stainless steel parts in the morning,

299
00:15:15,000 --> 00:15:17,800
then changes to a softer alloy in the afternoon.

300
00:15:17,800 --> 00:15:19,800
That change may need a different tool pack,

301
00:15:19,800 --> 00:15:22,400
program checks, and a first piece inspection.

302
00:15:22,400 --> 00:15:24,600
Now imagine the next job requires a material

303
00:15:24,600 --> 00:15:27,200
that must not pick up residue from the previous one.

304
00:15:27,200 --> 00:15:31,200
The change over includes cleaning, a fresh fixture, and an extra approval step.

305
00:15:31,200 --> 00:15:33,200
These jobs don't carry the same transition cost

306
00:15:33,200 --> 00:15:35,000
the same pattern shows up everywhere.

307
00:15:35,000 --> 00:15:37,000
A paint line may need flushing between colors,

308
00:15:37,000 --> 00:15:40,000
a food or chemical process may need cleaning between recipes

309
00:15:40,000 --> 00:15:42,000
and a press line may need a die change.

310
00:15:42,000 --> 00:15:45,000
In heat treatment, a batch may need a different temperature profile

311
00:15:45,000 --> 00:15:46,800
and the furnace cannot simply switch

312
00:15:46,800 --> 00:15:48,800
because in order to do dates as it should.

313
00:15:48,800 --> 00:15:51,000
Production people know all this without a theory lesson,

314
00:15:51,000 --> 00:15:52,200
they call it common sense.

315
00:15:52,200 --> 00:15:55,800
The trouble begins when the plan treats every job as though it enters a resource

316
00:15:55,800 --> 00:15:56,800
from a neutral state.

317
00:15:56,800 --> 00:15:57,600
It doesn't.

318
00:15:57,600 --> 00:16:00,000
Every job leaves the resource in some state

319
00:16:00,000 --> 00:16:01,800
and the next job inherits that state.

320
00:16:01,800 --> 00:16:04,000
It either benefits from it or pays to change it,

321
00:16:04,000 --> 00:16:06,600
run five orders from the same product family together

322
00:16:06,600 --> 00:16:08,800
and the machine may need one major setup.

323
00:16:08,800 --> 00:16:12,600
Alternate between families because the ERP sorts everything by due date alone

324
00:16:12,600 --> 00:16:15,400
and those same five orders can trigger several setups,

325
00:16:15,400 --> 00:16:18,600
same demand, same machine, very different use of time.

326
00:16:18,600 --> 00:16:20,000
Here's a practical example.

327
00:16:20,000 --> 00:16:23,600
Suppose four pump components all need the same machining center,

328
00:16:23,600 --> 00:16:26,200
two belong to family A and two belong to family B.

329
00:16:26,200 --> 00:16:27,800
Each order has a customer date,

330
00:16:27,800 --> 00:16:29,400
but none of them need shipment today.

331
00:16:29,400 --> 00:16:31,800
One sequence runs A, A, B, B

332
00:16:31,800 --> 00:16:35,000
and the team completes two campaigns with one change between them.

333
00:16:35,000 --> 00:16:37,400
Another sequence runs A, B, A, B

334
00:16:37,400 --> 00:16:39,400
and the machine changes state three times.

335
00:16:39,400 --> 00:16:41,200
Those extra changes consume time,

336
00:16:41,200 --> 00:16:45,600
create more chances for error and push productive machining later into the shift.

337
00:16:45,600 --> 00:16:48,400
The second sequence may look fair from an order date view

338
00:16:48,400 --> 00:16:52,800
and it may even look more responsive because each customer sees some work begin early.

339
00:16:52,800 --> 00:16:55,600
But the plant completes less work when extra change

340
00:16:55,600 --> 00:16:57,800
over the eat the hours meant for processing parts.

341
00:16:57,800 --> 00:17:00,800
Due date results can shift in ways that aren't obvious at first.

342
00:17:00,800 --> 00:17:03,200
Grouping jobs by family may protect capacity

343
00:17:03,200 --> 00:17:05,600
and bring more total orders through yet one order

344
00:17:05,600 --> 00:17:08,800
with an earlier customer promise may need to interrupt that campaign.

345
00:17:08,800 --> 00:17:11,200
The planner has to weigh the cost of breaking the sequence

346
00:17:11,200 --> 00:17:13,400
against the cost of delivering that order late.

347
00:17:13,400 --> 00:17:16,400
That's a real production choice and a date field can't decide it by itself.

348
00:17:16,400 --> 00:17:19,800
Most rootings don't capture every relationship that drives setup time.

349
00:17:19,800 --> 00:17:22,800
They may record a standard setup duration for an operation

350
00:17:22,800 --> 00:17:24,000
which helps with rough planning,

351
00:17:24,000 --> 00:17:27,600
but the routing often doesn't state that changing from family A to family B

352
00:17:27,600 --> 00:17:29,600
takes longer than changing within family A.

353
00:17:29,600 --> 00:17:32,600
It also doesn't say that one material transition needs cleaning

354
00:17:32,600 --> 00:17:34,800
while another only needs a tool offset check.

355
00:17:34,800 --> 00:17:37,200
Sometimes those rules sit in work instructions.

356
00:17:37,200 --> 00:17:40,800
More often, they live in the head of the person who has run that machine for years.

357
00:17:40,800 --> 00:17:42,600
The schedule needs a way to express them.

358
00:17:42,600 --> 00:17:44,800
It can use rules like do not run this grade

359
00:17:44,800 --> 00:17:49,200
after that grade without cleaning or group jobs with the same coating where possible.

360
00:17:49,200 --> 00:17:51,200
It can also use cost-based logic

361
00:17:51,200 --> 00:17:53,600
where the model assigns a penalty to a costly changeover

362
00:17:53,600 --> 00:17:56,600
and lets the scheduling process compare that against the risk of a late order.

363
00:17:56,600 --> 00:17:58,000
That doesn't remove judgment.

364
00:17:58,000 --> 00:17:59,400
It makes the trade-off visible.

365
00:17:59,400 --> 00:18:01,400
A planner can then ask a useful question.

366
00:18:01,400 --> 00:18:04,600
Are we accepting an extra setup because this customer date truly requires it

367
00:18:04,600 --> 00:18:06,800
or are we doing it because the sequence came from a list

368
00:18:06,800 --> 00:18:08,600
that knows nothing about changeovers?

369
00:18:08,600 --> 00:18:11,600
Keep that in mind as we return to the shared machining center.

370
00:18:11,600 --> 00:18:14,000
Once one resource limits the flow for many orders,

371
00:18:14,000 --> 00:18:16,800
its sequence stops being a local efficiency choice.

372
00:18:16,800 --> 00:18:19,200
The bottleneck turns sequence into a business decision.

373
00:18:19,200 --> 00:18:21,000
The bottleneck decides the pace.

374
00:18:21,000 --> 00:18:22,600
Here's what a bottleneck really is.

375
00:18:22,600 --> 00:18:26,600
It's the resource that limits how much work the plant can get through over a given period.

376
00:18:26,600 --> 00:18:28,400
Whether that's a single machining center,

377
00:18:28,400 --> 00:18:30,800
a paint booth, a furnace, a test station,

378
00:18:30,800 --> 00:18:32,400
or even an inspection step,

379
00:18:32,400 --> 00:18:34,800
only a handful of people are qualified to do.

380
00:18:34,800 --> 00:18:37,800
Where it sits in the flow matters more than what you call it.

381
00:18:37,800 --> 00:18:39,400
Think about the pump factory again.

382
00:18:39,400 --> 00:18:43,600
Several orders move through cutting, preparation, and assembly at different speeds

383
00:18:43,600 --> 00:18:46,800
but if most of them have to pass through one machining center,

384
00:18:46,800 --> 00:18:49,200
that center sets the pace for everything else.

385
00:18:49,200 --> 00:18:54,400
No amount of upstream hustle can get finished parts out faster than that one resource can process them.

386
00:18:54,400 --> 00:18:57,000
So here's where the planning question shifts entirely.

387
00:18:57,000 --> 00:18:59,400
Instead of asking whether every machine stays busy,

388
00:18:59,400 --> 00:19:02,800
you should ask whether the constraint is spending its time on the work

389
00:19:02,800 --> 00:19:07,000
that best protects customer commitments and overall plant flow.

390
00:19:07,000 --> 00:19:10,600
A non-bottle neck can sit idle for a while without hurting total output

391
00:19:10,600 --> 00:19:14,600
but the bottle neck can't lose an hour without the plant losing an hour of potential flow.

392
00:19:14,600 --> 00:19:17,000
And here's where local efficiency can mislead you.

393
00:19:17,000 --> 00:19:21,000
A supervisor might keep an upstream machine running because an idle machine feels wrong.

394
00:19:21,000 --> 00:19:24,800
The operator has work, the machine runs, and the local utilization number looks great.

395
00:19:24,800 --> 00:19:28,800
But those parts may just end up in a growing queue in front of the constraint machining center

396
00:19:28,800 --> 00:19:32,400
so you end up with more work in progress, not more finished orders.

397
00:19:32,400 --> 00:19:34,200
Meanwhile, the bottle neck might be waiting

398
00:19:34,200 --> 00:19:36,400
because the next priority job doesn't have material,

399
00:19:36,400 --> 00:19:39,000
the program isn't ready, the right fixture is somewhere else,

400
00:19:39,000 --> 00:19:42,000
or someone picked a sequence that caused an avoidable change over.

401
00:19:42,000 --> 00:19:44,800
Those lost minutes hurt way more than an idle upstream resource

402
00:19:44,800 --> 00:19:48,000
because the constraint determines what the whole system can actually ship.

403
00:19:48,000 --> 00:19:50,800
So the schedule needs to protect bottle neck time,

404
00:19:50,800 --> 00:19:53,800
which means planning the work that comes before it carefully.

405
00:19:53,800 --> 00:19:57,600
The next job should have material, tooling, paperwork, quality requirements,

406
00:19:57,600 --> 00:20:00,400
and operator support ready before the current job finishes.

407
00:20:00,400 --> 00:20:03,600
And if there's a maintenance window, the plan needs to account for it.

408
00:20:03,600 --> 00:20:06,000
If a sequence can reduce cleaning or tool changes

409
00:20:06,000 --> 00:20:08,200
without breaking an urgent customer promise,

410
00:20:08,200 --> 00:20:10,400
the planner should be able to see that option clearly.

411
00:20:10,400 --> 00:20:13,600
This isn't about treating one machine is more important than people or quality.

412
00:20:13,600 --> 00:20:17,000
It's about respecting the resource that controls the plant's output.

413
00:20:17,000 --> 00:20:18,800
When the bottle neck runs the wrong work,

414
00:20:18,800 --> 00:20:21,800
waits for missing inputs or spends too much time on changeovers,

415
00:20:21,800 --> 00:20:23,800
the cost spreads through the whole order book.

416
00:20:23,800 --> 00:20:26,400
There's a simple way to think about this called drum buffer rope.

417
00:20:26,400 --> 00:20:29,200
The drum is the paste set by the constrained resource.

418
00:20:29,200 --> 00:20:31,400
In our case, the machining center sets the beat,

419
00:20:31,400 --> 00:20:35,200
telling the rest of the plant how fast work can realistically flow.

420
00:20:35,200 --> 00:20:36,800
The buffer protects that pace.

421
00:20:36,800 --> 00:20:39,200
It's a planned amount of ready work before the bottle neck,

422
00:20:39,200 --> 00:20:40,600
not just a pile of parts.

423
00:20:40,600 --> 00:20:43,800
The buffer gives the plant some protection when an upstream step runs late

424
00:20:43,800 --> 00:20:46,800
or a small disruption hits, but it needs control.

425
00:20:46,800 --> 00:20:49,200
Two little buffer risks starving the bottle neck,

426
00:20:49,200 --> 00:20:52,200
too much creates confusion and hides problems.

427
00:20:52,200 --> 00:20:54,000
The rope controls release upstream,

428
00:20:54,000 --> 00:20:56,800
stopping the plant from launching work just because material exists

429
00:20:56,800 --> 00:20:58,600
or an earlier machine has free time,

430
00:20:58,600 --> 00:21:03,200
so work enters the flow to support the bottle neck's plant sequence and capacity.

431
00:21:03,200 --> 00:21:06,000
In practical terms, the bottle neck tells upstream teams

432
00:21:06,000 --> 00:21:07,400
what to prepare and when.

433
00:21:07,400 --> 00:21:11,000
Upstream production doesn't decide the flow just by keeping itself busy.

434
00:21:11,000 --> 00:21:14,400
That can feel counterintuitive in a factory built around utilization targets

435
00:21:14,400 --> 00:21:17,400
where people are often pressured to keep every resource running.

436
00:21:17,400 --> 00:21:20,600
But if every department optimizes its own local workload,

437
00:21:20,600 --> 00:21:24,200
they can overwhelm the one place that controls finished output.

438
00:21:24,200 --> 00:21:27,800
A finite schedule makes this visible by starting with the constrained resource

439
00:21:27,800 --> 00:21:30,800
and asking which jobs must occupy its limited slots,

440
00:21:30,800 --> 00:21:35,000
then working outward to check that the work arriving before it supports that sequence

441
00:21:35,000 --> 00:21:38,200
and that downstream operations can absorb the output.

442
00:21:38,200 --> 00:21:42,200
ERP planning dates usually don't carry that live view of constrained flow.

443
00:21:42,200 --> 00:21:45,600
They can tell you when an order should need machining based on its due date and rooting

444
00:21:45,600 --> 00:21:47,600
and they can show load against the work centre,

445
00:21:47,600 --> 00:21:51,000
but those dates don't automatically protect the bottle neck from a missing kit

446
00:21:51,000 --> 00:21:56,000
and unnecessary setup or a queue full of lower priority work.

447
00:21:56,000 --> 00:21:59,800
A planner with deep shop flow knowledge often does this mentally.

448
00:21:59,800 --> 00:22:03,400
They know which jobs must stay close to the bottle neck, which ones can wait,

449
00:22:03,400 --> 00:22:06,800
and which upstream orders should not yet enter production.

450
00:22:06,800 --> 00:22:09,800
And that knowledge is part of the real scheduling process,

451
00:22:09,800 --> 00:22:13,800
even if the ERP only shows a long list of released orders.

452
00:22:13,800 --> 00:22:16,400
And that leads to a problem that seems helpful at first,

453
00:22:16,400 --> 00:22:20,000
releasing work early because when upstream release ignores the bottle neck,

454
00:22:20,000 --> 00:22:23,800
more activity can actually create more delay.

455
00:22:23,800 --> 00:22:26,400
Why releasing everything early creates more delay?

456
00:22:26,400 --> 00:22:30,200
When the plan feels uncertain, many factories respond in a very human way,

457
00:22:30,200 --> 00:22:35,200
they release work early, push it onto the floor and tell each department to keep machines busy.

458
00:22:35,200 --> 00:22:36,800
It feels safer than waiting.

459
00:22:36,800 --> 00:22:40,400
If the order starts early, surely it has a better chance of shipping on time, right?

460
00:22:40,400 --> 00:22:43,400
Sometimes that works for a simple order with spare capacity everywhere,

461
00:22:43,400 --> 00:22:48,000
but once workflows through a constrained area, early release can do the opposite.

462
00:22:48,000 --> 00:22:51,400
You haven't created more capacity, you've just moved more unfinished work

463
00:22:51,400 --> 00:22:54,000
into a system that already has a limit.

464
00:22:54,000 --> 00:22:58,800
Picture a set of orders released several days before the constrained machining operation can take them.

465
00:22:58,800 --> 00:23:03,600
Raw parts get cut, components get prepared, paper work travels with them,

466
00:23:03,600 --> 00:23:07,400
and then the jobs reach the area before the bottle neck and weight.

467
00:23:07,400 --> 00:23:10,600
That growing pile is work in progress, WIP.

468
00:23:10,600 --> 00:23:14,000
It represents labor, material, and time already committed,

469
00:23:14,000 --> 00:23:17,200
but it doesn't represent a finished order that can ship.

470
00:23:17,200 --> 00:23:20,400
And when too much WIP sits in front of the constraint,

471
00:23:20,400 --> 00:23:22,600
people lose sight of what should run next.

472
00:23:22,600 --> 00:23:25,400
The queue starts to become its own planning system.

473
00:23:25,400 --> 00:23:28,800
A supervisor walks past and sees an urgent job near the back,

474
00:23:28,800 --> 00:23:32,800
and operator starts the job closest to the machine because it's easy to pick up.

475
00:23:32,800 --> 00:23:35,200
A planner calls asking for a different order,

476
00:23:35,200 --> 00:23:38,800
and someone from sales shows up with another escalation.

477
00:23:38,800 --> 00:23:41,800
Before long, priority comes from whoever asks the loudest,

478
00:23:41,800 --> 00:23:45,600
who's physically present, or which job happens to sit on top of the pile.

479
00:23:45,600 --> 00:23:47,400
None of that means people are careless.

480
00:23:47,400 --> 00:23:50,800
They're reacting to a system where the release process has created more choices

481
00:23:50,800 --> 00:23:54,600
than the bottle neck can handle, and the visible queue hides the actual priority

482
00:23:54,600 --> 00:23:58,400
because every job looks late, urgent, or already started.

483
00:23:58,400 --> 00:24:01,000
Feedback slows down, too.

484
00:24:01,000 --> 00:24:03,200
If an order waits in a queue for two days,

485
00:24:03,200 --> 00:24:07,000
a problem discovered at the bottle neck takes two days to reach the upstream team,

486
00:24:07,000 --> 00:24:10,600
and by then, more material may have been cut, more labor spent,

487
00:24:10,600 --> 00:24:12,400
and more orders released behind it.

488
00:24:12,400 --> 00:24:15,200
So the factory keeps producing work that can't move forward

489
00:24:15,200 --> 00:24:17,200
while the real constraint stays overloaded.

490
00:24:17,200 --> 00:24:20,200
That's why high utilization at every resource can be a trap.

491
00:24:20,200 --> 00:24:23,200
A non-bottle neck machine can run at full speed all day,

492
00:24:23,200 --> 00:24:27,800
and still hurt total flow if it feeds work faster than the constraint can absorb it.

493
00:24:27,800 --> 00:24:31,000
The local team sees activity, but the plant sees more WIP,

494
00:24:31,000 --> 00:24:33,400
longer queues, more searching, and more expediting.

495
00:24:33,400 --> 00:24:35,000
Busy isn't the same as productive.

496
00:24:35,000 --> 00:24:37,400
This is one of the harder conversations in manufacturing

497
00:24:37,400 --> 00:24:40,200
because nobody likes to tell an operator or supervisor

498
00:24:40,200 --> 00:24:42,200
that a machine should sometimes wait,

499
00:24:42,200 --> 00:24:45,200
but an upstream resource waiting for the right release signal

500
00:24:45,200 --> 00:24:50,200
may protect the flow far better than producing another batch that joins a queue.

501
00:24:50,200 --> 00:24:52,600
The objective isn't idle time for its own sake.

502
00:24:52,600 --> 00:24:54,000
It's controlled flow.

503
00:24:54,000 --> 00:24:56,400
Work should arrive early enough to protect the bottleneck,

504
00:24:56,400 --> 00:25:00,200
but not so early that the shop floor becomes a warehouse of half finished orders.

505
00:25:00,200 --> 00:25:04,200
ERP due dates can make this harder because they often become dispatch lists.

506
00:25:04,200 --> 00:25:06,800
The system shows a list of orders with plant dates,

507
00:25:06,800 --> 00:25:10,800
and people assume every released order should move through production as soon as possible.

508
00:25:10,800 --> 00:25:13,400
But a due date tells you when an order needs completion.

509
00:25:13,400 --> 00:25:16,800
It doesn't always tell you when the first operation should physically start.

510
00:25:16,800 --> 00:25:19,600
Those are different decisions, and a release rule connects them

511
00:25:19,600 --> 00:25:24,400
by asking whether releasing a job now supports the planned flow through the constrained resource

512
00:25:24,400 --> 00:25:25,800
or just adds to the queue.

513
00:25:25,800 --> 00:25:28,600
The rule might consider the expected slot at the bottleneck,

514
00:25:28,600 --> 00:25:32,400
the time needed upstream, and a controlled buffer before that slot.

515
00:25:32,400 --> 00:25:35,800
The exact method differs by factory, but the principle stays simple.

516
00:25:35,800 --> 00:25:38,600
Release work based on the system's ability to absorb it.

517
00:25:38,600 --> 00:25:42,000
Without that rule, ERP dates become a long list of instructions

518
00:25:42,000 --> 00:25:44,000
that all means start now,

519
00:25:44,000 --> 00:25:47,000
and no shop floor can treat every order as first priority,

520
00:25:47,000 --> 00:25:51,200
so the result is usually a mix of manual sorting, hidden local rules,

521
00:25:51,200 --> 00:25:52,800
and avoidable noise.

522
00:25:52,800 --> 00:25:55,200
There's another dependency sitting inside this problem.

523
00:25:55,200 --> 00:25:57,800
A job might reach the right point in the flow at the right time,

524
00:25:57,800 --> 00:25:59,800
but still lack what it needs to run,

525
00:25:59,800 --> 00:26:03,800
and material readiness adds another layer to the scheduling decision.

526
00:26:03,800 --> 00:26:07,200
Material availability is necessary, not enough.

527
00:26:07,200 --> 00:26:11,800
Let's start here because ERP genuinely earns its place in this part of the problem.

528
00:26:11,800 --> 00:26:13,000
When demand shows up,

529
00:26:13,000 --> 00:26:16,800
material requirements planning breaks a finished product into every purchased part.

530
00:26:16,800 --> 00:26:19,000
Raw material and subassembly it needs.

531
00:26:19,000 --> 00:26:21,400
It checks stock, nets demand against supply,

532
00:26:21,400 --> 00:26:25,600
and creates purchase or production proposals early enough to respect the planned lead time.

533
00:26:25,600 --> 00:26:28,400
That's difficult work, and it matters more than most people realize.

534
00:26:28,400 --> 00:26:29,400
Take a pump assembly.

535
00:26:29,400 --> 00:26:33,600
The ERP tells planning that the housing blank seal kit bearings, fasteners, and impeller

536
00:26:33,600 --> 00:26:36,400
all need to exist before final assembly can finish.

537
00:26:36,400 --> 00:26:39,800
It traces those requirements through several levels of the bill of material,

538
00:26:39,800 --> 00:26:43,800
so a missing bought-in component doesn't stay hidden until someone reaches the assembly bench,

539
00:26:43,800 --> 00:26:46,200
but here's the catch that trips up almost every plant.

540
00:26:46,200 --> 00:26:48,400
In stock, doesn't mean ready to run.

541
00:26:48,400 --> 00:26:53,200
Picture a machining order where the raw material record shows plenty of quantity in the warehouse.

542
00:26:53,200 --> 00:26:57,200
The planner sees green status and assumes the job can take its plan slot.

543
00:26:57,200 --> 00:27:01,600
Then production checks the actual material and finds part of the stock under quality hold.

544
00:27:01,600 --> 00:27:04,400
Another part reserved for a different customer allocation,

545
00:27:04,400 --> 00:27:08,600
and the remaining quantity sitting in a batch, the job can't legally use.

546
00:27:08,600 --> 00:27:10,000
The quantity exists on paper.

547
00:27:10,000 --> 00:27:12,200
The usable material doesn't exist in reality,

548
00:27:12,200 --> 00:27:14,400
and this happens for completely sensible reasons.

549
00:27:14,400 --> 00:27:17,400
Quality hold stop suspect material from moving into production,

550
00:27:17,400 --> 00:27:19,400
batch rules protect traceability,

551
00:27:19,400 --> 00:27:23,400
some material simply expire, especially chemicals, adhesives, coatings,

552
00:27:23,400 --> 00:27:26,000
or items with controlled storage conditions.

553
00:27:26,000 --> 00:27:28,600
A substitute might look equivalent in a planning record,

554
00:27:28,600 --> 00:27:32,800
but still needs engineering or quality approval before it can enter a specific product.

555
00:27:32,800 --> 00:27:34,800
None of those rules are administrative noise.

556
00:27:34,800 --> 00:27:38,800
They protect the product, the customer, and sometimes the operator running the machine.

557
00:27:38,800 --> 00:27:40,600
Partial kits create a different kind of headache,

558
00:27:40,600 --> 00:27:43,400
say a job needs 10 components and 9 are available.

559
00:27:43,400 --> 00:27:45,400
The missing item might cost a few euros,

560
00:27:45,400 --> 00:27:47,200
but without it the order can't complete.

561
00:27:47,200 --> 00:27:50,800
If production starts anyway, the plant burns machine time and labour,

562
00:27:50,800 --> 00:27:53,400
then leaves semi finished work waiting for that final part.

563
00:27:53,400 --> 00:27:55,800
That choice can make sense in a few specific cases,

564
00:27:55,800 --> 00:27:57,200
but it needs to be deliberate,

565
00:27:57,200 --> 00:27:59,400
because partial completion uses capacity

566
00:27:59,400 --> 00:28:02,600
that another fully ready order could have used to ship on time.

567
00:28:02,600 --> 00:28:07,000
The harder situation appears when a material delivery and a capacity slot collide on the same day.

568
00:28:07,000 --> 00:28:09,800
The ERP shows a supplier delivery due Tuesday morning

569
00:28:09,800 --> 00:28:12,200
and a machining operation plan for Tuesday afternoon.

570
00:28:12,200 --> 00:28:13,800
On paper that fits perfectly.

571
00:28:13,800 --> 00:28:16,800
In practice, receiving needs time to unload the material,

572
00:28:16,800 --> 00:28:18,800
check quantity, post the receipt,

573
00:28:18,800 --> 00:28:20,800
and maybe complete incoming inspection.

574
00:28:20,800 --> 00:28:24,000
If the material arrives late, or inspection flags an issue,

575
00:28:24,000 --> 00:28:25,800
that machining slot goes empty.

576
00:28:25,800 --> 00:28:28,200
When the slot belongs to a heavily loaded resource,

577
00:28:28,200 --> 00:28:31,200
recovering that lost time later in the week often isn't possible.

578
00:28:31,200 --> 00:28:35,600
This is exactly why material planning and finite scheduling need to talk to each other.

579
00:28:35,600 --> 00:28:40,000
Material availability determines which jobs can occupy a real production slot

580
00:28:40,000 --> 00:28:44,600
and limited slots change how much value an on-time material delivery actually creates.

581
00:28:44,600 --> 00:28:48,000
A component arriving Wednesday might still support the customer promise

582
00:28:48,000 --> 00:28:50,200
if the required machine has space Thursday.

583
00:28:50,200 --> 00:28:52,800
The same component arriving Wednesday causes a late order

584
00:28:52,800 --> 00:28:56,400
if the only qualified machine has no free slot until the following week.

585
00:28:56,400 --> 00:28:59,400
Material date and capacity date have to meet inside the same plan.

586
00:28:59,400 --> 00:29:02,000
And material alone still doesn't define readiness.

587
00:29:02,000 --> 00:29:05,000
The operation might need a specific fixture that's tied up elsewhere,

588
00:29:05,000 --> 00:29:07,400
cutting tools might lack enough remaining life.

589
00:29:07,400 --> 00:29:10,000
A qualified operator might only work a certain shift.

590
00:29:10,000 --> 00:29:13,200
Some products need a quality technician available for first off approval

591
00:29:13,200 --> 00:29:15,000
before the machine can keep running,

592
00:29:15,000 --> 00:29:18,800
planning each condition in a separate system produces a familiar result.

593
00:29:18,800 --> 00:29:24,000
Every team reports its own part, looks fine, while the jobs still can't start.

594
00:29:24,000 --> 00:29:28,600
A workable schedule brings those conditions together at the moment of execution.

595
00:29:28,600 --> 00:29:30,800
It asks, is the approved material available?

596
00:29:30,800 --> 00:29:32,400
Is the machine eligible and free?

597
00:29:32,400 --> 00:29:34,000
Are the tools and fixture ready?

598
00:29:34,000 --> 00:29:37,000
And can the required people support the job in that time window?

599
00:29:37,000 --> 00:29:40,400
That's a much stricter question than whether the inventory balance looks positive.

600
00:29:40,400 --> 00:29:43,000
ERP remains the source for most of this supply information.

601
00:29:43,000 --> 00:29:46,400
It holds the bill of material, the inventory position, supply of commitments,

602
00:29:46,400 --> 00:29:48,200
and the purchase transaction trail.

603
00:29:48,200 --> 00:29:51,800
But a constraint-based planning process needs usable material status,

604
00:29:51,800 --> 00:29:53,400
not just a quantity field,

605
00:29:53,400 --> 00:29:56,200
and it needs to test that status against real resource time.

606
00:29:56,200 --> 00:29:59,600
Once you add those checks, another form of dependency enters the schedule.

607
00:29:59,600 --> 00:30:01,600
A job doesn't only need the right inputs,

608
00:30:01,600 --> 00:30:04,000
it also needs to follow the required production path

609
00:30:04,000 --> 00:30:06,600
with one operation handing work to the next.

610
00:30:06,600 --> 00:30:09,400
Routing logic does not create a feasible schedule.

611
00:30:09,400 --> 00:30:12,800
A routing describes the planned path in order should take through production.

612
00:30:12,800 --> 00:30:16,400
It tells the system that this component moves from cutting to machining,

613
00:30:16,400 --> 00:30:18,000
then inspection, then assembly.

614
00:30:18,000 --> 00:30:21,000
For planning and costing, that structure matters a lot.

615
00:30:21,000 --> 00:30:23,000
But here's the distinction people miss.

616
00:30:23,000 --> 00:30:24,600
A routing describes a path.

617
00:30:24,600 --> 00:30:26,200
It doesn't reserve the road.

618
00:30:26,200 --> 00:30:29,000
Each operation usually has a predecessor and a successor.

619
00:30:29,000 --> 00:30:32,000
Machining can't start until cutting produces the required part,

620
00:30:32,000 --> 00:30:35,200
assembly can't begin until the machined components pass inspection.

621
00:30:35,200 --> 00:30:37,000
That gives the order a logical flow,

622
00:30:37,000 --> 00:30:39,800
and ERP can calculate dates that respect that flow.

623
00:30:39,800 --> 00:30:43,000
Still, factories rarely move whole orders as one solid block.

624
00:30:43,000 --> 00:30:46,800
A transfer batch might let the first 50 pieces from a larger lot

625
00:30:46,800 --> 00:30:49,800
move to the next operation before the rest of the lot finishes.

626
00:30:49,800 --> 00:30:51,600
That shortens lead time in many cases.

627
00:30:51,600 --> 00:30:54,200
In another process, the full batch must finish and pass a check

628
00:30:54,200 --> 00:30:56,000
before anything moves downstream.

629
00:30:56,000 --> 00:30:58,800
Overlapped rules handle the same question differently.

630
00:30:58,800 --> 00:31:02,600
One operation may start after a defined percentage of the prior operation completes

631
00:31:02,600 --> 00:31:04,400
or only after a formal release.

632
00:31:04,400 --> 00:31:06,800
Those rules shape the timing of an order

633
00:31:06,800 --> 00:31:09,400
and they can be perfectly reasonable in an ERP routing.

634
00:31:09,400 --> 00:31:11,800
The issue appears when those calculated operation dates

635
00:31:11,800 --> 00:31:13,200
reach shared resources.

636
00:31:13,200 --> 00:31:15,800
Take an order where cutting finishes at 10 in the morning

637
00:31:15,800 --> 00:31:18,000
and the routing permits machining to begin at 10

638
00:31:18,000 --> 00:31:19,800
because the transfer batch is ready.

639
00:31:19,800 --> 00:31:21,800
The ERP respects the predecessor link.

640
00:31:21,800 --> 00:31:23,400
It followed the defined logic.

641
00:31:23,400 --> 00:31:26,600
Yet, the machining resource might already run another order

642
00:31:26,600 --> 00:31:27,800
until late afternoon.

643
00:31:27,800 --> 00:31:30,600
The routing told you when the job becomes eligible to run.

644
00:31:30,600 --> 00:31:33,000
It hasn't proven the job can actually run then.

645
00:31:33,000 --> 00:31:35,400
Duration adds another layer of uncertainty.

646
00:31:35,400 --> 00:31:38,000
Many routing's use fixed and variable time.

647
00:31:38,000 --> 00:31:42,400
Fixed time might cover setup, loading, preparation, or first piece approval.

648
00:31:42,400 --> 00:31:44,600
Variable time changes with the order quantity,

649
00:31:44,600 --> 00:31:47,200
so producing more units takes more machine time.

650
00:31:47,200 --> 00:31:49,600
That model gives planning a reasonable starting point.

651
00:31:49,600 --> 00:31:52,200
But actual duration can differ for legitimate reasons.

652
00:31:52,200 --> 00:31:54,200
One batch needs more tool changes.

653
00:31:54,200 --> 00:31:55,800
A part requires an extra measurement.

654
00:31:55,800 --> 00:31:57,800
Material condition changes cutting speed.

655
00:31:57,800 --> 00:32:00,000
A machine runs slower for a difficult geometry.

656
00:32:00,000 --> 00:32:01,800
Sometimes standard time is close enough.

657
00:32:01,800 --> 00:32:03,600
Sometimes it's only a useful average.

658
00:32:03,600 --> 00:32:05,800
A schedule that treats every duration as fixed.

659
00:32:05,800 --> 00:32:07,200
When production knows it varies,

660
00:32:07,200 --> 00:32:10,200
we'll always look far cleaner than the shift it's trying to control.

661
00:32:10,200 --> 00:32:12,600
Then there are routes that don't behave like a straight line.

662
00:32:12,600 --> 00:32:15,000
Rework can send a part back to an earlier step

663
00:32:15,000 --> 00:32:16,600
after inspection finds a problem.

664
00:32:16,600 --> 00:32:18,400
That loop consumes capacity again,

665
00:32:18,400 --> 00:32:21,400
but it might not appear until execution confirms the issue.

666
00:32:21,400 --> 00:32:23,600
Alternative operations add another choice.

667
00:32:23,600 --> 00:32:25,400
A component normally runs on one machine,

668
00:32:25,400 --> 00:32:28,200
while a second machine can process it under certain conditions,

669
00:32:28,200 --> 00:32:32,400
perhaps with a different tool, program, quality check, or longer duration.

670
00:32:32,400 --> 00:32:34,800
Outside processing creates another dependency.

671
00:32:34,800 --> 00:32:37,800
An order may leave the plant for coating heat treatment, calibration,

672
00:32:37,800 --> 00:32:39,000
or a specialist process,

673
00:32:39,000 --> 00:32:41,800
then return before the next internal operation can begin.

674
00:32:41,800 --> 00:32:44,200
The routing includes plant lead time for that step.

675
00:32:44,200 --> 00:32:46,200
But the schedule still needs to handle what happens

676
00:32:46,200 --> 00:32:48,400
when the outside service date changes,

677
00:32:48,400 --> 00:32:52,400
or when the return part misses the internal resource window everyone expected.

678
00:32:52,400 --> 00:32:56,200
That's why a routing needs more than dates to become a working production plan.

679
00:32:56,200 --> 00:32:59,000
It needs the rules that govern movement between operations,

680
00:32:59,000 --> 00:33:00,800
the time assumptions behind each operation,

681
00:33:00,800 --> 00:33:03,400
and the resource choices that remain legal for that job.

682
00:33:03,400 --> 00:33:07,000
Then it needs a scheduling process that tests all of those conditions

683
00:33:07,000 --> 00:33:09,200
against actual slots across the factory.

684
00:33:09,200 --> 00:33:12,400
ERP can calculate an order flow that makes sense on its own terms.

685
00:33:12,400 --> 00:33:15,800
It can say cutting precedes, machining, machining precedes inspection

686
00:33:15,800 --> 00:33:17,200
and inspection precedes assembly.

687
00:33:17,200 --> 00:33:18,000
That's useful.

688
00:33:18,000 --> 00:33:20,600
Yet several orders can all follow their correct routing logic

689
00:33:20,600 --> 00:33:23,600
and still collide at the same machine, tool, test station,

690
00:33:23,600 --> 00:33:25,400
or outside supplier window.

691
00:33:25,400 --> 00:33:27,800
Order flow answers, what comes before what?

692
00:33:27,800 --> 00:33:30,400
A feasible schedule answers a harder question.

693
00:33:30,400 --> 00:33:31,600
Where does it run?

694
00:33:31,600 --> 00:33:35,600
Exactly when, and what gives way if two orders need the same slot?

695
00:33:35,600 --> 00:33:38,600
Keep that distinction in mind because the plan faces one more problem.

696
00:33:38,600 --> 00:33:41,200
Even if all the routing logic and resource rules are correct

697
00:33:41,200 --> 00:33:42,600
when the schedule is created,

698
00:33:42,600 --> 00:33:45,600
a real factory changes while the work is underway.

699
00:33:45,600 --> 00:33:47,800
The factory does not follow the plan.

700
00:33:47,800 --> 00:33:52,400
By 9.15, that schedule that looked solid at 8 in the morning is already wrong,

701
00:33:52,400 --> 00:33:54,200
and that's not a planning failure.

702
00:33:54,200 --> 00:33:58,800
Production deals with physical work and physical work changes constantly.

703
00:33:58,800 --> 00:34:00,800
Take a typical morning.

704
00:34:00,800 --> 00:34:02,800
A machine throws an alarm that needs maintenance,

705
00:34:02,800 --> 00:34:06,000
the one operator qualified for a control process calls and sick,

706
00:34:06,000 --> 00:34:10,800
quality rejects a batch creating scrap and forcing a replacement order into the flow,

707
00:34:10,800 --> 00:34:13,000
and then sales calls with an urgent request

708
00:34:13,000 --> 00:34:15,000
because a customer's line just stopped.

709
00:34:15,000 --> 00:34:18,600
Each one of those events changes more than just that single order.

710
00:34:18,600 --> 00:34:20,400
Here's what unplanned downtime really means.

711
00:34:20,400 --> 00:34:22,000
If a machine stops for 30 minutes,

712
00:34:22,000 --> 00:34:24,600
the first question isn't just when maintenance restarts it,

713
00:34:24,600 --> 00:34:26,600
you also need to know which operation was running,

714
00:34:26,600 --> 00:34:28,000
how much good quantity you have,

715
00:34:28,000 --> 00:34:29,600
whether material is still set up,

716
00:34:29,600 --> 00:34:30,800
whether the tool is damaged,

717
00:34:30,800 --> 00:34:33,200
and which later jobs just lost their planned time.

718
00:34:33,200 --> 00:34:35,200
The schedule needs facts, not guesses.

719
00:34:35,200 --> 00:34:38,200
Now this is where the MES and machine data enter the picture.

720
00:34:38,200 --> 00:34:40,400
The MES reports whether an operation started,

721
00:34:40,400 --> 00:34:41,600
paused, completed,

722
00:34:41,600 --> 00:34:43,600
or only produced part of its planned quantity.

723
00:34:43,600 --> 00:34:45,200
Machine signals give you a stop,

724
00:34:45,200 --> 00:34:47,000
an alarm state, a cycle count,

725
00:34:47,000 --> 00:34:48,800
or a change in runtime condition.

726
00:34:48,800 --> 00:34:50,000
But here's the catch.

727
00:34:50,000 --> 00:34:53,200
Raw signals don't automatically justify a schedule change.

728
00:34:53,200 --> 00:34:55,200
A machine alarm might clear in two minutes,

729
00:34:55,200 --> 00:34:57,000
a status feed might arrive late,

730
00:34:57,000 --> 00:34:59,000
or an operator records a temporary stop

731
00:34:59,000 --> 00:35:01,000
before a supervisor confirms the cause.

732
00:35:01,000 --> 00:35:03,800
If every incoming signal triggers a full reschedule,

733
00:35:03,800 --> 00:35:05,200
the plan becomes noise.

734
00:35:05,200 --> 00:35:06,600
People stop trusting it,

735
00:35:06,600 --> 00:35:08,000
because the next instruction changes

736
00:35:08,000 --> 00:35:09,800
before they can act on the previous one.

737
00:35:09,800 --> 00:35:12,800
So you need three separate stages to handle this properly.

738
00:35:12,800 --> 00:35:14,800
The process starts with a signal.

739
00:35:14,800 --> 00:35:17,600
An alarm, a delayed material receipt,

740
00:35:17,600 --> 00:35:20,800
a quality hold, or a direct message from the shop floor.

741
00:35:20,800 --> 00:35:22,800
It tells you something may need attention.

742
00:35:22,800 --> 00:35:24,800
Then the confirmed event arrives.

743
00:35:24,800 --> 00:35:27,000
Someone, or a trusted system rule,

744
00:35:27,000 --> 00:35:29,800
determines that the machine will be down for the rest of the shift,

745
00:35:29,800 --> 00:35:31,400
the material can't be released,

746
00:35:31,400 --> 00:35:34,200
or the operator absence changes available skill coverage.

747
00:35:34,200 --> 00:35:37,000
Now the event has enough meaning to affect planning.

748
00:35:37,000 --> 00:35:39,200
Only at that point does it make sense to decide

749
00:35:39,200 --> 00:35:41,000
whether the schedule actually changes.

750
00:35:41,000 --> 00:35:42,200
That step sounds obvious,

751
00:35:42,200 --> 00:35:43,800
but it gets skipped all the time.

752
00:35:43,800 --> 00:35:46,400
A disruption happens and someone moves several orders,

753
00:35:46,400 --> 00:35:48,800
and the factory spends the rest of the day chasing a plan

754
00:35:48,800 --> 00:35:51,000
that changed for no clear reason.

755
00:35:51,000 --> 00:35:53,800
A controlled process asks what the confirmed event effects,

756
00:35:53,800 --> 00:35:55,400
which commitments face risk,

757
00:35:55,400 --> 00:35:57,800
and whether moving work actually improves the outcome.

758
00:35:57,800 --> 00:36:00,000
And sometimes the right decision is no change at all.

759
00:36:00,000 --> 00:36:02,200
If the delay fits inside a protected buffer,

760
00:36:02,200 --> 00:36:03,600
leave the sequence alone.

761
00:36:03,600 --> 00:36:05,000
If a machine returns shortly,

762
00:36:05,000 --> 00:36:06,200
and the next job is ready,

763
00:36:06,200 --> 00:36:09,200
changing the schedule creates more disruption than the stop itself,

764
00:36:09,200 --> 00:36:11,200
people on the floor need stable instructions,

765
00:36:11,200 --> 00:36:13,200
especially when execution is close.

766
00:36:13,200 --> 00:36:15,600
But other events do justify a change.

767
00:36:15,600 --> 00:36:17,400
A confirmed machine outage,

768
00:36:17,400 --> 00:36:19,400
that removes the resource for the shift,

769
00:36:19,400 --> 00:36:22,400
scrap that means an order no longer has enough good quantity,

770
00:36:22,400 --> 00:36:24,200
or an urgent customer request

771
00:36:24,200 --> 00:36:27,200
with a commercial reason strong enough to displace planned work.

772
00:36:27,200 --> 00:36:29,400
Even then you need to think through the consequences,

773
00:36:29,400 --> 00:36:30,400
which order moves,

774
00:36:30,400 --> 00:36:32,400
which delivery promise now faces risk.

775
00:36:32,400 --> 00:36:35,600
Does the new sequence introduce extra setup or quality work?

776
00:36:35,600 --> 00:36:36,600
Is the material ready?

777
00:36:36,600 --> 00:36:39,000
Can the affected team actually act on the new instruction?

778
00:36:39,000 --> 00:36:40,800
A schedule change without those answers

779
00:36:40,800 --> 00:36:43,000
is just a new version of the same wish list.

780
00:36:43,000 --> 00:36:45,200
Static plans lose relevance quickly.

781
00:36:45,200 --> 00:36:48,200
They describe the factory as it existed at calculation time,

782
00:36:48,200 --> 00:36:51,800
while execution data describes the factory as it is right now.

783
00:36:51,800 --> 00:36:54,000
Good re-planning connects those two views

784
00:36:54,000 --> 00:36:55,800
without treating every small variation

785
00:36:55,800 --> 00:36:57,800
as a reason to rebuild the entire day.

786
00:36:57,800 --> 00:37:00,200
That requires discipline, thresholds, ownership,

787
00:37:00,200 --> 00:37:02,800
and a shared understanding of which events demand action,

788
00:37:02,800 --> 00:37:05,000
otherwise the loudest message wins,

789
00:37:05,000 --> 00:37:07,200
and the schedule becomes a record of interruptions

790
00:37:07,200 --> 00:37:08,800
rather than a guide for production,

791
00:37:08,800 --> 00:37:10,600
which is exactly why experienced planners

792
00:37:10,600 --> 00:37:12,400
keep local tools close by.

793
00:37:12,400 --> 00:37:14,400
They need somewhere to combine the ERP plan

794
00:37:14,400 --> 00:37:16,600
with the calls, events, and practical facts

795
00:37:16,600 --> 00:37:19,000
that arrive after the plan meets the shop floor.

796
00:37:19,000 --> 00:37:20,800
And that explains why Excel survives.

797
00:37:20,800 --> 00:37:22,600
Why Excel survives on the shop floor?

798
00:37:22,600 --> 00:37:24,200
This is where Excel shows up.

799
00:37:24,200 --> 00:37:25,200
It rolls their eyes,

800
00:37:25,200 --> 00:37:27,000
but the planner just gets on with it

801
00:37:27,000 --> 00:37:29,600
because they have to get work through the plant by Friday.

802
00:37:29,600 --> 00:37:31,400
The planner opens the ERP order list

803
00:37:31,400 --> 00:37:33,000
and keeps a spreadsheet beside it,

804
00:37:33,000 --> 00:37:35,000
taking a call from production about a machine

805
00:37:35,000 --> 00:37:36,800
that can't run a certain part today,

806
00:37:36,800 --> 00:37:39,000
reading a note about a tool still at maintenance

807
00:37:39,000 --> 00:37:40,600
and remembering that one operator

808
00:37:40,600 --> 00:37:42,600
can handle a difficult setup on the late shift

809
00:37:42,600 --> 00:37:44,200
while another can't?

810
00:37:44,200 --> 00:37:46,600
None of that fits neatly into a standard order date,

811
00:37:46,600 --> 00:37:48,800
so the spreadsheet becomes the working schedule.

812
00:37:48,800 --> 00:37:50,800
Sometimes it's a detailed file with tabs,

813
00:37:50,800 --> 00:37:52,600
color codes, filters, and formulas,

814
00:37:52,600 --> 00:37:54,800
only one person fully understands.

815
00:37:54,800 --> 00:37:56,800
Other times, it's simpler.

816
00:37:56,800 --> 00:37:59,200
A printed list, handwritten notes,

817
00:37:59,200 --> 00:38:01,000
a whiteboard near the production office,

818
00:38:01,000 --> 00:38:02,200
and the format changes,

819
00:38:02,200 --> 00:38:03,600
but the reason rarely does,

820
00:38:03,600 --> 00:38:05,000
the planner needs to connect facts

821
00:38:05,000 --> 00:38:06,600
that live in different places.

822
00:38:06,600 --> 00:38:08,000
ERP knows the order,

823
00:38:08,000 --> 00:38:10,400
routing, requested date, and material record.

824
00:38:10,400 --> 00:38:13,200
The MES may know current operation status,

825
00:38:13,200 --> 00:38:16,000
maintenance, knows plan work on the machine,

826
00:38:16,000 --> 00:38:18,400
production knows which setup causes trouble,

827
00:38:18,400 --> 00:38:21,400
quality knows a customer specific inspection is due.

828
00:38:21,400 --> 00:38:23,000
The planner pulls those fragments together

829
00:38:23,000 --> 00:38:25,000
into an instruction people can use.

830
00:38:25,000 --> 00:38:27,400
That manual board solves a context problem,

831
00:38:27,400 --> 00:38:29,000
it puts an order beside the machine

832
00:38:29,000 --> 00:38:30,600
that can run it the job before it,

833
00:38:30,600 --> 00:38:32,000
the person who supports it,

834
00:38:32,000 --> 00:38:35,000
and the practical condition that changes the sequence.

835
00:38:35,000 --> 00:38:37,600
An ERP screen may contain all the raw data,

836
00:38:37,600 --> 00:38:39,800
but it rarely brings those relationships together

837
00:38:39,800 --> 00:38:41,400
in a way that lets someone decide

838
00:38:41,400 --> 00:38:42,800
the next job under pressure.

839
00:38:42,800 --> 00:38:45,400
So I'd be careful when people call Excel the problem.

840
00:38:45,400 --> 00:38:47,800
It survives because it lets a planner shape

841
00:38:47,800 --> 00:38:50,000
a local model around the factory they know,

842
00:38:50,000 --> 00:38:52,400
adding a column for a constraint nobody modeled,

843
00:38:52,400 --> 00:38:54,200
moving an order in seconds,

844
00:38:54,200 --> 00:38:55,600
leaving a note that says,

845
00:38:55,600 --> 00:38:57,400
"Wait for first article approval"

846
00:38:57,400 --> 00:39:00,800
or "Run after the current batch if the tool returns."

847
00:39:00,800 --> 00:39:02,600
It's flexible because it doesn't insist

848
00:39:02,600 --> 00:39:05,200
the real world fit a rigid transaction form.

849
00:39:05,200 --> 00:39:06,400
Apparently Excel remains

850
00:39:06,400 --> 00:39:08,200
one of the most successful planning platforms

851
00:39:08,200 --> 00:39:10,000
Microsoft never intended to build,

852
00:39:10,000 --> 00:39:11,600
but flexibility has a cost.

853
00:39:11,600 --> 00:39:14,400
A local spreadsheet can carry business critical decisions

854
00:39:14,400 --> 00:39:17,000
without clear ownership, access control,

855
00:39:17,000 --> 00:39:18,000
version history,

856
00:39:18,000 --> 00:39:21,200
or a reliable trail of why someone moved an order.

857
00:39:21,200 --> 00:39:23,400
Two planners may work from different copies,

858
00:39:23,400 --> 00:39:25,400
a supervisor follows an old printout,

859
00:39:25,400 --> 00:39:28,000
"Someone changes a formula or overrides a date

860
00:39:28,000 --> 00:39:29,400
and nobody sees the effect

861
00:39:29,400 --> 00:39:31,600
until a customer order slips."

862
00:39:31,600 --> 00:39:33,800
The issue isn't that spreadsheets are bad,

863
00:39:33,800 --> 00:39:36,000
it's that the schedule can become private.

864
00:39:36,000 --> 00:39:37,600
If the person who maintains the file

865
00:39:37,600 --> 00:39:39,400
takes a holiday, leaves the company,

866
00:39:39,400 --> 00:39:40,800
or works a different shift,

867
00:39:40,800 --> 00:39:43,600
others inherit a plan without the reasoning behind it.

868
00:39:43,600 --> 00:39:45,000
They see a sequence of jobs,

869
00:39:45,000 --> 00:39:48,000
but they don't know which choices came from hard limits

870
00:39:48,000 --> 00:39:50,000
and which came from a personal preference

871
00:39:50,000 --> 00:39:52,000
or a phone call from sales.

872
00:39:52,000 --> 00:39:55,000
That creates a person dependent scheduling process.

873
00:39:55,000 --> 00:39:56,000
You might have an excellent planner

874
00:39:56,000 --> 00:39:58,000
who keeps the plant moving through experience,

875
00:39:58,000 --> 00:39:59,600
memory, and calm judgment,

876
00:39:59,600 --> 00:40:00,600
doing real engineering work,

877
00:40:00,600 --> 00:40:03,000
even if the tools make it look informal.

878
00:40:03,000 --> 00:40:04,000
Replacing their spreadsheet

879
00:40:04,000 --> 00:40:05,400
with a system that ignores their knowledge

880
00:40:05,400 --> 00:40:06,400
won't help.

881
00:40:06,400 --> 00:40:08,600
It just pushes real decisions back into messages,

882
00:40:08,600 --> 00:40:10,800
calls, and side conversations.

883
00:40:10,800 --> 00:40:13,200
A better approach captures the rules they use repeatedly

884
00:40:13,200 --> 00:40:15,200
while leaving room for them to judge the exceptions

885
00:40:15,200 --> 00:40:16,800
that no model can predict clearly.

886
00:40:16,800 --> 00:40:18,400
Ask the planner why a job moved,

887
00:40:18,400 --> 00:40:20,600
what must be true before that machine can run the order

888
00:40:20,600 --> 00:40:22,000
which changes over as they avoid,

889
00:40:22,000 --> 00:40:23,800
which customer dates can't move,

890
00:40:23,800 --> 00:40:25,800
and which resource causes the most trouble

891
00:40:25,800 --> 00:40:27,400
when its plan changes.

892
00:40:27,400 --> 00:40:29,600
Those answers describe the real scheduling logic

893
00:40:29,600 --> 00:40:32,000
far better than a generic template ever will.

894
00:40:32,000 --> 00:40:34,400
Some of that logic belongs in master data,

895
00:40:34,400 --> 00:40:36,000
some infinite scheduling rules,

896
00:40:36,000 --> 00:40:38,000
and some should remain a planner decision

897
00:40:38,000 --> 00:40:40,200
because the factory occasionally faces choices

898
00:40:40,200 --> 00:40:41,800
that need commercial judgment

899
00:40:41,800 --> 00:40:44,000
or direct discussion with operations.

900
00:40:44,000 --> 00:40:46,200
The aim isn't to eliminate the planner's board,

901
00:40:46,200 --> 00:40:48,600
it's to stop the board from becoming the only place

902
00:40:48,600 --> 00:40:50,800
where the factory's real constraints exist.

903
00:40:50,800 --> 00:40:52,000
And once you see that,

904
00:40:52,000 --> 00:40:55,000
the missing capability needs a clearer definition.

905
00:40:55,000 --> 00:40:57,200
What an optimal schedule actually means,

906
00:40:57,200 --> 00:40:59,400
people use the word optimal pretty casually

907
00:40:59,400 --> 00:41:00,800
when they talk about production planning,

908
00:41:00,800 --> 00:41:02,600
it sounds like there's one perfect schedule

909
00:41:02,600 --> 00:41:04,000
hidden somewhere in the system,

910
00:41:04,000 --> 00:41:06,000
just waiting for the right software to dig it out,

911
00:41:06,000 --> 00:41:07,000
but here's the truth.

912
00:41:07,000 --> 00:41:08,200
They usually isn't.

913
00:41:08,200 --> 00:41:10,400
What counts as optimal depends entirely

914
00:41:10,400 --> 00:41:12,200
on what the business is trying to improve,

915
00:41:12,200 --> 00:41:14,400
which rules it absolutely won't bend,

916
00:41:14,400 --> 00:41:16,000
and what trade-offs it's willing to make

917
00:41:16,000 --> 00:41:18,400
when those goals pull in different directions.

918
00:41:18,400 --> 00:41:19,800
If you haven't defined that part,

919
00:41:19,800 --> 00:41:22,600
optimal just means someone likes the answer.

920
00:41:22,600 --> 00:41:24,400
So let's start with something more concrete,

921
00:41:24,400 --> 00:41:26,200
a schedule that can actually run,

922
00:41:26,200 --> 00:41:28,600
that means every planned job respects the conditions

923
00:41:28,600 --> 00:41:30,600
the plant has agreed are non-negotiable.

924
00:41:30,600 --> 00:41:32,200
The job has a legal resource,

925
00:41:32,200 --> 00:41:33,400
the timing lines up,

926
00:41:33,400 --> 00:41:35,600
the order follows its required process path,

927
00:41:35,600 --> 00:41:37,200
and the necessary inputs are ready

928
00:41:37,200 --> 00:41:39,000
when the operation needs them.

929
00:41:39,000 --> 00:41:41,200
No resource gets more work than it can handle

930
00:41:41,200 --> 00:41:42,200
in the time assigned,

931
00:41:42,200 --> 00:41:43,800
that's feasibility right there,

932
00:41:43,800 --> 00:41:46,600
but a feasible schedule can still be a terrible business decision.

933
00:41:46,600 --> 00:41:49,600
You can build a plan that follows every physical rule perfectly

934
00:41:49,600 --> 00:41:52,000
yet delivers an urgent customer order late.

935
00:41:52,000 --> 00:41:54,200
Or you can build one that protects every customer date

936
00:41:54,200 --> 00:41:56,000
but forces constant setup changes

937
00:41:56,000 --> 00:41:58,400
and leaves too much work sitting idle between operations.

938
00:41:58,400 --> 00:41:59,400
Both plans will run,

939
00:41:59,400 --> 00:42:01,800
but neither one automatically serves the business.

940
00:42:01,800 --> 00:42:04,400
So once the schedule clears that feasibility test,

941
00:42:04,400 --> 00:42:05,400
you need a clear objective,

942
00:42:05,400 --> 00:42:07,600
sometimes the main goal is due date performance.

943
00:42:07,600 --> 00:42:10,200
The factory needs to protect a short list of customer commitments

944
00:42:10,200 --> 00:42:12,600
where a late shipment creates a real commercial problem.

945
00:42:12,600 --> 00:42:15,000
In another period, the goal might shift to throughput

946
00:42:15,000 --> 00:42:17,000
where moving as much finished work as possible

947
00:42:17,000 --> 00:42:18,400
through a constrained area

948
00:42:18,400 --> 00:42:20,600
determines what the plant can even ship.

949
00:42:20,600 --> 00:42:22,000
Here's where it gets tricky.

950
00:42:22,000 --> 00:42:24,800
Those goals can point in completely different directions.

951
00:42:24,800 --> 00:42:26,600
Think about an order that's due soon

952
00:42:26,600 --> 00:42:29,000
but needs a difficult change over at a busy resource.

953
00:42:29,000 --> 00:42:31,400
Running it next might protect the customer promise

954
00:42:31,400 --> 00:42:33,800
but it could also break a productive campaign,

955
00:42:33,800 --> 00:42:36,800
burn extra setup time and push several other orders later.

956
00:42:36,800 --> 00:42:38,400
Neither choice is automatically wrong

957
00:42:38,400 --> 00:42:41,000
if the business hasn't said which priority wins.

958
00:42:41,000 --> 00:42:43,800
The planner needs to see the real cost of each option

959
00:42:43,800 --> 00:42:46,200
if the urgent order goes first, which orders move,

960
00:42:46,200 --> 00:42:47,800
how much setup time gets added,

961
00:42:47,800 --> 00:42:50,000
and what happens to the work already queued.

962
00:42:50,000 --> 00:42:52,000
If the campaign continues instead,

963
00:42:52,000 --> 00:42:53,800
which customer date faces risk

964
00:42:53,800 --> 00:42:56,200
and does the business actually accept that risk,

965
00:42:56,200 --> 00:42:57,400
that's the heart of planning,

966
00:42:57,400 --> 00:42:59,200
not just sorting a list by date.

967
00:42:59,200 --> 00:43:00,200
Setup reduction matters

968
00:43:00,200 --> 00:43:03,200
because every avoidable change steals time from production.

969
00:43:03,200 --> 00:43:04,700
Lower work in progress matters

970
00:43:04,700 --> 00:43:07,600
because large queues hide priority and inflate lead time.

971
00:43:07,600 --> 00:43:10,800
Cost matters when overtime, subcontracting, premium freight,

972
00:43:10,800 --> 00:43:13,200
or a costly alternative resource enters the picture.

973
00:43:13,200 --> 00:43:14,400
And stability matters too,

974
00:43:14,400 --> 00:43:16,200
a schedule that reshuffles every hour

975
00:43:16,200 --> 00:43:18,200
might find a slightly better answer on paper

976
00:43:18,200 --> 00:43:20,800
but it creates a worst day for operators, supervisors,

977
00:43:20,800 --> 00:43:22,800
material handlers and quality teams.

978
00:43:22,800 --> 00:43:24,800
People need enough confidence in the near term plan

979
00:43:24,800 --> 00:43:26,400
to prepare work, stage material,

980
00:43:26,400 --> 00:43:28,600
and finish the job without chasing a new instruction

981
00:43:28,600 --> 00:43:30,000
halfway through the shift.

982
00:43:30,000 --> 00:43:33,000
So an optimal schedule often includes a preference

983
00:43:33,000 --> 00:43:35,200
for fewer unnecessary changes.

984
00:43:35,200 --> 00:43:37,000
Not because the plan should ignore disruption

985
00:43:37,000 --> 00:43:39,400
but because change itself has a real cost.

986
00:43:39,400 --> 00:43:40,600
The system should know

987
00:43:40,600 --> 00:43:42,520
when a new plan improves the result enough

988
00:43:42,520 --> 00:43:43,960
to justify that cost.

989
00:43:43,960 --> 00:43:46,360
This brings us back to the planner's private spreadsheet,

990
00:43:46,360 --> 00:43:48,880
a good planner already carries an objective in their head.

991
00:43:48,880 --> 00:43:50,800
They know customer X needs protection,

992
00:43:50,800 --> 00:43:53,200
they know a long run of similar parts saves time,

993
00:43:53,200 --> 00:43:55,200
and they know which orders are safe to move

994
00:43:55,200 --> 00:43:58,100
versus which ones will trigger a phone call before lunch.

995
00:43:58,100 --> 00:43:59,880
But if those priorities stay unspoken,

996
00:43:59,880 --> 00:44:01,480
the schedule can't explain itself.

997
00:44:01,480 --> 00:44:03,280
Two planners can look at the same order list

998
00:44:03,280 --> 00:44:04,640
and make completely different calls

999
00:44:04,640 --> 00:44:06,440
because they value different outcomes.

1000
00:44:06,440 --> 00:44:09,080
One might protect customer dates at almost any cost

1001
00:44:09,080 --> 00:44:11,120
while another might preserve the production sequence

1002
00:44:11,120 --> 00:44:13,920
unless a customer commitment faces immediate risk.

1003
00:44:13,920 --> 00:44:15,160
Both might have sound reasons

1004
00:44:15,160 --> 00:44:17,960
but the business needs to decide which rule actually applies.

1005
00:44:17,960 --> 00:44:20,760
That means constraints and priorities need clear names.

1006
00:44:20,760 --> 00:44:23,720
A hard constraint means the schedule cannot break it.

1007
00:44:23,720 --> 00:44:25,920
A machine may not run a certain material,

1008
00:44:25,920 --> 00:44:28,440
a qualified person needs to approve an operation

1009
00:44:28,440 --> 00:44:30,080
or a customer delivery is locked

1010
00:44:30,080 --> 00:44:33,160
because of a contract or a shutdown on their end.

1011
00:44:33,160 --> 00:44:34,520
A preference is different.

1012
00:44:34,520 --> 00:44:36,640
Grouping similar work to save setup time,

1013
00:44:36,640 --> 00:44:39,040
keeping the plan stable to reduce confusion

1014
00:44:39,040 --> 00:44:41,720
or choosing the lower cost route to protect margin,

1015
00:44:41,720 --> 00:44:44,280
these all matter, but the business can override them

1016
00:44:44,280 --> 00:44:46,120
when something more urgent comes up.

1017
00:44:46,120 --> 00:44:48,800
Once those rules sit openly in the planning process,

1018
00:44:48,800 --> 00:44:50,080
people can challenge them.

1019
00:44:50,080 --> 00:44:52,240
They can ask whether a customer date is truly fixed,

1020
00:44:52,240 --> 00:44:53,720
whether a setup rule still applies

1021
00:44:53,720 --> 00:44:56,040
or whether an assumed priority has actually changed,

1022
00:44:56,040 --> 00:44:58,080
that's far better than letting hidden habits decide

1023
00:44:58,080 --> 00:44:59,200
which order wins.

1024
00:44:59,200 --> 00:45:00,760
So optimal doesn't mean perfect.

1025
00:45:00,760 --> 00:45:02,800
It means the best feasible schedule against goals

1026
00:45:02,800 --> 00:45:04,400
the business has actually stated

1027
00:45:04,400 --> 00:45:07,280
with the reasons visible when one goal gives way to another.

1028
00:45:07,280 --> 00:45:10,280
And before any system can start hunting for the best schedule,

1029
00:45:10,280 --> 00:45:12,040
it needs to answer a simpler question first.

1030
00:45:12,040 --> 00:45:14,000
Can this plan physically run at all?

1031
00:45:14,000 --> 00:45:15,800
Finite scheduling in plain terms.

1032
00:45:15,800 --> 00:45:18,120
Finite scheduling starts with one simple rule.

1033
00:45:18,120 --> 00:45:20,680
Each resource only has the time it can actually provide.

1034
00:45:20,680 --> 00:45:23,000
That sounds obvious, but it completely changes

1035
00:45:23,000 --> 00:45:24,000
how planning works.

1036
00:45:24,000 --> 00:45:25,920
Instead of placing every operation on the date

1037
00:45:25,920 --> 00:45:27,040
it would ideally need,

1038
00:45:27,040 --> 00:45:29,040
the schedule checks the real time slots available

1039
00:45:29,040 --> 00:45:31,120
on the resources required to do the work.

1040
00:45:31,120 --> 00:45:33,360
Take an operation that needs four hours

1041
00:45:33,360 --> 00:45:34,600
on a machining center.

1042
00:45:34,600 --> 00:45:36,760
In a finite schedule those four hours occupy

1043
00:45:36,760 --> 00:45:38,400
a real slot on that machine.

1044
00:45:38,400 --> 00:45:41,200
And during that same period, no other job can claim it.

1045
00:45:41,200 --> 00:45:42,680
The schedule treats time as something

1046
00:45:42,680 --> 00:45:44,640
that must be reserved, not assumed.

1047
00:45:44,640 --> 00:45:46,240
And here's what people often miss.

1048
00:45:46,240 --> 00:45:48,080
The machine might not be the only resource

1049
00:45:48,080 --> 00:45:49,280
the job consumes.

1050
00:45:49,280 --> 00:45:50,960
A job can need a specific machine,

1051
00:45:50,960 --> 00:45:52,680
a fixture, a trained operator,

1052
00:45:52,680 --> 00:45:54,720
and a work area for loading or inspection.

1053
00:45:54,720 --> 00:45:56,200
The schedule checks those requirements

1054
00:45:56,200 --> 00:45:57,840
against the same time window.

1055
00:45:57,840 --> 00:45:59,800
If the machine is free, but the fixture is already

1056
00:45:59,800 --> 00:46:02,280
committed elsewhere, that isn't a valid slot.

1057
00:46:02,280 --> 00:46:04,320
If the operator with the required approval starts

1058
00:46:04,320 --> 00:46:06,120
on the late shift, the job can't just

1059
00:46:06,120 --> 00:46:08,640
begin on the early shift because the date looks right.

1060
00:46:08,640 --> 00:46:10,960
The plan has to deal with real duration too.

1061
00:46:10,960 --> 00:46:12,560
A job doesn't just appear to resource

1062
00:46:12,560 --> 00:46:15,280
and disappear once the system creates an operation record.

1063
00:46:15,280 --> 00:46:17,680
It occupies time for setup, processing,

1064
00:46:17,680 --> 00:46:19,280
and whatever defined production time

1065
00:46:19,280 --> 00:46:20,840
belongs in the planning rule.

1066
00:46:20,840 --> 00:46:22,720
When it finishes, the resource becomes available

1067
00:46:22,720 --> 00:46:24,400
for the next legal operation.

1068
00:46:24,400 --> 00:46:26,000
That gives you a schedule people can actually

1069
00:46:26,000 --> 00:46:27,440
test against the shift.

1070
00:46:27,440 --> 00:46:30,080
A supervisor can ask, what should this machine run

1071
00:46:30,080 --> 00:46:31,480
after the current job?

1072
00:46:31,480 --> 00:46:33,040
The schedule should answer with an order that

1073
00:46:33,040 --> 00:46:35,600
has an available slot, the required inputs,

1074
00:46:35,600 --> 00:46:36,880
and the place in the sequence.

1075
00:46:36,880 --> 00:46:38,720
It should not answer with three orders all planned

1076
00:46:38,720 --> 00:46:41,160
for the same hour and leave the supervisor to pick one.

1077
00:46:41,160 --> 00:46:43,240
When no legal slot exists, the finite schedule

1078
00:46:43,240 --> 00:46:44,080
has to move something.

1079
00:46:44,080 --> 00:46:45,480
It might push an operation later,

1080
00:46:45,480 --> 00:46:47,520
pull work forward if an earlier slot opens up,

1081
00:46:47,520 --> 00:46:49,920
or select another eligible resource where the rules allow it.

1082
00:46:49,920 --> 00:46:52,240
What it can't do is quietly place two conflicting jobs

1083
00:46:52,240 --> 00:46:54,040
on the same resource at the same time

1084
00:46:54,040 --> 00:46:55,320
and call that a plan.

1085
00:46:55,320 --> 00:46:57,440
And that limitation is actually useful.

1086
00:46:57,440 --> 00:46:59,840
It forces the conflict into the open.

1087
00:46:59,840 --> 00:47:02,200
If no slot exists before a customer date,

1088
00:47:02,200 --> 00:47:04,080
the schedule shows that the date faces risk

1089
00:47:04,080 --> 00:47:06,680
under the rules and capacity currently available.

1090
00:47:06,680 --> 00:47:08,560
Someone can then decide whether to add overtime,

1091
00:47:08,560 --> 00:47:09,720
use an approved alternative,

1092
00:47:09,720 --> 00:47:12,160
change the delivery commitment, or accept the consequence.

1093
00:47:12,160 --> 00:47:14,960
The system doesn't create capacity through optimistic dates.

1094
00:47:14,960 --> 00:47:16,720
Now, there are different ways to place work

1095
00:47:16,720 --> 00:47:17,960
in a finite schedule.

1096
00:47:17,960 --> 00:47:20,520
Forward scheduling starts from a known point.

1097
00:47:20,520 --> 00:47:22,600
The moment material becomes usable,

1098
00:47:22,600 --> 00:47:24,160
the end of a prior operation,

1099
00:47:24,160 --> 00:47:26,520
or the start of the planning horizon.

1100
00:47:26,520 --> 00:47:28,240
The schedule moves forward through the routing

1101
00:47:28,240 --> 00:47:30,880
and places each operation into the first suitable slots

1102
00:47:30,880 --> 00:47:31,880
it can find.

1103
00:47:31,880 --> 00:47:33,760
This works well when you want a practical answer

1104
00:47:33,760 --> 00:47:35,000
to a direct question.

1105
00:47:35,000 --> 00:47:37,480
Given what's ready now, when can we realistically finish

1106
00:47:37,480 --> 00:47:38,320
this work?

1107
00:47:38,320 --> 00:47:41,280
Backward scheduling starts from a due date and works in reverse.

1108
00:47:41,280 --> 00:47:43,640
It asks when the final operation must end,

1109
00:47:43,640 --> 00:47:45,680
then searches backward for legal resource time

1110
00:47:45,680 --> 00:47:47,440
for each earlier operation.

1111
00:47:47,440 --> 00:47:49,840
When capacity exists, the schedule protects the promise

1112
00:47:49,840 --> 00:47:52,320
while avoiding work that starts earlier than needed.

1113
00:47:52,320 --> 00:47:55,880
But backward scheduling gets honest in a finite model.

1114
00:47:55,880 --> 00:47:57,760
If the necessary time no longer exists

1115
00:47:57,760 --> 00:48:00,200
before the due date, the schedule can't just keep assigning

1116
00:48:00,200 --> 00:48:03,360
earlier dates and hope the shop floor absorbs the overload,

1117
00:48:03,360 --> 00:48:04,800
it identifies the conflict.

1118
00:48:04,800 --> 00:48:07,080
Many factories end up using a hybrid approach.

1119
00:48:07,080 --> 00:48:08,760
Near-term work may schedule forward

1120
00:48:08,760 --> 00:48:10,080
from actual shop floor status

1121
00:48:10,080 --> 00:48:12,040
because execution has already started

1122
00:48:12,040 --> 00:48:15,400
and physical conditions control the next steps.

1123
00:48:15,400 --> 00:48:17,120
Further out, the plan may work backward

1124
00:48:17,120 --> 00:48:19,600
from delivery promises, then test those promises

1125
00:48:19,600 --> 00:48:21,640
against available finite capacity,

1126
00:48:21,640 --> 00:48:23,600
the exact split depends on the process,

1127
00:48:23,600 --> 00:48:25,240
but the point stays the same.

1128
00:48:25,240 --> 00:48:27,840
The schedule works from real boundaries, not dates alone.

1129
00:48:27,840 --> 00:48:29,960
This doesn't mean the schedule becomes fixed forever.

1130
00:48:29,960 --> 00:48:31,920
It can change when a confirmed production event

1131
00:48:31,920 --> 00:48:33,680
changes the available options.

1132
00:48:33,680 --> 00:48:35,760
But every change needs to fit within the same

1133
00:48:35,760 --> 00:48:38,000
finite model of resources in time.

1134
00:48:38,000 --> 00:48:40,360
So finite scheduling gives you a feasible plan,

1135
00:48:40,360 --> 00:48:42,520
a working plan, not a dated wish list.

1136
00:48:42,520 --> 00:48:45,600
Still, feasibility alone doesn't choose the best answer.

1137
00:48:45,600 --> 00:48:47,480
Once several legal schedules exist,

1138
00:48:47,480 --> 00:48:49,480
the harder question becomes which one the factory

1139
00:48:49,480 --> 00:48:50,760
should actually pick.

1140
00:48:50,760 --> 00:48:52,520
Constraint-based optimization.

1141
00:48:52,520 --> 00:48:54,800
So you've got a few workable schedules on the table

1142
00:48:54,800 --> 00:48:57,160
and the scheduling engine now has choices to make.

1143
00:48:57,160 --> 00:48:59,760
Constraint-based optimization is how it searches

1144
00:48:59,760 --> 00:49:02,040
through those choices while obeying the rules

1145
00:49:02,040 --> 00:49:03,320
production cannot break.

1146
00:49:03,320 --> 00:49:05,920
This search isn't about finding a need order list.

1147
00:49:05,920 --> 00:49:07,080
It's searching for a schedule

1148
00:49:07,080 --> 00:49:09,320
where each decision ripples into the next one

1149
00:49:09,320 --> 00:49:12,440
because moving one job shifts machine time, setup time,

1150
00:49:12,440 --> 00:49:15,600
material timing, and the finished dates of several other orders.

1151
00:49:15,600 --> 00:49:18,360
Think about the decisions inside a normal planning day.

1152
00:49:18,360 --> 00:49:20,200
You decide which job runs first,

1153
00:49:20,200 --> 00:49:23,360
which eligible machine should process it, when it starts,

1154
00:49:23,360 --> 00:49:25,440
and whether the order can split into smaller lots

1155
00:49:25,440 --> 00:49:28,800
or must stay together until the operation finishes.

1156
00:49:28,800 --> 00:49:30,440
Those are your decision variables.

1157
00:49:30,440 --> 00:49:33,040
The parts of the schedule, the optimizer can change.

1158
00:49:33,040 --> 00:49:36,120
In a simple factory, sequence might be the biggest choice.

1159
00:49:36,120 --> 00:49:39,560
Put job A before job B and the next setup takes 10 minutes.

1160
00:49:39,560 --> 00:49:41,160
Reverse that and it could take an hour

1161
00:49:41,160 --> 00:49:42,520
or it might force a cleaning step.

1162
00:49:42,520 --> 00:49:44,880
In a more flexible plan, resource choice matters too.

1163
00:49:44,880 --> 00:49:47,080
One operation might run on either of two machines,

1164
00:49:47,080 --> 00:49:49,440
but one runs faster while the other protects capacity

1165
00:49:49,440 --> 00:49:51,120
for an order with no alternative.

1166
00:49:51,120 --> 00:49:53,360
Start time matters for the same reason.

1167
00:49:53,360 --> 00:49:56,280
An order could begin as soon as it's ready or it could wait.

1168
00:49:56,280 --> 00:49:58,840
Starting it later protects a more urgent job,

1169
00:49:58,840 --> 00:50:01,480
avoids a conflict or keeps related work together.

1170
00:50:01,480 --> 00:50:04,520
Lots splitting adds another decision where the process allows it.

1171
00:50:04,520 --> 00:50:06,720
A large production order can move through in smaller batches,

1172
00:50:06,720 --> 00:50:08,680
which helps a downstream operation start earlier,

1173
00:50:08,680 --> 00:50:10,320
but also creates more handling, more checks,

1174
00:50:10,320 --> 00:50:11,440
and more complexity.

1175
00:50:11,440 --> 00:50:14,320
The optimizer needs boundaries before it can make those choices.

1176
00:50:14,320 --> 00:50:17,040
Some rules are hard constraints that the schedule must obey.

1177
00:50:17,040 --> 00:50:19,440
A job may only run on approved resources.

1178
00:50:19,440 --> 00:50:21,720
A heat cycle must finish before inspection begins.

1179
00:50:21,720 --> 00:50:24,280
A tool cannot support two operations at once.

1180
00:50:24,280 --> 00:50:26,840
A regulated product requires a qualified operator.

1181
00:50:26,840 --> 00:50:28,360
If the schedule breaks one of those rules,

1182
00:50:28,360 --> 00:50:29,520
it's not a clever solution.

1183
00:50:29,520 --> 00:50:30,520
It's simply wrong.

1184
00:50:30,520 --> 00:50:32,080
Other rules are preferences.

1185
00:50:32,080 --> 00:50:34,760
You might prefer to keep jobs from the same family together.

1186
00:50:34,760 --> 00:50:37,520
You might want to minimize late orders, avoid overtime,

1187
00:50:37,520 --> 00:50:39,880
keep work moving, or avoid changing instructions

1188
00:50:39,880 --> 00:50:41,520
already issued to the shop floor.

1189
00:50:41,520 --> 00:50:42,800
Those preferences can conflict,

1190
00:50:42,800 --> 00:50:44,560
so the model applies penalties.

1191
00:50:44,560 --> 00:50:47,160
A late customer order might carry a high penalty.

1192
00:50:47,160 --> 00:50:49,520
An extra setup might carry a smaller one.

1193
00:50:49,520 --> 00:50:51,800
Moving a job inside the near term planning window

1194
00:50:51,800 --> 00:50:54,480
might carry another because change creates work for people.

1195
00:50:54,480 --> 00:50:56,080
The exact values aren't universal.

1196
00:50:56,080 --> 00:50:58,760
They express how your plan chooses between imperfect options

1197
00:50:58,760 --> 00:51:01,320
when capacity cannot satisfy every requested ones.

1198
00:51:01,320 --> 00:51:03,440
This is what people mean by an objective function,

1199
00:51:03,440 --> 00:51:05,840
though the phrase sounds more mysterious than it needs to.

1200
00:51:05,840 --> 00:51:07,680
An objective function is the scoring rules

1201
00:51:07,680 --> 00:51:10,440
the optimizer uses to compare legal schedules.

1202
00:51:10,440 --> 00:51:12,000
It converts production priorities

1203
00:51:12,000 --> 00:51:14,880
into a form the scheduling engine can evaluate.

1204
00:51:14,880 --> 00:51:16,560
One schedule might protect more due dates,

1205
00:51:16,560 --> 00:51:18,000
but create extra setups.

1206
00:51:18,000 --> 00:51:19,560
Another might run cleaner campaigns,

1207
00:51:19,560 --> 00:51:22,080
but delay and order the business considers urgent.

1208
00:51:22,080 --> 00:51:23,920
The score helps the engine compare those outcomes

1209
00:51:23,920 --> 00:51:26,560
using rules that planning and operations have agreed on.

1210
00:51:26,560 --> 00:51:28,400
You don't need to pretend the score captures

1211
00:51:28,400 --> 00:51:29,760
every human concern.

1212
00:51:29,760 --> 00:51:31,920
It won't, but it does mean the same conditions

1213
00:51:31,920 --> 00:51:33,560
lead to a repeatable planning process

1214
00:51:33,560 --> 00:51:35,360
rather than a different answer, depending

1215
00:51:35,360 --> 00:51:36,640
on who works that shift.

1216
00:51:36,640 --> 00:51:39,320
And when someone asks why the schedule selected one order

1217
00:51:39,320 --> 00:51:41,360
before another, the planner has a basis

1218
00:51:41,360 --> 00:51:42,240
for the answer.

1219
00:51:42,240 --> 00:51:44,960
This job protected a higher priority commitment,

1220
00:51:44,960 --> 00:51:46,920
avoided an illegal resource conflict,

1221
00:51:46,920 --> 00:51:49,320
or prevented a costly sequence change.

1222
00:51:49,320 --> 00:51:51,240
Planner judgment still belongs in the process.

1223
00:51:51,240 --> 00:51:54,640
A planner might know a customer can accept a one-day change,

1224
00:51:54,640 --> 00:51:57,200
even though the system treats the due date as firm,

1225
00:51:57,200 --> 00:51:58,840
they might know a maintenance team expects

1226
00:51:58,840 --> 00:52:01,080
to release a machine earlier than planned,

1227
00:52:01,080 --> 00:52:02,440
but hasn't confirmed it yet.

1228
00:52:02,440 --> 00:52:04,800
They might see a commercial reason to make an exception,

1229
00:52:04,800 --> 00:52:06,600
the model cannot infer on its own.

1230
00:52:06,600 --> 00:52:09,000
The point isn't to hand control to a solver and walk away.

1231
00:52:09,000 --> 00:52:10,720
The point is to give the planner a schedule

1232
00:52:10,720 --> 00:52:13,120
build from explicit rules, then let them review

1233
00:52:13,120 --> 00:52:16,080
and approve exceptions with the consequences visible.

1234
00:52:16,080 --> 00:52:17,480
That also makes improvement possible.

1235
00:52:17,480 --> 00:52:19,440
If planners override the same rule every week,

1236
00:52:19,440 --> 00:52:21,600
the team can ask whether the rule needs adjustment,

1237
00:52:21,600 --> 00:52:23,040
whether the master data is wrong,

1238
00:52:23,040 --> 00:52:25,960
or whether the factory has a condition nobody has modeled.

1239
00:52:25,960 --> 00:52:27,600
Let's return to that shared machining center

1240
00:52:27,600 --> 00:52:30,040
and see how this approach handles competing orders

1241
00:52:30,040 --> 00:52:31,800
when the schedule has to choose.

1242
00:52:31,800 --> 00:52:33,840
Replanning the same factory scenario.

1243
00:52:33,840 --> 00:52:35,160
Let's go back to the pump factory.

1244
00:52:35,160 --> 00:52:37,440
This time, the machining center has a finite plan

1245
00:52:37,440 --> 00:52:39,840
rather than a stack of overlapping dates.

1246
00:52:39,840 --> 00:52:41,320
Three orders need that same resource.

1247
00:52:41,320 --> 00:52:43,160
Order alpha has a customer due date tomorrow.

1248
00:52:43,160 --> 00:52:44,920
Order bravo ships two days later.

1249
00:52:44,920 --> 00:52:46,440
Order Charlie has more time,

1250
00:52:46,440 --> 00:52:48,920
but it belongs to the same product family as alpha.

1251
00:52:48,920 --> 00:52:50,440
So running those two together avoids

1252
00:52:50,440 --> 00:52:52,080
a long tool and fixture change.

1253
00:52:52,080 --> 00:52:53,800
There's also work already in progress.

1254
00:52:53,800 --> 00:52:55,160
The machine is halfway through a job

1255
00:52:55,160 --> 00:52:57,760
that cannot be interrupted without creating scrap risk

1256
00:52:57,760 --> 00:52:59,040
and extra inspection.

1257
00:52:59,040 --> 00:53:00,000
That job is locked.

1258
00:53:00,000 --> 00:53:02,080
The scheduling engine doesn't treat it as a free slot

1259
00:53:02,080 --> 00:53:04,800
just because a higher priority order appears in the order list.

1260
00:53:04,800 --> 00:53:06,680
That's how a real schedule begins

1261
00:53:06,680 --> 00:53:08,680
with what the factory can still change.

1262
00:53:08,680 --> 00:53:10,080
Now add two more conditions.

1263
00:53:10,080 --> 00:53:12,160
Material for alpha arrives this afternoon

1264
00:53:12,160 --> 00:53:14,960
and incoming inspection has confirmed the delivery time.

1265
00:53:14,960 --> 00:53:16,840
The machining center also has planned maintenance

1266
00:53:16,840 --> 00:53:17,800
tomorrow morning.

1267
00:53:17,800 --> 00:53:20,280
Maintenance needs the machine for a defined window

1268
00:53:20,280 --> 00:53:23,040
so that time disappears from available capacity.

1269
00:53:23,040 --> 00:53:24,960
A normal date calculation might still place

1270
00:53:24,960 --> 00:53:27,040
all three jobs before their customer dates,

1271
00:53:27,040 --> 00:53:29,000
but the finite model sees the actual problem.

1272
00:53:29,000 --> 00:53:31,640
There are fewer available hours than the orders need

1273
00:53:31,640 --> 00:53:33,200
and the sequence between those orders

1274
00:53:33,200 --> 00:53:36,480
changes how many of those hours remain for machining.

1275
00:53:36,480 --> 00:53:38,680
Suppose the current job belongs to Family A.

1276
00:53:38,680 --> 00:53:40,120
Alpha also belongs to Family A.

1277
00:53:40,120 --> 00:53:41,520
Bravo belongs to Family B.

1278
00:53:41,520 --> 00:53:44,040
Moving from A to B needs a full fixture change,

1279
00:53:44,040 --> 00:53:46,040
a tool swap and first piece approval.

1280
00:53:46,040 --> 00:53:47,640
Charlie belongs to Family A as well.

1281
00:53:47,640 --> 00:53:49,480
The schedule can use a sequence set up matrix.

1282
00:53:49,480 --> 00:53:52,120
That sounds technical, but it's just a table of transition rules.

1283
00:53:52,120 --> 00:53:54,880
It records how long it takes and what conditions apply

1284
00:53:54,880 --> 00:53:56,760
when one product family follows another.

1285
00:53:56,760 --> 00:54:00,080
Within Family A, the next set up might take a few minutes.

1286
00:54:00,080 --> 00:54:02,920
From Family A to Family B, the plant needs a much longer change.

1287
00:54:02,920 --> 00:54:06,120
From Family B back to Family A, it might need another one.

1288
00:54:06,120 --> 00:54:07,600
The direction matters because a machine

1289
00:54:07,600 --> 00:54:09,600
doesn't begin the day in a neutral state.

1290
00:54:09,600 --> 00:54:11,680
It begins from the state left by the previous job.

1291
00:54:11,680 --> 00:54:13,160
So the engine test possible sequences,

1292
00:54:13,160 --> 00:54:15,560
it could run Alpha next, then Charlie, then Bravo.

1293
00:54:15,560 --> 00:54:18,120
That protects Alpha's due date, groups the Family A work,

1294
00:54:18,120 --> 00:54:20,560
and delays the expensive change over until later.

1295
00:54:20,560 --> 00:54:22,400
But because maintenance removes capacity

1296
00:54:22,400 --> 00:54:24,960
tomorrow morning, Bravo may no longer finish in time.

1297
00:54:24,960 --> 00:54:27,160
It could run Alpha then Bravo then Charlie.

1298
00:54:27,160 --> 00:54:29,800
Bravo receives more protection, but the plant pays for an extra change

1299
00:54:29,800 --> 00:54:31,120
back into Family A.

1300
00:54:31,120 --> 00:54:33,800
Charlie then moves later and the bottleneck loses time

1301
00:54:33,800 --> 00:54:35,440
that could have gone into productive work.

1302
00:54:35,440 --> 00:54:37,600
And there may be another option, Charlie might qualify

1303
00:54:37,600 --> 00:54:39,720
for an alternative machine, not because every machine

1304
00:54:39,720 --> 00:54:41,720
can run every part, but because engineering

1305
00:54:41,720 --> 00:54:44,480
has approved a second routing under defined conditions.

1306
00:54:44,480 --> 00:54:46,080
That alternative machine runs slower,

1307
00:54:46,080 --> 00:54:48,080
and it may require a different fixture.

1308
00:54:48,080 --> 00:54:50,520
Still, if the fixture and operator support are available,

1309
00:54:50,520 --> 00:54:52,240
moving Charlie there could free the constraint

1310
00:54:52,240 --> 00:54:53,960
machining center for Alpha and Bravo.

1311
00:54:53,960 --> 00:54:55,360
That's a real trade off.

1312
00:54:55,360 --> 00:54:57,480
The schedule doesn't pretend the alternative machine

1313
00:54:57,480 --> 00:54:58,520
is identical.

1314
00:54:58,520 --> 00:55:01,600
It includes the longer processing time, the eligible routing,

1315
00:55:01,600 --> 00:55:03,440
and the fact that using that resource

1316
00:55:03,440 --> 00:55:05,960
might affect other work, it compares that cost

1317
00:55:05,960 --> 00:55:07,560
with the consequence of leaving Charlie

1318
00:55:07,560 --> 00:55:09,160
on the main machining center.

1319
00:55:09,160 --> 00:55:12,280
In one feasible answer, Alpha runs directly after the locked work.

1320
00:55:12,280 --> 00:55:14,120
Charlie moves to the alternative machine.

1321
00:55:14,120 --> 00:55:15,840
Bravo stays on the main machining center

1322
00:55:15,840 --> 00:55:17,480
after the plant maintenance window

1323
00:55:17,480 --> 00:55:19,760
with the family be setup performed once at a time

1324
00:55:19,760 --> 00:55:21,600
that doesn't interrupt the earlier work.

1325
00:55:21,600 --> 00:55:23,800
One order moves, but the move has a reason.

1326
00:55:23,800 --> 00:55:25,320
The plan I can see that Charlie moved

1327
00:55:25,320 --> 00:55:27,320
because it's due date carried less risk,

1328
00:55:27,320 --> 00:55:28,880
it had an approved alternative route

1329
00:55:28,880 --> 00:55:30,920
and keeping it on the bottleneck would force either

1330
00:55:30,920 --> 00:55:33,120
a late Bravo order or an extra setup

1331
00:55:33,120 --> 00:55:35,600
that consumed capacity the plant didn't have.

1332
00:55:35,600 --> 00:55:38,360
That explanation matters as much as the proposed sequence.

1333
00:55:38,360 --> 00:55:40,440
Without it, production sees another order

1334
00:55:40,440 --> 00:55:41,960
changed by software.

1335
00:55:41,960 --> 00:55:44,120
With it, the team sees a decision.

1336
00:55:44,120 --> 00:55:46,040
Protect the orders without alternatives,

1337
00:55:46,040 --> 00:55:48,200
use qualified flexibility where it exists

1338
00:55:48,200 --> 00:55:51,040
and spend bottleneck time where it has the most effect.

1339
00:55:51,040 --> 00:55:52,840
The planner may still reject the result.

1340
00:55:52,840 --> 00:55:54,800
Perhaps the alternative machine has an issue nobody

1341
00:55:54,800 --> 00:55:56,200
has confirmed in the system.

1342
00:55:56,200 --> 00:55:57,720
Perhaps the customer behind Charlie

1343
00:55:57,720 --> 00:56:00,600
cannot accept movement despite the recorded date.

1344
00:56:00,600 --> 00:56:01,520
That's fine.

1345
00:56:01,520 --> 00:56:03,520
The plan gives the planner a visible choice

1346
00:56:03,520 --> 00:56:06,400
and visible consequences rather than hiding the conflict

1347
00:56:06,400 --> 00:56:07,520
in a date list.

1348
00:56:07,520 --> 00:56:09,480
But the quality of that choice depends entirely

1349
00:56:09,480 --> 00:56:10,560
on the facts behind it.

1350
00:56:10,560 --> 00:56:12,440
The schedule can only respect the machine,

1351
00:56:12,440 --> 00:56:14,240
rooting, material and setup rules

1352
00:56:14,240 --> 00:56:15,640
that the factory has described.

1353
00:56:15,640 --> 00:56:17,960
The data model behind a schedule you can trust.

1354
00:56:17,960 --> 00:56:20,120
Here's the problem with most production schedules.

1355
00:56:20,120 --> 00:56:22,320
They only know the version of the factory you give them.

1356
00:56:22,320 --> 00:56:24,760
If the model treats every order as just a date,

1357
00:56:24,760 --> 00:56:26,480
every machine as a generic work center

1358
00:56:26,480 --> 00:56:28,400
and every material as an available quantity

1359
00:56:28,400 --> 00:56:30,960
that's exactly what it'll output just formatted nicely,

1360
00:56:30,960 --> 00:56:33,080
that's where the data model starts, not where it ends.

1361
00:56:33,080 --> 00:56:35,000
Think about what a planner actually pulls together

1362
00:56:35,000 --> 00:56:36,240
before a tough call.

1363
00:56:36,240 --> 00:56:38,320
You've got products with their own specs, processes

1364
00:56:38,320 --> 00:56:40,720
that describe the operations needed and resources

1365
00:56:40,720 --> 00:56:43,480
like machines, work areas, test equipment and people.

1366
00:56:43,480 --> 00:56:46,760
Then, layer in orders, materials, tools, skills and calendars.

1367
00:56:46,760 --> 00:56:48,520
All of that has to come together.

1368
00:56:48,520 --> 00:56:50,280
None of those things mean much on their own.

1369
00:56:50,280 --> 00:56:52,240
A product record tells you what you sell,

1370
00:56:52,240 --> 00:56:53,800
a routing names and operation,

1371
00:56:53,800 --> 00:56:55,120
but they don't connect the dots

1372
00:56:55,120 --> 00:56:56,800
between what you have and what you need.

1373
00:56:56,800 --> 00:57:00,000
A working schedule needs the relationships between those things.

1374
00:57:00,000 --> 00:57:01,800
Which process applies to which product,

1375
00:57:01,800 --> 00:57:04,240
which resource can actually perform that process

1376
00:57:04,240 --> 00:57:05,440
and under what conditions.

1377
00:57:05,440 --> 00:57:07,320
That's the product process resource relationship

1378
00:57:07,320 --> 00:57:09,360
and it's the foundation everything else sits on,

1379
00:57:09,360 --> 00:57:10,880
take a machine pump housing.

1380
00:57:10,880 --> 00:57:12,600
The model should connect that housing

1381
00:57:12,600 --> 00:57:14,440
to its specific machining operation,

1382
00:57:14,440 --> 00:57:16,760
which connects to the machines approved for running it

1383
00:57:16,760 --> 00:57:19,200
and each machine should then connect to the fixture,

1384
00:57:19,200 --> 00:57:21,520
tool set, program inspection requirement

1385
00:57:21,520 --> 00:57:23,800
and operator skill that the job actually needs.

1386
00:57:23,800 --> 00:57:27,320
Now, the schedule has something useful to test against.

1387
00:57:27,320 --> 00:57:30,920
It can ask whether machine one can technically run the part,

1388
00:57:30,920 --> 00:57:32,360
handle the current material grade,

1389
00:57:32,360 --> 00:57:33,800
whether the fixture is free

1390
00:57:33,800 --> 00:57:36,160
and whether the right person is available during that slot.

1391
00:57:36,160 --> 00:57:37,960
That's a lot more useful than assigning work

1392
00:57:37,960 --> 00:57:39,400
to a generic machining center

1393
00:57:39,400 --> 00:57:41,920
and hoping someone sorts it out when the shift starts.

1394
00:57:41,920 --> 00:57:44,440
Now, here's where resource capability needs detail,

1395
00:57:44,440 --> 00:57:45,680
but not fantasy.

1396
00:57:45,680 --> 00:57:47,960
A machine might process several product families

1397
00:57:47,960 --> 00:57:50,920
but only up to a certain size or tolerance.

1398
00:57:50,920 --> 00:57:53,040
Another resource could handle the same operation

1399
00:57:53,040 --> 00:57:55,880
but at a slower rate or with different quality rules.

1400
00:57:55,880 --> 00:57:57,640
A tool might fit several machines

1401
00:57:57,640 --> 00:57:59,920
while a specialist fixture only fits one.

1402
00:57:59,920 --> 00:58:01,400
These are eligibility rules.

1403
00:58:01,400 --> 00:58:03,440
They define what the schedule can actually choose,

1404
00:58:03,440 --> 00:58:06,200
they also stop false flexibility from creeping in.

1405
00:58:06,200 --> 00:58:08,280
A generic planning record might treat five machines

1406
00:58:08,280 --> 00:58:09,720
as interchangeable just because they sit

1407
00:58:09,720 --> 00:58:12,320
in the same department but production knows better.

1408
00:58:12,320 --> 00:58:13,760
One has the right spindle speed

1409
00:58:13,760 --> 00:58:16,080
and another has a program that still needs approval

1410
00:58:16,080 --> 00:58:17,880
and a third is reserved for a product

1411
00:58:17,880 --> 00:58:19,480
with no alternative route.

1412
00:58:19,480 --> 00:58:21,840
If those differences stay outside the model,

1413
00:58:21,840 --> 00:58:24,520
the scheduler creates choices that look sensible on paper

1414
00:58:24,520 --> 00:58:26,080
until the shift actually starts.

1415
00:58:26,080 --> 00:58:27,680
Sequence needs its own data too

1416
00:58:27,680 --> 00:58:29,600
and this is where most models fall short.

1417
00:58:29,600 --> 00:58:31,360
The system should describe setup families

1418
00:58:31,360 --> 00:58:33,520
not just setup time as one fixed number.

1419
00:58:33,520 --> 00:58:35,720
A job might follow another with almost no change

1420
00:58:35,720 --> 00:58:38,320
if both use the same material, tool state or coating

1421
00:58:38,320 --> 00:58:40,680
but a different transition could require cleaning,

1422
00:58:40,680 --> 00:58:42,480
fixture replacement, warm up

1423
00:58:42,480 --> 00:58:45,240
and a first piece check before it's ready to go.

1424
00:58:45,240 --> 00:58:47,080
Batch size also changes the plan in ways

1425
00:58:47,080 --> 00:58:48,680
the model needs to understand.

1426
00:58:48,680 --> 00:58:50,880
Some work can move in small transfer batches

1427
00:58:50,880 --> 00:58:52,320
while other work has to stay together

1428
00:58:52,320 --> 00:58:54,320
for traceability, quality, heat treatment

1429
00:58:54,320 --> 00:58:55,960
or just practical handling.

1430
00:58:55,960 --> 00:58:57,640
A campaign might need a minimum run length

1431
00:58:57,640 --> 00:58:59,960
before a costly cleanout makes financial sense

1432
00:58:59,960 --> 00:59:01,920
but a customer priority can sometimes justify

1433
00:59:01,920 --> 00:59:03,280
breaking that campaign.

1434
00:59:03,280 --> 00:59:05,720
Those rules belong where the schedule can use them.

1435
00:59:05,720 --> 00:59:07,560
Not just in someone's memory or on a sticky note

1436
00:59:07,560 --> 00:59:08,880
taped to the planning board.

1437
00:59:08,880 --> 00:59:10,600
Calendar's matter for the same reason.

1438
00:59:10,600 --> 00:59:12,840
A calendar does more than show whether a plant works

1439
00:59:12,840 --> 00:59:14,120
Monday through Friday.

1440
00:59:14,120 --> 00:59:16,600
It can describe a machine's maintenance time,

1441
00:59:16,600 --> 00:59:18,640
an operator groups shift pattern,

1442
00:59:18,640 --> 00:59:22,120
a two rooms availability or a planned engineering trial

1443
00:59:22,120 --> 00:59:24,840
that takes a resource out of normal production.

1444
00:59:24,840 --> 00:59:26,160
That brings us to the real challenge,

1445
00:59:26,160 --> 00:59:28,640
no single team owns all of this data.

1446
00:59:28,640 --> 00:59:31,080
Engineering owns product and process definitions.

1447
00:59:31,080 --> 00:59:33,360
Planning owns order priorities, planning horizons

1448
00:59:33,360 --> 00:59:36,640
and dispatch rules, maintenance owns planned availability,

1449
00:59:36,640 --> 00:59:38,880
production knows the practical capability limits

1450
00:59:38,880 --> 00:59:40,680
and changing shop floor conditions.

1451
00:59:40,680 --> 00:59:42,560
Quality controls approve rules that decide

1452
00:59:42,560 --> 00:59:45,520
whether a material, route or resource remains eligible.

1453
00:59:45,520 --> 00:59:47,400
That split is completely normal

1454
00:59:47,400 --> 00:59:50,800
but the problem starts when nobody agrees who changes what

1455
00:59:50,800 --> 00:59:52,440
when the change becomes effective

1456
00:59:52,440 --> 00:59:55,360
and which system is the trusted source for that fact.

1457
00:59:55,360 --> 00:59:57,000
A finite schedule doesn't need perfect data

1458
00:59:57,000 --> 00:59:58,520
but every corner of the plant.

1459
00:59:58,520 --> 01:00:00,280
It needs trusted data about the conditions

1460
01:00:00,280 --> 01:00:02,440
that drive the decisions you're trying to improve.

1461
01:00:02,440 --> 01:00:05,040
So start with the resource where conflicts keep appearing

1462
01:00:05,040 --> 01:00:07,960
then model the products, processes, capabilities, setups

1463
01:00:07,960 --> 01:00:10,280
and calendars that shape those conflicts.

1464
01:00:10,280 --> 01:00:12,400
That sounds manageable and honestly it often is

1465
01:00:12,400 --> 01:00:14,720
once you start with what's actually causing the pain

1466
01:00:14,720 --> 01:00:17,280
but this is also where many APS projects run into trouble

1467
01:00:17,280 --> 01:00:20,600
long before the optimizer even receives its first schedule.

1468
01:00:20,600 --> 01:00:23,600
Why APS projects fail before the optimizer runs?

1469
01:00:23,600 --> 01:00:26,280
Most APS projects don't fail because the optimizer

1470
01:00:26,280 --> 01:00:27,720
can't solve the problem.

1471
01:00:27,720 --> 01:00:30,120
They fail because the model gets a sketch of the factory

1472
01:00:30,120 --> 01:00:33,400
that nobody would trust at 7am on a Monday morning.

1473
01:00:33,400 --> 01:00:36,080
The software can only work with the data it receives.

1474
01:00:36,080 --> 01:00:39,280
If rooting times describe an ideal process from three years ago

1475
01:00:39,280 --> 01:00:41,280
generic work centers hide real differences

1476
01:00:41,280 --> 01:00:44,000
between machines and calendars still show capacity

1477
01:00:44,000 --> 01:00:45,560
during planned maintenance.

1478
01:00:45,560 --> 01:00:47,480
The resulting schedule looks precise

1479
01:00:47,480 --> 01:00:49,560
but sends people in the wrong direction.

1480
01:00:49,560 --> 01:00:51,320
That creates a trust problem fast

1481
01:00:51,320 --> 01:00:53,440
and trust is hard to rebuild once it's gone.

1482
01:00:53,440 --> 01:00:55,680
A rooting might say an operation takes two hours

1483
01:00:55,680 --> 01:00:57,560
but excludes setup, inspection, loading

1484
01:00:57,560 --> 01:00:59,720
or normal delays everyone already knows about.

1485
01:00:59,720 --> 01:01:02,640
The planning team might use one work center called machining

1486
01:01:02,640 --> 01:01:04,720
for six machines even though only two

1487
01:01:04,720 --> 01:01:06,280
can produce a certain product family

1488
01:01:06,280 --> 01:01:08,240
and one of those two regularly runs

1489
01:01:08,240 --> 01:01:09,960
a controlled customer order.

1490
01:01:09,960 --> 01:01:12,640
The model sees six choices but productions sees two

1491
01:01:12,640 --> 01:01:15,400
and sometimes only one when you factor in everything else.

1492
01:01:15,400 --> 01:01:17,080
Outdated calendars cause the same damage

1493
01:01:17,080 --> 01:01:18,320
and they're harder to spot.

1494
01:01:18,320 --> 01:01:20,080
A planning calendar can show a full shift

1495
01:01:20,080 --> 01:01:22,120
while the machine is scheduled for maintenance

1496
01:01:22,120 --> 01:01:23,520
the operator group is short staffed

1497
01:01:23,520 --> 01:01:25,880
or a tool room shutdown blocks preparation work.

1498
01:01:25,880 --> 01:01:28,680
None of this means the master data team did a bad job.

1499
01:01:28,680 --> 01:01:31,120
It usually means facts change in different parts

1500
01:01:31,120 --> 01:01:33,280
of the business while the planning model

1501
01:01:33,280 --> 01:01:36,560
receives updates too late or not at all.

1502
01:01:36,560 --> 01:01:38,480
Then there's the knowledge that lives in the planners head

1503
01:01:38,480 --> 01:01:40,600
and this is where most systems break down.

1504
01:01:40,600 --> 01:01:42,320
Experience planners know which machine

1505
01:01:42,320 --> 01:01:44,040
struggles with a certain alloy

1506
01:01:44,040 --> 01:01:46,440
which tool tends to fail after a long batch

1507
01:01:46,440 --> 01:01:50,360
and which root works only when a particular operator is present.

1508
01:01:50,360 --> 01:01:52,600
They might also know that a nominally approved alternative

1509
01:01:52,600 --> 01:01:54,560
machine creates so much rework

1510
01:01:54,560 --> 01:01:57,560
that it should only be used in a true delivery emergency.

1511
01:01:57,560 --> 01:01:59,280
If that knowledge never enters the model

1512
01:01:59,280 --> 01:02:02,880
the APS system would suggest plans that break practical rules.

1513
01:02:02,880 --> 01:02:04,280
After a few bad recommendations

1514
01:02:04,280 --> 01:02:05,600
people stop opening it entirely

1515
01:02:05,600 --> 01:02:06,640
and go back to the spreadsheet

1516
01:02:06,640 --> 01:02:08,880
because the spreadsheet at least contains the notes

1517
01:02:08,880 --> 01:02:10,440
that keep the factory moving.

1518
01:02:10,440 --> 01:02:12,120
You don't solve that by asking planners

1519
01:02:12,120 --> 01:02:14,480
to dump every thought they have into a system

1520
01:02:14,480 --> 01:02:16,000
that approach never works.

1521
01:02:16,000 --> 01:02:17,720
Some rules are stable enough to model

1522
01:02:17,720 --> 01:02:19,720
while others depend on a temporary condition,

1523
01:02:19,720 --> 01:02:21,280
commercial judgment or information

1524
01:02:21,280 --> 01:02:23,000
that hasn't reached a formal system yet.

1525
01:02:23,000 --> 01:02:25,320
The real job is identifying the repeatable rules

1526
01:02:25,320 --> 01:02:26,960
that shape most decisions

1527
01:02:26,960 --> 01:02:28,440
then giving the planner a clean way

1528
01:02:28,440 --> 01:02:30,720
to handle exceptions when they come up.

1529
01:02:30,720 --> 01:02:32,640
Data ownership often causes more trouble

1530
01:02:32,640 --> 01:02:34,680
than the solver itself and here's why.

1531
01:02:34,680 --> 01:02:35,720
You need clear answers.

1532
01:02:35,720 --> 01:02:37,040
Who owns order status?

1533
01:02:37,040 --> 01:02:38,160
Which system tells planning

1534
01:02:38,160 --> 01:02:40,160
that an operation has started or completed?

1535
01:02:40,160 --> 01:02:41,720
Who owns the machine calendar?

1536
01:02:41,720 --> 01:02:44,920
And where does an approved routing change actually begin?

1537
01:02:44,920 --> 01:02:46,880
If each system holds its own version

1538
01:02:46,880 --> 01:02:48,200
the schedule calculates against

1539
01:02:48,200 --> 01:02:50,520
stale or conflicting information every time.

1540
01:02:50,520 --> 01:02:52,680
You need a clear answer for each planning fact

1541
01:02:52,680 --> 01:02:54,680
where it's created, who can change it

1542
01:02:54,680 --> 01:02:57,040
and which source the scheduling process trusts

1543
01:02:57,040 --> 01:02:58,840
that doesn't require one giant database

1544
01:02:58,840 --> 01:03:00,720
just agreed responsibility and integration

1545
01:03:00,720 --> 01:03:02,480
that actually works end to end.

1546
01:03:02,480 --> 01:03:05,200
Another common mistake comes from good intentions.

1547
01:03:05,200 --> 01:03:07,680
The project team tries to capture every exception

1548
01:03:07,680 --> 01:03:10,280
before anyone has scheduled a single day of work.

1549
01:03:10,280 --> 01:03:11,760
They model rare quality rules

1550
01:03:11,760 --> 01:03:13,360
every possible alternate route

1551
01:03:13,360 --> 01:03:15,640
unusual custom instructions, temporary layouts

1552
01:03:15,640 --> 01:03:16,880
and years of local habits.

1553
01:03:16,880 --> 01:03:19,720
The scope expands, the model becomes difficult to test

1554
01:03:19,720 --> 01:03:22,280
and maintain and meanwhile the daily conflict

1555
01:03:22,280 --> 01:03:25,120
that started the project remains completely unsolved.

1556
01:03:25,120 --> 01:03:28,040
So start where the pain is visible, pick a known bottleneck.

1557
01:03:28,040 --> 01:03:30,320
Choose a product range with repeatable routing

1558
01:03:30,320 --> 01:03:33,200
and a planning decision people make every single day.

1559
01:03:33,200 --> 01:03:34,920
Model the actual machine eligibility

1560
01:03:34,920 --> 01:03:36,520
usable capacity setup rules

1561
01:03:36,520 --> 01:03:38,320
and the few material or tool conditions

1562
01:03:38,320 --> 01:03:40,520
that determine whether work can actually run

1563
01:03:40,520 --> 01:03:41,960
then compare the proposed schedule

1564
01:03:41,960 --> 01:03:43,200
with the planner's real decision

1565
01:03:43,200 --> 01:03:45,400
when the system gets the same answer ask why?

1566
01:03:45,400 --> 01:03:46,880
When it gets a different answer,

1567
01:03:46,880 --> 01:03:48,680
ask whether it missed a real constraint

1568
01:03:48,680 --> 01:03:50,760
or exposed a rule nobody had questioned before.

1569
01:03:50,760 --> 01:03:52,440
That's how confidence grows.

1570
01:03:52,440 --> 01:03:54,800
Through repeated tests against production facts,

1571
01:03:54,800 --> 01:03:56,560
not through a big launch announcement,

1572
01:03:56,560 --> 01:03:59,840
an APS system doesn't need to replace ERP to do this work.

1573
01:03:59,840 --> 01:04:02,080
ERP stays where demand orders, inventory

1574
01:04:02,080 --> 01:04:03,680
and purchasing transactions belong.

1575
01:04:03,680 --> 01:04:06,720
APS works beside it, taking the planning inputs it needs

1576
01:04:06,720 --> 01:04:08,960
and returning a constraint aware production plan

1577
01:04:08,960 --> 01:04:11,480
that people can review, debate and act on

1578
01:04:11,480 --> 01:04:13,600
when Monday morning rolls around.

1579
01:04:13,600 --> 01:04:16,880
ERP, MES and APS each have different jobs.

1580
01:04:16,880 --> 01:04:18,080
Here's the problem.

1581
01:04:18,080 --> 01:04:20,120
Once your planning model starts matching the factory

1582
01:04:20,120 --> 01:04:22,960
you actually run, ownership becomes the real headache,

1583
01:04:22,960 --> 01:04:24,320
not legal ownership.

1584
01:04:24,320 --> 01:04:27,200
I mean, who owns each planning fact, who gets to change it

1585
01:04:27,200 --> 01:04:29,920
and which system people trust when the numbers don't agree?

1586
01:04:29,920 --> 01:04:32,600
ERP, MES and APS can cooperate,

1587
01:04:32,600 --> 01:04:34,920
but trouble shows up the moment each system

1588
01:04:34,920 --> 01:04:36,640
tries to act like the master schedule.

1589
01:04:36,640 --> 01:04:38,800
Let's talk about what your ERP actually owns,

1590
01:04:38,800 --> 01:04:41,080
the commercial and transactional side of production.

1591
01:04:41,080 --> 01:04:43,040
It holds customer demand, sales orders,

1592
01:04:43,040 --> 01:04:45,280
production orders, builds of material, inventory,

1593
01:04:45,280 --> 01:04:48,800
purchase orders and the whole financial trail behind all of it.

1594
01:04:48,800 --> 01:04:51,480
When the business promises a customer an order,

1595
01:04:51,480 --> 01:04:55,200
that commitment needs a home and ERP is usually that home.

1596
01:04:55,200 --> 01:04:57,080
It also drives the material plan.

1597
01:04:57,080 --> 01:04:59,440
MRP turns demand into proposals for what to buy,

1598
01:04:59,440 --> 01:05:01,240
what to produce and when supply should arrive

1599
01:05:01,240 --> 01:05:02,920
linking an order to the components,

1600
01:05:02,920 --> 01:05:05,520
subassemblies, suppliers and internal work required

1601
01:05:05,520 --> 01:05:06,280
to fulfill it.

1602
01:05:06,280 --> 01:05:08,040
That role doesn't disappear when you bring

1603
01:05:08,040 --> 01:05:09,320
in finite scheduling.

1604
01:05:09,320 --> 01:05:11,720
You still need ERP to answer questions like,

1605
01:05:11,720 --> 01:05:13,480
what demand exists, what's been promised,

1606
01:05:13,480 --> 01:05:15,880
which materials are planned and what transaction needs

1607
01:05:15,880 --> 01:05:18,080
to post when work completes.

1608
01:05:18,080 --> 01:05:20,280
MES owns a different kind of truth.

1609
01:05:20,280 --> 01:05:22,440
It owns what happens during execution.

1610
01:05:22,440 --> 01:05:25,320
When an operator starts an operation, records good quantity,

1611
01:05:25,320 --> 01:05:28,800
reports scrap, pauses a job or completes a quality check,

1612
01:05:28,800 --> 01:05:32,480
the MES captures that activity along with batch genealogy,

1613
01:05:32,480 --> 01:05:35,360
serial traceability, electronic work instructions

1614
01:05:35,360 --> 01:05:38,600
and quality events that can stop work from moving forward.

1615
01:05:38,600 --> 01:05:40,920
That matters because a schedule starts as an intention,

1616
01:05:40,920 --> 01:05:42,640
but production creates facts.

1617
01:05:42,640 --> 01:05:45,040
The plan might expect a hundred parts to finish by noon,

1618
01:05:45,040 --> 01:05:47,640
but the MES reports that 85 good parts finished,

1619
01:05:47,640 --> 01:05:50,040
10 need review and five became scrap.

1620
01:05:50,040 --> 01:05:52,960
Those aren't planning opinions, they're execution facts

1621
01:05:52,960 --> 01:05:55,200
and the schedule needs them if it's going to stay connected

1622
01:05:55,200 --> 01:05:56,800
to the shop floor.

1623
01:05:56,800 --> 01:05:59,320
APS, advance planning and scheduling,

1624
01:05:59,320 --> 01:06:02,000
owns the decision layer between demand and execution.

1625
01:06:02,000 --> 01:06:04,560
It pulls together order demand, material conditions,

1626
01:06:04,560 --> 01:06:07,560
routing rules, available resources and current status,

1627
01:06:07,560 --> 01:06:10,000
then builds a finite schedule that tests whether the work

1628
01:06:10,000 --> 01:06:11,120
actually fits.

1629
01:06:11,120 --> 01:06:13,400
Its job isn't to replace the ERP order

1630
01:06:13,400 --> 01:06:15,840
or become the accounting record for stock movement.

1631
01:06:15,840 --> 01:06:17,560
APS asks a different question.

1632
01:06:17,560 --> 01:06:19,360
Given the conditions we have right now,

1633
01:06:19,360 --> 01:06:21,680
what sequence gives the best workable plan?

1634
01:06:21,680 --> 01:06:24,120
That includes scenario analysis where a planner tests

1635
01:06:24,120 --> 01:06:27,120
the impact of a machine outage, a late supplier delivery,

1636
01:06:27,120 --> 01:06:30,160
overtime on a constrained resource or a new urgent order,

1637
01:06:30,160 --> 01:06:32,480
comparing options before releasing a decision

1638
01:06:32,480 --> 01:06:35,880
rather than changing the live plan and hoping it works.

1639
01:06:35,880 --> 01:06:38,360
The APS output should be a recommendation with reasons.

1640
01:06:38,360 --> 01:06:40,160
It can show that moving a job protects

1641
01:06:40,160 --> 01:06:43,760
a higher priority delivery, avoids an illegal setup sequence

1642
01:06:43,760 --> 01:06:46,000
or uses an approved alternative resource

1643
01:06:46,000 --> 01:06:47,800
while also showing the trade-off.

1644
01:06:47,800 --> 01:06:50,440
Another order moves later, a setup increases

1645
01:06:50,440 --> 01:06:52,680
or overtime becomes necessary.

1646
01:06:52,680 --> 01:06:54,360
People can disagree with the choice,

1647
01:06:54,360 --> 01:06:56,800
but they shouldn't have to guess what the choice does.

1648
01:06:56,800 --> 01:06:59,440
Clear hand-offs matter more than the product names.

1649
01:06:59,440 --> 01:07:01,880
ERP sends demand order details approved

1650
01:07:01,880 --> 01:07:04,080
routing's material plans and customer commitments

1651
01:07:04,080 --> 01:07:05,360
into the planning process.

1652
01:07:05,360 --> 01:07:09,160
MES sends back actual progress, confirmed quantities,

1653
01:07:09,160 --> 01:07:11,840
quality status and execution events.

1654
01:07:11,840 --> 01:07:14,880
APS returns a feasible schedule with dispatch priorities

1655
01:07:14,880 --> 01:07:16,880
or proposed changes for review,

1656
01:07:16,880 --> 01:07:19,120
but only one place should hold schedule authority

1657
01:07:19,120 --> 01:07:20,520
for any given decision.

1658
01:07:20,520 --> 01:07:23,400
If ERP sends dates, APS sends a different sequence,

1659
01:07:23,400 --> 01:07:25,640
MES exposes its own dispatch list

1660
01:07:25,640 --> 01:07:27,800
and a planner maintains another order in Excel,

1661
01:07:27,800 --> 01:07:30,440
the shop floor gets four versions of the plan.

1662
01:07:30,440 --> 01:07:32,040
And nobody benefits from that.

1663
01:07:32,040 --> 01:07:34,320
The supervisor will follow the source they trust most,

1664
01:07:34,320 --> 01:07:36,360
which might be correct, but the architecture

1665
01:07:36,360 --> 01:07:37,600
has already failed them.

1666
01:07:37,600 --> 01:07:38,640
You need a clear rule.

1667
01:07:38,640 --> 01:07:42,240
For detailed finite scheduling, APS becomes the planning authority.

1668
01:07:42,240 --> 01:07:44,640
ERP stays the authority for customer orders,

1669
01:07:44,640 --> 01:07:47,240
material transactions and formal commitments.

1670
01:07:47,240 --> 01:07:50,200
MES stays the authority for what physically happened.

1671
01:07:50,200 --> 01:07:51,560
The boundary needs to be plain enough

1672
01:07:51,560 --> 01:07:52,960
that production knows where to ask

1673
01:07:52,960 --> 01:07:54,520
when a priority changes.

1674
01:07:54,520 --> 01:07:56,880
And the planner still owns the decision to release work.

1675
01:07:56,880 --> 01:07:59,360
A scheduling engine can calculate options faster

1676
01:07:59,360 --> 01:08:02,200
than any person can, but it can't carry accountability

1677
01:08:02,200 --> 01:08:05,080
for a late customer call, a safety concern,

1678
01:08:05,080 --> 01:08:07,040
an informal agreement with a supplier

1679
01:08:07,040 --> 01:08:09,400
or a production risk people haven't confirmed yet.

1680
01:08:09,400 --> 01:08:11,720
The planner reviews exceptions, approves changes

1681
01:08:11,720 --> 01:08:13,560
that affect execution and decides

1682
01:08:13,560 --> 01:08:16,600
when a recommendation should become a shop floor instruction.

1683
01:08:16,600 --> 01:08:18,080
That isn't a weakness in the system.

1684
01:08:18,080 --> 01:08:19,440
It's the operating model.

1685
01:08:19,440 --> 01:08:21,200
Once those responsibilities are clear,

1686
01:08:21,200 --> 01:08:24,040
the technical architecture becomes much easier to discuss.

1687
01:08:24,040 --> 01:08:25,680
And that's where Microsoft comes in,

1688
01:08:25,680 --> 01:08:28,960
not as a replacement for ERP, MES or APS,

1689
01:08:28,960 --> 01:08:30,720
but as the data and integration layer

1690
01:08:30,720 --> 01:08:33,240
that helps those systems exchange trusted facts.

1691
01:08:33,240 --> 01:08:36,720
Microsoft architecture without the product pitch.

1692
01:08:36,720 --> 01:08:39,720
So once you've decided which system owns which fact,

1693
01:08:39,720 --> 01:08:42,680
Microsoft technology can help connect the planning loop

1694
01:08:42,680 --> 01:08:46,120
without pretending it replaces the scheduling engine itself.

1695
01:08:46,120 --> 01:08:48,600
The starting point is data moving both ways.

1696
01:08:48,600 --> 01:08:51,480
ERP provides the planning inputs, production orders,

1697
01:08:51,480 --> 01:08:53,760
due dates, approved rootings, bills of material,

1698
01:08:53,760 --> 01:08:55,480
purchase status, customer commitments,

1699
01:08:55,480 --> 01:08:58,040
MES sends back what production has confirmed.

1700
01:08:58,040 --> 01:09:00,480
Operation start and finish times, good quantity,

1701
01:09:00,480 --> 01:09:02,160
scrap, holds, machine status,

1702
01:09:02,160 --> 01:09:04,200
work that no longer follows the original plan,

1703
01:09:04,200 --> 01:09:05,480
that flow needs care.

1704
01:09:05,480 --> 01:09:08,000
You don't want every system polling, every other system,

1705
01:09:08,000 --> 01:09:10,080
copying records around, then arguing

1706
01:09:10,080 --> 01:09:11,720
over which timestamp is right.

1707
01:09:11,720 --> 01:09:14,280
In practical terms, the integration should move the facts

1708
01:09:14,280 --> 01:09:17,360
each decision needs at the speed that decision requires.

1709
01:09:17,360 --> 01:09:20,200
A long range capacity review may only need refreshed data

1710
01:09:20,200 --> 01:09:22,560
at planned intervals, but a confirmed machine stoppage

1711
01:09:22,560 --> 01:09:24,280
that threatens today's bottleneck plan

1712
01:09:24,280 --> 01:09:27,280
may need to reach the scheduling process much sooner.

1713
01:09:27,280 --> 01:09:28,880
Those are different integration patterns

1714
01:09:28,880 --> 01:09:31,640
and treating them as one giant data feed usually creates

1715
01:09:31,640 --> 01:09:33,920
more noise than help as you're fits naturally

1716
01:09:33,920 --> 01:09:35,600
into this part of the architecture.

1717
01:09:35,600 --> 01:09:38,720
It supports secure connections between ERP, MES,

1718
01:09:38,720 --> 01:09:42,240
planning tools, machine data sources, and enterprise services,

1719
01:09:42,240 --> 01:09:45,360
handling APIs, messages, events, transformation rules,

1720
01:09:45,360 --> 01:09:48,040
and identity controls while keeping the shop floor separate

1721
01:09:48,040 --> 01:09:50,920
from systems that don't need direct access to it.

1722
01:09:50,920 --> 01:09:54,360
That separation matters because OT, operational technology,

1723
01:09:54,360 --> 01:09:56,560
has different needs from enterprise IT.

1724
01:09:56,560 --> 01:09:58,080
The machine network should not depend

1725
01:09:58,080 --> 01:10:00,640
on a cloud planning request before it can continue running

1726
01:10:00,640 --> 01:10:03,160
and production control stays close to production.

1727
01:10:03,160 --> 01:10:05,400
As you can collect approved operational events

1728
01:10:05,400 --> 01:10:07,320
and make them available to planning and analytics

1729
01:10:07,320 --> 01:10:09,480
without turning the cloud into a new point of failure

1730
01:10:09,480 --> 01:10:10,480
for the machine.

1731
01:10:10,480 --> 01:10:13,240
Picture a confirmed event moving through the architecture.

1732
01:10:13,240 --> 01:10:16,200
The MES records that a machining operation stopped.

1733
01:10:16,200 --> 01:10:17,960
A maintenance or production rule confirms

1734
01:10:17,960 --> 01:10:20,120
the resource won't return during the current shift.

1735
01:10:20,120 --> 01:10:22,000
That event passes through the integration layer

1736
01:10:22,000 --> 01:10:24,320
to the planning process where the scheduling engine

1737
01:10:24,320 --> 01:10:26,160
can test the impact against current orders

1738
01:10:26,160 --> 01:10:27,520
and available resources.

1739
01:10:27,520 --> 01:10:29,280
At the same time, the event becomes part

1740
01:10:29,280 --> 01:10:31,560
of the operational record for analysis,

1741
01:10:31,560 --> 01:10:34,080
not as a vague alarm in a log file,

1742
01:10:34,080 --> 01:10:38,320
but as an event tied to a machine and order, a planned slot,

1743
01:10:38,320 --> 01:10:40,280
and the eventual planning decision.

1744
01:10:40,280 --> 01:10:43,480
Microsoft, Fabric, becomes useful when you need a governed place

1745
01:10:43,480 --> 01:10:46,520
to bring planning and execution data together for analysis.

1746
01:10:46,520 --> 01:10:49,160
ERP data, MES events, maintenance records,

1747
01:10:49,160 --> 01:10:51,400
and schedule versions often sit in separate systems

1748
01:10:51,400 --> 01:10:54,240
for good reasons, but Fabric can bring approved copies

1749
01:10:54,240 --> 01:10:56,040
into a shared analytical environment

1750
01:10:56,040 --> 01:10:59,640
with common controls around access, lineage, and refresh.

1751
01:10:59,640 --> 01:11:01,560
That doesn't mean Fabric becomes the scheduler.

1752
01:11:01,560 --> 01:11:03,960
A scheduling engine needs to evaluate resource conflicts

1753
01:11:03,960 --> 01:11:05,720
and generate planning choices.

1754
01:11:05,720 --> 01:11:07,360
ERP needs to post transactions.

1755
01:11:07,360 --> 01:11:09,280
MES needs to record execution.

1756
01:11:09,280 --> 01:11:11,360
Fabric can help people analyze what happened

1757
01:11:11,360 --> 01:11:14,600
across those systems, ask where the plan drifted from execution,

1758
01:11:14,600 --> 01:11:16,320
and see whether the planning rules match

1759
01:11:16,320 --> 01:11:17,960
the way the factory performs.

1760
01:11:17,960 --> 01:11:19,760
Power BI then becomes the reporting layer

1761
01:11:19,760 --> 01:11:21,440
for people who need to see schedule health

1762
01:11:21,440 --> 01:11:23,200
without digging through order tables.

1763
01:11:23,200 --> 01:11:24,720
A production manager may need to know

1764
01:11:24,720 --> 01:11:27,200
where bottleneck load exceeds the time available.

1765
01:11:27,200 --> 01:11:30,080
A customer service team may need a view of promise risk

1766
01:11:30,080 --> 01:11:31,680
with a clear distinction between orders

1767
01:11:31,680 --> 01:11:34,520
that remain feasible and orders that need a decision.

1768
01:11:34,520 --> 01:11:36,760
A planner may need to compare the released schedule

1769
01:11:36,760 --> 01:11:39,560
with what actually ran to review why the order changed.

1770
01:11:39,560 --> 01:11:41,240
Those are decision views, not decoration.

1771
01:11:41,240 --> 01:11:42,920
A colorful report that shows late orders

1772
01:11:42,920 --> 01:11:45,040
after they ship doesn't improve the schedule.

1773
01:11:45,040 --> 01:11:47,080
A useful view exposes pressure early enough

1774
01:11:47,080 --> 01:11:49,200
for someone to decide whether to move work,

1775
01:11:49,200 --> 01:11:51,680
approve overtime, protect the customer order,

1776
01:11:51,680 --> 01:11:53,160
or revise a promise.

1777
01:11:53,160 --> 01:11:55,760
The same applies to plan versus actual analysis.

1778
01:11:55,760 --> 01:11:58,000
If an operation repeatedly takes longer than planned,

1779
01:11:58,000 --> 01:11:59,640
the team should be able to trace that gap

1780
01:11:59,640 --> 01:12:01,640
back to the root resource, product family,

1781
01:12:01,640 --> 01:12:03,440
or shift condition involved.

1782
01:12:03,440 --> 01:12:05,080
If the schedule changes every day,

1783
01:12:05,080 --> 01:12:07,040
people should see whether confirmed disruptions

1784
01:12:07,040 --> 01:12:09,680
cause those changes or whether the model keeps producing plans

1785
01:12:09,680 --> 01:12:11,320
that operations can't follow.

1786
01:12:11,320 --> 01:12:13,200
As a Microsoft MVP, I spend a lot of time

1787
01:12:13,200 --> 01:12:15,600
looking at where Azure, Fabric, and Power BI

1788
01:12:15,600 --> 01:12:17,040
fit in manufacturing architectures.

1789
01:12:17,040 --> 01:12:19,640
They can connect the dots between IT and OT,

1790
01:12:19,640 --> 01:12:21,720
provide real-time visibility where it helps,

1791
01:12:21,720 --> 01:12:24,160
and support an architecture that actually scales.

1792
01:12:24,160 --> 01:12:26,680
But they don't remove the need for scheduling logic.

1793
01:12:26,680 --> 01:12:28,880
No integration platform decides which job

1794
01:12:28,880 --> 01:12:31,600
should consume the last available hour on a bottleneck.

1795
01:12:31,600 --> 01:12:34,080
And no analytics report knows whether a sequence rule

1796
01:12:34,080 --> 01:12:36,840
is hard, flexible, or simply outdated.

1797
01:12:36,840 --> 01:12:38,760
Those decisions depend on the planning model,

1798
01:12:38,760 --> 01:12:40,360
the rules, the factory accepts,

1799
01:12:40,360 --> 01:12:43,080
and the specialist scheduling capability used to test them.

1800
01:12:43,080 --> 01:12:45,160
Microsoft can support the flow of trusted data

1801
01:12:45,160 --> 01:12:46,720
and the decisions around it.

1802
01:12:46,720 --> 01:12:48,280
The finite scheduling or APS layer

1803
01:12:48,280 --> 01:12:50,440
still needs to solve the actual constraint problem.

1804
01:12:50,440 --> 01:12:52,640
And even when the data reaches the right place,

1805
01:12:52,640 --> 01:12:54,960
systems can still disagree about what a machine

1806
01:12:54,960 --> 01:12:58,400
operation order status or resource qualification actually means,

1807
01:12:58,400 --> 01:13:00,640
which is where a semantic layer helps give those facts

1808
01:13:00,640 --> 01:13:02,320
a shared meaning.

1809
01:13:02,320 --> 01:13:04,560
Context, digital twin and knowledge graph.

1810
01:13:04,560 --> 01:13:06,400
Let's cut through the hype for a second.

1811
01:13:06,400 --> 01:13:08,680
A shared meaning layer can take several forms

1812
01:13:08,680 --> 01:13:11,560
and in manufacturing, two terms always come up.

1813
01:13:11,560 --> 01:13:13,240
Digital twin and knowledge graph.

1814
01:13:13,240 --> 01:13:14,600
They both help with planning,

1815
01:13:14,600 --> 01:13:17,120
but they describe different parts of the same problem.

1816
01:13:17,120 --> 01:13:18,560
Here's the practical view.

1817
01:13:18,560 --> 01:13:21,080
A digital twin models an operational asset

1818
01:13:21,080 --> 01:13:22,360
and its current state.

1819
01:13:22,360 --> 01:13:24,160
For a machine that means whether it's running,

1820
01:13:24,160 --> 01:13:26,680
stopped, under maintenance, available for planning

1821
01:13:26,680 --> 01:13:28,640
or restricted to certain work, think of it

1822
01:13:28,640 --> 01:13:31,280
as the current operational identity of that asset.

1823
01:13:31,280 --> 01:13:33,240
It links the physical machine on the floor

1824
01:13:33,240 --> 01:13:35,920
to a managed digital record that planning systems can use

1825
01:13:35,920 --> 01:13:36,440
directly.

1826
01:13:36,440 --> 01:13:38,920
That record can carry more than just a status signal.

1827
01:13:38,920 --> 01:13:40,640
It can hold the machine's identity,

1828
01:13:40,640 --> 01:13:43,160
its current setup family, plant maintenance windows,

1829
01:13:43,160 --> 01:13:45,160
operating limits, and the approved data that

1830
01:13:45,160 --> 01:13:48,120
tells other systems whether the machine can accept more work.

1831
01:13:48,120 --> 01:13:49,440
Here's why that matters.

1832
01:13:49,440 --> 01:13:52,360
Machine 12 is available is rarely enough information.

1833
01:13:52,360 --> 01:13:54,280
You need to know available for which operation

1834
01:13:54,280 --> 01:13:56,200
with which tool under what product restrictions

1835
01:13:56,200 --> 01:13:58,120
for which shift and whether it's actually available,

1836
01:13:58,120 --> 01:14:00,320
or just not reporting a fault at that moment.

1837
01:14:00,320 --> 01:14:02,360
A digital twin gives you a way to model

1838
01:14:02,360 --> 01:14:04,720
that current operational context without building

1839
01:14:04,720 --> 01:14:06,320
a huge virtual factory.

1840
01:14:06,320 --> 01:14:08,800
First, that idea has kept plenty of useful projects,

1841
01:14:08,800 --> 01:14:11,000
stuck in PowerPoint for far too long.

1842
01:14:11,000 --> 01:14:12,520
You can start with the assets that actually

1843
01:14:12,520 --> 01:14:13,840
shape the planning decision.

1844
01:14:13,840 --> 01:14:16,200
A knowledge graph handles a related but different job.

1845
01:14:16,200 --> 01:14:19,400
It models relationships across things that live in separate systems,

1846
01:14:19,400 --> 01:14:22,880
products, processes, resources, orders, material batches, tools,

1847
01:14:22,880 --> 01:14:24,520
skills, and maintenance activities.

1848
01:14:24,520 --> 01:14:27,320
The word graph can sound abstract, so keep it practical.

1849
01:14:27,320 --> 01:14:29,560
It just means the model can record that a product requires

1850
01:14:29,560 --> 01:14:30,480
an operation.

1851
01:14:30,480 --> 01:14:33,120
The operation can run on specific machines.

1852
01:14:33,120 --> 01:14:35,520
Each machine requires a tool for that operation,

1853
01:14:35,520 --> 01:14:38,360
and a given operator needs an approved skill to run it.

1854
01:14:38,360 --> 01:14:40,040
Those links are the planning context.

1855
01:14:40,040 --> 01:14:42,600
Take a machining order that calls for a pump housing,

1856
01:14:42,600 --> 01:14:43,720
following a routing.

1857
01:14:43,720 --> 01:14:45,560
One routing step needs a milling operation

1858
01:14:45,560 --> 01:14:47,440
that can run on two approved machines.

1859
01:14:47,440 --> 01:14:50,440
But one machine needs a fixture currently assigned elsewhere,

1860
01:14:50,440 --> 01:14:53,160
while the other enters a maintenance window later that day.

1861
01:14:53,160 --> 01:14:55,520
A schedule that only sees works and a capacity misses

1862
01:14:55,520 --> 01:14:56,840
that decision entirely.

1863
01:14:56,840 --> 01:14:58,520
A schedule that sees those relationships

1864
01:14:58,520 --> 01:15:00,000
can test real options.

1865
01:15:00,000 --> 01:15:02,440
It can ask whether the operation is eligible on that machine

1866
01:15:02,440 --> 01:15:04,760
at that time, check that the fixture is free,

1867
01:15:04,760 --> 01:15:06,960
test operator skill coverage, and avoid

1868
01:15:06,960 --> 01:15:08,840
maintenance collisions all at once.

1869
01:15:08,840 --> 01:15:10,000
That's what context does.

1870
01:15:10,000 --> 01:15:11,800
It turns separate facts into conditions

1871
01:15:11,800 --> 01:15:13,160
that can be checked together.

1872
01:15:13,160 --> 01:15:15,080
You don't need to call this a digital twin or a knowledge

1873
01:15:15,080 --> 01:15:16,200
graph for it to work.

1874
01:15:16,200 --> 01:15:18,280
Those labels aren't mandatory, and sometimes they

1875
01:15:18,280 --> 01:15:20,640
create more debate than the planning problem deserves.

1876
01:15:20,640 --> 01:15:22,400
The scheduling engine needs a trusted model

1877
01:15:22,400 --> 01:15:24,200
of the same relationships, whether they

1878
01:15:24,200 --> 01:15:27,000
sit in relational tables, a specialist APS data model,

1879
01:15:27,000 --> 01:15:28,840
a graph database, or a mix.

1880
01:15:28,840 --> 01:15:31,240
The format matters less than the clarity of the rules

1881
01:15:31,240 --> 01:15:33,040
and the reliability of the data.

1882
01:15:33,040 --> 01:15:36,000
Graph thinking becomes useful as relationships grow.

1883
01:15:36,000 --> 01:15:38,920
A traditional table can store that an operation needs a resource,

1884
01:15:38,920 --> 01:15:41,040
but factories often need to express more.

1885
01:15:41,040 --> 01:15:42,720
A resource supports an operation only

1886
01:15:42,720 --> 01:15:45,360
for certain product grades, with a certain fixture,

1887
01:15:45,360 --> 01:15:48,200
after a qualification date, outside a maintenance period,

1888
01:15:48,200 --> 01:15:51,360
and when the previous job leaves the machine in an allowed state.

1889
01:15:51,360 --> 01:15:54,040
Those are connected conditions, not isolated fields.

1890
01:15:54,040 --> 01:15:56,200
When you model them clearly, you reduce the need

1891
01:15:56,200 --> 01:15:58,160
for planners to remember every exception.

1892
01:15:58,160 --> 01:15:59,880
They can spend more time judging the situation

1893
01:15:59,880 --> 01:16:01,960
and less time rebuilding the factory in their head

1894
01:16:01,960 --> 01:16:03,280
before moving one order.

1895
01:16:03,280 --> 01:16:05,280
This is where the architecture gets practical.

1896
01:16:05,280 --> 01:16:08,040
The digital twin keeps operational asset state current.

1897
01:16:08,040 --> 01:16:10,000
The relationship model explains how that asset

1898
01:16:10,000 --> 01:16:12,800
connects to products, processes, orders, tools, and people.

1899
01:16:12,800 --> 01:16:14,960
And the planning engine tests the proposed schedule

1900
01:16:14,960 --> 01:16:17,600
against both current state and approved rules.

1901
01:16:17,600 --> 01:16:19,400
No model removes uncertainty.

1902
01:16:19,400 --> 01:16:21,880
A maintenance window can change, a tool can fail,

1903
01:16:21,880 --> 01:16:24,640
or a person can spot a condition the system doesn't yet know.

1904
01:16:24,640 --> 01:16:27,120
But clean context means the system can tell the difference

1905
01:16:27,120 --> 01:16:29,120
between a resource that looks free and one that

1906
01:16:29,120 --> 01:16:31,240
can legally and practically do the work.

1907
01:16:31,240 --> 01:16:33,760
But that's a much stronger basis for any planning decision.

1908
01:16:33,760 --> 01:16:35,800
It also changes what AI can safely do.

1909
01:16:35,800 --> 01:16:38,720
AI has a role, but it shouldn't schedule by guessing.

1910
01:16:38,720 --> 01:16:41,120
Let's cut through the AI hype for a second.

1911
01:16:41,120 --> 01:16:44,520
AI can help planners, but it needs a defined job.

1912
01:16:44,520 --> 01:16:47,920
Asking a generative AI tool to create the best production

1913
01:16:47,920 --> 01:16:50,920
schedule from a pile of order data sounds modern,

1914
01:16:50,920 --> 01:16:54,080
yet it skips the rules that make a schedule safe to run.

1915
01:16:54,080 --> 01:16:56,360
A language model can explain information well.

1916
01:16:56,360 --> 01:16:58,360
It can answer a planner's question in plain language

1917
01:16:58,360 --> 01:17:00,760
like, why did order bravo move?

1918
01:17:00,760 --> 01:17:02,760
Or it can retrieve the approved setup procedure

1919
01:17:02,760 --> 01:17:04,560
for a product family, pull together

1920
01:17:04,560 --> 01:17:06,600
the known conditions behind an exception,

1921
01:17:06,600 --> 01:17:08,800
or help someone find the maintenance instruction linked

1922
01:17:08,800 --> 01:17:09,800
to a resource.

1923
01:17:09,800 --> 01:17:11,280
That's useful support.

1924
01:17:11,280 --> 01:17:13,480
Picture a planner seeing an order moved outside

1925
01:17:13,480 --> 01:17:15,080
its original promise window.

1926
01:17:15,080 --> 01:17:17,480
Instead of opening five systems and chasing messages,

1927
01:17:17,480 --> 01:17:19,120
they ask a copilot style assistant

1928
01:17:19,120 --> 01:17:20,880
to show the confirmed events and constraints

1929
01:17:20,880 --> 01:17:22,200
that affected that order.

1930
01:17:22,200 --> 01:17:24,760
The assistant retrieves approved schedule changes,

1931
01:17:24,760 --> 01:17:26,640
the related maintenance event, the root rules,

1932
01:17:26,640 --> 01:17:28,280
and the current material status.

1933
01:17:28,280 --> 01:17:30,400
It helps the planner understand the situation faster,

1934
01:17:30,400 --> 01:17:32,320
but it should not invent the decision.

1935
01:17:32,320 --> 01:17:35,200
There's another AI role that fits manufacturing much better.

1936
01:17:35,200 --> 01:17:36,120
Prediction.

1937
01:17:36,120 --> 01:17:38,920
A predictive model can estimate how long an operation is likely

1938
01:17:38,920 --> 01:17:41,360
to take based on approved historical signals.

1939
01:17:41,360 --> 01:17:43,160
It can estimate failure risk for a machine,

1940
01:17:43,160 --> 01:17:45,800
quality risk for a product and process combination,

1941
01:17:45,800 --> 01:17:48,040
or the chance that a supplier delivery will arrive later

1942
01:17:48,040 --> 01:17:49,000
than planned.

1943
01:17:49,000 --> 01:17:51,600
Those predictions can improve the inputs to planning.

1944
01:17:51,600 --> 01:17:53,960
If a model estimates that an operation often needs

1945
01:17:53,960 --> 01:17:56,360
more time under a certain material condition,

1946
01:17:56,360 --> 01:17:59,040
the scheduling process can use that estimate as a planning

1947
01:17:59,040 --> 01:18:01,720
duration with proper review and controls.

1948
01:18:01,720 --> 01:18:03,880
If maintenance data suggests a higher risk of failure

1949
01:18:03,880 --> 01:18:05,320
during a planned run, the planner

1950
01:18:05,320 --> 01:18:07,440
can test scenarios before committing the bottleneck

1951
01:18:07,440 --> 01:18:09,440
to that work, but prediction and scheduling

1952
01:18:09,440 --> 01:18:10,800
remain different problems.

1953
01:18:10,800 --> 01:18:12,920
A prediction says this job may take longer,

1954
01:18:12,920 --> 01:18:15,560
but a scheduling engine asks, given that risk,

1955
01:18:15,560 --> 01:18:18,480
which legal sequence best meets the goals we've set?

1956
01:18:18,480 --> 01:18:21,200
That second question needs deterministic optimization,

1957
01:18:21,200 --> 01:18:23,360
meaning the engine applies stated rules

1958
01:18:23,360 --> 01:18:26,000
and chooses between options in a repeatable way.

1959
01:18:26,000 --> 01:18:28,760
The schedule must obey the constraints you define.

1960
01:18:28,760 --> 01:18:31,360
It needs to respect machine eligibility, approved routes,

1961
01:18:31,360 --> 01:18:34,040
setup rules, current availability, material conditions,

1962
01:18:34,040 --> 01:18:35,920
and whatever policy controls the plan,

1963
01:18:35,920 --> 01:18:37,440
then it can score possible schedules

1964
01:18:37,440 --> 01:18:39,720
against the business goals, like protecting a due date

1965
01:18:39,720 --> 01:18:41,800
or reducing avoidable setup time.

1966
01:18:41,800 --> 01:18:43,760
Generative AI doesn't replace that logic.

1967
01:18:43,760 --> 01:18:46,520
It can describe the result, help a planner query the model,

1968
01:18:46,520 --> 01:18:48,360
draft an explanation for a production meeting,

1969
01:18:48,360 --> 01:18:50,160
and find the work instruction that applies

1970
01:18:50,160 --> 01:18:51,560
when an exception occurs.

1971
01:18:51,560 --> 01:18:53,600
But natural language fluency doesn't prove

1972
01:18:53,600 --> 01:18:56,480
that a proposed sequence respects finite resource time

1973
01:18:56,480 --> 01:18:57,760
or every production rule.

1974
01:18:57,760 --> 01:18:59,720
A confident answer can still be wrong.

1975
01:18:59,720 --> 01:19:01,000
In fact, trees tend to notice.

1976
01:19:01,000 --> 01:19:03,120
So if you introduce co-pilot into this process,

1977
01:19:03,120 --> 01:19:05,360
start with approved data and a narrow scope.

1978
01:19:05,360 --> 01:19:07,200
The assistant needs permission or way access

1979
01:19:07,200 --> 01:19:08,800
to the records it can retrieve.

1980
01:19:08,800 --> 01:19:10,520
A planner may see customer commitments

1981
01:19:10,520 --> 01:19:12,920
and schedule risk that an operator should not see.

1982
01:19:12,920 --> 01:19:15,720
Maintenance may own notes that need controlled access.

1983
01:19:15,720 --> 01:19:18,160
Quality records can carry their own restrictions.

1984
01:19:18,160 --> 01:19:20,200
The assistant also needs clear action limits,

1985
01:19:20,200 --> 01:19:22,720
reading and explaining our one level of risk.

1986
01:19:22,720 --> 01:19:25,240
Drafting a proposed schedule change for review is another,

1987
01:19:25,240 --> 01:19:27,840
releasing a change priority directly to the shop floor,

1988
01:19:27,840 --> 01:19:29,040
changing a customer promise

1989
01:19:29,040 --> 01:19:31,560
or bypassing a quality condition crosses into a decision

1990
01:19:31,560 --> 01:19:33,960
that can affect delivery, safety and compliance.

1991
01:19:33,960 --> 01:19:35,800
That boundary should stay explicit.

1992
01:19:35,800 --> 01:19:38,120
A good design might let the assistant answer,

1993
01:19:38,120 --> 01:19:39,480
which release jobs will be affected

1994
01:19:39,480 --> 01:19:42,280
if this machine remains unavailable until the end of shift

1995
01:19:42,280 --> 01:19:44,440
or let it prepare a scenario for the planner.

1996
01:19:44,440 --> 01:19:46,640
It should not quietly rewrite dispatch instructions

1997
01:19:46,640 --> 01:19:48,960
because it inferred that one order sounded urgent

1998
01:19:48,960 --> 01:19:49,760
in an email.

1999
01:19:49,760 --> 01:19:51,480
Humans need to approve schedule changes

2000
01:19:51,480 --> 01:19:52,800
with operational impact.

2001
01:19:52,800 --> 01:19:54,560
That doesn't mean planners must calculate

2002
01:19:54,560 --> 01:19:55,920
every option by hand.

2003
01:19:55,920 --> 01:19:57,720
The scheduling engine can test options,

2004
01:19:57,720 --> 01:19:59,480
predictive models can improve assumptions

2005
01:19:59,480 --> 01:20:02,160
and a generative assistant can bring the reasoning together

2006
01:20:02,160 --> 01:20:03,640
in a form people can discuss.

2007
01:20:03,640 --> 01:20:06,600
But the person accountable for production

2008
01:20:06,600 --> 01:20:09,560
still decides whether that recommendation becomes a commitment,

2009
01:20:09,560 --> 01:20:10,640
keep that distinction clear,

2010
01:20:10,640 --> 01:20:12,120
a system can calculate a schedule

2011
01:20:12,120 --> 01:20:14,160
that scores well against today's rules.

2012
01:20:14,160 --> 01:20:15,560
But the plan still needs a schedule

2013
01:20:15,560 --> 01:20:17,400
people can prepare for, understand

2014
01:20:17,400 --> 01:20:21,000
and follow without receiving a new version every few hours.

2015
01:20:21,000 --> 01:20:22,760
The cost of constant rescheduling,

2016
01:20:22,760 --> 01:20:24,240
a schedule can respect capacity

2017
01:20:24,240 --> 01:20:26,400
and still cause chaos if it changes too often.

2018
01:20:26,400 --> 01:20:28,600
You've probably heard this called a nervous schedule

2019
01:20:28,600 --> 01:20:31,120
and that's exactly how it feels on the floor.

2020
01:20:31,120 --> 01:20:33,960
The plan keeps moving, priorities keep shifting

2021
01:20:33,960 --> 01:20:35,760
and nobody is sure whether the instruction

2022
01:20:35,760 --> 01:20:37,800
they got an hour ago still applies.

2023
01:20:37,800 --> 01:20:39,280
That creates work that never shows up

2024
01:20:39,280 --> 01:20:41,080
in any ERP transaction.

2025
01:20:41,080 --> 01:20:43,240
A supervisor stops a team to redirect them,

2026
01:20:43,240 --> 01:20:44,960
material handlers pull one kit back

2027
01:20:44,960 --> 01:20:46,200
and bring another forward.

2028
01:20:46,200 --> 01:20:48,880
Tooling gets ready for a setup only to find the job moved

2029
01:20:48,880 --> 01:20:50,640
and customer service calls a supplier

2030
01:20:50,640 --> 01:20:53,400
because an urgent order suddenly needs a missing component

2031
01:20:53,400 --> 01:20:54,080
sooner.

2032
01:20:54,080 --> 01:20:55,440
The machine pays for it too.

2033
01:20:55,440 --> 01:20:58,320
Every late priority change breaks a sensible sequence.

2034
01:20:58,320 --> 01:21:00,000
A job that would have followed a similar product

2035
01:21:00,000 --> 01:21:01,800
now needs a clean-out, a tool change,

2036
01:21:01,800 --> 01:21:03,960
a fresh inspection or a new fixture.

2037
01:21:03,960 --> 01:21:05,440
The schedule may look more responsive

2038
01:21:05,440 --> 01:21:07,560
because it moved the urgent job to the top

2039
01:21:07,560 --> 01:21:10,680
but the plant loses time in the very change it created.

2040
01:21:10,680 --> 01:21:13,600
You can't optimize only for today's urgent request.

2041
01:21:13,600 --> 01:21:17,000
You need to include the cost of disturbing the work already prepared.

2042
01:21:17,000 --> 01:21:18,360
Here's where freeze windows help.

2043
01:21:18,360 --> 01:21:20,760
A freeze window is a period near the current time

2044
01:21:20,760 --> 01:21:22,600
where the release plan stays stable

2045
01:21:22,600 --> 01:21:24,640
unless a real exception justifies a change.

2046
01:21:24,640 --> 01:21:27,240
It gives production enough certainty to stage material,

2047
01:21:27,240 --> 01:21:29,840
prepare tools, assign people and execute the work

2048
01:21:29,840 --> 01:21:33,560
without checking a new priority list every few minutes.

2049
01:21:33,560 --> 01:21:35,400
The length depends on the process.

2050
01:21:35,400 --> 01:21:38,560
A short cycle assembly line may only need a brief freeze window

2051
01:21:38,560 --> 01:21:40,080
while a process with long setups,

2052
01:21:40,080 --> 01:21:42,920
specialist tooling or complex material preparation

2053
01:21:42,920 --> 01:21:44,400
needs more protection.

2054
01:21:44,400 --> 01:21:46,320
The point isn't to make the schedule rigid.

2055
01:21:46,320 --> 01:21:49,480
It's to stop low-quality changes from reaching the shop floor.

2056
01:21:49,480 --> 01:21:51,680
Behind the freeze window sits a broader time fence,

2057
01:21:51,680 --> 01:21:54,040
think of the schedule as having different levels of commitment

2058
01:21:54,040 --> 01:21:55,880
as you move further into the future.

2059
01:21:55,880 --> 01:21:57,320
Work already running is fixed,

2060
01:21:57,320 --> 01:21:59,720
apart from safety or major production issues.

2061
01:21:59,720 --> 01:22:02,000
Work plan for the immediate period may be released

2062
01:22:02,000 --> 01:22:03,680
and protected by the freeze window.

2063
01:22:03,680 --> 01:22:05,320
Further out, the plan remains flexible

2064
01:22:05,320 --> 01:22:07,720
because customer demand, material dates, capacity

2065
01:22:07,720 --> 01:22:09,760
and maintenance conditions can still change.

2066
01:22:09,760 --> 01:22:11,960
That distinction gives planning room to react

2067
01:22:11,960 --> 01:22:14,440
without constantly disrupting execution.

2068
01:22:14,440 --> 01:22:17,120
Without time fences, every new sales order or forecast update

2069
01:22:17,120 --> 01:22:19,560
can pull work forward and push other work back,

2070
01:22:19,560 --> 01:22:21,280
turning the schedule into a live argument

2071
01:22:21,280 --> 01:22:23,200
between demand and capacity.

2072
01:22:23,200 --> 01:22:25,200
With time fences, the business can ask

2073
01:22:25,200 --> 01:22:26,720
a more useful question.

2074
01:22:26,720 --> 01:22:29,440
Does this new request justify breaking the firm plan

2075
01:22:29,440 --> 01:22:31,800
or should replace it into the next flexible window?

2076
01:22:31,800 --> 01:22:34,800
Not every event should trigger a full re-optimization either.

2077
01:22:34,800 --> 01:22:37,360
A machine status signal might flicker for a few seconds

2078
01:22:37,360 --> 01:22:39,640
and operator may pause a job to check a measurement

2079
01:22:39,640 --> 01:22:41,360
or a supplier may send an early warning

2080
01:22:41,360 --> 01:22:42,880
that still needs confirmation.

2081
01:22:42,880 --> 01:22:44,920
If every signal causes the planning engine

2082
01:22:44,920 --> 01:22:46,080
to rebuild the schedule,

2083
01:22:46,080 --> 01:22:48,840
the system creates noise faster than people can review it.

2084
01:22:48,840 --> 01:22:50,560
So planning needs event thresholds.

2085
01:22:50,560 --> 01:22:53,560
For example, a short interruption may only require local recovery

2086
01:22:53,560 --> 01:22:55,760
on the shop floor while a confirmed outage

2087
01:22:55,760 --> 01:22:59,080
beyond an agreed duration may trigger a new scenario.

2088
01:22:59,080 --> 01:23:00,960
A delayed material delivery matters only

2089
01:23:00,960 --> 01:23:03,360
if it threatens a released job or consumes the buffer

2090
01:23:03,360 --> 01:23:05,440
before a constrained resource.

2091
01:23:05,440 --> 01:23:07,840
The threshold should reflect operational impact,

2092
01:23:07,840 --> 01:23:09,960
not just the existence of an event.

2093
01:23:09,960 --> 01:23:11,080
This also protects trust.

2094
01:23:11,080 --> 01:23:13,160
People accept a schedule change more easily

2095
01:23:13,160 --> 01:23:14,800
when they understand why it happened,

2096
01:23:14,800 --> 01:23:16,760
who approved it and what it affects.

2097
01:23:16,760 --> 01:23:18,800
Priority changed isn't enough.

2098
01:23:18,800 --> 01:23:21,400
The explanation should state the reason in production terms.

2099
01:23:21,400 --> 01:23:24,000
A confirmed machine outage removed available time,

2100
01:23:24,000 --> 01:23:26,200
a material hold blocked the original job

2101
01:23:26,200 --> 01:23:28,240
or a customer escalation received approval

2102
01:23:28,240 --> 01:23:29,800
to enter the frozen period.

2103
01:23:29,800 --> 01:23:31,320
The planner should approve changes

2104
01:23:31,320 --> 01:23:32,920
that cross the agreed boundary

2105
01:23:32,920 --> 01:23:35,600
that approval doesn't need to slow every normal adjustment.

2106
01:23:35,600 --> 01:23:37,200
It creates a clear decision point

2107
01:23:37,200 --> 01:23:39,160
when a change disrupts released work,

2108
01:23:39,160 --> 01:23:40,760
affects a customer commitment

2109
01:23:40,760 --> 01:23:43,240
or forces people to prepare a different job.

2110
01:23:43,240 --> 01:23:45,720
It also creates a record that teams can review later,

2111
01:23:45,720 --> 01:23:46,640
but to blame someone,

2112
01:23:46,640 --> 01:23:49,320
but to learn whether the rules produce sensible decisions.

2113
01:23:49,320 --> 01:23:51,000
A schedule earns trust when it changes

2114
01:23:51,000 --> 01:23:53,840
for visible reasons and stays still when it should.

2115
01:23:53,840 --> 01:23:56,200
Optimization needs rules people can live with

2116
01:23:56,200 --> 01:23:58,840
because the best mathematical answer has little use

2117
01:23:58,840 --> 01:24:01,520
if the people who run the factory stop believing it.

2118
01:24:01,520 --> 01:24:03,840
Planning rules need shop floor ownership,

2119
01:24:03,840 --> 01:24:05,840
a constrained based schedule only works

2120
01:24:05,840 --> 01:24:07,680
when its rules come from the people

2121
01:24:07,680 --> 01:24:10,080
who live with the consequences.

2122
01:24:10,080 --> 01:24:12,760
Planning can't define the whole model alone.

2123
01:24:12,760 --> 01:24:14,760
Planning sees demand and priorities

2124
01:24:14,760 --> 01:24:16,400
while production sees the conditions

2125
01:24:16,400 --> 01:24:19,000
that decide whether a job can actually run.

2126
01:24:19,000 --> 01:24:20,280
Maintenance needs a voice

2127
01:24:20,280 --> 01:24:22,720
because it knows when a machine is technically available

2128
01:24:22,720 --> 01:24:24,000
when it is fragile

2129
01:24:24,000 --> 01:24:25,480
and when a planned intervention

2130
01:24:25,480 --> 01:24:28,320
can't move without creating a bigger risk.

2131
01:24:28,320 --> 01:24:29,400
Quality needs a voice

2132
01:24:29,400 --> 01:24:31,360
because an approved route, a batch release

2133
01:24:31,360 --> 01:24:33,880
or an inspection rule can decide whether an order

2134
01:24:33,880 --> 01:24:35,280
is allowed to proceed.

2135
01:24:35,280 --> 01:24:37,960
Logistics knows whether the material, packaging,

2136
01:24:37,960 --> 01:24:39,840
forklift capacity or staging space

2137
01:24:39,840 --> 01:24:41,160
supports the planned sequence.

2138
01:24:41,160 --> 01:24:42,840
Production brings the practical test.

2139
01:24:42,840 --> 01:24:44,360
A routing may claim that two machines

2140
01:24:44,360 --> 01:24:45,640
can perform the same work,

2141
01:24:45,640 --> 01:24:47,320
but the supervisor knows one machine

2142
01:24:47,320 --> 01:24:49,680
can only do it reliably with a certain fixture

2143
01:24:49,680 --> 01:24:51,360
and operator combination.

2144
01:24:51,360 --> 01:24:53,120
That isn't resistance to a new planning tool.

2145
01:24:53,120 --> 01:24:55,480
It's a production rule that needs a proper place in the model.

2146
01:24:55,480 --> 01:24:58,280
Planning still owns priorities and customer commitments,

2147
01:24:58,280 --> 01:24:59,520
but it needs those other teams

2148
01:24:59,520 --> 01:25:02,040
to define the physical boundaries around its choices.

2149
01:25:02,040 --> 01:25:05,000
Otherwise, the system turns undocumented shop floor knowledge

2150
01:25:05,000 --> 01:25:06,560
into avoidable exceptions.

2151
01:25:06,560 --> 01:25:08,920
The first useful conversation separates hard rules

2152
01:25:08,920 --> 01:25:09,840
from preferences.

2153
01:25:09,840 --> 01:25:12,160
A hard rule means the schedule must never break it.

2154
01:25:12,160 --> 01:25:14,320
A product may require a certified operator,

2155
01:25:14,320 --> 01:25:15,680
a machine may need a safety check

2156
01:25:15,680 --> 01:25:17,360
before a certain material runs,

2157
01:25:17,360 --> 01:25:19,320
a quality hold may block release

2158
01:25:19,320 --> 01:25:22,080
or a fixture may only exist once.

2159
01:25:22,080 --> 01:25:24,040
The scheduling engine should treat those conditions

2160
01:25:24,040 --> 01:25:25,120
as non-negotiable.

2161
01:25:25,120 --> 01:25:26,720
Preferences work differently.

2162
01:25:26,720 --> 01:25:28,480
You might prefer to group product families

2163
01:25:28,480 --> 01:25:30,960
into a campaign because the change overtakes time.

2164
01:25:30,960 --> 01:25:32,560
You might prefer to keep a certain customer

2165
01:25:32,560 --> 01:25:35,000
or the stable once material has been staged

2166
01:25:35,000 --> 01:25:36,880
or you might usually avoid overtime.

2167
01:25:36,880 --> 01:25:37,840
Those are real concerns,

2168
01:25:37,840 --> 01:25:39,240
but there may be circumstances where

2169
01:25:39,240 --> 01:25:41,600
the business chooses to accept the cost.

2170
01:25:41,600 --> 01:25:43,280
Then there are informal habits.

2171
01:25:43,280 --> 01:25:44,840
Some deserve to become formal rules

2172
01:25:44,840 --> 01:25:46,680
while others exist because a past problem

2173
01:25:46,680 --> 01:25:49,080
created a workaround that nobody revisited.

2174
01:25:49,080 --> 01:25:51,400
If the system copies every habit without question,

2175
01:25:51,400 --> 01:25:54,240
it can preserve waste with impressive mathematical discipline,

2176
01:25:54,240 --> 01:25:55,680
which isn't much of an improvement.

2177
01:25:55,680 --> 01:25:58,920
This needs open testing, especially when rules conflict.

2178
01:25:58,920 --> 01:26:00,640
Picture an urgent order arriving

2179
01:26:00,640 --> 01:26:02,120
while the bottleneck runs a campaign

2180
01:26:02,120 --> 01:26:03,800
that avoids a difficult clean-out.

2181
01:26:03,800 --> 01:26:05,880
Sales wants the urgent job at the front,

2182
01:26:05,880 --> 01:26:07,960
production wants to keep the campaign together

2183
01:26:07,960 --> 01:26:09,400
and the bottleneck plan may show

2184
01:26:09,400 --> 01:26:12,120
that inserting the order consumes enough time

2185
01:26:12,120 --> 01:26:14,440
to put several other deliveries at risk.

2186
01:26:14,440 --> 01:26:16,680
Nobody needs a solver lecture in that meeting.

2187
01:26:16,680 --> 01:26:18,280
The discussion should sound like this.

2188
01:26:18,280 --> 01:26:19,960
If we insert this order now,

2189
01:26:19,960 --> 01:26:22,040
we lose this amount of usable bottleneck time

2190
01:26:22,040 --> 01:26:24,800
to the changeover and these release jobs move.

2191
01:26:24,800 --> 01:26:26,240
If we keep the campaign intact,

2192
01:26:26,240 --> 01:26:27,960
the urgent order finishes later.

2193
01:26:27,960 --> 01:26:30,160
If we approve overtime or an alternative route,

2194
01:26:30,160 --> 01:26:31,520
the result changes again.

2195
01:26:31,520 --> 01:26:33,320
That gives people a decision they can own.

2196
01:26:33,320 --> 01:26:35,480
The scheduling engine can calculate the options,

2197
01:26:35,480 --> 01:26:37,480
but it shouldn't hide the trade-off behind a score

2198
01:26:37,480 --> 01:26:38,560
or a technical label.

2199
01:26:38,560 --> 01:26:42,000
Terms like penalty weight, heuristic, or constrained violation

2200
01:26:42,000 --> 01:26:44,280
may help the technical team build the model,

2201
01:26:44,280 --> 01:26:46,400
but they don't help a shift leader decide

2202
01:26:46,400 --> 01:26:48,200
whether to stage the next job.

2203
01:26:48,200 --> 01:26:50,240
Explain recommendations and operations language.

2204
01:26:50,240 --> 01:26:52,120
Say the order moved because the required tool

2205
01:26:52,120 --> 01:26:53,640
is booked until the next shift,

2206
01:26:53,640 --> 01:26:56,000
the job stayed in sequence because breaking the campaign

2207
01:26:56,000 --> 01:26:57,240
creates a cleaning step

2208
01:26:57,240 --> 01:27:00,080
and consumes the remaining protected time on the bottleneck

2209
01:27:00,080 --> 01:27:01,720
or the plan selected another machine

2210
01:27:01,720 --> 01:27:03,040
because that route is approved

2211
01:27:03,040 --> 01:27:05,360
and keeps the constraint machine available for work

2212
01:27:05,360 --> 01:27:06,640
with no alternative.

2213
01:27:06,640 --> 01:27:08,600
People can challenge clear reasoning.

2214
01:27:08,600 --> 01:27:09,440
That's healthy.

2215
01:27:09,440 --> 01:27:10,760
They can't challenge a black box

2216
01:27:10,760 --> 01:27:13,400
that tells them the schedule is optimized.

2217
01:27:13,400 --> 01:27:15,760
In manufacturing, that word usually lasts

2218
01:27:15,760 --> 01:27:17,040
right up until somebody asks

2219
01:27:17,040 --> 01:27:18,920
which machine will actually run the order.

2220
01:27:18,920 --> 01:27:21,240
This also needs governance, although that doesn't need

2221
01:27:21,240 --> 01:27:22,760
to mean another committee meeting with slides

2222
01:27:22,760 --> 01:27:23,920
nobody requested.

2223
01:27:23,920 --> 01:27:26,120
An override should record who changed the plan,

2224
01:27:26,120 --> 01:27:28,080
what rule or condition justified it

2225
01:27:28,080 --> 01:27:30,040
and what impact the planner accepted.

2226
01:27:30,040 --> 01:27:32,280
That protects the planner as much as the system.

2227
01:27:32,280 --> 01:27:34,240
If an urgent order displaces several jobs,

2228
01:27:34,240 --> 01:27:35,960
the decision becomes visible instead of looking

2229
01:27:35,960 --> 01:27:37,840
like a scheduling error the next morning.

2230
01:27:37,840 --> 01:27:39,960
Master data changes need similar discipline.

2231
01:27:39,960 --> 01:27:42,640
When engineering adds an approved alternative resource,

2232
01:27:42,640 --> 01:27:44,400
when maintenance changes a calendar

2233
01:27:44,400 --> 01:27:46,760
or when quality changes an eligibility rule,

2234
01:27:46,760 --> 01:27:48,160
the scheduling model needs to know

2235
01:27:48,160 --> 01:27:50,760
when that change takes effect and who approved it.

2236
01:27:50,760 --> 01:27:53,120
Otherwise, the schedule mixes yesterday's process rules

2237
01:27:53,120 --> 01:27:54,800
with today's operating conditions.

2238
01:27:54,800 --> 01:27:57,680
Review the overrides and recurring conflicts over time.

2239
01:27:57,680 --> 01:27:59,440
If the same override keeps appearing,

2240
01:27:59,440 --> 01:28:01,360
either the model missed a real rule

2241
01:28:01,360 --> 01:28:03,400
or the plan keeps working around a constraint

2242
01:28:03,400 --> 01:28:04,800
that deserves a different decision.

2243
01:28:04,800 --> 01:28:06,440
So don't judge the scheduling process

2244
01:28:06,440 --> 01:28:07,720
by how many people log into it,

2245
01:28:07,720 --> 01:28:09,960
measure whether it helps people make better decisions

2246
01:28:09,960 --> 01:28:12,760
when the factory can't satisfy every request.

2247
01:28:12,760 --> 01:28:14,760
Measuring the right scheduling outcomes,

2248
01:28:14,760 --> 01:28:17,320
if you want to know whether scheduling is actually improving,

2249
01:28:17,320 --> 01:28:18,960
start with delivery performance.

2250
01:28:18,960 --> 01:28:19,760
Don't stop there though,

2251
01:28:19,760 --> 01:28:22,160
because due date adherence matters for a simple reason.

2252
01:28:22,160 --> 01:28:24,840
It connects the plan to the promise you made a customer.

2253
01:28:24,840 --> 01:28:26,120
But a schedule that hits dates

2254
01:28:26,120 --> 01:28:28,680
by changing every few hours creates a different problem.

2255
01:28:28,680 --> 01:28:30,520
Production might meet the current promise,

2256
01:28:30,520 --> 01:28:32,960
but supervisors, operators, material handlers

2257
01:28:32,960 --> 01:28:35,440
and tool room staff end up spending the whole day

2258
01:28:35,440 --> 01:28:36,880
reacting to a moving target.

2259
01:28:36,880 --> 01:28:38,680
So you need to measure schedule stability

2260
01:28:38,680 --> 01:28:41,080
right alongside due date adherence.

2261
01:28:41,080 --> 01:28:42,760
Ask how often release jobs move,

2262
01:28:42,760 --> 01:28:44,760
how close to execution those moves happen,

2263
01:28:44,760 --> 01:28:47,560
and whether the changes came from confirmed factory events

2264
01:28:47,560 --> 01:28:48,920
or from planning noise.

2265
01:28:48,920 --> 01:28:51,120
You don't need to treat every schedule change as bad,