Kaizen Continuous Improvement Excel templates - Systems2win Kaizen masthead

Lean Video & Demos Home Page
Kaizen & Lean Training Home Page

Share |

Lean Glossary of Terms for Process Improvement

Definitions, formulas, and examples for lean dictionary 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

Tips

  • You can use "Ctrl+F" to find keywords
  • You can use your browser's Back button to return to where you were before following a hyperlink.
  • You will learn better and faster if you keep a copy of your Systems2win template open in another window - and actually play with some data as you read along - so that you really "get it".  Download free trial templates
  • Consider starting with the Value Stream Mapping training and videos -
    which give a nice introduction to the lean dictionary terms covered more thoroughly here.

        Lean Training

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.


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)

time observation

Lead Time = Sum of all Process Lead Times + Sum of all Queue Times between processes (1)

In practice, the term "Lead Time" usually means "Production Lead Time", but technically, there are several more subtle and exact types of Lead Time:

Training video Lead Time training video

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.


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.


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 - following one unit being processed by one operator - all the way through the process (or sub-process).

In an analytical environment, Process Time includes both "think time" and "touch time".

Lean Processing Time

Training video Processing & Cycle Time training video

Use the Time Observation Worksheet to collect and filter your stopwatch results. (The Time Observation Worksheet is a Word template, not Excel).

And be sure to follow the link at the bottom of the Time Observation Worksheet - to the online instructions for how to collect accurate Time Observations while improving rapport with the people you are observing.

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).

For a process that depends almost entirely on an automated machine (with very little human interaction required)...

If you are using a newer version of the VSM-PowerTool (with a release date greater than 80509),
then you can simply override Cycle Time with the value for your Machine Cycle Time.

If you are using an older version of the VSM-PowerTool, then enter the value for the Machine Cycle Time in the Processing Time field.


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: 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 provide a service to you - you would receive value of 100 x 5 minutes - even though Cycle Time would only be 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


Machine Time - Lean Manufacturing

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 not considered at all in Value Stream Mapping. Machine Time is a concept most commonly associated with the Standard Work Combination Sheet.
Also 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 accept 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.


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)

Training video Lead Time training video

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.


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 Processing Time

Value Stream Mapping just calculates a rough estimate:
Cycle Time = Processing Time / # of Operators

Training videoProcessing & Cycle Time training video

 

pipeline

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.


Effective Cycle Time = Cycle Time adjusted for all the factors that reduce Working Time Available.
(Also known as Output Pace)

Training videoProcessing & Cycle Time training video

Extra Credit:
How to adjust Effective Cycle Time for Optimum Batch Size calculation
(which you should usually do only for 1 bottleneck pacesetter operation - if at all)...

If using a version released after June 2009 - Simple 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.


Takt Time = Planning drumbeat. How often completed units NEED to come out the end of the pipe - as established by customer demand   (also known as "rate of customer demand", or "pace of customer demand")

takt time drumbeat

In most companies - "Takt Time" actually means "Operational Takt Time", which is customer demand adjusted through the Sales & Operations Planning process for factors such as:

  • Seasonal demand
  • Planned down-time
  • New product introductions
  • Etc.

Calculation = Working Time Available / Target Units to Produce (usually calculated per week or per shift)
Example: 420 working minutes per shift / 210 Target Units to Produce during that shift = Takt Time of 2 minutes per unit


Lean 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 needs to be converted into seconds.

Tip: We suggest that you calculate Working Time Available in one central worksheet (usually the Value Stream Map) that can be linked from multiple documents related to the same process.

One common example of takt time is golf course tee times. Groups of golfers are scheduled to tee off according 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.


Target Cycle Time = Operational Takt Time adjusted for other factors

Other factors might include:

staff load balancing chart

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)

Target Cycle Time must be less than or equal to (and is usually equal to) Operational Takt Time.

(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.)


Takt Image

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.


Home RunPitch

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.


Pitch Batch Size

Pitch Batch Size = how many things to be processed get released to the pacesetter operation for every Pitch cycle

Examples:

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)

  1. 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.)
  2. 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.
  3. The batch size that is delivered between processes. (Inter-process transport considerations can be especially important if your product is large or cumbersome)
  4. You usually want to monitor progress at least 4 times per shift - so Pitch should usually be 2 hours or less.
  5. 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.


Inverse Pitch

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.

Examples:


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 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:

  1. A FIFO lane
  2. A supermarket
  3. A (non-Lean) pile of inventory

Also see more discussion about Inventory Units of Measure, and how to adjust Effective Cycle Time for optimum batch size.


Out of Cycle Work = mid-shift operations that are not performed in every cycle, but reduce time available to meet Takt Time

The generally-accepted practice is to deduct most (if not all) foreseeable Out of Cycle Work from the "Working Time Available" that is used to calculate Takt Time in the first place. (See Takt Time above.)

Yet some Lean practitioners sometimes find it useful to separately consider some mid-shift operations as Out of Cycle Work. Examples might include setup change-overs between runs, pallet handling, routine mid-shift maintenance, routine mid-shift quality checks, and other activities that have their own mid-shift cycles that happen regularly, but not with every cycle.

You can make your own decisions about which time elements should be deducted from Working Time Available, and which (if any) should be included within Out of Cycle Work.

Either way, you should document your supporting calculations - in either a text box, or a hyperlink to another worksheet.


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")

Every Part Every 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 pay-offs 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:

  1. You must have clearly defined your product families (using our Product Family Matrix)
  2. You must have established flow for this product line (see our Lean Kaizen training)
  3. You must have implemented Level Load Scheduling (making a little of everything every day. See Lean Kaizen training.)

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.


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 re-organize the work place 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.


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").

Training video Units of Measure training video

 


More terms & concepts

 Gemba

The actual place where work is performed.

Sensei

Mentor, coach, teacher... 
And every sensei needs their own sensei.

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:


Notes

(1)  More technically correct calculation of Lead Time = Sum of all Process Lead Times + Sum of all Queue Times between processes

And assuming that there is no process that has a Process Lead Time that needs extra time for something like drying or curing or growing, then...

Lead Time = Cycle Time x units of WIP x number of operations + queue time between processes
Example 1: Cycle Time of 120 seconds x 1 unit of WIP x 1 operation + 0 queue time = Lead Time of 2 minutes
Example 2: Cycle Time of 120 seconds x 100 units of WIP x 2 operations + 0 queue time = Lead Time of 400 minutes

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 by far the greatest contributor to Lead Time - and often presents the greatest opportunities for quickly eliminating waste. ("Low hanging fruit").

Something to think about - to make sure you really "get it"...
Lead Time can be the same as Cycle Time IF (and only if) ALL of the following are true:

  1. Only one unit is produced at a time (batch size of 1)
  2. There is no work in process other than the one unit that is being worked upon
  3. There is only one operator
  4. There are no time delays between processes (for things like setups, batch queues, transportation, waiting for something from a support resource, etc.)

Suggested Reading

Kaizen & Lean Training - by Dean Ziegler of Systems2win
Value Stream Mapping Symbols and Concepts - Systems2win free online training
The full suite of Business Process Improvement tools offered by Systems2win
Lean Lexicon, by the Lean Enterprise Institute