Pe scurt

Controlul modificărilor din cadrul programului ERP oferă sponsorului o imagine de ansamblu asupra valorii, costurilor, testării și efectelor lansării înainte de aprobarea unei solicitări. Odată ce programul a confirmat o solicitare ca fiind o modificare, sponsorul are patru opțiuni: acceptare, amânare, schimb sau respingere. Directorul de program ERP întocmește recomandarea într-un singur document. Sponsorul stabilește limitele de delegare și decide asupra fondurilor, a termenelor și a liniei de bază revizuite care depășesc aceste limite.

Cum cererile minore de modificare a sistemului ERP duc la extinderea neprevăzută a domeniului de aplicare

După aprobarea proiectului, încep să sosească solicitările. La prima vedere, par minore: un câmp nou pe un ecran, o modificare a pragului de aprobare, un format diferit al raportului. Fiecare dintre ele ajunge în fața comitetului de coordonare ca o necesitate, fiind descrisă ca necesitând doar câteva zile de consultanță și prezentând un risc redus.

Un program poate scăpa de sub control fără ca vreo decizie importantă să fi fost luată. Sponsorii au motive întemeiate să accepte, deoarece solicitanții le cunosc activitățile. Refuzul poate părea un obstacol atunci când aceștia avertizează că randamentul sau închiderea contabilă de la sfârșitul lunii vor avea de suferit. Acest instinct este justificat. Dificultatea constă în ceea ce poate vedea sponsorul în momentul luării deciziei.

Efectele operaționale și asupra testării în aval ale modificărilor aduse domeniului de aplicare al sistemului ERP

Sponsorul observă o funcționalitate software pe pagină. Programul are o serie de consecințe în urma sa. Să luăm o cerere ipotetică. O modificare de două zile a configurației logicii de alocare a stocurilor poate declanșa zece zile de dezvoltare de scripturi personalizate. Poate invalida treizeci de scenarii de testare a integrării end-to-end finalizate. De asemenea, poate impune renegocierea interfețelor cu terții și poate distrage atenția utilizatorilor cheie din cadrul companiei de la repetițiile critice pentru tranziție.

Aceste cifre descriu o cerere ipotetică, nu un raport pentru orice altă modificare. Atunci când domeniul de aplicare, costurile, dependențele legate de testare și calendarul de lansare sunt prezentate în rapoarte separate, nicio pagină nu reflectă efectul în ansamblu. Astfel, linia de referință se modifică fără ca cineva să fi decis acest lucru.

Provocări transfrontaliere în gestionarea cererilor de modificare în sistemele ERP

Faptul că sediul central se află la Paris, Zurich, München sau Viena ridică îngrijorări justificate. Este nevoie de standarde la nivel de grup, de o vizibilitate consolidată și de respectarea bugetului convenit cu integratorul de sisteme. De asemenea, trebuie să se explice Consiliului de Administrație orice abatere de la acest buget.

Fabrica dispune de un set diferit. O fabrică de nivel 1 din Polonia, Cehia, Ungaria sau România poate aproviziona liniile de asamblare auto din Germania sau clienții din industria aerospațială. Acești clienți stabilesc intervale de livrare secvențiale, audituri de trasabilitate și standarde de ambalare. Este posibil ca modelul global să nu includă logica codurilor de bare sau manifestele de reciclare a containerelor solicitate de un client. Fabrica are atunci nevoie de un răspuns rapid, deoarece data de tranziție este legată de intervalele de livrare ale clienților și de calendarele de producție. O greșeală poate însemna următorul interval disponibil, nu doar câteva zile lucrătoare.

Ambele poziții sunt rezonabile. Apar tensiuni atunci când procesul de comunicare dintre ele este lent. Echipele din fabrici caută atunci soluții alternative, cum ar fi o solicitare informală adresată unui consultant local. Acestea sunt semnale, nu acte de sfidare.

