Errori nei progetti ERP: lasciare le persone fuori dal cambiamento

Ho visto insegnare un sistema nuovo con un’unica sessione di formazione, uguale per tutti, dalla contabilità al magazzino: dopo un mese metà dell’azienda lavorava come prima, sui fogli di calcolo. E ho visto sessioni costruite sui casi di ogni reparto trasformare utenti frustrati in alleati del progetto. In mezzo non stava un software diverso: stava il fatto che qualcuno avesse capito, o no, che l’adozione è un lavoro.

Questo è il quarto dei sei errori di questa serie sui progetti ERP. Il piano c’è, il costo totale è stato guardato in faccia, i dati sono in viaggio con le loro prove e la loro quadratura: ora il sistema deve entrare nelle abitudini di chi lavora, ed è il punto in cui i progetti tecnicamente riusciti falliscono lo stesso.

Il sistema giusto che nessuno usa

L’adozione non è spontanea, e i numeri dicono che a mancare sono guida e comunicazione.

Un ERP configurato bene e usato male è un fallimento con tutte le fatture pagate. Il rapporto del GAO - l’ufficio del Congresso americano che controlla i conti federali - già citato nel pezzo sulla migrazione mette la gestione delle persone, cambiamento compreso, fra le tre famiglie di cause dei fallimenti: accanto ai processi disciplinati e al governo dell’informatica, alla stessa altezza.

E la misura del problema è documentata. Il PMI (Project Management Institute, l’associazione internazionale di chi dirige progetti) ha indagato nel 2014 su oltre settecento capi progetto come le organizzazioni gestiscono il cambiamento: meno di una su cinque (il 18%) si dichiara davvero efficace, e chi lo è raccoglie il doppio: il 65% delle sue iniziative centra gli obiettivi, contro il 31% delle altre. E le due cause prime dei fallimenti, nelle risposte, sono la comunicazione insufficiente (59%) e la mancanza di guida (56%). Nessuna delle due riguarda la tecnologia, e sono le due cose di cui parla questo pezzo.

La gestione del cambiamento (il change management dei manuali) è proprio questo: il lavoro organizzato - comunicare, coinvolgere, formare, sostenere - che fa passare il sistema dalle slide alle abitudini. Ha un difetto strutturale: i suoi tempi sono più lunghi di quelli tecnici, perché il consenso non si installa. Per questo il pezzo sulla pianificazione chiedeva di aprire i cantieri del cambiamento il prima possibile.

E il cambiamento non è fatto di sole persuasioni: è anche revisione dei processi. Il rapporto GAO ne conserva il controesempio: al Dipartimento dell’Interno americano, per non aver preso il tempo di riesaminare e rivedere i propri processi, il sistema nuovo rischiava di perpetuare i vecchi modi di lavorare. Si paga il prezzo del cambiamento e si conservano le vecchie abitudini: il peggiore dei due mondi.

La direzione che ci mette la faccia

Serve qualcuno che ci metta la faccia, e che possa decidere quando i reparti confliggono.

Il primo fattore di efficacia, nella stessa indagine PMI, è il sostegno dei vertici (lo indica il 72% degli intervistati), e le iniziative con uno sponsor attivo della direzione sono il 64% nelle organizzazioni efficaci contro il 41% nelle altre. Il numero ha un volto concreto: la sponsorship della direzione è qualcuno dei vertici che ci mette la faccia. Firma i messaggi, apre le riunioni che contano, e soprattutto decide quando il progetto fa emergere i conflitti fra reparti - e li fa emergere sempre, perché un ERP ridistribuisce lavoro, visibilità e potere.

Qui torna la delega effettiva del primo pezzo: la sponsorship non è la direzione che decide tutto, è la direzione che dà mandati chiari e li difende. Lo sponsor non decide come va strutturato il campo «magazzino» in anagrafica: decide chi lo decide, e quando due reparti tirano la coperta ciascuno dalla sua parte, arbitra in tempi brevi. Un progetto sponsorizzato solo dall’IT è, agli occhi dell’azienda, un progetto dell’IT: gli altri reparti lo subiscono, e aspettano che passi.

La direzione IT, la regia tecnica

