Errori nei progetti ERP: trattare il go-live come un traguardo
Ho visto un help desk dedicato - persone con nome e numero di telefono, schierate apposta per le prime settimane - salvare una linea di produzione nei giorni dopo un lancio, difetto dopo difetto. E ho visto il contrario: il progetto smobilitato la settimana dopo l’accensione, gli utenti lasciati a improvvisare, la fiducia bruciata in un mese. In mezzo c’era la stessa idea sbagliata: che il go-live fosse un traguardo.
Questo è il sesto e ultimo errore di questa serie sui progetti ERP. Il piano c’è, il costo è guardato in faccia, i dati sono migrati e quadrati, le persone sono a bordo, i test hanno detto la loro: si accende. E proprio qui, a sistema acceso, si decide se i mesi precedenti diventano un investimento o un rimpianto.
Una partenza, non un traguardo
Il sistema si giudica nei primi giorni, e chi smobilita li consegna al caso.
Il go-live - la parola inglese è ormai d’uso comune - è l’accensione del sistema in esercizio, nella forma scelta dalla strategia di passaggio: l’evento più fotografato di un progetto, e il più frainteso. Per il progetto è la fine di una fatica; per l’azienda è il primo giorno di lavoro vero. Il pezzo sulla migrazione ha già detto come si forma la reputazione di un sistema: con le prime stampe, le prime bolle, i primi saldi. I primi giorni sono quelli in cui la fiducia si costruisce o si brucia, e sono esattamente i giorni in cui la tentazione di smobilitare è più forte: la stanchezza è tanta, i consulenti costano, i reparti reclamano le loro persone. «Mollare tutto» non è una decisione sbagliata che qualcuno prende: è quello che succede da sé, se nessuno ha deciso altrimenti prima.
Il presidio rafforzato
Un periodo dichiarato, con date e un criterio per uscirne: l’hypercare dei manuali.
La risposta di mestiere ha un nome: il presidio rafforzato - i manuali lo chiamano hypercare. La guida ufficiale all’implementazione di Dynamics 365, aperta e consultata, lo definisce un periodo breve dopo il go-live in cui si mettono in campo risorse e attenzione in più, perché l’azienda possa lavorare mentre i problemi iniziali vengono presi in carico. Dentro ci stanno tre cose: i consulenti raggiungibili, presenti e non «a chiamata»; i key user ancora col tempo prenotato, perché nei primi giorni il loro reparto ha bisogno di loro due volte, per il lavoro di sempre e per il sistema nuovo; un canale corto fra chi inciampa e chi corregge.
E il presidio ha un confine dichiarato. La stessa guida prescrive di definire prima la strategia di uscita, su criteri: nessun problema critico aperto, i processi chiave che girano, i tempi di servizio rispettati, il supporto ordinario capace di risolvere da solo. Il lettore della serie riconosce la figura al terzo incontro: è il criterio di uscita, già visto sulla quadratura dei dati e sulle soglie dei test. Dal presidio rafforzato si esce con dei numeri e una firma, non per stanchezza o perché è finito il budget delle giornate.
Il calendario delle prime volte
La prima chiusura, la prima fatturazione massiva: eventi con una data, da presidiare apposta.
Il presidio non è solo una durata: è un calendario. I test hanno provato la chiusura mensile, ma la prima chiusura vera - coi dati veri di un mese vero - è un evento, e ha una data nota in anticipo. Hanno una data anche le altre prime volte dei primi due o tre mesi. Non è una cautela inventata qui: il rapporto del GAO citato lungo tutta la serie elenca, fra le attività del dopo-conversione, il monitoraggio del primo ciclo di rendicontazione, la verifica d’integrità dei dati appena migrati, e la destinazione finale dei dati del sistema vecchio - l’archivio storico del pezzo sulla migrazione, che è qui che si chiude davvero.
| La prima volta | Quando arriva | Chi la presidia |
|---|---|---|
| La prima chiusura mensile | Fine del primo mese | Amministrazione, col consulente in linea |
| La prima fatturazione massiva | Il primo ciclo di fatturazione | Contabilità e direzione IT insieme |
| Il primo lancio completo di pianificazione | Il primo ordine di produzione a pieno regime | Produzione, col key user in reparto |
| Le prime scadenze di incasso e pagamento | Il primo scadenzario | Tesoreria, con la quadratura alla mano |
La regola pratica è semplice: ogni prima volta ha un presidio con un nome accanto, e il giorno dopo si fa il punto - cosa ha funzionato, cosa si corregge prima della seconda volta. Le prime volte superate sono anche il termometro del criterio di uscita: un sistema che ha passato la prima chiusura e la prima fatturazione è un sistema che si sta assestando.
Il canale dei problemi
Si eredita dal collaudo: il pannello, la classificazione e i key user come primo filtro.
Nei primi giorni i problemi arrivano, ed è un bene che arrivino: peggio è quando non arrivano perché la gente ha smesso di segnalare e si è arrangiata. Il canale però va organizzato, e non serve inventarlo: il pannello del collaudo sopravvive al go-live. La classificazione è la stessa dei test - bloccante, grave, minore - i tempi di risposta sono dichiarati per gravità, con una via di scalata scritta per i casi che non si sbloccano, e i key user fanno da primo filtro: raccolgono le segnalazioni dei colleghi, risolvono quel che sanno risolvere, passano il resto con le parole giuste. L’help desk - il punto unico di assistenza, con persone e orari pubblicati - dà al canale una porta d’ingresso che tutti conoscono. Quello che al collaudo era il pannello dei difetti diventa, senza cambiare natura, il pannello dei primi mesi.
Dal progetto all’esercizio
Il progetto finisce con consegne e una firma: l’AMS subentra, i key user restano.
Prima o poi il presidio finisce, ed è giusto che finisca: il criterio di uscita è fatto per questo. Non deve però finire nel nulla: il passaggio all’esercizio è un lavoro con le sue consegne, non uno spegnersi delle luci. La guida Microsoft lo dice con una formula pulita: il sistema va trasformato da progetto a soluzione, e una soluzione su cui l’azienda conta richiede una strategia di supporto. E la stessa guida aggiunge il punto che cambia il calendario: la transizione non è un evento, è un processo graduale che comincia presto, dentro il progetto. Chi supporterà il sistema partecipa alla costruzione e ai collaudi, e il modo migliore di allenarlo è usare i processi di supporto veri già durante il test utente: le segnalazioni dei collaudi si registrano, si smistano e si risolvono con gli stessi strumenti che serviranno dopo, così al go-live il supporto ha già i muscoli caldi.
Il rovescio è documentato nella stessa guida, in un caso di studio pubblicato: un’azienda europea di medie dimensioni che passava a un sistema unico diede per scontato che il supporto, esperto dei sistemi vecchi, avrebbe «imparato da sé» quello nuovo; la formazione fu rimandata perché il progetto era in ritardo, il passaggio di consegne si ridusse a due giorni, e i buchi si scoprirono dove si scoprono sempre: in produzione, coi processi cambiati e un supporto che non li conosceva.
In concreto il passaggio è il subentro dell’AMS - il servizio di gestione e manutenzione che il pezzo sulle persone ha visto disegnare dalla direzione IT, efficiente per chi usa e sostenibile per chi paga - con le consegne fatte per bene: le configurazioni documentate, il perché delle scelte, la mappa delle integrazioni, il registro dei difetti aperti, e le regole d’accesso del partner ai sistemi e ai dati scritte prima, non negoziate davanti a un problema critico. I key user restano dove il pezzo sulle persone li ha lasciati: riferimento dei colleghi, primo filtro del supporto, memoria del progetto.
E il progetto si chiude come si sono chiusi i suoi passaggi migliori: con una firma. Qualcuno con nome e cognome dichiara che le consegne sono fatte, che il presidio ordinario è in piedi, che i difetti rimasti hanno un piano. La delega effettiva del pezzo sulla pianificazione accompagna la serie fino all’ultima riga.
I numeri del dopo
Adozione e salute operativa: pochi indicatori, in continuità col pannello del collaudo.
Anche il dopo si misura, e i KPI del pannello hanno degli eredi naturali. Quattro esempi, in continuità con quelli del collaudo:
- il tasso di adozione: chi usa davvero il sistema, contro chi è tornato ai fogli di calcolo; è il numero che dice se l’investimento vive, e il suo rovescio tecnico è la procedura ombra che rispunta;
- gli arretrati: bolle non fatturate, ordini sospesi, registrazioni in coda; un arretrato che cresce è un processo che non gira, anche se nessuno ha aperto una segnalazione;
- le segnalazioni e la loro età: quante se ne aprono, quante se ne chiudono, da quanto aspettano le più vecchie; è il saldo dei difetti del collaudo, proseguito;
- i tempi delle operazioni quotidiane: la bolla, l’ordine, la registrazione; se si allungano, nei corridoi lo si dice prima che sul pannello - e il pannello serve proprio ad accorgersene prima dei corridoi.
Le soglie giuste dipendono dall’azienda e dal punto di partenza; il metodo invece no: dichiararle prima e guardarle ogni settimana, insieme, sul pannello che tutti conoscono già.
Il riconoscimento
Un lancio riuscito è un lavoro di molti: dirlo ad alta voce costa poco e rende molto.
Resta un ultimo gesto, che i manuali dimenticano: riconoscere il lavoro fatto. Un ERP acceso è costato mesi di doppio lavoro ai key user, pazienza ai reparti, sere lunghe alla direzione IT. Dirlo, ad alta voce e coi nomi - una riunione, un pranzo, un grazie scritto che resta - costa poco e rende molto: le stesse persone dovranno sostenere il sistema per anni, e il morale con cui lo faranno si costruisce adesso. Il progetto è finito; il modo in cui lo si dichiara finito lavora ancora per anni.
Il miglioramento governato
La coda delle richieste o si governa con un registro, o diventa deriva.
A sistema assestato arriva la coda: le personalizzazioni rimandate per scelta (il pezzo sul TCO aveva raccomandato di rimandarle), le mancanze emerse dall’uso, le idee dei reparti, le procedure ombra scoperte tardi che chiedono una casa vera. Questa coda ha due destini possibili. Il primo è il registro del miglioramento: ogni richiesta scritta, con una priorità, un responsabile e una revisione periodica - la stessa disciplina del pannello, applicata al futuro. Il secondo destino è non avere registro: le richieste passano per i corridoi, le più urlate vincono sulle più utili, e la deriva del perimetro - già incontrata nel pezzo sulla pianificazione - ricompare a sistema acceso, coi costi che il TCO aveva messo in conto. Fra i due destini la differenza non è la quantità di lavoro: è chi decide l’ordine.
La serie, ricapitolata
Sei errori, un filo solo: le decisioni prese prima valgono più delle correzioni fatte dopo.
Il giro è completo. Sei errori, in ordine di lettura: trattare la pianificazione come un optional; scegliere al ribasso senza guardare il costo totale; trattare la migrazione dei dati da dettaglio tecnico; lasciare le persone fuori dal cambiamento; saltare i test perché si è in ritardo; e trattare il go-live come un traguardo. A rileggerli insieme, il filo è uno: ogni errore è una decisione non presa in tempo - una delega non data, un criterio non scritto, un piano non difeso - che si ripresenta più tardi, con gli interessi. Il rimedio non è mai eroico e ha sempre la stessa forma: decidere prima, per iscritto, con un nome accanto. I sei pezzi si leggono dall’indice della serie, e i concetti che hanno introdotto - dalla delega effettiva al criterio di uscita, dai key user al debito di collaudo - si navigano nel grafo dei concetti di questo sito.
I concetti che questo articolo introduce
Cinque voci nuove sull’ambito ERP, e il go-live smette di essere una parola senza definizione.
| Concetto | Ambito | Che cos’è | Si lega a |
|---|---|---|---|
| Go-live | erp | L’accensione del sistema in esercizio: una partenza con una data, non un traguardo | lo governa la strategia di passaggio; apre il presidio rafforzato |
| Presidio rafforzato (hypercare) | erp | Il periodo dichiarato dopo il go-live in cui il progetto resta schierato: consulenti raggiungibili, key user col tempo prenotato, canale corto | comincia col go-live; se ne esce con un criterio di uscita, non per stanchezza; il primo filtro lo fanno i key user |
| Passaggio all’esercizio | erp | Lo smontaggio del progetto con le consegne a chi resta: l’AMS subentra, i key user diventano riferimento, la chiusura ha una firma | il supporto lo disegna prima la direzione IT; la firma di chiusura chiede la delega effettiva |
| Tasso di adozione | erp | La misura di chi usa davvero il sistema, contro chi è tornato ai fogli: il numero che dice se l’investimento vive | il suo crollo segnala resistenza al cambiamento rimasta inascoltata; la procedura ombra è il suo rovescio tecnico |
| Registro del miglioramento | erp | La coda governata delle richieste dopo il lancio: personalizzazioni rimandate, mancanze emerse, idee dei reparti, con priorità, responsabili e revisione periodica | senza governo la coda diventa deriva del perimetro a sistema acceso; lo alimentano i key user dal supporto |
Fonti
- Microsoft, guida ufficiale all’implementazione di Dynamics 365: Plan your support operations e Create a support strategy, aperte e consultate, col relativo caso di studio - la definizione di hypercare come periodo breve dopo il go-live con risorse e attenzione in più; la strategia di uscita da dichiarare prima, su criteri (nessun problema critico, processi chiave efficienti, livelli di servizio rispettati, supporto autonomo); il passaggio del sistema da progetto a soluzione come processo graduale che comincia dentro il progetto, col supporto allenato sui processi veri già durante il test utente; i livelli di servizio con scalate dichiarate e le regole d’accesso del partner definite prima; e il caso dell’azienda europea col passaggio di consegne ridotto a due giorni, scoperto in produzione.
- U.S. Government Accountability Office, Financial Management Systems: Additional Efforts Needed to Address Key Causes of Modernization Failures, GAO-06-184, marzo 2006 - fra le attività del dopo-conversione, il monitoraggio del primo ciclo di rendicontazione: la prima chiusura si presidia.
- L’aneddoto dell’help desk, il calendario delle prime volte, il registro del miglioramento e le regole sul riconoscimento vengono dall’esperienza diretta di progetto di chi scrive, e come tali vanno letti.