Advanced planning and scheduling: ce trebuie să respecte un program de producție

Presupune că vă cunoașteți procesul și că nu ați cumpărat niciodată software de programare a producției.

Restricțiile de programare pe care o linie reală trebuie să le respecte

Începeți cu restricțiile, pentru că software-ul este interesant doar în măsura în care le poate reprezenta. O mașină execută o lucrare pe rând, iar timpul necesar pentru a trece de la lucrarea curentă la următoarea depinde de obicei de care sunt cele două lucrări. De la culoare deschisă la culoare închisă este o ștergere; de la închis la deschis înseamnă purjare și curățare. Aceasta este schimbarea dependentă de secvență: timpul de setup nu este o proprietate a unei operații, ci a unei perechi de operații pe o anumită resursă, pentru că aceeași schimbare de culoare costă una pe o presă mare și alta pe una mică, iar pe unele linii depinde și de starea mașinii. Este restricția care lipsește cel mai des din sistemul de evidență, motiv pentru care un plan ieșit din ERP arată atât de des ca o listă sortată, nu ca o secvență.

Apoi restricțiile care nu țin de o singură mașină și care, pe destule linii, strâng mai tare decât matricea de schimbări. O matriță, o formă sau un stand de probă poate fi într-un singur loc la un moment dat, deci două celule care ar putea fiecare să execute comanda nu o pot executa amândouă. Un operator calificat este același tip de resursă rară: trei oameni pe schimb și unul singur certificat pentru clasa de sudură înseamnă că acea clasă are o capacitate de unu. Aerul comprimat, un cuptor sau o macara constrâng la nivel de zonă, deci două lucrări care individual încap pot să nu încapă împreună.

Disponibilitatea materialului este în același timp o precondiție dură și o dată de intrare moale. Comanda nu poate începe înainte să sosească reperul, dar data de sosire este o promisiune a unui furnizor cu propria lui fiabilitate. Programul ar trebui deci să arate care comenzi depind de o livrare care încă nu a intrat, astfel încât expunerea să fie vizibilă în plan, nu topită ca medie într-un lead time și descoperită în dimineața în care materialul nu ajunge.

Calendarele cântăresc mai mult decât se așteaptă lumea. Tiparele de schimb diferă de la o zonă la alta, nu de la o fabrică la alta: tratamentul termic merge peste noapte, montajul nu, iar o schimbare de vineri care nu poate fi terminată până la finalul schimbului va fi făcută de două ori. Ferestrele de mentenanță, sărbătorile și opririle anuale sunt perioade în care o resursă există în lista de active și nu este disponibilă pentru producție.

Și există reguli de proces care nu au nicio legătură cu capacitatea. Întărirea, uscarea, răcirea și carantina impun timpi minimi de așteptare între operații, iar adesea și timpi maximi: întărire cel puțin patru ore, acoperire în maximum douăzeci și patru, folosirea adezivului preparat în limita duratei lui de utilizare, spălarea piesei înainte să apară rugina superficială. Un motor de programare care înțelege timpii minimi de așteptare, dar nu și pe cei maximi, va produce discret planuri care rebutează material. Unele perechi de operații trebuie să fie consecutive pentru că piesa nu poate fi lăsată pe jumătate prelucrată; unele loturi trebuie construite la dimensiunea cuvei, nu la cantitatea cerută.

De ce rularea MRP produce termene pe care nu le poate respecta nimeni

MRP face ceva cu adevărat util, iar acel ceva nu este programarea producției. Descompune cererea prin listele de materiale, o compensează cu stocul și cu comenzile deschise, o decalează cu un lead time fix per articol și vă spune ce să fabricați sau să cumpărați și aproximativ când să începeți. Ca să facă asta pe mii de repere, presupune că există capacitate disponibilă oricând o cere aritmetica.

Presupunerea cade în tăcere. Două comenzi vor amândouă presa la ora zece, iar MRP le pune pe amândouă acolo. Decalajul de lead time este un număr setat o dată, o medie a timpilor de așteptare, de execuție și de transfer în condiții care nu mai sunt valabile, iar schimbările de produs fie lipsesc, fie sunt ascunse în el ca o cotă fixă care nu depinde de secvență. Rezultatul este consistent aritmetic și irealizabil fizic, ceea ce e mai rău decât să fie greșit, pentru că în sistem arată corect.

Hala de producție absoarbe diferența. Cineva resecvențiază manual, de obicei bine, folosind cunoștințe care trăiesc în unul-două capete, iar planul devine o sugestie. Tot ce derivă din el moștenește eroarea: termenele de livrare promise, momentul aprovizionării, încadrarea cu personal, cifra de capacitate comunicată vânzărilor. Când un planificator răspunde umflând lead time-urile, protecția este reală și la fel este și costul, pentru că un lead time umflat înseamnă muncă lansată devreme, care devine producție în curs staționând între stații.

