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)

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

 Order-to-Cash Time: Time between receiving customer order and receiving payment.
This time might be shorter or longer than Order Lead Time.

 Quote-to-Cash Time: Time between receiving a customer request for quotation and receiving final
payment. (Of particular interest for engineer-to-order production environments)

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

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

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

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

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

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.

Target Cycle Time = Operational Takt Time adjusted for other factors
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.
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.

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 Talk Time.

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:

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

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

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