MODELLAZIONE STRATEGICA DEI REQUISITI INFORMATIVI

Transcript

1 UNIVERSITA DEGLI STUDI DI PAVIA Facoltà di INGEGNERIA Corso di Laurea Specialistica in Ingegneria dei Servizi Digitali MODELLAZIONE STRATEGICA DEI REQUISITI INFORMATIVI Veronica BERGAMASCHI Anno Accademico

2 SOMMARIO PREFAZIONE 4 STRUTTURA DEL TESTO 5 A CHI È RIVOLTO 5 PARTE PRIMA 6 CAPITOLO 1. STAKEHOLDER E SCENARI 7 CAPITOLO 2. DEFINIZIONE DI REQUISITO DAI REQUISITI DI BUSINESS AI REQUISITI INFORMATIVI REQUISITI: LIVELLI DI DETTAGLIO 14 PARTE SECONDA 17 CAPITOLO 3. METODI ORIENTATI AI PROCESSI METODO BSP INFORMATION ENGINEERING (IE) MODELLI NORMATIVI ENHANCED TELECOM OPERATION MAP (ETOM) SUPPLY-CHAIN OPERATION REFERENCE MODEL (SCOR) 25 CAPITOLO 4. MODELLO ABE MODELLO MODELLO DEI DATI DESCRIZIONE DEL MODELLO STEP 1: PREPARAZIONE / LANCIO DEL PROGETTO STEP 2: SPECIALIZZAZIONE DELLA GRIGLIA STEP 3: VALUTAZIONE DEL SUPPORTO INFORMATIVO STEP 3.1: GRIGLIA INFORMAZIONI / BASI DI DATI STEP 3.2: GRIGLIA INFORMAZIONI / APPLICAZIONI STEP 3.3: GRIGLIA INFORMAZIONI / STRUTTURE STEP 3.4: GRIGLIA INFORMAZIONI / LIVELLI ELABORAZIONE STEP 4: ANALISI SENITIVITÀ STEP 4.1: DISCONTINUITÀ DI BUSINESS STEP 4.2: DISCONTINUITÀ TECNOLOGICHE STEP 4.3: INFORMAZIONI SENSIBILI 47 CAPITOLO 5. METODO ABE APPLICATO AD UN CASO REALE IL CASO RADIOLOGIA BREVE INTRODUZIONE ALLA STRUTTURA ORGANIZZATIVA E AI PROCESSI APPLICAZIONE DEL METODO: STEPS 52 APPENDICE 102 CASI D USO E SCENARI 112 ALLEGATO: CASO RADIOLOGIA 115 BIBLIOGRAFIA 134 2

3 INDICE DELLE FIGURE Figura 1 - Fasi di progetto di un SI 4 Figura 2 - Mappa degli Stakeholder 8 Figura 3 - Esempio Assembly Line e notazione 12 Figura 4 - Stakeholder dei diversi tipi di requisiti Rielaborazione personale da (Sommerville) 15 Figura 5 - Processi dell analisi dei requisiti 16 Figura 6 - Matrice priorità dei requisiti 16 Figura 7 - Stategie di analisi 17 Figura 8 - Passi del metodo BPS (Motta,1993) 19 Figura 9 - Esempio di una griglia dei processi e delle informazioni 19 Figura 10 - Information Engineering 20 Figura 11 - etom, processi orizzontali (da [10]) 23 Figura 12 - etom, processi verticali (da [10]) 24 Figura 13 - etom, modello completo (da [10]) 25 Figura 14 - SCOR: livelli di dettaglio (da [11]) 26 Figura 15 - Process Types 27 Figura 16 - Suddivisione dei Process Type (da [11]) 29 Figura 17 - Modello dei dati 31 Figura 18 - Griglia standard 33 Figura 19 - Scelta dominio e assegnazione livello 35 Figura 20 Definizione proprità 35 Figura 21 - Incrocio Domini e Livelli 35 Figura 22 - Esempio Griglia condivisa 36 Figura 23 - Griglia specializzata 38 Figura 24 - Dominio cliente, esempio di griglia specializzata 38 Figura 25 - Griglia di valutazione 39 Figura 26 - Griglia applicazioni (CRUD) 40 Figura 27 - Griglia informazioni/struttura 42 Figura 28 - Griglia informazioni/livelli elaborazione 43 Figura 29 - Analisi senitività: discontinuità business 45 Figura 30 - Analisi senitività: discontinuità business 46 Figura 31 - Analisi senitività: impatto delle normative 47 Figura 32 - Organigramma Azienda 49 Figura 33 Mappatura dei processi 51 Figura 35 - Griglia standard (domini raggruppati nelle macroclassi) 52 Figura 36 - Griglia condivisa finale. La griglia coincide con la griglia standard. 52 Figura 37 - Caso "Radiologia" - Passo2. Griglia specializzata 55 Figura 38- Caso "Radiologia" - Griglia Completa 57 Figura 39 - Grafico copertura basi di dati 63 Figura 40 - Grafico della copertura dei dati dalle applicazioni 74 Figura 41 - Macrostruttura aziendale 75 Figura 42 - Grafico supporto alle strutture 80 Figura 43 - Esempio di classificazione [Abstraction 1] 102 Figura 44 - Classficazione multipla : esempio [Abstraction 2] 102 Figura 45 - Classificazione multipla: un altro esempio 103 Figura 46 - Gerarchia di aggregazione: esempio 103 Figura 47 - Gerarchia d aggregazione: l'albero dei dati e dei processi di un sistema informativo aziendale 104 Figura 48 - Generalizzazione: esempio 105 Figura 49 - Gerarchia di generalizzazione di "cliente" [GENERAL 2] 106 Figura 50 - Gerarchia di generalizzazione di "richiesta" [GENERAL 3] 107 Figura 51 - Gerarchia di aggregazione dei processi di un sistema: esempio 108 Figura 52 - Generalizzazione dei processi di un sistema: esempio 109 Figura 53 - Gerarchia di aggregazione: esempio di dati relativi a generici ordini 110 Figura 54 - Gerarchia di generalizzazione : esempio 111 Figura 55 - Esempio di Use Case caso bibliotecario 113 3

4 Premessa Dal nostro punto di vista un sistema informativo è una applicazione software in cui una collezione di elaborazioni informatiche implementano transazioni che leggono, scrivono o modificano una o più basi di dati condivise completamente o parzialmente. Le tecnologie informatiche spportani l informatizzazione del sistema informativo aziendale: 1. Informatizzando processi e transazioni gestionali e trasformandoli in elaborazioni 2. Informatizzando i dati aziendali e strutturandoli in basi dati su elaboratore La trasformazione di un processo manuale in un processo informatico o di un processo informatico preesistente in un processo informatico nuovo avviene tipicamente attraverso un ciclo schematizzato qui sotto, dove molto importante è lo studio iniziale, etto STUIDIO DI FATTIBILITA, che è esattamente il tema di questo lavoro. Studio di fattibilità Raccolta e analisi dei Progettazione Implementazione Validazione e Funzionamento Figura 1 - Fasi di progetto di un SI Obiettivo fondamentale dello studio di fattibilità è fornire gli elementi necessari alla decisione di realizzazione di un progetto. Per raggiungere tale obiettivo, è necessario elaborare un primo livello di descrizione, ovvero un progetto di massima. L input dello studio di fattibilità sono I requisiti preliminari, che includono una descrizione generale del sistema e del suo supporto ai processi aziendali, mentre il risultato dovrebbe essere un rapporto che indichi convenga iniziare la realizzazione. 4

5 Questo lavoro, dopo una analisi iniziale dei concetti e delle definizioni di requisito e requisito informativo propone un manuale per la modellazione dei requisii delle basi dati, che utilizza il concetto di ABE (Aggregated Business Entities) e lo esemplifica su un caso (vedi allegato). Struttura del Testo Il testo è organizzato in parti, ciascuna contenente più capitoli: Parte 1: si introducono le nozioni fondamentali relative ai requisiti informativi. Parte 2: presenta una rassegna di alcuni metodi esistenti per la modellazione dei requisiti Parte 3: presentazione del metodo Aggregated Business Entities (ABE) con relativo esempio applicativo e mockup. A chi è rivolto La guida alla modellazione dei requisiti può essere utilizzata sia come strumento didattico sia come strumento effettivo. Un sito web xxx.unipv.it offrirà un manuale on-line. 5

6 PARTE PRIMA Requisiti Prima di iniziare lo sviluppo di un progetto di sistema informativo il management di un azienda deve definire perimetro ed obiettivi del progetto. Perimetro ed obiettivi rispetto al business aziendale sono definiti definendo i dati e le funzionalità dei sistemi. La definizione dei dati e delle funzionalità è strategica in quanto: 1. Considera aspetti rilevanti per il business 2. Prescinde dalle tecnologie adottabili, che sono valutate in altra sede strategica 3. Si concentra sulle funzionalità offerte, ovvero sul supporto ai processi di business 4. Analizza e definisce le classi di informazioni del sistema, determinando quindi il livello di controllo dell azienda sul suo ambiente. Oggetto specifico di questo manuale è la definizione dei requisiti strategici relativi alle informazioni. Tali requisiti sono descritti mediante Aggregated Business Entities (ABE), cioè macro entità informative che rispecchiano esigenze aziendali e prescindono completamente dalle esigenze e dai vincoli tecnologici. In questa sezione, i Capitoli 1 e 2 descrivono la mappa degli stakeholder del sistema e il concetto di requisito informativo. 6

7 Capitolo 1. Stakeholder e scenari La prima attività importante dell analisi dei requisiti è l identificazione degli stakeholder. Il termine Stakeholder ha una lunga storia. Edward Freeman ( Strategic Management, 1984) definisce gli stakeholder come Those groups without whose support the organization would cease to exist. Secondo questa teoria, il processo di una generica azienda deve soddisfare soglie critiche di costo, servizio e qualità che sono diverse e specifiche per ogni stakeholder. Al di sotto di una prestazione minima, il cliente cambia fornitore, e manager e operatori si licenziano, e i processi materialmente non possono continuare. Igor Ansoff in Corporate Strategy (1965) afferma che Stakeholder is the subject who takes a modifying and constraining influence on the former. Ancora più incisiva la definizione di Eric Rhenman, in Industrial Democracy and Industrial Management, Tavinstok Institute, London, We shall be using the term stakeholders to designate the individuals or groups which depend on the company for the realization of their personals goals and on whom the company is dependent. In that sense employees, owners, customers, suppliers, creditors as well as many other groups can all be regarded as stakeholders in the company. Da parte nostra identifichiamo in un processo gestionale stakeholder fondamentali: Clienti, richiedono e ricevono l output del processo; Manager, che controllano il processo e pianificano gli obiettivi aziendali; Operatori, che lavorano nel processo. Alcuni stakeholder sono facilmente individuabili (committente del progetto), mentre altri possono essere identificati in un secondo momento (p.e. esperti del settore in cui si sta operando). Occorre che l analisi copra l intera mappa degli stakeholder in modo da individuare tutti gli attori coinvolti nel progetto. 7

8 Figura 2 - Mappa degli Stakeholder 8

9 La Figura 2 posiziona le classi di stakeholder lungo il ciclo vitale del sistema. Gli stakeholder sono classificati a seconda del loro ruolo. Gli utenti includono chi usa il sistema. La classe degli utenti opera nella progettazione con il ruolo di Key User, cui sono affidate le maggiori responsabilità progettuali, e continua in fase di esercizio con gli utenti operativi e con gli utenti gestori, ovvero utenti che mantengono e modificano le funzioni del sistema, o in prima persona o attraverso esperti IT. Agli utenti si affianca la figura del committente, che autorizza e decide le sorti del progetto. Spesso le esigenze degli stakeholder sono difficili da fare emergere e non corrispondono a ciò che si esplicita in un intervista: Si originano così requirements bugs (requisiti errati) che portano al fallimento del progetto (S.Diev, 2007). Per comprendere le esigenze di uno stakeholder, un analista deve essere in grado, non solo di rilevare gli obiettivi ma anche di fare emergere la vision ed il loro di vista sul sistema da realizzare. Questo è critico perché la vision non solo descrive il dominio in cui operano gli stakeholder ma anche come lo stakeholder vi si muove. 9

10 Capitolo 2. Definizione di Requisito Con il termine requisito si intende esprimere un esigenza. I requisiti sono il punto di partenza per la progettazione in quanto contengono gli elementi necessari per progettare il sistema. I requisiti non costituiscono il progetto (design) ma raccomandazioni utili ai progettisti. (Bolchini, Mainetti, 2006). In engineering, a requirement is a singular documented need of what a particular product or service should be or do. It is most commonly used in a formal sense in systems engineering or software engineering. It is a statement that identifies a necessary attribute, capability, characteristic, or quality of a system in order for it to have value and utility to a user. (Wikipedia) Requisitoè sinonimo di esigenza, ed esprime qualcosa che si vorrebbe ottenere. Si indicheranno come Requisito Informativo, ovvero bisogno informativo, le informazioni che si vogliono ottenere prescindendo dalla tecnologia. La definizione dei requisiti avviene attraverso diversi stadi di definizione e affinamento (refinement) che vanno sotto il nome RCA, Requirements, Collection and Analysis. Per Collection si intende la raccolta dei requisiti. Essa può avvenire in vari modi (a) tramite interviste, (b) attraverso documentazione, come moduli, regolamenti interni, procedure aziendali (c) attraverso un processo di Reverse Engineering, ovvero da applicazioni esistenti, (d) attraverso osservazione diretta dei processi aziendali, per esempio, rilevazione mediante appunti, cronometrazione delle attività, misurazione dei volumi di lavoro ecc. Il termine analisi ha un duplice significato. Da una parte indica scomposizione, in opposizione a sintesi. Dall altra indica un arricchimento della conoscenza attraverso un esame dettagliato. Per precisare il significato del termine analisi ricordiamo il metodo della divisione di Aristotele. In esso, per definire un concetto è necessario inscrivere tale concetto in un insieme più esteso e suddividere quest ultimo mediante una serie di caratteristiche, fino ad ottenere un insieme che abbia la stessa estensione dell'oggetto da definire. Ad esempio, 10

11 volendo definire "uomo", si potrà partire dal concetto di "vivente" e suddividere i "viventi", in "animali" e "vegetali"; avendo poi riconosciuto che l'uomo è un animale, si procede a dividere gli animali in "volatili", "acquatici", "terrestri"; dunque, dopo aver diviso gli "animali terrestri" in "quadrupedi" e "bipedi", e avere riconosciuto che l'insieme indicato da quest ultima partizione include l'insieme degli uomini, si asserisce che la definizione di uomo è "animale terrestre bipede". L'applicazione di questo procedimento porta alla formazione di gerarchie di concetti. Anche la analisi dei requisiti implica la scomposizione secondo un criterio e definisce gerarchie di requisiti su un dominio di elementi. L analisi dei requisiti procede per livelli successivi di astrazione. Astrarre significa trascurare caratteristiche irrilevanti. La astrazione si ottiene con procedimenti attraverso cui si definiscono classi di oggetti (classificazione, identificazione) e si associano classi di oggetti (aggregazione, generalizzazione). L Appendice riporta un capitolo di approfondimento su aggregazione, classificazione e generalizzazione. 11

12 2.1 Dai Requisiti di Business ai Requisiti Informativi Il capitolo ha lo scopo di spiegare quali sono i passi che permettono di ricavare i requisiti informativi dai requisiti di business (obiettivi aziendali). Il passaggio dall analisi di business all analisi alla mappatura dei requisiti informativi avviene attraverso l individuazione degli elementi informativi candidati a far parte della descrizione del sistema IT (es. basi di dati,...). Successivamente si andrà a descrivere come le attività del processo di business utilizzano gli elementi informativi candidati e se ne derivano i casi d uso che descrivono i requisiti del sistema informativo dal punto di vista dell utente. Figura 3 - Esempio Assembly Line e notazione Il diagramma delle Assembly Lines consente di modellare il processo di mappatura che fa discendere il diagramma dei casi d uso a partire dall analisi di business. La parte superiore dell Assembly Line contiene la porzione del modello di business considerata, mentre la parte inferiore contiene le linee di assemblaggio, che contengono gli elementi informativi candidati alla selezione. La parte intermedia mappa in scrittura o in lettura alcune delle attività di business sugli elementi informativi: la scelta delle scritture o letture nella parte intermedia individua i casi d uso relativi ai requisiti informativi del sistema informativo di supporto al processo individuato. 12

13 Le entità candidate rappresentano strutture dati o unità informative la cui presenza si individua come significativa o probabile all interno del sistema IT di supporto. Le entità sono dette candidate perché solo una successiva analisi più dettagliata dei requisiti determina se esse sopravviveranno, evolveranno, o andranno ad inglobarsi con altre entità. Le assembly Lines indicano graficamente i rapporti tra attività ed entità IT mediante relazioni dirette di lettura e di scrittura. Le Assembly Lines non sono uno standard UML, ma sono un utile meccanismo per individuare entità candidate e casi d uso candidati. Entità e casi candidati formano insieme alle GUI i requisiti IT. ASSEMBLY LINES: METODO o Individuare le entità candidate Iniziare dalla prima attività Individuare le informazioni anagrafiche lette o scritte (p.e. cliente, prodotto ecc.) Riportare le informazioni come entità candidate Individuare le informazioni dinamiche lette o scritte (p.e. ordini cliente, conferme ordine) Riportare le informazioni come entità candidate Continuare con le altre attività o Per ogni attività individuare i casi d uso candidati (uno o più) o Rivedere e rifinire le entità candidate e i casi d uso candidati Le AL sono un approccio semiformale per identificare i requisiti IT corrispondenti a un dato schema di processo modellato con Activity Diagram Per individuare i requisiti IT (= Casi d uso, GUI, Classi di dati) possono essere usati anche altri metodi come ad esempio l analisi della documentazione IT, organizzativa, moduli, rapporti, studio delle funzionalità ERP utilizzate, prototipi software marcianti (metodi RAD e simili) e Mock-up. 13

14 2.2 Requisiti: livelli di dettaglio Requisito è una categoria concettuale molto ampia. Può indicare una descrizione di alto livello in linguaggio naturale di un servizio od una specifica matematica. Inoltre i requisiti possono essere usati sia come base per il contratto tra appaltatore ed appaltario sia come specifica contrattuale. Un esempio suggerito da Gordon Davis (1993) è il seguente: Se una azienda vuole concedere un appalto per un grande progetto di sviluppo software deve definire i suoi bisogni in modo sufficientemente astratto affinchè la soluzione non sia predefinita. I requisiti devono essere scritti in modo tale che diversi contraenti possano fare offerte per il contratto, proponendo anche diversi modi di soddisfare le necessità dell azienda del cliente. Una volta che l appalto è stato assegnato, i contraenti devono scrivere per il cliente una definizione del sistema più dettagliata, per lui comprensibile, in modo tale che egli possa verificare le potenzialità dello stesso. Entrambi i documenti possono essere chiamati documento dei requisiti per il sistema. I requisiti possono essere espressi a diversi livelli di dettaglio: 1. Requisiti funzionali: descrivono i requisiti in modo comprensibile all utente, che può non avere una dettagliata conoscenza tecnica. Si usano il linguaggio naturale, tabelle e diagrammi. Sono usati a livello manageriale. 2. Requisiti di sistema: definiscono in modo dettagliato le funzioni, i servizi e i vincoli operativi del sistema. Il documento dovrebbe essere strutturato in modo dettagliato come parte del contratto tra cliente e sviluppatore. Può essere specificato usando modelli formali di sistema. La definizione dei diversi livelli di dettaglio rispecchia la diversità degli stakeholder coinvolti nel processo. La Figura 3 mostra i diversi stakeholder coinvolti nella lettura dei requisiti utente e di sistema. 14

