- New JobKraft FoodsQuality Engineer
OEE HOURLY CALCULATION
As we all know OEE is a multiplication of Availability, Performance and Quality.
There is some debate here on what formula it should be used to calculate OEE every hour. We are a one piece flow environment having the automotive industry as a customer.
Here are some of the formulas that our corporate office came up with:
The OEE by hour calculation should be:
The total number of good parts produced for that hour/the goal
of parts for that hour.
The goal is calculated using the available time we are running
during the hour/the Takt time.
The hourly OEE calc is:
Total assemblies produced – Rejects /Standard machine capability
for one hour
Also during a visit at the plant near our corporate office I saw OEE majority over 100% and I was very surprised knowing that 85% is considered “World Class”
Your comments and help are highly appreciated.
Thank you for your help !!
How to calculate OEE and more OEE templates in xls version You can dowload from http://smartmanagement.info/lean-management/oee/oee-download.html
related to the options I would say : produced std time(it might be that you have different parts produced) by available time is the right way of calculation
100% OEE it is something like stolen your own hat – not realistical.
As a rule of thumb, I use good_units / (available_time x rated_units) for an OEE for the time period being reported on, where rated_units is the expectation/standard/maximum (as per policy) for the product/process being performed.
One of the challenges in reporting oee hour by hour is that some processes have a tail. If it takes 1/4 of an hour for the units into the process to make it to the end, at which point they are counted again as ‘good units’ (with those that don’t make it through counted as waste), then for the first 25% of hour 1, all units counted in will not have made it to the out counter. The same thing happens at the end of the process, where often there are no units fed into the head of the process, but there are units being counted at the output. This amortises over a job usually, or over a greater number of hours.
All good advice but don’t shy away from a basic OEE capture from basic counters that can be placed at two spots in the process to capture final delivery rate vs theoretical rate vs original delivery rate.
Since The topic of OEE is already posted I have a question as well. I would like to know how to calculate Unscheduled Downtime. I can calculate setup times and what not but unless I have the operator time himself or stand in the cell. I cannot get data for every time he makes a offset or a tool change. We have a big problem here with time variance however so could I use CHangeover and time variance in relation with unscheduled downtime?
Are you asking how to categorize the losses into categories?
Chris, No where i learned to do OEE they say in order to get your availability you have to take your net available time which is scheduled time subtracted from required downtime such as breaks, lunch and clean up. You then subtract that from your unscheduled downtime which they say is breakdowns, Changeovers & adjustments, and minor stoppages. Im having a hard time figuring out how im going to realisiically collect data for over 50 machinining centers every time someone has a minor stoppage or makes a offset.
Hmmmm, I’m not sure who taught you that OEE.
OEE is slightly different for different companies but there are 2 mainly recognized models. One takes all scheduled time and subtracts planned downtime for the denominator to calculate % availability.
My preference is not take out planned downtime and is an accepted practice because OEE is a way for you to find your losses. If you create a category to “hide” a loss, then that category tends to grow.
If you can get a sensor installed, find out the % of time that the line/machinery is operating (even at a reduced speed or ramp up/down). Simply put that’s your availability. However, then your challenge is to find out WHAT’s causing the losses and then you can start your observations to find them.
Hope this helps.
@jpfaffinger – Justin: It seems that your question is more about the mechanics of gathering the data, not so much the categories (as @cseider has been guiding you). Generally the most consistent method will be to instrument the equipment (I won’t say most accurate as it will depend on what you instrument, but if you choose the correct location, it should be accurate as well). If you have to do it manually, then you will probably want to do a study on the types of stoppages you have by MC and the time associated with each. Then, you have the operator just tally the number of events by type and you add up the estimated DT as # events x time/event (from study). Crude, but overall it will give you good directional data.
I do agree with Chris that if you subtract “planned” DT you end up with a bunch of things that don’t belong there). You also want to see how much change-overs, breaks, etc. are really consuming so that you can find alternate means of operating.
@Justin – I do the OEE calculation the same way, that is, removing planned downtime. When I started learning the OEE calculation, I thought about this and what I came up with is that PLANNED downtime is already known and measured so that would be why it may not be kept in the data.
As for your original question, I am in the same situation where our machines (60+) are not connected to a network and therefore the data is taken manually. In order to gather the time loss as much as possible, we define short and long stoppages. Short is 10 mins. Associates at the machine will record short stops with tic marks and long stops with actual time. Of course there is still time that is lost, if a recovery takes only 6 minutes but is documented as 10, 4 minutes will be doubled up with production time. However, for the size of my company and the willingness of upper management to invest in data capture, this system works well enough for continuous improvement efforts (for now).
Connecting machines or gages to a DB should be simpler now days, since few tools are built without some kind of data port, that supports some kind of data transfer protocol. In the bad old days, we had to “wire behind the light bulbs” to see when a machine was ON vs OFF, but even that paid off over time with many tools.
Tool data integration is a specialty not found in many IT organizations, who do not work on “real-time” operating systems, but rather get data from tracking systems after operators manually enter data. If OEE is a hot topic at your shop, perhaps rudimentary data capture might be better than the usual mistake-prone typed data. Each industry has tool vendors who understand tool data capture issues, so at least you might ask them, regardless of what your IT people say “cannot be done.” In semiconductor industry, we evolved communications protocol standards for all our tool vendors to follow (SECS I and II using RS-232 port, and later high speed messaging using ethernet ports.) Texas Instruments famously “wired behind the light bulbs” on a lithography tool that was used in many of their fabs worldwide, to see “when is lamp flashing” as that means the tool was at least exposure wafers to circuit pattern reticles, and they found that one fab was 2x better at OEE using that simple input, so they then studied it and were able to clone setup and scheduling ideas across all fabs, saving the cost of an entire new fab! At other extreme, machine sensor data can be streamed to multivariate analysis tools to detect FAULT counts (fault detection and classification schemes are common for some industrial tools). The idea is that if the tool is still doing the same things, the fault counts can be sensor means, medians, or inter-quartile-range spreads of time, power, voltage, current, whatever by process step vs history during known good product periods. For plasma etching, we found that the slope of the end-point-detector signal correlated to variation in line widths from center to edge of a wafer.
Even in low tech factories, simple data capture by a tablet attached to a machine data port, or to the on-off signal from operator start button, can give valuable information to maintenance and engineering folks.