Why Continuous Improvement Needs Better Data

1
00:00:00,000 --> 00:00:03,440
A kaiser-nevent can feel like real progress when you pull people off the line,

2
00:00:03,440 --> 00:00:06,560
gather them around a flipchart, mark problems on a process map,

3
00:00:06,560 --> 00:00:08,880
and build an action list before the day ends.

4
00:00:08,880 --> 00:00:11,680
But a few weeks later, the same loss shows up on another shift.

5
00:00:11,680 --> 00:00:14,960
Maybe the team reduced the change of a delay, clear the material rack,

6
00:00:14,960 --> 00:00:16,880
change the handoff, or added a checklist.

7
00:00:16,880 --> 00:00:18,800
The local fix looked sensible at the time,

8
00:00:18,800 --> 00:00:20,880
but could it hold up under a different product mix,

9
00:00:20,880 --> 00:00:23,200
a different crew, or different production sequence?

10
00:00:23,200 --> 00:00:26,560
Nobody could tell, that's where continuous improvement work loses momentum.

11
00:00:26,560 --> 00:00:29,040
Not because people don't care, they usually care a great deal,

12
00:00:29,040 --> 00:00:31,920
but because the workshop drifts away from daily production facts.

13
00:00:31,920 --> 00:00:33,760
The evidence lives in separate systems.

14
00:00:33,760 --> 00:00:37,280
Your MES records what that order did, your ERP holds the plan,

15
00:00:37,280 --> 00:00:41,760
and customer commitment, machine signals log stops, speed, alarms, and cycles,

16
00:00:41,760 --> 00:00:44,560
and operators know what actually shifted during the shift,

17
00:00:44,560 --> 00:00:46,720
often before any system picks it up.

18
00:00:46,720 --> 00:00:48,480
When those sources stay disconnected,

19
00:00:48,480 --> 00:00:52,560
the kaiser-nevent becomes a one-time burst of attention instead of a learning loop.

20
00:00:52,560 --> 00:00:54,800
So let's walk through a recurring production problem,

21
00:00:54,800 --> 00:00:57,520
because this is where the gap becomes easy to see.

22
00:00:57,520 --> 00:00:59,840
A familiar factory problem.

23
00:00:59,840 --> 00:01:02,800
Picture a production line that keeps missing planned output.

24
00:01:02,800 --> 00:01:06,640
Nothing dramatic happens, no single machine crash stops the plan for a day.

25
00:01:06,640 --> 00:01:09,040
Instead, the line slips a little during changeovers,

26
00:01:09,040 --> 00:01:11,520
waits for material, then loses time after restart,

27
00:01:11,520 --> 00:01:14,320
because the first units need adjustment or inspection.

28
00:01:14,320 --> 00:01:17,520
Late order start to build, change over time seems to rise,

29
00:01:17,520 --> 00:01:20,400
and output looks unstable from one shift to the next.

30
00:01:20,400 --> 00:01:22,800
At the daily meeting, someone brings yesterday's spreadsheet.

31
00:01:22,800 --> 00:01:27,040
It shows total output, scrap, downtime, and maybe an OEE number.

32
00:01:27,040 --> 00:01:28,800
Overall equipment effectiveness.

33
00:01:28,800 --> 00:01:31,440
The supervisor adds what they remember from the shift,

34
00:01:31,440 --> 00:01:34,080
maintenance adds a note about a recurring sensor alarm,

35
00:01:34,080 --> 00:01:38,400
and the planner points out that a priority order moved into the schedule late in the day.

36
00:01:38,400 --> 00:01:39,680
Everyone sees part of the problem,

37
00:01:39,680 --> 00:01:42,000
but nobody sees the whole production story.

38
00:01:42,000 --> 00:01:44,640
The operators often know more than the report captures.

39
00:01:44,640 --> 00:01:46,880
A certain toolset arrives late from cleaning.

40
00:01:46,880 --> 00:01:49,920
One product family takes longer to stabilize after a changeover,

41
00:01:49,920 --> 00:01:52,800
and a material role from one supplier behaves differently

42
00:01:52,800 --> 00:01:55,040
even when the material code looks the same.

43
00:01:55,040 --> 00:01:58,240
That knowledge matters, yet it often lives in shift handovers,

44
00:01:58,240 --> 00:02:00,880
informal notes, and conversations near the line.

45
00:02:00,880 --> 00:02:04,640
Now imagine an improvement team picks change over time as the problem.

46
00:02:04,640 --> 00:02:06,000
That choice sounds reasonable.

47
00:02:06,000 --> 00:02:08,240
The spreadsheet shows a rise in lost time,

48
00:02:08,240 --> 00:02:10,960
and the team can see people walking farther than they should

49
00:02:10,960 --> 00:02:12,640
to find tools and parts.

50
00:02:12,640 --> 00:02:15,440
They run a kaisen session, stage tools closer to the line,

51
00:02:15,440 --> 00:02:18,160
label locations, and add a simple setup checklist.

52
00:02:18,160 --> 00:02:21,120
The next few changes look better, so the team closes the action.

53
00:02:21,120 --> 00:02:23,440
But production doesn't run under laboratory conditions.

54
00:02:23,440 --> 00:02:26,960
A week later, a different crew runs a different sequence of products.

55
00:02:26,960 --> 00:02:29,920
The new tool staging helps, but the line still loses time

56
00:02:29,920 --> 00:02:32,880
because the prior order leaves adhesive residue in a component,

57
00:02:32,880 --> 00:02:35,600
the first few units after restart fail inspection,

58
00:02:35,600 --> 00:02:37,840
and operators slow the machine to adjust settings.

59
00:02:37,840 --> 00:02:40,800
The average changeover time may even improve,

60
00:02:40,800 --> 00:02:42,640
but delivery performance does not.

61
00:02:42,640 --> 00:02:44,880
That's because the team improved one visible step

62
00:02:44,880 --> 00:02:47,280
without checking the operating context around it.

63
00:02:47,280 --> 00:02:50,480
The loss moved downstream from setup time into restart time,

64
00:02:50,480 --> 00:02:53,360
quality checks, and waiting for a disposition decision.

65
00:02:53,360 --> 00:02:56,320
Improvement work tends to target where the paint shows up,

66
00:02:56,320 --> 00:02:59,040
but the real constraint is usually somewhere else in the flow.

67
00:02:59,040 --> 00:03:02,880
You need to ask, which product ran before the difficult changeover?

68
00:03:02,880 --> 00:03:04,160
Which product came next?

69
00:03:04,160 --> 00:03:06,880
Did the same material batch appear in the slow restart?

70
00:03:06,880 --> 00:03:08,400
Did the delay happen on every shift?

71
00:03:08,400 --> 00:03:10,880
Or mainly when a certain crew ran the line?

72
00:03:10,880 --> 00:03:14,240
Did the machine alarm occur before the quality issue or after it?

73
00:03:14,240 --> 00:03:16,720
A spreadsheet with one number per day can't answer that,

74
00:03:16,720 --> 00:03:20,080
and a workshop memory can't answer it reliably across weeks and shifts either.

75
00:03:20,080 --> 00:03:21,440
People remember the bad event,

76
00:03:21,440 --> 00:03:24,960
but they rarely remember every normal event that gives the bad event its meaning.

77
00:03:24,960 --> 00:03:26,720
This doesn't mean the daily meeting is useless.

78
00:03:26,720 --> 00:03:28,480
Quite the opposite.

79
00:03:28,480 --> 00:03:30,880
A short meeting near the work can catch problems early,

80
00:03:30,880 --> 00:03:34,240
and operator experience often points toward the right place to investigate,

81
00:03:34,240 --> 00:03:37,280
but experience needs a way to connect with production evidence.

82
00:03:37,280 --> 00:03:39,280
The team needs to trace an event through the order,

83
00:03:39,280 --> 00:03:41,120
the process step, the machine state,

84
00:03:41,120 --> 00:03:43,360
the material, the quality result, and the shift.

85
00:03:43,360 --> 00:03:45,840
Otherwise, every discussion starts with a partial view

86
00:03:45,840 --> 00:03:48,880
and ends with an action that only works under one set of conditions.

87
00:03:48,880 --> 00:03:51,440
There's also a planning effect teams often miss.

88
00:03:51,440 --> 00:03:52,640
When changeovers run long,

89
00:03:52,640 --> 00:03:55,280
the planner may re-sequence orders creating more material moves,

90
00:03:55,280 --> 00:03:58,160
more cleaning work, or more complex product transitions later in the day.

91
00:03:58,160 --> 00:04:00,320
A local loss starts changing the plan,

92
00:04:00,320 --> 00:04:02,560
and the changed plan creates new local losses.

93
00:04:02,560 --> 00:04:04,800
Soon enough, people argue about whether production,

94
00:04:04,800 --> 00:04:07,840
planning, maintenance, or quality cause the problem.

95
00:04:07,840 --> 00:04:09,680
Usually each group has evidence,

96
00:04:09,680 --> 00:04:12,480
but it's evidence from a different system in a different time boundary.

97
00:04:12,480 --> 00:04:14,800
This is why activity and learning aren't the same thing.

98
00:04:14,800 --> 00:04:17,280
You can hold workshops, fill action trackers,

99
00:04:17,280 --> 00:04:19,680
and close tasks while learning very little

100
00:04:19,680 --> 00:04:22,000
about why the line behaves the way it does.

101
00:04:22,000 --> 00:04:25,280
Real learning means a team can test a change against operating facts,

102
00:04:25,280 --> 00:04:27,760
see whether it holds, and understand when it doesn't.

103
00:04:27,760 --> 00:04:30,160
Lean is a learning system.

104
00:04:30,160 --> 00:04:34,560
I watch Lean get reduced to a collection of tools all the time.

105
00:04:34,560 --> 00:04:36,880
A 5S event, a value stream map,

106
00:04:36,880 --> 00:04:39,200
a kyson board, a visual status meeting,

107
00:04:39,200 --> 00:04:41,280
those are useful, but they don't define the system.

108
00:04:41,280 --> 00:04:43,040
Those tools help, sure,

109
00:04:43,040 --> 00:04:45,040
but Lean itself is really a way of learning

110
00:04:45,040 --> 00:04:47,680
how work moves through a system where work waits,

111
00:04:47,680 --> 00:04:49,360
where defects sneak in,

112
00:04:49,360 --> 00:04:52,400
and where one local decision ripples trouble somewhere downstream.

113
00:04:52,400 --> 00:04:55,120
That learning has to stay close to the work.

114
00:04:55,120 --> 00:04:57,920
Otherwise, the team starts improving the process they imagine

115
00:04:57,920 --> 00:05:00,480
instead of the process people actually run during a busy shift

116
00:05:00,480 --> 00:05:04,000
with late material, altered schedules, worn tools,

117
00:05:04,000 --> 00:05:07,680
and all the small exceptions that never fit neatly into a standard work document.

118
00:05:07,680 --> 00:05:10,800
Here's the thing about value stream mapping.

119
00:05:10,800 --> 00:05:13,120
Most teams treat it like a wall exercise.

120
00:05:13,120 --> 00:05:15,200
You draw it once, snap a photo,

121
00:05:15,200 --> 00:05:17,760
and don't touch it until the next improvement project comes around.

122
00:05:17,760 --> 00:05:21,520
But a value stream map should act as a shared view of flow,

123
00:05:21,520 --> 00:05:23,920
giving production, quality, maintenance,

124
00:05:23,920 --> 00:05:28,320
planning, and logistics a common way to talk about the path from demand to delivery.

125
00:05:28,320 --> 00:05:29,520
Where does material wait?

126
00:05:29,520 --> 00:05:31,200
When does information arrive too late?

127
00:05:31,200 --> 00:05:32,560
Which handoff causes rework?

128
00:05:32,560 --> 00:05:35,760
Where does the flow stop even though no one machine appears broken?

129
00:05:35,760 --> 00:05:38,800
That map doesn't need to capture every sensor tag or system field.

130
00:05:38,800 --> 00:05:41,040
It just needs to make the work visible enough

131
00:05:41,040 --> 00:05:43,600
so people can start asking better questions.

132
00:05:43,600 --> 00:05:46,560
A useful map can show that a long lead time isn't from cycle time,

133
00:05:46,560 --> 00:05:48,480
it's from a queue before inspection,

134
00:05:48,480 --> 00:05:49,840
a release rule in planning,

135
00:05:49,840 --> 00:05:52,720
or a quality hold that the production team only hears about

136
00:05:52,720 --> 00:05:55,040
after the next operation needs the batch.

137
00:05:55,040 --> 00:05:58,560
That shifts the conversation from which department owns this delay

138
00:05:58,560 --> 00:06:01,040
to what condition creates this weight

139
00:06:01,040 --> 00:06:03,680
and what information would let us prevent it.

140
00:06:03,680 --> 00:06:05,360
Kaisen fits right into that.

141
00:06:05,360 --> 00:06:07,520
Small practical improvement close to the work

142
00:06:07,520 --> 00:06:10,880
where the people running the process can test an idea and learn from the result.

143
00:06:11,040 --> 00:06:12,880
You don't need a big program office for this,

144
00:06:12,880 --> 00:06:14,400
but you do need discipline.

145
00:06:14,400 --> 00:06:18,160
A team sees a condition, forms a hypothesis about why it happens,

146
00:06:18,160 --> 00:06:20,640
changes something within a safe and a greed boundary,

147
00:06:20,640 --> 00:06:23,600
and then checks the result against the condition they expected to improve.

148
00:06:23,600 --> 00:06:25,760
That's the PDCA cycle.

149
00:06:25,760 --> 00:06:27,120
Plan, do, check, act.

150
00:06:27,120 --> 00:06:28,960
Plan means more than picking a target.

151
00:06:28,960 --> 00:06:31,200
The team defines the problem, the current condition,

152
00:06:31,200 --> 00:06:32,960
and the expected effect of a change.

153
00:06:32,960 --> 00:06:35,680
Say a line loses time after certain product transitions.

154
00:06:35,680 --> 00:06:38,560
The plan might state that pre-staging a specific cleaning kit

155
00:06:38,560 --> 00:06:41,280
should reduce the delay before stable production resumes.

156
00:06:41,280 --> 00:06:43,360
Do means trying that change in real work,

157
00:06:43,360 --> 00:06:45,280
not in a conference room or a slide deck,

158
00:06:45,280 --> 00:06:47,200
but on the line with the known product sequence

159
00:06:47,200 --> 00:06:49,520
under conditions the team records well enough to learn from.

160
00:06:49,520 --> 00:06:52,560
Check is where many improvement efforts go weak.

161
00:06:52,560 --> 00:06:54,720
The team needs to compare the expected result

162
00:06:54,720 --> 00:06:55,840
with what actually happened,

163
00:06:55,840 --> 00:06:58,320
including effects that might show up later in the process.

164
00:06:58,320 --> 00:06:59,440
Did the restart improve?

165
00:06:59,440 --> 00:07:00,560
Did quality hold?

166
00:07:00,560 --> 00:07:02,400
Did the new method add work somewhere else?

167
00:07:02,400 --> 00:07:03,520
Did it work for the next crew?

168
00:07:03,520 --> 00:07:04,880
Not just the one that designed it?

169
00:07:04,880 --> 00:07:05,760
Then comes act.

170
00:07:05,760 --> 00:07:07,440
If the evidence supports the change,

171
00:07:07,440 --> 00:07:09,200
the team builds it into standard work,

172
00:07:09,200 --> 00:07:11,280
training, planning rules, or maintenance routines.

173
00:07:11,280 --> 00:07:13,440
If not, they adapt or stop it.

174
00:07:13,440 --> 00:07:15,520
Stopping a weak countermeasure isn't failure.

175
00:07:15,520 --> 00:07:17,760
It's preventing a weak habit from becoming standard.

176
00:07:17,760 --> 00:07:20,240
PDCA gives lean its memory.

177
00:07:20,240 --> 00:07:21,360
Without that loop,

178
00:07:21,360 --> 00:07:23,920
improvement work becomes a set of good intentions

179
00:07:23,920 --> 00:07:25,840
attached to local observations.

180
00:07:25,840 --> 00:07:29,280
With it, each test adds to what the plant knows about its own process.

181
00:07:29,280 --> 00:07:30,560
Data supports that learning,

182
00:07:30,560 --> 00:07:32,000
but it doesn't replace GEMBA,

183
00:07:32,000 --> 00:07:33,680
the place where work happens.

184
00:07:33,680 --> 00:07:35,520
You still need to stand near the process,

185
00:07:35,520 --> 00:07:37,120
ask operators what they saw.

186
00:07:37,120 --> 00:07:38,560
Here, why they bypassed a step

187
00:07:38,560 --> 00:07:40,880
and noticed the gap between written work instructions

188
00:07:40,880 --> 00:07:41,920
and real work.

189
00:07:41,920 --> 00:07:44,000
A data record may show a 10-minute stop,

190
00:07:44,000 --> 00:07:46,080
but it won't always tell you that an operator paused

191
00:07:46,080 --> 00:07:47,440
because a part felt wrong.

192
00:07:47,440 --> 00:07:49,360
The normal material route was blocked,

193
00:07:49,360 --> 00:07:52,400
or a prior shift left the station in an unsafe state.

194
00:07:52,400 --> 00:07:53,680
The people at the line supply,

195
00:07:53,680 --> 00:07:56,080
meaning that systems can't infer on their own.

196
00:07:56,080 --> 00:07:58,640
At the same time, observation alone has limits.

197
00:07:58,640 --> 00:08:00,960
People see one shift, one event,

198
00:08:00,960 --> 00:08:02,320
one version of a problem.

199
00:08:02,320 --> 00:08:04,480
Connected operational data helps the team check

200
00:08:04,480 --> 00:08:08,000
whether that observation repeats across orders, machines, products, and time.

201
00:08:08,000 --> 00:08:10,080
So the strongest improvement loop combines both.

202
00:08:10,080 --> 00:08:12,720
GEMBA tells you where to look and what questions matter.

203
00:08:12,720 --> 00:08:14,720
Operational data lets you test those questions

204
00:08:14,720 --> 00:08:16,640
across the real pattern of production.

205
00:08:16,640 --> 00:08:18,560
Standard work carries the learning forward,

206
00:08:18,560 --> 00:08:20,960
so the next shift doesn't start from zero.

207
00:08:20,960 --> 00:08:22,480
That sounds straightforward,

208
00:08:22,480 --> 00:08:25,440
yet the loop often breaks right after the workshop ends,

209
00:08:25,440 --> 00:08:27,600
when the team returns to daily production

210
00:08:27,600 --> 00:08:29,520
and the evidence needed for the check step

211
00:08:29,520 --> 00:08:33,040
sits scattered across systems, reports, and personal memory.

212
00:08:33,040 --> 00:08:34,640
Why improvement programs stall?

213
00:08:34,640 --> 00:08:37,840
Most improvement programs follow a familiar path.

214
00:08:37,840 --> 00:08:40,240
Someone spots a recurring loss,

215
00:08:40,240 --> 00:08:42,080
a manager sponsors a workshop,

216
00:08:42,080 --> 00:08:44,240
the team spends a few days mapping the work,

217
00:08:44,240 --> 00:08:46,720
and then an action tracker appears with owners and dates.

218
00:08:46,720 --> 00:08:49,680
For a short time, attention is high.

219
00:08:49,680 --> 00:08:51,680
People ask questions, move things around,

220
00:08:51,680 --> 00:08:54,320
test new routines, and report progress.

221
00:08:54,320 --> 00:08:56,080
Then normal production pressure returns,

222
00:08:56,080 --> 00:08:58,000
the next urgent order enters the plan,

223
00:08:58,000 --> 00:09:00,080
and the tracker slowly becomes another file,

224
00:09:00,080 --> 00:09:02,240
nobody opens, unless someone asks

225
00:09:02,240 --> 00:09:03,520
for a status update.

226
00:09:03,520 --> 00:09:05,600
The work didn't fail because the team lacked effort.

227
00:09:05,600 --> 00:09:07,680
It lost its place in the daily operating rhythm.

228
00:09:07,680 --> 00:09:10,400
A shift supervisor still has to decide what to run next,

229
00:09:10,400 --> 00:09:12,960
a planner still has to respond when an order slips,

230
00:09:12,960 --> 00:09:14,560
and maintenance still has to choose

231
00:09:14,560 --> 00:09:16,640
which fault deserves attention first.

232
00:09:16,640 --> 00:09:18,080
Those decisions happen every day,

233
00:09:18,080 --> 00:09:19,280
often under time pressure,

234
00:09:19,280 --> 00:09:21,760
while the improvement actions sit somewhere separate,

235
00:09:21,760 --> 00:09:22,960
owned by a project team,

236
00:09:22,960 --> 00:09:25,200
or reviewed only in a monthly meeting.

237
00:09:25,200 --> 00:09:26,800
That separation creates a problem.

238
00:09:26,800 --> 00:09:28,640
The kaisen action becomes an extra task

239
00:09:28,640 --> 00:09:30,480
instead of part of how the process runs.

240
00:09:30,480 --> 00:09:33,040
Think about a countermeasure that changes a setup routine.

241
00:09:33,040 --> 00:09:34,480
The team agrees on a new sequence,

242
00:09:34,480 --> 00:09:35,680
writes it into the action list,

243
00:09:35,680 --> 00:09:37,040
and tells the next crew.

244
00:09:37,040 --> 00:09:38,880
But if the shift meeting doesn't check

245
00:09:38,880 --> 00:09:40,560
whether that sequence was used,

246
00:09:40,560 --> 00:09:42,480
under which product conditions it worked,

247
00:09:42,480 --> 00:09:43,600
and where it broke down,

248
00:09:43,600 --> 00:09:45,920
the change has no operating feedback.

249
00:09:45,920 --> 00:09:47,760
People then fall back to the old method

250
00:09:47,760 --> 00:09:48,960
when the line gets busy,

251
00:09:48,960 --> 00:09:50,320
not because they reject improvement,

252
00:09:50,320 --> 00:09:52,240
but because they can't see a clear link

253
00:09:52,240 --> 00:09:53,440
between the new method

254
00:09:53,440 --> 00:09:54,800
and the condition they need to control.

255
00:09:54,800 --> 00:09:56,320
Many programs also collect measures

256
00:09:56,320 --> 00:09:57,280
at the wrong moments,

257
00:09:57,280 --> 00:09:58,560
a baseline before the workshop,

258
00:09:58,560 --> 00:10:00,560
maybe another measurement a few weeks after,

259
00:10:00,560 --> 00:10:02,000
but between those two points,

260
00:10:02,000 --> 00:10:03,360
the team has very little evidence

261
00:10:03,360 --> 00:10:05,360
about what happened during the change.

262
00:10:05,360 --> 00:10:06,800
That makes calls and effect hard to judge.

263
00:10:06,800 --> 00:10:08,080
Maybe output improved

264
00:10:08,080 --> 00:10:10,400
because the new routine reduced setup work,

265
00:10:10,400 --> 00:10:11,600
or maybe the production plan

266
00:10:11,600 --> 00:10:13,920
happened to contain an easier mix of orders.

267
00:10:13,920 --> 00:10:15,120
Perhaps maintenance replaced

268
00:10:15,120 --> 00:10:17,040
a worn component during the same period,

269
00:10:17,040 --> 00:10:19,200
or quality released material faster.

270
00:10:19,200 --> 00:10:20,480
A before and after comparison

271
00:10:20,480 --> 00:10:22,080
can start a useful conversation,

272
00:10:22,080 --> 00:10:23,680
but it can't carry the whole argument.

273
00:10:23,680 --> 00:10:25,600
Production doesn't pause

274
00:10:25,600 --> 00:10:27,520
while an improvement team runs an experiment.

275
00:10:27,520 --> 00:10:29,280
Conditions keep changing around it,

276
00:10:29,280 --> 00:10:31,920
when teams can't see whether a countermeasure holds,

277
00:10:31,920 --> 00:10:32,960
ownership fades.

278
00:10:32,960 --> 00:10:34,720
The operator who helped develop the change

279
00:10:34,720 --> 00:10:35,760
may move to another shift,

280
00:10:35,760 --> 00:10:37,120
the supervisor who backed it

281
00:10:37,120 --> 00:10:38,640
may deal with a larger problem,

282
00:10:38,640 --> 00:10:40,320
and the process engineer may inherit

283
00:10:40,320 --> 00:10:42,480
several open actions from prior events

284
00:10:42,480 --> 00:10:44,320
without time to revisit each one.

285
00:10:44,320 --> 00:10:46,560
Eventually, the plant has a history

286
00:10:46,560 --> 00:10:47,520
of improvement projects,

287
00:10:47,520 --> 00:10:49,440
but no clear memory of which actions worked,

288
00:10:49,440 --> 00:10:51,200
where they worked, and under what conditions.

289
00:10:51,200 --> 00:10:53,280
Excel often fills that gap,

290
00:10:53,280 --> 00:10:55,840
and I don't say that as a cheap joke about spreadsheets.

291
00:10:55,840 --> 00:10:58,400
Excel survives because it solves a real need.

292
00:10:58,400 --> 00:11:00,480
A planner can join a few exports quickly,

