In breve

Il controllo delle modifiche nell’ambito dell’ERP offre al committente una visione d’insieme del valore, dei costi, dei test e dell’impatto sul lancio prima di approvare una richiesta. Una volta che il programma ha confermato una richiesta come modifica, il committente ha quattro opzioni: accettare, rinviare, sostituire o rifiutare. Il direttore del programma ERP prepara la raccomandazione in un unico documento. Il committente stabilisce i limiti di delega e decide in merito a risorse finanziarie, tempistiche e linea di base rivista al di sopra di tali limiti.

In che modo le richieste di modifica minori all’ERP causano lo “scope creep”

Una volta approvato il progetto, arrivano le richieste. Sembrano di poco conto: un nuovo campo in una schermata, una soglia di approvazione modificata, un layout diverso per un report. Ognuna di esse viene presentata al comitato direttivo come una necessità, descritta come richiedente pochi giorni di consulenza e a basso rischio.

Un programma può sfuggire al controllo senza che sia stata presa una singola decisione di rilievo. Gli sponsor hanno buoni motivi per dire di sì, perché chi presenta la richiesta conosce bene le loro operazioni. Rifiutare può sembrare un ostacolo quando avvertono che la produttività o la chiusura di fine mese ne risentiranno. È un istinto giustificato. La difficoltà sta in ciò che lo sponsor è in grado di vedere al momento della decisione.

Effetti operativi e sui test a valle delle modifiche all’ambito dell’ERP

Il committente vede una funzionalità software sulla pagina. Il programma comporta una serie di conseguenze. Prendiamo in esame una richiesta ipotetica. Una modifica alla configurazione della logica di allocazione delle scorte, che richiede due giorni, può comportare dieci giorni di sviluppo di script personalizzati. Può invalidare trenta scenari di test di integrazione end-to-end già completati. Può inoltre richiedere la rinegoziazione delle interfacce con terze parti e distogliere utenti aziendali chiave dalle prove di passaggio al nuovo sistema.

Questi dati descrivono una richiesta ipotetica, non un rapporto relativo a qualsiasi altra modifica. Quando l’ambito, i costi, le dipendenze relative ai test e le tempistiche di lancio sono riportati in report separati, nessuna singola pagina mostra l’effetto complessivo. La linea di base, quindi, cambia senza che nessuno abbia deciso di modificarla.

Sfide transnazionali nella gestione delle richieste di modifica nei sistemi ERP

La presenza di sedi centrali a Parigi, Zurigo, Monaco o Vienna solleva legittime preoccupazioni. Sono necessari standard di gruppo, una visibilità consolidata e il rispetto del budget concordato con l’integratore di sistemi. È inoltre necessario spiegare eventuali scostamenti al Consiglio di Amministrazione.

Lo stabilimento utilizza un modello diverso. Uno stabilimento di primo livello in Polonia, Repubblica Ceca, Ungheria o Romania può rifornire le linee di assemblaggio automobilistiche tedesche o i clienti del settore aerospaziale. Questi clienti stabiliscono finestre di consegna sequenziali, audit di tracciabilità e standard di imballaggio. Il modello globale potrebbe non includere la logica dei codici a barre o i manifesti di riciclaggio dei contenitori richiesti da un cliente. Lo stabilimento ha quindi bisogno di una risposta rapida, poiché la sua data di transizione è legata alle finestre di consegna dei clienti e ai calendari di produzione. Un errore può comportare l’attesa della prossima finestra operativa, non solo di pochi giorni lavorativi.

Entrambe le posizioni sono ragionevoli. Le tensioni sorgono quando il percorso tra le due è lento. I team degli stabilimenti cercano quindi delle soluzioni alternative, come ad esempio una richiesta informale a un consulente locale. Si tratta di segnali, non di ribellione.

Quando si tratta di una richiesta transfrontaliera, sono necessarie tre conferme da parte di tre soggetti diversi. Questi appartengono a entità e ordinamenti giuridici diversi e nessuno di essi può confermare da solo l’intera richiesta. La sezione “Autorità” indica chi conferma cosa.

L’integratore risponde alle richieste che riceve, mentre la decisione sull’ambito di applicazione spetta al cliente. Ciò richiede la presenza, da parte del cliente, di un responsabile dotato di esplicita autorità in materia di modifiche. In assenza di tale figura, il gruppo rischia di pagare due volte: una per le personalizzazioni non previste dal budget e l’altra per i malfunzionamenti dell’integrazione dopo la messa in produzione. Se un’esigenza locale giustifichi o meno un’eccezione al modello globale è una decisione a sé stante, da prendere prima di questa.

