Quando si descrive un processo aziendale, quasi sempre si parte dal caso ideale. Un cliente inserisce un ordine, il sistema verifica i dati, la merce è disponibile, le condizioni commerciali sono corrette, l’ordine viene confermato e il flusso prosegue verso la logistica. Sulla carta il processo appare lineare e, di conseguenza, anche il software necessario a gestirlo può sembrare relativamente semplice. Il problema è che le aziende reali non lavorano soltanto con casi ideali: lavorano soprattutto con eccezioni, deroghe, informazioni incomplete, vincoli temporanei, condizioni particolari e situazioni che non erano state previste quando il processo è stato disegnato.
È proprio qui che nasce una parte consistente della complessità dei sistemi enterprise. Il percorso standard può rappresentare il 90% delle transazioni e richiedere un insieme relativamente limitato di regole; il restante 10%, invece, può generare metà delle condizioni applicative, delle verifiche, delle autorizzazioni e dei test necessari. Non si tratta di una proporzione universale, naturalmente, ma di un modo molto efficace per rappresentare un fenomeno che incontriamo spesso nei progetti: il costo del software non cresce in modo proporzionale al numero dei casi gestiti, perché alcune eccezioni hanno un costo progettuale enormemente superiore alla loro frequenza.
Il processo standard è quasi sempre la parte più semplice
Consideriamo un processo di gestione ordini B2B. Nel caso standard il cliente è censito correttamente, dispone di un listino associato, il prodotto è disponibile, il credito è sufficiente e l’indirizzo di consegna è valido. Il software deve acquisire l’ordine, applicare le condizioni previste, effettuare alcune verifiche e trasmettere le informazioni all’ERP o al sistema logistico. Una sequenza del genere può essere descritta con poche regole e, soprattutto, è relativamente facile da testare.
Poi iniziano le eccezioni. Il cliente appartiene a un gruppo ma deve utilizzare condizioni commerciali differenti; un ordine supera il fido ma deve essere autorizzato da una determinata figura; una referenza non è disponibile e può essere sostituita soltanto per alcuni clienti; la consegna deve essere suddivisa su due sedi; una promozione non è cumulabile con uno sconto concordato; un prodotto è vendibile soltanto in alcuni mercati; l’ordine arriva dopo l’orario limite ma deve comunque partire; l’anagrafica è incompleta oppure esiste una deroga temporanea concordata dal commerciale.
Ognuna di queste situazioni introduce una domanda che il software deve saper affrontare. Chi può autorizzare la deroga? Vale per tutti i clienti o soltanto per alcuni? La decisione deve essere registrata? L’ERP è in grado di rappresentarla? Cosa accade se due eccezioni si verificano contemporaneamente? Come deve comportarsi il sistema se l’autorizzatore non è disponibile? E, soprattutto, la deroga è davvero un’eccezione oppure nel tempo è diventata una variante stabile del processo?
Una piccola percentuale di casi può moltiplicare le regole
Immaginiamo, a titolo esemplificativo, un processo che gestisca 100.000 pratiche all’anno. Se 90.000 seguono un percorso standard composto da 8 passaggi e 10 regole principali, mentre le restanti 10.000 si distribuiscono fra 15 tipologie di eccezione, il peso progettuale delle due popolazioni può essere completamente diverso. Per il percorso standard potrebbero essere sufficienti poche schermate, un workflow lineare e un set limitato di test; per le eccezioni potrebbero invece servire decine di condizioni, ruoli autorizzativi differenti, notifiche, stati intermedi, motivazioni obbligatorie, integrazioni aggiuntive e centinaia di combinazioni da verificare.
Il punto diventa ancora più evidente osservando i test. Con tre condizioni indipendenti, ciascuna delle quali può essere vera o falsa, esistono già otto combinazioni teoriche; con cinque condizioni si arriva a trentadue. Naturalmente non tutte richiedono un test dedicato e una buona progettazione consente di ridurre drasticamente la casistica, ma il principio rimane: quando le eccezioni interagiscono tra loro, la complessità cresce molto più rapidamente del volume delle transazioni interessate.
È per questo che una richiesta apparentemente marginale, come “in questo caso consentiamo anche questa possibilità”, può avere un impatto sorprendente. Non bisogna modificare soltanto la schermata visibile all’utente: occorre capire come la nuova condizione interagisca con le regole esistenti, quali sistemi debbano ricevere l’informazione, chi possa utilizzarla, come debba essere tracciata e quali scenari debbano essere nuovamente verificati.
Il costo dell’eccezione non è soltanto sviluppo
Supponiamo che un nuovo gestionale richieda 200 giornate di lavoro per coprire il processo principale e altre 100 giornate per gestire una serie di casistiche che, complessivamente, rappresentano soltanto il 10% delle operazioni. A un costo medio progettuale di 700 euro per giornata, quelle eccezioni valgono circa 70.000 euro di investimento. La domanda corretta non è però se sia “troppo” spendere quella cifra per il 10% dei casi, ma quale valore produca quella copertura e quale sarebbe il costo dell’alternativa.
Se quelle 10.000 pratiche annuali richiedessero, senza automazione, cinque minuti di intervento manuale ciascuna, avremmo circa 833 ore di lavoro all’anno. A un costo aziendale indicativo di 35 euro l’ora, il valore diretto sarebbe poco più di 29.000 euro annui: in questo scenario un investimento di 70.000 euro potrebbe comunque essere ragionevole, ma dovrebbe essere valutato su un orizzonte pluriennale e considerando anche errori, tempi di attraversamento e qualità del servizio. Se invece ciascuna eccezione richiedesse trenta minuti, il lavoro manuale supererebbe le 5.000 ore annue, equivalenti a circa 175.000 euro: il quadro economico cambierebbe radicalmente.
Questo semplice confronto mostra perché la frequenza non sia sufficiente per decidere cosa automatizzare. Un caso raro può essere estremamente costoso da gestire manualmente oppure avere conseguenze economiche e operative tali da giustificare un’automazione sofisticata; al contrario, una casistica frequente ma rapidissima da risolvere potrebbe non meritare lo stesso investimento.
Non tutte le eccezioni devono entrare nel software
Uno degli errori più comuni nei progetti enterprise consiste nel considerare la copertura del 100% dei casi come un obiettivo implicito. È comprensibile: quando si investe in un nuovo sistema, l’aspettativa naturale è che possa gestire tutto. Ma trasformare ogni comportamento storico dell’organizzazione in una regola applicativa può produrre un software molto costoso, difficile da comprendere e ancora più difficile da evolvere.
Se una determinata situazione si presenta venti volte all’anno e può essere risolta da un operatore esperto in dieci minuti, stiamo parlando di poco più di tre ore di lavoro annuale. Spendere diverse giornate di analisi, sviluppo e test per automatizzarla potrebbe non avere alcun senso economico. In questi casi può essere preferibile progettare un percorso di eccezione controllato: il sistema intercetta il caso, raccoglie le informazioni necessarie, lo assegna alla persona corretta e consente una gestione manuale tracciata.
Questa non è una rinuncia all’automazione, ma una forma più matura di automazione. Significa concentrare il software dove produce valore e lasciare all’intervento umano quei casi nei quali la variabilità è talmente elevata, o la frequenza talmente bassa, da rendere inefficiente codificare ogni possibile comportamento.
A volte l’eccezione rivela che il processo è sbagliato
Esiste poi una seconda possibilità, spesso ancora più importante: alcune eccezioni non dovrebbero essere automatizzate perché non dovrebbero esistere. Nel tempo le organizzazioni accumulano deroghe nate per risolvere esigenze contingenti. Un cliente strategico ottiene una modalità particolare, un reparto introduce un passaggio aggiuntivo, un controllo viene duplicato per compensare un limite del vecchio gestionale, una procedura temporanea diventa permanente. Dopo alcuni anni nessuno ricorda più perché certe regole esistano, ma vengono comunque inserite nei requisiti del nuovo sistema.
È uno dei motivi per cui la fase di analisi non dovrebbe limitarsi a chiedere agli utenti “come lavorate oggi?”. La domanda successiva deve essere “perché lavorate così?”. Se su 50 eccezioni censite durante l’analisi 15 derivano esclusivamente da limiti del software precedente e altre 10 da procedure che il business non considera più necessarie, eliminarle prima dello sviluppo significa ridurre del 50% il numero delle casistiche speciali senza scrivere una riga di codice.
Il rischio opposto è costruire un sistema nuovo che riproduce fedelmente tutti i compromessi del sistema vecchio. Il progetto viene formalmente completato, la tecnologia cambia, ma la complessità organizzativa rimane intatta e viene semplicemente cristallizzata in una nuova applicazione.
Le eccezioni devono diventare misurabili
Una buona progettazione non si limita a gestire le eccezioni: permette anche di osservarle. Se un processo devia dal percorso standard nel 2% dei casi, probabilmente il comportamento è fisiologico; se sei mesi dopo la percentuale è diventata il 25%, quella che continuiamo a chiamare eccezione potrebbe essere diventata una modalità operativa ordinaria oppure potrebbe indicare un problema nei dati, nelle regole o nel processo.
Per questo può essere utile misurare quante pratiche entrano nei percorsi di deroga, quali sono le cause più frequenti, quanto tempo rimangono sospese, quante richiedono un intervento umano e quante vengono successivamente respinte. Se, per esempio, il 60% delle anomalie sugli ordini deriva sempre dalla stessa incoerenza anagrafica, probabilmente il problema non va risolto migliorando ulteriormente la schermata di gestione dell’eccezione: va eliminata la causa a monte.
Questi dati trasformano il software in uno strumento di osservazione del processo. Non servono soltanto all’IT per capire se l’applicazione funziona, ma al management per individuare dove l’organizzazione consuma tempo, dove si concentrano le deroghe e quali regole stanno generando più attrito.
Progettare per le eccezioni senza costruire un sistema ingestibile
La soluzione non consiste quindi nell’ignorare i casi particolari né nel codificarli tutti indiscriminatamente. Occorre classificare le eccezioni, comprenderne frequenza e impatto, distinguere quelle strutturali da quelle occasionali e decidere consapevolmente quali debbano essere automatizzate, quali possano essere gestite attraverso configurazioni e quali debbano rimanere sotto controllo umano.
Anche l’architettura applicativa deve supportare questa impostazione. Regole commerciali, workflow autorizzativi e parametri che cambiano frequentemente non dovrebbero necessariamente essere dispersi nel codice; allo stesso tempo, rendere tutto configurabile può creare una piattaforma talmente flessibile da diventare incomprensibile. Il punto di equilibrio dipende dal dominio, dalla frequenza dei cambiamenti e dal livello di autonomia che l’organizzazione vuole mantenere.
Nei progetti più complessi è spesso utile partire da una matrice molto semplice che, per ciascuna eccezione, metta in relazione frequenza, costo della gestione manuale, rischio operativo, impatto sul cliente e complessità stimata dell’automazione. Non serve trasformare tutto in una formula matematica: l’obiettivo è impedire che una casistica venga sviluppata soltanto perché “oggi facciamo così”, senza chiedersi quanto accada realmente e quale valore produca automatizzarla.
Il vero requisito non è coprire tutto, ma governare la complessità
La qualità di un software enterprise non si misura dal numero di eccezioni che riesce a incorporare, ma dalla capacità di gestire la variabilità del business senza trasformarla in complessità incontrollata. In alcuni casi questo significa automatizzare completamente una deroga; in altri significa consentire a una persona di intervenire in modo semplice e tracciato; in altri ancora significa avere il coraggio di eliminare una regola che non ha più ragione di esistere.
È anche per questo che la fase di analisi ha un peso così rilevante nei progetti software complessi. Individuare il percorso standard è relativamente facile; capire quali eccezioni esistano davvero, quanto costino, quali siano necessarie e quali siano soltanto il risultato della storia dell’organizzazione richiede invece confronto con il business, conoscenza dei sistemi e capacità di mettere in discussione requisiti apparentemente consolidati.
In lab51 affrontiamo questi progetti partendo proprio dalla comprensione dei processi reali, comprese le deviazioni che spesso non emergono nei primi diagrammi o nelle specifiche iniziali. L’obiettivo non è costruire software che replichi indiscriminatamente ogni comportamento esistente, ma individuare dove l’automazione genera valore, dove è opportuno mantenere flessibilità e come progettare un sistema capace di evolvere senza accumulare nel tempo nuove stratificazioni di complessità.
Se stai valutando la realizzazione o la revisione di una piattaforma enterprise, lab51 può affiancarti nell’analisi dei processi e delle eccezioni, nella definizione dei requisiti e nella progettazione dell’architettura, trasformando la complessità operativa in scelte progettuali misurabili prima che diventi costo strutturale nel software.