15 QuickTime e un decompressore TIFF (LZW) sono necessari per visualizzare quest'immagine. Figura 4 - Stakeholder dei diversi tipi di requisiti Rielaborazione personale da (Sommerville) Formulando i requisiti, il committente esprime una serie di vincoli, chiarificando il modo in cui gli obiettivi dovranno essere soddisfatti dal sistema. A sua volta il progettista, dopo avere analizzato i requisiti, può formulare una o più ipotesi di soluzione, tra loro diverse per caratteristiche, costi e tempi di realizzazione, ma comunque in grado di rispondere ai requisiti espressi. Tra le soluzioni proposte, il committente sceglierà quella migliore in termini di rapporto tra costi e benefici, e stipulerà un contratto con i progettisti affinché la realizzino. In generale, la gestione dei requisiti richiede attività correlate : 1. Elicitazione: consiste nel far emergere, negoziare e raccogliere i requisiti degli stakeholder del sistema; 2. Analisi: consiste non solo nello strutturare i requisiti raccolti, ma anche nel decidere quali requisiti soddisfare, nell'assegnare loro una priorità e nel definire la strategia generale che ne permetta il soddisfacimento; 3. Specifica: consiste nel documentare in modo appropriato i requisiti che dovranno essere comunicati agli stakeholder e ai progettisti; 4. Validazione: gli obiettivi principali di tale attività sono, da una parte, concordare i requisiti con gli stakeholder (eventualmente rinegoziandoli) e, dall'altra, valutarne la qualità. 15

16 QuickTime e un decompressore TIFF (LZW) sono necessari per visualizzare quest'immagine. Figura 5 - Processi dell analisi dei requisiti Non tutti i requisiti hanno la stessa importanza ed alcuni requisiti contribuiscono maggiormente alla soddisfazione degli stakeholder. L assegnazione delle priorità è essenziale per risolvere i conflitti che si possono creare quando sono presenti diversi stakeholder. La priorità di un requisito è i generale correlata al ritorno economico del sistema. Un requisito con alta priorità dà conseguentemente un alto ritorno economico. Si può rappresentare questa relazione con una matrice, come avviene in Figura 5. Un requisito ad alto ritorno economico e alta priorità è detto requisito in scope. L ultimo passo dell analisi è la documentazione. I requisiti vengono documentati in modo da potere essere utilizzati per attività successive. I requisiti possono essere documentati con tabelle o schede, che ne semplificano comprensione e gestione. QuickTime e un decompressore TIFF (LZW) sono necessari per visualizzare quest'immagine. Figura 6 - Matrice priorità dei requisiti 16

17 PARTE SECONDA Metodi di Analisi Descrivere i requisiti informativi significa associare ad una classe di utenti (chi utilizza le informazioni) le informazioni che quella classe usa. QuickTime e un decompressore TIFF (LZW) sono necessari per visualizzare quest'immagine. Figura 7 - Stategie di analisi Un primo approccio di analisi è data-oriented. Esso specifica le informazioni rilevanti e le associa a classi di utenti, eventi e processi che ne fanno uso. Nell approccio processoriented vengono definiti i processi aziendali e le classi utilizzate. Questo approccio definisce i requisiti informativi di tutta l organizzazione, poiché un orientamento per processi fornisce una visione globale dell azienda eliminando i tempi morti delle attività ed è orientata allo sviluppo dell interazione diretta con i clienti. I metodi goal-oriented (Davide Bolchini, 2003) si basano sui goal di un sistema di gestione. Un approccio orientato ai goal mette in relazione i requisiti con gli obiettivi che essi soddisfano e con il contesto dell azienda e di business, tiene traccia delle decisioni di design ed è utile nella gestione dei cambiamenti. 17

18 I Capitoli 3 e 4 descrivono i modelli e le tecniche che possono essere utilizzate durante il processo di definizione dei requisiti. Capitolo 3. Metodi orientati ai processi Per processo si intende business process, ovvero una sequenza di attività svolte da una o più unità organizzative finalizzata a produrre un output secondo regole predefinite. Obiettivo dei metodi è individuare i business process ad un livello di granularità ragionevole dal punto di vista strategico (devono essere alcune decine). Scopo dell analisi strategica è individuare i processi aziendali e definire il livello di supporto IT di tali processi. 3.1 Metodo BSP Messo a punto dalla IBM fra il 1966 e il 1970, il Business Systems Planning (BSP) della IBM può essere considerato il capofila delle metodologie process-oriented. Il metodo formalizza le matrici a doppia entrate utilizzate nella fase di definizione dei requisiti. Combina specifici elementi con componenti base come ad esempio interviste, analisi del lavoro e questionari (R.Winter, B.Strauch, 2004). La procedura BSP consta di 14 passi che possono essere raggruppati in: azioni preliminari, che preparano l esecuzione dello studio; attività di analisi che formalizzano i requisiti informativi di impresa; definizione dell architettura dei sistemi, delle azioni necessarie per realizzarla e delle relative priorità; azioni conclusive, che formalizzano le conclusioni dello studio. 18

19 Figura 8 - Passi del metodo BPS (Motta,1993) Il BSP individua i requisiti informativi di un azienda a partire da una mappa dei processi individuata a monte. Il passo fondamentale consiste nell associare, alla lista dei processi che sono stati individuati, le informazioni che i processi elaborano. L associazione è descritta da una tabella a doppia entrata, dove le colonne elencano i processi e le righe le informazioni. La lista delle informazioni è acquisita, come detto in precedenza, con interviste agli utenti o l esame di documenti aziendali. PROCESSI INFORMAZIONI Info1 Info2 Info3 Info4 PR1 R C D U PR2 - D R - PR3 R U C U Figura 9 - Esempio di una griglia dei processi e delle informazioni La figura 8 è un esempio semplificato di griglia delle informazioni e dei processi. Viene usata una notazione dettagliata che indica il tipo di operazione del processo sull informazione, cioè C (creazione), U (aggiornamento), R (lettura) e D (cancellazione). Leggendo la tabella in verticale il progettista individua in quale processo aziendale è utilizzata una data informazione; leggendo la tabella in orizzontale il progettista individua invece quali informazioni sono usate in un dato processo. Con l analisi tabellare il management ha una descrizione completa e strutturata dei requisiti informativi generali, espressa in linguaggio gestionale. 19

20 3.2 Information Engineering (IE) Messa a punto nella seconda metà degli anni Ottanta, la Information Engineering (IE) è infatti una metodologia che assiste l'intero ciclo di pianificazione, analisi, progettazione e realizzazione. Le due fasi principali, Information Strategy Planning (ISP) e Business Area Analysis (BAA) sono dedicate alla pianificazione ed alla analisi preliminare. La fase ISP definisce un quadro sintetico della azienda ed analizza le possibili opzioni strategiche relativamente alle tecnologie della informazione. La fase BAA approfondisce in modo sistematico i requisiti di una singola area aziendale, per esempio la Produzione, le Vendite etc. La metodologia IE è basata su sistemi CASE (Computer Assisted Software Engineering), e questo la distingue per esempio dal BSP, che è invece manuale. Il sistema CASE assiste la costruzione degli schemi di dati e processi e,inoltre, memorizza su di una banca dati tutta una serie di informazioni sugli elementi aziendali analizzati in sede di ISP e BAA, quale le unità organizzative, traguardi e problemi aziendali, fattori aziendali di successo, evoluzioni tecnologiche etc. In questo modo il sistema assiste la costruzione delle matrici (che sono a loro volta memorizzate come registrazioni) dei dati e dei processi, delle unità organizzative e dei processi etc. Si costituisce così una banca dati di specifiche, che nel linguaggio IE sono chiamati "metadati", in quanto si tratta di "dati su dati". QuickTime e un decompressore TIFF (LZW) sono necessari per visualizzare quest'immagine. Figura 10 - Information Engineering 20

21 Il passo iniziale della fase di Information Strategic Planning (ISP) è la costruzione di uno schema sintetico della impresa (overview model of the enterprise) che descrive e correla, mediante delle matrici analoghe a quelle del BSP: 1) le unità organizzative della impresa (organizational units); 2) i processi (functions) cioè le classi di attività svolte dalla Impresa; 3) le località (locations) dove ha sede la impresa; 4) le classi di dati (entity type) utilizzate nei processi La Business Area Analysis (BAA) produce una specifica ad alto livello dei requisiti informativi di una o più aree della azienda. La specifica si basa sulla modellazione dei dati e dei processi e sulle consuete matrici che incrociano processi e dati. I dati sono specificati utilizzando un modello di tipo Entità - Relazione e applicando delle tecniche di normalizzazione. Si ottiene così una rappresentazione di livello concettuale della base dati delle aree analizzate. I processi sono specificati mediante due tipi di modelli complementari. Il modello gerarchico (process decomposition diagram) produce schemi appunto gerarchici, che incorpora le primitive canoniche di aggregazione e generalizzazione. I processi possono essere scomposti sino ad individuare dei processi di livello elementare. Il modello a flusso (process dependency program) illustra la sequenza fra i vari processi che sono individuati dagli schemi gerarchici. Attraverso le matrici la metodologia IE fornisce una visione completa e ad alto livello dei requisiti informativi, tuttavia, è una metodologia piuttosto complessa. 3.3 Modelli normativi Rientrano nei metodi process-oriented, i modelli normativi che rispecchiano una architettura di processi ottimale. I modelli normativi sono usati dai Business Process Reference Model (BPRM) per la modellazione delle informazioni. Secondo [9], una volta descritti i processi coinvolti con le relazioni tra essi e le best practice per il raggiungimento di prestazioni ottime, questi possono essere implementati per ottenere un vantaggio competitivo, descritti in modo non ambiguo e comunicativo, 21

22 misurati, gestiti e controllati e infine raffinati ulteriormente per uno specifico obiettivo Enhanced Telecom Operation Map (etom) In ambito TeleManagement Forum (TMF) venne avviata, fin dai primi anni '90, un'attività di analisi per la definizione di un modello processivo di riferimento per i processi gestionali di un Operatore. L'allora Gruppo di Lavoro che affrontò questa attività era chiamato SMART (Service Management Automation and Re-engineering Team), che produsse intorno alla metà degli anni '90 il "Business Process Model", evoluto successivamente nel "Service Management Business Process Model" e, nell'ottobre 1998, confluito nel "Telecom Operations Map" (TOM). Il framework TOM è un modello processivo di riferimento di alto livello che definisce i processi di gestione ed esercizio in un moderno Gestore di telecomunicazioni. Questo modello è stato costruito allo scopo di facilitare ed abilitare una visione quanto più possibile condivisa sui processi gestionali; di particolare importanza nel modello TOM è la definizione ed introduzione di una terminologia comune, che facilita relazioni e negoziazioni dei gestori con clienti, fornitori, o altri gestori. TOM si è rapidamente diffuso come standard "de facto" per i processi gestionali di un Gestore di telecomunicazioni. Nel 2000 si espande il framework TOM verso l'attuale etom (Enhanced Telecom Operations Map). Il framework etom è un modello processivo che descrive tutti i processi di un gestore di telecomunicazioni e analizzandoli a differenti livelli di dettaglio in relazione alla loro priorità per il business. Elemento di forza del framework etom è il fatto che rappresenta una componente fondamentale del programma NGOSS (Next Generation Operations Systems and Software) del TMF, fornendo il driver per la specifica e lo sviluppo di sistemi di gestione realmente orientati all'automatizzazione ed ottimizzazione dei processi aziendali. etom è strutturato su differenti livelli di dettaglio, organizza i processi di business secondo una struttura gerarchico-funzionale. I processi sono formalizzati con un nome, una descrizione, l'indicazione degli input/output ed altri elementi caratteristici. A livello concettuale, tutti i processi dell'impresa fanno riferimento ad una delle seguenti macroaree: 22

