Waar productiedoorlooptijd werkelijk oploopt
Fabrikanten meten de doorlooptijd van begin tot eind en zoeken vervolgens naar besparingen in de onderdelen waar machines bij betrokken zijn. Cyclustijden worden geoptimaliseerd, omsteltijden verkort en lay-outs herzien. Die inspanningen zijn zinvol en pakken de zichtbare helft van het probleem aan.
Een groot deel van de verstreken tijd is wachttijd, waarbij werk blijft liggen in afwachting van een beslissing, een document of een gegevensinvoer. Een onderdeel wacht op een herziene tekening. Een werkorder wacht op een stuklijst die overeenkomt met de huidige revisie. Een inkoper wacht op het bericht dat een component is gewijzigd voordat de volgende bestelling wordt geplaatst.
Wachten tussen systemen is de minst onderzochte categorie van allemaal. Het komt zelden voor in een doorlooptijd-analyse, omdat geen enkele afdeling er verantwoordelijk voor is en omdat het meer op administratie lijkt dan op productie.
Waarom duurt het zo lang voordat engineering change orders de productie bereiken?
Een engineering change order is een gecontroleerde instructie om een product te wijzigen, en de vertraging ontstaat door het aantal systemen dat actie moet ondernemen voordat er fysiek iets verandert. De goedkeuring zelf is zelden het vertragende onderdeel.
Een vrijgegeven wijziging moet het ERP bereiken zodat de productiestuklijst, standaardkosten en openstaande werkorders worden bijgewerkt. Het moet de inkoopafdeling bereiken zodat het oude onderdeel niet langer wordt besteld en de vervanger wordt ingekocht met zijn eigen doorlooptijd. Het moet de werkvloer bereiken zodat operators bouwen volgens de huidige revisie in plaats van die van vorige maand. Elk van deze systemen is afzonderlijk en heeft een eigen eigenaar.
Wanneer de overdracht handmatig verloopt, beweegt een wijziging op het tempo van degene die eraan denkt om het door te voeren. Een goedkeuring van drie dagen wordt een implementatie van drie weken, en het gat blijft onzichtbaar totdat iemand bouwt volgens een verouderde revisie.
De overdrachten die dagen toevoegen aan een wijziging
Elke overdracht tussen systemen is een plek waar een wijziging kan blijven liggen. Het patroon is consistent in de meeste operaties:
- Revisie-invoer: de engineering-stuklijst wordt opnieuw ingevoerd in het ERP als productiestuklijst, meestal handmatig en vaak dagen na de vrijgave
- Kosten- en inkoopupdate: standaardkosten en leveranciersgegevens worden afzonderlijk gewijzigd, waardoor de inkoopafdeling in de tussentijd het verkeerde onderdeel kan bestellen
- Effectiviteit van werkorders: openstaande werkorders worden één voor één beoordeeld om te bepalen welke volgens de oude revisie en welke volgens de nieuwe moeten worden gebouwd
- Documentatie voor de werkvloer: tekeningen en werkinstructies worden opnieuw uitgegeven aan de werkvloer, soms op papier, zonder bevestiging dat de vorige versie is ingetrokken
Elke stap op zich is kort. Maar in een reeks, met voor elke stap een wachtrij, vormen ze het grootste deel van de tijd tussen goedkeuring en productie.
Wat elimineert het automatiseren van de overdracht van wijzigingen nu echt?
Het elimineert de wachtrij, niet het werk. De revisie moet nog steeds worden gevalideerd, gecalculeerd en ingekocht. Wat verdwijnt, is het wachten tussen die stappen, evenals het opnieuw invoeren van gegevens, wat fouten in de hand werkt terwijl de wijziging in de wachtrij staat.
De mechanica van die overdracht, waarbij een engineering bill of materials wordt omgezet in de structuur die het ERP-systeem verwacht en de routing naar de werkvloer wordt gepusht, is wat de digitale draad tussen PLM, ERP en MES beschrijft. Het argument voor tijdwinst is eenvoudiger dan de architectuur. Wanneer een goedgekeurde wijziging automatisch wordt doorgevoerd, krimpt het interval tussen goedkeuring en de bouwbare status tot de tijd die de controles zelf in beslag nemen.
Eén afweging verdient aandacht. Het automatiseren van deze overdracht betekent dat het wijzigingsproces zelf correct moet zijn, omdat een foutieve revisie nu onmiddellijk elk systeem bereikt in plaats van te worden opgemerkt door iemand die de gegevens opnieuw intypt. De oplossing is validatie op het moment van overdracht, niet een tragere overdracht.
Hoe een integratieplatform de wijzigingscyclus verkort
Een integratieplatform bevindt zich tussen PLM, ERP en de systemen op de werkvloer en behandelt een vrijgegeven wijziging als een gebeurtenis in plaats van als een document. Wanneer PLM een revisie publiceert, pakt het platform deze op, vormt deze om naar wat elk ontvangend systeem verwacht en levert deze af in de volgorde die het proces vereist.
Op het Alumio iPaaS verloopt die logica als volgt:
- Routes: verwerken de vrijgegeven wijziging als een event-driven flow, zodat de verspreiding direct bij vrijgave start in plaats van te wachten op de volgende geplande synchronisatie
- Transformers: zetten de engineeringstructuur om naar het formaat dat het ERP-systeem accepteert, zodat de levering automatisch verloopt zonder automatisch fouten te introduceren
- Opslag: houdt de tussenliggende status vast, zodat een wijziging die bij één stap faalt, opnieuw kan worden uitgevoerd in plaats van handmatig opnieuw te moeten worden ingevoerd
- Logging en alarmering: registreren waar elke wijziging is aangekomen en wanneer, waardoor de cyclustijd een getal wordt dat het bedrijf kan meten in plaats van schatten
Omdat die verbindingen worden geconfigureerd in plaats van handmatig gebouwd voor elk systeempaar, en de Code Transformer beschikbaar is waar configuratie niet volstaat om aan een vereiste te voldoen, hoeft het werk niet opnieuw te worden gedaan bij het toevoegen van een tweede fabriek of het vervangen van een PLM-systeem. Dat is van belang voor ERP-integratie in de productie doorgaans, waarbij dezelfde stromen telkens opnieuw worden opgebouwd wanneer een systeem verandert.
Waarom het verkorten van doorlooptijden begint bij het wijzigingsproces
Programma's voor doorlooptijdverkorting beginnen meestal daar waar het werk zichtbaar is: op de werkvloer. De grootste reserve zit echter in de hiaten tussen systemen, waar een wijziging moet wachten op iemand die deze verder helpt.
Engineering Change Orders (ECO's) zijn het duidelijkste voorbeeld, omdat de vertraging volledig administratief en volledig meetbaar is. Een bedrijf dat weet hoeveel dagen er verstrijken tussen vrijgave en productie, heeft een getal waar het op kan sturen. De meeste bedrijven hebben dat getal niet, wat op zichzelf al een belangrijke bevinding is.
Het verkorten van dat interval werkt cumulatief. Snellere wijzigingscycli betekenen minder builds op basis van de verkeerde revisie, minder uitval en een bedrijf dat een product kan aanpassen zonder dat die aanpassing drie weken aan doorvoercapaciteit kost.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