Fra lo sponsor e i reparti, la direzione IT tiene la regia: progetto, conflitti, requisiti, interfacce, conformità, supporto e ciclo di vita.

La sponsorship non può essere solo dell’IT, ma questo non ridimensiona la direzione IT: le assegna il mestiere suo, che non è «quelli dei server». Fra il progetto e il dopo, i suoi mestieri sono almeno sette:

• la regia della corsia tecnica, cioè la conduzione quotidiana del progetto: coordina l’integratore di sistema, i fornitori e i consulenti, tiene insieme il calendario e le dipendenze fra i cantieri;
• il primo livello dei conflitti: molte tensioni fra reparti nascono tecniche - un campo conteso, una priorità di sviluppo, un’interfaccia - e si sciolgono qui; alla sponsorship deve salire soltanto ciò che richiede davvero una decisione dei vertici;
• la copertura dei requisiti: verifica che ogni requisito raccolto sia stato mappato su una risposta del sistema - una configurazione, una personalizzazione o una rinuncia dichiarata - e che nessuno si sia perso per strada fra le interviste e il rilascio;
• le interfacce e i dati: risponde della continuità dei flussi con i sistemi di terzi, al passaggio e dopo, e pretende che la mappatura dei dati della migrazione sia una procedura ripetibile - scritta, rieseguibile, provata - e non un lavoro artigianale fatto una volta: è la condizione perché le migrazioni di prova del pezzo sulla migrazione siano prove davvero;
• i requisiti che nessun reparto chiede: la disponibilità del sistema quando l’azienda lavora, la sicurezza, e la conformità alle norme vigenti: il GDPR, il regolamento europeo sulla protezione dei dati personali; la NIS2, la direttiva europea sulla sicurezza delle reti e dei sistemi informativi; e, se il sistema incorpora funzioni di intelligenza artificiale, l’AI Act, il regolamento europeo che le disciplina. Nessun utente li chiederà nelle interviste: se non li porta la direzione IT, non li porta nessuno;
• il supporto del dopo: disegna l’AMS (Application Management Services, l’organizzazione che assiste e manutiene il sistema a progetto chiuso) tenendo insieme le due misure che tirano in direzioni opposte: efficiente per chi il sistema lo usa - risposte in tempi noti, coi key user come primo filtro - e sostenibile nei costi per l’azienda. Il pezzo sul TCO (il costo totale di possesso) ha già messo questa voce nel conto;
• il ciclo di vita del sistema: versioni, aggiornamenti e durata prevista devono restare compatibili con gli obiettivi aziendali. Un sistema che impone all’azienda i suoi tempi, o che l’azienda supera prima di averlo ammortizzato, è una strategia scritta da altri.

Così la catena della guida regge: la sponsorship decide ciò che conta davvero, la direzione IT dirige la macchina e trattiene ciò che deve restare tecnico. I sette mestieri hanno un approfondimento dedicato in questa serie; qui manca l’ultimo gradino, la voce dei reparti dentro il progetto: i key user.

I key user, il ponte

Le persone dei reparti che accompagnano il progetto dall’inizio alla fine: chi sono, cosa fanno, e perché il loro tempo si prenota.

I pezzi precedenti li hanno già incontrati due volte: servivano per i test degli aggiornamenti in cloud, servivano per validare i dati migrati. È il momento di presentarli. Il key user è la persona del reparto che il processo lo conosce com’è davvero, non com’è descritto nelle procedure: sa come si lavora ogni giorno, quali eccezioni capitano, come si risolvono. Dentro il progetto fa da ponte, e il ponte si attraversa nei due sensi. Verso chi costruisce il sistema porta questa conoscenza: racconta i processi veri del suo reparto, perché il disegno si fondi su quelli. Verso i colleghi porta il sistema nuovo: lo prova per primo, lo impara per primo, e poi lo insegna.

