Lean Six Sigma Yellow Belt
After completing this course, you will be able to:
- Understand the key principles of Lean Six Sigma
- Identify improvement opportunities in your organization (projects)
- Understand and use the Define, Measure, Analyse, Improve, Control (DMAIC) model and key activities
- Use the basic tools and techniques
- Understand the role of Yellow Belts in Lean Six Sigma projects
- Run small improvements in their day-to-day work processes
The modules covered in this learning:
- Lean Six Sigma Overview
- Define Phase
- Measure Phase
- Analyse Phase
- Improve Phase
- Control Phase
Recommended study time for this course is approximately 5 hours
Key exam information
There is no exam at the end of the LSSYB. A Yellow Belt certificate is issued upon completion of the training.
Welcome back. This is part two of Define at Lean Six Sigma. An important part of define is to understand and record the voice of the customer. Think about your own work. Who are your customers? What do they want from you? Are they happy with what you send them? Do you ever talk to them? Do they ever give you feedback? Or do you just keep producing what you've always produced and send it to them, and because there is no feedback, you just keep doing it?
But it might be that what you are providing is not entirely suitable to what the customer wants. For instance, in an organization, someone created an Excel spreadsheet every month full of data. They sent it to someone else in the organization who took that Excel spreadsheet, copied and pasted it into a Word document. They then emailed it to another person in the organization. That process had been operating for many, many years. Someone decided to have a look at that simple process and so they went to the person who received the Word document and they asked them, "What do you do with the Word document when you get it?" The person told them that they copied and pasted it into Excel. So if the final customer wanted the data in Excel, why was this process converting it into a Word document? Not surprisingly, the person looking at this process removed that step and got the initiator of the data to talk directly with the customer to understand their needs so that they could provide the right data in the right format for them.
Understanding the voice of the customer is a key part of the Define phase of Lean Six Sigma. We want to know who are the key stakeholders that are affected by this problem. What are their needs and what's important to them? The things that are important to customers and known as critical to quality or CTQ.
It probably would be better to describe the most critical to customer, CTC, however as a hangover from the days of total quality management where quality was seen to be doing what the customer wanted, we still talk about CTQs. What are the impacts of the problem on the customer? Who feels the pain? And who will be affected if we make changes to this process? So to collect the voice of the customer we need to identify our customers and stakeholders, gather the voice of the customer by talking to them, understand their needs and values, and translate them into CTQs, critical to quality.
A way of understanding what the customer talks about when they answer the question "What is it you want?" can be helped by looking at the Kano Model. The Kano Model was developed by Professor Kano. And he was interested in understanding when customers are asked "What do you want from this process?" what things do they talk about.
Now, if a customer is asked, "What do you want?" following receiving a product or a service, they will talk about what they liked, what they didn't like, what worked well for them, what didn't. Professor Kano was not interested in this response but the response to "What do you want?" when asked before the customer had received the product or service.
This is a little like the IT situation where a customer says, "I would like a new system," and IT will ask, "What exactly do you want this system to do?" Kano discovered three areas to be looked at and understood in terms of what the customer talks about or doesn't.
There are basic requirements. These are the requirements that often the customer assumes you know about, and rarely do they talk about them. There is just an assumption that everybody knows this is what will be delivered. For example, if you want to write something, you'll get a pen or a pencil. The purpose of pen is to write. Yet no one goes into a shop and asks for a pen that writes. Because everyone knows the purpose of a pen is to write. However, if that pen does not write, then the customer will be dissatisfied. Also if the pen does write, well so what? That's what you expected and have very little impact on the customer's satisfaction or dissatisfaction. And this can be seen in this graph shown here.
If the basic requirement fails, the customer is dissatisfied. If it succeeds, so what? It has no impact really. If the customers do not talk about basic requirements, what do they talk about? The things they talk about Kano called performance. These are the key things that they want from the process. And often these are the things that they're going to use to decide do they buy this product, that product or another product, or use this service, that service or another service? And these are the things they talk about.
Think about the situation if you were going to buy a new car. You would sit down with the car salesman and talk about the car you wanted. The key things would be size of the engine, maximum speed, number of doors, reliability, comfort, color, fuel efficiency. You wouldn't ask, do the doors lock or do the windscreen wipers work because they are basic assumptions that they will come with the car.
So let's consider fuel efficiency. Your key requirement is a car that is fuel-efficient. You take delivery of the car, you fill it up with fuel and off you go. And let's say in a few miles the orange light comes on to say, give me more fuel. You will be very dissatisfied as a customer, as this clearly does not meet your requirements.
However, if the situation is you fill the car with fuel, you drive off and after many, many miles, you still haven't had to go and fill the car again, you're probably going to be happy and very satisfied with the car you've chosen. These are performance requirements.
Kano also discovered a third requirement which he called excitement. Think about the situation where have you ever received a product or a service which delivered more than you expected. Maybe an upgrade on an air flight or an upgrade in a hotel room. An example of excitement would be in one situation a husband and wife went to buy a new car. They went to pick up their new car. The husband was given the car keys and the wife was given a big bunch of flowers. Well surprisingly they were quite excited, not only at receiving the car, but being given the flowers as well. This impressed them so much that a few months later they went to buy another car for the wife. When they went to pick up the car, they were given the car keys, but this time, no flowers. The wife was very disappointed that there were no flowers. The car was fine, but there were no flowers. And so the danger of excitement is there is potential that you create an area of dissatisfaction which was not originally there when the customer was looking for the product or the service.
So those are the three areas of Kano: basic, performance, excitement. However, customers tend to only talk about the performance issues. They assume you will know the basics. However, if you fail on either the basics or the performance, they will be dissatisfied and therefore we need to spend time understanding what are the basics that the customers want, as well as focusing on the key requirements.
There are limitations and difficulties in collecting the voice of the customer. Sometimes when the customer is asked, "What do you want?" they don't know the full details. This is often seen in IT projects, where the customer wants a new system, and when asked what will the system look like, they really can't describe the system in the detail that IT want. And they may simply just respond, "Well, I want a payroll system." But what is it looking like? Well, it looks like a payroll system. That doesn't help IT develop such a system.
Kano also points out that many customers will assume that you know what their basics are. Sometimes it's not enough to ask customers what do you want. Sometimes it might be beneficial to go and watch them use the product or service and see how they're using it. Watching the customer use the product is often talked about going to Gemba.
Gemba is a Japanese word which means the place where it happens. Go and see where things are happening. Doing that might give an understanding of why things go wrong and what opportunities you have for putting them right. Once we've gathered the voice of the customer, we need to convert them into CTQs. CTQs should be important to the customer and they should be measurable. The Critical to Quality Tree may help you develop these ideas.
In this example, we're looking at a call center. A customer rings in the call center. What is it they expect from the call center? In very general terms, they expect to be connected to the right person. They expect a quick answer, and they expect to be answered by the first person. We can now measure these things. How often are customers connected to the right person? How quickly is their phone answered and their question answered? And how often is their answer given by the first person they talked to?
Looking at these metrics will give us an understanding of how well this process is delivering what the customer wants. And these will be the things that you would measure in the measure phase of Lean Six Sigma.
In summary, define is about describing the problem or the issue. It is about creating realistic goals. It is not about focusing on the solution. It is about understanding what the customer wants from the process. It's also recognizing that customers will assume that you know many of their basic requirements. Creating a Critical to Quality Tree may help now understanding the requirements of the customer, but also understand what is it we need to measure in the measure phase to see whether or not this process is delivering what the customer wants.
This is the end of the define phase.