Business Process Reengineering:
le fonti e il 70%

Il Business Process Reengineering ha una data di nascita precisa, due testi fondatori che si possono citare parola per parola, due casi aziendali con i numeri dentro e una statistica di fallimento che gira da trent'anni senza che nessuno l'abbia mai misurata. Questo articolo tiene separate le quattro cose.

01Il 1990, il 1993 e le due definizioni

L'espressione entra nel vocabolario aziendale con un articolo di Michael Hammer sulla Harvard Business Review del numero di luglio-agosto 1990, alle pagine 104-112, intitolato Reengineering Work: Don't Automate, Obliterate. La frase che l'ha resa celebre sta nella quarta riga del testo:

It is time to stop paving the cow paths. Instead of embedding outdated processes in silicon and software, we should obliterate them and start over.

Michael Hammer, Harvard Business Review, luglio-agosto 1990

In italiano: è ora di smettere di asfaltare i sentieri delle mucche; invece di incastrare processi scaduti dentro al silicio e al software, cancelliamoli e ricominciamo. Poco più avanti Hammer dà la sua definizione di cosa ci sia sotto: «At the heart of reengineering is the notion of discontinuous thinking, of recognizing and breaking away from the outdated rules and fundamental assumptions that underlie operations».

La definizione canonica arriva tre anni dopo, nel libro di Hammer e James Champy, Reengineering the Corporation (1993), a pagina 32: «Reengineering is the fundamental rethinking and radical redesign of business processes to achieve dramatic improvements in critical contemporary measures of performance such as cost, quality, service and speed». Nella frase lavorano quattro parole: fundamental, radical, dramatic, processes. Le prime tre dicono quanto in profondità si scava, la quarta dice su che cosa: il flusso intero, non l'ufficio.

02Automatizzare e riprogettare: il caso Ford

La differenza fra le due cose Hammer la spiega con un esempio che nel 1990 era appena successo, e che resta il caso più citato della disciplina.

All'inizio degli anni Ottanta il reparto contabilità fornitori di Ford in Nord America occupava più di 500 persone. La direzione contava di ridurre gli organici «by some 20%» razionalizzando le procedure e installando nuovi sistemi informatici. Poi guardò Mazda: lo stesso reparto, là, era fatto di cinque persone. Anche correggendo per la differenza di dimensione, Ford calcolò di avere una contabilità fornitori cinque volte più grande del dovuto.

Il processo vecchio funzionava così: l'ufficio acquisti mandava copia dell'ordine alla contabilità, il magazzino mandava copia del documento di ricevimento, il fornitore mandava la fattura, e la contabilità doveva far quadrare i tre documenti su 14 dati. La maggior parte del tempo se ne andava sulle discordanze. Il processo nuovo, che Ford chiamò invoiceless processing, elimina la fattura: all'arrivo della merce il magazziniere controlla a schermo se corrisponde a un ordine aperto, e in caso affermativo il sistema confronta tre soli dati (codice articolo, unità di misura, codice fornitore) e prepara il pagamento.

Hammer riassume il salto in una regola riscritta: Ford lavorava sulla regola «We pay when we receive the invoice» e l'ha sostituita con «We pay when we receive the goods». Il risultato dichiarato nell'articolo: 75% di riduzione degli organici dove il nuovo processo è stato introdotto, contro il 20% che un programma convenzionale avrebbe dato.

La lezione operativa sta nella riga di mezzo. Nessun software avrebbe tolto quei 14 confronti, perché i 14 confronti erano la conseguenza di una regola che nessuno aveva mai messo per iscritto e che nessuno aveva mai discusso.

03Le cinque mosse, e da dove vengono

Hammer non lascia un metodo numerato, lascia due domande e un criterio. Le due domande: «The reengineering team must keep asking Why? and What if?». Il criterio: «Rather than looking for opportunities to improve the current process, the team should determine which of its steps really add value and search for new ways to achieve the result». Su questo si regge la sequenza che si usa in pratica.

1. Mappare il processo come funziona davvero, sui dati che i sistemi registrano e non sui racconti di chi lo esegue.
2. Misurare tempi, costi, errori e attese, per avere cifre da confrontare a fine progetto.
3. Interrogare ogni passaggio con le due domande di Hammer: perché esiste, e cosa succede se sparisce.
4. Ridisegnare partendo dal risultato e dalle tecnologie disponibili adesso.
5. Portare le persone dentro il modo nuovo di lavorare, che è la parte in cui il metodo è storicamente inciampato.

Il passaggio che nessuno guarda

L'esempio più utile dell'articolo del 1990 sta in tre righe. Le filiali regionali di una compagnia assicurativa della costa orientale producevano da anni una serie di rapporti che mandavano regolarmente alla sede: «No one in the field realized that these reports were simply filed and never used. The process outlasted the circumstances that had created the need for it». Il processo era sopravvissuto alla ragione che l'aveva creato, e chi lo eseguiva non aveva modo di saperlo.