Pentru o cerere transfrontalieră sunt necesare trei confirmări din trei locuri diferite. Acestea aparțin unor entități și sisteme juridice diferite, iar niciuna nu poate confirma singură întreaga cerere. Secțiunea „Autorități” arată cine confirmă ce.

Integratorul răspunde la solicitările pe care le primește, iar decizia privind domeniul de aplicare îi revine clientului. Pentru aceasta este necesar ca, din partea clientului, să existe un responsabil cu autoritate explicită în ceea ce privește modificările. În lipsa acestuia, grupul poate ajunge să plătească de două ori: pentru personalizări neprevăzute în buget, apoi pentru erori de integrare după punerea în funcțiune. Dacă o nevoie locală justifică o excepție de la șablonul global este o decizie separată, luată înaintea acesteia.

Indicatori-cheie ai extinderii neprevăzute a domeniului de aplicare al proiectelor ERP

Sponsorii și comitetele de audit nu au nevoie să citească jurnalele de configurare pentru a constata că domeniul de aplicare se abate de la plan. Semnele concrete indică faptul că un program a pierdut controlul asupra schimbărilor.

• Linii de bază nesincronizate: Integratorul, biroul de program și uzina dispun de planuri generale diferite.
• Elementele restante nedocumentate: Responsabilii de fluxuri de lucru țin liste neoficiale cu îmbunătățirile aduse proiectului care nu ajung la comitetul de coordonare.
• Testarea repetată a regresiei: Testarea se reia deoarece apar noi îmbunătățiri după înghețarea versiunii software.
• Eroziunea de urgență: Ordinele de modificare emise de furnizori consumă fondurile de rezervă, în timp ce etapele cheie rămân nefinalizate.

Un singur semn poate avea o cauză obișnuită. Două semne împreună justifică o analiză a modului în care modificările sunt introduse în program.

Cadrul decizional al sponsorului pentru cererile de modificare a sistemului ERP

Gestionarea cererilor de modificare în cadrul sistemului ERP pornește de la o bază de referință stabilită. Acest cadru presupune că programul a confirmat deja elementul respectiv ca fiind o modificare, și nu ca o activitate convenită, dar nefinalizată. Dacă clientul și partenerul de implementare încă nu sunt de acord asupra naturii acestuia, trebuie stabilită mai întâi această delimitare. Sponsorul sau directorul de program, în limitele delegate, are apoi patru opțiuni. Fiecare dintre acestea necesită dovezi diferite.

Opțiunea 1: Acceptarea și finanțarea extinderilor domeniului de aplicare al sistemului ERP

Sponsorul aprobă adăugarea și o finanțează din fondul de rezervă. Dacă dependențele o impun, sponsorul prelungește, de asemenea, în scris, perioada de testare și data de tranziție. Dovezi necesare: costul estimat în scris, orele de lucru ale utilizatorilor-cheie interni, testele afectate și data la care se produce efectul. Compromisul este evident. Fondul de rezervă cheltuit acum nu va mai putea acoperi următoarea solicitare.

Opțiunea 2: Amânarea cererilor ERP pentru versiunile ulterioare lansării

Sponsorul acceptă valoarea și transferă solicitarea către o versiune ulterioară lansării. Exemplul de mai jos denumește această etapă „Faza 1.1” sau „Ziua a doua”. Trecerea la noul sistem se desfășoară conform liniei de bază stabilite. Dovezi necesare: o soluție provizorie specificată și confirmarea faptului că afacerea poate funcționa fără modificarea respectivă în ziua lansării. Compromisul constă într-o perioadă în care solicitantul găsește o soluție de ocolire a unei lacune.

Opțiunea 3: Modificarea domeniului de aplicare al sistemului ERP pentru a asigura respectarea termenelor de punere în funcțiune

