Pe scurt

Recuperarea în urma unei implementări eșuate a sistemului ERP într-o fabrică din Cehia reprezintă o situație de urgență operațională. Nu este o sarcină care să poată fi lăsată în seama integratorului de sisteme. Când punerea în funcțiune eșuează, înregistrarea stocurilor se oprește, iar listele de preluare se blochează. Produsele finite nu pot părăsi legal zona de expediere. Întrebarea reală a Consiliului de administrație este simplă: cine preia comanda în timp ce echipa repară baza de date? Acest ghid prezintă secvența în patru faze pentru recuperarea în urma eșecului implementării unui sistem ERP, pe care o urmează un director interimar al programului ERP. Prima fază constă într-o soluție manuală de ocolire care protejează livrările către clienți. Echipa repară apoi datele de referință și stabilizează tranzacțiile de bază, înainte de a preda din nou fabrica odată ce aceasta funcționează fără probleme.

Cauza: blocaj în depozit în primele zece zile de la trecerea la noul sistem

Implementarea unui sistem ERP industrial rareori eșuează fără să se observe. Eșecul apare de obicei în primele zece zile de la trecerea la noul sistem, nu luni mai târziu. Un comitet de coordonare din München, Viena sau Zurich a dat undă verde după luni întregi de testare. A treia zi se prezintă cu totul altfel.

Imaginați-vă o fabrică de componente situată în apropierea orașelor Plzeň, Liberec sau Pardubice. Noul sistem pierde legătura cu instalația fizică. Șoferii de stivuitoare scanează containerele pe care software-ul le indică ca fiind goale. Liniile de producție se opresc, deoarece sistemul ERP nu poate genera comenzi de reaprovizionare. Aceasta este o recuperare eșuată a implementării unui sistem ERP, în faza sa cea mai timpurie și mai concretă.

Produsele finite se acumulează pe culoarele depozitului. Departamentul de expediții nu poate genera documentele de transport sau declarațiile vamale. În termen de trei zile, activitatea de la rampa de încărcare se oprește. Linia de asamblare a unui client de nivel 1 din Germania se confruntă, la rândul său, cu o oprire a producției.

Integratorul de sisteme susține că software-ul funcționează și dă vina pe echipa locală de gestionare a schimbării. Directorul fabricii din Cehia dorește o revenire imediată la starea anterioară, o măsură care ar duce la pierderi de milioane și ar bloca procesul de contabilitate conform legii. Directorul operațional se confruntă acum cu o situație de urgență la nivelul liniei de producție, care a pornit de la un proiect software. Recuperarea după eșecul implementării sistemului ERP trebuie să înceapă imediat.

Provocări în gestionarea proiectelor transfrontaliere de recuperare a sistemelor ERP

Remedierea unei implementări ERP eșuate în cadrul unei filiale de producție din Cehia înseamnă rezolvarea simultană a trei probleme: arhitectura datelor, operațiunile locale și guvernanța corporativă. Niciuna dintre acestea nu poate fi rezolvată prin aceeași soluție. Remedierea unei implementări ERP eșuate nu se blochează doar la nivel tehnologic. Se blochează din cauza lipsei unei persoane cu autoritatea de a lua decizii atunci când sistemele nu mai funcționează conform proiectului.

Remedierea erorilor din datele de referință ale producției discrete în cadrul procesului de recuperare a sistemului ERP

Acesta este momentul în care recuperarea în urma unei implementări eșuate a unui sistem ERP fie se încheie cu succes, fie se prelungește luni întregi. Sectorul producției discrete nu tolerează prea bine datele aproximative. Cele mai multe eșecuri sunt cauzate de trei defecte structurale.

1. Rută coruptă a listei de materiale. Liniile vechi funcționau adesea pe baza unor ajustări informale, neînregistrate. Echipa a migrat listele de materiale tehnice fără a verifica duratele de traseu, marjele de deșeuri sau capacitățile ciclurilor mașinilor. Sistemul a programat apoi secvențe pe care fabrica nu le putea realiza.
2. Neconcordanța privind locația depozitului. Personalul a transferat stocul în noua bază de date fără a efectua o validare la nivel de locație de depozitare. Sistemul ERP consideră că piesele se află în culoarul patru. În realitate, acestea se află în depozitul suplimentar de alături.
3. Eșecul schimbului electronic de date. Clienții europeni aplică protocoale stricte, precum standardele VDA 4905/4913 sau Odette. Erorile de formatare din manifestele de expediere duc la respingerea automată a mărfii la rampa de descărcare a clientului.

