Some Lean practitioners have promoted the use of a third type of value-add: Non-Value-Add Required (NVAR).
Also known as Business Non-value Add, these activities are those that must be performed for legal or regulatory requirements. Another consideration is whether the process would fail altogether if the process step were eliminated. It is important to keep in mind that these activities are still a form of Non-Value Add. So the goal from a Lean practitioner standpoint for NVAR activities is to minimize or (if possible) to eliminate these process steps.
A Fundamental Lean Measure: Process Cycle Efficiency
Once you have agreed on the definition of CVA a key measure to understand for any Lean practitioner is the Process Cycle Efficiency (PCE – also called value-add ratio). This is simply the ratio of the total customer value add time for a single item (or transaction) divided by the total process lead time to deliver the product (or service). This is the key performance measure of any process.
A number of Lean writers estimate that a typical process has a PCE of 5% or less. In other words, 95% of the time required to move a product (or information) from start to finish are due to non-value add activities. Common examples of such activities include waiting, performing rework, reviewing information, dealing with defects / errors / mistakes, moving items, and watching.
Past research for a variety of types of business processes resulted in the following figures for a typical PCE, and ‘world class’ PCE (George Group, 2004):
|Type of Process||Typical PCE||World Class PCE|
|Continuous Process/ Assembly
(Continuous /One Piece Flow)
My own experience is that the values in the table above for ‘typical’ processes are somewhat generous. That is, the values are too high. I have seen PCE values well below 1% for many processes. In short, while the practice of determining the PCE for any process is an important one, it can also be very humbling.
The Challenge of Defining Value
As noted previously, both new and experienced Lean practitioners sometimes struggle with defining value. I hope the guidelines covered in Parts 1 and 2 of this blog will help to make this task a little easier. But even if you still find it challenging, I would suggest that the time spent discussing, debating, and arguing over how to categorize each process step in terms of CVA is exactly the sort of thing you should be doing as a lean practitioner. Working through this categorization is fundamental to developing Lean thinking, and hence is always worth the extra time required.
Finally, from a Lean practitioner standpoint you should always keep in mind the following rule of thumb when working on various types of activities:
In part 1 of this topic the fundamental concept of customer value was discussed. Before applying lean methods to improve a process, the first step is to define exactly what value means for that process. Or more accurately, to define what value means for the customers of that process.
This understanding of what adds value – which comes from an understanding of customer requirements – can then be used to categorize each process step as either Customer Value-Add (CVA) or Non-Value-Add (NVA). Once this categorization is performed a lean practitioner can focus on eliminating or minimizing non-value-add activities. Sounds simple, and for many lean projects it can be that straightforward.
As was explained in Part 1 of Defining Value, there are two key characteristics of process steps that add customer value:
1) Change to materials OR information
2) Something for which a customer will pay
So to be clear: A customer value-add process step must cause both a change to materials (OR information) AND be something for which customers will pay. Examples of such activities in manufacturing include cutting metal, assembling a wiring harness, and painting a panel. In a transactional process CVA activities include analyzing data, writing a report, approving a loan, performing a credit check, and answering customer questions.
The Second Time Around
Not covered in Part 1 was the situation where any of these activities are done a second time due to a mistake made the first time. In this case the process step should not be categorized as customer value-add. Such an activity is a form of rework, and although it may meet the first part of the definition of customer value-add (a change to materials or information) it fails the second part (activities for which a customer will pay). Think about it: If you purchase a new television, would you want to pay for rework performed on that TV? Or if you submit an application to refinance your home loan do you want to pay for mistakes made by the staff of the bank?
One easy way to check if an activity is non-value-add is to see if the letters “re” are used in describing the task. Some NVA examples include: rework, review, rewrite, repaint, retest, recheck, return, recall, retype, retrain, reissue, reship, redesign. Always keep in mind the lean goal to ‘do it right the first time’.
Assessing Value in Internal Processes
This approach to classifying activities as CVA or NVA seems pretty straightforward for most manufacturing processes, and even most service processes. Where many lean practitioners struggle is when they are working to improve internal processes that may not directly impact the external customer. Examples of such processes include payroll, month-end close, hiring/HR, and regulatory processes. Clearly such processes do result in a change to materials or information. But just as clearly, external customers are not willing to pay for these types of activities.
There are two keys to assessing value in such processes. The first is the previously mentioned question of who is the customer of the process. But the second consideration is to answer the question: Are we looking at the process level, or at the organization level? The answers to these questions will help in characterizing the process steps.
To be clear, when speaking of organization level I am referring to the value stream used to meet the needs of the external customer by the organization. This value stream – sometimes referred to as the order fulfillment process – is really made up of a series of sub-processes including order entry, scheduling, operations, packaging, and delivery. The customer at the organization level is the customer who pays for the product or service they receive.
On the other hand, the process level refers to any process within an organization whether it is part of the order fulfillment process (such as operations) or is a support process (such as payroll or hiring). The customer of the hiring process is the department that needs a new employee. The customer of the month-end-close process is the management team.
Now let’s look more closely at a process like payroll. Does the external customer – i.e., the paying customer – care about payroll of their supplier? No, they do not. So at the organizational level, the payroll process does not contain any CVA activities.
But now consider the customers of the payroll process: employees (who want to be paid), managers (who need to track costs), and the government (who need the information to tax the company and its employees). Each of these entities do value the activities required to provide them with the various products (checks, reports, information) of the payroll process. So at the process level, there are CVA activities.
And here is the clincher: What if the company decided to outsource payroll? That is, what if they asked a third party to perform the process of payroll. Would the company pay the third party to perform this process? Absolutely. Therefore, one can infer that the company values the critical activities performed in the payroll process. So now we have met the two requirements of a CVA activity covered in Part 1: (a) Change to material OR information, and (b) Something for which a customer will pay.
Do you have non-value add elements in your processes? What are you doing to make your processes more efficient?
Does that activity add value? The answer can provoke friendly debates, heated arguments, tears, hurt feelings, and the occasional fist fight. And that’s just among lean project team members! It can be even worse between lean practitioners and front-line workers, whether they are in a factory, warehouse, retail store, or office.
Think about it from this perspective: How would you feel if someone told you ‘What you do all day long is not a value-add activity’? That is the reason it is important to make a distinction between the person performing an activity, and the activity itself.
Yet despite the difficulty of defining value, it is a key skill for any successful lean practitioner. In the book Lean Thinking by Womack & Jones (1996) they proposed a basic approach to implementing lean that consisted of a five step process. The authors stated that “Specifying value accurately is the critical first step in defining lean thinking”.
In other words, before you can move forward in applying various lean concepts it is important to begin with a clear understanding of what constitutes a value-add – and non-value-add – activity. In the book mentioned above the authors address this topic further by noting that:
“Value can only be defined by the ultimate customer. And it’s only meaningful when expressed in terms of a specific product (a good or a service, and often both at once) which meets a customer’s needs at a specific price at a specific time.”
Several years ago I investigated the topic of value in order to make a presentation at an engineering conference. What I discovered was that different writers had different explanations of value-add. Consider these definitions from that research:
Value is added by changing the form of something or by moving it closer to the customer
Activities that must be performed to meet customer requirements
Value-added time may be thought of as any time spent on actually transforming the product toward its final configuration.
Value-added steps (or activities) are those that matter to the customer (external or internal); all others are nonvalue added. If there is disagreement over whether a step is value or nonvalue-added, it is best to err on the side of calling it value-added.
Any activity that increases the market form or function of the product or service. (These are things the customer is willing to pay for.)
The overarching themes seen in these definitions are two-fold:
1) Change to materials OR information
2) Something for which a customer will pay
In other words, if an activity results in a change to materials OR information AND if a customer would be willing to pay for that activity, then said activity should be classified as value-add. Examples in the world of manufacturing include tasks such as cutting, welding, assembling, and painting. In terms of service processes, examples include checking in a person at a hotel, answering technical questions via a helpdesk, mowing a lawn, and assisting a customer with the use of a new product. In the world of transactional processes, examples of value-add activities include capturing customer requirements, analyzing data, writing reports, making key decisions, and communicating needed information.
Of course, there are always some activities that fall into a ‘grey zone’ in terms of value-add. In the manufacturing arena two examples are tooling costs and setup charges. Many firms routinely charge fees associated with activities associated with these two process steps. Yet neither of them result in a physical change to materials.
Another such example is inspection. In some industries a supplier is required by contract to inspect their product before sending it to the customer. So in essence the customer is willing to pay for this activity. Yet inspection does not result in a physical change to a product. In office processes inspection or review activities are very common. Such steps are often put in place due to some problem that may have occurred months or years ago.
So should these tasks that fall into the ‘grey zone’ be classified as value-add activities? From a lean purist standpoint, I would say no. But from a practical standpoint I would be willing to accept that they are value-add. At the end of the day, it is more important that you agree on a definition of value-add at your firm, and are consistent in how it is used.
In Part 2 of Defining Value we will explain a fundamental lean measure to use when examining the level of value-add in a process: Process Cycle Efficiency. Also covered is an explanation of this measure in terms of both typical and world-class firms for various types of business processes. Finally, Part 2 will include a discussion of how to categorize activities performed due to regulatory and similar requirements.
As the Program Manager for Lean Six Sigma (LSS) at TMAC, I’ve worked with a variety of companies implementing continuous improvement programs. LSS uses a simple but powerful structured approach to process improvement called DMAIC, referring to the five phases of problem solving that a LSS project goes through: Define, Measure, Analyze, Improve, Control. In LSS Green Belt and Black Belt training we cover each of these phases, teaching participants a series of tools that can be used to solve all types of business problems, from relatively simple to extremely complex.
A common question from new Green Belt and Black Belt students is ‘How can I get results on my project?’ We answer that question with the following equation:
Results = Quality of the Solution x Acceptance Level of the Solution.
It is important to start out with an agreement on what is the goal of a project. That is to say, the Project Sponsor must work with the Black Belt or Green Belt to define the desired Results. This is a key deliverable for the Define Phase. Typically the desired Results will be something like a reduction in error rate, an increase in production level, or a decrease in customer complaints. There should also be a financial impact associated with achieving the desired Results.
Quality of the Solution
The first part of the equation to achieve results is the Quality of the Solution. The question anyone involved in process improvement should ask themselves: ‘Is this solution technically sound?’ The answer should always be yes. Make sure that the solution will work ‘on paper’ (or in theory). Here is where it is critical to have the right combination of process data, statistical methods, lean tools, and related process improvement techniques. It is also important to adapt the specific tool or method to the business process. Which leads to the second part of the equation to get results.
Acceptance Level of the Solution
Technically superior solutions do not always translate to achieving results. In fact, spending too much time on developing a solution that is better from a technical standpoint can actually hurt results. It is critical for Lean Six Sigma practitioners to set aside time to work on increasing the Acceptance Level of the Solution. Consider a very elegant solution from a technical standpoint that will cause a low Acceptance Level from the workforce. Such a solution will typically result in poor Results, if not outright failure. In such a case, a simpler, less technically advanced solution may be more acceptable, and hence yield better results.
How much of my time should be spent on increasing the Acceptance Level? The answer, of course, is ‘It depends’. At organizations where continuous improvement is part of the company culture and employees are familiar with commonly used tools then the percent of time spent on gaining acceptance may be relatively low, perhaps 10 to 20%. But at companies where continuous improvement is new, or the workforce is not aware of Lean or Six Sigma tools then the percent of time spent gaining acceptance will be much higher. From 25% up to 50% of project time may be needed to change a group of Doubting Thomases to Believers.
Completing the formula
A great idea doesn’t always mean success, using this formula along with the DMAIC process and appropriate tools gets you one step closer to the results and impact you (and your organization) are looking for.
How do you determine your results on a Lean Six Sigma project? Have you seen a project fizzle because it was too technically complex? How did you handle that?