23 l'area "Operations", comprendente tutti i processi operativi per la gestione delle richieste del cliente, la gestione dei servizi, delle reti e delle relazioni con i Fornitori / Partner; l'area "Strategy, Infrastructure & Products", comprendente tutti i processi di definizione e sviluppo delle strategie aziendali, i processi di progettazione, realizzazione e installazione delle infrastrutture (reti, logistica a supporto, ecc.), ed i processi di concettualizzazione, prototipazione e sviluppo dei nuovi prodotti/servizi da offrire alla clientela; l'area "Enterprise Management", comprendente tutti i processi di supporto alla gestione dell'impresa (gestione finanziaria, gestione delle risorse umane, gestione della sicurezza, ecc.). Il framework è organizzato su due dimensioni: la dimensione orizzontale, nella quale i processi sono raggruppati a seconda delle funzionalità di riferimento espletate (es. la gestione del cliente o la gestione della rete); la vista per funzionalità è indipendente dai confini organizzativi all'interno dell'azienda (es. gestire le relazioni con il cliente comprende sia aspetti di marketing che di gestione degli ordinativi, che di fatturazione); Figura 11 - etom, processi orizzontali (da [10]) la dimensione verticale, nella quale i processi sono raggruppati a seconda di processi End-To-End (es. il Fulfillment, l'assurance o il Billing), sui quali l'azienda è misurata dal cliente o dalla concorrenza. 23

24 Figura 12 - etom, processi verticali (da [10]) Il modello completo di etom è rappresentato in figura 12: 24

25 Figura 13 - etom, modello completo (da [10]) Supply-Chain Operation Reference model (SCOR) Il Supply-Chain Operations Reference-model (SCOR) è un modello di riferimento sviluppato e sponsorizzato dal Supply-Chain Council 1 come lo strumento standard e cross-industry per la diagnostica del supply-chain management. Il modello SCOR, consente di: * costruire, tra i vari attori della supply-chain, una visione condivisa sulla creazione di valore all interno e all esterno dell impresa * definire gli obiettivi di business e misurarne coerentemente le prestazioni * attivare benchmark * configurare la supply-chain * analizzare e misurare i processi chiave della supply-chain 1 Il Supply Chain Council è un organizzazione no-profit indipendente che opera su scala mondiale a cui aderiscono imprese di tutti i settori industriali. Questo ha permesso di mettere a punto un modello standard cross-industry, riferimento nell ambito del Supply Chain Management. 25

26 * riprogettare la supply-chain nel rispetto degli obiettivi di business avendo come riferimento le best practice che confluiscono dinamicamente nel modello, con il contributo volontario dei membri del Council * promuovere visibilità, fiducia e collaborazione tra gli attori della supply-chain. Il modello SCOR definisce metrics, regole standard per la mappatura dei processi, best practice; si occupa delle interazioni con i clienti, dalla ricezione dell ordine alla fatturazione del pagamento, delle transizioni di prodotto fino alle interazioni col mercato. Lo SCOR è strutturato su tre livelli di dettaglio: Figura 14 - SCOR: livelli di dettaglio (da [11]) 26

27 1. TOP LEVEL: vengono definiti scope e contenuti del modello. I processi vengono suddivisi in cinque categorie. A questo livello le aziende definiscono i loro piani strategici, inoltre vengono fornite le basi per le la pianificazione degli obiettivi di performance. Plan Source Make Deliver Return Return Figura 15 - Process Types o Plan: La pianificazione si identifica con quell'insieme di processi atti al bilanciamento della domanda e dell'offerta al fine di definire una sequenza di azioni che consenta al meglio il soddisfacimento delle "regole di business" predefinite. In sostanza, con la pianificazione si cerca di predisporre l'offerta in base alla percezione che si ha della domanda dai dati a disposizione, in modo da raggiungere pienamente gli obiettivi prefissati; in un'ottica di gestione integrata, la pianificazione avviene a livello dell'intero processo al fine di poter massimizzare l'efficienza e al contempo diminuire i costi e più in particolare interviene: 1. Nelle valutazioni delle risorse e delle capacità del sistema non solo a breve ma anche e soprattutto a medio-lungo termine (valutazioni strategiche) della configurazione della supply chain; 27

28 2. Nelle valutazioni delle capacità di gestione del magazzino, dell' aggregazione e dell'ordinamento delle esigenze della domanda, nella valutazione dei canali di distribuzione, delle loro caratteristiche ed esigenze, nella valutazione delle componenti dell'area produzione; 3. Nella valutazione dei prodotti, della capacità di commercializzare e di gestire le fasi di entrata ed uscita del prodotto e del suo ciclo di vita; 4. Nelle decisioni di marketing, "make or buy", nelle decisioni logistiche, di produzione e distribuzione; 5. Nella gestione della struttura di pianificazione cosi creata. o Source: Con il termine "source" ci si riferisce ai processi concernenti l'approvvigionamento e la fornitura di beni e servizi necessari per il soddisfacimento della domanda e quindi degli obiettivi preposti. Le attività di cui generalmente si compone il processo di sono le seguenti: 1. Procurare; 2. Ricevere; 3. Mantenere; 4. Spedire. o Make : La fase del processo produttivo riassume in se tutte le operazioni che vanno dalla presa in consegna dei beni da lavorare provenienti dal magazzino (semilavorati e materie prime), fino al momento in cui i beni finiti vengono spediti al cliente o al distributore, oppure trasferiti in magazzino e stoccati per essere destinati in un secondo tempo al mercato. In questo intervallo le materie prime ed i semilavorati vengono trasformati fisicamente fino a costituire il prodotto finito. o Deliver: comprende tutte le attività relative alla distribuzione del prodotto finito: 1. Gestione dell ordine di vendita; 2. Gestione del magazzino in uscita; 3. Gestione logistica; 4. Gestione delle infrastrutture. o Return: comprende attività relative alla restituzione del prodotto (prodotti difettosi, eccedenze, prodotti in garanzia). 28

29 2. CONFIGURATION LEVEL: molte aziende iniziano a questo livello, in cui implementano le proprie strategie operative secondo la configurazione della loro supplì-chain. A questo livello i processi SCOR sono descritti dai process types descritti precedentemente, inoltre, vi è una ulteriore suddivisione del processo su tre livelli: o Planning: processo di allineamento tra risorse e domanda e domanda e fornitura migliorando il tempo di risposta della supply-chain. o Execution : processo di pianificazione e attuazione della domanda, che cambia lo stato dei beni materiali. Comprende lo scheduling dei materiali, la trasformazione dei prodotti e lo spostamento del prodotto allo stadio successivo. Contribuisce al miglioramento del ciclo di vita. o Enable: processo di preparazione, mantenimento e gestione delle informazioni e delle relazioni su cui si basano i processi di planning e execution. Figura 16 - Suddivisione dei Process Type (da [11]) 3. PROCESS ELEMENT LEVEL: vengono scomposti ad un maggior livello di dettaglio i processi del livello 2, specificando dettagliatamente input e output del processo e i process element. Vengono definite le metriche e le best practice applicate. 4. IMPLEMENTATION LEVEL: a questo livello le aziende implementano e gestiscono la specifica supply-chain. Il livello 4 definisce le pratiche per raggiungere vantaggi competitivi e per adattarsi ai cambiamenti di business. 29

30 PARTE TERZA Aggregated Business Entities Capitolo 4. Metodo ABE Fino ad ora sono stati analizzate delle metodologie consolidate, che si possono definire classiche per l analisi dei requisiti. Negli ultimi anni vi è stata l introduzione del metodo ABE (Aggregated Business Entities). Il metodo prevede una modellazione ad altissimo livello e fornisce una visione strategica di tutte le risorse informative, aiuta a capire dove sono collocate le informazioni e dove e quali sono le informazioni critiche, infine, è utile nella valutazione delle risorse informative per la definizione delle opportune strategie. 4.1 Modello ABE significa Entità Aggregate di Business, ma che cos è un entità? Un entità è un oggetto estrapolato dalla realtà con caratteristiche proprie rappresentate mediante attributi (P.P. Chen 1976). Il concetto di entità è molto ampio, e per esso non è definibile una granularità fissa ed invariante. Una entità può esser molto aggregata (p.e. Persona ) o molto disaggregata (p.e. Cliente-privato ). Nelle basi dati la granularità è generalmente troppo spinta per essere adatta all analisi strategica. È invece necessario portare il livello di generalizzazione al livello dell analisi strategica. L aggregazione è obiettivo precipuo del metodo ABE. Un secondo obiettivo è la definizione di meta-proprietà che permettano uno schema normativo di ABE specifico di ogni settore industriale (le ABE di una banca devono differire dalle ABE di una azienda industriale). Lo schema normativo generico delle ABE è dato da una griglia che incrocia due criteri di classificazione delle informazioni: livello di dettaglio e dominio. Il livello di volatilità riflette la variazione nel tempo delle informazioni. A seconda del grado di volatilità le informazioni possono essere distinte in Master Data, che descrivono le 30

31 proprietà strutturali degli oggetti su cui si opera, e Transaction Data che descrivono gli eventi. Un terzo tipo di informazioni, detto indici, comprende dati aggregati finalizzati all analisi e al controllo. Il dominio identifica a sua volta l universo del discorso cui si riferiscono le entità. In generale quindi, dato un dominio D i esisterà almeno una ABE di D i di tipo anagrafico e almeno una di tipo dinamico. 4.2 Modello dei dati Il meta-modello proposto vede le ABE in relazione con: Applicazioni: applicazioni intese come moduli, pacchetti e soluzioni software Strutture IT: tutto il patrimonio tecnologico Strutture Organizzative: la struttura aziendale, l organigramma Business Process: il processo aziendale, l argomento di studio dell analista. Figura 17 - Modello dei dati Relazione Applicazioni - ABE La relazione tra ABE ed Applicazioni ha lo scopo di valutare da un lato il fabbisogno informativo delle applicazioni, ovvero quali informazioni (di alto livello) sono necessarie affinché la applicazione possa svolgere correttamente le proprie funzionalità in particolare, la relazione fra Applicativi ed ABE è di tipo CRUD (ovvero Create, UpDate, Read e Delete) e permette di verificare oltre al fabbisogno informativo anche quali operazioni vengono effettuate sui dati, ovvero quale software elabora (ed in che modo) le informazioni. Relazione Strutture Organizzative ABE 31

32 La relazione permette di valutare la ownership del dato. Permette, cioè, di capire quali informazioni sono necessarie alle strutture organizzative per svolgere il lavoro in modo corretto e anche quali informazioni sono di competenza di una determinata struttura organizzativa. Relazione Business Process - ABE La relazione sta ad indicare che un business process necessita di sapere determinate informazioni. La novità proposta dal modello è l inserimento del processo aziendale in una struttura di processi. In questo modo, è possibile utilizzare per un processo figlio tutte le informazioni comuni al processo padre ed eventualmente eliminare o aggiungere ulteriori informazioni non comuni. Relazione ABE Strutture IT Lo scopo è quello di valutare la distribuzione delle informazioni sulle infrastrutture tecnologiche (server, client, DBserver ) e definire/mappare i relativi livelli di elaborazione. I livelli di elaborazione dei dati sono: Raccolta e acquisizione Archiviazione e conservazione Elaborazione, trasformazione e produzione Distribuzione, comunicazione e scambio Relazione Applicazioni Business Process Mette in relazione il portafoglio applicativo (ERP, CRM, BI ) con i processi e la relativa struttura. Scopo della relazione è quello di valutare il ruolo giocato dalle applicazioni sulla struttura dei processi e la loro copertura. Relazione Strutture Organizzative Business Process Si vogliono mettere in relazione le responsabilità delle varie strutture organizzative nel processo. Scopo della relazione è quello di mappare /valutare le responsabilità sul processo. Permette di capire se esistono responsabili di processo (process owner). Il tipo di relazione può essere classificato utilizzando, ad esempio, metriche LRC. 32

33 4.3 Descrizione del modello L analisi si pone come obiettivi principali l individuazione dei domini informativi con la descrizione delle ABE tipiche dell azienda, la valutazione del supporto informativo con lo scopo di confrontare la situazione normativa ed esistente e l analisi di sensitività, ovvero individuare quali domini sono impattati da discontinuità di business, discontinuità tecnologiche e informazioni sensibili Step 1: Preparazione / lancio del progetto OBIETTIVO: definire e condividere una griglia con cui classificare le informazioni di tipo aggregato indipendenti dalla realizzazione sul sistema informativo. INPUT: in input si ha la griglia standard, ottenuta incrociando domini e livelli base. Figura 18 - Griglia standard OUTPUT: il risultato del passo 1 è la griglia condivisa, che può essere la stessa griglia standard. ESECUZIONE DEL PASSO: l analista espone al gruppo di lavoro i criteri con cui vengono classificate le informazioni, si assicura di avere la possibilità di analizzare le informazioni nell azienda / ente oggetto dell analisi, individuando i possibili referenti. Di seguito viene descritta la logica di classificazione delle informazioni e illustrate le sequinze di esecuzione del passo. Inizialmente il progettista deve definire una griglia che incrocia due categorie logiche: VOLATILITA delle INFORMAZIONI, intesa come variazione nel tempo delle informazioni, a cui appartengono informazioni anagrafiche (Master Data), 33

34 informazioni dinamiche (Transaction Data) e indici (Analysis Data). DOMINIO, identifica l universo del discorso cui si riferiscono le entità statiche e dinamiche. La definizione della matrice domini e livelli è basata su modelli normativi di settore quali etom che fissano le best practice. Lo studio di tali modelli ha portato alla definizione dei seguenti domini base, che potranno essere successivamente specializzati in modo da caratterizzare l azienda presa in esame. I domini dell informazione sono riassunti nelle seguenti macroclassi: Stakeholder e attori del business o Norma o Concorrente o Cliente o Fornitore o Agente o Azionista Risorse del business o Personale o Impianto o Materie Prime o Denaro Contesto o Struttura o Progetto o Territorio Output o Processo o Prodotto o Servizio Le figure seguenti mostrano i passi per la definizione della griglia base. Per prima viene la scelta del dominio al quale sarà associata una ABE di tipo Master, Transaction o Indice (Figura 18) e alla quale corrisponderà una data proprietà (Figura 19). Dall incrocio di domini e livelli di informazione si individua una griglia base (Figura 20). 34

35 Figura 19 - Scelta dominio e assegnazione livello Figura 20 Definizione proprità Figura 21 - Incrocio Domini e Livelli 35

36 Il passo si conclude con la definizione di una griglia condivisa che può coincidere con la griglia standard. Figura 22 - Esempio Griglia condivisa 36

37 4.3.2 Step 2: Specializzazione della griglia OBIETTIVO: Definire la struttura applicabile all azienda, che si avvicini il più possibile ai modelli di riferimento. INPUT: in input si ha la griglia condivisa ottenuta come output del passo 1. OUTPUT: il risultato è una griglia di domini e livelli specializzati che caratterizzano l azienda. ESECUZIONE DEL PASSO: analizzando le fonti, a partire dalla griglia condivisa ottenuta al passo 1 l analista può effettuare operazioni di creazione, scomposizione e specializzazione dei livelli e dei domini di base. Creazione: individuazione di nuovi livelli o domini non derivabili da altri di base per scomposizione o specializzazione. Specializzazione/Ampliamento: vengono specificati sotto-tipi di un livello o di un dominio. Ad esempio il dominio cliente può essere specializzato in: Cliente Privato Cliente Aziendale e il livello transaction data in : Transazione uomo - macchina Transazione macchina macchina Scomposizione: domini e livelli informativi vengono scomposti in vari livelli. Ad esempio, il livello Master Data è scomposto in: Dati identificativi Dati descrittivi 37

38 Figura 23 - Griglia specializzata In figura 22 è riportato l esempio di una griglia specializzata. Vengono rappresentate in particolare le specializzazioni del domino cliente e dei livelli master e transaction. Per semplificare la lettura della griglia, si può pensare di rappresentare ogni dominio come tabelle personalizzate che hanno in input i domini stessi con le loro specializzazioni e scomposizioni e i livelli informativi anch essi specializzati e scomposti (figura 23). Figura 24 - Dominio cliente, esempio di griglia specializzata Il passo continua poi con la compilazione da parte dell analista della griglia specializzata con le informazioni (requisiti) necessarie all analisi. Ogni cella rappresenta una ABE. 38

39 4.3.3 Step 3: Valutazione del supporto informativo Con il passo 3 inizia la fase di valutazione dei dati raccolti dall analista costituita da una serie di sotto-passi volti a valutare criticamente il supporto informativo esistente Step 3.1: Griglia informazioni / Basi di Dati OBIETTIVO: Valutare in quale misura le informazioni sono coperte dalle basi di dati. INPUT: in input la griglia personalizzata ottenuta la passo 2. Sulle righe vengono elencate tutte le ABE dei livelli Master, Transaction e Indice, sulle colonne invece l elenco delle basi dati. Figura 25 - Griglia di valutazione OUTPUT: in output viene fornita una mappa di copertura. ESECUZIONE DEL PASSO: vengono illustrati gli strumenti notazionali che hanno lo scopo di supportare il lavoro dell analista nella documentazione della valutazione del supporto informativo in relazione con le ABE individuate. Si è scelto di valutare la copertura delle informazioni dalle basi di dati sulla base della completezza, esattezza ed aggiornamento. Si possono creare scale di valutazione personalizzate, assegnando dei nomi che le identifichino in modo chiaro. Le scale di valutazione sono definite tramite una lista di 39

40 parole che spaziano da una valutazione minima ad una massima. Le scale includono una descrizione del loro significato e suggerimenti su come potrebbero essere impiegate. Di seguito è riportato l esempio della scala di valutazione utilizzata per questo passo: Nulla: l informazione non è presente nelle basi dati Limitata: l informazione non è completamente presente nelle basi di dati Soddisfacente e perfettibile: l informazione è presente nelle basi di dati ma può essere migliorata Ottima: informazione completamente presente nelle basi dati E possibile attribuire a tali valori colori diversi a seconda della copertura in modo da rendere più immediata e semplice la lettura delle tabelle Step 3.2: Griglia informazioni / Applicazioni OBIETTIVO: Questa griglia ha lo scopo di valutare quali applicazioni usano quali informazioni. In ingresso si ha sempre la griglia delle informazioni personalizzata e l inventario delle applicazioni software presenti. INPUT: in input la griglia personalizzata ottenuta la passo 2. Sulle righe vengono elencate tutte le ABE dei livelli Master, Transaction e Indice, sulle colonne invece l inventario delle applicazioni software. Figura 26 - Griglia applicazioni (CRUD) 40

41 OUTPUT: in output viene fornita una macromappa di uso delle informazioni. ESECUZIONE DEL PASSO: In questo caso, vengono utilizzate metriche CRUD (Create, Read, Update, Delete) per l individuazione di mappe di uso delle informazioni. C: informazione creata R: informazione letta ma non modificata U: informazione esistente aggiornata D: informazione cancellata. La lettura in verticale indica quali informazioni sono usate da una certa applicazione, mentre la lettura in orizzontale indica eventuali anomalie nel ciclo di vita. La procedura di analisi di tabelle che utilizzano metriche CRUD, si esemplifica in sei passi: 1. Verifica delle precedenze. Un primo obiettivo è quello di individuare le anomalie di precedenza in sede di progetto. L ordinamento in tabella, infatti, rispecchia parzialmente l ordine di precedenza delle attività. Esaminando le colonne dall alto verso il basso, devono essere rispettate le seguenti condizioni: una C non può seguire una R o U (una registrazione deve esistere per essere letta o modificata); una D non può precedere una R o U (una registrazione non può essere letta o modificata se è già stata cancellata). 2. Verifica di chiusura. Individua le informazioni che non completano il loro ciclo vitale di creazione, modifica, lettura e cancellazione nell ambito delle funzioni di aggiornamento elencate nella tabella. Seppure sia normale che un sistema non gestisca tutto il ciclo vitale di tutti i suoi dati, certi casi possono essere dovuti ad una progettazione non corretta. 3. Importazione. Le informazioni sono consultate (R) o modificate (U), non vengono però create (C) dal sistema. Queste informazioni devono essere generate da altri sistemi. 4. Ridondanza. Le informazioni sono create (C) ma non consultate (R) né modificate (U). Le 5. informazioni ridondanti, quando non utilizzate effettivamente da altri sistemi, vanno eliminate poiché appesantiscono le elaborazioni. 6. Distruzione. Le informazioni sono cancellate (D) ma non create (C) né modificate 41

42 (U); è segno di errori o di analisi incomplete. Si può utilizzare la stessa griglia per valutare il supporto informativo alle applicazioni. In questo caso verrà utilizzata la scala qualitativa descritta al sotto-passo precedente, ottenendo in questo caso una mappa di copertura dati Step 3.3: Griglia informazioni / Strutture OBIETTIVO: Questa griglia ha lo scopo di valutare il supporto informativo alle strutture. INPUT: in input la griglia personalizzata ottenuta la passo 2. Sulle righe vengono elencate tutte le ABE dei livelli Master, Transaction e Indice, sulle colonne invece le componenti dell organigramma aziendale. Figura 27 - Griglia informazioni/struttura OUTPUT: in output viene fornita una mappa di copertura. ESECUZIONE DEL PASSO: L esecuzione del passo è del tutto anologa a quella vista nel passo 3.1: anche in questo caso la valutazione è espressa in termini di completezza, esattezza ed aggiornamento, utilizzando ancora una volta una scala qualitativa di colori. 42

43 Step 3.4: Griglia informazioni / Livelli Elaborazione OBIETTIVO: Questa griglia ha lo scopo di valutare la distribuzione delle informazioni. INPUT: in input la griglia personalizzata ottenuta la passo 2. Sulle righe vengono elencate tutte le ABE dei livelli Master, Transaction e Indice, sulle colonne invece l architettura di elaborazione personalizzata, come ad esempio, client fissi o dispiositivi mobili. Figura 28 - Griglia informazioni/livelli elaborazione OUTPUT: in output viene fornita una griglia in cui sono indicate le responsabilità di ciascun dispositivo. ESECUZIONE DEL PASSO: L esecuzione del passo prevede l utilizzo di metriche CRUD già precedentemente discusse. 43

44 4.3.4 Step 4: Analisi Senitività L analisi di sensitività ha lo scopo di individuare quali domini informativi sono impattati da azioni o variabili strategiche. Le ABE vengono rapportate con le discontinuità di business, tecnologiche e le informazioni sensibili. Di seguito verranno descritti i passi per la creazione delle griglie di valutazione per l analisi di sensitività. L analisi di sensitività può essere di supporto alla creazione del Business Continuity Plan (BCP), documento principale che contiene le attività, le azioni ed i piani relativi alla continuità operativa (business continuity) di un'azienda. L analisi di sensitività viene eseguita valutando l impatto delle informazioni su diversi fattori del business. In particolare vengono analizzati gli impatti sulle discontinuità causate dall IT, sugli obiettivi strategici e sulle normative Step 4.1: Discontinuità di Business OBIETTIVO: Questa griglia ha lo scopo di valutare l impatto delle ABE sulle scelte strategiche, ovvero valutare in quale misura le informazioni influiscono sugli obiettivi aziendali. INPUT: in input la griglia personalizzata ottenuta la passo 2. Sulle righe vengono elencate tutte le ABE dei livelli Master, Transaction e Indice, sulle colonne invece il piano strategico dell azienda. 44

45 Figura 29 - Analisi senitività: discontinuità business ESECUZIONE DEL PASSO: l analista analizza l impatto delle ABE sugli obiettivi aziendali utilizzando una scala di valutazione qualitativa con i seguenti valori: Nullo Limitato, ovvero la modifica o l estensione delle tabelle; Alto, ovvero comporta la modifica degli schemi; Globale, ovvero la riprogettazione totale degli schemi. Come già visto nei passi precedenti, anche in questo caso utilizzando una scala di valutazione qualitativa si sceglie di attribuire ad ogni valore un colore diverso. Questa considerazione varrà anche per i successi steps 4.2 e 4.3 che avranno input diversi ma stessa modalità di esecuzione del passo. 45

46 Step 4.2: Discontinuità Tecnologiche OBIETTIVO: Questa griglia ha lo scopo di valutare l impatto delle strategie tecnologiche sulle informazioni (per esempio come influisce l introduzione di una tecnologia SOA sulle informazioni raccolte). INPUT: in input la griglia personalizzata ottenuta la passo 2. Sulle righe vengono elencate tutte le ABE dei livelli Master, Transaction e Indice, sulle colonne invece il piano strategico tecnologico. Figura 30 - Analisi senitività: discontinuità business ESECUZIONE DEL PASSO: l analista analizza l impatto delle tecnologie utilizzando una scala di valutazione qualitativa con i seguenti valori: Nullo Limitato, ovvero la modifica o l estensione delle tabelle; Alto, ovvero comporta la modifica degli schemi; Globale, ovvero la riprogettazione totale degli schemi 46

47 Step 4.3: Informazioni sensibili OBIETTIVO: Questa griglia ha lo scopo di valutare l impatto delle normative sulle informazioni. INPUT: in input la griglia personalizzata ottenuta al passo 2. Sulle righe vengono elencate tutte le ABE dei livelli Master, Transaction e Indice, sulle colonne invece l elenco delle normative. Figura 31 - Analisi senitività: impatto delle normative ESECUZIONE DEL PASSO: l analista analizza l impatto normative utilizzando una scala di valutazione qualitativa con i seguenti valori: Nullo Limitato, ovvero la modifica o l estensione delle tabelle; Alto, ovvero comporta la modifica degli schemi; Globale, ovvero la riprogettazione totale degli schemi. 47

48 Di seguito si riporta una tabella riassuntiva degli steps, che serve per verificare che input e output corrispondano. STEP INPUT OUTPUT 1. Preparazione del GRIGLIA progetto STANDARD GRIGLIA CONDIVISA 2. Specializzazione griglia GRIGLIA CONDIVISA GRIGLIA SPECIALIZZATA 3. Valutazione supporto info 3.1 Informazioni / DB GRIGLIA SPECIALIZZATA 3.2 Informazioni / GRIGLIA Applicazioni SPECIALIZZATA INVENTARIO APPLICAZIONI 3.3 Informazioni / Strutture GRIGLIA SPECIALIZZATA ORGANIGRAMMA 3.4 Informazioni / Livelli Elaborazione GRIGLIA SPECIALIZZATA ARHITETTURA ELABORAZIONE PERSONALIZZATA 4. Analisi sensitività 4.1 Discontinuità Business ABE PIANO STRATEGICO AZIENDALE 4.2 Discontinuità Tecnologiche ABE PIANO STRATEGICO IT 4.3 Informazioni Sensibili ABE NORMATIVE 48

49 Capitolo 5. Metodo ABE applicato ad un caso reale 5.1 Il caso Radiologia In questa capitolo viene illustrato, passo per passo, il metodo delle ABE applicato ad il caso di studio Radiologia riportato in Allegato. Il progetto Radiologia si propone di rilevare e analizzare le principali criticità dei processi di business della struttura Diagnostica per Immagini di una ASL (di cui non è fornita alcuna generalità) per migliorarne l efficacia e l efficienza. In particolare il capitolo si soffermerà sulla raccolta e analisi dei requisiti informativi applicando il metodo delle ABE Breve introduzione alla struttura organizzativa e ai processi Il Dipartimento Immagini della azienda ospedaliera è stato costituito nel 1999 raggruppando strutture operative di varie diagnostiche. A capo di ogni struttura operativa vi è un dirigente medico di I livello. DIREZIONE GENERALE COORDINAMENTO STAFF Figura 32 - Organigramma Azienda 49

50 STRUTTURA DEI PROCESSI In figura viene riportata la struttura dei processi primari identificati all interno della struttura Diagnostica per Immagini esaminata. I processi coinvolti sono quelli evidenziati in verde. 50

51 Figura 33 Mappatura dei processi 51

52 5.2 Applicazione del metodo: steps 1. STEP 1 Il passo 1 è dedito alla definizione della griglia condivisa. Individuati i domini e i livelli base si è provveduto alla creazione vera e propria della griglia, prima individuando quella ottenuta dalle quattro macroclassi di domini con i livelli, poi quella finale con l esplosione delle macroclassi: dallo studio del caso se ne evince che la griglia condivisa coincide con la griglia standard. Figura 34 - Griglia standard (domini raggruppati nelle macroclassi) Figura 35 - Griglia condivisa finale. La griglia coincide con la griglia standard. 52

53 2. STEP 2 Il passo 2 ha lo scopo di definire una griglia specializzata che si avvicini il più possibile ai modelli normativi di riferimento ed associare ad ogni livello e dominio una proprietà (ABE). Analizzando il caso e facendo uno studio dello stato dell arte del contesto in cui si colloca il caso di studio, è stato possibile effettuare diverse specializzazioni. a. CLIENTE: il cliente di un servizio di un reparto di una struttura ospedaliera può essere suddiviso in: PAZIENTE: ovvero chi riceve il servizio offerto. Nel caso in esame, il paziente viene ulteriormente specializzato a seconda del tipo di rapporto che ha con la struttura: o Paziente Ricoverato o Paziente Ambulatoriale o Paziente di Pronto Soccorso COMMITTENTE: In generale, il committente è la figura disposta a sostenere i costi per il progetto, e che ha la responsabilità di valutare se il prodotto risultante è accettabile. E' il principale decisore del progetto, ed il suo ruolo deve essere noto ed accettato da tutte le parti interessate all'andamento ed agli esiti del progetto (gli "stakeholder"). b. PERSONALE: TECNICO: comprensivo di tutti i tecnici presenti nella struttura (tecnici radiologi, etc.) AMMINISTRATIVO: personale che svolge lavoro amministrativo/ segretariale e contabile (segretarie, centralinisti, contabili etc.) MEDICO: comprensivo di medici ed infermieri. c. MATERIE PRIME: FARMACI: tutto il portfolio farmacologico presente nella struttura, considerando anche i farmaci che risiedono nei depositi non interni 53

54 alla struttura stessa. Vengono considerati solo i farmaci somministrati durante la degenza del paziente, quindi sono esclusi i farmaci a carico del paziente (quelli prescritti dopo aver usufruito del servizio). DISPOSITIVI MEDICI: Qualsiasi strumento, apparecchio, impianto, sostanza o altro prodotto, utilizzato da solo o in combinazione (compreso il software informatico impiegato per il corretto funzionamento) e destinato dal fabbricante ad essere impiegato nell'uomo a scopo di diagnosi, prevenzione, controllo, terapia o attenuazione di una malattia; di diagnosi, controllo, terapia, attenuazione o compensazione di una ferita o di un handicap; di studio, sostituzione o modifica dell'anatomia o di un processo fisiologico; di intervento sul concepimento, il quale prodotto non eserciti l'azione principale, nel o sul corpo umano, cui è destinato, con mezzi farmacologici o immunologici né mediante processo metabolico ma la cui funzione possa essere coadiuvata da tali mezzi. BENI DI CONSUMO: tutto ciò che soddisfa un bisogno (cibo, abiti, attrezzatura per servizio alberghiero in generale, etc.). Sono state poi effettuate operazioni di scomposizione e specializzazione anche sui livelli delle informazioni, in particolare: d. MASTER DATA: Dati Identificativi Dati Descrittivi e. TRANSACTION DATA: : annotazione delle informazioni su appositi supporti (DB, supporto cartaceo) Certificazioni 54

55 Master Data Transaction Data Indice Dati Identificativi Dati Descrittivi Certificazioni Norma Concorrente STAKEHOLDER Cliente Agente Fornitore Azionista Committente Paziente Ricoverato Paziente Ambulatoriale Paziente P.S. RISORSE Personale Impianto Materie Prime Amministrativo Tecnico Medico Farmaci Dispositivi Medici Beni di Consumo Denaro CONTESTO Struttura Progetto Territorio OUTPUT Processo Prodotto Servizio Figura 36 - Caso "Radiologia" - Passo2. Griglia specializzata 55

56 Il passo prosegue con la compilazione della griglia. Ogni cella verrà riempita con le informazione raccolte con l analisi del caso (ABE). Di seguito è mostrata la griglia completa delle informazioni e verrà fatta una breve descrizione di esse. 56

57 Figura 37- Caso "Radiologia" - Griglia Completa 57

58 3. STEP 3 Per la valutazione del supporto informativo esistente nell azienda analizzata, sono state utilizzate le griglie precedentemente definite al passo Griglia informazioni / Basi di Dati L analisi AS-IS del caso, ha riscontrato la presenza di diverse basi dati nel sistema. Le basi di dati sono tutte indipendenti tra loro e non hanno modo di comunicare. Per questo, ci si trova di fronte ad un caso di isole Informative, le informazioni vengono memorizzate nelle diverse basi dati, e questo provoca la duplicazione di dati. Le basi di dati esistenti nell azienda sono quelle relative al RIS (sistema informativo sanitario), la base dati per la prenotazione delle prestazioni ambulatoriali e quella utilizzata dall amministrazione. La prima griglia proposta è quella che valuta la copertura dei dati dalle basi dati. Di seguito è riportata la griglia di valutazione ottenuta. 58

59 Database RIS Database Amm Database Pren Completezza Esattezza Aggiornamento Completezza Esattezza Aggiornamento Completezza Esattezza Aggiornamento Norma Cliente Pronto soccorso Ricoverati Esterni Legge Privacy Certificazioni ISO 9001 Livello di certificazione Dati identificativi Dati anagrafici Dati descrittivi Patient Health Record Accettazione Cure Stato Farmaco Certificazioni Referto di profilatura Dati identificativi Dati anagrafici Dati descrittivi Cartella clinica Accettazione Cure Stato Farmaco Prestazioni alberghiere Certificazioni Referto di profilatura Dati identificativi Dati anagrafici Dati descrittivi Patient Health Record Prenotazione Accettazione Prestazioni 59

60 Agente Fornitore Azionista Personale Committente Amministrativo Tecnico Medico Certificazioni Referto di profilatura Dati identificativi Dati anagrafici Dati descrittivi Dati amministrativi Contatti Certificazioni Ricevute di pagamento di profilatura Dati identificativi Dati anagrafici Dati descrittivi Dati amministrativi Fatture Certificazioni Contratto Acquisti di profilatura Dati Dati anagrafici identificativi Dati descrittivi Certificazioni Dati identificativi Dati descrittivi Dati anagrafici Mansione Competenze Pagamento busta paga Certificazioni Certificazioni di sviluppo Dati identificativi Dati anagrafici Specializzazione Dati descrittivi Competenze Pagamento busta paga Carriera Formazione Certificazioni Certificazioni Assenteismo Dati identificativi Dati anagrafici Specializzazione Dati descrittivi Competenze 60

61 Impianto Materie Prime Denaro Farmaci Dispositivi Medici Beni di consumo Pagamento busta paga Carriera Formazione Certificazioni Certificazioni Produttività Altri Dati identificativi Impianto Dati descrittivi Manuali Certificazioni Manutenzione Riparazione Certificazione di conformità AGING BFTR Dati identificativi farmaco Dati descrittivi Foglietto Illustrativo nota rifornimenti Certificazioni Certificazioni di conformità di qualità Turnover Dati identificativi Dati descrittivi Manuali Manutenzione Riparazione Certificazioni certificazioni ISO di qualità Turnover Dati identificativi Dati descrittivi Dati informativi nota rifornimenti Certificazioni Certificazioni Dati identificativi Dati descrittivi di qualità Turnover Dati anagrafici banca 61

62 Struttura Progetto Territorio Processo Prodotto Servizio Incassi Pagamenti Certificazioni Estratto conto Bilancio Organigramma Struttura Certificazioni ISO 9000 Struttura progetto (ABS, WBS) Apertura attività Chiusura Attività Certificazioni Collaudo di avanzamento end value Territorio (GIS) Struttura sequenza operazioni KPI Dati identificativi prodotto Dati descrittivi Distinta base Modifiche Certificazioni Collaudo qualità del servizio Qualià Servizio Costo 62

63 Come si può notare, non necessariamente le tabelle devono essere completate interamente. Le caselline rimaste vuote vogliono significare che quella determinata ABE non è interessata alla fase di analisi. Per l analisi si è adottata una scala qualitativa a cui è stata associata una opportuna scala di colori, scelta arbitrariamente. La griglia mostra molte zone gialle e talvolta rosse, a dimostrazione che le informazioni non sono opportunamente coperte dalle basi di dati alo stato attuale dell analisi. La griglia aiuta a capire in quali zone si deve intervenire per risolvere il problema delle isole informative, magari introducendo in fase di TO-BE nuove basi dati. Figura 38 - Grafico copertura basi di dati Il grafico mostra l andamento della copertura. Si osserva che solo in area amministrativa si ha la situazione ottimale, mentre, dato rilevante è la scarsa copertura per quanto riguarda le informazioni relative al cliente. 63

64 3.2 Griglia informazioni / Applicazioni Per valutare in che misura le informazioni sono coperte dalle applicazioni, si utilizzano le metriche CRUD. In ingresso alla griglia, oltre alle ABE vi è l inventario delle applicazioni presenti nella struttura. Applicazione prenotazione: applicazione presente sia allo sportello dove è possibile effettuare la prenotazione di persona, sia quella relativa alla prenotazione telefonica (CUP). Gestione risorse: applicazione dedicata alla gestione di tutte le risorse presenti in azienda (materie prime, risorse umane etc.). Gestione amministrazioni: applicazione dedicata alla gestione amministrativa (contabilità, contratti, appalti, etc.). S.I.O: Sistema Informativo Ospedaliero, dedicato alla gestione dell area sanitaria. E stato preso in considerazione per l analisi sebbene nel caso studiato non abbia un ruolo fondamentale, in quanto, come si è visto, la gestione delle informazione è risultata avere una struttura ad isole. 64

65 Norma Concorrente Cliente Pronto soccorso Ricoverati Esterni Committente Applicazione prenotazioni Gestione risorse Gestione amministrazioni S.I.O Legge Privacy R R R Certificazioni ISO 9001 R R R Livello di certificazione R R R R Dati identificativi Dati anagrafici R R Dati descrittivi Patient Health Record R CRUD Accettazione CRUD RU Cure R CRUD Stato R CRUD Farmaco CRUD R RU Certificazioni Referto R CRUD di profilatura CRUD Dati identificativi Dati anagrafici R R R Dati descrittivi Cartella clinica R CRUD Accettazione R R Cure R CRUD Stato R R Farmaco CRUD R RU Prestazioni alberghiere R CRUD R Certificazioni Referto R CRUD di profilatura CRUD Dati identificativi Dati anagrafici R R R Dati descrittivi Patient Health Record R CRUD Prenotazione CRUD R R Accettazione R R Prestazioni R R CRUD Certificazioni Referto R CRUD di profilatura CRUD Dati identificativi Dati anagrafici R R Dati descrittivi Dati amministrativi R R Contatti R CRUD Certificazioni Ricevute di pagamento CRUD R 65

66 Agente Fornitore Azionista Personale Impianto Amministrativo Tecnico Medico di profilatura CRUD Dati identificativi Dati anagrafici R R Dati descrittivi Dati amministrativi R R Fatture CRUD R Certificazioni Contratto Acquisti CRUD R di profilatura CRUD Dati identificativi Dati anagrafici R Dati descrittivi Certificazioni Dati identificativi Dati anagrafici CRUD Mansione CRUD Dati descrittivi Competenze CRUD Pagamento busta paga R Certificazioni Certificazioni R di sviluppo CRUD Dati identificativi Dati anagrafici CRUD Specializzazione CRUD Dati descrittivi Competenze CRUD Pagamento busta paga CRUD Carriera CRUD Formazione CRU Certificazioni Certificazioni CRU Assenteismo CRU Dati identificativi Dati anagrafici R R Specializzazione RU R Dati descrittivi Competenze RU R Pagamento busta paga CRUD Carriera CRUD Formazione CRU Certificazioni Certificazioni CRU Produttività CRUD Altri Dati identificativi Impianto R Dati descrittivi Manuali R Manutenzione CRUD 66

67 Riparazione CRUD Certificazioni Certificazione di conformità R AGEING RU BFTR Dati identificativi farmaco R R Dati descrittivi Foglietto Illustrativo R R Farmaci nota rifornimenti CRUD Certificazioni Certificazioni di conformità R di qualità R Turnover CRUD Dati identificativi R R Dati descrittivi Manuali R Manutenzione CRUD Materie Prime Dispositivi Medici Riparazione CRUD Certificazioni certificazioni ISO R di qualità R Turnover CRUD CRUD Dati identificativi R R Dati descrittivi Dati informativi R R Beni di consumo nota rifornimenti CRUD Certificazioni Certificazioni R di qualità R Turnover CRUD R Dati identificativi Dati anagrafici banca R R Dati descrittivi Denaro Incassi CRUD Pagamenti CRUD Certificazioni Estratto conto CRUD bilancio CRUD Organigramma Struttura CRUD Struttura Certificazioni ISO 9000 CRUD Struttura progetto (ABS, WBS) CRUD Apertura attività CRUD Progetto Chiusura Attività CRUD Certificazioni Collaudo CRUD di avanzamento end value CRUD Territorio Territorio (GIS) CRUD 67

68 Processo Prodotto Servizio Struttura sequenza operazioni CRUD CRUD KPI CRUD Dati identificativi prodotto R R CRUD R Dati descrittivi Distinta base RU CRUD R Modifiche CRUD Certificazioni Collaudo CRUD qualità CRUD del servizio R R CRUD R DRG R CRUD R Qualià CRUD Servizio R R CRUD R Costo R R CRUD 68

69 La griglia evidenzia la scarsa partecipazione dell applicazione relativa alle prenotazioni, e mette altresì in risalto il ruolo importante del SIO. Da tenere in considerazione in fase di realizzazione di un possibile TO-BE, poiché il SIO è un utile strumento per la maggiore condivisione delle informazioni e la gestione delle stesse. E stata effettuata una ulteriore analisi utilizzando sempre la stessa griglia di ingresso, questa volta però valutando la copertura dei dati utilizzando la stessa metrica prevista per il passo 3.1. Di seguito è riportato il risultato finale con il relativo grafico qualitativo. 69

70 Appl. Prenotazione Gestione Risorse Gestione Amministrazione SIO Completezza Esattezza Aggiornamento Completezza Esattezza Aggiornamento Completezza Esattezza Aggiornamento Completezza Esattezza Aggiornamento Norma Cliente Legge Privacy Certificazioni ISO 9001 Livello di certificazione Dati identificativi Dati anagrafici Dati descrittivi Patient Health Record Accettazione Pronto soccorso Cure Stato Farmaco Certificazioni Referto di profilatura Dati identificativi Dati anagrafici Dati descrittivi Cartella clinica Accettazione Cure Ricoverati Stato Farmaco Prestazioni alberghiere Certificazioni Referto di profilatura Esterni Dati identificativi Dati anagrafici 70

71 Agente Fornitore Azionista Personale Committente Amministrativo Tecnico Medico Dati descrittivi Patient Health Record Prenotazione Accettazione Prestazioni Certificazioni Referto di profilatura Dati identificativi Dati anagrafici Dati descrittivi Dati amministrativi Contatti Certificazioni Ricevute di pagamento di profilatura Dati identificativi Dati anagrafici Dati descrittivi Dati amministrativi Fatture Certificazioni Contratto Acquisti di profilatura Dati identificativi Dati anagrafici Dati descrittivi Certificazioni Dati identificativi Dati anagrafici Mansione Dati descrittivi Competenze Pagamento busta paga Certificazioni Certificazioni di sviluppo Dati identificativi Dati anagrafici Specializzazione Dati descrittivi Competenze Pagamento busta paga Carriera Formazione Certificazioni Certificazioni Assenteismo Dati identificativi Dati anagrafici Dati descrittivi Specializzazione 71

72 Competenze Pagamento busta paga Impianto Materie Prime Denaro Farmaci Dispositivi Medici Beni di consumo Carriera Formazione Certificazioni Certificazioni Produttività Altri Dati identificativi Impianto Dati descrittivi Manuali Manutenzione Riparazione Certificazioni Certificazione di conformità AGING BFTR Dati identificativi farmaco Dati descrittivi Foglietto Illustrativo nota rifornimenti Certificazioni Certificazioni di conformità di qualità Turnover Dati identificativi Dati descrittivi Manuali Manutenzione Riparazione Certificazioni certificazioni ISO di qualità Turnover Dati identificativi Dati descrittivi Dati informativi nota rifornimenti Certificazioni Certificazioni di qualità Turnover Dati identificativi Dati anagrafici banca Dati descrittivi Incassi Pagamenti Certificazioni Estratto conto 72

73 Struttura Progetto Territorio Processo Prodotto Servizio bilancio Organigramma Struttura Certificazioni ISO 9000 Struttura progetto (ABS, WBS) Apertura attività Chiusura Attività Certificazioni Collaudo di avanzamento end value Territorio (GIS) Struttura sequenza operazioni KPI Dati identificativi prodotto Dati descrittivi Distinta base Modifiche Certificazioni Collaudo qualità del servizio Qualià Servizio Costo 73

74 Come si verificare anche dal grafico, le applicazioni dedicate a determinate aree coprono in modo ottimale le informazioni relative ad esse. Figura 39 - Grafico della copertura dei dati dalle applicazioni 74

75 3.3 Griglia informazioni / Strutture Organizzative Il passo preveda la valutazione del supporto informativo alle strutture. In ingresso alla griglia è stato inserito l organigramma dell azienda, in particolare la macrostruttura aziendale. La macrostruttura è composta da 2 unità organizzative principali che seguono la logica delle funzioni e a loro volta suddivise gerarchicamente (figura 36). Figura 40 - Macrostruttura aziendale 75

76 DIREZIONE GENERALE AMMINISTRAZIONE DIREZIONE SANITARIA Dip. Tecnico/Economico Dip.Risorse Umane Dip. Diagnostica per immagini Dir. Presidio Territoriale Completezza Esattezza Aggiornamento Completezza Esattezza Aggiornamento Completezza Esattezza Aggiornamento Completezza Esattezza Aggiornamento Legge Privacy Norma Concorrente Cliente Pronto soccorso Ricoverati Certificazioni ISO 9001 Livello di certificazione Dati identificativi Dati anagrafici Dati descrittivi Patient Health Record Accettazione Cure Stato Farmaco Certificazioni Referto di profilatura Dati identificativi Dati anagrafici Dati descrittivi Cartella clinica Accettazione Cure Stato Farmaco Prestazioni alberghiere Certificazioni Referto di profilatura 76

77 Agente Fornitore Azionista Personale Dati identificativi Dati anagrafici Dati descrittivi Patient Health Record Prenotazione Esterni Accettazione Prestazioni Certificazioni Referto di profilatura Dati identificativi Dati anagrafici Dati descrittivi Dati amministrativi Committente Contatti Certificazioni Ricevute di pagamento di profilatura Dati identificativi Dati anagrafici Dati descrittivi Dati amministrativi Fatture Certificazioni Contratto Acquisti di profilatura Dati identificativi Dati anagrafici Dati descrittivi Certificazioni Dati identificativi Dati anagrafici Amministrativo Mansione Dati descrittivi Competenze Pagamento busta paga Certificazioni Certificazioni di sviluppo Dati identificativi Dati anagrafici Specializzazione Dati descrittivi Competenze Pagamento busta paga Tecnico Carriera Formazione Certificazioni Certificazioni Assenteismo Medico Dati identificativi Dati anagrafici 77

78 Impianto Materie Prime Denaro Farmaci Dispositivi Medici Beni di consumo Dati descrittivi Specializzazione Competenze Pagamento busta paga Carriera Formazione Certificazioni Certificazioni Produttività Altri Dati identificativi Impianto Dati descrittivi Manuali Manutenzione Riparazione Certificazioni Certificazione di conformità AGING BFTR Dati identificativi farmaco Dati descrittivi Foglietto Illustrativo Nota rifornimenti Certificazioni Certificazioni di conformità di qualità Turnover Dati identificativi Dati descrittivi Manuali Manutenzione Riparazione Certificazioni certificazioni ISO di qualità Turnover Dati identificativi Dati descrittivi Dati informativi Nota rifornimenti Certificazioni Certificazioni di qualità Turnover Dati identificativi Dati anagrafici banca Dati descrittivi Incassi Pagamenti 78

79 Struttura Progetto Territorio Processo Prodotto Servizio Certificazioni Estratto conto bilancio Organigramma Struttura Certificazioni ISO 9000 Struttura progetto (ABS, WBS) Apertura attività Chiusura Attività Certificazioni Collaudo di avanzamento end value Territorio (GIS) Struttura sequenza operazioni KPI Dati identificativi prodotto Dati descrittivi Distinta base Modifiche Certificazioni Collaudo qualità del servizio DRG Qualià Servizio Costo 79

80 Figura 41 - Grafico supporto alle strutture L analisi rileva un elevato supporto alle strutture amministrative, rimanendo in linea con le valutazioni precedenti che vedevano le informazioni relative all amministrazione le più coperte sia dalle applicazioni che dalle basi dati. 80

81 3.4 Griglia informazioni / Livelli di elaborazione In input alla griglia, oltre alle ABE individuate nei passi precedenti, sono stati messi i dispositivi utilizzati dall azienda. L architettura dell azienda si compone di client e server ed inoltre, è stata inserita la Carta dei Servizi, poiché già presente ma non ancora attiva. La valutazione sulla Carta dei Servizi, perciò, è stata fatta anche in previsione futura. I vari dispositivi sono stati divisi per competenza, ovvero CLIENT/SERVER/CARTA DEI SERVIZI di competenza del RIS (sistema informatico radiologia), della amministrazione e dello sportello prenotazione (sia esso quello telefonico oppure lo sportello vero e proprio ubicato all ASL). 81

82 RIS AMMINISTRAZIONE PRENOTAZIONE CLIENT SERVER CARTA SERVIZI CLIENT SERVER CARTA SERVIZI CLIENT SERVER CARTA SERVIZI Norma Concorrente Cliente Pronto soccorso Ricoverati Esterni Legge Privacy Certificazioni ISO 9001 CRU CRUD Livello di certificazione U CRUD Dati identificativi Dati anagrafici CRUD CRUD R R R Dati descrittivi Patient Health Record Accettazione Cure Stato Farmaco Certificazioni Referto di profilatura Dati identificativi Dati anagrafici R R R R R R CRUD CRUD R Dati descrittivi Cartella clinica CRUD CRUD R R Accettazione R R Cure RU CRUD Stato RUD CRUD Farmaco R R Prestazioni alberghiere CR CRUD Certificazioni Referto CRUD CRUD R R di profilatura R R Dati identificativi Dati anagrafici R R R R R R CRUD CRUD R Patient Health Dati descrittivi Record R R R R R R Prenotazione Accettazione Prestazioni Certificazioni Referto di profilatura 82

83 Agente Fornitore Azionista Personale Committente Amministrativo Tecnico Medico Dati identificativi Dati anagrafici Dati descrittivi Dati amministrativi Contatti Ricevute di Certificazioni pagamento di profilatura Dati identificativi Dati anagrafici CRU CRUD Dati descrittivi Dati amministrativi CRU CRUD Fatture CRU CRUD Certificazioni Contratto Acquisti CRU CRUD di profilatura Dati identificativi Dati anagrafici CRU CRUD Dati descrittivi Certificazioni Dati identificativi Dati anagrafici CRU CRUD Dati descrittivi Mansione CRU CRUD Competenze CRU CRUD Pagamento busta paga CRU CRUD Certificazioni Certificazioni CRU CRUD di sviluppo Dati identificativi Dati anagrafici R RU CRU CRUD Dati descrittivi Specializzazione R RU CRU CRUD Competenze R RU CRU CRUD Pagamento busta paga CRU CRUD Carriera CRU CRUD Formazione CRU CRUD Certificazioni Certificazioni CRU CRUD Assenteismo R CR Dati identificativi Dati anagrafici R RU CRU CRUD Dati descrittivi Specializzazione R RU CRU CRUD Competenze R RU CRU CRUD Pagamento busta paga CRU CRUD Carriera CRU CRUD Formazione CRU CRUD 83

84 Impianto Materie Prime Denaro Farmaci Dispositivi Medici Beni di consumo Certificazioni Certificazioni R CRUD Produttività Altri Dati identificativi Impianto CRU CRUD Dati descrittivi Manuali CRU CRUD Certificazioni Manutenzione CRU CRUD Riparazione CRU CRUD Certificazione di conformità AGING BFTR Dati identificativi farmaco R RU CRU CRUD Dati descrittivi Foglietto Illustrativo R RU CRU CRUD nota rifornimenti R RU CRU CRUD Certificazioni di Certificazioni conformità R RU CRU CRUD di qualità Turnover Dati identificativi R RU CRU CRUD Dati descrittivi Manuali R RU CRU CRUD Manutenzione R RU CRU CRUD Riparazione R RU CRU CRUD Certificazioni certificazioni ISO R RU CRU CRUD di qualità Turnover Dati identificativi R RU CRU CRUD Dati descrittivi Dati informativi R RU CRU CRUD nota rifornimenti R RU CRU CRUD Certificazioni Certificazioni R RU CRU CRUD di qualità Turnover Dati identificativi Dati anagrafici banca R CRUD Dati descrittivi Incassi R CRUD Pagamenti R CRUD Certificazioni Estratto conto R CRUD Bilancio Organigramma Struttura Struttura R CRUD 84

85 Progetto Territorio Processo Prodotto Servizio Certificazioni ISO 9000 R CRUD Struttura progetto (ABS, WBS) R CRUD Apertura attività RU CRUD Chiusura Attività RU CRUD Certificazioni Collaudo RU CRUD di avanzamento end value Territorio (GIS) RU CRUD Struttura sequenza operazioni RU CRUD RU CRUD KPI R RU Dati identificativi prodotto R RU RU CRUD Dati descrittivi Distinta base R RU RU CRUD Modifiche R RU RU CRUD Certificazioni Collaudo R RU RU CRUD qualità del servizio RU CRUD DRG RU CRUD Qualià Servizio Costo 85

86 4. STEP 4 Ultimo passo dello studio sui requisiti del caso radiologia, è l analisi di sensitività, cioè l individuazione di quali informazioni sono impattate da azioni strategiche. Le griglie proposte per tale analisi sono quelle che vedono in ingresso con le informazioni, le discontinuità di business, le discontinuità tecnologiche e le normative. Discontinuità di Business Sulle colonne della griglia sono stati inseriti gli obiettivi strategici risultati dallo studio. Gli obiettivi preposti per il miglioramento della situazione AS-IS del reparto radiologia individuati sono : o Prenotazione automatica delle prestazioni ambulatoriali; o Introduzione di una base dati unificata che permetta una migliore condivisione delle informazioni, eliminando i supporti cartacei e quindi le informazioni duplicate; o La attivazione della carta dei servizi per il miglioramento del reperimento dei dati; o La schedulazione automatica delle informazioni. Per l analisi si è utilizzata la stessa metrica di valutazione qualitativa a cui è stata associata una scala di colori. La griglia finale è riportata di seguito. 86

87 Prenotazione automatica DB unificato Carta dei servizi Schedulazione automatica Norma Cliente Agente Fornitore Azionista Personale Pronto soccorso Ricoverati Esterni Committente Amministrativo Legge Privacy Certificazioni ISO 9001 Livello di certificazione Dati identificativi Dati anagrafici Dati descrittivi Patient Health Record Accettazione Cure Stato Farmaco Certificazioni Referto di profilatura Dati identificativi Dati anagrafici Dati descrittivi Cartella clinica Accettazione Cure Stato Farmaco Prestazioni alberghiere Certificazioni Referto di profilatura Dati identificativi Dati anagrafici Dati descrittivi Patient Health Record Prenotazione Accettazione Prestazioni Certificazioni Referto di profilatura Dati identificativi Dati anagrafici Dati descrittivi Dati amministrativi Contatti Certificazioni Ricevute di pagamento di profilatura Dati identificativi Dati anagrafici Dati descrittivi Dati amministrativi Fatture Certificazioni Contratto Acquisti di profilatura Dati identificativi Dati anagrafici Dati descrittivi Certificazioni Dati identificativi Dati anagrafici Mansione Dati descrittivi Competenze 87

88 Impianto Materie Prime Denaro Struttura Tecnico Medico Farmaci Dispositivi Medici Beni di consumo Certificazioni Dati identificativi Dati descrittivi Certificazioni Dati identificativi Dati descrittivi Certificazioni Dati identificativi Dati descrittivi Certificazioni Dati identificativi Dati descrittivi Certificazioni Dati identificativi Dati descrittivi Certificazioni Dati identificativi Dati descrittivi Certificazioni Dati identificativi Dati descrittivi Certificazioni Pagamento busta paga Certificazioni di sviluppo Dati anagrafici Specializzazione Competenze Pagamento busta paga Carriera Formazione Certificazioni Assenteismo Dati anagrafici Specializzazione Competenze Pagamento busta paga Carriera Formazione Certificazioni Produttività Altri Impianto Manuali Manutenzione Riparazione Certificazione di conformità AGING BFTR farmaco Foglietto Illustrativo nota rifornimenti Certificazioni di conformità di qualità Turnover Manuali Manutenzione Riparazione certificazioni ISO di qualità Turnover Dati informativi nota rifornimenti Certificazioni di qualità Turnover Dati anagrafici banca Incassi Pagamenti Estratto conto bilancio Organigramma Struttura Certificazioni ISO

89 Progetto Territorio Processo Prodotto Servizio Certificazioni Dati identificativi Dati descrittivi Certificazioni Struttura progetto (ABS, WBS) Apertura attività Chiusura Attività Collaudo di avanzamento end value Territorio (GIS) Struttura sequenza operazioni KPI prodotto Distinta base Modifiche Collaudo qualità del servizio Qualità Servizio Costo Dalla griglia si può vedere che tutti e quattro gli obiettivi di business preposti impattano maggiormente sulla macroclasse Stakeholder. Maggiore rilevanza si ha soprattutto nel caso dell introduzione di un database unificato, poiché è l area con la maggiore criticità riscontrata. Le caselle rimaste vuote significano che le informazioni non sono interessate all introduzione di un determinato obiettivo; questo è diverso dall impatto nullo (colore rosso). 89

90 Discontinuità Tecnologiche L analisi è stata fatta considerando l impatto che può avere l introduzione della SOA. Una Service-Oriented Architecture (SOA, Architettura Orientata ai Servizi) è un modello architetturale per la creazione di sistemi residenti su una rete che focalizza l attenzione sul concetto di servizio. Un sistema costruito seguendo la filosofia SOA è costituito da applicazioni, chiamate servizi, ben definite ed indipendenti l una dall altra, che risiedono su più computer all interno di una rete (ad esempio la rete interna di una azienda). Ogni servizio mette a disposizione una certa funzionalità e può utilizzare quelle che gli altri servizi hanno reso disponibili, realizzando, in questo modo, applicazioni di maggiore complessità. L astrazione delle SOA non è legata ad alcuna specifica tecnologia, ma semplicemente definisce alcune proprietà, orientate al riutilizzo e all integrazione in un ambiente eterogeneo, che devono essere rispettate dai servizi che compongono il sistema. In particolare un servizio dovrà: o essere ricercabile e recuperabile dinamicamente. Un servizio deve poter essere ricercato in base alla sua interfaccia e richiamato a tempo di esecuzione. La definizione del servizio in base alla sua interfaccia rende quest ultima (e quindi l interazione con altri servizi) indipendente dal modo in cui è stato realizzato il componente che lo implementa. o essere autocontenuto e modulare. Ogni servizio deve essere ben definito, completo ed indipendente dal contesto o dallo stato di altri servizi. o essere definito da un interfaccia ed indipendente dall implementazione. Deve cioè essere definito in termini di ciò che fa, astraendo dai metodi e dalle tecnologie utilizzate per implementarlo. Questo determina l indipendenza del servizio non solo dal linguaggio di programmazione utilizzato per realizzare il componente che lo implementa ma anche dalla piattaforma e dal sistema operativo su cui è in esecuzione: non è necessario conoscere come un servizio è realizzato ma solo quali funzionalità rende disponibili. 90

91 o essere debolmente accoppiato con altri servizi (loosely coupled). Un architettura è debolmente accoppiata se le dipendenze fra le sue componenti sono in numero limitato. Questo rende il sistema flessibile e facilmente modificabile. o essere reso disponibile sulla rete attraverso la pubblicazione della sua interfaccia (in un Service Directory o Service Registry) ed accessibile in modo trasparente rispetto alla sua allocazione. Essere disponibile sulla rete lo rende accessibile da quei componenti che ne richiedono l utilizzo e l accesso deve avvenire in maniera indipendente rispetto all allocazione del servizio. La pubblicazione dell interfaccia deve rendere noto anche le modalità di accesso al servizio. o fornire un interfaccia possibilmente a grana grossa (coarsegrained). Deve mettere a disposizione un basso numero di operazioni, cioè poche funzionalità, in modo tale da non dover avere un programma di controllo complesso. Deve essere invece orientato ad un elevato livello di interazione con gli altri servizi attraverso lo scambio di messaggi. o essere realizzato in modo tale da permetterne la composizione con altri. Nell architettura SOA le applicazioni sono il risultato della composizione di più servizi. È per questo motivo che ogni servizio deve essere indipendente da qualsiasi altro, in modo tale da ottenere il massimo della riusabilità. La creazione di applicazioni o di servizi più complessi attraverso la composizione dei servizi di base viene definita Service Orchestration. Di seguito è riportata la griglia finale ottenuta dall analisi dell introduzione di una architettura SOA nell azienda ospedaliera. Per l analisi si è utilizzata la metrica qualitativa a cui è associata una scala di colori. 91

92 Norma Concorrente Cliente Agente Fornitore Pronto soccorso Ricoverati Esterni Committente Legge Privacy Certificazioni ISO 9001 Livello di certificazione Dati identificativi Dati anagrafici Dati descrittivi Patient Health Record Accettazione Cure Stato Farmaco Certificazioni Referto di profilatura Dati identificativi Dati anagrafici Dati descrittivi Cartella clinica Accettazione Cure Stato Farmaco Prestazioni alberghiere Certificazioni Referto di profilatura Dati identificativi Dati anagrafici Dati descrittivi Patient Health Record Prenotazione Accettazione Prestazioni Certificazioni Referto di profilatura Dati identificativi Dati anagrafici Dati descrittivi Dati amministrativi Contatti Certificazioni Ricevute di pagamento di profilatura Dati identificativi Dati anagrafici Dati descrittivi Dati amministrativi Fatture SOA 92

93 Certificazioni Contratto Acquisti di profilatura Dati identificativi Dati anagrafici Dati descrittivi Azionista Certificazioni Dati identificativi Dati anagrafici Amministrativo Mansione Dati descrittivi Competenze Pagamento busta paga Certificazioni Certificazioni di sviluppo Dati identificativi Dati anagrafici Specializzazione Dati descrittivi Competenze Pagamento busta paga Tecnico Carriera Personale Formazione Certificazioni Certificazioni Assenteismo Dati identificativi Dati anagrafici Specializzazione Dati descrittivi Competenze Pagamento busta paga Medico Carriera Formazione Certificazioni Certificazioni Produttività Altri Dati identificativi Impianto Dati descrittivi Manuali Manutenzione Impianto Riparazione Certificazioni Certificazione di conformità AGING BFTR Materie Prime Farmaci Dati identificativi farmaco 93

94 Denaro Struttura Progetto Territorio Processo Dispositivi Medici Beni di consumo Dati descrittivi Foglietto Illustrativo Nota rifornimenti Certificazioni Certificazioni di conformità di qualità Turnover Dati identificativi Dati descrittivi Manuali Manutenzione Riparazione Certificazioni certificazioni ISO di qualità Turnover Dati identificativi Dati descrittivi Dati informativi Nota rifornimenti Certificazioni Certificazioni di qualità Turnover Dati identificativi Dati anagrafici banca Dati descrittivi Incassi Pagamenti Certificazioni Estratto conto bilancio Organigramma Struttura Certificazioni ISO 9000 Struttura progetto (ABS, WBS) Apertura attività Chiusura Attività Certificazioni Collaudo di avanzamento end value Territorio (GIS) Struttura sequenza operazioni KPI 94

95 Prodotto Servizio Dati identificativi prodotto Dati descrittivi Distinta base Modifiche Certificazioni Collaudo qualità del servizio DRG Qualià Servizio Costo 95

96 Dalla griglia si osserva che il dominio cliente è quello maggiormente interessato all introduzione della SOA. Il risiede nel fatto che un architettura SOA permette una vista unificata e in tempo reale dei dati relativi al paziente. Questi dati possono essere ricavati sia dai documenti dell ospedale e dei medici, sia dai sistemi di terze parti (ad esempio una società assicurativa). In questo caso, non solo le fonti da cui derivano le informazioni operano su sistemi e applicazioni diverse, ma utilizzano anche una terminologia (paziente versus titolare della polizza) e metodi di registrazione (John Smith versus Smith, John P) differenti. Un architettura SOA permette di unificare diverse tipologie di informazioni provenienti da fonti diverse, sia interne che esterne, di conseguenza, può offrire una vista unificata del paziente/titolare della polizza. Informazioni sensibili L analisi è stata effettuata valutando l impatto delle normative sulla Privacy e sulla Sicurezza. Si è utilizzata la scala qualitativa già utilizzata in precedenza. 96

97 Legge Privacy Norma Certificazioni ISO 9001 Livello di certificazione Dati identificativi Dati anagrafici Dati descrittivi Patient Health Record Accettazione Pronto soccorso Cure Stato Farmaco Certificazioni Referto di profilatura Dati identificativi Dati anagrafici Dati descrittivi Cartella clinica Accettazione Cure Ricoverati Stato Farmaco Cliente Prestazioni alberghiere Certificazioni Referto di profilatura Dati identificativi Dati anagrafici Dati descrittivi Patient Health Record Prenotazione Esterni Accettazione Prestazioni Certificazioni Referto di profilatura Dati identificativi Dati anagrafici Dati descrittivi Dati amministrativi Committente Contatti Certificazioni Ricevute di pagamento di profilatura Agente Fornitore Dati identificativi Dati anagrafici Sicurezza Privacy 97

98 Azionista Personale Impianto Amministrativo Tecnico Medico Dati descrittivi Dati amministrativi Fatture Certificazioni Contratto Acquisti di profilatura Dati identificativi Dati anagrafici Dati descrittivi Certificazioni Dati identificativi Dati anagrafici Mansione Dati descrittivi Competenze Pagamento busta paga Certificazioni Certificazioni di sviluppo Dati identificativi Dati anagrafici Specializzazione Dati descrittivi Competenze Pagamento busta paga Carriera Formazione Certificazioni Certificazioni Assenteismo Dati identificativi Dati anagrafici Specializzazione Dati descrittivi Competenze Pagamento busta paga Carriera Formazione Certificazioni Certificazioni Produttività Altri Dati identificativi Impianto Dati descrittivi Manuali Manutenzione 98

99 Materie Prime Denaro Struttura Progetto Farmaci Dispositivi Medici Beni di consumo Riparazione Certificazioni Certificazione di conformità AGING BFTR Dati identificativi farmaco Dati descrittivi Foglietto Illustrativo nota rifornimenti Certificazioni Certificazioni di conformità di qualità Turnover Dati identificativi Dati descrittivi Manuali Manutenzione Riparazione Certificazioni certificazioni ISO di qualità Turnover Dati identificativi Dati descrittivi Dati informativi nota rifornimenti Certificazioni Certificazioni di qualità Turnover Dati identificativi Dati anagrafici banca Dati descrittivi Incassi Pagamenti Certificazioni Estratto conto bilancio Organigramma Struttura Certificazioni ISO 9000 Struttura progetto (ABS, WBS) Apertura attività Chiusura Attività 99

100 Territorio Processo Prodotto Servizio Certificazioni Collaudo di avanzamento end value Territorio (GIS) Struttura sequenza operazioni KPI Dati identificativi prodotto Dati descrittivi Distinta base Modifiche Certificazioni Collaudo qualità del servizio Qualià Servizio Costo 100

101 Da notare assenza del colore rosso. Il valore nullo nella scala risulta ambiguo ai fini della valutazione perché non aiuta a capire il vero impatto sull informazione: dando valore nullo si intende che non impatta oppure che l informazione non è interessata? Si è preferito scegliere la soluzione di non riempire la casella, sia nel caso in cui esse non fossero interessate, sia in quello in cui l impatto è nullo. 101

102 Appendice Di seguito si riporta il capitolo sull astrazione tratto da Motta, Bracchi, Classificazione Classificare (classification) significa definire classi di oggetti. Una classe è un insieme di oggetti individuali che sono caratterizzati da una proprietà comune. Per esempio, gli individui Borg, Panatta, Edberg sono collettivamente classificati come tennista, in quanto giocano a tennis. Tennista è quindi una classe, tutti i membri della quale condividono la caratteristica di giocare a tennis. A seconda della proprietà comune che consideriamo, un medesimo oggetto può appartenere a più classi. Per esempio Panata e Borg sono membri della classe Calciatore in quanto entrambi giocano a pallone. Per indicare graficamente la appartenenza di una data serie di oggetti a una data classe, si usa un grafo ad albero. Le foglie dell albero elencano i membri della classe, la radice indica la classe considerata, e gli archi orientati che uniscono foglie e radice mostrano la relazione di appartenenza (IS-MEMBER-OF) degli individui alla classe (Figura 44). BORG PANATTA TENNISTA EDBERG ABSTRACTION 1 Figura 42 - Esempio di classificazione [Abstraction 1] BORG PANATTA CALCIATORE TENNISTA EDBERG ABSTRACTION 2 Figura 43 - Classficazione multipla : esempio [Abstraction 2] 102

103 La figura 45 esemplifica una classificazione dei processi di elaborazione di un sistema informativo. I processi Versamento sul conto corrente, Stampa del saldo del conto corrente, Calcolo mensile degli interessi sul conto corrente sono ascritti a diverse classi, a seconda che sia stata rispettivamente considerata la caratteristica modalità di elaborazione o tipologia operativa. VERSAMENTO SU C/C CALCOLO MENS. INTERESSI STAMPA SALDO C/C PROCESSI INTERATTIVI AGGIORNAMENTI INTERROGAZIONI ABSTRACTION 3 Figura 44 - Classificazione multipla: un altro esempio Aggregazione L aggregazione è un procedimento di astrazione attraverso cui delle classi di oggetti sono incluse in una altra classe. La struttura di una registrazione di una base dati è un classico esempio di aggregazione. Le classi cognome, nome formano la classe identificazione ; la classe identificazione, insieme con la classe numero conto corrente, forma la classe correntista bancario. L aggregazione è rappresentata da un albero, la cui radice indica la classe al vertice della gerarchia d aggregazione, mentre gli archi orientati indicano di quale classe un dato nodo fa parte (IS-PART-OF). Come si nota, l aggregazione può essere, e tipicamente è, su più livelli. Per distinguere l aggregazione dalla classificazione, la notazione per gli oggetti e per gli archi è diversa (Figura 46). CORRENTISTA NUMERO CONTO IDENTIFICAZI ONE NOME COGNOME Figura 45 - Gerarchia di aggregazione: esempio 103

104 Le gerarchie d aggregazione sono un meccanismo fondamentale per la analisi dei sistemi. La analisi ha, infatti, lo scopo di individuare i componenti ultimi della base dati e dei processi, rispettivamente i dati elementari ed i moduli di programma. Consideriamo il caso della base dati. La base dati può essere vista come una aggregazione di (tipi di) registrazioni, che, a loro volta, sono aggregazioni di proprietà (la registrazione "correntista" aggrega le proprietà "numero conto corrente" e "identificazione"). Analogo ragionamento si applica ai processi. Un sottosistema di processi aggrega un certo numero di processi, che a loro volta sono aggregazioni di moduli. La Figura 47 mostra la gerarchia globale di aggregazione di un immaginario sistema informativo per i conti correnti. Il sotto-albero della base dati comprende tre tipi di registrazione, di cui nell albero è dettagliato solo quello che si riferisce al correntista. Il sotto-albero dei processi include vari processi; i moduli di programma sono individuati solo per il processo versamento da assegno. NUMERO C/C CORRENTISTA IDENTIFICAZIONE NOME BASE DATI COGNOME CONTO MOVIMENTI GESTIONE CLIENTE E C/C RICHIESTA SALDO SISTEMA C/C STAMPA MOVIMENTI IDENTIFICAZIONE PROCESSI OPERAZIONI VERSAMENTO DA ASSEGNO BENESTARE ASSEGNO AGG.TO BASE DATI STAMPA DOC. ALTRE OPERAZIONI NON SPORTELLO SEGNAL. PERIODICHE Figura 46 - Gerarchia d aggregazione: l'albero dei dati e dei processi di un sistema informativo aziendale 104

105 Generalizzazione La generalizzazione è un procedimento attraverso cui si costruiscono gerarchie di caratteristiche fra (elementi di) due o più classi. Per esempio, sia la classe dei calciatori sia la classe dei tennisti hanno alcune caratteristiche comuni: la iscrizione a un club, il nome. D'altra parte però, le due classi si distinguono per altre caratteristiche: i tennisti giocano in una categoria agonistica, mentre i calciatori sono legati da un contratto. Astraendo le proprietà comuni, si definisce una nuova classe "Giocatori", che aggrega le caratteristiche comuni alle sottoclassi "Tennisti" e "Calciatori". La generalizzazione è rappresentata graficamente da un albero. I nodi inferiori dell'albero rappresentano le classi iniziali, la radice indica la classe generalizzata, e gli archi dell'albero indicano che ogni nodo è un sottoinsieme (IS-A) della classe radice (Figura 48). GIOCATORE TENNISTA CALCIATORE Figura 47 - Generalizzazione: esempio La gerarchia di generalizzazione è una astrazione fondamentale per la analisi sia dei processi sia dei dati. Nella analisi dei dati, essa per esempio permette di approfondire un dato aggregato di informazioni per approssimazioni successive. Si consideri per esempio il caso di una azienda telefonica che progetta una banca dati sui clienti. Il primo passo sarà evidentemente una ampia definizione per ciò che si intende come cliente in genere, per esempio "una entità giuridica o una persona fisica con cui la azienda ebbe, ha od avrà rapporti economici relativamente ai servizi telefonici". Questa definizione, ancorché vaga, ci indica subito che i clienti possono essere di diversi tipi. Per esempio, rispetto al tempo, possono essere clienti "storici", "correnti", "potenziali"; analogamente, rispetto alla loro 105

106 natura sociale ed alle loro condizioni contrattuali, i clienti possono essere enti giuridici o persone private (il "signor Rossi"). La gerarchia di generalizzazione permette di dettagliare per successivi livelli, dal generale al particolare, le specializzazioni del concetto di "cliente" (la gerarchia di generalizzazione è simile al procedimento platonico di divisione delle idee). STORICO PERSONA CORR. POT. CLIENTE STORICO ENTE CORR. POT. Figura 48 - Gerarchia di generalizzazione di "cliente" [GENERAL 2] Lo stesso ragionamento si applica ai processi. Supponiamo, sempre nella stessa azienda telefonica, di analizzare i processi di elaborazione dei contratti dei clienti. E' evidente che tutti i processi risponderanno ad un generalissimo tipo di evento, che chiamiamo "richiesta contratto". Ora, analizzando l'evento in questione, possiamo distinguerlo, a seconda del tipo del cliente, nelle due grandissime classi "contratti privati" e "contratti societari". Proseguendo la analisi, dividiamo i contratti privati a seconda del tipo di eventi, in "richiesta cliente" e "rinnovo". Otterremo così la gerarchia di processi mostrata in figura, che ovviamente andrebbe dettagliata sino a trovare dei tipi elementari. 106

107 RICH. CONTRATTO PERSONA RICHIESTA RINNOVO ENTE Figura 49 - Gerarchia di generalizzazione di "richiesta" [GENERAL 3] Osservazioni E' importante osservare che una gerarchia di generalizzazione può essere costruita sia bottom-up sia top-down. La divisione di un tipo ("cliente") in sottotipi ("provato", "ente") è una costruzione top-down. Viceversa, l unificazione di più sottotipi (per esempio, "impiegato", "operaio", dirigente") in un unico tipo supertipo (per esempio "dipendente") è una costruzione bottom-up. Per chiarezza chiameremo "specializzazione" la costruzione top-down e "generalizzazione" quella bottom-up. Anche la gerarchia di aggregazione può essere costruita sia bottom-up sia top-down. Chiameremo "scomposizione" la costruzione top-down, in cui un oggetto è appunto scomposto nelle sue parti, e "aggregazione" la costruzione bottom-up, in cui degli elementi componenti sono aggregati in un unico composto. La generalizzazione-specializzazione e la scomposizione-aggregazione sono usate congiuntamente nella analisi dei sistemi informativi. Qui di seguito consideriamo alcuni semplici esempi. a) Generalizzazione di processi Si considerino i processi di elaborazione di un generico sistema informativo "Conti correnti" di una generica banca. Ogni processo comprende dei sottoprocessi. Come è evidente dalla figura 9, il sottoprocesso "Identificazione" è presente in tutti i processi considerati. Altri sottoprocessi, come "Output su video", sono presenti solo in alcuni processi. Applicando la generalizzazione, si ottiene lo schema di cui in figura 46. Il sistema è suddiviso in due sottosistemi, i processi di consultazione e quelli di movimentazione. Tutti i processi hanno in comune "Identificazione". A loro volta, tutti i processi di consultazione hanno in comune "Output su video". In una gerarchia di generalizzazione, le classi di livello inferiore ereditano tutte le caratteristiche della rispettiva di livello superiore. La generalizzazione permette di ingegnerizzare la progettazione dei processi, lasciando al progettista la scelta se realizzare tutti i processi con una stessa catena di moduli 107

108 (generalizzazione del software) o se, invece, realizzarli separatamente (specializzazione del software). C/C RICHIESTA SALDO STAMPA MOVIMENTI VERSAMENTO ASSEGNO VERSAMENTO CONTANTI PRELIEVO CON Identificazione Output su video Identificazione Identificazione Identificazione Identificazione Identificazione richiesta Output su video Benestare assegno Aggiornamento b.d. Benestare assegno Identificazione richiedente e Stampa lista movimenti Aggiornamento b.d. Stampa doc. versamento Benestare fondi Input parametri operazione Stampa doc. versamento Segnalazione cassa Aggiornamento b.d. Lettura b.d. Figura 50 - Gerarchia di aggregazione dei processi di un sistema: esempio 108

109 Identificazione Output su video CONSULTAZIO NE STAMPA Stampa lista movimenti Agg.to b.d. OPERAZIONE Stampa docum. versam. MOVIMENTAZI ONE CONTO VERSAMENTO CONTANTI Segnalazione cassa ASSEGNO Benestare assegno PRELIEVO CON ASSEGNO Benestare fondi Benestare assegno Figura 51 - Generalizzazione dei processi di un sistema: esempio b) Generalizzazione di dati Si consideri il caso degli ordini Italia e degli ordini Estero. Entrambe le classi di dati contengono la sottoclasse "Identificazione Ordine", "Codice cliente", "Codice articolo", 109