Remedierea acestor trei deficiențe este sarcina directorului interimar al programului ERP, nu a Consiliului de administrație. Sarcina Consiliului de administrație este mai restrânsă: să acorde autoritatea de a îngheța modificările și de a realoca personalul pe durata desfășurării acestor activități. Aceste trei deficiențe reprezintă principalele domenii în care se concentrează eforturile inițiale ale procesului de redresare a unei implementări eșuate a sistemului ERP.

Gestionarea riscurilor legate de guvernanța transfrontalieră și de conformitatea cu legislația

O a doua problemă se află la nivelul superior al datelor: guvernanța transfrontalieră, unde recuperarea unei implementări ERP eșuate fie prinde avânt, fie se blochează. Sediul central al companiei tratează de obicei implementarea ca pe o actualizare IT, gestionată de la distanță de consultanți externi. La fața locului, personalul din fabrică o percepe ca pe o povară externă care îi împiedică să producă piese. Niciuna dintre aceste perspective nu este greșită. Fiecare parte vede o latură diferită a aceluiași eșec.

Norma relevantă se regăsește în Legea societăților comerciale Legea, Legea nr. 90/2012 din Colecția de legi. Împreună cu standardele locale de contabilitate fiscală, aceasta înseamnă că mărfurile nu pot părăsi sediul fără documente fiscale și de livrare conforme. Dacă software-ul nu poate genera documente valabile, conducerea nu poate expedia mărfurile în mod legal, indiferent de capacitatea fizică a spațiului de vânzare.

Gartner iar analiștii din domeniu constată că între 55% și 75% dintre proiectele ERP din sectorul producției nu își ating obiectivele. Fabricile cu producție discretă se confruntă cu cele mai mari perturbări după punerea în funcțiune. McKinsey & Company rapoarte că peste 70% dintre transformările digitale nu reușesc să genereze valoarea așteptată. Aceasta este realitatea operațională în care se desfășoară procesul de redresare a unei implementări ERP eșuate – se abordează problema direct, nu se ocolește.

Cinci indicatori operaționali care necesită o gestionare imediată a crizelor în cadrul sistemului ERP

În primele zile ale procesului de redresare în urma eșecului unei implementări ERP, problemele obișnuite apărute după lansare și o defecțiune a sistemului structural pot părea similare. Cinci semne indică momentul în care se atinge pragul de criză.

• Blocajul fizic din zona docurilor este primul. Produsele finite rămân în zona de încărcare mai mult de 24 de ore. Sistemul ERP nu va valida avizele de expediere și nu va debloca blocările de credit.
• Soldurile negative din stocuri, care sunt în creștere, reprezintă al doilea. Sistemul indică stocuri negative în conturile de produse în curs de fabricație sau de materii prime. Aceasta înseamnă că înregistrarea retroactivă nu corespunde cu consumul de pe linia de producție.
• Foile de calcul „Shadow” reprezintă a treia. Planificatorii și șefii de depozit renunță la terminalul ERP și urmăresc expedierile folosind în schimb fișe de lucru scrise de mână.
• ASN-urile lipsă ale clienților ocupă locul al patrulea. Clienții importanți formulează reclamații privind livrările, deoarece expedierile ajung fără o notificare electronică prealabilă de expediere.
• Pierderea încrederii este al cincilea. Întâlnirile zilnice dintre integrator și echipele locale de operațiuni se transformă mai degrabă în schimburi de acuzații decât în soluționarea problemelor.

Oricare dintre aceste cinci semne indică faptul că procesul de redresare a unei implementări ERP eșuate este deja în curs, nu este vorba doar de o situație obișnuită.

Cadrul de recuperare în patru etape pentru punerea în funcțiune a sistemului ERP

Pentru a pune capăt eșecului nu este nevoie de mai mulți programatori care să scrie cod personalizat. Este nevoie de un director la fața locului care să înțeleagă atât activitatea din fabrică, cât și arhitectura întreprinderii.

