Il sito usa solo cookie tecnici necessari al funzionamento: nessun tracciamento, nessuna profilazione. Cookie Policy

Salta al contenuto
Tutti i termini

Cos'è la fallacia dei costi sommersi?

Continuare a investire in un progetto per la spesa già fatta invece che per il valore che può ancora produrre.

La fallacia dei costi sommersi è l'errore di decisione per cui si continua a investire in un progetto perché ci si è già investito molto, invece di valutarlo per il risultato che può ancora produrre. Il costo sommerso è la spesa già sostenuta e non più recuperabile, e per definizione non cambia in base a quello che si decide oggi: non è un dato della decisione. Nel software aziendale è il bias che tiene in vita un progetto fallito: un gestionale su misura che dopo due anni non copre il ciclo dell'ordine, un modulo di ERP che nessuno apre e che continua a comparire in fattura. La domanda che la fallacia sostituisce, e che è l'unica utile, non è quanto ho speso, ma quanto mi costa ancora arrivare al risultato e quanto costerebbe ottenerlo per un'altra strada.

Cosa mettere al posto della spesa passata

Il riferimento accademico è l'articolo di Hal R. Arkes e Catherine Blumer, "The Psychology of Sunk Cost", pubblicato nel 1985 su Organizational Behavior and Human Decision Processes (vol. 35, pp. 124-140). Gli autori definiscono il costo sommerso come denaro, tempo o fatica già investiti, e mostrano su una serie di esperimenti che aver pagato aumenta la tendenza a proseguire. La spiegazione che l'evidenza sostiene è il desiderio di non apparire spreconi; chi aveva sostenuto il costo sopravvalutava anche le probabilità di riuscita, ma quell'ottimismo non basta da solo a spiegare l'effetto: in uno studio sul campo, chi aveva pagato di più un abbonamento teatrale è andato a più spettacoli nei sei mesi seguenti. L'analogia con il Concorde, da cui il secondo nome, è di Richard Dawkins e Tamsin R. Carlisle su Nature nel 1976, contro l'idea che un genitore animale investa in base a quanto ha già investito: il velivolo anglo-francese fu finanziato oltre ogni previsione perché ci si era già speso troppo per fermarsi.

Il criterio è facile da enunciare e scomodo da applicare, e le opzioni da confrontare sono tre, nessuna delle quali guarda alla spesa fatta: completare sulla base attuale, rifare da un'altra base, fermarsi. Vince quella col maggior valore atteso da oggi in avanti, dove il valore del risultato pesa quanto il costo per ottenerlo: se il beneficio residuo non copre il costo residuo, fermarsi vince anche quando completare è la strada più economica. È il conto del business case, purché rifatto da oggi, sul percorso che resta: vedi business case e ROI dell'AI.

Un esempio concreto

Il caso tipico è una PMI di distribuzione che commissiona un gestionale su misura a una software house e in due anni arriva a spendere sull'ordine degli 80.000 euro. Il modulo ordini funziona, quello di magazzino no, la contabilità gira ancora su fogli di calcolo. La domanda che arriva in riunione, se buttare tutto, riformulata bene diventa: quanto costa completare il magazzino sulla base attuale, quanto portare il solo modulo ordini su una base nuova, e quanta parte del codice è debito tecnico che renderà ogni intervento più caro del preventivo. Spesso la risposta non è né buttare né insistere: è conservare la parte che regge e sostituire il resto per pezzi, come nello strangler fig pattern.

Perché conta, e quando insistere è la scelta giusta

Un progetto in ritardo non è per questo da chiudere: se la causa è nota e già risolta, e il costo residuo resta inferiore all'alternativa, insistere è razionale. "Taglia le perdite" preso come dogma distrugge valore quanto il bias opposto: ogni progetto serio attraversa un tratto in cui è più speso che finito. Il segnale non è la fatica, ma l'assenza di apprendimento: se a ogni ciclo la stima di completamento cresce e nessuno sa dire perché, quel denaro sta ancora affondando. Qui il criterio incrocia il recinto di Chesterton, che sembra dire l'opposto: non rimuovere ciò di cui non capisci lo scopo. Si conciliano perché nessuna delle due decide in base a quanto è costato. Chesterton guarda al passato solo per un fine preciso, sapere quale rischio quella cosa stia ancora coprendo oggi; il costo sommerso vieta di usare il passato come titolo di credito. Una chiede a cosa serve, l'altra quanto renderà.

  • Recinto di Chesterton · Non rimuovere una regola oscura del codice finché non hai capito, con prove, perché era stata messa lì.
  • Debito tecnico · La metafora di Ward Cunningham: ogni scorciatoia nel codice è un prestito, e gli interessi si pagano a ogni modifica successiva.
  • Business case e ROI dell'AI · Il metodo per stimare il ritorno di un progetto AI con tre scenari espliciti, contando i costi che di solito restano fuori.
  • Strangler fig pattern · Sostituire un sistema legacy per gradi, instradando il traffico verso il nuovo finché il vecchio non serve più.
  • "Se non puoi misurarlo, non puoi migliorarlo" · La massima circola troncata a metà: Deming la citava per definirla un mito costoso, non per sostenerla.

Un termine che ti riguarda da vicino? Parliamone.

CONTATTAMI