AI In
Manufacturing
Playbook
A Practical Guide to Cutting
Costs and Downtime with
Predictive Maintenance,
Computer Vision, Demand
Forecasting, Scheduling, and
Energy AI
Pruthvi Panchal
MANUFACTURING & OPERATIONS
AI In Manufacturing
Playbook
Author
:
Pruthvi
Panchal
© 2026
Pruthvi
Panchal
.
All
rights
reserved
.
No
part
of
this
publication
may
be
reproduced
,
stored
in
a
retrieval
system
,
or
transmitted
in
any
form
or
by
any
means
without
prior
written
permission
from
the
author
,
except
for
brief
quotations
used
in
reviews
or
educational
references
.
Disclaimer
:
The
information
provided
in
this
book
is
for
educational
purposes
only
and
does
not
constitute
engineering
,
financial
,
or
operational
advice
specific
to
any
facility
.
Table of Contents
Introduction: Introduction
....................................................................................................................
Page
Chapter 1: Predictive Maintenance for Downtime
....................................................................................................................
Page
Chapter 2: Defect Detection with Computer Vision
....................................................................................................................
Page
Chapter 3: Forecast Supply with Demand Signals
....................................................................................................................
Page
Chapter 4: Optimize Scheduling with Constraint AI
....................................................................................................................
Page
Chapter 5: Energy Cost Reduction with AI
....................................................................................................................
Page
Final Thoughts: From Reacting to Running an AI-Assisted Control Loop
....................................................................................................................
Page
Y
B E F O R E YO U B E G I N
Introduction
ou
'
re
looking
to
cut
manufacturing
downtime
and
costs
without
betting
your
operation
on
vague
experiments
.
If
you
'
ve
already
tried
spreadsheets
,
alerts
,
or
one
-
off
automation
,
you
know
the
hard
part
isn
'
t
wanting
better
results
-
it
'
s
turning
data
into
decisions
on
a
repeatable
schedule
.
This
book
gives
you
a
clear
,
step
-
by
-
step
way
to
apply
AI
where
it
matters
most
,
from
seeing
problems
before
they
stop
production
to
planning
work
and
energy
with
confidence
.
You
'
ll
walk
through
the
practical
playbook
behind
AI
In
Manufacturing
Playbook
:
predictive
maintenance
,
defect
detection
with
computer
vision
,
demand
-
aware
supply
forecasting
,
constraint
-
based
scheduling
,
and
energy
cost
reduction
.
WHAT YOU'LL BUILD
Five
connected
capabilities
:
a
failure
forecast
that
turns
sensor
data
into
repair
plans
,
a
defect
triage
loop
that
stops
scrap
before
it
spreads
,
a
supply
model
that
fuses
demand
with
supplier
risk
,
a
constraint
-
aware
scheduler
that
protects
throughput
,
and
an
energy
forecast
that
targets
peak
demand
before
it
gets
expensive
.
I
PA RT 1 : R E D U C I N G U N P L A N N E D D O W N T I M E
Predictive Maintenance for
Downtime
f
you
only
react
after
a
machine
stops
,
you
accept
the
worst
timing
:
you
fix
damage
after
it
grows
,
you
hunt
for
parts
when
lead
times
hurt
,
and
you
reshuffle
work
because
production
already
slipped
.
Your
equipment
usually
gives
clues
earlier
-
vibration
shifts
,
heat
changes
,
motor
current
drift
,
oil
quality
decay
,
cycle
irregularity
,
and
repeated
micro
-
stops
.
The
question
is
whether
you
turn
those
clues
into
a
repair
plan
before
the
stop
happens
.
This
chapter
delivers
a
hands
-
on
approach
to
forecasting
breakdowns
using
sensor
data
and
failure
patterns
,
then
scheduling
repairs
with
confidence
,
using
the
3-
Layer
Failure
Forecast
.
The 3-Layer Failure Forecast: Signals
→
Patterns
→
Actions
Your
AI
system
should
not
start
with
a
prediction
label
like
"
will
fail
."
It
should
start
with
the
smallest
truth
you
can
measure
reliably
.
Layer
1 -
Signals
.
Collect
raw
or
near
-
raw
readings
that
reflect
the
machine
'
s
condition
:
vibration
amplitude
,
bearing
temperature
,
motor
current
,
hydraulic
pressure
,
oil
contamination
.
You
don
'
t
need
every
signal
-
you
need
the
ones
your
equipment
actually
changes
as
it
approaches
failure
.
Layer
2 -
Patterns
.
Convert
signals
into
failure
-
related
behavior
:
trends
,
repeatable
signatures
,
or
"
shape
changes
"
that
show
up
before
breakdown
.
Instead
of
asking
"
what
'
s
wrong
right
now
,"
ask
"
how
does
this
machine
behave
as
it
moves
toward
failure
?"
"Your machine didn't fail randomly - so why do you treat it like it did?"
Layer
3 -
Actions
.
Translate
the
pattern
into
a
maintenance
decision
-
inspect
,
replace
,
schedule
shutdown
,
tighten
alignment
,
change
oil
,
or
monitor
more
frequently
-
tied
to
a
time
window
and
a
confidence
level
so
technicians
know
what
to
do
and
when
.
Choosing Sensor Inputs That Actually Reflect Failure
Start
with
the
failure
history
you
already
have
.
Look
at
your
last
stoppages
and
write
down
what
each
failure
typically
changes
:
heat
,
load
,
friction
,
lubrication
quality
,
alignment
,
fluid
flow
,
or
mechanical
clearance
.
Then
map
those
changes
to
signals
you
can
measure
.
For
motor
-
driven
machines
,
vibration
and
motor
current
often
reveal
load
changes
and
bearing
issues
.
For
hydraulic
systems
,
pressure
stability
and
flow
behavior
show
internal
wear
.
For
gearboxes
,
temperature
plus
vibration
frequency
content
surfaces
gear
mesh
damage
early
.
Pick
signals
that
meet
three
rules
:
Confirm
you
log
time
consistently
,
capture
enough
samples
during
real
operation
,
and
don
'
t
mix
readings
from
different
operating
modes
without
labeling
them
-
otherwise
your
patterns
will
learn
"
normal
mode
changes
"
as
if
they
were
failure
.
PRACTICAL TAKEAWAY
Build
your
predictive
maintenance
plan
around
Signals
→
Patterns
→
Actions
,
not
around
a
single
prediction
number
you
can
'
t
act
on
.
They
change
before
the
breakdown
-
not
only
at
the
moment
the
machine
stops
.
â–¸
They
stay
measurable
across
normal
operations
,
without
constant
drift
or
dropout
.
â–¸
They
connect
to
a
maintenance
action
,
not
just
"
interesting
data
."
â–¸
Turning Sensor Data Into Failure Patterns
For
each
known
failure
event
,
pull
the
sensor
history
leading
up
to
it
.
Mark
a
"
before
"
window
(
how
far
back
you
want
to
detect
)
and
a
"
near
"
window
(
how
close
to
failure
you
want
the
strongest
signal
).
Compare
these
against
normal
runs
from
similar
operating
conditions
,
and
test
whether
a
trend
or
signature
strengthens
as
failure
approaches
-
you
can
start
with
simple
rule
-
based
thresholds
before
training
a
full
model
.
When
you
train
,
keep
it
practical
:
train
per
asset
type
or
machine
family
,
include
operating
mode
context
(
speed
/
load
),
and
validate
on
failures
the
model
hasn
'
t
seen
.
Finally
,
calibrate
the
raw
model
score
into
a
decision
-
friendly
risk
band
that
maps
directly
to
Layer
3
actions
.
Scheduling Repairs From Predictions
Predictions
don
'
t
reduce
downtime
unless
they
change
what
you
schedule
.
Define
a
small
set
of
action
rules
tied
to
risk
levels
and
time
windows
:
FIELD EXAMPLE - TANYA, PLANT MAINTENANCE SUPERVISOR
Tanya
managed
a
line
where
a
gearbox
-
driven
unit
often
failed
"
without
warning
."
Technicians
had
been
changing
parts
based
on
hours
,
not
condition
.
By
aligning
sensor
timelines
with
work
orders
,
her
team
found
that
vibration
temperature
and
vibration
energy
drifted
and
spiked
in
the
same
window
before
every
breakdown
.
They
trained
a
failure
pattern
model
for
that
gearbox
class
and
calibrated
the
risk
band
to
trigger
earlier
inspection
while
the
machine
still
ran
reliably
.
The
change
wasn
'
t
the
AI
itself
-
it
was
tying
machine
behavior
to
the
maintenance
record
precisely
enough
to
learn
the
real
failure
-
approach
pattern
.
Low
risk
-
continue
run
-
to
-
plan
and
collect
more
data
.
â–¸
Medium
risk
-
schedule
inspection
during
the
next
planned
maintenance
window
.
â–¸
High
risk
-
plan
a
corrective
repair
at
the
next
feasible
shutdown
and
prepare
parts
.
â–¸
Critical
risk
-
request
immediate
intervention
if
safety
or
catastrophic
failure
risk
rises
.
â–¸
Connect
every
flagged
risk
band
to
a
work
order
with
the
evidence
summary
(
which
signals
and
pattern
features
drove
it
)
and
the
recommended
time
window
-
and
close
the
loop
by
recording
what
you
found
after
every
repair
,
so
misses
and
near
-
misses
keep
improving
your
labels
.
QUICK ACTION STEP
Pick
one
critical
asset
with
frequent
downtime
.
Collect
2–4
months
of
sensor
data
plus
work
order
timestamps
.
Match
each
breakdown
to
a
labeled
failure
event
and
pull
the
"
before
"
window
.
Test
whether
signals
repeat
in
failure
-
approach
windows
.
Train
and
calibrate
a
pattern
model
,
set
risk
bands
,
and
create
action
rules
that
open
work
orders
.
After
the
first
planned
repair
,
log
what
you
found
and
update
your
labels
.
CLOSING THOUGHT
Predictive
maintenance
becomes
real
when
actions
get
scheduled
.
When
your
AI
forecast
stops
being
a
dashboard
and
starts
becoming
a
work
-
order
plan
,
downtime
drops
because
you
stopped
guessing
-
you
learned
what
failure
looks
like
in
your
signals
,
converted
it
into
patterns
your
team
trusts
,
and
scheduled
actions
while
the
machine
still
gave
you
time
.
O
PA R T 2 : C U T T I N G S C R A P A N D R E W O R K
Defect Detection with Computer
Vision
ne
damaged
part
can
trigger
a
chain
reaction
:
the
line
slows
for
inspection
,
workers
rework
,
packaging
gets
reprinted
,
and
the
shipment
slips
.
In
many
mechanical
plants
,
defect
-
driven
rework
and
scrap
quietly
outspend
"
real
downtime
,"
because
defects
show
up
after
the
value
has
already
been
added
-
during
assembly
,
at
final
inspection
,
or
even
in
the
customer
return
window
.
The
fastest
way
to
cut
that
cost
is
to
stop
treating
defects
like
a
paperwork
problem
and
start
treating
them
like
a
visual
detection
problem
,
using
the
Defect
Triage
Loop
.
The Defect Triage Loop: Detect
→
Classify
→
Contain
Detect
.
Your
camera
system
and
lighting
capture
images
from
a
known
position
and
distance
,
and
the
AI
flags
"
something
looks
wrong
"
based
on
visual
patterns
.
Classify
.
Don
'
t
stop
at
"
defect
/
no
defect
."
Label
what
kind
of
defect
it
is
-
surface
scratch
vs
.
missing
material
vs
.
misalignment
vs
.
wrong
component
-
because
your
containment
decision
depends
on
the
label
.
FIELD EXAMPLE - LUIS, QUALITY MANAGER, PRECISION PARTS
Luis
'
s
real
pain
wasn
'
t
that
defects
happened
-
it
was
that
they
didn
'
t
show
up
consistently
.
Surface
flaws
and
assembly
defects
popped
up
in
clusters
after
a
tooling
change
or
a
shift
handoff
,
and
his
team
kept
catching
issues
late
,
then
spent
hours
tracing
which
machine
,
batch
,
or
operator
caused
it
.
Computer
vision
became
the
bottom
-
line
lever
:
detect
surface
flaws
and
assembly
defects
automatically
,
classify
them
the
same
way
every
time
,
and
contain
the
problem
before
it
spreads
.
Contain
.
The
system
routes
the
part
to
the
right
path
:
reject
,
rework
,
hold
the
lot
,
or
request
a
quick
human
check
for
borderline
cases
.
Detect: Build a Camera Setup That Finds Flaws Reliably
Computer
vision
fails
most
often
for
a
boring
reason
:
the
image
doesn
'
t
stay
consistent
.
Control
three
things
-
illumination
,
part
presentation
,
and
camera
angle
.
Lock
the
part
location
with
fixtures
,
keep
the
camera
fixed
,
and
design
lighting
that
highlights
the
defect
instead
of
hiding
it
.
Confirm
steady
brightness
and
sharpness
on
normal
parts
,
then
confirm
defect
pixels
stand
out
repeatably
on
known
-
defective
samples
.
Classify: Label Defects So Quality Can Take Action
Build
a
label
set
based
on
real
actions
,
not
vague
categories
.
For
surface
flaws
,
label
by
defect
type
and
location
.
For
assembly
defects
,
label
by
the
specific
failure
mode
:
missing
component
,
upside
-
down
part
,
offset
feature
,
wrong
orientation
,
or
incomplete
seating
.
Define
each
label
in
simple
,
unambiguous
language
-
if
two
people
can
look
at
the
same
image
and
disagree
,
your
training
data
will
reflect
that
confusion
.
Luis
tied
each
label
to
a
downstream
decision
:
reworkable
,
scrap
,
or
verify
-
the
same
paths
his
team
already
used
.
PRACTICAL TAKEAWAY
If
your
images
vary
more
than
your
defects
,
you
'
ll
chase
ghosts
.
Stabilize
light
and
placement
before
you
train
anything
.
Contain: Turn AI Decisions Into Hold, Reject, and Rework Paths
Containment
is
where
computer
vision
starts
cutting
money
.
Build
a
decision
policy
tied
to
classification
output
:
auto
-
reject
high
-
confidence
scrap
-
worthy
defects
,
route
reworkable
defects
to
the
correct
station
,
and
hold
borderline
cases
for
quick
human
verification
.
Add
lot
-
containment
logic
-
when
a
specific
defect
label
clusters
above
normal
rate
,
pause
and
check
fixture
wear
,
tooling
condition
,
and
the
last
shift
handoff
.
Quality Data Collection That Doesn't Waste Your Team's Time
Start
with
a
baseline
dataset
from
normal
production
,
then
collect
defect
images
from
confirmed
scrap
,
known
rework
outcomes
,
and
misses
from
your
current
inspection
process
.
Use
a
sampling
rule
so
rare
-
but
-
costly
defects
(
like
missing
components
)
still
get
enough
coverage
.
Keep
camera
settings
,
lighting
,
and
orientation
consistent
,
and
store
images
with
metadata
:
product
type
,
station
ID
,
time
window
,
and
the
human
-
confirmed
label
.
Deployment Checklist: Make Vision Live Without Surprises
WATCH FOR
A
vision
model
without
containment
logic
only
creates
extra
inspection
.
Add
routing
first
,
then
add
lot
holds
for
defect
clusters
.
Start
with
a
pilot
station
or
limited
product
run
,
in
"
assist
mode
"
first
.
â–¸
Track
disagreements
between
the
AI
and
inspectors
;
use
them
to
refine
labels
.
â–¸
Move
to
"
automation
mode
"
only
for
the
labels
you
trust
-
usually
scrap
decisions
first
.
â–¸
Run
a
per
-
shift
check
:
image
sharpness
plus
known
-
good
and
known
-
bad
reference
samples
.
â–¸
Document
containment
actions
so
operators
know
exactly
what
to
do
for
every
label
.
â–¸
CLOSE: MAKE DEFECT DETECTION PAY FOR ITSELF
Computer
vision
reduces
scrap
and
rework
when
you
connect
three
pieces
:
Detect
what
looks
wrong
,
Classify
it
into
labels
that
match
your
actions
,
and
Contain
the
outcome
so
defects
don
'
t
keep
flowing
.
Ask
yourself
:
do
you
already
have
a
clear
path
for
every
defect
label
the
AI
will
produce
?
If
yes
,
deploy
quickly
.
If
no
,
fix
containment
and
labeling
first
-
that
'
s
where
the
savings
show
up
.
Y
PA R T 3 : P R E D I C T I N G M AT E R I A L R I S K
Forecast Supply with Demand
Signals
our
next
production
shortage
won
'
t
start
with
a
dramatic
"
out
of
stock
"
alert
.
It
starts
quietly
-
sales
orders
pick
up
,
lead
times
drift
longer
,
and
a
supplier
quietly
moves
you
to
the
back
of
the
loading
queue
.
By
the
time
the
missing
material
shows
up
on
the
shop
floor
,
you
'
ve
already
paid
for
the
damage
in
expediting
fees
,
overtime
,
and
rescheduling
.
Build the Demand-Lead-Time Fusion Model
Fuse
what
you
expect
to
build
(
sales
orders
and
demand
plans
)
with
how
long
it
takes
to
get
the
parts
(
lead
-
time
history
and
supplier
performance
),
then
add
operational
signals
that
tell
you
whether
the
supplier
will
actually
hit
the
date
.
Define
a
demand
calendar
that
matches
your
release
cadence
-
weekly
or
daily
.
For
each
finished
product
,
map
sales
demand
to
component
quantities
using
your
bill
of
materials
,
so
the
output
is
a
clean
table
of
component
demand
by
date
.
FIELD EXAMPLE - PRIYA, SUPPLY CHAIN ANALYST
Priya
learned
this
after
one
late
shipment
of
a
machined
component
stopped
a
key
assembly
line
.
She
didn
'
t
need
a
magic
forecast
-
she
needed
a
repeatable
way
to
predict
material
needs
and
supplier
risk
early
,
using
signals
her
team
already
had
:
sales
demand
,
confirmed
lead
times
,
and
operational
status
.
That
'
s
exactly
what
the
Demand
-
Lead
-
Time
Fusion
Model
gives
you
.
Use
two
lead
-
time
concepts
:
planned
lead
time
(
what
you
promise
)
and
observed
lead
time
(
what
you
actually
get
,
calculated
as
receipt
date
minus
order
date
per
supplier
and
part
).
Compute
an
expected
arrival
date
for
each
requirement
by
subtracting
lead
time
from
the
need
date
-
if
expected
arrival
slips
past
your
need
date
,
treat
that
as
a
risk
event
.
Operational Signals: Forecasting "Current Reality"
Lead
-
time
history
forecasts
the
average
future
.
Operational
signals
forecast
current
reality
,
in
three
buckets
:
Priya
'
s
team
got
value
fast
tracking
one
signal
:
how
often
suppliers
changed
promised
dates
after
first
confirming
.
When
a
supplier
repeatedly
pushed
promises
later
,
that
became
an
early
sign
observed
lead
time
was
about
to
worsen
.
Score
risk
so
it
updates
as
new
information
arrives
-
increase
risk
when
progress
lags
,
decrease
risk
when
evidence
shows
movement
,
and
adjust
lead
-
time
expectations
when
execution
health
shows
repeated
slippage
.
Convert
internal
scores
into
plain
categories
your
team
can
act
on
:
Green
(
likely
on
time
),
Amber
(
needs
review
),
Red
(
likely
late
).
QUICK ACTION STEP
Create
a
component
-
level
demand
calendar
from
your
sales
plan
and
BOM
,
then
calculate
observed
lead
time
by
supplier
and
part
family
.
Output
expected
arrival
dates
and
mark
any
that
land
after
your
component
need
date
-
that
'
s
your
first
risk
list
.
Order
status
-
confirmed
,
released
,
in
production
,
shipped
,
received
.
â–¸
Execution
health
-
frequent
schedule
changes
,
high
backlog
,
partial
shipments
,
repeated
late
confirmations
.
â–¸
Inbound
evidence
-
tracking
updates
,
dispatch
scans
,
goods
-
in
completion
timing
.
â–¸
Factor In Your Own Flexibility
Supplier
risk
only
matters
when
it
collides
with
your
capacity
to
absorb
it
.
Feed
your
model
a
simple
"
coverage
"
view
-
on
-
hand
inventory
plus
open
incoming
quantities
-
so
teams
stop
chasing
every
risk
event
equally
and
instead
focus
on
what
your
buffer
can
'
t
cover
.
Close the Loop
Every
time
you
receive
material
,
record
what
happened
-
on
time
,
early
,
or
late
-
and
how
the
risk
category
looked
when
the
system
flagged
it
.
That
"
forecast
vs
.
reality
"
history
is
the
training
signal
that
improves
the
fusion
model
over
time
,
and
it
'
s
also
your
reality
check
:
if
Red
keeps
calling
parts
that
arrive
on
time
,
loosen
the
thresholds
;
if
Amber
regularly
slips
,
tighten
them
.
DATA HYGIENE
Standardize
supplier
names
and
part
numbers
before
you
trust
the
model
. "
Acme
Tools
Ltd
."
and
"
Acme
Tools
LLC
"
treated
as
different
suppliers
will
quietly
erase
your
learning
signal
.
QUICK ACTION STEP
Pick
10
suppliers
and
20
critical
components
.
Pull
purchase
order
status
timestamps
plus
dispatch
/
receipt
evidence
.
Build
a
risk
score
that
updates
daily
.
Review
the
top
Red
and
Amber
lines
each
morning
,
record
the
outcome
after
receipt
,
and
use
that
record
to
refine
your
thresholds
.
A
PA R T 4 : P R O T E C T I N G T H R O U G H P U T
Optimize Scheduling with
Constraint AI
schedule
doesn
'
t
fail
because
your
team
lacks
effort
.
It
fails
because
constraints
show
up
late
,
in
ways
spreadsheets
can
'
t
handle
cleanly
:
frequent
rescheduling
,
late
jobs
that
never
recover
,
and
changeovers
that
spike
because
the
plan
ignored
what
happens
between
runs
.
The Constraint Chessboard Scheduler Framework
Treat
scheduling
like
a
board
game
where
each
job
placement
must
follow
rules
.
The
AI
doesn
'
t
guess
a
best
schedule
-
it
searches
for
one
that
satisfies
your
constraints
and
optimizes
your
objective
,
usually
throughput
and
changeover
reduction
.
FIELD EXAMPLE - MARCUS, MACHINE SHOP OWNER
Marcus
would
watch
the
shop
floor
"
go
sideways
"
in
small
,
predictable
ways
every
Monday
:
a
job
slipped
because
a
tool
holder
wasn
'
t
back
yet
,
another
got
bumped
for
a
safety
check
,
and
suddenly
half
the
schedule
looked
wrong
.
He
needed
a
scheduling
system
that
respected
real
constraints
and
still
found
a
workable
plan
fast
enough
to
matter
-
the
Constraint
Chessboard
Scheduler
.
Define
the
objective
-
for
example
,
reduce
total
changeover
minutes
while
keeping
due
dates
feasible
.
â–¸
Define
the
board
-
the
time
buckets
and
machine
resources
the
schedule
covers
.
â–¸
Define
the
pieces
-
jobs
with
processing
times
,
setup
requirements
,
and
readiness
status
.
â–¸
Define
the
rules
-
the
constraints
the
scheduler
must
respect
.
â–¸
Capture Constraints That Actually Affect Changeover
Start
with
constraint
types
that
directly
drive
setup
work
:
job
-
to
-
machine
compatibility
,
tooling
and
setup
state
,
labor
and
operator
availability
,
maintenance
windows
,
and
quality
holds
.
Then
add
the
constraints
that
protect
due
dates
and
flow
:
release
dates
and
job
readiness
(
material
,
drawings
,
pre
-
operations
)
and
sequence
-
dependent
setups
(
setup
time
that
changes
depending
on
the
previous
job
type
).
Build the Chessboard Inputs
You
need
three
clean
input
tables
.
The
jobs
table
covers
processing
time
,
due
date
,
eligible
machines
,
and
setup
requirements
.
The
resource
and
time
slots
table
sets
your
horizon
and
a
consistent
granularity
-
don
'
t
mix
minute
-
level
precision
for
one
job
with
shift
-
level
assumptions
for
another
.
The
setup
cost
matrix
is
where
changeover
reduction
becomes
real
-
group
jobs
by
part
family
or
process
type
and
estimate
setup
time
between
families
if
you
can
'
t
measure
every
pair
exactly
.
Encode
readiness
so
jobs
only
enter
the
board
when
material
and
prerequisites
arrive
,
and
optimize
for
changeover
minutes
plus
lateness
penalties
,
not
makespan
alone
.
PRACTICAL TAKEAWAY
You
win
when
your
objective
matches
what
costs
you
money
:
changeover
time
and
missed
commitments
-
not
just
"
minimize
time
"
on
paper
.
QUICK ACTION STEP
Write
down
the
top
5
constraints
your
team
overrides
manually
each
week
.
For
each
one
,
specify
what
data
you
already
have
-
tool
readiness
timestamps
,
operator
shift
calendars
,
maintenance
windows
,
job
release
dates
-
then
turn
those
into
"
hard
"
or
"
soft
"
rules
for
the
scheduler
.
Run the Solver, Then Tighten It Like a Planner
Start
with
a
baseline
run
that
respects
hard
constraints
-
machine
eligibility
,
maintenance
blocking
,
operator
coverage
,
tooling
readiness
.
Then
review
the
schedule
against
a
changeover
-
focused
checklist
:
does
it
group
similar
work
to
reduce
setup
frequency
?
Does
it
avoid
"
tool
thrashing
"?
Do
transitions
fit
within
real
setup
windows
?
Does
it
respect
job
readiness
?
After
the
first
run
,
tighten
soft
constraints
-
preferences
like
minimizing
changeover
or
limiting
setups
per
day
-
and
add
stability
rules
so
a
single
job
change
doesn
'
t
reshuffle
the
whole
plan
.
Marcus's Workflow
Marcus
builds
a
setup
cost
proxy
grouped
by
process
type
and
tooling
family
,
loads
jobs
with
readiness
from
material
arrival
and
drawing
release
,
blocks
maintenance
windows
and
operator
coverage
as
hard
constraints
,
and
runs
the
solver
with
an
objective
that
prioritizes
changeover
minutes
while
penalizing
lateness
.
When
a
job
slips
,
he
updates
only
the
affected
constraints
and
reruns
-
rather
than
rebuilding
the
whole
plan
and
forcing
the
floor
to
relearn
it
.
What to Measure So the AI Stays Honest
Changeover
minutes
per
machine
per
day
-
whether
the
solver
actually
reduces
setup
churn
.
â–¸
Distinct
setups
per
shift
-
reveals
"
thrashing
"
even
when
total
minutes
look
acceptable
.
â–¸
Schedule
stability
-
how
often
the
plan
changes
after
first
approval
.
â–¸
Infeasible
start
attempts
-
job
starts
the
schedule
implies
that
you
can
'
t
actually
execute
.
â–¸
CLOSING THOUGHT
Marcus
learned
to
stop
asking
for
"
better
schedules
"
and
start
asking
for
"
schedules
that
obey
the
board
rules
."
When
AI
follows
your
real
constraints
,
you
cut
the
waste
that
keeps
showing
up
in
downtime
reports
and
cost
sheets
,
week
after
week
.
I
PA R T 5 : C O N T R O L L I N G E N E R G Y S P E N D
Energy Cost Reduction with AI
f
your
bills
surprise
you
,
your
factory
schedule
and
utility
meters
already
tell
the
truth
-
you
just
haven
'
t
turned
that
truth
into
decisions
.
The
goal
is
simple
:
predict
your
next
-
day
and
next
-
shift
energy
load
so
you
can
run
smarter
,
not
just
react
faster
.
Define Load in Plain Terms
For
most
mechanical
plants
,
load
means
total
kW
demand
(
how
much
power
you
pull
at
a
moment
)
and
kWh
consumption
(
how
much
energy
you
use
over
time
).
If
your
utility
charges
demand
fees
or
penalties
for
high
kW
peaks
,
kW
prediction
matters
most
.
If
your
biggest
pain
is
monthly
energy
spend
with
no
demand
spikes
,
kWh
optimization
matters
more
.
"Energy cost control starts with knowing what you will burn - before you burn it."
FIELD EXAMPLE - AISHA, SUSTAINABILITY & UTILITIES LEAD
Aisha
'
s
team
tried
to
"
reduce
energy
"
but
couldn
'
t
explain
why
one
week
looked
cheap
and
the
next
looked
brutal
-
the
machines
didn
'
t
just
run
more
,
they
ran
differently
.
AI
helped
by
building
a
predictive
model
using
both
operational
signals
(
production
plan
,
line
states
,
schedules
)
and
facility
signals
(
outdoor
temperature
,
compressed
air
patterns
,
time
-
of
-
day
effects
),
outputting
a
forecast
curve
of
expected
kW
by
hour
and
kWh
by
day
,
with
confidence
ranges
.
What to Feed the AI So It Can Predict Load
Pull
at
least
3–6
months
of
interval
data
(
hourly
or
15-
minute
billing
data
works
)
and
align
it
with
operational
states
:
which
lines
ran
,
how
many
shifts
you
staffed
,
and
whether
high
-
energy
steps
-
heat
treating
,
curing
,
forging
,
large
motor
loads
,
major
compressor
stages
-
happened
during
those
intervals
.
Add
operational
state
signals
(
line
running
vs
.
idle
,
production
plan
,
major
load
events
,
shift
schedule
)
and
facility
context
(
outdoor
temperature
,
day
-
of
-
week
and
time
-
of
-
day
effects
).
Validate the Forecast With a Method Your Team Trusts
You
don
'
t
need
perfect
accuracy
-
you
need
timing
alignment
.
Compare
predicted
vs
.
actual
hourly
demand
for
the
last
few
weeks
,
identify
the
actual
peak
intervals
,
and
check
whether
the
same
intervals
appear
in
the
predicted
curve
.
If
a
predicted
high
-
demand
day
matches
the
operational
plan
,
you
'
ve
captured
the
driver
;
if
not
,
you
likely
have
a
missing
operational
event
-
an
unlogged
machine
,
a
maintenance
mode
,
or
an
unplanned
weekend
run
.
Optimizing Machine Run Patterns
Predicting
load
tells
you
when
trouble
will
hit
.
Optimizing
run
patterns
tells
you
how
to
change
what
happens
in
those
windows
.
Start
-
up
surges
,
idle
consumption
,
warm
-
up
cycles
,
and
process
pacing
create
repeating
shapes
in
your
demand
curve
-
the
Peak
-
to
-
Plan
Energy
Playbook
maps
every
spike
back
to
the
run
pattern
that
caused
it
,
then
tests
small
adjustments
:
shifting
start
times
,
batching
similar
work
,
and
changing
pause
behavior
.
Watch
for
repeatable
behaviors
:
demand
spikes
right
after
start
-
ups
,
demand
dips
during
planned
pauses
that
then
rebound
,
and
"
ping
-
pong
"
behavior
where
machines
stop
and
restart
frequently
in
a
short
window
.
QUICK ACTION STEP - PREDICTION FIRST, THEN CONTROL
Build
an
hourly
energy
forecast
from
your
existing
meters
plus
simple
operational
signals
,
then
review
"
forecast
vs
.
actual
"
every
week
until
the
timing
errors
shrink
to
something
your
team
can
act
on
.
Targeting Peak Demand
Many
utility
structures
punish
high
kW
demand
more
than
they
punish
total
energy
use
,
so
peak
management
is
often
the
fastest
path
to
real
savings
.
Pull
your
utility
demand
billing
rules
,
identify
the
billing
window
,
and
translate
it
into
an
internal
peak
target
kW
value
-
even
an
approximate
one
based
on
your
recent
worst
hours
is
enough
to
drive
behavior
.
Then
identify
your
top
peak
reducers
:
intermittent
high
-
energy
processes
,
compressed
air
staging
,
and
HVAC
or
auxiliary
systems
that
don
'
t
scale
down
with
production
.
Execute Peak Plans With a Weekly Feedback Loop
When
a
peak
still
happens
,
inspect
the
plan
rather
than
the
model
-
you
'
ll
often
find
an
unplanned
run
,
a
maintenance
override
,
or
a
product
mix
change
you
didn
'
t
account
for
,
and
feed
that
gap
back
into
your
signal
mapping
.
QUICK ACTION STEP - PATTERN CONTROL
Identify
the
top
3
energy
-
driving
processes
on
each
line
,
then
test
small
run
-
pattern
changes
-
start
timing
,
batching
,
idle
handling
-
while
tracking
hourly
demand
and
output
.
Review
next
week
'
s
forecasted
peaks
by
hour
.
â–¸
Mark
the
likely
drivers
-
which
processes
or
systems
run
during
those
hours
.
â–¸
Decide
which
moves
you
can
make
-
shift
start
times
,
adjust
batching
,
change
staging
.
â–¸
Execute
the
plan
on
the
floor
with
clear
ownership
.
â–¸
Compare
actual
demand
to
the
peak
target
and
capture
what
worked
.
â–¸
CLOSING THOUGHT: MAKE ENERGY A REAL SCHEDULING VARIABLE
Energy
management
succeeds
when
you
treat
energy
like
a
production
variable
you
can
control
:
forecast
when
demand
will
rise
,
adjust
run
patterns
to
smooth
the
curve
,
and
target
peak
hours
to
avoid
the
most
expensive
moments
.
AI
gives
you
the
prediction
;
your
plant
gives
you
the
leverage
.
T
C L O S I N G T H E P L AY B O O K
From Reacting to Running an AI-
Assisted Control Loop
he
transformation
is
simple
:
move
from
reacting
to
failures
to
running
an
AI
-
assisted
control
loop
that
predicts
,
detects
,
plans
,
and
optimizes
-
so
problems
become
inputs
,
not
surprises
.
Apply
one
of
the
core
techniques
from
this
book
,
such
as
predictive
maintenance
with
failure
-
risk
forecasting
,
to
guide
maintenance
timing
and
reduce
unplanned
downtime
.
The
five
chapters
in
this
playbook
connect
:
predictive
maintenance
protects
uptime
,
defect
detection
protects
quality
cost
,
demand
-
lead
-
time
fusion
protects
supply
continuity
,
constraint
scheduling
protects
throughput
,
and
energy
forecasting
protects
margin
.
Each
one
follows
the
same
pattern
-
turn
raw
signals
into
decision
-
ready
output
,
then
connect
that
output
to
an
action
someone
on
your
floor
can
execute
.
START TODAY
Choose
one
line
,
one
loss
type
,
and
one
data
source
you
already
have
-
machine
sensor
logs
or
maintenance
history
.
Define
your
first
success
metric
:
downtime
minutes
per
week
,
or
cost
per
unit
.
In
the
next
7
days
,
map
the
data
to
the
Chapter
1
workflow
and
write
a
short
pilot
plan
detailed
enough
that
someone
else
could
run
it
with
you
.
FINAL THOUGHT
The plants that win with AI aren't the ones with the fanciest models. They're the ones that
build the tightest loop between data, decisions, and results - and keep tightening it,
week after week.