Why AI Can't Optimize a Factory It Doesn't Understand

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

2
00:00:02,480 --> 00:00:04,480
A machine stops mid-production run.

3
00:00:04,480 --> 00:00:07,600
The planner gets an alarm, checks the MES, opens the ERP,

4
00:00:07,600 --> 00:00:10,240
and within minutes, the simple question turns complicated,

5
00:00:10,240 --> 00:00:12,320
which customer orders are now at risk.

6
00:00:12,320 --> 00:00:14,240
The ERP knows the plan and the ship dates,

7
00:00:14,240 --> 00:00:16,200
the MES knows the operation stopped,

8
00:00:16,200 --> 00:00:19,280
and the machine control layer has the fault code timestamp,

9
00:00:19,280 --> 00:00:21,880
and maybe a temperature reading from right before the stop.

10
00:00:21,880 --> 00:00:23,360
Each system holds part of the story,

11
00:00:23,360 --> 00:00:26,120
so you ask an AI assistant, what should we do?

12
00:00:26,120 --> 00:00:29,200
It can find patterns and downtime data, summarize the alarm,

13
00:00:29,200 --> 00:00:30,720
maybe even suggest a likely cause,

14
00:00:30,720 --> 00:00:33,280
but unless it knows which product ran on that machine,

15
00:00:33,280 --> 00:00:35,920
which order depends on it, what could run elsewhere,

16
00:00:35,920 --> 00:00:37,640
and what production rules apply.

17
00:00:37,640 --> 00:00:39,000
It can't judge the consequence.

18
00:00:39,000 --> 00:00:40,320
That's not a failure of AI.

19
00:00:40,320 --> 00:00:41,320
It's a context problem.

20
00:00:41,320 --> 00:00:43,800
Factories produce more than sensor readings and work orders.

21
00:00:43,800 --> 00:00:46,480
They produce relationships, a machine handles some operations,

22
00:00:46,480 --> 00:00:47,480
but not others.

23
00:00:47,480 --> 00:00:48,880
A tool fits one product family,

24
00:00:48,880 --> 00:00:50,800
but fails a quality check for another.

25
00:00:50,800 --> 00:00:52,640
An operator works nights, but not days.

26
00:00:52,640 --> 00:00:55,080
A late material delivery turns a sensible replay

27
00:00:55,080 --> 00:00:56,440
into a bad call.

28
00:00:56,440 --> 00:00:57,800
AI needs that working knowledge

29
00:00:57,800 --> 00:00:59,680
before it can help with optimization.

30
00:00:59,680 --> 00:01:02,480
So let's follow one disruption through a normal factory day.

31
00:01:02,480 --> 00:01:06,120
A three hour machine failure shows exactly where raw data ends

32
00:01:06,120 --> 00:01:08,800
and real operational understanding has to begin.

33
00:01:08,800 --> 00:01:11,560
A three hour failure is never just a machine failure.

34
00:01:11,560 --> 00:01:14,600
Picture a plant running several product variants

35
00:01:14,600 --> 00:01:16,240
through shared work centers.

36
00:01:16,240 --> 00:01:18,240
Machine four handles a machining operation

37
00:01:18,240 --> 00:01:21,000
that appears in the root for a group of high priority orders

38
00:01:21,000 --> 00:01:22,680
and it stops during an active run.

39
00:01:22,680 --> 00:01:24,080
Maintenance gets the alarm,

40
00:01:24,080 --> 00:01:26,320
production sees the machine state go down,

41
00:01:26,320 --> 00:01:29,400
and the MES logs that the current operation didn't finish.

42
00:01:29,400 --> 00:01:32,400
On paper, it sounds contained, fix machine four and restart it.

43
00:01:32,400 --> 00:01:34,400
But production doesn't pause around a machine

44
00:01:34,400 --> 00:01:36,160
just because the machine paused.

45
00:01:36,160 --> 00:01:38,440
There's already work waiting in front of that operation.

46
00:01:38,440 --> 00:01:41,120
Parts in queue with material allocated, tools ready,

47
00:01:41,120 --> 00:01:42,680
a plant start time.

48
00:01:42,680 --> 00:01:44,840
Other parts have left the machine in wait for inspection

49
00:01:44,840 --> 00:01:45,840
or the next step.

50
00:01:45,840 --> 00:01:48,680
The failure cuts through a chain of work that keeps moving

51
00:01:48,680 --> 00:01:50,360
even when one asset stops.

52
00:01:50,360 --> 00:01:52,320
Say maintenance estimates a three hour outage,

53
00:01:52,320 --> 00:01:53,480
that estimate matters,

54
00:01:53,480 --> 00:01:55,760
but it doesn't answer the plan is real question.

55
00:01:55,760 --> 00:01:57,080
Can the queue orders wait?

56
00:01:57,080 --> 00:01:58,880
Is there another machine that can take the work

57
00:01:58,880 --> 00:02:01,760
and would moving that work create a new bottleneck downstream?

58
00:02:01,760 --> 00:02:04,440
A second machine might show as available in the MES,

59
00:02:04,440 --> 00:02:06,320
but it's scheduled for a different product family

60
00:02:06,320 --> 00:02:07,680
for the next six hours.

61
00:02:07,680 --> 00:02:09,680
Moving the order could require a change over,

62
00:02:09,680 --> 00:02:11,520
a different fixture, a tool check,

63
00:02:11,520 --> 00:02:13,520
and an operator with the right certification.

64
00:02:13,520 --> 00:02:15,440
If the order has tight quality requirements,

65
00:02:15,440 --> 00:02:17,360
the alternate route may need approval

66
00:02:17,360 --> 00:02:18,800
before anyone schedules it.

67
00:02:18,800 --> 00:02:21,280
None of that appears in a simple downtime alarm.

68
00:02:21,280 --> 00:02:22,520
Let's make it concrete.

69
00:02:22,520 --> 00:02:24,840
Machine four runs an operation for an order

70
00:02:24,840 --> 00:02:26,200
due tomorrow morning.

71
00:02:26,200 --> 00:02:28,720
The order has enough material for the planned batch,

72
00:02:28,720 --> 00:02:30,840
but the next operation has limited capacity

73
00:02:30,840 --> 00:02:33,720
because another order already occupies that work center.

74
00:02:33,720 --> 00:02:35,600
If the first operation finishes late,

75
00:02:35,600 --> 00:02:37,920
the downstream station may miss its loading window.

76
00:02:37,920 --> 00:02:40,320
The customer commitment shifts from an ERP date

77
00:02:40,320 --> 00:02:41,960
to a real factory problem.

78
00:02:41,960 --> 00:02:43,560
Can the downstream station work late,

79
00:02:43,560 --> 00:02:44,680
is overtime approved?

80
00:02:44,680 --> 00:02:46,200
Does that create a staffing issue?

81
00:02:46,200 --> 00:02:48,120
Would it delay a higher priority order?

82
00:02:48,120 --> 00:02:49,680
Can the plan ship partial quantities

83
00:02:49,680 --> 00:02:51,480
or does the order need to go out complete?

84
00:02:51,480 --> 00:02:53,200
A planner often knows these answers

85
00:02:53,200 --> 00:02:54,960
because the planner knows the planned.

86
00:02:54,960 --> 00:02:57,640
That knowledge lives in experience, daily conversations,

87
00:02:57,640 --> 00:02:59,160
paper notes, maintenance habits,

88
00:02:59,160 --> 00:03:01,400
and sometimes a spreadsheet that nobody wants to admit

89
00:03:01,400 --> 00:03:02,920
still runs part of production.

90
00:03:02,920 --> 00:03:04,600
And honestly, Excel survives for a reason.

91
00:03:04,600 --> 00:03:06,360
It gives planners a place to combine things

92
00:03:06,360 --> 00:03:08,000
the formal systems haven't connected.

93
00:03:08,000 --> 00:03:09,480
They pull the schedule from one system,

94
00:03:09,480 --> 00:03:11,840
capacity from another, material status from somewhere else,

95
00:03:11,840 --> 00:03:14,000
then add the rules people carry in their heads.

96
00:03:14,000 --> 00:03:16,000
That doesn't mean planners resist modern systems.

97
00:03:16,000 --> 00:03:18,840
It usually means the systems don't yet cover the full decision.

98
00:03:18,840 --> 00:03:21,320
The immediate loss might be three hours of machine time,

99
00:03:21,320 --> 00:03:23,840
but the operational consequences last much longer.

100
00:03:23,840 --> 00:03:25,840
Work piles up, downstream stations,

101
00:03:25,840 --> 00:03:29,200
wait or change sequences, operators move to other tasks,

102
00:03:29,200 --> 00:03:31,120
quality checks shift, and delivery risks

103
00:03:31,120 --> 00:03:34,280
spreads to orders that never touched machine for directly.

104
00:03:34,280 --> 00:03:36,040
Even the repair has context.

105
00:03:36,040 --> 00:03:37,880
Maintenance might need a spare part,

106
00:03:37,880 --> 00:03:40,080
a lockout procedure, and after restart,

107
00:03:40,080 --> 00:03:42,360
a warm-up run, first off inspection,

108
00:03:42,360 --> 00:03:44,880
or process check before the machine is ready.

109
00:03:44,880 --> 00:03:47,520
Machine available doesn't always mean machine ready

110
00:03:47,520 --> 00:03:48,600
for this order.

111
00:03:48,600 --> 00:03:50,880
So the planner doesn't eat another red alarm on a dashboard.

112
00:03:50,880 --> 00:03:52,480
The planner needs options.

113
00:03:52,480 --> 00:03:54,480
Option one, keep work on machine four

114
00:03:54,480 --> 00:03:56,000
and accept a controlled delay.

115
00:03:56,000 --> 00:03:59,000
Option two, move selected orders to another resource,

116
00:03:59,000 --> 00:04:01,440
but only the ones with the right tooling and approved root.

117
00:04:01,440 --> 00:04:03,720
Option three, change the downstream sequence

118
00:04:03,720 --> 00:04:06,480
to protect tomorrow's order while a lower priority order

119
00:04:06,480 --> 00:04:07,080
waits.

120
00:04:07,080 --> 00:04:08,840
Each option carries trade-offs.

121
00:04:08,840 --> 00:04:10,600
Each depends on facts from different parts

122
00:04:10,600 --> 00:04:12,080
of the business and the shop floor.

123
00:04:12,080 --> 00:04:14,520
Before we ask AI to choose among those options,

124
00:04:14,520 --> 00:04:16,560
we need to ask a simpler question.

125
00:04:16,560 --> 00:04:18,600
What can each existing system actually

126
00:04:18,600 --> 00:04:20,480
answer about the situation?

127
00:04:20,480 --> 00:04:24,760
Every system knows something, nobody knows the whole situation.

128
00:04:24,760 --> 00:04:27,520
Let's start with ERP, the enterprise resource planning

129
00:04:27,520 --> 00:04:28,400
system.

130
00:04:28,400 --> 00:04:30,080
It holds the business side of production,

131
00:04:30,080 --> 00:04:32,800
demand, sales orders, planned work orders, purchase

132
00:04:32,800 --> 00:04:35,920
material, inventory positions, and promised ship dates,

133
00:04:35,920 --> 00:04:39,320
often with a planning horizon well beyond the current shift.

134
00:04:39,320 --> 00:04:41,120
For a planner dealing with an outage,

135
00:04:41,120 --> 00:04:44,480
ERP can answer which orders matter commercially, which

136
00:04:44,480 --> 00:04:47,600
materials are expected, and which dates the plant has committed

137
00:04:47,600 --> 00:04:48,200
to.

138
00:04:48,200 --> 00:04:49,240
That's useful.

139
00:04:49,240 --> 00:04:50,040
But here's the catch.

140
00:04:50,040 --> 00:04:53,320
ERP usually works from planned capacity and planned routes,

141
00:04:53,320 --> 00:04:56,080
so it may not know that a machine stopped 10 minutes ago,

142
00:04:56,080 --> 00:04:58,200
or that a tool is sitting in inspection.

143
00:04:58,200 --> 00:05:00,520
The MES operates much closer to execution.

144
00:05:00,520 --> 00:05:02,760
It records which work order enter the work center,

145
00:05:02,760 --> 00:05:05,040
how many units pass through an operation, where work

146
00:05:05,040 --> 00:05:08,200
and progress sits, and whether a step past or failed.

147
00:05:08,200 --> 00:05:09,560
It can tell you that an operation

148
00:05:09,560 --> 00:05:12,600
started, paused, completed, or produced scrap.

149
00:05:12,600 --> 00:05:14,240
That gives the plant a record of work

150
00:05:14,240 --> 00:05:15,840
moving through the process.

151
00:05:15,840 --> 00:05:18,160
Yet an MES may not carry every commercial rule

152
00:05:18,160 --> 00:05:20,880
from ERP, and it may not know the real condition

153
00:05:20,880 --> 00:05:22,840
of a spare part in the maintenance store.

154
00:05:22,840 --> 00:05:24,440
It knows a lot about execution, but it

155
00:05:24,440 --> 00:05:26,160
doesn't automatically hold the full reason

156
00:05:26,160 --> 00:05:27,320
for a planning decision.

157
00:05:27,320 --> 00:05:30,360
Below that, the control layer deals with the physical event.

158
00:05:30,360 --> 00:05:33,120
A programmable logic controller, or PLC,

159
00:05:33,120 --> 00:05:35,200
sees inputs and outputs in milliseconds,

160
00:05:35,200 --> 00:05:38,360
detecting an interlock, a fault, a motor state, a pressure

161
00:05:38,360 --> 00:05:40,040
limit, or a cycle signal.

162
00:05:40,040 --> 00:05:41,960
An IoT layer can collect those signals,

163
00:05:41,960 --> 00:05:44,640
standardize them, wear practical, and move selected events

164
00:05:44,640 --> 00:05:46,600
into systems outside the machine network.

165
00:05:46,600 --> 00:05:48,760
A historian may retain time series process data

166
00:05:48,760 --> 00:05:51,080
so engineers can study what happened before,

167
00:05:51,080 --> 00:05:52,640
during, and after a stop.

168
00:05:52,640 --> 00:05:55,880
That data can be precise, but it can also be deeply local.

169
00:05:55,880 --> 00:05:59,040
A tag like M4 Drive fault tells a controls engineer something

170
00:05:59,040 --> 00:06:01,560
useful, but it doesn't tell a production planner

171
00:06:01,560 --> 00:06:03,920
whether the fault affects a customer delivery.

172
00:06:03,920 --> 00:06:05,760
The tag describes a signal, not the work that

173
00:06:05,760 --> 00:06:08,080
depends on the machine, the approved alternatives,

174
00:06:08,080 --> 00:06:09,960
or the people needed to carry out a change.

175
00:06:09,960 --> 00:06:12,360
Maintenance adds another part of the picture.

176
00:06:12,360 --> 00:06:15,320
It's system may track work requests, asset records,

177
00:06:15,320 --> 00:06:18,280
plan service, repair history, spare parts,

178
00:06:18,280 --> 00:06:20,040
and technician activity.

179
00:06:20,040 --> 00:06:22,680
A maintenance lead can judge whether a fault looks like a quick

180
00:06:22,680 --> 00:06:25,520
reset, a known recurring issue, or a job that needs a supplier

181
00:06:25,520 --> 00:06:28,360
call, but maintenance planning follows its own rules.

182
00:06:28,360 --> 00:06:30,760
The system may identify the asset by a maintenance number

183
00:06:30,760 --> 00:06:32,920
that doesn't match the work center code in the MES.

184
00:06:32,920 --> 00:06:34,240
Nobody did anything wrong.

185
00:06:34,240 --> 00:06:36,440
The systems just grew around different jobs.

186
00:06:36,440 --> 00:06:38,080
Quality carries another set of facts.

187
00:06:38,080 --> 00:06:40,360
Inspection results, non-conformance records, product

188
00:06:40,360 --> 00:06:43,000
release rules, sampling plans, and process approvals

189
00:06:43,000 --> 00:06:45,440
can decide whether work can move or restart.

190
00:06:45,440 --> 00:06:48,120
A schedule that ignores quality rules isn't a schedule.

191
00:06:48,120 --> 00:06:49,720
It's a wish list with dates.

192
00:06:49,720 --> 00:06:52,600
Then there's the information that rarely fits neatly anywhere.

193
00:06:52,600 --> 00:06:55,040
A shift supervisor knows that one alternate machine

194
00:06:55,040 --> 00:06:57,240
has been temperamental since a recent repair,

195
00:06:57,240 --> 00:06:59,840
an operator knows the fixture for a product is available,

196
00:06:59,840 --> 00:07:02,320
but only after a colleague finishes a current run.

197
00:07:02,320 --> 00:07:04,600
A production planner knows a customer may accept a partial

198
00:07:04,600 --> 00:07:07,560
shipment, even though the ERP order doesn't state that clearly.

199
00:07:07,560 --> 00:07:09,200
This is why spreadsheets keep showing up

200
00:07:09,200 --> 00:07:10,600
between formal systems.

201
00:07:10,600 --> 00:07:12,520
They fill gaps, letting people create

202
00:07:12,520 --> 00:07:15,400
temporary links between orders, capacity, people,

203
00:07:15,400 --> 00:07:19,160
and local rules, because the decision crosses system boundaries.

204
00:07:19,160 --> 00:07:21,560
Sometimes that spreadsheet becomes a carefully managed planning

205
00:07:21,560 --> 00:07:23,040
tool, sometimes it becomes a file

206
00:07:23,040 --> 00:07:25,360
called schedule final, really final V7,

207
00:07:25,360 --> 00:07:27,440
but both situations point to the same issue.

208
00:07:27,440 --> 00:07:30,240
The plant needs a shared way to connect facts.

209
00:07:30,240 --> 00:07:32,520
As a Microsoft MVP, I spend a lot of time

210
00:07:32,520 --> 00:07:35,760
around Azure, Fabric, Power BI, and Power Platform projects.

211
00:07:35,760 --> 00:07:38,840
Bringing ERP, MES, Maintenance, Quality, and IoT data

212
00:07:38,840 --> 00:07:41,360
into a shared environment can remove a lot of manual effort

213
00:07:41,360 --> 00:07:44,640
and improve access, traceability, and real-time visibility.

214
00:07:44,640 --> 00:07:47,160
Still, collection doesn't create common meaning

215
00:07:47,160 --> 00:07:50,560
if ERP calls something a production order, MES calls it a work order,

216
00:07:50,560 --> 00:07:54,200
maintenance knows only the asset, and the IoT feed knows a tag path,

217
00:07:54,200 --> 00:07:55,880
putting every record in one data platform

218
00:07:55,880 --> 00:07:58,520
doesn't tell the system how those records relate.

219
00:07:58,520 --> 00:08:01,760
You've gathered the pages, but you haven't connected the story.

220
00:08:01,760 --> 00:08:03,560
That brings us to the real challenge.

221
00:08:03,560 --> 00:08:05,760
Data only becomes operational understanding

222
00:08:05,760 --> 00:08:08,040
when the factory can state what each fact means,

223
00:08:08,040 --> 00:08:11,680
what it connects to, and which rules govern the decision.

224
00:08:11,680 --> 00:08:13,880
The difference between data and context.

225
00:08:13,880 --> 00:08:18,120
A production system can record a temperature of 92 degrees,

226
00:08:18,120 --> 00:08:21,320
a stopcode, a cycle count, and a timestamp.

227
00:08:21,320 --> 00:08:23,760
Those are facts, accurate and timestamped,

228
00:08:23,760 --> 00:08:26,200
easy to store in a data platform.

229
00:08:26,200 --> 00:08:30,160
Still, none of those facts explains the operational meaning on its own.

230
00:08:30,160 --> 00:08:32,800
Take a machine stopcode, the same code may appear during

231
00:08:32,800 --> 00:08:35,960
an automated changeover, during a planned maintenance task,

232
00:08:35,960 --> 00:08:39,840
or halfway through a batch that must not sit idle beyond a defined time.

233
00:08:39,840 --> 00:08:43,560
The code looks identical in a table, but the production consequence doesn't.

234
00:08:43,560 --> 00:08:46,360
Context answers the questions around the signal.

235
00:08:46,360 --> 00:08:48,120
Which asset produced this event?

236
00:08:48,120 --> 00:08:50,400
Which physical location that asset occupies,

237
00:08:50,400 --> 00:08:52,160
what operation ran at the time?

238
00:08:52,160 --> 00:08:55,320
Which product, batch, and work order that operation belonged to?

239
00:08:55,320 --> 00:08:57,960
Which shift owned the work, what condition triggered the alarm,

240
00:08:57,960 --> 00:09:00,320
and which rules limit the next action?

241
00:09:00,320 --> 00:09:01,560
That's the difference.

242
00:09:01,560 --> 00:09:03,360
Data tells you that an event occurred,

243
00:09:03,360 --> 00:09:07,560
context tells you what that event means in the factory and what it may affect next.

244
00:09:07,560 --> 00:09:09,360
Think about a cycle count from a press.

245
00:09:09,360 --> 00:09:13,160
On its own, a count rising every few seconds may suggest normal production,

246
00:09:13,160 --> 00:09:15,480
but connected to the planned operation,

247
00:09:15,480 --> 00:09:17,800
the target quantity, the material lot,

248
00:09:17,800 --> 00:09:20,480
the current tool, and the inspection rule,

249
00:09:20,480 --> 00:09:23,280
and the same signal can tell a different story.

250
00:09:23,280 --> 00:09:25,160
Maybe the press runs at the expected rate,

251
00:09:25,160 --> 00:09:28,360
but produces parts from a material lot now blocked by quality,

252
00:09:28,360 --> 00:09:29,960
maybe it reaches the planned quantity,

253
00:09:29,960 --> 00:09:31,480
but the operation still can't close,

