Transformarea digitală în producție este o problemă de ordine, nu de tehnologie

Secvențierea este partea grea și partea pe care materialele de furnizor o sar, pentru că varianta onestă înseamnă să îi spui clientului să cumpere mai puțin anul acesta. Pagina aceasta este chiar acea ordine.

De ce se blochează proiectele de transformare digitală din producție

Patru cauze le explică pe cele mai multe. Toate patru sunt eșecuri de program, nu de produs, și exact acesta este punctul: sunt cele pe care fabrica le controlează. Software-ul chiar eșuează și pe cont propriu, iar lista aceea își are locul în achiziție: proiectarea tranzacțiilor, performanța la scară, un furnizor a cărui implicare se termină la punerea în funcțiune.

Prima este un sponsor fără un responsabil sub el. Un sponsor aprobă un buget și vine la o ședință lunară; un responsabil are timp în hală, autoritatea de a schimba un proces și un rezultat personal legat de faptul că fabrica merge sau nu altfel peste un an. A doua este un business case care presupune date ce nu există, așa că un plan de analiză a opririlor se lovește de o coloană cu text liber pe fișa de tură. A treia este un pilot care nu a fost construit niciodată ca să scaleze. A patra este cumpărarea unei platforme înainte de a ști întrebarea, așa că fabrica ajunge să dețină un sistem capabil, fără o primă utilizare.

Cum se alege primul proiect de digitalizare

Primul proiect trebuie să vină din constrângerea fabricii, nu din lista de module. În cele mai multe fabrici pierderea este lipsită de strălucire: schimbări de reglaj mai lungi decât standardul, material care nu se găsește, opriri de două minute pe care nu le raportează nimeni.

Trei întrebări filtrează rapid candidații. Apare pierderea deja în contabilitatea fabricii, ca rebut, ore suplimentare, transport expres sau penalizare de întârziere? Ar acționa cineva altfel în aceeași tură dacă ar avea răspunsul? Puteți spune în interiorul unui singur ciclu de producție dacă a funcționat? Ciclu, nu trimestru: trei luni sunt un test corect în producția repetitivă cu mix mare și nu înseamnă nimic în aerospațial sau într-o campanie farmaceutică, unde unitatea este o campanie sau o comandă.

Uneori software-ul este răspunsul greșit: dacă restricția este fizică, niciun set de date nu va face mașina mai rapidă. Ce face măsurarea este să arate unde se duce capacitatea, iar asta de obicei redirecționează cererea de investiție în loc să o confirme. Timpul de funcționare al mașinii candidate arată mai rău decât credea oricine, odată ce sunt numărate opririle scurte, și totuși cele mai multe ore pierdute nu erau ale ei: era înfometată din amonte, blocată în aval, în schimbare de reglaj sau aștepta un operator care acoperea două posturi. Mașina nu a fost niciodată constrângerea, iar banii își au locul altundeva.

Ce se măsoară înainte de start, ca să puteți dovedi schimbarea mai târziu

Capcana este de definiție. Înainte de punerea în funcțiune, disponibilitatea se ia de pe o fișă de tură pe care opririle scurte nu se scriu; după, opririle se detectează automat, deci OEE-ul măsurat scade, pentru că pierderi care au existat dintotdeauna sunt în sfârșit numărate. Dacă nimeni nu a consemnat definiția veche și cifra veche, luna a treia arată ca o regresie, iar programul își cheltuie credibilitatea apărându-se.

Așa că scrieți cifra actuală și definiția ei în întregime: baza de timp pe care o folosește procentul, de unde vine timpul de ciclu ideal, cum se clasifică opririle, dacă mentenanța planificată este exclusă și cum se tratează reprelucrarea. Primele două decid mai tot: timpul calendaristic, cel programat și cel cu personal dau aceleiași fabrici trei cifre diferite din date identice, iar timpul de ciclu ideal este cel de pe plăcuța mașinii, cel mai bun demonstrat sau un număr din fluxul tehnologic stabilit o dată și nerevizuit niciodată.