Foaia de calcul care înlocuiește acele termene este o îmbunătățire reală, dar cu plafon. Funcționează pentru că planificatorul ține în cap matricea de schimbări și conflictele de SDV-uri, și cade la scară, în concediul lui și la întrebarea ce se rupe dacă acceptăm comanda asta.

Ce schimbă programarea la capacitate finită

Programarea la capacitate finită întoarce întrebarea. În loc să întrebe când ar trebui să înceapă o operație dacă nu i-ar sta nimic în cale, plasează operațiile pe resurse care au deja lucrări pe ele, respectând setup-urile, calendarele, SDV-urile și precedențele, și raportează termenele care rezultă. Termenele devin un rezultat, nu o dată de intrare.

Consecințele sunt practice. Secvența pe fiecare resursă este explicită, deci matricea de setup poate fi exploatată: acolo unde setup-ul reprezintă o parte semnificativă din capacitatea disponibilă, gruparea produselor compatibile recuperează ore de schimbare fără investiție. Dacă aceasta este situația dumneavoastră este un singur număr pe care îl puteți măsura săptămâna aceasta și merită măsurat primul, pentru că pe o linie cu schimbări de cinci minute și o problemă de material, secvențierea nu recuperează aproape nimic. Blocajele devin vizibile ca încărcări, nu ca păreri. Pentru că planul este constrâns, adăugarea unei comenzi arată ce anume deplasează, iar asta face posibilă o promisiune de livrare credibilă.

Schimbă și lansarea în fabricație. Un plan la capacitate infinită lansează lucrările cât de devreme permit decalajele; un plan finit lansează atunci când restricția le poate prelua, ceea ce trage în jos producția în curs și scurtează distanța dintre momentul în care se face un defect și cel în care este găsit. Nimic din toate astea nu e gratis: modelul trebuie întreținut și este onest doar în măsura în care sunt timpii din el.

Planificarea, programarea și dispecerizarea sunt trei lucruri diferite

Confundarea lor este cel mai frecvent motiv pentru care un proiect de programare produce ceva ce nu folosește nimeni. Planificarea lucrează în săptămâni și luni. Răspunde dacă cererea este fezabilă în agregat, dacă e nevoie de un al doilea schimb în martie, ce se angajează față de furnizori. Unitatea este o familie și o săptămână; mai multă precizie ar fi falsă, pentru că nici cererea nu este precisă.

Programarea lucrează în ore și zile. Răspunde care este secvența pe fiecare resursă pentru schimburile următoare, cu setup-urile pe care acea secvență le implică, și este exact ceea ce înseamnă APS în sensul cel mai strict.

Dispecerizarea lucrează în minute. Răspunde ce începe operatorul de la această celulă în continuare, date fiind oprirea, prima piesă respinsă, materialul care nu a ajuns. Locul ei este acolo unde se uită efectiv operatorul — un terminal MES, o listă de dispecerizare, o secvență lipită pe mașină — și ce contează este să stea aproape de muncă și să aibă voie să devieze de la program, pentru că realitatea are și ea un vot.

Modul de eșec este folosirea unui instrument la altitudinea greșită: programare la minut cu trei săptămâni în avans sau planificare de capacitate pornind de la o listă de dispecerizare. Celălalt este interzicerea devierii la nivelul dispecerizării, ceea ce face din sistem un obstacol și garantează că va fi ocolit.

De ce date are nevoie un APS: fluxuri tehnologice, timpi de ciclu, timpi de schimbare

Un motor de programare este un calcul peste datele dumneavoastră de bază. Dacă datele sunt decorative, rezultatul este decorativ și sigur pe el.

Fluxurile tehnologice trebuie să reflecte cum se fabrică piesa în realitate, inclusiv alternativele. Dacă o lucrare poate merge pe trei mașini, dar fluxul numește una singură, motorul așază lucrările în coadă acolo și raportează un blocaj pe care nu îl aveți. Dacă un flux omite o operație care se întâmplă întotdeauna — o debavurare, o inspecție, o așteptare de răcire — fiecare termen este mai scurt cu atât.

Timpii de ciclu trebuie măsurați, nu moșteniți. Timpii standard din majoritatea sistemelor ERP au fost introduși la punerea în funcțiune și reflectă o sculă și un operator care poate nu mai există. Nu aveți nevoie de timpi perfecți, doar de timpi a căror eroare este mică și nedeplasată: un traseu în care fiecare operație este optimistă cu aceeași marjă se compune într-un program greșit cu un schimb până la finalul săptămânii.

