- Il sapere operativo di un’azienda è quasi tutto tacito: vive nella testa di chi fa il lavoro, non nei documenti, e nessuno lo ha mai scritto per intero.
- Il paradosso è che chi è bravo in un processo non sa più spiegarlo: lo ha automatizzato, e alla domanda «come fai?» risponde «dipende» o «di solito».
- Il trucco non è chiedere la teoria, è chiedere l’ultima volta reale: un caso concreto, con nomi e numeri, e poi scavare su ogni «di solito» e «dipende».
- Quel sapere diventa utile a un agente solo quando è scritto come regole con la fonte, validate da chi le ha dette. Da lì il company brain, e l’agente che ci lavora sopra.
Quello che tiene in piedi l’azienda non è scritto da nessuna parte
In quasi ogni azienda, la parte che conta di come si lavora non è in un manuale: è nella testa di chi fa il lavoro tutti i giorni. Quale fornitore chiamare quando quello di fiducia è pieno, come si tratta un cliente che protesta, quando si fa un’eccezione e quando no. È conoscenza tacita: reale, preziosa, e invisibile, perché nessuno l’ha mai scritta per intero. Finché quella persona c’è, tutto fila. Il giorno che manca, o che il team raddoppia, il processo si inceppa.
C’è un paradosso che rende il problema più difficile di quanto sembri: chi è davvero bravo in un processo, quel processo non sa più spiegarlo. Lo ha ripetuto così tante volte che è diventato automatico, come guidare o allacciarsi le scarpe. Se gli chiedi «come decidi?», la risposta onesta è «dipende», oppure «di solito faccio così, ma non sempre». Non ti sta nascondendo niente: semplicemente il sapere è sceso sotto il livello delle parole. Tirarlo fuori è il lavoro vero.
Chi è bravo in un processo non sa spiegartelo, perché lo ha automatizzato dentro di sé. Il tuo compito non è chiedere la regola: è farla riaffiorare da un caso reale.
Non chiedere «come funziona»: chiedi «l’ultima volta com’è andata»
La domanda che non funziona è quella astratta: «come gestisci un reclamo?». Costringe la persona a inventare una versione pulita e teorica che non corrisponde a come lavora davvero, e ti riempie di «di solito» e «in genere». La domanda che funziona è concreta e al passato: «l’ultima volta che è arrivato un reclamo, cos’è successo? Chi era il cliente, cosa ha scritto, cosa hai fatto tu, riga per riga?». Il caso reale non si può edulcorare: ha nomi, tempi, un esito.
Da lì il metodo è scavare, non annuire. Ogni volta che senti un «di solito» o un «dipende», fermati e chiedi da cosa dipende: «di solito rispondo entro un’ora, tranne quando…», e quel «tranne quando» è la regola vera, ed è esattamente ciò che un agente deve sapere. Fai raccontare due o tre casi diversi, incluso quello andato storto, e le eccezioni emergono da sole. Non stai facendo un’intervista giornalistica: stai portando in superficie un algoritmo che la persona esegue senza vederlo.
Intervista, trascrizione, regole con la fonte
Il metodo, per esteso, è semplice e ripetibile: due o tre interviste 1:1 con chi conosce il lavoro, registrate e trascritte, poi trasformate in file strutturati, decisioni, regole, glossario, domande aperte, e validate con la persona. Non è un processo tecnico: è un trasferimento di conoscenza tra una testa e dei file leggibili. L’abbiamo scritto passo per passo qui: come costruire un company brain su file.
Più le istruzioni, le automazioni delle routine e un esempio reale già compilato da cui copiare.
Il kit open source cowork-os ti dà la struttura pronta dove far atterrare quelle risposte: cartelle per il contesto, le decisioni e le regole, con un esempio già compilato da cui copiare. Non parti dal foglio bianco: incolli un file, rispondi a sei domande e il workspace si costruisce da solo, pronto ad accogliere il sapere che stai tirando fuori dalle interviste.
Una regola con la fonte è qualcosa che un agente può applicare
La differenza tra un appunto e una regola operativa è la fonte. «I resi oltre i 30 giorni si rifiutano» è un’opinione finché non è tracciabile; «i resi oltre i 30 giorni si rifiutano, decisione presa il 12 marzo perché la logistica non regge oltre, salvo clienti premium» è una regola: ha un motivo, una data, un’eccezione. Scritta così, una persona nuova la applica senza chiedere, e un agente pure. È questo che rende il company brain diverso da una wiki: non racconta com’è fatto, dice come si decide, adesso.
Questo è anche il salto che porta un’azienda in alto sulla scala di maturità: da un sapere che vive nelle teste (L0) a un contesto strutturato e vivo che persone e agenti leggono. Se vuoi sapere da che livello parti e qual è il passo dopo, fai l’auto-diagnosi. Quando poi vuoi passare dal contesto all’agente vero e proprio dentro il workspace, il metodo per lavorarci sopra è in Claude Cowork.
Questo è il passo di estrazione, non tutto il lavoro
Vale la pena essere onesti sul perimetro: tirare fuori la conoscenza tacita è solo il primo passo, non l’intero company brain. L’intervista serve quando il sapere vive in una testa e nessuno l’ha mai scritto; non serve quando il processo è già documentato bene e stabile, o quando cambia ogni settimana e qualsiasi regola scritta nasce già vecchia. E da sola non basta: le regole estratte vanno strutturate in file, validate, e mantenute quando la realtà cambia. Il metodo completo, dall’intervista fino al workspace governato, è qui: come costruire un company brain su file.
Se invece hai già il contesto e vuoi passare all’agente che lavora su un processo reale, con prezzo e tempi fissi, guarda gli agenti AI per aziende.
Dal tacito all’agente, in pratica
Cos’è la conoscenza tacita, in un’azienda?
È il sapere operativo che vive nella testa di chi fa il lavoro e che nessuno ha mai scritto per intero: quale eccezione fare, quale fornitore chiamare, come si tratta un caso difficile. È reale e preziosa, ma invisibile, e sparisce quando la persona manca o il team cresce. Trasformarla in contesto leggibile è il primo passo per far lavorare un agente sul processo.
Perché chi conosce un processo non sa spiegarlo?
Perché lo ha ripetuto così tante volte che è diventato automatico, come guidare. Il sapere è sceso sotto il livello delle parole, e alla domanda «come fai?» la risposta onesta è «dipende». Non è reticenza: è competenza automatizzata. Per questo non si chiede la teoria, si parte da un caso reale e si scava sui «di solito» e i «dipende».
Come si fa un’intervista per estrarre il sapere tacito?
Non chiedendo «come funziona», ma «l’ultima volta com’è andata»: un caso concreto, con nomi e numeri, raccontato riga per riga. Ogni «di solito» o «dipende» è un segnale: fermati e chiedi da cosa dipende, perché lì c’è la regola vera. Fai raccontare due o tre casi, incluso quello andato storto, registra, trascrivi e trasforma le risposte in regole con la fonte.
Cosa deve sapere un agente per applicare un processo?
Regole con la fonte, non appunti. Una regola operativa ha un motivo, una data e un’eccezione: così una persona nuova la applica senza chiedere, e un agente pure. Un agente non fallisce perché il modello è debole, ma perché non conosce il contesto dell’azienda: il company brain è quel contesto, scritto in modo che sia leggibile da persone e agenti insieme.
Fonti
- [1]cowork-os, repository open source. github.com
Questa pagina è scritta da Raffaele Zarrelli e Simone Bova, founder di Yempik, con editing fatto con Claude. Il company brain e il suo maturity model sono modelli editoriali di Yempik. Il kit citato è il nostro open source cowork-os (licenza MIT). Gli esempi di processo sono illustrativi.
Hai una persona che «sa tutto» e non ha tempo di scriverlo?
Facciamo noi l’intervista. Partiamo da un processo reale, tiriamo fuori le regole e le eccezioni, e le mettiamo in file tuoi, governati, che il team e un agente possono rileggere e applicare. Prezzo e tempi fissi, il codice è tuo.