Var produktionens ledtid faktiskt ackumuleras
Tillverkare mäter ledtid från start till mål och letar sedan efter besparingar i de delar som involverar maskiner. Cykeltider optimeras, omställningar förkortas och layouter görs om. Dessa insatser är viktiga och de adresserar den synliga halvan av problemet.
En stor del av den totala tiden är kötid, där arbetet ligger och väntar på ett beslut, ett dokument eller en datainmatning. En del väntar på en reviderad ritning. En arbetsorder väntar på en stycklista som stämmer överens med den aktuella revisionen. En inköpare väntar på att få veta att en komponent har ändrats innan nästa order läggs.
Väntetid mellan system är den minst granskade kategorin av alla. Den syns sällan i en ledtidsanalys eftersom ingen avdelning äger den och eftersom den ser ut som administration snarare än produktion.
Varför tar tekniska ändringsordrar så lång tid att nå produktionen?
En teknisk ändringsorder är en kontrollerad instruktion för att ändra en produkt, och fördröjningen beror på hur många system som måste agera innan något ändras fysiskt. Själva godkännandet är sällan den långsamma delen.
En godkänd ändring måste nå ERP-systemet så att tillverkningsstycklistor, standardkostnader och öppna arbetsordrar uppdateras. Den måste nå inköpsavdelningen så att den gamla komponenten inte längre beställs och ersättningsartikeln köps in med sin egen ledtid. Den måste nå verkstadsgolvet så att operatörerna bygger enligt den aktuella revisionen istället för den som skrevs ut förra månaden. Varje del är ett separat system med en separat ägare.
När överlämningarna sker manuellt rör sig en ändring i den takt som den person som kommer ihåg att flytta den tillåter. Ett godkännande på tre dagar blir en implementering på tre veckor, och glappet förblir osynligt tills någon bygger med en utgången revision.
Överlämningarna som lägger till dagar till en ändring
Varje överföring mellan system är en plats där en ändring kan bli liggande. Mönstret är konsekvent i de flesta verksamheter:
- Revisionsinmatning: ingenjörsstycklistan skrivs in på nytt i ERP-systemet som en tillverkningsstycklista, oftast för hand och ofta dagar efter att den släppts
- Uppdatering av kostnader och inköp: standardkostnader och leverantörsregister ändras separat, vilket gör att inköpsavdelningen kan råka beställa fel del under tiden
- Arbetsorderseffektivitet: öppna arbetsordrar granskas en i taget för att avgöra vilka som ska byggas enligt den gamla revisionen och vilka som ska följa den nya
- Dokumentation för verkstadsgolvet: ritningar och arbetsinstruktioner skickas ut på nytt till verkstaden, ibland i pappersform, utan bekräftelse på att den tidigare versionen har dragits tillbaka
Varje steg är kort i sig självt. Men i sekvens, med en kö framför varje steg, utgör de huvuddelen av tiden mellan godkännande och produktion.
Vad tar automatisering av ändringshanteringen egentligen bort?
Den tar bort kön, inte arbetet. Revisionen måste fortfarande valideras, kostnadsberäknas och källan måste fastställas. Det som försvinner är väntetiden mellan dessa steg, tillsammans med den manuella inmatningen som skapar fel medan ändringen väntar.
Mekaniken i den överföringen, att konvertera en teknisk stycklista till den struktur som affärssystemet förväntar sig och skicka ut arbetsflöden till verkstaden, är vad den digitala tråden mellan PLM, ERP och MES beskriver. Tidsargumentet är enklare än arkitekturen. När en godkänd ändring rör sig av sig själv, krymper intervallet mellan godkännande och produktionsklart tillstånd till den tid som själva kontrollerna tar.
En avvägning förtjänar att nämnas. Att automatisera denna överföring innebär att själva ändringsprocessen måste vara korrekt, eftersom en felaktig revision nu når alla system omedelbart istället för att fångas upp av någon som skriver in den på nytt. Svaret är validering vid överföringstillfället, inte långsammare överföring.
Så här förkortar en integrationsplattform ändringscykeln
En integrationsplattform placeras mellan PLM, ERP och verkstadens system, och behandlar en godkänd ändring som en händelse snarare än ett dokument. När PLM publicerar en revision plockar plattformen upp den, omformar den till det format varje mottagande system förväntar sig och levererar den i den ordning processen kräver.
I Alumio iPaaS körs den logiken som:
- Rutter: hanterar den godkända ändringen som ett händelsestyrt flöde, så att spridningen startar vid godkännande istället för att vänta på nästa schemalagda synkronisering
- Transformatorer: konverterar den tekniska strukturen till det format som affärssystemet accepterar, så att leveransen sker automatiskt utan att bli automatiskt felaktig
- Lagring: håller mellanliggande tillstånd, så att en ändring som misslyckas i ett steg kan köras om istället för att matas in manuellt
- Loggning och avisering: registrerar var varje ändring hamnade och när, vilket gör cykeltiden till ett mätbart värde för verksamheten istället för en uppskattning
Eftersom dessa kopplingar konfigureras snarare än byggs för hand för varje systempar, och med Code Transformer tillgänglig där konfiguration inte räcker till, innebär tillägg av en andra fabrik eller byte av PLM-system inte att arbetet måste börja om. Det är avgörande för ERP-integration inom tillverkning generellt sett, där samma flöden tenderar att byggas om varje gång ett system ändras.
Varför minskade ledtider börjar med ändringsprocessen
Program för ledtidsförkortning börjar oftast där arbetet syns, ute på verkstadsgolvet. Den största potentialen finns dock i glappen mellan systemen, där en ändring väntar på att någon ska föra den vidare.
Tekniska ändringsordrar är det tydligaste exemplet, eftersom fördröjningen är helt administrativ och fullt mätbar. Ett företag som vet hur många dagar som passerar mellan friskläppning och produktion har en siffra att arbeta utifrån. De flesta har inte den siffran, vilket i sig är en viktig insikt.
Att förkorta det intervallet ger en kumulativ effekt. Snabbare ändringscykler innebär färre tillverkningar enligt fel version, mindre skrot och en verksamhet som kan justera en produkt utan att det kostar tre veckors genomströmning.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
