Immaginate una riunione di verifica del rilascio in cui il team di implementazione dichiara concluso il lavoro, ma un responsabile di processo non può confermare che gli utenti sappiano gestire le eccezioni e il partner non ha confermato chi supporterà l'operatività in produzione. Lo sponsor non dovrebbe considerare il completamento delle attività progettuali come un'autorizzazione ad avviare l'operatività.
Autorizzate il go-live ERP quando i responsabili aziendali possono dimostrare la preparazione operativa e il team di supporto può assumersi la responsabilità dei rischi ancora aperti. Rinviatelo quando un processo critico dipende da utenti impreparati, specialisti non disponibili o un percorso di escalation non verificato. L'approvazione condizionata può collocarsi tra queste alternative solo se le condizioni sono esplicite e se ne può esigere il rispetto.
Questa checklist di preparazione al go-live ERP riguarda l'autorizzazione a entrare in produzione. Affianca, senza sostituirle, l'approvazione del cutover tecnico, la riconciliazione dei dati e la pianificazione del ripristino. Viene inoltre dopo la decisione di migliorare o sostituire l'ERP: ora occorre stabilire se l'organizzazione sia in grado di operare con il rilascio che sta per ricevere.
Distinguere l'accettazione del responsabile di processo dal completamento delle attività
Chiedete a ogni responsabile di processo critico una dichiarazione di accettazione riferita al perimetro effettivo del rilascio. Dovrebbe indicare i flussi operativi esaminati, gli utenti coinvolti, le limitazioni ancora presenti e le eventuali procedure alternative che il responsabile è disposto a gestire. Il rapporto del project manager sul completamento dei test dovrebbe contribuire a questa dichiarazione, non sostituirla.
La distinzione riguarda la responsabilità. Un consulente funzionale può spiegare come funziona il processo configurato; spetta al responsabile aziendale decidere se la procedura operativa proposta sia accettabile. Richiedete entrambi i punti di vista quando l'operatività dipende da un passaggio di consegne tra team.
Per esempio, in un'ipotetica verifica della gestione ordini, chiedete agli utenti di dimostrare il flusso ordinario e un'eccezione che richieda un intervento. Poi chiedete chi riconosce l'eccezione, chi autorizza la risposta e chi conferma che il lavoro possa riprendere. Si tratta di una prova di accettazione operativa, non di un test completo di integrazione o riconciliazione.
Registrate il dissenso invece di trasformarlo in uno stato verde. Se un responsabile di processo non può accettare il flusso, stabilite se l'ostacolo sia una preparazione insufficiente, un difetto irrisolto o una procedura operativa inaccettabile. L'azione successiva dovrebbe affrontare quello specifico ostacolo. Un'altra dimostrazione del team di implementazione non è la risposta se ciò che manca è la prova delle capacità degli utenti.
Verificare la preparazione degli utenti, non solo la presenza ai corsi
Francesco Perrotta, professionista in ambito ERP, indica la sottovalutazione della formazione come un problema ricorrente nella propria esperienza, collegandola a un utilizzo inefficace del sistema e a una riduzione dei benefici dell'implementazione. La conseguenza pratica per l'approvazione è chiara: chiedete evidenze che gli utenti sappiano svolgere il proprio lavoro, non soltanto che la formazione sia stata erogata.
Chiedete al responsabile della formazione di associare i ruoli interessati alle attività che dovranno svolgere all'avvio. Esaminate le presenze insieme alle esercitazioni osservate, alle domande ancora aperte, alle modalità di recupero e all'accesso a istruzioni aggiornate. Includete i sostituti e gli utenti esterni al gruppo principale di progetto. Un key user preparato non dovrebbe essere considerato rappresentativo di un intero team operativo.
L'evidenza più convincente è una dimostrazione delle attività da parte delle persone che dovranno eseguirle, usando le procedure e le autorizzazioni previste per la produzione. Chiedete loro di spiegare quando si fermerebbero, richiederebbero un'approvazione o aprirebbero una richiesta di assistenza. Le slide e il registro delle presenze restano documenti utili, ma non rispondono a queste domande.
Definite i criteri di accettazione in base alle conseguenze di un errore per ciascun ruolo. Per un'attività critica, chiedete al responsabile di processo di identificare la lacuna formativa residua e le sue conseguenze operative. Se gli utenti hanno bisogno di affiancamento, assegnatelo e verificatene il risultato prima dell'approvazione. Se viene proposta una procedura alternativa, controllate che chi la eseguirà ne comprenda i limiti e che il relativo responsabile accetti il carico di lavoro aggiuntivo.
Confermare la capacità di supporto e simulare l'escalation
Perrotta avverte inoltre che alcuni partner hanno problemi di allocazione del personale perché seguono troppi progetti, lasciando i clienti senza l'interlocutore necessario quando serve assistenza. Non è un motivo per scartare un partner in base alle dimensioni. È un motivo per verificarne la disponibilità effettiva al momento dell'autorizzazione al rilascio.
Richiedete un piano di copertura del supporto con i nominativi dei referenti interni e del partner, le responsabilità, i periodi di copertura e i sostituti. Chiedete ai responsabili di funzione di confermare che gli specialisti interni abbiano tempo riservato al supporto, oltre alle normali mansioni. Chiedete al partner di identificare le persone che copriranno gli aspetti funzionali e tecnici di questo rilascio, anziché accettare una generica rassicurazione sull'esistenza di un team di assistenza.
Se la proposta iniziale lascia poco chiare queste responsabilità, riprendete le verifiche sul team e sulla disponibilità usate nella selezione del partner. Al go-live, il punto non è più la capacità complessiva del fornitore. È capire se le persone necessarie possano rispondere alle esigenze di questo specifico perimetro operativo.
Simulate un'escalation partendo da un'ipotetica interruzione dell'operatività. Chiedete a un utente di segnalare il problema, al service desk di instradarlo e agli specialisti responsabili di spiegare i passi successivi. Confermate chi valuta l'impatto aziendale, chi autorizza una procedura alternativa e chi comunica con le funzioni operative interessate. Non equiparate l'assegnazione di un ticket all'assunzione della responsabilità del ripristino dell'operatività.
Per il passaggio di consegne, chiedete al responsabile del team di supporto subentrante di accettare le procedure, gli accessi, il registro dei problemi noti e i contatti per l'escalation. Un'email che conferma l'invio della documentazione è un'evidenza più debole rispetto alla conferma che il team ricevente sappia utilizzarla. Se l'attribuzione delle responsabilità resta controversa, risolvetela prima di chiedere allo sponsor di accettare il rischio.
Riservare capacità alla stabilizzazione e agli aggiornamenti successivi
Definite la stabilizzazione come un insieme di attività con responsabili identificati, non semplicemente come un periodo nel calendario di progetto. Stabilite chi valuterà e smisterà i problemi in produzione, affiancherà gli utenti, approverà le modifiche e manterrà aggiornate le istruzioni operative. Separate le attività urgenti di ripristino dalle richieste evolutive, evitando di impegnare implicitamente le stesse persone su entrambe senza stabilire le priorità.
La responsabilità continuativa si estende anche oltre il rilascio iniziale. In una discussione della community Microsoft Dynamics, Steve Goodwin ha descritto il confronto necessario per aiutare i vertici aziendali a comprendere il processo di aggiornamento della piattaforma, la gestione delle funzionalità e le capacità disponibili per la loro organizzazione. È il racconto di un cliente riferito a un contesto specifico, non una prova di un risultato tipico dei progetti ERP.
L'indicazione utile è che la comprensione da parte della direzione dovrebbe includere ciò che accade dopo l'avvio. Chiedete chi esaminerà gli aggiornamenti pertinenti, ne valuterà l'impatto aziendale, coordinerà i test e preparerà gli utenti alle modifiche accettate. Riservate capacità a queste responsabilità, anziché presumere che la conclusione dell'implementazione elimini anche la necessità di partecipazione delle funzioni aziendali.
Concordate le evidenze necessarie per passare dal supporto intensificato di stabilizzazione alla gestione ordinaria. È utile verificare se per i problemi critici sia stata concordata una modalità di gestione, se l'attribuzione delle responsabilità di supporto funzioni e se i responsabili di processo possano gestire il carico di lavoro residuo. Scegliete criteri adeguati al rilascio; non sostituite una decisione di accettazione con il semplice trascorrere di un periodo arbitrario.
Inserire responsabili nominativi e rischi aperti nel verbale di approvazione
Usate la seguente scheda come supporto alla decisione dello sponsor. Sostituite i ruoli con nomi effettivi, collegate le evidenze e indicate l'esposizione al rischio ancora irrisolta. Non trasformate le righe in un punteggio che permetta a una grave lacuna operativa di scomparire dentro una media.
| Area decisionale | Responsabile da indicare per nome | Evidenze da esaminare | Rischio aperto da registrare |
|---|---|---|---|
| Accettazione dei processi | Responsabile del processo aziendale | Perimetro dei flussi accettati, eccezioni e procedure alternative | Attività che l'azienda non è ancora in grado di svolgere in sicurezza |
| Preparazione degli utenti | Responsabile della formazione e responsabile di funzione | Risultati delle esercitazioni per ruolo, azioni di recupero e istruzioni accessibili | Attività che gli utenti non sanno ancora svolgere o per cui non sanno attivare l'escalation |
| Disponibilità del personale | Responsabile del supporto interno e referente del partner | Piano nominativo, copertura e sostituti | Responsabilità scoperte o impegni incompatibili |
| Escalation e passaggio di consegne | Responsabile del supporto subentrante | Instradamento delle segnalazioni verificato con una simulazione e materiali di supporto accettati | Autorità di ripristino poco chiara o accessi mancanti |
| Stabilizzazione e aggiornamenti | Responsabile applicativo | Capacità riservata, priorità e criteri di passaggio alla gestione ordinaria | Attività di supporto o aggiornamento senza una risorsa responsabile |
Un meccanismo utile per la registrazione compare nel modello di decisione sulla preparazione al go-live: per l'approvazione condizionata si registrano la condizione, il responsabile, la scadenza, chi ne verifica il rispetto e la conseguenza in caso di mancato adempimento. Usate questo meccanismo per distinguere una vera autorizzazione condizionata da una promessa informale di completare il lavoro in seguito.
Approvate quando le evidenze confermano la possibilità di operare in produzione e i rischi residui sono accettati da responsabili identificati. Usate le condizioni per lacune circoscritte la cui risoluzione possa essere verificata prima dell'inizio dell'attività interessata. Rinviate quando una responsabilità operativa critica resta priva di copertura. Registrate il motivo, l'azione correttiva e le evidenze necessarie per la decisione successiva, non soltanto una nuova data.
Prima della riunione di approvazione, chiedete a ogni responsabile di processo critico e al responsabile del supporto subentrante di inserire evidenze e rischi aperti nello stesso documento decisionale. Se servono risorse funzionali o tecniche per colmare queste lacune, confrontatevi con gli specialisti ERP di Digiventi sul perimetro del rilascio e sulle responsabilità di supporto.