Un director interimar al programului ERP, sau director de redresare, conduce procesul de redresare a implementării eșuate a sistemului ERP încă din prima zi. Acest director preia comanda operațională directă. Liderul interimar pune capăt acuzelor reciproce dintre departamentul IT al companiei și conducerea fabricii locale. Pentru a rezolva criza, organizația are nevoie de un director cu experiență dovedită, potrivit pentru mandatul respectiv. Acest director trebuie să fie pregătit să își înceapă activitatea în termen de 72 de ore de la finalizarea brief-ului de mandat.

Etapa 1: Stabilirea unor proceduri alternative manuale de expediere și înghețarea codurilor

Prima săptămână are un singur obiectiv: menținerea în funcțiune a liniilor de producție ale clientului și eliberarea zonei de încărcare. Liderul interimar autorizează o procedură temporară de expediere pe suport de hârtie. Camioanele se deplasează pe baza inventarelor fizice verificate, în timp ce echipa repară software-ul. Toate personalizările IT neverificate sunt înghețate fără întârziere, astfel încât baza de date nu mai înregistrează erori noi. O ședință de triere, organizată de două ori pe zi, reunește directorul fabricii, șeful depozitului, șeful departamentului IT al companiei și integratorul principal. Aceasta prioritizează remedierea problemelor strict în funcție de impactul asupra producției. Aceasta este prima fază a recuperării după eșecul implementării sistemului ERP. Decizia proprie a directorului operațional (COO) în acest caz este limitată, dar crucială. Aprobă ocolirea manuală și înghețarea codului încă din prima zi, apoi lasă directorul interimar să conducă procesul.

Etapa 2: Curățarea datelor de referință și reconcilierea inventarului fizic

Odată ce echipa asigură expedierea, aceasta remediază discrepanța dintre baza de date și depozitul fizic. Un inventar țintit, efectuat în weekend, reconciliază cantitățile și locațiile de depozitare pentru piesele cu cel mai mare volum. Rezultatele devin noua bază de referință verificată. Echipa corectează apoi timpii de traseu eronați, multiplicatorii de deșeuri și declanșatorii de backflush. De asemenea, simplifică ierarhia depozitului, astfel încât locațiile virtuale de pregătire a comenzilor să nu mai inducă în eroare operatorii de stivuitoare. Această a doua etapă a recuperării implementării eșuate a sistemului ERP este momentul în care sistemul începe să prezinte din nou informații corecte.

Etapa 3: Stabilizarea fluxurilor de lucru „Order-to-Cash”, MRP și „Procure-to-Pay”

Directorul executiv interimar stabilizează trei fluxuri de lucru care asigură circulația numerarului și a produselor. Fluxul „de la comandă la încasare” aliniază maparea EDI cu portalurile clienților și elimină crearea manuală a facturilor. Fluxul „de la planificare la producție” restabilește planificarea automatizată a necesarului de materiale, astfel încât programele să genereze cereri de achiziție pe baza termenelor reale de livrare. Fluxul de lucru „Procure-to-pay” restabilește concordanța tripartită între comanda de achiziție, recepția mărfurilor și factura furnizorului. Acest lucru elimină restanțele la conturile de plătit și restabilește încrederea furnizorilor. Până la sfârșitul acestei faze, procesul de redresare a implementării eșuate a sistemului ERP a depășit etapa de triere. Fabrica funcționează acum cu un ciclu financiar și de planificare operațional.

Etapa 4: Recalificarea personalului, aprobarea furnizorilor și predarea operațională

Odată ce tranzacțiile sunt stabilizate, directorul interimar instruiește în limba cehă șefii de schimb, operatorii de stivuitoare și planificatorii cu privire la gestionarea standard a excepțiilor. De asemenea, directorul asigură respectarea termenelor contractuale de livrare convenite cu integratorul de sisteme. Ultima etapă constă într-o predare structurată. Supravegherea revine conducerii permanente a fabricii și departamentului IT al companiei, iar directorul interimar părăsește locația. Cazul următor ilustrează în practică recuperarea acestei implementări eșuate a sistemului ERP.

Studiu de caz: Transformarea sistemului ERP SAP S/4HANA într-o unitate de producție din Cehia