Sponsorul acceptă modificarea cu o singură condiție: ca din versiunea inițială să fie eliminată o parte echivalentă din domeniul de aplicare existent, care nu este critică. Acest lucru asigură menținerea capacității de testare și respectarea datei de lansare. Dovezi necesare: dovada că elementul eliminat este într-adevăr necritic și acordul responsabilului acestuia de a-l amâna. Compromisul constă în faptul că o cerere este amânată pentru ca alta să poată fi procesată.

Opțiunea 4: Respingerea cererilor de modificare a sistemului ERP care nu sunt esențiale

Sponsorul respinge cererea deoarece valoarea acesteia nu justifică costul, întreruperea testării sau riscul operațional. O respingere reprezintă o evaluare a momentului și a consecințelor, nu a meritelor ideii. Dovezi necesare: un motiv consemnat, astfel încât solicitantul să poată reveni după lansare cu un argument mai solid. Compromisul este o funcție care implică o lacună și poate duce la pierderea încrederii în program.

Autoritatea de aprobare în cadrul procesului de control al modificărilor din sistemul ERP

Directorul programului ERP deține autoritatea delegată de control al schimbărilor. Această persoană evaluează fezabilitatea tehnică, dependențele între fluxurile de lucru și disponibilitatea resurselor, apoi formulează recomandări. De asemenea, directorul trebuie să aibă autoritatea de a suspenda adăugările informale la domeniul de aplicare și de a prezenta sponsorului opțiuni comerciale clare.

Peste limitele delegate, responsabilul de proiect deține puterea de decizie în ceea ce privește alocarea resurselor financiare și a timpului. Acestea includ capitalul, calendarul și data lansării. Poate fi vorba de directorul financiar al grupului, de directorul operațional al grupului sau de un alt membru al conducerii.

Factori declanșatori pentru escaladarea către sponsori în cazul modificărilor bugetului și calendarului ERP

Controlul modificărilor bugetare în sistemul ERP funcționează atunci când inițiatorul stabilește din timp limitele de delegare. Acestea trebuie stabilite înainte de prima cerere, nu în timpul unei dispute legate de o cerere ulterioară. Inițiatorul stabilește o limită pentru fiecare cerere și o limită cumulativă pentru cheltuieli neprevăzute. O cerere împărțită în mai multe părți pentru a rămâne sub o anumită limită se consideră o singură cerere. Aceste condiții determină trimiterea directă a cererii către inițiator.

• Solicitarea modifică data de lansare sau un alt termen-cheie stabilit.
• Cererea, împreună cu cele aprobate până în prezent, depășește limita stabilită de sponsor pentru fondurile de rezervă.
• Solicitarea modifică un criteriu de etapă-poartă sau un proiect aprobat.
• Integratorul și directorul de program au opinii diferite cu privire la impact.

Orice sumă sub pragurile stabilite rămâne în responsabilitatea directorului de program, care o înregistrează și raportează soldul pentru situații neprevăzute la fiecare ciclu de coordonare.

Roluri de aprobare transfrontalieră pentru unitățile de producție și sediile centrale ale grupului

Directorul fabricii sau directorul general confirmă că solicitarea este necesară din punct de vedere operațional. Specialiști calificați din țara în care se află fabrica confirmă respectarea cerințelor legale. Sediul central confirmă respectarea standardelor grupului și aprobă alocarea fondurilor.

Limitele clare sunt în beneficiul ambelor părți. Unitatea primește o decizie sau o solicitare de dovezi datată în cadrul primei ședințe a comitetului de coordonare care examinează solicitarea. În cazul solicitărilor impuse de client sau prevăzute de lege, inițiatorul poate stabili o procedură în afara ciclului obișnuit și poate decide frecvența acesteia. Sediul central înregistrează fiecare decizie într-un singur dosar.

Câmpuri obligatorii pentru o înregistrare privind decizia de schimbare a sistemului ERP

Registrul deciziilor privind modificările pune la dispoziția sponsorului o pagină pentru fiecare solicitare. Acesta reprezintă instrumentul de lucru pentru controlul modificărilor din cadrul sistemului ERP. CE Interim îl propune ca un instrument practic, nu ca un standard recunoscut. Acesta conține șase câmpuri.