110 "Quantità ordinata". Esse possono essere perciò generalizzate nella classe "Ordini", che si divide nelle due sottoclassi "Ordini-Italia", "Ordini-Estero" (figura 53, figura 54). ORDINI ORDINI ITALIA ORDINI ESTERO Identificazione Codice fiscale cliente Codice cliente Codice articolo Quantità ordinata Identificazione Ordine # Codice cliente Data ordine Codice paese Tipo ordine Codice valuta Stato ordine Codice articolo Quantità ordinata Figura 52 - Gerarchia di aggregazione: esempio di dati relativi a generici ordini 110

111 Identificazione Codice cliente Codice articolo ORDINI Quantità ordinata ORDINI ITALIA Codice fiscale cliente ORDINI ESTERO Codice paese Codice valuta Figura 53 - Gerarchia di generalizzazione : esempio 111

112 Casi d Uso e Scenari L analisi dei requisiti può essere associata a scenari e diagrammi dei casi d uso, tecniche di cui si tratta in questo capitolo ma che non rientrano in quelle che si vogliono studiare in questo lavoro. Come già citato in precedenza, per facilitare la definizione dei requisiti si può ricorrere alla tecnica degli scenari (J.Carroll,2000). Uno scenario immagina come un utente può interagire con in sistema, cercando di prevedere il comportamento dello stesso e la reazione del sistema alle sue richieste. Uno scenario è un esempio concreto di una parte che sarà supportata dal sistema da realizzare e deve essere realistico e saliente. Uno scenario anticipa le interazioni con gli utenti e quello che il sistema permette e non permette di fare, è utile perciò a verificare se gli obiettivi degli stakeholder sono stati compresi. Con gli scenari si agevolano i colloqui con gli stakeholder, velocizzando il processo di definizione dei requisiti. Gli scenari possono essere espressi a diversi livelli di dettaglio e rappresentati, in genere, secondo una forma narrativa, ma si possono altresì esprimere in forma non testuale come ad esempio mock-up e storyboard. Di seguito è riportato un esempio di scenario: Scenario Maria abita a Roma e quasi ogni sabato va a trovare i nipoti a Napoli prendendo l'ic delle 12:10. Oggi l'accompagna anche una sua cara amica che però non ha la Carta Argento come lei. Sono un po' in ritardo ed inoltre si sono accorte di non avere abbastanza moneta contante per i due biglietti. Maria decide di pagare con il suo Bancomat entrambi i biglietti. Requisiti Maria non ha bisogno di avere informazioni sull'orario, nè sul tipo di treno, vuole solo comprare i biglietti Maria vuole comprare due biglietti Maria vuole comprare un biglietto con la riduzione della Carta Argento Maria vuole pagare con il Bancomat Gli scenari sono un sottoinsieme di un altra tecnica che facilita la definizione dei requisiti: quella degli Use Case. 112