Indicatori chiave dello "scope creep" nei progetti ERP

Gli sponsor e i comitati di revisione non hanno bisogno di leggere i registri di configurazione per rendersi conto che l’ambito sta subendo delle variazioni. Ci sono segnali concreti che indicano che un programma ha perso il controllo sul cambiamento.

• Linee di base non sincronizzate: L'integratore, l'ufficio di programma e l'impianto dispongono di programmi generali diversi.
• Voci in arretrato non documentate: I responsabili dei flussi di lavoro tengono elenchi informali delle modifiche progettuali che non vengono sottoposte al comitato direttivo.
• Test di regressione ripetuti: I test riprendono perché, dopo il congelamento del software, vengono introdotti nuovi miglioramenti.
• Erosione da contingenza: Le richieste di modifica da parte dei fornitori esauriscono il fondo di riserva, mentre le tappe fondamentali rimangono incompiute.

Un singolo segnale può avere una causa banale. Due segnali insieme giustificano una revisione delle modalità con cui le modifiche vengono inserite nel programma.

Quadro decisionale degli sponsor per le richieste di modifica dell'ERP

La governance delle richieste di modifica nell’ambito di un sistema ERP parte da una linea di riferimento ben definita. Questo quadro presuppone che il programma abbia già confermato l’elemento in questione come una modifica e non come un lavoro concordato ma non ancora completato. Se il cliente e il partner di implementazione continuano a non essere d’accordo su quale delle due ipotesi si tratti, occorre chiarire innanzitutto tale distinzione. Lo sponsor, o il direttore del programma entro i limiti delegati, ha quindi quattro opzioni a disposizione. Ciascuna richiede prove diverse.

Opzione 1: Accettare e finanziare le integrazioni all’ambito dell’ERP

Lo sponsor approva l’aggiunta e la finanzia attingendo dal fondo di riserva. Se le dipendenze lo richiedono, lo sponsor proroga inoltre per iscritto il periodo di test e la data di passaggio. Documentazione richiesta: costo scritto, ore degli utenti chiave interni, test interessati e data di decorrenza. Il compromesso è evidente: il fondo di riserva utilizzato ora non potrà coprire la richiesta successiva.

Opzione 2: rinviare le richieste relative all'ERP alle versioni successive al lancio

Lo sponsor accetta il valore e trasferisce la richiesta a una versione successiva al go-live. L’esempio riportato di seguito definisce questa fase come “Fase 1.1” o “Giorno Due”. Il passaggio procede sulla base della baseline stabilita. Documentazione richiesta: una soluzione provvisoria ben definita e la conferma che l’azienda possa operare senza la modifica il giorno del lancio. Il compromesso consiste in un periodo durante il quale il richiedente aggira una lacuna.

Opzione 3: Modificare l'ambito dell'ERP per garantire il rispetto delle date di avvio operativo

Lo sponsor accetta la modifica a una condizione: che dalla versione iniziale venga esclusa una parte equivalente dell’ambito di lavoro esistente e non critica. Ciò garantisce la capacità di test e la data di lancio. Documentazione richiesta: prova che l’elemento rimosso sia effettivamente non critico e il consenso del responsabile a rinviarlo. Il compromesso consiste nel fatto che una richiesta venga messa in attesa affinché un’altra possa procedere.

Opzione 4: Rifiutare le richieste di modifica non essenziali relative al sistema ERP

Lo sponsor respinge la richiesta perché il suo valore non giustifica il costo, l’interruzione dei test o il rischio operativo. Un rifiuto è una valutazione relativa alla tempistica e alle conseguenze, non al merito dell’idea. Elementi necessari: una motivazione documentata, in modo che il richiedente possa ripresentare la richiesta dopo il lancio con argomenti più convincenti. Il compromesso è un elemento che comporta una lacuna e può minare la fiducia nel programma.

Autorità di approvazione nel controllo delle modifiche nell'ambito dell'ERP

Il direttore del programma ERP detiene l’autorità delegata in materia di controllo delle modifiche. Tale figura valuta la fattibilità tecnica, le interdipendenze tra i flussi di lavoro e la disponibilità delle risorse, per poi formulare le proprie raccomandazioni. Il direttore deve inoltre disporre dell’autorità necessaria per sospendere le aggiunte informali all’ambito di progetto e sottoporre al committente scelte commerciali chiare.

