PROGETTAZIONE E SVILUPPO DI UN SISTEMA DI SUPPORTO DECISIONALE PER LA FASE DI PACKAGING DI UN'AZIENDA FARMACEUTICA

(1)

DIPARTIMENTO DI INGEGNERIA DELL’ENERGIA DEI SISTEMI, DEL TERRITORIO E DELLE COSTRUZIONI

Corso di Laurea Magistrale in Ingegneria Gestionale

Tesi di Laurea Magistrale:

PROGETTAZIONE E SVILUPPO DI UN SISTEMA

DI SUPPORTO DECISIONALE PER LA FASE DI PACKAGING DI UN’AZIENDA FARMACEUTICA

_____________________________________________________________________ RELATORE:

Prof. Riccardo DULMIN

TUTOR AZIENDALE: Giacomo MINICHIELLO

CANDIDATO Paolo GRASSI Matricola:470669

Sessione di Laurea del 18/07/2018 Anno Accademico 2017-18

(2)

(3)

INDICE

LISTA TABELLE ... 1

LISTA FIGURE ... 2

1.INTRODUZIONE ... 5

1.1PRESENTAZIONE DEL PROBLEMA ... 5

1.2LETTERATURA CONSULTATA ... 6

1.3CONTENUTO DELLA TESI ... 6

2. CASO DI STUDIO ... 9

2.1PRODUZIONE DELL’INSULINA ... 9

2.2CICLO PRODUTTIVO ... 11

2.3DESCRIZIONE DEL PROGETTO GLOBAL PACKAGING BATCH REVIEW... 13

2.4L’AZIENDA SVILUPPATRICE ... 14

2.5SETTORE FARMACEUTICO ... 15

2.6L’AZIENDA COMMITTENTE ... 17

2.7CARATTERISTICHE E OBIETTIVI DEL PROGETTO ... 18

3. ANALISI REQUISITI E PROGETTAZIONE CONCETTUALE ... 19

3.1RACCOLTA DEI REQUISITI ... 19

3.2PROJECT PLAN ... 21

3.3ANALISI DEI REQUISITI TECNICI ... 22

3.4ATTRIBUTI DELLE TABELLE DEL CORE UTILIZZATI ... 29

3.5GESTIONE DEGLI ATTRIBUTI ... 33

3.6PROGETTAZIONE LOGICA DEL DATA MART ... 35

4. ARCHITETTURA DI DATA WAREHOUSE ... 37

4.1DATA WAREHOUSE ... 37

4.2ARCHITETTURA SISTEMI DATA WAREHOUSING ... 39

4.3NORMALIZZAZIONE DATABASE ... 44

4.4SCHEMA A STELLA E A FIOCCO DI NEVE ... 47

5. PRESENTAZIONI SOURCE SYSTEMS E ARCHITETTURA GLOBAL MANUFACTURING DATA MODEL... 51

5.1ARCHITETTURA GLOBAL MANUFACTURING DATA MODEL ... 51

5.2NOMENCLATURA ... 53 5.3SOURCE SYSTEM ... 55 5.5CORE AREA ... 58 5.6DATAMART AREA ... 59 5.7UNIVERSE ... 59 6. STRUMENTI UTILIZZATI ... 60 6.1AMBIENTE DI SVILUPPO ... 60

6.2IBMNETEZZA DATABASE... 61

(4)

6.4I PROCESSI ETL(EXTRACTION,TRANSFORMATION AND LOADING) ... 68

6.5INFORMATICA POWER CENTER ... 71

6.5.1 Designer ... 73

6.5.2 Workflow Manager ... 79

6.5.3 Workflow Monitor ... 82

6.5.4 Repository Manager ... 83

6.6SAPBUSINESS OBJECT ... 83

7. FASI DI SVILUPPO SISTEMA DI BUSINESS INTELLIGENCE... 90

7.1CARICAMENTO DATI DA SOURCE SYSTEM A STAGING ... 90

7.2SVILUPPI BACK-END ... 92

7.3SVILUPPI FRONT-END ... 96

7.4DOCUMENTAZIONE ... 98

8. FASE DI TEST DELLA SOLUZIONE ... 100

8.1TEST INFORMALI ... 100 8.2TEST FORMALI ... 101 9. CONCLUSIONI ... 103 10. ALLEGATO ... 105 BIBLIOGRAFIA ... 113 RINGRAZIAMENTI ... 115

(5)

1

LISTA TABELLE

TABELLA 1 REQUISITI SEZIONI DEL REPORT ... 28

TABELLA 2 TABELLE IN ANALISI ... 29

TABELLA 3 BATCH PARENTERAL ... 30

TABELLA 4 PRODUCTION PROCEDURE ... 30

TABELLA 5 WORK CENTER ... 30

TABELLA 6 PMX LOG ... 30

TABELLA 7 DEVIATION INFORMATION ... 31

TABELLA 8 PRINTED LABEL ... 31

TABELLA 9 ALARMS ... 31

TABELLA 10 CRITICAL CHANGES ... 32

TABELLA 11 MATERIAL IDENTIFICATION ... 32

TABELLA 12 PROCESS VALUE ... 33

TABELLA 13: DIFFERENZE OLTP-OLAP. ... 39

TABELLA 14 NOMENCLATURA TABELLE DI STAGING... 53

TABELLA 15 NOMENCLATURA TABELLE DEL CORE ... 54

TABELLA 16 NOMENCLATURA TABELLE DATAMART ... 54

TABELLA 17 NOMENCLATURA ATTRIBUTI ... 55

(6)

2

LISTA FIGURE

FIGURA 1: MACRO-FASI PROCESSO PRODUTTIVO ... 11

FIGURA 2: CARTUCCIA D'INSULINA ... 12

FIGURA 3: LINEE PRODUTTIVE E DI PACKAGING DEL SITO ITALIANO ... 12

FIGURA 4: LOGO SDG GROUP ... 14

FIGURA 5: MACROSEGMENTAZIONE SETTORE FARMACEUTICO. ... 16

FIGURA 6: FATTURATO SETTORE FARMACEUTICO. ... 17

FIGURA 7 PROJECT PLAN ... 21

FIGURA 8 SLOWLY CHANGING DIMENSIONS DI TIPO 1 ... 33

FIGURA 11 STORICIZZAZIONE DI ATTRIBUTI CHE CAMBIANO RAPIDAMENTE .. 34

FIGURA 12: ARCHITETTURA A UN LIVELLO DI UN DATA WAREHOUSE. ... 41

FIGURA 13: ARCHITETTURA A DUE LIVELLI DI UN DATA WAREHOUSE. ... 42

FIGURA 14: ARCHITETTURA A TRE LIVELLI DI UN DATA WAREHOUSE. ... 43

FIGURA 15: ESEMPIO PARTE 1. ... 44

FIGURA 20: STAR SCHEMA. ... 48

FIGURA 21: SNOWFLAKE SCHEMA. ... 49

FIGURA 22: ARCHITETTURA SPECIFICA AZIENDA COMMITTENTE. ... 52

FIGURA 23: CICLO DI VITA DEL SOFTWARE. ... 61

FIGURA 24: 2017 GARTNER MAGIC QUADRANT FOR DATA MANAGEMENT SOLUTION FOR ANALYTICS. ... 62

FIGURA 25: ARCHITETTURA AMPP. ... 66

FIGURA 26: ARCHITETTURA DI UN S-BLADE. ... 67

FIGURA 27: SCHEMATIZZAZIONE PROCESSO ETL. ... 70

FIGURA 28: SCHEMATIZZAZIONE PROCESSO ELT. ... 70

FIGURA 29: 2017 GARTNER MAGIC QUADRANT FOR DATA INTEGRATION TOOLS. ... 71

(7)

3

FIGURA 30: COMPONENTI DI INFORMATICA POWER CENTER. ... 73

FIGURA 31 ICONA DESIGNER ... 73

FIGURA 32 ESEMPIO TABELLA SORGENTE ... 74

FIGURA 33 ESEMPIO TABELLA TARGET ... 74

FIGURA 34 OGGETTI DISPONIBILI SUL DESIGNER ... 75

FIGURA 35 ESEMPIO DI MAPPING ... 75

FIGURA 36 ESEMPIO SOURCE QUALIFIER ... 76

FIGURA 37 ESEMPIO EXPRESSION TRASFORMATION ... 77

FIGURA 38 ESEMPIO UPDATE STRATEGY CON LOGICA DI AGGIORNAMENTO 77 FIGURA 39 ICONA WORKFLOW MANAGER ... 79

FIGURA 40 WORKFLOW UTILIZZATO PER IL PROGETTO GPBR ... 81

FIGURA 41 ICONA WORKFLOW MONITOR ... 82