113 Il concetto di caso d'uso (use case) è stato proposto da Ivar Jacobson, uno degli autori principali di UML, per la prima volta nel Ma la diffusione del termine avviene a partire dal 1992, con la pubblicazione del libro Object-Oriented Software Engineering. A Use Case Driven Approach. I casi d uso costituiscono un insieme di scenari che identificano uno schema d uso del sistema che deve essere costruito, ovvero sono una descrizione del modo in cui il prodotto verrà utilizzato. Un caso d uso cita brevemente una storia riguardante il modo in cui un utente finale interagisce con il sistema, in un determinato insieme di circostanze, e rappresenta il prodotto dal punto di vista dell utente finale. Ci saranno, di seguito, degli attori, che utilizzeranno il sistema nel contesto della funzione descritta. Un esempio di diagramma di Use Case può essere il seguente: QuickTime e un decompressore TIFF (LZW) sono necessari per visualizzare quest'immagine. Figura 54 - Esempio di Use Case caso bibliotecario Dal punto di vista degli Use Case, un sistema viene visto come una black box sigillata, ed possibile osservarne solo i comportamenti dall esterno. È il punto di vista dell utilizzatore, e di tutto ciò che interagisce con il sistema nell ambito del suo funzionamento. Usare i casi d'uso significa: 1. Individuare chi (persone, o altri sistemi "esterni") dovrà utilizzare il sistema 113

