Errori nei progetti ERP: saltare i test perché si è in ritardo

Ho visto sistemi arrivare al lancio con ogni funzione provata e nessun filo percorso per intero: gli ordini si inserivano, la merce usciva, ma le fatture non partivano, perché il passaggio dalla spedizione alla fatturazione non l’aveva mai attraversato nessuno. E ho visto un progetto multinazionale arrivare al lancio dopo due cicli di test completi, ripetuti fino a noia, e partire senza un giorno di caos. La differenza non era la fortuna, e nemmeno il fornitore: era il posto che i test avevano nel calendario, e chi aveva il potere di difenderlo.

Questo è il quinto dei sei errori di questa serie sui progetti ERP. Il piano c’è, il costo è guardato in faccia, i dati sono in viaggio, le persone sono a bordo: resta da dimostrare che tutto questo funzioni insieme, prima di scoprirlo coi clienti.

I test in fondo al calendario

Il ritardo di tutti diventa il ritardo dei test: la data non si sposta, la qualità sì.

Nessuno decide a tavolino di saltare i test: ci si arriva. La meccanica è sempre la stessa, e conviene descriverla per intero. Si prova più volte, lungo tutto il percorso - il pezzo ci torna fra poco - ma il collaudo che decide, quello finale, sta in fondo al calendario, dopo la configurazione, le personalizzazioni e la migrazione; la data di lancio, intanto, è stata promessa - alla direzione, ai reparti, a volte ai clienti - e spostarla costa a chi l’ha promessa. Così ogni ritardo a monte scivola a valle, e a valle non c’è più nessuno: l’ultimo blocco della fila assorbe il ritardo di tutti. «Siamo in ritardo» non diventa mai «costruiamo meno»: diventa «proviamo meno».

Il rimedio non sta nei test: sta nel piano. Il piano a tappe del pezzo sulla pianificazione dà ai test un perimetro difeso e margini di tempo dichiarati; la sponsorship della direzione, dal pezzo sulle persone, ha il potere di spostare la data o il perimetro quando i margini finiscono. Se nessuno può toccare la data né il perimetro, la variabile rimasta è una sola: la qualità.

Il debito di collaudo

I difetti noti lasciati passare non spariscono: ricadono sui rilasci successivi, con gli interessi.

Che cosa succede quando l’asticella si abbassa non è un’ipotesi: è agli atti. Il rapporto del GAO - l’ufficio del Congresso americano che controlla i conti federali, già citato nel pezzo sulla migrazione - registra il caso delle dogane americane: a più di tre anni dal secondo tentativo di modernizzare il sistema, gli standard di qualità furono allentati e le fasi successive avviate nonostante i difetti noti; la correzione di quei difetti - annota il rapporto - avrebbe consumato persone e risorse a scapito dei rilasci successivi. È la definizione operativa del debito di collaudo: i difetti che si lasciano passare per tenere la data non spariscono, si spostano avanti, e chi doveva costruire il rilascio due passa il tempo a correggere il rilascio uno. Con gli interessi: un difetto scoperto in produzione costa la correzione, più i dati sporchi che ha prodotto, più la fiducia che ha bruciato - e il pezzo sulla migrazione ha già raccontato quanto vale quella fiducia, con la storia della prima stampa sbagliata arrivata al cliente.

Lo stesso rapporto riporta il caso gemello, più secco: il Dipartimento dei trasporti passò al sistema contabile nuovo, e il sistema non sapeva contabilizzare i rimborsi attesi dai beneficiari dei finanziamenti, per oltre seicento milioni di dollari. Un processo non provato è una domanda senza risposta, e la risposta arriva comunque, solo che arriva in produzione.

I test cominciano col progetto

I test non sono una fase in fondo: i casi di prova si scrivono dai requisiti, e le procedure si provano man mano che sono pronte.

Il modo più efficace per difendere il blocco finale è alleggerirlo: i test non sono una fase, sono un lavoro che accompagna tutto il progetto. Lo dice il principio più citato della disciplina, che il syllabus ISTQB - il programma aperto dell’organismo internazionale che certifica chi collauda il software - enuncia così: «il collaudo anticipato fa risparmiare tempo e denaro». I difetti rimossi presto non generano difetti derivati, e le prove dovrebbero cominciare il prima possibile. Lo dice anche l’appendice sui processi disciplinati del rapporto GAO: i casi di prova scritti presto, a partire dai requisiti, scovano errori, omissioni e ambiguità molto prima che il sistema sia configurato, e scoprire i difetti prima del collaudo finale fa risparmiare quantità enormi di tempo.