Apoi capturați faptele mai greu de redefinit și care se pot reconcilia cu financiarul: bucăți livrate, ore plătite față de ore lucrate, poziții de comandă livrate cu întârziere, note de credit și ore suplimentare. Mai greu nu înseamnă imposibil, deci înghețați definiția și sistemul-sursă pentru fiecare, alături de definiția OEE. Respectarea termenelor are nevoie de propria decizie scrisă, pentru că data luată ca referință este definiția cel mai des rediscutată din orice fabrică: termenul confirmat inițial sau ultima dată revizuită, comanda sau poziția, expedierea sau recepția.

Ce vine primul: conectivitate, date de bază, apoi analize

Conectivitatea și datele de bază stau sub tot, analizele stau deasupra și valorează cât valorează straturile acelea, iar datele de bază sunt dependența subestimată în mod constant. Un sistem de execuție nu poate lansa o operație care lipsește dintr-un flux tehnologic, iar un motor de programare nu poate secvenția fără timpi normați măsurați de cineva în deceniul acesta. Așa că, înainte de a vă angaja la o dată, numărați reperele fără flux tehnologic, timpii normați rotunzi, locațiile care există în practică dar în niciun sistem și listele de materiale duplicate.

Cealaltă interfață care se definește la început, nu la sfârșit, este integrarea cu ERP, unde dificultatea este acordul, nu codul: ce înseamnă o confirmare de fiecare parte și dacă o postează hala sau o descărcare retroactivă, cum ajung cantitățile parțiale și împărțirile de comandă, ce se întâmplă cu un storno după ce materialul s-a mișcat, unde se înregistrează rebutul față de costul standard. Fiecare răspuns este o decizie între departamente care nu au fost niciodată nevoite să se pună de acord.

Două dependențe cu termen lung apar rareori într-un roadmap tehnic. O evidență de execuție care atribuie producția, opririle și rebutul unui operator numit este, în Germania și în mare parte din Europa, un sistem capabil să monitorizeze performanța individuală, deci are nevoie de un acord cu consiliul de întreprindere, negociat înainte de punerea în funcțiune. Aprobarea durează luni, așa că se începe în anul unu, în paralel cu datele de bază. Fondul este scurt: dacă identitatea operatorului se stochează sau nu, cine o vede, cât timp și dacă raportarea este agregată prin construcție.

A doua se aplică producției reglementate. În farmaceutice, dispozitive medicale și în mare parte din alimentar, un sistem care înregistrează sau impune o decizie de calitate intră în scopul validării: plan de validare, calificare, pistă de audit, obligații de semnătură, control al modificărilor mai lent după aceea. Raportarea, captura opririlor și programarea stau în afara acestei linii; blocarea unui lot, decizia de eliberare și versiunea de model pe care o folosește un sistem de inspecție stau înăuntru. Definiți scopul înainte de a cumpăra modulul, pentru că validarea este adesea cel mai lung element din tot programul.

De ce MES vine înaintea APS, și datele de calitate înaintea predicției de calitate cu AI

Dați planificării avansate presupunerea de ieri despre unde se află lucrarea și secvența se rearanjează de mână înainte să înceapă tura, planificatorul este înapoi în foaia de calcul în câteva săptămâni, iar verdictul este că software-ul de programare a fost prost. Nu a fost prost, a fost orb.

Datele în timp real fac un program fezabil, nu rulabil, iar în decalajul acela stă cea mai mare parte a dezamăgirii legate de APS. Un program pe date perfecte este tot ignorat dacă optimizează obiectivul greșit, minimizând reglajele în timp ce fabrica este judecată după termene; dacă lipsesc constrângerile secundare, pentru că secvențele reale se decid după scule, matricea de competențe și manopera partajată; sau dacă nu este nimic înghețat, pentru că un optimizator care recalculează continuu îi dă șefului de tură un plan nou de fiecare dată când se uită. Stabiliți un orizont înghețat și lăsați optimizarea să se agite în afara lui.

