Ciao a tutti. Dopo è passato già mezzo anno, durante il quale ho avuto l'opportunità di parlare a due conferenze e tenere lezioni sulla gestione della conoscenza in due importanti aziende IT. Parlando con i colleghi, ho compreso che nel settore IT si può ancora trattare la gestione della conoscenza a un livello «principiante», ovvero semplicemente riconoscere che la gestione della conoscenza è necessaria per qualsiasi reparto di qualsiasi azienda. Oggi presenterò il mio minimo personale esperienza - vorrei esaminare gli standard internazionali esistenti nella gestione della conoscenza.
Iniziamo, probabilmente, con il marchio più famoso nel settore della standardizzazione – ISO. Immaginate, esiste un intero standard dedicato ai sistemi di gestione della conoscenza (ISO 30401:2018). Ma oggi non mi fermerò su di esso. Prima di capire 'come' dovrebbe apparire e funzionare un sistema di gestione della conoscenza, dobbiamo concordare che in linea di principio è necessario.
Prendiamo, ad esempio, ISO 9001:2015 (Sistemi di gestione della qualità). Come si evince dal titolo, questo standard è dedicato al sistema di gestione della qualità. Per essere certificata secondo questo standard, un'organizzazione deve garantire la trasparenza e la continuità dei processi lavorativi e dei prodotti e/o servizi forniti. In altre parole, il certificato significa che nella vostra azienda tutto funziona in modo chiaro e coordinato, capite quali rischi comporta l'attuale organizzazione dei processi, sapete come controllare questi rischi e cercate di minimizzarli.
E che cosa c'entra la gestione della conoscenza? Ecco come:
7.1.6 Conoscenze dell'organizzazione
L'organizzazione deve identificare le conoscenze necessarie per il funzionamento dei suoi processi e per raggiungere la conformità dei prodotti e dei servizi.
Le conoscenze devono essere mantenute e disponibili in un volume necessario.
Nel considerare le mutate necessità e le tendenze, l'organizzazione deve tenere conto delle conoscenze in suo possesso e determinare come ottenere o garantire l'accesso a ulteriori conoscenze e il loro aggiornamento.
NOTE 1. Le conoscenze dell'organizzazione sono conoscenze specifiche dell'organizzazione; in gran parte acquisite sulla base di esperienze.
Le conoscenze sono informazioni che vengono utilizzate e scambiate per raggiungere gli obiettivi dell'organizzazione.
NOTA 2. Le conoscenze dell'organizzazione possono derivare da:
a) fonti interne (ad esempio, proprietà intellettuale; conoscenze acquisite dall'esperienza; conclusioni tratte da progetti falliti o riusciti; raccolta e condivisione di conoscenze ed esperienze non documentate; risultati dei miglioramenti di processi, prodotti e servizi);
b) fonti esterne (ad esempio, standard, comunità scientifica, conferenze, conoscenze acquisite dai clienti e fornitori esterni).
E di seguito, negli allegati:
I requisiti riguardanti le conoscenze dell'organizzazione sono stati introdotti con l'obiettivo di:
a) proteggere l'organizzazione dalla perdita di conoscenze, ad esempio, a causa di:
- turnover del personale;
- mobilità delle informazioni;
b) incentivare l'organizzazione ad acquisire conoscenze, ad esempio, sulla base di:
- apprendimento dall'esperienza;
- mentoring;
- benchmarking.
Quindi, lo standard ISO nel campo della gestione della qualità afferma che, per garantire la qualità delle proprie attività, l'azienda deve occuparsi della gestione delle conoscenze. Proprio così, in modo ineludibile – «deve». Altrimenti non conformità, e arrivederci. Questo fatto stesso suggerisce che non sia un aspetto facoltativo nell'organizzazione, come spesso si considera la gestione delle conoscenze nell'IT, ma una componente obbligatoria dei processi aziendali.
Inoltre, lo standard indica quali rischi la gestione delle conoscenze è intesa a eliminare. In effetti, sono piuttosto evidenti.
Immaginiamo... no, non così – ricordate, per favore, una situazione della vostra carriera in cui avevate assolutamente bisogno di un'informazione lavorativa, ma il suo unico titolare era in quel momento in ferie/missione, si era dimesso dall'azienda o semplicemente era malato. Ricordate? Penso che praticamente ognuno di noi abbia affrontato una situazione simile. Cosa avete provato in quel momento?
Se dopo un po' di tempo la direzione della divisione analizzerà il ritardo nel progetto, certamente troverà un colpevole e su questo si calmerà. Ma per voi, in quel momento, quando le conoscenze erano necessarie, non è servito a nulla capire che "è colpa del PM, che è andato a Bali e non ha lasciato istruzioni in caso di domande". Certamente, è colpevole. Ma la vostra situazione non cambierà.
Se le conoscenze sono documentate in un sistema accessibile alle persone che potrebbero averne bisogno, la storia "da resort" descritta diventa praticamente impossibile. In questo modo si garantisce la continuità dei processi aziendali, il che significa che ferie, assenze dei dipendenti e quel famigerato bus factor non spaventano l'azienda: la qualità del prodotto/servizio rimarrà ai suoi livelli abituali.
Se in azienda esiste una piattaforma per lo scambio e la conservazione di informazioni ed esperienze, e si è sviluppata una cultura (abitudine) nell'uso di questa piattaforma, i dipendenti non devono aspettare giorni per ricevere una risposta da un collega (o addirittura cercare quel collega per giorni) e mettere così in attesa le proprie attività.
Perché parlo di abitudine? Perché è insufficiente creare una base di conoscenze perché venga utilizzata. Siamo tutti abituati a cercare risposte alle nostre domande su Google, mentre l'intranet di solito ci fa pensare a richieste di ferie e bacheche degli annunci. Non abbiamo l'abitudine di "cercare informazioni sui framework Agile" (ad esempio) sull'intranet. Pertanto, anche se avessimo in un attimo una fantastica base di conoscenze, nessuno inizierebbe a usarla nel secondo successivo (e nemmeno nel mese successivo): manca l'abitudine. Cambiare le proprie abitudini è doloroso e lungo. Non tutti sono pronti a farlo. Soprattutto dopo aver "lavorato così per 15 anni". Ma senza questo, l'iniziativa di gestione delle conoscenze in azienda è destinata al fallimento. Ecco perché gli esperti nel campo della gestione delle conoscenze collegano inestricabilmente la gestione delle conoscenze alla gestione del cambiamento.
Vale la pena notare che "Nel considerare i bisogni e le tendenze in cambiamento, l'organizzazione deve tenere conto delle conoscenze che possiede…", ossia sviluppare una cultura di riferimento all'esperienza passata nelle decisioni in un mondo in cambiamento. E notate, di nuovo "deve".
A proposito, in questo breve punto dello standard si parla molto di esperienza. Di solito, quando si parla di gestione della conoscenza, gli stereotipi iniziano a proporre l'immagine di una base di conoscenze con centinaia di documenti, inseriti in forma di file (regolamenti, requisiti). Ma l'ISO parla di esperienza. Le conoscenze acquisite sulla base dell'esperienza passata dell'azienda e di ciascun suo dipendente sono ciò che consente di evitare il rischio di ripetere errori, prendere decisioni più vantaggiose immediatamente e persino creare nuovi prodotti. Nelle aziende più mature nel campo della gestione della conoscenza (compresi, è bene notarlo, anche quelle russe), la gestione della conoscenza è vista come un mezzo per aumentare la capitalizzazione dell'azienda, creare nuovi prodotti, sviluppare nuove idee e ottimizzare i processi. Non è una base di conoscenze, ma un meccanismo per le innovazioni. Per approfondire ulteriormente, ci aiuta Il manuale PMBOK dell'organizzazione PMI.
PMBOK è il manuale che raccoglie le conoscenze sulla gestione dei progetti, il libro di riferimento per il PM. Nella sesta edizione (2016) di questo manuale è apparso un capitolo dedicato alla gestione dell'integrazione del progetto, che a sua volta include una sezione sulla gestione della conoscenza del progetto. Questo punto è stato creato "sulla base dei commenti degli utenti del manuale", cioè è diventato il prodotto dell'esperienza di utilizzo delle versioni precedenti della guida in condizioni reali. E la realtà ha richiesto la gestione della conoscenza!
L'output principale del nuovo punto è il "Registro delle lezioni apprese" (che, tra l'altro, è menzionato anche nello standard ISO descritto sopra). Inoltre, secondo il manuale, la compilazione di questo registro deve avvenire durante tutta la realizzazione del progetto, e non al termine, quando arriva il momento di analizzare il risultato. A mio avviso, questo si ricollega molto alle retrospettive in agile, ma di questo scriverò un post separato. Testualmente, il testo nel PMBOK suona così:
La gestione della conoscenza del progetto è il processo di utilizzo delle conoscenze esistenti e di creazione di nuove conoscenze per raggiungere gli obiettivi del progetto e favorire l'apprendimento nell'organizzazione
L'area di conoscenza "gestione dell'integrazione del progetto" richiede l'integrazione dei risultati ottenuti in tutte le altre aree di conoscenza.
Le tendenze in evoluzione nei processi di integrazione includono, tra l'altro:
…
• Gestione della conoscenza del progetto
La crescente mobilità e la natura sostituibile della forza lavoro richiedono un processo più rigoroso di definizione delle conoscenze lungo l'intero ciclo di vita del progetto e la loro trasmissione ai pubblici target, affinché si eviti la perdita di conoscenze.
***
I principali vantaggi di questo processo consistono nel fatto che le conoscenze precedentemente acquisite dall'organizzazione vengono utilizzate per ottenere o migliorare i risultati del progetto, mentre le conoscenze acquisite durante l'attuazione dell'attuale progetto rimangono accessibili per garantire l'operatività dell'organizzazione e dei progetti futuri o delle loro fasi. Questo processo viene attuato per tutta la durata del progetto.
Non copierò qui l'intero lungo capitolo della guida. Puoi consultarlo autonomamente e trarre le dovute conclusioni. Le citazioni sopra riportate, a mio avviso, sono più che sufficienti. Mi sembra che la presenza di una tale dettagliata descrizione del compito del PM nella gestione della conoscenza del progetto denoti già l'importanza di questo aspetto nel lavoro sui progetti. A proposito, sento spesso l'affermazione: «A chi servono le nostre conoscenze negli altri reparti?» Cioè, a chi servono queste lezioni apprese?
In realtà, spesso si può vedere che la divisione si considera come un "unità in un vuoto". Ecco noi con la nostra biblioteca, e poi c'è tutta l'altra azienda, e le conoscenze sulla nostra biblioteca non le servono in alcun modo. Sulla biblioteca – forse. E sui processi correlati?
Esempio banale: durante il lavoro su un progetto c'è stata interazione con un appaltatore. Ad esempio, con un designer. L'appaltatore si è rivelato mediocre, ha mancato le scadenze e si è rifiutato di completare il lavoro senza un pagamento supplementare. Il PM ha registrato nel registro delle lezioni apprese che non vale la pena lavorare con questo appaltatore inaffidabile. Nel frattempo, nel marketing stavano cercando un designer e si sono imbattuti nello stesso appaltatore. In quel momento ci sono due opzioni:
a) se nella azienda c'è una buona cultura del riutilizzo delle esperienze, un collega del marketing cercherà nel registro delle lezioni apprese se qualcuno ha già avuto a che fare con questo appaltatore, vedrà il feedback negativo dal nostro PM e non perderà tempo e soldi interagendo con questo appaltatore inaffidabile.
b) se in azienda non c'è una tale cultura, il marketer si rivolgerà allo stesso fornitore inaffidabile, perderà soldi per l'azienda, tempo e potrebbe compromettere una campagna promozionale importante e urgente, ad esempio.
Quale opzione sembra più promettente? E notate, l'informazione utile non era sul prodotto in fase di sviluppo, ma sui processi collegati a esso. E questa informazione si è rivelata utile non a un altro PM, ma a un dipendente di un settore completamente diverso. Da ciò deriva la conclusione: non si può considerare lo sviluppo separatamente dalla vendita, il supporto tecnico dall'analisi di business, e l'IT da AHR. Tutti in azienda hanno esperienze lavorative che possono risultare utili a qualcun altro in azienda. E non è affatto detto che siano rappresentanti di settori affini.
D'altra parte, anche l'aspetto tecnico del progetto può essere utile. Provate a svolgere un audit dei progetti nella vostra azienda negli ultimi anni. Rimarrete sorpresi di quanti "biciclette" siano state inventate nella risoluzione di compiti simili. Perché? Perché non ci sono processi di scambio di conoscenze consolidati.
Quindi, la gestione delle conoscenze, secondo le linee guida PMI, è uno dei compiti del PM. Come vediamo, due conosciute organizzazioni che offrono certificazioni a pagamento nei loro standard includono la gestione delle conoscenze tra gli strumenti imprescindibili per il controllo della qualità e la gestione dei progetti. Perché i manager nelle aziende IT continuano a ritenere che la gestione delle conoscenze equivalga alla documentazione? Perché i centri di scambio di conoscenze rimangono la macchinetta del caffè e il fumatore? Il problema è di comprensione e abitudini. Spero che gradualmente la comprensione dell'area di gestione delle conoscenze tra i manager IT aumenterà e che la tradizione orale smetterà di essere uno strumento per la conservazione delle conoscenze in azienda. Studiate gli standard del vostro lavoro: c'è molto di interessante!
Fonte: habr.com