Misurare l'attesa, non il lavoro

Hammer riporta la stima di una compagnia assicurativa sulle proprie pratiche: una domanda di polizza restava 22 giorni nel processo, e il lavoro effettivo su quella pratica era di 17 minuti. È il rapporto che il process mining oggi ricostruisce in automatico leggendo i registri di ERP e CRM, invece di stimarlo con le interviste. La domanda che quel rapporto apre riguarda i 22 giorni, non i 17 minuti: accelerare i 17 minuti con un software lascia il processo dov'è.

04Cosa cambia con l'AI, e i numeri italiani

Nel 2025 le imprese italiane con almeno dieci addetti che usano almeno una tecnologia di intelligenza artificiale sono il 16,4%, contro l'8,2% del 2024 e il 5,0% del 2023. Le grandi imprese stanno al 53,1%, le PMI al 15,7%, e il divario fra le due si allarga: circa 20 punti percentuali nel 2023, 25 nel 2024, 37 nel 2025 (Istat, Imprese e ICT 2025, 15 dicembre 2025).

Quali tecnologie, fra le imprese che ne usano almeno una:

La riga più eloquente del comunicato è un'altra. Fra le imprese che dichiarano di usare l'AI, la quota che non sa indicare nessun ambito aziendale in cui la usa è passata dal 15,5% del 2024 al 33,4% del 2025, ed è composta per l'83,3% da imprese fra 10 e 49 addetti. L'Istat la commenta come «un'adozione dell'IA sempre più diffusa ma ancora poco strutturata». Una tecnologia in casa senza un processo a cui sia attaccata è esattamente la condizione che il reengineering descriveva nel 1990, con il software al posto dell'AI.

Dove l'AI viene attaccata a un ambito, gli ambiti sono marketing e vendite (33,1%), organizzazione dei processi amministrativi (25,7%) e ricerca e sviluppo (20,0%), e sono anche i tre che crescono di più rispetto al 2024.

Le tecnologie del 1990 rendevano possibile togliere la fattura dal processo di Ford. Quelle del 2026 rendono possibile togliere la lettura manuale di un documento. In tutti e due i casi la domanda che precede è la stessa: quel passaggio deve esistere?

05Come si conduce un progetto, e i tempi che Hammer prometteva

Prima dei passi operativi ci sono tre scelte che decidono metà del risultato: su quale processo intervenire (impatto alto e complessità gestibile), chi siede nel gruppo di lavoro (chi conosce il processo insieme a chi conosce la tecnologia) e chi lo sponsorizza in direzione. Hammer chiedeva esplicitamente un gruppo composto dalle funzioni coinvolte nel processo e da tutte quelle che ne dipendono.

1. Ricognizione: registri dei sistemi, qualche intervista mirata, documenti.
2. Analisi: separare i passaggi che aggiungono valore da quelli che sono attesa o controllo doppio.
3. Ideazione: disegnare il processo ideale, per un primo giro senza vincoli tecnologici.
4. Prototipo: simulare gli scenari prima di spostare risorse vere.
5. Pilota: applicare su un perimetro dove sbagliare costa poco.
6. Estensione: allargare per gradi, con la formazione che accompagna.

Dopo l'estensione restano gli indicatori. Il confronto onesto si fa sulle stesse grandezze misurate nella fase 2, prima di toccare qualunque cosa: senza quella misura iniziale, il salto dichiarato alla fine è un numero senza termine di paragone. È la ragione per cui i due casi della sezione seguente si citano ancora dopo trentasei anni: hanno il prima e il dopo.

06Due casi con i numeri della fonte

Hammer porta due casi, e li porta con le cifre. Il primo è Ford, già visto: da oltre 500 persone in contabilità fornitori a un organico ridotto del 75%, con il confronto esplicito contro il 20% che avrebbe dato la strada dell'automazione.

Mutual Benefit Life, dai 25 giorni alle quattro ore

Il secondo è Mutual Benefit Life, all'epoca diciottesima compagnia vita degli Stati Uniti. Il processo di istruttoria di una domanda di assicurazione attraversava «as many as 30 discrete steps», 5 reparti e 19 persone. Nel caso migliore la pratica si chiudeva in 24 ore; il tempo tipico andava da 5 a 25 giorni, e la maggior parte se ne andava nel passaggio di carte da un reparto all'altro. Il presidente chiese un miglioramento di produttività del 60%.