FIGURA 42 MONITOR DI INFORMATICA. ... 82

FIGURA 43 ICONA REPOSITORY MANAGER ... 83

FIGURA 44 UNIVERSO: STRATO SEMANTICO TRA DATABASE E UTENTE [24] .. 85

FIGURA 45 UNIVERSO GLOBAL BATCH REVIEW ... 86

FIGURA 46 ESEMPIO CREAZIONE OGGETTO IN UNIVERSO ... 87

FIGURA 47 IMMAGINE CREAZIONE QUERY REPORT BO ... 88

FIGURA 48 ESEMPIO HEADER GLOBAL PACKAGING BATCH REVIEW ... 96

(8)

4

Sommario

Il presente elaborato di tesi contiene tutte le informazioni relative alla personale esperienza di stage svolta presso l’azienda SDG Group con sede a Firenze. L’oggetto di tale esperienza ha avuto come obiettivo la realizzazione di un sistema di reporting per la validazione dei lotti di cartucce di insulina in fase di packaging per una

multinazionale farmaceutica. La necessità dell’azienda farmaceutica è quella di migliorare e snellire il processo della validazione dei lotti nella fase di Packaging. Tale sistema di reporting permetterà ai business users di controllare più facilmente e rapidamente tutti i dati necessari per consentire il rilascio del prodotto finito sul mercato.

Dopo una fase preliminare di analisi dei requisiti, viene svolta una fase di sviluppi back end, cioè la parte non visibile agli utenti che permette l’effettivo funzionamento del sistema di Business Intelligence, e una di front end, cioè la parte visibile all’utente con cui può interagire ovvero il sistema di reporting. Alla fine degli sviluppi è prevista una fase di test.

Il progetto è stato svolto interamente da me e il mio tutor aziendale e per questo mi sono occupato personalmente di tutte le principali fasi del progetto. Lo sviluppo di questo progetto mi ha permesso di conoscere e utilizzare vari strumenti informatici quali Informatica Power Center e SAP Business Objects.

(9)

5

1

1. INTRODUZIONE

1.1 Presentazione del problema

Nel settore farmaceutico una fase di primaria importanza è rappresentata dal controllo qualità date le norme sempre più stringenti decretate dall'istituzione pubblica

competente per l'attività regolatoria dei farmaci. In Italia questa istituzione è l'Agenzia italiana del farmaco (AIFA). In questo ambito i prodotti devono raggiungere standard di qualità ben definiti per poter offrire ai pazienti prodotti sicuri e che soddisfino i requisiti. Nel settore farmaceutico, così come in altri settori, il controllo e l’analisi dei dati

informatici provenienti dall’intero processo produttivo aziendale, sono necessari per permettere di ottenere un determinato standard qualitativo e che possa essere misurabile. I problemi relativi a questi dati sono la difficoltà di integrare i dati derivanti da diverse fonti e di analizzarli in tempi brevi; se queste attività non vengono svolte correttamente c’è il rischio di rilasciare sul mercato prodotti non idonei e

potenzialmente pericolosi per i pazienti. La maggiore difficoltà riscontrata nell’analizzare i dati provenienti da un sistema informativo di una multinazionale farmaceutica è dato dal fatto che la produzione non ha luogo in un unico sito produttivo. È opportuno non esaminare i vari stabilimenti come entità isolate, ma bisogna considerarli come soggetti della supply chain, i quali hanno compiti definiti all’interno dell’intero processo produttivo. Il conseguimento dei requisiti di qualità di un sitò è propedeutico per gli stabilimenti successivi della supply chain. La qualità del

(10)

6 prodotto finito, il farmaco, è influenzata in maniera diretta dal monitoraggio dei dati; per la reperibilità e la correttezza dei dati necessari al controllo qualità e la possibilità di fornire report è indispensabile l’utilizzo di un sistema di Business Intelligence, in grado di integrare dati provenienti dai sistemi informativi dei diversi siti produttivi.

Il progetto trattato in questa tesi, svolto presso l’azienda SDG Group, descrive la realizzazione di un sistema di Business Intelligence in grado di estrarre e integrare dati proveniente da diversi sistemi sorgenti. L’obiettivo è la realizzazione di un report utilizzabile dagli utenti nella fase di packaging del prodotto, in grado di certificare la qualità del prodotto finito e quindi assicurare l’introduzione sul mercato di farmaci che rispettino i requisiti stabiliti.

1.2 Letteratura consultata

Per ricercare informazioni utili per la realizzazione di questa tesi sono state consultate numerose fonti, prevalentemente raccolte dal web. I concetti per le procedure di estrazione, trasformazione e caricamento di dati sono stati ricavati da materiale universitario. Altri concetti di base, sono stati ricavati da materiale fornito dall’azienda sviluppatrice sia in formato cartaceo sia disponibile sul portale di training aziendale. Le informazioni relative all’azienda sviluppatrice sono state ottenute dal sito web dell’azienda SDG Group, mentre non è menzionata la società cliente coinvolta per motivi di privacy.

Le informazioni relative all’insulina e al settore farmaceutico sono state ottenute dalla consultazione di riviste scientifiche e da altri elaborati online per approfondire tali argomenti.

Per le caratteristiche dell’ambiente di sviluppo e degli strumenti utilizzati viene fatto riferimento prevalentemente ai siti ufficiali delle aziende sviluppatrici di tali strumenti e al training ricevuto dall’azienda sviluppatrice.

(11)

7 Il progetto descritto in questa tesi di laurea illustra la realizzazione di uno strumento, sviluppato per una multinazionale farmaceutica, finalizzato al supporto decisionale relativo al processo di controllo qualità della fase di packaging del processo produttivo del farmaco. Lo strumento sviluppato è un report che permette, grazie all’inserimento del numero di lotto, di ottenere tutte le informazioni necessarie che permettono di decidere se rilasciare sul mercato tale lotto.

Il capitolo 2 introduce il caso di studio e tratta inizialmente la storia della produzione di insulina e il ciclo produttivo utilizzato dall’azienda. Viene poi spiegato più nello specifico il progetto che sarà sviluppato, l’azienda sviluppatrice e l’azienda committente. Per comprendere meglio il mercato di riferimento dove opera l’azienda cliente viene fornita una breve descrizione del settore farmaceutico.

Il capitolo 3 inizia con l’illustrazione relativa al Project plan del progetto.

Successivamente viene trattata la raccolta dei requisiti del progetto, analisi iniziali svolte e la progettazione concettuale iniziale del data mart interessato. Nel capitolo sono riportati le tabelle e i campi interessati per il progetto.

Nel Capitolo 4 è descritta la teoria dei Data Warehouse, spiegandone le caratteristiche e le varie tipologie di architetture possibili. Dopo la spiegazione di tali concetti viene proposta l’architettura messa a punto da SDG per lo svolgimento del progetto. Successivamente è spiegata la normalizzazione di un database illustrando i modelli concettuali.

Il Capitolo 5 illustra nel dettaglio l’architettura specifica dell’azienda, Global

Manufacturing Data Model (GMDM); in questo capitolo sono elencati i sistemi sorgenti e successivamente i vari layer del database. Per ogni layer sono descritte le

caratteristiche e le modalità di caricamento dei dati. L’architettura è stata progettata in modo parametrico, e quindi è in grado di gestire le informazioni provenienti dagli stabilimenti dell’azienda committente che sono localizzati in nazioni differenti. Il capitolo 6 descrive il tradizionale ciclo di vita del software e i relativi ambienti di sviluppo necessari alla sua implementazione. Inoltre, sono illustrati gli strumenti utilizzati; viene descritta la piattaforma sulla quale viene sviluppato il data warehouse (IBM Netezza), lo strumento usato per le operazioni di estrazione, trasformazione e caricamento (Informatica PowerCenter) e la piattaforma dedicata alla realizzazione di

(12)

8 report (SAP Business Object). Gli aspetti descritti riguardano l’architettura delle

applicazioni, l’interazione con l’utente sviluppatore e le funzionalità più importanti. Il capitolo 7 tratta dello sviluppo del sistema di Business intelligence denominato Global Packaging Batch Review. Inizialmente viene descritto il processo di caricamento dei dati dai sistemi sorgenti all’area di Staging, illustrando gli attributi tecnici tipici delle tabelle di staging. Successivamente viene illustrata la fase del progetto Back end per il quale gli strumenti principalmente utilizzati sono Informatica Power Center e IBM Netezza. In questa parte sono spiegati gli step da seguire e esempi di comandi in linguaggio SQL. Dopo la spiegazione della fase Back-end viene affrontata la fase Front end del progetto tramite l’utilizzo di SAP Business Object per lo sviluppo del report che sarà utilizzato per la validazione dei lotti nella fase di Packaging. La parte finale del capitolo tratta della documentazione necessaria per tracciare le modifiche effettuate nel database e per garantire la qualità dei dati mostrati nel report.