293
00:11:00,480 --> 00:11:03,040
an engineer can add a note beside a number,

294
00:11:03,040 --> 00:11:04,720
and a supervisor can correct something

295
00:11:04,720 --> 00:11:06,720
that doesn't look right before the morning meeting.

296
00:11:06,720 --> 00:11:08,080
Those are practical strengths,

297
00:11:08,080 --> 00:11:09,360
but the spreadsheet also becomes

298
00:11:09,360 --> 00:11:11,440
a private version of the process.

299
00:11:11,440 --> 00:11:14,160
One person knows which columns came from the MES,

300
00:11:14,160 --> 00:11:15,760
which number came from an email,

301
00:11:15,760 --> 00:11:17,920
and which adjustment came from local knowledge.

302
00:11:17,920 --> 00:11:19,280
When that person isn't there,

303
00:11:19,280 --> 00:11:20,720
the report may still open,

304
00:11:20,720 --> 00:11:22,880
but the reasoning behind it has gone missing.

305
00:11:22,880 --> 00:11:24,240
Teams then spend meeting time

306
00:11:24,240 --> 00:11:27,200
reconciling numbers instead of deciding what to test next.

307
00:11:27,200 --> 00:11:28,720
You might see an action mark complete

308
00:11:28,720 --> 00:11:30,080
because someone installed a rack

309
00:11:30,080 --> 00:11:32,160
and changed a work instruction or added a reason code,

310
00:11:32,160 --> 00:11:34,400
but that only confirms the task finished.

311
00:11:34,400 --> 00:11:37,120
It doesn't confirm the production condition improved.

312
00:11:37,120 --> 00:11:38,560
Completion isn't learning.

313
00:11:38,560 --> 00:11:40,240
A better program keeps improvement work

314
00:11:40,240 --> 00:11:42,720
connected to the same routines that manage production.

315
00:11:42,720 --> 00:11:45,440
The action should appear when the related loss appears.

316
00:11:45,440 --> 00:11:48,640
The person responsible should see the result close enough to act,

317
00:11:48,640 --> 00:11:50,960
and the team should know what evidence would confirm

318
00:11:50,960 --> 00:11:53,600
the change holds or tell them to revise it.

319
00:11:53,600 --> 00:11:55,360
That requires more than a project tracker.

320
00:11:55,360 --> 00:11:57,280
It requires a reliable way to check,

321
00:11:57,280 --> 00:12:00,480
and that brings us to the weakest part of PDCA in many factories.

322
00:12:00,480 --> 00:12:02,400
Not the plan and not the action,

323
00:12:02,400 --> 00:12:04,160
but the evidence between them.

324
00:12:04,160 --> 00:12:05,920
PDCA needs a reliable check step.

325
00:12:05,920 --> 00:12:10,080
Here's the thing about PDCA that most teams miss.

326
00:12:10,080 --> 00:12:12,080
The whole system only works when the check step

327
00:12:12,080 --> 00:12:14,240
can push back on the team's own assumptions.

328
00:12:14,240 --> 00:12:15,840
Without that, you're just running a process

329
00:12:15,840 --> 00:12:17,040
that feels productive,

330
00:12:17,040 --> 00:12:18,640
but never really teaches you anything.

331
00:12:18,640 --> 00:12:21,280
Let me break down what that actually looks like in practice.

332
00:12:21,280 --> 00:12:23,120
In the plan step, you need a problem statement

333
00:12:23,120 --> 00:12:25,120
that's testable, not just a complaint.

334
00:12:25,120 --> 00:12:27,120
Saying, "Changeovers are too slow,

335
00:12:27,120 --> 00:12:29,280
doesn't give your team anything to verify."

336
00:12:29,280 --> 00:12:31,680
It's a description of pain, not a hypothesis.

337
00:12:31,680 --> 00:12:34,240
A better plan describes three things clearly,

338
00:12:34,240 --> 00:12:36,080
where you are now, where you want to be,

339
00:12:36,080 --> 00:12:39,040
and why you think one specific change will close that gap.

340
00:12:39,040 --> 00:12:40,320
Here's a simple example.

341
00:12:40,320 --> 00:12:42,560
Say your team notices that certain changeovers

342
00:12:42,560 --> 00:12:44,560
run longer after a particular product family.

343
00:12:44,560 --> 00:12:46,560
They suspect it's because tools arrive late,

344
00:12:46,560 --> 00:12:49,440
the outgoing order doesn't trigger preparation early enough,

345
00:12:49,440 --> 00:12:51,280
so they form a clear hypothesis.

346
00:12:51,280 --> 00:12:54,000
If we prepare the toolset before the prior order finishes,

347
00:12:54,000 --> 00:12:56,480
the delay between the last good unit of one order

348
00:12:56,480 --> 00:12:58,720
and the first stable unit of the next should drop.

349
00:12:58,720 --> 00:13:00,400
That's a plan you can actually test.

350
00:13:00,400 --> 00:13:03,040
Now here's where teams often skip a crucial step.

351
00:13:03,040 --> 00:13:04,080
Before you change anything,

352
00:13:04,080 --> 00:13:06,240
you need to decide what would count as evidence,

353
00:13:06,240 --> 00:13:07,760
which changeovers are part of the test,

354
00:13:07,760 --> 00:13:09,760
what time window gives you a fair baseline,

355
00:13:09,760 --> 00:13:11,520
what result would support your idea,

356
00:13:11,520 --> 00:13:13,840
and what side effect would tell you it's not working.

357
00:13:13,840 --> 00:13:15,440
Without those decisions upfront,

358
00:13:15,440 --> 00:13:17,280
your check step turns into a meeting

359
00:13:17,280 --> 00:13:19,760
where everyone picks the story that sounds most convincing.

360
00:13:19,760 --> 00:13:21,920
I've seen that happen more times than I can count,

361
00:13:21,920 --> 00:13:24,000
and it never leads to real learning.

362
00:13:24,000 --> 00:13:26,320
Now the do step, this part needs more care

363
00:13:26,320 --> 00:13:27,840
than most teams give it.

364
00:13:27,840 --> 00:13:29,600
Running a controlled production change

365
00:13:29,600 --> 00:13:32,560
doesn't mean turning your factory into a science experiment.

366
00:13:32,560 --> 00:13:34,480
You still have delivery commitments,

367
00:13:34,480 --> 00:13:36,080
safety rules, quality controls,

368
00:13:36,080 --> 00:13:37,680
and people trying to finish a shift.

369
00:13:37,680 --> 00:13:39,840
What it means is recording enough about the trial

370
00:13:39,840 --> 00:13:42,480
to separate the change from everything else around it.

371
00:13:42,480 --> 00:13:44,800
You note when the revised setup method started,

372
00:13:44,800 --> 00:13:46,240
you document the machine or line,

373
00:13:46,240 --> 00:13:48,000
the product sequence, the team running it,

374
00:13:48,000 --> 00:13:50,320
and any unusual event that happened during the trial.

375
00:13:50,320 --> 00:13:52,320
If maintenance adjusted something at the same time,

376
00:13:52,320 --> 00:13:53,600
that belongs in the record too.

377
00:13:53,600 --> 00:13:55,680
Otherwise, you might give credit to the wrong action.

378
00:13:55,680 --> 00:13:58,160
Countermeasures rarely arrive alone.

379
00:13:58,160 --> 00:13:59,680
They come with other changes attached,

380
00:13:59,680 --> 00:14:01,600
and you need to know which one actually mattered.

381
00:14:01,600 --> 00:14:02,480
Then you get to check,

382
00:14:02,480 --> 00:14:04,480
this is where the process stops being a good idea

383
00:14:04,480 --> 00:14:06,000
and becomes a learning system.

384
00:14:06,000 --> 00:14:08,240
You compare the actual operating result

385
00:14:08,240 --> 00:14:09,840
with the result you expected,

386
00:14:09,840 --> 00:14:12,720
using the same terms and boundaries you set in the plan step.

387
00:14:12,720 --> 00:14:14,240
Did the change reduce the delay?

388
00:14:14,240 --> 00:14:16,160
Did the delay just move somewhere else?

389
00:14:16,160 --> 00:14:19,360
Did the method only work for one specific product transition?

390
00:14:19,360 --> 00:14:21,120
Did it add extra work for the operator

391
00:14:21,120 --> 00:14:23,360
or create a quality issue after start-up?

392
00:14:23,360 --> 00:14:25,520
Those questions need facts from real production,

393
00:14:25,520 --> 00:14:28,240
not just a positive impression after the first trial.

394
00:14:28,240 --> 00:14:29,840
Here's something most people overlook.

395
00:14:29,840 --> 00:14:32,000
A good check step respects variation.

396
00:14:32,000 --> 00:14:33,760
One clean run tells you very little.

397
00:14:33,760 --> 00:14:36,880
A line can behave well because material arrived on time,

398
00:14:36,880 --> 00:14:38,560
the tool was in good condition,

399
00:14:38,560 --> 00:14:41,440
or an experienced operator happened to be running that setup.

400
00:14:41,440 --> 00:14:43,840
You don't need a huge study for every small improvement,

401
00:14:43,840 --> 00:14:47,360
but you do need enough evidence to tell the difference between a repeatable effect

402
00:14:47,360 --> 00:14:48,480
and a lucky shift.

403
00:14:48,480 --> 00:14:50,960
This is where many teams jump too quickly from due to act.

404
00:14:50,960 --> 00:14:52,240
They try a new method,

405
00:14:52,240 --> 00:14:54,480
see an early improvement and write a new standard.

406
00:14:54,480 --> 00:14:56,720
Then later the method breaks under different conditions

407
00:14:56,720 --> 00:14:58,240
and people quietly stop using it

408
00:14:58,240 --> 00:15:00,800
because the standard no longer matches the real work.

409
00:15:00,800 --> 00:15:02,160
That damages trust.

410
00:15:02,160 --> 00:15:04,240
And rebuilding it takes a lot more effort

411
00:15:04,240 --> 00:15:06,240
than getting the check step right the first time.

412
00:15:06,240 --> 00:15:08,160
Act should follow evidence.

413
00:15:08,160 --> 00:15:09,200
When the result holds,

414
00:15:09,200 --> 00:15:11,680
you decide how to carry the change into normal work.

415
00:15:11,680 --> 00:15:14,720
That might mean updating standard work, changing a planning rule,

416
00:15:14,720 --> 00:15:16,320
revising a maintenance check,

417
00:15:16,320 --> 00:15:18,800
or training the crews who will use the new method.

418
00:15:18,800 --> 00:15:21,040
When the evidence doesn't support your idea,

419
00:15:21,040 --> 00:15:22,400
act means something else.

420
00:15:22,400 --> 00:15:25,200
You adapt the countermeasure, narrow where it applies,

421
00:15:25,200 --> 00:15:26,800
or remove it completely.

422
00:15:26,800 --> 00:15:29,840
A plant that can reverse a weak change quickly learns faster

423
00:15:29,840 --> 00:15:32,160
than one that preserves every completed action

424
00:15:32,160 --> 00:15:34,640
because nobody wants to reopen a closed project.

425
00:15:34,640 --> 00:15:37,440
The check step gives people permission to be wrong in a useful way.

426
00:15:37,440 --> 00:15:39,520
Without it, PDCA turns into an opinion loop,

427
00:15:39,520 --> 00:15:41,440
someone with more experience, more authority

428
00:15:41,440 --> 00:15:43,600
or simply a stronger voice proposes a cause.

429
00:15:43,600 --> 00:15:44,720
The team acts on it.

430
00:15:44,720 --> 00:15:47,920
A few people agree it looks better than the next problem takes over.

431
00:15:47,920 --> 00:15:49,680
That can produce local improvements,

432
00:15:49,680 --> 00:15:51,600
but it doesn't build reliable knowledge.

433
00:15:51,600 --> 00:15:53,200
With a reliable check step,

434
00:15:53,200 --> 00:15:55,440
each countermeasure leaves a record of the condition,

435
00:15:55,440 --> 00:15:58,480
the hypothesis, the trial, and the result.

436
00:15:58,480 --> 00:16:01,040
Over time, you can see which actions actually worked,

437
00:16:01,040 --> 00:16:02,640
which conditions change the outcome,

438
00:16:02,640 --> 00:16:04,560
and which all the assumptions no longer hold.

439
00:16:04,560 --> 00:16:07,200
That's how continuous improvement becomes continuous.

440
00:16:07,200 --> 00:16:09,120
It's built on evidence, not momentum.

441
00:16:09,120 --> 00:16:10,080
But here's the trap.

442
00:16:10,080 --> 00:16:12,240
Use data is still too vague.

443
00:16:12,240 --> 00:16:14,560
A factory can collect millions of machine events

444
00:16:14,560 --> 00:16:16,160
and still lack the evidence needed

445
00:16:16,160 --> 00:16:17,600
to judge a simple countermeasure.

446
00:16:17,600 --> 00:16:20,000
So before connecting systems or building reports,

447
00:16:20,000 --> 00:16:23,040
you need to define the data that makes a check step credible.

448
00:16:23,040 --> 00:16:24,320
Not every data point helps.

449
00:16:24,320 --> 00:16:26,480
I see this all the time.

450
00:16:26,480 --> 00:16:29,280
A team decides to check a countermeasure with production data,

451
00:16:29,280 --> 00:16:31,840
and the first instinct is to collect more of it.

452
00:16:31,840 --> 00:16:34,480
More sensor tags, more reports, more fields from the MES,

453
00:16:34,480 --> 00:16:36,160
more exports from the ERP,

454
00:16:36,160 --> 00:16:37,840
than someone builds a giant table

455
00:16:37,840 --> 00:16:40,400
that nobody can explain without the person who created it.

456
00:16:40,400 --> 00:16:41,520
That doesn't solve your problem.

457
00:16:41,520 --> 00:16:43,040
It just gives you more noise.

458
00:16:43,040 --> 00:16:45,040
A useful data point connects to actual work.

459
00:16:45,040 --> 00:16:46,640
It tells you what happened, where it happened,

460
00:16:46,640 --> 00:16:49,440
when it happened, and under what production conditions it happened.

461
00:16:49,440 --> 00:16:50,480
Without those links,

462
00:16:50,480 --> 00:16:51,680
a number might look precise

463
00:16:51,680 --> 00:16:54,080
while telling you almost nothing about the improvement question

464
00:16:54,080 --> 00:16:55,120
you're trying to answer.

465
00:16:55,120 --> 00:16:56,480
Take downtime as an example.

466
00:16:56,480 --> 00:16:59,680
Your line might show 40 minutes of downtime in one shift.

467
00:16:59,680 --> 00:17:00,560
That's a starting point,

468
00:17:00,560 --> 00:17:02,560
but it doesn't tell you whether the stop occurred

469
00:17:02,560 --> 00:17:04,720
during an order, between orders,

470
00:17:04,720 --> 00:17:05,920
during a planned changeover,

471
00:17:05,920 --> 00:17:08,080
or while quality was waiting for a decision.

472
00:17:08,080 --> 00:17:09,680
The same number can mean very different things

473
00:17:09,680 --> 00:17:11,680
depending on when and why it happened.

474
00:17:11,680 --> 00:17:12,800
For improvement work,

475
00:17:12,800 --> 00:17:15,840
every measure needs enough context to support a decision.

476
00:17:15,840 --> 00:17:18,720
At a minimum, you should be able to tie an event to a time,

477
00:17:18,720 --> 00:17:20,080
a product or product family,

478
00:17:20,080 --> 00:17:21,120
a process step,

479
00:17:21,120 --> 00:17:22,000
a resource,

480
00:17:22,000 --> 00:17:23,280
and a shift or crew,

481
00:17:23,280 --> 00:17:25,120
where that context helps explain the work.

482
00:17:25,120 --> 00:17:27,120
You don't need every fact for every question,

483
00:17:27,120 --> 00:17:29,680
but you need the facts that could change your conclusion.

484
00:17:29,680 --> 00:17:31,360
Here's a scenario I see frequently.

485
00:17:31,360 --> 00:17:33,440
Imagine a scrap increase on a filling line,

486
00:17:33,440 --> 00:17:35,040
the daily report shows scrap rows

487
00:17:35,040 --> 00:17:36,240
during the afternoon shift.

488
00:17:36,240 --> 00:17:37,360
That gives you a place to start,

489
00:17:37,360 --> 00:17:39,840
but it doesn't prove the afternoon shift caused the loss.

490
00:17:39,840 --> 00:17:42,800
Maybe a new material batch entered the line near the shift change.

491
00:17:42,800 --> 00:17:44,640
Maybe the line restarted after cleaning.

492
00:17:44,640 --> 00:17:46,880
Maybe a change in machine speed happened earlier,

493
00:17:46,880 --> 00:17:49,680
and the rejected units only appeared later at inspection.

494
00:17:49,680 --> 00:17:50,960
If your data can't connect,

495
00:17:50,960 --> 00:17:52,960
scrap to the order of batch machine setting,

496
00:17:52,960 --> 00:17:54,880
process time and inspection result,

497
00:17:54,880 --> 00:17:56,640
you'll fill the gaps with assumptions.

498
00:17:56,640 --> 00:17:58,240
People do that naturally.

499
00:17:58,240 --> 00:18:00,320
It's what happens when the record is incomplete.

500
00:18:00,320 --> 00:18:03,120
Context also matters for waiting time.

501
00:18:03,120 --> 00:18:04,960
Waiting rarely appears cleanly in the system

502
00:18:04,960 --> 00:18:06,880
because no one owns it as a machine state.

503
00:18:06,880 --> 00:18:09,440
A work order might finish one operation at 10 o'clock,

504
00:18:09,440 --> 00:18:12,080
then sit for two hours before the next operation begins.

505
00:18:12,080 --> 00:18:13,280
Was the resource busy?

506
00:18:13,280 --> 00:18:14,720
Was material unavailable?

507
00:18:14,720 --> 00:18:16,320
Did the order wait for inspection?

508
00:18:16,320 --> 00:18:17,280
Did the plan change?

509
00:18:17,280 --> 00:18:20,560
Or did someone simply fail to record the next transaction on time?

510
00:18:20,560 --> 00:18:23,120
You can't improve waiting by treating it as a blank space

511
00:18:23,120 --> 00:18:24,400
between two timestamps.

512
00:18:24,400 --> 00:18:25,680
That brings us to definitions.

513
00:18:25,680 --> 00:18:28,400
You need to agree definitions before you compare those timestamps.

514
00:18:28,400 --> 00:18:29,680
What counts as downtime?

515
00:18:29,680 --> 00:18:31,600
Does a planned tool change count?

516
00:18:31,600 --> 00:18:33,360
When does a change over start and end?

517
00:18:33,360 --> 00:18:36,080
Does scrap mean every rejected unit or only units

518
00:18:36,080 --> 00:18:37,360
that can't be reworked?

519
00:18:37,360 --> 00:18:39,600
When does rework become a separate operation,

520
00:18:39,600 --> 00:18:42,240
rather than a correction inside the original operation?

521
00:18:42,240 --> 00:18:43,680
These sound like small questions

522
00:18:43,680 --> 00:18:46,560
until two departments calculate the same loss differently.

523
00:18:46,560 --> 00:18:49,360
If production counts a unit as complete when it leaves the machine,

524
00:18:49,360 --> 00:18:51,040
while quality counts it as incomplete

525
00:18:51,040 --> 00:18:52,400
until inspection passes,

526
00:18:52,400 --> 00:18:54,240
both teams will defend their numbers.

527
00:18:54,240 --> 00:18:56,000
Neither team is necessarily wrong.

528
00:18:56,000 --> 00:18:57,200
They're using different definitions

529
00:18:57,200 --> 00:18:58,480
for different parts of the process.

530
00:18:58,480 --> 00:19:01,360
Improvement needs a shared definition for the question at hand.

531
00:19:01,360 --> 00:19:02,880
That doesn't mean forcing every system

532
00:19:02,880 --> 00:19:04,800
into one giant universal measure.

533
00:19:04,800 --> 00:19:07,200
Factories have different purposes for different records.

534
00:19:07,200 --> 00:19:08,960
Maintenance needs one view of a stop.

535
00:19:08,960 --> 00:19:10,160
Production needs another.

536
00:19:10,160 --> 00:19:12,640
Finance may use a different time boundary for reporting.

537
00:19:12,640 --> 00:19:14,800
The work is to make those differences explicit,

538
00:19:14,800 --> 00:19:16,880
then choose the definition that fits the decision.

539
00:19:16,880 --> 00:19:18,960
If you want to reduce loss production time,

540
00:19:18,960 --> 00:19:22,000
you need a clear rule for when productive time begins and ends.

541
00:19:22,000 --> 00:19:24,320
If you want to reduce quality loss after a restart,

542
00:19:24,320 --> 00:19:27,360
you need a clear rule for which units belong to that restart window.

543
00:19:27,360 --> 00:19:29,520
This is also where OE can create confusion.

544
00:19:29,520 --> 00:19:31,920
Overall, equipment effectiveness can be useful

545
00:19:31,920 --> 00:19:34,640
because it gives a common way to discuss availability,

546
00:19:34,640 --> 00:19:36,080
performance and quality.

547
00:19:36,080 --> 00:19:38,960
A falling OE number can tell you that something changed

548
00:19:38,960 --> 00:19:40,160
and deserves attention.

549
00:19:40,160 --> 00:19:41,920
But OE doesn't diagnose the cause.

550
00:19:41,920 --> 00:19:44,480
A lower OE result might come from longer stops,

551
00:19:44,480 --> 00:19:47,600
slower cycles, rejected units, or a mix of all three.

552
00:19:47,600 --> 00:19:50,320
It can also change because the target rate in the calculation

553
00:19:50,320 --> 00:19:53,120
no longer matches the product or operating condition.

554
00:19:53,120 --> 00:19:56,160
Treating OE as a root cause answer is like treating a warning light

555
00:19:56,160 --> 00:19:57,040
as a repair manual.

556
00:19:57,040 --> 00:19:58,480
It tells you where to look.

557
00:19:58,480 --> 00:20:00,080
It doesn't tell you what to change.

558
00:20:00,080 --> 00:20:01,840
The same applies to any headline measure.

559
00:20:01,840 --> 00:20:05,120
Total output, schedule adherence, scrap rate, and lead time

560
00:20:05,120 --> 00:20:07,360
can all point to water condition that needs work.

561
00:20:07,360 --> 00:20:09,600
They become useful for lean only when you can trace them

562
00:20:09,600 --> 00:20:11,920
back to the actual work and test a specific idea.

563
00:20:11,920 --> 00:20:14,880
So don't start with the data your systems happen to produce.

564
00:20:14,880 --> 00:20:17,120
Start with the production question you need to answer,

565
00:20:17,120 --> 00:20:20,160
then follow that question back through the facts required to answer it.

566
00:20:20,160 --> 00:20:21,760
That's the only way to build a check step

567
00:20:21,760 --> 00:20:23,200
that actually teaches you something.

568
00:20:23,200 --> 00:20:26,080
Start with the improvement question.

569
00:20:27,520 --> 00:20:30,160
So start with a real question from the work itself.

570
00:20:30,160 --> 00:20:32,560
Not a list of every field your systems can export.

571
00:20:32,560 --> 00:20:34,960
Say a team complains that changeovers take too long

572
00:20:34,960 --> 00:20:36,160
that still covers too much.

573
00:20:36,160 --> 00:20:37,760
A more useful question would be,

574
00:20:37,760 --> 00:20:40,720
why does changeover time vary so much for the same product family

575
00:20:40,720 --> 00:20:41,360
on the same line?

576
00:20:41,360 --> 00:20:44,000
Now the team has something they can actually investigate.

577
00:20:44,000 --> 00:20:46,400
They aren't trying to explain every stop on the line.

578
00:20:46,400 --> 00:20:49,680
They want to understand the variation in one defined part of the process

579
00:20:49,680 --> 00:20:52,880
and that lets them decide what facts belong in the investigation.

580
00:20:52,880 --> 00:20:54,720
And just as important, what facts don't.

581
00:20:55,840 --> 00:20:57,360
Think about what can affect a changeover.

582
00:20:57,360 --> 00:21:00,880
You need the production order because the sequence often matters more than the product alone.

583
00:21:00,880 --> 00:21:03,920
You need to know which product ran before and which one ran after.

584
00:21:03,920 --> 00:21:07,040
You need the line or machine, the toolset, the material involved,

585
00:21:07,040 --> 00:21:08,960
the recipe or settings where those apply,

586
00:21:08,960 --> 00:21:10,960
the shift and the people carrying out the work.

587
00:21:10,960 --> 00:21:13,760
Time matters too, but not just one time stamp.

588
00:21:13,760 --> 00:21:15,760
The team may need the end of the prior run,

589
00:21:15,760 --> 00:21:18,640
the start of setup, the first unit after restart,

590
00:21:18,640 --> 00:21:20,800
and the point where stable output resumes.

591
00:21:20,800 --> 00:21:21,840
Those are different events.

592
00:21:21,840 --> 00:21:24,640
If the factory records only one broad change over complete time,

593
00:21:24,640 --> 00:21:27,520
it may hide the part of the delay the team really needs to improve.

594
00:21:27,520 --> 00:21:29,520
Then at the result, did the line start on time?