In pratica sono due abitudini. Ogni requisito mappato - la copertura è uno dei sette mestieri della direzione IT - porta con sé la sua domanda di collaudo, «come verificheremo che funzioni?», e conviene scriverla subito, quando il requisito è fresco. E man mano che le procedure configurate si rendono pronte, i key user le provano: direttamente, o coordinando i colleghi del reparto. Chi prova strada facendo non azzera il blocco finale - il test di processo e quello di carico esigono comunque il loro momento - ma ci arriva coi difetti grossi già trovati quando correggerli costava poco, e con un collaudo finale che conferma invece di scoprire.

La catena dei test

Ogni tipo di test risponde a una domanda, e nessuno risponde a quella di un altro.

«Fare i test» è un’espressione che nasconde mestieri diversi. Conviene scomporla: ogni anello della catena risponde a una domanda precisa, e saltarne uno lascia quella domanda - solo quella, ma tutta - senza risposta.

La tabella chiede tre chiarimenti. Il test di processo è quello che l’aneddoto d’apertura ha visto mancare: ordini, spedizioni e fatture funzionavano ciascuno per sé, era il filo fra loro a non essere mai stato percorso; provare le funzioni una a una non prova il processo, come collaudare i gradini non collauda la scala. Il test utente - la sigla di mestiere è UAT, User Acceptance Test, il collaudo di accettazione - è l’unico in cui il sistema viene usato da chi ci lavorerà, sui casi del reparto, e la sua firma è quella che conta. E il test di carico risponde a una domanda che nessun altro anello vede: il sistema vuoto di domenica mattina è sempre veloce; la chiusura mensile con tutti collegati è un’altra cosa, e conviene scoprirlo prima.

Il piano dei test e il suo pannello

Un calendario che copre il ciclo attivo e quello passivo, condiviso da uffici, direzione e fornitore, con un pannello visibile a tutti.

Un collaudo così - anticipato, a catena, fra reparti - non si coordina a voce. Il primo strumento è il piano dei test: chi prova che cosa, quando, su quali dati. La sua misura di completezza è il giro intero dell’azienda: il ciclo passivo (dall’ordine d’acquisto all’entrata merce, alla fattura del fornitore, al pagamento) e il ciclo attivo (dall’ordine del cliente al confezionamento, alla spedizione, alla fattura, all’incasso), con la produzione in mezzo a legarli, perché senza materie in magazzino non si produce. Un piano che percorre i due cicli per intero è completo; una lista di prove sparse è una lista di funzioni. E poiché impegna il tempo prenotato dei reparti, il piano non è un documento del progetto: è un calendario dell’azienda, e si condivide con tutti gli uffici e con la direzione.

Il secondo strumento è il pannello di avanzamento: le prove eseguite e superate contro quelle previste, e i difetti aperti, ognuno con la gravità e lo stato - aperto, in correzione, da riprovare, chiuso. E il pannello parla per numeri: pochi KPI (Key Performance Indicator, gli indicatori chiave) capaci di dire giorno per giorno lo stato di salute del collaudo, non solo la sua attività. Quattro esempi:

• l’avanzamento delle prove: eseguite e superate contro le pianificate a oggi; se il pianificato corre e l’eseguito no, la settimana sta già slittando;
• il saldo dei difetti: aperti contro chiusi, giorno per giorno e per gravità; se la curva dei nuovi non scende mentre il go-live si avvicina, il sistema non sta maturando;
• l’età dei bloccanti: da quanti giorni i difetti che fermano un processo aspettano la correzione; misura la reattività del fornitore prima che la misuri il calendario;
• la copertura dei cicli: quanta parte del ciclo attivo e del passivo è stata percorsa e firmata; misura la completezza, che è un’altra cosa dall’operosità.

