Vad datainsamling från verkstadsgolvet måste stämma av
OEE ser ut som en enda procentsats. Den är sammanställd av mätvärden som flera system definierar oberoende av varandra.
- Planerad produktionstid: skiftschemat, som finns i ERP-systemet men som maskinen inte känner till
- Stillestånd och orsaken till det: maskinen registrerar att den har stannat, och endast en operatör eller ett MES-system (Manufacturing Execution System) vet om det var ett haveri, en omställning eller en rast
- Ideal cykeltid: takten som komponenten bör köras i, vanligtvis lagrad i rutten i ERP-systemet snarare än i maskinen
- Godkänt antal kontra totalt antal: maskinen räknar cykler, och kvalitetskontrollen avgör vilka av dessa som var säljbara
- Vilken order produktionen tillhör: vilken arbetsorder som kördes vid tillfället, vilket maskinen inte har någon anledning att känna till
Endast en av dessa fem punkter har sitt ursprung i maskinen. Resten kommer från affärssystemen, vilket är anledningen till att ett insamlingsprojekt som stannar vid maskinen producerar en siffra som ingen kan försvara.
Varför producerar datainsamling från verkstadsgolvet två olika OEE-siffror?
Definitionerna går isär innan något annat gör det. Om planerad produktionstid exkluderar schemalagt underhåll i ett system och inkluderar det i ett annat, kommer tillgängligheten att skilja sig med flera procentenheter utan att något av systemen har fel. Detsamma gäller om ett fem minuter långt stopp räknas som stillestånd eller som ett mikrostopp som bakas in i prestandan.
Tidpunkten gör klyftan ännu större. Maskindata strömmar in kontinuerligt, medan ERP-bokföringar sker först när någon bekräftar en produktionsorder, ofta vid arbetspassets slut. Att jämföra en realtidssiffra med en bekräftad siffra mäter i lika hög grad rapporteringsfördröjningen som själva prestationen. Det är den fördröjningen som realtidsövervakning av produktionen syftar till att lösa på arkitekturnivå.
Attribution är det tystaste av de tre problemen, men också det mest kostsamma. Produktion som registreras mot fel arbetsorder ger fortfarande en korrekt totalsumma på fabriksnivå, samtidigt som kostnaden för varje enskilt jobb blir felaktig. Det är detta som gör att siffrorna på fabriksnivå ser rimliga ut, medan kalkyleringen för enskilda jobb förblir opålitlig.
Inget av dessa tre är ett sensorproblem, vilket är anledningen till att det inte hjälper att köpa in fler sensorer.
Där en missvisande OEE-siffra kostar pengar
Instrumentpanelen går inte sönder med en smäll. Den börjar i tysthet ignoreras, och kostnaderna ackumuleras i bakgrunden.
- Möten där man bråkar om siffrorna: tid som läggs på att debattera vems siffra som är korrekt istället för vad som behöver göras åt saken
- Förbättringsarbete inriktat på fel typ av förlust: om omställningar felaktigt kategoriseras som driftstopp, läggs underhållsbudgeten på fel saker när det egentligen var ställprocessen som var problemet
- Jobbkalkylering som inte går att lita på: produktion som tillskrivs fel order förvränger marginalen för båda
- Kapacitetsplanering baserad på uppblåsta siffror: att planera utifrån en teoretisk cykeltid som ingen någonsin uppnått leder till löften som fabriken inte kan hålla
- Investeringsärenden som stannar av: ett maskinbyte som motiverats med OEE-data stannar av när ekonomiavdelningen inte kan verifiera baslinjen
Instinkten när siffrorna ser felaktiga ut är att samla in mer data.
Varför datainsamling från verkstadsgolvet måste ske i båda riktningar
Att samla in mer data från golvet innebär fler sensorer, högre granularitet och kortare intervaller. Det förbättrar upplösningen på den halva som redan fungerar, men lämnar oenigheten precis där den var.
Den andra halvan handlar om kontext. En stopphändelse blir till driftstopp med en orsak först när någon eller något klassificerar den. Ett cykelantal blir till godkänt antal först när kvaliteten har godkänt det. En produktionskvantitet blir meningsfull först när den kopplas till den arbetsorder den tillhör.
Det verkliga kravet är alltså att data flödar i båda riktningar. Arbetsorder, ruttplanering och skiftkalender måste nå verkstadsgolvet så att maskindata kan taggas i samma stund som den skapas. Det taggade resultatet måste sedan återföras till affärssystemet som en bekräftelse. Ett projekt som bara flyttar data uppåt kommer alltid att producera siffror som kräver diskussion.
Man försöker stänga den loopen på tre sätt, och varje sätt brister på olika vis. En plattform för maskinövervakning visualiserar OEE väl, men använder oftast sina egna definitioner snarare än affärssystemets. Ett MES-system placerar sig korrekt mellan verkstadsgolvet och affärssystemen, men är en omfattande implementering, vilket är anledningen till att många fabriker skjuter upp det. Manuell inmatning i affärssystemet vid skiftets slut är vad de flesta fabriker fortfarande gör, och det skapar precis den fördröjning som gör avstämning omöjlig.
Hur får en integrationsplattform data från verkstadsgolvet att stämma överens?
En integrationsplattform (iPaaS) kopplar samman maskinnivån med de system som innehåller definitionerna, det vill säga affärssystemet för kalender och ruttplanering, samt kvalitetssystemet för godkänt antal. Båda riktningarna går genom samma lager, så att kontext når golvet och bekräftelser återvänder.
Riktningen är det som gör detta till mer än bara ett dataflöde. Att skicka ner den aktiva arbetsordern till maskinen innebär att produktionen taggas i samma ögonblick som den sker, istället för att rekonstrueras vid skiftets slut. Att mappa maskintillstånd mot affärssystemets egna kategorier för driftstopp innebär att tillgängligheten vilar på samma definition på båda sidor. Att bara flytta data åt ett håll är det som skapar två olika siffror.
Alumio är en integrationsplattform byggd för att fungera i båda riktningar, genom att föra ner kontext och skicka tillbaka bekräftelser. Alumios integrationsplattform hanterar detta på fyra sätt.
- Kontext skickas ner till verkstadsgolvet: en händelsestyrd dataväg (Route) inom Alumio skickar den aktiva arbetsordern, ruttplaneringen och skiftkalendern till maskinnivån, så att produktionen taggas när den sker istället för att rekonstrueras i efterhand
- Samma definition tillämpas på båda sidor: en datatransformator mappar maskintillstånd mot samma kategorier för driftstopp som affärssystemet använder, så att tillgänglighet betyder samma sak i båda systemen
- Bekräftelser returneras kontinuerligt: en dataväg (Route) för in producerade och kasserade kvantiteter i affärssystemet mot rätt order i takt med att de sker, vilket eliminerar fördröjningen vid skiftets slut
- Varje värde kan spåras till sin källa: detaljerade loggar registrerar vilken avläsning som producerade vilken siffra, så att en ifrågasatt siffra kan kontrolleras direkt istället för att kräva ett möte
Konfiguration hanterar tillståndsmappning och returflöden, där Alumio Code Transformer gör det möjligt för utvecklare att koda där de föredrar det framför konfiguration. En andra linje tas i drift mot befintliga mappningar, vilket är det som förvandlar maskindata som når affärssystemen till en siffra snarare än ett flöde.
Vad förändras när insamling av produktionsdata stäms av
Framgången för ett insamlingsprogram mäts inte i hur många maskiner som rapporterar in. Den mäts i om fabrikschefen och ekonomichefen ser samma siffra och ingen av dem ifrågasätter den.
Tre roller sitter på varsin del av pusslet. Fabrikschefen ansvarar för OEE-talet och förbättringsplanen som bygger på det. Produktionsplaneraren lägger scheman utifrån cykeltider som anges i rutiner istället för vad linjen faktiskt har presterat. Ekonomichefen måste kalkylera varje jobb baserat på utdata som kan ha tillskrivits fel order.
Att nå fram till en gemensam siffra förändrar syftet med datan. OEE slutar vara ett fabriksnyckeltal som bara visas på fabriksmöten och blir istället ett underlag för kalkylering, kapacitetsplanering och investeringsbeslut. En integrationsplattform som arbetar i båda riktningarna är det som skapar den enhetliga siffran, eftersom båda parter till slut beräknar den utifrån samma definitioner. Det är något helt annat än en bättre instrumentpanel.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
