Errori nei progetti ERP: pensare che la pianificazione sia un optional

Ho visto un produttore manifatturiero buttare via mesi di lavoro. Per la fretta di mostrare risultati, il progetto aveva saltato il confronto con il reparto produzione: il sistema non gestiva i loro cicli di lavorazione, e nessuno se n’era accorto finché rimediare non è diventato costoso. E i cicli di lavorazione non sono un dettaglio: sono il modo in cui quella fabbrica trasforma materia in prodotto, e un gestionale che non li rappresenta obbliga la produzione a lavorare fuori dal sistema, su fogli di calcolo, dal primo giorno. Quel guasto era nato prima della scelta della tecnologia, nel confronto che nessuno aveva cercato.

Questa serie raccoglie sei errori visti nei progetti ERP (Enterprise Resource Planning: il sistema gestionale che tiene insieme contabilità, magazzino, produzione e vendite), uno per fase del progetto. Il primo viene prima di tutti gli altri, perché li rende possibili: trattare la pianificazione come un accessorio.

Un progetto su sei finisce fuori controllo

Lo sforamento medio è sopportabile. Il rischio vero sono i progetti che escono da ogni previsione.

I progetti informatici non falliscono in media: falliscono nei casi estremi. Lo studio di Flyvbjerg e Budzier su un ampio campione di progetti, pubblicato dalla Harvard Business Review, dice che lo sforamento medio dei costi è contenuto, ma un progetto su sei diventa un cigno nero di progetto: costi in media al triplo del previsto e tempi allungati di quasi il 70%. Guardare la media rassicura; il conto lo presentano i casi estremi.

Un ERP sta quasi sempre nella categoria esposta, per quattro ragioni che si sommano. Tocca ogni reparto, quindi ogni requisito dimenticato ha un proprietario che prima o poi lo reclama. Sostituisce abitudini decennali, quindi il grosso del lavoro è far lavorare le persone in un modo nuovo. Si decide una volta ogni dieci o quindici anni, quindi l’azienda che lo affronta non ha memoria fresca di come si fa, e giudica il lavoro di fornitori che ne sanno più di lei. E arriva insieme a un integratore di sistema, cioè a un partner il cui contratto è stato firmato quando il perimetro era ancora un’idea. Ognuna di queste ragioni, da sola, si governa. Insieme, senza pianificazione, compongono il cigno nero.

Che cosa significa pianificare un progetto ERP

Un perimetro dichiarato, i requisiti raccolti da chi userà il sistema, e un nome accanto a ogni decisione.

Nella pianificazione ERP tre prodotti contano più del calendario, e nessuno dei tre è un documento di cortesia.

Il primo è il perimetro del progetto: l’elenco di ciò che il progetto consegna e, altrettanto esplicito, di ciò che non consegna. Quasi sempre manca la seconda metà, che è la più utile: quando arriva la richiesta di gestire anche la manutenzione degli impianti, la risposta sta in una riga scritta sei mesi prima.

Il secondo è la raccolta dei requisiti: il censimento di ciò che il sistema deve fare, condotto con chi lo userà davvero e non solo con chi lo compra. Il magazziniere sa cose sul ciclo passivo - il giro degli acquisti, dall’ordine al pagamento - che il direttore amministrativo non sospetta; l’operatore di linea sa quali scarti si registrano e quali si registrano il giorno dopo, a memoria. Un requisito che manca qui riappare fra un anno come modifica urgente, al prezzo delle modifiche urgenti. Il Project Management Institute ha misurato il peso di questa fase: la raccolta inaccurata dei requisiti è causa primaria del 37% dei progetti falliti, e il 5,1% di ogni euro investito nei progetti va sprecato per requisiti gestiti male. Sono numeri del 2014, e chi frequenta i progetti sa quanto poco sia cambiato.

Il terzo prodotto è un elenco di nomi: chi decide il perimetro, chi firma i requisiti di ogni processo, chi ha l’autorità di dire no a una richiesta di modifica. Nei progetti che ho visto andare male questo elenco non esisteva, e al suo posto lavorava una regola non scritta: decide chi urla più forte, più vicino alla scadenza.

L’elenco ha anche un errore speculare: accentrare ogni decisione alla direzione. Sembra prudenza e produce l’effetto opposto, perché la direzione non ha gli strumenti per entrare nel merito di un ciclo passivo o di un tracciato di magazzino, e chi non può decidere nel merito decide sulle uniche grandezze che vede: il bilancio e le date. Così ogni scelta tecnica diventa una trattativa su costi e scadenze, che è il modo più caro di deciderla. La delega effettiva è la condizione dell’elenco dei nomi: chi firma i requisiti di un processo deve avere l’autorità di deciderli, sennò l’elenco raccoglie passacarte e la decisione vera risale sempre, spogliata del merito, fino a chi guarda solo il bilancio.