• Descrierea cererii de modificare: ce solicită solicitantul și de ce tocmai acum.
• Valoarea pentru afaceri și justificarea operațională: procesul pe care îl protejează.
• Costul furnizorului și impactul asupra resurselor interne: comisionul extern, orele de lucru interne și soldul fondului de rezervă înainte și după.
• Analiza dependenței și a efectului programului: testele și datele pe care le afectează.
• Domeniul de aplicare modificat sau schimbat: ce rămâne în textul final, dacă este cazul.
• Decizia autorizată și scenariul de referință actualizat: persoana care a aprobat, opțiunea aleasă și planul revizuit.

Directorul de program înregistrează impactul înainte ca sponsorul să ia o decizie. Ulterior, directorul actualizează planul asociat și informează locațiile afectate și integratorul. Aprobarea lansării, contractul și criteriile de acceptare sunt decizii separate, cu dovezi proprii. Acestea rămân în responsabilitatea sponsorului sau a Consiliului, în cazul în care postul este vacant. Orice modificare a unei date stabilite de Consiliu este, de asemenea, supusă Consiliului.

Lista de verificare a sponsorului înainte de aprobarea modificărilor aduse domeniului de aplicare al sistemului ERP

Fiabilitatea unui document depinde în totalitate de cifrele pe care le conține. Un sponsor cu experiență privește cu neîncredere o cerere care conține o singură estimare, deoarece fiecare parte stabilește prețul doar pentru propria sa parte.

În primul rând, stabiliți ce anume nu este inclus în fiecare estimare: retestarea, orele de lucru ale utilizatorilor-cheie, responsabilii de interfețe și timpul necesar pentru repetiția tranziției. În al doilea rând, centralizați cifrele furnizate de integrator, de unitatea de producție și de departamentul financiar central într-un singur document, astfel încât nicio parte să nu-și evalueze singură impactul. Abia atunci puneți întrebarea decisivă: poate compania să funcționeze în ziua lansării fără această schimbare?

O etapă manuală dintr-un proces necritic poate rămâne imperfectă. La fel și un raport care așteaptă prima versiune. În schimb, lacunele în ceea ce privește facturarea, gestionarea stocurilor, livrările către clienți sau conformitatea legală nu ar trebui să existe. Singurul compromis rămas este cel legat de situațiile neprevăzute. Fiecare aprobare implică cheltuieli care nu pot acoperi următoarea solicitare, așa că sponsorul ar trebui să cunoască soldul înainte de a da acordul.

Exemple de cazuri: Evaluarea impactului modificărilor aduse domeniului de aplicare al sistemului ERP asupra datelor concrete

Acest scenariu este ipotetic. Nu este vorba despre un client CE Interim, iar cifrele sunt doar ilustrative, nu reprezintă valori de referință. Un furnizor din industria auto, cu capital austriac, implementează modelul ERP al grupului său într-o fabrică din Polonia. Într-un ciclu de coordonare, sosesc mai multe solicitări, fiecare fiind descrisă ca fiind de mică amploare.

Înainte de ședință, directorul programului ERP înregistrează fiecare cerere în registrul deciziilor privind modificările. Integratorul prezintă o evaluare scrisă a impactului asupra costurilor, testării și termenelor. Unitatea de producție și departamentul central de finanțe furnizează numărul de ore interne. Registrul oferă sponsorului o modalitate structurată de a analiza, echilibra și decide cu privire la fiecare modificare ERP propusă. Acesta împiedică acceptarea oricărei modificări a scopului fără o vizibilitate explicită asupra costurilor, testării și etapelor de livrare.

Exemplu de acceptare: Înregistrarea automată a retururilor la linia de producție

Fabrica dorește ca operatorii să nu mai introducă manual datele privind retururile de deșeuri, iar această solicitare se încadrează în criteriile de bază.