Non è un’invenzione di questo blog: il registro sistematico dei difetti, con origine, data e stato, è fra le pratiche del collaudo disciplinato nell’appendice del rapporto GAO, e il syllabus ISTQB elenca proprio queste famiglie di metriche - avanzamento delle prove, difetti trovati e corretti, copertura dei requisiti - e i cruscotti fra i mezzi per comunicare lo stato dei test, con rapporti regolari a chi ha interesse nel progetto e un processo dei difetti seguito da tutti i soggetti coinvolti. Il punto organizzativo è la visibilità: il pannello lo vedono la direzione e tutti i key user, perché i tempi e le responsabilità si condividono solo se si vedono - un ritardo visibile lunedì si recupera, uno scoperto a fine mese no.

La visibilità serve soprattutto alla staffetta fra reparti. I due cicli attraversano gli uffici in sequenza: senza un’entrata merce registrata la produzione non può provare, senza un ordine inserito non si confeziona né si spedisce, senza spedizione non si fattura. Il test di processo eredita queste dipendenze, e il coordinamento dei key user è doppio: funzionale, chi prepara che cosa per chi, e temporale, in quale ordine ed entro quando. Se il key user del magazzino non carica l’entrata merce lunedì, la produzione non prova martedì e la contabilità non fattura giovedì. È la parte più difficile del piano, e il pannello deve renderla evidente: chi aspetta chi, e da quando.

E la staffetta ha bisogno di un arbitro: la direzione. I momenti in cui serve sono due. Il primo è il conflitto fra le prove e le urgenze: l’azienda non si ferma per il progetto, e capiterà che il key user prenotato per i test serva d’improvviso al suo reparto - il cliente grosso, la chiusura, l’ispezione. Quella decisione non può prenderla né il reparto, che vedrebbe solo la sua urgenza, né il progetto, che vedrebbe solo il suo calendario: la prende la direzione, che vede le due poste insieme - è la sponsorship del pezzo sulle persone, con la delega esercitata sul calendario. E chi cede una finestra deve farlo sapendo, dal pannello, che sta spostando la catena intera, non un appuntamento.

Il secondo momento è la puntualità reciproca. Nella staffetta il ritardo di uno ricade sugli altri, ma nessun reparto è naturalmente motivato a essere puntuale per conto di un altro: la puntualità fra uffici è un impegno che solo la direzione può chiedere e sostenere, reparto per reparto, col pannello a renderla misurabile. Senza questo presidio, ogni ritardo trova una buona ragione locale, e la somma delle buone ragioni è la compressione dei test vista all’inizio.

L’ultimo posto a tavola è del fornitore. Il partner che cura l’implementazione - l’integratore di sistema del pezzo sul TCO - ha in mano il calendario dei test, e quel calendario è fatto di disponibilità prenotate: le finestre in cui i key user sono stati liberati dal lavoro ordinario. Per questo le sue consegne verso le date concordate - concordate anche con lui - meritano un impegno speciale, scritto insieme al resto del contratto: una consegna che slitta non brucia giorni di progetto, brucia finestre prenotate che i reparti non restituiranno. Non a caso, fra le correzioni di rotta tipiche del controllo dei test, il syllabus ISTQB elenca proprio la riprogrammazione dovuta al ritardo nella consegna dell’ambiente di prova: è l’incidente da prevenire con l’impegno, non da amministrare dopo.

I dati di prova

Si prova sui dati veri, migrati: dieci anagrafiche di fantasia non fanno un collaudo.

Un test vale quanto i dati su cui gira. Dieci anagrafiche inventate e tre articoli di prova non fanno inciampare nessun processo: sono i dati di prova veri - le anagrafiche migrate, i saldi, i documenti aperti, con le loro eccezioni accumulate in anni - a far emergere i difetti che poi si presenterebbero in produzione. È l’aggancio tecnico col pezzo sulla migrazione: ogni migrazione di prova produce un ambiente pieno di dati veri, ed è lì che la catena dei test ha senso, non nel sistema dimostrativo del fornitore. Gli scenari, a loro volta, vengono dai casi propri: la chiusura contabile del mese, l’ordine col cliente in blocco, il reso della scatola da sei - gli stessi casi che hanno messo alla prova i sistemi candidati nella selezione, arrivati al collaudo.

Chi testa, e chi firma

I key user col tempo prenotato, e la regola che chi costruisce non collauda il proprio lavoro.