Un conglomerat global elvețiano-german din domeniul ingineriei a implementat un șablon standardizat SAP S/4HANA pentru întreprinderi în fabrica sa de turnare de precizie și prelucrare mecanică, cu 550 de angajați, situată în apropierea orașului Hradec Králové, din Republica Cehă. Fabrica furniza componente hidraulice cu toleranțe ridicate către liniile de asamblare ale echipamentelor de construcții din Europa.

La cinci zile de la punerea în funcțiune, operațiunea a pierdut controlul asupra tranzacțiilor sale de bază. Modulele de expediere din depozit nu au reușit să genereze manifeste vamale internaționale conforme și coduri de bare pentru ambalajele clienților. Produsele finite s-au acumulat în halele de producție, obligând conducerea fabricii să oprească două linii principale de prelucrare din cauza lipsei de spațiu fizic. Livrări către clienți în valoare de peste 6 milioane de euro au rămas blocate la sediu, iar doi clienți OEM importanți au amenințat cu aplicarea de penalități pentru încălcarea contractului.

Partenerul extern de implementare a propus un program de remediere cu durata de trei luni, în timp ce directorul fabricii locale din Cehia a cerut revenirea completă la sistemul vechi. Această măsură ar fi costat 4 milioane de euro și ar fi blocat procesul de consolidare digitală la nivel de grup.

Punerea în aplicare a strategiei de recuperare a sistemului ERP la fața locului în Boemia de Est

CE Interim a detașat un director interimar de program ERP cu o vastă experiență, având la activ douăzeci de ani de experiență în operațiuni de producție și în redresarea sistemelor SAP. În termen de 72 de ore de la finalizarea brief-ului mandatului, directorul interimar se afla deja la fața locului, în Hradec Králové, având autoritate operațională deplină asupra procesului de reorganizare a fabricii.

Conducerea interimară a pus în aplicare un plan imediat de redresare în situații de criză:

• S-a instituit o procedură de ocolire a dispeceratului de urgență: Au creat o procedură manuală de inventariere conformă cu normele și auditată, aprobată de autoritățile vamale locale și de echipele de logistică ale clienților. Aceasta a permis lichidarea unui stoc blocat în valoare de 2,4 milioane de euro în primele 96 de ore și a prevenit întreruperea producției la clienți. 
• EDI fix și serializarea codurilor de bare: Directorul a reconfigurat interfața de expediere din cadrul software-ului. În termen de 14 zile, au remediat problema generării etichetelor cu coduri de bare pentru ambalaje și au aliniat tranzacțiile EDI la specificațiile portalului OEM. 
• S-a efectuat încărcarea datelor din inventarul fizic țintit: Directorul a coordonat o inventariere fizică specifică, desfășurată în weekend, pentru 1.200 de coduri de produse active. Aceasta a eliminat erorile de stoc negative și a readus stocul din sistem în concordanță cu pozițiile fizice de pe rafturi. 
• S-a restabilit gradul de adoptare de către utilizatori pe această linie: Liderul interimar a înființat o echipă de sprijin la nivel de producție, formată din specialiști bilingvi în limbile cehă și germană. Aceștia au asigurat recalificarea a 60 de șefi de schimb și operatori în ceea ce privește tranzacțiile standard din sistem.

Până în ziua 50, toate procedurile manuale de expediere au fost eliminate. Unitatea a funcționat în întregime în cadrul noului sistem ERP, atingând o precizie a stocurilor de 99,11 TP3T și o rată de livrare la timp către clienți de 98,61 TP3T. Liderul interimar a supravegheat finalizarea oficială a proiectului împreună cu integratorul de sisteme și a realizat o predare structurată către conducerea permanentă a fabricii.

Întrebări frecvente despre conducerea procesului de redresare în domeniul ERP

Ce înseamnă recuperarea în urma unei implementări eșuate a unui sistem ERP?

Recuperarea în urma unei implementări eșuate a sistemului ERP restabilește operațiunile de expediere, stocuri și tranzacțiile financiare după ce punerea în funcțiune a sistemului ERP a eșuat. De obicei, procesul este condus la fața locului de un director interimar, nu de furnizorul de software. Acesta începe cu o ocolire manuală, urmată de repararea datelor de bază, înainte ca unitatea să revină complet la noul sistem.