Al di sopra dei limiti delegati, è il responsabile a prendere le decisioni che incidono sugli aspetti finanziari e temporali. Queste riguardano il capitale, la tempistica e la data di avvio operativo. Può trattarsi del CFO del gruppo, del COO del gruppo o di un altro dirigente responsabile.

Definizione dei criteri di escalation per le modifiche al budget e alla tempistica dell'ERP

Il controllo delle variazioni di budget nell’ERP funziona quando il responsabile stabilisce tempestivamente i limiti di delega. È necessario fissarli prima della prima richiesta, non nel corso di una discussione su una richiesta successiva. Il responsabile stabilisce un limite per ogni richiesta e un limite cumulativo per le spese impreviste. Una richiesta suddivisa per rimanere al di sotto di un limite conta come un’unica richiesta. Questi criteri di attivazione inviano la richiesta direttamente al responsabile.

• La richiesta comporta lo spostamento della data di entrata in funzione o di un’altra tappa fondamentale già concordata.
• La richiesta, insieme a quelle già approvate, attinge a fondi di riserva oltre il limite stabilito dal promotore.
• La richiesta comporta la modifica di un criterio di fase-gate o di un progetto approvato.
• L'integratore e il direttore del programma non sono d'accordo sull'impatto.

Tutto ciò che non raggiunge le soglie di attivazione rimane di competenza del direttore del programma, il quale lo registra e riferisce il saldo di riserva ad ogni ciclo di coordinamento.

Ruoli di approvazione transfrontaliera per gli stabilimenti e la sede centrale del Gruppo

Il direttore dello stabilimento o l’amministratore delegato conferma che la richiesta è necessaria dal punto di vista operativo. Esperti qualificati nel Paese in cui ha sede lo stabilimento verificano l’eventuale conformità ai requisiti di legge. La sede centrale conferma gli standard del gruppo e sblocca i fondi.

Limiti chiari vanno a vantaggio di entrambe le parti. Lo stabilimento riceve una decisione, oppure una richiesta di prove con data precisa, in occasione della prima riunione del comitato direttivo che esamina la richiesta. Per le richieste imposte dal cliente o previste dalla legge, il promotore può stabilire un iter fuori ciclo e decidere la sua periodicità. La sede centrale prende visione di ogni decisione in un unico documento.

Campi obbligatori per un record relativo alla decisione di cambiamento dell'ERP

Il registro delle decisioni relative alle modifiche mette a disposizione del promotore una pagina per ogni richiesta. Si tratta dello strumento operativo per il controllo delle modifiche all’ambito dell’ERP. CE Interim lo propone come ausilio pratico, non come standard riconosciuto. È composto da sei campi.

• Descrizione della richiesta di modifica: cosa chiede il richiedente e perché proprio ora.
• Valore aziendale e giustificazione operativa: il processo che tutela.
• Costo del fornitore e impatto sulle risorse interne: il compenso esterno, le ore di lavoro interne e il saldo del fondo di riserva prima e dopo.
• Verifica delle dipendenze e dell’effetto sulla pianificazione: i test e le date interessate.
• Ambito di applicazione modificato o sostituito: cosa rimane del testo originario, se rimane qualcosa.
• Decisione autorizzata e scenario di riferimento aggiornato: il responsabile dell'approvazione, l'opzione scelta e il piano rivisto.

Il direttore del programma registra l’impatto prima che lo sponsor prenda una decisione. Successivamente, il direttore aggiorna il piano collegato e ne informa le sedi interessate e l’integratore. L’approvazione del lancio, il contratto e i criteri di accettazione sono decisioni separate, con le relative prove a sostegno. Queste rimangono di competenza dello sponsor o del Consiglio di Amministrazione, qualora la carica sia vacante. Qualsiasi modifica a una data fissata dal Consiglio di Amministrazione deve essere sottoposta al Consiglio stesso.

Lista di controllo per la verifica da parte dello sponsor prima dell’approvazione delle modifiche all’ambito dell’ERP

L'affidabilità di un documento dipende esclusivamente dall'attendibilità dei dati in esso contenuti. Uno sponsor esperto diffida di una richiesta che viene presentata con una sola stima, poiché ciascuna parte stabilisce il prezzo solo della propria parte.

