Tema

ERPdi

Errori nei progetti ERP: scegliere al ribasso senza guardare il reale costo totale

Ho guidato squadre di selezione che hanno scartato l’offerta più economica del tavolo. Sulla carta vinceva: licenze a metà prezzo, tempi più corti, un integratore volenteroso. Poi abbiamo messo in colonna i costi dei dieci anni successivi, formazione, manutenzione, aggiornamenti, personalizzazioni, e la soluzione conveniente è risultata la più cara della rosa. Nessuno ci aveva mentito: semplicemente, il prezzo raccontava la prima riga di un conto lungo una pagina.

Questo è il secondo dei sei errori di questa serie sui progetti ERP, e viene subito dopo la pianificazione perché è lì che si prepara: chi arriva alla scelta senza un perimetro e senza requisiti firmati può confrontare le offerte solo sull’unica colonna che tutte dichiarano, il prezzo.

Il prezzo è solo la prima riga del conto

Il costo totale di possesso si misura sul ciclo di vita, non alla firma.

Lo strumento per non farsi ingannare esiste da decenni e ha un nome: il costo totale di possesso (TCO, Total Cost of Ownership), cioè la somma di tutti i costi, diretti e indiretti, che il sistema genera lungo il suo ciclo di vita: dalla realizzazione all’esercizio quotidiano, fino alla sostituzione. Il concetto nasce negli studi Gartner alla fine degli anni Ottanta, e il bollettino di ricerca EDUCAUSE che lo applica ai progetti ERP lo riassume in una frase da tenere sul tavolo il giorno della firma: il prezzo d’acquisto è solo l’inizio, i soldi veri stanno nei costi del ciclo di vita.

L’orizzonte del calcolo va dichiarato, perché cambia il verdetto. La prassi registrata dal bollettino simula su tre-cinque anni; un ERP però vive dieci-quindici, come ricorda il pezzo sulla pianificazione. Un sistema che costa poco nei primi tre anni e caro nei dieci successivi vince tutte le gare calcolate corte. La scelta onesta è misurare sull’intera vita attesa del sistema, e scrivere nel modello quale vita ci si aspetta.

Il picco su cui si negozia Qui sta il grosso del conto Costi Tempo Acquisizione Esercizio e manutenzione Sostituzione
L'andamento dei costi lungo il ciclo di vita, ridisegnato dalla Figura 1 del bollettino EDUCAUSE citato in fondo: assi qualitativi, nessuna scala. Il picco iniziale è quello su cui si negozia per mesi; il baricentro del conto sta nella lunga salita di esercizio e manutenzione.

Il caso meglio documentato al mondo è pubblico, e conferma la posta in gioco. La Corte dei conti americana (GAO) ha esaminato nel 2010 i nove ERP critici della Difesa: sei in ritardo da due a dodici anni, cinque con aumenti fra 530 milioni e 2,4 miliardi di dollari ciascuno. Tredici anni dopo, il suo aggiornamento sui 24 programmi gestionali della stessa amministrazione racconta la stessa musica: oltre la metà con variazioni di costi o di tempi in un solo anno. E il dettaglio più istruttivo per questo articolo: i ritardi obbligano a pagare più a lungo i sistemi vecchi che l’ERP doveva sostituire, una voce del ciclo di vita che nessun prezzo d’acquisto aveva raccontato.

I due rapporti dicono anche perché, e qui diventano un manuale. Nel 2010 il GAO scrisse che la Difesa sapeva quanto spendeva e quanto tardava, ma non aveva definito né una nozione di successo né le misure per dire se i sistemi consegnassero le capacità per cui erano nati: il controllo guardava costi e tempi, non risultati. È l’assenza del criterio di uscita, vista da un bilancio federale. Nel 2023 le cause dichiarate suonano familiari: l’aumento più grosso, 815 milioni di dollari in un anno su un solo sistema, è attribuito a «capacità aggiunte», cioè alla deriva del perimetro; il ritardo più lungo, quattro anni, all’estensione del sistema ad altre organizzazioni; fra le ragioni restanti, i prezzi dei fornitori e le difficoltà di migrazione al cloud. Dopo più di trent’anni di tentativi, scrive il GAO, i problemi sono gli stessi: i nomi delle cause sono i capitoli di questa serie.

