DRY vs WET nella progettazione dei processi aziendali (senza passare al digitale)

Image by rawpixel.com on Freepik

DRY ("Don’t Repeat Yourself") è un principio del software, ma lo stesso problema ricorre nelle operations: regole duplicate e lavoro duplicato si disallineano, generano errori e aumentano i costi in modo silenzioso. Questo articolo usa la metafora DRY/WET per guardare alla progettazione dei processi puramente analogica: template, lavoro standard, flusso fisico, checklist e schede kanban (molto prima che qualcuno parli di software).

“Abbiamo già il processo. Basta seguirlo”.

La maggior parte dei team di leadership che incontro non dice “ci serve automazione”. Dice qualcosa che suona più ragionevole e più innocente:

“Abbiamo già il processo. Basta seguirlo” (nota: ricordati di scrivere un articolo sull’affermazione “trust the process”).

È una diagnosi rassicurante, perché implica che la soluzione sia culturale: comunicare meglio, far rispettare con più rigore, aggiungere un altro training, magari mettere la procedura in un PDF più curato. E a volte funziona, per una o due settimane, soprattutto subito dopo che qualcuno di importante lo ribadisce in riunione.

Poi la realtà torna. Gli stessi errori si ripresentano. Gli stessi passaggi di consegna si inceppano. Le stesse escalation “com’è possibile?” arrivano sulle stesse scrivanie.

Quello che di solito si nasconde sotto non è una mancanza di disciplina. È un problema strutturale: l’organizzazione sta chiedendo alle persone di ricostruire il processo a partire da frammenti ogni volta che devono svolgere il lavoro.

La regola esiste in un documento di policy, ma il modulo dice qualcosa di leggermente diverso. La presentazione di training riflette l’eccezione dell’anno scorso. Il team lead la spiega in un modo, le operations in un altro. La checklist è stata aggiornata, ma solo in un reparto. Così le persone “seguono il processo”, ma ciascuno sta seguendo una interpretazione locale dello stesso.

Questo è il momento in cui, senza voler fare i brillanti, mi capita di prendere in prestito una metafora dall’ingegneria del software, perché descrive l’odore operativo con una precisione scomoda: WET vs DRY.

DRY e WET, spiegati come li intendono davvero gli sviluppatori

Nel software, DRY non è solo “non fare copia-incolla”. La formulazione classica riguarda la conoscenza: ogni pezzo di conoscenza dovrebbe avere una rappresentazione unica, non ambigua e autorevole all’interno di un sistema.

WET è il contro-principio scherzoso: “Write Everything Twice” (a volte reso anche come “We Enjoy Typing” o “Waste Everyone’s Time”). La battuta funziona perché è vera: in un sistema a più livelli, aggiungere un campo “semplice” può obbligarti a ripetere lo stesso concetto tra etichette, moduli, funzioni, query e script.

Nelle operations succede la stessa cosa, solo con raccoglitori, moduli, tradizione orale e “qui si fa così”.

Perché DRY emerge naturalmente nell’analisi di processo

Quando mappi il lavoro reale end-to-end, la ripetizione si fa notare da sola:

• gli stessi dati riscritti su più moduli,

• gli stessi controlli eseguiti in aree diverse dell’organizzazione,

• la stessa eccezione gestita a mano ogni mattina,

• la stessa spiegazione di training data in modo diverso da ogni responsabile.

Nel codice, DRY chiede: perché la stessa conoscenza è archiviata in più punti?
Nella progettazione dei processi, DRY chiede: perché l’organizzazione deve “ri-derivare” la stessa decisione o lo stesso step di lavoro più volte, e perché è consentito che diverga?

Questa domanda non è digitale. È operativa.

DRY/WET tradotti nel linguaggio dei processi

Questa è la mappatura più pulita che ho trovato in pratica:

In termini di governance BPM, molte organizzazioni puntano esplicitamente a una fonte unica di verità per la documentazione di processo, perché la frammentazione crea rischio di compliance e di esecuzione.

Ma c’è una sfumatura pratica importante: eliminare la duplicazione non è sempre l’obiettivo.

Una correzione necessaria: alcune ripetizioni sono intenzionali

Nel software, un eccesso di DRY può creare astrazioni fragili. Nelle operations, un eccesso di DRY spesso si manifesta così:

• una procedura universale che nessuno riesce davvero a seguire,

• decisioni centralizzate che diventano colli di bottiglia,

• “standardizzazione” che ignora il contesto,

• workaround locali che ricreano WET nell’ombra.

Ancora più importante: alcune ripetizioni sono un meccanismo di controllo. Controlli indipendenti, doppie firme e routine di sicurezza sono “lavoro duplicato” per scelta. Non è WET; è gestione del rischio.

Una regola operativa pragmatica è:

Rendi DRY regole e definizioni. Duplica i controlli solo quando il rischio lo giustifica.

“Automazione” prima dei computer: la catena analogica di codifica della ripetizione

Se restiamo totalmente nel mondo analogico, “automazione” non significa software. Significa codificare la ripetizione in meccanismi in modo che il lavoro diventi affidabile ed economico, attraverso strumenti, layout, procedure e segnali.

Una scala storica utile può essere questa:

1) Meccanizzazione: lasciare che la natura svolga il lavoro ripetitivo

Un mulino ad acqua usa l’energia idraulica per azionare lavoro meccanico come macinazione (grinding), laminazione o battitura, sostituendo fatica umana ripetuta con un meccanismo ripetibile.

