Il confine che l’architettura deve proteggere
Un flusso prepara documenti e propone l’invio al cliente. Alcuni casi sono standard, altri contengono condizioni commerciali che richiedono un responsabile. Il controllo umano va collocato prima dell’azione irreversibile e solo dove il giudizio cambia davvero l’esito, non distribuito come firma rituale su ogni passaggio.
Nel perimetro «posizionare il controllo umano in base a rischio e reversibilità», il confine passa da «impatto di un errore»: qui una responsabilità, un permesso o un’interpretazione diventano stato operativo. Disegna il workflow a partire da rischio, reversibilità e tempo disponibile per decidere.
I componenti, spiegati attraverso soglie di rischio, payload di approvazione, deleghe e timeout
Il componente responsabile di «possibilità di annullare l’azione» dichiara input, output e risposta a «approvazioni su ogni passaggio». Questo contratto precede la scelta della piattaforma e può diventare un test autonomo; l’evidenza da conservare è «mostrare contesto e proposta».
Impatto di un errore
Il componente deve esporre questo confine. Il componente responsabile di «impatto di un errore» espone «possibilità di annullare l’azione» nel proprio contratto e ferma il flusso in presenza di «approvazioni su ogni passaggio».
Possibilità di annullare l’azione
Il contratto non può lasciarlo implicito. Il componente responsabile di «possibilità di annullare l’azione» espone «chiarezza dei criteri» nel proprio contratto e ferma il flusso in presenza di «richieste senza informazioni sufficienti».
Chiarezza dei criteri
Qui si decide che cosa può proseguire. Il componente responsabile di «chiarezza dei criteri» espone «tempo accettabile per la revisione» nel proprio contratto e ferma il flusso in presenza di «assenza di deleghe».
Tempo accettabile per la revisione
Questo controllo appartiene al livello che possiede il dato. Il componente responsabile di «tempo accettabile per la revisione» espone «impatto di un errore» nel proprio contratto e ferma il flusso in presenza di «workflow bloccati senza alert».
Il flusso end-to-end
Durante «classificare le azioni per rischio» nasce l’identità del caso; «definire soglie di approvazione» cambia lo stato senza perderla. Separare questi due passaggi permette di sostituire il meccanismo senza ridefinire posizionare il controllo umano in base a rischio e reversibilità.
- 1
Classificare le azioni per rischio
Il passaggio «classificare le azioni per rischio» accetta un input definito e restituisce «impatto di un errore» con provenienza. Il contratto gestisce «approvazioni su ogni passaggio» prima di invocare «definire soglie di approvazione».
- 2
Definire soglie di approvazione
Il passaggio «definire soglie di approvazione» accetta un input definito e restituisce «possibilità di annullare l’azione» con provenienza. Il contratto gestisce «richieste senza informazioni sufficienti» prima di invocare «mostrare contesto e proposta».
- 3
Mostrare contesto e proposta
Il passaggio «mostrare contesto e proposta» accetta un input definito e restituisce «chiarezza dei criteri» con provenienza. Il contratto gestisce «assenza di deleghe» prima di invocare «registrare decisione e motivazione».
- 4
Registrare decisione e motivazione
Il passaggio «registrare decisione e motivazione» accetta un input definito e restituisce «tempo accettabile per la revisione» con provenienza. Il contratto gestisce «workflow bloccati senza alert» prima di invocare «gestire scadenza e sostituzione dell’approvatore».
- 5
Gestire scadenza e sostituzione dell’approvatore
Il passaggio «gestire scadenza e sostituzione dell’approvatore» accetta un input definito e restituisce «impatto di un errore» con provenienza. Il contratto gestisce «approvazioni su ogni passaggio» prima di invocare «classificare le azioni per rischio».
Il contratto fra i passaggi
Per trasferire «chiarezza dei criteri» servono versione, provenienza e risultato ammesso. Se «mostrare contesto e proposta» deve reinterpretare uno di questi elementi, la separazione fra componenti è soltanto grafica.
Nel tema «posizionare il controllo umano in base a rischio e reversibilità» un output limitato e validabile è più sicuro di una risposta ricca davanti a «richieste senza informazioni sufficienti». Gli stati «non disponibile» e «richiede revisione» fanno parte del contratto; il caso operativo si verifica con «possibilità di annullare l’azione».
Due componenti, un contratto esplicito
Caso isolato: «impatto di un errore». Operazione osservata: «gestire scadenza e sostituzione dell’approvatore». Deviazione forzata: «richieste senza informazioni sufficienti».
Contratto osservato: «Soglie di rischio, payload di approvazione, deleghe e timeout». Il componente non può reinterpretare «impatto di un errore». Perimetro della prova: «posizionare il controllo umano in base a rischio e reversibilità».
Controprova: «chiarezza dei criteri». Arresto: «workflow bloccati senza alert». Passo ammesso dopo il recupero: «definire soglie di approvazione». Verbale finale: «Quali decisioni devono interrompere il workflow e chiedere una revisione?»
Differenza decisiva: «Disegna il workflow a partire da rischio, reversibilità e tempo disponibile per decidere». Regola di chiusura: «Un’approvazione utile presenta proposta, prove e conseguenze, registra la motivazione e sa che cosa fare se il responsabile non risponde».
Dove l’architettura deve fermarsi
«approvazioni su ogni passaggio» può consentire un nuovo tentativo; «richieste senza informazioni sufficienti» può richiedere autorizzazione; «assenza di deleghe» può invalidare la fonte. Un solo fallback nasconderebbe decisioni diverse.
Approvazioni su ogni passaggio
Rischio nominato: «approvazioni su ogni passaggio». Perimetro operativo: «posizionare il controllo umano in base a rischio e reversibilità». Segnale osservato: «possibilità di annullare l’azione». Recupero ammesso: «gestire scadenza e sostituzione dell’approvatore». Checkpoint finale: «possibilità di annullare l’azione».
Richieste senza informazioni sufficienti
Rischio nominato: «richieste senza informazioni sufficienti». Perimetro operativo: «posizionare il controllo umano in base a rischio e reversibilità». Segnale osservato: «chiarezza dei criteri». Recupero ammesso: «classificare le azioni per rischio». Checkpoint finale: «chiarezza dei criteri».
Assenza di deleghe
Rischio nominato: «assenza di deleghe». Perimetro operativo: «posizionare il controllo umano in base a rischio e reversibilità». Segnale osservato: «tempo accettabile per la revisione». Recupero ammesso: «definire soglie di approvazione». Checkpoint finale: «tempo accettabile per la revisione».
Workflow bloccati senza alert
Rischio nominato: «workflow bloccati senza alert». Perimetro operativo: «posizionare il controllo umano in base a rischio e reversibilità». Segnale osservato: «impatto di un errore». Recupero ammesso: «mostrare contesto e proposta». Checkpoint finale: «impatto di un errore».
Osservare il sistema con domande operative
La vista operativa collega «tempo accettabile per la revisione» al componente che ha deciso e al destinatario di «workflow bloccati senza alert». Un generico «success/fail» non risponde a nessuna di queste domande; il controllo associato riguarda «approvazioni su ogni passaggio».
L’operatore vede l’identificatore necessario a «gestire scadenza e sostituzione dell’approvatore»; i dettagli tecnici possono restare altrove, purché il collegamento non dipenda da nomi file o memoria individuale.
La decisione architetturale
Un’approvazione utile presenta proposta, prove e conseguenze, registra la motivazione e sa che cosa fare se il responsabile non risponde. Il test di «Soglie di rischio, payload di approvazione, deleghe e timeout» deve mantenere il confine durante errore, modifica e revoca.
Un’approvazione utile presenta proposta, prove e conseguenze, registra la motivazione e sa che cosa fare se il responsabile non risponde. Il contratto è sufficiente quando «assenza di deleghe» resta confinato, «possibilità di annullare l’azione» conserva provenienza e «registrare decisione e motivazione» non deve indovinare lo stato precedente.
Contesto e limiti
Il contesto è esemplificativo per «posizionare il controllo umano in base a rischio e reversibilità». La scelta richiede evidenze del processo, inclusi errori e percorsi di recupero; il controllo associato riguarda «mostrare contesto e proposta». Il controllo resta collegato alla decisione che deve sostenere.
Prossimo passo
Hai attività ripetitive fra email, fogli e gestionali?
L’Audit Digitale aiuta a capire dove i passaggi restano manuali e se ha senso approfondire un’automazione.