N
U
IVERSITA DI ISA
P
DIPARTIMENTO DIINFORMATICA Corso di Laurea Magistrale in Informatica per l’Economia e per l’Azienda
(Business Informatics)
Tesi di Laurea Magistrale
P
ROGETTAZIONE E SVILUPPO DI UN
S
ISTEMA DI
S
UPPORTO
D
ECISIONALE
PER UNA AZIENDA FARMACEUTICA
Relatore: Candidato:
Anna Monreale Giacomo MINICHIELLO
matricola: 486381
Tutor aziendale:
Marco Luchini
Progettazione e sviluppo di un Sistema di Supporto Decisionale per una azienda farmaceutica
Autore: Giacomo MINICHIELLO Relatore: Anna Monreale Tutor aziendale: Marco Luchini
Printed in Pisa marzo 2016
Abstract
Il presente lavoro di tesi illustra la realizzazione di uno strumento finalizzato a supportare il processo di controllo qualità inerente la produzione di insulina all’interno di una multinazionale farmaceu-tica. L’obiettivo è quello di fornire agli utenti una serie di report che certificano la bontà del farmaco, e quindi stabilire la sua im-missione sul mercato senza rischi per il paziente. Il caso di studio descritto è stato realizzato dalla società SDG Group S.p.a. per una multinazionale farmaceutica americana. L’elaborazione inizia con la presentazione della tematica trattata, indicando gli attori e le fasi coinvolte nel processo di produzione di insulina. Successivamen-te sono descritti gli strumenti utilizzati, le attività di progettazione e implementazione del data warehouse, soffermandosi sul processo di elaborazione dei dati in ingresso e sulla rappresentazione grafica delle informazioni offerta agli utenti.
Indice
Lista delle figure i
Lista delle tabelle iii
1 Introduzione 1
1.1 Presentazione del problema . . . 1
1.2 Rassegna della letteratura . . . 2
1.3 Contenuto della tesi . . . 2
2 Caso di studio 5 2.1 Produzione dell’insulina . . . 5
2.2 Logiche del ciclo produttivo . . . 7
2.3 Descrizione del progetto Batch Review . . . 7
2.4 Sorting: controllo qualità tramite ispezione visiva . . . 9
2.5 L’azienda sviluppatrice: SDG Group . . . 13
2.6 L’azienda committente . . . 13
2.6.1 Industria farmaceutica . . . 13
2.6.2 Azienda committente . . . 14
3 Analisi dei requisiti e progettazione concettuale iniziale 15 3.1 Il processo di data warehousing . . . 15
3.2 Analisi dei requisiti . . . 16
3.2.1 Specifica dei requisiti . . . 16
3.3 Progettazione concettuale iniziale . . . 25
4 Progettazione concettuale finale e logica 27 4.1 Presentazione del sistema sorgente . . . 27
4.1.1 Descrizione del sistema sorgente PMX . . . 27
4.1.2 Logica del sistema sorgente PMX . . . 29
4.1.3 Progettazione concettuale candidata e finale . . . 30
5 Ambiente di sviluppo 33
5.1 Aspetti generali . . . 33
5.2 Oracle database 11g Enterprise Edition . . . 34
5.3 Oracle SQL Developer . . . 36
5.4 Informatica PowerCenter . . . 37
5.4.0.1 La componente grafica . . . 38
5.4.0.2 L’ indipendenza dalla base dati . . . 38
5.4.0.3 La manutenzione e i tempi di sviluppo . . . 39
5.4.0.4 L’ analisi degli impatti . . . 39
5.4.0.5 Gli oggetti per effettuare le trasformazioni sui dati 39 5.4.0.6 L’ ambiente di debug, lo schedulatore e i monitor interni . . . 39
5.4.1 PowerCenter Designer . . . 40
5.4.2 PowerCenter Workflow Manager . . . 44
5.4.2.1 Workflow . . . 45
5.4.2.2 Worklet . . . 45
5.4.2.3 Task e Sessioni . . . 47
5.4.2.4 Sorgenti e Destinazioni . . . 47
5.5 SAP Business Object . . . 48
5.5.0.5 Reporter . . . 48
5.5.0.6 Designer . . . 48
5.5.0.7 Supervisor . . . 48
5.5.0.8 WebIntelligence/ InfoView . . . 48
5.5.0.9 Repository . . . 49
5.5.1 Universe Design tool . . . 49
5.5.2 SAP Business Object Web Intelligence (WEBI) . . . 50
6 Architettura di Data Warehousing 53 6.1 Architettura dei sistemi di Data Warehousing . . . 53
6.2 Architettura GMDM . . . 55
6.2.1 Source System . . . 57
6.2.2 Staging Area . . . 58
6.2.3 Data Warehouse Area . . . 60
6.2.4 Data Mart Area . . . 60
7 Estrazione, Trasformazione e Caricamento 61 7.1 Processo di ETL . . . 61
7.2 Tipologie di ETL . . . 62
7.3 Nomenclatura . . . 63
7.4 Caricamento dati dalle sorgenti all’area di staging . . . 65
7.4.1 Store Procedure LOAD_STG . . . 68
7.4.1.2 Inizializzazione variabili per lo statement . . . 69
7.4.1.3 Inizializzazione delle variabili per il caricamen-to dello staging . . . 70
7.4.1.4 Caricamento del primo livello di staging . . . 71
7.4.1.5 Caricamento delle tabelle di secondo livello di staging . . . 72
7.4.1.6 Popolamento della tabella di log TBSTGLOG_-LOAD_STG . . . 81
7.5 Caricamento del data mart . . . 82
7.5.1 Esecuzione procedure e frequenza di aggiornamento . . . . 83
8 Reportistica 85 8.1 Reportistica . . . 85
8.2 Definizione dell’universo . . . 86
8.3 Progettazione dello strato semantico universo . . . 86
8.3.1 Creazione di classi e oggetti . . . 87
8.3.2 Problematiche: presenza di cicli . . . 88
8.4 Report realizzati . . . 89
9 Conclusioni 91
Lista delle figure
2.1 Macro-fasi del processo produttivo . . . 7
2.2 I quattro macro-report che compongono la Batch Review . . . 9
2.3 Macchinario AVIM . . . 10
2.4 Macchinario utilizzato durante il sistema di ispezione semiauto-matico SVIM . . . 11
2.5 Schema riepilogativo della fase di Sorting . . . 12
2.6 Scomposizione dell’industria farmaceutica complessiva in base ai tre macro-business . . . 14
3.1 Modello concettuale iniziale del data mart . . . 26
4.1 Logica del sistema PMX . . . 28
4.2 Modello logico . . . 31
5.1 Suddivisione logica dei dati in Oracle . . . 35
5.2 Posizionamento di Informatica PowerCenter secondo il Magic Qua-drant di Gartner . . . 37
5.3 Le quattro componenti di Informatica PowerCenter . . . 38
5.4 Oggetto PowerCenter per la definizione delle sorgenti dei dati . . 40
5.5 Icona relativa alle sorgenti dei dati . . . 40
5.6 Oggetto PowerCenter per la definizione delle destinazioni dei dati 41 5.7 Icona relativa alla destinazione dei dati . . . 41
5.8 Oggetto PowerCenter per la definizione del Source Qualifier . . . 41
5.9 Oggetto PowerCenter per la definizione della Expression Trasfor-mation . . . 42
5.10 Icona relativa alla Expression Trasformation . . . 42
5.11 Finestra PowerCenter per la realizzazione della Expression Tra-sformation . . . 42
5.12 Oggetto PowerCenter per la definizione dell’ Update Transforma-tion . . . 43
5.13 Definizione della strategia di aggiornamento all’interno dell’og-getto Update Transformation . . . 43
II LISTA DELLE FIGURE
5.14 Mapping per il trasferimento dei dati dalla tabella Sorgente alla
tabella Destinazione . . . 44
5.15 Struttura del Mapping per il trasferimento dei dati dalla tabella Sorgente alla tabella Destinazione . . . 44
5.16 Esempio di Workflow . . . 45
5.17 Esempio di Worklet . . . 46
5.18 Esempio di universo . . . 50
6.1 Architettura di Data Warehousing a tre livelli . . . 54
6.2 I sistemi sorgenti hanno implementazioni locali, mentre le aree di data warehouse e del data mart sono uniche e implementate rispettivamente su schema differenti. . . 56
6.3 Architettura GMDM. . . 57
7.1 Processo di estrazione, caricamento e trasformazione (ELT) . . . . 62
7.2 Nomenclatura tabella di staging . . . 63
7.3 Nomenclatura tabella data warehouse . . . 64
7.4 Processo di caricamento dell’area di staging . . . 68
8.1 Rappresentazione dell’universo come strato semantico tra l’uten-te e il database. . . 86
8.2 Informazioni generali su un lotto di insulina . . . 89
Lista delle tabelle
3.1 Requisiti di analisi e dimensioni di analisi . . . 18
3.1 Requisiti di analisi e dimensioni di analisi . . . 19
3.1 Requisiti di analisi e dimensioni di analisi . . . 20
3.2 Fatto attività svolta sul batch . . . 21
3.3 Dimensioni di analisi . . . 21 3.4 Batch Parenteral . . . 22 3.5 Annotation . . . 22 3.6 Production Procedure . . . 22 3.7 Routing . . . 22 3.7 Routing . . . 23 3.8 BOM . . . 23 3.9 Equipment . . . 23 3.10 Variables . . . 23 3.10 Variables . . . 24 3.11 Critical Changes . . . 24
1
Introduzione
1.1 Presentazione del problema
Il controllo qualità sui dati costituisce un requisito fondamentale nel mondo della farmaceutica. In tale ambito i livelli di sicurezza e qualità devono rag-giungere standard ben definiti affinché si possa offrire al paziente un prodotto sicuro. Nel processo produttivo farmaceutico il dato informatico riveste un ruo-lo di primaria importanza in quanto permette di raggiungere un determinato standard qualitativo che può essere misurato. Per la produzione in sicurezza dei farmaci occorre monitorare ed analizzare i dati provenienti dall’intero pro-cesso produttivo aziendale. Purtroppo se questi dati non vengono integrati tra di loro, o non sono analizzabili in tempi relativamente brevi, si corre il serio ri-schio di rilasciare sul mercato un prodotto dannoso per il paziente. Le maggiori difficoltà riscontrate nel riuscire ad interpretare i dati provenienti da un sistema informativo di una multinazionale farmaceutica derivano dal fatto che la produ-zione non avviene in un unico stabilimento o sito produttivo, ma coinvolge siti locati a migliaia di chilometri tra di loro. Non bisogna pensare ai vari siti come stabilimenti a sé stanti, ma bisogna vederli come pezzi di un mosaico, di una catena produttiva, ai quali vengono assegnati compiti ben definiti del processo produttivo del farmaco, e il raggiungimento della qualità di un sito è propedeu-tico per la qualità degli altri stabilimenti. In un’ottica globale il controllo qualità sui dati si riflette in maniera diretta sulla qualità del farmaco stesso, quindi per l’integrità e la reperibilità di un dato informatico si rende necessaria l’adozio-ne di un sistema di Busil’adozio-ness Intelligence, capace di mettere in relaziol’adozio-ne i dati provenienti dai sistemi informativi degli stabilimenti sparsi per il mondo e di fornire report in tempi relativamente brevi.
2 1. INTRODUZIONE Il presente lavoro descrive un progetto svolto presso l’azienda SDG Group, volto alla realizzazione di un sistema di Business Intelligence che sia capace di raccogliere e integrare le informazioni generate dal processo produttivo del farmaco di una multinazionale farmaceutica. Lo scopo è quello di fornire agli utenti una serie di report che certificano la bontà del farmaco, e quindi stabilire la sua immissione sul mercato senza rischi per il paziente.
1.2 Rassegna della letteratura
Per la realizzazione del progetto di tesi sono state consultate numerosi fon-ti. Una parte non trascurabile del lavoro è basata sulle soluzioni proposte da A. Albano[AA15] per la progettazione di data Warehouse in quanto da tale fonte è possibile consultare i concetti teorici e pratici sull’argomento, e tali concetti sono poi correlati da indicazioni sulla presentazione formale di una realizza-zione di un data warehouse. Le informazioni relative alla società coinvolta nel progetto sono estrapolate dal sito web ufficiale del gruppo SDG [Gro] mentre per motivi di privacy non viene menzionata la società cliente coinvolta. In-formazioni inerenti il sistema informatico dell’azienda cliente PMX, sono state ricavate dal sito ufficiale dell’azienda che ha prodotto tale sistema, la Rockwell Automation [RA]. Dati riguardo la produzione di insulina sono stati ricavati dalla rivista scientifica Diabetes Forecast [Geb03], un mensile pubblicato negli Stati Uniti dall’American Diabetes Association (ADA). Nozioni inerenti il settore dell’industria farmaceutica si basano sul lavoro di S.Holland e B.Batiz-Lazo The Global Pharmaceutical Industry [S.H04]. Per le caratteristiche dell’ambiente di sviluppo e dei tool utilizzati, per le procedure di estrazione, trasformazione e caricamento e per la reportistica viene fatto riferimento rispettivamente alla documentazione ufficiale Informatica PowerCenter[Cora], e SAP Business Ob-ject [SE]. I tool appena citati verranno descritti nei capitoli 5 e 8 del presente documento. Infine, per i concetti inerenti la fase di estrazione, trasformazio-ne e caricamento dei dati si è fatto riferimento al lavoro svolto da R. Kimball [Kim04].
1.3 Contenuto della tesi
Il presente lavoro di tesi illustra la realizzazione di uno strumento finalizzato a supportare il processo di controllo qualità inerente la produzione di un far-maco all’interno di una multinazionale farmaceutica. Il caso di studio descritto è stato realizzato dalla società SDG Group S.p.a. per una multinazionale far-maceutica americana, le cui aree aziendali interessate sono state la manifattura e il controllo qualità eseguito nell’area di Information Technology. Il presente lavoro di tesi è organizzato nel modo seguente.
1.3. CONTENUTO DELLA TESI 3 Il Capitolo 2 è dedicato alla presentazione del caso di studio e si pone come obiettivo principale quello di introdurre ambito, soggetti ed altri aspetti rela-tivi al progetto realizzato. Si definiscono pertanto inizialmente alcuni concetti chiave relativi alla tematica centrale del lavoro, cioè la produzione dei flaconi di insulina e il controllo che deve essere effettuato durante la produzione. In seguito, sono presentate le organizzazioni interessate, nei ruoli di azienda com-mittente, azienda sviluppatrice, e alcune caratteristiche generali del prodotto richieste dal cliente.
Nel Capitolo 3 è descritta la prima parte della progettazione del sistema di Business Intelligence, che include la fase di analisi dei requisiti e di progetta-zione concettuale iniziale del data mart interessato. Entrambi gli aspetti sono correlati da documenti formali e tecnici per la descrizione degli aspetti modella-ti. Il modello usato prevede la descrizione del fatto, delle misure da utilizzare, delle dimensioni di analisi e delle gerarchie presenti in esse.
Il Capitolo 4 conclude la descrizione della progettazione concettuale finale e definisce la trasformazione di questa in uno schema logico del data warehouse, corrispondente a uno schema relazionale a stella. Per arrivare a definire il pro-getto finale sono analizzate le fonti informative disponibili sui sistemi di origine dei dati.
Il Capitolo 5 è dedicato all’introduzione dei principali strumenti usati per lo sviluppo del sistema. Si descrivono quindi la piattaforma sulla quale viene sviluppato il data warehouse (Oracle), lo strumento usato per le operazioni di estrazione, trasformazione e caricamento (Informatica PowerCenter) e la piat-taforma dedicata alla realizzazione di report grafici (SAP Business Object). Gli aspetti descritti riguardano l’architettura delle applicazioni, l’interazione con l’utente sviluppatore e le funzionalità più importanti.
Nel Capitolo 6 si presenta l’architettura di Business Intelligence messa a pun-to dall’azienda SDG per quespun-to progetpun-to. L’architettura è stata progettata in mo-do parametrico, e quindi è in gramo-do di gestire le informazioni provenienti dagli stabilimenti dell’azienda committente che sono locati in nazioni differenti. Dopo una descrizione approfondita dell’architettura, viene spiegato come queste scel-te archiscel-tetturali abbiano influenzato le procedure di estrazione, trasformazione e caricamento.
Nel Capitolo 7 si presenta il processo di ETL, volto a combinare i dati pro-venienti dalle varie fonti a disposizione per ottenere le informazioni finali da caricare nelle strutture definite in fase di progettazione. Le operazioni sono logicamente suddivise in: estrazione delle informazioni, importazione e stori-cizzazione sul sistema finale, combinazione delle fonti e caricamento del data
mart.
Il Capitolo 8 è dedicato alla descrizione dell’interfaccia del sistema rivolta all’utente finale. Si descrivono inizialmente i meccanismi usati per la creazione di uno strato semantico dei dati tra il data warehouse e il tool di reportistica.
4 1. INTRODUZIONE Successivamente, viene mostrato graficamente l’aspetto del cruscotto realizzato e il significato di alcuni report esemplari.
Il Capitolo 9 infine conclude la tesi, e in particolare vengono fatte varie con-siderazioni sul lavoro affrontato e descritto in questa tesi, indicando gli sviluppi futuri che possono essere portati avanti.
2
Caso di studio
L’obiettivo dell’attività, svolta presso l’azienda SDG Group, è la realizzazio-ne di un sistema software che permetta a una determinata categoria di utenti di una multinazionale farmaceutica il monitoraggio delle informazioni rileva-te duranrileva-te la produzione di cartucce di insulina. Nel presenrileva-te capitolo, dopo aver inquadrato l’ambito di riferimento e le principali motivazioni del progetto, sono presentate alcune informazioni generali relative alle funzionalità richieste e sull’azienda sviluppatrice. Informazioni dettagliate sull’azienda committente non possono essere descritte in questo lavoro di tesi in quanto è stato richiesto di mantenere l’anonimato su di essa.
2.1 Produzione dell’insulina
Il diabete è una malattia cronica caratterizzata dalla presenza di elevati livel-li di glucosio nel sangue (iperglivel-licemia) e dovuta a un’alterata quantità o funzio-ne dell’insulina. L’insulina è un ormofunzio-ne prodotto dal pancreas, che consente al glucosio l’ingresso nelle cellule e il suo conseguente utilizzo come fonte energe-tica. Quando questo meccanismo è alterato, il glucosio si accumula nel circolo sanguigno.
In passato i preparati insulinici industriali venivano prodotti grazie al pan-creas di bovini e suini in quanto chimicamente simile a quello umano, ma ciò rappresentava un processo di estrazione abbastanza complesso. La quantità di insulina è infatti molto scarsa e per produrre un flaconcino si impiegano cir-ca sei mesi. Inoltre, le insuline di origine animale contengono impurità, che provocano intolleranze e reazioni allergiche.
6 2. CASO DI STUDIO Attualmente, la maggior parte dei preparati insulinici, sono preparati tra-mite tecnologia genica, risolvendo i problemi legati alla produzione di origine animale.
Per la sintesi di insulina viene utilizzato il microrganismo Escherichia coli (E. coli). Piccoli tubi che contengono questi batteri vengono conservati in freezer a -70◦C per decenni. Nel 1980, l’azienda committente, trattata in questo lavoro di tesi, ha prodotto un lotto padre, chiamato master cell bank, e da allora continua a coltivare un lotto di Humulin1. Ogni volta che si ha la necessità di una nuova scorta di Humulin viene estratto un tubo dal master cell bank, fatto scongelare, e i batteri vengono stimolati alla crescita.
Partendo da mezzo grammo di batteri questi cominciano a replicarsi espo-nenzialmente, raddoppiando il loro numero ogni venti minuti circa. Quando il tubo che li contiene diventa troppo affollato i batteri vengono spostati in reci-pienti sempre più careci-pienti. I microrganismi si sviluppano in un brodo batterico composto da acqua, zucchero, sale, azoto e un additivo per contrastare ogni forma di contaminazione. Dopo diversi giorni i batteri sono pronti per la pro-duzione di insulina, e possono essere separati dal brodo in cui sono contenuti. Questo viene fatto grazie a una centrifuga che spinge i batteri verso il fondo della macchina. Il brodo viene rimosso e sostituito con un liquido contenente una sostanza in grado di rompere le membrane cellulari, per fare in modo che i batteri vengano separati dall’insulina prodotta al loro interno. Il passo successi-vo è la purificazione dell’insulina e questo viene fatto sfruttando la diversità in termini di carica elettrica, acidità e dimensione dell’insulina rispetto alle altre molecole.
Lo step finale da compiere, prima che l’insulina sia pronta per il packaging, è la cristallizzazione. Viene mischiata con zinco, che aiuta a formare cristalli stabili, e disidratata fino ad assumere la forma di una polvere di cristalli. A tempo debito, i cristalli vengono re-idratati in soluzione e versati in flaconcini, penne e cartucce, pronte per la spedizione.
1Humulin è un farmaco prodotto con moderne tecniche di ingegneria genetica, in cui il DNA
2.2. LOGICHE DEL CICLO PRODUTTIVO 7
2.2 Logiche del ciclo produttivo
Il processo produttivo dell’azienda farmaceutica nello stabilimento italiano si configura in tre macro-fasi (Figura 2.1)
1. Formulation: gli eccipienti vengono combinati con il principio attivo otte-nendo un lotto di formulazione; l’insulina disidratata viene prodotta da un altro sito produttivo dell’azienda farmaceutica. Per il sito preso in esame l’insulina rappresenta un semilavorato di produzione, che verrà reidratato in soluzione nello stabilimento italiano;
2. Filling: è la fase di riempimento della cartuccia di insulina;
3. Sorting: prevede un sistema automatico di ispezione visiva (conosciu-to anche come “Visual Inspection”) con campionamen(conosciu-to, per identificare difettosità delle cartucce di insulina;
Figura 2.1: Macro-fasi del processo produttivo
Quanto proposto in questo lavoro di tesi riguarderà le attività di controllo qualità sulla cartuccia di insulina prodotta al termine del ciclo produttivo, quindi verrà considerata la sola fase di Sorting.
2.3 Descrizione del progetto Batch Review
Il progetto “Batch Review” ha permesso di fornire all’azienda presa in esame strumenti operazionali integrati con le soluzioni di business intelligence per la supervisione dei processi governati da PMX (un sistema informatizzato che ha la principale funzione di gestire e controllare la funzione produttiva dell’azien-da); il centro di interesse per l’analisi è il lotto (Batch) di produzione e la sua compliance1 agli standard qualitativi attesi sul prodotto finito (Review).
Essendo non strettamente un progetto analitico ma operazionale, il suo ruo-lo è critico per il business in quanto permette di raccogliere dati dalla rete di
1Compliance è la conformità delle attività aziendali alle disposizioni normative, ai
8 2. CASO DI STUDIO produzione allo scopo di validare l’intero processo produttivo in termini di qua-lità raggiunta (validazione Quality) molto più rapidamente di quanto lo si possa fare con un sistema di supervisione manuale.
Il sistema produttivo è orientato al processo e non al prodotto, in quanto la linea di produzione è in grado di produrre formulazioni diverse dello stes-so prodotto a parità di equipment produttivo. Ad esempio, non si parlerà di distinta base come nei modelli di produzione orientati al prodotto, ma di “re-cipe” (ricetta), la quale richiede un sistema di gestione dinamico del processo produttivo.
Le norme di buona fabbricazione (NBF in inglese GMP - Good Manufac-turing Practice), o buone prassi di fabbricazione, sono un insieme di regole, procedure e linee guida in base alle quali vengono prodotti i farmaci (in Europa si usa il termine medicinali), i dispositivi medici, i prodotti per la diagnostica, i cibi e le sostanze farmacologicamente attive (in inglese Active Pharmaceuti-cal Ingredients, API). Il meccanismo di campionamento dei prodotti può fornire solo garanzie di tipo statistico sul fatto che i campioni stessi (ed eventualmen-te le aree adiacenti al luogo dove vengono prelevati i campioni) siano idonei all’uso; di conseguenza, poiché i controlli finali si basano tutti su tecniche di campionamento, le NBF seguono un approccio olistico secondo il quale vengo-no regolamentati nel loro complesso gli ambienti di produzione e di controllo in laboratorio.
Ai fini degli standard GMP, essendo il processo di validazione Quality del batch fondamentale per la produzione e la sua commercializzazione, il progetto Batch Review è quindi da ritenersi un sistema di reporting operazionale critico per il business.
La Batch Review si compone di 4 macro-report, uno per fase più una fase chiamata “Campagna” (Campaign), come mostrato nella Figura 2.2.
La Campaign corrisponde ad un insieme di fasi di Filling delle cartucce e accomuna un insieme di fasi di preparazione o chiusura di una fase di Filling.
Quindi oltre al processo orizzontale, come descritto nel paragrafo 2.2 Logi-che del ciclo produttivo, esiste questa macro-fase verticale Logi-che raggruppa più fasi di Filling.
2.4. SORTING: CONTROLLO QUALITÀ TRAMITE ISPEZIONE VISIVA 9
Figura 2.2: I quattro macro-report che compongono la Batch Review
2.4 Sorting: controllo qualità tramite ispezione
visiva
Terminata la fase di Filling, le cartucce di insulina prodotte devono esse-re sottoposte a un controllo di qualità finale per verificaesse-re che siano prive di difettosità e determinare se il lotto può essere immesso sul mercato.
Il controllo qualità viene fatto tramite ispezione visiva delle singole cartucce di insulina, passando prima per un processo automatizzato, utilizzando dei mac-chinari dedicati, e per ultimo da un controllo manuale, svolto da un personale addetto. E’ possibile individuare tre fasi in questo processo:
• AVIM, Automatic Visual Inspection Machine; • SVIM, Semi-automatic Visual Inspection Machine; • AQL, Acceptable Quality Limit
Il primo controllo qualità che viene fatto al termine della fase di filling si compone di una prima ispezione visiva completamente automatica. Il mac-chinario interessato è l’ AVIM (Figura 2.3). Con sensori e telecamere ad alta risoluzione l’AVIM controlla che le singole cartucce di insulina siano prive di difettosità, come una scheggiatura sul vetro della cartuccia.
10 2. CASO DI STUDIO Dopo questa prima verifica l’AVIM può restituire tre stati:
1. Buona, ovvero la cartuccia è priva di difettosità e può essere immessa sul mercato;
2. Indeterminata/Grigia, ovvero la macchina non è in grado di dire se la cartuccia sia da scartare o meno, e bisogna ricontrollarla;
3. Nera, ovvero la cartuccia deve essere scartata perché difettosa;
Se l’AVIM stabilisce che un lotto è privo di difettosità (tutte le cartucce superano la verifica con esito ‘Buono’) viene scelto un campione di cartucce dall’intero lotto1, e sottoposto alla verifica di AQL.
Figura 2.3: Macchinario AVIM
Se invece l’AVIM non è in grado di decidere se la cartuccia sia da scartare o meno, si passa a un sistema di ispezione semiautomatico, SVIM (Figura 2.4), dove il controllo qualità viene effettuato oltre che dalla macchina anche dal per-sonale addetto. Nello specifico la macchina posiziona le cartucce e le fa ruotare in modo tale da favorire al meglio il controllo visivo da parte degli operatori. Dal controllo fatto con la SVIM la cartuccia può trovarsi in uno stato di ‘Buona’ o ‘Nera’. Nel primo caso, viene scelto un campione, così come viene fatto quando le cartucce superano l’ispezione visiva fatta dall’AVIM, e sottoposte all’ispezione manuale AQL. Nel caso in cui le cartucce non superino la verifica della SVIM vengono scartate definitivamente.
2.4. SORTING: CONTROLLO QUALITÀ TRAMITE ISPEZIONE VISIVA 11
Figura 2.4: Macchinario utilizzato durante il sistema di ispezione semiautomatico
SVIM
L’ AQL è un controllo statistico sulle cartucce classificate come buone da AVIM e SVIM. Viene prelevato un campione di cartucce buone per valutare la precisione delle macchine di ispezione visiva per ogni lotto riempito. È tolle-rato un certo margine di errore dei controlli AVIM e SVIM nel ritrovamento di difetti sulle cartucce. Se il controllo supera i limiti per cui AVIM e SVIM sono considerate affidabili, si fa un re-sorting del lotto (solo delle cartucce dichiarate buone); su questo lotto di re-sorting si riesegue la verifica AVIM solo sul difetto per cui l’AQL è uscito dai limiti (lanciando una ricetta ad hoc), e l’AQL di nuovo su tutte le cartucce buone, mentre la fase di SVIM non viene più eseguita.
Nella Figura 2.5 viene mostrata una rappresentazione dell’interno processo di Sorting. Viene usata la notazione BPMN (Business Process Modeling Nota-tion), la notazione standard internazionale per la rappresentazione dei processi di business.
12 2. CASO DI STUDIO
2.5. L’AZIENDA SVILUPPATRICE: SDG GROUP 13
2.5 L’azienda sviluppatrice: SDG Group
SDG Group è una società di consulenza gestionale che utilizza pratiche di Business Intelligence, Corporate Performance Management e Collaborative Bu-siness Analytics nello sviluppo di soluzioni manageriali e analitiche. Fonda-ta a Milano nel 1991, attualmente è presente anche a Roma, Verona, Firenze, Londra, Barcellona, Madrid, Lisbona, Amburgo, Monaco, Cairo, Algeri, Parigi, Londra, York, Lima e Bogotà.
2.6 L’azienda committente
Prima di parlare dell’azienda committente, è utile fornire una breve intro-duzione al mondo dell’industria farmaceutica.
2.6.1 Industria farmaceutica
L’industria farmaceutica si distingue per un elevato grado di complessità ed articolazione, per i considerevoli rischi d’impresa a cui è soggetta, derivanti so-prattutto dall’attività di R&D (la ricerca e sviluppo costituisce il core business dell’indotto), e per i singolari margini di cui godono soprattutto le grandi azien-de farmaceutiche, le cosidazien-dette Big Pharma. Le origini azien-dell’industria moazien-derna vengono datate tra la fine del diciannovesimo e l’inizio del ventesimo secolo.
Da[S.H04] è possibile evidenziare tre aree tematiche in cui si articola l’indu-stria farmaceutica: Pharmaceutical, Biotechnology e Life Science Medical De-vice (vedi Figura 2.6). Il settore dei Pharmaceutical è dominato dai cosiddetti “ethical” drug, ovvero i farmaci convenzionali o gli agenti più complessi tra cui i vaccini per i quali è necessaria la prescrizione medica. I farmaci etici costitui-scono l’industria farmaceutica in senso stretto in cui operano la grandi aziende farmaceutiche multinazionali, le Big Pharma. A questo settore possono tutta-via essere ricondotti anche i farmaci “over the counter” (OTC Pharmaceutical), che prendono il loro nome dalla possibilità di essere acquistati senza prescri-zione direttamente dal consumatore finale. Sia i farmaci “ethical” sia gli OTC sono a loro volta presenti sul mercato sia in forma branded (con marchio) sia come “generici” (unbranded). Ciò che contraddistingue in modo determinante le varie tipologie di prodotti è individuabile nel sistema di marketing e nell’or-ganizzazione della attività di vendita (processo di acquisto e rete distributiva). Il settore Biotechnology comprende i farmaci prodotti attraverso molecole na-turali più complesse che molto spesso sono create a partire da cellule viventi, mentre quello dei Life Science Medical Device è costituito dalle strumentazioni e dalle attrezzature al servizio dell’industria farmaceutica e di quella biotech.
14 2. CASO DI STUDIO
Figura 2.6: Scomposizione dell’industria farmaceutica complessiva in base ai tre
macro-business
2.6.2 Azienda committente
L’azienda committente è una multinazionale farmaceutica, impegnata nel campo della ricerca, nell’innovazione di prodotto, nella ricerca di soluzioni sa-nitarie e di terapie farmacologiche. La missione aziendale punta a migliorare la salute dei singoli pazienti in diverse aree terapeutiche, tra le quali il diabete.
Nello stabilimento italiano il processo produttivo dell’azienda riguarda la produzione di cartucce di insulina da immettere sul mercato e la successiva spedizione. Quindi si fa principalmente riferimento alle attività inerenti la lavo-razione. Essendo l’insulina un farmaco realizzato attraverso molecole complesse prodotte da cellule viventi, l’azienda committente rientra nel settore Biotechno-logy.
3
Analisi dei requisiti e
progettazione concettuale
iniziale
Questo capitolo, dopo una breve introduzione sulle scelte, caratteristiche e aspetti architetturali del processo di data warehousing, documenta le prime fasi di progettazione concettuale del data warehouse a partire dalle analisi dei requisiti. In particolare, l’attenzione è focalizzata sulle specifiche dei requisiti e sul disegno concettuale iniziale dei data mart sulla base dei requisiti di analisi.
3.1 Il processo di data warehousing
Con il termine data warehousing[AA15] si fa riferimento al processo di orga-nizzazione dei dati in un data warehouse per consentire agli utenti di analizzarli con strumenti di business intelligence. Per la realizzazione di un processo di data warehousing si adotta un’architettura a 3 livelli: il livello delle sorgenti dati, il livello dei dati intermedi (area di staging), e il livello dell’area del data
warehouse. Per un’analisi approfondita dell’architettura utilizzata si rimanda al capitolo 6.
Per quanto riguarda la progettazione del data warehouse si individuano cin-que fasi:
1. Analisi dei requisiti;
2. Progettazione concettuale dei data mart guidata dall’analisi; 3. Progettazione concettuale candidata guidata dai dati;
16 3. ANALISI DEI REQUISITI E PROGETTAZIONE CONCETTUALE INIZIALE 4. Progettazione concettuale finale;
5. Progettazione logica dei data mart e del data warehouse.
3.2 Analisi dei requisiti
3.2.1 Specifica dei requisiti
La raccolta dei requisiti è stata portata avanti con il cliente attraverso nu-merosi incontri, in seguito ai quali sono state individuate le seguenti aree di interesse:
• Il punto focale delle analisi è rappresentato dalle attività che vengono svolte sul lotto di insulina durante il processo produttivo.
• Un’attività viene svolta su un lotto, e per ognuna di queste attività si vuole tener traccia delle informazioni anagrafiche che lo caratterizzano, quali il codice di lotto usato per identificarlo all’interno del processo produttivo; il materiale di cui è composto, quindi codice e descrizione del materiale (ogni lotto è composto da cartucce realizzate con un determinato mate-riale, es. HUMALOG soluzione 100U/ML). Per ogni lotto viene riportato il materiale di cui sono composte le cartucce di insulina e da un codice che identifica univocamente quel materiale; infine per un lotto si tiene traccia di data di inizio e di fine produzione.
• Un’attività può riguardare cambiamenti critici avvenuti nel processo pro-duttivo dovuti a scostamenti rispetto agli standard definiti. Durante la lavorazione possono essere cambiati dei parametri critici che possono ri-guardare sia i materiali utilizzati che operazioni da svolgere durante la lavorazione. Quindi da un’attività si deve poter analizzare quali sono i cambiamenti critici a cui eventualmente è associata.
• Un lotto può essere prodotto seguendo uno specifico processo produttivo che differisce da quanto fatto per altri lotti. Quindi bisogna riportare an-che le informazioni del processo an-che ha portato alla realizzazione di quel determinato lotto. Nello specifico, la procedura di produzione (produc-tion procedure) del lotto è composta da un insieme di materie prime e semilavorati di produzione, e da un insieme di procedure che indicano come utilizzarle e combinarle al fine di produrre un lotto di cartucce di insulina. Le materie prime e i semilavorati di produzione vengono defini-ti Beam Of Material (BOM), che cosdefini-tituisce la disdefini-tinta base dei prodotdefini-ti, mentre le procedure vengono dette Routing. L’insieme delle BOM e dei Routing costituisce la production procedure. Sia le BOM che le Routing
3.2. ANALISI DEI REQUISITI 17 vengono identificate da un codice, e da una versione con uno stato as-sociato poiché sono soggette a cambiamenti. Infatti può accadere che le materie utilizzate cambino oppure il modo il cui vengono utilizzate ven-ga modificato. Lo stato è utile quando si vuole conoscere se i materiali o le procedure utilizzate sono obsolete o meno nel momento in cui si va a consultare il report.
• Un’attività svolta su un lotto di insulina può essere registrata in un LOG di eventi. Durante il processo produttivo è possibile che si verifichino delle situazioni inattese, degli scostamenti dai comportamenti attesi e definiti nella production procedure. In questi casi si deve tener conto di que-ste situazioni indesiderate in un log. L’azienda cliente definisce queque-ste situazioni con il termine CAPA (corrective action / preventive action) e vengono tracciate in un sistema informatico interno. Nel caso della Batch Review l’obiettivo è quello di visualizzare le eventuali deviazioni memo-rizzare in separata sede dal sistema informatico dell’azienda cliente sul lotto in esame. In questi casi si deve tenere traccia dell’utente che ha svolto quell’attività, la descrizione dell’evento, e la data.
• Un’attività svolta su un lotto di insulina può riguardare il ciclo di pulizia svolta sui macchinari (cicli EQO) . Per un ciclo EQO interessa il nome, l’identificativo e la tipologia. Un ciclo EQO identifica una fase di pulizia svolta sui macchina e sugli utensili e può interessare più lotti prodotti in processi produttivi differenti. Quindi, un ciclo di pulizia può essere esegui-to ogni qual volta viene prodotesegui-to un nuovo lotesegui-to di insulina, ma riguarda più lotti prodotti. Un ciclo EQO è caratterizzato da un intervallo tem-porale che indica la validità del ciclo eseguito, e in quest’arco temtem-porale vengono prodotti più lotti di cartucce di insulina.
• Le informazioni anagrafiche su un’attività svolta su un lotto di insulina, come il nome dell’attività. In base al tipo di attività, queste vengono ca-tegorizzate in gruppi, i quali vengono indicati come Procedure Step (PS). Quindi per un’attività si vuole conoscere a che gruppo appartiene. A sua volta un gruppo PS fa parte di una determinata fase del processo produtti-vo (formulation, filling, sorting). Infine, a una PS viene associato un ticket di produzione. Il ticket viene generato ogni qual volta viene ordinata la produzione di un determinato lotto di insulina.
18 3. ANALISI DEI REQUISITI E PROGETTAZIONE CONCETTUALE INIZIALE Di seguito (Tabella 3.1) viene proposto uno schema riepilogativo dei requisiti con le dimensioni di analisi coinvolte
Tabella 3.1: Requisiti di analisi e dimensioni di analisi N. Requisito di analisi Dimensioni
1 Per un’attività svolta, le infor-mazioni anagrafiche del lotto interessato, per materiale utiliz-zato, per process order, per data di inizio e fine lavorazione del lotto nella fase di sorting, per production procedure
Batch Parenteral (Batch Num-ber, Material Code, Sort Pha-se Start Date, Sort PhaPha-se End Date), Production Procedure (Nome, Versione)
2 Un’attività può riguardare cam-biamenti critici avvenuti nel processo produttivo dovuti a cambiamenti rispetto agli stan-dard definiti. Durante la lavo-razione possono essere cambia-ti dei parametri cricambia-tici che pos-sono riguardare sia i materia-li utimateria-lizzati che operazioni da svolgere durante la lavorazione. Di un cambiamento critico inte-ressa sapere la descrizione del cambiamento effettuato, la da-ta in cui si è effettuato, il valore prima e dopo il cambiamento, e dati su chi lo ha eseguito
Critical Changes (Code, Action Description, Action Date, Pa-rameter Description, Initial Va-lue, Final VaVa-lue, User ID, User Description)
3 Per un’attività, conoscere even-tuali eventi o scostamenti dai comportamenti attesi che si so-no verificati. In questo caso, quello che interessa registrare sono la data, l’utente che ha re-gistrato un evento /scostamen-to, la descrizione e la tipolo-gia, per distinguere tra evento e scostamento
Annotation(Code, Date, User desc, Description, Tipology, User ID)
3.2. ANALISI DEI REQUISITI 19 Tabella 3.1: Requisiti di analisi e dimensioni di analisi
N. Requisito di analisi Dimensioni 4 Per un’attività si vuole
conosce-re quali proceduconosce-re sono state utilizzate per eseguirla e la di-stinta base dei materiali utiliz-zata. Per ognuna di queste in-formazioni interessa tener trac-cia della versione, della data di inizio e fine validità, e lo stato
Routing (Code, Version, Ver-sion Start Date, VerVer-sion End Da-te, State), BOM(Code, Version, Version Start Date, Version End Date, State)
5 Un’attività svolta può rientrare in un ciclo di pulizia dei mac-chinari. In questo caso biso-gna analizzare un’attività per descrizione del ciclo EQO, la tipologia, la versione, le date di inizio e fine validità della versione, e lo stato.
EQO (Code, Description, Ti-pology, Version, Version Start Date, Version End Date, State)
20 3. ANALISI DEI REQUISITI E PROGETTAZIONE CONCETTUALE INIZIALE Tabella 3.1: Requisiti di analisi e dimensioni di analisi
N. Requisito di analisi Dimensioni 6 Le informazioni anagrafiche su
un’attività svolta su un lotto di insulina, come il nome dell’at-tività. Un’attività rientra in un gruppo di attività accomunate tra di loro, i gruppo sono indi-cati come Procedure Step (PS). Quindi per un’attività si vuole conoscere a che gruppo appar-tiene. A sua volta un gruppo PS fa parte di una determinata fase del processo produttivo (formu-lation, filling, sorting). Infine, a una PS viene associato un tic-ket di produzione. Il tictic-ket ne generato ogni qual volta vie-ne ordinata la produziovie-ne di un determinato lotto di insulina. A una PS viene associato un va-lore, cioè una procedure varia-bles, che rappresenta il risulta-to dell’attività svolta. L’esirisulta-to di una PS può essere sia numerico che di tipo stringa.
Variables (Code, Procedure Step, Procedure Variables Text, Procedure Variables Number, Phase, Ticket)
All’interno del processo produttivo, la singola attività svolta rappresenta un elemento atomico. Come evidenziato in[AA15] è preferibile scegliere come fat-to di analisi una grana fine perché poi nelle analisi è sempre possibile diminuire il livello di dettaglio, mentre non è possibile fare il contrario. Il fatto “attività
svolta sul batch”(Tabella 3.2) si presenta come un fatto di tipo istantaneo (Tran-saction Fact), in quanto rappresenta l’informazione su uno specifico evento che si è verificato durante l’esecuzione di un processo aziendale. Come nel caso del fatto scelto per questo progetto, un Transaction Fact può anche non avere misure associate, se usato solo per rappresentare il verificarsi di un evento.
3.2. ANALISI DEI REQUISITI 21 Tabella 3.2: Fatto attività svolta sul batch
Descrizione Dimensioni preliminari
Il fatto descrive il verificarsi di un’atti-vità svolta durante il processo produtti-vo inerente la produzione di un lotto di insulina
Annotation, Production Procedure, Routing, BOM, Equipment Order, Variables, Critical Changes
Nella tabella 3.3 si descrivono le dimensioni specificando per ognuna di esse il nome, una descrizione e la granularità.
Tabella 3.3: Dimensioni di analisi
Nome Descrizione Granularità
Batch Parenteral Informazioni relative al lotto di insulina sul quale vengono svolte le attività
Un lotto di insulina
Annotation Dimensione in cui vengono re-gistrati i log associati agli ordini di manifattura
Un log
Production procedure Per ogni lotto, i dettagli di production procedure
Una production proce-dure
Routing Informazioni relative alla ricet-ta usaricet-ta dai processi di manifat-tura
Una routing
BOM Distinta base dei materiali Singola BOM Equipment Order Informazioni sui cicli di pulizia
sui macchinari
Un ciclo di pulizia Variables Per ogni ordine processato dal
sistema PMX questa tabella con-tiene i dettagli sulle variabili
Singola Variabile
Critical Changes Contiene attività critiche verifi-catesi durante le fasi di manifat-tura
22 3. ANALISI DEI REQUISITI E PROGETTAZIONE CONCETTUALE INIZIALE Per ogni dimensioni, nelle tabelle 3.4 - 3.11, si elencano gli attributi e una breve descrizione
Tabella 3.4: Batch Parenteral
Nome Descrizione
Batch Nbr Identificativo del lotto
Material Cd Identificativo del materiale utilizzato
Sort phase start Dt Data di inizio lavorazione del lotto nella fase di sorting Sort phase end Dt Data di fine lavorazione del lotto nella fase di sorting
Tabella 3.5: Annotation
Nome Descrizione
Annotation Id Identificativo dell’annotazione Annotation Desc Descrizione dell’annotazione
Annotation Dt Data dell’annotazione in formato ss:mm:hh GG /M-M/YYYY
Annotation User Desc Nome e identificativo dell’utente che ha registrato l’annotazione
Annotation Type Desc Tipologia di annotazione: attributo descrittivo che identifica un’annotazione tra le varie fasi del processo produttivo
Tabella 3.6: Production Procedure
Nome Descrizione
Prod Procedure Cd Identificativo della production procedure
Prod Procedure Ver Identifica la versione della production procedure Prod Procedure Ver
Start Dt
Data di inizio validità, in formato GG/MM/YYYY Prod Procedure Ver End
Dt
Data di fine validità, in formato GG/MM/YYYY Prod Procedure Status
Desc
Descrizione dello stato in cui si trova una production procedure (obsoleto, in approvazione etc.)
Tabella 3.7: Routing
Nome Descrizione
Routing Cd Identificativo della routing
3.2. ANALISI DEI REQUISITI 23 Tabella 3.7: Routing
Nome Descrizione
Routing Ver Start Dt Data di inizio validità, in formato GG/MM/YYYY Routing Ver End Dt Data di fine validità, in formato GG/MM/YYYY
Routing Status Desc Descrizione dello stato in cui si trova la routing (obsoleto, in approvazione etc.)
Tabella 3.8: BOM
Nome Descrizione
Bom Cd Identificativo della BOM Bom Desc Descrizione della BOM
Output Material Cd Identificativo del materiale utilizzato Output Theoretical Qty
Val
Quantità di materiale da utilizzare
Bom Head Ver Start Dt Data di inizio validità, in formato GG/MM/YYYY Bom Head Ver End Dt Data di fine validità, in formato GG/MM/YYYY Version Identifica la versione del BOM
Bom Head Status Desc Descrizione dello stato in cui si trova una BOM (obsoleto, in approvazione etc.)
Tabella 3.9: Equipment
Nome Descrizione
Equipment Cd Identificativo dell’ equipment Equipment Desc Descrizione dell’ equipment
Equipment Type Desc Indica su quale oggetto è stato effettuato un ciclo di pulizia, su una macchina, un utensile etc.
Equipment Ver Cd Identifica la versione del ciclo di pulizia
Equipment Ver Start Dt Data di inizio ciclo di pulizia, in formato GG/MM/YYYY Equipment Ver End Dt Data di fine ciclo pulizia, in formato GG/MM/YYYY Equipment Status Desc Descrizione dello stato in cui si trova un ciclo di pulizia
(obsoleto, in approvazione etc.)
Tabella 3.10: Variables
Nome Descrizione
Variable Cd Identificativo della variables
Variable Val Text Procedure Variable: risultato in formato stringa dell’attività PS
24 3. ANALISI DEI REQUISITI E PROGETTAZIONE CONCETTUALE INIZIALE Tabella 3.10: Variables
Nome Descrizione
Variable Val Nbr Procedure Variable: risultato numerico dell’attività PS Variable Text Desc Identifica la Procedure Step: nome dell’attività che
viene svolta
Phase Desc Identifica la fase del processo produttivo (formulation /-filling/sorting)
Ticket Cd Identifica il ticket di produzione generato per la produzione di un lotto di insulina
Tabella 3.11: Critical Changes
Nome Descrizione
Action Dt Data in cui si è verificato il cambiamento critico, in formato ss:mm:hh GG/MM/YYYY
Parameter Desc Descrizione del parametro che ha subito un cambiamen-to critico
Parameter Inital Val Valore del parametro prima del cambiamento critico Paramente Final Val Valore del parametro dopo il cambiamento critico Action Desc Descrizione del cambiamento effettuato
User Name Cd Identificato dell’utente che ha effettuato il cambiamento critico
User Name Desc Descrizione dell’utente che ha effettuato il cambiamen-to critico
Per quanto riguarda la gestione degli attributi dimensionali che possono su-bire modifiche nel tempo, è possibile adottare differenti strategie di storicizza-zione. Si valutano quattro possibilità, delle quali le prime tre si considerano quando qualche attributo cambia raramente (slowly changing dimensions):
• Tipo 1 (oggi per ieri): il valore di un attributo dimensionale che cambia va trattato come un valore errato da sostituire con il nuovo valore. E’ la soluzione più semplice, ma si perde la storia dei valori.
• Tipo 2 (oggi o ieri): Si vuole conservare la storia dei valori. E’ la soluzione più comune anche se aumenta i dati della dimensione.
• Tipo 3 (oggi e ieri): Si vuole sia la storia dei valori che la data in cui si verifica il cambiamento.
3.3. PROGETTAZIONE CONCETTUALE INIZIALE 25 • Tipo 4: gli attributi dimensionali cambiano frequentemente. In questo caso è preferibile adottare strategie diverse dalle precedenti. E’ possibile per esempio optare per la separazione della dimensione in due tabelle, una contente gli attributi destinati a non cambiare nel tempo e una contenente i rimanenti, organizzati in intervalli di valori.
Nel caso di studio presentato non è prevista la necessità di storicizzare dei cambiamenti se non per il caso in cui un record non è più presente nel sistema sorgente. In questo caso nel data warehouse viene settato un attibuto flag che va a indicare che quella tupla è stata cancellata a livello della sorgente. Per maggiori dettagli sulla soluzione architetturale adottata si rimanda al capitolo 6. In particolare, non interessa mantenere lo storico delle informazioni in quanto i report che verranno prodotti devono fornire informazioni riguardanti solo i lotti di insulina che sono stati prodotti (secondo gli standard GMP di cui si è parlato nel cap. 2) e per i quali ancora non è stato deciso se possono essere immessi sul mercato.
3.3 Progettazione concettuale iniziale
La raccolta dei requisiti e la traduzione formale di questi ha permesso di identificare requisiti specifici sul fatto e sulle dimensioni, inclusa la definizione di gerarchie dimensionali e di strategie per la gestione di attributi modificabili nel tempo. E’ possibile esprimere e rappresentare graficamente una sintesi delle informazioni raccolte attraverso il formalismo DFM (Dimensional Fact Model). Il modello ottenuto a partire dall’analisi descritta è rappresentato in Figura 3.1 Si osserva come utilizzando tale formalismo sia possibile rappresentare, ol-tre al fatto e alle dimensioni, alcuni dettagli aggiuntivi. In particolare sulle di-mensioni EQO, Annotation e Critical Changes è presente un taglio sull’arco che congiunge le dimensioni al fatto, a indicare che le intere dimensioni potrebbero non essere definite per una certa attività svolta. Infatti, una data attività svolta durante il processo produttivo può non riguardare un ciclo di pulizia sui mac-chinari (EQO), o un’azione svolta a fronte di un cambiamento critico, o infine potrebbe non riguardare una deviazione.
26 3. ANALISI DEI REQUISITI E PROGETTAZIONE CONCETTUALE INIZIALE A"vità'su'Batch' Annota0on' Batch'Parenteral'' Produc0on'Procedure' Rou0ng' BOM' Equipment'Order' Variables' Cri0cal'Changes' Batch' Material' Sort'Phase'Start'Date' Sort'Phase'End'Date' Annota0on'Date' Annota0on'User'' Annota0on'Type' Ac0on'Date' Parameter' Parameter'Ini0al'Val' Parameter'Final'Val' Ac0on' User'Name' Variable'Val'' Variable'Text'' Phase' Ticket' Equipment' Equipment'Type' Equipment'Version' Equipment'Start'Date' Equipment'End'Date' Equipment'Status' Bom'Desc' Output'Material' Output'Theore0cal'Quan0ty' BOM'Head'Version'Start'Date' BOM'Head'Version'End'Date' Version'' BOM'Head'Status' Version' Version'Start'Date' Version'End'Date' Status' Version' Version'Start'Date' Version'End'Date' Status'
4
Progettazione concettuale finale
e logica
Nel presente capitolo sono affrontate le ultime fasi relative al design del data
martsecondo il modello adottato. La prima di queste fasi riguarda la proget-tazione concettuale candidata, cioè quella ottenuta a partire dall’osservazione delle fonti di dati disponibili, che richiede pertanto una presentazione iniziale del sistema operazionale di partenza e delle fonti già presenti nel data
ware-house. La successiva fase, quella di progettazione concettuale finale, prevede un raffinamento ed un’integrazione dei due modelli preliminarmente ottenuti, allo scopo di comprendere e colmare le eventuali differenze riscontrate in essi. Infine, una volta ottenuto il modello concettuale finale, si procede alla presenta-zione della progettapresenta-zione logica che, in questo contesto specifico, consiste nella traduzione in un modello relazionale degli aspetti precedentemente modellati.
4.1 Presentazione del sistema sorgente
4.1.1 Descrizione del sistema sorgente PMX
Il sistema informativo PMX (Production Management System) viene clas-sificato a livello funzionale come MES (“Manufacturing Execution System”) , ovvero un sistema informatizzato che ha la principale funzione di gestire e con-trollare la funzione produttiva di un’azienda. La gestione coinvolge il dispaccio degli ordini, gli avanzamenti in quantità e tempo, il versamento a magazzino, nonché il collegamento diretto ai macchinari per dedurre informazioni utili ad integrare l’esecuzione della produzione, come a produrre informazioni per il controllo della produzione stessa.
28 4. PROGETTAZIONE CONCETTUALE FINALE E LOGICA PMX è un prodotto rilasciato dalla società Rockwell Automation[RA], e la sua implementazione rappresenta un sistema informativo integrato all’interno delle soluzioni IT dell’azienda farmaceutica, presa in esame in questa tesi, per l’ingegnerizzazione e l’esecuzione del processo di produzione del farmaco.
Il sistema PMX è stato implementato in due versioni:
PMX Presto: versione legacy1 del prodotto attualmente dismessa a partire da Gennaio 2014, i cui dati sono ancora disponibili per solo mantenimento storico (flussi di ETL spenti);
PMX PPN: versione del prodotto in produzione a partire da Gennaio 2014, in alimentazione dati;
Il database operazionale PMX contiene un numero molto alto di tabelle, vi-ste ed altri oggetti (package, funzioni e procedure). Data la complessità della base di dati, si presentano nel seguito solo una parte delle tabelle e gli attri-buti più importanti per la realizzazione del data warehouse (vedi Figura 4.1). In particolare, nel prossimo paragrafo viene descritta la logica che è alla ba-se del sistema PMX, ovvero le interazioni tra le tabelle TBDWFT_VARIABLES, TBDWFT_PROC_PROCEDURE, TBDWFT_PROD_ORDER.
Figura 4.1: Logica del sistema PMX
1Per sistema legacy si intende sistema informatico obsoleto che continua ad essere utilizzato
4.1. PRESENTAZIONE DEL SISTEMA SORGENTE 29
4.1.2 Logica del sistema sorgente PMX
Di seguito viene presentata la parte più caratterizzante del sistema sorgen-te PMX, ovvero la gestione di un ordine di produzione di un nuovo lotto di insulina. In questo ambito si rende necessaria la spiegazione della relazione tra le tabelle TBDWFT_VARIABLES, TBDWFT_PROC_PROCEDURE, TBDWFT_-PROD_ORDER.
La pianificazione SAP trasmette a PMX l’ordine di manifattura per un certo quantitativo di insulina da formulare. Usando la terminologia interna dell’a-zienda cliente diremo che al sistema PMX verrà inviato un Ticket (l’ordine di manifattura) per la produzione di un Batch (lotto di insulina) assegnando un numero di Batch e di Process Order. Il ticket viene esploso in fasi di processo chiamate Operation (conosciute anche come Fasi di processo)
La gerarchia logica con cui queste informazioni si sviluppano all’interno della base dati sorgente è la seguente:
Order (Ticket)
Operation (Fasi di processo)
Procedure Step (Sottofasi di processo) Process Variables (Variabili)
Un ordine di lavorazione (ticket) durante ogni fase di lavorazione (formula-tion, filling e sorting) subisce il passaggio da vari stadi (operation). In ogni ope-ration vengono effettuati vari interventi, identificabili sempre attraverso l’accop-piata procedure step (PS)/ process variable (PV). Le PS identificano una serie di attività specifiche accomunate tra di loro, mentre le PV identificano il risultato di ogni singolo intervento. Per fare un esempio, una PS può essere “controllare la difettosità X sul lotto”. I corrispondenti valori delle sue PV possono essere “Data di quando è stato effettuato il controllo”, “l’identificativo dell’operatore che ha effettuato il controllo”, “il numero di difetti X presenti sul lotto”. Un esempio di variabile a livello più profondo della gerarchia è “il numero di cartucce da con-trollare durante una fase di sorting”, “firma elettronica dell’approvazione del campione”, etc. Quindi le tre tabelle TBDWFT_VARIABLES, TBDWFT_PROC_-PROCEDURE, TBDWFT_PROD_ORDER si trovano in una relazione gerarchica tra di loro. La TBDWFT_PROD_ORDER contiene un ticket di produzione per un certo lotto di insulina. Questo ticket poi viene esploso in più fasi di processo nel-la tabelnel-la TBDWFT_PROC_PROCEDURE, e ad ogni operazione corrispondono una serie di attività registrate nella tabella TBDWFT_VARIABLES.
30 4. PROGETTAZIONE CONCETTUALE FINALE E LOGICA
4.1.3 Progettazione concettuale candidata e finale
L’analisi delle fonte dati disponibile non stravolge il modello concettuale iniziale, anzi lo conferma. A causa della dimensione e della complessità del data
warehouse, non viene mostrato il modello concettuale nella sua interezza, che peraltro non è risultato dell’attività di progettazione qui descritta. Pertanto, il modello concettuale mostrato nel capitolo 3, al paragrafo 3.3, viene considerato come il modello concettuale finale.
4.1.4 Progettazione logica del data mart
Definito il modello concettuale, si passa alla definizione del modello logico. La realizzazione dello schema logico avverrà secondo i seguenti passi:
1. Il fatto è modellato con una tabella;
2. Ogni dimensione viene modellata con una tabella;
3. Le chiavi primarie delle tabelle dimensionali vengono utilizzate come chia-vi esterne nella tabella del fatto;
4. L’opzionalità di alcune dimensioni è implementata tramite la creazione di valori/tuple di default (con codici N/D e descrizioni del tipo Non Dispo-nibile, Altro etc).
Si osservi che, nonostante sia possibile normalizzare alcune gerarchie di-mensionali dividendo gli attributi in più tabelle, ottenendo un cosiddetto snow-flake schema (schema a fiocco di neve), si sceglie di mantenere una ridondanza nei dati, velocizzando così le analisi sul data mart grazie ad un ridotto utilizzo di operazioni di join in fase di esecuzione. Lo star schema (schema a stella) ottenuto è mostrato in Figura 4.2:
Per la nomenclatura per tabelle e attributi si rimanda al paragrafo 7.3 del capitolo 7.
4.1. PRESENTAZIONE DEL SISTEMA SORGENTE 31 MDM_BATCH_PARENTERAL_DIM MDM_ANNOTATION_DIM BATCH_PARENTERAL_ID ANNOTATION/ID/ BATCH_NBR/ ANNOTATION/DESC/ MATERIAL/CD/ ANNOTATION/DT/ SORT/PHASE/START/DT/ ANNOTATION/USER/DESC/ SORT/PHASE/END/DT/ ANNOTATION/TYPE/DESC/ MDM_PRODUCTION_PROCEDURE MDM_BOM_DIM PROD_PROCEDURE_ID BOM_ID PROD/PROCEDURE/CD/ BOM/CD/ PROD/PROCEDURE/VER/ BOM/DESC/ PROD/PROCEDURE/VER/START/DT/ OUTPUT/MATERIAL/CD/ PROD/PROCEDURE/VER/END/DT/ OUTPUT/THEORETICAL/QTY/VAL/ PROD/PROCEDURE/STATUS/DESC/ BOM/HEAD/VER/START/DT/ BOM/HEAD/VER/END/DT/ VERSION/ BOM/HEAD/STATUS/DESC/ MDM_BATCH_DM MDM_ROUTING_DIM BATCH_PARENTERAL_ID ROUTING_ID ANNOTATION/ID/ ROUTING/CD/ PROD_PROCEDURE_ID
ROUTING/VER/CD/ ROUTING_ID MDM_EQUIPMENT_DIM
ROUTING/VER/START/DT/ BOM_ID EQUIPMENT/ID/
ROUTING/VER/END/DT/ EQUIPMENT/ID/ EQUIPMENT/CD/
ROUTING/STATUS/DESC/ VARIABLE_ID EQUIPMENT/DESC/
CRITICAL_CHANGES_ID EQUIPMENT/TYPE/DESC/ EQUIPMENT/VER/CD/ EQUIPMENT/VER/START/DT/ EQUIPMENT/VER/END/DT/ MDM_VARIABLES_DIM EQUIPMENT/STATUS/DESC/ VARIABLE_ID VARIABLE/CD/ VARIABLE/VAL/TEXT/ VARIABLE/VAL/NBR/ VARIABLE/TEXT/DESC/ MDM_CRITICAL_CHANGES PHASE/DESC/ CRITICAL_CHANGES_ID TICKETCD/ ACTION/DT/ PARAMETER/DESC/ PARAMETER/INITAL/VAL/ PARAMENTE/FINAL/VAL/ ACTION/DESC/ USER/NAME/CD/ USER/NAME/DESC/
5
Ambiente di sviluppo
In questo capitolo verranno descritti i principali strumenti attraverso i quali è stato implementato il progetto Global Batch Review. Dopo una breve intro-duzione al DBMS Oracle e all’ambiente di sviluppo ORACLE SQL Developer, ci si soffermerà maggiormente sullo strumento di ETL Informatica PowerCenter, e sul tool di reportistica SAP Business Object. A causa della vastità degli argo-menti e della non centralità di questi per il lavoro presentato, non si fornirà una descrizione dettagliata del linguaggio PL/SQL 1, ma, dove necessario, alcune
caratteristiche saranno riprese e spiegate nei capitoli successivi.
5.1 Aspetti generali
Ogni tipo di applicazione software attraversa diverse fasi in quello che vie-ne chiamato in letteratura ciclo di vita del software. All’interno di questo ciclo di vita si trovano fasi che possiamo definire preliminari, in quanto precedono lo sviluppo di codice vero e proprio (analisi dei requisiti, pianificazione del-le attività e progettazione del sistema), altre incentrate interamente sul codice (implementazione, collaudo e rilascio), oltre a fasi complementari di impor-tanza non trascurabile come documentazione e manutenzione dei sistemi. Per portare avanti le diverse fasi di gestione del software solitamente si usano diffe-renti ambienti, e questo è quello che è avvenuto nel progetto descritto in questo documento. In particolare si sono usati i seguenti ambienti di:
1Il PL/SQL è un’estensione proprietaria del linguaggio SQL utilizzata per permettere agli
sviluppatori di interfacciarsi con i database relazionali secondo un paradigma di tipo imperativo, includendo caratteristiche dei linguaggi orientati agli oggetti
34 5. AMBIENTE DI SVILUPPO 1. sviluppo - ambiente in cui si svolge la fase di implementazione; si tratta di un ambiente minimale, nel senso che sono presenti il minimo indispen-sabile di strutture dati necessarie per la realizzazione dei componenti, e i dati presenti in questo ambiente non sono reali (o realistici);
2. test - ambiente in cui si testa il software prodotto per verificare che i requisiti siano rispettati in modo corretto; sono presenti dati reali;
3. produzione - ambiente finale in cui il software è eseguito nel contesto reale e dove viene rilasciato dopo la fase di test; contiene tutti i dati necessari al funzionamento del sistema;
Può capitare che dopo il rilascio in produzione siano segnalati dei comporta-menti indesiderati, delle anomalie o richieste di modifiche dipendenti da fattori esterni. In tal caso le modifiche necessarie sono implementate in sviluppo, te-state nuovamente in test, rilasciate in produzione e così via. Questa struttura è replicata su tutte le piattaforme coinvolte nel progetto. Generalmente gli am-bienti di sviluppo e test sono costituiti da istanze diverse presenti su una stessa piattaforma hardware, mentre gli ambienti finali sono installati su macchine dedicate e di elevata qualità, per questioni prestazionali e di sicurezza.
5.2 Oracle database 11g Enterprise Edition
Oracle Corporation[Corb] è tra le più grandi società al mondo di software per le imprese, la prima ad aver commercializzato il database relazionale per la gestione dei dati (1977). Tra i clienti Oracle ci sono oltre duemila istituzioni ed enti pubblici in tutto il mondo, il suo successo è legato all’alta affidabilità, alla sicurezza dei dati e alla potenza dell’architettura su cui si basa. Un server Ora-cle è rappresentato fondamentalmente da due strutture, il database e l’istanza. Con il termine database si indicano i file fisici in cui sono memorizzati i da-ti, mentre per istanza si intende l’insieme delle aree di memoria e dei processi di background necessari ad accedere ai dati, ovvero al database. Ogni istan-za usa un’area di memoria condivisa chiamata System Global Area (SGA) per memorizzare i dati e altre informazioni in RAM, e un’area di memoria chiama-ta Program Global Area (PGA) per memorizzare le informazioni per i processi del server. Ogni database deve obbligatoriamente fare riferimento almeno ad un’istanza, ed è anche possibile avere più di un’istanza per database. Ciascun database consiste di strutture logiche di memorizzazione, per immagazzinare e gestire i dati, (tabelle, indici, etc.) e di strutture fisiche di memorizzazione che contengono le strutture logiche. I servizi offerti dalle strutture logiche del server sono indipendenti dalle strutture fisiche che le contengono. Questo per far si che le strutture logiche possano essere progettate nello stesso modo indi-pendentemente dall’hardware e dal sistema operativo impiegati. I dati vengono
5.2. ORACLE DATABASE 11GENTERPRISE EDITION 35 memorizzati logicamente in tablespace e fisicamente in datafiles. Come mostra-to in Figura 5.1, un tablespace è composmostra-to da un gruppo di segment, e sua volta il segment è formato da un insieme di extent. Ogni qualvolta si crea un segment Oracle alloca al suo interno almeno un extent che, a sua volta, contiene almeno un block. Un segment può essere associato esclusivamente ad un tablespace. Lo spazio di allocazione utilizzato è l’extent quando l’utente crea nuovi oggetti nel database, ed è composto da un numero specifico di blocchi contigui di dati.
Figura 5.1: Suddivisione logica dei dati in Oracle
Un blocco dati (block) è la più piccola unità di memorizzazione in Oracle, pertanto indivisibile, e corrisponde ad un numero di byte scelto dal DBA durante la creazione del database. La dimensione di un block viene definita in fase di configurazione del database che di solito è un multiplo dei blocchi del sistema operativo affinché le operazioni di I/O verso il disco fisso vengano agevolate. Un segment rappresenta un oggetto del database come ad esempio tabelle ed indici. Oracle permette di salvare i dati di una tabella in tablespace diversi permettendo
36 5. AMBIENTE DI SVILUPPO la ripartizione delle informazioni in molti file di dati, questo per evitare che in caso di danneggiamento del file di dati tutto il contenuto della tabella diventi irrecuperabile. E’ possibile anche partizionare il database o alcune delle sue parti in aree distinte per migliorare le performance.
5.3 Oracle SQL Developer
Oracle SQL Developer è un ambiente di sviluppo integrato che fornisce agli sviluppatori di database un semplice modo per connettersi a un database sche-ma, gestire gli oggetti , eseguire istruzioni SQL e script , sviluppare ed eseguire il codice PL/SQL , esportare i dati e molte altre attività di base. SQL Developer è stato utilizzato per gestire il database Oracle ed eseguire query.
Oracle SQL Developer è un’applicazione client di database server, sviluppato da Oracle Corporation per l’interazione con i database, dotata di tutte le caratte-ristiche di un ambiente di sviluppo integrato (IDE) per la programmazione SQL. Lo scopo principale di Oracle SQL Developer è quello di facilitare la creazione, la modifica e la gestione degli oggetti di un database relazionale e di renderla comprensibile anche a chi non conosce il linguaggio SQL. Questa applicazione funge quindi anche da terminale client che presenta un’interfaccia grafica che permette di compiere tutte le operazioni che si possono eseguire con il linguag-gio SQL. SQL Developer permette di interfacciarsi con tutti i database Oracle anche di precedenti versioni.
5.4. INFORMATICAPOWERCENTER 37
5.4 Informatica PowerCenter
Informatica PowerCenter [Cora] è un tool di estrazione, trasformazione e caricamento (ETL) sviluppato dalla società Informatica Corporation, largamen-te usato nello sviluppo di data warehouse. I componenti forniti da Informatica PowerCenter permettono di estrarre i dati dalle sorgenti trasformandoli secondi i requisiti di business e di caricarli in un data warehouse di destinazione. Se-condo il Magic Quadrant di Gartner1 (Figura 5.2) per i tool di data integration, Informatica continua a crescere e a mantenere la propria posizione da leader del mercato, ormai da otto anni consecutivi. Questo grazie al fatto che la soluzione di Data Integration di Informatica è stata creata appositamente per migliorare l’agilità del business.
Figura 5.2: Posizionamento di Informatica PowerCenter secondo il Magic Quadrant di Gartner
1Il Magic Quadrant è una metodologia di ricerca qualitativa ideata da Gartner Inc, una
società la cui principale attività consiste nel supportare le decisioni di investimento dei suoi clienti attraverso attività di ricerca e consulenza.
38 5. AMBIENTE DI SVILUPPO Come mostrato in Figura 5.3, Informatica PowerCenter è suddiviso in quat-tro componenti: Designer, Workflow Manager, Workflow Monitor e Repository Manager.
Figura 5.3: Le quattro componenti di Informatica PowerCenter
5.4.0.1 La componente grafica
PowerCenter è costituito da diversi strumenti di amministrazione e di svi-luppo, entrambi gestibili mediante un’interfaccia grafica che ne facilita l’uso e la comprensione. I secondi, in particolare, permettono di progettare i flussi di dati per acquisire i dati dalle diverse sorgenti, effettuare le trasformazioni necessarie e trasferirli nelle diverse tabelle o file di destinazione.
5.4.0.2 L’ indipendenza dalla base dati
Uno degli strumenti di sviluppo di PowerCenter, il Designer, permette di effettuare interrogazioni su basi dati eterogenee in modo completamente tra-sparente. Con un’unica interfaccia si riesce a mettere in comunicazione diverse fonti informative: dai file alle tabelle di database gestiti con DBMS eterogenei.