Le voci del conto, una per una

La tabella che il fornitore non porta alla prima riunione.

Il costo totale di possesso smette di essere una predica quando diventa un elenco. Il ciclo di vita ha cinque stagioni: acquisizione, realizzazione, esercizio, manutenzione e sostituzione. Il bollettino EDUCAUSE indica dove sta il baricentro: la parte più grossa del conto si concentra nell’esercizio e nella manutenzione, non nell’acquisto su cui si negozia per mesi. Queste sono le voci, con il momento in cui si pagano e il posto dove amano nascondersi. E un tratto del ciclo va contato a parte: durante la realizzazione i sistemi sono due, il vecchio che lavora e si paga, il nuovo che nasce e si paga, e ogni mese di ritardo allunga il doppio binario. È il meccanismo che il GAO ha messo a verbale per la Difesa americana, dove i ritardi degli ERP hanno tenuto in vita i sistemi vecchi molto oltre le previsioni.

La voce Quando si paga Dove si nasconde
Licenze o canone Alla firma, poi ogni anno Nei modelli a consumo: il prezzo cresce con gli utenti e i volumi che oggi non avete
Realizzazione Durante il progetto Nelle giornate dell’integratore oltre il preventivo, quando i requisiti erano vaghi
Infrastruttura All’avvio, poi a ogni crescita Nei requisiti minimi «consigliati», sempre più alti di quelli scritti in offerta
Formazione Prima del lancio, poi a ogni assunzione Nel presupposto che basti una sessione: la formazione è un flusso che si regge sui key user, come racconta il pezzo sulle persone lasciate all’oscuro
Il tempo delle vostre persone Per tutto il progetto, e nei primi mesi dopo In nessuna fattura: distacchi da coprire, produttività che cala durante il cambio, ore dei key user fra prove e supporto
Manutenzione e assistenza Ogni anno, per sempre Nei canoni che si rivalutano e nelle fasce di assistenza: quella inclusa risponde domani
Aggiornamenti A ogni versione Nel lavoro di riprova di tutto ciò che è stato personalizzato
Personalizzazioni Quando si fanno, e poi a ogni aggiornamento È la voce moltiplicatrice: una sezione più sotto è tutta per lei
Integrazioni con sistemi di terzi Durante il progetto, poi a ogni cambio di uno dei due lati In ogni interfaccia, che è un contratto fra due programmi da mantenere; il caso peggiore sono le procedure ombra, più sotto
Crescita e nuovi paesi A ogni espansione Nelle localizzazioni e nei moduli che il listino chiama «aggiuntivi»
Il non pianificato (la deriva) Quando emerge, sempre in emergenza Ovunque il lavoro a monte è mancato: procedure ombra, processi valutati male, cambiamento non gestito
Uscita Alla fine, tutta insieme Da nessuna parte: non compare in nessuna offerta, e ha la sua sezione più sotto

La tabella mescola due nature che il bollettino distingue: i costi diretti, quelli che arrivano in fattura e si mettono a bilancio, e i costi indiretti, il tempo delle persone, la produttività che cala, i fermi. I secondi sono i più difficili da finanziare e i più sottovalutati, e la fonte indica dove si annidano quasi tutti: nella formazione e nel supporto a chi usa il sistema. Un modello che conta solo le fatture sta contando la metà visibile del conto.

Un modello di costo totale è questa tabella con i numeri della vostra azienda dentro, proiettata sull’orizzonte dichiarato. Non serve che sia precisa al centesimo: serve che nessuna riga sia vuota, perché ogni riga vuota è una sorpresa prenotata.

La penultima riga merita una spiegazione, perché è diversa dalle altre: il non pianificato non si preventiva, si riserva. È il costo delle funzionalità che emergono a progetto avviato, e ha tre sorgenti che questa serie conosce per nome: le procedure ombra che nessun censimento ha dichiarato, i processi aziendali valutati male alla raccolta dei requisiti, e il cambiamento non gestito che si ripresenta come richieste di modifica quando le persone incontrano il sistema. Il modo onesto di metterla nel modello è una riserva dichiarata, dimensionata su quanto bene è stato fatto il lavoro di pianificazione: chi ha censito coi reparti e aperto presto i cantieri del cambiamento può tenerla stretta; chi ha raccolto i requisiti in sala riunioni farà bene a tenerla larga. Le «capacità aggiunte» degli 815 milioni del GAO sono questa riga, vista a consuntivo da chi non l’aveva scritta.