Predicția de calitate are aceeași formă: un model care prognozează rebutul are nevoie de rebut înregistrat la operația unde s-a produs, cu o cauză și cu context de proces, de la mașină și sculă până la lotul de material.

Mentenanța are o distincție peste care se trece la vânzare. Detectarea anomaliilor pe semnături de vibrație sau de curent rulează fără istoric de defecțiuni, ceea ce nu este același lucru cu a rula fără date: are nevoie de săptămâni de date din stare sănătoasă care să acopere toată plaja de funcționare, altfel alarmează la fiecare schimbare de reglaj în loc de la avarie, și de senzori montați și eșantionați pentru modurile de defectare care vă interesează. Și chiar și atunci spune doar că ceva este neobișnuit, iar ca să știți care anomalii au contat aveți nevoie de istoric de comenzi de lucru cu moduri de defectare.

Nicio cameră care arată conform sau neconform pe un ecran nu a schimbat fabrica: verdictul trebuie să se lege de o comandă de fabricație, de un lot și de o versiune de model, în interiorul evidenței de execuție și de calitate, ceea ce face din inspecție o capabilitate târzie, nu un punct de intrare. Ghiduri separate acoperă programarea la capacitate finită, ce trebuie să satisfacă un program APS și unde se termină un CMMS și unde începe mentenanța predictivă.

Cine conduce programul și de ce rezistă operatorii la introducerea datelor în hală

IT-ul este partener, nu proprietar: când IT-ul deține programul, optimizează pentru integrare și securitate, le face bine, apoi se blochează la adopție, pentru că nimeni de pe linia aceea nu răspunde pentru faptul că un operator folosește sau nu ecranul. Sub responsabil stau utilizatorii-cheie, câte unul pe zonă, numiți, cu ore alocate: ei decid ce cere un ecran și în ce ordine, iar hala îi ascultă pe ei.

Obstacolul declarat în calea adopției sunt aproape întotdeauna oamenii; obstacolul real este de obicei proiectarea tranzacției. Urmăriți o confirmare în timpul unei schimbări de reglaj, cu mănuși pe mâini, cu următoarea comandă în așteptare. Dacă introducerea unui motiv de oprire nu schimbă nimic vizibil, introducerea este o taxă pe tură, plătită cât mai târziu posibil și de obicei ca un pachet de ficțiune la final. Dacă anunță mentenanța, actualizează tabla de tură sau resecvențiază comanda următoare, devine parte din muncă.

Proiectarea bună a introducerii este concretă: terminale la mașină, operare cu o mână și cu mănuși, valori implicite luate din comandă și o listă scurtă de motive pe tip de mașină, în locul unei taxonomii din care se folosesc doar câteva coduri. Când tranzacția se potrivește cu munca, instruirea este suficient de scurtă cât să se facă la mașină, în timpul unei ture. Când nu se potrivește, nicio cantitate de instruire în sala de curs nu rezolvă nimic, iar o cerere de mai multă instruire este adesea o problemă de proiectare diagnosticată greșit ca problemă de oameni.

Două lucruri lipsesc din cele mai multe planuri de instruire. Primul sunt corecțiile: confirmarea unei cantități bune este ușor de predat, în timp ce stornarea uneia greșite sau desfacerea unei confirmări înregistrate pe comanda greșită este locul unde un utilizator neinstruit face pagube reale. Al doilea este că instruirea nu este un eveniment, pentru că șefii de tură au nevoie de mai mult decât operatorii, iar noii angajați, personalul de la agenții de muncă temporară și o hală multilingvă sosesc continuu.

Extinderea unui pilot la toată fabrica: ce face un pilot copiabil