In primo luogo, occorre individuare ciò che ogni stima tralascia: nuovi test, ore di lavoro degli utenti chiave, responsabili delle interfacce e tempo necessario per le prove di transizione. In secondo luogo, riunite in un unico documento i dati forniti dall’integratore, dallo stabilimento e dalla direzione finanziaria centrale, in modo che nessuna delle parti possa valutare il proprio impatto. Solo allora ponete la domanda decisiva: l’azienda potrà funzionare il giorno del lancio senza questo cambiamento?

Una fase manuale in un processo non critico può rimanere imperfetta. Lo stesso vale per un rapporto in attesa della prima versione. Le lacune nella fatturazione, nella gestione delle scorte, nelle spedizioni ai clienti o nella conformità normativa non dovrebbero invece esserlo. Il compromesso rimanente riguarda le spese impreviste. Ogni approvazione comporta un esborso che non può coprire la richiesta successiva, quindi il responsabile del progetto dovrebbe conoscere il saldo prima di dare il via libera.

Esempi pratici: valutazione delle modifiche all'ambito dell'ERP sulla base dei dati effettivi

Questo scenario è ipotetico. Non si tratta di un cliente CE Interim e i dati riportati hanno scopo puramente illustrativo, non di riferimento. Un fornitore automobilistico di proprietà austriaca sta implementando il modello ERP del proprio gruppo in uno stabilimento in Polonia. Nel corso di un ciclo di coordinamento, pervengono diverse richieste, ciascuna delle quali viene definita di entità ridotta.

Prima della riunione, il direttore del programma ERP registra ogni richiesta nel registro delle decisioni relative alle modifiche. L’integratore fornisce una valutazione scritta dell’impatto su costi, test e scadenze. Lo stabilimento e la direzione finanziaria centrale comunicano le ore di lavoro interne. Il registro offre allo sponsor uno strumento strutturato per esaminare, valutare e decidere in merito a ciascuna modifica ERP proposta. Impedisce che qualsiasi modifica dell’ambito venga accettata senza una visibilità esplicita su costi, test e scadenze di consegna.

Esempio di accettazione: prenotazione automatizzata del reso in linea di produzione

Lo stabilimento desidera che gli operatori smettano di inserire manualmente i dati relativi ai resi di scarti, e la richiesta è in linea con i criteri di base.

• Richiesta: Prenotazione automatizzata dei resi in linea di produzione.
• Vantaggio: elimina la necessità di inserire manualmente i dati relativi ai scarti; consente di risparmiare 1,5 ore di lavoro amministrativo per turno.
• Costo: 18.500 € per i servizi di un fornitore esterno; 45 ore di lavoro dedicate alla configurazione da parte degli utenti chiave interni.
• Test e tempistiche: sono necessari 4 giorni di test di regressione nel flusso di lavoro Assembly; nessun ritardo sul percorso critico.
• Ambito di applicazione modificato: non richiesto; contingenza assorbita.
• Decisione e stato di riferimento: Approvato (Accetta ora): bilancio di riferimento aggiornato; test completati nello Sprint 4.

Il responsabile dello stabilimento conferma la necessità. L’impatto è contenuto: le attività di collaudo rientrano in un flusso di lavoro con capacità inutilizzata e il percorso critico rimane invariato. Non si applica alcun criterio di escalation, pertanto il direttore del programma approva la modifica entro i limiti delegati. La decisione viene comunicata allo sponsor. Il direttore aggiorna la linea di base e riferisce in merito alla riserva di contingenza residua nello stesso ciclo di coordinamento.

Esempio di Scope Exchange: dashboard personalizzata dei KPI esecutivi

I dirigenti del gruppo desiderano una dashboard al posto dei report statici in fogli di calcolo, e questa esigenza è legittima.

• Richiesta: Dashboard personalizzata dei KPI esecutivi.
• Vantaggio: sostituisce i report statici su fogli di calcolo destinati al team esecutivo del gruppo.
• Costo: 34.000 € per lo sviluppo del fornitore; 30 ore di revisione della rendicontazione finanziaria centrale.
• Test e tempistiche: elevata complessità; richiede l’impiego degli architetti principali responsabili della reportistica durante i test di accettazione da parte degli utenti.
• Ambito modificato: rinviare i report di sintesi dei centri di costo non critici al secondo giorno.
• Decisione e stato di riferimento: Ambito concordato: approvato per il rilascio iniziale; i rapporti di sintesi sono stati rinviati alla Fase 1.1.

