OEE (overall equipment effectiveness) is a key metric to measure process delivery and productivity (for more information about the different types of metrics, click here). The theory is simple: OEE compares “net operation time” with the “real time” to see how well things have gone. Let’s see an example:
The concept of Real Operation Time looks innocent, but it is very tricky. There are uncountable circumstances where some people will think that the process is in operation, while others will believe that it is not. Imagine you are tracking a batch and taking data. You have to decide if the following events should be part of the Real Operation Time (or not) to calculate OEE:
- The machine is running at maximum speed
- The machine is running but producing bad parts
- The machine is running slower than it could
- The machine is stopped (breakdown)
- The machine is stopped (no material)
- The machine is stopped (cleaning)
- The machine is stopped (operators training, meetings)
- The machine is stopped (shift not scheduled)
- The machine is stopped (weekend)
Everybody agrees that situations 1-4 are part of the ROT, but then the discussion begins. Typical questions are “Why should I be penalized if I’m training the operators? Or cleaning the equipment? Or if I decide not to use the equipment?”. These are fair questions. The answer is that there is no answer. Everything depends on what you want to use OEE for.
- Do you want to improve machine downtime? Then ROT = 1+2+3+4
- Do you want to improve scheduling? Then ROT = 1+2+3+4+5+6+7
- Do you want to know if you have to buy extra equipment? Then ROT = 1+2+3+4+5+6+7+8+9
The lesson here is that OEE means nothing without a model. The number itself is meaningless. It is the trend (going up, going down) what matters. Everything depends on the model, and the model depends on your improvement goal. Use OEE calculations to help you understand the process and find the problems you need to solve to improve according to your goal. Don’t you have a goal? Then you don’t need OEE.
A typical OEE model look like this:
It’s your choice to decide how many of the seven blocks (NOT, QL, TL, UD, PD, UT, NPT) are part of your OEE. That is your model. All models are potentially valid; a model is good or bad just depending on how well it is aligned with your goal.
OEE is typically divided in 4 categories: Loading, Availability, Throughput and Quality:
- Loading: Scheduled Time (TST) / Calendar Time (TCT)
- Availability: Running Time (RT) / Scheduled Time (TST)
- Throughput: (Total Parts * Max Cycle Time) / Running Time (RT)
- Quality: Good parts / Total Parts
Many people consider that the “Loading” portion depends only on how you decide to schedule work and has nothing to do with equipment effectiveness. Therefore it is unfair to consider “Loading” as part of the OEE and should not be part of the calculation. To solve this philosophical problem, a new metric called TEEP (Total effective equipment performance) is born:
- OEE = Availability x Throughput x Quality
- TEEP = Loading x Availability x Throughput x Quality
The story of OEE has just begun! Don’t miss more information about OEE calculations, typical errors using OEE and an OEE guide in following posts!
“Trust the process” is one of the most important Lean mantras. The process is the king of the Lean castle and just like real kings, each process is different. A process is good if:
- it is standard (repeatable: the same situations drive to the same actions)
- it is documented (teachable: everybody knows how things work)
- it is fair (balanced: there is enough people/time/equipment to do things and solve problems)
- it is visible (measurable: problems are easy to find)
- it has a clear owner (actionable: problems are solved)
These rules are easy to list and difficult to fulfill. But even if a process does not follow all of them, it is important to keep them in mind to know what is missing and what must be done next.
“Sticking to the process” is extremely important for several reasons. If the process is not well defined or if it is executed differently each time:
- It is not repeatable: There is no reference to know if the process is working fine or not. This means that there is no clear definition of “good” and this makes very difficult to know if the process is in trouble. Problems are hidden, which is one of the worst things that can happen.
- It is not teachable: teaching is extremely difficult because nobody knows what to expect. The same situation will drive to very different responses. This creates a very confusing environment where teaching and learning are hard things to do.
- It is not balanced: if you don’t know how the process will look like, how can you put the needed people/time/equipment in place? How can you predict capacity or lead time?
- It is not measurable: how can you measure something that can not be seen? Yes, you can take some numbers here and there, but data will not be consistent and comparable, so trends and systematic problems are almost invisible.
- It is difficult to improve: there will be little or no time to think calmly, analyze problems and put robust solutions in place. Even worse, all ideas and improvement actions identified by the workers will be lost, because everybody will do things their own way.
So please, slow down, calm down, don’t worry, don’t hurry and stick to the process!
Efficiency and effectiveness are two terms widely used in operational excellence and Lean. They are used indistinctly many times, but their meaning is really different:
Efficiency is doing the thing right. Effectiveness is doing the right thing.
Effectiveness is related with the Critical Quality Attributes of the product: those features and characteristics that your customer expects and is willing to pay for. A process is effective only if it provides what the customer wants. Efficiency is linked to Performance: how work is done and how well are the available resources used.
All combinations of effective/ineffective – efficient/inefficient are possible, even the counter-intuitive “efficient & ineffective” (well, some people think that effective is a prerequisite for efficient. This means that a process not doing the right things – therefore, ineffective – can not be considered efficient. It’s a valid point but I’ll consider effectiveness and efficiency independent from now on). Let’s see an example. Imagine I want a portion of pizza for dinner. Four things can happen:
- The taste and temperature of the pizza is perfect (effective) and I get it very quick (efficient)
- The taste and temperature of the pizza is perfect (effective) but I have to wait too long (inefficient)
- I get a cup of coffee instead of pizza (ineffective) but very quick (efficient)
- I get cold pizza (ineffective) and I have to wait too long (inefficient)
Please note that in this example we are assuming that a quick process is an effective process. This is not necessarily true for several reasons. First, speed can be accomplished assigning excessive resources to do a job. This would lead to high speed but also to high costs, which is absolutely not efficient. Second, speed is often a Critical Quality Attribute, more related with effectiveness than with efficiency. However the “speed = efficiency” assumption is a fair simplification for this example.
Efficiency is important; effectiveness is absolutely critical. Ineffective processes are constantly producing things your customers will not buy: this destroys the company reputation and economy. Always solve effectiveness problems immediately. Then, when you know you are doing the right things, it’s time to start thinking how to improve them.
There is nothing quite so useless, as doing with great efficiency, something that should not be done at all.
This is a real example of a process map I found recently as part of a SOP (click on the image to zoom):
It is a great example of how not to do a process map because it does not follow the most basic rules of mapping. First of all, let’s remember the main purpose of process maps. Yes, you are right, their goal is to describe a process in a clear, visual and unambiguous way. Two notes on this:
- Processes are complex beings that result of the combination of tasks, materials, machines, people, methods and the environment. Not all these components must be part of your map. Many times simplicity is more important than precision (for an accurate description of a process, a SOP or a standard worksheet are typically a better option). However, consider all of them and include everything that can make the map more understandable.
- Maps greatest strength is that they are visual. Most people prefer getting information visually and process maps are one of the best ways to do this. Avoid the massive use of text.
Let’s summarize the key rules for creating great maps:
- Make clear where the process starts and ends: It is so sad to spend minutes looking for the process start point… One good way is to use a rounded rectangle to mark the beginning and the end. (The example map uses a black arrow to mark the start point and nothing to mark the end.)
- Represent time correctly: If you write left to right, why don’t you do the same with your maps? Representing time from left to write (or top-down) will make the process more clear. S-shapes, O-shapes or W-shapes may be appropriate sometimes, but in most cases they will make the map difficult to understand. (The example map uses an O-shape most of the time and a Y-shape at the end. There is no need to do that. Additionally, there is no clear evidence of how time goes by)
- Represent tasks and precedences correctly: The task order must be consistent and, of course, possible. (The example map proposes to “reuse” the product after its “destruction”. This is obviously impossible)
- Be consistent:
- Use always the same symbols for the same things. (The example represents tasks using 4 different ways: blue boxes, blue diamonds, pink diamonds and plain text)
- Represent the same type of information in the same way (The example uses plain text for: tasks, task owner (MANAGER) and locations (WAREHOUSE),…)
- Colors must mean something: Few things are more misleading than the random use of colors. If you use different colors, make sure they mean something relevant (The example uses red and green arrows, but they mean the same, I think)
- Use standard symbols: There are several symbols widely accepted. A box means a task, a diamond means a decision, a circle is the start/end point, red means bad, greed means good… If you choose not to follow them, at least be consistent (rule #3) and show the meaning of each symbol. (The example uses a black arrow to indicate the start point and diamond boxes for tasks, which are not a standard symbols. If you want to do so, explain the new meaning of the symbols somewhere)
- Map one thing at a time: You don’t have to put everything (every piece of data, every process) on your map. Remember that a confusing map is a useless map. Sometimes it makes sense to draw several processes together, but consider separating them to improve clarity. (The example maps several processes: product availability, product manufacturing, product reevaluation and product destruction. It makes sense to mix those processes because the map is very high level; however it would be beneficial to visually separate them or to create different maps for each process and increase the level of detail)
Good maps make training quicker and more effective. This results in fewer errors and higher execution speed. They are worth the effort.
- Guide to creating process maps: http://www.isixsigma.com/tools-templates/process-mapping/practical-guide-creating-better-looking-process-maps/
- Symbols reference: