Trasformare la conoscenza individuale in knowledge base condivisa

Nel post recente sul ruolo del Sistema Informativo, il punto centrale era che il SI deve diventare un patrimonio di conoscenza del proprietario, non un semplice registro di ticket. Qui facciamo il passo operativo successivo: come trasformare la conoscenza “in testa ai tecnici” in una knowledge base condivisa, stabile e riusabile.

Ogni organizzazione FM ha almeno una persona che “sa praticamente tutto”: dove sono le valvole nascoste, quali quadri fanno scherzi, quali UTA hanno logiche strane, quali aree sono sempre inaccessibili, quale fornitore risponde davvero. Se quella persona cambia lavoro o va in pensione e tu non hai codificato quella conoscenza, perdi anni di esperienza e torni a rifare gli stessi errori. La knowledge base è l’unico antidoto pratico.

Perché la conoscenza individuale è un rischio operativo, non solo un problema organizzativo?

Perché crea dipendenza. Quando un guasto complesso si risolve solo chiamando “quello che sa”, stai accettando un single point of failure. Questo impatta tempi di ripristino, qualità degli interventi, e capacità di gestire l’imprevisto. E, soprattutto, ti rende vulnerabile nei cambi appalto: appena cambia squadra, perdi competenza storica sul patrimonio.

In termini pratici, la conoscenza individuale genera tre costi: tempi più lunghi per diagnosi, ripetizione di interventi sbagliati, e maggiore rischio di errori su impianti critici. Trasformarla in knowledge base è un’azione di continuità operativa, non “formazione”.

Perché il SI è il posto giusto dove far vivere la knowledge base (e non un file Word in rete)?

Perché la conoscenza è utile solo se è trovabile nel momento giusto. Se la knowledge base è separata dal flusso di lavoro, nessuno la consulta quando serve e nessuno la aggiorna quando impara qualcosa. Nel SI invece puoi collegarla a asset, location, servizi, procedure e ticket: cioè esattamente ai contesti in cui nasce e serve.

Inoltre, se la knowledge base è nel SI, diventa governabile: versioni, autori, approvazioni, evidenze, e soprattutto misurabilità (quante volte viene usata, su quali problemi, con quale esito). Un Word “in cartella” è solo un cimitero di documenti.

Che cosa intendo per knowledge base “operativa” ?

Una knowledge base operativa non è una raccolta di manuali. È un set di contenuti brevi e riusabili che risolvono frizioni reali: diagnosi ricorrenti, procedure corrette per quel sito, trucchi di accesso, setpoint standard, check di sicurezza, compatibilità ricambi, errori tipici e come evitarli.

La regola è: ogni entry deve ridurre tempo o errori su un caso reale. Se non sai dire quale ticket o quale attività MP migliora, non è una entry: è rumore.

Quali sono i tipi di “conoscenza” che vale la pena catturare per primi?

Vale la pena catturare ciò che genera ritardi e recidive: guasti ricorrenti con diagnosi non ovvie, configurazioni particolari (logiche BMS, sequenze), punti deboli noti di certe famiglie di asset, vincoli di accesso e permessi, e ricambi critici con codici corretti e alternative.

Poi cattura la conoscenza che evita rischi: procedure di messa in sicurezza, lockout/tagout, sequenze di ripristino, e cosa non fare. Nel FM una “dritta” sbagliata è pericolosa; meglio poche schede ben validate che cento appunti non verificati.

Anche un tipo di ticket può diventare conoscenza riutilizzabile. Serve un meccanismo semplice: quando un ticket è stato difficile, ha richiesto più uscite, o ha evidenziato una regola “non scritta”, deve poter generare una bozza di scheda KB con un click. Non deve essere un’attività separata e opzionale che nessuno fa.

La scheda deve essere strutturata in modo standard: sintomo, contesto (asset/location), causa più probabile, verifica rapida, soluzione, rischi/attenzioni, e riferimenti (foto, schemi, ticket ID). Se rendi il formato sempre uguale e breve, la produzione diventa sostenibile.

Chi deve scrivere e chi deve validare, per evitare che la KB diventi piena di “opinioni”?

Chi scrive è spesso chi ha risolto: tecnico, specialista, fornitore. Ma chi valida deve essere un owner tecnico o un responsabile di disciplina, perché una KB non validata può diffondere pratiche scorrette o pericolose.

Il modello che funziona è leggero: bozza rapida dal campo, validazione a campione sulle schede importanti (impianti critici, safety, procedure speciali), e pubblicazione con versione. Non serve un comitato: serve una responsabilità chiara.

Come collego la knowledge base agli asset e alle location per renderla davvero riusabile?

Devi legare ogni scheda a uno o più “punti di aggancio” nel SI: asset (o famiglia asset), location/area tecnica, servizio/disciplina, e tag di sintomo. Così quando un tecnico apre un ticket su quell’asset o in quella zona, il sistema può suggerire automaticamente le schede rilevanti.

Questo si sposa con ciò che abbiamo discusso sulla qualità dell’anagrafica e sulle unità di lavoro (pacchetti, componenti virtuali): se asset e location sono incoerenti, anche la KB non si trova. La KB amplifica la qualità del SI, e viceversa.

Come collego la KB alla manutenzione programmata (MP) per farla diventare competenza “di sistema”?

La KB non serve solo per la correttiva. Serve anche per migliorare le procedure MP: se in MP emergono sempre gli stessi problemi (asset non accessibile, misure fuori range, filtri sempre intasati), la KB deve alimentare un aggiornamento della checklist e della pianificazione.

Questo crea un circuito virtuoso: la MP genera osservazioni, la KB codifica le regole e le eccezioni, e poi la procedura viene aggiornata. È il modo più concreto per trasformare esperienza in best practice ingegneristica applicata.

Come evito di perdere la conoscenza quando cambia fornitore o se ne va “chi sa tutto”?

Devi rendere la KB parte della consegna e del ciclo di contratto: non un extra. Ciò significa prevedere che la KB sia di proprietà del committente, che viva nel SI (o in repository controllato dal committente) e che sia aggiornata con continuità. Se la KB è “del fornitore”, alla fine del contratto te la portano via, e hai perso l’obiettivo.

Operativamente, quando entra un nuovo fornitore, la KB diventa materiale di onboarding: invece di “imparare sul campo per sei mesi”, studi le schede per i punti critici del sito. Questo riduce errori e riduce la dipendenza dal singolo esperto storico.

Come si collega tutto questo al valore del SI per il proprietario, come discusso nel post precedente?

Nel post precedente abbiamo detto che il SI deve essere arricchito e analizzato nel corso degli anni per migliorare la gestione del patrimonio. La knowledge base è l’anello mancante: trasforma dati e ticket in regole e competenze riusabili. Senza KB, hai storico ma non apprendimento. Con KB, lo storico diventa istruzione operativa e riduzione di rischio.

Per il proprietario, la KB è anche una leva di indipendenza: riduce il lock-in verso persone e fornitori, perché la conoscenza critica è codificata e governata.

Conclusioni

Trasformare la conoscenza individuale in knowledge base condivisa significa ridurre dipendenza da singoli tecnici e rendere il patrimonio più governabile nel tempo, soprattutto per i proprietari. La chiave è trattare la KB come parte del Sistema Informativo, collegata ad asset e location, con formati brevi e standard, validazione minima e misurazione dell’uso.

Così eviti il rischio più comune nel FM: perdere in un giorno ciò che hai imparato in anni, solo perché “se ne va chi sa tutto”. Una knowledge base ben fatta non è cultura aziendale: è continuità operativa, efficienza e capacità di migliorare davvero il patrimonio nel tempo.