La sede centrale ha un’esigenza concreta in questo ambito: una visibilità affidabile dell’impianto. Il costo va oltre il compenso del fornitore, poiché i test di accettazione richiedono gli stessi responsabili della reportistica. Il rinvio dei rapporti di sintesi approvati comporta una modifica al progetto approvato, il che fa scattare un’escalation. Il committente registra il consenso scritto del responsabile del rapporto al rinvio, quindi procede a uno scambio anziché a un’aggiunta. Il dashboard viene integrato nella versione iniziale.

Esempio di differimento: tracciabilità dei pallet specifica per cliente

Un distributore regionale ha un’esigenza logistica non standard, e il rapporto commerciale è importante.

• Richiesta: tracciabilità dei pallet specifica per cliente.
• Valore: Soddisfa una richiesta logistica non standard per un singolo distributore regionale.
• Costo: 26.000 € di commissione al venditore; logica personalizzata e articolata nel modulo di gestione del magazzino.
• Test e tempistiche: ritarda di 12 giorni lavorativi l’approvazione dell’integrazione con il sistema di gestione del magazzino.
• Ambito non contemplato: Nessuno individuato dal gruppo di lavoro richiedente.
• Decisione e scenario di riferimento: rinviato alla Fase 1.1: implementato 60 giorni dopo il lancio; inizialmente è stato utilizzato un registro di confezionamento manuale.

Il ritardo comporta il superamento di una tappa fondamentale già fissata, il che innesca un’escalation, e il flusso di lavoro richiedente non lascia alcun margine per rinunciare. Il direttore dello stabilimento conferma che il distributore ha bisogno di un processo operativo fin dal primo giorno. Un registro manuale ne fornisce uno. Il responsabile del progetto rinvia la richiesta, nomina il responsabile del magazzino come responsabile del registro e fissa una data per la revisione.

Esempio di rifiuto: fatturazione automatizzata con autofatturazione da parte dei fornitori

Il reparto Finanza vuole accelerare il processo di abbinamento delle fatture lungo tutta la catena di fornitura, e i vantaggi sono plausibili.

• Richiesta: Fatturazione automatizzata con auto-fatturazione da parte dei fornitori.
• Valore: Accelera il processo di abbinamento delle fatture dei fornitori nell’ambito della rete di fornitori europea.
• Costo: 52.000 € per lo sviluppo da parte del fornitore; significativa riconfigurazione dell'interfaccia EDI.
• Test e calendario: Modifica le regole fondamentali di registrazione contabile; mette a rischio la finestra temporale prevista per il passaggio al sistema contabile principale.
• Ambito spostato: Nessuna; il team richiedente non è disposto a modificare l'ambito del progetto.
• Decisione e situazione di partenza: Rifiutato: elevato rischio legato alla tempistica; per la messa in produzione si mantiene l’abbinamento standard degli ordini di acquisto.

La decisione si basa sul rischio legato alle tempistiche, non sul merito. La richiesta modifica le regole fondamentali di contabilizzazione, il che comporta una modifica al progetto già approvato e fa scattare la procedura di escalation. Il team richiedente non modificherà l’ambito di lavoro. Il committente mantiene la corrispondenza standard per la messa in produzione e ne registra il motivo. L’autofatturazione riguarda anche le regole di fatturazione, che variano da paese a paese. Gli specialisti qualificati in Polonia verificano cosa consentono le regole prima che l’idea venga riproposta.

Punti chiave da trarre dagli esempi di modifica dell'ambito dell'ERP

Lo stesso dato ha prodotto risposte diverse a richieste apparentemente simili, e nessuna di queste ha comportato un blocco totale. Si tratta di modelli ricorrenti in questo scenario, non di regole. La richiesta accolta ha avuto un effetto circoscritto e il percorso critico è stato rispettato. Lo scambio ha funzionato perché la capacità di test rappresentava il vincolo e un elemento non critico aveva un responsabile disponibile. Il rinvio ha funzionato perché l’attività poteva proseguire grazie a una soluzione alternativa ben definita. Il rifiuto è stato determinato da un elevato rischio di ritardo nella pianificazione, senza alcun margine di manovra.

L'impianto ha ricevuto una risposta motivata per ogni richiesta, comprese quelle che non sono state accolte. La richiesta accolta ha attinto alla riserva di contingenza, pertanto la richiesta successiva potrà attingere a una riserva più ridotta. Il gruppo mantiene un livello di riferimento che è in grado di giustificare.