Il capitolo 8 descrive la fase di testing che viene svolta per assicurare la correttezza del report sviluppato. Concettualmente la fase di testing è divisa nei test informali svolti dagli utenti in ambiente di sviluppo (DEV) e i test formali svolti dagli utenti e dal team SDG in ambiente di Test (QA).

Il capitolo 9 descrive le conclusioni finali del progetto e in allegato è presente un

esempio dell’esecuzione del report per un determinato lotto di cartucce di insulina della fase di Packaging.

(13)

9

2

2. CASO DI STUDIO

L’obiettivo del progetto, svolto presso l’azienda SDG Group per una multinazionale farmaceutica, è la realizzazione di un report (un software) che permetta agli utenti il monitoraggio delle informazioni durante la fase di packaging del prodotto. I prodotti interessati sono cartucce di insulina o penne per insulina.

Nel presente capitolo, dopo aver inquadrato l’ambito di riferimento e le principali motivazioni del progetto, sono descritte alcune informazioni relative alla produzione di insulina, all’azienda sviluppatrice e alle funzionalità richieste. Non è presente il nome e la descrizione dell’azienda committente in quanto è stato richiesto da essa di

mantenere l’anonimato; per comprendere meglio il mercato di riferimento sarà fatta una breve descrizione del settore dell’industria farmaceutica.

2.1 Produzione dell’insulina

L’insulina (dal latino insula, “isola”, perché prodotta nelle Isole di Langerhans nel pancreas) è un ormone proteico che regola il metabolismo dei carboidrati. Ha principalmente la funzione di promuovere la diffusione di glucosio attraverso le

membrane cellulari diminuendo la glicemia (la concentrazione di zucchero nel sangue) e permettendo così l’utilizzo di glucosio ai diversi tessuti. [1]

Quando l’insulina è prodotta in quantità non sufficiente dal pancreas oppure le cellule dell’organismo non rispondono alla sua presenza, nel sangue si avranno livelli di glucosio più alti del normale (iperglicemia) favorendo, così, la comparsa del diabete. [2]

(14)

