Lean Glossary of Terms
Lean Dictionary for Process Improvement
Definitions, formulas, and examples for lean manufacturing terms that are so important to Lean process improvement.
These are the exact formulas and definitions used in your Systems2win Excel templates. Download free trial templates
Table of Contents
Bookmark = TheThing
The Thing = the thing being processed
In a manufacturing, distribution, or retail environment, the thing is usually a physical product.
In a medical environment, the thing might be a patient.
In a back office, service, non-profit, or government environment, the thing might be a form.
Bookmark = LeadTime
Lead Time = the average time it takes for one unit of the thing
to go through the entire process — from start to finish —
including time waiting between sub-processes
Also known as "Throughput Time" or "Turnaround Time"
Lead Time = Sum of all Process Lead Times + Sum of all Queue Times between processes
In practice, the term "Lead Time" usually means "Production Lead Time",
but technically, there are several more subtle and exact types of Lead Time:
Production Lead Time
The time it takes to physically make or deliver the thing —
from the receipt of production authorization to customer delivery.
Order Lead Time
The time between a customer placing an order and receiving delivery.
Production Lead Time plus everything that happens before releasing
Work Authorization, and after the product leaves the shipping dock.
Time between receiving customer order and receiving payment.
(Order-toCash Time might be shorter or longer than Order Lead Time)
Time between receiving a customer request for quotation and receiving final payment.
(Of particular interest for engineer-to-order production environments)
Lead Time Calculator
The Lead Time Unit of Measure Converter
on your Systems2win Value Stream Mapping template
allows you at any time to quickly convert between
Working Days, Calendar Days, Hours, or Weeks.
Further understanding of Lead Time
If no sub-process has a Process Lead Time that needs extra time...
(for something like drying or curing or growing), then you can use this simplified Lead Time calculation...
Simplified Lead Time Calculation
Lead Time = Cycle Time x units of WIP x number of operations + queue time between processes
Cycle Time of 120 seconds x 1 unit of WIP x 1 operation + 0 queue time = Lead Time of 2 minutes
Cycle Time of 120 seconds x 100 units of WIP x 2 operations + 0 queue time = 400 minutes
WIP Increases Lead Time
Notice how the number of units of Work In Process (WIP) radically increases lead time.
This is one of several reasons that Lean is so obsessed with small batch sizes. "Time delays between processes" is often the greatest contributor to Lead Time — and often presents the greatest opportunities for "low hanging fruit" to quickly eliminate waste.
Bookmark = QueueTime
Queue Time = The time between sub-processes that the thing gets shuffled around or sits around waiting
for someone to work on it.
Also known as "Waiting & Transportation Time" or "Inventory/Transportation Time"
See advanced training for how to handle queue time for a shared process.
Bookmark = ProcessingTime
Processing Time = The time that the thing is being worked on by an Operator.
Also known as "Process Time" or "Touch Time"
Processing time is observed with a stopwatch or video camera —
In an analytical environment,
Use a Time Observation Worksheet to collect and filter your stopwatch results.
Your Systems2win templates include multiple choices of Time Observations worksheets that are appropriate for different types of observations and different types of processes.
Be sure to coach your people to learn and follow
to the instructions
Processing Time = Manual Work + Walking + Waiting
That portion of Processing Time that is performed by the Production Department is sometimes called "Operator Cycle Time", but Processing Time might also include time spent in sales order processing, engineering, approval cycles, etc.
Note that Machine Time is NOT included in Processing Time.
If the Operator has nothing better to do than stand around to wait for the machine to finish doing its thing,
then that is called "Wait time", and Wait Time is included within Processing Time.
Just remember... Processing Time is all about the Operator (not the machine).
(with very little human interaction required)
On your Value Stream Map,
simply override Cycle Time
with the value for your Machine Cycle Time.
Bookmark = ValueAddTime
Value Add Time = Time of those work elements or process steps that actually transform the thing in a way that
the customer is willing to pay for.
also known as Value Creating Time
Non Value Add Time = Processing Time minus Value Add Time
Note: Prior to 2007, older versions of the Systems2win Value Stream Map used to incorrectly calculate Non Value Add Time in the manner prescribed by many books — as Cycle Time minus Value Add Time.
But think about it. If there were 100 workers each simultaneously devoting an intense 5 minutes to providing a service
to you — you would receive value of 100 x 5 minutes — even though Cycle Time would be only 5 minutes.
So it is always true that Lead Time >= Processing Time >= Value Add Time,
but it is NOT always true that Cycle Time >= Value Add Time
Some organizations differentiate "Customer Value Add Time" from "Organizational Value Add Time".
Example: Time spent examining a patient is customer value add time.
Doing patient admission paperwork might be organizational value add time.
And waiting in the lobby is clearly non-value add time.
Bookmark = MachineTime
Machine Time = The time that a machine is working on the thing
Machine time is the total time that the machine is working on the product. Whether or not the Operator has something better to do than to stand around waiting for the machine to finish has no influence on Machine Time.
For example — If an automatic machine is running for 60 seconds, and the Operator has something valuable to do for 20 seconds, and then has 40 seconds of "Wait time",
the Machine Time is still 60 seconds.
Notice that Machine Time is very different from Machine Cycle Time.
In many production environments — "Machine Time" is used to measure any process
that does not require Operator involvement. Perhaps waiting for sediment to settle,
or for glue to dry...
Rather than trying to rename the field, we suggest educating your users to understand your unique use of the field — because all of the Lean literature uses the term "Machine Time" — even though it can be used in creative ways.
Bookmark = ProcessLeadTime
Process Lead Time = The time that the thing is "being worked on"
before it can be passed on to the next process.
Process Lead Time = Processing Time * Batch Size
Processing Time must be converted from the Cycle Time Unit of Measure
(usually seconds) into the Lead Time Unit of Measure (usually days)
If the Operator is involved in every moment of the process, and you have
a batch size of 1...
then Process Lead Time is simply Processing Time calculated into a tiny decimal fraction of a day.
The actual calculation takes into consideration the number of shifts, and breaks, and other factors — but the resulting number is so small that it can often be safely ignored.
What if the product is still "being worked on" in a way that doesn't require the Operator?
Machine Time has absolutely no effect on Processing Time — except to the extent that the Operator might be caused to wait for the machine to finish doing its thing. This "Wait Time" is included within Processing Time.
And therefore, Process Lead Time that includes Wait Time is still simply Processing Time translated into days instead of seconds.
What happens if the product is still "being worked on" in a way that doesn't require the Operator to sit around
and wait for it? (e.g. drying time, curing time, etc.)
Then Process Lead Time is NOT just Processing Time translated from seconds into days. You can override Process Lead Time to show that even though the Operator only needs to spend 30 seconds painting the product, it takes 2 days for the paint to dry — before the product can then be moved to the next process.
In this example — Processing Time = 30 seconds, and Process Lead Time = 2 days.
Bookmark = CycleTime
also known as Exit Cycles
Cycle Time = The average time between completed units "coming out the end of the pipe"
Example: the cycle time of motors assembled at the rate of 120 per hour would be 30 seconds per unit
For Standard Work Analysis
with more than one Operator:
Cycle Time = the operator with the longest
Value Stream Mapping just calculates a rough estimate:
Cycle Time = Processing Time / # of Operators
Bookmark = MachineCycleTime
Machine Cycle Time = The average time between completed units coming out of a machine
Example: A machine might have Machine Time of 60 seconds, but if the machine makes batches of 6, then Machine Cycle Time is 10 seconds.
IF your process is labor intensive — notice that Machine Time is not included in the calculation of Cycle Time. (Unless the Operator is standing around waiting for the machine to finish a cycle — and then the Operator's time is counted as Wait time)
IF your process is machine intensive, however, (requiring little or no human intervention) — then Cycle Time might be equal to Machine Cycle Time. And on your VSM Power Tool, in the Processing Time field for that operation, you should enter the Cycle Time for that sub-process, (rather than Operator Processing Time which will make no sense for that machine-intensive process).
For Value Stream Mapping, both Cycle Time and Takt Time are almost always measured in seconds per unit.
For other types of process flow charts, Cycle Time and Takt Time might be measured in minutes per unit of work.
Also see the Cycle Time training video on the Value Stream Mapping training home page.
Bookmark = EffectiveCycleTime
Effective Cycle Time = Cycle Time adjusted for all the factors that reduce Working Time Available.
Also known as Output Pace
How to adjust Effective Cycle Time for Optimum Batch Size calculation
(which you should usually do for only1 bottleneck pacesetter
operation — if at all)...
If using a version released after June 2009 —
simply take into consideration the BatchCalc field, which contains the calculated Optimum Batch Size for your pacesetter process.
BatchCalc = The smallest possible batch size to keep Effective Cycle Time just below Takt Time
If using a version older than June 2009 —
Effective Cycle Time actually calculates very differently when you enter a non-zero value into Time Per Change Over. Then your VSM-Power Tool will do the calculations to suggest the optimum Batch Size that will keep your Effective Cycle Time equal to or just under Takt Time.
Bookmark = WorkingTimeAvailable
Working Time Available
aka Time Available for Work, or Work Time Available
To calculate Working Time Available, deduct breaks, meetings, beginning of shift set-up,
end of shift clean-up, planned maintenance, and most other planned non-working time.
Do NOT deduct unplanned downtime or change-overs.
Although Working Time Available is usually calculated in minutes,
it might need to be converted into seconds for templates where Systems2win has not provided sophisticated calculations to automatically convert time units of measure.
Bookmark = TaktTime
Also known as "rate of customer demand" or "pace of customer demand"
Takt Time = Your planning drumbeat.
How often completed units NEED to come out the end of the pipe — as established by customer demand.
Calculation = Working Time Available / Target Units to Produce
Example: 420 working minutes per shift / 210 Target Units to Produce during that shift = Takt Time of 2 minutes per unit
One common example of takt time is golf course tee times. Groups of golfers are scheduled to tee off according to the takt time schedule determined by the golf course operators. Doctors’ office appointments (with patients scheduled every 12 or 15 or 20 minutes) are another example of takt time scheduling.
Operational Takt Time
In most real-world production situations,
Bookmark = TargetCycleTime
Target Cycle Time = Operational Takt Time adjusted for other factors
Also known as Planned Cycle Time
Other factors might include:
- Adjusting to shop floor conditions
such as absenteeism, different-than-expected yields, etc.
- Master Scheduler discretion
to plan for or react to the same factors that are considered within Sales & Operations Planning, but within a Sales & Operation Planning period, rather than across periods.
- Change Over Time
If your process has multiple machines that run mostly unattended,
then use your Machine Balancing template to determine the machine with the longest Change Over Time, and/or the Change Over Time for the machine with the longest total Machine Cycle Time, and then use that (one chosen number) as your Change Over Time for the entire inter-connected process.
It can be difficult to estimate/choose the number to use for Change Over Time, especially if it varies by products within the product families produced in a mixed model production environment, and it is very important to use your Machine Balancing template to re-evaluate your bottleneck or pace maker machine each time that you get a new machine, and each time that you do a kaizen event to improve your SMED Quick Change Over Setup Reduction for each machine.
- Unplanned Downtime
Refer to the DV sheet in your OEE template for all of the various Reason codes for Unplanned Downtime as well as Standby.
Note that Unplanned Downtime only considers small stoppages.
Catostrophic disasters cannot and should not be considered in your production planning.
If you have gaps between shifts, then Unplanned Downtime is usually NOT considered in your calculation of Target Cycle Time — because you can (and often should) handle unplanned downtime with simple tolerances (allowing a little extra time per shift to still fulfill production requirements even if a few small things go wrong), and/or overtime.
- Wait Time
When doing Staff Load Balancing for a process that is divided between several staff positions, it is common to need to add Wait time to the Standard Work for some staff positions in order for each sub-job to be synchronized to the same Target Cycle Time. (as depicted in the chart on the right)
Many consultants and lean professionals have differing
(and often strong) opinions about what factors to include and exclude from Target Cycle Time.
The important thing is to clearly define how Target Cycle Time is calculated for YOUR team, and then ensure that everyone calculates it the same way. A good place to document your agreed-upon factors to include and exclude from Target Cycle Time is the User-Defined Training section near the bottom of the Help sheet of each Systems2win template. (And remember, this is one of the many types of personalizations that will be automatically found and transferred each time that you upgrade your templates.)
Some lean professionals have equally strong opinions about whether to call it Target Cycle Time or Planned Cycle Time. It's a good thing your Systems2win templates can be so easily personalized to use a User Substitution to call it whatever you want.
In many environments, Takt Time, Operational Takt Time, and Target Cycle Time are all the same,
and the single term "Takt Time" can be used.
In other environments, especially High Mix / High Variability environments,
the differences can become important.
Target Cycle Time must be less than or equal to (and is usually equal to) Operational Takt Time.
Bookmark = TaktImage
Any visual, at-a-glance way to monitor whether a process is meeting its takt time.
Examples: Folders in an in-box. Colored chart. Heijunka box. A runner that comes around every Pitch Cycle to take away finished work and bring materials needed for the next Pitch Cycle.
Bookmark = Pitch
Pitch = how often work is released and monitored
Pitch = takt time * pitch batch size (the batch size in which work is released to the pacesetter process)
It is sometimes helpful to think of Pitch like a train station or a bus stop. The bus comes around on a pre-determined schedule, and you either make it or you don't.
The big difference is that the bus driver NOTICES that you're off schedule — and immediately sends up a red flag that triggers a troubleshooter to very quickly show up at your workstation to do whatever it takes to help you get back on schedule.
Bookmark = PitchBatchSize
Pitch Batch Size = how many things to be processed get released to the pacesetter operation for every Pitch cycle
If Takt Time is 10 seconds,
and pallet size is 1200 units
then pitch = 10 seconds x 1200 units = 12000 seconds (or 200 minutes)
If Takt Time is 15 minutes
and new patients are assigned to doctors in batches of 4 client folders
then pitch = 15 minutes x 4 client folders = 60 minutes (or 1 hour)
In other words...
Every 200 minutes — the production scheduling department releases instructions for the pacesetter work cell to produce another 1200 units of the thing to be processed
Or every hour — the physician's assistant releases another 4 patient case folders to each doctor
Factors to consider when choosing Pitch Batch Size (which in turn determines the Pitch time increment)
- The "delivery unit" that is delivered to the end customer. (e.g. pallet size, case size, the amount of time that the doctor needs for an average patient visit, etc.)
- In a mixed environment, the Pitch time increment should usually not be lower than the longest time to produce one "delivery unit" of any item in the product family.
- The batch size that is delivered between processes. (Inter-process transport considerations can be especially important if your product is large or cumbersome)
- You usually want to monitor progress at least 4 times per shift — so Pitch should usually be 2 hours or less.
- It is always best if Pitch is rounded to the nearest increment of Takt Time.
It is important not to confuse Pitch Batch Size with Change Over Batch Size.
Bookmark = InversePitch
If Pitch is less than Takt Time, then this is known as Inverse Pitch, and often requires creative ideas for how to establish Pitch Batch Size and/or a visual Takt Image.
- Break work into an assembly line, with work being completed in small chunks, and either the worker or the "thing" moves to another work station for the next processing step.
- Have the worker validate completion of sub-phases of work — and provide obvious visual feedback as to whether the process is on or behind schedule.
- Provide the worker with only enough materials and/or instructions to do what is needed for the next Pitch increment.
- Create FIFO lanes with obvious visual feedback re: expected vs. actual progress.
- Hire an experienced Lean consultant — who can help you invent creative ways to release and monitor work in a rhythmic and highly visual way — that reliably triggers a troubleshooter to quickly respond whenever work falls behind schedule.
Bookmark = ChangeOverBatchSize
Change Over Batch Size
Change Over Batch Size = how many things get processed before a Change Over is needed (to reset or change equipment)
Change Over Batch Size can be identical to, or dramatically different from Pitch Batch Size.
While the pacemaker operation usually determines the Pitch Batch Size for every other process in the value stream, Change Over Batch Size can be (and often is) different for some processes.
To extend the above examples:
The doctor works on only one patient at a time — not 4 patients at a time.
Perhaps a nurse might come in to re-set or change the configuration of the room between each patient visit.
The 1200 units in each pallet might be made in batches of 12,000 before equipment change-over is needed,
or, (keeping in mind that one of the objectives of Lean is to produce in the smallest batch sizes possible...)
the 1200 units in each pallet might be made in Change Over Batch Sizes of 120, or 12, or (ideally) just 1.
As explained in the books Creating Continuous Flow and Creating Mixed Model Value Streams, if you have a machine or process that requires a Change Over Batch Size greater than the rest of your processes, then that process must be decoupled from the rest of your continuous flow process, using either:
Bookmark = OOCW
Out of Cycle Work = mid-shift operations that are not performed in every cycle, but reduce time available to meet Takt Time
Examples: setup change-overs between runs, inspection, palletizing, routine mid-shift maintenance, routine mid-shift quality checks, and any other activities that have their own mid-shift cycles that happen regularly, but not with every cycle.
There are several approaches for how to handle Out of Cycle Work:
- The most common practice is to deduct most (if not all) foreseeable Out of Cycle Work from the
"Work Time Available" that is used to calculate Takt Time in the first place. (See Takt Time above.)
- Another approach is to use a top-level StdWk sheet for a longer cycle.
(Long enough to include the longer recurring cycles)
And then roll data up from and drill down to sub-level StdWk sheets (or separate workbooks)
and/or other related documents containing the details of each sub-process.
For sub-processes that have a more frequent cycle than the top level —
simply multiply the linked lower-level Cycle Time by the number of cycles for that subprocess.
- Run (multiplying the linked rolled up Cycle Time by the number of cycles run per shift)
- Inspection (multiplying by the number of inspections per shift)
- Clean up
- Another (less popular) approach:
Your Systems2win Standard Work template also provides a User Defined field
(two rows beneath Target Cycle Time) — and the data in that field will generate a fourth line on the Standard Work Combination Table. This field can optionally be used to graphically depict Out of Cycle Work over and above regular Cycle Time.
(Note: This option only makes sense for processes staffed with a single operator, or multiple operators performing every operation — following each other in a circular work cell.)
You can mix and match any or all of the above approaches — making your own decisions for which work elements should be deducted from Work Time Available, and which (if any) should be handled differently.
In the above example — you might simply remove setup and clean up time from Work Time Available,
and then perhaps use drill down/roll ups for some other elements.
No matter how you handle Out of Cycle Work, you should document your supporting calculations —
in either a text box, the Custom Formula Safe Zone, or links to related documents.
Bookmark = EPEx
Every Part Every Interval = The longest lead time to make any product variation within a product family.
Often abbreviated as EPEI or EPEx. Sometimes incorrectly abbreviated to just "Interval"
At what time interval will you be able to run through every offering in your product family?
EPEx provides your salespeople with a rock-solid answer to your customers' most common question: "When can I have it?"
Intervals/week = Time Available for Change Overs / Time per CO
Every Part Every Interval = (Working Days / Intervals) * # Product Variations
On your Value Stream Mapping PowerTool — EPEx is auto-calculated when you enter Time Per Change Over
and the latest version now correctly adjusts for actual batch size for most processes —
which should be using the batch size determined by the pacesetter process.
The pacesetter process is the only one that might be using the optimum batch size (as calculated in the BatchCalc field); and is therefore the only process that might actually be able to use the classic EPEx formula without modification for actual batch size.
EPEx is one of the million dollar payoffs for all of your Lean efforts. (literally)
Why? Because it completely eradicates any need for the enormous costs and time required for finite scheduling software.
(For any product line that you can simplify enough to use EPEx)
Requirements for EPEx to be meaningful:
Although your Systems2win value stream map will automatically answer the question:
"What is the EPEx for the pacemaker?" (which then serves as EPEx for the entire value stream)...
it is even wiser to use what-if
scenarios to answer the even more powerful question:
"What Change Over times are needed for our target EPEx?"
And then use SMED setup reduction methods to do what it takes to meet your strategic objectives.
Bookmark = Strip
Standard Work In Process Inventory = The amount of inventory that SHOULD usually be found at specified locations within a process
One of the methods of Lean process improvement is to clearly define exactly how much inventory should be located at each specific place within a process — and then reorganize the workplace so that there is only space available for exactly that quantity of inventory.
One objective of Lean is to reduce the amount of inventory required - but buffer inventories are very useful for hiding problems beneath the surface — so be careful to "lower the inventory swamp waters slowly" — so that the rocks and alligators lurking just below the surface of your process can be systematically identified and removed one at a time — rather than "draining the entire swamp all at once". Refer to Systems2win Lean & Kaizen online training.
Bookmark = UOM
Units of Measure for the Thing Being Processed
In order for bottom-line Time Sum calculations to come out correctly...
every process and sub-process within a Value Stream Map must convert to a single Inventory Unit of Measure.
The Demand Unit of Measure is the most common (or lowest) Unit of Measure in which the end customer requests or orders "the thing being processed". Any alternative UOMs must convert to this one.
You define that common Demand Unit of Measure on the UOMs worksheet of your Systems2win VSM-PowerTool template.
Example: Let's say that you are making "cars" as your default unit of measure for inventory.
And let's say that a sub-process is making "wheels". A Value Stream Map is set up to use "cars" as the common Demand Unit of Measure for every sub-process. So if the Takt Time for the entire value stream
is 10 cars per day, then the Takt Time for your "Wheel-making" sub-process is the same as every other
sub-process in the value stream — "10 cars per day".
If this unit of measure is confusing for the workers in the sub-process,
who might think in terms of making "wheels", not "cars", then...
1) If you have the latest version — you simply enter the UOM Ratio conversion factor in the very first row — and all calculations for that process are automatically converted to "wheels" instead of "cars" — and yet the bottom line Time Sum Line still calculates correctly.
2) If you own an older version of the Systems2win PowerTool (and can't yet convince your boss to upgrade)...
you could add User-defined Rows to translate Takt Time and Cycle Time etc. into "wheels" for that sub-process. So even though the primary fields still have numbers expressed in the same unit of measure as the rest of the value stream (e.g. 10 "cars"), the user-defined rows for this sub-process could translate those values into "wheels". (e.g. 40 "wheels").
More Lean Manufacturing Terms
Bookmark = Gemba
The actual place where work is performed.
A structured way of thinking and acting that you practice until the pattern becomes a habit.
Learn more on our Kata training page.
Bookmark = Sensei
Mentor, coach, teacher...
And every sensei needs their own sensei.
Bookmark = Consensus
Everyone feels that their ideas and concerns have been sincerely heard and listened to, and they are willing to fully support the agreed-upon course of action — even if it wasn't their first choice.
Consensus is NOT:
- Unanimous agreement
- Majority rule
OEE Overall Equipment Effectiveness
See the separate Glossary of terms for TPM Total Productive Maintenance and OEE Overall Equipment Effectiveness.
Bookmark = Reading
- Kaizen & Lean Training
- Value Stream Mapping Symbols and Concepts
- The full suite of Continuous Process Improvement Tools