Timpii de schimbare sunt datele care lipsesc cel mai des complet și sunt cele mai valoroase. O matrice completă a fiecărei perechi de produse este rareori de întreținut. Ce funcționează este gruparea produselor în familii după ce determină efectiv setup-ul — culoare, material, sculă, temperatură, lățime — și definirea timpilor între familii, cu excepții doar acolo unde contează. Așteptați-vă să țineți acea matrice familie-la-familie pe grup de resurse, nu o dată pentru toată fabrica, pentru că aceeași tranziție costă rareori la fel pe două mașini diferite.

Producția în curs actuală este partea pe care lumea o uită. Un program pentru mâine pornește de la starea halei din seara aceasta: ce este pe jumătate prelucrat, unde se află, ce este pregătit pe fiecare mașină. Dacă acea stare este tastată la finalul schimbului de pe o fișă pe hârtie, motorul optimizează o fabrică ce exista acum câteva ore.

Datele proaste se anunță singure. O resursă este mereu saturată și tot restul stă, ceea ce înseamnă de obicei că fluxurile tehnologice o alimentează artificial. Planificatorii suprascriu aceleași comenzi în fiecare zi, ceea ce înseamnă că din model lipsește o restricție. Lucrările sunt confirmate în pachete, în același minut, ceea ce înseamnă că raportările sunt retastate mai târziu și că orele de început sunt ficțiune. Instinctul este să reglezi motorul; cauza sunt aproape întotdeauna datele de bază.

Cum se evaluează un program de producție

Livrarea la timp este rezultatul care contează, măsurată față de data dată clientului, nu față de cea internă revizuită cel mai recent, altfel cifra se va îmbunătăți fără ca experiența clientului să se schimbe.

Totalul orelor de schimbare pe săptămână este cea mai curată măsură a faptului că secvențierea chiar face treabă și se convertește direct în capacitate.

Producția în curs și timpul de trecere prin flux spun dacă planul lansează rezonabil. Un program care îmbunătățește livrarea la timp inundând hala cu lansări timpurii a mutat problema pe culoare.

Respectarea programului — cât din ce a fost planificat pentru un schimb s-a executat efectiv, în secvența planificată — este măsura onestă a faptului că planul este credibil. Un program cu indicatori teoretici excelenți, pe care hala a încetat să îl urmeze înainte de prânz, este un document.

Gradul de utilizare este capcana. Ținerea fiecărei mașini ocupată pe o non-restricție produce stoc, nu throughput, iar o linie încărcată aproape de plafon peste tot nu mai are cu ce să absoarbă variabilitatea, deci cozile cresc neliniar și lead time-urile se înrăutățesc pe măsură ce cifra de utilizare se îmbunătățește. Urmăriți-o la restricție și ignorați-o în mare măsură în rest.

Politica de reprogramare și nervozitatea programului

Un motor care poate replanifica în câteva secunde invită la replanificare permanentă. Rezistați. Dacă secvența se schimbă de fiecare dată când se mișcă ceva, hala învață că planul de la opt nu este planul de la zece și revine la a executa ce pare rezonabil. Acea instabilitate se numește nervozitate și distruge încrederea mai repede decât o face un program mediocru.

Tiparul utilizabil este un orizont înghețat plus o politică. În interiorul ferestrei, secvența nu se schimbă decât pentru blocaje reale, astfel încât setup-urile deja începute să nu fie irosite; dincolo de ea, reoptimizarea este permisă. Regula practică este să replanificați nu mai des decât lungimea ferestrei înghețate și să stabiliți acea fereastră din două lucruri pe care le puteți observa în zonă: cât durează un setup și cât de des apare un blocaj real. Un atelier de prelucrări mecanice cu lucrări de o oră și un conflict de SDV-uri în majoritatea zilelor va îngheța câteva ore și va replanifica la fiecare schimb; o fabrică de proces care rulează campanii de o săptămână va îngheța zile. Oricum ar fi, rulările programate sunt completate cu rulări declanșate de evenimente pentru o defecțiune de mașină, o livrare lipsă sau o comandă urgentă.

Două lucruri fac politica să funcționeze. Lista de excepții trebuie să fie explicită: ce se consideră motiv de rupere a înghețului și cine poate autoriza. Iar când programul chiar se schimbă, șeful de schimb trebuie să poată vedea de ce, pentru că o schimbare neexplicată se citește ca un software nefiabil.

Unde stă APS lângă ERP și MES și cine decide ce