254
00:09:31,480 --> 00:09:33,880
because a required inspection hasn't passed.

255
00:09:33,880 --> 00:09:35,480
Or maybe the count looks low,

256
00:09:35,480 --> 00:09:39,240
only because the machine entered a planned trial run after a tool change.

257
00:09:39,240 --> 00:09:41,280
The number didn't change, but its meaning changed.

258
00:09:41,280 --> 00:09:43,800
That's why data projects can look successful and still struggle

259
00:09:43,800 --> 00:09:45,240
when people ask for action.

260
00:09:45,240 --> 00:09:47,200
You can ingest millions of machine events,

261
00:09:47,200 --> 00:09:50,520
join them to production records, and build clean reports.

262
00:09:50,520 --> 00:09:53,160
Yet if the model doesn't state how an event relates to an order,

263
00:09:53,160 --> 00:09:55,480
a root, a resource limit, and a production rule,

264
00:09:55,480 --> 00:09:58,080
an AI system can only infer.

265
00:09:58,080 --> 00:10:00,080
An inference can be risky in a factory.

266
00:10:00,080 --> 00:10:02,480
A generic AI model may read that machine force stopped,

267
00:10:02,480 --> 00:10:04,120
see that another machine looks idle,

268
00:10:04,120 --> 00:10:05,400
and suggest moving work.

269
00:10:05,400 --> 00:10:07,680
That sounds sensible until you add the missing facts.

270
00:10:07,680 --> 00:10:09,520
The other machine may lack the approved fixture,

271
00:10:09,520 --> 00:10:12,400
it may only run the product after a setup process.

272
00:10:12,400 --> 00:10:15,400
The available operator may not hold the required certification,

273
00:10:15,400 --> 00:10:19,840
or the batch may sit at a stage where re-routing breaks a quality rule.

274
00:10:19,840 --> 00:10:22,520
The AI didn't fail because it lacks language skills.

275
00:10:22,520 --> 00:10:25,800
It failed because nobody gave it the factory's working relationships.

276
00:10:25,800 --> 00:10:28,640
This is where the phrase "Somantic Layer" comes in.

277
00:10:28,640 --> 00:10:30,160
It sounds more abstract than it needs to,

278
00:10:30,160 --> 00:10:33,480
but it's simply a shared way to state what records mean

279
00:10:33,480 --> 00:10:35,040
and how the factory connects them.

280
00:10:35,040 --> 00:10:37,280
It can state that this event came from this asset,

281
00:10:37,280 --> 00:10:39,720
that the asset performs this operation under these conditions

282
00:10:39,720 --> 00:10:42,680
for this product family, that the operation belongs to this root

283
00:10:42,680 --> 00:10:44,480
which fulfills this work order,

284
00:10:44,480 --> 00:10:47,280
and it can also state the limits, approved tools,

285
00:10:47,280 --> 00:10:50,640
material rules, quality gates, maintenance status,

286
00:10:50,640 --> 00:10:52,680
and available capacity.

287
00:10:52,680 --> 00:10:56,160
You're moving from rows of records to a model of the operating situation.

288
00:10:56,160 --> 00:10:59,200
That model doesn't need to copy every detail from ERP,

289
00:10:59,200 --> 00:11:00,960
MES, quality, or maintenance.

290
00:11:00,960 --> 00:11:03,760
In fact, it shouldn't pretend it owns all the source truth.

291
00:11:03,760 --> 00:11:05,960
The source system still managed their own records

292
00:11:05,960 --> 00:11:08,920
and the semantic layer connects the facts that a decision needs

293
00:11:08,920 --> 00:11:12,480
while keeping a clear path back to where each fact came from.

294
00:11:12,480 --> 00:11:14,760
This also changes how you think about AI.

295
00:11:14,760 --> 00:11:18,120
Rather than asking an AI assistant to optimize production,

296
00:11:18,120 --> 00:11:19,960
you can ask it a grounded question,

297
00:11:19,960 --> 00:11:22,000
which orders face risk from this stop,

298
00:11:22,000 --> 00:11:24,840
which approved resources could run the affected operation,

299
00:11:24,840 --> 00:11:27,400
and which constraints block each option.

300
00:11:27,400 --> 00:11:28,920
Now the answer can include reasons.

301
00:11:28,920 --> 00:11:30,960
It can say an alternate resource exists,

302
00:11:30,960 --> 00:11:33,600
but is unavailable until a current order ends,

303
00:11:33,600 --> 00:11:35,760
that another root would need a quality approval,

304
00:11:35,760 --> 00:11:38,400
or that the material allocation prevents a move.

305
00:11:38,400 --> 00:11:39,760
Those aren't just answers.

306
00:11:39,760 --> 00:11:41,240
They are operational explanations

307
00:11:41,240 --> 00:11:43,800
that a planner can challenge, confirm, or act on.

308
00:11:43,800 --> 00:11:45,880
Relationships are the unit of understanding.

309
00:11:45,880 --> 00:11:48,640
A larger pile of rows doesn't create them automatically,

310
00:11:48,640 --> 00:11:50,920
even when every row sits in the same lake house.

311
00:11:50,920 --> 00:11:53,920
You need to name the entities, connect them with explicit rules,

312
00:11:53,920 --> 00:11:56,360
and keep the model close enough to the live factory

313
00:11:56,360 --> 00:11:59,800
that its answers still hold when decisions need to happen.

314
00:11:59,800 --> 00:12:02,640
Once you see that distinction, dashboards start to look different, too.

315
00:12:02,640 --> 00:12:04,280
A dashboard can show a change,

316
00:12:04,280 --> 00:12:05,840
but the moment someone asks,

317
00:12:05,840 --> 00:12:07,520
what production should move next,

318
00:12:07,520 --> 00:12:10,240
the problem shifts from reporting to decision making.

319
00:12:10,240 --> 00:12:12,680
Why a dashboard cannot run the factory?

320
00:12:12,680 --> 00:12:16,520
Power BI can give a plant a clearer view of what's happening.

321
00:12:16,520 --> 00:12:19,040
You track OEE, downtime, output, scrap,

322
00:12:19,040 --> 00:12:22,040
late orders, and work in progress across shifts, lines and plants,

323
00:12:22,040 --> 00:12:24,760
all in one place, so production leaders can ask better questions.

324
00:12:24,760 --> 00:12:27,520
That's useful, but a dashboard still reports a view of the factory

325
00:12:27,520 --> 00:12:29,720
after someone has chosen the measures, joined the data,

326
00:12:29,720 --> 00:12:31,840
and decided what each measure means.

327
00:12:31,840 --> 00:12:35,400
Picture that planner from our machine-outage scenario opening a report.

328
00:12:35,400 --> 00:12:38,240
It shows machine-fall down, a growing queue before the operation,

329
00:12:38,240 --> 00:12:40,480
and several orders with rising delay risk.

330
00:12:40,480 --> 00:12:43,760
Maybe it even shows available capacity at other work centers.

331
00:12:43,760 --> 00:12:46,600
Useful information, but still not a production decision.

332
00:12:46,600 --> 00:12:48,000
The planner looks at the same report

333
00:12:48,000 --> 00:12:50,520
and immediately adds things the report can't know.

334
00:12:50,520 --> 00:12:52,920
They remember one alternate machine has a tool change

335
00:12:52,920 --> 00:12:54,320
booked later in the shift,

336
00:12:54,320 --> 00:12:55,720
an operator can run the product,

337
00:12:55,720 --> 00:12:57,800
but only after finishing a quality check.

338
00:12:57,800 --> 00:13:01,280
One customer order can move, another needs to stay together as a batch.

339
00:13:01,280 --> 00:13:03,400
Most reports depend on that human layer.

340
00:13:03,400 --> 00:13:06,920
The planner reads the numbers, checks the floor, calls maintenance,

341
00:13:06,920 --> 00:13:09,720
talks to quality, and weighs the commercial impact.

342
00:13:09,720 --> 00:13:11,800
That doesn't mean the dashboard failed.

343
00:13:11,800 --> 00:13:14,000
It means the dashboard has a defined job.

344
00:13:14,000 --> 00:13:16,200
It answers questions like, what changed?

345
00:13:16,200 --> 00:13:17,640
Where is the queue building?

346
00:13:17,640 --> 00:13:19,320
Which work center lost time?

347
00:13:19,320 --> 00:13:20,720
Those are reporting questions,

348
00:13:20,720 --> 00:13:23,640
and they matter because people need a shared view before they can act.

349
00:13:23,640 --> 00:13:26,000
The next question changes the work completely.

350
00:13:26,000 --> 00:13:27,440
What should move next?

351
00:13:27,440 --> 00:13:28,920
That means a list of allowed actions,

352
00:13:28,920 --> 00:13:30,480
the rules around each action,

353
00:13:30,480 --> 00:13:32,560
and an estimate of the effects that follow.

354
00:13:32,560 --> 00:13:34,400
A report can show resource B looks free.

355
00:13:34,400 --> 00:13:37,200
It doesn't automatically know whether resource B can legally

356
00:13:37,200 --> 00:13:40,120
and technically run the affected operation at that moment

357
00:13:40,120 --> 00:13:42,480
with the material tool, process settings,

358
00:13:42,480 --> 00:13:44,000
and people actually available.

359
00:13:44,000 --> 00:13:45,720
You can put more logic into a dashboard.

360
00:13:45,720 --> 00:13:47,920
Add calculated measures, drill through paths,

361
00:13:47,920 --> 00:13:49,680
exception lists, and alert rules,

362
00:13:49,680 --> 00:13:51,600
build an excellent operational cockpit.

363
00:13:51,600 --> 00:13:53,320
I'm not arguing against that.

364
00:13:53,320 --> 00:13:55,480
In many plans, it's the right next step

365
00:13:55,480 --> 00:13:57,960
because teams first need trusted visibility.

366
00:13:57,960 --> 00:14:00,560
But there's a point where the report starts carrying decision logic

367
00:14:00,560 --> 00:14:02,120
that belongs somewhere more explicit.

368
00:14:02,120 --> 00:14:05,320
You see it when measures turn into long chains of special cases.

369
00:14:05,320 --> 00:14:07,280
You see it when planners export data

370
00:14:07,280 --> 00:14:09,880
because the report can't test a realistic option.

371
00:14:09,880 --> 00:14:12,600
You see it when the answer needs a note beside it saying,

372
00:14:12,600 --> 00:14:16,600
this only applies if the fixture is free and quality approves.

373
00:14:16,600 --> 00:14:18,800
That note doesn't just contain a reporting caveat.

374
00:14:18,800 --> 00:14:20,000
It contains a factory rule.

375
00:14:20,000 --> 00:14:21,800
Excel often takes over at this point

376
00:14:21,800 --> 00:14:24,000
because it lets the planner work through the messy part.

377
00:14:24,000 --> 00:14:26,200
They copy an order list, move a few rows,

378
00:14:26,200 --> 00:14:28,600
add a comment about tooling, changes start time,

379
00:14:28,600 --> 00:14:30,480
and check whether the plan still seems plausible.

380
00:14:30,480 --> 00:14:32,160
It's flexible, it's fast.

381
00:14:32,160 --> 00:14:34,240
And it can become fragile when five people

382
00:14:34,240 --> 00:14:36,160
edit different versions under pressure.

383
00:14:36,160 --> 00:14:38,120
The spreadsheet isn't the root problem.

384
00:14:38,120 --> 00:14:40,480
It's a sign that the planning decision needs relationships

385
00:14:40,480 --> 00:14:42,680
and constraints that haven't found a proper home.

386
00:14:42,680 --> 00:14:43,920
There's also a timing issue.

387
00:14:43,920 --> 00:14:46,600
A daily dashboard may help a manager spot a trend

388
00:14:46,600 --> 00:14:48,120
yet an outage demands a response

389
00:14:48,120 --> 00:14:49,800
while the shift still has time to recover.

390
00:14:49,800 --> 00:14:51,320
People need current facts,

391
00:14:51,320 --> 00:14:52,880
but current facts alone won't tell them

392
00:14:52,880 --> 00:14:54,520
which action protects delivery

393
00:14:54,520 --> 00:14:56,800
without causing a worse problem later in the route.

394
00:14:56,800 --> 00:14:58,960
So don't ask a dashboard to run the factory.

395
00:14:58,960 --> 00:15:01,040
Ask it to make the factory easier to see,

396
00:15:01,040 --> 00:15:03,120
easier to question and easier to trust.

397
00:15:03,120 --> 00:15:06,040
Then give the decision process its own model of resources,

398
00:15:06,040 --> 00:15:08,200
work, limits, and consequences.

399
00:15:08,200 --> 00:15:11,040
That move from reporting to action forces a distinction

400
00:15:11,040 --> 00:15:13,360
that gets lost in a lot of AI conversations.

401
00:15:13,360 --> 00:15:15,800
A system that predicts a problem doesn't necessarily

402
00:15:15,800 --> 00:15:18,400
know how to choose the best feasible response.

403
00:15:18,400 --> 00:15:21,080
Prediction is not optimization.

404
00:15:21,080 --> 00:15:23,400
A system can predict that a machine may fail soon.

405
00:15:23,400 --> 00:15:25,000
It can predict that an order now carries

406
00:15:25,000 --> 00:15:26,800
a high risk of missing its due date.

407
00:15:26,800 --> 00:15:28,640
Both can help a planner act earlier,

408
00:15:28,640 --> 00:15:31,000
but neither prediction chooses the plan.

409
00:15:31,000 --> 00:15:33,160
Think about the difference in the machine four case.

410
00:15:33,160 --> 00:15:35,160
A predictive model might examine past faults,

411
00:15:35,160 --> 00:15:38,040
vibration reading, cycle patterns, or maintenance records

412
00:15:38,040 --> 00:15:41,200
then estimate that the machine faces a higher chance of failure.

413
00:15:41,200 --> 00:15:42,880
That gives maintenance a reason to inspect it

414
00:15:42,880 --> 00:15:45,680
before the shift loses production time.

415
00:15:45,680 --> 00:15:47,760
A late order model works similarly.

416
00:15:47,760 --> 00:15:51,240
Compare current progress, queue time, expected run time,

417
00:15:51,240 --> 00:15:53,960
and past production patterns, then flag and order

418
00:15:53,960 --> 00:15:55,320
as likely to finish late.

419
00:15:55,320 --> 00:15:56,320
Again, useful.

420
00:15:56,320 --> 00:15:58,560
The system has identified risk, but then somebody

421
00:15:58,560 --> 00:15:59,920
still needs to decide what to do.

422
00:15:59,920 --> 00:16:01,400
Optimization has a different job.

423
00:16:01,400 --> 00:16:02,840
It searches through possible actions

424
00:16:02,840 --> 00:16:05,200
and selects options that meet the rules you've said.

425
00:16:05,200 --> 00:16:07,480
In production, that might mean testing which orders

426
00:16:07,480 --> 00:16:10,040
can move where they can move when they can start

427
00:16:10,040 --> 00:16:12,760
and what each choice does to the rest of the schedule.

428
00:16:12,760 --> 00:16:14,680
That word feasible matters a lot.

429
00:16:14,680 --> 00:16:16,920
A schedule can look attractive because it cuts late orders

430
00:16:16,920 --> 00:16:18,320
or increases machine use.

431
00:16:18,320 --> 00:16:21,080
Yet, it may fail the moment it reaches the shop floor.

432
00:16:21,080 --> 00:16:23,320
The material might not be at the alternate machine.

433
00:16:23,320 --> 00:16:25,560
The tool might be in use, a setup may take longer

434
00:16:25,560 --> 00:16:26,760
than the remaining shift.

435
00:16:26,760 --> 00:16:28,600
The sequence may break a process rule.

436
00:16:28,600 --> 00:16:30,720
Maintenance may have reserved the resource.

437
00:16:30,720 --> 00:16:32,560
Quality may need to approve the change.

438
00:16:32,560 --> 00:16:34,320
So an optimizer needs more than a target

439
00:16:34,320 --> 00:16:36,000
like reduced lateness.

440
00:16:36,000 --> 00:16:37,560
It needs the rules that define a plan

441
00:16:37,560 --> 00:16:39,360
the factory can actually execute.

442
00:16:39,360 --> 00:16:40,840
Some rules aren't negotiable.

443
00:16:40,840 --> 00:16:44,280
Safety limits, approved recipes, material compatibility,

444
00:16:44,280 --> 00:16:46,800
and operator certification belong in that category.

445
00:16:46,800 --> 00:16:49,360
If an alternate machine can't run a process safely

446
00:16:49,360 --> 00:16:51,240
or within an approved quality window,

447
00:16:51,240 --> 00:16:53,800
the system must remove it from the option set.

448
00:16:53,800 --> 00:16:55,640
Other rules involve trade-offs.

449
00:16:55,640 --> 00:16:58,720
A plan may accept over time to protect a customer date.

450
00:16:58,720 --> 00:17:00,720
It may accept an extra change over to prevent

451
00:17:00,720 --> 00:17:02,040
a much larger delay.

452
00:17:02,040 --> 00:17:04,680
It may choose to keep a lower margin order waiting

453
00:17:04,680 --> 00:17:06,720
if that protects a contractual commitment.

454
00:17:06,720 --> 00:17:09,040
There isn't always one mathematically perfect answer

455
00:17:09,040 --> 00:17:12,600
because people still decide which business cost they want to accept.

456
00:17:12,600 --> 00:17:14,840
That's why optimization needs clear objectives

457
00:17:14,840 --> 00:17:16,560
and those objectives need owners.

458
00:17:16,560 --> 00:17:19,320
Do you want to protect due dates first, reduce change overs,

459
00:17:19,320 --> 00:17:22,480
avoid over time, keep a line stable, limit energy use

460
00:17:22,480 --> 00:17:24,760
during peak periods, each goal pulls the schedule

461
00:17:24,760 --> 00:17:26,680
in a slightly different direction.

462
00:17:26,680 --> 00:17:28,640
A planning team needs to state those priorities

463
00:17:28,640 --> 00:17:30,880
instead of hoping an AI model somehow picks up

464
00:17:30,880 --> 00:17:32,240
the unwritten rules of the plant.

465
00:17:32,240 --> 00:17:35,440
Generative AI has a place here, but its role needs to stay clear.

466
00:17:35,440 --> 00:17:38,680
A conversational assistant can explain why an order carries risk.

467
00:17:38,680 --> 00:17:40,480
It can answer questions in plain language.

468
00:17:40,480 --> 00:17:42,120
It can gather the facts of plan or needs,

469
00:17:42,120 --> 00:17:45,880
compare scenarios, and help create a handover note for the next shift.

470
00:17:45,880 --> 00:17:48,320
That can remove a lot of searching across systems.

471
00:17:48,320 --> 00:17:50,720
But it shouldn't act like a hidden scheduling engine.

472
00:17:50,720 --> 00:17:54,000
Language models generate likely text based on patterns in their input.

473
00:17:54,000 --> 00:17:56,640
They don't naturally prove that a production plan obeys

474
00:17:56,640 --> 00:18:01,240
every material rule, capacity limit, sequence rule, and quality restriction.

475
00:18:01,240 --> 00:18:04,320
You can ask one to suggest a replay and it may produce something

476
00:18:04,320 --> 00:18:05,960
that sounds entirely reasonable.

477
00:18:05,960 --> 00:18:09,320
A confident sentence doesn't reserve a tool or qualify an operator.

478
00:18:09,320 --> 00:18:11,480
This is why the architecture needs distinct jobs.

479
00:18:11,480 --> 00:18:13,400
Predictive models estimate likelihoods,

480
00:18:13,400 --> 00:18:16,920
optimization engines search for feasible choices within stated limits.

481
00:18:16,920 --> 00:18:19,480
A generative AI layer helps people ask questions,

482
00:18:19,480 --> 00:18:22,560
understand results, and move work through an approved process.

483
00:18:22,560 --> 00:18:25,160
And deterministic checks, rule based checks

484
00:18:25,160 --> 00:18:27,560
that produce the same result from the same inputs,

485
00:18:27,560 --> 00:18:31,120
verify that a proposed action meets the conditions you've defined.

486
00:18:31,120 --> 00:18:32,400
Those parts can work together.

487
00:18:32,400 --> 00:18:34,360
They just shouldn't pretend to be the same thing.

488
00:18:34,360 --> 00:18:37,480
Take a planner asking, can we still ship order 8.1 scene on time

489
00:18:37,480 --> 00:18:39,200
after machine four stops?

490
00:18:39,200 --> 00:18:41,920
A prediction might answer, risk is high.

491
00:18:41,920 --> 00:18:42,960
That's a warning.

492
00:18:42,960 --> 00:18:45,120
An optimization process might respond,

493
00:18:45,120 --> 00:18:47,360
there are two feasible schedules that preserve the date,

494
00:18:47,360 --> 00:18:50,840
but one needs overtime and the other moves a lower priority order.

495
00:18:50,840 --> 00:18:52,200
That's a decision option.

496
00:18:52,200 --> 00:18:54,760
Then the AI assistant can explain the trade-off in language

497
00:18:54,760 --> 00:18:58,560
the planner, production supervisor, and customer service team can discuss.

498
00:18:58,560 --> 00:19:01,640
It can also point back to the facts and rules behind the answer,

499
00:19:01,640 --> 00:19:04,520
rather than inventing a cheerful plan from a few rows of data.

500
00:19:04,520 --> 00:19:07,120
So when someone says they want AI to optimize production,

501
00:19:07,120 --> 00:19:08,640
I'd ask a few practical questions.

502
00:19:08,640 --> 00:19:11,640
What decision should improve which options counters allowed,

503
00:19:11,640 --> 00:19:13,560
which constraints must never be broken,

504
00:19:13,560 --> 00:19:15,600
and who decides between the remaining trade-offs?