Due cose della tabella si pagano care se mancano. La prima è la scelta: il key user finisce spesso per essere «quello che si può liberare», cioè il meno indispensabile al reparto, cioè raramente il più bravo. È la scelta opposta a quella giusta, e si vede mesi dopo, nei requisiti mancati e nei test firmati senza guardare. La seconda è il tempo: quelle persone mandano avanti i reparti, e se il progetto le usa «quando possono», non le usa mai, o le brucia col doppio lavoro. Il loro tempo va prenotato come una risorsa del progetto, con un sollievo vero sulle attività ordinarie: è lo stesso vincolo visto sul TCO e sulla migrazione, perché è sempre il medesimo tempo. Il rapporto GAO ne documenta un caso: al ministero della salute americano le figure chiave coprivano più ruoli con un tempo effettivo inadeguato ai compiti, il personale era sovraccarico e posizioni essenziali restavano vacanti o coperte a tempo parziale. Il primo rilascio slittò di sei mesi.

Il loro compito non finisce col progetto: a sistema acceso i key user diventano le persone di riferimento per la gestione e la manutenzione - il primo aiuto dei colleghi, il filtro delle richieste, la memoria del perché le cose sono configurate così. Il progetto finisce; il ponte resta.

La resistenza è un’informazione

Chi resiste spesso sta indicando un processo che il disegno non ha visto.

La stessa indagine PMI registra un contrasto di sguardi che chiunque abbia attraversato un progetto riconosce: i dirigenti tendono a vedere nel cambiamento un’opportunità, per l’azienda e per sé; i dipendenti tendono a viverlo come un’intrusione e una probabile perdita. Trattare questa distanza da problema di comunicazione in senso stretto - «non hanno capito» - è l’errore comodo. Una parte della resistenza al cambiamento è timore, e si cura con la chiarezza; ma un’altra parte è informazione: chi si oppone sta spesso difendendo un pezzo di processo che il disegno non ha capito.

Il pezzo sul TCO l’ha mostrato dal lato tecnico: le procedure ombra - i fogli e le maschere fuori dal gestionale - nascono proprio dove le persone non sono state intervistate, o dove i responsabili non le hanno coinvolte. La resistenza è il sintomo umano della stessa malattia. Ascoltarla prima di volerla vincere è il modo più economico di scoprire i requisiti mancanti: ogni «così non posso lavorare» esaminato sul serio è un’integrazione, un’eccezione o una procedura ombra che esce allo scoperto prima del go-live invece che dopo.

La comunicazione ha un calendario

Prima si spiega il perché, durante si dice cosa cambia per ciascuno, al rilascio si dice dove chiedere aiuto.

La comunicazione insufficiente è la prima causa di fallimento nell’indagine PMI, e i fattori che distinguono le organizzazioni efficaci sono precisi: avere un piano di comunicazione, eseguirlo davvero, e comunicare i benefici attesi del cambiamento. «Canali bidirezionali» è un nome; un piano è un calendario:

• prima, il perché: cosa non regge più nel modo attuale di lavorare, cosa ci guadagna l’azienda, cosa ci guadagnano - o smettono di perdere - le persone. È il messaggio che firma la sponsorship, non l’IT;
• durante, il cosa: cosa cambia per il tuo lavoro, quando, e cosa no. Le paure crescono nel vuoto, e il vuoto si riempie da solo, di voci;
• al rilascio, il dove: dove si chiede aiuto, chi risponde, in quanto tempo. Qui i key user diventano visibili a tutti;
• in ogni fase, l’ascolto: un canale dove le domande arrivano davvero e le risposte tornano indietro - e le obiezioni si esaminano, perché la resistenza, si è visto, è anche informazione.

Il «cosa cambia per il tuo lavoro» non è un dettaglio di cortesia: nei casi del rapporto GAO, all’ufficio che gestisce il personale federale mancava proprio un piano di transizione che preparasse le persone al cambiamento delle loro mansioni. Quel piano è la comunicazione di mezzo, messa per iscritto.

La formazione parla la lingua del reparto

Per ruolo, coi dati propri, vicina al rilascio: la sessione unica per tutti non insegna a nessuno.

L’aneddoto dell’apertura ha già detto quasi tutto. La formazione per ruolo batte la sessione unica perché non insegna «il sistema» in astratto: insegna a ciascuno come si fa, nel sistema nuovo, il proprio lavoro di ogni giorno. La contabilità si esercita sulle chiusure, il magazzino sulle bolle. E ci si esercita sui dati propri - i clienti veri, gli articoli veri, con le loro eccezioni - perché il lavoro vero è fatto di quelli. È la stessa idea della prova su casi propri che i pezzi precedenti hanno usato per scegliere il sistema e per validare i dati migrati, portata in aula.