10 Fino agli anni ’80 i preparati insulinici industriali venivano prodotti utilizzando pancreas suini e bovini in quanto chimicamente simile a quello umano (la sequenza di insulina umana di 51 aminoacidi differisce da quella dell'insulina di maiale da un singolo

amminoacido e da tre aminoacidi derivati dall'insulina bovina). Il processo di estrazione dell’insulina dai pancreas suini e bovini era abbastanza complesso, richiedeva ingenti quantità di organi animali per produrre piccole quantità di insulina e era un processo che richiedeva molto tempo. Inoltre, c’era il problema che l’insulina di origine animale era riconosciuta dall’organismo umano come estranea e alcune persone che la utilizzavano sviluppavano reazioni immunitarie, rendendo quindi l’insulina meno efficace. Attualmente la maggior parte della produzione dei preparati insulinici viene realizzata tramite tecnologia genetica, risolvendo i problemi legati alla produzione di origine animale. Per la sintesi di insulina viene utilizzato il microrganismo Escherichia Coli. L’escherichia Coli è coltivata in serbatoi da 50000 litri chiamati fermentatori. Nel 1980 l’azienda committente ha prodotto un lotto padre, chiamato master cell bank, e da allora continua a coltivare un lotto di Humulin1_{. Humulin è un farmaco prodotto con}

moderne tecniche di ingegneria genetica, in cui il DNA umano viene inserito in una cellula ospite, l’Escherichia coli. 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; questi batteri vengono conservati in serbatoi in freezer a -70°C. A partire da mezzo grammo di batteri, i microrganismi iniziano a replicarsi, raddoppiando il loro numero ogni 20 minuti circa. Una volta che un serbatotio diventa troppo affollato, i batteri vengono spostati in altri sempre più capienti. I microrganismi devono prosperare in un brodo batterico composto da acqua, zucchero, sale, azoto e un additivo per prevenire la formazione di altri batteri che comprometterebbero la qualità del lotto. Dopo alcuni giorni di riproduzione, i batteri sono pronti per la

produzione dell’insulina e vengono separati dal loro brodo grazie a una centrifuga. Il brodo viene sostituito con un liquido contenente una sostanza (induttore) in grado di rompere le membrane cellulari, per fare in modo che i batteri vengano separati dall’insulina prodotta al loro interno. Dopo qualche ora, viene svolta la fase della purificazione, cioè l’isolamento dell’insulina dalle altre molecole. Lo step finale prima che l'insulina sia pronta per il confezionamento è la cristallizzazione. L'insulina è mescolata con lo zinco, che aiuta a formare cristalli stabili. I cristalli di insulina sono la

1_{Humulin è un farmaco prodotto con moderne tecniche di ingegneria genetica, in cui il DNA umano viene} inserito in una cellula ospite, l’Escherichia coli.

(15)

11 materia prima utilizzata per le fasi successive; solitamente alcuni siti produttivi hanno il compito di produrre cristalli di insulina e altri, partendo da questi cristalli, svolgono lavorazioni successive che prevedono la reidratazione dei cristalli. [3] Per quanto riguarda il sito italiano, in questo arrivano direttamente i cristalli di insulina e si occupa delle fasi successive della produzione.

2.2 Ciclo produttivo

Il processo produttivo dell’azienda farmaceutica si configura in tre macro-fasi riportate in figura 1.

Figura 1: Macro-fasi processo produttivo

Nello stabilimento italiano vengono svolte solo la seconda e terza fase in quanto i cristalli di insulina sono forniti da un altro sito produttivo.

1. Components: questa fase comprende tutte le lavorazioni fino alla produzione dei cristalli di insulina (insulina disidratata).

2.1 Formulation: l’insulina viene reidratata e combinata con altri elementi seguendo una precisa ricetta (recipe) ottenendo un lotto di formulazione. L’insulina è

contenuta in grandi serbatoi.

(16)

12 Figura 2: Cartuccia d'insulina

2.3 Sorting: prevede un sistema automatico di ispezione visiva (conosciuto anche come “Visual Inspection”) delle cartucce per identificare eventuali difettosità delle cartucce di insulina (ad esempio: crepatura vetro, colore insolito, presenza di altri microrganismi).

3. Packaging: è la fase che prevede l’applicazione dell’etichetta sul prodotto, il suo confezionamento e l’inserimento della documentazione necessaria all’interno della scatola. Questa fase differisce a seconda dello stato a cui saranno destinati i prodotti in quanto cambiano lingua e norme vigenti. Per la linea Blister è presente solo la fase packaging, mentre le linee Apollo e Irma hanno due sottofasi: wet e packaging. La fase di wet, svolta a priori rispetto alla fase di packaging, prevede l’inserimento della cartuccia di insulina all’interno di penne monouso o riutilizzabili. Le fasi di wet e packaging della linea Irma prevedono l’utilizzo di cartucce di insulina prodotte in altri siti.

In figura 3 è riportato il layout del sito produttivo italiano.

(17)

13 Il progetto in esame riguarda le attività di controllo qualità nella fase di packaging e per questo nel seguito sarà considerata solo questa ultima fase.

2.3 Descrizione del progetto Global Packaging Batch Review

Il progetto in esame è stato richiesto dall’azienda committente inizialmente solo per il sito di produzione italiano. Tale progetto è sviluppato seguendo le normative globali interne dell’azienda dato che anche altri siti produttivi si sono interessati a tale soluzione e hanno richiesto all’azienda sviluppatrice informazioni dettagliate e possibilità di alcuni requisiti differenti. L’azienda sviluppatrice, dialogando con i responsabili dei siti interessati, ha cercato di allineare il più possibile i requisiti

soluzione in modo tale da rendere applicabile a più siti la soluzione finale. In ogni caso, nella prima versione della soluzione, solo il sito italiano adotterà questo nuovo report. Una volta completata la fase di raccolta e definizione dei requisiti funzionali viene svolta la pianificazione e la stima dei costi e tempi di progetto. La stima dettagliata viene poi inviata ai responsabili che potranno accettare o meno tale offerta.

Il progetto Global Packaging Batch Review è stato pensato in seguito alla realizzazione della soluzione Global Batch Review il cui obiettivo è la validazione dei lotti per le fasi del processo produttivo precedenti al packaging, ovvero per Formulation, Filling e Sorting.

Il progetto ha permesso di fornire all’azienda presa in esame strumenti operazionali integrati con le soluzioni di business intelligence per la supervisione dei processi di packaging (governati da PMX, un sistema informatizzato che ha la funzione di

raccogliere e controllare i dati del sistema produttivo aziendale). L’oggetto in analisi è il lotto (Batch) di produzione e la sua conformità agli standard qualitativi del prodotto finale (Review). Il progetto è classificato come progetto non solo analitico ma anche operazionale che permette di validare, in concordanza alle norme di buona

fabbricazione (in inglese GMP - Good Manufacturing Practice), un lotto relativo alla fase di packaging molto più rapidamente di quanto possa essere fatto utilizzando un sistema di supervisione manuale.

Le norme di buona fabbricazione sono un insieme di procedure, regole e linee guida in base alle quali vengono prodotti i farmaci, i dispositivi medici, i prodotti per la

(18)

14 Ai fini degli standard GMP, essendo il processo di validazione quality del batch

fondamentale per la produzione e sua la commercializzazione, il progetto è da ritenersi un sistema di reporting operazionale critico per il business.

2.4 L’azienda sviluppatrice

Figura 4: Logo SDG Group

SDG Group (logo aziendale in figura 4) è una società di consulenza gestionale leader del settore, caratterizzata da una speciale visione delle pratiche di Business

Intelligence, Corporate Performance Management e Collaborative Business Analytics nello sviluppo di soluzioni manageriali e analitiche. Fondata a Milano nel 1991, attualmente è presente anche a Roma, Verona, Firenze, Londra, Barcellona, Madrid, Lisbona, Amburgo, Monaco, Cairo, Algeri, Dubai, Parigi, Londra, York, New Jersey, Lima e Bogotà. I servizi e le soluzioni offerte da SDG si sono progressivamente

arricchiti negli anni con l’aggiunta di social intelligence practices, big data architecture e business analytics d’avanguardia.

Mission aziendale: Strategy. Decision. Governance. Con queste tre parole si riassume la sfida che muove SDG ogni giorno. In quanto società di consulenza leader nel settore, SDG riconosce il fulcro delle proprie competenze nei modelli e nelle soluzioni di ricerca e sviluppo continui, attraverso la trasformazione degli stessi in Key Success Factors. [4]

(19)

15

2.5 Settore farmaceutico

Prima di parlare dell’azienda committente è utile presentare una breve introduzione del settore farmaceutico.

Le origini dell’industria farmaceutica moderna sono datate verso la fine del

diciannovesimo secolo. L’industria farmaceutica è caratterizzata da un elevato grado di complessità ed articolazione, per i considerevoli rischi d’impresa a cui è soggetta, derivanti soprattutto dall’attività di Ricerca&Sviluppo (R&D) che rappresenta il core business. I risultati della R&D sono tutelati dai brevetti che in ambito internazionale hanno la durata di 20 anni. Alla scadenza del brevetto cominciano a essere prodotti i farmaci generici, ovvero medicinali contenenti lo stesso principio attivo del prodotto originale. L’industria farmaceutica investe mediamente in ricerca, a livello mondiale, circa il 15% del fatturato. Dati gli alti costi necessari per l’attività di R&D (il costo medio di sviluppo di un nuovo farmaco si colloca tra $800 milioni e $1,2 miliardi), le quote di mercato sono principalmente suddivise dalle grandi aziende farmaceutiche, conosciute come le Big Pharma. Il fatturato globale delle aziende appartenenti al settore

farmaceutico è stimato a più di $1100 miliardi per il 2018, confermando il trend crescente riscontrato nell’ultimo decennio caratterizzato da un tasso di crescita annuale intorno al 5%. [5]

Nonostante risulta difficile operare una classificazione ben definita del settore

farmaceutico vista la complessità e l’estremo dinamismo che lo contraddistinguono, è utile illustrare una macrosegmentazione, seppure un po’ forzata, del settore

farmaceutico. Le tre aree tematiche (figura 5) in cui si articola l’industria farmaceutica sono le seguenti:

• Pharmaceutical • Biotechnology

(20)

16 Figura 5: Macrosegmentazione settore farmaceutico.

Il segmento dei Pharmaceutical rappresenta circa il 78% (figura 6) del valore dell’intero settore ed è dominato dagli “Ethical” Drugs, cioè i farmaci convenzionali (compresi anche i vaccini) per i quali è necessaria la prescrizione medica. Gli “Ethical” drugs costituiscono l’industria farmaceutica in senso stretto in cui operano le grandi

multinazionali farmaceutiche, le Big Pharma. A questo segmento sono collegati anche i farmaci “over the counter” (OTC Pharmaceutical), che prevedono la possibilità di essere acquistati dal consumatore finale senza prescrizione medica. Gli “Ethical” drugs e gli OTC sono presenti sul mercato sia in forma branded (con marchio) sia come “generici” (unbranded). La concorrenza all’interno del segmento è contenuta da fenomeni di barriere all’ingresso, di monopolio dovuti alla presenza di brevetti e all’elevata differenziazione dei prodotti che rendono la competizione diretta tra singoli prodotti poco rilevanti.

Il segmento Biotechnology comprende i farmaci prodotti attraverso molecole naturali più complesse che molto spesso sono create a partire da cellule viventi. Pertanto, i processi biotecnologici sono impiegati diffusamente nelle diverse fasi di sviluppo e test di nuovi farmaci (anche quelli che verranno poi prodotti con le tradizionali tecnologie di sintesi chimica). Il mercato globale delle biotecnologie presenta tassi di crescita molto interessanti, generando un volume d’affari nel 2008 pari a 216,3 miliardi di dollari.

(21)

17 Il segmento dei Life Science Medical Device è costituito dalle strumentazioni e dalle attrezzature al servizio dell’industria farmaceutica e di quella biotech. [6]

Figura 6: Fatturato settore farmaceutico.

2.6 L’azienda committente

L’azienda committente è una multinazionale farmaceutica di origine statunitense, fondata sul finire dell’800. La società ha stabilimenti produttivi in oltre 10 paesi ed è impegnata nel campo della ricerca, nell’innovazione di prodotto, nella ricerca di soluzioni sanitarie e di terapie farmacologiche. Nello stabilimento italiano il processo produttivo dell’azienda riguarda la produzione di penne e cartucce di insulina da immettere sul mercato. Dal 2017 nel sito italiano la produzione di insulina soddisfa quasi un terzo del fabbisogno mondiale. Essendo l’insulina un farmaco realizzato attraverso molecole complesse prodotte da cellule viventi, l’azienda committente rientra nel settore Biotechnology.

Mission aziendale: produrre medicine che aiutano le persone a vivere più a lungo, in salute e vite più attive.

Vision aziendale: dare un contributo significativo all’umanità migliorando la salute globale nel 21° secolo.

(22)

18

2.7 Caratteristiche e obiettivi del progetto

Il progetto Global Packaging Batch Review è stato richiesto dall’azienda committente al fine di migliorare e snellire il processo della validazione dei lotti nella fase di Packaging. Con la realizzazione di questo progetto verrà soddisfatta l’esigenza dell’azienda cliente in quanto attualmente gli utenti per accertarsi della corretta rispondenza ai requisiti di un lotto sono costretti a consultare dati e informazioni provenienti da diversi report. Tale processo è attualmente non ottimizzato in quanto all’utente non appaiono automaticamente tutti i dati necessari per questo tipo di analisi ma deve estrarre tali dati in diversi report e questo richiede molto tempo. Il nuovo progetto garantirà agli utenti tutti e soli i dati necessari per la validazione di un lotto in un’unica soluzione di reportistica, permettendo così una migliore chiarezza e un notevole risparmio in termini di tempo.

L’esecuzione del progetto può essere concettualmente divisa in due macro-fasi, la prima chiamata di Back-end e la seconda di Front-end:

1. Estrazione dei dati dai sistemi sorgenti dell’azienda e aggregazione dei dati nel database utilizzando le logiche di business utilizzate;

2. Creazione di un report che permetta di mostrare tali dati estratti in un formato comprensibile e semplice per gli utenti.

Tale progetto è stato svolto interamente da me e il mio tutor aziendale. Dopo un periodo di due settimane di training, il mio lavoro è iniziato contemporaneamente con il Kick off2_{del progetto e ho seguito e collaborato fino al termine di esso.}

La fase di Back-end è stata svolta utilizzando prevalentemente Informatica Power Center, che è uno strumento che permetta l’estrazione, la trasformazione e il caricamento di dati.

La fase di Front-end è stata svolta utilizzando SAP Business Object che permette la creazione del report che poi verrà utilizzato dagli utenti.

Entrambi gli strumenti utilizzati verranno poi illustrati nel dettaglio nel capitolo 5.

(23)

19

3

3. ANALISI REQUISITI E PROGETTAZIONE

CONCETTUALE

3.1 Raccolta dei requisiti

La raccolta dei requisiti del report è stata svolta nelle seguenti fasi:

• Inizialmente è stato fatto un documento di requisiti da parte dell’azienda cliente che è stato consegnato all’azienda sviluppatrice SDG;

• Il team di SDG che è incaricato allo sviluppo del progetto si riunisce e analizza il documento dei requisiti ricevuto. In presenza di qualche requisito non specifico o fraintendibile vengono svolte riunioni tra l’azienda sviluppatrice e l’azienda committente per chiarire tali punti;

• Una volta determinati i requisiti finali il team SDG effettua una stima dei tempi e dei costi del progetto calcolati in Full-Time Equivalent (ovvero le giornate uomo necessarie a svolgere l’intero progetto) e la manda all’azienda committente che può decidere se accettare o meno tale offerta. Nel caso non venga accettata segue una contrattazione tra le due parti. Nel caso dei progetti svolti da SDG per questa multinazionale farmaceutica la contrattazione non avviene di frequente in quanto tra le due aziende c’è un rapporto di fiducia e di collaborazione di lungo periodo;

• Sono concessi cambiamenti dei requisiti del report entro il periodo di sviluppo. Quando viene approvata la documentazione per passare all’ambiente di

(24)

20 sviluppo successivo (in QAR) non sono più consentite modifiche (eventuali modifiche possono essere richieste in release3_successive).

Oltre ai requisiti tecnici richiesti dal cliente, che verranno poi spiegati dettagliatamente nei successivi paragrafi, l’azienda committente richiede che il report sia eseguibile (quindi nell’ambiente di sviluppo PRD) entro inizio agosto e che i dati abbiano una latenza massima di 3 ore.

La latenza massima di 3 ore è dettata da logiche di business, in quanto è possibile che in 3 ore venga iniziata e completata la fase di packaging di un lotto, e quindi per la validazione di tale lotto sono indispensabili i dati aggiornati. Attualmente l’azienda per la validazione dei lotti per la fase di packaging utilizza diversi strumenti di reportistica dove però è necessario andare a cercare i dati necessari e quindi richiedono maggiore tempo da parte degli utilizzatori. Con l’utilizzo del nuovo report è stato calcolato un benefit equivalente a 1 FTE e per questo è stato fissata la data di rilascio del report a inizio agosto perché altrimenti l’azienda committente avrebbe avuto la necessità di assumere, e formare, un nuovo utente.

Attualmente i flussi ETL sono eseguiti due o tre volte al giorno, sia dai sistemi sorgenti all’area di Staging, sia dallo Staging al Core e infine dal Core all’area dei Data Mart; quindi per valutare la possibilità di aggiornare i dati ogni 3 ore (8 volte al giorno) è stata eseguita un’analisi sulle durate di questi flussi. Sono stati ricavati i dati sulla durata dei flussi ETL interessati all’area del progetto relativi agli ultimi 2 mesi e è stato controllato che la durata massima non superasse le 3 ore di tempo. Per i flussi relativi al sistema sorgente PMX la durata superava spesso le 3 ore e quindi è stata necessaria una modifica. Sono state identificate tutte le tabelle dell’Area di Staging e del Core

interessate al progetto ed è stato diviso il flusso da PMX in due flussi differenti: il flusso contenente le tabelle necessarie per il progetto Global Packaging Batch Review è stato schedulato ogni 3 ore, mentre l’altro flusso di PMX contenente il resto delle tabelle è rimasto schedulato come in precedenza. Per effettuare questo diverso caricamento delle tabelle di PMX è stato utilizzato il campo tecnico delle tabelle SRC_INST_CD valorizzato a PPN_SES per le tabelle del flusso schedulato ogni 3 ore e

PPN_SES_OTHER per l’atro flusso.

(25)

21 Nello sviluppo del progetto il linguaggio SQL ha avuto un ruolo di primaria importanza ed è stata utilizzata la tecnica di programmazione parametrica per i seguenti motivi:

• Per il passaggio negli ambienti di sviluppo non è necessario andare a modificare tutti i flussi andando a cambiare il database e lo schema di riferimento ma è necessario utilizzare un file dei parametri differente;

• Il progetto Global Packaging Batch Review è un progetto a livello globale, come dice il nome stesso, in quanto anche altri siti dell’azienda committente si sono interessate ed è previsto lo sviluppo del report per almeno altri due siti

produttivi. Per questo motivo è utile parametrizzare il linguaggio (in questo caso specifico parametrizzare l’attributo FCLTY_CD, campo che identifica

univocamente un determinato sito produttivo) così che quando sarà sviluppato per altri siti sarà solo necessario utilizzare un file dei parametri che permetta una diversa valorizzazione dei parametri riguardanti il sito produttivo.

3.2 Project Plan

In base ai requisiti ricevuti il team di SDG crea il seguente project plan:

(26)

22 In accordo con quanto illustrato nel project plan gli sviluppi back-end devono essere terminati entro il 4 maggio e il 18 maggio devono essere consegnate tutte le sezioni del report. In concomitanza con lo sviluppo del report gli utenti potranno accedere al

report, testando informalmente le varie sezioni create e fornendo feedback che permettano agli sviluppatori di correggere il report. Durante la fase di sviluppo del report dovrà essere creata anche la documentazione necessaria per l’approvazione del report. Per il 15 giugno è previsto che l’intero report sia stato corretto in base alle segnalazioni degli utenti, mentre a inizio luglio è programmato il passaggio

nell’ambiente di testing e ad agosto il passaggio nell’ambiente di produzione e quindi l’effettivo utilizzo del report da parte degli utenti. La deadline del progetto è molto sfidante a causa della richiesta dell’azienda committente di avere a disposizione il report validato per lo shutdown4_{estivo dell’impianto produttivo. A luglio sono anche}

previsti dei test per una soluzione sviluppata precedentemente, la Global Batch Review del semifinito, in quanto alcuni Data mart sono condivisi dalle due soluzioni; questi test servono per certificare che le modifiche effettuate sulle tabelle in comune non

compromettano il corretto funzionamento della soluzione precedentemente esistente. Da parte di SDG non è stata programmata alcuna tipologia di training agli utenti per due motivi:

• Il report sarà strutturato in modo semplice e intuitivo;

• Sarà creata una SOP5_{(Standard Operating Procedure) da parte degli utenti che}

hanno fornito i requisiti per la soluzione e con la quale c’è stata collaborazione durante le varie fasi del progetto.

3.3 Analisi dei requisiti tecnici

I requisiti raccolti e concordati con il cliente prevedono che il report venga sviluppato in 13 sezioni differenti:

• Report Information • Batch Information

4_{Shutdown: interruzione del sistema produttivo dell’azienda.}

5_{Le SOP sono documenti di proprietà aziendale che hanno lo scopo di chiarire le procedure utilizzate per}

(27)

23 • Batch Genealogy

• Log PMX-PPN • Trackwise Events

• Clichè and Printed Materials • Alarms

• Recipe Parameters Modifications • Batch Quantity Information • Challenge Tests

• IPC • Checklist • Cleaning.

In ogni sezione devono essere mostrati il lotto, il materiale associato e il numero dell’ordine di lavorazione del lotto. Nella prima sezione deve essere riportato l’elenco delle sezioni del report e una tabella contenente i sistemi sorgenti e la data associata dell’ultimo caricamento dei dati. In questa prima sezione non sono presenti dati necessari per il processo di validazione dei lotti. Nella tabella seguente vengono mostrati i requisiti e le dimensioni di analisi coinvolte per le altre sezioni del report:

Sezione

Requisiti

Dimensioni

Batch Information Questa sezione è strutturata in due sottosezioni, General Information e Ticket Steps. Nella General information vengono mostrati

l’identificativo del lotto, il codice e la descrizione del materiale, il numero

dell’ordine, la data6_{di inizio}

e fine Packaging, la data in cui è stato approvato il lotto del semifinito, la data di

Batch Parenteral, Production Procedure utilizzate per entrambi le sottosezioni e Work Center utilizzata solo per la sottosezione Ticket Steps.

(28)

24 scadenza e il paese di

destinazione del lotto. Nella Ticket Steps sono mostrati gli step delle fasi di

packaging, lo stato e il Work Center nel quale è stata svolta la lavorazione Batch Genealogy In questa sezione devono

essere mostrati il codice dei materiali, il numero

dell’ordine e il lotto che sono di input alla fase di Packaging. Quindi per la fase di Wet verranno mostrati lotti del semifinito mentre per la fase di Packaging verranno mostrati lotti della fase di Wet.

Batch Parenteral (poi dati caricati in Identified Material Datamart)

Log PMX-PPN In questa sezione vengono mostrati i Log7_{(numero e}

descrizione) inseriti dagli utenti e la firma dell’utente con l’ID. In questa tabella sono presenti anche due campi, vecchio valore e nuovo valore, utilizzati quando un utente effettua cambiamenti su alcuni parametri del processo.

PMX Log

Trackwise Events Questa sezione deve mostrare i Log provenienti da Trackwise. Nel dettaglio

I dati necessari per questa sezione non erano presenti in nessuna tabella del Core.

(29)

25 devono comparire

l’identificativo del Log, la data di creazione, lo stato, il tipo (osservazione o deviazione), la descrizione inserita e la firma

dell’utente.

Per questo è stata prevista la creazione di una nuova tabella Deviation Information nella quale caricare i dati necessari dalle tabelle di Staging.

Clichè and Printed Materials

Questa sezione è divisa in due sottosezioni, Clichè Note e Printed Materials. Nella prima sono riportati numero di batch, data di scadenza, e alcuni dati di testo che riportano

caratteristiche del prodotto finito. Nella seconda tabella sono presenti tutti i

materiali usati per la fase di packaging vera e propria come ad esempio scatola, astuccio e etichette. Per i lotti di Wet questa sezione non è applicabile.

I dati necessari per questa sezione non erano presenti in nessuna tabella del Core. Per questo è stata prevista la creazione di una nuova tabella Printed Label nella quale caricare i dati necessari dalle tabelle di Staging.

Alarms Nella sezione degli allarmi sono riportati tutti gli allarmi scattati da inizio a fine fase di packaging. Per ogni allarme il report deve mostrare la data in cui è scattato, il macchinario, la descrizione dell’allarme, la data in cui l’allarme viene chiuso e la firma

dell’operatore.

Alarms (poi dati caricati in Alarms Batch Datamart)

(30)

26 Recipe Parameters

Modifications

In questa sezione devono essere mostrate le

informazioni relative a cambi di parametri nelle fasi di lavorazione. Devono essere presenti la data della modifica, il macchinario, l’azione svolta, il vecchio e il nuovo valore, la firma di chi effettua la modifica e di chi l’approva.

Critical Changes

Batch Quantity Information

Questa sezione è suddivisa in Quantity Information e PMX Output Quantity. Nella prima sezione deve essere mostrata la quantità di cartucce e di campioni per ciascun lotto. Nella

seconda sono mostrate le unità di carico, il relativo numero di cartucce associato e la data.

Material identification (poi dati caricati in Identified Material Datamart)

Challenge Tests In questa sezione sono riportate le checklist eseguite per controllare alcuni dispositivi automatici. Per ciascuna macchina su cui devono essere effettuati tali controlli devono essere mostrati il nome delle checklist con il relativo valore inserito dall’utente (Not Applicable o

Process value (poi dati caricati in Batch Disposition Datamart)

(31)

27 Compliant), la data e la

firma dell’utente. IPC8 _{Questa sezione è}

strutturata con la stessa logica della precedente. Le Sezioni sono state divise per logiche di business per dividere le checklist svolte per i dispositivi automatici e per gli IPC.

Checklist Questa sezione è

composta da Maintenance Checklists and Other Checklist. La prima sezione deve riportare informazioni riguardo la manutenzione dei macchinari come la firma dell’utente, l’azione svolta, il macchinario, il componente e la data. Nella seconda sezione sono riportate le checklist non automatiche ma aperte a mano dagli utenti.

Cleaning Nella sezione cleaning devono essere mostrate tre tabelle. Nella prima sono mostrate il tipo di pulizia (“Minore” o “Maggiore”) effettuata dopo il lotto e la data; nella seconda deve essere mostrato l’ultimo lotto (in ordine temporale)

(32)

28 sul quale è stata effettuata

una pulizia “Maggiore” e la data in cui è stata fatta. Nella terza tabella devono essere mostrati il lotto e il materiale del lotto

precedente e successivo passati per la stessa linea produttiva

Tabella 1 Requisiti sezioni del report

Le dimensioni della tabella precedenti corrispondono alle tabelle del Core dal quale vengono estratte le informazioni da mostrare a report.

Nella tabella successiva, per ognuna di queste tabelle, viene riportate una breve descrizione e la granularità (con il termine granularità è inteso il livello di dettaglio delle tabelle).

Nome tabella

Descrizione

Granularità

Batch Parenteral Informazioni relative al lotto di insulina sul quale vengono svolte le attività

Batch

Production Procedure Per ogni lotto sono presenti i dettagli di production procedure

Production procedure

Work Center Informazioni relative ai Work Center di

produzione

Work Center

PMX Log Dimensione dove vengo

registrati i Log provenienti da PMX

Il singolo Log

Deviation Information Dimensione dove vengono registrate le deviazioni da Trackwise

(33)

29 Printed Label Informazioni relative alle

informazioni da stampare per ciascun lotto

Batch

Alarms Informazioni relative agli

allarmi scattati nel reparto produttivo

Allarme

Critical Changes Informazioni relative ad attività critiche che si sono verificate durante il

processo produttivo

Attività critica

Material identification Informazioni relative ai materiali utilizzati durante il processo produttivo per ogni lotto

Materiale

Process value Informazioni riguardanti vari aspetti del processo produttivo

La singola informazione

Tabella 2 Tabelle in analisi

3.4 Attributi delle tabelle del Core utilizzati

In questa sezione non vengono elencati gli attributi tecnici presenti nelle tabelle in quanto essi vengono utilizzati solo come filtro dagli sviluppatori.

Per ogni tabella utilizzata viene fornita l’elenco degli attributi utilizzati e una breve descrizione di essi:

Attributo Descrizione

Batch Code Identificativo del lotto

Material Code Codice del materiale

Process Order code Il numero dell’ordine

Packaging Line code Nome della linea di Packaging Packaging Start Date Data di inizio Packaging

(34)

30

Packaging End Date Data di fine Packaging

Destination Country Paese di destinazione

Quantity Quantità di cartucce del singolo lotto

Tabella 3 Batch Parenteral

Prod Procedure Code Identificativo della production procedure Prod Procedure Version La versione della production procedure Prod Procedure Ver Start Dt Data di inizio validità

Prod Procedure Ver End Dt Data di fine validità

Prod Procedure Status Desc Descrizione dello stato in cui si trova una production procedure (obsoleto, in approvazione etc.)

Tabella 4 Production Procedure

Work Center Code Identificativo del Work Center Work Center Description Descrizione del Work Center

Tabella 5 Work Center

Annotation Code Identificativo del Log

Annotation Description Descrizione del Log

Annotation Date Data in cui è stato registrato Log Annotation User Firma di chi ha registrato il Log Annotation Type Description Tipo di Log

New Value Nuovo valore del parametro

Old Value Vecchio valore del parametro

Tabella 6 PMX Log

(35)

31

Batch Code Lotto al quale è associata una

deviazione

Date Discovered Data rilevamento deviazione

Event Type Gravità della deviazione

Deviation Status Stato della deviazione

Description Descrizione inserita dall’utente

Person Code Identificativo di chi controlla la

deviazione Tabella 7 Deviation Information

Batch Code Identificativo del Batch

Process Order code Il numero dell’ordine

Type Description Stringa stampata (es Expiry Date)

Value Valore associata alla stranga (es data di

scadenza del lotto) Tabella 8 Printed Label

Alarm Id Identificativo dell’allarme

Description Descrizione dell’allarme

Machine Code Macchinario sul quale è scattato l’allarme

Batch Code Lotto su cui è scattato l’allarme

Alarm In Start Date Data in cui è scattato l’allarme Alarm Out Start Date Data in cui è risolto l’allarme

User Identificativo dell’operatore che si occupa

di risolvere l’allarme Tabella 9 Alarms

(36)

32

Critical Changes Id Identificativo dell’azione critica

Description Descrizione dell’allarme

Parameter Description Parametro modificato durante processo produttivo

Batch Code Lotto su cui è scattato l’allarme

Parameter Initial Value Valore del parametro di partenza Parameter Final Value Valore del parametro dopo modifica

Machine Code Macchinario sul quale è avvenuta la

modifica

User Id Identificativo dell’operatore che approva

azione critica Tabella 10 Critical Changes

Batch Code Identificativo del lotto del materiale

Material Code Codice materiale

Material Description Descrizione materiale

Quantity Quantità disponibile

Output Batch Code Lotto di prodotto finito per il quale è usato ciascun materiale

Load Carrier Unità di carico

Tabella 11 Material Identification

Process Order Code Il numero dell’ordine

Linked Procedure Step Code Si tratta di tre campi chiave della tabella che insieme all’identificativo del lotto e il numero dell’ordine identificano in maniera univoca un record. Procedure Step Short Description

(37)

33

Value Valore attribuito a un certo record

Date Data in cui è stata registrata

l’informazione Tabella 12 Process Value

3.5 Gestione degli attributi

Gli attributi elencati nelle precedenti tabelle possono essere dei seguenti tipi: • Varchar: associato ai campi contenente stringhe;

• Timestamp: associato ai campi data;

• BigInt: associato ai campi contenenti numeri interi; • Numeric: associato ai campi numerici non interi.

Non è stato ritenuto utile mostrare il tipo di dato associato a ogni attribuito in quanto poco influente alla realizzazione del progetto in analisi.

Esistono alcuni attributi non statici ma che possono subire modifiche nel tempo. Per la gestione di questi attributi è possibile adottare differenti strategie di storicizzazione:

• Slowly changing dimensions di Tipo 1: il nuovo valore di un attributo va sostituito al valore precedente. È la soluzione più semplice, ma non si ha la storicizzazione dei valori (non si può effettuare AS WAS analisys). Il vantaggio del Tipo 1 è il risparmio di spazio.

Figura 8 Slowly changing dimensions di Tipo 1

• Slowly changing dimensions di Tipo 2: con questo metodo si ha una parziale storicizzazione del dato. Per ogni record abbiamo registrato il valore attuale e il valore precedente all’ultimo cambiamento e la data del cambiamento.

(38)

34 Figura 9 Slowly changing dimensions di Tipo 2

• Slowly changing dimensions di Tipo 3: con questo metodo ogni volta che un attributo cambia viene inserito un nuovo record con le date di inizio e fine periodo in cui è stato valido il valore di quell’attributo. È la soluzione più comune che permette la storicizzazione del dato ma ha il difetto di occupare lo spazio occupato.

Figura 10 Slowly changing dimensions di Tipo 3

• Tipo 4: utilizzato per gli attributi che cambiano frequentemente. In questo caso è preferibile separare la tabella in due tabelle, una contenente gli attributi destinati a non cambiare nel tempo e l’altra contenente i rimanenti, organizzati in intervalli di valori.

Figura 11 Storicizzazione di attributi che cambiano rapidamente

Per il progetto in esame non interessa mantenere lo storico delle informazioni in quanto il report che verrà prodotto deve fornire informazioni riguardanti i lotti di prodotto finito e per i quali ancora non è stato deciso se possono essere immessi sul mercato. Non interessa quindi analizzare trend sulla base dei cambiamenti avvenuti nel tempo, ma bisogna prendere in esame i dati elaborati di un determinato arco temporale.

(39)

35

3.6 Progettazione logica del data mart

Per alcune sezioni del report i dati sono stati trasferiti dal Core all’area dei Datamart riutilizzando tabelle già esistenti utilizzate da altre soluzioni. In alcuni casi si è resa necessaria l’aggiunta di alcune colonne (attributi). Questo è stato fatto sia per sfruttare le tabelle già presenti nell’Universo (concetto approfondito nel paragrafo 5.6) sia per logiche di business. Ad esempio, per la sezione del report riguardante gli allarmi è stato richiesto di mostrare nel report gli allarmi con gravità (severity) 1 e 2 e non mostrare gli altri. Utilizzando il Data mart è stato possibile filtrare i dati degli allarmi caricando la tabella del Data mart solo con gli allarmi di effettivo interesse. In questo modo quando il report verrà utilizzato dagli utenti avrà performance migliori in quanto invece di cercare tra tutti gli allarmi di un lotto e poi filtrare per gli allarmi con una certa severity, basterà mostrare tutti gli allarmi presenti relativi a un lotto.

Di particolare interesse è il Datamart Batch Disposition e la logica con cui questo è caricato. Questo Datamart è popolato con due tabelle del Core: la Process Value e la Batch Disposition CNF. Con il termine CNF vengono identificate le tabelle di

configurazione. Le tabelle di configurazione sono tabelle nelle quali i record sono inseriti dagli sviluppatori. I record sono inseriti manualmente utilizzando il seguente comando SQL:

INSERT INTO table_name (column1, column2, column3, ...) VALUES (value1, value2, value3, ...);

Le tabelle di configurazione servono per filtrare le tabelle del Core. Per spiegare bene il concetto riporto gli attributi della Process Value illustrati nel paragrafo precedente:

Process Order Code Il numero dell’ordine

Linked Procedure Step Code (LPS) Si tratta di tre campi chiave della tabella che insieme all’identificativo del lotto e il numero dell’ordine identificano in maniera univoca un record. Procedure Step Short Description (PS)

Variable Text (PV)

(40)

36 Gli attributi della tabella di configurazione sono i seguenti:

• Linked Procedure Step Code (LPS) • Procedure Step Short Description (PS) • Variable Text (PV)

Gli attributi LPS, PS e PV identificano univocamente il valore di una certa informazione. Quindi inserendo nella tabella di configurazione determinati valori di LPS, PS e PV e facendo l’operazione di Join tra le due tabelle andremo a popolare il Datamart con le informazioni necessarie al nostro report. Ad esempio, questo Datamart è utilizzato per la sezione del report Challenge Tests dove devono essere mostrate le checklist eseguite per controllare alcuni dispositivi automatici. I tre valori distinti LPS, PS, PV identificano univocamente il nome di una singola Checklist, mentre il valore inserito dall’utente è contenuto nel campo Value.

(41)

37

4

4. ARCHITETTURA DI DATA WAREHOUSE

4.1 Data warehouse

Nel 1990 è stata fornita da William Inmon la prima definizione di data warehouse che ancora oggi è considerata valida ed è ampiamente utilizzata: “A data warehouse is a subject-oriented, integrated, nonvolatile, and timevarying collection of data in support of management’s decisions”. [13]

Esaminiamo ora le caratteristiche del data warehouse:

• Organizzato per soggetti: nei database operazionali i dati sono organizzati per svolgere le attività aziendali quotidiane e per ottimizzare l’elaborazione delle transazioni; nei data warehouse i dati sono organizzati per analizzare dei soggetti di interesse che influenzano l’andamento complessivo dell’azienda. Un Datamart (chiamato anche chiamato extension) è un sottoinsieme o

un’aggregazione dei dati presenti nel data warehouse, contenente l’insieme delle informazioni rilevanti per una particolare area del business, una particolare divisione dell’azienda, una particolare categoria di soggetti. • Integrato: i dati raccolti nel data warehouse provengono in genere da più

sistemi sorgenti; questi devono essere uniti in un insieme coerente di dati tramite un processo di integrazione di dati eterogenei.

• Non volatile: i dati vengono usati interattivamente per eseguire query e altre operazioni di analisi; i dati non vengo usati per operazioni di modifica. Periodicamente possono essere aggiunti nuovi dati o rimossi quelli ritenuti obsoleti.

(42)

38 • Tempificato: per un sistema operativo i dati memorizzati contengono i valori

correnti. I dati raccolti nel data warehouse contengono informazioni sul tempo in cui si verificano gli eventi di interesse. Questa caratteristica permette lo studio dei dati storici e quindi l’analisi e il supporto decisionale.

• Finalizzato ad analisi di supporto alle decisioni: i dati sono organizzati per facilitare la loro analisi allo scopo di produrre delle opportune sintesi di supporto ai processi decisionali.

Un data warehouse è solitamente separato da un database operativo per i seguenti motivi:

• Performance: l’operazione di analisi dei dati richiede in genere query complesse che degraderebbero le prestazioni delle transazioni operative. • Funzione: il supporto decisionale richiede dati storici, che i database operativi

non mantengono, e l’integrazione di dati da fonti eterogenee.

La costruzione di un sistema di Data Warehouse non comporta l’inserimento di nuove informazioni bensì la riorganizzazione di quelle esistenti.

La tabella 13 mostra le differenze tra le applicazioni tradizionali che usano i database (On Line Transaction Processing, OLTP) e le applicazioni per il supporto alle decisioni che usano i data warehouse (On Line Analytical Processing, OLAP). [14]

OLTP OLAP

Funzione Sistemi per la gestione dei dati

Sistemi per l’analisi dei dati e per il supporto alle

decisionali

Utenti Molti, livello operativo Pochi, livello direzionale Complessità Bassa complessità delle

operazioni (90% ripetitive)

Permettono di eseguire operazioni non previste nella progettazione del DB (90% soluzioni ad hoc) Quantità di dati Le operazioni coinvolgono

una piccola quantità di dati

Operano su grosse moli di dati

Dati Correnti, aggiornati,

dettagliati, omogenei

Storici (anche previsioni), aggregati, multidimensionali, eterogenei

(43)

39

Acceso Lettura e scrittura Lettura con query

complesse

Fonti Generalmente operano su

dati provenienti da un’unica fonte

Operano su dati provenienti da più fonti eterogenee

DB size 100 MB to GB 100 GB to TB

Altre proprietà Devono essere rispettate le proprietà ACID (atomicità, correttezza, isolamento, durabilità) delle transazioni

Le proprietà ACID non sono rilevanti perché le

operazioni sono di sola lettura

Tabella 13: Differenze OLTP-OLAP.

4.2 Architettura sistemi data warehousing

Con il termine data warehousing si fa riferimento a una collezione di metodi, tecnologie e strumenti di ausilio al knowledge worker (dirigente, amministratore, gestore, analista) per condurre analisi dei dati finalizzate all’attuazione di processi decisionali e al

miglioramento del patrimonio informativo.

Caratteristiche del processo di data warehousing: [15]

• accessibilità a utenti con conoscenze limitate di informatica e strutture dati; • integrazione dei dati sulla base di un modello standard dell’impresa; • flessibilità di interrogazione per trarre il massimo vantaggio dal patrimonio

informativo esistente;

• sintesi per permettere analisi mirate ed efficaci;

• rappresentazione multidimensionale per offrire all’utente una visione intuitiva ed efficacemente manipolabile delle informazioni;

• correttezza e completezza dei dati integrati.

L’architettura dei sistemi di data warehousing deve possedere i seguenti requisiti: [15] • Separazione: l’elaborazione analitica e quella transazionale devono essere

(44)

40 • Scalabilità: l’architettura hardware e software deve poter essere facilmente

ridimensionata a fronte della crescita nel tempo dei volumi di dati da gestire e elaborare e in relazione al numero di utenti da soddisfare.

• Estendibilità: deve essere possibile accogliere nuove applicazioni e tecnologie senza riprogettare integralmente il sistema.

• Sicurezza: il controllo sugli accessi è essenziale a causa della natura strategica dei dati memorizzati.

• Amministrabilità: la complessità dell’attività di amministrazione non deve risultare eccessiva.

Esistono tre diverse soluzioni architetturali da applicare a un processo di data warehousing [16]:

• Architettura a un livello (figura 12): l’obiettivo è la minimizzazione dei dati memorizzati, ottenuta tramite l’eliminazione delle ridondanze. Il data warehouse in questa soluzione è virtuale, cioè viene implementato come una vista

multidimensionale dei dati operativi. Il punto debole di questa architettura è che l’elaborazione analitica OLAP e quella transazionale OLTP non sono separate. Le query di analisi vengono eseguite sui dati operazionali, interferendo così con il normale carico di lavoro transazionale. Con questa architettura è possibile esprimere un livello di storicizzazione superiore a quello dei sistemi sorgenti. Questa soluzione è utilizzata in genere dalle piccole organizzazioni in quanto il volume di dati da esaminare è limitato e perché risulta una soluzione a basso costo.

(45)

41 Figura 12: Architettura a un livello di un data warehouse.

• Architettura a due livelli (figura 13): tradizionalmente denominata a due livelli per evidenziare la separazione tra il livello delle sorgenti e quello del data warehouse. In realtà è articolata su quattro livelli distinti che descrivono stadi successivi del flusso dei dati. Questi livelli sono:

o Livello delle sorgenti: il DW utilizza fonti di dati eterogenei estratti dai sistemi sorgenti.

o Livello di alimentazione: i dati memorizzati nei sistemi sorgenti devono essere estratti, ripuliti (per eliminare le inconsistenze e completare eventuali parti mancanti) e integrati (per fondere sorgenti eterogenee secondo uno schema comune) utilizzando gli strumenti ETL (Extraction, Transformation and Loading).

o Livello del Warehouse. Le informazioni vengono raccolte nel DW, centralizzato logicamente. Esso può essere direttamente consultato, ma anche usato come sorgente per costruire data mart; questi ultimi sono orientati verso specifiche aree dell’impresa e, di fatto, costituiscono una replica parziale del Data Warehouse. Il contenitore dei metadati

mantiene informazioni sulle sorgenti, sui meccanismi di accesso, sulle procedure di pulitura ed alimentazione, sugli utenti, sugli schemi dei data mart, ecc.

(46)

42 o Livello di Analisi. Permette la consultazione efficiente e flessibile dei dati

integrati per la stesura dei report e per le attività di analisi e di simulazione.

Figura 13: Architettura a due livelli di un data warehouse.

• Architettura a tre livelli: il terzo livello introdotto in questa architettura è il livello dei dati riconciliati, cioè dati operazionali ottenuti a valle del processo di integrazione e ripulitura dei dati sorgente: quindi i dati sono integrati,

consistenti, corretti, volatili, correnti e dettagliati. Questo livello è anche detto staging area. I dati nella staging area possono essere aggiornati continuamente come quelli operativi, e quindi trasferiti nel data warehouse quando necessario. Con questa soluzione si rendono indipendenti i sistemi sorgenti dal data

warehouse evitando possibili interferenze e un conseguente calo delle

performance. I metadati (MD) sono informazioni sulla struttura, il contenuto e le interdipendenze dei componenti del data warehouse, per supportare

(47)

43 sviluppatori e amministratori responsabili degli strumenti del data warehouse e degli utenti finali. Come illustrato nella figura 14, il data warehouse non viene più alimentato direttamente dai sistemi sorgenti, bensì dai dati riconciliati. I dati riconciliati introducono un’ulteriore ridondanza rispetto ai dati operazionali dei sistemi sorgenti. In certi casi si può assumere che anche nelle architetture a due livelli sia presente un livello riconciliato, che non sarà, in quel caso,

materializzato ma soltanto virtuale, essendo definito come una vista integrata e consistente dei dati memorizzati nei sistemi sorgenti operazionali.

(48)

44

4.3 Normalizzazione database

Per comprendere meglio la modellazione dei data warehouse viene posta prima l’attenzione sul concetto di normalizzazione di un database. La normalizzazione è un metodo di organizzazione dei dati in un database per ridurre la ridondanza dei dati ed eliminare eventuali anomalie indesiderate. Per comprendere meglio questo concetto viene proposto anche un semplice esempio partendo dalla tabella in figura 15. [17]

Figura 15: Esempio parte 1. • 1a forma normale (1NF)

La prima forma Normale richiede che il valore di ciascun attributo contenga solo un singolo valore dal dominio di quell'attributo. In breve, questo significa che puoi solo inserire un valore per ogni cella della tabella. Viene ottenuta la tabella in figura 16.

(49)

45 • 2a forma normale (2NF)

Una tabella è in seconda forma normale se e solo se si trova in prima forma normale e ogni attributo non-prime della tabella dipende dalla chiave. La chiave è qualcosa che identifica in modo univoco ogni record della tabella. In questo esempio la chiave è data dalla combinazione di "Date", "Product name" e "Customer name", in quanto tale combinazione è unica e quindi identifica in modo univoco ogni record della tabella. Queste colonne sono gli attributi prime, mentre le altre sono attributi non-prime. In questo esempio "Customer city" è solo correlata al " Customer name " ma non ha alcuna connessione con " Product name " o "Date", ecc. Quindi la tabella non è in seconda forma normale.

Per portare questa tabella alla seconda forma normale, dividiamo la tabella come riportato in figura 17.

Figura 17: Esempio parte 3. • 3a forma normale (3NF)

Una tabella è in terza forma normale se è in seconda forma normale e se tutti gli attributi chiave dipendono dalla chiave soltanto, ossia non esistono attributi non-chiave che dipendono da altri attributi non-non-chiave. Tale normalizzazione elimina la dipendenza transitiva degli attributi dalla chiave.

(50)

46 Per semplificare la dichiarazione di cui sopra, supponiamo di decidere di memorizzare il codice postale dei clienti insieme alla città del cliente nella seconda tabella, come mostrato in figura 18.

Figura 18: Esempio parte 4.

Questa tabella non è in 3NF in quanto la città non dipende direttamente dal nome del cliente; se conosco il codice postale, posso ottenere il nome della città da questo. Quindi la città dipende dal codice postale (dipendenza transitiva).

Figura 19: Esempio parte 5.

Una volta che abbiamo separato la città e il codice postale in una nuova tabella (figura 19), la tabella dell’esempio è in terza forma normale.

Un DWH NON è:

• Normalizzato: non serve normalizzare i dati ed è inefficiente nelle ricerche • Aggiornato on-line: sono i sistemi informativi operativi che sono mantenuti in

on-line. Il DWH viene aggiornato con procedure di allineamento a tempo (mensili, settimanali, giornaliere) attingendo i dati dalle diverse sorgenti.