Colmare le lacune di governance nel controllo delle modifiche all’ambito dell’ERP

Un’autorità interna competente può gestire il controllo delle modifiche all’ambito dell’ERP con limiti delegati e un percorso di riferimento verso lo sponsor. Lo sponsor, o il Consiglio di Amministrazione qualora la carica sia vacante, può verificare la conformità a tali condizioni riportate nel registro del programma.

• Nessun dirigente del cliente ha la responsabilità congiunta del budget, del piano di test e del piano di transizione, pertanto ciascuno di questi aspetti viene deciso in sedi separate.
• Il responsabile del programma non può sospendere le aggiunte informali all'ambito di applicazione, poiché nessuno gli ha concesso tale autorità per iscritto.
• Il ruolo di sponsor è vacante, oppure lo sponsor è impegnato nella gestione dell'azienda, pertanto le richieste rimangono in sospeso oltre la durata di un ciclo direttivo.
• I dati relativi all'impatto forniti dall'integratore, dall'impianto e dal reparto finanziario continuano a divergere, e nessuno ha l'autorità per appianare tali divergenze.

Qualora si verifichino due o più di queste condizioni, il programma non decide più in merito alle richieste relative a un singolo record. Il gruppo rischia quindi di pagare due volte o di modificare automaticamente la data fissata dal Consiglio. A giudizio di CE Interim, il programma comporta quindi un rischio critico per l’azienda e necessita di un responsabile dal lato del cliente dotato di autorità esecutiva. Una scadenza di per sé non è un motivo sufficiente per nominare un dirigente ad interim.

Il ruolo di un direttore ad interim della trasformazione nella governance dell'ERP

Un Direttore ad interim per la trasformazione e i programmi può detenere l'autorità di modifica dal lato del cliente. Il ruolo opera nell'ambito di una delega scritta. Risponde a chi gli ha conferito tale delega: lo sponsor o il Consiglio di Amministrazione, qualora la carica sia vacante. Non è né il project manager dell'integratore né un consulente che si limita a formulare raccomandazioni.

Il mandato prevede limiti di delega, stabiliti una volta che i dati sono stati raccolti in un unico documento. Indica il dirigente ad interim come unico responsabile del piano relativo alla parte cliente. Stabilisce un percorso di escalation e concorda il trasferimento della responsabilità a un responsabile designato. Il dirigente presenta al decisore, in un unico documento, la conferma della necessità da parte dello stabilimento, la conferma legale locale e l’autorizzazione all’erogazione dei fondi da parte della sede centrale.

I CE Interim Partners verificano la qualità del registro delle modifiche e supportano l'escalation. Forniscono a chi ha delegato l'autorità una visione dello stato di avanzamento con cadenza concordata e supervisionano il passaggio di consegne.

Definizione del mandato provvisorio per la supervisione esecutiva

Se la carica di amministratore è vacante o non è accompagnata da una delega scritta, il dirigente ad interim la ricopre per la durata del mandato. Lo stesso vale qualora tale carica ricada all’interno dell’integratore o del reparto IT.

Qualora vi sia un amministratore competente ma la lacuna si trovi a livello di sponsor, il mandato ricade al di sopra dell’amministratore. Se il posto di sponsor è vacante, il Consiglio nomina chi detiene il potere decisionale riservato prima dell’inizio del mandato. Tali decisioni riguardano il capitale eccedente i limiti, la tempistica e la data di avvio. Un Interim CFO o Interim COO può mantenerli entro i limiti stabiliti dal Consiglio.

L’ordine è importante. Innanzitutto, il dirigente riunisce in un unico registro i dati relativi all’impatto forniti dall’integratore, dallo stabilimento e dalla funzione finanziaria. Il dirigente inserisce in tale registro anche il portafoglio ordini informale, con l’autorità di sospendere nuove aggiunte informali. Successivamente, lo sponsor, o il Consiglio di Amministrazione qualora la carica sia vacante, stabilisce i limiti di delega su tale base. Solo a quel punto il dirigente avvia il ciclo di coordinamento, con la data di restituzione concordata all’inizio.

La nomina non modifica il contratto di realizzazione, non comporta la deroga ai criteri di accettazione né autorizza il lancio. Tali competenze rimangono di competenza dello sponsor o, qualora il posto sia vacante, del Consiglio. Anche qualsiasi modifica a una data fissata dal Consiglio deve essere sottoposta al Consiglio stesso.

