Quando una procedura diventa affidabile
Quando verifico una base di conoscenza, non comincio dal testo. Cerco prima la versione che l’organizzazione considera valida. Controllo chi l’ha approvata, quale verifica ha ricevuto, quando dovrà essere riesaminata e quale contenuto ha sostituito. Solo dopo leggo la procedura per capire se può guidare davvero il lavoro di una persona.
Questa sequenza può sembrare eccessiva. Se qualcuno cerca una risposta, perché non dovrebbe bastare una pagina chiara e ben scritta? Perché una procedura non serve soltanto a trasmettere istruzioni. Stabilisce una condotta operativa e, quando il contesto richiede responsabilità, deve permettere di ricostruire chi ha deciso che quella condotta fosse ancora valida.
Nel lavoro che svolgo da molti anni tra processi, sistemi digitali e organizzazione della conoscenza, incontro spesso una confusione precisa: si scambia la presenza di un documento per la disponibilità di una fonte affidabile. Un file può trovarsi nel posto giusto e contenere informazioni corrette in origine. Questo non basta a sapere se sia ancora applicabile, se rappresenti l’ultima versione o se qualcuno abbia controllato le conseguenze delle modifiche intervenute nel frattempo.
La differenza emerge con particolare chiarezza nelle organizzazioni sottoposte a vincoli regolamentari. In una grande organizzazione finanziaria, le informazioni necessarie agli operatori sono distribuite fra file, versioni superate delle procedure e messaggi conservati nelle caselle personali. Le persone conoscono il lavoro e spesso sanno riconoscere la risposta corretta. Per offrirla, però, devono ricostruire quale fonte sia ancora valida, quale modifica abbia sostituito quella precedente e chi possa confermare il significato operativo del contenuto.
Da questa situazione derivano due costi. Il primo riguarda il tempo: più gruppi cercano o ricostruiscono informazioni già prodotte altrove. Il secondo riguarda la responsabilità: una procedura può essere consultata senza che risultino con chiarezza il suo stato, la persona che l’ha verificata e la data entro la quale occorre esaminarla di nuovo. Il lavoro procede, ma la sua memoria rimane incompleta.
Il documento attraversa un ciclo di vita
Considero una procedura un oggetto operativo. Viene preparata, esaminata, approvata, pubblicata, aggiornata e, quando diventa superata, sostituita o ritirata. Ogni passaggio richiede una condizione, una persona responsabile e una traccia. Se manca uno di questi elementi, il documento può continuare a circolare senza che l’organizzazione sappia più quale decisione lo sostiene.
Questa lettura avvicina la gestione della conoscenza alla gestione del lavoro. Un’attività possiede stati, transizioni, responsabilità e criteri di conclusione. Anche una procedura li possiede, se l’organizzazione vuole usarla per orientare azioni reali. La differenza riguarda l’oggetto trattato, non la necessità di rendere visibile il percorso.
I sistemi digitali possono rappresentare questo percorso attraverso un workflow. La procedura entra in revisione quando il contenuto è pronto per il controllo previsto. Passa alla pubblicazione dopo l’approvazione. Una scadenza assegna a qualcuno il compito di verificare se il contenuto è ancora valido. Il registro conserva autore, data, stato e sequenza delle operazioni, così la decisione rimane ricostruibile anche quando le persone coinvolte cambiano ruolo.
La documentazione ufficiale di Atlassian descrive il workflow di Jira come l’insieme degli stati e delle transizioni che accompagnano un elemento dalla creazione alla conclusione. La definizione è tecnica, però la conseguenza organizzativa è rilevante: ogni transizione indica che qualcuno ha stabilito quale passaggio sia possibile, chi possa compierlo e quali condizioni debbano essere soddisfatte. La documentazione Atlassian sui workflow di Jira rende esplicito questo legame fra stati, transizioni e processi dell’organizzazione.
La configurazione non stabilisce se una procedura sia corretta. Non sostituisce l’esperienza dell’operatore né il giudizio di chi conosce il contenuto. Può però impedire che una pagina acquisisca il valore di una fonte approvata soltanto perché qualcuno l’ha inserita nell’archivio. La pubblicazione deve dipendere da un passaggio riconoscibile e da una persona che ne assuma la responsabilità.
La conoscenza nasce fra esperienza e registrazione
Il rapporto fra conoscenza tacita e conoscenza esplicita aiuta a capire perché la gestione documentale sia difficile. Un programmatore conosce il motivo di una configurazione. Un responsabile di progetto ricorda quale vincolo abbia spostato una scadenza. Una persona del supporto riconosce dal sintomo la causa più probabile di un errore. Queste competenze nascono dall’esperienza e spesso non si lasciano trasferire attraverso una semplice lista di istruzioni.
La registrazione rimane necessaria perché l’esperienza individuale non è sempre disponibile. Una procedura può conservare una parte di quel sapere, se mantiene anche il contesto: chi ha deciso, quale problema doveva risolvere, quali evidenze ha esaminato, quali alternative ha scartato e fino a quando la decisione rimane valida.
Ikujiro Nonaka descrive la creazione della conoscenza organizzativa come un dialogo continuo fra conoscenza tacita ed esplicita. Il suo modello non autorizza a pensare che basti trasformare ogni esperienza in un documento. Mostra piuttosto che l’organizzazione apprende quando l’esperienza viene messa in comune, resa discutibile, collegata ad altre conoscenze e riportata nella pratica. L’articolo di Nonaka sulla creazione dinamica della conoscenza organizzativa offre una base utile per distinguere la semplice conservazione di informazioni dal lavoro attraverso il quale un gruppo attribuisce loro un significato operativo.
Una pagina approvata non contiene quindi tutta la conoscenza necessaria. Costituisce una fonte che il gruppo riconosce come utilizzabile entro determinate condizioni. La sua affidabilità dipende dalla qualità del contenuto, dalla provenienza, dai collegamenti con il lavoro e dalla possibilità di verificarne la validità nel tempo.
Approvare non significa garantire per sempre
L’approvazione registra una verifica compiuta in una certa data. Non garantisce che il contenuto rimanga valido per sempre. Cambiano norme, prodotti, procedure, ruoli e strumenti. Una scadenza di revisione rende visibile questo passaggio del tempo e assegna a qualcuno il compito di controllarne gli effetti.
Nel lavoro quotidiano la scadenza può sembrare un promemoria amministrativo. In realtà, prolunga la responsabilità oltre il momento della pubblicazione. Chi approva una procedura dichiara che, sulla base delle verifiche compiute, quella versione può guidare un’attività. Chi deve riesaminarla dovrà controllare se le condizioni siano ancora presenti.
Questa distinzione protegge anche chi utilizza il contenuto. Un operatore non deve limitarsi a leggere le istruzioni: deve poter capire se sta consultando una versione corrente, se il contenuto è in revisione e a chi rivolgersi quando trova un’incoerenza. La qualità della conoscenza comprende validità, reperibilità, provenienza e regole di accesso.
Le funzioni di approvazione presenti in Confluence mostrano bene questo punto. La documentazione Atlassian sulle approvazioni di Confluence collega la richiesta di approvazione alla registrazione dei responsabili, dei commenti, dell’esito e della cronologia. Il valore di questa funzione non consiste nel colore associato allo stato. Consiste nella possibilità di rispondere a domande concrete: chi deve verificare, chi ha già risposto, che cosa è stato richiesto e quando è avvenuta la decisione.
Un’approvazione può tuttavia diventare un rito vuoto. Se chi approva non possiede il tempo, le informazioni o l’autorità per valutare il contenuto, il sistema registra un passaggio senza produrre una verifica significativa. La firma digitale della responsabilità non sostituisce la responsabilità reale.
Il workflow mostra la distribuzione dell’autorità
Quando osservo un workflow, cerco la decisione che dovrebbe essere presa in ciascun passaggio. Una persona approva un documento perché possiede l’autorità necessaria? Compila un campo perché quel dato serve a comprendere il caso? Trasferisce una richiesta perché manca una competenza, un accesso o un’autorizzazione? Le risposte distinguono il controllo dal semplice inoltro.
La stessa analisi vale per una richiesta di servizio. La persona che riceve il problema può raccogliere le informazioni, classificarlo e risolverlo. Può anche avere soltanto il permesso di inoltrarlo al gruppo successivo. Le due situazioni producono flussi differenti perché assegnano in modo diverso la possibilità di agire.
Quando il percorso segue i confini dei reparti, il ticket attraversa l’organizzazione interna. Una funzione lo riceve, un’altra controlla il sistema coinvolto, una terza autorizza la modifica e una quarta comunica l’esito. Ogni passaggio può rispondere a un vincolo reale. Può anche ripetere una separazione organizzativa che non aiuta chi deve risolvere il problema. Il ticket continua a muoversi, mentre la richiesta rimane ferma.
La configurazione del workflow diventa così una dichiarazione pratica sull’autorità. L’organigramma mostra posizioni e rapporti formali. Il flusso mostra che cosa una persona può fare, che cosa deve attendere e quale responsabilità lascia dopo l’azione. In alcuni casi il workflow descrive con maggiore precisione la distribuzione del potere rispetto alle dichiarazioni sulla centralità del cliente o sull’autonomia dei gruppi.
Anche gli stati devono avere un significato controllabile. «In revisione» può indicare una verifica tecnica, un’attesa di approvazione oppure un contenuto fermo perché manca una risposta. Se circostanze diverse ricevono lo stesso nome, il sistema conserva meno significato di quanto sembra. La persona che consulta la pagina vede lo stato, però deve ancora capire chi debba intervenire e quale risultato sia atteso.
La documentazione ufficiale di Atlassian avverte che ogni stato e ogni transizione aggiungono complessità al lavoro del gruppo. Il punto è importante: aggiungere precisione al disegno non distribuisce automaticamente meglio l’autorità. Può limitarsi a descrivere con maggiore dettaglio una catena di attese. Un workflow affidabile rende leggibili le decisioni necessarie; un workflow sovraccarico moltiplica i passaggi che le persone devono imparare e mantenere.
La memoria comprende anche le configurazioni
Una parte della memoria organizzativa vive nei testi. Un’altra parte vive nelle configurazioni che stabiliscono quali testi possono essere pubblicati, chi può modificarli, quali approvazioni servono e quando una revisione deve ricominciare.
Quando un gruppo viene accorpato, una responsabilità passa a un’altra funzione o un prodotto viene sostituito, l’organigramma può cambiare mentre il sistema conserva per mesi vecchi ruoli, vecchie code e vecchi permessi. Il workflow continua ad applicare una scelta che nessuno ha più riesaminato.
Prima di modificare uno stato o un’autorizzazione, occorre capire quale rischio intendesse ridurre la regola precedente, quali casi attraversasse e quali rapporti alimentasse con notifiche, automazioni e rapporti. Una migrazione che trasferisce soltanto campi e stati può conservare la forma del processo e perdere la ragione per cui è stato costruito.
Il National Institute of Standards and Technology richiama, nella propria riflessione sulla gestione della conoscenza, la necessità di ruoli chiari, processi sistematici di condivisione, individuazione degli asset conoscitivi e strumenti adeguati all’organizzazione. Il commento NIST sulla gestione della conoscenza organizzativa aiuta a spostare l’attenzione dal semplice archivio alla capacità di rendere il sapere affidabile e utilizzabile.
Una procedura affidabile lascia una traccia
Quando torno a controllare una procedura, parto dalla stessa domanda: chi ha approvato questa versione? Cerco anche il passaggio che ha reso possibile quell’approvazione, le informazioni esaminate e la data del prossimo controllo.
Se il sistema conserva questi elementi, la pagina è collegata a una decisione. Se conserva soltanto il testo e l’ultimo aggiornamento, l’organizzazione possiede un documento. La responsabilità deve ancora essere ricostruita.
La differenza riguarda il modo in cui un gruppo lavora quando la persona che conosceva il contesto non è disponibile. Una procedura affidabile non elimina la necessità dell’esperienza. Riduce però la parte di esperienza che deve essere ricostruita ogni volta da capo. Conserva una decisione, rende visibile la sua durata e indica chi deve verificare se quella decisione continua a valere.
Per questo considero la gestione della conoscenza una pratica di governo. Il documento conserva parole. Il workflow conserva passaggi. L’approvazione conserva una responsabilità. La revisione futura verifica se il rapporto fra quei tre elementi è ancora valido.
Riferimenti
- Atlassian, What are Jira workflows?
- Atlassian, Request and manage approvals in Confluence.
- Ikujiro Nonaka, A Dynamic Theory of Organizational Knowledge Creation, Organization Science, 1994.
- National Institute of Standards and Technology, Baldrige Criteria Commentary.