La gestione di un progetto di sistema informativo (SI), come un progetto ERP, si basa fortemente sulla disponibilità delle risorse umane.
La Gestione della Conoscenza (“Knowledge Management” o KM) è un processo fondamentale che consiste nell'utilizzare le conoscenze esistenti e nell'acquisirne di nuove per raggiungere gli obiettivi del progetto.
In un ambiente di progetto informatico, dove l'approccio richiede una continuità nel team di progetto, il capo progetto deve attuare una strategia attiva per garantire la sostenibilità del sapere ed evitare che il progetto venga compromesso.
Il rischio del sapiente unico e il furto di conoscenze
La conoscenza si divide in due categorie principali: la conoscenza esplicita (facilmente codificabile tramite parole o documenti) e la conoscenza tacita (personale, difficile da esprimere, che risiede nell'esperienza e nel "savoir-faire" degli esperti).
Il tranello del "sapiente unico" si manifesta quando il progetto dipende eccessivamente da questa conoscenza tacita detenuta da un solo individuo o da un piccolo gruppo.
Questo rischio è considerevolmente aggravato da diversi fattori inerenti ai progetti:
Frequente rinnovamento del personale del team di progetto:
Una forza lavoro sempre più mobile e temporanea rende necessario un processo più rigoroso per il trasferimento delle conoscenze. Il capo progetto deve anticipare il rischio indotto dalla fuga del sapere o del “savoir-faire”, in particolare accentuato dall'arrivo alla pensione delle numerose generazioni e dall'aumento del “turnover” del personale.
Percezione della conoscenza come potere:
Il sapere è spesso percepito come un'arma di potere o di influenza. La trasmissione di questa conoscenza può essere assimilata a una perdita di capacità d'influenza, il che genera una riluttanza alla condivisione all'interno dei team. Se le persone non sono incoraggiate a condividere ciò che sanno, anche i migliori strumenti di “Knowledge Management3 (KM) non funzioneranno.
Team mal definito o utenti chiave non assegnati:
L'assenza di una chiara definizione dei ruoli, delle responsabilità e delle competenze necessarie rende difficile l'identificazione dei detentori di conoscenze e il trasferimento mirato. La mancanza di interlocutori con potere decisionale è un fattore di rischio per il progetto.
Dipendenza dalla conoscenza tacita:
Il rischio si manifesta quando il progetto si basa troppo sul sapere personale, l'esperienza e il " savoir-faire » di un solo individuo o di un piccolo gruppo, poiché questa conoscenza è difficile da formalizzare e condividere.
La gestione della conoscenza come apprendimento organizzativo
Il processo di gestione della conoscenza del progetto mira non solo a sfruttare le conoscenze organizzative pregresse, ma anche a capitalizzare i ritorni di esperienza tratti dal progetto disponibili per i lavori futuri.
Per questo, il capo progetto deve implementare una combinazione di strumenti e tecniche di gestione della conoscenza (incentrati sugli scambi tra le persone) e di gestione dell'informazione (codificazione delle conoscenze esplicite).
Coinvolgere il team e le funzioni aziendali per la condivisione
La gestione della conoscenza richiede la creazione di un'atmosfera di fiducia per favorire la condivisione.
- Designare i Referenti Funzionali (Key Users) : Il cliente deve designare e coinvolgere gli esperti di ogni dipartimento fin dalla fase di inquadramento.
- Incoraggiare la Cooperazione e l'Appropriazione : Il capo progetto deve dinamizzare la cooperazione e il libero scambio, poiché non può sapere tutto. Il team deve sentirsi mobilitato intorno all'appropriazione e allo sviluppo delle proprie conoscenze.
- Gestire il coinvolgimento delle funzioni aziendali (Key users) : Gli utenti finali sono attori principali, forza di validazione e di proposta. Per un progetto ERP, un buon controllo dei flussi deve essere rappresentata da una o più persone aventi potere decisionale, disponibili e motivate. La partecipazione degli utenti alla definizione dei requisiti è cruciale. Il capo progetto deve lavorare per creare condizioni favorevoli alla mobilitazione del suo team, poiché se il progetto è vissuto come un vincolo, il coinvolgimento ne sarà ridotto.
- Definire chiaramente ruoli e competenze : Analizzare le competenze necessarie per l'esecuzione dei compiti e individualizzare gli obiettivi. Assicurarsi che i membri del team posseggano le attitudini richieste; in caso contrario, devono essere intraprese azioni proattive come la formazione o un tutoraggio.
Formalizzare, capitalizzare e trasferire il sapere
Per ovviare all'instabilità dei team e alla dipendenza dal sapere tacito, la formalizzazione è vitale.
Questa formalizzazione passa attraverso l'utilizzo di strumenti specifici:
- Il repository documentale unico : Le fonti documentali di un progetto sono numerose e varie: comprendono, tra l'altro, gli appunti presi durante le sessioni di analisi, i documenti di analisi funzionale (Functional Requirements Document o FRD), i verbali di workshop, i documenti di presentazione dei “mock up”, i supporti di formazione, nonché la lista dei test. Per ottimizzare la condivisione e la consultazione di queste conoscenze esplicite, l'utilizzo di una piattaforma collaborativa come SharePoint è essenziale. Questo tipo di software permette di stabilire un repository unico con una arborescenza strutturata e standardizzata che deve essere mantenuta in modo coerente da un progetto all'altro al fine di facilitare la ricerca e la capitalizzazione delle informazioni.
- L'utilizzo di Onenote (https://onenote.cloud.microsoft/) in modalità condivisa tramite Onedrive può completare SharePoint servendo da spazio di lavoro dinamico e flessibile per la documentazione viva (wikis, gestione dei requisiti e note di riunione). Mentre SharePoint assicura l'archiviazione formale, sicura e verificabile dei documenti finali (specifiche firmate e manuali validati), Onenote massimizza l'agilità e la collaborazione quotidiana del team di progetto. La sua integrazione con Teams e tutti i software della suite Office è un vantaggio molto interessante. Coloro che preferirebbero una soluzione più completa per gestire uno spazio di lavoro condiviso possono utilizzare Notion ([https://www.notion.com/]).
- Il registro delle lezioni apprese: Questo documento è sfortunatamente uno strumento molto poco utilizzato, mirato a registrare le conoscenze acquisite lungo tutto il progetto, successi come difficoltà, affinché possano essere sfruttate per migliorare i progetti futuri. Si distingue dal Registro dei rischi che, invece, è un documento proattivo utilizzato per identificare, analizzare, pianificare risposte e monitorare le minacce e le opportunità potenziali suscettibili di influenzare gli obiettivi del progetto prima che si realizzino.
Questi strumenti sono solo un supporto per l'archiviazione e la messa a disposizione delle informazioni; sono i membri del team che devono utilizzarli e alimentarli. Per facilitare questo approccio, è essenziale mettere in atto eventi o azioni mirate.
- Gli Scambi Informali Strutturati : È importante integrare momenti di scambio informale come i stand up meetings o le pause caffè organizzate nelle abitudini del team di progetto. Questi momenti di co
- presenza sono potenti catalizzatori della conoscenza tacita, permettendo agli esperti di condividere il loro "savoir faire" e i loro "trucchi" in un contesto meno restrittivo della riunione formale.
- Workshop : Per far emergere discussioni e identificare i punti di forza e di debolezza del progetto, il ricorso a workshop, interviste specifiche o riunioni di tipo " Show & Tell » è un buon modo per provocare uno scambio di informazioni su un tema del progetto.
Leadership e attitudine del capo progetto
L'attitudine del capo progetto è un fattore chiave per il mantenimento della motivazione e della gestione delle conoscenze.
- Essere Esemplare e Delegante : Il capo progetto deve ammettere che non ha bisogno di sapere tutto né di fare tutto. Deve delegare per responsabilizzare, trasformando il sapiente unico in facilitatore.
- Adottare uno stile di Management adattato : Il capo progetto deve adattare il suo stile di leadership in funzione della competenza del membro del team per un dato compito (direttivo, persuasivo, partecipativo o delegante). In particolare, se la persona è molto competente (più esperta del capo progetto), deve praticare il management delegante per lasciargli l'autonomia e la creatività necessarie.
- Non Imporre la Knoledge Managment : Bisogna evitare di imporre un repository di conoscenze per autorità gerarchica, il che comporta una mancanza di motivazione e informazioni elementari inutili. Il capo progetto deve lasciare che il suo team si appropri del repository.
- Vigilanza sui Fattori di Fallimento : Il capo progetto deve essere vigile sui fattori che conducono al fallimento del KM, come l'assimilazione del repository a un vincolo o una mancanza di stabilità delle informazioni.
In definitiva, per un progetto ERP, la gestione della conoscenza è un fattore importante di diminuzione dei rischi di perdita di conoscenza. Il capo progetto, in quanto leader e federatore, assicura la sostenibilità del sapere creando un ambiente collaborativo e metodologico che incoraggia la condivisione (tacita, anche tramite scambi informali, ed esplicita) e neutralizza il rischio di dipendenza dal sapere individuale e l'impatto negativo del turnover.