595
00:21:29,520 --> 00:21:30,720
Did it reach normal speed?

596
00:21:30,720 --> 00:21:32,240
Did the first output pass quality?

597
00:21:32,240 --> 00:21:35,600
Did the setup trigger an alarm, a manual adjustment or a wait for material?

598
00:21:35,600 --> 00:21:38,480
That turns a vague complaint into a testable question.

599
00:21:38,480 --> 00:21:41,120
Suppose the team thinks tool staging causes the variation.

600
00:21:41,120 --> 00:21:42,960
They can test that idea against changeovers,

601
00:21:42,960 --> 00:21:45,760
where the right tools were ready before the prior order ended,

602
00:21:45,760 --> 00:21:49,280
then compare those runs with similar transitions where preparation started late.

603
00:21:49,280 --> 00:21:53,280
The comparison only works if similar means something concrete.

604
00:21:53,280 --> 00:21:55,840
Same product family may not mean same package size,

605
00:21:55,840 --> 00:21:58,480
same machine may not mean same tool condition,

606
00:21:58,480 --> 00:22:00,720
same shift may not mean the same staffing level.

607
00:22:00,720 --> 00:22:03,200
Lean teams already know this when they stand at the line.

608
00:22:03,200 --> 00:22:05,760
The data model needs to preserve enough of that context

609
00:22:05,760 --> 00:22:08,400
for the evidence to remain honest after the meeting ends.

610
00:22:08,400 --> 00:22:12,000
This also protects teams from collecting data just because it exists.

611
00:22:12,000 --> 00:22:14,800
A modern line can generate a huge number of signals.

612
00:22:14,800 --> 00:22:17,840
Temperature readings, motor current, cycle counts, alarm codes,

613
00:22:17,840 --> 00:22:19,760
valve positions, controller states.

614
00:22:19,760 --> 00:22:22,160
Some of those signals may help explain the setup problem.

615
00:22:22,160 --> 00:22:22,880
Many won't.

616
00:22:22,880 --> 00:22:26,400
If nobody can explain how a sensor tag could change the improvement decision,

617
00:22:26,400 --> 00:22:27,280
don't start with it.

618
00:22:27,280 --> 00:22:28,960
That doesn't mean the tag has no use.

619
00:22:28,960 --> 00:22:32,720
It may matter later once the team sees a pattern that points toward machine condition

620
00:22:32,720 --> 00:22:33,840
or process stability.

621
00:22:33,840 --> 00:22:36,960
But collecting every available tag before the question is clear,

622
00:22:36,960 --> 00:22:41,600
usually creates delay, noise, and a false sense that the team has become more scientific

623
00:22:41,600 --> 00:22:43,280
because the data said grew.

624
00:22:43,280 --> 00:22:45,200
More rows don't create better reasoning.

625
00:22:45,200 --> 00:22:47,600
The level of detail should also match the decision.

626
00:22:47,600 --> 00:22:51,280
A production manager deciding whether a new setup standard holds across the week

627
00:22:51,280 --> 00:22:54,560
may need a shift-level trend with clear drill down into exceptions.

628
00:22:54,560 --> 00:22:58,000
A process engineer trying to find why the first units fail after restart

629
00:22:58,000 --> 00:23:02,720
may need event-level data, perhaps down to individual cycles or inspection results.

630
00:23:02,720 --> 00:23:04,000
Those are different questions.

631
00:23:04,000 --> 00:23:05,600
They need different time scales.

632
00:23:05,600 --> 00:23:09,120
Trying to force both into one report often produces something that looks complete

633
00:23:09,120 --> 00:23:10,560
but helps neither person.

634
00:23:10,560 --> 00:23:12,640
The manager gets too much detail to act quickly.

635
00:23:12,640 --> 00:23:15,760
The engineer gets averages that smooth out the event they need to examine,

636
00:23:15,760 --> 00:23:17,760
so ask who needs to decide what and when.

637
00:23:17,760 --> 00:23:19,760
If the decision happens during a shift handover,

638
00:23:19,760 --> 00:23:22,640
the evidence must arrive quickly enough for the next crew to use it.

639
00:23:22,640 --> 00:23:25,920
If the decision concerns a recurring pattern across product families,

640
00:23:25,920 --> 00:23:28,560
a daily or weekly view may fit perfectly well.

641
00:23:28,560 --> 00:23:31,760
Real-time data can help, but it isn't a badge of seriousness.

642
00:23:31,760 --> 00:23:35,520
A late but trusted record can beat a live number with no production context.

643
00:23:35,520 --> 00:23:37,760
Here's another benefit to starting with the question.

644
00:23:37,760 --> 00:23:39,760
It exposes missing links early.

645
00:23:39,760 --> 00:23:43,040
You may discover that the MES records the order and the machine state,

646
00:23:43,040 --> 00:23:44,480
but not the tool identity.

647
00:23:44,480 --> 00:23:46,960
Or the quality system records failed start-up units,

648
00:23:46,960 --> 00:23:49,200
but nobody links them to the change over that came before.

649
00:23:49,200 --> 00:23:50,240
That's useful information.

650
00:23:50,240 --> 00:23:53,440
It tells you where the improvement loop loses sight of the process.

651
00:23:53,440 --> 00:23:55,680
Don't respond by launching a giant data program.

652
00:23:55,680 --> 00:23:59,120
Define the smallest missing fact that would let the team test its hypothesis.

653
00:23:59,120 --> 00:24:02,160
Perhaps that means adding a simple tool identifier to the setup record.

654
00:24:02,160 --> 00:24:04,960
Perhaps it means recording when stable production begins.

655
00:24:04,960 --> 00:24:07,200
Rather than treating restart as a single event,

656
00:24:07,200 --> 00:24:10,800
small changes to data capture can change the quality of the conversation.

657
00:24:10,800 --> 00:24:14,240
Once the question is clear, you can trace where each fact lives.

658
00:24:14,240 --> 00:24:17,680
Some sit in planning records, some come from production execution,

659
00:24:17,680 --> 00:24:21,200
others come directly from the equipment or from the people who work with it.

660
00:24:21,200 --> 00:24:23,600
ERP knows the commercial and planning context.

661
00:24:23,600 --> 00:24:26,800
Once the team knows which facts it needs,

662
00:24:26,800 --> 00:24:28,560
ERP becomes part of the story.

663
00:24:28,560 --> 00:24:33,760
Your enterprise resource planning system holds the commercial and planning view of production.

664
00:24:33,760 --> 00:24:37,760
The part that lean teams often miss when they focus only on what happened at a machine.

665
00:24:37,760 --> 00:24:42,400
ERP knows the sales order, promised delivery date, planned quantity,

666
00:24:42,400 --> 00:24:45,200
bill of materials, routing and material demand.

667
00:24:45,200 --> 00:24:48,080
It can tell you what the business intended the factory to produce,

668
00:24:48,080 --> 00:24:50,160
in what broad sequence and for whom.

669
00:24:50,160 --> 00:24:52,000
That context changes the improvement question.

670
00:24:52,000 --> 00:24:53,840
Take a long change over on a line.

671
00:24:53,840 --> 00:24:56,240
From the lines point of view, it looks like lost time.

672
00:24:56,240 --> 00:24:58,800
From the ERP view, it may also affect a customer order,

673
00:24:58,800 --> 00:25:02,080
due tomorrow, consumed capacity needed for a higher priority job

674
00:25:02,080 --> 00:25:05,520
or force a planner to split a batch that normally runs as one lot.

675
00:25:05,520 --> 00:25:07,280
The physical delay stays the same.

676
00:25:07,280 --> 00:25:08,560
The consequence does not.

677
00:25:08,560 --> 00:25:11,280
Planning records also explain why a team may see different results

678
00:25:11,280 --> 00:25:13,280
from what looked like the same improvement.

679
00:25:13,280 --> 00:25:16,400
Suppose a Kaiser team cuts setup time for a certain product family.

680
00:25:16,400 --> 00:25:19,280
In the following month, delivery performance still slips.

681
00:25:19,280 --> 00:25:21,520
At first, that can look like the countermeasure failed.

682
00:25:21,520 --> 00:25:23,840
But the ERP plan may show that demand changed,

683
00:25:23,840 --> 00:25:26,320
the production mix shifted towards smaller lots

684
00:25:26,320 --> 00:25:30,560
or a customer commitment forced more frequent product switches than the line normally sees.

685
00:25:30,560 --> 00:25:34,880
Without that planning context, the team judges the improvement against a moving target.

686
00:25:34,880 --> 00:25:38,800
ERP also carries the process design that production is supposed to follow.

687
00:25:38,800 --> 00:25:41,760
A routing may define which operations an order should visit,

688
00:25:41,760 --> 00:25:43,520
which work centers should perform them,

689
00:25:43,520 --> 00:25:45,680
and what materials the order should consume.

690
00:25:45,680 --> 00:25:48,240
That gives the improvement team a reference point when it asks

691
00:25:48,240 --> 00:25:50,880
whether the actual process followed the intended path.

692
00:25:50,880 --> 00:25:53,520
But planned data and actual data are different things.

693
00:25:53,520 --> 00:25:56,480
A routing can say an order should run on a certain resource.

694
00:25:56,480 --> 00:25:58,320
The schedule can say it should begin at 8.

695
00:25:58,320 --> 00:26:01,360
Material demand can say everything should be available before release.

696
00:26:01,360 --> 00:26:03,440
None of that proves the order actually ran there,

697
00:26:03,440 --> 00:26:06,000
started then or had the right material at the line.

698
00:26:06,000 --> 00:26:07,520
Factories adapt all day.

699
00:26:07,520 --> 00:26:10,960
Planners, re-sequence work, supervisors move orders to another resource.

700
00:26:10,960 --> 00:26:13,600
Operators use and approved substitute material.

701
00:26:13,600 --> 00:26:16,560
A machine stops and the original plan becomes history before lunch.

702
00:26:16,560 --> 00:26:18,240
That isn't a failure of ERP.

703
00:26:18,240 --> 00:26:20,320
ERP manages intent and coordination.

704
00:26:20,320 --> 00:26:21,600
It gives the plan to common plan,

705
00:26:21,600 --> 00:26:24,400
but it doesn't automatically record the full detail of execution

706
00:26:24,400 --> 00:26:26,000
at the point where work happens.

707
00:26:26,000 --> 00:26:29,040
This distinction matters when a lean team investigates a loss.

708
00:26:29,040 --> 00:26:32,000
If the team treats ERP status as live operating truth,

709
00:26:32,000 --> 00:26:33,520
it may draw the wrong conclusion.

710
00:26:33,520 --> 00:26:36,480
An order can look released in ERP while it waits for material.

711
00:26:36,480 --> 00:26:38,480
It can look complete from a quantity point of view

712
00:26:38,480 --> 00:26:40,880
while quality still holds part of the batch.

713
00:26:40,880 --> 00:26:43,040
It can remain scheduled on one work centre

714
00:26:43,040 --> 00:26:45,680
after production moved it somewhere else to keep the line running.

715
00:26:45,680 --> 00:26:47,200
The planar may know why that happened.

716
00:26:47,200 --> 00:26:48,800
The system may not show the full reason

717
00:26:48,800 --> 00:26:50,800
in a form the improvement team can use.

718
00:26:50,800 --> 00:26:53,040
Master data can create trouble here too.

719
00:26:53,040 --> 00:26:55,040
Product codes, routing, standard times

720
00:26:55,040 --> 00:26:57,040
and resource assignments look administrative

721
00:26:57,040 --> 00:27:00,000
until a team tries to compare actual work with a baseline.

722
00:27:00,000 --> 00:27:02,880
If the routing says a change over should take one amount of time

723
00:27:02,880 --> 00:27:04,720
but the tool requirement changed months ago

724
00:27:04,720 --> 00:27:05,920
without a matching update,

725
00:27:05,920 --> 00:27:07,840
the baseline already contains a problem.

726
00:27:07,840 --> 00:27:10,240
Then the team can spend days trying to explain a gap

727
00:27:10,240 --> 00:27:11,920
that began in master data.

728
00:27:11,920 --> 00:27:15,040
That's why continuous improvement needs a two-way connection with planning.

729
00:27:15,040 --> 00:27:17,600
Lean work shouldn't treat the schedule as an outside condition

730
00:27:17,600 --> 00:27:18,960
that no one can question.

731
00:27:18,960 --> 00:27:22,080
If repeated evidence shows a routing no longer matches the work,

732
00:27:22,080 --> 00:27:23,680
that's an improvement finding.

733
00:27:23,680 --> 00:27:27,120
If plan sequence rules create avoidable cleaning or setup losses,

734
00:27:27,120 --> 00:27:28,880
that belongs in the discussion too.

735
00:27:28,880 --> 00:27:31,280
A production loss can begin in a planning assumption.

736
00:27:31,280 --> 00:27:33,680
ERP helps the team connect shop floor conditions

737
00:27:33,680 --> 00:27:36,560
to order promises, material demand, capacity choices

738
00:27:36,560 --> 00:27:38,640
and the process that people expect it to run.

739
00:27:38,640 --> 00:27:40,400
It can show the consequence of a local issue

740
00:27:40,400 --> 00:27:42,240
beyond one machine or one shift.

741
00:27:42,240 --> 00:27:45,040
Still, ERP can only tell you part of the story.

742
00:27:45,040 --> 00:27:47,440
To see what the order actually did after release,

743
00:27:47,440 --> 00:27:49,360
you need to move closer to the work

744
00:27:49,360 --> 00:27:52,000
into the system that records production execution.

745
00:27:52,000 --> 00:27:54,320
MES knows what production executed.

746
00:27:54,320 --> 00:27:57,760
ERP tells you what the plant intended to do

747
00:27:57,760 --> 00:27:59,520
but the manufacturing execution system,

748
00:27:59,520 --> 00:28:02,640
or MES, records the work as it move through production

749
00:28:02,640 --> 00:28:06,160
which gives the improvement team a firmer place to test an assumption.

750
00:28:06,160 --> 00:28:08,800
An MES can capture that a work order reached a line

751
00:28:08,800 --> 00:28:10,480
that an operation started and finished

752
00:28:10,480 --> 00:28:14,400
along with produced quantity, rejects, holds, material consumption,

753
00:28:14,400 --> 00:28:16,720
operator entries and traceability links

754
00:28:16,720 --> 00:28:19,120
tying a unit or batch back to the process history.

755
00:28:19,120 --> 00:28:23,200
That record fills the space between the plan and the physical result,

756
00:28:23,200 --> 00:28:26,320
picture an order that ERP scheduled for line two.

757
00:28:26,320 --> 00:28:28,320
During the shift, the line develops a fault,

758
00:28:28,320 --> 00:28:30,400
so the supervisor moves the order to line three,

759
00:28:30,400 --> 00:28:32,320
the operator starts later than planned,

760
00:28:32,320 --> 00:28:35,840
pauses for a quality check, produces most of the required quantity

761
00:28:35,840 --> 00:28:37,760
then puts the remaining units on hold

762
00:28:37,760 --> 00:28:40,080
because an inspection result needs review.

763
00:28:40,080 --> 00:28:42,400
The planning record alone can't tell that story

764
00:28:42,400 --> 00:28:46,320
but the MES can show the actual route times quantities at each stage

765
00:28:46,320 --> 00:28:48,320
and exactly where the order stopped moving.

766
00:28:48,320 --> 00:28:51,520
For lean work, that detail changes the kind of question a team can ask.

767
00:28:51,520 --> 00:28:54,240
Instead of saying we seem to lose time after release,

768
00:28:54,240 --> 00:28:56,960
they can ask whether orders wait before a specific operation,

769
00:28:56,960 --> 00:29:00,800
whether a revised setup method reduces time from start to stable output

770
00:29:00,800 --> 00:29:04,000
or whether rejects rise after certain production conditions.

771
00:29:04,000 --> 00:29:07,200
The MES gives events a production identity,

772
00:29:07,200 --> 00:29:10,960
a stop, a reject, or a delay becomes more useful

773
00:29:10,960 --> 00:29:12,720
when you connect it to a work order,

774
00:29:12,720 --> 00:29:15,440
an operation, a resource, and a time range.

775
00:29:15,440 --> 00:29:17,040
That doesn't solve the cause on its own

776
00:29:17,040 --> 00:29:19,200
but it gives the team a trace they can follow

777
00:29:19,200 --> 00:29:21,840
without relying on someone's memory from last Tuesday.

778
00:29:21,840 --> 00:29:23,360
Now here's where it gets interesting.

779
00:29:23,360 --> 00:29:27,200
This matters most when a countermeasure has to survive normal variation,

780
00:29:27,200 --> 00:29:29,200
say the team changes a setup instruction

781
00:29:29,200 --> 00:29:31,600
and wants to know if the change works across all crews.

782
00:29:31,600 --> 00:29:34,800
They can use mess records to compare execution across shifts,

783
00:29:34,800 --> 00:29:37,600
product families, and orders that ran under the agreed method

784
00:29:37,600 --> 00:29:39,440
but the comparison has to stay honest.

785
00:29:39,440 --> 00:29:42,480
The team needs to know which orders followed the new method when it began

786
00:29:42,480 --> 00:29:44,480
and whether operators used it as intended,

787
00:29:44,480 --> 00:29:48,080
otherwise the report may compare two groups that only look similar from a distance.

788
00:29:48,080 --> 00:29:51,440
MES records aren't automatically clean

789
00:29:51,440 --> 00:29:53,760
just because they come from a production system.

790
00:29:53,760 --> 00:29:55,200
Every factory has gaps.

791
00:29:55,200 --> 00:29:57,040
An operator may enter a transaction late

792
00:29:57,040 --> 00:29:58,960
because the line needed attention first.

793
00:29:58,960 --> 00:30:01,360
A reason code may mean one thing to day shift

794
00:30:01,360 --> 00:30:03,120
and something different to night shift

795
00:30:03,120 --> 00:30:05,840
and a supervisor may use a workaround to keep work moving

796
00:30:05,840 --> 00:30:09,520
when the formal transaction sequence doesn't fit in unusual situation.

797
00:30:09,520 --> 00:30:12,080
Those work runs often carry useful information.

798
00:30:12,080 --> 00:30:14,880
They show where the digital process doesn't match the real process.

799
00:30:14,880 --> 00:30:16,800
If people routinely delay a transaction

800
00:30:16,800 --> 00:30:18,080
or choose a broad reason code

801
00:30:18,080 --> 00:30:20,160
because the available choices don't describe the work,

802
00:30:20,160 --> 00:30:22,400
the team shouldn't start by blaming data entry.

803
00:30:22,400 --> 00:30:25,120
Instead they should ask what the workflow asks people to do

804
00:30:25,120 --> 00:30:27,520
and whether that request makes sense during production.

805
00:30:27,520 --> 00:30:29,440
Reason codes need the same treatment.

806
00:30:29,440 --> 00:30:32,480
A code like equipment issue may point toward maintenance

807
00:30:32,480 --> 00:30:34,640
but it doesn't explain whether a sensor failed,

808
00:30:34,640 --> 00:30:36,640
a fixture needed adjustment or an alarm

809
00:30:36,640 --> 00:30:38,000
followed a material problem.

810
00:30:38,000 --> 00:30:41,440
The MES can give the event a place in the order history

811
00:30:41,440 --> 00:30:44,400
but investigation still needs people who understand the process.

812
00:30:44,400 --> 00:30:46,000
That's actually a healthy split.

813
00:30:46,000 --> 00:30:48,000
The system records repeatable facts

814
00:30:48,000 --> 00:30:50,080
and operators, engineers, quality staff

815
00:30:50,080 --> 00:30:51,840
and maintenance teams interpret those facts

816
00:30:51,840 --> 00:30:53,120
against the conditions they know.

817
00:30:53,120 --> 00:30:55,680
When the interpretation reveals a gap,

818
00:30:55,680 --> 00:30:58,240
MES data can show whether that gap repeats elsewhere

819
00:30:58,240 --> 00:30:59,920
or belongs to one unusual run.

820
00:30:59,920 --> 00:31:00,960
Watch the timing though.

821
00:31:00,960 --> 00:31:03,840
An MES might record the time a user confirms an operation.

822
00:31:03,840 --> 00:31:06,000
Not the exact moment the physical process ended,

823
00:31:06,000 --> 00:31:07,360
that distinction can matter a lot

824
00:31:07,360 --> 00:31:09,760
when studying short delays, handoffs or setup work.

825
00:31:09,760 --> 00:31:12,800
For some questions, transaction time gives enough evidence.

826
00:31:12,800 --> 00:31:14,400
For others, the team needs a closer view

827
00:31:14,400 --> 00:31:16,240
of equipment and process states.

828
00:31:16,240 --> 00:31:18,240
The decision should follow the improvement question,

829
00:31:18,240 --> 00:31:20,720
not a belief that every timestamp means the same thing.

830
00:31:20,720 --> 00:31:23,920
Used well, the MES becomes the factual record of execution

831
00:31:23,920 --> 00:31:26,000
that PDCA needs for its checkstep.

832
00:31:26,000 --> 00:31:28,640
It shows whether an action changed the work order path,

833
00:31:28,640 --> 00:31:31,440
operation duration, output, reject pattern

834
00:31:31,440 --> 00:31:33,760
or hold status across real production runs.

835
00:31:33,760 --> 00:31:36,480
But it still sees the factory from the execution layer

836
00:31:36,480 --> 00:31:39,200
to understand the physical behavior inside a cycle.

837
00:31:39,200 --> 00:31:42,960
Stop or restart, the team may need another source of evidence.

838
00:31:42,960 --> 00:31:45,280
The signals coming from the equipment itself.

839
00:31:45,280 --> 00:31:47,840
IoT and machine data explain the physical process.

840
00:31:47,840 --> 00:31:51,680
The MES can tell you when an operation started

841
00:31:51,680 --> 00:31:55,120
when someone recorded a stop and how many units passed or failed.

842
00:31:55,120 --> 00:31:56,640
But when the team needs to understand

843
00:31:56,640 --> 00:31:58,480
what happened inside that operation,

844
00:31:58,480 --> 00:32:00,640
they often need data from the machine.

845
00:32:00,640 --> 00:32:02,880
That data usually begins at the PLC,

846
00:32:02,880 --> 00:32:05,840
the programmable logic controller that runs the equipment.

847
00:32:05,840 --> 00:32:09,600
It may include cycle signals, machine states, alarm events, speed,

848
00:32:09,600 --> 00:32:11,440
temperature pressure, motor load,

849
00:32:11,440 --> 00:32:14,320
or a signal showing an interlock prevented the next step.

850
00:32:14,320 --> 00:32:17,200
This is where industrial internet of things

851
00:32:17,200 --> 00:32:19,440
or IoT data becomes useful.

852
00:32:19,440 --> 00:32:22,560
It gives the improvement team a closer record of the physical process

853
00:32:22,560 --> 00:32:24,640
rather than only the transactions around it.

854
00:32:24,640 --> 00:32:26,240
Take a recurring restart delay.

855
00:32:26,240 --> 00:32:28,800
The MES may show that production resumed at a certain time

856
00:32:28,800 --> 00:32:30,720
and stable output arrived much later,

857
00:32:30,720 --> 00:32:34,080
but machine data can help separate that period into actual events.

858
00:32:34,080 --> 00:32:37,120
Perhaps the line cycled, but ran below target speed,

859
00:32:37,120 --> 00:32:40,320
perhaps an alarm repeated several times before an operator cleared it,

860
00:32:40,320 --> 00:32:43,440
or perhaps a temperature zone took longer to reach range after cleaning.

861
00:32:43,440 --> 00:32:44,800
Those are different conditions,

862
00:32:44,800 --> 00:32:46,560
and they call for different countermeasures.

863
00:32:46,560 --> 00:32:48,880
A machine signal on its own still has limits.

864
00:32:48,880 --> 00:32:51,120
A motor current spike may look very precise,

865
00:32:51,120 --> 00:32:53,440
but without knowing the work order, product, operation,

866
00:32:53,440 --> 00:32:55,760
and machine condition is just a precise orphan.

867
00:32:55,760 --> 00:32:59,040
You might find a repeated alarm and assume it explains the quality problem,

868
00:32:59,040 --> 00:33:00,960
but then you join it to the production record

869
00:33:00,960 --> 00:33:03,680
and find that the alarm appears on many normal runs,

870
00:33:03,680 --> 00:33:05,440
or you find that it only becomes a problem

871
00:33:05,440 --> 00:33:08,320
during a specific product transition after a tool change

872
00:33:08,320 --> 00:33:09,920
and before the first inspection result.

873
00:33:09,920 --> 00:33:12,720
Context turns the signal into evidence,

874
00:33:12,720 --> 00:33:15,920
so the team needs links between machine events and the production record.

875
00:33:15,920 --> 00:33:18,000
A stop should connect, where possible,

876
00:33:18,000 --> 00:33:22,000
to the resource, work order, operation, product, and time range,

877
00:33:22,000 --> 00:33:24,000
and a quality issue after a restart

878
00:33:24,000 --> 00:33:26,400
should connect back to the process state before it,

879
00:33:26,400 --> 00:33:28,480
not only to the final inspection record.

