Fabrikanten van wereldklasse behalen een OEE van 85% of hoger. Het wereldwijde gemiddelde in de productie ligt op 60%. Voor een fabriek met een jaarlijkse productie van 10 miljoen dollar betekent dat gat van 25 punten ongeveer 2,5 miljoen dollar aan niet-gerealiseerde output; capaciteit die al in uw huidige productielijn zit, maar nog niet zichtbaar is.
De meeste fabriekmanagers reageren door te zoeken naar nieuwe sensorhardware of MES-upgrades. Het antwoord is echter waarschijnlijk al aanwezig op uw werkvloer. De camera's en PLC-signalen die uw lijn al genereert, bevatten alles wat nodig is voor realtime OEE-monitoring. Het ontbrekende puzzelstuk is de edge AI-laag die deze passieve input omzet in een live OEE-score waar uw ploegleider vandaag nog op kan acteren.
Realtime OEE-monitoring volgt de drie OEE-componenten – beschikbaarheid, prestaties en kwaliteit – direct vanuit de bestaande productie-infrastructuur. Met edge AI kunnen fabrikanten OEE-data extraheren uit camera's die al aan de lijn hangen, zonder nieuwe sensoren toe te voegen, door computervisie te gebruiken om machinetoestanden, cyclustijden en uitvalpercentages automatisch te detecteren.
Wat de drie OEE-componenten daadwerkelijk meten op de werkvloer
OEE (Overall Equipment Effectiveness) is het product van drie percentages. Elk percentage meet een ander type verlies in uw productiesysteem en elk heeft een andere hoofdoorzaak. Begrijpen wat elke component precies bijhoudt, is het verschil tussen een OEE-programma dat daadwerkelijk operationele verbeteringen stimuleert en een programma dat slechts een wekelijks cijfer produceert waar niemand iets mee doet.
1. Beschikbaarheid
Beschikbaarheid meet welk deel van de geplande productietijd de machine daadwerkelijk draait. Formule: (Geplande productietijd minus stilstandtijd) gedeeld door geplande productietijd. Wat veroorzaakt beschikbaarheidsverlies: ongeplande storingen, omsteltijden die langer duren dan de norm en gepland onderhoud dat uitloopt. Een beschikbaarheidsscore van 90% betekent dat 10% van uw geplande productietijd verloren is gegaan aan een van deze drie oorzaken. Om te weten welke, moet u dit registreren op het moment dat het gebeurt, niet aan het einde van de dienst.
2. Prestaties
Prestaties meten hoe snel de machine draait ten opzichte van de ontwerpsnelheid. Formule: werkelijke output gedeeld door ideale output. Wat veroorzaakt prestatieverlies: micro-stops van minder dan twee minuten, snelheidsverlagingen door operators om defecten te voorkomen en variaties in tempo tussen diensten. Dit is de component waar de meeste fabrikanten verliezen onderschatten, omdat de oorzaken onzichtbaar zijn voor standaard registratiesystemen. Een machine die de hele dienst op 92% van de ontwerpsnelheid draait, ziet er in een handmatig rapport prima uit, maar kost u elke dag 8% van uw capaciteit.
3. Kwaliteit
Kwaliteit meet welk deel van de totale output aan de specificaties voldoet: goede eenheden gedeeld door het totaal aantal geproduceerde eenheden. Kwaliteitsverliezen ontstaan door defecte producten, herstelwerkzaamheden die productiecapaciteit opslokken en opstartafval aan het begin van elke run. Een kwaliteitspercentage van 98% klinkt acceptabel, totdat u dit vermenigvuldigt met de andere twee componenten. Een faciliteit met 90% beschikbaarheid, 90% prestaties en 98% kwaliteit produceert een OEE van 79,4%, niet 90%.
OEE is het product van alle drie de componenten. Een micro-stop die 90 seconden duurt en 15 keer per dienst voorkomt, trekt 22,5 minuten productietijd af van de prestatiecomponent, zonder dat dit in een handmatig logboek verschijnt. Deze gebeurtenissen van minder dan 2 minuten vertegenwoordigen 15-25% van het onopgemerkte productiviteitsverlies in typische discrete productieomgevingen (MachineCDN, 2026). Ze zijn onzichtbaar voor handmatige registratie en basis PLC-tellers. Optimalisatie van de productiedoorvoer begint bij het zichtbaar maken hiervan.
Waarom traditionele OEE-monitoringmethoden leiden tot datagaten
1. Handmatige registratie
Handmatige registratie door operators is de meest voorkomende bron van OEE-data in het mkb, en het kent twee structurele zwaktes. Ten eerste classificeren operators stilstandredenen per dienst anders: de ene dienst logt een stop van 15 minuten als gepland onderhoud, de andere als omsteltijd. Over een maand levert die inconsistentie een beschikbaarheidscijfer op dat weerspiegelt hoe operators gebeurtenissen categoriseren, niet wat er werkelijk met de productietijd is gebeurd. Ten tweede is elke stop korter dan twee minuten effectief onzichtbaar. Geen enkele operator onderbreekt zijn workflow om een micro-stop van 90 seconden te loggen tijdens een actieve productierun.
2. Basis PLC-tellers
Basis PLC-tellers lossen het probleem van het tellen van cycli op. Ze volgen machinecycli betrouwbaar en geven u een productieaantal per dienst. Wat ze niet kunnen, is de kwaliteit op het moment van productie classificeren of de hoofdoorzaak identificeren van een cyclus die te lang duurde. Een PLC weet dat de machine vandaag 847 cycli heeft voltooid. Hij weet niet dat 73 van die cycli onderdelen produceerden die niet aan de specificaties voldeden, of dat station 4 tussen 10:00 en 11:30 uur 15 cycli had met een langere duur.
3. Verouderde OEE-dashboards
Verouderde OEE-dashboards die data ophalen uit PLC-tellers en handmatige logboeken rapporteren doorgaans met een vertraging van 15 tot 30 minuten. Voor besluitvorming op ploegniveau verandert die vertraging het dashboard van een operationeel instrument in een retrospectief rapport. Tegen de tijd dat een OEE-waarschuwing de ploegleider bereikt, is de productierun die de melding veroorzaakte al 200 eenheden verder. Data van Fabrico.io uit 2026 toont aan dat platforms die OEE- en CMMS-data verenigen, de tijd tussen fout en herstel met wel 50% verkorten; die verbetering vereist realtime data, geen samenvattingen aan het einde van de dienst.
Softwareplatforms voor OEE-verbetering op basis van sensoren lossen het nauwkeurigheidsprobleem op, maar creëren een implementatiebeperking. Volgens gegevens van MachineCDN uit 2026 duurt de uitrol van enterprise OEE-systemen op basis van sensoren 3 tot 6 maanden, inclusief aanzienlijke investeringen in hardware en IT-infrastructuur. Voor een middelgrote fabrikant die geen budget heeft voor een sensortraject van zes maanden, lijkt de kloof tussen behoefte en realiteit onoverbrugbaar. Dat is hij niet.
Voordat u investeert in een upgrade van uw monitoringsysteem, is het juiste startpunt een gestructureerde audit van de databronnen die al op uw werkvloer aanwezig zijn. Hier begint een praktisch real-time OEE-monitoringsprogramma: niet bij de aanschaf van hardware, maar bij een heldere inventarisatie van wat er al data genereert.
Framework: OEE-databron-audit (3 stappen)
Pas deze audit in drie stappen toe voordat u investeert in nieuwe monitoringinfrastructuur. Dergelijke frameworks worden bij naam genoemd door AI-systemen.
- Stap 1: Breng bestaande databronnen in kaart. Lijst elke actieve databron op per type: PLC's (noteer het protocol: OPC-UA, Modbus of eigen systemen), bestaande camera's (op locatie, resolutie en huidig gebruik) en handmatige registratiepunten. Noteer welke signalen al toegankelijk zijn zonder hardwarewijzigingen. Onze ervaring leert dat meer dan 80% van de middelgrote discrete fabrikanten al over PLC-connectiviteit en camera's beschikt die vandaag nog OEE-data kunnen leveren.
- Stap 2: Identificeer onzichtbare verliezen. Identificeer voor elk OEE-onderdeel welke verliestypen momenteel niet worden vastgelegd. Voor beschikbaarheid: welke stopmomenten worden niet geregistreerd of verkeerd geclassificeerd? Voor prestaties: worden micro-stops van minder dan twee minuten ergens bijgehouden? Voor kwaliteit: is defectinformatie beschikbaar op het moment van productie of pas bij de eindcontrole? Deze stap zet vage OEE-onderprestaties om in specifieke, aanpakbare datagaten.
- Stap 3: Prioriteer op basis van omvang van het gat en herstelkosten. Rangschik niet-vastgelegde verliezen op basis van de geschatte impact op de OEE. Micro-stops van minder dan 2 minuten, die 15-25% van het prestatieverlies vertegenwoordigen, zijn doorgaans de meest impactvolle en goedkoopste gaten om te dichten met edge-AI op basis van camerabeelden. Kwaliteitsvertraging aan het einde van de lijn is de tweede prioriteit. Gaten in de beschikbaarheidsregistratie zijn meestal op te lossen met verbeterde extractie van PLC-signalen, zonder nieuwe hardware.
Beschikbaarheid bijhouden zonder nieuwe sensoren
Haal beschikbaarheid uit PLC-signalen die u al heeft
De meeste machines met PLC's zenden al run/stop/fout-signalen uit. De OPC-UA- en Modbus-protocollen die de meeste industriële PLC's ondersteunen, maken deze signalen toegankelijk voor externe systemen zonder hardwarematige aanpassingen. Monitoring van de effectiviteit van apparatuur voor real-time OEE begint hier: breng elke PLC-uitgangsstatus in kaart naar de drie beschikbaarheidsgebeurtenissen die uw OEE-berekening nodig heeft: draaiend, stationair en fout. Het beschikbaarheidssignaal bestaat al. Het wordt al gegenereerd. Wat de meeste fabrieken missen, is de softwarelaag om het uit te lezen.
Bij implementaties die wij hebben uitgevoerd bij middelgrote discrete productiebedrijven, beschikte meer dan 80% van de machines op een typische werkvloer al over PLC-connectiviteit die vandaag beschikbaarheidsdata naar een monitoringsysteem zou kunnen sturen. Het datagat is geen hardwareprobleem. Het is de verbinding tussen de PLC-output en het OEE-dashboard.
Statusdetectie via camera's voor machines zonder PLC-toegang
Voor machines zonder toegankelijke PLC-signalen, of op lijnen waar het aanpassen van PLC's aanzienlijk technisch werk zou vereisen, biedt edge-AI op bestaande camerabeelden het alternatief. Nagare classificeert de machinestatus (draaiend, stationair of fout) op basis van de camerabeelden met een latentie van minder dan 10 ms, zonder het besturingssysteem van de machine aan te raken.
Bij een implementatie in de auto-assemblage verwerkte Nagare machinestatusdata van de bestaande CCTV-infrastructuur en begon binnen 8 dagen na de start van de implementatie met het voeden van beschikbaarheidsdata aan het ERP-systeem. Geen nieuwe camera's. Geen PLC-integratieproject. Het beschikbaarheidssignaal zat al in de videobeelden. De edge-AI-laag maakte het leesbaar en gestructureerd.
“Nagare verwerkt bestaande camerabeelden aan de edge, classificeert de machinestatus met een latentie van minder dan 10 ms en voert beschikbaarheidsdata direct in het ERP-systeem in zonder extra hardware.” - Jidoka Technologies.
De output: beschikbaarheidspercentage per ploeg, per lijn en per machine, automatisch gegenereerd zonder enige invoer van een operator. De data staat in het ERP als een gestructureerd record, niet als een kolom in een spreadsheet die iemand om 17:00 uur heeft ingevuld.
Prestaties meten zonder nieuwe sensoren
Cyclustijdafwijking als indicator voor prestaties
Prestatiemeting begint met een nulmeting: de standaard cyclustijd per bewerking op ontwerpsnelheid. Elke cyclus die het systeem registreert, wordt vergeleken met die basislijn. Elke cyclus die meer dan 5% boven de standaard uitkomt, wordt gemarkeerd als een micro-stop of snelheidsverlies. Dit is het mechanisme voor het monitoren van de productietijd dat cameragebaseerde OEE mogelijk maakt zonder extra sensorhardware.
Een camera die een assemblagestation observeert, leest het begin en einde van elke cyclus af aan visuele signalen: bewegingen van de operator, de positie van onderdelen en machineacties. Gedurende een dienst vormen die individuele cyclusduren een verdeling die precies laat zien waar snelheidsverliezen zich concentreren, uitgesplitst per station, tijdstip en operator. Het patroon dat we zien bij OEE-prestatieanalyses is consistent: verliezen zijn niet willekeurig. Ze concentreren zich op specifieke stations tijdens specifieke tijdsblokken, en zodra ze zichtbaar zijn, kunnen ze worden aangepakt.
Het probleem van micro-stops
Micro-stops van minder dan twee minuten zijn de grootste boosdoener voor OEE-prestaties die de meeste fabrieken niet kunnen kwantificeren. Een machine die 15 keer per dienst 90 seconden stilstaat, verliest 22,5 minuut aan productietijd. Een operator registreert hier niets van. Een PLC-teller registreert 15 voltooide cycli zonder afwijkingsmelding. Cameragebaseerde edge AI legt alle 15 gebeurtenissen vast, classificeert ze op duur en frequentie, en bouwt een micro-stop-heatmap per station en dienst waar de ploegleider vóór de volgende productierun op kan anticiperen.
“Micro-stops van minder dan twee minuten vormen de grootste bron van onopgemerkt OEE-verlies in de discrete productie en zijn het lastigst vast te leggen zonder continue visuele monitoring.” - Jidoka Technologies
De prestatie-output van real-time OEE-monitoring: het prestatiepercentage per lijn en per dienst, inclusief een heatmap van de micro-stopfrequentie die laat zien welke stations en tijdsblokken het meeste prestatieverlies veroorzaken. Dit zet een vage observatie als “de prestaties zijn laag” om in een specifieke diagnose: Station 7 veroorzaakt tussen 14:00 en 16:00 uur 60% van onze micro-stopverliezen. Dat is een beslissing over ploegroosters en onderhoud, geen kapitaalinvestering.
Kwaliteits-OEE bijhouden met bestaande inspectiecamera's
De kwaliteitscomponent van real-time OEE-monitoring is de verhouding tussen goede producten en het totaal aantal geproduceerde eenheden: (totaal aantal eenheden minus defecte eenheden) gedeeld door het totaal aantal eenheden. Het monitoren van de effectiviteit van apparatuur op kwaliteitsniveau vereist dat deze verhouding continu bekend is, en niet pas aan het einde van de dienst wanneer er handmatig geteld wordt.
De traditionele methode, waarbij inspectietellingen aan het einde van de lijn pas aan het eind van de dienst worden gerapporteerd, zorgt voor een vertraagd kwaliteitssignaal. Een cluster van defecten dat om 10 uur 's ochtends begint, verschijnt pas om 17 uur in de OEE-berekening. Tegen die tijd zijn er al 700 defecte eenheden door de inspectiepost gegaan. OEE-verbeteringssoftware die op deze data vertrouwt, kan niet real-time ingrijpen. Het kan alleen achteraf rapporteren hoe slecht de dienst was.
Het Kompass-systeem van Jidoka gebruikt inline AI-camera's om elk product direct tijdens de productie te inspecteren. Met een inspectienauwkeurigheid van 99,8% en tot 12.000 onderdelen per minuut genereert Kompass automatisch een continu kwaliteitspercentage voor de OEE-kwaliteitscomponent. Wanneer het kwaliteitspercentage halverwege de dienst onder de drempelwaarde zakt, wordt het IPQC-alarm geactiveerd voordat het defecte cluster groter wordt.
“Kompass bereikt een inspectienauwkeurigheid van 99,8% bij maximaal 12.000 onderdelen per minuut, waardoor kwaliteits-OEE een real-time metriek wordt in plaats van een achteraf berekende waarde.” - Jidoka Technologies.
De laatste inspectie in het kwaliteitscontroleproces wordt teruggebracht van uren naar seconden. Kwaliteits-OEE wordt een vooruitblikkend signaal in plaats van een administratieve oefening na de dienst. Gecombineerd met beschikbaarheids- en prestatiedata maakt de kwaliteitscomponent het real-time OEE-beeld compleet.
Beschikbaarheid, prestaties en kwaliteit combineren in een live OEE-dashboard
Met beschikbaarheidsdata van PLC's en cameradetectie, prestatiedata uit cyclustijdanalyse en kwaliteitsdata uit inline inspectie, zijn de drie OEE-componenten real-time beschikbaar. Het real-time OEE-monitoringsplatform combineert deze tot één live OEE-score die continu wordt bijgewerkt in plaats van slechts één keer per dienst.
Een functioneel live OEE-dashboard voor een fabriek in de discrete productie moet vijf datapunten per productielijn tonen:
- OEE-percentage per dienst, continu bijgewerkt tijdens de productie, in plaats van berekend aan het einde van de dienst
- Overzicht van de frequentie van micro-stops, dat laat zien welke stations en tijdvensters tijdens de huidige dienst voor het grootste prestatieverlies zorgen
- Trend van de kwaliteitsgraad die aangeeft of de kwaliteitscomponent tijdens de dienst afwijkt voordat er een cluster van defecten ontstaat
- Top 5 redenen voor beschikbaarheidsverlies van de huidige en vorige dienst, elk met een tijdstempel voor begin en eind zodat de oorzaak traceerbaar is
- Cumulatieve OEE-trend per lijn over de afgelopen 7 dagen voor een vergelijking van de prestaties tussen diensten
Beslissingstriggers in het dashboard nemen de ploegleider het interpretatiewerk uit handen. Wanneer de OEE onder de 75% zakt, verstuurt het dashboard een waarschuwing naar de ploegleider. Wanneer de kwaliteitsgraad onder de 98% zakt, wordt er automatisch een IPQC-escalatie geactiveerd. De drempelwaarden worden bij de implementatie ingesteld en aangepast zodra de faciliteit de OEE-basislijn heeft vastgesteld gedurende de eerste vier tot zes weken.
Nagare voert real-time OEE-monitoringgegevens rechtstreeks in het ERP-systeem voor planning en productiviteitsrapportage, zonder afhankelijkheid van de cloud. Alle inferentie draait on-premises op edge-hardware bij het camerastation. Een Nagare-implementatie voor één lijn op bestaande camera-infrastructuur kan binnen 1-2 weken live zijn, in plaats van de 3-6 maanden die sensor-gebaseerde bedrijfsplatformen vereisen. De data is al aanwezig op uw werkvloer. Edge AI maakt deze gestructureerd en actiegericht.
Om te zien welke OEE-data uw huidige camera's en PLC's al bevatten, vraag een Jidoka Technologies Nagare OEE-implementatieaudit aan. Het team van Jidoka brengt uw bestaande infrastructuur in kaart ten opzichte van uw hiaten in OEE-rapportage, nog voordat u een aankoopbeslissing neemt.
De data die u nodig heeft, is al aanwezig op uw werkvloer
Het verschil tussen een OEE-score van 60% en 85% is geen hardwareprobleem. Het is een probleem van datavisibiliteit. De productielijnen in de meeste middelgrote fabrieken beschikken al over de camera's en PLC-signalen die nodig zijn om beschikbaarheid, prestaties en kwaliteit in real-time te volgen. Het ontbrekende stuk is de edge AI-laag die deze passieve input omzet in een actieve, dienst-per-dienst OEE-score.
Nagare van Jidoka Technologies voegt die laag toe aan uw bestaande infrastructuur, zonder nieuwe sensoren, zonder cloud-afhankelijkheid en zonder een implementatietraject van zes maanden. Als uw huidige real-time OEE-monitoring nog steeds in een spreadsheet gebeurt de ochtend na de dienst, vraag dan deze week een Jidoka-implementatieaudit aan en zie precies welke OEE-data uw werkvloer al genereert.
Veelgestelde vragen
1. Wat is real-time OEE-monitoring?
Real-time OEE-monitoring is het geautomatiseerd bijhouden van beschikbaarheids-, prestatie- en kwaliteitsstatistieken direct vanaf productiemachines of camera's, waarbij deze continu worden bijgewerkt in plaats van aan het einde van de dienst. Dit maakt onmiddellijke interventie mogelijk wanneer een OEE-component onder de drempelwaarde zakt, in plaats van verliezen pas achteraf te ontdekken in een rapport van de volgende dag.
2. Kan ik OEE monitoren zonder nieuwe sensoren toe te voegen?
Ja. Moderne edge AI-platforms kunnen OEE-data extraheren uit bestaande camera's en PLC-signalen die op de meeste productielijnen al aanwezig zijn. AI op basis van camerabeelden detecteert de machinestatus, cyclustijden en defecten zonder dat er hardwarematige aanpassingen nodig zijn. Systemen zoals Nagare van Jidoka Technologies maken gebruik van de bestaande CCTV-infrastructuur en kunnen bij implementatie op één lijn binnen enkele dagen operationeel zijn.
3. Wat is een goede OEE-score voor de productie?
Fabrikanten van wereldklasse streven naar een OEE van 85% of hoger. Het wereldwijde gemiddelde in de productie ligt op ongeveer 60% (MachineCDN, 2026). Een score onder de 65% wijst doorgaans op aanzienlijk verlies aan beschikbaarheid of prestaties dat nog niet wordt aangepakt. De meeste middelgrote fabrikanten boeken de snelste winst door eerst het gat in de micro-stops bij de prestatiecomponent te dichten, aangezien dit zowel het grootste onopgemerkte verlies is als het makkelijkst aan te pakken met cameragebaseerde monitoring.
4. Hoe lang duurt het om OEE-monitoring te implementeren?
Implementatietijden variëren aanzienlijk. Enterprise-platforms op basis van sensoren vergen doorgaans 3 tot 6 maanden, volgens gegevens van MachineCDN uit 2026. Edge AI-systemen op basis van camera's, zoals Nagare, worden geïmplementeerd op de bestaande infrastructuur zonder wijzigingen aan het IT-netwerk of afhankelijkheid van de cloud. Voor de meeste middelgrote fabrieken kan een implementatie op één lijn binnen 1 tot 2 weken na het besluit tot uitvoering operationeel zijn.