In conto capitale o ricorrenti: la seconda lettura del modello

Le stesse voci, rilette con l’amministrazione al tavolo: cosa si ammortizza e cosa pesa ogni anno.

Il modello di costo ha una seconda lettura, e l’amministrazione ve la chiederà comunque: quali voci sono investimento in conto capitale, che si ammortizza su più esercizi, e quali sono costi ricorrenti, che pesano sul conto economico di ogni anno, per sempre. Le due nature raccontano lo stesso progetto in due modi diversi, e una scelta può sembrare conveniente in una lettura e cara nell’altra.

La voce Di norma L’attenzione
Licenze o canone Mista: la licenza perpetua è capitale, il canone è ricorrente È la stessa riga che separa comprare e abbonarsi: le due forme non si confrontano senza questa lettura
Realizzazione Capitale Gli oneri di progetto si ammortizzano col sistema; le giornate oltre il preventivo finiscono qui, e gonfiano l’investimento
Infrastruttura Mista: di proprietà è capitale, a noleggio o in cloud è ricorrente Il passaggio al cloud sposta questa riga di colonna, e il bilancio se ne accorge
Formazione Ricorrente Quella iniziale a volte si tratta come onere del progetto: lo decide l’amministrazione, non l’entusiasmo
Il tempo delle vostre persone Ricorrente La parte dedicata alla costruzione può essere capitalizzabile; il resto pesa sull’anno in cui matura, cioè sempre
Manutenzione e assistenza Ricorrente Nessun ammortamento la diluisce: si vede tutta, ogni anno
Aggiornamenti Ricorrente Il grande passaggio di versione trattato come progetto fa eccezione, e torna capitale
Personalizzazioni Mista: lo sviluppo si può capitalizzare, la riprova a ogni versione no La voce va spezzata nelle due metà, sennò il modello mente in una delle due letture
Integrazioni con sistemi di terzi Mista: la costruzione è capitale, il mantenimento è ricorrente Ogni interfaccia porta le due nature insieme, per tutta la vita dei due lati
Crescita e nuovi paesi Mista: l’estensione è un progetto, le sue ricadute sono ricorrenti Ogni paese nuovo riapre in piccolo tutte le righe di questa tabella
Il non pianificato (la deriva) Mista per definizione: prende la natura di ciò che emerge La riserva si stanzia a bilancio come ciò che copre; una deriva senza riserva si finanzia da sola, mangiando le altre righe
Uscita Ricorrente, quando matura Si paga tutta nell’anno in cui arriva, di solito insieme all’investimento nel sistema successivo

La classificazione precisa dipende dai principi contabili applicabili e la firma l’amministrazione, non il progetto: la regola pratica è costruire il modello con lei al tavolo fin dall’inizio. E questa lettura spiega anche una parte del fascino del cloud presso chi guarda i bilanci: sposta quasi tutto nel ricorrente, niente investimento da ammortizzare, un canone che entra nel conto economico da subito e per sempre. La sezione seguente dice a quali condizioni lo scambio conviene davvero.

Comprare o abbonarsi: il conto cambia forma

Il canone ingloba voci intere della tabella, e le trasforma in un costo perpetuo.

Gran parte degli ERP oggi si vende in cloud, a canone. La tabella qui sopra non si accorcia: cambia forma. Infrastruttura e aggiornamenti spariscono come voci vostre e rientrano dentro il canone, insieme a una parte dell’assistenza; in cambio, il costo diventa perpetuo e cresce con utenti e volumi, e il potere negoziale si sposta verso chi ospita, perché i dati vivono da lui. Chi legge la serie sugli agenti AI di questo blog riconosce la coppia: il pezzo su chi paga il conto degli agenti mette a confronto costo a consumo e costo di possesso per i modelli linguistici, con la stessa morale. Nessuna delle due forme vince in assoluto: vince quella che il vostro modello di costo totale, calcolato sull’orizzonte dichiarato, mostra più conveniente per i vostri volumi. Il canone basso del primo anno è il prezzo iniziale travestito da rata.

