Planificarea și Execuția Lanțului de Aprovizionare (SCP)

APS optimizează programul de producție în interiorul fabricii; SCP extinde acest plan la furnizori, achiziții și logistica de ieșire.

Da. Portalurile pentru furnizori și integrările EDI/API mențin automat sincronizate confirmările și termenele furnizorilor.

Absolut. SCP este conceput pentru a echilibra cererea și oferta între mai multe fabrici și depozite.

Da. Indiferent de ce are în jur, SCP are nevoie de un nomenclator de articole întreținut, cu termene de livrare și reguli de comandă, de rețete și liste de materiale (BOM), de un stoc în care aveți încredere și de comenzile de aprovizionare și de producție deschise, iar acestea trebuie să vină dintr-un ERP sau dintr-un sistem echivalent care ține evidența oficială. Fără MES, avansul și consumul ajung ca raportări înregistrate la finalul turei sau al comenzii, așa că planul reacționează târziu, nu deloc.

O propunere de achiziție este aritmetică pe termenul de livrare, cantitatea minimă de comandă (MOQ), multiplul de comandă, stocul disponibil și lista de materiale. Dacă termenele de livrare ale furnizorilor sunt tot cele introduse la crearea articolului, propunerile vor fi greșite, chiar dacă arată perfect credibil. Aceste erori nu rămân ascunse: primele rulări de planificare transformă un termen sau un stoc greșit într-o dată sau o cantitate vizibil greșită. Curățarea lor înainte de go-live costă mult mai puțin decât după.

Le calculează și le propune; nu decide ce risc sunteți dispuși să vă asumați. Un stoc de siguranță rezultă din variabilitatea cererii, variabilitatea termenelor de livrare ale furnizorilor și nivelul de serviciu pe care îl alegeți, iar al treilea este o decizie comercială pe care cineva trebuie să o ia pe grupă de articole. Stabiliți-l după variabilitatea măsurată, nu după obișnuință, apoi analizați excepțiile, pentru că acolo scade efectiv stocul.

Nu de unul singur. Ce vă dă este o singură previziune, vizibilă, cu versiuni și comparată cu ce s-a vândut efectiv, iar de obicei asta se cere atunci când se pune întrebarea. Modelele statistice ajută acolo unde cererea are istoric și un tipar; nu fac nimic pentru un produs nou sau pentru o comandă câștigată printr-o licitație. Îmbunătățirea vine din faptul că cineva își asumă previziunea și analizează eroarea la fiecare ciclu.

Poate, dar stabiliți față de ce. ATP verifică stocul liber și intrările confirmate; CTP verifică în plus dacă există capacitate și componente pentru a face comanda la timp. Cu APS în funcțiune, CTP se calculează pe programul secvențiat; fără el, pe capacitatea declarată pe intervale, ceea ce e util ca direcție, dar nu prinde un conflict de secvențiere sau de schimbare de reper (setup). Promisiunile cad din cauza confirmărilor vechi de la furnizori și a capacității estimate optimist, așa că stabiliți cu vânzările ce are voie sistemul să promită singur.

Este nevoie de un responsabil nominalizat, a cărui muncă devine tratarea excepțiilor, nu refacerea fișierelor Excel. Treaba e concretă: analiza alertelor, eliberarea sau respingerea propunerilor în ciclul dumneavoastră de planificare și menținerea corectă a termenelor de livrare și a parametrilor de comandă. Efortul crește cu numărul de articole planificate și cu excepțiile generate de parametri, iar cel mai mare este în primele cicluri după go-live, cât timp se corectează acei parametri. Dacă nu și-l asumă nimeni, lista de alerte crește până când oamenii nu o mai citesc.

Nu, decât dacă vreți asta. Majoritatea fabricilor îngheață un orizont apropiat, trimit modificările din interiorul lui către planificator ca excepții și lasă sistemul să reoptimizeze dincolo de el. Unde se pune linia este o decizie de politică internă, nu una tehnică, așa că stabiliți în implementare perioada înghețată și cine are voie să o spargă. Pe planificatori îi trimite înapoi la Excel instabilitatea planului.