Proiectele-pilot nu reușesc să scaleze din motive proiectate chiar în ele: cea mai bună linie, mașinile vechi evitate, furnizorul pe teren zilnic, date de bază curățate manual. Un pilot construit ca să scaleze rulează pe o linie reprezentativă, include cel puțin un utilaj incomod și înregistrează orele pe linie, pentru că acel cost unitar este singura intrare onestă în planul de extindere.

Criteriile de ieșire și data deciziei de extindere se agreează înainte de începerea pilotului, iar ultima parte rulează fără furnizor. Ce contează la partea aceea este acoperirea, nu durata, pentru că proiectele-pilot rareori cad în timpul rulării obișnuite. Cad la prima închidere de perioadă, când cifrele trebuie să se reconcilieze cu ERP-ul și cineva găsește rebut înregistrat de două ori, și la prima repornire după o oprire, când gateway-urile revin, dar contoarele tamponate nu. Așa că specificați acoperirea: o închidere de perioadă cu reconcilierea ei, tot mixul de produse pe care îl rulează linia, și o oprire planificată cu repornirea de după. În majoritatea fabricilor asta înseamnă o lună sau un ciclu complet, nu două săptămâni.

Ce acoperă un buget de transformare digitală și costul de operare de după

Licența este linia negociată cel mai dur, iar liniile care decid rezultatul sunt în altă parte: integrarea cu ERP și cu mașinile; hardware, de la gateway-uri și panouri până la senzori montați ulterior; curățarea datelor de bază; instruirea și timpul de producție pe care îl consumă; și efortul intern. Efortul intern este linia cel mai des omisă: utilizatorii-cheie, responsabilul, IT-ul, tehnicienii care montează gateway-urile, producția pierdută la trecerea în producție. Dacă nimeni nu a calculat costul orelor acelea, bugetul este greșit oricât de bine ar fi fost negociată licența.

Lucrarea fizică se împarte în două categorii care se programează diferit. Trasele de cablu, porturile de switch și segmentarea între rețeaua de automatizare și cea de business sunt inginerie obișnuită cu termene lungi de livrare și pot avansa în paralel cu producția. Orice se află în interiorul unui dulap de comandă nu poate: aceea este lucrare izolată, cere blocare și etichetare și o oprire planificată, iar în majoritatea fabricilor există o interdicție permanentă de a deschide un tablou sub tensiune. Așa că adevărata constrângere a planului de conectivitate este câte ferestre de oprire mai rămân anul acesta și cât din fiecare a revendicat deja mentenanța. Conectivitatea se planifică după calendarul de mentenanță, nu după planul de software.

Apoi costul de operare, pe care niciun buget de proiect nu îl conține și pe care directorul financiar îl cere primul: costul din anul patru. Abonamentul sau suportul anual continuă, iar panourile și gateway-urile industriale se uzează mai repede decât hardware-ul de birou. Mai presus de toate, cineva din interior operează sistemul după ce pleacă furnizorul: întreținerea datelor de bază, modificările de coduri de motiv și de fluxuri tehnologice, administrarea utilizatorilor, preluarea fiecărei versiuni. Prevedeți buget separat pentru modificări în cele douăsprezece luni de după punerea în funcțiune, pentru că cererile care merită finanțate apar abia după ce hala crede ce îi spune sistemul.

Cum se eșalonează un roadmap de smart factory pe trei ani

Un calendar adaugă ce nu poate adăuga ordinea dependențelor: cine decide la fiecare graniță și cum se eșalonează banii și orele. Anul unu așază deciziile scumpe de revizuit, iar responsabilul le așază împreună cu financiarul, IT-ul și consiliul de întreprindere, nu cu echipa de proiect: definițiile KPI, structura datelor de bază, interfața cu ERP, identitatea operatorului și, într-o fabrică reglementată, scopul validării. Efortul intern atinge maximul aici față de cheltuiala cu licența, deci un buget croit ca un proiect IT clasic este deja greșit. Un element își are locul în anul unu și este amânat de fabrici: contorizarea celor mai mari consumatori electrici pentru a stabili o valoare de referință, ceea ce este instrumentare, nu modelare, și de multe ori nu este opțional sub un standard de energie sau un audit.