114 2. Chiedersi quali sono gli obiettivi che intendono conseguire utilizzando il sistema 3. Approfondire, in termini di descrizione di scenari concreti, ciascuna modalità di utilizzo, chiarendo il modo in cui inizia, le risposte che l utilizzatore si attende dal sistema, la sequenza di passi con cui l interazione si svolge, eventuali altri soggetti (esterni al sistema) coinvolti. Ragionare con i committenti (e gli altri stakeholder) in termini di casi d'uso agevola notevolmente la scoperta dei requisiti ed il loro progressivo chiarimento. E costituisce un ottimo punto di partenza per le attività di analisi e design, implementazione e test del sistema. I casi d uso sono parti del linguaggio UML, dell aspetto funzionale del la descrizione del sistema: il modello funzionale rappresenta il sistema dal punto di vista dell'utente, ovvero ne descrive il suo comportamento così come esso è percepito all'esterno, prescindendo dal suo funzionamento interno. 114

115 Allegato: Caso Radiologia Il signor Rossi Italia del Centro. Una provincia di di abitanti circa. Lunedì mattina. Matteo Rossi, come tutte le mattine, si prepara per andare alla stazione ferroviaria e recarsi al lavoro. Anche oggi avverte un dolore acuto alla schiena. Il dolore non è forte, durante la giornata si attenua sino a scomparire, ma si ripresenta la mattina successiva. Inizialmente il signor Rossi aveva pensato ad un malessere temporaneo e non aveva dato peso, considerandolo un dolorino di mezza età. Oggi tuttavia le cose sembrano peggiori e forse è occorre recarsi dal medico di base, il dr. Rapetti. Rapetti è un brillante dottore che ha sostituito l anziano dr. Claudio Ragusa, andato in pensione. Il sig. Rossi e il Dr. Ragusa si conoscevano da tempo e il loro rapporto era divenuto di amicizia più che di paziente-medico. Il Dr. Ragusa riceveva spesso dopo l orario di ambulatorio, alla sera, così da evitare a Rossi di dover richiedere un permesso dal lavoro. Rappetti invece non conosce ancora i suoi pazienti e non aveva ancora creato quindi un rapporto personale: questa volta Rossi doveva chiedere mezza giornata di permesso per farsi visitare. Presa nota dell orario di visita, Rossi decise di presentarsi al mattino presto per evitare la coda. Entrato nella sala d aspetto dello studio medico, constatò che la sua tattica era troppo scontata: la sala era già gremita di persone e ad occhio e croce l attesa non sarebbe stata breve. Dopo un tempo che sembrava interminabile arrivò il suo turno. Il Dr. Rapetti lo accolse calorosamente e iniziò a fargli le consuete domande per l anamnesi. Rapetti non aveva dimestichezza con il personal computer e compilava schede cartacee. Rossi spiegò dettagliatamente il proprio disturbo e Rapetti lo visitò accuratamente. Terminata la visita, non nascose alcune perplessità: i dolori erano stati trascurati e dalla visita erano emerse sintomi contrastanti. Era quindi necessaria una visita da parte dello specialista ortopedico, che avrebbe definito le analisi da fare. Forse sarebbe bastata una semplice radiografia ma avrebbero potuto essere necessarie una TAC o una risonanza magnetica (RM). Con l impegnativa del medico, Rossi tornò a casa e telefonò al centro unico di prenotazione (CUP) per fissare un appuntamento. Rossi temeva di passare il pomeriggio al telefono, attendendo una risposta. Forse sarebbe stato meglio andare agli sportelli della 115

116 ASL, attendere il proprio turno e prenotare l appuntamento di presenza. Ma questo avrebbe significato chiedere altre ore di permesso. Il telefono pareva l unica soluzione. Fortunatamente tutto si risolse velocemente: fornito il numero dell impegnativa e il nome del medico, riuscì a prenotare in un azienda ospedaliera vicina a casa e con un ortopedico molto bravo, almeno a detta di molti. Lo specialista riscontrò, durante la visita specialistica, la presenza di alcune anomalie, non preoccupanti, ma da non trascurare; ritenne quindi utile analizzare la situazione con una radiografia della zona lombo-sacrale con particolare attenzione alle vertebre L5-S1 così da potere escludere alcune cause già in fase iniziale. Con la nuova impegnativa, Rossi si diresse allo sportello della ASL per le prenotazioni, per non perdere altro tempo. Arrivato allo sportello però lo trovò chiuso. Guardando l orario di apertura (8:00 12:00; 14:00 16:00) comprese di avere perso l occasione di prenotare sul posto, proprio per i per pochi minuti che aveva speso per le spiegazioni dell ortopedico. Non restava che telefonare al CUP. Questa volta fu più difficile: l attesa fu lunga e l operatore sembrava fare molta confusione sulle informazioni da fornire. Alla fine riuscì a prenotare la visita per la settimana successiva. Rossi si recò di buon mattino presso la azienda ospedaliera. Entrato nel Dipartimento di Diagnostica per Immagini notò due file in sala di attesa. Da un lato stavano pazienti vestiti e dall altro pazienti in pigiama e/o vestaglia. Il primo gruppo era composto da pazienti ambulatoriali, mentre il secondo da pazienti ricoverati presso i reparti dell azienda ospedaliera. Rossi si chiese come fosse possibile gestire contemporaneamente utenti così diversi. Tra qualche ora avrebbe avuto risposta alla sua domanda. In fondo alla grande sala vi era uno sportello amministrativo del Dipartimento Immagini che curava l accettazione, la segreteria e il ritiro referti. Le postazioni erano quattro: due dedicate all accettazione, una dedicata alla consegna dei referti e una impegnata in attività di segreteria. Gli sportelli erano aperti da lunedì a sabato, dalle 8:00 alle 14:00, ed il giovedì dalle 15:30 alle 17:30 (il progetto originario, come riportato dai giornali locali, prevedeva con orario continuato dalle 8:00 alle 20:00, che era stato possibile attuare per mancanza di personale). Il turno del pomeriggio coincideva con il turno dello sportello, in modo che i pazienti potessero pagare i ticket. Lo sportello dedicato alla consegna dei referti permetteva il ritiro 116