505
00:19:15,600 --> 00:19:18,680
Those questions define what factory understanding really means,

506
00:19:18,680 --> 00:19:22,160
what factory understanding actually means.

507
00:19:22,160 --> 00:19:24,320
Let's define what factory understanding actually means.

508
00:19:24,320 --> 00:19:27,880
It doesn't need to copy the judgment of a planner with 20 years on the floor.

509
00:19:27,880 --> 00:19:30,760
It needs a working model of the things involved in a decision,

510
00:19:30,760 --> 00:19:34,560
the links between them, and the conditions that limit what can happen.

511
00:19:34,560 --> 00:19:37,360
For production, I start with product, process, and resource.

512
00:19:37,360 --> 00:19:39,560
The product is what the plant needs to produce.

513
00:19:39,560 --> 00:19:42,040
That sounds obvious, but it means more than a part number.

514
00:19:42,040 --> 00:19:44,840
It may include a revision, a product family, a batch rule,

515
00:19:44,840 --> 00:19:47,480
a material grade, a customer-specific requirement,

516
00:19:47,480 --> 00:19:50,240
and quality conditions that apply only to that product.

517
00:19:50,240 --> 00:19:53,080
A process describes how that product moves through the plant,

518
00:19:53,080 --> 00:19:55,720
including the required operations, their sequence,

519
00:19:55,720 --> 00:19:58,960
possible alternate steps, inspection points, set-up needs,

520
00:19:58,960 --> 00:20:01,320
and rules for what counts as complete.

521
00:20:01,320 --> 00:20:02,800
Two products may use the same machine,

522
00:20:02,800 --> 00:20:04,280
but follow different process rules,

523
00:20:04,280 --> 00:20:07,480
and that difference decides whether a replan works or creates scrap.

524
00:20:07,480 --> 00:20:08,640
Then you have the resources.

525
00:20:08,640 --> 00:20:12,840
A resource can be a machine, a fixture, a cutting tool, a furnace zone,

526
00:20:12,840 --> 00:20:15,720
a test station, a forklift, or a person.

527
00:20:15,720 --> 00:20:19,720
Production planning often treats capacity as if it lives inside a work center,

528
00:20:19,720 --> 00:20:21,120
which can work for broad planning.

529
00:20:21,120 --> 00:20:23,240
On the floor capacity depends on much more.

530
00:20:23,240 --> 00:20:26,040
A machine may sit idle because the required tool isn't available.

531
00:20:26,040 --> 00:20:29,480
The tool may be ready, but the certified operator starts on the next shift.

532
00:20:29,480 --> 00:20:32,000
Or the machine supports only an older product revision.

533
00:20:32,000 --> 00:20:33,720
Available isn't the same as capable.

534
00:20:33,720 --> 00:20:36,080
This is where factory understanding becomes practical.

535
00:20:36,080 --> 00:20:39,320
The model needs to state that a particular asset can perform a certain operation

536
00:20:39,320 --> 00:20:42,480
and describe the limits around that capability like supported materials,

537
00:20:42,480 --> 00:20:46,440
size ranges, approved recipes, tool requirements, and quality approvals.

538
00:20:46,440 --> 00:20:48,520
It also needs the current condition of the asset,

539
00:20:48,520 --> 00:20:53,560
running, stopped, under maintenance, waiting for a check, or released for production.

540
00:20:53,560 --> 00:20:56,600
Not every decision needs every detail. That point matters.

541
00:20:56,600 --> 00:21:02,000
If you're only reviewing weekly OEE, you don't need a live model of every fixture and shift handover.

542
00:21:02,000 --> 00:21:05,160
But if you want to re-root an order after a machine stop you probably do,

543
00:21:05,160 --> 00:21:09,000
the model should fit the decision, not become a giant archive of factory trivia

544
00:21:09,000 --> 00:21:10,480
that nobody can keep current.

545
00:21:10,480 --> 00:21:14,360
Or does sit in the same model, connected to the production route they need to follow?

546
00:21:14,360 --> 00:21:19,320
Each order carries a quantity, due date, priority, current execution state, and material status,

547
00:21:19,320 --> 00:21:22,400
along with customer rules like whether partial delivery is allowed.

548
00:21:22,400 --> 00:21:24,920
With that connection, the system can ask a better question,

549
00:21:24,920 --> 00:21:30,240
not which machine is free, but which available resource can perform the next required operation for this order,

550
00:21:30,240 --> 00:21:35,840
using an approved process with the needed tool, material, and person available within the remaining time.

551
00:21:35,840 --> 00:21:39,880
That's a longer question. It's also much closer to the question a planner is already answering.

552
00:21:39,880 --> 00:21:42,560
People belong in the model when they limit the action.

553
00:21:42,560 --> 00:21:44,920
A shift plan tells you who's expected on site,

554
00:21:44,920 --> 00:21:47,400
a skills record states who can perform a task,

555
00:21:47,400 --> 00:21:53,440
and a local rule may require two people for a setup or an engineer's approval before a route changes.

556
00:21:53,440 --> 00:21:56,480
So you don't need to reduce people to rows in a scheduling table,

557
00:21:56,480 --> 00:22:00,440
but pretending skills, shift coverage, and approval rules don't exist

558
00:22:00,440 --> 00:22:02,720
doesn't make them disappear from the decision.

559
00:22:02,720 --> 00:22:04,520
Plant rules matter for the same reason.

560
00:22:04,520 --> 00:22:08,560
Some work must run in a fixed sequence, some batches can't wait too long between steps,

561
00:22:08,560 --> 00:22:11,080
some resources need cleaning after a certain material,

562
00:22:11,080 --> 00:22:14,640
and some orders must stay on a name line due to customer approval.

563
00:22:14,640 --> 00:22:18,920
These rules shape the available choices before anyone compares cost or due date risk.

564
00:22:18,920 --> 00:22:22,440
Think of factory understanding as a working map of what the plant can do right now.

565
00:22:22,440 --> 00:22:24,480
What it plans to do next and what it must not do.

566
00:22:24,480 --> 00:22:26,880
That map connects the product to its process,

567
00:22:26,880 --> 00:22:30,160
then connects the process to the resources that can carry it out,

568
00:22:30,160 --> 00:22:34,280
including their current state, limits, tools, people, and location.

569
00:22:34,280 --> 00:22:37,560
It also keeps orders attached to the commitments the plant needs to meet.

570
00:22:37,560 --> 00:22:40,760
Once those links exist, AI has something concrete to work with.

571
00:22:40,760 --> 00:22:46,720
It can search, explain, compare, and support a decision without treating the factory as a collection of unrelated records.

572
00:22:46,720 --> 00:22:52,560
There's a common name for this sort of connected model, a knowledge graph, knowledge graphs without the hype.

573
00:22:52,560 --> 00:22:56,960
A knowledge graph sounds like one of those terms that comes with a lot of expensive slides.

574
00:22:56,960 --> 00:22:59,200
Strip that away and the idea is fairly plain.

575
00:22:59,200 --> 00:23:00,560
It's a model of connected facts.

576
00:23:00,560 --> 00:23:04,360
Instead of keeping a machine, operation, work order, and material lot

577
00:23:04,360 --> 00:23:08,160
as separate records that only meet when someone writes a report query,

578
00:23:08,160 --> 00:23:11,840
the model stores the links between them as part of the factory knowledge.

579
00:23:11,840 --> 00:23:13,560
Take the outage on machine four.

580
00:23:13,560 --> 00:23:17,000
The graph can state that machine four performs a named machining operation

581
00:23:17,000 --> 00:23:19,320
that operation belongs to a root for a product,

582
00:23:19,320 --> 00:23:21,000
the root fulfills a work order,

583
00:23:21,000 --> 00:23:24,920
and the work order supports a customer order with a due date.

584
00:23:24,920 --> 00:23:27,480
Each of those statements has a direction and a meaning.

585
00:23:27,480 --> 00:23:29,960
Machine four can perform operation 20.

586
00:23:29,960 --> 00:23:33,560
Operation 20 requires fixture A for a certain product family.

587
00:23:33,560 --> 00:23:37,160
fixture A sits at a specific location and currently supports another job.

588
00:23:37,160 --> 00:23:40,160
The order needs operation 20 before it can move to inspection.

589
00:23:40,160 --> 00:23:41,160
These aren't loose notes.

590
00:23:41,160 --> 00:23:44,560
There are stated relationships that software can query, test, and explain

591
00:23:44,560 --> 00:23:46,880
that changes the sort of question the system can handle.

592
00:23:46,880 --> 00:23:51,360
A normal database query might join tables across ERP, MES, maintenance, and quality.

593
00:23:51,360 --> 00:23:52,800
There's nothing wrong with that.

594
00:23:52,800 --> 00:23:55,360
Most factory systems rely on relational databases

595
00:23:55,360 --> 00:23:56,880
and do many jobs extremely well,

596
00:23:56,880 --> 00:24:00,160
but the query often starts from a question someone already knows how to frame,

597
00:24:00,160 --> 00:24:02,160
like which work orders stopped at this work center,

598
00:24:02,160 --> 00:24:05,200
which as is generated this alarm or which orders ship this week.

599
00:24:05,200 --> 00:24:08,600
A graph becomes helpful when the question follows a chain of relationships

600
00:24:08,600 --> 00:24:11,200
that crosses several business and shop floor domains.

601
00:24:11,200 --> 00:24:14,600
For example, you can ask which open orders depend on this failed asset,

602
00:24:14,600 --> 00:24:18,000
which of their next operations can run on approved alternate resources,

603
00:24:18,000 --> 00:24:22,400
and which of those alternatives are blocked by tooling, maintenance, or a quality rule.

604
00:24:22,400 --> 00:24:25,600
You can still answer that with tables, joins, and well-written logic.

605
00:24:25,600 --> 00:24:27,400
The graph doesn't give you supernatural powers,

606
00:24:27,400 --> 00:24:32,000
what it gives you is a way to represent the relationship path directly,

607
00:24:32,000 --> 00:24:34,800
making it easier to reuse, inspect, and govern.

608
00:24:34,800 --> 00:24:36,800
Think of it less as a replacement database,

609
00:24:36,800 --> 00:24:39,200
and more as a connected index of factory meaning.

610
00:24:39,200 --> 00:24:45,800
The nodes in that index can represent an asset, an operation, a product, an order, a person, a tool, or a location.

611
00:24:45,800 --> 00:24:48,600
The links state the relationship, can run, requires,

612
00:24:48,600 --> 00:24:51,600
belongs to, uses, depends on, sits, ad or needs approval from.

613
00:24:51,600 --> 00:24:52,800
The names don't matter much.

614
00:24:52,800 --> 00:24:53,800
The meaning does.

615
00:24:53,800 --> 00:24:57,200
If a planner asks why an order cannot move to an alternate machine,

616
00:24:57,200 --> 00:25:00,600
the system should not return a blank result and expect the planner to guess.

617
00:25:00,600 --> 00:25:03,200
Instead, it should follow the relationship path

618
00:25:03,200 --> 00:25:07,200
and say that the machine supports the operation, but the approved fixture is unavailable

619
00:25:07,200 --> 00:25:12,400
until a current job finishes, or that the root allows the machine only for a prior product revision.

620
00:25:12,400 --> 00:25:15,200
That explanation makes the model useful in a real conversation.

621
00:25:15,200 --> 00:25:16,600
It also makes gaps visible.

622
00:25:16,600 --> 00:25:20,800
If no relationship exists between an operation and an approved alternate resource,

623
00:25:20,800 --> 00:25:23,000
the system can't safely pretend one exists.

624
00:25:23,000 --> 00:25:28,000
That may expose missing engineering data, or a process rule that only lives in a senior operator's head.

625
00:25:28,000 --> 00:25:30,800
Either way, the gap becomes work the plan can address.

626
00:25:30,800 --> 00:25:32,800
A knowledge graph does not replace ERP.

627
00:25:32,800 --> 00:25:36,800
ERP still owns the commercial order, material plan, and formal production data.

628
00:25:36,800 --> 00:25:40,200
It doesn't replace the MES, which records execution on the floor.

629
00:25:40,200 --> 00:25:43,200
It doesn't replace the historian that retains time series signals

630
00:25:43,200 --> 00:25:45,600
or the maintenance system that manages repair work.

631
00:25:45,600 --> 00:25:48,600
Those systems remain the sources that run their own parts of the factory.

632
00:25:48,600 --> 00:25:51,200
The graph connects the facts needed for a cross-system decision.

633
00:25:51,200 --> 00:25:53,400
It can keep links back to the source record.

634
00:25:53,400 --> 00:25:56,600
So a planner or engineer can check where an answer came from,

635
00:25:56,600 --> 00:25:59,200
rather than trusting a black box with good grammar.

636
00:25:59,200 --> 00:26:01,600
That boundary matters because factories change,

637
00:26:01,600 --> 00:26:05,200
orders update, machines get repaired, product revisions shift.

638
00:26:05,200 --> 00:26:08,600
A graph must receive those changes and manage its own relationship rules,

639
00:26:08,600 --> 00:26:12,000
but it shouldn't quietly become a second ERP or a shadow MES.

640
00:26:12,000 --> 00:26:13,600
Start smaller than most people expect.

641
00:26:13,600 --> 00:26:17,000
Pick one decision where people repeatedly chase facts across systems,

642
00:26:17,000 --> 00:26:21,200
define the entities involved, and the links that determine which actions are allowed.

643
00:26:21,200 --> 00:26:24,400
Then test the questions with the people who live with the decision every day.

644
00:26:24,400 --> 00:26:27,600
If the model can explain a blocked re-root in terms of planner recognises,

645
00:26:27,600 --> 00:26:29,000
you're on the right track.

646
00:26:29,000 --> 00:26:33,200
If it can only draw a pretty web of equipment tags, you've built an expensive directory.

647
00:26:33,200 --> 00:26:36,400
One more distinction will help because knowledge graphs and digital twins

648
00:26:36,400 --> 00:26:38,800
often get pushed together as if they mean the same thing.

649
00:26:38,800 --> 00:26:39,800
They don't.

650
00:26:39,800 --> 00:26:41,400
Digital twin.

651
00:26:41,400 --> 00:26:42,800
Model with a job.

652
00:26:42,800 --> 00:26:44,400
Not a marketing label.

653
00:26:44,400 --> 00:26:47,800
A knowledge graph describes relationships,

654
00:26:47,800 --> 00:26:50,400
but a digital twin goes one step further.

655
00:26:50,400 --> 00:26:52,400
It takes a model of something real

656
00:26:52,400 --> 00:26:55,200
and puts it to work for a specific operational job.

657
00:26:55,200 --> 00:26:56,600
That difference sounds small,

658
00:26:56,600 --> 00:26:58,600
but it keeps a lot of factory projects honest.

659
00:26:58,600 --> 00:27:01,200
You don't need a digital twin because the term sounds modern.

660
00:27:01,200 --> 00:27:05,200
You need one when a live representation of an asset, a line, or a production system

661
00:27:05,200 --> 00:27:07,400
actually helps somebody make a better decision.

662
00:27:07,400 --> 00:27:08,800
Let's start with an asset twin.

663
00:27:08,800 --> 00:27:12,400
It represents a physical machine and the facts that matter for a particular use.

664
00:27:12,400 --> 00:27:15,800
Current operating state, maintenance status, supported operations,

665
00:27:15,800 --> 00:27:19,200
installed tooling, process limits, and recent events.

666
00:27:19,200 --> 00:27:21,800
The twin doesn't need every signal from every controller.

667
00:27:21,800 --> 00:27:24,600
A control system already handles fast machine behaviour.

668
00:27:24,600 --> 00:27:26,800
The twin carries the part of the machine's state

669
00:27:26,800 --> 00:27:30,200
that other systems need when they ask wider operational questions.

670
00:27:30,200 --> 00:27:32,000
A line twin works at a different level.

671
00:27:32,000 --> 00:27:35,000
It connects the machines, buffers, work centres, and flow rules

672
00:27:35,000 --> 00:27:37,800
that shape how work moves through one production area.

673
00:27:37,800 --> 00:27:42,000
When a machine stops, the line twin can help describe where work will pile up,

674
00:27:42,000 --> 00:27:43,400
where starvation might hit,

675
00:27:43,400 --> 00:27:45,600
and which parts of the line need attention first.

676
00:27:45,600 --> 00:27:48,400
From there you can move up again to a production system twin.

677
00:27:48,400 --> 00:27:52,800
This model connects production work to orders, routes, materials, people,

678
00:27:52,800 --> 00:27:55,000
quality rules, and delivery commitments.

679
00:27:55,000 --> 00:27:57,400
It doesn't replace the systems that own those records.

680
00:27:57,400 --> 00:28:01,600
It gives the plant a current, connected representation for decisions that cross those systems.

681
00:28:01,600 --> 00:28:04,400
The level matters because digital twin often gets used

682
00:28:04,400 --> 00:28:07,600
as though every factory needs one giant model of everything.

683
00:28:07,600 --> 00:28:09,600
That's rarely a useful starting point.

684
00:28:09,600 --> 00:28:13,600
A machine engineer needs an asset twin to support maintenance or process diagnosis.

685
00:28:13,600 --> 00:28:17,400
A production manager needs a line twin to understand flow and capacity.

686
00:28:17,400 --> 00:28:20,600
A planner dealing with late orders needs a production system twin

687
00:28:20,600 --> 00:28:23,400
that connects equipment state to the work depending on it.

688
00:28:23,400 --> 00:28:24,600
Each twin needs a job.

689
00:28:24,600 --> 00:28:27,400
If you can't name the user, the decision, and the time window,

690
00:28:27,400 --> 00:28:30,000
you're just collecting data under a more expensive label.

691
00:28:30,000 --> 00:28:32,000
I've seen people call a dashboard a digital twin

692
00:28:32,000 --> 00:28:33,800
because it shows live machine status.

693
00:28:33,800 --> 00:28:35,800
A live dashboard can be very useful,

694
00:28:35,800 --> 00:28:39,000
but it doesn't become a twin simply because the numbers refresh often.

695
00:28:39,000 --> 00:28:42,200
A screen with colored machine icons tells you which assets stopped,

696
00:28:42,200 --> 00:28:43,800
but it won't represent their capabilities,

697
00:28:43,800 --> 00:28:47,400
current production role, operating limits, or the effects of a change.

698
00:28:47,400 --> 00:28:49,200
The same goes for attack hierarchy.

699
00:28:49,200 --> 00:28:53,200
Organizing PLC tags by site, line, machine, and sensor helps with data access,

700
00:28:53,200 --> 00:28:56,800
but it still doesn't state that a certain machine only processes a particular product

701
00:28:56,800 --> 00:29:00,600
under a defined recipe after a quality release using an approved tool.

702
00:29:00,600 --> 00:29:03,000
A digital twin needs relationships in state.

703
00:29:03,000 --> 00:29:04,800
It also needs govern source data.

704
00:29:04,800 --> 00:29:08,600
If the MES reports one asset status, maintenance reports another,

705
00:29:08,600 --> 00:29:11,000
and a manual spreadsheet carries the current truth,

706
00:29:11,000 --> 00:29:14,600
the twin can't quietly choose which ever source looks convenient.

707
00:29:14,600 --> 00:29:16,800
The plant has to state which source owns which fact,

708
00:29:16,800 --> 00:29:19,600
how often the twin updates, and what happens when sources disagree.

709
00:29:19,600 --> 00:29:21,800
That's less glamorous than a 3D factory model,

710
00:29:21,800 --> 00:29:23,200
but it's where the work sits.

711
00:29:23,200 --> 00:29:28,000
For a production twin, current state also means more than machine running or machine stopped.

712
00:29:28,000 --> 00:29:30,800
Fas, sabale, t'gue, le thin, t'ah,

713
00:29:30,800 --> 00:29:34,600
the model needs to know which work order currently uses the asset.

714
00:29:34,600 --> 00:29:36,200
Where the batch sits in the root,

715
00:29:36,200 --> 00:29:39,400
whether the material remains released, whether a repair blocks restart,

716
00:29:39,400 --> 00:29:42,000
and whether the next operation still has capacity,

717
00:29:42,000 --> 00:29:43,600
only include facts that support the job.

718
00:29:43,600 --> 00:29:46,000
A twin build for outage impact needs different detail

719
00:29:46,000 --> 00:29:48,800
from one build for energy analysis or preventive maintenance.

720
00:29:48,800 --> 00:29:52,600
There's no prize for modeling every nut, bolt, and historical event in the plant.

721
00:29:52,600 --> 00:29:54,400
You'll spend a long time keeping it current

722
00:29:54,400 --> 00:29:57,000
and most of it won't help the decision you set out to improve.

723
00:29:57,000 --> 00:29:59,600
So I use the term digital twin with some discipline.

724
00:29:59,600 --> 00:30:01,400
If it reports status, call it a dashboard.

725
00:30:01,400 --> 00:30:03,400
If it organises signals, call it a tag model.

726
00:30:03,400 --> 00:30:05,800
Both are useful. They just have different jobs.

727
00:30:05,800 --> 00:30:09,800
Reserve twin, for when it represents a defined part of the physical operation,

728
00:30:09,800 --> 00:30:12,000
keeps relevant state connected to source truth

729
00:30:12,000 --> 00:30:14,400
and supports a real decision or action.

730
00:30:14,400 --> 00:30:17,600
Once the model has a clear job, the next test is simple.

731
00:30:17,600 --> 00:30:20,000
Can it turn a shop floor event into a clear statement

732
00:30:20,000 --> 00:30:22,200
about the business and production consequence

733
00:30:22,200 --> 00:30:25,400
from shop floor signal to business consequence?

734
00:30:25,400 --> 00:30:28,800
Let's follow a failure event from the machine into a decision process.

