One question that comes up quite regularly when I’m demonstrating the XL800 OEE System is: “How can I get the most from an XL800 OEE System when I have more than 1 machine that I want to measure?“.
If you have 1 machine that you want to monitor, or a simple block process, the location for your XL800 OEE System is extremely obvious – you install it on either the single machine, or (and) in an area where the operators can see it easily as per this example:
How to get the most from XL800 OEE System on a Continuous Flow line:
If you have run a continuous flow line (typical of most food, drink, confectionary manufacture) then when we talk about XL most manufacturers say: “We want to install this on the bottleneck machine, and we also want to analyse the other machines on the line”. This presents us with a couple of technical issues; firstly XL800 is optimised to provide detailed analysis of a single machine, secondly as part of analysing a single machine you would need our LineView system to analyse the “causal downtime” i.e. the effect of your other machines on the bottleneck machine. Secondly it presents an operational issue: I know many sites that try to collect everything but don’t act on the data, and they don’t improve. To drive your OEE up – collect only what you need, as simply as possible, and act on it vigorously.
So here’s a work-around that i outline in this scenario:
- Install the XL800 OEE system on your Bottleneck machine as normal
- Install a “lack of product” signal from your infeed conveyor. This signal machines that your bottleneck machine is available to run but cannot run due to lack of product = upstream stoppage.
- Install a “build back” signal from your outfeed conveyor. This signal machines that your bottleneck machine is available to run but cannot run due to build back of product on the outfeed = downstream stoppage
- Install whatever additional faults you want on your bottleneck machine and other machines
How this will help:
- You will know the efficiency and downtime on your bottleneck machine, which is crucial
- You will know that of all the time the bottleneck is not running, how much of that time is due to upstream or downstream issues, rather than the machine just being not available.
With this information i would:
- Carry out a Short Interval Control every hour or 2 hours
- If the greatest loss to my bottleneck machine is lack or buildback then i would identify which machine has caused that loss, and why.
- If i can’t identify why or the root cause, I would put a manual tick sheet on that machine for 1 hour only and ask the operator to get some good quality downtime data.
- I would fix the root cause and review my downtime loss to the bottleneck machine
In my opinion one of the greatest pitfalls that a site can fall into is “I want to collect everything right now”. I promise you that if you try to collect everything you will either collect rubbish by spreading your resource to thin, or you will not be able to take action because you’re reviewing data. Collect only what you need to improve and act on it vigorously.