Il software non può risolvere un caos organizzativo

Un cliente aveva centinaia di clienti, ognuno con logiche di prezzo diverse: a peso, a pezzo, con forfait, con sconti storici, con accordi presi a voce negli anni. Voleva un software che "automatizzasse tutto". La digitalizzazione dei processi aziendali senza prima fare ordine produce esattamente questo: un sistema pieno di eccezioni, con decine di logiche di calcolo diverse, che nessuno riesce davvero a spiegare.

Quel software non era scritto male. Era la trasposizione fedele di un business senza regole chiare.

Ed è qui il punto: il software codifica quello che già esiste. Se a monte manca ordine, a valle troverai solo una versione più rigida della stessa confusione.

Il software è uno specchio

C’è una verità poco comoda: il software amplifica i problemi organizzativi: li rende più evidenti e più rigidi.

Se il tuo processo è chiaro ma manuale, il software lo velocizza. Se il tuo processo è lento ma ben definito, il software lo automatizza. Se invece il tuo processo è fatto di eccezioni, decisioni caso per caso e regole implicite, il software trasformerà tutto questo in una rete di condizioni difficili da capire e ancora più difficili da modificare.

Il codice ha bisogno di regole esplicite. Se tu non riesci a spiegare come funziona il tuo processo senza dire “dipende” ogni due frasi, chi sviluppa dovrà tradurre ogni “dipende” in una condizione diversa. E il risultato sarà un sistema che riflette esattamente quella confusione.

Segnali che il problema sta a monte del software

“Ci servono molte eccezioni”

Durante l’analisi, se ogni requisito è seguito da “sì, ma in questo caso è diverso”, non sei davanti a un processo: sei davanti a una serie di abitudini stratificate nel tempo.

Un sistema sano ha poche eccezioni ben definite. Un sistema caotico è composto quasi solo da eccezioni.

“Non riesco a spiegarti come funziona”

Prova a scrivere su un foglio le regole del tuo business: come si calcola il prezzo, come si applicano gli sconti, come funziona la fatturazione, come gestisci gli ordini.

Se non riesci a farlo in modo lineare, probabilmente non stai descrivendo un processo, ma una serie di decisioni prese caso per caso nel tempo.

“Ogni cliente è un caso a sé”

C’è una differenza netta tra personalizzazione strutturata e caos. Nel primo caso hai pochi modelli chiari combinabili tra loro; nel secondo ogni cliente ha condizioni uniche, negoziate a voce e mai formalizzate. La prima situazione si può automatizzare. La seconda va prima ricondotta a regole.

Cosa succede quando digitalizzi il caos

Nella pratica si vedono sempre gli stessi effetti. Il software diventa difficile da mantenere, perché ogni nuova funzionalità deve tenere conto di tutte le eccezioni precedenti e le modifiche diventano lente, rischiose e costose. Il sistema finisce per diventare fragile e ogni deploy diventa fonte di tensione.

Nel frattempo il team continua a lavorare “a parte”. Le persone evitano il software perché per certi casi è ancora più veloce fare a mano, quindi fogli Excel ed email continuano a vivere in parallelo. E naturalmente i costi crescono più del previsto: il costo del software dipende dalla complessità delle regole, non dalla dimensione dell'azienda. Poche regole chiare portano a un sistema semplice, mentre molte regole implicite portano a un sistema costoso e difficile. Del resto costruire qualcosa di semplice è già di per sé la cosa più difficile.

Prima organizzi, poi digitalizzi

Prima di iniziare un progetto software, spesso conviene fare un lavoro preliminare molto più semplice di quanto sembri: chiarire le regole. È lo stesso principio per cui le stime di sviluppo sono spesso sbagliate: senza regole chiare, non si può stimare nulla con precisione.

La prima domanda utile riguarda il listino. Se la risposta è “dipende dal cliente”, allora la domanda successiva è se possa dipendere da meno fattori: fasce, categorie, criteri ripetibili che coprano la maggior parte dei casi. La seconda riguarda il rapporto tra regole ed eccezioni. Se le eccezioni sono più delle regole, non sei pronto per un software; sei pronto per semplificare il processo. La terza domanda è cosa puoi standardizzare senza perdere valore, perché molte differenze percepite come fondamentali in realtà non lo sono. Il cliente vede il risultato finale, non il metodo interno con cui lo ottieni.

Il ruolo di chi progetta il software

Il lavoro più prezioso sta nell'aiutare a riformulare i requisiti prima ancora di tradurli in codice.

“Ogni cliente ha il suo prezzo” può diventare “abbiamo un sistema di fasce con alcune deroghe documentate”.
“Ogni progetto è diverso” può diventare “abbiamo un modello con opzioni configurabili”.

Questa fase è chiarificazione del modello di business.

Una checklist pratica

Se riesci a spiegare il tuo processo principale senza usare “dipende” più di una volta, se le eccezioni sono poche e sai elencarle, se le regole che applichi oggi sono scritte da qualche parte, se due persone diverse nella tua azienda descrivono il processo nello stesso modo e se un nuovo collaboratore potrebbe impararlo leggendo quelle regole, allora probabilmente sei pronto a digitalizzare. Se molte di queste risposte sono negative, il lavoro da fare è prima di tutto organizzativo.

In sintesi

Il software è un acceleratore. Accelera quello che già esiste.

Se esiste ordine, accelera l’ordine. Se esiste confusione, accelera la confusione.

Mettere ordine prima di digitalizzare è il modo più efficace per evitare un software costoso che riflette problemi invece di risolverli.