The greatest obstacle to Data Integrity
How to overcome it easily and improve all business processes and Data Governance.
13 mai, 2020 par
The greatest obstacle to Data Integrity
Ympronta srl, Info Ympronta
| aucun commentaire pour l'instant








L'ostacolo più grande al Data Integrity

Hai mai voluto osservare letteralmente un dato lungo il suo viaggio attraverso i processi aziendali? Pensi sia impossibile? Dal momento che la normativa su Data Integrity richiede una gestione efficace dei processi ed un costante monitoraggio di tutti i dati critici, le aziende farmaceutiche sono alla ricerca di uno strumento adatto a questo scopo. In questo articolo parleremo della sfida più grande nel raggiungimento di un buon livello di Data Integrity e presenteremo una soluzione che permette di vincere questa sfida, costruendo con facilità un ambiente robusto che, oltre a mettere in sicurezza i tuoi dati, consolida tutti i processi aziendali. 

I TUOI BELLISSIMI DIAGRAMMI DI FLUSSO


Nel corso della tua vita professionale hai probabilmente dovuto disegnare almeno un flow chart. Ah, quanto era bello da vedere! Quanto era chiaro ed autoesplicativo! Come rappresentava bene quel processo perfetto che avevi in mente. Una volta che sulla carta "girava", ovvero era snello, robusto e senza errori, era praticamente fatta. 


Rimanevano da fare pochi "semplici" passi affinché quel bellissimo flusso prendesse vita:

  1. condividerlo con tutti gli attori che vi sarebbero stati coinvolti. Anzi, se si trattava di un ambiente democratico, il processo doveva piacere a tutti per essere approvato.

  2. digitalizzarlo. Ovvero sviluppare/configurare un'applicazione più o meno complessa. O, nei casi meno fortunati, semplicemente redigere procedure operative cartacee, da applicare una volta implementato il flusso.

In questo articolo eviteremo di approfondire il caso in cui viene introdotto un sistema digitale "chiavi in mano", con i flussi già implementati, costringendo l'azienda ad adeguarsi a questi flussi, talvolta troppo rigidi e poco adatti alle esigenze specifiche delle persone.

Parliamo, quindi, di quei casi dove l'azienda (o una parte di essa) è in fase di pieno sviluppo e di rapida crescita. Quella fase dove i cambiamenti sono all'ordine del giorno ed il processo che avevi disegnato ieri, oggi non è più attuale. 

