Un campo come stato = "in attesa" sembra sufficiente finché il processo non accumula approvazioni, eccezioni e azioni che dipendono dal modo in cui è arrivato a quel punto. A quel punto sorgono domande pratiche: si può annullare dopo l’approvazione? Chi può riaprire un caso? Che cosa succede se la stessa richiesta arriva due volte? Una macchina a stati aiuta a rispondere descrivendo non solo lo stato corrente, ma anche i cambiamenti consentiti e i loro effetti.
Non tutti i flussi richiedono questo modello. In un processo breve e lineare, un’etichetta di stato e alcune regole semplici possono essere più facili da realizzare e mantenere. La decisione consiste nel confrontare la complessità effettiva del flusso con il costo di rendere esplicite le sue regole, non nell’adottare in anticipo un determinato modello.
Stato come etichetta e macchina a stati: che cosa cambia
Salvare uno stato come etichetta rappresenta una condizione corrente: per esempio, un’attività può risultare “in attesa” o “completata”. Da sola, l’etichetta non spiega quali cambiamenti siano validi, quale evento li provochi né quali azioni debbano accompagnarli. Spesso questa logica è distribuita tra interfaccia, server e diverse condizioni nel codice.
Una macchina a stati descrive il processo come un insieme definito di stati e transizioni. Una transizione stabilisce quale evento consente di passare da uno stato a un altro e, se necessario, quali condizioni devono essere soddisfatte o quali azioni vengono eseguite. Lo stato corrente limita quindi le evoluzioni possibili.
La differenza non dipende dal numero di etichette presenti in un database. Un campo di stato può far parte di una macchina esplicita se il sistema convalida le transizioni. E un elenco lungo di stati non costituisce di per sé un buon modello, se nessuno sa spiegare come si passa dall’uno all’altro.
Segnali che suggeriscono di definire transizioni esplicite
Il modello inizia a essere utile quando le regole dipendono dal punto del processo e gli errori di transizione hanno conseguenze. Fai attenzione a questi segnali:
- Azioni consentite diverse: non tutti possono approvare, modificare o annullare in ogni fase, oppure un’azione è disponibile solo dopo una convalida.
- Percorsi alternativi: una richiesta può essere approvata, respinta, restituita per completare le informazioni o annullata.
- Regole distribuite: parti diverse dell’applicazione verificano in modo indipendente se un’operazione è valida, con il rischio di contraddirsi.
- Effetti associati al cambiamento: una transizione deve registrare una decisione, avvisare qualcuno o avviare un’altra attività. È utile distinguere questo effetto dal semplice cambio di etichetta.
- Nuovi tentativi e concorrenza: due persone o processi potrebbero cercare di modificare lo stesso caso, oppure un’integrazione potrebbe ripetere un evento.
Un buon indizio diagnostico è che il team discuta spesso se una modifica “dovrebbe essere consentita” in una determinata fase. Se la risposta dipende dallo stato precedente, da chi interviene o da un risultato aziendale, è opportuno registrare la regola in modo esplicito e centralizzato.
Quando bastano stati semplici
Un modello semplice è spesso sufficiente quando il processo è lineare, ha poche transizioni e le eccezioni sono rare o facili da gestire. Per esempio, un’attività interna che passa da “in attesa” a “completata” può richiedere soltanto un campo e un controllo chiaro, soprattutto se non ci sono approvazioni, nuovi tentativi o conseguenze esterne.
Conta anche il costo operativo. Una macchina a stati introduce concetti, test e attività di manutenzione. Se il flusso non presenta ambiguità, il costo può superare il beneficio. Non trasformare ogni cambio di schermata, passaggio dell’interfaccia o variazione minore in uno stato aziendale: un’esperienza visiva non corrisponde sempre a una fase del processo.
Come criterio pratico, parti dalla rappresentazione più semplice che consenta di applicare le regole importanti. Se compaiono condizioni ripetute, transizioni implicite o problemi dovuti a cambiamenti non validi, rivedi la progettazione. L’evoluzione può essere graduale: non è necessario riprogettare l’intero processo per formalizzare prima le transizioni più rischiose.
Criteri per prendere una decisione
Non esiste un numero universale di stati o transizioni oltre il quale una macchina diventa necessaria. Valuta il comportamento e l’impatto degli errori con domande concrete:
- Quanti percorsi effettivi esistono? Conta i percorsi aziendali e le loro diramazioni, non soltanto le etichette. Più percorsi con autorizzazioni o risultati diversi spesso giustificano un modello esplicito.
- Che cosa succede se qualcuno tenta una transizione non valida? Se l’effetto è un inconveniente reversibile, può bastare una convalida semplice. Se può causare una decisione errata, lavoro duplicato o un’azione difficile da annullare, definisci controlli più chiari.
- Possono verificarsi modifiche simultanee o eventi ripetuti? Se sì, stabilisci come verificare che lo stato non sia cambiato dall’inizio dell’operazione e come evitare che l’elaborazione ripetuta dello stesso evento duplichi gli effetti.
- È necessario ricostruire il percorso? Se assistenza, audit o team operativi devono sapere chi ha fatto cosa, quando e perché, tenere distinto lo stato corrente dalla cronologia degli eventi facilita la ricostruzione dell’evoluzione.
- Le regole possono essere raccolte in un unico punto comprensibile? Se richiedono eccezioni concatenate in più componenti, il problema non riguarda più soltanto il numero di stati: è un segnale che il flusso non ha una definizione univoca.
Come dare un nome a stati, eventi ed eccezioni
Usa termini che descrivano fasi riconoscibili per l’attività. Uno stato risponde alla domanda “in quale situazione si trova il caso?”; un evento risponde a “che cosa è successo per modificarlo?”. Per esempio, “in revisione” può essere uno stato e “revisione approvata” un evento. Evita di usare i due concetti come se fossero intercambiabili.
Distingui anche la fase dal risultato quando rappresentano dimensioni diverse. “Chiuso” descrive una fase finale, mentre “approvato” o “respinto” descrive un risultato. Se li si mescola, possono comparire stati combinati come “chiuso e respinto”, che moltiplicano le varianti e rendono più difficile ragionare sulle regole.
Indica quali stati sono terminali, cioè quelli in cui il processo normalmente termina. Definisci separatamente se sia possibile annullare o riaprire un caso e chi possa farlo. Uno stato terminale non deve necessariamente impedire ogni intervento amministrativo, ma l’eccezione va delimitata e non deve diventare una scorciatoia per aggirare le regole.
Per i nuovi tentativi, evita di creare uno stato per ogni tentativo se il caso rimane nella stessa fase. Mantieni lo stato appropriato e registra il tentativo nella cronologia o come dato separato. Fai lo stesso per errori ed eccezioni: crea uno stato distinto solo se cambia in modo rilevante ciò che l’attività può fare in seguito.
Esempio ipotetico: una richiesta con revisione
Immagina una richiesta che viene ricevuta, esaminata e infine approvata o respinta. Nella versione più semplice, gli stati potrebbero essere “ricevuta”, “in revisione” e “risolta”, con un risultato associato. Se il team deve chiedere informazioni aggiuntive, il flusso deve rappresentare questa pausa e definire quale evento consente di tornare alla revisione quando arriva la risposta.
Una transizione può specificare che solo una persona autorizzata può approvare o respingere la richiesta quando è “in revisione”. Se viene respinta, il caso risulta risolto con esito “respinto”; se mancano informazioni, passa a “in attesa di informazioni”. La macchina non richiede una piattaforma speciale: è sufficiente che il sistema convalidi questi cambiamenti in modo coerente e registri i dati necessari.
Questo esempio è ipotetico; nomi e regole devono essere adattati al processo effettivo. Se chiedere informazioni non cambia le azioni disponibili e non richiede un monitoraggio specifico, può bastare registrare una nota. Il modello deve rappresentare differenze operative, non anticipare ogni possibilità immaginabile.
Errori comuni e lista di controllo
Un modello può diventare più difficile del processo se crea stati per ogni dettaglio, confonde autorizzazioni e fasi o non definisce che cosa accade ai casi esistenti quando cambiano le regole. È un errore anche rappresentare le transizioni in un diagramma e lasciare che il codice le ignori: la regola deve essere applicata nel punto in cui viene accettata la modifica.
Prima di scegliere o rivedere l’approccio, verifica quanto segue:
- Ogni stato rappresenta una situazione che l’attività sa spiegare?
- Gli eventi descrivono fatti e le transizioni specificano quali cambiamenti consentono?
- I percorsi alternativi, gli annullamenti e le riaperture sono chiari?
- Le operazioni non valide vengono rifiutate e gli eventi ripetuti o le modifiche simultanee vengono gestiti?
- La cronologia viene registrata quando è necessario ricostruire le decisioni?
- Ci sono stati che possono essere accorpati senza perdere regole o informazioni rilevanti?
Scegli una macchina a stati quando rende visibili e applicabili regole che altrimenti resterebbero distribuite e quando il costo di una transizione errata giustifica questo controllo. Se il processo è lineare e prevedibile, inizia con stati semplici. Rivedi la decisione quando cambiano i percorsi, le eccezioni o le conseguenze: il modello migliore è il più semplice che rappresenta fedelmente l’evoluzione del lavoro.