Comprare Abbonarsi Costo cumulato Tempo Il punto di pareggio
Schema qualitativo, senza scala: comprare parte alto e sale piano, abbonarsi parte basso e non smette di salire. Dove cada il punto di pareggio dipende dai vostri numeri; l'errore è confrontare le due curve solo nel primo tratto.

Il canone porta con sé anche un obbligo che il listino non evidenzia: in cloud gli aggiornamenti li decide il fornitore. Le versioni nuove arrivano a calendario suo, spesso con finestre obbligatorie, e ogni arrivo impone la riprova di ciò che è stato personalizzato o esteso, nei tempi del fornitore e non nei vostri. Il costo è organizzativo prima che tecnico: i key user che devono provare sono le stesse persone che mandano avanti i reparti, e la loro disponibilità non segue il calendario di rilascio di nessun fornitore. Chi valuta un sistema in cloud mette nel modello anche questo: quante versioni l’anno, con quanto preavviso, con quale finestra di prova, e chi la coprirà.

La leva principale: quante modifiche al software di base

Ogni personalizzazione si paga tre volte: quando si fa, a ogni aggiornamento, all’uscita.

Se il costo totale ha una manopola, è questa. Il bollettino EDUCAUSE la indica come il mezzo principale per controllare il conto: limitare il numero e la profondità delle modifiche al software di base, tracciando la linea all’inizio del progetto e rivedendola solo in circostanze estreme. La personalizzazione del software di base è la modifica al comportamento standard del sistema, e si paga tre volte: quando si scrive, a ogni aggiornamento che la costringe alla riprova, e all’uscita, quando qualcuno dovrà capire cosa faceva per rifarla altrove.

La stessa fonte aggiunge il rovescio, meno gradito: l’azienda deve essere pronta a modificare le proprie pratiche per stare dentro il comportamento standard, e rimandare questo adeguamento fa solo crescere il conto nel tempo. Quando il processo è davvero distintivo, la personalizzazione si difende in una riga di motivazione; quando il processo è uguale a quello di chiunque altro, si sta adattando il sistema a un’abitudine.

Gli interventi sul sistema non sono tutti uguali, e distinguerli è metà del controllo del conto. La configurazione adatta il sistema dentro i parametri che il prodotto prevede: costa il lavoro di capire, e sopravvive agli aggiornamenti. L’estensione aggiunge funzioni fuori dal nucleo, attraverso le interfacce che il prodotto espone: costa sviluppo, ma il nucleo resta standard. La modifica del nucleo è la personalizzazione vera, quella che si paga tre volte, e nei sistemi in cloud è spesso vietata dal fornitore stesso: un divieto che è la miglior difesa del vostro conto, travestita da limite.

Qui pesa anche l’integratore di sistema incontrato in pianificazione: uno che conosce il vostro settore copre i requisiti configurando il prodotto, uno che non lo conosce riscrive. La differenza non si vede nell’offerta, dove le giornate si somigliano tutte; si vede al terzo anno, nel conto degli aggiornamenti. All’equilibrio fra adattare il sistema e adattare i processi è dedicato un approfondimento fuori serie, Personalizzare senza toccare il core.

Le integrazioni con i sistemi di terzi

Ogni azienda è un concerto di sistemi: per ognuno si decide all’inizio se integrarlo o sostituirlo.

Nessun ERP lavora da solo. In ogni azienda collaborano più sistemi: la gestione dei clienti, le macchine e i programmi di reparto, la banca, il commercio in rete, la logistica dei corrieri. Il sistema nuovo entra in questo concerto, e per ogni sistema esistente la decisione va presa all’inizio, non scoperta strada facendo: si integra o si sostituisce. Entrambe le risposte hanno un prezzo che il modello deve contenere. La sostituzione sposta requisiti dentro il perimetro del progetto; ogni integrazione con sistemi di terzi si paga invece due volte, quando si costruisce e a ogni cambio di uno dei due lati, perché un’interfaccia è un contratto fra due programmi e i contratti vanno mantenuti. Il censimento delle integrazioni, con la decisione presa per ogni sistema, è un prodotto della pianificazione e il pezzo che apre la serie gli dedica una sezione; la voce di costo sta qui.