735
00:30:28,800 --> 00:30:31,000
When the PLC detects a fault and stops the cycle

736
00:30:31,000 --> 00:30:34,400
and edge gateway picks up the event with its time, fault state, and source tag,

737
00:30:34,400 --> 00:30:36,400
then passes it into the wider data path

738
00:30:36,400 --> 00:30:39,000
without putting cloud services in the control loop.

739
00:30:39,000 --> 00:30:42,600
That separation matters because the machine must stay safe and predictable

740
00:30:42,600 --> 00:30:46,200
even if a networking drops or an analytic service goes offline.

741
00:30:46,200 --> 00:30:48,400
Once the event reaches the data and context layer,

742
00:30:48,400 --> 00:30:51,000
the first job isn't AI, its identification.

743
00:30:51,000 --> 00:30:54,200
The system needs to establish which physical asset produced the event,

744
00:30:54,200 --> 00:30:58,600
rather than treating a tag path as if it already carries complete production meaning.

745
00:30:58,600 --> 00:31:00,600
After that, it asks a time bound question,

746
00:31:00,600 --> 00:31:03,200
what was this asset doing when the fault occurred?

747
00:31:03,200 --> 00:31:07,000
At that time, machine four was running Operation 24 Work Order 81 and Seen.

748
00:31:07,000 --> 00:31:11,000
The MES provides the execution state, quantity completed, quantity remaining,

749
00:31:11,000 --> 00:31:13,600
and the active batch where the process uses batches.

750
00:31:13,600 --> 00:31:17,200
The production model connects that operation to the root, the product revision,

751
00:31:17,200 --> 00:31:21,400
and the planned next step that turns a machine event into an operational event.

752
00:31:21,400 --> 00:31:23,600
The system can now state something more useful than

753
00:31:23,600 --> 00:31:25,800
machine four stopped at 1017.

754
00:31:25,800 --> 00:31:30,000
It can say, "Machine four stopped during Operation 20 on Work Order 817".

755
00:31:30,000 --> 00:31:31,600
The order has quantity remaining.

756
00:31:31,600 --> 00:31:34,400
Its next required operation is inspection followed by assembly.

757
00:31:34,400 --> 00:31:38,000
The planned completion time now falls outside the current schedule.

758
00:31:38,000 --> 00:31:40,200
Notice what changed.

759
00:31:40,200 --> 00:31:42,000
The fault code didn't get more accurate,

760
00:31:42,000 --> 00:31:44,400
but the system gained the relationships around it.

761
00:31:44,400 --> 00:31:49,200
From there, the impact path continues to other orders waiting in the queue for the same operation.

762
00:31:49,200 --> 00:31:52,200
Orders downstream that depend on work, leaving machine four,

763
00:31:52,200 --> 00:31:55,600
and orders due close enough that a delay affects shipment.

764
00:31:55,600 --> 00:31:59,000
A production consequence rarely follows a single straight line.

765
00:31:59,000 --> 00:32:01,800
One order might wait without risk because it has scheduled slack,

766
00:32:01,800 --> 00:32:04,800
while another has none, and a third might not ship soon,

767
00:32:04,800 --> 00:32:08,400
but uses material that blocks an urgent order if the queue builds wrong.

768
00:32:08,400 --> 00:32:10,800
That's why a useful system traces dependencies

769
00:32:10,800 --> 00:32:13,200
rather than just listing affected work orders.

770
00:32:13,200 --> 00:32:16,200
It also checks capacity in the places that matter next,

771
00:32:16,200 --> 00:32:19,800
whether downstream inspection can absorb a delayed batch later in the shift,

772
00:32:19,800 --> 00:32:21,800
whether another resource has an approved route,

773
00:32:21,800 --> 00:32:24,200
and if an alternate exists when it becomes free

774
00:32:24,200 --> 00:32:26,800
in whether using it displaces higher priority work.

775
00:32:26,800 --> 00:32:28,400
The answer should stay explainable.

776
00:32:28,400 --> 00:32:31,000
Instead of an anomaly score with no operational meaning,

777
00:32:31,000 --> 00:32:32,800
a planner needs a statement like,

778
00:32:32,800 --> 00:32:34,600
"This failure puts two orders at risk.

779
00:32:34,600 --> 00:32:39,000
One can recover on the original machine if repair completes before the next planned slot."

780
00:32:39,000 --> 00:32:41,200
The other needs an alternate resource,

781
00:32:41,200 --> 00:32:44,400
but the current option conflicts with a tooling reservation.

782
00:32:44,400 --> 00:32:46,200
That gives people something they can test.

783
00:32:46,200 --> 00:32:48,200
Maintenance can challenge the repair estimate.

784
00:32:48,200 --> 00:32:50,000
Production can check tooling status.

785
00:32:50,000 --> 00:32:52,000
Quality can confirm the alternate route,

786
00:32:52,000 --> 00:32:55,000
and customer service can decide whether to contact the customer.

787
00:32:55,000 --> 00:32:57,000
The system hasn't replaced those roles.

788
00:32:57,000 --> 00:33:00,600
Just reduce the time spent finding the part of the story each role needs.

789
00:33:00,600 --> 00:33:03,400
This also creates a cleaner handoff between systems.

790
00:33:03,400 --> 00:33:06,200
The PLC and Edgelayer report, what the equipment detected,

791
00:33:06,200 --> 00:33:10,000
the MES provides execution truth ERP provides demand and commitment data,

792
00:33:10,000 --> 00:33:12,000
maintenance contributes repair status,

793
00:33:12,000 --> 00:33:14,400
quality contributes release and process conditions,

794
00:33:14,400 --> 00:33:17,400
and the context layer connects those facts around the decision

795
00:33:17,400 --> 00:33:19,600
while preserving a path back to source systems.

796
00:33:19,600 --> 00:33:23,800
Tools like Azure, Fabric and Power BI can support parts of this flow.

797
00:33:23,800 --> 00:33:26,600
Azure for secure event intake and processing,

798
00:33:26,600 --> 00:33:30,600
Fabric for shared operational data, Power BI for exposing impact.

799
00:33:30,600 --> 00:33:32,400
But none of those tools can decide on their own

800
00:33:32,400 --> 00:33:34,400
that one event belongs to one asset,

801
00:33:34,400 --> 00:33:37,200
one active operation and one customer promise.

802
00:33:37,200 --> 00:33:39,400
The factory has to model and maintain those links.

803
00:33:39,400 --> 00:33:40,800
There's a practical point here too,

804
00:33:40,800 --> 00:33:43,400
not every machine event deserves a business impact trace.

805
00:33:43,400 --> 00:33:45,400
A brief plan stop needs no response,

806
00:33:45,400 --> 00:33:48,200
but a fault during a constrained operation on an urgent order

807
00:33:48,200 --> 00:33:50,000
might trigger a much deeper assessment.

808
00:33:50,000 --> 00:33:52,600
So the model needs rules for when to follow the chain,

809
00:33:52,600 --> 00:33:55,200
how far to follow it, and who receives the result.

810
00:33:55,200 --> 00:33:58,400
Otherwise you've built a very intelligent way to send people more alerts.

811
00:33:58,400 --> 00:34:01,600
The aim isn't to turn every alarm into an executive incident.

812
00:34:01,600 --> 00:34:05,400
The aim is to recognize when a shop floor event changes the available production choices,

813
00:34:05,400 --> 00:34:08,000
then explain that change clearly enough for people to act.

814
00:34:08,000 --> 00:34:10,400
And before any of this can work consistently,

815
00:34:10,400 --> 00:34:13,200
the factory needs to solve a problem that sounds basic

816
00:34:13,200 --> 00:34:15,200
but breaks this chain all the time.

817
00:34:15,200 --> 00:34:18,400
The same machine often has more than one identity.

818
00:34:18,400 --> 00:34:21,200
The asset identity problem.

819
00:34:21,200 --> 00:34:24,800
Here's the problem most manufacturers don't talk about.

820
00:34:24,800 --> 00:34:28,600
A fault event only becomes useful when the system can name the thing that produced it.

821
00:34:28,600 --> 00:34:30,000
You'd think that's basic,

822
00:34:30,000 --> 00:34:33,600
but it causes more trouble than any AI project ever admits to.

823
00:34:33,600 --> 00:34:35,800
Picture one physical machine on a production line,

824
00:34:35,800 --> 00:34:38,400
maintenance calls it asset 0, 4, 2, and C.

825
00:34:38,400 --> 00:34:40,200
The MES calls it Workcenter M4.

826
00:34:40,200 --> 00:34:43,200
ERP knows it as a capacity group called CNC-CLB.

827
00:34:43,200 --> 00:34:46,200
And in the IoT feed, the fault comes from a tag path

828
00:34:46,200 --> 00:34:48,200
a controls contractor wrote years ago.

829
00:34:48,200 --> 00:34:50,400
All four names can refer to the same machine,

830
00:34:50,400 --> 00:34:52,400
but none of them prove it to the other systems.

831
00:34:52,400 --> 00:34:55,600
When the data platform receives an event from that tag path,

832
00:34:55,600 --> 00:34:58,800
it needs a reliable way to resolve that event to the physical asset.

833
00:34:59,400 --> 00:35:01,800
From there it can link to the MES Workcenter,

834
00:35:01,800 --> 00:35:05,400
the maintenance record, and any planning resource tied to that equipment.

835
00:35:05,400 --> 00:35:07,600
Without those mappings, the data might look connected

836
00:35:07,600 --> 00:35:09,600
while the actual chain breaks at the first joint.

837
00:35:09,600 --> 00:35:13,000
People usually reach for fuzzy matching or AI when they hit this wall.

838
00:35:13,000 --> 00:35:16,200
Those tools can help find likely matches, especially in all data,

839
00:35:16,200 --> 00:35:19,000
but a production decision needs more than a likely match.

840
00:35:19,000 --> 00:35:21,200
It needs a governed identity that people trust.

841
00:35:21,200 --> 00:35:23,000
You don't want a system to re-root work

842
00:35:23,000 --> 00:35:26,200
because it gets the two similar machine names referred to the same asset.

843
00:35:26,200 --> 00:35:27,800
Now here's where it gets nastier.

844
00:35:27,800 --> 00:35:31,200
Names change, a machine moves to another line, a controller gets replaced.

845
00:35:31,200 --> 00:35:34,200
Maintenance restructures its asset hierarchy.

846
00:35:34,200 --> 00:35:37,400
Engineering changes the Workcenter model after a layout change.

847
00:35:37,400 --> 00:35:40,800
Someone adds a new gateway and creates a fresh namespace for tags.

848
00:35:40,800 --> 00:35:43,800
None of those changes are unusual, plants evolve.

849
00:35:43,800 --> 00:35:47,200
But if nobody owns the mapping between physical assets, business resources,

850
00:35:47,200 --> 00:35:50,600
and technical signals, the context layer slowly drifts away from the floor.

851
00:35:50,600 --> 00:35:53,200
Then an AI assistant answers with confidence

852
00:35:53,200 --> 00:35:55,600
using a relationship that stopped being true six months ago.

853
00:35:55,600 --> 00:35:58,400
That's a very polite way to create a bad production decision.

854
00:35:58,400 --> 00:36:00,000
Tag names create a separate issue.

855
00:36:00,000 --> 00:36:03,400
A PLC tag usually describes an electrical or control concept.

856
00:36:03,400 --> 00:36:07,600
A motor overload, a conveyor zone, a valve state, a cycle complete signal.

857
00:36:07,600 --> 00:36:09,400
Controls engineers meet that detail.

858
00:36:09,400 --> 00:36:12,200
Yet a tag rarely states the production meaning a planner needs.

859
00:36:12,200 --> 00:36:16,600
A tag called Station 12 a run doesn't tell you whether Station 12 means a machine,

860
00:36:16,600 --> 00:36:20,600
a test rig, a packing cell, or one unit inside a larger automated line.

861
00:36:20,600 --> 00:36:24,200
It doesn't say whether the signal belongs to a resource that can run a specific order

862
00:36:24,200 --> 00:36:26,800
and it definitely doesn't tell you which work order ran at the time.

863
00:36:26,800 --> 00:36:30,400
So you need a layer of master data and mapping rules between those worlds.

864
00:36:30,400 --> 00:36:33,400
The mapping may state that a group of tags belongs to a controller,

865
00:36:33,400 --> 00:36:35,400
the controller connects to a physical asset

866
00:36:35,400 --> 00:36:39,000
and the asset supports one or more production resources in the MES.

867
00:36:39,000 --> 00:36:44,200
That mapping should include location, line, ownership, status, and effective dates

868
00:36:44,200 --> 00:36:46,800
because those relationships change over time.

869
00:36:46,800 --> 00:36:48,800
Effective dates matter more than people expect.

870
00:36:48,800 --> 00:36:52,000
If a controller gets swapped during a retrofit, a signal from last year

871
00:36:52,000 --> 00:36:55,200
may need a different interpretation from a signal collected today.

872
00:36:55,200 --> 00:36:59,600
The system should preserve that history rather than rewriting the past to fit the new layout.

873
00:36:59,600 --> 00:37:02,600
This work can feel less exciting than talking about co-pilots.

874
00:37:02,600 --> 00:37:06,200
It lives in master data workshops, asset registers, naming rules,

875
00:37:06,200 --> 00:37:09,400
and difficult conversations about which system owns which identifier.

876
00:37:09,400 --> 00:37:12,800
But it's the work that lets you connect the dots between IT and OT.

877
00:37:12,800 --> 00:37:16,400
A sensible model doesn't force one ID to replace every other ID.

878
00:37:16,400 --> 00:37:19,600
Each system can keep the identifier it needs for its own job.

879
00:37:19,600 --> 00:37:22,600
The context layer holds the mappings, the source of each mapping,

880
00:37:22,600 --> 00:37:25,000
and the rules for resolving one identity to another.

881
00:37:25,000 --> 00:37:26,600
That makes the result traceable.

882
00:37:26,600 --> 00:37:29,600
If a planner questions why an alarm links to a certain work center,

883
00:37:29,600 --> 00:37:33,200
the system can show the mapping path instead of replying with a vague machine name.

884
00:37:33,200 --> 00:37:34,800
Ownership needs to be equally clear.

885
00:37:34,800 --> 00:37:38,000
When a new machine arrives, who creates the asset identity?

886
00:37:38,000 --> 00:37:39,800
Who links it to the MES resource?

887
00:37:39,800 --> 00:37:41,200
Who maps the incoming signals?

888
00:37:41,200 --> 00:37:42,400
When equipment moves?

889
00:37:42,400 --> 00:37:45,000
Who updates the location and capacity relationship?

890
00:37:45,000 --> 00:37:46,600
When an old machine leaves service?

891
00:37:46,600 --> 00:37:47,600
Who closes the links?

892
00:37:47,600 --> 00:37:50,000
So it doesn't remain an available option in a planning model?

893
00:37:50,000 --> 00:37:51,400
Those aren't admin details.

894
00:37:51,400 --> 00:37:54,800
They decide whether real-time visibility refers to the real factory.

895
00:37:54,800 --> 00:37:58,400
You don't need perfect asset data across the whole enterprise before you start.

896
00:37:58,400 --> 00:38:02,600
You do need dependable identity for the assets involved in the decision you want to support.

897
00:38:02,600 --> 00:38:03,400
Start there.

898
00:38:03,400 --> 00:38:07,000
Test the mappings with maintenance and production, then extend them as the use case grows.

899
00:38:07,000 --> 00:38:09,200
Once the system knows which machine it is dealing with,

900
00:38:09,200 --> 00:38:11,000
another mapping challenge appears.

901
00:38:11,000 --> 00:38:15,600
The plant must also describe what that machine can do for a given product through a given process.

902
00:38:15,600 --> 00:38:18,000
Product process and resource context.

903
00:38:18,000 --> 00:38:22,800
Once the asset identity is clear, you can ask a more useful question,

904
00:38:22,800 --> 00:38:26,400
what can this machine actually do for this product under this process?

905
00:38:26,400 --> 00:38:29,000
That question sits at the center of production planning.

906
00:38:29,000 --> 00:38:33,200
A machine lists a loan count answered because capacity doesn't come from equipment names.

907
00:38:33,200 --> 00:38:36,800
Capacity comes from the relationship between a product, the process it needs,

908
00:38:36,800 --> 00:38:39,000
and the resources that can carry out that process.

909
00:38:39,000 --> 00:38:40,400
Think about the product first.

910
00:38:40,400 --> 00:38:43,200
The product isn't just a part number from ERP.

911
00:38:43,200 --> 00:38:46,200
For a real production decision, it may mean a specific revision,

912
00:38:46,200 --> 00:38:50,800
material grade, customer variant, batch size, or approved manufacturing condition.

913
00:38:50,800 --> 00:38:53,800
A planner might see two orders with the same base part number,

914
00:38:53,800 --> 00:38:55,600
and assume they can move together.

915
00:38:55,600 --> 00:38:59,600
But one order may use a revised drawing, a different raw material lot,

916
00:38:59,600 --> 00:39:01,600
or a customer rule that changes the route.

917
00:39:01,600 --> 00:39:05,200
The product definition needs enough detail to tell those cases apart.

918
00:39:05,200 --> 00:39:06,800
Then comes the process.

919
00:39:06,800 --> 00:39:10,800
The process describes the work needed to turn material into a finished product.

920
00:39:10,800 --> 00:39:15,200
It defines operations, the expected sequence, set up conditions, inspections,

921
00:39:15,200 --> 00:39:19,200
and points where the plant must check quality before work can continue.

922
00:39:19,200 --> 00:39:24,000
It can also describe alternate paths, but alternate doesn't mean unrestricted.

923
00:39:24,000 --> 00:39:25,400
Take a machining operation.

924
00:39:25,400 --> 00:39:28,000
Engineering may approve it on machine 4 and machine 7,

925
00:39:28,000 --> 00:39:31,200
yet machine 7 may only qualify for certain dimensions,

926
00:39:31,200 --> 00:39:34,000
a named tool set, or a particular product revision.

927
00:39:34,000 --> 00:39:35,400
It may need a different set up.

928
00:39:35,400 --> 00:39:39,400
The process model needs to express that difference in a way planning systems can test.

929
00:39:39,400 --> 00:39:42,200
Otherwise, alternate resource becomes a vague label,

930
00:39:42,200 --> 00:39:44,200
and vague labels create bad replans.

931
00:39:44,200 --> 00:39:47,600
The resource side covers the things required to perform the process.

932
00:39:47,600 --> 00:39:49,600
Machines, work centers, and more.

933
00:39:49,600 --> 00:39:52,400
A fixture can limit production just as much as a machine,

934
00:39:52,400 --> 00:39:55,000
and so can a test rig, a furnace zone, a shared tool,

935
00:39:55,000 --> 00:39:57,600
a trained operator, or even a space in a buffer.

936
00:39:57,600 --> 00:39:59,800
Physical availability only answers part of the question.

937
00:39:59,800 --> 00:40:04,200
A machining center might sit idle because the required fixture remains on another machine.

938
00:40:04,200 --> 00:40:06,000
A test station might have open time,

939
00:40:06,000 --> 00:40:09,800
but the order can't enter it until inspection releases the prior operation.

940
00:40:09,800 --> 00:40:13,800
A person may work that shift and still lack approval for a customer-specific process.

941
00:40:13,800 --> 00:40:16,600
The resource exists, but it doesn't support the action you need.

942
00:40:16,600 --> 00:40:20,200
That's why product, process, and resource links need to be explicit.

943
00:40:20,200 --> 00:40:23,400
The model can state that product revision B requires operation 20.

944
00:40:23,400 --> 00:40:26,800
It can state that operation 20 can run on machine 4 or machine 7.

945
00:40:26,800 --> 00:40:29,600
It can then state the conditions that apply to each route.

946
00:40:29,600 --> 00:40:33,200
The supported material grade, needed fixture, set up duration,

947
00:40:33,200 --> 00:40:38,000
approved program, tool status, and any release needed before the work begins.

948
00:40:38,000 --> 00:40:41,000
Those relationships turn planning from broad capacity arithmetic

949
00:40:41,000 --> 00:40:43,600
into a test of what the factory can actually execute.

950
00:40:43,600 --> 00:40:46,200
Let's make that concrete with the machine 4 failure.

951
00:40:46,200 --> 00:40:49,600
The planner sees that machine 7 has spare time later in the shift.

952
00:40:49,600 --> 00:40:51,400
That's a starting point, not an answer.

953
00:40:51,400 --> 00:40:55,600
The context model checks whether machine 7 supports the exact product revision,

954
00:40:55,600 --> 00:40:58,600
whether the fixture is free, whether the program is approved,

955
00:40:58,600 --> 00:41:01,600
and whether moving the work changes the expected finish time enough

956
00:41:01,600 --> 00:41:03,400
to create a downstream issue.

957
00:41:03,400 --> 00:41:07,000
Maybe machine 7 can take part of the affected work, but not the full batch.

958
00:41:07,000 --> 00:41:10,800
Maybe it can run the operation only after a change over that would disrupt another order.

959
00:41:10,800 --> 00:41:15,000
Maybe the work can move, but the next inspection station can't absorb it until tomorrow.

960
00:41:15,000 --> 00:41:18,200
Each result can be valid as long as the model exposes the reason

961
00:41:18,200 --> 00:41:22,400
that also gives engineering, planning, and production a common place to discuss the rule.

962
00:41:22,400 --> 00:41:25,200
If the model blocks a move that people know is safe,

963
00:41:25,200 --> 00:41:27,200
somebody can review the process approval.

964
00:41:27,200 --> 00:41:31,400
Perhaps the alternate route exists in practice, but hasn't entered the formal route data.

965
00:41:31,400 --> 00:41:35,200
If the model permits a move, nobody would accept the missing condition becomes visible.