Molto prima del digitale, questa è la mossa centrale: il lavoro ripetuto diventa un comportamento di sistema.

2) Metodi e misurazione: rendere il lavoro osservabile e riprogettabile

Lo studio tempi e metodi combina time study e motion study per analizzare e migliorare i sistemi di lavoro scomponendo le attività, misurando e riprogettando il metodo. [Approfondisci]

Qui DRY si applica al movimento umano: smettere di “reinventare” il metodo e convergere su una baseline insegnabile.

3) Flusso e sequenza: codificare l’ordine nell’ambiente

La catena di montaggio mobile è un’idea semplice ma potente: codificare sequenza e ritmo nel sistema produttivo, così il lavoro arriva nell’ordine previsto. Lo stabilimento Ford di Highland Park introdusse la catena di montaggio mobile per la produzione automobilistica nel 1913, con tappe spesso citate in ottobre e dicembre di quell’anno.

4) Segnali e pull: codificare le decisioni in token

Un kanban è un dispositivo di segnalazione che autorizza produzione o prelievo di articoli in un sistema pull, spesso implementato come schede fisiche.

In sostanza, è una decisione “esteriorizzata” dalla memoria in una convenzione condivisa.

5) Lavoro standard: codificare il miglior metodo noto in una baseline

Nel Lean, il “lavoro standard” formalizza tipicamente elementi come sequenza di lavoro, tempi/takt e work-in-process standard, così il sistema ha stabilità e il miglioramento ha un punto di riferimento.

L’intento non è burocrazia: è ridurre la variabilità casuale e rendere il miglioramento reale, non retorico.

Nota il pattern costante: più qualcosa si ripete, più c’è valore nel codificarlo, anche se la codifica è carta, attrezzature o flusso fisico.

Un breve esempio: dove “basta seguire il processo” crolla

Uno dei pattern WET più comuni che vedo (soprattutto nei servizi) assomiglia a questo:

Una richiesta cliente entra da tre canali. Ogni canale ha il suo modulo di intake. Ogni modulo usa definizioni leggermente diverse per gli stessi campi. A valle, qualcuno riconcilia le differenze a mano “perché ci serve nel template che si aspetta finance”. Finance poi ri-valida perché non si fida dei dati upstream. Le operations ricontrollano perché finance a volte blocca elementi tardi.

Nessun singolo passaggio è irrazionale, preso da solo. Ma l’intero sistema è WET: la stessa conoscenza (cos’è la richiesta, cosa qualifica, quali dati servono) esiste in più rappresentazioni, quindi tutti compensano con altra ripetizione.

La soluzione, in un framing solo analogico, non è “fare più training”. È rendere il sistema meno dipendente dalla ricostruzione:

• una definizione autorevole dei dati richiesti,

• un set di regole autorevole per la qualificazione,

• un pattern di intake con varianti controllate (per canale, lingua o tipo cliente),

• un meccanismo di controllo visibile per le eccezioni.

Questo è “process DRY”.

Come PM e BPM rendono più nitida la lente DRY

Anche se non digitalizzi mai, un buon PM e un buon BPM migliorano la tua capacità di applicare DRY senza trasformarlo in dogma.

PM: scomposizione e confini di controllo

Le discipline di project management (quando fatte bene) impongono chiarezza su perimetro e interfacce: cosa sta dentro il sistema, cosa è dipendenza esterna, dove le approvazioni cambiano davvero il rischio e dove sono solo tradizione. Questa definizione dei confini è essenziale per evitare astrazioni “DRY ovunque” che ignorano la realtà.

BPM: architettura e governance di processo

Il BPM porta un altro punto di forza: tratta i processi come asset che richiedono ownership, versioning e governance. In pratica, questo spinge verso un repository coerente e una “fonte unica di verità” per la conoscenza di processo, perché la duplicazione non governata diventa un rischio di compliance e di esecuzione.

La sintesi è semplice:

• Il PM ti tiene onesto su vincoli, interfacce e rischio.

• Il BPM ti tiene onesto su coerenza, ownership e deriva nel tempo.

Indicazioni pratiche: “process DRY” senza passare al digitale

Puoi fare process DRY in modo significativo con carta, layout e disciplina:

1. Rendi le regole esplicite e univoche.
   Se una regola cambia, deve esistere un solo punto in cui aggiornarla (e un modo controllato per propagare l’aggiornamento).

2. Standardizza il nucleo ripetibile, non le eccezioni.
   Il lavoro standard è una baseline per stabilità e miglioramento, non una negazione del contesto.

Esternalizza le decisioni ricorrenti in segnali visibili.
Il kanban è un esempio canonico: la decisione su “quando reintegrare” diventa un token e una convenzione.

1. Codifica vincoli in moduli, strumenti e flusso fisico.
   Template, moduli precompilati, contenitori etichettati, instradamento e checklist sono “regole di validazione” analogiche. Ridimensionano la dipendenza da memoria e interpretazione.

Progettare prima, digitalizzare dopo

DRY nasce nel software, ma descrive una realtà operativa molto più antica: la conoscenza duplicata si disallinea, e il disallineamento crea costo. Nella progettazione dei processi, la strada analogica verso l’automazione è spesso disponibile prima di quella digitale, attraverso lavoro standard, flusso fisico, template, checklist e sistemi di segnalazione.

Se poi digitalizzi, puoi guadagnare velocità. Ma se prima rendi coerente il sistema analogico, guadagni qualcosa di più prezioso: prevedibilità.