Le procedure ombra

Gli strumenti nati ai margini del gestionale, che sfuggono anche ai censimenti fatti bene.

Dentro il capitolo delle integrazioni vive un caso a parte: le procedure nate negli anni ai margini del gestionale. La maschera in Access che prepara i flussi della tesoreria, il foglio di calcolo con cui il controllo di gestione costruisce il rapporto mensile nella forma esatta in cui il presidente lo vuole, o il foglio con cui si pianifica il lavoro di alcune linee di produzione, che compare come per magia una settimana prima del lancio. Nessuno le ha dichiarate perché nessuno le considera sistemi: sono «come abbiamo sempre fatto», e spesso chi le ha costruite non c’è più.

La loro esistenza non è un mistero della natura: è il sintomo di un lavoro non fatto. Emergono dove chi ha disegnato i processi non ha condotto le dovute interviste, o dove le persone che le gestiscono non sono state coinvolte dai loro responsabili: la stessa mancanza della pianificazione, i requisiti raccolti lontano da chi lavora e la delega rimasta sulla carta, vista dal lato del conto.

Si scoprono nel momento peggiore: il sistema nuovo è in linea, e la funzionalità che «era ovvio che dovesse avere» non c’è. Senza quella maschera l’azienda non manda i pagamenti; senza quel foglio il rapporto per il presidente esce in una forma che il presidente non riconosce. A quel punto la procedura ombra è diventata strategica per decreto dei fatti, e va rifatta in emergenza: come integrazione da costruire o come personalizzazione, ai prezzi dell’emergenza. Il rimedio è la domanda in più da fare in ogni reparto durante il censimento: non solo «cosa fa il sistema per voi», ma «cosa gli gira intorno», quali file, quali maschere, quali passaggi a mano prendono i suoi dati o glieli danno.

La scalabilità è una voce del conto

La crescita che non è stata prezzata si paga due volte: nei moduli aggiuntivi o nel ricomprare tutto.

Un sistema si sceglie per l’azienda che si sarà, non solo per quella che si è. La crescita dei volumi e degli utenti sta già nella tabella, dentro licenze e infrastruttura; la crescita che sfugge ai modelli è l’espansione: una nuova società nel gruppo, un nuovo paese. Ogni paese porta la sua localizzazione: lingua, norme fiscali, adempimenti, tracciati che le autorità vogliono in un modo preciso. Chi ha portato dodici società di paesi diversi su un sistema solo sa che le localizzazioni sono progetti dentro il progetto, altro che nota a piè di listino: un sistema che non le copre nel proprio catalogo le fa pagare come personalizzazioni, cioè tre volte. La domanda da fare alla selezione è secca: quali paesi copre il prodotto di suo, e quanto è costata l’ultima espansione a un cliente della nostra taglia. Un sistema che non regge la crescita prevista converte la scalabilità mancata in un costo di uscita anticipato: si ricompra tutto, prima del previsto.

La voce che nessuno mette a preventivo: l’uscita

Il vincolo al fornitore, trasformato in un numero.

Ogni sistema prima o poi si lascia. Il costo di uscita è quanto costa andarsene: riportare fuori i dati in una forma utilizzabile, riscrivere le integrazioni con gli altri sistemi, chiudere le licenze, rifare la formazione altrove. Nessuna offerta lo dichiara, e si capisce: è il prezzo che il fornitore incassa in potere negoziale ogni anno in cui uscire resta impensabile.

Questo blog ha già un nome per quel potere: il vincolo al fornitore, che il pezzo su chi paga il conto degli agenti racconta per i modelli linguistici. Il costo di uscita è quel concetto trasformato in un numero, e la domanda che lo fa emergere va posta prima della firma, quando negoziare è ancora possibile: quanto costa, fra cinque anni, portare via i nostri dati e i nostri processi? Un fornitore che risponde con un documento è un fornitore che prevede di tenervi per qualità. Uno che cambia discorso ha già risposto.

I cinque miti del costo totale

Li ha elencati chi ha inventato il costo totale di possesso, e l’ultimo - i costi che non arrivano in fattura non conterebbero - è quello che costa di più.