La posta è concreta. Un contabile che al primo bilancio non sa dove mettere le mani torna ai fogli di calcolo, e il pezzo sul TCO ha già contato quanto costa riportare al sistema chi è tornato ai fogli. Il caso limite sta nel rapporto GAO: al ministero dei veterani americano la conversione al sistema nuovo fu compromessa anche perché il personale della gestione scorte non era stato addestrato come previsto. La formazione mancata non rallenta soltanto: interrompe.

Due regole pratiche, per esperienza. La formazione si fa vicina al rilascio: quella fatta tre mesi prima evapora, e al go-live è come non fatta. E la erogano, dove possibile, i key user ai colleghi: parlano la lingua del reparto, rispondono con gli esempi giusti, e il sapere resta in casa invece di andarsene col consulente.

Il confine col dopo

Del presidio dopo il lancio parla un altro articolo della serie: qui resta il ponte per arrivarci.

Il vecchio consiglio «non fermatevi al go-live» è giusto e trova posto più avanti: il sesto pezzo della serie tratta il presidio dopo il lancio, i problemi dei primi giorni e il miglioramento che segue. Qui basta il raccordo: la struttura che regge quel dopo - i key user come riferimento, il canale per i problemi, la fiducia costruita con la formazione - non si può improvvisare a sistema acceso. O esce dal progetto già in piedi, o non esiste.

Dove prosegue la serie

Persone a bordo: restano i test, e poi il lancio.

L’errore quarto era credere che l’adozione fosse spontanea. Le persone sono a bordo quando qualcuno dei vertici ci mette la faccia, la direzione IT tiene la regia tecnica, i key user fanno da ponte col tempo prenotato, la resistenza viene ascoltata prima che vinta, e la formazione parla la lingua di ogni reparto. Il prossimo pezzo tratta i test - quelli che si saltano «perché siamo in ritardo» - e l’ultimo il go-live e il dopo.

I concetti che questo articolo introduce

Sei voci nuove sull’ambito ERP, con gli agganci alla delega, alle procedure ombra e alla migrazione.

---

Fonti

• U.S. Government Accountability Office, Financial Management Systems: Additional Efforts Needed to Address Key Causes of Modernization Failures, GAO-06-184, marzo 2006 - la gestione delle persone, cambiamento compreso, è una delle tre famiglie di cause ricorrenti dei fallimenti, accanto ai processi disciplinati e al governo dell’informatica. Suoi anche i casi citati: le figure chiave con più ruoli e tempo inadeguato ai compiti, col rilascio rinviato di sei mesi (ministero della salute); i processi non rivisti che fanno perpetuare al sistema nuovo i vecchi modi di lavorare (Dipartimento dell’Interno); il piano di transizione mancante sulle mansioni (ufficio del personale federale); l’addestramento saltato che compromette la conversione (ministero dei veterani).
• Tricia S. Cabrey e Amy Haughey, Enabling Organizational Change Through Strategic Initiatives, PMI Pulse of the Profession In-Depth Report, marzo 2014 - indagine su 723 professionisti di progetto: solo il 18% delle organizzazioni si dichiara molto efficace nel gestire il cambiamento; le cause prime dei fallimenti sono la comunicazione insufficiente (59%) e la mancanza di guida (56%); il sostegno dei vertici è il primo fattore di efficacia (72%) e gli sponsor attivi distinguono le organizzazioni efficaci (64% contro 41%); contano un piano di comunicazione, la sua esecuzione e la comunicazione dei benefici attesi.
• I testi delle norme citate, nelle versioni ufficiali su EUR-Lex: regolamento (UE) 2016/679 (GDPR), direttiva (UE) 2022/2555 (NIS2), regolamento (UE) 2024/1689 (AI Act).
• Le regole pratiche sui key user e sui mestieri della direzione IT - la scelta, il tempo prenotato, il sollievo sul lavoro ordinario, la formazione erogata ai colleghi, il filtro dei conflitti, la mappatura ripetibile - vengono dall’esperienza diretta di progetto di chi scrive, e come tali vanno lette.