In the previous post we looked at the potential problems when using an OEE for line balancing. Now, in the fourth post on line balancing, we actually use the OEE to create target cycle times (or, alternatively, a target line takt) for our system before we start balancing the system in the next post.
What to Do with OEE
In any case, now you have the OEE and can calculate the target cycle time based on the customer takt (or, if you prefer it the other way round, calculate the target line or process takt based on the cycle times of the individual tasks). Here again, you have multiple options on how to proceed.
Target Line Cycle Time
The easiest way to do this is to assume that the losses, and hence the OEE, is pretty much the same across all tasks and parts. You also assume that the entire system is working at the same time (i.e., either all processes work or all are off-shift).
The target cycle time for all processes is then simply the takt time multiplied by the OEE. If, as in the example above, your takt time is 60 seconds, and your OEE is 80%, then all processes have a target cycle time of 48 seconds.
This is by far the easiest approach. If you can make the assumption above, then your life will be easier.
Target Process Cycle Time
Sometimes, you have processes where you know that the OEE is different. For example, in your production system you may have one machine that gives you nothing but trouble. If it is mostly trouble that is bigger than the buffers to the adjacent processes, then this is reflected in the OEE of the other processes anyway. However, if there are lots of little problems, then you may choose to use a different OEE for selected processes.
Yet, you mostly can avoid this. If the OEE differs by less than 10%, I would not really bother too much. In my experience, OEEs are not that precise anyway. Additionally, due to interdependence between processes in a flow line, it is rare that one process is significantly better or worse than the rest of the system. Hence, unless you absolutely feel the need to treat one process separately, don’t!
Target Process and Product Specific Cycle Time
Distinguishing the OEE by different processes can even be pushed one step further by also distinguishing by different product types. For example, product A may give you much more trouble than product B. In this case, you could have separate OEEs for different products. But, be warned, you are opening a can of worms that is not easily swallowed (and let me know if I am mixing incompatible metaphors 😉 ).
First of all, do you know your OEE by product type? It may be difficult to separate the OEE for different products. Secondly, you would need to do the calculation “the other way around.” Normally, I take the customer takt and calculate a target cycle time using the OEE. Then I group my tasks into suitable processes that are roughly as fast as the target. However, the task times are by themselves an average. Either I take the task times for the high runners and assume all others are the same, or I create weighted averages (see above).
But by then it is too late to distinguish by product type. Hence, if you really want product-specific OEEs, you would have to take the task times for the individual products and divide them by the appropriate OEE into the task takt time for the individual products. Only now you can combine the task takt times for either the high runner or the weighted average of all products, and then group them into processes where the process takt time matches the customer takt time. Hence, again, unless you absolutely feel the need to treat products separately, don’t!
How Flexible Are You?
An important factor is the flexibility you have in changing your system. By “flexibility,” I mean mainly two things:
Sequence Flexibility: How much can you change the sequence of the processes? Some processes are a prerequisite for another process. Others, however, can be moved before or after another process. The more you can move the processes around, the easier it will be later to design a well-balanced system. There are probably software systems where you can enter the possible sequences; however, this is a lot of work. I would rather play around with the sequence later and see what works instead of spend lots of time adding dependencies into a software tool and then hope that the tool will give me a good result. Hence, as for data collection, you need to be aware of the possibilities of changing the sequence, but in my view it is too much work to actually define it beforehand.
Grouping Flexibility: If it consists mostly of manual work, you have lots of flexibility in grouping the work. If you buy new machines or have universal tooling machines, then you may also have flexibility in deciding which machine does which sub-processes. If you already own dedicated machines for the processes, then you probably have the least flexibility. Hence, some processes can be grouped together with other processes, whereas others have to be an individual cycle. Overall, manual processes are much easier to work with here. Similar to the sequence flexibility, I do not summarize my options beforehand, as this would be too much work. I’d rather play around with different sequences later and then check if they work.
Quick Summary so Far
By now we should have a good overview of the system and all the data we need for the balancing of the line:
- List of tasks and the times needed for the tasks. May be based on high-runner example, weighted average, or multiple sets for multiple products. Usually, it is a task cycle time, but may also be a task takt time including the losses. Should include all tasks that are necessary to make any of the products that have to pass through the system.
- Target cycle time needed to achieve the customer takt with respect to losses (OEE), if your task times do not include losses. If your task times include losses, this should be simply the customer takt. Usually, it is the target cycle time or customer takt across all products, but in rare cases it may be distinguished by product type.
- Some understanding on flexibility in the sequence and the grouping, not necessarily in an exhaustive data set but rather in your head.
At this point you can also make a quick estimate on the number of stations or workers you probably need. You take the sum of all task cycle times and divide it by the target cycle time. For example, if you have work for 460 seconds, and have a target cycle time of 48 seconds, then you would need
\[ {\frac{460 s}{48 s}} = 9.58 stations \]This means that after balancing you probably need around 10 stations or workers in your system.
Now we can actually start balancing the line 🙂 . In the next post I will explain how to do it on paper (my preferred method), before explaining how to do it on a computer and showing you some tricks in the post afterward. Until then, stay tuned and organize your industry!
Line Balancing Series Overview
- Data Overview: List of products, list of tasks, and customer takt
- Duration of Tasks: How to get the duration of tasks, especially if they differ among products
- OEE Caveats: Potential problems when using the OEE to transform takt times to cycle times
- OEE Usage and Flexibility: Once you have the OEE, how do you use it? Also a bit on flexibility.
- Balancing using Paper: Finally, actual line balancing using paper
- Tips and Tricks for Balancing: Some Pro-Tips, and also a bit about line balancing using computers
I love the practical shortcuts in this, Christoph.
Many thanks, Dilesh 🙂
Hello Christoph,
There has been many confusion for me while calculating target output per hour.
I usually take (3600(S) / target CT) * 0,95 = Target per hour (5% would be time to fill productions work order, going toilet, drinking water etc…)
For my boss the 5% or 10% is only a way to hide problems and Its Not Lean because 5 min per hour makes 100 minutes per day and 30000 euros per year and so on…
It’s becoming so frustrating for people on shop floor because the target is not SMART at all.
Also, Target cycle time shouldn’t take into consideration actual machines OEE and should be equal the customer TT. This will push the organization to continuously improv the process while in this case there is a risk to not deliver your customer demand.
Thanks for sharing your experience