- Raphael L. Vitalo, Ph.D.
In his web blog post titled, Value Added Percentage Question, Miller (2009)
shared a perplexing finding. He had come across a description of a value stream
in which the value added percentage was greater than 100% (a Value Added Ratio1
[VAR] >1). As he analyzed the reported data, he could not find a flaw in
the computation. Yet, he understood this result made no sense. So he posted
the finding and asked readers to comment. He suspected the issue was that the
value stream had value-adding work done by multiple people in parallel. So,
he asked his readers whether the value added percentage or VAR had any meaning
for processes in which work is done in parallel.
My first reaction to his report was to suspect his computation. Percentages
express a part-whole relationship. Clearly, a part (value-adding work) cannot
be larger than the whole that it partially constitutes (value-adding activity
+ waste). For the logic of percentages to be satisfied, both the numerator
and denominator must define the “whole” the same way. If the numerator
reports the surface area of the planet Earth (its version of the “whole”)
and the denominator reports the total surface area of the United States (its
notion of the “whole”)—that rule is violated. Clearly, the
planet Earth and the area defined by the United States are not the same “whole.” And,
if Miller’s computation violates the logic of a percentage then the nature
of the value stream it describes becomes an irrelevant issue. And, in fact,
his computation did violate that logic. In the case he presented, the computation
for the denominator (all work activity) only added the time consumed by work
activities on the process’s critical path as its version of the “whole.” In
contrast, the numerator portion of work labeled “value adding” included
all the work activity done in the process even work done off the critical path.
Those two definitions of the “whole” do not match.
It seemed obvious to me that Miller used an incorrect formula. The question
that judgment raised to me was, “How could anyone familiar with the guidance
in Lean literature make that error?” It struck me that the author cited
no reference for his computational formula nor did any of the people who commented
on his posting. I concluded, therefore, that the apparently ‘confused
thinking’ in this post, and in the comments of its discussants contributed,
was due to the failure of Lean community members to refer to primary sources
to verify the meaning of the Lean terms they used. Web discussants seemed to
simply argue intuitively based on their own personal assumptions. I imagined
that, if they had simply gone to the Lean literature, they would have quickly
uncovered the error in the formula Miller used. To test my suspicion, and not
replicate the error I imagined others were making, I decided to go to the Lean
literature. But, rather than confirm my suspicion, I found that the Lean literature
seems to be confusing at best. Indeed, my search led me “down the rabbit
hole” and, as I went deeper, it triggered my Lean insanity.
Metrics Important to Computing
the Value Added Ratio (VAR)
Based on my past study, I assumed that the ingredients used to
compute the VAR were cycle time and value-adding time. Value-adding time is
the time consumed by activities that materially change an output in ways the
customer values. At least one important primary source in Lean literature,
however, uses lead time not cycle time in its computation of VAR (Jones and
Womack, 2009). This revealed to me that the ingredients for computing VAR might
not be commonly agreed upon. Further, a review of other important Lean source
materials revealed that there was no single definition of any of the elements
used to compute VAR by any method. For the purposes of this paper, we will
start with what I assumed were VAR’s only ingredients—time consumed
by value-adding work and cycle time. Then we will address lead time and two
other concepts related to cycle and lead time—processing time and throughput
time. In each case, we will investigate whether a single, agreed to, operational
definition for each exists.
What Is Cycle Time?
My first stop down the rabbit hole was at the sign post labeled “cycle
time.” I never had any doubt about its meaning or how to measure it until
I revisited the Lean literature. What I found was that there is no standard
definition of what cycle time means or how it is measured.
Rather and Shook
Rather and Shook (2003, p. 19) state that cycle time is “the time that
elapses between one part coming out of the process to the next part.” That
definition is easy to envision and its guidance for doing its measurement seems
clear. To me, it said, “Stand at the end of a process, detect the exist
of an output, start the timer, detect the exit of the next output, and stop
the timer.” I have always used this definition. However, when I revisited
their work, I discovered that it is not their only definition. They also define
it as “the time it takes an operator to go through all of their work
elements before repeating them” (ibid, p. 21). Unfortunately, these definitions
do not necessarily coincide. There are at least three ways these definitions
could differ. The first is in terms of what is timed. The second concerns what
operations are included in its measurement. And the third is in terms of whether
time spent in wait states is counted.
What Is Timed
Following the first definition of cycle time, one measures the time interval
between the emergence of Output A and Output B. The result includes all the
time expended by all the activities that shape that product as it passes
through the critical path of the process. The critical path of a process
is the sequence of activities that determine the minimal time an output can
be generated by the process. It is only time spent on the critical path that
affects the interval between outputs existing a process. Thus, it does not
reflect all the people or machine operating time expended in the process
since some of this may be done in parallel and therefore “off the critical
Using Rather and Shook’s second definition, my focus for calculating
cycle time is the time spent by people doing work. As just stated, not all
work within a process is on its critical path. For processes in which parallel
processing occurs, the second formula would seem to include such work and
the resultant cycle time computed would be much greater than the cycle time
as computed by their first definition.
What Operations Are Included
The critical path of a process may include unattended machine operations
whose time would be included in Rather and Shook’s first definition
of cycle time. Yet, their second definition specifies “operator activity” only.
If the term “operator activity” is being used literally, then
it refers to ‘people activity’ and not ‘machine activity.’ Thus,
the second method for computing cycle time would only include people activity
and presumably exclude unattended machine processing even when it is on the
critical path. Again, using the first definition, both machine and human
time falling on the critical path would contribute to determining cycle time.
Using a literal interpretation of the second definition, only people activity
Whether Timed Consumed in Wait States Is Included
Rather and Shook’s second definition of cycle time based on timing
people’s activities would also seem to exclude time consumed by wait
states between operator actions—e.g., waiting for a tool to become
available or for materials to cure so that additional operations can be done.
This would be so if we took operator activity literally to mean “activity” and
exclude waiting or if the person went off the process for that period of
time and worked in some other process and, in fact, does not personally ‘wait’.
Are these distinctions meaningful or am I just splitting hairs? It might seem
that way as regards the last two distinctions—operations included and
the issue of wait states. But, from a measurement perspective, there should
no ‘hairs’ to split. A good metric is defined operationally in
concrete terms that any alert, motivated, and reasonably competent person can
follow and that, across such people, results in computations that produce the
same value. Otherwise, those definitions cannot reliably guide people in computing
the measures they describe since different people may interpret them differently.
Jones and Womack
Jones and Womack’s (2009) definition of cycle time is not all that helpful
in clarifying what cycle time means. They defined cycle time as the “time
required to complete one cycle of a process” (2009, p. 348). This definition
seems to tell you the time “it takes one piece to move all the way through
a process” (Rather and Shook, 2003, p. 21). The problem is that Rather
and Shook (2003) use that phrase to define lead time. No one in my experience
would assert that these two constructs cycle time and lead time have the same
meaning. Further, if we measure cycle time as “time required to complete
one cycle of a process,” it could produce a value different from cycle
time as computed by measuring the “operator activity” time referred
to by Rather and Shook. For example, assume that one “cycle of a process” means
the time from when the first input enters the process to the exit of the process’s
output. One common trigger event (first input) for many processes is the receipt
of a ticket directing the process to produce one unit of say, ‘Model
A.’ That ticket may be received and registered (Step 1 of the process
that produces Model A) and posted on a board in a queue. It may sit in that
cue for three days before the second step in the process is initiated. There
is no operator activity associated with the time the ticket sits in the queue.
Indeed, all of the operators are occupied working on other tickets. Using Jones’s
and Womack definition that wait time would be counted. Using the ‘operator
activity’ focus that time is would not be counted.
Other Definitions of Cycle Time
In the hopes of finding convergence in the definition of cycle time, I looked
at two other definitions. Neither provided convergence.
Lean Manufacturing Glossary
The Lean Manufacturing Glossary’s defines cycle time as, “The
time it takes to do one repetition of any particular task typically measured
from ‘Start to Start’.” They clarify “Start to Start”
as meaning “the starting point of one product’s processing in
a specified machine or operation until the start of another similar product’s
processing in the same machine or process” (Cycle time, 2014). So, rather
than focusing on the interval between outputs exiting the process, this definition
seems to focus on the interval between the startup of processing of a new
output. This is strange since—again, taken literally—successive
startups are influenced not only by the availability of the processing resources
needed to perform work but by the receipt of the signal that work on a new
unit should begin. That signal is frequently external to the process. Nonetheless,
it is the process’s first input. This would mean that some event outside
the process itself and occurring before the process is actually activated
may affect the determination of a process’s cycle time. Such a cycle
time computation would appear to include both processing time and the interval
between demands for processing. Put that way, the cycle time computed by this
method might not at all align with the cycle time computed by any other method
discussed thus far.
The glossary goes on to state that,
“Cycle time is commonly categorized into:
1) Manual Cycle Time: The time loading, unloading, flipping/turning parts,
adding components to parts while still in the same machine/process.
2) Machine Cycle Time: The processing time of the machine working on a part.
3) Auto Cycle Time: The time a machine runs un-aided (automatically) without
4) Overall Cycle Time: The complete time it takes to produce a single unit.
This term is generally used when speaking of a single machine or process.
5) Total Cycle Time: This includes all machines, processes, and classes
of cycle time through which a product must pass to become a finished product.
This is not Lead Time, but it does help in determining it.” (Cycle
While added specificity is generally helpful, this added specificity seems
confusing. For example, how does one distinguish between Overall Cycle Time
and Total Cycle Time? The time to produce a single unit of output would seem
to be the same as the time consumed by all the operation, human or otherwise,
“through which a product must pass to become a finished product.”
Also, based on the discussion above concerning the “Start to Start”
reference point, if one were to compute Total Cycle Time by adding “all
machines, processes, and classes of cycle time through which a product must
pass to become a finished product” they would not necessarily produce
the same value as if they computed it using “The time it takes to do
one repetition of any particular task typically measured from ‘Start
As a result of my analysis of the Lean Manufacturing Glossary’s definition
of cycle time, I concluded there was no solution here for my growing confusion.
So I took one more stab as finding closure.
Velaction.com is a web site that offers learning resources that teach visitors
about Lean thinking and its terms. It offers a wide variety of resources including
independent study packs, audio and visual training materials, and web-based
tutorials as well as other self training aids. Its formula for cycle time
is “Cycle time = processing time + wait time” (Cycle time, 2014a).
It goes on to state,
“The more common definition of cycle time is the equivalent of processing
time in the equation above—the start-to-finish time of an individual
unit. Note that even this definition of cycle time creates some opportunity
for confusion. Often there are bits of waiting within the process.”
This definition of cycle time introduces the concept of “processing
time” (discussed below), suggests that processing time does not include
wait states, and the “more common definition” of cycle time is
the same as processing time. This means that the most common definition of
cycle time does not include wait states. Hence, one assumes that is why they
explicitly include wait states in their definition of cycle time. The guidance
goes on to state that Velaction.com recommends “using the elapsed start
to finish time for cycle time. This would include the waiting within the process,
but not at the end.” This definition seems similar to Jones’s
and Womack (“time required to complete one cycle of a process”)
however since it adds the element that wait states within the process should
be counted, it remains unclear whether Velaction.com’s definition converges
with the thinking of Jones and Womack.
Finding no closure as to precisely what cycle time means nor how it is measured,
I decided to move forward to the other key element in computing the VAR metric—value-adding time.
Meaning and Measurement
Whether or not one computes VAR using cycle time or lead time,
it appears certain that everyone uses time consumed in doing value-adding work
as the numerator for the VAR. Happily, there seems to be complete convergence
on what value-adding work is. It is work that actually transforms a product
in a way that the customer is willing to pay for. What about its measurement?
Rather and Shook (2003) refer to value-adding work as “value-creating
work.” Their guidance for how to measure it seems uncertain at best. Specifically,
they state that one should record the time spent in “those work elements
that actually transform the product in a way that the customer is willing to
pay for” (p. 21). The phrase “work elements” would seem to
suggest both people and machine activities and, even more importantly, all activities
including those off the critical path! For example, if value-adding work occurred
in parallel—say three workers in parallel add valued features to different
components of an output—it seems that the time spent in value-adding work
by all three would be measured and combined to calculate value-adding time.
Using this interpretation, however, leads to Miller’s (2009) predicament
of having more value-added time than there is cycle time, assuming that cycle
time is the time interval between Output 1 and Output 2. It specifies as the
numerator, a portion (value-adding time) of a “whole” that is defined
as total time expended by all activities in a process. For the denominator,
the whole—using Rather and Shook’s first definition of cycle time—represents
the time spent on the critical path and that is only a subset of all the time
a process’s operations consume. If this formula were used, the VAR would
become a nonsensical percentage since the numerator (total time expended by
all work elements doing value-adding work anywhere in the process) and denominator
(time to traverse the critical path) do not align. Yet, one could cite Rather
and Shook as their source.
Jones and Womack (2009) also refer to value-adding time as value
creating time. They provide an example of how they calculate value-adding time
in Seeing the Whole (2009, pages 15–17). From the example, they count
both human and machine operations but the example they provide seems to measure
a linear workflow without parallelism. Hence it is not possible to say—and
they do not appear to specify—whether their computation of value-adding
time includes all time expended in the process or just time expended on the
process’s critical path.
A search of the Lean Manufacturing Glossary and the Velaction.com
web site failed to uncover any guidance for computing value-adding time.
Based on this investigation, one must conclude that there no definitive explanation
for how to compute a process’s value-adding work time with regard to whether
one includes just the value-adding work occurring on the critical path or all
value-adding work performed anywhere in a process.
Lead Time—Its Meaning
Given that Jones and Womack (2009) use lead time as their denominator
for computing VAR, we should check its meaning. They define lead time as the
“total time a customer must wait to receive a product after placing an
order” (2009, p. 349). This definition is problematic for several reasons.
On its face, it seems to suggest that lead time only applies to the order to
delivery cycle. That seems silly so, as a hopefully intelligent reader, I imagine
I should generalize their words to mean from when a request for an output is
made to when the output is delivered to the recipient who requested it. If my
generalization of the their definition is correct, then what they label as a
“process’s” lead time may not be a feature of a single process
per se but of a sequence of activities that fulfill a customer request. This
distinction is needed because a customer request may not go to the specific
process that will generate the product requested and the product may not be
delivered to the customer by the process itself. This is true even in the case
of a downstream process (‘internal customer’) requesting an output
from an upstream process. There may be intervening activities, both before and
after production, that are not work elements of the process that generates the
output that the downstream process requested. Assuming that we have correctly
analyzed the meaning of Jones and Womack’s definition, it appears that
what they are defining cannot be properly used to compute the lead time of a
process per se except where the process receives directly requests for its outputs
and delivers its outputs to the requesting parties. In situations that fail
this requirement, Jones and Womack’s definition seems to have as its unit
of analysis the customer and not the process. In that context, the metric appears
to be gauging one element of the customer’s experience—essentially,
his or her wait time.
Rather and Shook (2003, p. 21) define lead time as the time “it
takes one piece to move all the way through a process or value stream”
(Rather and Shook, 2003, p. 21). It appears that what Rather and Shook are measuring
is the life cycle of an input as it transforms into an output. That time period
would begin with the input entering the process and end when its transformation
was complete. It also would not include any time consumed from when the request
for the output was made to when the signal for the process to begin operation
was received. Nor would it include the time period beginning when the output
is completed and ending with the customer having the output that was requested.
Clearly, Rather and Shook’s and Jones’s and Womack definitions nor
the metric they would operationalize align.
The Lean Manufacturing Glossary defines lead time as “The
time required from receipt of order until products are shipped to a customer”
(Lead time, 2014). At first glance, this seems to mirror Jones and Womack’s
definition, but it does not. Notice that the end point for timing is “products
are shipped to a customer” whereas Jones and Womack state “received”
by the customer. Again, one might say that this is hair splitting, but not if
you were the person having to make the measurement.3
Based on this investigation, it appears that the Velaction.com
web site has it right when they state: “In the most common definition,
lead time is the time that elapses from when a customer places an order until
the order is received. Some variations on the definition of lead time look at
the time from when a raw material arrives at a facility until the finished product
ships” (Lead time, 2014a).
Again, we must conclude that there is no single definition of
Other Related Lean Terms for
Important Process Features
At least two other terms mentioned in relation to cycle time and
lead time appear to have problematic definitions. These are throughput time
and processing time.
Jones and Womack (2009, p. 352) define throughput time as “the time
required for a product to proceed from concept to launch, order to delivery,
or raw materials into the hands of the customer.”4 These authors direct
their reader to contrast that definition with definition of lead time and
processing time. One might add cycle time to that list. If, by “contrast,”
they meant, recognize the differences—that would be quite a challenge.
Specifically, if we take lead time to mean the time “it takes one piece
to move all the way through a process or value stream” (Rather and Shook,
2003, p. 21), I am stumped to state a ‘contrast.’ If we take lead
time to mean the total time a customer must wait to receive a product after
placing an order” (Jones and Womack, 2009, p. 349) and generalize these
words to mean from when a request for an output is made to when the output
is delivered to the recipient who requested it, then the resulting meaning
seems to render lead time and throughput time as identical in meaning. Similarly,
with regard to cycle time, if we take the definition of cycle time as being
the “time required to complete one cycle of a process” (Jones
and Womack, 2009, page 348), I would be hard pressed to state the difference
between cycle time and throughput time since, for example, the time from “concept
to launch” appears to me to be “one cycle” of the process
of product development.
The Lean Manufacturing Glossary defines throughput as the “rate at
which work proceeds through a manufacturing system” (Throughput, 2014)
thus introducing, but not clarifying, two important words—“rate”
and “manufacturing system.” What is meant by rate? The dictionary
definition is “a measure of a part with respect to a whole” (Rate,
2014). Arithmetically, it is a subset of ratios that represent the probability
that an observed event is likely to occur. Neither of these definitions fit.
We might assume that it means “the speed at which something happens
over a particular period of time” (Rate, 2014a), but that would be our
assumption. Also, how would we measure the speed? By the interval between
outputs as is done with cycle time? If so, how do we distinguish cycle time
from throughput time? Finally, at least this reader cannot specify with any
confidence what is being referred to by the phrase “manufacturing system.”
What is the entry point for this system? What is its ending point?
Velaction.com had no entry in its Lean dictionary for throughput and a search
of the book, Learning See, did not uncover a definition for the term either.
As regards processing time, Jones and Womack (2009) define it as “the
time a product is actually worked on” (p. 351). They add that processing
time is a component of lead time and throughput time. This suggests that both
lead time and throughput time include wait states whereas processing time
does not. Processing time is just the time an output is being acted on in
some way (wasteful or value adding) by a person or machine. From an operational
perspective, it suggests (but does not make explicit) that processing time
measures all the activity time even activity that is done in parallel. If
this is correct, it would be quite possible for processing time to actually
exceed throughput or lead time. Both throughput and lead time measure time
along the critical path. That conclusion, while reasonable, is at odds with
their assertion that processing time is a component of lead time and throughput
The Lean Manufacturing Glossary had no entry for processing time. Velaction.com
also had no entry for the term but does define it incidentally as it explains
cycle time. It states that processing time “is ... the start-to-finish
time of an individual unit” (Cycle time, 2014a). Velaction.com views
processing time as activity time only and states that it does not include
the in-process wait times. It implies, but does not state, that processing
time includes all activity occurring in a process even activity off the process’s
Based on this review, we must conclude that there is no single definition for
either throughput or processing time.
Implications for Computing the
Exhibit 1, next page, summarizes this paper’s brief survey of Lean literature
as regards key metrics associated with the VAR and guidance for how it is computed.
Key terms referencing important features of a process’s operating performance
seem defined multiple ways by multiple, respected Lean authors. Some definitions
given by the same authors seem inconsistent. Others are different between authors.
None appears to be operationalized to the point that one can confidently assert
that “here is the precise sequence of steps that one uses to measure feature
X.” Without an operational definition, it is impossible to have a reliable
The facts this limited investigation uncovered suggest that the meaning and
method of computation of the VAR is not standardized. There is varying guidance
for how one computes VAR’s numerator (value-adding time) and what one
uses as its denominator (lead time or cycle time). Depending on which combination
one applies, it is quite likely to produce a value added percentage that violates
the logic of what a percentage means and have legitimate Lean references to
back up your meaningless computation.
The Path Out of My Lean Insanity
As demoralizing as my trip down the rabbit hole was, I did manage to recognize
a path back to sanity. It is one both you and I can use either to escape the
rabbit hole or—preferably—to avoid entering it. While the array
of available definitions of key metrics offered in the Lean literature are contradictory
and poorly operationalized, there is knowledge one can use to correct that problem.
That knowledge guides both the definition and use of metrics and how we communicate
about them. And, using knowledge to guide one’s performance is actually
a critical pillar in Lean thinking. It is the action component of leveraging
learning to improve one’s performance.
Building a Sane Metric
A business metric gauges the status of some feature of some object important
to business decision making. To define a sound metric, use the following steps.
- Specify the focus of your interest.
- Identify the feature whose status you wish to gauge.
- State the reason why you are interested in measuring this feature.
- Specify a measure you will use to gauge its status.
- Define the method you will use to calibrate the status on that measure.
- Test your measure and method.
- Document it.
The focus of your interest is the foundation of your metric. It identifies
the group of people or things you will observe or otherwise gather information
about. It clarifies the perspective from which you will evaluate your business
(customer, offering, etc.). In defining your metric’s focus, ask yourself:
“What group of people, places, things, or activities am I interested
in knowing about?” For example, is it the customer, the offering we
provide customers, the work processes we implement to generate that offering,
the value stream within which work processes are organized, or perhaps the
people who implement the business? Once you have named the object of your
interest, define it and clarify who is and is not included in the group. If
your focus is customers, how do you define the customer? Do you follow Deming’s
(1982) definition of a customer as the person who uses the offering to accomplish
the task or purpose for which it was designed? If so, specify that. Also,
specify whether you are interested in all customers or only those in one or
another business region or who use one of another specific version of an offering.
Use concrete language that enables a reader to envision who is in and who
is out of the group.5
Next, you need to label about which feature or characteristic of this group
you wish to gauge. For example, in a Lean enterprise, we are interested in
a number of features of work processes including the relative presence of
time spent wastefully versus time spent adding value and the process’s
cycle time, processing time, lead time, and throughput rate. Just labeling
a feature, however, is not enough to proceed. You must also define the feature
in observable and measurable terms and clarify its scope. For example, if
I am interested in the presence of time spent wastefully in a process—how
do I define ‘time spent wastefully’? Further, am I interested
in all time spent wastefully within a process as inputs traverse every path
within it to become its output or just the time spent on the process’s
critical path? Again, be specific. Use concrete language. Define any special
terms you use (e.g., critical path).
Your third step must be to state why you want to know the status of this
feature. In a business context, information is gathered to enable decision-making.
So, for example, if you want to know the presence of time spent wastefully
along every process’s critical path—ask yourself what decisions
will I use this information to support? One obvious decision this information
would support is to detect whether the throughput rate of any studied process
(how many units it can produce over a specified period of uptime—like
one shift) is hindered by waste. Another is whether, over time, we are reducing
that hindrance. Knowing the ‘why’ behind your interest in an item
of information is critical to properly defining a measure that will provide
the information you seek. For example, each of the just stated judgments requires
a different measure to provide the information needed to make it. The first
judgment can be made with a report of the amount of time spent wastefully
or the judgment that time spent wastefully is present or not present along
the process’s critical path. The second specified decision requires
a measure that will reflect whether there has been change in the level of
time spent wastefully over time.
A measure represents the status of a feature. It must be defined in a manner
that enables us to make the decision or judgment we seek to make. Every measure
includes a metric. Metrics calibrate status in either logical (Yes/No, True/False,
Present/Absent) or quantitative terms (number, percentage, ratio, etc.). As
just described, the metric used depends on the judgment one seeks to make
with the status information.
If the judgment is of an “either/or” type (e.g., goal accomplished,
report completed), then a logical metric is used. Otherwise, a quantitative
metric is used. Exhibit 2 suggests which metrics are useful given the type
of judgment you seek to make.
Next, specify how the status on the metric will be obtained.
State the goal of measurement; who should do it, where, and when; the resources
the person needs to make the measurement; and the process the measurer should
implement. Make sure the process is a step-by-step program that gets a person
ready to do the measurement, guides the person in doing the measurement, and
specifies how the person follows up once the measurement is done. The follow
up steps should include verifying the measure, documenting and storing the
findings, and reporting them to decision makers.
Test your metric and method of measurement. As to the metric,
ask and answer whether the metric you defined satisfies the logic of mathematics.
As we have seen, that answer will not always be, “Yes.” Ratios
that are proportions or percentages, for example, require that the numerator
report a potion of a ‘whole’ that is absolutely identical to the
‘whole’ reported in their denominators. The status of a feature
of a random process—e.g., its cycle time—cannot be reported as
a point value (single value) unless it is reporting for a specific instance
of operation. Random process evidence variation that requires the status of
any of its features to be reported in terms of its central tendency or limits
(hi-lo occurrence). Then evaluate whether the metric provides the information
needed to enable decision makers to the make the judgment specified in the
reason for the measure.
With regard to the method of measurement, resolve each of the following questions.
- Is the person specified to do the measurement qualified to implement
- Does the timing for producing the information meet the needs of the decision
makers who will use it?
- Are the resources specified for doing the measurement sufficient given
the steps the measurer must execute?
- Does the measurement process include getting ready, doing, and follow-up
- Do the ‘doing steps’ follow proper statistical principles
as regards, for example, sampling selection or choice of a central tendency
metric (mean, median, or mode)?
- Does a walk through of the process generate the information needed?
Finally, document the metric and its measurement as you would
any standardized work within a Lean enterprise. Treat it as any other vital
process within the organization. This means continuously improve it so that
it is waste free, repeatable, reproducible, and valid.
On Communicating About Metrics
The second set of guidance for preventing the propagation of Lean insanity
concerns how we communicate about metrics. It is summarized in the following
Receiving Information About Metrics
Assume nothing! The mere fact that someone uses a term that is the same
as you use to label a metric does not at all mean that the two metrics are
the same. It should be clear that well meaning and studious Lean community
members may compute metrics differently. If, for example, I am a follower
of Rather and Shook, my VAR is computed using cycle time as the denominator.
If, on the other hand, I learned my VAR from Jones an Womack, I use lead time
as the denominator. This means that we each must always clarify and confirm
(Byron and Vitalo, 2003) what another person is reporting especially as regards
to metrics (focus, feature, reason, measure, method).
Communicating Information About Metrics
Always provide the information that person you are communicating with needs
to understand each metric you are reporting about. In other words, provide
by some means (footnote, endnote, embedded table) for each metric you report
a brief statement of the focus and feature it is reporting about, the decision
it supports, the mathematical expression of the measure, and the method used
to gauge its status.
Byron, J.S. & Bierley, P.V. (2003). Working with others training
program. O’Fallon, MO: Lowrey Press.
Cycle time (2014). Definition from the Lean Manufacturing Glossary.
Retrieved September 25, 2014, from http://www.tpsLean.com/glossary/cycledef.htm
Cycle time (2014a). Definition from the Velaction.com web site.
Retrieved September 25, 2014, from Retrieved September 25, 2014, from http://www.velaction.com/cycle-time/
Deming, W.E. (1982a). Out of crisis. Cambridge, MA: Massachusetts
Institute of Technology Center for Advanced Engineering Study.
Jones, D. & Womack, J. (2009). Seeing the whole. Cambridge:
MA, Lean Enterprise Institute.
Lead time (2014). Definition from the Lean Manufacturing Glossary.
Retrieved October 7, 2014, from http://www.tpsLean.com/glossary/leadtimedef.htm
Lead time (2014). Definition from the Velaction.com web site.
Retrieved October 7, 2014, from http://www.velaction.com/lead-time/
Miller, J. (2009, July 16). Value added percentage question.
Retrieved 9/25/2014, from http://www.gembapantarei.com/2009/07/value_added_percentage_question.html
Rate (1992). Definition in The American Heritage Electronic Dictionary.
New York: NY, Houghton Mifflin Company.
Rate (2014a). Definition in The Merriam Webster Dictionary. Retrieve
October 8, 2014, from http://www.merriam-webster.com/dictionary/rate
Rather, M. & Shook, J. (1999). Learning to see. Cambridge:
MA, Lean Enterprise Institute.
Throughput (2014). Definition from the Lean Manufacturing Glossary.
Retrieved October 7, 2014, http://www.tpsLean.com/glossary/throughputdef.htm
1 The value added ratio is
actually a proportion—that is, a subset of ratios in which the denominator
is the total and the numerator is a portion of the total. A percentage is simply
another way of representing a proportion. Thus, both the value added percentage
and the value added ratio have the same mathematical meaning.
2 This author has not yet uncovered
a single definition of “cycle time” that explicitly states that
it is measuring time spent along the critical path. The failure to use this
clarifying phrase may be one source of the confusion among Lean community members
about what is and what is not included in the computation of cycle time.
3 To be fair, the Glossary’s
entry has a note that offers an example of why lead time is important. In that
example, but not in the definition, the end point for timing is “your
products delivered to your door.” Internal inconsistency, however, does
not provide definitive guidance.
4 These three functions are
repeatedly referenced in Womack and Jones’ Lean Thinking. They appear
to refer to the product development value stream, the order to cash value stream,
and the production value stream respectively.
5 The focus of your study is,
in the language of statistics, the study’s unit of analysis. Specifying
the scope of objects that you will study is termed defining the sampling frame.
Published October 21, 2014, Revised November, 17, 2014, Revised
June 2, 2022
Help Us Provide
You Better Content.
Tell us your thoughts about this
Be sure to name the article in your