880
00:33:28,480 --> 00:33:31,360
That doesn't mean every machine event needs a perfect business label.

881
00:33:31,360 --> 00:33:33,200
Factories produce too much data for that

882
00:33:33,200 --> 00:33:35,840
and plenty of it won't matter to the question at hand.

883
00:33:35,840 --> 00:33:37,840
Instead, start with the physical signals

884
00:33:37,840 --> 00:33:40,640
that can help distinguish one explanation from another.

885
00:33:40,640 --> 00:33:42,880
If the team investigates unstable changeovers,

886
00:33:42,880 --> 00:33:44,800
it may need machine state changes,

887
00:33:44,800 --> 00:33:47,520
cycle timing, speed after restart, alarm history,

888
00:33:47,520 --> 00:33:49,680
and time to reach stable running conditions,

889
00:33:49,680 --> 00:33:52,320
but it probably doesn't need every unused control attack

890
00:33:52,320 --> 00:33:55,280
copied into a cloud platform just because the tag exists.

891
00:33:55,280 --> 00:33:56,960
That approach keeps the work focused.

892
00:33:56,960 --> 00:33:58,800
Machine data also needs careful handling

893
00:33:58,800 --> 00:34:01,040
because this sits inside the OT world.

894
00:34:01,040 --> 00:34:02,320
Operational technology.

895
00:34:02,320 --> 00:34:05,680
The controls network exists to run equipment safely and predictably,

896
00:34:05,680 --> 00:34:08,640
not to support a last minute analytics experiment from the office.

897
00:34:08,640 --> 00:34:11,040
Collection should respect the production environment,

898
00:34:11,040 --> 00:34:12,480
use approved connections,

899
00:34:12,480 --> 00:34:14,720
keep traffic and access within known limits,

900
00:34:14,720 --> 00:34:17,280
and avoid changes that interfere with controller timing,

901
00:34:17,280 --> 00:34:20,080
safety functions, or the people trying to run the line.

902
00:34:20,080 --> 00:34:22,400
A factory can tolerate a report arriving later,

903
00:34:22,400 --> 00:34:24,080
but it can't tolerate a data project

904
00:34:24,080 --> 00:34:26,080
that creates an unstable control environment.

905
00:34:26,080 --> 00:34:27,120
This sounds obvious,

906
00:34:27,120 --> 00:34:29,040
but the pressure for real-time visibility

907
00:34:29,040 --> 00:34:30,720
can produce bad decisions.

908
00:34:30,720 --> 00:34:33,760
Not every improvement question needs second-by-second data.

909
00:34:33,760 --> 00:34:36,320
If a team studies a recurring loss across a week,

910
00:34:36,320 --> 00:34:39,440
a scheduled extract of machine states may give enough evidence.

911
00:34:39,440 --> 00:34:41,520
If they need to react during a shift,

912
00:34:41,520 --> 00:34:44,080
faster data may justify the added effort.

913
00:34:44,080 --> 00:34:46,800
The speed of the data should follow the speed of the decision.

914
00:34:46,800 --> 00:34:48,160
There's a human side to this too.

915
00:34:48,160 --> 00:34:50,960
Machine data can help people see recurring process conditions,

916
00:34:50,960 --> 00:34:52,880
but it can also become surveillance theatre

917
00:34:52,880 --> 00:34:56,400
if it's used mainly to judge individual operators from isolated events.

918
00:34:56,400 --> 00:34:57,360
That's not lean.

919
00:34:57,360 --> 00:34:59,920
If a cycle runs slowly, the useful question isn't,

920
00:34:59,920 --> 00:35:01,600
who caused the slow cycle?

921
00:35:01,600 --> 00:35:02,880
It's what condition slowed it?

922
00:35:02,880 --> 00:35:04,640
Was the material difficult to feed?

923
00:35:04,640 --> 00:35:06,160
Did the equipment need adjustment?

924
00:35:06,160 --> 00:35:08,800
Did the work instructionally room for interpretation?

925
00:35:08,800 --> 00:35:11,280
Did a quality concern force a careful manual check?

926
00:35:11,280 --> 00:35:13,600
People need to trust that data will improve the work,

927
00:35:13,600 --> 00:35:16,320
not simply create a new way to assign blame.

928
00:35:16,320 --> 00:35:17,520
When that trust exists,

929
00:35:17,520 --> 00:35:19,840
machine signals can strengthen the PDCA loop.

930
00:35:19,840 --> 00:35:22,320
The team can test whether a change reduced repeated alarms

931
00:35:22,320 --> 00:35:23,600
short and time to stable speed,

932
00:35:23,600 --> 00:35:25,600
or remove the recurring stop pattern,

933
00:35:25,600 --> 00:35:27,120
and they can also see side effects

934
00:35:27,120 --> 00:35:29,040
that an end-of-shift total would hide.

935
00:35:29,040 --> 00:35:32,160
Still, equipment can only report what its sensors and controls can detect,

936
00:35:32,160 --> 00:35:34,240
but it can't explain why an operator chose a work around

937
00:35:34,240 --> 00:35:36,080
why maintenance postponed a repair,

938
00:35:36,080 --> 00:35:38,880
or why a quality check felt wrong despite a normal machine state.

939
00:35:38,880 --> 00:35:41,440
That meaning still comes from the shop floor.

940
00:35:41,440 --> 00:35:43,120
The shop floor adds meaning.

941
00:35:43,440 --> 00:35:46,400
Machine data tells you a line stopped.

942
00:35:46,400 --> 00:35:49,120
The MES shows which order an operation was running,

943
00:35:49,120 --> 00:35:51,520
but neither system catches what people actually saw,

944
00:35:51,520 --> 00:35:53,760
heard, or decided while the process was under pressure.

945
00:35:53,760 --> 00:35:55,520
That context still lives on the shop floor,

946
00:35:55,520 --> 00:35:58,400
and it often changes the direction of an investigation

947
00:35:58,400 --> 00:36:00,320
more than another week of data collection would.

948
00:36:00,320 --> 00:36:03,760
Picture a filler that pauses several times during a run.

949
00:36:03,760 --> 00:36:06,720
The records show repeated short stops and lower speed.

950
00:36:06,720 --> 00:36:08,800
An operator might tell you the real issue starts

951
00:36:08,800 --> 00:36:11,040
when a certain type of container enters the infeed,

952
00:36:11,040 --> 00:36:13,040
because it sits slightly differently in the guide rails

953
00:36:13,040 --> 00:36:14,560
and triggers a manual adjustment.

954
00:36:14,560 --> 00:36:16,720
That observation gives the data a direction.

955
00:36:16,720 --> 00:36:19,120
Maintenance notes matter for the same reason.

956
00:36:19,120 --> 00:36:21,680
A technician records that they adjusted a sensor bracket,

957
00:36:21,680 --> 00:36:24,400
cleaned a photo eye, or noticed wear on a guide.

958
00:36:24,400 --> 00:36:27,120
A quality inspector notes that defects appear at start-up

959
00:36:27,120 --> 00:36:29,040
but fade after the process warms up.

960
00:36:29,040 --> 00:36:30,720
During handover, one crew wants the next

961
00:36:30,720 --> 00:36:33,840
that a work around is in place because a normal step takes too long.

962
00:36:33,840 --> 00:36:35,920
None of those notes replace proper process records.

963
00:36:35,920 --> 00:36:38,480
They add the conditions that formal records often miss.

964
00:36:38,480 --> 00:36:40,320
Reason codes sit right in the middle of this.

965
00:36:40,320 --> 00:36:42,960
A code like material issue, machine fault,

966
00:36:42,960 --> 00:36:45,920
or quality hold helps sort a large number of events

967
00:36:45,920 --> 00:36:47,840
but it shouldn't close the investigation.

968
00:36:47,840 --> 00:36:50,400
A broad code is usually the start of a conversation.

969
00:36:50,400 --> 00:36:53,200
If an operator selects material issue,

970
00:36:53,200 --> 00:36:55,840
the team still needs to ask what that meant in the moment.

971
00:36:55,840 --> 00:36:57,040
Was the material late?

972
00:36:57,040 --> 00:36:58,000
Was the label wrong?

973
00:36:58,000 --> 00:36:59,680
Did the material behave differently?

974
00:36:59,680 --> 00:37:01,440
Did the container arrive damaged?

975
00:37:01,440 --> 00:37:03,360
Or did an upstream change create a problem

976
00:37:03,360 --> 00:37:05,120
that only appeared at this station?

977
00:37:05,120 --> 00:37:06,400
But the code points somewhere.

978
00:37:06,400 --> 00:37:10,080
People explain the path that means data capture needs to fit the way work happens.

979
00:37:10,240 --> 00:37:11,760
If recording an event takes too long,

980
00:37:11,760 --> 00:37:13,760
asks for details nobody can know at the time

981
00:37:13,760 --> 00:37:16,000
or forces an operator to leave a running process,

982
00:37:16,000 --> 00:37:18,800
the data becomes late, vague, or gets skipped.

983
00:37:18,800 --> 00:37:22,000
Then someone in an office calls it a data quality problem.

984
00:37:22,000 --> 00:37:24,960
Technically true, but not very helpful.

985
00:37:24,960 --> 00:37:27,120
A better approach asks a simpler question.

986
00:37:27,120 --> 00:37:30,240
What is the smallest human input that would help the next decision?

987
00:37:30,240 --> 00:37:32,240
Maybe an operator only needs to choose

988
00:37:32,240 --> 00:37:34,080
from a few clear stop categories

989
00:37:34,080 --> 00:37:36,160
and add a short note when a condition falls

990
00:37:36,160 --> 00:37:37,840
outside those categories.

991
00:37:37,840 --> 00:37:40,080
Perhaps a supervisor can confirm the calls later

992
00:37:40,080 --> 00:37:42,240
after speaking with maintenance or quality.

993
00:37:42,240 --> 00:37:44,560
The work should follow the event, not interrupt it.

994
00:37:44,560 --> 00:37:47,680
You also need a feedback loop back to the people who enter the data.

995
00:37:47,680 --> 00:37:49,920
Operators stop trusting a reason code process

996
00:37:49,920 --> 00:37:52,080
if every entry disappears into a report

997
00:37:52,080 --> 00:37:53,840
that nobody at the line ever sees again.

998
00:37:53,840 --> 00:37:56,800
They need to see that a repeated issue triggered a check

999
00:37:56,800 --> 00:37:58,560
that a note led to a discussion

1000
00:37:58,560 --> 00:38:01,760
and that an agreed countermeasure changed something in the process.

1001
00:38:01,760 --> 00:38:03,760
Trust grows through visible response.

1002
00:38:03,760 --> 00:38:07,200
Think about the difference between asking someone to log a recurring jam

1003
00:38:07,200 --> 00:38:09,920
and returning the next shift with a clear finding.

1004
00:38:09,920 --> 00:38:11,440
We checked the last 10 events.

1005
00:38:11,440 --> 00:38:13,360
They all followed the same product transition

1006
00:38:13,360 --> 00:38:16,320
and the guide adjustment is now part of the setup check.

1007
00:38:16,320 --> 00:38:18,800
That doesn't promise the problem has vanished.

1008
00:38:18,800 --> 00:38:21,360
It shows that the entry became part of the learning loop.

1009
00:38:21,360 --> 00:38:24,000
That's a much better reason to record the next event carefully.

1010
00:38:24,000 --> 00:38:26,080
The shop floor also keeps improvement honest.

1011
00:38:26,080 --> 00:38:29,200
Data attempts a team to talk only about what fits into a field,

1012
00:38:29,200 --> 00:38:30,960
a timestamp or a chart.

1013
00:38:30,960 --> 00:38:33,920
But the people doing the work can point out the missing condition.

1014
00:38:33,920 --> 00:38:36,720
They can say the stop was planned but recorded as unplanned.

1015
00:38:36,720 --> 00:38:39,680
They can explain why a standard method wasn't safe or practical

1016
00:38:39,680 --> 00:38:41,040
during a particular run.

1017
00:38:41,040 --> 00:38:43,200
They can spot when a clean looking report conflicts

1018
00:38:43,200 --> 00:38:45,840
with the actual process that challenges healthy.

1019
00:38:45,840 --> 00:38:48,400
Continuous improvement needs structured facts

1020
00:38:48,400 --> 00:38:50,800
but it also needs a way for people to correct the story.

1021
00:38:50,800 --> 00:38:52,080
Those facts appear to tell.

1022
00:38:52,080 --> 00:38:56,240
The best setup doesn't force operators to become full-time data clerks

1023
00:38:56,240 --> 00:38:59,280
and it doesn't ask engineers to guess what happened from a distance.

1024
00:38:59,280 --> 00:39:01,120
It gives each person a useful role.

1025
00:39:01,120 --> 00:39:04,320
Operators and supervisors capture what the systems can't sense.

1026
00:39:04,320 --> 00:39:07,520
Maintenance and quality add their view of equipment and product conditions.

1027
00:39:07,520 --> 00:39:10,160
Engineers connect those observations to recurring patterns.

1028
00:39:10,160 --> 00:39:13,680
Then the result returns to the work as a better standard, a better check

1029
00:39:13,680 --> 00:39:15,600
or a clearer question for the next cycle.

1030
00:39:15,600 --> 00:39:18,240
But that only works if people can trust the shared record.

1031
00:39:18,240 --> 00:39:21,760
When the ERP, MS, machine historian and local spreadsheet

1032
00:39:21,760 --> 00:39:24,240
all describe the same shift in different ways,

1033
00:39:24,240 --> 00:39:27,280
the team spends its time debating which number to believe

1034
00:39:27,280 --> 00:39:29,440
instead of improving the process.

1035
00:39:29,440 --> 00:39:30,560
When systems disagree.

1036
00:39:30,560 --> 00:39:32,640
The trouble gets harder

1037
00:39:32,640 --> 00:39:35,600
when each system tells a slightly different story about the same work.

1038
00:39:35,600 --> 00:39:38,960
Your ERP might identify a machine by a planning work center code.

1039
00:39:38,960 --> 00:39:41,360
The MES uses a production resource name.

1040
00:39:41,360 --> 00:39:44,160
Maintenance refers to the asset number stamped on the machine

1041
00:39:44,160 --> 00:39:46,880
while the historian collects signals under a controller tag

1042
00:39:46,880 --> 00:39:48,880
created years ago by an integrator.

1043
00:39:48,880 --> 00:39:50,240
Everyone means the same machine,

1044
00:39:50,240 --> 00:39:51,840
yet the records don't join cleanly.

1045
00:39:51,840 --> 00:39:53,200
That sounds like a technical nuisance

1046
00:39:53,200 --> 00:39:55,520
until a lean team tries to investigate a repeated loss.

1047
00:39:55,520 --> 00:39:58,080
Someone pulls downtime from the MES.

1048
00:39:58,080 --> 00:39:59,920
Maintenance history from another system

1049
00:39:59,920 --> 00:40:01,680
and ordered data from ERP.

1050
00:40:01,680 --> 00:40:04,160
The team then spends half the meeting asking whether line 12,

1051
00:40:04,160 --> 00:40:06,640
packet 12, asset 00481

1052
00:40:06,640 --> 00:40:10,400
and the PLC tag pk_12 all refer to the same physical resource.

1053
00:40:10,400 --> 00:40:13,600
Sometimes they do, sometimes one name refers to the full line

1054
00:40:13,600 --> 00:40:16,000
and another refers only to the filler inside it.

1055
00:40:16,000 --> 00:40:19,200
A report can't solve that by making the labels look similar.

1056
00:40:19,200 --> 00:40:21,840
The team needs to know what each label actually represents.

1057
00:40:21,840 --> 00:40:23,520
Time creates the same kind of problem.

1058
00:40:23,520 --> 00:40:26,000
ERP groups work around a planned shift boundary.

1059
00:40:26,000 --> 00:40:29,120
MES records an operation when an operator confirms it.

1060
00:40:29,120 --> 00:40:32,160
The historian logs a machine event at the moment it happens.

1061
00:40:32,160 --> 00:40:34,800
Quality records a result after a sample reaches the lab.

1062
00:40:34,800 --> 00:40:36,320
Those timestamps can all be correct.

1063
00:40:36,320 --> 00:40:38,080
They just describe different moments.

1064
00:40:38,080 --> 00:40:41,200
Consider a batch that completes on the line late in the afternoon.

1065
00:40:41,200 --> 00:40:44,320
The MES records the produced quantity and closes the operation.

1066
00:40:44,320 --> 00:40:45,920
ERP now sees the order as complete

1067
00:40:45,920 --> 00:40:47,760
from a production posting point of view.

1068
00:40:47,760 --> 00:40:50,880
But quality holds the batch because an inspection result hasn't cleared.

1069
00:40:50,880 --> 00:40:52,560
Production thinks the order is done.

1070
00:40:52,560 --> 00:40:54,560
Quality sees product that can't move.

1071
00:40:54,560 --> 00:40:57,760
Planning sees a completed order that may still threaten the shipment.

1072
00:40:57,760 --> 00:41:00,960
Nobody needs to be wrong for the factory to face a real problem.

1073
00:41:00,960 --> 00:41:04,000
If a daily performance report counts that batch as good output

1074
00:41:04,000 --> 00:41:06,480
while the delivery report counts it as unavailable,

1075
00:41:06,480 --> 00:41:09,680
a continuous improvement team can easily start with the wrong condition.

1076
00:41:09,680 --> 00:41:12,000
They may look for a line loss when the actual delay

1077
00:41:12,000 --> 00:41:14,960
sits in the handoff between production completion and quality release.

1078
00:41:14,960 --> 00:41:16,880
The same issue appears in downtime.

1079
00:41:16,880 --> 00:41:20,960
A machine state changes to stop at the exact time a sensor detects no movement.

1080
00:41:20,960 --> 00:41:24,400
The MES begins downtime only when an operator selects a reason code.

1081
00:41:24,400 --> 00:41:27,040
A supervisor classifies the event after the shift.

1082
00:41:27,040 --> 00:41:31,200
Once they know whether the stop belonged to a planned changeover or an equipment fault.

1083
00:41:31,200 --> 00:41:32,480
Each record has a purpose.

1084
00:41:32,480 --> 00:41:36,080
Problems begin when people compare them as though they measure the same thing.

1085
00:41:36,080 --> 00:41:39,840
Spreadsheets often hide this disagreement because somebody quietly fixes it.

1086
00:41:39,840 --> 00:41:42,560
They adjust a timestamp, rename a resource,

1087
00:41:42,560 --> 00:41:44,400
remove an event that doesn't look right,

1088
00:41:44,400 --> 00:41:46,480
or add a manual note to explain a gap.

1089
00:41:46,480 --> 00:41:49,520
The report then looks tidy enough for the morning meeting.

1090
00:41:49,520 --> 00:41:51,760
But the reconciliation work hasn't disappeared.

1091
00:41:51,760 --> 00:41:53,360
It's moved into one person's head.

1092
00:41:53,360 --> 00:41:55,360
That creates a fragile improvement process.

1093
00:41:55,360 --> 00:41:58,400
If the person who understands the adjustments changes role takes leave

1094
00:41:58,400 --> 00:42:02,800
or simply runs out of time, the next report tells a different story without anyone noticing why.

1095
00:42:02,800 --> 00:42:04,320
You can see the effect in meetings.

1096
00:42:04,320 --> 00:42:06,480
One person says the line lost 40 minutes.

1097
00:42:06,480 --> 00:42:09,280
Another says the machine only stopped for 25.

1098
00:42:09,280 --> 00:42:12,720
A third points out that the lost time occurred during a planned product switch,

1099
00:42:12,720 --> 00:42:15,360
so neither figure describes the question they actually need to answer.

1100
00:42:15,360 --> 00:42:16,800
People then argue over the number.

1101
00:42:16,800 --> 00:42:18,960
The better question is what each number means.

1102
00:42:18,960 --> 00:42:20,960
This isn't a dashboard formatting problem.

1103
00:42:20,960 --> 00:42:22,160
It's a factory model problem.

1104
00:42:22,160 --> 00:42:24,320
A dashboard can present the information clearly,

1105
00:42:24,320 --> 00:42:27,920
but it can't decide whether an order completion means production complete,

1106
00:42:27,920 --> 00:42:29,920
quality released, packed or shipped.

1107
00:42:29,920 --> 00:42:33,040
It can't infer whether a resource code refers to a whole line,

1108
00:42:33,040 --> 00:42:35,120
one station, or a shared tool.

1109
00:42:35,120 --> 00:42:39,600
And it can't safely guess whether two events from separate systems belong to the same production incident,

1110
00:42:39,600 --> 00:42:41,280
someone needs to define those links.

1111
00:42:41,280 --> 00:42:44,320
That doesn't mean forcing every department to abandon its own terms.

1112
00:42:44,320 --> 00:42:46,800
Production, maintenance, quality, and planning,

1113
00:42:46,800 --> 00:42:48,880
each need language that fits their work.

1114
00:42:48,880 --> 00:42:51,440
The aim is to create enough shared reference points

1115
00:42:51,440 --> 00:42:55,360
so people can connect records without pretending every record has the same purpose.

1116
00:42:55,360 --> 00:42:57,360
For a specific improvement question,

1117
00:42:57,360 --> 00:43:00,640
agree on the resource in scope, the order or batch in scope,

1118
00:43:00,640 --> 00:43:04,480
the event boundaries, and the rule for deciding when output counts.

1119
00:43:04,480 --> 00:43:06,720
Put those rules where the team can find them.

1120
00:43:06,720 --> 00:43:09,200
Not only in the memory of the person who built the report,

1121
00:43:09,200 --> 00:43:11,040
then challenge them when the process changes,

1122
00:43:11,040 --> 00:43:12,240
because it will change.

1123
00:43:12,240 --> 00:43:13,680
Equipment gets modified.

1124
00:43:13,680 --> 00:43:15,680
Roots shift, new products arrive.

1125
00:43:15,680 --> 00:43:19,280
An old machine might gain a new controller while keeping the same asset number.

1126
00:43:19,280 --> 00:43:24,160
Exactly the sort of detail that can create a very confident and completely misleading trend line.

1127
00:43:24,160 --> 00:43:26,560
Continuous improvement depends on shared facts.

1128
00:43:26,560 --> 00:43:29,200
Shared facts don't appear just because systems connect.

1129
00:43:29,200 --> 00:43:32,240
They appear when the factory agrees on what its records refer to

1130
00:43:32,240 --> 00:43:34,720
and keeps that agreement current as work changes.

1131
00:43:34,720 --> 00:43:38,240
The next step is building that shared factory language into the data itself.

1132
00:43:38,240 --> 00:43:40,400
The data model behind continuous improvement.

1133
00:43:40,400 --> 00:43:43,200
Here's a problem I see all the time.

1134
00:43:43,200 --> 00:43:46,320
A team sits in a meeting, agrees on what a line stop means,

1135
00:43:46,320 --> 00:43:49,120
shakes hands, and then everyone goes back to their desks.

1136
00:43:49,120 --> 00:43:52,560
Then somebody opens a report and the MES count stops one way

1137
00:43:52,560 --> 00:43:54,240
while the maintenance log counts another.

1138
00:43:54,240 --> 00:43:57,120
The shared language evaporated the second people started typing.

1139
00:43:57,120 --> 00:43:59,920
What you actually need is a data model that carries those definitions

1140
00:43:59,920 --> 00:44:01,520
through the systems people use every day.

1141
00:44:01,520 --> 00:44:04,720
Think about the data model as a set of rules that let a production event

1142
00:44:04,720 --> 00:44:07,600
keep its meaning as it moves from the machine through the mess,

1143
00:44:07,600 --> 00:44:09,920
into planning, quality, maintenance,

1144
00:44:09,920 --> 00:44:11,600
and eventually into improvement work.

1145
00:44:11,600 --> 00:44:15,040
Without those rules, every new question starts with the same old step.

1146
00:44:15,040 --> 00:44:16,000
Clean up.

1147
00:44:16,000 --> 00:44:18,880
You spend half the meeting arguing about what happened

1148
00:44:18,880 --> 00:44:21,120
instead of figuring out what to do about it.

1149
00:44:21,120 --> 00:44:22,160
Start with identity.

1150
00:44:22,160 --> 00:44:23,920
A product needs a common identifier.

1151
00:44:23,920 --> 00:44:27,120
So does a process step, a work order, a batch, a resource, and a shift.

1152
00:44:27,120 --> 00:44:30,720
Those identifiers don't need to replace every local code in every system.

1153
00:44:30,720 --> 00:44:32,880
They need a managed relationship between them.

1154
00:44:32,880 --> 00:44:35,680
If a production planner calls a resource line three,

1155
00:44:35,680 --> 00:44:38,160
the MES calls it line zero three,

1156
00:44:38,160 --> 00:44:40,800
and maintenance tracks three separate assets inside it.

1157
00:44:40,800 --> 00:44:43,200
The model needs to state how those things relate.

1158
00:44:43,200 --> 00:44:44,800
Is line three the full production line?

1159
00:44:44,800 --> 00:44:46,640
Which asset performs the filling operation?

1160
00:44:46,640 --> 00:44:48,400
Which one controls the label application?

