Cos'è il principio di Pareto applicato al software aziendale?

Il principio di Pareto afferma che, in molti sistemi, una quota minoritaria delle cause produce la maggioranza degli effetti: la formulazione più diffusa è l'80/20, per cui circa l'80% dei risultati deriva da circa il 20% degli input, anche se le proporzioni reali variano caso per caso e non sono una legge fissa. Applicato al software aziendale, il principio si traduce così: la maggior parte del valore che chi lavora in azienda estrae ogni giorno da un gestionale, un CRM o una piattaforma dati arriva da una piccola porzione delle funzionalità disponibili, mentre il resto del catalogo resta inutilizzato o quasi. Per chi decide cosa costruire o cosa comprare, il principio è uno strumento per allocare tempo e budget sulle funzioni che generano davvero valore, invece di distribuirle in modo uniforme su un intero elenco di requisiti. Non è una regola matematica esatta, ma un'euristica di prioritizzazione, e va usata proprio così, non come previsione precisa di una percentuale.

Leggi anche: Agile · Organizzare lo sviluppo in cicli brevi ridecidendo le priorità: funziona se il contratto permette di cambiare il perimetro.

Un nome che il suo stesso autore ha corretto

Il nome nasce da un'attribuzione che Joseph M. Juran ha corretto pubblicamente. Fu Juran, negli anni '40, a battezzare il fenomeno "principio di Pareto", collegandolo alle osservazioni dell'economista italiano Vilfredo Pareto sulla distribuzione della ricchezza a fine Ottocento. Nel 1975, però, Juran pubblicò su Quality Progress (maggio 1975, vol. 8, n. 5, pp. 8-9) l'articolo "The Non-Pareto Principle; Mea Culpa", in cui scrive che il principio come regola universale non era di Pareto ("The Pareto principle as a universal was not original with Pareto") e che, per quanto ne sappia, la prima formulazione generale è sua ("To my knowledge, the first exposition was by myself"). Pareto aveva osservato una distribuzione di reddito, non enunciato una regola di gestione della qualità. Juran ammette di aver scelto quel nome per motivi di comunicazione, non di rigore storico: un'attribuzione a un economista già noto rendeva l'idea più memorabile e più facile da far accettare dentro un'organizzazione. Juran corresse anche sé stesso su un secondo punto: aveva battezzato le due parti "vital few and trivial many", e poi cambiò "trivial" in "useful many", perché quell'80% residuo non è spazzatura.

Un esempio concreto

Un caso tipico è un'azienda manifatturiera che sostituisce un ERP generalista con un sistema più mirato ai suoi processi reali. Prima del cambio, chi lo usa ogni giorno in produzione e in amministrazione naviga un menu con decine di moduli, ma il lavoro quotidiano si concentra su gestione ordini, magazzino e fatturazione: tre o quattro aree che coprono la quasi totalità delle operazioni. Secondo il Feature Adoption Report 2019 di Pendo, che ha misurato 615 prodotti software in abbonamento, in media l'80% delle funzionalità viene usato raramente o mai, mentre un nucleo di circa il 12% delle funzionalità genera l'80% dell'utilizzo giornaliero. Il resto del catalogo resta inutilizzato ma continua a pesare sul canone annuale, sulla formazione di chi entra in azienda e sulla superficie che ogni aggiornamento del fornitore può rompere. Applicare il principio di Pareto qui non significa eliminare tutto ciò che si usa poco, ma decidere consapevolmente quali moduli valgono il costo di mantenimento e quali sono semplicemente ereditati da un pacchetto venduto per intero, un rischio descritto più a fondo alla voce vendor lock-in.

Perché conta per chi decide

Per chi valuta un investimento software, il principio di Pareto è un criterio di selezione, non solo di analisi a posteriori: prima di firmare un contratto vale la pena chiedere quale percentuale delle funzionalità del prodotto verrà davvero usata da chi ci lavora, e se quel nucleo minoritario si può ottenere con uno strumento più piccolo, più economico e più facile da mantenere. Lo stesso criterio guida la scelta tra costruire uno strumento su misura o adottare un prodotto a listino, discussa alla voce selezione dei casi d'uso AI, ed è un argomento a favore della delivery incrementale del modello forward deployed engineer: costruire prima il nucleo che genera valore, verificarlo sul campo, e solo dopo decidere se estenderlo, invece di specificare in anticipo un intero catalogo di funzioni che nessuno, alla fine, userà davvero.