Il pezzo sulle persone ha già presentato chi tiene in mano il collaudo: i key user, col tempo prenotato e non ritagliato, perché il test fatto «quando si può» è il primo candidato alla compressione del calendario. Qui va aggiunta una regola sola, vecchia quanto il mestiere: chi ha configurato non collauda il proprio lavoro. Non per sfiducia, ma perché chi ha costruito una soluzione la esercita come l’ha pensata, e i difetti stanno quasi tutti fuori da quel sentiero: nelle eccezioni, nei casi strani, nell’uso che nessuno aveva previsto. Il consulente dimostra; il reparto prova. Sono due verbi diversi, e il secondo trova ciò che il primo non cerca.

Il criterio di uscita

Si parte quando i numeri dichiarati prima lo dicono, e lo firma un nome.

Resta la domanda che decide tutto: quando i test sono «finiti»? Senza una risposta scritta prima, la risposta la darà il calendario - cioè l’errore che questo pezzo racconta. La risposta di mestiere ha tre parti. I difetti si classificano per gravità: bloccanti (il processo non si chiude), gravi (si chiude con un rimedio manuale), minori (si conviva). Le soglie si dichiarano prima di cominciare: si parte con zero bloccanti e con un tetto dichiarato di gravi, ognuno col suo piano di rientro; deciderlo a test in corso, sotto la pressione della data, riporta all’asticella abbassata delle dogane viste sopra. E la firma ha un nome e un cognome: chi dichiara che si parte se ne assume la responsabilità, con la delega effettiva del pezzo sulla pianificazione - perché una partenza che non firma nessuno è una partenza che hanno deciso tutti, cioè nessuno.

Il lettore della serie riconosce la figura: è il criterio di uscita che questo sito ha già incontrato parlando degli agenti AI, e che il pezzo sulla migrazione ha applicato ai dati con la quadratura. Nei test la stessa idea - la soglia si dichiara prima, la firma ha un nome - si applica alla qualità del sistema intero.

Dove prosegue la serie

Provato tutto, si accende: resta il go-live, e il dopo.

L’errore quinto era lasciare che il calendario decidesse la qualità. Non succede quando i test cominciano col progetto e accompagnano ogni procedura pronta, quando la catena è completa con una domanda per anello, quando il piano percorre i cicli dell’azienda con un pannello che direzione, key user e fornitore vedono insieme, quando i dati sono veri e il tempo è prenotato, e quando il criterio di uscita è dichiarato prima e firmato da un nome. Resta l’ultimo errore, e l’ultimo pezzo: il go-live trattato come un traguardo invece che come una partenza, e il presidio dei primi giorni.

I concetti che questo articolo introduce

Sei voci nuove sull’ambito ERP, e l’aggancio trasversale al criterio di uscita.

---

Fonti

• U.S. Government Accountability Office, Financial Management Systems: Additional Efforts Needed to Address Key Causes of Modernization Failures, GAO-06-184, marzo 2006 - il caso delle dogane americane: standard di qualità allentati e fasi avviate nonostante i difetti noti, con le correzioni destinate a consumare persone e risorse a scapito dei rilasci successivi; e il caso del Dipartimento dei trasporti, passato a un sistema contabile che non sapeva contabilizzare rimborsi attesi per oltre seicento milioni di dollari. Nell’appendice sui processi disciplinati, le pratiche qui riprese: i casi di prova scritti presto, dai requisiti, che scovano errori prima che il sistema sia configurato; il registro sistematico dei difetti con origine, data e stato; le prove delle interfacce da un capo all’altro.
• ISTQB, Certified Tester Foundation Level Syllabus, v4.0.1, 2024, PDF aperto - il programma dell’organismo internazionale di certificazione del collaudo: il principio del collaudo anticipato, le metriche e i rapporti regolari di avanzamento, i cruscotti fra i mezzi per comunicare lo stato dei test, il processo dei difetti dalla scoperta alla chiusura seguito da tutti i soggetti coinvolti, e la riprogrammazione per ritardi di consegna dell’ambiente di prova fra le correzioni tipiche del controllo dei test.
• La catena dei test, la staffetta fra reparti lungo i cicli attivo e passivo, l’arbitrato della direzione fra le prove e le urgenze e sulla puntualità reciproca, l’impegno del fornitore sulle date concordate, la regola che chi costruisce non collauda il proprio lavoro, la classificazione dei difetti e le soglie del criterio di uscita vengono dall’esperienza diretta di progetto di chi scrive, e come tali vanno lette.