La maggior parte dei sistemi di monitoraggio si basa su un software installato su un server o su un PC locale: il software di monitoraggio è stato generalmente testato e convalidato, funziona ed esegue le normali funzioni richieste per la creazione di rapporti, allarmi e visualizzazioni generali. Ma sono tutti contenti?
Con il passare del tempo, alcune normative cambiano, potrebbero esserci dei requisiti di funzionalità che non fanno parte del vostro software, oppure la velocità del sistema non riesce a tenere il passo con l'espansione delle sedi monitorate. L'IT decide che il vostro sistema convalidato ha bisogno di patch di sicurezza per rimanere sulla rete aziendale - il vostro server deve essere aggiornato per tenere il passo con i carichi di lavoro aggiuntivi, i vostri backup dei dati hanno smesso di funzionare (senza che voi lo sappiate), e ora le patch di sicurezza IT hanno bloccato l'accesso al vostro software di monitoraggio, o peggio, hanno interrotto il monitoraggio del tutto!
Questi scenari sono tipici della gestione di un server locale, con un'applicazione o un software di monitoraggio di terze parti, e in passato erano generalmente accettati come parte del business. La quantità di tempo e di sforzi per mantenere il software in funzione può essere estenuante, ma perdere i dati o la possibilità di avere un monitoraggio continuo non è finanziariamente accettabile per l'azienda. Dover coinvolgere QA, QC, strutture e IT solo per far funzionare un software non è una soluzione praticabile. Se poi si aggiunge il fornitore di terze parti che supporta l'applicazione in remoto, beh, ci sono troppe possibilità di "cosa potrebbe andare storto". Qual è la risposta?
Perché non pensare di eliminare la manutenzione del server, il supporto software, il backup e le soluzioni IT e passare al cloud? Se tutti i problemi che avete affrontato potessero essere affidati direttamente al fornitore, risparmiereste molto tempo e fatica. Cosa c'è da fare? Quali sono i rischi?
La maggior parte delle aziende utilizza prodotti basati sul Cloud o Software as a Service (SaaS): i sistemi e-mail, finanziari, CRM ed ERP sono tutti basati sul Cloud. Ma molte aziende farmaceutiche non sono tra le prime ad adottare questo sistema: i rischi di perdita di dati o di integrità dei dati sembrano troppo elevati. Dal punto di vista del reparto qualità, il fatto di avere i dati in locale e di poterli convalidare facilmente li tranquillizza. Sapere esattamente quali sono i Master Plan di convalida, avere tutti i set di dati a disposizione, era il modo tipico di spuntare tutte le caselle, di avere un sistema chiuso e controllato. Ora si chiede loro di cedere i gioielli della Corona a una terza parte, per custodirli. Perché dovrebbero farlo?
Beh, le tecnologie sono cambiate. Per lo più in meglio. Ma non sono cambiate le responsabilità: infatti, ora che il fornitore si occupa della vostra infrastruttura, della vostra piattaforma o del vostro software come servizio, è necessaria una maggiore collaborazione per garantire che il fornitore si occupi della convalida completa, ma in ultima analisi la responsabilità è del cliente.
Di seguito sono riportate le responsabilità tipiche dell'azienda e del fornitore - scenari di convalida locale e di convalida nel cloud.
Ma anche in questo caso non si tratta di un quadro completo: dopo il completamento della convalida, è essenziale che venga stipulato un accordo sul livello di servizio (SLA). Lo SLA è in genere un accordo sulla configurazione del cloud, sull'accesso, sulla disponibilità in tempo reale, sui costi, ecc. Potrebbero esserci requisiti più dettagliati che riguardano la governance, la conformità, i luoghi di archiviazione e la politica di conservazione. Tutto ciò che serve al cliente per garantire l'accesso ai suoi dati è stato documentato e concordato.
Utilizzando uno SLA completo, si stabiliscono aspettative chiare e trasparenti; di solito questi SLA vengono forniti come modello dal fornitore. Attraverso una serie di round, è possibile definire e concordare le aspettative. Utilizzando obiettivi misurabili, gli SLA possono essere definiti in modo tale da regolare i costi correnti. Avete bisogno di un tempo di attività del 99,999%? I vostri dati devono essere recuperabili in 5 minuti o in 5 ore? Avete bisogno di opzioni di de-clouding, potreste voler cambiare fornitore di cloud e portare con voi i vostri dati? Certo, è bello avere il miglior SLA possibile, ma può avere un costo elevato. Stabilite delle aspettative ragionevoli che l'azienda possa accettare e che il fornitore possa fornire. I clienti devono essere consapevoli delle trattative iniziali, del loro livello di rischio e della volontà di lavorare con un partner in grado di assumersi le responsabilità di una fornitura SaaS.
Il passaggio al cloud presenta molti vantaggi rispetto a un sistema localizzato: l'accessibilità dei dati e il supporto dell'applicazione sono solo l'inizio; più avanti nella serie parleremo dei Big Data e di come possono trasformare i dati in voci intelligenti.
Nel prossimo blog LabWatch IoT parleremo dei requisiti GxP del cloud e delle politiche di sicurezza.
Copyright: Amphenol Corporation