Il censimento delle integrazioni

Un ERP non lavora da solo. Prima di fissare perimetro e requisiti va scritto l’elenco dei sistemi che gli stanno intorno, e per ciascuno la decisione: si integra, si sostituisce, si spegne.

Ai tre prodotti se ne aggiunge uno che in molti progetti non viene scritto mai, e che decide gli altri tre. Nessun ERP lavora da solo: intorno all’azienda che lo installa vivono già il programma della produzione, quello del magazzino, il gestionale commerciale, il portale degli ordini, il software di manutenzione, i collegamenti con le banche, il fornitore che manda i listini e il cliente che pretende il documento di trasporto nel suo formato. Il censimento delle integrazioni è l’elenco scritto di quei sistemi, con una decisione presa per ciascuno: si integra, si sostituisce o si spegne.

La decisione va presa all’inizio perché ognuna delle tre risposte cade su un prodotto diverso della pianificazione. Sostituire un sistema porta i suoi requisiti dentro il perimetro del progetto, e il perimetro cresce. Integrarlo crea un’interfaccia, che è un contratto fra due programmi: va costruita, provata e mantenuta a ogni cambio di uno dei due lati, e il pezzo sul costo totale conta perché quella voce si paga due volte. Spegnere un sistema sembra la risposta più semplice ed è quella che chiede più attenzione, perché quasi sempre qualcuno lo usa ancora per un lavoro che nessuno ha dichiarato.

Per ogni voce dell’elenco servono cinque informazioni, e sono le stesse che al collaudo diranno se l’interfaccia funziona:

• il proprietario: chi risponde di quel sistema, per nome, dalle due parti del collegamento;
• i flussi: quali dati entrano e quali escono, con la direzione dichiarata;
• il momento: se lo scambio avviene mentre si lavora o durante la notte, e ogni quanto;
• il volume: quanti documenti al giorno, perché un tracciato che regge cento righe può non reggerne centomila;
• il comportamento in caso d’errore: che cosa succede quando lo scambio fallisce, e chi se ne accorge.

Il censimento sbaglia quasi sempre nello stesso modo: si conduce chiedendo all’informatica quali applicazioni esistono. Così si trovano i sistemi ufficiali, quelli con una licenza e un contratto, e restano fuori i passaggi di dati che non hanno un nome - il file esportato ogni lunedì, la casella di posta da cui qualcuno copia gli ordini, la cartella condivisa dove il fornitore deposita i listini. La domanda che li fa emergere non è «quali applicazioni avete», ma «quali dati vi arrivano e da dove, e quali dati uscendo da qui vanno a finire da qualche altra parte». È la stessa domanda che serve a scoprire le procedure ombra, il caso limite di cui il pezzo sul costo totale racconta il prezzo.

Questo elenco non muore alla fine del progetto. Passa all’esercizio e diventa il registro vivo che l’approfondimento sulla direzione IT chiama inventario delle interfacce: la prima pagina che si apre quando arriva un aggiornamento, e la prima domanda che si fa quando di notte un flusso non arriva.

I tre modi in cui la pianificazione salta

Requisiti raccolti dai soli vertici, perimetro che deriva, dati lasciati per ultimi.

Il primo modo è raccogliere i requisiti dai soli vertici. È il più naturale, perché i vertici sono disponibili, parlano il linguaggio del progetto e hanno firmato il contratto. Il risultato è un sistema che risponde all’organigramma: le funzioni descritte nelle riunioni ci sono tutte, e i processi reali, quelli che vivono nei reparti, restano fuori. La logistica che scopre al lancio di non avere il tracciamento sta leggendo il verbale di chi non era stato invitato.

L’errore opposto inganna di più: raccogliere solo dal basso. Un censimento condotto reparto per reparto, senza la direzione, tende a ricostruire l’esistente dentro il sistema nuovo, e un ERP che fotografa i processi di ieri è un investimento per non cambiare niente. Le indicazioni dei vertici sono la rotta del cambiamento e vanno tenute ferme; il lavoro sui requisiti è il punto in cui quella rotta si misura con i processi reali. Dove le due cose non combaciano si apre un cantiere di cambiamento organizzativo, e conviene aprirlo subito: costruire il consenso è il lavoro più lento del progetto, e rimandarlo al lancio significa ritrovarlo come resistenza. Come si governa quel cantiere lo racconta il pezzo sulle persone lasciate all’oscuro del cambiamento.