966
00:41:35,200 --> 00:41:38,200
Instead of letting that knowledge stay buried in a shift hand over,

967
00:41:38,200 --> 00:41:42,000
the plant can put it where the next planner and the next system can use it.

968
00:41:42,000 --> 00:41:46,400
This work shouldn't try to capture every bit of plant knowledge in one giant model.

969
00:41:46,400 --> 00:41:50,000
Start with the decisions where rerouting, sequencing, or capacity trade-offs

970
00:41:50,000 --> 00:41:52,200
happen often enough to justify the effort.

971
00:41:52,200 --> 00:41:55,200
Model the product details, process steps, and resource facts

972
00:41:55,200 --> 00:41:57,000
that decide whether an option is possible.

973
00:41:57,000 --> 00:42:00,200
The goal is a model that can answer a very practical question.

974
00:42:00,200 --> 00:42:04,000
Can this order run here, now, and under the conditions the plant accepts?

975
00:42:04,000 --> 00:42:05,800
That question still needs one more layer.

976
00:42:05,800 --> 00:42:10,300
A route may be technically possible, but production rules can still rule it out.

977
00:42:10,300 --> 00:42:13,500
Constraints are part of the data.

978
00:42:13,500 --> 00:42:17,100
A route can be technically possible and still be something you'd never actually run.

979
00:42:17,100 --> 00:42:19,300
That's where constraints come into the model.

980
00:42:19,300 --> 00:42:23,800
A constraint is basically a condition that limits which production actions the plant can take

981
00:42:23,800 --> 00:42:27,900
and it needs the same clear treatment as an order, a machine, or material record.

982
00:42:27,900 --> 00:42:31,300
Some constraints are hard limits. Nobody should be negotiating them under pressure

983
00:42:31,300 --> 00:42:32,800
just because an order looks late.

984
00:42:32,800 --> 00:42:34,800
Safety rules belong here.

985
00:42:34,800 --> 00:42:40,600
So do machine limits, approved recipe ranges, material compatibility rules, and operator certifications.

986
00:42:40,600 --> 00:42:43,300
If a process needs a certified person and available person

987
00:42:43,300 --> 00:42:45,800
without that certification, doesn't count as capacity.

988
00:42:45,800 --> 00:42:49,000
If a material can't run through a machine because of contamination risk,

989
00:42:49,000 --> 00:42:51,400
an empty machine doesn't count as an alternative.

990
00:42:51,400 --> 00:42:55,800
The planning system needs to remove those options before anyone even starts comparing them.

991
00:42:55,800 --> 00:42:57,100
Take a coding operation.

992
00:42:57,100 --> 00:43:02,000
The line might appear free, the product may fit physically, and the needed quantity may sit in the queue.

993
00:43:02,000 --> 00:43:06,700
But if the previous run used the material that requires cleaning before this product can enter the line

994
00:43:06,700 --> 00:43:08,800
that cleaning rule changes the plan.

995
00:43:08,800 --> 00:43:12,000
If the required recipe hasn't been approved for a new product revision,

996
00:43:12,000 --> 00:43:13,900
the line can't simply try it and see.

997
00:43:13,900 --> 00:43:16,100
That isn't a detail for someone to remember later.

998
00:43:16,100 --> 00:43:17,800
It is part of the production fact pattern.

999
00:43:17,800 --> 00:43:20,800
Other constraints allow judgment, but they still need to be visible.

1000
00:43:20,800 --> 00:43:22,300
Changes are a common case.

1001
00:43:22,300 --> 00:43:25,800
A plant may choose to add a changeover to protect an urgent delivery,

1002
00:43:25,800 --> 00:43:30,700
but that choice carries a cost in time, risk, and disruption to the rest of the schedule.

1003
00:43:30,700 --> 00:43:33,000
Campaign rules work in a similar way.

1004
00:43:33,000 --> 00:43:36,500
Some plants, group products by color, material, or process condition

1005
00:43:36,500 --> 00:43:40,500
because frequent switching creates waste, cleaning work, or unstable output.

1006
00:43:40,500 --> 00:43:44,800
The planner may break a campaign rule, but they should see the cost before they do it.

1007
00:43:44,800 --> 00:43:47,500
Maintenance windows also belong in the decision.

1008
00:43:47,500 --> 00:43:50,000
A resource may appear available in the MES schedule,

1009
00:43:50,000 --> 00:43:54,200
while maintenance has reserved it for an inspection that can't move without creating another risk.

1010
00:43:54,200 --> 00:43:56,200
Staffing creates the same kind of limit.

1011
00:43:56,200 --> 00:44:01,800
A machine can run only if the right people, shift coverage, and support roles exist when the plan calls for them.

1012
00:44:01,800 --> 00:44:03,100
Then there are commercial rules.

1013
00:44:03,100 --> 00:44:04,900
A due date is more than a date field.

1014
00:44:04,900 --> 00:44:08,400
One customer may accept a partial shipment, another may require a complete order,

1015
00:44:08,400 --> 00:44:10,900
one late order may carry a contract penalty,

1016
00:44:10,900 --> 00:44:15,400
another may carry a high customer relationship risk that never appears in a standard priority code.

1017
00:44:15,400 --> 00:44:18,100
I wouldn't suggest hiding all that inside an opaque score.

1018
00:44:18,100 --> 00:44:21,000
The planner needs to understand why one order moves ahead of another,

1019
00:44:21,000 --> 00:44:23,800
especially when the decision creates a delay elsewhere.

1020
00:44:23,800 --> 00:44:28,400
So the model should state the rule, its source, and the person or team that owns it.

1021
00:44:28,400 --> 00:44:32,300
Engineering may own an approved process limit, quality may own a release condition,

1022
00:44:32,300 --> 00:44:35,800
maintenance may own an outage window, planning may own a sequencing rule,

1023
00:44:35,800 --> 00:44:39,700
customer service, or commercial leadership may own an order priority decision.

1024
00:44:39,700 --> 00:44:41,900
Without ownership constraints become folklore,

1025
00:44:41,900 --> 00:44:45,200
someone remembers them until they leave the business, move shifts,

1026
00:44:45,200 --> 00:44:47,700
or simply aren't available when the machine stops.

1027
00:44:47,700 --> 00:44:50,800
Then a system built on partial information fills the gap with an assumption,

1028
00:44:50,800 --> 00:44:54,800
which is exactly what you don't want when physical production sits behind the decision.

1029
00:44:54,800 --> 00:44:58,500
Constraints also change over time, a qualification can expire, a tool can move,

1030
00:44:58,500 --> 00:45:01,800
a temporary deviation can allow a route for a limited period,

1031
00:45:01,800 --> 00:45:04,000
a maintenance job can shift after a repair.

1032
00:45:04,000 --> 00:45:06,600
The model needs to capture when a condition applies,

1033
00:45:06,600 --> 00:45:08,900
not just whether it exists somewhere in a document,

1034
00:45:08,900 --> 00:45:12,600
that doesn't mean every factory rule must become machine readable on day one.

1035
00:45:12,600 --> 00:45:16,400
Some rules need human review because they rely on judgment or unusual circumstances,

1036
00:45:16,400 --> 00:45:19,800
but the system should at least identify where that review belongs.

1037
00:45:19,800 --> 00:45:23,300
Instead of presenting a recommendation as though the rule never existed.

1038
00:45:23,300 --> 00:45:26,700
For machine four, this changes the replant question again.

1039
00:45:26,700 --> 00:45:29,400
The question isn't whether another machine has spare hours,

1040
00:45:29,400 --> 00:45:33,000
it's whether another machine can run the affected work under the approved product,

1041
00:45:33,000 --> 00:45:36,600
process, quality, tools, staffing, maintenance, and commercial conditions.

1042
00:45:36,600 --> 00:45:39,700
If only one alternative remains after those checks that's useful,

1043
00:45:39,700 --> 00:45:41,600
if none remain that is useful too,

1044
00:45:41,600 --> 00:45:45,300
because the planner can stop chasing an option, the plant can't execute.

1045
00:45:45,300 --> 00:45:48,800
Clean data helps, but clean data alone won't capture these conditions.

1046
00:45:48,800 --> 00:45:53,600
A perfectly accurate table can still leave the system unable to explain what a record permits,

1047
00:45:53,600 --> 00:45:55,100
blocks, or changes.

1048
00:45:55,100 --> 00:45:59,100
Why better data quality is necessary but not enough?

1049
00:45:59,100 --> 00:46:00,600
When teams hit these problems,

1050
00:46:00,600 --> 00:46:03,900
the first response often sounds sensible, clean the data.

1051
00:46:03,900 --> 00:46:06,300
And yes, they should, if machine events arrive late,

1052
00:46:06,300 --> 00:46:08,400
if timestamps use different time zones,

1053
00:46:08,400 --> 00:46:11,100
if quantities don't reconcile between MS and ERP,

1054
00:46:11,100 --> 00:46:13,600
or if nobody knows which version of a route applies,

1055
00:46:13,600 --> 00:46:15,900
then no planning model will earn trust.

1056
00:46:15,900 --> 00:46:18,100
Bad data creates bad decisions faster.

1057
00:46:18,100 --> 00:46:20,000
There's no clever AI workaround for that.

1058
00:46:20,000 --> 00:46:23,600
Accurate timestamps matter because production depends on sequence.

1059
00:46:23,600 --> 00:46:27,700
If a system can't tell whether an inspection happened before or after a process step,

1060
00:46:27,700 --> 00:46:30,100
it can't reliably decide whether the batch can move,

1061
00:46:30,100 --> 00:46:31,800
complete tag data matters too,

1062
00:46:31,800 --> 00:46:35,900
because a missing state change may turn normal production into a false downtime event.

1063
00:46:35,900 --> 00:46:39,000
But clean data only tells you that the recorded facts are dependable.

1064
00:46:39,000 --> 00:46:40,700
It doesn't tell you what those facts permit.

1065
00:46:40,700 --> 00:46:43,100
Think about two tables that both contain clean,

1066
00:46:43,100 --> 00:46:44,900
complete, well-governed records.

1067
00:46:44,900 --> 00:46:47,000
One table list available machine hours.

1068
00:46:47,000 --> 00:46:48,600
Another list's open work orders.

1069
00:46:48,600 --> 00:46:51,600
You can join them, sort them, and publish them in a report.

1070
00:46:51,600 --> 00:46:53,100
Yet the results still won't answer

1071
00:46:53,100 --> 00:46:56,700
whether work order 817 can run on a certain resource this afternoon.

1072
00:46:56,700 --> 00:46:58,800
That answer depends on meaning outside the rows.

1073
00:46:58,800 --> 00:47:01,600
Does available mean the machine has no scheduled order?

1074
00:47:01,600 --> 00:47:03,700
Or does it mean the machine is released by maintenance?

1075
00:47:03,700 --> 00:47:06,600
Has the correct tool and has a qualified operator assigned?

1076
00:47:06,600 --> 00:47:09,500
Does complete mean the final part, left the machine,

1077
00:47:09,500 --> 00:47:12,800
the quantity passed inspection, the batch posted to inventory,

1078
00:47:12,800 --> 00:47:14,700
or the order closed in ERP?

1079
00:47:14,700 --> 00:47:17,400
Different teams often use the same word for different states.

1080
00:47:17,400 --> 00:47:18,900
Nobody is necessarily wrong.

1081
00:47:18,900 --> 00:47:21,400
They may simply speak from different parts of the process.

1082
00:47:21,400 --> 00:47:24,000
A production supervisor may call an operation complete

1083
00:47:24,000 --> 00:47:26,100
when the planned quantity leaves the work center.

1084
00:47:26,100 --> 00:47:29,700
Quality may call it incomplete until the inspection result passes.

1085
00:47:29,700 --> 00:47:32,900
Finance may see completion only after transaction posts in ERP.

1086
00:47:32,900 --> 00:47:36,300
If a data model treats those states as one field called complete,

1087
00:47:36,300 --> 00:47:39,000
it creates confusion with perfect technical accuracy.

1088
00:47:39,000 --> 00:47:40,800
The fix is a shared semantic model.

1089
00:47:40,800 --> 00:47:43,300
That means defining what the business terms mean,

1090
00:47:43,300 --> 00:47:47,500
which systems applies each fact and how those facts connect in a given decision.

1091
00:47:47,500 --> 00:47:50,900
It turns a familiar word into a statement people can test, for example.

1092
00:47:50,900 --> 00:47:53,900
The model may define production availability as a resource

1093
00:47:53,900 --> 00:47:55,900
that is technically ready, released for use,

1094
00:47:55,900 --> 00:47:57,300
not reserved for maintenance,

1095
00:47:57,300 --> 00:47:58,900
compatible with the operation,

1096
00:47:58,900 --> 00:48:01,500
and staffed for the planned time window.

1097
00:48:01,500 --> 00:48:04,200
That definition may not fit every plant or every decision.

1098
00:48:04,200 --> 00:48:05,000
It doesn't need to.

1099
00:48:05,000 --> 00:48:06,900
The point is that the definition is explicit.

1100
00:48:06,900 --> 00:48:08,600
Capacity needs the same care.

1101
00:48:08,600 --> 00:48:12,700
A planning system may calculate rated capacity from standard hours and scheduled shifts.

1102
00:48:12,700 --> 00:48:16,100
The floor may see usable capacity as whatever can run with current tooling,

1103
00:48:16,100 --> 00:48:18,400
materials, people and maintenance conditions.

1104
00:48:18,400 --> 00:48:22,500
Both views can help problems start when a replant treats rated capacity

1105
00:48:22,500 --> 00:48:25,600
as usable capacity without checking the conditions around it.

1106
00:48:25,600 --> 00:48:27,600
This is why data quality scores can be misleading.

1107
00:48:27,600 --> 00:48:30,100
You can measure null values, duplicate records,

1108
00:48:30,100 --> 00:48:32,000
late events, and failed interfaces.

1109
00:48:32,000 --> 00:48:33,100
Those checks matter.

1110
00:48:33,100 --> 00:48:35,600
Yet a table can receive a high score while nobody agrees

1111
00:48:35,600 --> 00:48:37,400
how it should drive a production decision.

1112
00:48:37,400 --> 00:48:39,500
A better test asks a more practical question.

1113
00:48:39,500 --> 00:48:41,900
When the system tells a planner that an order can move,

1114
00:48:41,900 --> 00:48:44,300
can the planner trace the statement back to the source facts,

1115
00:48:44,300 --> 00:48:47,100
the business definitions, and the rules that produced it?

1116
00:48:47,100 --> 00:48:49,800
If the answer is no, you don't have enough context yet.

1117
00:48:49,800 --> 00:48:52,500
The semantic model creates a common layer for that context.

1118
00:48:52,500 --> 00:48:57,300
It doesn't overwrite the ERP definition of an order or the MES definition of execution.

1119
00:48:57,300 --> 00:48:59,500
Instead, it states how those definitions relate

1120
00:48:59,500 --> 00:49:01,800
when the plant asks a cross-system question.

1121
00:49:01,800 --> 00:49:04,100
That separation keeps ownership clear.

1122
00:49:04,100 --> 00:49:07,500
ERP can remain the source for customer dates and formal work orders.

1123
00:49:07,500 --> 00:49:10,700
MES can remain the source for shop floor execution.

1124
00:49:10,700 --> 00:49:14,100
Maintenance and quality can retain their own records and approval rules.

1125
00:49:14,100 --> 00:49:16,500
The context model connects the parts that need to meet

1126
00:49:16,500 --> 00:49:18,500
when someone must decide how to respond.

1127
00:49:18,500 --> 00:49:21,100
So improve the data, fix broken interfaces,

1128
00:49:21,100 --> 00:49:24,300
standardize identifiers, track missing events, just don't stop there.

1129
00:49:24,300 --> 00:49:26,700
A factory can have clean tables and still lack a shared answer

1130
00:49:26,700 --> 00:49:30,500
to simple words like available, capacity, complete, and done.

1131
00:49:30,500 --> 00:49:33,500
Until those words carry a greed meaning in the decision model,

1132
00:49:33,500 --> 00:49:36,200
AI will still fill the gaps with assumptions.

1133
00:49:36,200 --> 00:49:39,200
The factory changes faster than the model.

1134
00:49:39,200 --> 00:49:42,600
Here's another problem that shows up as soon as you build a semantic model.

1135
00:49:42,600 --> 00:49:45,100
The factory doesn't hold still while you're modeling it.

1136
00:49:45,100 --> 00:49:48,800
A schedule might look fine at shift start, then drift within an hour.

1137
00:49:48,800 --> 00:49:52,300
A machine slows, an operator finds scrap, material arrives late,

1138
00:49:52,300 --> 00:49:54,900
or a quality check holds a batch longer than planned.

1139
00:49:54,900 --> 00:49:56,300
The model has to handle that movement

1140
00:49:56,300 --> 00:49:59,800
or it becomes a very accurate description of a factory that no longer exists.

1141
00:49:59,800 --> 00:50:03,400
That's why plant state and actual state need to sit side by side.

1142
00:50:03,400 --> 00:50:06,000
Plant state tells you what the plant intended to do.

1143
00:50:06,000 --> 00:50:09,600
It covers the production schedule, expected runtimes, assigned resources,

1144
00:50:09,600 --> 00:50:14,100
booked maintenance windows, expected material arrivals and target completion dates.

1145
00:50:14,100 --> 00:50:17,900
Planning needs that view because it gives people a starting point to work from.

1146
00:50:17,900 --> 00:50:20,800
Actual state tells you what production has actually done so far.

1147
00:50:20,800 --> 00:50:24,800
It includes current machine condition, quantity produced, quantity rejected,

1148
00:50:24,800 --> 00:50:27,500
work waiting in queues, material actually received,

1149
00:50:27,500 --> 00:50:30,600
and work orders that started later, or earlier than planned.

1150
00:50:30,600 --> 00:50:31,900
Neither view works alone.

1151
00:50:31,900 --> 00:50:34,900
If you only use plant data, a schedule can look healthy

1152
00:50:34,900 --> 00:50:36,800
even after the floor is moved away from it.

1153
00:50:36,800 --> 00:50:39,600
If you only use actual data, you know where things are,

1154
00:50:39,600 --> 00:50:42,600
but you can't judge the effect against the plan you were trying to meet.

1155
00:50:42,600 --> 00:50:44,000
Take the same machine outage.

1156
00:50:44,000 --> 00:50:47,700
At 8 in the morning, the plan might place work order 811 team on machine 4

1157
00:50:47,700 --> 00:50:49,800
until noon, then send it to inspection.

1158
00:50:49,800 --> 00:50:51,000
At 10, the machine stops.

1159
00:50:51,000 --> 00:50:53,800
By 11, maintenance revises the repair estimate.

1160
00:50:53,800 --> 00:50:56,900
Meanwhile, another order finishes early on an alternate resource.

1161
00:50:56,900 --> 00:50:59,800
Those changes shift the choices available to the planner.

1162
00:50:59,800 --> 00:51:04,600
A model that only reads the morning schedule will miss the new opening on that alternate resource.

1163
00:51:04,600 --> 00:51:06,900
A model that only reads live machine status may miss

1164
00:51:06,900 --> 00:51:10,700
that using the opening would push a higher priority order past its delivery commitment.

1165
00:51:10,700 --> 00:51:14,300
Replanning depends on both the intended route and the current position.

1166
00:51:14,300 --> 00:51:16,600
Time also changes what the facts mean.

1167
00:51:16,600 --> 00:51:20,800
An available tool at shift start may become unavailable after a technician assigns it to another job.

1168
00:51:20,800 --> 00:51:25,800
A resource that supports a product revision today may lose that approval after an engineering change.

1169
00:51:25,800 --> 00:51:30,900
A route that applied to work released last month may not apply to work released after a revision date.

1170
00:51:30,900 --> 00:51:33,900
So the model needs effective time, not just current values.

1171
00:51:33,900 --> 00:51:35,800
When did this relationship apply?

1172
00:51:35,800 --> 00:51:36,800
When did the machine move?

1173
00:51:36,800 --> 00:51:38,700
Which recipe version governed that batch?

1174
00:51:38,700 --> 00:51:41,000
Which maintenance state was active when the stop occurred?

1175
00:51:41,000 --> 00:51:44,300
These questions matter when people need to explain a decision later?

1176
00:51:44,300 --> 00:51:47,100
Or when an AI system tries to learn from past events?

1177
00:51:47,100 --> 00:51:48,800
Event history supports that work.

1178
00:51:48,800 --> 00:51:52,200
The plan doesn't need to store every thought someone had during a shift.

1179
00:51:52,200 --> 00:51:55,500
But it does need a trace of operational events that change the situation.

1180
00:51:55,500 --> 00:52:03,200
Machine stops, repair updates, quantity postings, quality holds, route changes, material releases, and planner decisions.

1181
00:52:03,200 --> 00:52:05,100
That history gives you traceability.

1182
00:52:05,100 --> 00:52:06,600
It also gives you a basis for learning.

1183
00:52:06,600 --> 00:52:09,800
Over time you can compare planned duration against actual duration.

1184
00:52:09,800 --> 00:52:13,300
You can study how often the certain failure created downstream delay.

1185
00:52:13,300 --> 00:52:19,400
You can see whether a re-root commonly worked or whether it caused quality issues extra setup time or trouble at the next operation.

1186
00:52:19,400 --> 00:52:24,500
But learning from history only works if you preserve the context that existed at the time.

1187
00:52:24,500 --> 00:52:28,600
A record that says "machine 4 stopped" tells you very little by itself.

1188
00:52:28,600 --> 00:52:36,500
A record that connects the stop to the active order, product revision, route version, resource condition, and later outcome gives you something far more useful.

1189
00:52:36,500 --> 00:52:39,000
You can ask whether the repair estimate was right.