De ce ar trebui să se evite revenirea la vechiul sistem ERP după punerea în funcțiune?

Revenirea la versiunea anterioară este rareori o simplă comutare. Trecerea la noul sistem blochează baza de date veche, iar fiecare tranzacție efectuată de la momentul punerii în funcțiune se află doar în noul sistem. Inversarea acestui proces necesită o remigrare complexă a datelor și duce la pierderea unor investiții de capital în valoare de milioane. Companiile care recurg la revenirea la versiunea anterioară pierd adesea complet accesul la software-ul enterprise de care beneficiau. O stabilizare disciplinată și rapidă este aproape întotdeauna mai rapidă și mai puțin dăunătoare decât o revenire la versiunea anterioară. O revenire la versiunea anterioară efectuată în grabă este rareori soluția potrivită în cazul recuperării după o implementare ERP eșuată.

De ce integratorii de sisteme nu pot remedia singuri defecțiunile sistemelor ERP la nivel de fabrică?

Integratorii de sisteme înțeleg tabelele bazelor de date și setările de configurare, nu operațiunile din fabrică. Un integrator nu poate semna documente de expediere, nu poate redirecționa utilajele din hală și nu poate da instrucțiuni șoferilor de stivuitoare. Rezolvarea crizei necesită un director cu autoritate operațională directă asupra fabricii. Acest director lucrează alături de integrator, nu în locul acestuia. De aceea, recuperarea unei implementări ERP eșuate necesită prezența unui director cu autoritate la fața locului.

Ce competențe trebuie să aibă un director interimar de program ERP?

Directorul executiv interimar are nevoie de autoritate care să facă legătura între conducerea locală a fabricii și departamentul IT al companiei. Aceasta include dreptul de a lua decizii cu privire la procedurile temporare de expediere, înghețarea codurilor, aprobarea furnizorilor și validarea datelor de referință. Fără această autoritate consemnată în scris încă de la început, mandatul devine pur consultativ, iar procesul de redresare se încetinește.

Cât durează, de obicei, un proces de recuperare a sistemului ERP?

Triage-ul de urgență și decongestionarea fluxurilor de date durează, de obicei, între șapte și zece zile. Stabilizarea completă a tranzacțiilor, curățarea datelor de referință și eliminarea soluțiilor manuale provizorii necesită mai mult timp. Termenul obișnuit pentru recuperarea în urma unei implementări eșuate a sistemului ERP este de șaizeci până la nouăzeci de zile de la începerea mandatului.

La ce compromisuri operaționale ar trebui să se aștepte Consiliul în prima lună?

Precizia raportării și unele soluții manuale rămân imperfecte în prima lună. Acest compromis este acceptabil. Prioritatea o reprezintă continuitatea activității clienților și vizibilitatea fluxurilor de numerar, nu un sistem perfect reconciliat încă din prima zi. Perfecțiunea poate aștepta. Operațiunile de descărcare nu pot. Acest lucru este normal în timpul recuperării după o implementare eșuată a sistemului ERP, nu un semn că aceasta a eșuat.

Cunoștințe conexe și următorul pas

Recuperarea în urma eșecului implementării unui sistem ERP reprezintă o situație de urgență operațională. Aceasta pune în pericol lichiditatea întreprinderii, încrederea clienților și credibilitatea programului mai amplu de transformare digitală al grupului. Un director cu experiență, prezent la fața locului, restabilește controlul și protejează angajamentele față de clienți.

Lecturi conexe:

• Nu mai conduceți fabrica din Franța: Cum managementul din umbră distruge responsabilitatea locală în fabricile poloneze
• Când sediul central DACH trebuie să gestioneze procesele de redresare din Polonia, Republica Cehă și România în același timp
• Când cifrele nu se potrivesc: investigarea unei fabrici din Cehia fără a provoca haos

CE Interim pune la dispoziție un partener executiv cu experiență dovedită, potrivit pentru fiecare mandat, gata să își înceapă activitatea în termen de 72 de ore de la finalizarea caietului de sarcini. A Partener interimar CE poate contribui la redresarea unei implementări eșuate a sistemului ERP, asigurând protecția programului mai amplu de transformare al grupului.