- Raphael L. Vitalo, Ph.D.
In his web log post titled, Value Added Percentage Question, Miller (2009)
shared a perplexing finding. He had come across a description of value stream
in which the value added percentage was greater that 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.
Clearly, a part (value adding work) cannot be larger than the whole that it
partially constitutes (value added activity + waste). For the logic of percentages
as expressions of part-whole relationships to be satisfied, both the numerator
and denominator must define the “whole” the same way. If the numerator
reports the area of part of the universe (its version of the “whole”)
and the denominator only reports the total area of the United States (its notion
of the “whole”)—that rule is violated. Clearly, the areas
of the universe and 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
It seemed obvious to me that Miller used an incorrect formula. The question
that judgment raised for 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 was fueled,
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 log 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 and 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 important lean source materials
suggests that there may be 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. Here is what I found.
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 if the next output, and
stop the timer.” It is the one I have always used. 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 times the 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 it. 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 path.”2
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 is timed.
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
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). But unspecified
is how one detects “one cycle of a process.” Do I detect it by observing
outputs, as in the interval between Output A and Output B? Do I detect it by
measuring the time that elapses from the moment the first input enters a process
to the moment the output whose production it provoked emerges? The answer to
this question is important. The first meaning tells you the rate at which a
process generates it output. The second, however, seems to tell you the time
“it takes one piece to move all the way through a process or value stream”
(Rather and Shook, 2003, p. 21). The problem is that Rather and Shook (2003)
use that phrase to define lead time, not cycle time.
Further, neither of the possible meanings of Jones’s and Womack definition
are necessarily the same as “operator activity” time referred 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 might be counted. Using the
‘operator activity’ focus, that time is might 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
Value Adding Work—Its
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
Help Us Provide
You Better Content.
Tell us your thoughts about this
Be sure to name the article in your