1190
00:52:39,000 --> 00:52:41,500
You can ask whether the chosen replan protected the due date?

1191
00:52:41,500 --> 00:52:43,700
You can examine where the model missed a constraint.

1192
00:52:43,700 --> 00:52:45,900
That also means the model needs change control.

1193
00:52:45,900 --> 00:52:47,600
Engineering can revise a root.

1194
00:52:47,600 --> 00:52:49,800
Mente nons can change an asset structure.

1195
00:52:49,800 --> 00:52:52,200
Quality can revise in approved process condition.

1196
00:52:52,200 --> 00:52:54,000
Planning can alter a capacity rule.

1197
00:52:54,000 --> 00:52:57,100
Those changes shouldn't silently overwrite the past.

1198
00:52:57,100 --> 00:52:59,800
Because past production happened under prior conditions.

1199
00:52:59,800 --> 00:53:03,100
The model needs to know which version applied and when.

1200
00:53:03,100 --> 00:53:05,800
This sounds like extra effort because it is extra effort.

1201
00:53:05,800 --> 00:53:07,600
A living factory model needs care.

1202
00:53:07,600 --> 00:53:13,000
But a static model becomes unreliable quickly, especially once people use it to support decisions under pressure.

1203
00:53:13,000 --> 00:53:15,700
So don't treat context as a one-time data project.

1204
00:53:15,700 --> 00:53:22,200
Treat it as an operational model that receives current events, keeps planned an actual state apart, retains enough history to explain change,

1205
00:53:22,200 --> 00:53:26,000
and manages the versions of the facts that shape production decisions.

1206
00:53:26,000 --> 00:53:28,800
Once you accept that, the next question becomes practical.

1207
00:53:28,800 --> 00:53:30,200
Where does this model sit?

1208
00:53:30,200 --> 00:53:37,600
And how do the operational systems, data services and decision tools work together without creating another disconnected layer?

1209
00:53:37,600 --> 00:53:40,900
The architecture in three working layers.

1210
00:53:40,900 --> 00:53:46,400
Once you treat factory context as a living model, the architecture becomes easier to talk about.

1211
00:53:46,400 --> 00:53:50,400
Not simple, but easier because each part has a clear job.

1212
00:53:50,400 --> 00:53:52,000
I think of it in three working layers.

1213
00:53:52,000 --> 00:53:53,700
The first is the operational layer.

1214
00:53:53,700 --> 00:53:56,800
This is where production work happens and where the source facts begin.

1215
00:53:56,800 --> 00:54:01,300
Your ERP holds demand, work orders, material plans and customer commitments.

1216
00:54:01,300 --> 00:54:06,000
Your MS records execution on the shop floor, maintenance manages asset work and repair status,

1217
00:54:06,000 --> 00:54:09,300
quality owns inspection results, holds and release decisions.

1218
00:54:09,300 --> 00:54:12,300
Closer to the physical process, PLC's control equipment,

1219
00:54:12,300 --> 00:54:15,500
historians retain detailed machine and process signals over time.

1220
00:54:15,500 --> 00:54:19,700
IoT gateways may collect events from controllers and pass selected data into IT systems.

1221
00:54:19,700 --> 00:54:22,500
Each system works to its own time scale and risk level.

1222
00:54:22,500 --> 00:54:27,700
Because a controller protecting a machine has a very different job from a planning system reviewing tomorrow's schedule.

1223
00:54:27,700 --> 00:54:29,400
That separation should stay.

1224
00:54:29,400 --> 00:54:34,400
Production equipment shouldn't depend on a cloud connection before it can stop safely, run safely,

1225
00:54:34,400 --> 00:54:36,900
or respond to a local control condition.

1226
00:54:36,900 --> 00:54:39,500
A decision service can inform people about a disruption,

1227
00:54:39,500 --> 00:54:42,600
but it shouldn't sit in the direct command path to equipment by default.

1228
00:54:42,600 --> 00:54:45,900
That would turn an information project into a plant availability risk.

1229
00:54:45,900 --> 00:54:46,900
Nobody needs that.

1230
00:54:46,900 --> 00:54:50,200
Above the operational layer sits the data and context layer.

1231
00:54:50,200 --> 00:54:55,900
This is where information from those source systems becomes available for shared analysis and cross-system decisions,

1232
00:54:55,900 --> 00:55:01,000
without pretending that the source systems no longer own their own facts.

1233
00:55:01,000 --> 00:55:06,200
Data ingestion brings in events, transactions, status changes, master data and reference data.

1234
00:55:06,200 --> 00:55:09,200
Storage retains the records at the level needed for the decision.

1235
00:55:09,200 --> 00:55:12,800
Some information arrives as live events, other information updates on a schedule.

1236
00:55:12,800 --> 00:55:16,000
A routing revision may change far less often than a machine state,

1237
00:55:16,000 --> 00:55:18,000
and the architecture should respect that.

1238
00:55:18,000 --> 00:55:22,000
Then comes the semantic work. This layer defines what an asset, work order,

1239
00:55:22,000 --> 00:55:25,400
operation, material, tool and location mean in the decision model.

1240
00:55:25,400 --> 00:55:27,400
It also keeps the relationships between them.

1241
00:55:27,400 --> 00:55:30,600
An event from a controller can connect to a physical asset.

1242
00:55:30,600 --> 00:55:33,100
That asset can connect to a production resource.

1243
00:55:33,100 --> 00:55:35,700
The resource can connect to the operations it supports,

1244
00:55:35,700 --> 00:55:38,100
subject to the conditions the plant has defined.

1245
00:55:38,100 --> 00:55:41,800
A graph can fit here when the decision depends on traversing those relationships.

1246
00:55:41,800 --> 00:55:46,800
A semantic model can fit here when teams need consistent business definitions for analytics and planning.

1247
00:55:46,800 --> 00:55:52,200
In many cases you'll use both. The product choice matters less than making the meaning explicit and keeping it governed.

1248
00:55:52,200 --> 00:55:55,000
The data and context layer also needs traceability.

1249
00:55:55,000 --> 00:55:56,900
When a result says an order sits at risk,

1250
00:55:56,900 --> 00:56:01,600
people need to trace it back through the event execution record, route, capacity condition

1251
00:56:01,600 --> 00:56:04,400
and delivery commitment that produced that conclusion.

1252
00:56:04,400 --> 00:56:09,000
Otherwise, the model becomes another system, people consult only when it agrees with the spreadsheet.

1253
00:56:09,000 --> 00:56:13,400
The third layer is the decision layer. This is where people consume information and act on it.

1254
00:56:13,400 --> 00:56:16,400
Power BI reports may monitor production, state and exceptions.

1255
00:56:16,400 --> 00:56:20,300
Simulation can test the likely result of a schedule change under stated assumptions.

1256
00:56:20,300 --> 00:56:24,800
Optimization can search for feasible plans within the constraints that belong to the model.

1257
00:56:24,800 --> 00:56:30,400
Workflow can route a proposed decision to the planner, supervisor, quality team or maintenance team

1258
00:56:30,400 --> 00:56:31,500
that needs to approve it.

1259
00:56:31,500 --> 00:56:34,800
A co-pilot or conversational interface can sit here too.

1260
00:56:34,800 --> 00:56:37,800
But it needs to query grounded facts and defined rules.

1261
00:56:37,800 --> 00:56:41,100
It can help a planner ask which orders are exposed by this outage

1262
00:56:41,100 --> 00:56:43,700
and it can gather the reason and alternate route fails.

1263
00:56:43,700 --> 00:56:47,100
It can prepare an explanation of the trade-offs between two feasible options.

1264
00:56:47,100 --> 00:56:50,300
It should not invent a production instruction and send it to a machine.

1265
00:56:50,300 --> 00:56:51,800
That line needs to stay clear.

1266
00:56:51,800 --> 00:56:56,800
Decision support can move quickly but physical control, safety interlocks and local operating limits

1267
00:56:56,800 --> 00:57:01,800
remain in the operational layer under the systems and people responsible for running the equipment.

1268
00:57:01,800 --> 00:57:04,700
Think about how the layers work when machine force stops.

1269
00:57:04,700 --> 00:57:10,300
The operational layer records default, the work in progress, the maintenance response and the production status.

1270
00:57:10,300 --> 00:57:16,100
The data and context layer connects those facts to the affected order, route, resources and constraints.

1271
00:57:16,100 --> 00:57:20,700
The decision layer shows the impact, tests available actions, explains the trade-offs,

1272
00:57:20,700 --> 00:57:23,700
and routes the chosen action through the right approval path.

1273
00:57:23,700 --> 00:57:29,100
Each layer needs the others but they shouldn't collapse into one giant platform with unclear ownership.

1274
00:57:29,100 --> 00:57:33,100
That's the architecture that actually scales, source systems running operations,

1275
00:57:33,100 --> 00:57:38,900
a context layer connecting meaning across IT and OT and decision tools helping people choose what to do next,

1276
00:57:38,900 --> 00:57:40,900
where Azure fits.

1277
00:57:40,900 --> 00:57:45,500
So where does Azure actually belong in this picture without turning the whole thing into a cloud-first story

1278
00:57:45,500 --> 00:57:47,700
that ignores how a plant really runs?

1279
00:57:47,700 --> 00:57:53,100
As you give you the building blocks for secure connectivity, integration, event processing, storage and AI services,

1280
00:57:53,100 --> 00:57:57,900
it gives IT teams a managed place to move selected operational data, apply security controls,

1281
00:57:57,900 --> 00:58:02,900
connect enterprise systems, and run workloads that need more scale than a local server can handle.

1282
00:58:02,900 --> 00:58:06,300
But here's the thing, Azure doesn't know what your machine tags mean.

1283
00:58:06,300 --> 00:58:10,300
That meaning still comes from your asset model, your process rules, your mess configuration,

1284
00:58:10,300 --> 00:58:13,900
your engineering data, and the people who understand how the line runs.

1285
00:58:13,900 --> 00:58:15,900
Azure can host and process the information.

1286
00:58:15,900 --> 00:58:19,500
It can't infer an approved route, a quality restriction or a maintenance rule,

1287
00:58:19,500 --> 00:58:21,900
just because a fault event shows up with a timestamp.

1288
00:58:21,900 --> 00:58:24,500
Let's trace the path from a machine to a production decision.

1289
00:58:24,500 --> 00:58:27,700
Near the equipment, a PLC detects a state change or an alarm.

1290
00:58:27,700 --> 00:58:32,900
An industrial gateway edge computer or existing historian connector can collect that event locally.

1291
00:58:32,900 --> 00:58:37,500
That local layer can filter noise, buffer data during an outage, and send only the information

1292
00:58:37,500 --> 00:58:39,500
that serves a wider business or planning need.

1293
00:58:39,500 --> 00:58:41,500
This local boundary protects the plant.

1294
00:58:41,500 --> 00:58:45,700
If a cloud service slows down, if an internet connection drops or if an integration job fails,

1295
00:58:45,700 --> 00:58:51,700
the machine will still follow its local logic, safety functions, interlocks, emergency stops and control loops,

1296
00:58:51,700 --> 00:58:56,700
those belong close to the physical process under the responsibility of the systems designed for that job.

1297
00:58:56,700 --> 00:58:58,300
Azure belongs beyond that boundary.

1298
00:58:58,300 --> 00:59:04,700
From there, Azure can receive events through secure integration paths and distribute them to the services that need them.

1299
00:59:04,700 --> 00:59:08,900
A machine stop might reach a stream processing service, a data store, a maintenance workflow,

1300
00:59:08,900 --> 00:59:11,100
or a data platform used for wider analysis.

1301
00:59:11,100 --> 00:59:16,100
A work order update from ERP may arrive through a separate integration path at a slower pace

1302
00:59:16,100 --> 00:59:19,300
because it doesn't need the same response time as a fault signal.

1303
00:59:19,300 --> 00:59:21,300
Those paths shouldn't all work the same way.

1304
00:59:21,300 --> 00:59:25,700
A machine event may need near real-time handling because a planner needs to assess an active disruption.

1305
00:59:25,700 --> 00:59:28,300
A root revision can arrive through a scheduled update.

1306
00:59:28,300 --> 00:59:32,100
Maintenance status might change only when a technician updates a work order.

1307
00:59:32,100 --> 00:59:34,700
The architecture needs to account for those different rhythms,

1308
00:59:34,700 --> 00:59:38,900
rather than pushing every record through one universal pipeline and hoping for the best.

1309
00:59:38,900 --> 00:59:40,900
Failure handling matters just as much.

1310
00:59:40,900 --> 00:59:43,100
What happens if the gateway loses its connection?

1311
00:59:43,100 --> 00:59:45,700
Does it retain events locally and send them later?

1312
00:59:45,700 --> 00:59:49,100
How does the platform detect duplicate messages after reconnecting?

1313
00:59:49,100 --> 00:59:52,500
Which system owns the final status if an event reaches Azure

1314
00:59:52,500 --> 00:59:57,100
before the MES has posted the related execution update, those sound like integration details.

1315
00:59:57,100 --> 00:59:58,300
They're really decision details.

1316
00:59:58,300 --> 01:00:01,500
If the context model treats delayed or duplicated events as current truth,

1317
01:00:01,500 --> 01:00:05,700
it can tell a planner that a machine remains down after maintenance has released it.

1318
01:00:05,700 --> 01:00:08,300
Or it can link a fault to the wrong production state

1319
01:00:08,300 --> 01:00:10,900
because the event sequence arrived out of order.

1320
01:00:10,900 --> 01:00:12,900
Good architecture doesn't remove these cases.

1321
01:00:12,900 --> 01:00:15,700
It identifies them and defines how the system handles them.

1322
01:00:15,700 --> 01:00:18,900
Identity and security also belong in this part of the design.

1323
01:00:18,900 --> 01:00:22,700
Azure can help apply access control, managed identities, encryption network boundaries,

1324
01:00:22,700 --> 01:00:24,700
and monitoring around data and services.

1325
01:00:24,700 --> 01:00:30,300
That matters when production, maintenance, quality, and commercial information meet in one decision float.

1326
01:00:30,300 --> 01:00:34,300
Not everyone who can view an OEE report should automatically see customer commitments,

1327
01:00:34,300 --> 01:00:37,100
maintenance notes, or detailed process data.

1328
01:00:37,100 --> 01:00:39,300
Permissions need to follow the decision context.

1329
01:00:39,300 --> 01:00:41,500
OT and IT teams also need clear ownership.

1330
01:00:41,500 --> 01:00:43,500
OT owns the safe operation of equipment

1331
01:00:43,500 --> 01:00:46,500
and often owns the local data collection rules near the line.

1332
01:00:46,500 --> 01:00:49,700
It owns enterprise integration, identity, cloud operations,

1333
01:00:49,700 --> 01:00:52,900
and many of the services that keep data available for business use.

1334
01:00:52,900 --> 01:00:54,700
Neither group can build this alone

1335
01:00:54,700 --> 01:00:58,700
because the hard work sits in the handoff between a physical event and its production meaning.

1336
01:00:58,700 --> 01:01:03,700
As a Microsoft MVP, I spend a lot of time looking at where Azure fits in industrial architecture.

1337
01:01:03,700 --> 01:01:05,500
I'd be careful with one assumption,

1338
01:01:05,500 --> 01:01:08,700
sending data to Azure doesn't complete OT, IT conversions.

1339
01:01:08,700 --> 01:01:09,700
It starts the work.

1340
01:01:09,700 --> 01:01:13,900
Azure gives you a controlled way to connect systems, process data, run models,

1341
01:01:13,900 --> 01:01:16,300
and support workflows beyond the plant boundary.

1342
01:01:16,300 --> 01:01:18,700
The factory still needs to decide which events matter,

1343
01:01:18,700 --> 01:01:22,300
who owns each source, how late or missing data changes a result,

1344
01:01:22,300 --> 01:01:25,100
and which decisions remain with people on the floor.

1345
01:01:25,100 --> 01:01:29,100
Build the event path around latency, failure modes, ownership, and plant risk.

1346
01:01:29,100 --> 01:01:32,900
Then Azure becomes a useful part of an architecture that actually scales,

1347
01:01:32,900 --> 01:01:37,100
rather than another place where production data goes to wait for someone to explain it.

1348
01:01:37,100 --> 01:01:39,500
Where Microsoft Fabric fits.

1349
01:01:39,500 --> 01:01:43,100
Microsoft Fabric becomes relevant once the factory needs a shared place to work

1350
01:01:43,100 --> 01:01:47,900
with operational and enterprise data, without creating a fresh copy of every record for every team.

1351
01:01:47,900 --> 01:01:48,900
That sounds obvious.

1352
01:01:48,900 --> 01:01:51,300
In practice, it's where many data programs slow down.

1353
01:01:51,300 --> 01:01:54,300
Production data may sit in a historian or a mes database.

1354
01:01:54,300 --> 01:01:57,700
Order and material facts may sit in ERP, maintenance has its own system.

1355
01:01:57,700 --> 01:01:58,700
Quality has another.

1356
01:01:58,700 --> 01:02:02,100
Each team exports what it needs, often into a report model, a local database,

1357
01:02:02,100 --> 01:02:05,900
or inevitably a spreadsheet that becomes more trusted than the system it came from.

1358
01:02:05,900 --> 01:02:09,700
Fabric can provide a common analytics environment for that wider set of data.

1359
01:02:09,700 --> 01:02:14,100
It can support ingestion, engineering, analysis, and governed reporting in one Microsoft platform.

1360
01:02:14,100 --> 01:02:16,900
For manufacturers already using Microsoft data services,

1361
01:02:16,900 --> 01:02:20,300
that can reduce the number of handoffs between isolated reporting projects.

1362
01:02:20,300 --> 01:02:23,300
The point isn't to move everything into Fabric just because it exists.

1363
01:02:23,300 --> 01:02:25,900
Some production data needs to stay close to the plant.

1364
01:02:25,900 --> 01:02:29,300
Some detailed high-frequency signals belong in specialist historians.

1365
01:02:29,300 --> 01:02:34,900
Some execution data stays in VS because that system manages the transaction and the operational workflow.

1366
01:02:34,900 --> 01:02:39,100
Fabric fits when people need to combine selected facts from those places for analysis,

1367
01:02:39,100 --> 01:02:41,900
planning support, and cross-system decisions.

1368
01:02:41,900 --> 01:02:45,300
One Lake matters in this conversation because it creates a shared data foundation

1369
01:02:45,300 --> 01:02:46,900
across Fabric workloads.

1370
01:02:46,900 --> 01:02:49,900
Rather than every reporting team building another private extract,

1371
01:02:49,900 --> 01:02:54,700
teams can work from govern data products where the architecture and access rules allow it.

1372
01:02:54,700 --> 01:02:58,900
That can reduce duplication and cut down on arguments about which copy of a work order table

1373
01:02:58,900 --> 01:03:00,300
people should trust this week.

1374
01:03:00,300 --> 01:03:02,500
But shared storage doesn't create shared meaning.

1375
01:03:02,500 --> 01:03:06,500
You can bring an mes event, an ERP order, a maintenance status,

1376
01:03:06,500 --> 01:03:09,300
and a PLC alarm into the same Fabric environment.

1377
01:03:09,300 --> 01:03:12,300
They may still refer to the same machine with different IDs.

1378
01:03:12,300 --> 01:03:15,300
They may still use different definitions of availability.

1379
01:03:15,300 --> 01:03:18,500
They may still fail to state which routing rule blocks an alternate resource.

1380
01:03:18,500 --> 01:03:20,500
Fabric gives you a place to bring data together.

1381
01:03:20,500 --> 01:03:23,100
The factory still needs to connect the facts correctly.

1382
01:03:23,100 --> 01:03:26,500
This is where Fabric's data engineering and data science capabilities

1383
01:03:26,500 --> 01:03:28,500
can support the wider context work.

1384
01:03:28,500 --> 01:03:32,700
You can prepare data from several sources, manage transformations, retain history,

1385
01:03:32,700 --> 01:03:37,300
and build analytical views that planners, engineers and analysts can use.

1386
01:03:37,300 --> 01:03:39,500
You can also support machine learning workloads

1387
01:03:39,500 --> 01:03:42,300
where a model has a clear question and grounded input data.

1388
01:03:42,300 --> 01:03:46,900
For example, a team may combine repair history, machine events, execution data,

1389
01:03:46,900 --> 01:03:50,300
and schedule facts to study patterns around recurring disruption.

1390
01:03:50,300 --> 01:03:51,300
That can be useful.

1391
01:03:51,300 --> 01:03:53,900
Yet the result only becomes operationally sound

1392
01:03:53,900 --> 01:03:57,100
when the model can distinguish a stop on an unconstrained resource

1393
01:03:57,100 --> 01:04:00,300
from a stop during an operation that puts a committed order at risk.

1394
01:04:00,300 --> 01:04:02,300
The data platform supplies the material.

1395
01:04:02,300 --> 01:04:04,300
The context model supplies the meaning.

1396
01:04:04,300 --> 01:04:07,100
Power BI fits at the consumption end of that flow.

1397
01:04:07,100 --> 01:04:11,900
A semantic model in Power BI can define shared measures in terms for business audience.

1398
01:04:11,900 --> 01:04:15,100
It can help avoid a situation where production, finance, and supply chain

1399
01:04:15,100 --> 01:04:18,100
all calculate the same metric differently from the same records.

1400
01:04:18,100 --> 01:04:19,500
That sort of governance matters.

1401
01:04:19,500 --> 01:04:22,700
Still, a Power BI semantic model shouldn't become a hidden substitute

1402
01:04:22,700 --> 01:04:24,900
for all factory relationships and planning rules.

1403
01:04:24,900 --> 01:04:27,700
Measures can express business logic, reports can support people

1404
01:04:27,700 --> 01:04:29,300
who need to monitor operations.