1161
00:44:48,400 --> 00:44:50,320
What does the schedule actually reserve?

1162
00:44:50,320 --> 00:44:53,280
That level of detail lets a team ask a real question

1163
00:44:53,280 --> 00:44:55,920
without rebuilding the context every single time.

1164
00:44:55,920 --> 00:44:57,200
The same applies to products.

1165
00:44:57,200 --> 00:45:00,000
A finished goods code may describe what ships to the customer,

1166
00:45:00,000 --> 00:45:03,040
but a recipe, pack format, toolset, and material batch

1167
00:45:03,040 --> 00:45:05,360
all describe conditions that affect the work.

1168
00:45:05,360 --> 00:45:06,480
For some improvement questions,

1169
00:45:06,480 --> 00:45:08,640
the finished goods code gives enough detail.

1170
00:45:08,640 --> 00:45:11,200
For others, it hides the difference that explains the loss.

1171
00:45:11,200 --> 00:45:14,080
A good data model supports both levels

1172
00:45:14,080 --> 00:45:16,720
without forcing people to guess which one they need.

1173
00:45:16,720 --> 00:45:18,880
Relationships matter just as much as names.

1174
00:45:18,880 --> 00:45:20,960
I've seen improvement work fail time and again

1175
00:45:20,960 --> 00:45:23,280
because the records tell you several things happened,

1176
00:45:23,280 --> 00:45:24,480
but they don't connect.

1177
00:45:24,480 --> 00:45:26,560
You need to know which product followed which route.

1178
00:45:26,560 --> 00:45:28,960
You need to know which operation ran on which resource.

1179
00:45:28,960 --> 00:45:31,760
You may need to know which tool, recipe, material, batch,

1180
00:45:31,760 --> 00:45:34,080
or maintenance condition applied during that operation.

1181
00:45:34,080 --> 00:45:36,640
And you need to link the outcome back to those conditions.

1182
00:45:36,640 --> 00:45:39,120
In practical terms, that means a reject record

1183
00:45:39,120 --> 00:45:41,360
should not float alone in a quality table.

1184
00:45:41,360 --> 00:45:43,600
It should link back to the order or batch,

1185
00:45:43,600 --> 00:45:45,200
the operation, the resource,

1186
00:45:45,200 --> 00:45:46,960
and the relevant production window.

1187
00:45:46,960 --> 00:45:50,000
A downtime event should connect to the resource and time period

1188
00:45:50,000 --> 00:45:53,200
then join to the order and operating state where the loss occurred.

1189
00:45:53,200 --> 00:45:56,640
Those links let a team test to hypothesis with a lot less guesswork.

1190
00:45:56,640 --> 00:45:58,400
Time leads the same attention.

1191
00:45:58,400 --> 00:46:00,400
Factories often store plenty of timestamps,

1192
00:46:00,400 --> 00:46:02,960
but they don't always distinguish what each one means.

1193
00:46:02,960 --> 00:46:05,680
Plan start time, actual start time, machine event time,

1194
00:46:05,680 --> 00:46:07,200
operator confirmation time.

1195
00:46:07,200 --> 00:46:08,560
They also add next to each other,

1196
00:46:08,560 --> 00:46:10,320
but they answer very different questions.

1197
00:46:10,320 --> 00:46:12,720
A planner needs planned and actual start times

1198
00:46:12,720 --> 00:46:14,640
to understand scheduled performance.

1199
00:46:14,640 --> 00:46:17,200
A process engineer needs the exact machine event time

1200
00:46:17,200 --> 00:46:18,720
to study a short stop.

1201
00:46:18,720 --> 00:46:21,040
A lean team testing a revised work method needs to know

1202
00:46:21,040 --> 00:46:22,240
when that method started,

1203
00:46:22,240 --> 00:46:24,000
which runs fell inside the trial period

1204
00:46:24,000 --> 00:46:26,000
and when the team changed it again.

1205
00:46:26,000 --> 00:46:29,360
If the model treats all time stamps as one generic date and time field,

1206
00:46:29,360 --> 00:46:31,600
the evidence gets slippery really fast.

1207
00:46:31,600 --> 00:46:33,600
Definitions also need a home in the model.

1208
00:46:33,600 --> 00:46:36,800
Down time, scrap, rework, good count, and target rate

1209
00:46:36,800 --> 00:46:40,240
should each have a clear rule tied to the question people need to answer.

1210
00:46:40,240 --> 00:46:41,280
Take good count.

1211
00:46:41,280 --> 00:46:43,040
Does it mean units leaving the machine?

1212
00:46:43,040 --> 00:46:44,320
Units that passed inspection?

1213
00:46:44,320 --> 00:46:45,920
Units packed and ready for shipment?

1214
00:46:45,920 --> 00:46:47,760
All of those measures can be useful,

1215
00:46:47,760 --> 00:46:49,360
but they should not share one label

1216
00:46:49,360 --> 00:46:51,920
and quietly mean different things in different reports.

1217
00:46:51,920 --> 00:46:54,080
The same problem appears with target rate.

1218
00:46:54,080 --> 00:46:56,560
A line may have one standard speed for a simple product

1219
00:46:56,560 --> 00:46:58,560
and another for a difficult format.

1220
00:46:58,560 --> 00:47:00,240
If the model ignores that difference,

1221
00:47:00,240 --> 00:47:02,480
a performance loss appears even when the line ran

1222
00:47:02,480 --> 00:47:04,720
exactly as the approved process required.

1223
00:47:04,720 --> 00:47:06,400
Definitions need versioning too.

1224
00:47:06,400 --> 00:47:07,680
A process doesn't freeze.

1225
00:47:07,680 --> 00:47:10,160
New products arrive, tools change,

1226
00:47:10,160 --> 00:47:12,000
engineering updates, recipes,

1227
00:47:12,000 --> 00:47:14,000
maintenance replaces major components.

1228
00:47:14,000 --> 00:47:16,640
The model needs to preserve which version of the process,

1229
00:47:16,640 --> 00:47:17,920
standard or target,

1230
00:47:17,920 --> 00:47:19,440
applied at the time of the event.

1231
00:47:19,440 --> 00:47:22,720
Without that, people compare last month's production against today's rules

1232
00:47:22,720 --> 00:47:24,000
and call the difference a trend.

1233
00:47:24,000 --> 00:47:26,480
This is where master data ownership comes into the picture.

1234
00:47:26,480 --> 00:47:28,960
Somebody needs responsibility for product structures,

1235
00:47:28,960 --> 00:47:31,360
rooting relationships, resource hierarchies,

1236
00:47:31,360 --> 00:47:32,320
approved rates,

1237
00:47:32,320 --> 00:47:34,320
and the mappings that connect systems.

1238
00:47:34,320 --> 00:47:35,920
That doesn't mean one central team

1239
00:47:35,920 --> 00:47:37,760
has to know every detail of the factory.

1240
00:47:37,760 --> 00:47:40,160
It means each type of data has a named owner,

1241
00:47:40,160 --> 00:47:41,200
a change process,

1242
00:47:41,200 --> 00:47:43,200
and a way to check the effect downstream.

1243
00:47:43,200 --> 00:47:44,880
When a new tool enters production,

1244
00:47:44,880 --> 00:47:47,840
who links it to the resources and product transitions it affects.

1245
00:47:47,840 --> 00:47:50,240
When a work center splits into two physical stations,

1246
00:47:50,240 --> 00:47:52,320
who updates the relationship used by planning,

1247
00:47:52,320 --> 00:47:54,160
MES, maintenance, and reporting.

1248
00:47:54,160 --> 00:47:55,680
If nobody owns those changes,

1249
00:47:55,680 --> 00:47:58,160
the data model slowly drifts away from the work.

1250
00:47:58,160 --> 00:48:00,400
Then every chisin event starts with an argument

1251
00:48:00,400 --> 00:48:01,760
about the facts on the ground.

1252
00:48:01,760 --> 00:48:03,760
A useful data model doesn't need to describe

1253
00:48:03,760 --> 00:48:05,680
every part of the plant on day one.

1254
00:48:05,680 --> 00:48:07,600
It needs to describe the part of the process

1255
00:48:07,600 --> 00:48:08,800
the team wants to improve,

1256
00:48:08,800 --> 00:48:09,840
with enough identity,

1257
00:48:09,840 --> 00:48:11,440
relationship, time, and definition

1258
00:48:11,440 --> 00:48:13,200
to preserve the production story.

1259
00:48:13,200 --> 00:48:14,480
Once that structure exists,

1260
00:48:14,480 --> 00:48:17,200
PDCA can move beyond documents and action lists.

1261
00:48:17,200 --> 00:48:19,200
The improvement cycle carries its own evidence

1262
00:48:19,200 --> 00:48:21,200
from the problem statement through the trial

1263
00:48:21,200 --> 00:48:23,280
and into the decision about what happens next.

1264
00:48:23,280 --> 00:48:25,440
From PDCA documents to a data loop.

1265
00:48:25,440 --> 00:48:28,960
Once the factory has enough shared context,

1266
00:48:28,960 --> 00:48:32,000
the PDCA cycle can stop living in a document folder.

1267
00:48:32,000 --> 00:48:34,480
The improvement record becomes part of the operating record

1268
00:48:34,480 --> 00:48:36,560
connected to the work it intends to change.

1269
00:48:36,560 --> 00:48:37,680
Start with plan.

1270
00:48:37,680 --> 00:48:39,920
A team should link the issue to a measurable condition

1271
00:48:39,920 --> 00:48:41,520
and a named part of the process.

1272
00:48:41,520 --> 00:48:44,480
Not a broad statement like improved performance on line three.

1273
00:48:44,480 --> 00:48:46,800
The record needs to state where the condition appears,

1274
00:48:46,800 --> 00:48:47,760
when it appears,

1275
00:48:47,760 --> 00:48:49,360
and what the team expects to change.

1276
00:48:49,360 --> 00:48:51,440
It might refer to a defined change over sequence

1277
00:48:51,440 --> 00:48:53,920
on a named line for a certain product transition

1278
00:48:53,920 --> 00:48:55,360
during a known production window.

1279
00:48:55,360 --> 00:48:58,000
That gives the problem a location in the factory model.

1280
00:48:58,000 --> 00:49:01,040
The plan record can then point to the baseline the team chose.

1281
00:49:01,040 --> 00:49:03,760
Not a generic monthly average pulled from an old report,

1282
00:49:03,760 --> 00:49:06,560
but the actual production runs, orders, events,

1283
00:49:06,560 --> 00:49:08,960
and time range that describe the current condition.

1284
00:49:08,960 --> 00:49:11,040
Anyone reviewing the work later can trace the claim

1285
00:49:11,040 --> 00:49:12,720
back to the evidence used at the time,

1286
00:49:12,720 --> 00:49:14,560
and that changes the quality of the discussion.

1287
00:49:14,560 --> 00:49:16,640
A hypothesis belongs in the record too.

1288
00:49:16,640 --> 00:49:19,040
The team should write what it thinks causes the loss,

1289
00:49:19,040 --> 00:49:21,280
what countermeasure it intends to try,

1290
00:49:21,280 --> 00:49:23,760
and what result would support or reject that idea.

1291
00:49:23,760 --> 00:49:25,440
You don't need a huge document here.

1292
00:49:25,440 --> 00:49:27,040
A short clear statement is often better

1293
00:49:27,040 --> 00:49:28,560
because people can actually test it.

1294
00:49:28,560 --> 00:49:31,440
Then comes do, and the countermeasure needs its own context.

1295
00:49:31,440 --> 00:49:32,480
Record the scope,

1296
00:49:32,480 --> 00:49:34,480
which resource, shift, product, family,

1297
00:49:34,480 --> 00:49:36,880
work instruction, or order group did the team include,

1298
00:49:36,880 --> 00:49:39,680
who owns the trial, when does it start, and when does it change?

1299
00:49:39,680 --> 00:49:42,800
If the team applies the new method only to one set of conditions,

1300
00:49:42,800 --> 00:49:45,280
say so plainly, scope protects the evidence.

1301
00:49:45,280 --> 00:49:47,360
Without it, a later report may include runs

1302
00:49:47,360 --> 00:49:49,040
that never use the countermeasure,

1303
00:49:49,040 --> 00:49:50,400
or exclude runs where it did,

1304
00:49:50,400 --> 00:49:52,080
the team compares mixed populations

1305
00:49:52,080 --> 00:49:53,680
and calls the result inconclusive

1306
00:49:53,680 --> 00:49:55,600
when the real issue is that nobody captured

1307
00:49:55,600 --> 00:49:57,120
where the trial applied.

1308
00:49:57,120 --> 00:49:59,920
A data loop also records changes as they happen.

1309
00:49:59,920 --> 00:50:01,600
If a supervisor adjusts the countermeasure

1310
00:50:01,600 --> 00:50:03,760
after the first few runs, that's not a failure.

1311
00:50:03,760 --> 00:50:04,720
It's part of PDCA,

1312
00:50:04,720 --> 00:50:06,960
but the system needs to retain the first version,

1313
00:50:06,960 --> 00:50:08,240
the revised version,

1314
00:50:08,240 --> 00:50:10,400
and the date each version entered production.

1315
00:50:10,400 --> 00:50:12,640
Otherwise the check period becomes hard to interpret.

1316
00:50:12,640 --> 00:50:13,920
Now consider check.

1317
00:50:13,920 --> 00:50:15,360
The team should define a baseline

1318
00:50:15,360 --> 00:50:17,520
and a control period before looking at the result.

1319
00:50:17,520 --> 00:50:20,160
The baseline describes the condition before the trial.

1320
00:50:20,160 --> 00:50:22,560
The control period captures comparable production

1321
00:50:22,560 --> 00:50:24,160
after the trial began.

1322
00:50:24,160 --> 00:50:26,080
Comparable doesn't mean identical.

1323
00:50:26,080 --> 00:50:28,080
Factories rarely give you that luxury.

1324
00:50:28,080 --> 00:50:29,840
It means the team uses agreed rules

1325
00:50:29,840 --> 00:50:31,520
for which runs belong in each group

1326
00:50:31,520 --> 00:50:34,480
and then checks the actual result against the expected result.

1327
00:50:34,480 --> 00:50:36,960
The comparison can update automatically as MES events,

1328
00:50:36,960 --> 00:50:39,280
quality outcomes, and approved machine data arrive.

1329
00:50:39,280 --> 00:50:41,760
But automation should not quietly decide the conclusion.

1330
00:50:41,760 --> 00:50:44,080
People still need to ask whether an unusual order mix

1331
00:50:44,080 --> 00:50:45,680
a maintenance event, a missing record,

1332
00:50:45,680 --> 00:50:47,920
or a process change affected the comparison.

1333
00:50:47,920 --> 00:50:49,840
The report should expose those conditions,

1334
00:50:49,840 --> 00:50:51,920
not bury them under one green number.

1335
00:50:51,920 --> 00:50:54,240
A useful check view lets the team move from the measure

1336
00:50:54,240 --> 00:50:55,440
to the affected runs,

1337
00:50:55,440 --> 00:50:58,160
then back to the evidence and the notes attached to those runs.

1338
00:50:58,160 --> 00:50:59,760
That makes review faster,

1339
00:50:59,760 --> 00:51:02,000
without turning it into blind trust in the dashboard.

1340
00:51:02,000 --> 00:51:04,000
If the result supports the hypothesis,

1341
00:51:04,000 --> 00:51:06,000
act moves the change into normal work.

1342
00:51:06,000 --> 00:51:07,760
The team may update standard work,

1343
00:51:07,760 --> 00:51:10,320
revise a setup checklist, change a planning rule,

1344
00:51:10,320 --> 00:51:12,400
or extend the method to another resource.

1345
00:51:12,400 --> 00:51:14,800
Each decision needs a clear status and effective date.

1346
00:51:14,800 --> 00:51:17,360
The factory should know whether the countermeasure remains a trial,

1347
00:51:17,360 --> 00:51:18,640
became the approved method,

1348
00:51:18,640 --> 00:51:20,240
applies only in a narrow context,

1349
00:51:20,240 --> 00:51:21,440
or has been withdrawn.

1350
00:51:21,440 --> 00:51:22,960
Withdrawal deserves a record too,

1351
00:51:22,960 --> 00:51:25,440
when evidence shows a countermeasure doesn't work,

1352
00:51:25,440 --> 00:51:27,360
or creates an unwanted side effect,

1353
00:51:27,360 --> 00:51:30,080
reversing it is a sound engineering decision.

1354
00:51:30,080 --> 00:51:33,120
A closed action should not mean never discuss this again.

1355
00:51:33,120 --> 00:51:35,120
It should mean the team can see the decision,

1356
00:51:35,120 --> 00:51:36,320
the evidence behind it,

1357
00:51:36,320 --> 00:51:38,400
and the condition under which it was taken.

1358
00:51:38,400 --> 00:51:39,760
That history matters,

1359
00:51:39,760 --> 00:51:41,840
when the same loss returns months later.

1360
00:51:41,840 --> 00:51:43,840
Instead of starting from a blank action tracker,

1361
00:51:43,840 --> 00:51:46,000
the next team can find prior hypotheses,

1362
00:51:46,000 --> 00:51:48,720
see what people tested, inspect the production conditions,

1363
00:51:48,720 --> 00:51:50,880
and decide whether the old result still applies.

1364
00:51:50,880 --> 00:51:53,280
Maybe the prior countermeasure failed

1365
00:51:53,280 --> 00:51:55,760
because of a product format that no longer runs.

1366
00:51:55,760 --> 00:51:58,640
Maybe it worked until a new tool changed the setup process.

1367
00:51:58,640 --> 00:52:01,520
The improvement record remembers what the slide deck forgets.

1368
00:52:01,520 --> 00:52:03,520
This does not require every kies in action

1369
00:52:03,520 --> 00:52:05,200
to become a complex software project.

1370
00:52:05,200 --> 00:52:07,520
A small loop can begin with a disciplined record,

1371
00:52:07,520 --> 00:52:08,960
a few linked data points,

1372
00:52:08,960 --> 00:52:11,120
and a routine that reviews them at the right time,

1373
00:52:11,120 --> 00:52:13,600
but the record must stay attached to the process.

1374
00:52:13,600 --> 00:52:14,560
When it does,

1375
00:52:14,560 --> 00:52:17,200
PDCA becomes more than plan due check act,

1376
00:52:17,200 --> 00:52:18,560
written on a workshop board.

1377
00:52:18,560 --> 00:52:20,160
It becomes a chain of evidence,

1378
00:52:20,160 --> 00:52:22,080
a condition, a tested response,

1379
00:52:22,080 --> 00:52:23,360
an observed result,

1380
00:52:23,360 --> 00:52:25,520
and a decision that production can carry forward.

1381
00:52:25,520 --> 00:52:28,240
Scenario reducing change over loss.

1382
00:52:29,360 --> 00:52:32,400
Here's a scenario that most manufacturing teams have lived through.

1383
00:52:32,400 --> 00:52:35,120
You've got a packaging line running several product formats

1384
00:52:35,120 --> 00:52:36,240
and the schedule is tight.

1385
00:52:36,240 --> 00:52:38,480
Every change over window matters.

1386
00:52:38,480 --> 00:52:40,080
Changes over should be predictable,

1387
00:52:40,080 --> 00:52:43,200
but some fly by while others blow the next order out of the water.

1388
00:52:43,200 --> 00:52:45,840
The plant already ran kies and events on the problem.

1389
00:52:45,840 --> 00:52:47,840
Teams mapped setup steps,

1390
00:52:47,840 --> 00:52:49,920
moved tools closer to the line,

1391
00:52:49,920 --> 00:52:51,200
and updated a checklist.

1392
00:52:51,200 --> 00:52:53,760
For a while it felt like progress.

1393
00:52:53,760 --> 00:52:55,840
Then missed schedule windows came back.

1394
00:52:55,840 --> 00:52:57,600
The team came up with a better question,

1395
00:52:57,600 --> 00:52:59,760
instead of how do we reduce change over time?

1396
00:52:59,760 --> 00:53:02,400
They started asking why the same line,

1397
00:53:02,400 --> 00:53:04,400
changing between the same product families,

1398
00:53:04,400 --> 00:53:07,200
performs so differently from one change over to the next.

1399
00:53:07,200 --> 00:53:09,360
That shift in wording changes everything.

1400
00:53:09,360 --> 00:53:10,480
On a walk through the line,

1401
00:53:10,480 --> 00:53:11,840
the team spots a common delay.

1402
00:53:11,840 --> 00:53:14,160
Operators start hunting for tools

1403
00:53:14,160 --> 00:53:15,760
after the previous order finishes.

1404
00:53:15,760 --> 00:53:16,880
Some tools are staged,

1405
00:53:16,880 --> 00:53:18,000
some are laid from cleaning,

1406
00:53:18,000 --> 00:53:21,200
and sometimes the setup instruction doesn't even say which version they need.

1407
00:53:21,200 --> 00:53:23,040
So the team forms a hypothesis.

1408
00:53:23,040 --> 00:53:25,840
If they identify, check and stage the next tool set

1409
00:53:25,840 --> 00:53:27,600
before the current order ends.

1410
00:53:27,600 --> 00:53:30,800
The gap between last good unit and stable output should shrink.

1411
00:53:30,800 --> 00:53:33,200
They also expect fewer rushed adjustments on startup.

1412
00:53:33,200 --> 00:53:34,080
That's the plan,

1413
00:53:34,080 --> 00:53:36,000
but they don't roll it out everywhere at once.

1414
00:53:36,000 --> 00:53:39,600
They start with a specific set of product transitions on one line,

1415
00:53:39,600 --> 00:53:41,680
recording the date, the sequence,

1416
00:53:41,680 --> 00:53:43,680
and who's responsible for staging.

1417
00:53:43,680 --> 00:53:45,520
The paper checklist might still be there.

1418
00:53:45,520 --> 00:53:46,720
That's not the issue.

1419
00:53:46,720 --> 00:53:48,720
The difference is that the checklist now links

1420
00:53:48,720 --> 00:53:50,480
to actual production evidence.

1421
00:53:50,480 --> 00:53:52,560
The ERP record gives the plant sequence

1422
00:53:52,560 --> 00:53:53,760
what came before and after,

1423
00:53:53,760 --> 00:53:54,880
planned quantity,

1424
00:53:54,880 --> 00:53:57,280
and whether the planner changed the sequence near shift start,

1425
00:53:57,280 --> 00:53:58,800
that's critical because a last minute

1426
00:53:58,800 --> 00:54:00,400
sequence can kill the staging window

1427
00:54:00,400 --> 00:54:01,920
even if the method is solid.

1428
00:54:01,920 --> 00:54:04,160
MES adds the execution trail.

1429
00:54:04,160 --> 00:54:05,680
When the prior order closed,

1430
00:54:05,680 --> 00:54:06,720
when the next started,

1431
00:54:06,720 --> 00:54:08,240
when accepted output came through,

1432
00:54:08,240 --> 00:54:10,000
they can trace rejects, holes,

1433
00:54:10,000 --> 00:54:11,600
and rework during restart,

1434
00:54:11,600 --> 00:54:13,760
which lets them separate a short mechanical setup

1435
00:54:13,760 --> 00:54:16,560
from a long recovery after the machine starts moving.

1436
00:54:16,560 --> 00:54:18,320
Machine states at the physical detail,

1437
00:54:18,320 --> 00:54:20,160
the line might idle, run a few cycles,

1438
00:54:20,160 --> 00:54:21,760
stop on an alarm, restart,

1439
00:54:21,760 --> 00:54:23,360
then crawl while operators adjust.

1440
00:54:23,360 --> 00:54:25,680
If the team only measures time to first cycle,

1441
00:54:25,680 --> 00:54:27,680
they might claim success while the factory is still

1442
00:54:27,680 --> 00:54:29,520
losing output in that early ramp.

1443
00:54:29,520 --> 00:54:31,840
Stable output is the condition that really matters.

1444
00:54:31,840 --> 00:54:33,520
Operator observations rounded out,

1445
00:54:33,520 --> 00:54:35,200
maybe one crew says staging works

1446
00:54:35,200 --> 00:54:36,960
when the tool cart returns on time,

1447
00:54:36,960 --> 00:54:39,760
but falls apart when a tool needs an extra inspection.

1448
00:54:39,760 --> 00:54:41,920
Another crew reports that the instruction lists

1449
00:54:41,920 --> 00:54:43,120
the right tool family,

1450
00:54:43,120 --> 00:54:46,000
but not the exact insert for a certain package size.

1451
00:54:46,000 --> 00:54:47,680
Those notes don't replace the records,

1452
00:54:47,680 --> 00:54:49,040
they explain patterns in them.

1453
00:54:49,040 --> 00:54:51,440
After enough trials, don't just look at the average,

1454
00:54:51,440 --> 00:54:53,680
it can look good while hiding a new problem.

1455
00:54:53,680 --> 00:54:55,760
Break results down by product family, crew,

1456
00:54:55,760 --> 00:54:57,440
tool type, and maintenance condition,

1457
00:54:57,440 --> 00:54:58,640
where you have the data.

1458
00:54:58,640 --> 00:55:00,480
Maybe the new routine helps standard tools,