Già, anche se riuscivi a convincere tutti (tutt'altro che facile) e, dopo aver integrato nel diagramma i feedback di ciascuno, portavi il processo alla sua fase implementativa, ti scontravi con la dura realtà dei fatti: digitalizzare un processo disegnato sulla carta, disegnato solo in base alla logica del business e senza considerare i vincoli tecnologici, comporta inevitabilmente scendere a compromessi e "ritoccare" di nuovo il tuo bellissimo diagramma.

O, in alternativa, avere un budget infinito in modo da commissionare l'implementazione di un sistema praticamente da zero e completamente custom.


Questo è quasi impossibile nell'ambito farmaceutico, dove qualsiasi custom è penalizzato in partenza poiché impone sforzi e costi notevoli per la convalida (se si tratta dei processi GxP). La soluzione, quindi, è l'adozione dei sistemi configurabili. Ovvero soluzioni quasi-standard che, senza necessità di scrivere codice, ma grazie solamente a configurazioni, trasformano un sistema rigido in uno flessibile ed adattabile ad alcune esigenze specifiche. 

Tutto risolto, quindi? Non proprio. 

Il fatto è che non esiste un sistema unico che copre tutti i processi dalla A alla Z: da R&D e registrazione dei farmaci, all'acquisto delle materie prime, alla fabbricazione dei semilavorati e prodotti finiti, all'analisi di laboratorio, fino alle vendite, e tanto altro.

Certo, esistono sistemi modulari, come gli ERP, che coprono molti degli ambiti citati. Molti, ma non tutti. E comunque, i moduli di un ERP possono essere visti come applicazioni indipendenti, ma ben integrati tra loro. In questa ottica, ogni ambito richiede l'adozione di un modulo software specificamente progettato e sviluppato per quell'ambito, e personalizzato per ogni specifica azienda. La sfida successiva è far collaborare efficacemente questi sistemi e moduli. Ed è proprio questo l'ostacolo più grande al Data Integrity.

...durante l'intero ciclo di vita...

Tutte le definizioni di Data Integrity si riducono a questo. Ed ognuno dei principi ALCOA+ lo prevede. Non è sufficiente che ogni sistema, che fa parte di un ambiente complesso, garantisca l'integrità dei dati al suo interno. La maggior parte dei software farmaceutici lo fa già. Il Data Integrity è una disciplina cross-reparti e cross-sistemi e richiede che il dato rimanga integro anche durante tutti i salti quantici da un sistema all'altro che questo compie! Ed è proprio questo il significato di "durante l'intero ciclo di vita del dato". Ed è questa la principale sfida del Data Governance.

Ma come è possibile garantire l'integrità dei dati nei momenti di trasferimento da un sistema all'altro? Ogni sistema è esperto nei processi dell'ambito a cui si riferisce e può garantire l'integrità dei dati, finché questi sono sotto la sua giurisdizione

Ma tra i due sistemi comunicanti, chi deve garantire la riuscita del trasferimento del dato?

La risposta, naturalmente, è... nessuno dei due. La soluzione migliore è delegare l'onere di trasmettere efficacemente i dati a chi fa questo di mestiere. Un Middleware

COME È FATTO?

Come deve essere un Middleware? lo vediamo nel seguente esempio. Prendiamo in esame un semplice processo immaginario che possa essere di immediata comprensione: analisi di laboratorio con successiva approvazione del lotto.



Il processo viene innescato alla conclusione della fase produttiva del lotto. Il sistema, che potrebbe essere un LIMS centrale‎, è in attesa dei campioni prelevati per l'analisi (step "Batch Sample Receiving" nel diagramma) e, appena li riceve, trasmette i relativi dati ai due laboratori di analisi, chimico e microbiologico. Dopo di che, resta in attesa dei risultati di analisi. Quando arrivano i risultati da entrambi i laboratori, il sistema può prendere la sua decisione preliminare sulla qualità del lotto: approvato o rigettato. Naturalmente, solo se entrambi i risultati sono positivi, il lotto può essere approvato.

La consistenza di questo flusso è discutibile ma, come dicevamo, l'obiettivo non è rappresentare fedelmente un processo reale, ma solo immaginare come questo potrebbe essere realizzato grazie ad un Middleware

Verso la meta ambita


L'animazione seguente non è stata prodotta appositamente per questo articolo tramite un software di video editing o animation. È la ripresa del funzionamento reale del motore dei processi, adottato da Ympronta, nei suoi progetti più complessi e critici.


Ogni nodo rappresenta uno specifico stato dell'oggetto di questo processo, nel nostro caso del lotto.

Il contatore, visibile nella parte bassa di ogni nodo, rappresenta il numero di lotti che si trovano attualmente in quel specifico stato. 

Le connessioni tra i nodi definiscono la sequenza degli stati che ogni lotto deve percorrere. Una connessione che si "illumina" indica in tempo reale il passaggio del lotto da uno stato logico ad un altro. 

Come puoi immaginare, in ogni momento l'intero processo può essere "attraversato" da più lotti. E più lotti possono trovarsi nello stesso stato, contemporaneamente. Non c'è nessun conflitto. Ogni lotto è come un pellegrino che segue, con il proprio zaino, la stessa rotta degli altri per raggiungere la meta ambita.

La cosa più interessante è che ad ogni passaggio e ad ogni sosta, il lotto arricchisce letteralmente il proprio bagaglio di dati, arrivando in fondo con un album pieno di ricordi. Questo si vede anche nella parte finale dell'animazione, quando vengono mostrati, nel riquadro destro, i dati relativi ad ogni lotto nel suo stato finale (prova ad ingrandire la pagina per vedere meglio il dettaglio). 


Tutti i passaggi da un sistema all'altro, i risultati di tutte le analisi, i cambiamenti di stato... qualsiasi cosa sia accaduta al lotto durante la sua lavorazione, può essere aggiunta automaticamente al "dossier" finale. Certo, per non portarsi dietro una valigia troppo pesante, il sistema può, di tanto in tanto, confezionare e spedire quanto raccolto finora ad un deposito specializzato, e portare con sé fino alla fine solo i dati più rilevanti per un consulto immediato.

Tutto questo il Middleware lo fa con un'insostenibile leggerezza, perché è proprio per questo che è stato progettato.

Lungo il percorso, vengono registrati anche tutti i dati relativi alle comunicazioni tra i sistemi. Ed è per questo che il Middleware è la risposta giusta alla domanda "... tra i due sistemi comunicanti, chi deve garantire la riuscita del trasferimento del dato?"


In questo modo il process engine (detto anche Middleware o orchestrator), diventa, a tutti gli effetti, l'Audit Trail delle interfacce e delle comunicazioni che avvengono all'interno di un ambiente IT, sollevando così tutti gli altri sistemi digitali da questo onere.   

Conclusioni

Un sistema, come quello discusso sopra, può avere molteplici impieghi. Può agire da "colla" tra diversi sistemi e processi. Esistenti o nuovi. Può essere usato per creare processi totalmente nuovi, indipendenti da qualsiasi altro software. Può estendere le funzionalità di un sistema, esportando, elaborando e reimportando i dati indietro nello stesso sistema. Questo è molto utile per modificare il comportamento di un sistema esistente particolarmente rigido, se non si vuole sostituirlo perché si è affezionati o perché richiede un investimento notevole. Ma sopratutto, in ambito farmaceutico, è lo strumento ideale per garantire il Data Integrity, visto che permette di costruire, senza grandi investimenti, in tempo e denaro, un ambiente digitale con un efficace controllo di tutti i flussi e dei dati.

Il process engine di Ympronta è il cuore della nostra piattaforma cloud. Progettato proprio per questo scopo, riesce a gestire migliaia di processi concorrenti. Grazie alla sua tecnologia avanzata ed essendo un ambiente "multi-client" è in grado di gestire in parallelo i processi di tutti i nostri clienti, senza andare in conflitto e senza mai fallire. Infine, ogni cliente può gestire e monitorare tutti i suoi processi e i suoi dati all'interno del proprio spazio riservato. 


Grazie al designer grafico, ad immediato impatto visivo, che non richiede la scrittura del codice, riusciamo ad implementare i processi e testarli insieme ai clienti, ricevendo da loro il feedback immediato. Tutto questo riduce drasticamente il tempo complessivo necessario per la creazione di processi solidi, robusti e conformi al Data Integrity. Non sono più necessarie lunghe riunioni per immaginare, rivedere ed approvare sulla carta i processi. È sufficiente il requisito iniziale e l'idea di massima per abbozzare la prima versione di un processo reale. Successivamente, grazie ai continui  feedback degli utenti, nell'ottica di metodologia Agile, si arriva ad affinare il processo fino alla sua versione finale, per poi pubblicarlo in produzione.

E con i processi che possono invocare altri processi riusciamo a disegnare flussi di elevata complessità, costruendo vere e proprie gerarchie multi-livello.

Se il nostro Cloud Process Engine ti ha incuriosito, se hai in mente un progetto ma non sai come realizzarlo, o credi che potresti farlo grazie al nostro process engine, se hai domande sulla nostra piattaforma, non esitare a contattarci.

Unisciti a noi!

Sii il primo ad essere avvisato degli eventi, novità su Ympronta e la pubblicazione dei materiali di elevata qualità e utilità.

Odoo • Un'immagine con didascalia
Soluzione IoT per Data Integrity in laboratorio di analisi 
Odoo • Un'immagine con didascalia
Piattaforma Smart Serializzazione Farmaceutica
Y-MES
Smart MES Solution for Life Sciences Industry.
Data Integrity 
Questions and Answers
Your Dynamic Snippet will be displayed here... This message is displayed because you did not provided both a filter and a template to use.
The greatest obstacle to Data Integrity
Ympronta srl, Info Ympronta 13 mai, 2020
Partager ce poste
Archivia
Se connecter pour laisser un commentaire.