1405
01:04:29,300 --> 01:04:32,900
But complex production contexts may also need relationship models and rule services

1406
01:04:32,900 --> 01:04:36,700
outside the report layer, especially when the question crosses live execution,

1407
01:04:36,700 --> 01:04:40,500
process approval, asset capability, and planning constraints.

1408
01:04:40,500 --> 01:04:41,900
Keep the jobs separate.

1409
01:04:41,900 --> 01:04:46,300
Fabric can help organize and govern the data used across analytics and decision support.

1410
01:04:46,300 --> 01:04:49,500
Power BI can make that information available to the people who needed.

1411
01:04:49,500 --> 01:04:54,500
Azure services can handle integration, event parts, security, and workloads

1412
01:04:54,500 --> 01:04:56,100
that sit around the data platform.

1413
01:04:56,100 --> 01:04:59,700
None of those products automatically resolves whether a machine can process a product

1414
01:04:59,700 --> 01:05:00,900
revision on a given shift.

1415
01:05:00,900 --> 01:05:04,200
That answer comes from the model your engineering planning, quality, and

1416
01:05:04,200 --> 01:05:06,300
operations teams agree to maintain.

1417
01:05:06,300 --> 01:05:13,300
It needs a home, clear ownership, and rules for change, building the semantic layer.

1418
01:05:13,300 --> 01:05:17,500
Before you touch a schema, a graph database, or start building a data engineering

1419
01:05:17,500 --> 01:05:20,700
backlog, you need a clear purpose for that semantic layer.

1420
01:05:20,700 --> 01:05:23,300
So start with the decision people actually struggle to make.

1421
01:05:23,300 --> 01:05:26,700
Don't begin with every table you can access or every tag in the historian.

1422
01:05:26,700 --> 01:05:30,900
Ask a planner or supervisor a dead simple question when a disruption happens.

1423
01:05:30,900 --> 01:05:34,100
What's the one thing you need to know before you can act with confidence?

1424
01:05:34,100 --> 01:05:36,700
That answer usually points straight to the first model.

1425
01:05:36,700 --> 01:05:39,900
For an outage impact question, you might need to know the affected asset,

1426
01:05:39,900 --> 01:05:43,100
the current operation, the active order, the remaining quantity, the approved

1427
01:05:43,100 --> 01:05:46,100
alternatives, and the conditions that block those alternatives.

1428
01:05:46,100 --> 01:05:49,300
Maybe delivery commitments, tool status, equality release.

1429
01:05:49,300 --> 01:05:52,700
But you definitely don't need to model every object in the plant

1430
01:05:52,700 --> 01:05:54,300
just to answer that one question.

1431
01:05:54,300 --> 01:05:56,500
That alone keeps the project from spiraling.

1432
01:05:56,500 --> 01:06:00,300
I'd start by naming the core entities in language people already use asset,

1433
01:06:00,300 --> 01:06:04,900
production resource operation, work order, material, tool, person, location.

1434
01:06:04,900 --> 01:06:08,300
And depending on the decision, you might add batch recipe inspection result,

1435
01:06:08,300 --> 01:06:12,500
maintenance job, or shift names matter because the model has to make sense

1436
01:06:12,500 --> 01:06:15,900
to people outside the data team take asset versus production resource.

1437
01:06:15,900 --> 01:06:19,500
And asset is the physical machine maintenance works on a production resource

1438
01:06:19,500 --> 01:06:21,500
is the capacity object planning schedules.

1439
01:06:21,500 --> 01:06:24,900
They might point to the same equipment, but they don't always mean the same thing.

1440
01:06:24,900 --> 01:06:27,700
Treat them as identical just because the labels look alike.

1441
01:06:27,700 --> 01:06:29,500
And you're creating problems down the line.

1442
01:06:29,500 --> 01:06:32,900
Once the entities are clear, define the relationships as full-blown statements.

1443
01:06:32,900 --> 01:06:35,100
An asset supports a production resource.

1444
01:06:35,100 --> 01:06:37,300
That production resource can perform an operation.

1445
01:06:37,300 --> 01:06:40,500
An operation belongs to a root for a specific product revision.

1446
01:06:40,500 --> 01:06:42,300
A work order requires that root.

1447
01:06:42,300 --> 01:06:45,100
A tool is approved for a resource during a time window.

1448
01:06:45,100 --> 01:06:47,500
And a person is qualified for a defined process.

1449
01:06:47,500 --> 01:06:49,500
These statements might sound too simple,

1450
01:06:49,500 --> 01:06:53,300
but they expose exactly what the factory needs to know and what it doesn't.

1451
01:06:53,300 --> 01:06:56,300
If nobody can state which resources can perform an operation,

1452
01:06:56,300 --> 01:06:59,700
you've found a planning problem before you've even got to an AI problem.

1453
01:06:59,700 --> 01:07:00,900
Next up, rules.

1454
01:07:00,900 --> 01:07:02,300
Some relationships are constant.

1455
01:07:02,300 --> 01:07:04,300
A work order always belongs to a product.

1456
01:07:04,300 --> 01:07:07,500
Others shift with time, status, or conditions.

1457
01:07:07,500 --> 01:07:10,500
A resource may perform an operation only when a tool is installed,

1458
01:07:10,500 --> 01:07:13,100
a recipe is approved, and a qualified person is present.

1459
01:07:13,100 --> 01:07:16,100
The semantic layer needs to hold those conditions in a way

1460
01:07:16,100 --> 01:07:17,700
the decision process can check.

1461
01:07:17,700 --> 01:07:22,100
Keep the wording close to how planners, engineers, and quality teams actually talk.

1462
01:07:22,100 --> 01:07:24,500
If the model uses labels nobody on the floor recognizes

1463
01:07:24,500 --> 01:07:26,300
people won't push back when they get something wrong.

1464
01:07:26,300 --> 01:07:27,300
That's dangerous.

1465
01:07:27,300 --> 01:07:29,500
The model has to support a practical conversation.

1466
01:07:29,500 --> 01:07:31,500
Why did the system reject machine 7?

1467
01:07:31,500 --> 01:07:34,500
Because the fixture is reserved until the night shift.

1468
01:07:34,500 --> 01:07:37,900
That answer should trace back to an actual rule and source record,

1469
01:07:37,900 --> 01:07:40,500
not a mysterious calculation buried in a pipeline.

1470
01:07:40,500 --> 01:07:43,100
Source ownership stays in place as you build this out.

1471
01:07:43,100 --> 01:07:45,300
The semantic layer doesn't own the work order,

1472
01:07:45,300 --> 01:07:46,700
just because it links to one.

1473
01:07:46,700 --> 01:07:48,700
ERP still owns the formal order,

1474
01:07:48,700 --> 01:07:50,700
MES owns execution status,

1475
01:07:50,700 --> 01:07:53,700
maintenance owns repair status, quality owns release decisions,

1476
01:07:53,700 --> 01:07:55,700
the semantic layer keeps references,

1477
01:07:55,700 --> 01:07:59,100
interprets them for the decision, and records which source supplied them.

1478
01:07:59,100 --> 01:08:00,900
That distinction matters when data changes.

1479
01:08:00,900 --> 01:08:02,700
If a planner spots a wrong due date,

1480
01:08:02,700 --> 01:08:05,100
they should correct it in the system that owns that due date,

1481
01:08:05,100 --> 01:08:08,300
not patch the semantic layer until the next refresh overrides it.

1482
01:08:08,300 --> 01:08:11,100
The context model can hold derived facts where needed,

1483
01:08:11,100 --> 01:08:14,500
but it shouldn't become an unofficial replacement for systems people already trust.

1484
01:08:14,500 --> 01:08:16,500
You'll also need a way to handle uncertainties.

1485
01:08:16,500 --> 01:08:20,900
Sometimes the source data doesn't yet confirm whether a repair will take two hours or six.

1486
01:08:20,900 --> 01:08:25,500
Sometimes a routing exception exists only in an engineering note waiting for approval.

1487
01:08:25,500 --> 01:08:27,700
The model shouldn't turn unknown into known.

1488
01:08:27,700 --> 01:08:32,300
It should preserve the uncertainty and show that a decision depends on a fact still in flight.

1489
01:08:32,300 --> 01:08:34,300
That's way more useful than false precision.

1490
01:08:34,300 --> 01:08:37,300
You can build this layer in Microsoft Fabric Azure Services,

1491
01:08:37,300 --> 01:08:40,500
a graph platform, a manufacturing application, or a mix.

1492
01:08:40,500 --> 01:08:43,500
The technical home matters, but the model matters more.

1493
01:08:43,500 --> 01:08:47,500
A perfect platform can't rescue unclear definitions or orphaned relationships.

1494
01:08:47,500 --> 01:08:49,100
So start from a decision question.

1495
01:08:49,100 --> 01:08:51,500
Name the things involved, state how they connect,

1496
01:08:51,500 --> 01:08:53,500
attach rules, time, sources, and ownership.

1497
01:08:53,500 --> 01:08:57,500
Then test the model with the people who actually face that decision under pressure.

1498
01:08:57,500 --> 01:09:01,500
If it can't answer their questions in plain language, it's not ready for AI yet.

1499
01:09:01,500 --> 01:09:04,500
Choose a decision, not an AI demo.

1500
01:09:04,500 --> 01:09:06,500
Once you can describe the context,

1501
01:09:06,500 --> 01:09:08,500
fight the urge to build a broad AI demo.

1502
01:09:08,500 --> 01:09:10,500
Pick one decision that happens often,

1503
01:09:10,500 --> 01:09:15,500
creates real pressure and currently relies on too many phone calls, spreadsheets, and assumptions.

1504
01:09:15,500 --> 01:09:17,500
Machine outage impact is a good example.

1505
01:09:17,500 --> 01:09:21,500
Clear trigger, real time limit, consequences everyone already understands.

1506
01:09:21,500 --> 01:09:24,500
Picture a planner getting notice that a constrained machine has stopped.

1507
01:09:24,500 --> 01:09:28,500
They don't need a chatbot that explains the history of artificial intelligence.

1508
01:09:28,500 --> 01:09:30,500
So they need to know which orders are at risk,

1509
01:09:30,500 --> 01:09:31,500
which alternatives are still allowed,

1510
01:09:31,500 --> 01:09:34,500
and who has to approve a change before the shift loses more time.

1511
01:09:34,500 --> 01:09:36,500
That gives the project a clean boundary.

1512
01:09:36,500 --> 01:09:38,500
First define who owns the decision.

1513
01:09:38,500 --> 01:09:41,500
In some plans, the production planner owns the first re-plan.

1514
01:09:41,500 --> 01:09:46,500
In others, the shift supervisor decides whether to move work while central planning adjusts the formal schedule later.

1515
01:09:46,500 --> 01:09:50,500
Quality, maintenance, and engineering may each hold a veto on part of it.

1516
01:09:50,500 --> 01:09:52,500
Write that down before you build a thing.

1517
01:09:52,500 --> 01:09:53,500
Then define the decision window.

1518
01:09:53,500 --> 01:09:56,500
Is the team deciding within minutes because work is active?

1519
01:09:56,500 --> 01:09:58,500
Do they need an answer before the next shift?

1520
01:09:58,500 --> 01:10:01,500
Or does the disruption affect a plan for the next day?

1521
01:10:01,500 --> 01:10:05,500
The answer drives data freshness, integration design, and how much human review should be in the flow.

1522
01:10:05,500 --> 01:10:09,500
A system that refreshes every hour might work for one planning question and fall flat for another.

1523
01:10:09,500 --> 01:10:12,500
Next name the inputs the decision actually needs.

1524
01:10:12,500 --> 01:10:17,500
For an outage that could be current execution state from MS, repair status from maintenance,

1525
01:10:17,500 --> 01:10:22,500
routing and resource rules, material position, tool availability, and customer commitment data.

1526
01:10:22,500 --> 01:10:24,500
You don't need every signal available.

1527
01:10:24,500 --> 01:10:27,500
You need enough trusted facts to decide whether a proposed action is feasible.

1528
01:10:27,500 --> 01:10:29,500
That difference keeps the work grounded.

1529
01:10:29,500 --> 01:10:31,500
I'd also define the escalation path early.

1530
01:10:31,500 --> 01:10:34,500
Suppose the system finds no approved alternate resource.

1531
01:10:34,500 --> 01:10:37,500
Does it notify engineering to review a temporary route?

1532
01:10:37,500 --> 01:10:40,500
Does it send a planner an impact assessment that requires a manual decision?

1533
01:10:40,500 --> 01:10:44,500
Does customer service need a heads up because a delivery date might move?

1534
01:10:44,500 --> 01:10:47,500
An answer without a next action just becomes another report.

1535
01:10:47,500 --> 01:10:48,500
Keep the operational tests simple.

1536
01:10:48,500 --> 01:10:51,500
Can the team assess impact faster than they do today?

1537
01:10:51,500 --> 01:10:54,500
Does the system catch conditions people often miss during a rushed replay?

1538
01:10:54,500 --> 01:10:58,500
Can users trace the recommendation back to the facts and rules behind it?

1539
01:10:58,500 --> 01:11:01,500
Those are stronger tests than asking if the AI response sounds impressive.

1540
01:11:01,500 --> 01:11:03,500
This is where many projects go off track.

1541
01:11:03,500 --> 01:11:06,500
Someone builds a conversational assistant because it's easy to demo.

1542
01:11:06,500 --> 01:11:08,500
You type, "What should we do about machine 4?"

1543
01:11:08,500 --> 01:11:13,500
It responds in polished language and everyone nods because the interface looks familiar.

1544
01:11:13,500 --> 01:11:14,500
But what does it know?

1545
01:11:14,500 --> 01:11:18,500
If it can't name the active order, check the approved route, identify the tooling conflict,

1546
01:11:18,500 --> 01:11:22,500
and say where its information came from, then it's not supporting a production decision.

1547
01:11:22,500 --> 01:11:25,500
It's producing plausible text around a production problem.

1548
01:11:25,500 --> 01:11:28,500
The factory already has enough of that, usually in email threads.

1549
01:11:28,500 --> 01:11:31,500
A narrow decision use case forces better questions.

1550
01:11:31,500 --> 01:11:33,500
What counts as a successful outcome?

1551
01:11:33,500 --> 01:11:35,500
Which fact needs near real-time arrival?

1552
01:11:35,500 --> 01:11:37,500
Which facts can update less often?

1553
01:11:37,500 --> 01:11:39,500
When should the system stay quiet?

1554
01:11:39,500 --> 01:11:41,500
Because the disruption has no material effect?

1555
01:11:41,500 --> 01:11:43,500
What uncertainty should stop it from proposing an action?

1556
01:11:43,500 --> 01:11:46,500
Those questions expose the work needed in the semantic layer.

1557
01:11:46,500 --> 01:11:49,500
They also stop teams from treating AI as the first architectural choice.

1558
01:11:49,500 --> 01:11:53,500
You might eventually add a co-pilot, analytics, predictive models, workflow,

1559
01:11:53,500 --> 01:11:56,500
or scheduling software around that same decision.

1560
01:11:56,500 --> 01:11:57,500
Each has its place.

1561
01:11:57,500 --> 01:11:59,500
But the first goal stays grounded.

1562
01:11:59,500 --> 01:12:03,500
Help a named person make a defined production choice with fewer blind spots.

1563
01:12:03,500 --> 01:12:08,500
For the outage example, the first release might just state the affected orders, remaining quantity,

1564
01:12:08,500 --> 01:12:12,500
approved alternate resources and the conditions blocking each option.

1565
01:12:12,500 --> 01:12:14,500
That alone can eliminate a lot of manual searching.

1566
01:12:14,500 --> 01:12:17,500
Once people trust that view, you can ask a harder question.

1567
01:12:17,500 --> 01:12:22,500
If several options are possible, how do you test their likely effect before recommending one?

1568
01:12:22,500 --> 01:12:24,500
Simulation before optimization.

1569
01:12:24,500 --> 01:12:27,500
Before a system recommends a new production plan,

1570
01:12:27,500 --> 01:12:29,500
it needs to test what that plan might actually do.

1571
01:12:29,500 --> 01:12:31,500
And that's where simulation comes in.

1572
01:12:31,500 --> 01:12:35,500
A simulation takes a proposed action and plays it through a model of the factory.

1573
01:12:35,500 --> 01:12:37,500
Not as a promise, but as a structured question.

1574
01:12:37,500 --> 01:12:41,500
If we move this order, delay this operation, or use this alternate resource,

1575
01:12:41,500 --> 01:12:45,500
what effects are likely to follow under the conditions we know right now.

1576
01:12:45,500 --> 01:12:49,500
For the machine 4 outage, imagine the plan as sees two possible moves.

1577
01:12:49,500 --> 01:12:52,500
The first moves the affected order to machine 7 later today,

1578
01:12:52,500 --> 01:12:56,500
while the second holds the order until machine 4 returns and protects downstream work

1579
01:12:56,500 --> 01:12:58,500
of changing the inspection sequence.

1580
01:12:58,500 --> 01:13:01,500
Neither option should be judged by spare machine time alone.

1581
01:13:01,500 --> 01:13:05,500
The simulation needs to consider setup duration, the queue already waiting at machine 7,

1582
01:13:05,500 --> 01:13:10,500
expected repair time, material availability, and the capacity of the next operation.

1583
01:13:10,500 --> 01:13:15,500
It also needs to account for yield risk if the alternate machine has a different process history for that product.

1584
01:13:15,500 --> 01:13:17,500
That's a more honest way to plan.

1585
01:13:17,500 --> 01:13:23,500
A schedule often looks neat because it assumes every duration, arrival and output rate will behave exactly as planned.

1586
01:13:23,500 --> 01:13:25,500
But production doesn't work like that.

1587
01:13:25,500 --> 01:13:29,500
The estimates change, material deliveries, miss slots, batches fail inspection,

1588
01:13:29,500 --> 01:13:32,500
and tools reach their way limits earlier than expected.

1589
01:13:32,500 --> 01:13:35,500
Simulation gives those uncertainties a place in the decision.

1590
01:13:35,500 --> 01:13:37,500
You don't need to pretend you know the exact future.

1591
01:13:37,500 --> 01:13:39,500
Instead, you can test reasonable cases.

1592
01:13:39,500 --> 01:13:41,500
What if the repair takes another hour?

1593
01:13:41,500 --> 01:13:43,500
What if it takes most of the shift?

1594
01:13:43,500 --> 01:13:46,500
Or what if machine 7 produces at a lower rate during the first run?

1595
01:13:46,500 --> 01:13:49,500
Because the team needs extra setup time.

1596
01:13:49,500 --> 01:13:51,500
The result should show the effect of those assumptions.

1597
01:13:51,500 --> 01:13:55,500
Maybe moving the order to machine 7 protects one due date only if the repair runs long.

1598
01:13:55,500 --> 01:14:00,500
But if machine 4 returns quickly, the changeover on machine 7 creates more disruption than it avoids.

1599
01:14:00,500 --> 01:14:07,500
Or perhaps both options expose a downstream bottleneck, which means the planner needs to look beyond the failed machine before moving anything.

1600
01:14:07,500 --> 01:14:11,500
That's useful because it turns a rushed response into a comparison of consequences.

1601
01:14:11,500 --> 01:14:15,500
A good simulation also respects the rules already present in the model.

1602
01:14:15,500 --> 01:14:18,500
It doesn't test a schedule that requires an unavailable fixture and unapproved route,

1603
01:14:18,500 --> 01:14:21,500
or a person who isn't qualified for the process.

1604
01:14:21,500 --> 01:14:25,500
Because there's little value in comparing attractive plans that the factory cannot run.

1605
01:14:25,500 --> 01:14:30,500
So the simulation starts with feasible options, then explores how those options behave when uncertain conditions change.

1606
01:14:30,500 --> 01:14:33,500
Think of it as a rehearsal for a production decision.

1607
01:14:33,500 --> 01:14:35,500
You aren't trying to predict every detail of the next shift.

1608
01:14:35,500 --> 01:14:40,500
Instead, you're trying to see which decision remains sensible when normal variation enters the picture.

1609
01:14:40,500 --> 01:14:43,500
That distinction matters when people ask for an optimal plan.

1610
01:14:43,500 --> 01:14:47,500
A plan can look optimal only because it assumes a single repair duration,

1611
01:14:47,500 --> 01:14:50,500
a fixed output rate, and no delays anywhere else.

1612
01:14:50,500 --> 01:14:54,500
But in a live plant, those assumptions can be wrong before the planner finishes the meeting.

1613
01:14:54,500 --> 01:14:58,500
Simulation lets you see whether a choice holds up across more than one plausible condition.

1614
01:14:58,500 --> 01:15:01,500
It also makes trade-offs easier to discuss.

1615
01:15:01,500 --> 01:15:04,500
One option may protect a high priority order but increase overtime risk,

1616
01:15:04,500 --> 01:15:08,500
while another may reduce changeovers, but leave a lower priority order exposed.

1617
01:15:08,500 --> 01:15:14,500
And a third may keep the schedule stable, but depend on a repair estimate that maintenance cannot yet confirm.

1618
01:15:14,500 --> 01:15:21,500
There may not be one perfect answer, but rather a set of options, each with a clear cost, assumption, and likely effect.

1619
01:15:21,500 --> 01:15:24,500
That's where human judgment remains part of the process.

1620
01:15:24,500 --> 01:15:28,500
The planner knows things that may not yet sit in the model, for example.

1621
01:15:28,500 --> 01:15:37,500
A customer may accept a partial delivery, a supervisor may know a team can handle an unusual setup or maintenance may have more confidence in the repair than the status code suggests.

1622
01:15:37,500 --> 01:15:43,500
Those facts should enter the decision through a clear review step, not through silent workarounds after the system produces a plan.