Il secondo modo è la deriva del perimetro (in inglese scope creep), e il nome italiano descrive bene la cosa: non è un evento, è una corrente. Nessuna singola richiesta la causa; la causa è l’assenza di un perimetro dichiarato contro cui pesare le richieste. Ogni aggiunta sembra piccola, urgente e ragionevole, e nessuna porta scritto il proprio costo. Tempi e bilancio si scoprono sforati a cose fatte, e a quel punto la colpa è di tutti, cioè di nessuno.

Il terzo modo è lasciare i dati per ultimi, come se fossero un dettaglio tecnico del trasloco. Anagrafiche duplicate e registri non riconciliati entrano nel sistema nuovo dal primo giorno e lo screditano subito: la prima stampa sbagliata vale più di dieci dimostrazioni riuscite. La pulizia dei dati comincia in pianificazione, quando si decide cosa migrare e cosa lasciare morire nel sistema vecchio; come si fa lo spiega il pezzo sulla migrazione dei dati.

Come si riconosce un piano di facciata

Quattro segni che il piano è solo un rito.

Molti progetti falliti avevano un piano, spesso rilegato. La pianificazione di facciata si riconosce da segni precisi.

La data di lancio è stata decisa prima del perimetro: il progetto parte da quando deve finire, e ogni analisi successiva è una trattativa contro un numero già promesso al consiglio di amministrazione. Il piano l’ha scritto il fornitore da solo: è accurato, professionale, e descrive il progetto che conviene a lui. Nessuna fase ha una condizione di chiusura scritta: le fasi finiscono quando finisce il tempo assegnato, e ciò che resta scivola nella fase dopo, che era già piena. E il piano non nomina mai ciò che il progetto non farà: un documento che promette tutto non ha deciso niente.

Chi ritrova due o più di questi segni nel proprio progetto non ha un piano: ha un calendario con un logo.

Il rimedio ha una forma: il piano a tappe

Fasi con traguardi verificabili, e la condizione di chiusura decisa prima di cominciare.

Il rimedio è dare alla pianificazione una forma controllabile. Il piano a tappe divide il progetto in fasi con traguardi verificabili, e ogni tappa chiude con un criterio di uscita: la condizione, decisa prima, che dice se la fase è finita davvero o se è solo finita l’agenda.

Un criterio di uscita scritto bene è concreto fino al fastidio. Per la fase dei requisiti, per esempio: «ogni processo del perimetro ha un flusso futuro documentato, firmato dal responsabile del reparto che lo eseguirà; le eccezioni note sono elencate con la decisione presa su ognuna». Se per una fase non si riesce a scrivere una frase così, quella fase è soltanto un periodo del calendario. È lo stesso principio della valutazione degli agenti AI, che il pezzo sull’harness spiega per intero: dire prima come si misura la riuscita è il gesto che distingue un piano da una speranza.

Le scadenze, in questa forma, si negoziano sui fatti. Se la data non regge, il piano a tappe mostra quale tappa non regge e cosa si può togliere dal perimetro per tenerla: la conversazione si sposta dal «ce la faremo» al «cosa lasciamo fuori». Senza piano, la data si tiene tagliando in silenzio le cose che si vedranno dopo il lancio, e si arriva ai test e all’abbandono dopo il lancio, gli ultimi due errori della serie, con il costo già deciso.

Dove prosegue la serie

Sei errori, uno per fase: questo era il primo.

I prossimi pezzi seguono l’ordine del progetto, non quello di pubblicazione: la scelta del sistema guardando solo il prezzo, la migrazione dei dati trattata da dettaglio tecnico, le persone lasciate all’oscuro, i test sacrificati alla data, e l’abbandono dopo il lancio. In fondo a ogni pezzo sta la tabella dei concetti che introduce: da lì nasce la mappa che collega questa serie al resto del sito.

I concetti che questo articolo introduce

Otto voci nuove sull’ambito ERP, e un aggancio alla valutazione degli agenti.

---

Fonti

• Bent Flyvbjerg e Alexander Budzier, Why Your IT Project Might Be Riskier Than You Think, Harvard Business Review 89(9), 2011, copia ufficiale degli autori su arXiv - il progetto su sei che diventa un cigno nero, con sforamento medio del 200% dei costi e di quasi il 70% dei tempi. È la fonte del numero che apre questo articolo.
• Project Management Institute, Requirements Management: A Core Competency for Project and Program Success, Pulse of the Profession, agosto 2014 - la raccolta inaccurata dei requisiti come causa primaria del 37% dei progetti falliti, e il 5,1% di spreco per requisiti gestiti male.
• Gli episodi raccontati vengono dall’esperienza diretta di chi scrive: errori visti, non letti.