La riprogettazione ha sostituito la catena con una figura sola, il case manager, che segue l'intera pratica appoggiandosi a una postazione collegata ai sistemi centrali e a un sistema esperto; i sottoscrittori e i medici intervengono come consulenti sui casi difficili, senza che il case manager perda il controllo della pratica. I numeri dopo, come li riporta Hammer: una domanda si chiude «in as little as four hours», il tempo medio scende a due-cinque giorni, sono state eliminate 100 posizioni nelle filiali e ogni case manager gestisce più del doppio delle pratiche di prima.

07Il 70% che nessuno ha misurato

Su qualunque presentazione di trasformazione digitale compare prima o poi la riga «il 70% dei progetti fallisce», spesso attribuita a Hammer. Vale la pena di guardare cosa Hammer e Champy hanno scritto davvero, perché è un'altra frase, a pagina 200 di Reengineering the Corporation:

Our unscientific estimate is that as many as 50 to 70 percent of the organizations that undertake a reengineering effort do not achieve the dramatic results they intended.

Hammer e Champy, Reengineering the Corporation, 1993, p. 200

Tre cose distinguono quella frase dalla citazione che circola. Gli autori la qualificano da sé come unscientific. È un intervallo da 50 a 70, e viene citato solo l'estremo alto. E dice che quelle organizzazioni «non ottengono i risultati drammatici che volevano», che descrive un obiettivo mancato e non un progetto fallito.

Gli stessi autori hanno provato a rimetterla a posto. In The Reengineering Revolution (1995), Hammer e Steven Stanton scrivono che l'osservazione era stata «widely misrepresented and transmogrified and distorted into a normative statement», e aggiungono: «There is no inherent success or failure rate for reengineering».

Nel 2011 Mark Hughes, dell'Università di Brighton, ha passato in rassegna cinque usi pubblicati della cifra del 70% e ha concluso: «whilst the existence of a popular narrative of 70 per cent organizational change failure is acknowledged, there is no valid and reliable empirical evidence to support such a narrative» (Journal of Change Management, volume 11, numero 4, 2011, pagine 451-464).

Quello che si può dire con una fonte in mano è quindi: un intervallo stimato a occhio dagli autori del metodo nel 1993, sconfessato da uno di loro nel 1995 e senza base empirica secondo la rassegna del 2011. Una cifra ripetuta per trent'anni senza misura dice più sul mestiere della consulenza che sui progetti di riprogettazione.

La critica arrivata da dentro

Nel 1995, sul numero di esordio di Fast Company, Thomas H. Davenport, uno degli autori del metodo, pubblica The Fad That Forgot People, in cui racconta come un'idea circoscritta si sia trasformata in una moda distruttiva. Kleiner, nel 2000, riporta questa sua frase: «The last thing that I would have ever imagined was that people would start losing their jobs because of some ideas that I was offering».

Gli errori che restano

• Automatizzare senza interrogare. È l'errore che dà il titolo all'articolo del 1990 e che dopo trentasei anni si commette con gli stessi movimenti, cambiando il nome della tecnologia.
• Partire dallo strumento. Comprare la piattaforma e poi cercare dove applicarla rovescia l'ordine delle domande.
• Non misurare prima. Senza i tempi e i costi del processo attuale, il risultato finale non ha un termine di paragone, e infatti la maggior parte dei casi che circolano non ne ha uno.
• Dimenticare le persone. È l'accusa che al metodo ha rivolto uno dei suoi autori, con quel titolo, nel 1995.
• Perimetro troppo largo. Un progetto che tocca tutta l'azienda si ferma prima del pilota.

08Glossario

• BPR: «fundamental rethinking and radical redesign of business processes to achieve dramatic improvements» (Hammer e Champy, 1993, p. 32).
• Cow path: il sentiero tracciato dalle mucche che poi diventa strada. Nell'articolo del 1990 è l'immagine del processo ereditato che si asfalta invece di rifarlo.
• As-Is: il processo come funziona adesso, ricostruito sui dati registrati dai sistemi.
• To-Be: il processo come si vuole che funzioni dopo.
• Process mining: ricostruzione automatica del flusso reale a partire dai registri di ERP, CRM e gestionali. Serve a far vedere i 22 giorni di attesa, non i 17 minuti di lavoro.
• Kaizen: miglioramento continuo per piccoli passi. Lavora sul processo esistente, dove il reengineering lo mette in discussione.
• BPMN 2.0: notazione standard per disegnare i processi, gestita dall'Object Management Group.
• Unscientific estimate: la qualifica che Hammer e Champy hanno dato da soli alla loro stima del 50-70%, e che si perde ogni volta che quella cifra viene ricitata.

Il modo in cui affronto oggi questa separazione, nei corsi e in azienda, si chiama Divide et Delega: si spezza il processo in pezzi, si distingue quello che è calcolo da quello che è giudizio, si delega alla macchina solo il calcolo e della decisione risponde una persona. La prima domanda di Hammer resta la prima anche lì: quel pezzo deve esistere?