1459
00:55:00,480 --> 00:55:02,000
but not precision adjustments.

1460
00:55:02,000 --> 00:55:03,760
Maybe it works on day shift because staging

1461
00:55:03,760 --> 00:55:04,880
is someone's clear job,

1462
00:55:04,880 --> 00:55:06,720
but night shift has a different handover.

1463
00:55:06,720 --> 00:55:08,480
Or maybe long changeovers cluster

1464
00:55:08,480 --> 00:55:10,400
after a tool comes back from maintenance.

1465
00:55:10,400 --> 00:55:11,920
That points to tool readiness,

1466
00:55:11,920 --> 00:55:13,200
not operator behavior.

1467
00:55:13,200 --> 00:55:14,320
That's why context matters.

1468
00:55:14,320 --> 00:55:16,080
Now take a result that looks like a win.

1469
00:55:16,080 --> 00:55:17,440
Average changeover time drops,

1470
00:55:17,440 --> 00:55:19,040
and the team is ready to standardize.

1471
00:55:19,040 --> 00:55:22,480
But quality records show increased rejects after restart

1472
00:55:22,480 --> 00:55:23,600
for one product family.

1473
00:55:23,600 --> 00:55:24,800
The line starts sooner,

1474
00:55:24,800 --> 00:55:26,720
but it doesn't reach stable production sooner.

1475
00:55:26,720 --> 00:55:28,400
A rushed setup might leave a guide rail

1476
00:55:28,400 --> 00:55:29,920
or a ceiling parameter off.

1477
00:55:29,920 --> 00:55:32,720
The first units run, then inspection catches the fault.

1478
00:55:32,720 --> 00:55:34,880
If the team celebrates only the setup time drop,

1479
00:55:34,880 --> 00:55:37,280
they've just shifted loss from availability to quality.

1480
00:55:37,280 --> 00:55:38,400
That's not improvement.

1481
00:55:38,400 --> 00:55:40,160
The check step needs both metrics.

1482
00:55:40,160 --> 00:55:42,080
Changeover time, time to stable speed,

1483
00:55:42,080 --> 00:55:44,720
and units reworked or rejected after restart.

1484
00:55:44,720 --> 00:55:47,360
Broken down by format, crew, and tool condition.

1485
00:55:47,360 --> 00:55:48,880
Once they can answer those questions,

1486
00:55:48,880 --> 00:55:50,400
they can tune the countermeasure.

1487
00:55:50,400 --> 00:55:52,720
Maybe keep staging and add a verification step

1488
00:55:52,720 --> 00:55:54,000
for certain formats,

1489
00:55:54,000 --> 00:55:56,560
or maybe staging only fixes part of the loss.

1490
00:55:56,560 --> 00:55:59,040
And tool maintenance needs its own PDCA cycle.

1491
00:55:59,040 --> 00:56:00,560
Either way, the plant moves forward

1492
00:56:00,560 --> 00:56:01,760
because they learned from production,

1493
00:56:01,760 --> 00:56:03,200
not from a whiteboard session.

1494
00:56:03,200 --> 00:56:04,400
And notice what happened here.

1495
00:56:04,400 --> 00:56:06,400
They didn't need every machine tag in the plant

1496
00:56:06,400 --> 00:56:07,840
or a massive data program.

1497
00:56:07,840 --> 00:56:09,600
They needed a small connected record

1498
00:56:09,600 --> 00:56:11,600
around one recurring loss.

1499
00:56:11,600 --> 00:56:13,760
And a way to check whether the change improved flow

1500
00:56:13,760 --> 00:56:16,000
without creating a new loss somewhere else.

1501
00:56:16,000 --> 00:56:18,640
The next challenge is that even good data can mislead

1502
00:56:18,640 --> 00:56:20,880
when you boil it down to a single average.

1503
00:56:20,880 --> 00:56:22,560
Why averages mislead lean teams?

1504
00:56:22,560 --> 00:56:24,960
Averages feel safe.

1505
00:56:24,960 --> 00:56:27,040
They compress a messy process into one number.

1506
00:56:27,040 --> 00:56:29,440
But when you treat an average as the whole story,

1507
00:56:29,440 --> 00:56:31,600
it hides the exact condition that needs attention.

1508
00:56:31,600 --> 00:56:33,280
Take the packaging line example,

1509
00:56:33,280 --> 00:56:36,400
average changeover time drops after the staging routine starts.

1510
00:56:36,400 --> 00:56:38,080
That sounds good, and it might be good.

1511
00:56:38,080 --> 00:56:40,320
But imagine most changeovers are slightly faster

1512
00:56:40,320 --> 00:56:41,840
while a few still take ages.

1513
00:56:41,840 --> 00:56:43,760
Those long ones still break the schedule.

1514
00:56:43,760 --> 00:56:47,040
If five changeovers finish on time and one takes twice as long,

1515
00:56:47,040 --> 00:56:48,320
the average looks fine.

1516
00:56:48,320 --> 00:56:50,000
But the planner still has a late order.

1517
00:56:50,000 --> 00:56:51,760
The next line still waits for material

1518
00:56:51,760 --> 00:56:54,800
and the shift supervisor still spends an hour patching the schedule.

1519
00:56:54,800 --> 00:56:57,360
The team needs to see the spread, not just the middle.

1520
00:56:57,360 --> 00:56:58,560
Ask a different question.

1521
00:56:58,560 --> 00:57:01,120
How often does a changeover blow past the window?

1522
00:57:01,120 --> 00:57:02,240
You need to protect.

1523
00:57:02,240 --> 00:57:04,880
That brings the operational consequence back into the review

1524
00:57:04,880 --> 00:57:06,320
and it helps you look for the conditions

1525
00:57:06,320 --> 00:57:07,440
around the long events.

1526
00:57:07,440 --> 00:57:09,760
Maybe they all happen after a specific product,

1527
00:57:09,760 --> 00:57:11,680
maybe after the tool comes back from maintenance,

1528
00:57:11,680 --> 00:57:13,680
maybe only when the order sequence changes late

1529
00:57:13,680 --> 00:57:15,680
and prep starts after the prior run ends.

1530
00:57:15,680 --> 00:57:17,440
The average won't show you that pattern.

1531
00:57:17,440 --> 00:57:19,120
Shift variation creates the same risk.

1532
00:57:19,120 --> 00:57:22,480
A line might show a stable average changeover time across a month,

1533
00:57:22,480 --> 00:57:25,920
but one crew consistently has longer recovery after restart.

1534
00:57:25,920 --> 00:57:28,160
That doesn't automatically mean they need more training.

1535
00:57:28,160 --> 00:57:30,400
It could be staffing, handover timing, tool access,

1536
00:57:30,400 --> 00:57:32,080
product mix, maintenance support,

1537
00:57:32,080 --> 00:57:34,240
or the sequence planning assigns to that shift.

1538
00:57:34,240 --> 00:57:36,000
A number can point fingers too quickly.

1539
00:57:36,000 --> 00:57:38,560
Treat variation is a question about process conditions.

1540
00:57:38,560 --> 00:57:40,880
Which condition changes when the result changes?

1541
00:57:40,880 --> 00:57:42,640
What accompanies the long changeovers

1542
00:57:42,640 --> 00:57:44,160
and vanishes on the short ones?

1543
00:57:44,160 --> 00:57:46,800
That's a better starting point than asking who had the worst number.

1544
00:57:46,800 --> 00:57:48,720
OEE can create the same false calm.

1545
00:57:48,720 --> 00:57:51,760
One score combines availability, performance, and quality.

1546
00:57:51,760 --> 00:57:53,680
It helps you spot that a line moved wrong,

1547
00:57:53,680 --> 00:57:56,480
but it hides how the loss shifted inside the process.

1548
00:57:56,480 --> 00:57:59,440
Say availability improves because setup time drops.

1549
00:57:59,440 --> 00:58:02,080
At the same time, quality declines after startup

1550
00:58:02,080 --> 00:58:04,560
and the line loses more units before stabilizing.

1551
00:58:04,560 --> 00:58:06,480
The combined OEE might barely change,

1552
00:58:06,480 --> 00:58:08,080
a manager sees a flat trend,

1553
00:58:08,080 --> 00:58:09,920
the crew sees a new quality issue.

1554
00:58:09,920 --> 00:58:11,920
Both views are real because the headline number

1555
00:58:11,920 --> 00:58:14,320
compress different losses into one.

1556
00:58:14,320 --> 00:58:15,680
Separate the loss modes.

1557
00:58:15,680 --> 00:58:18,560
Ask, did the line stop too often, run too slow,

1558
00:58:18,560 --> 00:58:19,840
or produce defects?

1559
00:58:19,840 --> 00:58:21,600
Then ask when each loss occurred?

1560
00:58:21,600 --> 00:58:24,240
A speed loss in the first 15 minutes after changeover

1561
00:58:24,240 --> 00:58:27,520
points to a different condition than a long unplanned stop mid-run.

1562
00:58:27,520 --> 00:58:30,320
Time sequence often tells you more than the daily total.

1563
00:58:30,320 --> 00:58:32,320
Waiting between operations works the same way.

1564
00:58:32,320 --> 00:58:33,840
Daily output might meet the plan,

1565
00:58:33,840 --> 00:58:36,880
but individual orders sit for long periods between steps.

1566
00:58:36,880 --> 00:58:38,720
The plant catches up by end of day,

1567
00:58:38,720 --> 00:58:39,840
so the total looks fine.

1568
00:58:39,840 --> 00:58:41,600
But WIP grows, priorities shift,

1569
00:58:41,600 --> 00:58:44,320
and teams spend more time chasing orders through the factory.

1570
00:58:44,320 --> 00:58:46,800
Flow suffers before the output report admits it.

1571
00:58:46,800 --> 00:58:49,600
To answer that, follow an order through time.

1572
00:58:49,600 --> 00:58:51,120
When did it finish one step?

1573
00:58:51,120 --> 00:58:52,560
When did the next start?

1574
00:58:52,560 --> 00:58:53,760
And what filled the gap?

1575
00:58:53,760 --> 00:58:55,920
A resource constrained, inspection weight,

1576
00:58:55,920 --> 00:58:58,560
missing material, dispatching rule, or late transaction,

1577
00:58:58,560 --> 00:59:00,000
each creates a different response.

1578
00:59:00,000 --> 00:59:01,520
One daily number can't answer that,

1579
00:59:01,520 --> 00:59:03,760
so when a measure moves, don't stop at the average.

1580
00:59:03,760 --> 00:59:04,720
Check the distribution.

1581
00:59:04,720 --> 00:59:07,200
Look at the long events, the short ones, the sequence,

1582
00:59:07,200 --> 00:59:09,120
and the point where variation enters.

1583
00:59:09,120 --> 00:59:11,040
Compare conditions that look similar on paper,

1584
00:59:11,040 --> 00:59:12,720
but behave differently in production.

1585
00:59:12,720 --> 00:59:14,880
The goal isn't a more complex report.

1586
00:59:14,880 --> 00:59:17,440
It's to find the condition you can actually change.

1587
00:59:17,440 --> 00:59:20,640
Improvement also needs to follow the flow of work across the factory,

1588
00:59:20,640 --> 00:59:22,320
not just the score of one asset.

1589
00:59:22,320 --> 00:59:24,240
Value stream mapping meets live data.

1590
00:59:24,240 --> 00:59:26,800
Here's the problem.

1591
00:59:26,800 --> 00:59:28,960
Most manufacturers don't talk about.

1592
00:59:28,960 --> 00:59:32,720
Value stream mapping gives a lean team a common language for flow.

1593
00:59:32,720 --> 00:59:35,920
It tracks material and information from the first customer signal

1594
00:59:35,920 --> 00:59:38,240
through planning, production, inspection, and shipment,

1595
00:59:38,240 --> 00:59:40,320
so people can see where work sits, loops back,

1596
00:59:40,320 --> 00:59:43,040
or moves without adding customer value.

1597
00:59:43,040 --> 00:59:45,840
That shared view helps, but it can go stale quickly.

1598
00:59:45,840 --> 00:59:47,600
Picture a map on a wall showing a process

1599
00:59:47,600 --> 00:59:49,840
that takes five days from release to shipment.

1600
00:59:49,840 --> 00:59:52,160
The team marked queue times between operations,

1601
00:59:52,160 --> 00:59:54,000
work in progress, inspection steps,

1602
00:59:54,000 --> 00:59:55,680
and how planning information flows

1603
00:59:55,680 --> 00:59:58,240
when they built it, everyone agreed on the big picture.

1604
00:59:58,240 --> 00:59:59,920
Then the production mix changes.

1605
00:59:59,920 --> 01:00:01,760
A supplier delivery arrives late,

1606
01:00:01,760 --> 01:00:05,040
or a planner resequences orders to protect the customer commitment.

1607
01:00:05,040 --> 01:00:07,040
The map still describes the intended flow,

1608
01:00:07,040 --> 01:00:10,000
but it can't tell the team how this week's orders actually moved.

1609
01:00:10,000 --> 01:00:12,880
That's where operational data steps into backup the map.

1610
01:00:12,880 --> 01:00:15,920
The map should stay simple enough for people from production,

1611
01:00:15,920 --> 01:00:19,040
planning, quality, and logistics to discuss it together.

1612
01:00:19,040 --> 01:00:20,720
You don't want to turn it into a technical model

1613
01:00:20,720 --> 01:00:22,400
that only a data engineer can read.

1614
01:00:22,400 --> 01:00:24,880
But behind each step, the team can connect live

1615
01:00:24,880 --> 01:00:27,120
or regularly refreshed evidence from the systems

1616
01:00:27,120 --> 01:00:28,160
that record the work.

1617
01:00:28,160 --> 01:00:30,960
A queue on the map becomes a question with evidence behind it.

1618
01:00:30,960 --> 01:00:33,520
How long do orders really wait between this machining operation

1619
01:00:33,520 --> 01:00:34,880
and the next assembly step?

1620
01:00:34,880 --> 01:00:37,840
Does the wait happen every day or only when a certain product family runs?

1621
01:00:37,840 --> 01:00:41,760
Does it grow after a quality hold, a material shortage, or a schedule change?

1622
01:00:41,760 --> 01:00:43,600
The answers sit in the order history,

1623
01:00:43,600 --> 01:00:46,800
MES events, quality records, and planning updates.

1624
01:00:46,800 --> 01:00:49,120
The map gives that question a place in the flow,

1625
01:00:49,120 --> 01:00:51,600
and the data lets the team actually test it.

1626
01:00:51,600 --> 01:00:54,480
Take work in progress, WIP as it's often called.

1627
01:00:54,480 --> 01:00:57,440
A static value stream map might show a typical number of units

1628
01:00:57,440 --> 01:00:59,760
or batches waiting between two processes

1629
01:00:59,760 --> 01:01:01,360
that can highlight a broad problem,

1630
01:01:01,360 --> 01:01:03,040
but it doesn't tell you which orders are waiting,

1631
01:01:03,040 --> 01:01:05,200
how long they've waited, or whether they're all waiting

1632
01:01:05,200 --> 01:01:06,240
for the same reason.

1633
01:01:06,240 --> 01:01:08,400
The operational record can fill in those blanks.

1634
01:01:08,400 --> 01:01:10,800
A team might find that the queue looks normal overall,

1635
01:01:10,800 --> 01:01:13,840
while a small set of orders repeatedly waits for inspection release.

1636
01:01:13,840 --> 01:01:17,600
Or maybe the queue rises after one upstream resource runs a large batch,

1637
01:01:17,600 --> 01:01:19,600
even though the next resource can't take that product

1638
01:01:19,600 --> 01:01:20,960
until a tool becomes free.

1639
01:01:20,960 --> 01:01:23,840
The counter loan doesn't reveal which condition created the waiting.

1640
01:01:23,840 --> 01:01:25,200
Flow needs time and context.

1641
01:01:25,200 --> 01:01:26,400
Lead time works the same way.

1642
01:01:26,400 --> 01:01:28,560
If a customer order takes longer than expected,

1643
01:01:28,560 --> 01:01:31,040
the team should be able to trace its real path.

1644
01:01:31,040 --> 01:01:32,480
When did planning release it?

1645
01:01:32,480 --> 01:01:33,920
When did material become available?

1646
01:01:33,920 --> 01:01:36,000
When did each operation actually start and finish?

1647
01:01:36,000 --> 01:01:37,440
Did the order sit in a queue?

1648
01:01:37,440 --> 01:01:39,360
Return for rework, wait for inspection,

1649
01:01:39,360 --> 01:01:41,600
or lose priority after a schedule change?

1650
01:01:41,600 --> 01:01:44,240
That trace connects an abstract lead time problem

1651
01:01:44,240 --> 01:01:46,400
to decisions people can actually change.

1652
01:01:46,400 --> 01:01:47,600
Say an order misses shipment.

1653
01:01:47,600 --> 01:01:49,600
A quick review might blame the final production line

1654
01:01:49,600 --> 01:01:51,680
because that's where the last visible delay occurred.

1655
01:01:51,680 --> 01:01:54,160
But when you trace the order through the value stream,

1656
01:01:54,160 --> 01:01:56,560
you may find the delay started much earlier.

1657
01:01:56,560 --> 01:01:58,160
Perhaps planning released the order late

1658
01:01:58,160 --> 01:02:00,160
because a component looked unavailable.

1659
01:02:00,160 --> 01:02:01,520
Perhaps the component arrived,

1660
01:02:01,520 --> 01:02:05,120
but the ERP status didn't update in time for the next planning run.

1661
01:02:05,120 --> 01:02:06,640
Maybe production finished the order,

1662
01:02:06,640 --> 01:02:08,000
then quality held it for a check

1663
01:02:08,000 --> 01:02:10,560
that the team hadn't included in the original flow map.

1664
01:02:10,560 --> 01:02:12,800
The final line didn't create the whole delay.

1665
01:02:12,800 --> 01:02:13,680
It inherited it.

1666
01:02:13,680 --> 01:02:16,080
That's why the information flow in value stream mapping

1667
01:02:16,080 --> 01:02:17,760
matters as much as the material flow.

1668
01:02:17,760 --> 01:02:20,480
A production order can wait because material is missing,

1669
01:02:20,480 --> 01:02:22,720
but it can also wait because a status change,

1670
01:02:22,720 --> 01:02:24,880
inspection result, dispatch decision,

1671
01:02:24,880 --> 01:02:27,360
or planning rule, didn't reach the person who needed it.

1672
01:02:28,240 --> 01:02:30,320
When you connect the map to operating data,

1673
01:02:30,320 --> 01:02:32,240
you can see both forms of waiting.

1674
01:02:32,240 --> 01:02:33,760
Now, here's where restraint comes in.

1675
01:02:33,760 --> 01:02:36,320
You don't need a live feed for every box and arrow on the map.

1676
01:02:36,320 --> 01:02:39,440
The purpose isn't to build a busy digital wall that nobody uses.

1677
01:02:39,440 --> 01:02:41,040
The purpose is to connect the points

1678
01:02:41,040 --> 01:02:43,360
where the team needs to make an improvement decision

1679
01:02:43,360 --> 01:02:46,400
with the records that show whether flow actually improved.

1680
01:02:46,400 --> 01:02:49,440
For one value stream, that might mean daily queue age,

1681
01:02:49,440 --> 01:02:52,400
order lead time, rework loops, and schedule changes.

1682
01:02:52,400 --> 01:02:54,480
For another, it might mean shift-level flow

1683
01:02:54,480 --> 01:02:55,920
through a constrained operation

1684
01:02:55,920 --> 01:02:57,840
and the reason orders wait before it.

1685
01:02:57,840 --> 01:03:00,880
The measures should follow the problem in that value stream,

1686
01:03:00,880 --> 01:03:02,400
not every line needs the same view.

1687
01:03:02,400 --> 01:03:05,440
The useful result is a map that stays human readable

1688
01:03:05,440 --> 01:03:07,600
while the evidence behind it stays current.

1689
01:03:07,600 --> 01:03:10,000
People can still stand together and ask where flow breaks.

1690
01:03:10,000 --> 01:03:12,640
But instead of relying on an old workshop snapshot,

1691
01:03:12,640 --> 01:03:14,400
they can follow a real order

1692
01:03:14,400 --> 01:03:18,240
through planning, release, operation, inspection, and shipment.

1693
01:03:18,240 --> 01:03:19,360
That changes the conversation.

1694
01:03:19,360 --> 01:03:21,920
A late order stops being a red number on a delivery report.

1695
01:03:21,920 --> 01:03:24,000
It becomes a chain of events across functions

1696
01:03:24,000 --> 01:03:26,240
with named handoffs and recorded conditions.

1697
01:03:26,240 --> 01:03:27,760
Once you can trace that chain,

1698
01:03:27,760 --> 01:03:30,800
continuous improvement moves beyond one line or one department

1699
01:03:30,800 --> 01:03:33,840
because the decision often sits between IT and OT,

1700
01:03:33,840 --> 01:03:36,800
planning and execution, or quality and production.

1701
01:03:36,800 --> 01:03:38,400
Improvement across IT and OT.

1702
01:03:38,400 --> 01:03:41,440
Now, here's where it gets interesting.

1703
01:03:41,440 --> 01:03:44,000
Once improvement follows the path of a real order,

1704
01:03:44,000 --> 01:03:46,160
the team crosses a boundary that many factories

1705
01:03:46,160 --> 01:03:47,840
still treat as separate worlds.

1706
01:03:47,840 --> 01:03:51,280
Operational technology, OT, runs the physical process.

1707
01:03:51,280 --> 01:03:54,080
It includes the controls, machines, sensors,

1708
01:03:54,080 --> 01:03:56,400
safety systems, and the people responsible

1709
01:03:56,400 --> 01:03:57,920
for keeping production stable.

1710
01:03:57,920 --> 01:04:00,720
OT teams work with equipment that can hurt people,

1711
01:04:00,720 --> 01:04:02,400
damage product, or stop a plant

1712
01:04:02,400 --> 01:04:04,160
when something changes carelessly.

1713
01:04:04,160 --> 01:04:05,440
That changes the rules.

1714
01:04:05,440 --> 01:04:07,440
And OT engineer can't treat a production line

1715
01:04:07,440 --> 01:04:08,240
like a test server.

1716
01:04:08,240 --> 01:04:10,000
A controller change needs discipline.

1717
01:04:10,000 --> 01:04:11,440
Network access needs discipline.

1718
01:04:11,440 --> 01:04:13,840
Even a new data connection requires someone to understand

1719
01:04:13,840 --> 01:04:15,440
what it touches, when it runs,

1720
01:04:15,440 --> 01:04:17,840
and how the line behaves if that connection fails.

1721
01:04:17,840 --> 01:04:19,040
It has a different job.

1722
01:04:19,040 --> 01:04:21,520
IT manages identity access, integration,

1723
01:04:21,520 --> 01:04:23,120
data storage, enterprise reporting,

1724
01:04:23,120 --> 01:04:24,640
and the rules around security.

1725
01:04:24,640 --> 01:04:26,560
They need systems that people can support,

1726
01:04:26,560 --> 01:04:29,840
audit, and extend without building a new one-off connection

1727
01:04:29,840 --> 01:04:31,520
every time somebody needs a report.

1728
01:04:31,520 --> 01:04:33,120
Both groups protect the business.

1729
01:04:33,120 --> 01:04:35,680
They just protect it from different forms of failure.

1730
01:04:35,680 --> 01:04:37,440
Lean teams sit right between them

1731
01:04:37,440 --> 01:04:40,800
because improvement questions often need both kinds of evidence.

1732
01:04:40,800 --> 01:04:42,880
A team may want to know why a line loses flow

1733
01:04:42,880 --> 01:04:43,920
after machine alarm.

1734
01:04:43,920 --> 01:04:45,840
That question needs the operating facts from OT,

1735
01:04:45,840 --> 01:04:47,520
but it may also need the work order,

1736
01:04:47,520 --> 01:04:49,200
material status, quality result,

1737
01:04:49,200 --> 01:04:51,600
and delivery consequence from enterprise systems.

1738
01:04:51,600 --> 01:04:53,040
Nobody owns that question alone.

1739
01:04:53,040 --> 01:04:54,480
If OT owns the whole answer,

1740
01:04:54,480 --> 01:04:56,480
the team may see the machine condition,

1741
01:04:56,480 --> 01:04:57,840
but miss the planning decision

1742
01:04:57,840 --> 01:04:59,680
that created repeated product switches.

1743
01:04:59,680 --> 01:05:02,480
If I'd owns the whole answer,

1744
01:05:02,480 --> 01:05:04,160
the team may join data correctly,

1745
01:05:04,160 --> 01:05:06,160
yet misunderstand what a machine state means

1746
01:05:06,160 --> 01:05:07,360
during a real setup.

1747
01:05:07,360 --> 01:05:10,320
The factory needs both views in the same conversation.

1748
01:05:10,320 --> 01:05:12,880
Picture a recurring issue with a heat treatment process.

1749
01:05:12,880 --> 01:05:14,400
Production sees batches waiting.

1750
01:05:14,400 --> 01:05:16,160
Maintenance sees no active fault.

1751
01:05:16,160 --> 01:05:18,960
The planner sees a resource that should have capacity.