117 dei risultati dal lunedì al venerdì dalle 11:00 alle 13:30, il giovedì anche dalle 15:30 alle 17:30 e il sabato dalle 10:30 alle 12:30. Lo sportello era aperto 313 giorni l anno (escluse le domeniche) per sei ore al giorno, per un totale di ore; considerando le aperture pomeridiane si raggiungevano1.982 ore lavorative l anno. L accettazione dei pazienti avveniva unicamente allo sportello. Ogni paziente doveva presentare la prescrizione sanitaria (impegnativa), la tessera sanitaria, la documentazione relativa ad eventuali esenzioni dal ticket e, se richiesta, la ricevuta del pagamento del ticket. L operatore, tramite il software gestionale, recuperava i dati sul paziente ed inseriva una nuova richiesta, comprensiva delle analisi da condurre. Talvolta il paziente non aveva con sé la tessera sanitaria o la calligrafia del medico era incomprensibile. In questo caso l operatore invitava il paziente a ripresentarsi con tutti i documenti completi e validi, causando tensioni. L operatore, in possesso di tutti i dati, specificava la convenzione con la quale il paziente accedeva al servizio e calcolava le eventuali riduzioni sul ticket. Una volta inseriti i dati, l operatore stampava in doppia copia una distinta con i dati riepilogativi della richiesta: codice della richiesta, codice del paziente, elenco delle immagini richieste, codice della radiologia che si avrebbe prodotto le immagini, l importo da pagare e la data di ritiro del referto. La data di ritiro era calcolata sulla base del tempo di attesa maggiore (per ogni tipo di immagine a listino era indicato il relativo tempo di attesa). Sulla distinta erano indicati gli orari in cui si potevano ritirare i referti; era inoltre scritto che il referto poteva essere ritirato solo dal paziente o da un suo delegato scritto in un apposito spazio del modulo. La distinta riportava il numero telefonico della segreteria, alla quale era possibile chiedere l avanzamento degli esami; per evidenti motivi di privatezza non era possibile sapere l esito della refertazione per telefono. Una copia della distinta rimaneva in accettazione per scopi amministrativi, l altra era consegnata al paziente. L accettazione, inoltre, raccoglieva gli eventuali referti di esami precedenti portati dal paziente per farli visionare dal radiologo e dal medico specialista. In questo caso, la distinta menzionava i referti acquisiti, che venivano restituiti al paziente insieme con i nuovi. In sala accettazione, erano provvisoriamente archiviate le impegnative e le ricevute dei ticket pervenute, successivamente trasferite in sala archivio. Il ticket era pagato o il giorno stesso dell esame o in precedenza, dopo la prenotazione della visita. Erano possibili diverse modalità di pagamento: contanti, carta di credito, bonifico bancario. Il pagamento per contanti o carta di credito avveniva presentando 117

118 l impegnativa del medico di base allo sportello esterno, collocato presso gli uffici della ASL. Gli operatori dell accettazione avevano un elenco cartaceo delle prenotazioni, stampato dal CUP (Centro Unico Prenotazione) il giorno precedente e consegnato da un fattorino la mattina successiva. L elenco, inserito su un semplice foglio excel dagli operatori del CUP a fine turno, spesso non solo era incompleto ma riportava anche generalità errate. Gli operatori, non avendo reali strumenti di controllo, assumevano che i pazienti si presentassero il giorno giusto. Lo Sportello Ticket era aperto con orario continuato dalle 9:00 alle 17:30. Poiché l orario di apertura era posticipato di un ora rispetto all accettazione, l accettazione anticipava le distinte chiedendo al paziente di pagare il ticket quanto prima. Accadeva che alcuni pazienti si recassero allo Sportello Ticket e aspettassero l apertura, ritardando l arrivo alla sala diagnostica; altri invece si recavano subito alla sala diagnostica proponendosi di pagare il ticket ad esame terminato. Spesso questi pazienti si dimenticavano di pagare il ticket. Il giorno del ritiro del referto l operatore, se si accorgeva che il ticket non era stato pagato, chiedeva il pagamento prima del ritiro del referto. Rossi ritirò la distinta mostrando il pagamento del ticket effettuato tramite bonifico bancario e si diresse verso la sala diagnostica B. L azienda ospedaliera disponeva di nove sale diagnostiche. Le sale A-F realizzavano indagini con raggi X, la sala G con la tomografia assiale computerizzata (TAC), la sala H con la risonanza magnetica nucleare (RMN) e la sala I con la ecografia (ECO). Giunto alla sala diagnostica B Rossi consegnò la distinta ad un infermiera e si mise a sedere, aspettando il proprio turno. Dopo un ora era stata chiamata la maggioranza dei pazienti arrivati prima di lui: in breve sarebbe arrivato il suo turno, pensò Rossi. All improvviso una forte agitazione attraversò la corsia: era avvenuto un incidente stradale sulla strada provinciale, che aveva coinvolto motociclette e pedoni. Si temevano politraumatizzati. La sala diagnostica B era stata allertata e le visite furono sospese in attesa dell arrivo delle ambulanze. Il Rossi guardò l orologio sulla parete: non poteva fare tardi al lavoro. Chiese di essere rischedulato sulle altre sale, ma ciò era impossibile, poiché senza una lista aggiornata dei pazienti era impossibile valutare lo stato delle code delle sale diagnostiche. L infermiera lo invitò ad aspettare il proprio turno alla diagnostica B. Dopo una altra ora, Rossi realizzò di dovere tornare al lavoro. Chiese all infermiera di 118

119 riprenotarlo, ma la infermiera rispose che avrebbe dovuto riprenotarsi attraverso il CUP. Rossi uscì, e tornò in ufficio. La settimana dopo, dopo avere ripetuto la prenotazione attraverso il CUP, Rossi, dopo un ora di attesa, rientrò nella sala diagnostica B, ormai familiare, seguì scrupolosamente le indicazioni che il tecnico radiologo (TSRM) gli rivolse, si rivestì e uscì dall ospedale. Quattro giorni dopo Rossi andò allo sportello per ritirare esami e referti. Poi sarebbe dovuto andare nuovamente dal Dr. Rapetti per avere l impegnativa per la visita specialistica, fissare un appuntamento con l ortopedico e fargli visionare le lastre. Pensando a quanto tempo avrebbe dovuto perdere per seguire questa trafila, pensò che forse la schiena non gli faceva tanto male.nel frattempo il Dr. Rapetti stava rimettendo a posto le schede paziente nel suo archivio a muro e gli capitò in mano quella del sig. Rossi: chissà se aveva risolto il suo problema? La storia del Sig, Rossi sembrava essere una storia come molte, una storia di scarso interesse. Un giornale locale fece un inchiesta sul funzionamento della assistenza; Rossi fu intervistato perché raccontasse la sua storia e le difficoltà che aveva incontrato. Il titolo della inchiesta era significativo un mese per un mal di schiena. Furono intervistati esponenti della azienda sanitaria, medici di base e medici del laboratorio. Il direttore generale della ASL, Ing. Luca Giuliani, fu dispiaciuto del clamore. Convocò il direttore di dipartimento, Dott. Minoli, il direttore amministrativo, Dott. Gerbetto, e la responsabile della funzione Sistemi Informativi, Ing. Piera Carolis, per avere un rapporto sulla lunghezza e sulla qualità del servizio. Il Dr. Carlo Minoli Il Dipartimento Immagini della azienda ospedaliera era stato costituito nel 1999 raggruppando le strutture operative di varie diagnostiche. A capo di ogni struttura operativa vi è un dirigente medico di I livello. Il direttore del Dipartimento, nominato dopo un lungo periodo di riorganizzazioni, è il Dr. Carlo Minoli. A lui spetta il compito di negoziare il budget con la Direzione Generale e di allocare tale budget fra le nove unità diagnostiche, tenendo conto delle esigenze operative e degli investimenti. Inoltre gestisce i programmi di ricerca e la formazione attraverso corsi accreditati ECM. Infine si occupa di 119

120 gestire i rapporti con alcuni centri diagnostici a capitale privato distribuiti sul territorio provinciale, che spesso richiedono consulenze per la refertazione delle immagini prodotte. Il Dr. Minoli uscì dalla sala riunioni dove aveva incontrato il Direttore Generale, il direttore amministrativo e la responsabile della funzione Sistemi Informativi. Camminando nel corridoio Minoli guardò i documenti discussi durante la riunione, tra cui l organigramma della struttura ospedaliera. La situazione non era rosea. Lo preoccupava la gestione delle emergenze, che nonostante i tentativi, non era migliorata. Anche quel giorno c era stato un incidente e sembrava che il personale fosse impreparato. Siamo in un ospedale. Le emergenze dovrebbero essere il nostro pane quotidiano. Dovremmo sapere come gestirle. pensò Minoli. Ricordò il seminario cui aveva partecipato in Francia. L ospedale Saint Denis di Parigi era all avanguardia. In presenza di un emergenza, tutte le attività successive erano rischedulate in tempo reale, tutto il personale sapeva come comportarsi e tutti i pazienti erano immediatamente informati dei cambiamenti. Il giornale non aveva torto Rossi aveva pagato le inefficienze del sistema. DIREZIONE GENERALE COORDINAMENTO STAFF Minoli ripensò alla riunione. L azienda ospedaliera era stata messa in difficoltà ma forse questo avrebbe finalmente smosso la situazione. La ventilata disponibilità di fondi regionali per la ristrutturazione di aziende ospedaliere costruite prima della Seconda Guerra Mondiale lo rendeva ottimista. L azienda aveva infatti i requisiti per accedere ai fondi 120

121 Aspettando l ascensore ripensò alla attuale planimetria dell azienda e alle molte volte in cui si era sentito rispondere che i fondi erano pochi e le priorità erano altre. Elementi Dislocazione Portineria Piano terra Filiale Bancaria Piano terra Bar Piano terra Pagamento ticket Piano terra Tribunale Diritti Malato Piano terra 6 Diagnostiche Radiologia Tradizionale Padiglione 5 1 Diagnostica di Tomografia Assiale computerizzata Padiglione 11 1 Diagnostica Ecografia Padiglione 5 1 Diagnostica risonanza Nucleare Magnetica Padiglione 9 Accettazione pazienti esterni RX + ECO Primo piano Accettazione pazienti esterni TAC + RNM Secondo Piano Tabella 1 Planimetria (mono-presidio per prestazioni/anno) La ristrutturazione avrebbe potuto fornire l occasione per una riorganizzazione generale, con un ripensamento dei processi dai punti di vista sia gestionale sia tecnologico. Minoli capiva le grandi difficoltà di un cambiamento, ma pensava che occorresse una svolta, che permettesse di superare la inerzia delle organizzazioni e di modificare le procedure consolidate. Su questo concordava con il direttore generale. Giunto al terzo piano Minoli si riscosse dai suoi pensieri. In agenda aveva un appuntamento con il responsabile della qualità, Ing. Piero Massi, con cui doveva discutere una questione importante. L azienda infatti si stava preparando all incontro di monitoraggio della certificazione UNI EN ISO 9001:2000. Il suo desiderio era di transitare a breve termine alla certificazione dell eccellenza, cioè la certificazione della Joint Commission. Scorse i fogli che aveva in mano, riesaminando i dati sulle tipologie di clienti (Tabella 3), sulle prestazioni erogate (Tabella 4), sulle procedure primarie e abilitanti (Tabella 5), sull organico dell unità di radiologia (Tabella 6). Dati numerici Posti letto 1000 (di cui 200 in day hospital) Abitanti del bacino di utenza Tabella 2 Dati generali Tipologia dei clienti paziente ricoverato vs. paziente ambulatoriale paziente in elezione vs. paziente in urgenza paziente in regime istituzionale vs. paziente in regime libero professionale Tabella 3 Tipologie dei clienti Prestazioni erogate (esami) Volumi annui Pazienti Ricoverati Pazienti Ambulatoriali In elezione In urgenza In elezione In urgenza 121

122 radiologia convenzionale RX ecografia ECO tomografia assiale computerizzata TAC risonanza nucleare magnetica RNM 980 Tabella 4 Prestazioni erogate e volumi Attività primarie prenotazione pagamento ticket + accettazione esecuzione esame + recupero dello storico refertazione preparazione documentale consegna referto Tabella 5 Attività primarie / Attività secondarie Attività secondarie (abilitanti) pianificazione & consuntivazione gestione del personale (tra cui formazione) gestione delle tecnologie gestione della qualità gestione approvvigionamenti gestione dei rifiuti Figure Compiti Numero Medico radiologo Responsabile della diagnosi e delle procedure interventistiche 6 Tecnici sanitari di radiologia medica Segretarie (personale amministrativo) Archivisti Personale IT Tabella 6 Figure professionali ed organici Responsabili produzione delle immagini e del controllo qualità TSRM Trascrizione dei referti dettati dai radiologi e che rappresentano il collegamento tra la radiologia ed il mondo esterno Responsabili della gestione dell archivio delle pellicole e delle cartelle cliniche e della loro distribuzione all interno dell ospedale Gestione, manutenzione, aggiornamento dell infrastruttura informativa In aggiunta il dott. Minoli aveva preparato delle tabelle sulle modalità di prenotazione, per pazienti ambulatoriali e ricoverati, che si differenziavano a seconda del regime di urgenza o di routine. Prestazioni Carattere Luogo e modalità di prenotazione Modulistica RX Routine Presso il CUP anche telefonicamente Presso l'accettazione della Radiologia Impegnativa del MMG Modulo aziendale RX Urgenza Presso il CUP anche telefonicamente Presso l accettazione della Radiologia Presso il DEA (pronto soccorso) Tessera Sanitaria Carta d identità ECO Routine TC - RM Routine Tabella 7 Pazienti Ambulatoriali Presso il CUP anche telefonicamente Presso l'accettazione della Radiologia Tipologia Carattere Luogo e modalità di prenotazione Modulistica Ricoverati nei reparti dell'azienda Ospedaliera Routine Urgenza Emergenza Consulenza Presso l'accettazione della Radiologia In Diagnostica presso i singoli Modulo interno Nessuno Ricoverati in regime DH-DS Routine Urgenza Emergenza Medici Presso l'accettazione della Radiologia Impegnativa del MMG Modulo aziendale Modulo interno 122

123 Ricoverati negli ospedali extra Azienda Consulenza Routine Urgenza Consulenza Tabella 8 Pazienti Ricoverati In Diagnostica presso i singoli Medici Presso l'accettazione della Radiologia In Diagnostica presso i singoli Medici Nessuno Modulo aziendale Nessuno Al termine dei suoi appunti, Minoli si soffermò sulle tabelle sui tempi di attesa, nota dolente di molte organizzazioni. Sicuramente si poteva sempre fare meglio, ma in fondo il dott. Minoli pensava che il livello di servizio ai pazienti poteva dirsi soddisfacente. Si ripromise di raccogliere i dati di settore e fare un controllo. Entrando nell ufficio dell Ing. Mass, Minoli notò la presenza del responsabile della qualità e del responsabile dell ufficio relazioni pubbliche, la Dr.ssa Amelia De Cavilli. Non si stupì: la comunicazione ai cittadini era un punto debole dell azienda. Tuttavia, Minoli non condivideva sino in fondo l orientamento al pubblico della Direzione Generale: l ospedale deve erogare qualità tecnica e non comfort e cortesia ecc: non era certo un ristorante e la cortesia non salvava gli operati al cuore. Chi vorrebbe un medico simpatico ed incompetente? Tempi di attesa per pazienti ricoverati Prestazione Tempi di esecuzione Tempi di refertazione RX <5 gg dalla richiesta 48 h ECO <4 gg 48 h TAC <5 gg dalla richiesta 96 h RM <7 gg 96 h Tabella 9 Pazienti Ricoverati Tempi di attesa per prenotati Prestazione Tempi di esecuzione Tempi di refertazione RX <15gg dalla richiesta 48 h ECO >25gg dalla richiesta 48 h TAC <35 gg dalla richiesta 96 h RM < 65gg dalla richiesta se non urgente 96 h Tabella 10 Pazienti prenotati Tempi di attesa in sala d attesa Prestazione Ricoverati Ambulatoriali Urgenze RX 1-60 min min 1-20 min ECO 1-60 min min 1-20 min TAC 1-60 min min 1-20 min RM 1-60 min min 1-20 min Tabella 11 Tempi di attesa in sala d attesa La Dr.ssa De Cavillis non perse tempo in convenevoli ed espresse le sue osservazioni. I revisori chiamati a valutare l azienda avevano espresso parere negativo sulla tracciabilità delle informazioni agli utenti. La dottoressa osservò che le numerose informazioni sulle 123

124 prestazioni servivano a soddisfare il fabbisogno informativo della Regione e non a fornire agli utenti informazioni sui servizi. Anche l utilità della Carta dei Servizi, la cui diffusione presso gli enti pubblici era stata fortemente promossa dalla Regione, era in discussione. Questa carta in realtà rappresentava solo una serie di buoni propositi. Occorreva invece identificare indicatori di prestazione significativi, di tipo quantitativo, che rispondessero ad una logica di Bilancio Sociale (in aziende private esistono schemi analoghi SLA, Service Level Agreement). Un problema rilevante, proseguì De Cavillis, è che non viene seguita una logica di servizio al paziente e alla sua famiglia. Ad esempio i questionari di valutazione per la customer satisfaction sono strutturati in modo tale da fare risultare ottimo il servizio, omettendo di chiedere che cosa l utente pensa del servizio. Che cosa è necessario fare per potere affermare che il servizio è adeguato? 2 A questo punto il Dr. Minoli intervenne: I problemi sono rilevanti; tuttavia si deve tenere presente che la nostra attività tratta richieste che ci giungono con casualità ed è complessa. Fissare parametri quantitativi per le prestazioni che eroghiamo significherebbe non riuscire a rispettarli. Non me la sento di sottoscrivere un accordo con i cittadini, garantendo prestazioni stringenti che in partenza so di non potere mantenere. L Ing. Massi concluse sottolineando le necessità del monitoraggio del clima sociale E vero che la logica dell utente è la più importante, ma non bisogna dimenticare che esiste anche una logica interna. Ad esempio non rileviamo il clima organizzativo all interno delle varie strutture. Ad esempio in radiologia le tensioni sono forti. I conflitti tra tecnici e medici sono quotidiani, le comunità professionali si scontrano non solo sui contenuti, ma anche su questioni amministrative (ferie, turnazioni, livelli di esposizioni alle radiazioni ). I dati a disposizione, sono scarsi, cartacei, confusi e contradditori. Mario Uboldi Mario Uboldi è il tecnico sanitario radiologo medico (TSRM) con maggiore esperienza. Tra pochi mesi andrà in pensione e la sua esperienza si perderà. Le prassi operative non sono codificate e i segreti del mestiere sono trasmessi informalmente, con l affiancamento quotidiano (training on the job). Uboldi pensava che i giovani fossero attenti alle tematiche 2 Si vedano a questo proposito i decreti legislativi DL 502/92 e DM 15/10/96 sulla qualità delle prestazioni sanitarie. 124