Granița spre anul doi este o judecată, nu o dată, și se trece atunci când hala se ceartă cu cifra sistemului în loc să o ignore. A închide o buclă înseamnă că un șef de tură sau un manager de calitate predă o decizie unei reguli, așa că scopul acela se negociază cu oamenii a căror autoritate se mută, iar cheltuiala se deplasează de la ore interne către licență și integrare. Anul trei își câștigă stratul bazat pe modele pe doi ani de evidență, iar condiția lui de graniță este proprietatea: fiecare capabilitate are nevoie de o persoană numită care deține pragul și programul de reantrenare. Energia atribuită pe piesă își are locul aici, pentru că atribuirea are nevoie de evidența de execuție construită în primii doi ani.

Două condiții de oprire își au locul în aprobare. Dacă hala nu are încredere în datele din anul unu, anul doi nu începe. Iar tragerea anului trei în față pentru că un consiliu de administrație a cerut o inițiativă de AI produce exact proiectul blocat descris la începutul acestei pagini.

Cum știți dacă merită continuat: criterii de trecere pentru fiecare etapă

Fiecare etapă are nevoie de o poartă cu dovezi pe care le-ați putea arăta unui sceptic. După conectivitate, se potrivește producția captată cu o numărare manuală pe o tură întreagă, într-o toleranță agreată înainte de test. După prima cifră raportată, se mai întreține vechea foaie de calcul în paralel cu ea; când se oprește discret din a mai fi actualizată, cifra a fost acceptată.

O poartă își are locul la prima punere în funcțiune a execuției și este aproape întotdeauna sărită: ce face linia când sistemul nu este acolo. Odată ce operatorii confirmă la mașină și calitatea blochează loturi după reguli, un switch sau o interfață căzută oprește producția: fabrica a schimbat hârtia de pe planșetă cu un punct unic de defectare. Așa că definiți și testați mai întâi modul degradat: ce tamponează terminalul local și cât timp, care este varianta pe hârtie, cine poate autoriza rularea fără sistem și cum se reintroduce restanța fără dublă contorizare. Testați-l trăgând conexiunea în timpul unei ture în lucru, pentru că un failover netestat este motivul obișnuit pentru care o punere în funcțiune devine un incident de producție.

După evidența de execuție, puteți reconstrui o comandă, inclusiv opriri, rebut și cine a rulat-o, la nivelul de identificare agreat, fără să întrebați un om. Înainte de planificare, este producția în curs corectă la începutul unei ture. Un trend contează mai mult decât orice poartă singulară: dacă fiecare linie nouă costă cât a costat cea dinainte, programul a construit instalări la comandă, nu o metodă.

Unde se încadrează Meta Smart Factory

Meta Smart Factory acoperă straturile de mai sus ca module separate, de la MES, MRP și APS, prin calitate, mentenanță, depozit și vedere artificială, până la integrarea cu ERP. Modularitatea face acea secvențiere cumpărabilă, dar prima achiziție nu este doar un modul. Este un modul pus în fața unei constrângeri numite, într-o singură zonă, plus fundația de dedesubt: conectivitatea, curățarea datelor de bază, interfața cu ERP și definițiile agreate. Fundația aceea reprezintă cea mai mare parte a efortului din primul an și nu apare pe nicio listă de prețuri, deci își are locul în aprobare ca linie proprie, nu presupusă în interiorul unei licențe.

Părțile grele supraviețuiesc oricărei alegeri de platformă. Stabilirea a ce înseamnă cifrele, curățarea datelor de bază, proiectarea unor tranzacții pe care operatorii le vor finaliza fără să fie alergați și alegerea a ce se oprește sunt muncă în comun. Dacă acolo vă aflați, o discuție despre ordinea pașilor pentru constrângerea dumneavoastră bate o demonstrație de produs.