1623
01:15:43,500 --> 01:15:45,500
Simulation also exposes missing context.

1624
01:15:45,500 --> 01:15:53,500
If the team can't estimate the impact of moving in order, because the model lacks setup time, queue state, or yield assumptions, that gap becomes visible.

1625
01:15:53,500 --> 01:15:58,500
Then you can decide whether collecting that fact will improve future decisions enough to justify the effort.

1626
01:15:58,500 --> 01:16:01,500
That's a better use of the model than pretending it already knows everything.

1627
01:16:01,500 --> 01:16:07,500
Once the team can simulate feasible alternatives and review their assumptions, optimization has a much clearer job.

1628
01:16:07,500 --> 01:16:12,500
It can search through the options the factory accepts rather than chasing an elegant schedule that only works in software.

1629
01:16:12,500 --> 01:16:16,500
Optimization has a different job than AI chat.

1630
01:16:16,500 --> 01:16:20,500
Once you've simulated feasible options, optimization can do the work it's designed for.

1631
01:16:20,500 --> 01:16:29,500
It searches through many possible schedules and resources assignments and finds choices that satisfy the rules you've given it while improving is stated business objective.

1632
01:16:29,500 --> 01:16:31,500
That last part needs to stay explicit.

1633
01:16:31,500 --> 01:16:35,500
An optimizer can't decide what your plan should care about unless you tell it.

1634
01:16:35,500 --> 01:16:43,500
For the machine for outage, you might ask it to reduce late order risk while keeping change over slow and staying within normal shift coverage.

1635
01:16:43,500 --> 01:16:48,500
Or you may decide that one customer order must ship first even if that pushes another order back.

1636
01:16:48,500 --> 01:16:52,500
Those are different objectives and they can produce different schedules from the same set of facts.

1637
01:16:52,500 --> 01:16:56,500
There isn't a neutral production plan. Every plan favors something.

1638
01:16:56,500 --> 01:17:04,500
It may favor due date performance, throughput, lower overtime, fewer setups, lower energy use, stable campaigns, or reduced work in progress.

1639
01:17:04,500 --> 01:17:10,500
Sometimes those aims work together, but often they conflict, especially when capacity has already tightened.

1640
01:17:10,500 --> 01:17:15,500
So the optimizer needs both constraints and objectives. Constraints define what the plan can and cannot do.

1641
01:17:15,500 --> 01:17:21,500
The model removes options that fail qualification, material, tooling, safety, maintenance, or root rules.

1642
01:17:21,500 --> 01:17:27,500
Objectives rank the remaining options and tell the optimizer how to judge a feasible plan against another feasible plan.

1643
01:17:27,500 --> 01:17:29,500
That distinction keeps the conversation honest.

1644
01:17:29,500 --> 01:17:41,500
If a schedule moves a late order ahead of several others, the planer should know whether the system followed a declared customer priority rule, avoided a contract risk, or simply applied a weight that someone entered months ago, and nobody remembers.

1645
01:17:41,500 --> 01:17:46,500
A schedule may be mathematically consistent but still deserve a challenge. Make the trade-offs visible.

1646
01:17:46,500 --> 01:17:52,500
Suppose the optimizer finds a plan that protects the urgent order by adding an extra change over on machine 7 and shifting work into overtime.

1647
01:17:52,500 --> 01:18:01,500
That may be the right decision, but it should present the decision as a choice with a cost, not as a mysterious answer stamped optimal. Production people need to see the price of the plan.

1648
01:18:01,500 --> 01:18:12,500
This also explains why a generative AI and optimization belong in different parts of the decision flow. A large language model can understand a planer's question in normal language, retrieve approved facts.

1649
01:18:12,500 --> 01:18:17,500
Explain why a route failed, compare scenario notes, and help prepare an escalation message.

1650
01:18:17,500 --> 01:18:23,500
That's useful work, but a language model should not act as the scheduling engine just because it can write a convincing paragraph about a schedule.

1651
01:18:23,500 --> 01:18:30,500
It doesn't naturally enforce every hard constraint in a production model, and fluent language can hide an infeasible answer surprisingly well.

1652
01:18:30,500 --> 01:18:36,500
The factory doesn't benefit from a beautifully phrased plan that assigns a non-existent fixture to two machines.

1653
01:18:36,500 --> 01:18:43,500
Optimization engines work differently. They search a defined problem space using rules, available capacity, time windows, and objective functions.

1654
01:18:43,500 --> 01:18:50,500
Depending on the planning problem that may involve scheduling methods, constraint programming, mixed integer optimization, or specialist manufacturing planning software.

1655
01:18:50,500 --> 01:18:58,500
The exact method matters to the engineering team, but the operational point stays simple. The engine tests options against the rules before it recommends them.

1656
01:18:58,500 --> 01:19:09,500
Use deterministic checks around the result too. Before a proposed plan reaches a planner, verify that it still respects the current root approval, resource status, material condition, and time sensitive restrictions.

1657
01:19:09,500 --> 01:19:20,500
Live production changes. A plan created 15 minutes ago may already rely on a tool that has moved, a machine that has stopped, or an order priority that customer service has changed.

1658
01:19:20,500 --> 01:19:28,500
The result needs a freshness check. Generative AI can sit beside that process and make the result easier to use. A planner might ask why the system can't work order 8.1.0.

1659
01:19:28,500 --> 01:19:33,620
811mts on machine 4 rather than moving it, what effectary co-pilot should know before it speaks.

1660
01:19:33,620 --> 01:19:39,940
So your optimizer found some feasible options, that's step 1. Now the co-pilot's job is to make

1661
01:19:39,940 --> 01:19:44,820
those options usable. But here's the thing, before it answers a single planner question it needs more

1662
01:19:44,820 --> 01:19:49,380
then a folder of reports and a handful of tables. It needs context that's grounded in reality.

1663
01:19:49,380 --> 01:19:53,300
That means it has to know where each answer came from, when that source last updated,

1664
01:19:53,300 --> 01:19:56,900
what assumptions are baked into the result and what gaps are still hanging open.

1665
01:19:56,900 --> 01:20:01,220
Let's say a planner asks which orders are affected by the machine for outage.

1666
01:20:01,220 --> 01:20:05,380
A useful answer lists the current outage status, the work orders tied to that machine,

1667
01:20:05,380 --> 01:20:09,380
the remaining steps, and the due dates that fall within the repair window.

1668
01:20:09,380 --> 01:20:13,380
It also tells you when the maintenance estimate was last updated.

1669
01:20:13,380 --> 01:20:16,660
If the repair time is still uncertain, the co-pilot should say that clearly,

1670
01:20:16,660 --> 01:20:20,340
rather than turning an estimate into a fact that shifts the whole tone.

1671
01:20:20,340 --> 01:20:23,700
Instead of saying these orders will be late, it says something like,

1672
01:20:23,700 --> 01:20:28,500
based on the current repair estimate and the approved schedule, these orders face due date risk.

1673
01:20:28,500 --> 01:20:33,060
That estimate came from the active maintenance record and hasn't been confirmed by the technician yet.

1674
01:20:33,060 --> 01:20:35,860
Now the planner has something they can actually evaluate.

1675
01:20:35,860 --> 01:20:38,340
Source links matter because production questions cross teams.

1676
01:20:38,340 --> 01:20:41,460
If a planner asks why an order can't move to another machine,

1677
01:20:41,460 --> 01:20:43,860
the co-pilot needs to trace the full chain.

1678
01:20:43,860 --> 01:20:47,300
The approved route, resource capability, tool assignments,

1679
01:20:47,300 --> 01:20:49,140
quality status, staffing.

1680
01:20:49,140 --> 01:20:53,540
It can't just say machine 7 is unavailable, that one phrase can hide very different problems.

1681
01:20:53,940 --> 01:20:57,540
Maybe machine 7 is down or it's already running another order that can't move,

1682
01:20:57,540 --> 01:20:59,860
or the fixture you need is tied up elsewhere,

1683
01:20:59,860 --> 01:21:03,780
or quality hasn't signed off on that route for the current product revision.

1684
01:21:03,780 --> 01:21:06,660
Those are different problems with different people who can fix them.

1685
01:21:06,660 --> 01:21:09,380
A good conversational answer keeps those distinctions clear.

1686
01:21:09,380 --> 01:21:11,220
Permissions deserve the same attention.

1687
01:21:11,220 --> 01:21:14,340
A production supervisor needs machine status and work order info,

1688
01:21:14,340 --> 01:21:16,260
not customer account details.

1689
01:21:16,260 --> 01:21:19,060
A maintenance tech needs asset condition and repair history,

1690
01:21:19,060 --> 01:21:20,820
not every planning priority rule.

1691
01:21:20,820 --> 01:21:23,380
The co-pilot has to respect those boundaries,

1692
01:21:23,380 --> 01:21:26,420
while still giving a useful answer based on the user's role.

1693
01:21:26,420 --> 01:21:29,700
That means the co-pilot can't treat factory data as one open pool.

1694
01:21:29,700 --> 01:21:32,260
It needs identity aware access across production,

1695
01:21:32,260 --> 01:21:34,900
maintenance, quality planning and commercial data.

1696
01:21:34,900 --> 01:21:36,500
When someone doesn't have access to a record,

1697
01:21:36,500 --> 01:21:38,020
the system should be honest about it,

1698
01:21:38,020 --> 01:21:39,700
say a restriction affects the recommendation

1699
01:21:39,700 --> 01:21:41,780
without showing details they shouldn't see.

1700
01:21:41,780 --> 01:21:43,860
And there's a practical reason beyond security.

1701
01:21:43,860 --> 01:21:47,300
People trust systems more when they understand what the system knows,

1702
01:21:47,300 --> 01:21:50,100
what it can't access, and where that answer came from.

1703
01:21:50,340 --> 01:21:53,300
A good factory co-pilot should help people ask better questions,

1704
01:21:53,300 --> 01:21:55,780
not the vague kind like, "How do we fix production?"

1705
01:21:55,780 --> 01:21:58,020
But questions that point to a real decision,

1706
01:21:58,020 --> 01:22:00,340
questions like which released orders face risk,

1707
01:22:00,340 --> 01:22:02,020
if the repair runs to the end of shift,

1708
01:22:02,020 --> 01:22:05,540
which alternate resources meet the approved root and current tool setup,

1709
01:22:05,540 --> 01:22:07,780
what's blocking each rejected alternative,

1710
01:22:07,780 --> 01:22:10,740
and which team needs to review the first feasible option.

1711
01:22:10,740 --> 01:22:13,780
Those all connect to specific source facts and define checks.

1712
01:22:13,780 --> 01:22:15,380
The co-pilot can pull those up,

1713
01:22:15,380 --> 01:22:18,020
compare them and explain the results in language

1714
01:22:18,020 --> 01:22:19,780
that matches the work people already do.

1715
01:22:19,780 --> 01:22:21,780
The co-pilot can also suggest a workflow,

1716
01:22:21,780 --> 01:22:23,700
maybe it prepares an impact note for the planner,

1717
01:22:23,700 --> 01:22:26,260
sends a review request to quality for a root exception,

1718
01:22:26,260 --> 01:22:28,100
or drafts a message to customer service

1719
01:22:28,100 --> 01:22:29,540
when a commitment is at risk.

1720
01:22:29,540 --> 01:22:31,940
But the human still decides whether to move forward.

1721
01:22:31,940 --> 01:22:32,980
That line matters.

1722
01:22:32,980 --> 01:22:34,820
The co-pilot should never invent a new root,

1723
01:22:34,820 --> 01:22:35,940
override a quality hold,

1724
01:22:35,940 --> 01:22:38,660
or issue a production instruction based on a vague question.

1725
01:22:38,660 --> 01:22:40,900
Its job is to help people get to the right analysis

1726
01:22:40,900 --> 01:22:43,220
and approval path with less manual digging.

1727
01:22:43,220 --> 01:22:45,540
Sometimes the most useful answer it can give is,

1728
01:22:45,540 --> 01:22:48,660
"I can't recommend a move yet because the repair estimate is unconfirmed

1729
01:22:48,660 --> 01:22:51,220
and the only alternate root needs engineering approval."

1730
01:22:51,220 --> 01:22:54,260
And that sounds less impressive than a confident paragraph.

1731
01:22:54,260 --> 01:22:56,660
But on a real shop floor, it's far more valuable.

1732
01:22:56,660 --> 01:22:58,820
Explainability, accountability and safety.

1733
01:22:58,820 --> 01:23:03,620
A recommendation earns trust only when people can inspect the path that produced it.

1734
01:23:03,620 --> 01:23:07,620
Say the system suggests moving work order 8-1-10 to machine 7.

1735
01:23:07,620 --> 01:23:09,140
The planner shouldn't just get a green check

1736
01:23:09,140 --> 01:23:10,740
and a sentence saying it's recommended,

1737
01:23:10,740 --> 01:23:12,340
they need the facts behind it,

1738
01:23:12,340 --> 01:23:13,620
the current outer record,

1739
01:23:13,620 --> 01:23:14,740
the remaining quantity,

1740
01:23:14,740 --> 01:23:15,780
the approved root,

1741
01:23:15,780 --> 01:23:17,780
tool status, shift time available,

1742
01:23:17,780 --> 01:23:20,660
and the delivery impact under the assumptions used.

1743
01:23:20,660 --> 01:23:22,820
That explanation needs to stay specific.

1744
01:23:22,820 --> 01:23:24,740
It should also show the constraint checks,

1745
01:23:24,740 --> 01:23:26,820
did the move pass the product revision rule,

1746
01:23:26,820 --> 01:23:29,140
is the fixture available for the full window

1747
01:23:29,140 --> 01:23:31,380
has quality released that process path

1748
01:23:31,380 --> 01:23:33,380
and does the plan conflict with another order

1749
01:23:33,380 --> 01:23:35,300
already committed to that machine?

1750
01:23:35,300 --> 01:23:37,940
If a condition fails, the system should say exactly why.

1751
01:23:37,940 --> 01:23:41,540
Machine 7 can't run this order because fixture F12 is assigned

1752
01:23:41,540 --> 01:23:43,860
to another approved operation until 6 o'clock PM.

1753
01:23:43,860 --> 01:23:47,140
That gives the planner a real reason,

1754
01:23:47,140 --> 01:23:50,340
a place to verify and a person or team who might be able to help.

1755
01:23:50,340 --> 01:23:52,660
Saying alternative unavailable tells them nothing,

1756
01:23:52,660 --> 01:23:54,900
trade-offs need to be part of the explanation too.

1757
01:23:54,900 --> 01:23:57,940
Maybe the move saves the customer date but requires overtime,

1758
01:23:57,940 --> 01:23:59,460
or it avoids overtime,

1759
01:23:59,460 --> 01:24:02,980
but risks the late shipment if the repair takes longer than expected,

1760
01:24:02,980 --> 01:24:04,740
or it keeps the current schedule stable

1761
01:24:04,740 --> 01:24:07,220
but pushes a lower priority order into the next shift.

1762
01:24:07,220 --> 01:24:08,740
People can make those calls,

1763
01:24:08,740 --> 01:24:10,580
but they need to see the cost of each option.

1764
01:24:10,580 --> 01:24:12,340
This is where accountability gets real.

1765
01:24:12,340 --> 01:24:14,420
An optimizer generates feasible choices,

1766
01:24:14,420 --> 01:24:17,060
a copilot explains them, but neither one owns the decision.

1767
01:24:17,060 --> 01:24:21,060
A planner, supervisor, engineer, or whoever the plans rules designate

1768
01:24:21,060 --> 01:24:22,420
needs to approve the action.

1769
01:24:22,420 --> 01:24:24,180
That doesn't make the system less valuable,

1770
01:24:24,180 --> 01:24:25,620
it gives it the right job.

1771
01:24:25,620 --> 01:24:27,620
Some decisions take seconds because the risk is low

1772
01:24:27,620 --> 01:24:28,660
and the rules are clear.

1773
01:24:28,660 --> 01:24:31,780
Others need quality, maintenance, or engineering sign-off,

1774
01:24:31,780 --> 01:24:33,460
because a root exception, product risk,

1775
01:24:33,460 --> 01:24:36,100
or customer commitment is outside the planner's authority.

1776
01:24:36,100 --> 01:24:38,340
The decision path should match the level of risk.

1777
01:24:38,340 --> 01:24:40,420
A solid design records that whole path.

1778
01:24:40,420 --> 01:24:42,980
The source facts at the time, the options considered,

1779
01:24:42,980 --> 01:24:45,060
the constraints checked, who approved it,

1780
01:24:45,060 --> 01:24:47,060
and any edits they made before releasing.

1781
01:24:47,060 --> 01:24:50,100
If the planner rejects the recommendation, that matters too.

1782
01:24:50,100 --> 01:24:51,860
It might show the model Mr. Condition,

1783
01:24:51,860 --> 01:24:54,580
or it might show a human applied a business judgment

1784
01:24:54,580 --> 01:24:56,020
the model hadn't learned yet.

1785
01:24:56,020 --> 01:24:58,580
Without that record, teams can't learn from the outcome.

1786
01:24:58,580 --> 01:25:00,340
Now, there's a separate boundary around safety

1787
01:25:00,340 --> 01:25:02,020
and it needs to be crystal clear.

1788
01:25:02,020 --> 01:25:04,420
Conversational AI, cloud analytics,

1789
01:25:04,420 --> 01:25:06,580
and planning tools should stay outside safety

1790
01:25:06,580 --> 01:25:07,940
and direct control paths.

1791
01:25:07,940 --> 01:25:09,860
They can inform people, raise an exception,

1792
01:25:09,860 --> 01:25:11,460
or prepare a proposed plan.

1793
01:25:11,460 --> 01:25:13,940
But they should never bypass safety systems,

1794
01:25:13,940 --> 01:25:16,420
right directly to a PLC, or change an interlock

1795
01:25:16,420 --> 01:25:18,420
because someone asked confidently enough.

1796
01:25:18,420 --> 01:25:20,260
The physical process has consequences.

1797
01:25:20,260 --> 01:25:22,660
A production instruction can affect equipment condition,

1798
01:25:22,660 --> 01:25:25,460
product quality, worker safety, or regulatory compliance.

1799
01:25:25,460 --> 01:25:27,300
That's why control systems, safety functions,

1800
01:25:27,300 --> 01:25:29,860
and local procedures keep their own authority.

1801
01:25:29,860 --> 01:25:32,420
The AI layer supports the people who run those systems.

1802
01:25:32,420 --> 01:25:33,620
It doesn't replace them.

1803
01:25:33,620 --> 01:25:35,540
Take a quality hold during a disruption.

1804
01:25:35,540 --> 01:25:38,660
The model might find that rerouting protects a due date,

1805
01:25:38,660 --> 01:25:40,180
but if that hold is still active,

1806
01:25:40,180 --> 01:25:42,420
the system has to treat it as a stop condition,

1807
01:25:42,420 --> 01:25:44,980
not an inconvenient detail to explain away.

1808
01:25:44,980 --> 01:25:46,340
The recommendation can say,

1809
01:25:46,340 --> 01:25:49,460
"This option needs quality release before production continues."

1810
01:25:49,460 --> 01:25:52,020
It can't decide the release doesn't matter anymore.

1811
01:25:52,020 --> 01:25:53,860
That restraint is part of good engineering.

1812
01:25:53,860 --> 01:25:57,540
Explainability also means talking about uncertainty.

1813
01:25:57,540 --> 01:25:59,620
If maintenance hasn't confirmed the repair time,

1814
01:25:59,620 --> 01:26:02,660
the system should say which scenarios depend on that estimate.

1815
01:26:02,660 --> 01:26:05,380
If the material status came in late from another system,

1816
01:26:05,380 --> 01:26:07,140
it should show how fresh that data is.

1817
01:26:07,140 --> 01:26:09,620
A recommendation with unknowns can still be useful,

1818
01:26:09,620 --> 01:26:12,900
but it needs to bring those unknowns into the approval conversation.

1819
01:26:12,900 --> 01:26:15,940
False certainty causes more trouble than an honest heads-up.

1820
01:26:15,940 --> 01:26:18,500
Over time, that builds a better working relationship

1821
01:26:18,500 --> 01:26:20,660
between people and decision tools.

1822
01:26:20,660 --> 01:26:22,660
Planners don't have to accept a black box answer

1823
01:26:22,660 --> 01:26:24,660
because the system shows its reasoning.

1824
01:26:24,660 --> 01:26:26,180
Engineers can fix a missing rule,

1825
01:26:26,180 --> 01:26:28,020
quality can challenge an assumption,

1826
01:26:28,020 --> 01:26:30,020
maintenance can update a repair condition,

1827
01:26:30,020 --> 01:26:31,860
and every approved or rejected decision

1828
01:26:31,860 --> 01:26:33,460
leaves a trail for the next one.

1829
01:26:33,460 --> 01:26:35,220
Governance for a living factory model.

1830
01:26:35,220 --> 01:26:38,340
A factory model doesn't stay useful

1831
01:26:38,340 --> 01:26:41,060
because some project team built it carefully once.

1832
01:26:41,060 --> 01:26:43,300
It stays useful because people treat its definitions,

1833
01:26:43,300 --> 01:26:46,340
relationships and rules like part of normal operational work,

1834
01:26:46,340 --> 01:26:48,260
so someone needs to own each piece of it.

1835
01:26:48,260 --> 01:26:50,740
But that ownership can't sit only with IT.

1836
01:26:50,740 --> 01:26:52,820
It can manage platforms and integration,

1837
01:26:52,820 --> 01:26:55,780
but it can't decide whether a resource stays approved

1838
01:26:55,780 --> 01:26:57,780
for a process after an engineering change.

1839
01:26:57,780 --> 01:26:59,860
And it can't sit only with engineering either,