• Solicitare: Înregistrarea automată a retururilor la linia de producție.
• Beneficiu: Elimină înregistrările manuale privind retururile de deșeuri; economisește 1,5 ore de muncă administrativă pe schimb.
• Cost: 18.500 € comision pentru furnizorul extern; 45 de ore de configurare de către utilizatorii-cheie interni.
• Testare și calendar: Sunt necesare 4 zile de testare de regresie în cadrul fluxului de lucru „Assembly”; fără întârzieri pe calea critică.
• Domeniu de aplicare modificat: Nu este necesar; situația neprevăzută a fost gestionată.
• Decizie și situație inițială: Aprobat (Acceptă acum): Bugetul inițial a fost actualizat; testarea a fost finalizată în Sprintul 4.

Directorul fabricii confirmă necesitatea. Impactul este limitat: testarea se încadrează într-un flux de lucru cu capacitate disponibilă, iar calea critică rămâne neschimbată. Nu se aplică niciun criteriu de escaladare, astfel încât directorul de program aprobă modificarea în limita delegată. Decizia este comunicată sponsorului prin intermediul înregistrării. Directorul actualizează linia de bază și raportează rezerva de urgență rămasă în cadrul aceluiași ciclu de coordonare.

Exemplu de schimb de domeniu de aplicare: Tablou de bord personalizat cu indicatori-cheie de performanță (KPI) pentru conducere

Conducerea grupului dorește un tablou de bord în locul rapoartelor statice din foi de calcul, iar această cerință este justificată.

• Solicitare: Tablou de bord personalizat cu indicatori-cheie de performanță (KPI) pentru conducere.
• Valoare: Înlocuiește raportarea statică pe foi de calcul pentru echipa de conducere a grupului.
• Cost: 34.000 € pentru dezvoltarea furnizorului; 30 de ore pentru revizuirea raportării financiare centrale.
• Testare și program: Complexitate ridicată; distrage atenția arhitecților principali responsabili de raportare în timpul testării de acceptare de către utilizatori.
• Domeniu de aplicare modificat: Amânarea rapoartelor de sinteză privind centrele de cost necritice pentru ziua a doua.
• Decizie și situația inițială: Domeniul de aplicare stabilit: Aprobat pentru lansarea inițială; rapoartele sumare au fost amânate pentru faza 1.1.

Sediul central are o nevoie reală în acest sens: o vizibilitate fiabilă asupra fabricii. Costul depășește tariful furnizorului, deoarece testarea de acceptare necesită aceiași arhitecți responsabili de raportare. Amânarea rapoartelor sumare aprobate modifică un proiect aprobat, ceea ce declanșează o escaladare. Sponsorul înregistrează acordul scris al responsabilului de raport cu privire la amânare, apoi efectuează un schimb, nu o adăugare. Tabloul de bord se alătură versiunii inițiale.

Exemplu de amânare: Trasabilitatea paleților specifici fiecărui client

Un distribuitor regional are o cerință logistică neobișnuită, iar relația comercială este importantă.

• Solicitare: Trasabilitatea paleților specifici fiecărui client.
• Valoare: Răspunde unei solicitări logistice neobișnuite pentru un singur distribuitor regional.
• Cost: 26.000 € comision de vânzare; logică complexă, personalizată, în modulul de gestionare a depozitului.
• Testare și calendar: amână cu 12 zile lucrătoare aprobarea integrării sistemului de gestionare a depozitelor.
• Domeniu de aplicare modificat: Nu s-au identificat modificări de către grupul de lucru solicitant.
• Decizie și situația inițială: Amânat pentru faza 1.1: Implementat la 60 de zile după lansare; inițial s-a utilizat un jurnal manual de împachetare.

Întârzierea afectează atingerea unui obiectiv stabilit, ceea ce declanșează o escaladare, iar echipa responsabilă de cerere nu are nicio posibilitate de a renunța. Directorul fabricii confirmă că distribuitorul are nevoie de un proces operațional încă din prima zi. Un registru manual oferă această soluție. Sponsorul amână cererea, îl desemnează pe șeful depozitului ca responsabil al registrului și stabilește o dată de revizuire.