125 tecniche, ma non alle esigenze gestionali. Soprattutto non comprendono la necessità del servizio al cliente. La sanità stava cambiando ed il privato diventa sempre più abile ad approfittare delle difficoltà gestionali e di risorse. Chi era convinto che in sanità non vi fosse competizione era un ingenuo. Prima di andare in pensione Uboldi voleva lasciare un segno delle proprie capacità (non essendo laureato aveva svolto mansioni tecniche) aiutando il Dr. Minioli a migliorare le prestazioni della radiologia, preparando una serie di appunti sul funzionamento della radiologa. L azienda voleva conseguire la certificazione Joint Commission e una valutazione dei processi della radiologia sarebbe stata utile. Il flusso di lavoro include una fase pre-diagnostica, una fase diagnostica e una fase postdiagnostica. Le procedure pre-diagnostiche cambiano a seconda che il paziente sia degente o ambulatoriale. Un caso a parte sono i pazienti provenienti dal pronto soccorso. Per i ricoverati, le prestazioni radiologiche sono prenotate dai reparti dell ospedale con un apposito modulo. Il modulo deve essere compilato completamente, riportare il quesito diagnostico ed essere firmato dal medico richiedente. L unità di degenza deve anche provvedere alla eventuale preparazione del paziente. Anche per il paziente ambulatoriale l esame è richiesto da un medico; in questo caso, però, è il personale della segreteria, che, al momento della prenotazione, informa il paziente sulle modalità di preparazione all esame. Durante l accettazione, il paziente ambulatoriale riceve un modulo per il ritiro dell esame. Il radiologo ha la possibilità, se ritiene, di opporsi all esame e/o di modificare il percorso diagnostico, tramite una comunicazione all utente, che è trasmessa anche al medico richiedente. Se l esame prevede l uso di mezzi di contrasto iniettabili (come nella PET), il dipartimento ha l obbligo di fornire al paziente una informazioni preventiva completa e di richiedere il consenso informato (si usa un apposito modulo cartaceo prestampato). Se il paziente è degente, questo compito spetta al personale sanitario del reparto di degenza. Il consenso firmato del paziente è allegato nella cartella clinica del degente od è archiviato in radiologia se il paziente é ambulatoriale. All ingresso della richiesta in radiologia, il personale esecutivo (tecnico o medico) registra l attività. Il paziente è poi chiamato dal personale che controlla l identità del paziente, che 125

126 deve confermare il proprio nominativo, data di nascita ed esame cui sarà sottoposto. Le attività di prenotazione e accettazione sono state schematizzate dal sig. Uboldi nella Tabella 12e nella Tabella 13. Paziente Operazioni Il medico del reparto in Note/documenti prodotti Le richieste, cartacee, sono consegnate in accettazione con la cartella clinica da infermieri o ausiliari del reparto di provenienza INTERNO cui è ricoverato il paziente richiede l esame Quotidianamente gli esami sono assegnati tra medici e tecnici e diagnostiche; la assegnazione comparirà a video sulle stazioni RIS 3 ESTERNO PRONTO SOCCORSO Il paziente fissa l appuntamento telefonicamente, presso gli uffici del reparto o via CUP Il medico di Pronto Soccorso richiede l esame per il paziente Tabella 12 Attività di prenotazione Quotidianamente gli esami sono assegnati tra medici e tecnici e diagnostiche; la assegnazione comparirà a video sulle stazioni RIS 3 La richiesta é trasmessa via RIS alla Radiologia In Radiologia la programmazione ordinaria è modificata manualmente per inserire la nuova richiesta d urgenza ACCETTAZIONE Paziente Operazioni Note/documenti prodotti INTERNO ESTERNO PAZIENTE DI PRONTO SOCCORSO Tabella 13 Attività di accettazione Nel giorno definito in fase di prenotazione il paziente è portato in Radiologia per l esame In Radiologia il paziente è inviato alla diagnostica di riferimento secondo la tipologia dell esame Nel giorno fissato in fase di prenotazione il paziente paga il ticket ed è automaticamente registrato in Radiologia sul RIS3 In Radiologia il paziente è inviato alla diagnostica di riferimento secondo la tipologia dell esame Il paziente è portato in Radiologia per l esecuzione dell esame In Radiologia il paziente è inviato alla diagnostica di riferimento secondo la tipologia dell esame Nella cartella clinica del paziente è presente la richiesta del Reparto Il paziente è in possesso di una ricevuta di pagamento relativa all esame radiologico La fase diagnostica è più complessa; ogni intervento organizzativo dovrebbe essere concordato bottom-up. Tutti gli esami radiologici sono condotti dal personale della radiologia, in base ai protocolli clinici dell azienda ospedaliera. Per le indagini eseguite con mezzi di contrasto è sempre presente un anestesista, reperibile al pronto soccorso in caso di emergenza. I radiogrammi (immagini radiografiche) sono foto-timbrati per essere identificabili. Il fototimbro è realizzato direttamente sul supporto fotografico e riporta il nome del paziente con 3 RIS = Sistema Informativo Radiologia 126

127 la data di esecuzione dell esame. L identificazione riguarda sia il paziente sia il TSRM che esegue la prestazione. Il tecnico appone la propria sigla sul radiogramma e registra il numero delle esposizioni (radiogrammi validi e di scarto) e, negli esami di scopìa, anche i tempi. La registrazione avviene su registri cartacei che sono elaborati dal personale amministrativo a fine mese. Per le ecografie, la sigla apposta non è quella del medico radiologo,non del TSRM. Le attività esecutive dell esame sono indicate nella Tabella 14. Paziente Operazioni Note/documenti prodotti INTERNO ESTERNO PAZIENTE DI PRONTO SOCCORSO Viene svolto l esame diagnostico con relativa produzione della radiografia e stampa di etichetta con nome e cognome del paziente da RIS 3 La radiografia viene imbustata con l etichetta del nome del paziente prodotta dal RIS 3 e diretta al medico per la refertazione Tabella 14 Attività esecutive dell esame Dopo l esecuzione dell esame il paziente resta in sala di attesa fino allo sviluppo della pellicola, mentre il medico radiologo e il tecnico valutano la validità dell esame. Infatti il 10% delle immagini va rifatta, poiché la posizione e/o l esposizione non sono corrette. Il paziente ritira il referto alla data comunicata in fase di accettazione. Il referto radiologico è redatto dal medico radiologo. La firma del referto e il timbro convalidano l intero processo. I radiogrammi realizzati nei centri diagnostici privati che dispongono solo di TSRM sono trasferiti tramite fattorino, in una valigetta presso la radiologia. Dopo la refertazione, i radiogrammi sono riconsegnati ai laboratori. Spesso, questi radiogrammi hanno priorità su quelli realizzati presso la azienda, per stringenti vincoli contrattuali. Ciò porta l azienda a peggiorare i suoi tempi a vantaggio dei centri diagnostici privati, che sono scelti come benchmark dalla Regione. La consegna dei referti e dei radiogrammi avviene per i pazienti interni, da parte del personale dei reparti richiedenti. Quando, poi, il paziente sarà dimesso essi saranno archiviati presso gli Archivi Radiologici. Tali archivi occupano ampi spazi nel sotterraneo dell azienda ospedaliera. Più volte era stata avanzata la richiesta di usare tali spazi per tecnologie pesanti, quali quelle della medicina nucleare. Tuttavia ciò era stato giudicato non fattibile per via degli stringenti vincoli di legge sulla conservazione delle varie immagini diagnostiche. Ai pazienti ambulatoriali, invece, sono rilasciati i referti, firmati dal medico e i radiogrammi. Ad essi, al momento del ritiro, si richiede lo scontrino rilasciato al momento dell accettazione per rispetto della tutela della Privacy. Il ritiro del referto deve avvenire personalmente o, nel caso di impossibilità, attraverso delega scritta da parte del 127

128 paziente. Le attività post-diagnostiche sono sintetizzate nella Tabella 15 e nella Tabella 16. Paziente Operazioni Note/documenti prodotti INTERNO Sono consegnati ai medici le radiografie per la ESTERNO refertazione secondo la programmazione giornaliera / disponibilità PRONTO SOCCORSO Tabella 15 Attività di refertazione Sono consegnati ai medici gli esami per la refertazione con urgenza secondo la tipologia di richiesta del Pronto Soccorso I medici refertano direttamente su stazioni RIS 3 o registrano il referto su cassette che sono passate al personale amministrativo che le digita su stazione RIS Paziente Operazioni Note/documenti prodotti INTERNO ESTERNO PRONTO SOCCORSO Sono consegnati (in visione) il referto e la radiografia al Reparto in giornata; il paziente, dopo la dimissione, può richiedere una copia della cartella clinica che include radiografia e referto Il paziente tramite il modulo di ricevuta di pagamento si presenta per ritirare esiti degli esami Al Pronto Soccorso sono consegnati (in visione) radiografia e referto per la cartella clinica del paziente Le radiografie sono distribuite ai reparti dal personale ausiliario della Radiologia o ritirate dal personale del Reparto richiedente Dopo la dismissione del paziente la radiografia originale e il referto sono conservati su RIS e su carta Al paziente sono consegnati il referto e la radiografia dopo 3/4 giorni Presso la Radiologia il referto è conservato sia su RIS sia su carta Presso la Radiologia é conservato il referto su RIS e su carta; il paziente è in possesso del referto di dimissione e può chiedere copia della radiografia all archivio clinico Tabella 16 Attività di consegna Mentre Uboldi stava rileggendo i propri appunti, entrò in ufficio il sig. Claudio Sacchi, TSRM di turno presso la diagnostica D, che si lamentò del rapporto tra TSRM e radiologi, per la supponenza di questi ultimi. Anche quel giorno le liste dei pazienti erano state modificate per venire incontro alle esigenze dei medici radiologi, che per accontentare i colleghi di reparto non esitavano ad anticipare o posticipare sia gli esami sia la refertazione. Questi battibecchi erano frequenti. D altronde, lo stesso direttore generale aveva dichiarato che i radiologi erano una risorsa preziosa. L evoluzione tecnologica avevano evidenziato quanto fossero cruciali TSRM e radiologi competenti. Ma mentre i TSRM erano facilmente reperibili (soprattutto in Est Europa), i radiologi erano figure più rari. La stessa azienda aveva difficoltà a specializzare i radiologi sugli esami diagnostici (RX, ECO, RMN, TAC) e cercava di uniformare le competenze,di tal modo che qualunque radiologo potesse refertare su più esami. Più volte di fronte ai 128

129 valori di prestazione non entusiasmanti raccolti dal centro elaborazione dati (CED) si era addotta come motivazione la variabilità dei tempi di refertazione e l elevato numero di retake. L Ing. Piera Carolis L Ing. Piera Carolis è la responsabile del settore Sistemi Informativi da sei anni ed ha assunto questo incarico presso la funzione S.I. al termine dell attuazione del progetto RIS in sostituzione dell Ing. Ferravano che si era trasferito in un'altra città del nord Italia. Questo progetto fu realizzato in due anni (dal 1998 alla fine del 1999) e consisteva nella introduzione del nuovo Sistema Informativo di Radiologia (RIS). L Ing. Carolis iniziò il suo intervento durante la riunione con i responsabili della ASL e del Dipartimento criticando le prassi adottate durante l implementazione del progetto. Vista la centralità del ruolo del dipartimento di Radiodiagnostica il RIS doveva 'assumere una identità specifica e distinta nell'ambito dei Sistemi Informativi Ospedalieri, introdusse L Ing. Carolis, l'obiettivo a cui si puntava andava oltre la sola produzione di immagini digitali. Una presentazione Powerpoint accompagnava i commenti della responsabile dei S.I. e le prime due slide sono riportate nella figura 1 e 2. Altra importante esigenza da soddisfare era quella di avere un sistema informativo integrato e completo che facesse propri i concetti di modulare, di standard e di sistema aperto, continuò l ingegnere, ma neanche questo obbiettivo fu raggiunto, almeno per il momento. Un approccio frammentario ha caratterizzato anche le modalità seguite nell acquisto di sistemi di hardware e software: la dotazione informatica delle varie unità non è stata infatti coordinata a livello centrale, e neanche allineata con le strutture esterne, come le CUP. Il progetto RIS non era l unico progetto di informatizzazione che veniva implementato nell azienda ospedaliera in quegli anni. Infatti, furono acquistati vari PC per i reparti nell ambito della realizzazione di un HIS (Hospital Information System) e furono realizzate delle mini-reti interne per permettere la gestione delle attività amministrative e di supporto a livello dei singoli reparti. Abbiamo cercato in questi anni di promuovere un integrazione dei sistemi informativi esistenti, ma il problema principale è l esistenza di una informazione duplicata, incompleta 129

130 e spesso presente su supporto cartaceo, continuò l Ing. Carolis, questa informazione rappresenta dei dati eterogenei e spesso non allineati. L Ing. Carolis presentò a questo punto del suo intervento una relazione con una analisi dettagliata delle criticità dei sistemi informativi esistenti e completata con un elenco di proposte per poter colmare le deficienze e migliorare l esistente. Un punto evidenziato in rosso all interno del rapporto enunciava quanto segue Ci servirebbe una iniziativa volta a creare, un infrastruttura integrata sull informazione sanitaria che, eliminando gli isolati database in essere presso la nostra struttura ospedaliera, distretti sanitari, medici di base ecc., ed elimina in questo modo ogni duplicazione di dati, inutile quanto costosa. La fattibilità di questo tipo di iniziativa va analizzato in dettaglio per le sue implicazioni anche esterne alla nostra Azienda. L Ing. Luca Giuliani, leggendo questo appunto fece notare all intervenente che esisteva un reale problema riguardo ai dati circolanti in questi sistemi e in particolare durante le operazioni di refertazione radiologiche e analisi mediche. Stavo proprio arrivando a questo punto importantissimo che riguarda il problema della sicurezza delle reti e della loro ownership, e con questo termine intendo la titolarità e la responsabilità legale della rete rilevò subito l Ing. Carolis, mettere in comunicazione i vari operatori sanitari e le varie micro-strutture e strutture, non significa rendere l informazione pubblica ed accessibile a tutti. Bisognerà adottare una strategia finalizzata allo scambio di documenti amministrativi in estrema sicurezza al fine di garantire completa riservatezza e affidabilità alle informazioni scambiate. Evoluzione della Radiologia Informatizzata L'informatica è diventata parte integrante dei dipartimenti di Radiologia: i progressi tecnologici hanno infatti permesso lo sviluppo di metodiche basate sull'impiego del computer (Angiografia digitale, TC, radiografia digitale, RM) che hanno rivoluzionato il volto della diagnostica per immagini. Dalle prime applicazioni sperimentali del computer in ambito radiologico degli anni 60 al prepotente sviluppo dell'angiografia digitale e della TC negli anni `80. La rivoluzione più evidente che, le tecniche basate su computer hanno introdotto in quegli anni, riguarda le immagini prodotte. Esse diventano generalmente di sezione (TC, RM), diverse ed innovative rispetto a quelle tradizionali, aprendo al radiologo possibilità diagnostiche fino ad allora difficilmente realizzabili. E' comprensibile quindi l'enorme interesse suscitato 130

131 dalle nuove possibilità e giustificabile anche l'entusiasmo che talvolta ha accolto la continua evoluzione delle tecniche computerizzate di imaging. Il settore degli esami tradizionalmente ottenuti in modo analogico con il classico abbinamento schermo-pellicola non poteva non essere interessato dalle ventate innovative. Il grande successo delle tecniche digitali ha infatti spinto la ricerca tecnologica all'obiettivo di digitalizzare tutte le metodiche dominate fino a quel momento dalla radiologia convenzionale. La loro evoluzione in questo ambito è stata più lenta per la necessità di competere con un sistema già affermato ed ottimizzato in un secolo di radiologia. La tradizionale pellicola radiografica costituisce infatti un supporto di immagine estremamente efficace e versatile poiché agisce contemporaneamente da sistema di rilevazione, di registrazione, di display e di archiviazione, possiede una elevata risoluzione spaziale e di contrasto ed è inoltre un sistema a basso costo. La ricerca tecnologica non poteva però fermarsi per "rispetto" del glorioso sistema schermo-pellicola; Continuando con la sua presentazione PPT, l ingegnere iniziò a descrivere la architettura applicativa impiegata dai vari attori presenti nel processo analizzato. Le applicazioni che sono utilizzate sono di diversi tipi ed eseguite su macchine con sistemi operativi diversi, affermò Carolis. I moduli disponibili localmente, oltre al RIS sono il software gestionale della accettazione e quello dei pagamenti dei ticket e esternamente il software di gestione delle prenotazioni del CUP, se vogliamo considerare un semplice foglio excel come un modulo applicativo. Per quanto riguarda i dati gestiti nel nostro sistema informativo HIS nel Dipartimento di Radiologia ci interessano i dati presenti nel Database della anagrafica degli assistiti, e in quello della anagrafica dei medici. La cartella clinica del paziente è ancora cartacea e quindi presenta informazioni difficilmente gestibili concluse Carolis. A questo punto della riunione, l Ing. Carolis, richiamò l attenzione dei presenti riguardo al sistema che aveva visto durante una visita all ospedale S. Anna di Ferrara. Il loro nuovo sistema è completamente digitale, iniziò la responsabile dei S.I., In una prima fase hanno attivato un percorso digitale (archiviazione, refertazione e documentazione) per le 131

132 immagini TC ed RM in 4 reparti pilota (Medicina d'urgenza, Oncologia, Ortopedia e Neurologia) proponendo, su una scala ridotta, tutti gli aspetti di una gestione totalmente digitale delle informazioni radiografiche. Con il trasferimento della Radiologia in un nuovo stabile che stavano costruendo, si dovrebbe attivare un percorso completamente digitale per tutti i reparti ed anche per le immagini di radiografia tradizionale acquisite mediante sistemi DR e CR. Il Direttore del dipartimento intervenne dichiarando: Credo che la promessa di un Ospedale Virtuale si scontrerà con le difficoltà della gestione di cambiamenti sul workflow e sulle competenze del personale, bisognerà tenere conto anche di questi fattori prima di proporre una qualsiasi iniziativa. Volevo anche sollevare il problema degli archivi, ne siamo sommersi e non si riescono più a gestire in modo efficiente, aggiunse il Direttore. Abbiamo pensato di introdurre degli archivi sotto forma di juke-box di dischi DVD, rispose l Ing. Carolis, ma questo presuppone l accesso ad una memoria legale a lungo termine e non permetterebbe un rapido recupero e visualizzazione degli esami dalle stazioni di refertazione. Sapendo che statisticamente l'accesso a immagini acquisite da oltre un anno si è dimostrato relativamente raro, bisognerà identificare nuove tecnologie aggiuntive da adottare. La ringrazio per l esposizione e prima di concludere la riunione, aggiunse il Dott. Minoli, vorrei leggervi una considerazione pubblicata sulle ultime riforme attuate nel sistema sanitario tedesco e che afferma che - la massiccia introduzione di Information Technology nel sistema informativo sembra aver compensato le inefficienze della sanità ma fortissima è la tentazione di rinunciare all information management per dare la priorità alle tecnologie e alle loro possibili applicazioni in medicina e sanità, finendo per coprire gli operatori sanitari con una valanga di informazioni non necessarie, indesiderate e ingestibili-. Non vorrei che anche qui succedesse! 132

133 Figura 1: Descrizione del flusso di elaborazione delle immagini nel processo Ambulatori o Agende Referti Richieste Referti Pronto soccorso Prenotazione Repart o Programmazione sale Urgenze Conferma liste Allarmi Richieste Sistema Informativo Radiologia (RIS) Conferme Agende Lista di sala Urgenze Refertazione Conferma esecuzione Equipe Fuori lista Sala Richieste Referti Sale operatorie Cartella clinica del paziente Figura 2 Stuazione attuale del sistema informativo 133