Pubblicazione delle linee guida sulla governance dell’ambito di applicazione dell’ERP

Due fonti pubblicate sostengono il principio del controllo dell'ambito. Le linee guida di Microsoft su Dynamics 365 descrivono le schede di progettazione che esaminare e approvare progetti di soluzioni. Si afferma che i team dovrebbero rispettare i criteri delle fasi di controllo, senza saltarli "a causa della pressione o dell’ottimismo".

Il fornitore di servizi ERP Atreus riferisce che Ritardi nell'implementazione del sistema ERP per il servizio post-vendita che la situazione si è stabilizzata. Ha ridefinito l’ambito, il budget e le fasi del progetto, e ha stabilito ruoli e responsabilità per il settore aziendale, l’IT e i partner. Nessuna delle due fonti descrive questo dato né individua un singolo cambiamento come causa. Il rapporto di Atreus è un documento redatto dal fornitore, non una revisione indipendente.

Domande frequenti sul controllo delle modifiche all'ambito dell'ERP

È opportuno congelare le modifiche all'ambito dell'ERP in prossimità del go-live?

Non è una regola generale. Un blocco può rendere l'azienda incapace di operare. Una modifica che soddisfi un requisito legale o protegga un processo critico ha ottime ragioni per essere accettata. Gli specialisti del Paese in cui si trova lo stabilimento dovrebbero confermare che il requisito sia effettivo. I miglioramenti non essenziali possono attendere una versione successiva.

Chi approva le modifiche nell'ambito del controllo delle variazioni dell'ERP?

Il direttore del programma ERP approva le richieste entro i limiti delegati e le registra. Una richiesta che soddisfa i criteri di attivazione viene inoltrata allo sponsor esecutivo, il quale decide in merito al capitale, alla tempistica e alla data di avvio operativo. Lo sponsor risolve inoltre eventuali disaccordi tra l’integratore e il direttore del programma in merito all’impatto.

Un dirigente ad interim sostituisce il direttore del programma ERP?

Non di norma. Un amministratore competente, dotato di poteri scritti, mantiene la carica. Qualora la carica sia ricoperta da un dirigente ad interim, il mandato definisce la linea gerarchica e i limiti della delega. Inoltre, stabilisce fin dall’inizio una data per il passaggio di consegne. Le decisioni relative al contratto, all’accettazione e al lancio rimangono di competenza dello sponsor o, in caso di vacanza della carica, del Consiglio di Amministrazione.

Cosa succede alla data di avvio concordata quando viene accettato un cambiamento nell'ERP?

Lo sponsor ridefinisce per iscritto i parametri di riferimento del programma: calendario generale, scadenze delle fasi di controllo, piani di test di integrazione e budget. Il direttore del programma ne informa quindi tutte le sedi e i fornitori interessati. Qualora il Consiglio di Amministrazione avesse già approvato la data originaria, lo sponsor sottopone prima la nuova data al Consiglio stesso.

Conoscenze correlate e passo successivo

Il controllo delle modifiche all’ambito dell’ERP tutela la linea di base quando ogni richiesta comporta un impatto in termini di costi, test e date su una singola decisione. Una richiesta approvata senza tale valutazione può portare all’entrata in produzione prima che il Consiglio abbia concordato una nuova data. Il promotore, o il Consiglio qualora la carica sia vacante, verifica innanzitutto le condizioni di cui sopra rispetto al registro del programma. Il passo successivo consiste nel definire i limiti di delega e valutare se la discrepanza si collochi a livello di programma o di promotore.

Altre letture:

• Chiudere uno stabilimento statunitense dalla Germania: il responsabile ad interim del sito che ci è riuscito in sei mesi
• Un fornitore rifornisce diversi stabilimenti dell'Europa centrale e orientale. Come si dovrebbe ripartire il materiale disponibile in quantità limitata?
• Perché un obiettivo di costo di produzione non equivale a una riprogettazione del modello operativo

CE Interim fornisce leadership esecutiva transnazionale per trasformazioni aziendali di fondamentale importanza. Una volta completata la descrizione dell’incarico, un dirigente già sottoposto a verifica, in linea con i requisiti dell’incarico e vincolato da un accordo di riservatezza (NDA) è pronto a iniziare.

Se si verificano due o più delle condizioni sopra indicate, rivolgersi a un Partner ad interim di CE riguardo al mandato.