Exemplu de refuz: Facturarea automată de către furnizor prin auto-facturare

Departamentul financiar dorește o reconciliere mai rapidă a facturilor la nivelul întregii rețele de furnizori, iar avantajul este plauzibil.

• Solicitare: Facturare automată prin auto-facturare de către furnizori.
• Valoare: Accelerează procesul de reconciliere a facturilor de la furnizori la nivelul întregii rețele de furnizori din Europa.
• Costuri: lucrări de dezvoltare la inițiativa furnizorului în valoare de 52.000 €; reconfigurare semnificativă a interfeței EDI.
• Testare și program: Modifică regulile de bază privind înregistrarea operațiunilor financiare; pune în pericol perioada de tranziție pentru sistemul financiar principal.
• Domeniu de aplicare modificat: Niciuna; echipa solicitantă nu este dispusă să modifice domeniul de aplicare.
• Decizie și situația inițială: Respingere: Risc ridicat legat de program; se menține corelarea standard a comenzilor de achiziție pentru punerea în funcțiune.

Decizia se bazează pe riscul legat de respectarea termenelor, nu pe merit. Solicitarea modifică regulile financiare de bază privind înregistrările contabile, ceea ce duce la modificarea unui proiect deja aprobat și declanșează o escaladare. Echipa solicitantă nu va modifica domeniul de aplicare. Sponsorul menține corelarea standard pentru punerea în funcțiune și consemnează motivul. Autofacturarea afectează, de asemenea, regulile de facturare, care diferă de la o țară la alta. Specialiștii calificați din Polonia confirmă ce permit regulile înainte ca ideea să fie retrimisă.

Concluzii cheie din exemplele privind modificarea domeniului de aplicare al sistemului ERP

Aceeași înregistrare a generat răspunsuri diferite la solicitări aparent similare, iar niciunul dintre acestea nu a constat într-o înghețare generală. Acestea sunt tipare în acest scenariu, nu reguli. Solicitarea acceptată a avut un efect limitat, iar calea critică a fost menținută. Schimbul a funcționat deoarece capacitatea de testare era constrângerea, iar un element necritic avea un responsabil dispus să-și asume responsabilitatea. Amânarea a funcționat deoarece activitatea putea continua pe baza unei soluții alternative specificate. Refuzul a urmat unui risc ridicat legat de program, fără posibilitatea de a renunța la ceva din domeniul de aplicare.

Unitatea a primit un răspuns motivat la fiecare cerere, inclusiv la cele care nu au fost aprobate. Cererea acceptată a fost acoperită din fondul de rezervă, astfel încât următoarea cerere va beneficia de o rezervă mai mică. Grupul menține un nivel de referință pe care îl poate justifica.

Remedierea lacunelor de guvernanță în controlul modificărilor din cadrul sistemului ERP

O autoritate internă competentă poate gestiona controlul modificărilor privind domeniul de aplicare al sistemului ERP, cu limite delegate și o cale de apel către sponsor. Sponsorul, sau Consiliul de administrație în cazul în care postul respectiv este vacant, poate verifica dacă aceste condiții sunt îndeplinite, pe baza informațiilor din dosarul programului.

• Niciun director din partea clientului nu este responsabil atât de buget, cât și de planul de testare și de planul de tranziție, așa că fiecare dintre acestea este decis în cadrul unor foruri separate.
• Directorul de program nu poate suspenda adăugările informale la domeniul de aplicare, deoarece nimeni nu i-a acordat această autoritate în scris.
• Funcția de sponsor este vacantă sau sponsorul se ocupă de conducerea afacerii, astfel încât cererile rămân în așteptare mai mult decât un ciclu al comitetului de coordonare.
• Cifrele privind impactul furnizate de integrator, de uzină și de departamentul financiar continuă să difere, iar nimeni nu are competența necesară pentru a le armoniza.

