Lean Insanity - Raphael L. Vitalo, Ph.D.

Introduction

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 path.”²

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 ‘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 manual intervention.
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 time, 2014)

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

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.

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 and Measurement

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

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 lead time.

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.

Throughput 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.”⁴ 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.

Processing Time

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

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 critical path.

Based on this review, we must conclude that there is no single definition for either throughput or processing time.

Implications for Computing the VAR

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

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.

1. Specify the focus of your interest.
2. Identify the feature whose status you wish to gauge.
3. State the reason why you are interested in measuring this feature.
4. Specify a measure you will use to gauge its status.
5. Define the method you will use to calibrate the status on that measure.
6. Test your measure and method.
7. Document it.

Focus

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

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

Reason

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.

Measure

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.

Method

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

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 it?
• 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 step?
• 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?

Document

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

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.

Download PDF of Article

Reference

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

Footnotes

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

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

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

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

⁵ 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 article.
Be sure to name the article in your feedback.