Questo articolo è stato aggiornato dopo la pubblicazione originale
 

Proseguiamo la rassegna delle 5 più comuni problematiche nelle implementazioni LIMS e nella seconda puntata di questa serie (trovate la prima parte qui) trattiamo di un aspetto che se trascurato può diventare nei casi peggiori il “killer silenzioso” di un progetto.

2 – Non corretta identificazione di ruoli e responsabilità

L’implementazione di un sistema LIMS è un progetto e come tale, pur essendo caratterizzato da specificità tipiche del dominio di applicazione (ossia l’Information Technology), condivide le proprietà più generali della definizione di “progetto” cosa che ci permette di adottare utili similitudini.

Pensiamo a un progetto finalizzato alla costruzione di un’abitazione. I futuri inquilini (il Cliente) entro i limiti finanziari del budget a disposizione e fisici della superficie e volumetria assegnata esprimono i propri desideri (Requisiti) in termini ad esempio di numero di vani e loro orientamento, collocazione di porte e finestre, materiali e finiture ecc. Il progettista trasforma tutto ciò in un documento (Specifiche) conforme alla normativa esistente in materia. L’approvazione del piano di progetto da parte di tutti gli attori coinvolti dà luogo all’inizio lavori da parte dell’impresa costruttrice (Fornitore). Si potrebbe pensare che Fornitore e Cliente perseguano lo stesso fine, ma non si può negare che l’interesse delle due parti sia di natura profondamente diversa: l’interesse del primo è quello di costruire un’abitazione al meglio delle proprie competenze, professionalità ed esperienza rispettando scrupolosamente il piano di lavoro concordato; l’interesse del secondo è viverci.

È quindi opportuno che il Cliente eserciti un controllo costante sulle attività svolte durante tutta la durata del progetto e fornisca le proprie fondamentali indicazioni qualora sia necessario discutere di tutto ciò che non è stato possibile includere nel documento di specifiche tecniche o riveli l’insorgere di potenziali deviazioni rispetto al piano originario.

In maniera analoga, sebbene l’implementazione di un sistema LIMS coinvolga principalmente le risorse del team di progetto costituito dal Fornitore, la partecipazione di rappresentanti del Cliente non va sottovalutata e deve essere adeguatamente pianificata sin dal principio. Come nella metafora della costuzione di una casa, l’obiettivo del progetto è realizzare un sistema informativo destinato a gestire dati e processi aziendali vitali per il business del Cliente, ed è pertanto nell’interesse di quest’ultimo che il proprio gruppo di lavoro sia disponibile, presti la massima attenzione alle attività di progetto che lo riguardano e rispetti i compiti e le tempistiche pianificate.

 Tutto ciò richiede una non trascurabile quantità di tempo che purtroppo spesso si scontra con la realtà in cui si inserisce il progetto LIMS. Innanzitutto gli utenti coinvolti sono i medesimi che devono portare avanti anche le quotidiane attività nei laboratori. Inoltre il business del Cliente non si può ovviamente fermare durante l’implementazione del progetto: un audit da parte di un ente regolatorio esterno o cliente, una attività imprevista e urgente, ecc. possono comportare  la temporanea sospensione delle attività e conseguenti ritardi.

 Come mitigare l’impatto di queste situazioni?

 Innanzitutto è importante pervenire a una corretta identificazione di ruoli e responsabilità. Questa attività, a cui gli addetti ai lavori danno spesso il nome di stakeholder analysis, permette di far emergere tutte le figure appartenenti alla propria organizzazione che il Cliente deve mettere a disposizione del progetto in modo che ne diventino, se il caso, risorse con attività assegnate di ben definita tipologia e durata.

Si può così scoprire e opportunamente gestire nella formulazione del project plan (come mi è capitato di sperimentare in situazioni reali) che, per esempio, la fase 1 del progetto dovrà essere formalmente chiusa con approvazione da parte del Direttore di Dipartimento nell’ultima settimana di maggio, che tradizionalmente coincide con il periodo in cui l’azienda discute il budget per l’anno successivo. Oppure che il workshop per la discussione della soluzione proposta a un determinato insieme di requisiti richiede la presenza di un determinato esperto (subject matter expert) e si svolgerà in date nelle quali quest’ultimo sarà impegnato in un corso di aggiornamento.

L’esito di questa analisi consente inoltre di valutare possibili scenari nei quali una determinata risorsa del Cliente risulti non disponibile a causa di eventi probabili ma non certi (come un audit, per esempio) in una delle fasi critiche del progetto e valutarne il conseguente impatto in termini di tempi e costi.

Viene in aiuto in questi casi l’adozione di tecniche di “ridondanza” che consistono nel prevedere accanto alle risorse di progetto “primarie” l’affiancamento di risorse “secondarie” aventi conoscenza equivalente per  quanto concerne le rispettive competenze, siano periodicamente ragguagliate sullo stato del progetto e possano in caso di emergenza sostituire con facoltà decisionale le risorse primarie temporaneamente non disponibili.

Questi accorgimenti consentono di rendere più robusta la struttura tipica dei team di progetto che in LABVANTAGE è costruita attorno a queste figure tipiche:

  • Project Manager (PM): responsabile del raggiungimento finale degli obiettivi di progetto nel rispetto delle 3 dimensioni principali di valutazione di ogni progetto: “scopo/qualità”, “costi”, “tempi”. Generalmente esiste una figura di PM sia lato fornitore che lato cliente
  • Business Analyst (BA): colui o colei che conosce in maniera approfondita il sistema LIMS e ha il compito di tradurre i requisiti utenti in specifiche funzionali del sistema stesso. Il BA si interfaccia con gli esperti del Business, subject matter experts (SME), messe a disposizione del gruppo di lavoro per assicurare che quanto proposto corrisponda alle aspettative ed esigenze degli utenti finali.
  • Subject Matter Expert (SME): key users di riferimento esperti dei processi/flussi interni
  • Solution Engineer (SE); sviluppatori che hanno il compito di tradurre le specifiche tradotte dal BA e approvate da SME in funzionalità specifiche (personalizzazioni) del sistema LIMS
  • End Users: utenti finali che utilizzeranno il sistema nelle attività giornaliere

In base alla dimensione e/o complessità del progetto le figure sopra possono confluire in una o più persone diverse. In LABVANTAGE il Project Manager ha anche una approfondita conoscenza ed esperienza sia del software sia dei progetti LIMS molto spesso in segmenti industriali diversi. Quindi il suo ruolo è anche quello di primo suggeritore di possibili soluzioni ai requisiti utenti. La nostra esperienza ci porta infatti a dire che la figura di project manager “puro” è poco praticabile nella realtà di progetti LIMS che richiedono invece un solido bagaglio di conoscenze tecniche.

Aver chiaro ruoli e responsabilità permette di gestire in maniera tempestiva eventi avversi, escalation e deviazioni. Inoltre la chiara definizione della propria mansione è in molti casi fonte di motivazione in quanto accresce la consapevolezza del contributo dato al progetto.

Nel prossimo articolo illustreremo l’importanza delle procedure di Change Management.

Share This

X