În cazul în care se aplică două sau mai multe dintre aceste condiții, programul nu mai ia decizii cu privire la cererile referitoare la un singur dosar. Grupul riscă atunci să plătească de două ori sau să modifice data stabilită de Consiliu în mod implicit. În opinia CE Interim, programul prezintă atunci un risc critic pentru întreprindere și are nevoie de un lider din partea clientului, dotat cu autoritate executivă. Un termen limită nu constituie, în sine, un motiv suficient pentru numirea unui director interimar.

Rolul unui director interimar de transformare în guvernanța ERP

O Director interimar pentru transformare și programe poate deține autoritatea de modificare din partea clientului. Acest rol ia decizii în cadrul unei delegări scrise. Răspunde în fața celui care i-a acordat această autoritate: sponsorul sau Consiliul de administrație, în cazul în care postul respectiv este vacant. Nu este nici managerul de proiect al integratorului, nici un consultant care se limitează la a face recomandări.

Mandatul prevede limite de delegare, stabilite odată ce datele sunt centralizate într-un singur registru. Acesta desemnează directorul executiv interimar ca unic responsabil pentru planul referitor la clienți. De asemenea, stabilește o procedură de escaladare a problemelor și prevede transferul responsabilității către un responsabil desemnat. Directorul executiv prezintă decizionarului, în ansamblu, confirmarea necesității din partea fabricii, confirmarea juridică locală și aprobarea alocării fondurilor de la sediul central.

Partenerii interimari CE evaluează calitatea înregistrării modificării și sprijină procesul de escaladare. Aceștia oferă persoanei care a delegat autoritatea informații privind progresul la intervale convenite și supraveghează predarea responsabilității.

Definirea mandatului provizoriu pentru supravegherea executivă

În cazul în care postul de director este vacant sau nu există o împuternicire scrisă, funcția este preluată de directorul interimar pe durata mandatului. Același lucru se aplică și în cazul în care postul face parte din departamentul de integrare sau din cel IT.

În cazul în care există un director competent, dar postul de sponsor este vacant, mandatul se aplică la un nivel ierarhic superior celui al directorului. Dacă postul de sponsor este vacant, Consiliul de administrație desemnează persoana care deține competența de decizie rezervată înainte de începerea mandatului. Aceasta se referă la capitalul care depășește limitele stabilite, la calendarul de implementare și la data punerii în funcțiune. Un Interim CFO sau Interim COO le poate menține în limitele stabilite de Consiliu.

Ordinea este importantă. În primul rând, directorul executiv consolidează cifrele privind impactul furnizate de integrator, de fabrică și de departamentul financiar într-un singur registru. De asemenea, directorul executiv include în acesta și portofoliul informal de comenzi, având autoritatea de a suspenda adăugarea de noi comenzi informale. Apoi, sponsorul sau Consiliul de Administrație – în cazul în care postul respectiv este vacant – stabilește limitele de delegare pe această bază. Abia atunci directorul executiv derulează ciclul de coordonare, cu data de predare convenită la început.

Numirea nu modifică contractul de implementare, nu anulează criteriile de acceptare și nu autorizează lansarea. Aceste competențe rămân în sarcina sponsorului sau a Consiliului, în cazul în care postul respectiv este vacant. Orice modificare a unei date stabilite de Consiliu trebuie, de asemenea, să fie supusă aprobării Consiliului.

Ghid publicat privind guvernanța domeniului de aplicare al ERP

Două surse publicate susțin principiul controlului domeniului de aplicare. Ghidul Microsoft pentru Dynamics 365 descrie tabele de proiectare care a examina și a aproba proiectarea soluțiilor. Se precizează că echipele ar trebui să respecte criteriile etapelor de evaluare, fără a le omite "din cauza presiunii sau a optimismului".