1752
01:05:18,960 --> 01:05:22,160
A lean team starts asking why the queue grows on certain days.

1753
01:05:22,160 --> 01:05:23,680
An OT person may point out

1754
01:05:23,680 --> 01:05:25,680
that the oven needs a controlled cool-down period

1755
01:05:25,680 --> 01:05:26,960
after certain recipes.

1756
01:05:26,960 --> 01:05:30,000
The MES record can show when that condition occurred.

1757
01:05:30,000 --> 01:05:32,560
Planning may then find that the schedule repeatedly places

1758
01:05:32,560 --> 01:05:34,640
incompatible recipes next to each other,

1759
01:05:34,640 --> 01:05:36,960
creating waiting that looks like a capacity problem

1760
01:05:36,960 --> 01:05:38,640
but begins as a sequencing rule.

1761
01:05:38,640 --> 01:05:41,520
That is an improvement question that crosses IT and OT.

1762
01:05:41,520 --> 01:05:43,600
The goal isn't to turn every Kaiser event

1763
01:05:43,600 --> 01:05:45,040
into an integration project

1764
01:05:45,040 --> 01:05:47,200
that would kill the pace of improvement very quickly.

1765
01:05:47,200 --> 01:05:48,560
You don't need a steering committee

1766
01:05:48,560 --> 01:05:52,240
and six months of architecture work every time a team sees a recurring delay.

1767
01:05:52,240 --> 01:05:53,760
But you do need a repeatable path

1768
01:05:53,760 --> 01:05:56,960
for getting approved facts into the hands of the people who need to act.

1769
01:05:56,960 --> 01:05:58,000
Start with the question.

1770
01:05:58,000 --> 01:05:59,280
Which event needs explanation?

1771
01:05:59,280 --> 01:06:01,040
Which system records part of that event?

1772
01:06:01,040 --> 01:06:03,120
Which person can explain the operating condition?

1773
01:06:03,120 --> 01:06:05,600
What decision will change if the team finds an answer?

1774
01:06:05,600 --> 01:06:07,440
Those questions keep the work practical.

1775
01:06:07,440 --> 01:06:09,040
Shared ownership matters too.

1776
01:06:09,040 --> 01:06:11,280
OT should help define what machine states,

1777
01:06:11,280 --> 01:06:13,680
alarms, and operating limits actually mean.

1778
01:06:13,680 --> 01:06:16,640
It should help define access, data movement, identity,

1779
01:06:16,640 --> 01:06:18,640
retention, and the support model.

1780
01:06:18,640 --> 01:06:21,760
Lean leaders and production teams should define the loss of the work process,

1781
01:06:21,760 --> 01:06:24,560
the review rhythm, and the countermeasure they want to test.

1782
01:06:24,560 --> 01:06:26,800
No single team can fill in all those blanks.

1783
01:06:26,800 --> 01:06:29,280
Data quality needs the same shared approach.

1784
01:06:29,280 --> 01:06:32,720
If a tag changes after a machine upgrade OT may spot it first.

1785
01:06:32,720 --> 01:06:35,520
If the change breaks an integration or alter the report,

1786
01:06:35,520 --> 01:06:36,880
IT may spot it next.

1787
01:06:36,880 --> 01:06:40,160
If a supervisor sees that the report no longer matches the shift,

1788
01:06:40,160 --> 01:06:42,480
production needs a simple way to raise that issue

1789
01:06:42,480 --> 01:06:45,440
before people start making decisions from bad evidence.

1790
01:06:45,440 --> 01:06:48,240
The response process matters as much as the data connection.

1791
01:06:48,240 --> 01:06:50,160
You also need to avoid a common mistake.

1792
01:06:50,160 --> 01:06:53,520
Sometimes I'd ask for universal standards before connecting anything.

1793
01:06:53,520 --> 01:06:55,520
Sometimes OT refuses any shared access

1794
01:06:55,520 --> 01:06:56,800
because the first request arrived

1795
01:06:56,800 --> 01:06:58,560
without enough understanding of the plant.

1796
01:06:58,560 --> 01:07:01,680
Both reactions make sense when people have lived through poor projects.

1797
01:07:01,680 --> 01:07:04,240
Still, neither response solves the production problem.

1798
01:07:04,240 --> 01:07:07,680
A better approach starts with a bounded use case and clear controls.

1799
01:07:07,680 --> 01:07:10,000
The team agrees which signals or records it needs,

1800
01:07:10,000 --> 01:07:12,480
how often it needs them, who can access them,

1801
01:07:12,480 --> 01:07:14,480
and what stays inside the operational network.

1802
01:07:14,480 --> 01:07:17,600
Then it tests whether the information helps a real PDCA cycle.

1803
01:07:17,600 --> 01:07:20,320
That builds trust through work, not through slogans.

1804
01:07:20,320 --> 01:07:23,440
As a Microsoft MVP, I spend a lot of time around Azure,

1805
01:07:23,440 --> 01:07:26,000
Fabric, Power BI, and the wider Microsoft stack.

1806
01:07:26,000 --> 01:07:29,200
Those tools can help connect the dots between IT and OT.

1807
01:07:29,200 --> 01:07:31,120
But they don't decide what a stop means,

1808
01:07:31,120 --> 01:07:33,200
which process condition deserves attention,

1809
01:07:33,200 --> 01:07:36,000
or whether a countermeasure works safely on a live line.

1810
01:07:36,000 --> 01:07:37,600
The factory has to model that meaning.

1811
01:07:37,600 --> 01:07:38,800
Once those roles are clear,

1812
01:07:38,800 --> 01:07:42,400
Microsoft technology can fit into the architecture as a practical data path,

1813
01:07:42,400 --> 01:07:46,480
rather than another platform, someone hopes will fix an unclear improvement process.

1814
01:07:46,480 --> 01:07:48,320
A practical Microsoft data path.

1815
01:07:48,320 --> 01:07:51,760
Here's the problem most manufacturers don't talk about.

1816
01:07:51,760 --> 01:07:54,480
You've got the equipment, you've got MS, you've got ERP,

1817
01:07:54,480 --> 01:07:56,640
and you've probably got Azure somewhere in the mix.

1818
01:07:56,640 --> 01:07:59,440
But getting data from the shop floor into something useful

1819
01:07:59,440 --> 01:08:01,920
still feels like a plumbing project with no blueprint.

1820
01:08:01,920 --> 01:08:04,560
And the worst part is, nobody wants to admit

1821
01:08:04,560 --> 01:08:07,760
their data model can't support the questions they're actually asking.

1822
01:08:07,760 --> 01:08:11,600
So let's walk through what a practical data path looks like on Microsoft tools

1823
01:08:11,600 --> 01:08:13,840
without pretending the platform owns the process.

1824
01:08:13,840 --> 01:08:16,000
It doesn't, it supports it, start close to the equipment.

1825
01:08:16,000 --> 01:08:18,480
Machine and sensor data should leave the operational network

1826
01:08:18,480 --> 01:08:20,160
through an approved edge layer.

1827
01:08:20,160 --> 01:08:22,800
Something OT teams understand and can support.

1828
01:08:22,800 --> 01:08:25,120
That layer collects selected PLC states,

1829
01:08:25,120 --> 01:08:27,440
alarms, cycle events, and process values,

1830
01:08:27,440 --> 01:08:30,960
then passes them forward without giving the cloud direct control over the line.

1831
01:08:30,960 --> 01:08:33,760
Production stays in charge of production full stop,

1832
01:08:33,760 --> 01:08:36,000
pull execution facts from MES next.

1833
01:08:36,000 --> 01:08:38,800
Operation times quantities hold rejects reason codes,

1834
01:08:38,800 --> 01:08:41,680
that's the record of what actually happened versus what was planned.

1835
01:08:41,680 --> 01:08:44,960
At ERP data for order demand, plant sequence, routing,

1836
01:08:44,960 --> 01:08:49,440
material status, and the planning changes that explain why a supposedly stable process

1837
01:08:49,440 --> 01:08:51,440
keeps getting disrupted at the last minute.

1838
01:08:51,440 --> 01:08:55,440
Quality records join when you need to know whether a change improved output

1839
01:08:55,440 --> 01:08:57,200
but hurt product acceptance.

1840
01:08:57,200 --> 01:09:01,360
Maintenance records join when equipment, condition, or work history is part of the hypothesis.

1841
01:09:01,360 --> 01:09:03,120
You don't need every source for every case,

1842
01:09:03,120 --> 01:09:05,600
but you need the sources that explain the condition you're reviewing.

1843
01:09:05,600 --> 01:09:08,560
This is a chain of evidence, not a data collection contest.

1844
01:09:08,560 --> 01:09:14,080
Collecting everything and hoping the answer appears is how you end up with a lake of data nobody trusts.

1845
01:09:14,080 --> 01:09:16,480
Azure provides the services around that chain,

1846
01:09:16,480 --> 01:09:19,840
ingestion from approved sources, storage for event history,

1847
01:09:19,840 --> 01:09:24,640
integration between systems, identity controls, monitoring, secure access patterns,

1848
01:09:24,640 --> 01:09:27,120
the exact services depend on what you already have.

1849
01:09:27,120 --> 01:09:29,280
I wouldn't start with a preferred product list.

1850
01:09:29,280 --> 01:09:31,520
Start with the path, a fact needs to travel.

1851
01:09:31,520 --> 01:09:33,600
A machine event enters through an edge gateway,

1852
01:09:33,600 --> 01:09:38,720
an MES event arrives through an API, a database extract, or a message interface.

1853
01:09:38,720 --> 01:09:41,920
ERP data comes through a managed connector or an agreed export.

1854
01:09:41,920 --> 01:09:44,800
The point is to preserve source, event time,

1855
01:09:44,800 --> 01:09:47,520
and the context needed to interpret each record later.

1856
01:09:47,520 --> 01:09:49,280
If you lose those details during integration,

1857
01:09:49,280 --> 01:09:53,680
the report may look clean while the improvement team loses the ability to ask where a number came from.

1858
01:09:53,680 --> 01:09:56,720
Microsoft Fabric becomes useful once data from those sources

1859
01:09:56,720 --> 01:09:59,760
needs a governed shared home for engineering work and analysis.

1860
01:09:59,760 --> 01:10:03,680
It brings data preparation, storage, and analytical models closer together,

1861
01:10:03,680 --> 01:10:07,440
which helps when multiple teams need to work from the same definitions

1862
01:10:07,440 --> 01:10:10,560
instead of building separate copies of the same production logic.

1863
01:10:10,560 --> 01:10:13,840
That does not mean Fabric magically resolves factory disagreement.

1864
01:10:13,840 --> 01:10:16,320
A platform can store a resource hierarchy,

1865
01:10:16,320 --> 01:10:19,520
but it can't tell you whether a resource name means a full line,

1866
01:10:19,520 --> 01:10:23,600
a station, or a shared fixture, unless someone who knows the process defines it.

1867
01:10:23,600 --> 01:10:25,680
It can calculate a change over duration,

1868
01:10:25,680 --> 01:10:28,480
but it can't decide whether the endpoint should be first cycle,

1869
01:10:28,480 --> 01:10:30,640
first accepted unit, or stable output.

1870
01:10:30,640 --> 01:10:32,000
The factory supplies the meaning.

1871
01:10:32,000 --> 01:10:34,640
The platform keeps that meaning usable across the data path.

1872
01:10:34,640 --> 01:10:38,720
A typical setup builds a curated improvement model around the question at hand.

1873
01:10:38,720 --> 01:10:42,720
It links the planned order from ERP to the executed operation in MES,

1874
01:10:42,720 --> 01:10:46,000
then relates that operation to machine events during the same production window.

1875
01:10:46,000 --> 01:10:48,320
Quality outcomes, maintenance notes,

1876
01:10:48,320 --> 01:10:51,280
and operator observations sit alongside those facts when they apply.

1877
01:10:51,280 --> 01:10:55,200
Now the team can move through the evidence without rebuilding the join every week.

1878
01:10:55,200 --> 01:10:57,360
Power BI sits near the end of that path.

1879
01:10:57,360 --> 01:11:00,400
It returns role-based views to the people who need to make decisions.

1880
01:11:00,400 --> 01:11:02,800
A supervisor looks at open losses during a shift.

1881
01:11:02,800 --> 01:11:06,400
A process engineer reviews trial results, a planner checks schedule effects,

1882
01:11:06,400 --> 01:11:09,360
an improvement team compares runs before and after a countermeasure.

1883
01:11:09,360 --> 01:11:11,520
Each group needs a different level of detail.

1884
01:11:11,520 --> 01:11:15,200
One shared model supports those views when the definitions stay consistent.

1885
01:11:15,200 --> 01:11:17,600
That consistency matters more than visual polish.

1886
01:11:17,600 --> 01:11:21,280
A clean report with unclear logic just speeds up disagreement.

1887
01:11:21,280 --> 01:11:25,600
A simpler view that lets a team trace a number back to the order event and decision behind it

1888
01:11:25,600 --> 01:11:27,520
supports much better improvement work.

1889
01:11:27,520 --> 01:11:30,160
Same principle applies to alerts and automation.

1890
01:11:30,160 --> 01:11:33,920
A workflow can notify the right person when a condition crosses an agreed threshold

1891
01:11:33,920 --> 01:11:36,240
or when a trial reaches a review point.

1892
01:11:36,240 --> 01:11:38,480
But the trigger has to connect to a known response.

1893
01:11:38,480 --> 01:11:41,200
If an alert arrives and nobody knows what to check who owns it

1894
01:11:41,200 --> 01:11:43,040
or whether production can act safely,

1895
01:11:43,040 --> 01:11:45,760
it becomes just another message people learn to ignore.

1896
01:11:45,760 --> 01:11:47,920
Factories already have enough of those.

1897
01:11:47,920 --> 01:11:50,240
Microsoft tools handle the platform work.

1898
01:11:50,240 --> 01:11:52,160
Secure data movement, storage,

1899
01:11:52,160 --> 01:11:55,840
governed access, engineering workflows, analytical models reporting.

1900
01:11:55,840 --> 01:11:58,880
Specialised manufacturing systems continue running execution,

1901
01:11:58,880 --> 01:12:01,920
controls, quality, maintenance and scheduling where they belong.

1902
01:12:01,920 --> 01:12:04,320
The lean team still decides what lost to study.

1903
01:12:04,320 --> 01:12:07,600
Production still decides whether a new method works in real conditions.

1904
01:12:07,600 --> 01:12:09,040
OT still protects the equipment.

1905
01:12:09,040 --> 01:12:11,120
IT still keeps the data path supportable.

1906
01:12:11,120 --> 01:12:12,960
That division keeps the architecture honest.

1907
01:12:12,960 --> 01:12:14,480
When these roles fit together,

1908
01:12:14,480 --> 01:12:17,520
improvement work gains a record that reaches from the shop floor to planning

1909
01:12:17,520 --> 01:12:20,560
without turning the factory into one giant reporting project.

1910
01:12:20,560 --> 01:12:23,280
But a report, even one built on good data,

1911
01:12:23,280 --> 01:12:25,040
can't run PDCA by itself.

1912
01:12:25,040 --> 01:12:26,080
That still takes people.

1913
01:12:26,080 --> 01:12:27,760
Why dashboards don't create improvement?

1914
01:12:27,760 --> 01:12:31,200
A dashboard can show a loss very clearly.

1915
01:12:31,200 --> 01:12:32,880
It can show that change over time rose,

1916
01:12:32,880 --> 01:12:34,960
that rejects increased after a restart

1917
01:12:34,960 --> 01:12:37,280
or that orders waited too long between two operations.

1918
01:12:37,280 --> 01:12:39,360
But it still can't tell a team what to try next

1919
01:12:39,360 --> 01:12:41,600
because a chart doesn't form a hypothesis,

1920
01:12:41,600 --> 01:12:42,880
run and control the test,

1921
01:12:42,880 --> 01:12:45,920
or decide whether the result is safe enough to standardise.

1922
01:12:45,920 --> 01:12:48,960
That distinction gets lost when a plant invests in reporting.

1923
01:12:48,960 --> 01:12:50,560
The report arrives faster,

1924
01:12:50,560 --> 01:12:52,160
the numbers look more consistent,

1925
01:12:52,160 --> 01:12:54,640
and people understandably feel they've gained control.

1926
01:12:54,640 --> 01:12:57,040
Then the same issue appears in the next shift meeting,

1927
01:12:57,040 --> 01:12:59,440
except now everybody can see it in nicer colours.

1928
01:12:59,440 --> 01:13:00,480
Visibility helps.

1929
01:13:00,480 --> 01:13:01,920
It isn't improvement.

1930
01:13:01,920 --> 01:13:04,080
Consider a line with frequent short stops.

1931
01:13:04,080 --> 01:13:06,720
A dashboard may show the stop count rising on one resource

1932
01:13:06,720 --> 01:13:08,400
during a certain product family.

1933
01:13:08,400 --> 01:13:10,080
That gives the team a useful signal,

1934
01:13:10,080 --> 01:13:12,720
but the next step still needs people close to the work.

1935
01:13:12,720 --> 01:13:14,000
What condition changed?

1936
01:13:14,000 --> 01:13:16,000
Does the stop happen at a certain speed?

1937
01:13:16,000 --> 01:13:18,400
After a refill during a particular sequence?

1938
01:13:18,400 --> 01:13:21,360
Or when a specific material lot enters the process?

1939
01:13:21,360 --> 01:13:23,120
The team needs an explanation to contest,

1940
01:13:23,120 --> 01:13:24,720
not another tile that turns red.

1941
01:13:24,720 --> 01:13:27,760
A report becomes useful when it sits inside a decision path.

1942
01:13:27,760 --> 01:13:29,040
Someone sees the condition.

1943
01:13:29,040 --> 01:13:30,560
Someone owns the first check.

1944
01:13:30,560 --> 01:13:32,400
The team knows which evidence to review

1945
01:13:32,400 --> 01:13:34,880
when to run a trial and when to return to the result.

1946
01:13:34,880 --> 01:13:37,600
Without that path, a dashboard becomes a record of problems

1947
01:13:37,600 --> 01:13:40,160
everybody noticed and nobody carried through.

1948
01:13:40,160 --> 01:13:41,600
I've seen this pattern often.

1949
01:13:41,600 --> 01:13:43,200
The morning meeting reviews OEE,

1950
01:13:43,200 --> 01:13:44,560
output, scrap and laid orders.

1951
01:13:44,560 --> 01:13:46,000
People discuss the losses,

1952
01:13:46,000 --> 01:13:47,360
assign a few actions,

1953
01:13:47,360 --> 01:13:49,600
and move on because production needs attention.

1954
01:13:49,600 --> 01:13:52,080
A week later, the same numbers appear again.

1955
01:13:52,080 --> 01:13:53,840
The actions may still sit in a tracker,

1956
01:13:53,840 --> 01:13:56,720
but nobody can tell whether they applied to the right condition

1957
01:13:56,720 --> 01:13:58,400
or changed the process at all.

1958
01:13:58,400 --> 01:14:00,000
Faster refresh does not fix that.

1959
01:14:00,000 --> 01:14:01,920
There's also a people problem hiding inside

1960
01:14:01,920 --> 01:14:03,280
many performance reports.

1961
01:14:03,280 --> 01:14:04,880
When a dashboard mainly compares people

1962
01:14:04,880 --> 01:14:06,560
or shifts through output figures,

1963
01:14:06,560 --> 01:14:08,640
it pushes teams toward defensive behavior.

1964
01:14:08,640 --> 01:14:10,400
Someone avoids recording a short stop.

1965
01:14:10,400 --> 01:14:12,320
Another person chooses a broad reason code

1966
01:14:12,320 --> 01:14:14,080
because a detailed one looks worse.

1967
01:14:14,080 --> 01:14:16,560
A supervisor focuses on getting the number back into range

1968
01:14:16,560 --> 01:14:18,400
before anyone understands the cause.

1969
01:14:18,400 --> 01:14:20,880
The report then measures the response to the report.

1970
01:14:20,880 --> 01:14:23,120
Lean should help people expose problems safely.

1971
01:14:23,120 --> 01:14:24,720
That means a view needs enough context

1972
01:14:24,720 --> 01:14:27,040
to support a conversation about process conditions,

1973
01:14:27,040 --> 01:14:29,920
not just a rank order of who appears to perform best.

1974
01:14:29,920 --> 01:14:31,760
For a supervisor, a useful view might show

1975
01:14:31,760 --> 01:14:33,120
the current abnormal condition,

1976
01:14:33,120 --> 01:14:34,080
the affected order,

1977
01:14:34,080 --> 01:14:35,360
the state of the countermeasure,

1978
01:14:35,360 --> 01:14:36,960
and who needs to respond.

1979
01:14:36,960 --> 01:14:38,080
For an improvement engineer,

1980
01:14:38,080 --> 01:14:40,640
the same underlying data may need comparable runs,

1981
01:14:40,640 --> 01:14:41,520
trial scope,

1982
01:14:41,520 --> 01:14:43,360
and evidence before and after a change.

1983
01:14:43,360 --> 01:14:44,800
Those are different decisions.

1984
01:14:44,800 --> 01:14:46,560
They should not get the same report.

1985
01:14:46,560 --> 01:14:48,000
The design question is simple.

1986
01:14:48,000 --> 01:14:50,160
When this number moves, what action should follow?

1987
01:14:50,160 --> 01:14:51,200
If nobody can answer that,

1988
01:14:51,200 --> 01:14:52,640
the measure belongs in a report archive

1989
01:14:52,640 --> 01:14:53,920
not in a daily meeting.

1990
01:14:53,920 --> 01:14:55,200
And when the action does exist,

1991
01:14:55,200 --> 01:14:57,360
the view should help the team follow through.

1992
01:14:57,360 --> 01:14:59,680
It should show whether the issue remains open,

1993
01:14:59,680 --> 01:15:01,520
whether a countermeasure is under trial,

1994
01:15:01,520 --> 01:15:03,520
what conditions fall inside that trial

1995
01:15:03,520 --> 01:15:05,360
and when the team needs to check the result.

1996
01:15:05,360 --> 01:15:07,280
That turns reporting into part of the work.

1997
01:15:07,280 --> 01:15:09,840
There is a dry but useful reality check here.

1998
01:15:09,840 --> 01:15:13,280
A colorful OEE report can't tighten a loose fixture.

1999
01:15:13,280 --> 01:15:14,960
It can't clean a blocked sensor,

2000
01:15:14,960 --> 01:15:16,800
change an unstable setup method,

2001
01:15:16,800 --> 01:15:18,240
or resolve a material problem

2002
01:15:18,240 --> 01:15:19,200
between two departments.

2003
01:15:19,200 --> 01:15:20,400
People change the process.

2004
01:15:20,400 --> 01:15:23,600
Data helps them spend less time arguing about where to look.

2005
01:15:23,600 --> 01:15:25,360
It helps them test whether a change held

2006
01:15:25,360 --> 01:15:27,040
across normal production conditions.

2007
01:15:27,040 --> 01:15:28,560
It helps them notice side effects

2008
01:15:28,560 --> 01:15:31,120
before a local fix becomes a wider problem.

2009
01:15:31,120 --> 01:15:33,040
But the work still happens at the machine,

2010
01:15:33,040 --> 01:15:34,080
in the shift handover,

2011
01:15:34,080 --> 01:15:35,520
in planning and maintenance,

2012
01:15:35,520 --> 01:15:37,680
and in the decisions that shape the next production run.

2013
01:15:37,680 --> 01:15:40,320
So don't judge a dashboard by how much it displays,

2014
01:15:40,320 --> 01:15:42,080
judge it by whether it helps the right person

2015
01:15:42,080 --> 01:15:43,440
take a clear next step,

2016
01:15:43,440 --> 01:15:45,040
then check the result against the condition

2017
01:15:45,040 --> 01:15:46,000
they intended to change.

2018
01:15:46,000 --> 01:15:48,240
That requires a working rhythm around the data.

2019
01:15:48,240 --> 01:15:51,360
And that's where the real improvement lives.

2020
01:15:51,360 --> 01:15:52,560
The daily improvement rhythm.

2021
01:15:52,560 --> 01:15:54,880
A data loop doesn't do any good

2022
01:15:54,880 --> 01:15:56,720
unless it fits the normal rhythm of the plant.

2023
01:15:56,720 --> 01:15:58,080
If teams only look at evidence

2024
01:15:58,080 --> 01:15:59,600
at the end of a kaizin project,

2025
01:15:59,600 --> 01:16:01,760
they catch problems after conditions have shifted

2026
01:16:01,760 --> 01:16:03,120
and the people closest to the work

2027
01:16:03,120 --> 01:16:04,800
have moved onto the next fire.

2028
01:16:04,800 --> 01:16:06,960
The routine has to match the pace of production.

2029
01:16:06,960 --> 01:16:08,560
Not every question needs a deep dive,

2030
01:16:08,560 --> 01:16:10,160
but every recurring loss needs a spot

2031
01:16:10,160 --> 01:16:11,440
where somebody checks it, owns it,

2032
01:16:11,440 --> 01:16:12,960
and decides what happens next.

