Wat gegevensverzameling op de werkvloer moet afstemmen
OEE lijkt één percentage. Het is opgebouwd uit metingen die door verschillende systemen onafhankelijk van elkaar worden gedefinieerd.
- Geplande productietijd: de ploegendienstkalender, die in het ERP staat en waar de machine niets van weet
- Stilstand en de reden daarvan: de machine registreert dat deze is gestopt, en alleen een operator of het Manufacturing Execution System (MES) weet of dat een storing, een ombouw of een pauze was
- Ideale cyclustijd: het tempo waarin het onderdeel geproduceerd zou moeten worden, meestal vastgelegd in de routing in het ERP in plaats van in de machine
- Goede aantallen versus totaal aantal: de machine telt cycli en de kwaliteitscontrole bepaalt welke daarvan verkoopbaar zijn
- De order waartoe de output behoort: welke werkorder op dat moment liep, iets waar de machine geen reden toe heeft om te weten
Slechts één van die vijf is afkomstig van de machine. De rest komt uit bedrijfssystemen, en dat is waarom een verzamelproject dat stopt bij de machine een cijfer oplevert dat niemand kan verdedigen.
Waarom levert gegevensverzameling op de werkvloer twee OEE-cijfers op?
Definities lopen uiteen nog voordat er iets anders gebeurt. Als de geplande productietijd in het ene systeem gepland onderhoud uitsluit en in het andere systeem insluit, verschilt de beschikbaarheid met enkele punten zonder dat een van beide systemen ongelijk heeft. Hetzelfde geldt voor de vraag of een stop van vijf minuten telt als stilstand of als een micro-stop die wordt opgenomen in de prestaties.
Timing vergroot de kloof nog verder. Machinegegevens komen continu binnen, terwijl ERP-boekingen pas worden verwerkt wanneer iemand een productieorder bevestigt, vaak aan het einde van een dienst. Het vergelijken van een live-cijfer met een bevestigd cijfer meet net zozeer de rapportagevertraging als de prestaties. Die vertraging is het probleem dat real-time productiemonitoring aan de architectuurkant oplost.
Toewijzing is de minst opvallende van de drie, maar wel de duurste. Output die aan de verkeerde werkorder wordt gekoppeld, klopt op fabrieks-niveau nog steeds in het totaal, terwijl de kosten van elke betrokken opdracht onjuist worden weergegeven. Dat is de reden waarom cijfers op fabrieks-niveau redelijk lijken, terwijl de nacalculatie onbetrouwbaar blijft.
Geen van deze drie is een sensorprobleem, en daarom helpt het kopen van meer sensoren niet.
Waar een onbetrouwbaar OEE-cijfer geld kost
Het dashboard faalt niet opzichtig. Het wordt stilletjes genegeerd, en de kosten stapelen zich daarachter op.
- Vergaderingen waarin wordt gediscussieerd over het cijfer: tijd die wordt besteed aan het debatteren over wiens cijfer klopt, in plaats van wat eraan gedaan moet worden
- Verbeterprojecten gericht op het verkeerde verlies: als omsteltijden onterecht als storingen worden gecategoriseerd, wordt het onderhoudsbudget uitgegeven aan zaken waar het instelproces het eigenlijke probleem was
- Nacalculatie die niet kan worden vertrouwd: output die aan de verkeerde order wordt toegewezen, vertekent de marge van beide orders
- Capaciteitsplanning op basis van opgeblazen tarieven: plannen op basis van een theoretische cyclustijd die niemand ooit heeft gehaald, leidt tot beloftes die de fabriek niet kan waarmaken
- Investeringsvoorstellen die vastlopen: een machinevervanging die wordt onderbouwd met OEE-gegevens komt stil te liggen wanneer de financiële afdeling de nulmeting niet kan verifiëren
De instinctieve reactie wanneer een cijfer niet klopt, is om er meer van te verzamelen.
Waarom het verzamelen van werkvloergegevens in twee richtingen moet verlopen
Meer verzamelen vanaf de werkvloer betekent meer sensoren, een fijnere granulariteit en kortere intervallen. Dat verbetert de resolutie van de helft die al werkt, maar laat het meningsverschil precies waar het was.
De andere helft is context. Een stopgebeurtenis wordt pas uitvaltijd met een reden wanneer iemand of iets deze classificeert. Een cyclustelling wordt pas een telling van goede producten nadat de kwaliteitscontrole deze heeft goedgekeurd. Een productiehoeveelheid wordt pas betekenisvol wanneer deze gekoppeld is aan de bijbehorende werkorder.
De echte vereiste loopt dus in beide richtingen. De werkorder, routing en ploegenkalender moeten de werkvloer bereiken zodat machinegegevens kunnen worden gelabeld op het moment dat ze worden geproduceerd. Het gelabelde resultaat moet vervolgens als bevestiging terugkeren naar het ERP. Een project dat gegevens alleen naar boven verplaatst, zal altijd een getal opleveren waarover gediscussieerd moet worden.
Het sluiten van die cirkel wordt op drie manieren geprobeerd, en elke manier schiet op een andere manier tekort. Een machinebewakingsplatform visualiseert OEE goed en hanteert over het algemeen zijn eigen definities in plaats van die van het ERP. Een MES bevindt zich op de juiste plek tussen de werkvloer en de bedrijfssystemen en is een aanzienlijke implementatie, wat de reden is dat veel fabrieken dit uitstellen. Handmatige invoer in het ERP aan het einde van de dienst is wat de meeste fabrieken nog steeds doen, en dat veroorzaakt precies de vertraging die afstemming onmogelijk maakt.
Hoe zorgt een integratieplatform ervoor dat werkvloergegevens op elkaar aansluiten?
Een integration platform-as-a-service (iPaaS) verbindt de machinelaag met de systemen die de definities bevatten, namelijk het ERP voor de kalender en de routing, en de kwaliteitscontrole voor de telling van goede producten. Beide richtingen lopen door dezelfde laag, zodat context de werkvloer bereikt en bevestigingen terugkeren.
Richting is wat dit meer maakt dan alleen een datastroom. Het naar de machine sturen van de actieve werkorder betekent dat de output wordt gelabeld op het moment dat deze plaatsvindt, in plaats van dat dit aan het einde van de dienst wordt gereconstrueerd. Het koppelen van machinestatussen aan de eigen uitvaltijdcategorieën van het ERP betekent dat beschikbaarheid aan beide kanten op dezelfde definitie berust. Gegevens slechts in één richting verplaatsen is wat twee verschillende getallen oplevert.
Alumio is een integratieplatform dat is gebouwd om in beide richtingen te werken, waarbij context naar beneden wordt gestuurd en bevestigingen terugkeren. Het Alumio-integratieplatform regelt dit op vier manieren.
- Context naar de werkvloer gestuurd: een event-driven data Route binnen Alumio pusht de actieve werkorder, routing en ploegenkalender naar de machinelaag, zodat output wordt gelabeld terwijl deze plaatsvindt in plaats van achteraf gereconstrueerd
- Eén definitie toegepast op beide kanten: een data Transformer koppelt machinestatussen aan dezelfde uitvaltijdcategorieën die het ERP gebruikt, zodat beschikbaarheid in beide systemen hetzelfde betekent
- Bevestigingen continu geretourneerd: een data Route voert geproduceerde en afgekeurde hoeveelheden in het ERP in tegen de juiste order zodra ze zich voordoen, wat de vertraging aan het einde van de dienst wegneemt
- Elke waarde herleidbaar naar de bron: gedetailleerde Logs leggen vast welke meting welk cijfer heeft opgeleverd, zodat een betwist getal een kwestie van opzoeken is in plaats van een vergadering
Configuratie regelt de statuskoppeling en de retourstromen, waarbij de Alumio Code Transformer ontwikkelaars in staat stelt om te coderen waar zij de voorkeur aan geven boven configuratie. Een tweede lijn komt online tegen mappings die al bestaan, en dat is wat machinegegevens die bedrijfssystemen bereiken verandert in een cijfer in plaats van een datastroom.
Wat veranderde door het afstemmen van gegevensverzameling op de werkvloer
De waarde van een verzamelprogramma wordt niet bepaald door het aantal machines dat rapporteert. Het gaat erom of de bedrijfsleider en de financieel directeur hetzelfde getal zien en dit beiden accepteren.
Drie rollen dragen elk een deel van de verantwoordelijkheid. De bedrijfsleider is verantwoordelijk voor het OEE-cijfer en het verbeterplan dat daarop is gebaseerd. De productieplanner plant op basis van cyclustijden uit de routing in plaats van tijden die in de praktijk zijn aangetoond. De financieel controller moet elke opdracht calculeren op basis van output die mogelijk aan de verkeerde order is toegewezen.
Het bereiken van één enkel cijfer verandert het doel van de data. OEE is niet langer slechts een fabrieksstatistiek voor interne vergaderingen, maar wordt een input voor kostprijsberekeningen, capaciteitsplanning en investeringsvoorstellen. Een integratieplatform dat in beide richtingen werkt, zorgt voor dat ene cijfer, omdat beide partijen het berekenen op basis van dezelfde definities. Dat is iets heel anders dan een beter dashboard.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