Furnizorul de servicii ERP Atreus raportează o depășirea termenului de implementare a sistemului ERP pentru serviciile post-vânzare că situația s-a stabilizat. S-au replanificat domeniul de aplicare, bugetul și etapele, și s-au definit rolurile și responsabilitățile pentru departamentul de afaceri, cel IT și parteneri. Niciuna dintre surse nu descrie acest raport și nici nu identifică o singură schimbare ca fiind cauza. Atreus este un raport al furnizorului, nu un audit independent.

Întrebări frecvente despre controlul modificărilor în cadrul sistemului ERP

Ar trebui înghețate modificările aduse domeniului de aplicare al sistemului ERP în apropierea datei de punere în funcțiune?

Nu este o regulă generală. O înghețare a versiunii poate face ca afacerea să nu mai poată funcționa. O modificare care îndeplinește o cerință legală sau protejează un proces critic are argumente solide în favoarea acceptării sale. Specialiștii din țara în care se află fabrica ar trebui să confirme că cerința respectivă este reală. Îmbunătățirile neesențiale pot aștepta o versiune ulterioară.

Cine aprobă modificările în cadrul procesului de control al modificărilor din cadrul ERP?

Directorul programului ERP aprobă cererile în limitele delegate și le înregistrează. O cerere care îndeplinește un criteriu de declanșare este transmisă sponsorului executiv, care decide asupra bugetului, calendarului și datei de lansare. De asemenea, sponsorul soluționează orice neînțelegere între integrator și directorul programului cu privire la impact.

Un director executiv interimar îl înlocuiește pe directorul programului ERP?

Nu în mod implicit. Un director competent, care dispune de autoritate scrisă, își păstrează funcția. În cazul în care funcția este ocupată de un director interimar, mandatul stabilește ierarhia de raportare și limitele delegării de atribuții. De asemenea, acesta stabilește de la început o dată de predare a funcției. Deciziile privind contractul, acceptarea și lansarea rămân în competența sponsorului sau, în cazul în care postul este vacant, în competența Consiliului de administrație.

Ce se întâmplă cu data de lansare convenită atunci când se acceptă o modificare a sistemului ERP?

Sponsorul actualizează în scris parametrii de referință ai programului: calendarul general, termenele etapelor-porți, planurile de testare a integrării și bugetul. Directorul de program informează apoi fiecare locație și fiecare furnizor implicat. În cazul în care Consiliul de administrație a stabilit data inițială, sponsorul prezintă mai întâi noua dată Consiliului de administrație.

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

Controlul modificărilor din cadrul ERP protejează linia de bază atunci când fiecare cerere are propriul cost, test și efect asupra datei, toate acestea fiind incluse într-o singură decizie. O cerere aprobată fără a ține cont de aceste efecte poate duce la punerea în funcțiune înainte ca Consiliul să fi convenit asupra unei noi date. Sponsorul, sau Consiliul în cazul în care postul este vacant, verifică mai întâi condițiile de mai sus în raport cu înregistrările programului. Următorul pas constă în definirea limitelor de delegare și în evaluarea faptului dacă discrepanța se situează la nivelul programului sau al sponsorului.

Lecturi conexe:

• Închiderea unei fabrici din SUA, coordonată din Germania: directorul interimar al unității care a dus la bun sfârșit acest proiect în șase luni
• Un singur furnizor aprovizionează mai multe fabrici din Europa Centrală și de Est. Cum ar trebui repartizate materialele disponibile în cantități limitate?
• De ce stabilirea unui obiectiv privind costurile de producție nu înseamnă o reproiectare a modelului operațional

CE Interim oferă servicii transfrontaliere de conducere executivă pentru transformări critice ale afacerilor. Odată ce caietul de sarcini este finalizat, un director executiv deja verificat, potrivit pentru mandat și care a semnat un acord de confidențialitate (NDA) este gata să își înceapă activitatea.

Dacă se îndeplinesc două sau mai multe dintre condițiile de mai sus, discutați cu un Partener interimar CE despre mandat.