ERP deține lumea comercială și materială și este sursa pentru ce trebuie fabricat și până când. APS deține secvența, luând cererea și materialul din ERP, restricțiile din propriul model și starea halei din execuție. MES deține execuția și evidența ei și este totodată senzorul APS-ului, fără de care motorul de programare este orb la prezent.

Bucla se închide doar dacă merge în ambele sensuri: de la APS la MES pleacă programul, de la MES la APS vine ce s-a întâmplat cu adevărat. Un fișier zilnic de raportări este suficient ca să planificați ziua de mâine și insuficient ca să replanificați în după-amiaza asta.

Responsabilitățile trebuie scrise înainte de punerea în funcțiune, pentru că disputele sunt previzibile. Cine poate schimba un termen de livrare. Cine întreține matricea de schimbări și timpii de ciclu, la ce ciclu de revizuire. Cine poate suprascrie secvența la celulă și dacă suprascrierea se înregistrează. Care sistem este de referință când ERP-ul și motorul de programare nu sunt de acord asupra stocului existent. Lăsarea acestora implicite este motivul obișnuit pentru care o implementare corectă tehnic se împotmolește.

Cum faceți o evaluare care vă spune ceva

O demonstrație a furnizorului pe datele furnizorului dovedește doar că software-ul rulează. Judecați-l pe fabrica dumneavoastră; exercițiul este ieftin dacă îi stabiliți limitele.

Alegeți o zonă cu restricții reale — setup-uri semnificative, SDV-uri partajate, comenzi care concurează — nu toată fabrica, și luați o perioadă trecută de patru până la opt săptămâni pentru care știți ce s-a executat și ce a întârziat. Dați candidatului datele de bază pe care le aveți azi, nu o versiune curățată pentru test, pentru că starea datelor dumneavoastră este unul dintre lucrurile pe care le măsurați.

Apoi cereți-i să reproducă un program pentru acea perioadă și comparați. Modelul reprezintă restricțiile dumneavoastră sau are nevoie ca cele incomode să fie simplificate până dispar. Tratează timpii maximi de așteptare la fel de bine ca pe cei minimi, dacă procesul dumneavoastră are un termen de valabilitate sau o durată de utilizare în el. Cât timp de schimbare consumă secvența lui față de cât ați cheltuit efectiv și ce spune despre comenzile pe care le-ați livrat cu întârziere. Apoi rulați scenariile care contează: blocajul oprit două zile, o comandă urgentă la mijlocul săptămânii, o livrare întârziată cu o săptămână.

Apoi așezați un planificator în fața lui pentru o după-amiază. Întrebarea nu este dacă motorul este deștept, ci dacă un om poate vedea de ce a luat o decizie și o poate ajusta fără să se lupte cu instrumentul; un motor de programare cu care nu poate nimeni să se contrazică este un motor pe care nu îl va folosi nimeni. Întrebați cât costă întreținerea modelului când se schimbă un produs, o mașină sau un timp de setup, și în câte locuri. Majoritatea programelor se degradează nu pentru că motorul a greșit, ci pentru că nimeni nu a preluat modelul după încheierea proiectului.

Unde se încadrează Meta Smart Factory

Modulele APS și MRP din Meta Smart Factory fac partea de capacitate finită din toate acestea, pe un model de restricții care acoperă schimbările dependente de secvență, SDV-urile partajate, calificarea operatorilor și calendarele de schimb pe zonă, cu rulări de scenarii pentru perturbările de mai sus. Pentru că stau în aceeași platformă ca modulul MES, nu există niciun transfer de fișiere peste noapte între execuție și motorul de programare, deci starea halei este la zi în măsura în care o fac punctele dumneavoastră de raportare și disciplina de raportare a operatorilor. Aceasta este o condiție, nu un detaliu: dacă jumătate din raportări se introduc în pauză, iar pasul de montaj manual nu are punct de scanare, arhitectura nu vă salvează. Stabilirea locului acelor puncte este muncă de implementare, nu un produs secundar al ei. Interfața cu ERP-ul pentru comenzi, liste de materiale și raportări face parte din aceeași lucrare.

Părțile care decid dacă toate acestea funcționează nu sunt ale noastre de furnizat: timpi de ciclu măsurați, o matrice de schimbări pe care o deține cineva, fluxuri tehnologice care se potrivesc cu modul real de fabricație și o politică de reprogramare scrisă. Dacă sunteți la început cu asta, primul pas util nu este o demonstrație, ci comparația istorică descrisă mai sus, pe o singură zonă cu restricții, cu datele dumneavoastră așa cum sunt.