Bill Kirwin, l’analista Gartner che il costo totale di possesso l’ha inventato, ha elencato i miti che ne accompagnano l’uso. Sono cinque, e valgono da lista di controllo prima di ogni decisione:

Come si sceglie, in pratica

Un modello sul ciclo di vita, una prova su casi vostri, i reparti al tavolo.

Quattro mosse trasformano la selezione da asta al ribasso a decisione.

Il modello di costo totale si costruisce prima di chiedere le offerte, sull’orizzonte di vita dichiarato: così le offerte si versano in un modello vostro, invece di confrontare tabelle scritte da chi vende. La prova su casi propri va oltre la dimostrazione preparata dal fornitore: i vostri processi, i vostri dati, i vostri casi strani, con un criterio di riuscita scritto prima, come per ogni collaudo serio. I progetti consegnati del fornitore e dell’integratore contano più delle referenze dichiarate: cercate aziende del vostro settore e della vostra taglia, e parlate con chi il sistema lo usa da tre anni, non da tre mesi. I reparti che useranno il sistema siedono al tavolo della scelta: sono gli stessi che hanno firmato i requisiti in pianificazione, e vedono nelle dimostrazioni le cose che un comitato di direzione non può vedere.

Dove prosegue la serie

Scelto il sistema, arrivano i dati: è l’errore più sottovalutato di tutti.

Il prossimo pezzo entra nella migrazione dei dati, trattata quasi sempre da dettaglio tecnico del trasloco e capace da sola di screditare un sistema ben scelto. Vengono poi le persone, i test, e il giorno dopo il lancio. L’ordine di lettura della serie è dichiarato in fondo a ogni pezzo, e i concetti di ognuno alimentano la mappa che collega questa serie al resto del sito.

I concetti che questo articolo introduce

Nove voci nuove sull’ambito ERP, con due agganci al resto del grafo.

Concetto Ambito Che cos’è Si lega a
Costo totale di possesso (TCO, Total Cost of Ownership) erp La somma dei costi, diretti e indiretti, lungo il ciclo di vita del sistema: acquisto, realizzazione, infrastruttura, formazione, manutenzione, aggiornamenti, personalizzazioni, uscita il costo di possesso dei modelli AI ne è un caso particolare; si contrappone alla scelta sul solo prezzo iniziale
Personalizzazione del software di base erp La modifica al comportamento standard del sistema, con il suo seguito di riprova a ogni aggiornamento è la leva principale del costo totale di possesso; alimenta il vincolo al fornitore
Integratore di sistema erp Il partner che realizza il progetto; la sua esperienza di settore decide quanta strada si fa configurando prima di personalizzare la sua scelta pesa sul costo totale di possesso
Costo di uscita erp Quanto costa lasciare sistema e fornitore: dati da riportare fuori, integrazioni da riscrivere, licenze, formazione da rifare è la misura concreta del vincolo al fornitore; è la voce assente del costo totale di possesso
Prova su casi propri erp La verifica del sistema sui processi e sui dati dell’azienda, con un criterio di riuscita scritto prima, oltre la dimostrazione del fornitore smaschera prima della firma i costi di personalizzazione del software di base
Integrazione con sistemi di terzi erp Il collegamento dell’ERP agli altri sistemi dell’azienda; per ognuno la decisione iniziale è se integrarlo o sostituirlo, e ogni interfaccia è un contratto fra due programmi da mantenere si paga nel costo totale di possesso alla costruzione e a ogni cambio di uno dei due lati; il censimento sta nel perimetro del progetto
Procedura ombra erp Lo strumento nato ai margini del gestionale, mai dichiarato perché nessuno lo considera un sistema, che emerge quando il sistema nuovo non ne copre la funzione è il caso nascosto dell’integrazione con sistemi di terzi; emerge dove la raccolta dei requisiti non ha ascoltato chi lavora
Configurazione erp L’adattamento del sistema dentro i parametri che il prodotto prevede: sopravvive agli aggiornamenti si oppone alla personalizzazione del software di base; è il terreno dell’integratore di sistema esperto
Localizzazione erp L’adeguamento del sistema a lingua, norme fiscali e adempimenti di un paese pesa sul costo totale di possesso a ogni espansione; se manca dal catalogo diventa personalizzazione del software di base

Fonti