2033
01:16:12,960 --> 01:16:14,400
So start with the shift review.

2034
01:16:14,400 --> 01:16:16,000
Keep it short and close to the work.

2035
01:16:16,000 --> 01:16:18,960
The goal isn't to explain every loss before the next break,

2036
01:16:18,960 --> 01:16:20,800
it's to establish the current condition,

2037
01:16:20,800 --> 01:16:22,240
what ran, what changed,

2038
01:16:22,240 --> 01:16:24,080
which abnormal events happened,

2039
01:16:24,080 --> 01:16:26,160
and whether an open countermeasure needs attention

2040
01:16:26,160 --> 01:16:28,080
before the next crew takes over.

2041
01:16:28,080 --> 01:16:30,080
A supervisor might sit down with the operator

2042
01:16:30,080 --> 01:16:31,840
who saw a repeated stop pattern

2043
01:16:31,840 --> 01:16:33,200
and check whether the current trial

2044
01:16:33,200 --> 01:16:34,800
still applies to the next order.

2045
01:16:34,800 --> 01:16:37,120
A maintenance issue might need a clear handoff,

2046
01:16:37,120 --> 01:16:39,120
or a quality hold requires a status check

2047
01:16:39,120 --> 01:16:40,400
before it becomes a planning problem.

2048
01:16:40,400 --> 01:16:42,960
The data should support that conversation with recent facts,

2049
01:16:42,960 --> 01:16:44,720
while people add the context systems,

2050
01:16:44,720 --> 01:16:45,760
can't capture a loan.

2051
01:16:45,760 --> 01:16:46,720
Keep it practical.

2052
01:16:46,720 --> 01:16:48,000
The shift review should separate

2053
01:16:48,000 --> 01:16:49,200
what needs immediate containment

2054
01:16:49,200 --> 01:16:51,520
from what belongs in a longer improvement cycle.

2055
01:16:51,520 --> 01:16:54,240
If a guard is damaged, follow the safety process.

2056
01:16:54,240 --> 01:16:56,560
If a recurring setup delay shows up again,

2057
01:16:56,560 --> 01:16:59,360
record it properly and carry it into the next review with evidence.

2058
01:16:59,360 --> 01:17:00,720
Those are different response paths

2059
01:17:00,720 --> 01:17:02,560
and mixing them creates noise.

2060
01:17:02,560 --> 01:17:04,080
Next, you need a weekly review.

2061
01:17:04,080 --> 01:17:05,120
This is where the team checks

2062
01:17:05,120 --> 01:17:06,320
whether patterns from daily work

2063
01:17:06,320 --> 01:17:07,440
repeat across shifts,

2064
01:17:07,440 --> 01:17:08,320
product runs,

2065
01:17:08,320 --> 01:17:09,520
and operating conditions.

2066
01:17:09,520 --> 01:17:12,080
It's also where countermeasure moves from intention

2067
01:17:12,080 --> 01:17:13,840
into an evidence-based decision.

2068
01:17:13,840 --> 01:17:16,640
A weekly review can ask a few simple but useful questions.

2069
01:17:16,640 --> 01:17:18,640
Did the trial apply when we thought it did?

2070
01:17:18,640 --> 01:17:20,000
Did the condition improve?

2071
01:17:20,000 --> 01:17:21,360
Under comparable production?

2072
01:17:21,360 --> 01:17:24,480
Did quality, delivery, or flow move in an unwanted direction?

2073
01:17:24,480 --> 01:17:26,720
Are some shifts seeing different results?

2074
01:17:26,720 --> 01:17:29,120
And can we explain the difference through the process

2075
01:17:29,120 --> 01:17:30,960
rather than assumptions about people?

2076
01:17:30,960 --> 01:17:33,280
The data model lets the team answer those questions

2077
01:17:33,280 --> 01:17:35,120
without rebuilding the story each week.

2078
01:17:35,120 --> 01:17:37,520
A process engineer can look at the relevant runs,

2079
01:17:37,520 --> 01:17:39,280
a planner can explain the sequence change

2080
01:17:39,280 --> 01:17:41,360
and maintenance can add equipment context

2081
01:17:41,360 --> 01:17:44,320
while the supervisor confirms whether the method worked on the floor.

2082
01:17:44,320 --> 01:17:46,000
That's PDCA in normal operations.

2083
01:17:46,000 --> 01:17:48,160
The monthly review serves a different purpose.

2084
01:17:48,160 --> 01:17:49,600
It should look for changes

2085
01:17:49,600 --> 01:17:51,920
that need to become part of the system around the work,

2086
01:17:51,920 --> 01:17:54,000
not just part of one team's memory.

2087
01:17:54,000 --> 01:17:55,760
Standard work might need revision,

2088
01:17:55,760 --> 01:17:58,400
a planning rule might keep causing avoidable disruption,

2089
01:17:58,400 --> 01:18:01,280
or a maintenance pattern might point to a recurring condition

2090
01:18:01,280 --> 01:18:03,200
short term fixes can't solve.

2091
01:18:03,200 --> 01:18:05,600
Master data belongs in this discussion, too.

2092
01:18:05,600 --> 01:18:07,120
If the plant changes a routing,

2093
01:18:07,120 --> 01:18:09,120
target rate, resource relationship,

2094
01:18:09,120 --> 01:18:10,720
or approved setup method,

2095
01:18:10,720 --> 01:18:13,440
the records that support improvement need to change with it.

2096
01:18:13,440 --> 01:18:15,680
Otherwise teams keep checking performance against

2097
01:18:15,680 --> 01:18:18,240
a process definition that no longer matches production.

2098
01:18:18,240 --> 01:18:20,560
The monthly review should also ask whether lessons

2099
01:18:20,560 --> 01:18:22,480
from one area apply elsewhere,

2100
01:18:22,480 --> 01:18:25,200
not every countermeasure should spread plant-wide.

2101
01:18:25,200 --> 01:18:27,920
A method that works on one line may depend on a tool,

2102
01:18:27,920 --> 01:18:29,680
product range, or crew structure

2103
01:18:29,680 --> 01:18:31,200
that doesn't exist on another line.

2104
01:18:31,200 --> 01:18:32,960
Still, the factory shouldn't rediscover

2105
01:18:32,960 --> 01:18:34,720
the same lesson in isolation.

2106
01:18:34,720 --> 01:18:37,120
This rhythm works best when definitions stay consistent

2107
01:18:37,120 --> 01:18:39,120
from the shop floor through plant management

2108
01:18:39,120 --> 01:18:41,760
even though each group sees a different level of detail.

2109
01:18:41,760 --> 01:18:43,360
An operator needs the current condition

2110
01:18:43,360 --> 01:18:44,800
in the agreed next step,

2111
01:18:44,800 --> 01:18:47,360
a team leader needs open actions and recurring patterns,

2112
01:18:47,360 --> 01:18:49,040
and a plant manager needs to see

2113
01:18:49,040 --> 01:18:52,720
whether repeated losses affect service, flow, quality, or cost.

2114
01:18:52,720 --> 01:18:54,480
Same facts, different questions.

2115
01:18:54,480 --> 01:18:56,400
That consistency prevents a familiar problem

2116
01:18:56,400 --> 01:18:58,400
where the shift meeting discusses one number,

2117
01:18:58,400 --> 01:19:00,160
the weekly lean meeting uses another,

2118
01:19:00,160 --> 01:19:02,800
and management sees a third version after the month closes.

2119
01:19:03,520 --> 01:19:06,320
Once that happens, people spend energy reconciling reports

2120
01:19:06,320 --> 01:19:07,520
instead of fixing work.

2121
01:19:07,520 --> 01:19:09,840
Data should show up where decisions get made.

2122
01:19:09,840 --> 01:19:12,000
A production team shouldn't wait days for a report

2123
01:19:12,000 --> 01:19:14,080
to learn a trial caused a new quality loss,

2124
01:19:14,080 --> 01:19:16,080
and a planner shouldn't discover at month end

2125
01:19:16,080 --> 01:19:18,960
that repeated re-sequencing drove avoidable changeovers,

2126
01:19:18,960 --> 01:19:20,880
and improvement team shouldn't need to request

2127
01:19:20,880 --> 01:19:22,720
a fresh extract every time it wants to check

2128
01:19:22,720 --> 01:19:23,920
an open countermeasure.

2129
01:19:23,920 --> 01:19:25,840
The right cadence turns operational data

2130
01:19:25,840 --> 01:19:27,520
into a working memory for the plant.

2131
01:19:27,520 --> 01:19:29,040
It also creates discipline.

2132
01:19:29,040 --> 01:19:30,560
A condition enters the shift review,

2133
01:19:30,560 --> 01:19:32,640
moves into a weekly check when it repeats,

2134
01:19:32,640 --> 01:19:34,560
and reaches the monthly level when the standard

2135
01:19:34,560 --> 01:19:37,520
planning rule or system definition needs to change.

2136
01:19:37,520 --> 01:19:39,600
Not every issue travels that far,

2137
01:19:39,600 --> 01:19:40,560
and that's fine.

2138
01:19:40,560 --> 01:19:42,240
What matters is that the factory doesn't wait

2139
01:19:42,240 --> 01:19:45,280
for a workshop to end before it starts learning again.

2140
01:19:45,280 --> 01:19:47,120
Measures that drive better questions.

2141
01:19:47,120 --> 01:19:49,840
Once you have that review rhythm,

2142
01:19:49,840 --> 01:19:51,120
the next question is,

2143
01:19:51,120 --> 01:19:53,040
which measures deserve a spot in it?

2144
01:19:53,040 --> 01:19:54,480
Factories can measure almost anything now,

2145
01:19:54,480 --> 01:19:55,680
but that doesn't mean every number

2146
01:19:55,680 --> 01:19:58,400
deserves a place in a shift review or a kaizen effort.

2147
01:19:58,400 --> 01:20:01,280
A measure earns its place when it helps someone see a condition,

2148
01:20:01,280 --> 01:20:02,320
make a decision,

2149
01:20:02,320 --> 01:20:04,400
and check whether that decision changed the work.

2150
01:20:04,400 --> 01:20:06,160
Start with safety and quality.

2151
01:20:06,160 --> 01:20:07,840
If a proposed improvement shortens a setup

2152
01:20:07,840 --> 01:20:10,160
but introduces a safety risk or raises defects,

2153
01:20:10,160 --> 01:20:12,240
the time-save doesn't count as progress.

2154
01:20:12,240 --> 01:20:15,200
Delivery, flow, cost, and resource use all matter,

2155
01:20:15,200 --> 01:20:16,640
but they sit behind the conditions

2156
01:20:16,640 --> 01:20:18,080
that protect people and product.

2157
01:20:18,080 --> 01:20:20,000
That order keeps the conversation grounded

2158
01:20:20,000 --> 01:20:21,280
when pressure builds.

2159
01:20:21,280 --> 01:20:23,360
The next distinction is between outcome measures

2160
01:20:23,360 --> 01:20:24,720
and process measures.

2161
01:20:24,720 --> 01:20:26,400
An outcome measure tells you whether the factory

2162
01:20:26,400 --> 01:20:28,080
achieved something people care about,

2163
01:20:28,080 --> 01:20:29,520
orders, shipped on time,

2164
01:20:29,520 --> 01:20:31,840
accepted output, lead time, or scrap.

2165
01:20:31,840 --> 01:20:33,040
It tells you where to look,

2166
01:20:33,040 --> 01:20:35,120
but it may not tell a team what it can change

2167
01:20:35,120 --> 01:20:36,320
during the next shift.

2168
01:20:36,320 --> 01:20:38,480
A process measure sits closer to the work.

2169
01:20:38,480 --> 01:20:40,080
For a change over improvement effort,

2170
01:20:40,080 --> 01:20:42,480
the outcome might be whether the next order starts

2171
01:20:42,480 --> 01:20:45,600
on time and reaches acceptable output without excess loss.

2172
01:20:45,600 --> 01:20:48,000
Process measures could include whether tools arrived

2173
01:20:48,000 --> 01:20:49,680
before the prior order ended,

2174
01:20:49,680 --> 01:20:51,280
whether the setup followed the method

2175
01:20:51,280 --> 01:20:53,440
or how long the line spent in transition.

2176
01:20:53,440 --> 01:20:56,000
Those measures give the team handles on the process.

2177
01:20:56,000 --> 01:20:56,880
You need both.

2178
01:20:56,880 --> 01:20:58,720
If a team tracks only setup steps,

2179
01:20:58,720 --> 01:21:00,480
it gets good at completing a checklist

2180
01:21:00,480 --> 01:21:02,320
while the delivery problem remains.

2181
01:21:02,320 --> 01:21:04,240
But if it tracks only delivery,

2182
01:21:04,240 --> 01:21:07,040
it sees the result after the chance to act is gone.

2183
01:21:07,040 --> 01:21:08,880
A useful measure connects the two.

2184
01:21:08,880 --> 01:21:11,040
Each measure should come with a few plain answers

2185
01:21:11,040 --> 01:21:12,720
who owns the decision it supports.

2186
01:21:12,720 --> 01:21:14,320
What action follows when it changes,

2187
01:21:14,320 --> 01:21:16,080
which system supplies the record?

2188
01:21:16,080 --> 01:21:17,600
What does the measure mean exactly?

2189
01:21:17,600 --> 01:21:18,960
And when will the team review it?

2190
01:21:18,960 --> 01:21:20,160
Without those answers,

2191
01:21:20,160 --> 01:21:22,880
measures pile up because someone once asked for them,

2192
01:21:22,880 --> 01:21:24,800
the report gets longer, the meeting gets slower,

2193
01:21:24,800 --> 01:21:26,640
and nobody wants to remove a number

2194
01:21:26,640 --> 01:21:28,640
because it might be politically dangerous.

2195
01:21:28,640 --> 01:21:30,560
That's how reporting turns into storage.

2196
01:21:30,560 --> 01:21:32,880
Take a daily measure like downtime minutes.

2197
01:21:32,880 --> 01:21:34,720
It sounds simple until a supervisor asks

2198
01:21:34,720 --> 01:21:36,080
what action should follow.

2199
01:21:36,080 --> 01:21:37,840
If the number includes planned cleaning,

2200
01:21:37,840 --> 01:21:39,760
changeovers, waiting for material,

2201
01:21:39,760 --> 01:21:41,440
equipment faults and a line stopped

2202
01:21:41,440 --> 01:21:43,040
because quality plays the hold,

2203
01:21:43,040 --> 01:21:44,400
it has very little direction.

2204
01:21:44,400 --> 01:21:46,160
You can still record total downtime,

2205
01:21:46,160 --> 01:21:47,520
but the team needs categories

2206
01:21:47,520 --> 01:21:49,040
that match different response paths.

2207
01:21:49,040 --> 01:21:50,800
An equipment fault goes to maintenance,

2208
01:21:50,800 --> 01:21:53,520
a missing material condition goes to planning or logistics,

2209
01:21:53,520 --> 01:21:56,320
and a repeated setup delay enters a PDCA cycle.

2210
01:21:56,320 --> 01:21:57,360
The measure becomes useful

2211
01:21:57,360 --> 01:21:58,880
when the team can move from the number

2212
01:21:58,880 --> 01:22:00,480
to the kind of decision it needs.

2213
01:22:00,480 --> 01:22:02,080
This also applies to OEE.

2214
01:22:02,080 --> 01:22:05,440
OEE can help a team notice a change in availability,

2215
01:22:05,440 --> 01:22:06,880
performance or quality,

2216
01:22:06,880 --> 01:22:08,720
but it should lead to a more specific question,

2217
01:22:08,720 --> 01:22:10,080
not end the discussion.

2218
01:22:10,080 --> 01:22:12,560
If OEE drops, ask which loss moved,

2219
01:22:12,560 --> 01:22:14,080
where it appeared in the process,

2220
01:22:14,080 --> 01:22:16,320
and whether the team has a response it can test.

2221
01:22:16,320 --> 01:22:19,120
Otherwise, OEE becomes a score people defend.

2222
01:22:19,120 --> 01:22:20,240
Leading signals can help,

2223
01:22:20,240 --> 01:22:21,840
but they need some humility.

2224
01:22:21,840 --> 01:22:23,120
A rising number of short stops

2225
01:22:23,120 --> 01:22:25,120
may warn of a worsening machine condition,

2226
01:22:25,120 --> 01:22:28,240
a growing cue before inspection may warn of rising lead time,

2227
01:22:28,240 --> 01:22:31,440
and a missed pre-stage check may warn of a long change over,

2228
01:22:31,440 --> 01:22:32,640
those signals point to risk,

2229
01:22:32,640 --> 01:22:34,400
but they don't predict every outcome.

2230
01:22:34,400 --> 01:22:35,680
Teams often damage trust

2231
01:22:35,680 --> 01:22:37,840
when they treat a leading signal like a promise.

2232
01:22:37,840 --> 01:22:39,120
It should trigger a check,

2233
01:22:39,120 --> 01:22:40,720
not replace judgment,

2234
01:22:40,720 --> 01:22:41,920
and help people act earlier

2235
01:22:41,920 --> 01:22:42,720
while they understand

2236
01:22:42,720 --> 01:22:44,640
that production contains variation,

2237
01:22:44,640 --> 01:22:46,480
exceptions, and conditions

2238
01:22:46,480 --> 01:22:48,960
no single measure can capture.

2239
01:22:48,960 --> 01:22:50,800
Use measures to ask better questions,

2240
01:22:50,800 --> 01:22:53,040
not to pretend uncertainty disappeared.

2241
01:22:53,040 --> 01:22:54,240
Good improvement programs

2242
01:22:54,240 --> 01:22:55,360
need another discipline.

2243
01:22:55,360 --> 01:22:57,840
Retire measures when they stop driving a real decision.

2244
01:22:57,840 --> 01:22:59,600
A metric might help during a trial,

2245
01:22:59,600 --> 01:23:02,480
but lose its purpose once the method becomes normal work,

2246
01:23:02,480 --> 01:23:04,560
while another stays on a management report

2247
01:23:04,560 --> 01:23:06,400
long after the process changed.

2248
01:23:06,400 --> 01:23:08,640
Keeping it forever doesn't make the plant more controlled,

2249
01:23:08,640 --> 01:23:10,560
it just makes attention harder to find.

2250
01:23:10,560 --> 01:23:12,000
When a team removes a measure,

2251
01:23:12,000 --> 01:23:13,920
it should be able to explain why.

2252
01:23:13,920 --> 01:23:16,000
Maybe the decision moved into standard work,

2253
01:23:16,000 --> 01:23:18,080
a different measure now gives a clearer signal,

2254
01:23:18,080 --> 01:23:21,440
or the source data no longer represents the process after a change.

2255
01:23:21,440 --> 01:23:22,560
That's not losing information,

2256
01:23:22,560 --> 01:23:24,800
it's keeping the improvement loop focused on work people

2257
01:23:24,800 --> 01:23:26,080
can actually influence.

2258
01:23:26,080 --> 01:23:28,240
And once measures shape real decisions,

2259
01:23:28,240 --> 01:23:29,760
the quality of the underlying data

2260
01:23:29,760 --> 01:23:31,360
stops being an IT concern

2261
01:23:31,360 --> 01:23:33,280
and becomes part of how the plant runs.

2262
01:23:33,280 --> 01:23:35,040
Data quality is part of standard work.

2263
01:23:35,040 --> 01:23:37,360
Here's how it really works.

2264
01:23:37,360 --> 01:23:39,040
Once a measure drives a real decision,

2265
01:23:39,040 --> 01:23:40,800
the team has to trust the event behind it.

2266
01:23:40,800 --> 01:23:44,240
That means data quality becomes part of normal factory work,

2267
01:23:44,240 --> 01:23:46,800
not some cleanup project IT checks once a quarter.

2268
01:23:46,800 --> 01:23:48,640
Think about a downtime record for a second.

2269
01:23:48,640 --> 01:23:51,200
A line stops and someone has to pick a reason close enough

2270
01:23:51,200 --> 01:23:53,440
that the next review can follow the right path.

2271
01:23:53,440 --> 01:23:55,520
Choosing other keeps the screen moving,

2272
01:23:55,520 --> 01:23:57,520
but it tells the next team almost nothing.

2273
01:23:57,520 --> 01:23:59,920
Reason codes need to match how work actually happens.

2274
01:23:59,920 --> 01:24:02,160
If operators can't find the right code quickly,

2275
01:24:02,160 --> 01:24:04,320
the list is too long, the wording is unclear,

2276
01:24:04,320 --> 01:24:07,280
or the system asks for detail nobody can know at that moment.

2277
01:24:07,280 --> 01:24:08,640
So don't blame the operator.

2278
01:24:08,640 --> 01:24:11,120
Study the reporting step like any other work step.

2279
01:24:11,120 --> 01:24:14,160
Ask what the person saw and what information was available

2280
01:24:14,160 --> 01:24:15,840
then make the choice practical.

2281
01:24:15,840 --> 01:24:17,280
A useful reason code structure

2282
01:24:17,280 --> 01:24:18,960
starts broad for rapid entry

2283
01:24:18,960 --> 01:24:21,600
and allows more detail after the immediate issue passes.

2284
01:24:21,600 --> 01:24:23,440
An operator records an equipment stop

2285
01:24:23,440 --> 01:24:25,520
and maintenance later classifies the failure mode

2286
01:24:25,520 --> 01:24:26,640
when evidence supports it.

2287
01:24:26,640 --> 01:24:28,720
That preserves the first fact without forcing a guest

2288
01:24:28,720 --> 01:24:29,920
during a busy recovery.

2289
01:24:29,920 --> 01:24:31,840
The same thinking applies to timestamps.

2290
01:24:31,840 --> 01:24:34,720
A late transaction doesn't mean somebody ignored the process.

2291
01:24:34,720 --> 01:24:36,720
The operator might need to secure the machine,

2292
01:24:36,720 --> 01:24:39,280
contain a quality issue, help with a changeover,

2293
01:24:39,280 --> 01:24:42,320
and only get to the mess entry after production settles.

2294
01:24:42,320 --> 01:24:45,360
If the improvement team uses the entry time as the event time,

2295
01:24:45,360 --> 01:24:47,600
the analysis places the loss in the wrong order.

2296
01:24:47,600 --> 01:24:49,840
The system should capture what it can automatically

2297
01:24:49,840 --> 01:24:51,680
and make clear what each time means.

2298
01:24:51,680 --> 01:24:54,320
Machine signals bring their own data quality problems.

2299
01:24:54,320 --> 01:24:57,360
A sensor can drift, a communication link can drop records,

2300
01:24:57,360 --> 01:24:59,600
and a PLC tag can change after an upgrade

2301
01:24:59,600 --> 01:25:02,240
while the reporting layer still expects the old meaning.

2302
01:25:02,240 --> 01:25:05,280
The value keeps arriving, which makes the problem harder to spot.

2303
01:25:05,280 --> 01:25:08,400
It looks like data, but it doesn't describe the process anymore.

2304
01:25:08,400 --> 01:25:11,120
That's why checks need to run as part of the operating routine.

2305
01:25:11,120 --> 01:25:13,920
Compare expected cycle patterns with recorded events,

2306
01:25:13,920 --> 01:25:18,080
flag impossible sequences like accepted quantity without a related operation,

2307
01:25:18,080 --> 01:25:20,720
check if a stopped machine reports production at the same time

2308
01:25:20,720 --> 01:25:23,760
and review gaps after maintenance or control changes.

2309
01:25:23,760 --> 01:25:26,240
These checks don't need to create a blame exercise.

2310
01:25:26,240 --> 01:25:28,320
A data defect is a process defect.

2311
01:25:28,320 --> 01:25:31,200
Something in the method, system, interface, or definition

2312
01:25:31,200 --> 01:25:33,280
let the record drift away from the work.

2313
01:25:33,280 --> 01:25:35,600
The team needs to find that cause, correct it,

2314
01:25:35,600 --> 01:25:37,040
and prevent it from returning.

2315
01:25:37,040 --> 01:25:38,720
Picture an engineer reviewing a trial

2316
01:25:38,720 --> 01:25:41,920
and noticing that the MES claims a line-rangering period

2317
01:25:41,920 --> 01:25:43,200
when everyone knows it was down.

2318
01:25:43,200 --> 01:25:45,360
That person needs a simple path to raise the issue,

2319
01:25:45,360 --> 01:25:47,600
attach the evidence, and get a response from the team

2320
01:25:47,600 --> 01:25:49,680
responsible for the source or integration.

2321
01:25:49,680 --> 01:25:52,720
If the only option is an informal message to someone in IT,

2322
01:25:52,720 --> 01:25:55,440
the defect sits there, the next report reuses it,

2323
01:25:55,440 --> 01:25:57,680
and people slowly stop trusting the whole model.

2324
01:25:57,680 --> 01:25:59,440
Feedback has to travel both ways.

2325
01:25:59,440 --> 01:26:01,520
When a data owner changes a reason code list,

2326
01:26:01,520 --> 01:26:04,080
interface, resource name, or calculation rule,

2327
01:26:04,080 --> 01:26:06,800
affected users need to know what changed and when.

2328
01:26:06,800 --> 01:26:08,560
And when production sees a mismatch,