UNIVERSITÀ DEGLI STUDI DI GENOVA

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "UNIVERSITÀ DEGLI STUDI DI GENOVA"

Transcript

1 UNIVERSITÀ DEGLI STUDI DI GENOVA FACOLTÀ DI INGEGNERIA TESI DI LAUREA IN INGEGNERIA ELETTRONICA Performance measurement system per la gestione di eventi industriali complessi Relatore accademico Dott. Ing. Marco Baglietto Correlatore accademico Dott. Ing. Flavio Tonelli Relatore aziendale Dott. Marco Genta Candidato Adriano Moretti 20/05/2011 Anno accademico

2 Performance measurement system for complex industrial events management Abstract The here proposed thesis dealt with the problem of measuring key performance indicators in industrial plants. The absence of affordable and widespread tools to achieve this goal led to the implementation of a software experimental prototype for measuring the "Overall Equipment Effectiveness" performance metric. Such experimental prototype has the capability to operate on data coming from production lines and the capability of carrying comparison with evaluation rules and emitting possible alerts. The prototype underwent a validation phase highlighting its correct behaviour. II

3 Alla Commissione di Laurea e di Diploma Alla Commissione Tirocini e Tesi Sottopongo la tesi redatta dallo studente Adriano Moretti dal titolo Performance measurement system per la gestione di eventi industriali complessi. Ho esaminato, nella forma e nel contenuto, la versione finale di questo elaborato scritto, e propongo che la tesi sia valutata positivamente assegnando i corrispondenti crediti formativi. Il Relatore Accademico Prof. Marco Baglietto III

4 Ringraziamenti Al Prof. Baglietto e al Prof. Tonelli, che mi hanno risposto sempre con i consigli giusti alle mie domande e perplessità. Al Dott. Marco Genta e ai ragazzi del laboratorio di programmazione di Atomos, che mi hanno avuto la pazienza di insegnarmi un linguaggio di programmazione nuovo e i trucchi del mestiere. Alla mia famiglia, che mi ha supportato e sopportato durante il corso di studi e mi ha dato la possibilità di giungere fino a questo punto. Dedico questa tesi a mio nonno Giacomo IV

5 If you can not measure it, you can not improve it. Lord Kelvin V

6 Simboli ed abbreviazioni in ambito informatico ed elettronico API Application Program Interface CPU Central processing unit CSS Cascade Style Sheet DB DataBase DCS Distributed Control System DCS Distributed Control System EEPROM Electrically Erasable Read-Only Memory HTML Hypertext Markup Language IDE Integrated Development Environment IP Internet Protocol IT Information Technology LAN Local Area Network OLAP On Line Analytical Processing OLTP On Line Transaction Processing PLC Programmable Logic Controller RAM Random Access Memory ROM Read-Only Memory RTU Remote Terminal Unit SCADA Supervisory Control and Data Acquisition SQL Standard Query Language WAN Wide Area Network Wi-Fi "Wireless Fidelity" XML extensible Markup Language VI

7 Simboli ed abbreviazioni in ambito produttivo e industriale BAM BI BPM DMAIC E&AM EFQM ERP KPI MES OEE PM(s) RTE SC Business Activity Monitoring Business Intelligence Business Process Management Define, Measure, Analyze, Improve, Control Event Management and Alerting European Foundation for Quality Management Enterprise Resource Planning Key Performance Indicator Manufacturing Execution System Overall Equipment Effectiveness Performance Measure(s) Real Time Enterprise Supply Chain VII

8 Prefazione Il lavoro svolto per questa tesi è correlato al settore dell'automazione industriale, in particolare si colloca nell'ambito della misura e della valutazione di prestazione dei processi produttivi. È un compito che tocca le discipline diverse, dall'elettronica per i sensori, gli attuatori e il trasferimento dei dati, alla gestione dei processi e delle informazioni, passando per l'informatica che ha permesso di tradurre le informazioni nascoste nei dati in resoconti comprensibili. Lo stretto legame tra tecnologia informatica e processi aziendali non è più una novità: i calcolatori consentono sempre maggiori funzionalità e i progetti di centralizzazione delle informazioni sono sempre più consistenti. Sono nati nuovi strumenti, sotto il nome di Business Intelligence, con lo scopo di integrare le informazioni provenienti dalle vari componenti che costituiscono un'azienda, per ottenere una visione d'insieme più ampia e per raggiungere un'eccellenza operazionale. Non sempre è facile ottenere una perfetta integrazione tra i sistemi di ogni livello, ma le soluzioni di Business Intelligence sono in fase di costante sviluppo ed evoluzione per fare di un'impresa tradizionale, un'impresa in cui ogni sua parte dialoga con le altre in tempo reale. Ottenere misure corrette, precise e velocemente permette un'individuazione delle risorse con performance non adeguata alle richieste di produzione, individuazione seguita da azioni di controllo volte a correggere i fattori con impatto negativo sulla performance stessa. VIII

9 Indice generale 1 Monitoraggio e controllo di sistemi industriali complessi Il problema della definizione e utilizzo di indicatori di performance per il controllo di sistemi industriali complessi Misura della performance Misure individuali di performance e sistema di misura come entità Interazione tra ambiente e sistema di misura della performance Metodologie per lo sviluppo di misure in un particolare ambiente Misurazione della performance di un sistema produttivo Manufacturing Execution System e misura della performance Strumenti e tecnologie a supporto Soluzioni esistenti e fabbisogni emergenti Stato dell'arte Vantaggi e problemi dell'estrazione e confronto di dati da fonti eterogenee Soluzione per un caso reale Origine dei dati trattati Architettura del sistema Programmable Logic Control L'acquisizione dei dati Definizione di un modello semplificato Tecnologie IT a supporto della soluzione Data Warehouse Data Mart Extract Transform & Load Event & Alert Management Strumenti Ambiente di sviluppo Delphi Database relazionale Oracle File di configurazione e supporto...33 IX

10 3 Realizzazione del prototipo sperimentale Metodo di sviluppo Descrizione generale e schema a blocchi Descrizione dei moduli software sviluppati Anagrafica indicatori Modulo E.T.L Modulo gestione eventi e notifiche Il database relazionale Verifica e validazione del prototipo sperimentale Ambiente e condizioni di verifica Fase di test funzionale Calcolo dell'overall Equipment Effectiveness Limiti e problemi Conclusioni e sviluppi futuri Considerazioni Possibili miglioramenti e sviluppi futuri...80 X

11 1 Monitoraggio e controllo di sistemi industriali complessi 1.1 Il problema della definizione e utilizzo di indicatori di performance per il controllo di sistemi industriali complessi Le misurazioni sono la base di ogni tentativo di progredire perché offrono un idea chiara dello stato raggiunto e cosa parimenti importante, indicano la direzione verso la quale ci si sta muovendo. Sono proprio le misurazioni, dunque, che possono guidare gradualmente verso il raggiungimento degli obiettivi che ci è prefissati di raggiungere. Per trarre un reale vantaggio dal processo di misurazione, però, bisogna capire bene quali sono le caratteristiche giuste da misurare e le motivazioni che stanno alla base di questa raccolta di dati. La misurazione delle performance delle attività e dei processi aziendali richiede la definizione di un sistema di indicatori che permetta di individuare le prestazioni critiche dei processi aziendali e sia orientato al controllo operativo. La successiva valutazione delle misure ottenute tramite il sistema di indicatori consente di effettuare un'analisi del divario tra obbiettivi e risultati e in base a questa porre in atto eventuali azioni correttive. Tale retroazione è l'attuazione di un controllo volto migliorare, cioè ad eliminare o ridurre gli elementi penalizzanti dei processi al di sotto degli obbiettivi. Questa tesi si concentra in particolare sul processo di misurazione e valutazione attraverso l'uso indicatori chiave di performance di un sistema produttivo industriale automatizzato raccolti tramite processi informatici. 1

12 1.1.1 Misura della performance La misura della performance è un argomento spesso discusso ma raramente definito chiaramente. Letteralmente è il processo di quantificare l'azione, dove la misura è il processo di quantificazione mentre l'azione è ciò che determina la performance. Secondo la prospettiva del marketing, le organizzazioni raggiungono i loro obiettivi, ovvero hanno una buona performance, se riescono a soddisfare i propri clienti con maggiore efficienza ed efficacia rispetto ai loro concorrenti [1]. I termini efficienza ed efficacia in questo contesto sono utilizzati con precisione. Efficacia si riferisce al grado con il quale vengono soddisfatte le richieste dei clienti, mentre efficienza è una misura di come siano utilizzate economicamente le risorse dell'azienda fornendo un livello stabilito di soddisfazione dei clienti. Ciò è una questione importante perché non solo definisce le due dimensioni fondamentali della performance, ma evidenzia inoltre che possono sussistere sia fattori esterni (clientela, territorio), sia interni (processi di produzione, innovazioni) per perseguire specifici percorsi d'azione [2]. Si prenda a titolo di esempio una delle dimensioni della performance correlata alla qualità, l'affidabilità del prodotto. In termini di efficacia, raggiungere un livello superiore di affidabilità del prodotto, può condurre a una maggiore soddisfazione della clientela. In termini di efficienza, può ridurre i costi sostenuti dall'azienda a causa di un calo dei guasti e delle richieste di sostituzione in garanzia. Di conseguenza il livello di performance che un'azienda consegue è una funzione dell'efficienza e dell'efficacia delle azioni che intraprende. Quindi è possibile definire la misurazione della performance come il processo di identificare l'efficienza e l'efficacia di un'azione una misura di performance come metrica utilizzata per quantificare l'efficienza e/o l'efficacia di un'azione un sistema di misura della performance come un insieme di metriche utilizzate per quantificare sia l'efficienza sia l'efficacia delle azioni [3]. 2

13 Kennerly e Neely affermano che un sistema di misurazione della performance è costituito da tre parti [4]: le misure individuali che quantificano l'efficienza e l'efficacia delle azioni un insieme di misure combinate per valutare globalmente la performance di un'organizzazione un'infrastruttura di supporto che permetta di acquisire, confrontare, ordinare, analizzare, interpretare e diffondere i dati I Key Performance Indicators (KPI) aiutano a definire e misurare i progressi compiuti per raggiungere gli obiettivi della propria organizzazione. Dopo che l'azienda ha analizzato la sua missione, identificato tutti i suoi concorrenti e definito gli obiettivi, essa necessita di un modo per misurare il raggiungimento di tali obiettivi. I KPI sono proprio tali misure. Un'organizzazione sceglie un insieme ridotto di misure chiave con le quali intende monitorare i progressi del proprio operato. I singoli stabilimenti e reparti hanno spesso diverse misure aggiuntive che forniscono un'analisi più dettagliata dei fattori che influenzano la produzione ai manager, ai supervisori o agli operatori. Troppe misure possono essere fonte di confusione e possono oscurare la direzione strategica dell'azienda. Devono essere scelte un numero sufficientemente piccolo di misure in modo che le persone possano capirle e usarle efficacemente Misure individuali di performance e sistema di misura come entità Leong, Snyder e Ward, riguardo la letteratura sulla strategia della produzione, sostengono che sia ampiamente accettato che i processi manifatturieri, e di conseguenza le dimensioni chiave della performance della produzione, possano essere definiti in termini di qualità, tempo, affidabilità, costo e flessibilità [5]. Nonostante tale affermazione, uno dei problemi nella letteratura sulla misura della performance è la diversità delle prospettive, cioè ciascuno dei singoli autori si sono soffermati maggiormente su aspetti diversi della progettazione di un sistema di misura 3

14 della performance. Ad esempio gli analisti e gli studiosi del comportamento dell'organizzazione hanno studiato più a fondo il fondamento logico sottostante l'uso della misura della performance rispetto alla comunità della produzione e gestione delle operazioni. Poiché in questo contesto non è conveniente analizzare a fondo tutte le possibili misure della performance di produzione, vengono di seguito presentate le definizioni delle cinque dimensioni chiave precedentemente menzionate. Tradizionalmente la qualità è stata definita in termini di conformità alle specifiche e di conseguenza le misure basate sulla qualità si focalizzano su problemi come il numero di difetti prodotti e il costo della qualità [6]. Il tempo è stato descritto sia come origine di vantaggio competitivo, sia come misura fondamentale della performance produttiva [7][8]. Assume un ruolo fondamentale nella filosofia della produzione Just in Time (JIT) [9] e della Optimized Production Technology [10]. Il costo riguarda l'economicità della produzione di beni o servizi. Tradizionalmente si parla di Return of Interests (ROI) cioè di ritorno di interessi [11], Activity-Based Costing, ovvero l'effettiva incidenza dei costi associati a ciascun prodotto e ciascun servizio venduto [12] [13] e infine di produttività, definita come rapporto tra le uscite e le entrate [14]. L'affidabilità viene definita come la percentuale di ordini corretti nei tempi previsti Le dimensioni della flessibilità sono identificate con l'estensione, cioè quanto è possibile cambiare il sistema di produzione e la risposta, ovvero quanto rapidamente ed economicamente è possibile cambiarlo [15]. Nella letteratura manifatturiera è spesso discusso il fatto che le misure di prestazione debbano derivare dalle scelte strategiche, ovvero esse debbano essere scelte per rafforzare l'importanza di certe variabili strategiche. Sebbene ciò non sembri accadere sempre nella realtà [16], il legame esistente tra performance e strategia è stato esplorato estensivamente nella letteratura delle strategie di business. Molti dei primi analisti, quali Andrews e Ansoff, sostennero che strategia e pianificazione 4

15 fossero sinonimi. In realtà le strategie hanno una natura molto più complessa perché evolvono via via che le decisioni vengono prese e il percorso delle azioni viene perseguito [17]. Il punto fondamentale è la consistenza, tra le decisioni e le azioni, perché una strategia viene realizzata soltanto una volta prese le decisioni e perseguiti i percorsi d'azione La misura della performance e i test per la valutazione e miglioramento di attività e processi aziendali sono diventati aspetti rilevanti a partire dagli anni '90 Determinare il migliore modo per valutare la performance aziendale è un problema molto complesso a causa delle diversità dei criteri e delle dimensioni della performance che devono essere considerate. Alcuni modelli di performance presentati nella letteratura sostengono l'introduzione di un numero selezionato di aree chiavi di performance al fine di ottenere una visione olistica valida dell'azienda. I framework esistenti per la misura della performance mostrano un numero di caratteristiche chiave che sono di supporto all'azienda nell'individuazione di un appropriato insieme di misure per valutare la proprie prestazioni. [18]. Il lavoro di Kaplan e Norton, la Balanced Scorecard pone l'enfasi sul fatto che l'insieme delle misure deve fornire un quadro bilanciato dell'azienda secondo quattro prospettive: prospettiva finanziaria (gli azionisti), prospettiva del consumatore, prospettiva interna dell'impresa (i processi) e prospettiva di innovazione [19]. Esso è il framework più conosciuto. Altri framework simili ma meno conosciuti sono la Performance Measure Matrix di Keegan [20], che pone in esame misure di performance interne/esterne e di costo/non-costo. Nel modello EFQM l'azienda viene analizzata in base a molti criteri, poi raggruppati in nove criteri principali, ciascuno con un proprio peso che concorre alla valutazione finale dell'azienda. I criteri di distinzione sono basati su due aree. Fattori abilitanti, cioè azioni intraprese per raggiungere buoni risultati: Leadership, Gestione del personale, Politiche e strategie, Gestione delle risorse, Processi. Risultati cioè cosa produce l'azienda: Soddisfazione del personale, Soddisfazione del cliente, Impatto sulla società, Risultati di business. 5

16 Il modello EFQM che viene indicato dalla letteratura come il modello che fornisce la più ampia indicazione sulle prestazioni da misurare [21]. Altro framework è il Performance Prism, sviluppato in cooperrazione tra il Centre for Business Performance at Cranfield School ed il Process Excellence Core Capability Group of Andersen Consulting. Esso è composto da 5 prospettive tra loro interrelate (Stakeholder Satisfaction, Stakeholder Contribution, Strategies, Processes, Capabilities). Altri autori propongono ulteriori modelli, quali l'insieme di linee guida di Globerson [22], i Seven Principles di Maskell [23] e una metodologia strutturata per la revisione di Dixon [24]. Quello che emerge come punto comune tra tutti i framework/modelli è la necessità delle aziende di implementare un insieme di misure di prestazioni che sia multidimensionale. Questo riflette il bisogno di misurare tutte le aree della performance che siano rilevanti per il successo dell'azienda. Nonostante l'interesse accademico verso sistemi di controllo strategico, c'è una ricerca sul campo scarsamente sviluppata e studi effettuati su 200 industrie britanniche hanno evidenziato che fino a pochi anni fa solamente 11% ne fossero dotate [25]. 1.2 Interazione tra ambiente e sistema di misura della performance Metodologie per lo sviluppo di misure in un particolare ambiente Le misure possono trovare applicazione in un'azienda per sviluppare, mantenere e migliorare sia gli aspetti strategici sia quelli operativi. Ciò accade per aziende che vogliono utilizzare le informazioni per supportare lo sviluppo di un nuovo sistema di gestione o mantenere e migliorarne uno già esistente. Secondo quanto affermato da Triantis esistono un numero di principi di misurazione che forniscono una guida nella fase di sviluppo di un sistema informativo di qualità di un' azienda [26]. In primo luogo la misurazione non è praticata invano, ma con l'intento di facilitare il 6

17 miglioramento dei processi e migliorare la capacità dell'azienda di mettere in pratica una gestione di qualità totale. In secondo luogo le misure dovrebbero indicare i risultati della qualità di gestione. Il miglioramento della qualità può essere successivamente visto come raggiunto attraverso miglioramenti dei processi (riduzione della variabilità) o attraverso il potenziamento della capacità aziendale di affinare la qualità delle attività di gestione. Molte aziende discutono, analizzano, esaminano, studiano e valutano errori, guasti, difetti e problemi ed esse concordano per la maggior parte nel credere che uno dei metodi più efficienti per migliorare la qualità e la produttività sia eliminare gli errori al momento noti in modo da assicurare che essi non si verifichino nuovamente. Ciò avviene migliorando la sottostante produzione e processi di gestione che hanno generato gli errori in prima istanza. Così in questo modo gli errori sono resi pubblici indicando le misure rilevanti. Per quanto riguarda le misure in sé è spesso sostenuto che sia importante iniziare con un piccolo insieme che possa essere facilmente utilizzato e che abbia le seguenti caratteristiche : ben definito pratico quantificabile i dati da cui provengono le misure siano facilmente accessibili conveniente le misure devono essere facilmente comprese le misure siano appropriate per un sistema di raccolta dati automatizzato È importante motivare l'utenza dell'utilità delle misure, evidenziando come l'accesso a un sistema informativo di qualità abbia un impatto positivo sull'intera organizzazione. Inoltre il processo di misura deve essere visto in una prospettiva di continuo progresso che richiede regolari revisioni. Tale continuo sviluppo implica la rimozione di alcune delle misure iniziali; molte organizzazioni conducono test pilota sui propri sistemi di misura, sapendo che alcune parti supereranno lo scrutinio ed altre avranno necessità di essere 7

18 corrette. Così, questi programmi di misurazione pilota possono aiutare le organizzazioni a imparare come cambiare e identificare le misure che non hanno pregio di essere inserite nel sistema. È da tenere presente che le misurazioni e i processi di miglioramento richiedono tempo, diversi anni, e devono essere continuamente rafforzati affinché possano essere sostenuti e possano svilupparsi. Tale approccio utilizza una metodologia strutturata, progettata per essere utilizzata in molteplici contesti e che ben sia adatta alle industrie di produzione. La progettazione di un framework per misurazione della performance di sistemi complessi richiede che in primo luogo si indichino un numero di richieste/necessità di misurazione. Il processo inizia con una dettagliata analisi del sistema che cattura i meccanismi di controllo e la struttura del flusso di informazioni. Tale compito risulta difficile a priori, dal momento che le misure stesse sono sempre specifiche per un'azienda e devono quindi essere sviluppate individualmente con grande livello di dettaglio e accuratezza. La selezione di misure rappresenta uno strumento importante per una efficiente ed efficace definizione ed una realizzazione pratica. I passi essenziali per progettare un'appropriata misura di performance possono essere ricondotte ai seguenti quattro punti: Definizione e sviluppo di misure generiche. Determinare cosa deve essere misurato al fine di ottenere una visione complessiva del grado di buon funzionamento del sistema. Rifinire le misure generiche secondo uno specifico ambiente di lavoro. Evidenziare ogni misura e definirla all'interno del contesto del particolare ambiente. Aggiungere misure addizionali che non siano derivate dalla lista delle misure generiche. Ciascuna di esse deve essere pertinente all'ambito lavorativo e non deve essere già inclusa nella lista generica. Eliminare le misure generiche che non si adattano allo specifico ambito selezionato. vengono eliminate le misure nella lista generica che non sono adatte o non sono necessarie nella lista specifica. 8

19 Stakeholders Needs and Requirements Agree Business Objectives Design Appropriate PM Test and agree the set of measures Implement and review Define and develop generic measures Tailor generic measure to a specific environment Add measures not derived from generic ones Delete measures from generic list not applying to work environment Illustrazione 1.1: Metodologia per sviluppare misure in un particolare ambiente Adattamento da "A Structured Methodology for Developing Performance Measures in any Environment" Applicando la metodologia illustrata si ottiene un insieme di misure che sono di natura quantitativa e qualitativa. Appropriate unità di misura devono essere applicate alle prime e scale significative per le seconde Misurazione della performance di un sistema produttivo Un sistema di produzione può essere definito come un insieme di uomini, macchine, attrezzature ed organizzazione legati da un flusso comune di materiali e di informazioni finalizzato alla trasformazione di materiale grezzo in prodotti finiti. Identificare le prospettive chiave di performance è importante, ma tale aspetto da solo non è sufficiente a fornire le informazioni alla dirigenza per incrementare la performance. Kaydos [27] identifica le variabili che devono essere misurate per monitorare appropriatamente un processo produttivo, sia che si tratti di un reparto, di una persona o di un processo fisico : Resource inputs sono identificate con denaro, forza lavoro e materiali utilizzati per ottenere il prodotto finito. 9

20 Work inputs sono le richieste inviate al sistema di produzione. Enviromental Factors sono forze o condizioni esterne in grado di influenzare la performance del sistema. Quality inputs sono misure della qualità del lavoro in entrata (misure effettuate su semilavorati o parti in ingresso). Operational Variance rappresenta qualsiasi deviazione dalle condizioni ideali alle quali il processo di produzione dovrebbe attenersi. Product outputs sono prodotti o servizi utili forniti. Productivity è il rapporto tra ingressi ed uscite, come già discusso nel paragrafo Waste ovvero gli scarti; sono presenti nella maggior parte dei processi. Sebbene generalmente si pensi agli scarti in termini di materiali, ogni risorsa che non sia utilizzata in modo tale da produrre uscita è da considerarsi come scarto. La maggior parte delle industrie produce un eccesso di scarti senza esserne coscienti. Quality outputs misurano il grado di bontà dei beni o servizi prodotti e la conformità alle specifiche. Variance outputs sono una tipologia speciale di misura di qualità. Performance, behavior, diagnostic possono essere distinti come segue. Le misure di performance sono indicatori di livello superiore di quanto il sistema di produzione operi bene o male. Le misure di comportamento sono fattori di secondo livello che mostrano l'interazione tra le maggiori componenti del sistema di produzione. Le misure diagnostiche sono utilizzate per isolare i problemi al loro livello impugnabile. Nel mondo reale una determinata misura può essere etichettata in tutti e tre i modi allo stesso tempo; la questione non è inserire ogni misura in una classe o un'altra ma ragionare su tali scopi quando si decide cosa deve essere misurato. Constraints. Possono essere fisici, come limiti di capacità, o concettuali, come il tempo massimo di evasione di un ordine. Misurare la corretta variabile in un sistema di produzione è la prima condizione per un 10

21 sistema di misura della performance efficace, ma non è sufficiente. Per essere efficiente deve anche soddisfare i requisiti di validità, completezza e sufficiente dettaglio. Validità: le misure di performance devono essere valide; esse devono rilevare ciò che realmente importa e devono essere comprese dagli utenti. Completezza: le misure di produttività e qualità devono essere progettate per evitare azioni sbagliate e parimenti spingere a compiere quelle corrette. La misura deve essere chiusa nel senso che comprenda ogni aspetto di equilibrio dell'azione che deve essere compiuta. Sufficiente dettaglio: nella teoria dell'informazione esiste il concetto di varietà,che può essere definito come i modi di risposta di un'entità. Al crescere della varietà di un sistema, aumenta il numero di informazioni necessarie a descrivere il suo comportamento Manufacturing Execution System e misura della performance Il quadro teorico fino qui esposto trova la sua concreta applicazione nell'ambito dell'automazione industriale, per risolvere il problema della valutazione della performance di un sistema produttivo attraverso una serie di Indicatori Chiave di Prestazione, funzionali all'analisi del gap tra obiettivi previsti e risultati conseguiti. A tale analisi seguono azioni correttive per minimizzare la differenza evidenziata e nuove misure vengono effettuate. Illustrazione 1.2: Modello DMAIC 11

22 Ogni Catena di Distribuzione (Supply Chain) rappresenta un sistema complesso di processi interdipendenti. Partendo da questo assunto, gli studiosi ed i professionisti hanno implementato un insieme generale di sistemi di pianificazione e controllo per la gestione dei processi. Un sistema di pianificazione permette il coordinamento dei processi ed il mantenimento dell efficienza produttiva, mentre un sistema di controllo esecutivo permette la valutazione della capacità di realizzazione del piano preventivato e di collezione delle informazioni relative alle performance registrate. Proprio su queste ultime informazioni, fornite dal Manufactury Execution System, si focalizza l'interesse di questo lavoro. Nei capitoli 2 e 3 verrà discusso come questo insieme di informazioni raccolte automaticamente possano essere filtrate veicolate ai sistemi di pianificazione gestionale di livello superiore solo quando esse risultino rilevanti ai fini delle decisioni strategiche. Con Manufacturing Execution System (MES) si indica un sistema informatizzato che ha la principale funzione di gestire e controllare la funzione produttiva di un'azienda. La gestione coinvolge il dispaccio degli ordini, gli avanzamenti in quantità e tempo, il versamento a magazzino, nonché il collegamento diretto ai macchinari per dedurre informazioni utili ad integrare l'esecuzione della produzione come a produrre informazioni per il controllo della produzione stessa. Il Manufacturing Execution System si colloca al livello 3 dei 5 definiti dallo standard internazionale ISA-95, basati sul modello Purdue Reference Model [28]: 12

23 Illustrazione 1.3: Standard ISA Adattamento da Industrial Performance Measurementand Management: an internal operational perspective focused on efficiency improvement,tonelli F., July 2009 Livello 0: dispositivi fisici. Livello 1: strumentazione, misurazione e stato dei dispositivi. Livello 2: automazione, gestione delle risorse e acquisizione dei dati di processo. Livello 3: gestione delle operazioni, esecuzione del flusso, e gestione documentale. Livello 4: gestione delle iniziative basate sulle transazioni (ERP). Il Manufacturing Execution System agisce come middleware tra i livelli ai quali operano i sistemi SCADA e DCS e quello superiore della pianificazione. I sistemi SCADA e DCS verranno esaminati nel paragrafo

24 2 Strumenti e tecnologie a supporto 2.1 Soluzioni esistenti e fabbisogni emergenti Stato dell'arte Nel paragrafo è stato accennato alla necessità di selezionare dall'insieme di informazioni raccolte automaticamente dal MES solo quelle rilevanti ai fini dell'enterprise Resource Planning (ERP); questo capitolo riprende e approfondisce la problematica. I soli sistemi MES non hanno la capacità di generare informazioni direttamente utilizzabili dall'erp. Esiste un divario tra i dati relativi alle linee di produzione e le informazioni di pianificazione ad alto livello. A causa di ciò sono stati sviluppati e tutt'ora sono in costante fase di studio e sviluppo diversi strumenti di analisi per la Business Intelligence (BI) ovvero strumenti di supporto alle decisioni che implementano logiche ad hoc per la realtà in cui sono inseriti [29][30]. La Business Intelligence può essere applicata ai seguenti obiettivi: 1. Misurazione: programmi per la creazione di gerarchie di metriche della performance e loro valutazione rispetto a termini di confronto; questo approccio prende il nome di Business Performance Management. 2. Analisi: programmi che costruiscono insiemi di dati su cui effettuare operazioni di Datamining, analisi statistiche e predittive, modellazione predittiva. 3. Reporting: programmi in grado di creare un'infrastruttura software per la rendicontazione strategica 4. Collaborazione: programmi di condivisione tra aree differenti e lavoro collaborativo basato sullo scambio di dati 5. Gestione della conoscenza: programmi per identificare, creare, rappresentare distribuire e mettere in pratica esperienze proprie della Business Intelligence. 14

25 In relazione al punto 1, che è quello di rilievo ai fini di questo lavoro, si può puntualizzare che Business Process Management è un approccio olistico di gestione focalizzato sull'allineamento di ogni aspetto dell'azienda verso le richieste del cliente. Promuove l'efficacia e l'efficienza e propugna l'innovazione, la flessibilità e l'integrazione tecnologica. Allo stato attuale dell'arte, le suite di programmi in grado di realizzare tale approccio olistico sono poche e costose. Multinazionali del calibro di Oracle, IBM, Siemens, SAP, Microsoft hanno sviluppato e continuano a sviluppare. Per trasformare la propria impresa in una Real Time Enterprise (RTE) è necessaria una soluzione di Business Intelligence che fornisca l'accesso completo ai dati, incorpori dati storici ed attuali quando richiesti. Avere accesso completo ad ogni singola informazione è solo la base di partenza; la Business Intelligence aggiunge proprio l'intelligenza per estrarre informazioni significative e tendenze emergenti dall'unione delle singole parti formanti il sistema imprenditoriale, che altrimenti resterebbero sepolte in Gigabyte di dati Vantaggi e problemi dell'estrazione e confronto di dati da fonti eterogenee L'applicazione della Business Intelligence comporta i vantaggi che già sono stati illustrati, che se applicati ad un grado di eccellenza portano a realizzare un' impresa in tempo reale in cui le informazioni fluiscono senza ostacolo, ed i processi di business sono costantemente monitorati per permettere reazioni rapide, di solito automatizzate, secondo regole di business predefinite. Tuttavia mettere in pratica le soluzioni proposte in letteratura non è immediato né semplice. Il maggiore problema è rappresentato dall'integrazione con le infrastrutture informatiche preesistenti che andranno a diventare fonte dei dati del nuovo sistema di BI: non si tratta solo di integrare le informazioni della pianificazione con quelle relative alla produzione, ma si tratta anche di uniformare dati dallo stesso contenuto concettuale ma dalla struttura differente. Come esemplificazione di un caso estremo si può pensare a due reparti di uno stesso stabilimento che debbano avere un interscambio di dati tra database e fogli di calcolo. Si pensi ancora ad integrare i dati provenienti dai Manufacturing Execution 15

26 System di due stabilimenti diversi che abbiano attributi leggermente differenti per descrivere uno stesso tipo di indicatore, oppure pur avendo gli stessi attributi possano essere espresse o memorizzate in forme differenti, (es. gg/mm/aaaa e mm/gg/aa) o unità di misura differenti (es. centimetri e pollici). Risolvere questo problema porta porta il beneficio di avere un insieme organico di indicatori che risultano trasversali a tutta la filiera con conseguente miglioramento della visione globale della performance aziendale. Inoltre, avere dati organici e normalizzati tra loro permette di effettuare confronti in modo più rapido e preciso per verificare se gli indicatori di performance, che sono KPI di lagging, cioè riferiti a istanti o periodi passati, si discostano dagli indicatori di leading, cioè KPI il cui valore è predittivo dei risultati da raggiungere. Potere effettuare confronti più rapidamente significa ridurre l'intervallo di tempo tra la misura e la successiva azione di controllo. La possibilità di avere a disposizione una vasta mole di informazioni provenienti dal Manufacturing Execution system (e più in generale dalla Supply Chain), rappresenta di per sé un vantaggio potenziale rispetto ad aziende che non utilizzano la raccolta dati. Tuttavia avere accesso a tali dati non è sufficiente a trasformare il vantaggio da potenziale ad effettivo, poiché è necessario saper interpretarli e utilizzarli correttamente. Il problema è mettere correttamente in relazione tra loro dati che possono anche essere 'distanti' tra loro. Per mettere in relazione indicatori di alto livello può essere necessario effettuare diversi passi di aggregazione di indicatori a livelli inferiori, oppure per valutare come un indicatore di basso livello influisce, come componente, nel calcolo di un indicatore superiore Soluzione per un caso reale Nel panorama delle Software House dedite allo sviluppo di applicativi gestionali è presente Atomos S.p.A., azienda nata nel 1988, da un progetto di ricerca sulle metodologie di schedulazione a capacità finita sviluppato all'interno di una tesi presso l'università di Genova, facoltà di Ingegneria Elettronica. 16

27 Chi si rivolge ad Atomos, sia che si tratti di piccole e medie imprese, sia che si tratti di realtà industriali più affermate, ha essenzialmente due tipi di esigenze: disporre di software per il controllo della produzione e disporre di software per la pianificazione. L'esigenza di monitorare la produzione viene soddisfatta con un applicativo il cui compito primario è controllare in tempo reale i dati di produzione, l'avanzamento dei lavori, il conteggio delle quantità prodotte e del tempo impiegato. Quello che è stato definito precedentemente con il nome di Manufactury Execution System. Le necessità dell'enterprise Resource Planning vengono invece soddisfatte da altri applicativi della suite preposti alla simulazione degli ordini, alla schedulazione ed ottimizzazione delle risorse tramite un'analisi sia temporale, tramite anticipo o posticipo del fabbisogno, sia spaziale, tramite l'utilizzo di risorse alternative. Come già esposto in precedenza, sussiste il problema di come rendere fruibili le misure di performance provenienti dal MES agli applicativi ERP. Si è valutata la possibilità di eliminare la separazione tra i due livelli sia attraverso l'utilizzo di componenti software di terzi, sia attraverso lo sviluppo di un prototipo sperimentale. È stata scelta la realizzazione di un prototipo dalle capacità ridotte e solo per la misurazione della performance (vedere punto 1 del paragrafo precedente), ma comunque utile per capire studiare il grado di difficoltà che comporta lo sviluppo di questo tassello mancante. La scelta di integrare software proprietario di terze parti è stato scartata principalmente per l'elevato costo e in secondo luogo per la sovrapposizione di alcune funzioni già offerte dalla suite Atomos. Percorrere la via della realizzazione prototipale avrebbe potuto significare aprire la strada per un ulteriore sviluppo commerciale, in caso di risultati incoraggianti. Con questi presupposti si è proceduto allo studio e all'implementazione di un prototipo sperimentale in grado di estrarre e trasformare dati da sorgenti differenti, effettuare un confronto sui dati risultanti dalla trasformazione ed emettere eventuali notifiche in caso di scostamento dai valori stabiliti. 17

28 2.2 Origine dei dati trattati Architettura del sistema Come già discusso nel paragrafo 1.2.3, il Manufacturing Execution System (MES) è il sistema informatizzato con funzione di gestione e controllo delle operazioni produttive. Strettamente correlato al MES è il sistema SCADA, acronimo di Supervisory Control and Data Acquisition. Il termine è generalmente riferito ai sistemi industriali di controllo di supervisione e acquisizione dati. I sistemi SCADA e DCS operano al livello 1 e 2 dello standard ISA-95. Esistono diverse generazioni di sistemi SCADA, differenziate in base all'utilizzo dell'hardware e al grado di decentralizzazione. La prima generazione Monolitica ha visto impiegati i Mainframe decenni addietro, quando la rete non esisteva ancora al tempo in cui i primi sistemi scada vennero concepiti. Era previsto l'utilizzo di un Mainframe di backup in caso di guasto. La possibilità di comunicazione tra sistemi separati è stata integrata solo successivamente mediante l'uso di terminali remoti. La generazione successiva Distribuita ha permesso di dislocare il processamento su più stazioni connesse tramite LAN (Local Area Network) e di scambiarsi informazioni in tempo reale. Ogni stazione è responsabile di un compito particolare rendendo più economico il loro utilizzo rispetto ai sistemi della generazione precedente. Le implementazioni SCADA di questa generazione sono spesso caratterizzate da protocolli proprietari che le rendono chiuse. La generazione corrente di sistemi SCADA è denominata Networked. È caratterizzata da architetture aperte piuttosto che da implementazioni specifiche controllate dai produttori. L'utilizzo di standard aperti ha permesso il collegamento di periferiche di terze parti quali stampanti e supporti di memorizzazione esterni. I protocolli utilizzati sono anch'essi di standard aperto, facilitando l'interconnessione e la distribuzione delle funzionalità attraverso LAN e nelle implementazioni di scala maggiore attraverso WAN (Wide Area Network). Il Protocollo Internet (IP) è uno di questi e permette la comunicazione tra la 18

29 stazione principale e gli apparati remoti. Esiste un certo grado di confusione tra sistemi SCADA e DCS (Distributed Control Systems) dovuta alla sovrapposizione di alcune funzionalità tra i due sistemi. Essa è una conseguenza della crescente innovazione tecnologica che ha permesso di integrare nello stesso hardware capacità di acquisizione dati, controllo, supervisione e distribuzione. La discriminante tra SCADA e DCS è la filosofia con cui sono concepiti i due tipi di sistemi: SCADA DCS Orientati all'acquisizione dati Orientati al processo Event-driven State-driven Utilizzati per applicazioni distribuite su Usati comunemente in singoli stabilimenti vaste aree geografiche Progettati per lavorare anche in assenza di Sempre connessi alla fonte dei dati connettività Tabella 2.1: differenze tra SCADA e DCS Un sistema SCADA è composto generalmente dai seguenti sottosistemi: Un'Interfaccia Macchina-Uomo (HMI) è un apparato in grado di presentare i dati relativi al processo all'operatore umano, il quale osserva e controlla il processo medesimo Un Computer Supervisore con comunicazione bidirezionale che raccoglie i dati e invia i comandi al processo. Terminali Remoti (RTU) connessi ai sensori di misura. Inviano i segnali convertiti in forma digitale al Computer Supervisore Infrastruttura di comunicazione tra i Sistemi di Supervisione e i Terminali Remoti Controllori a Logica Programmabile (PLC) usati come come dispositivi di campo; sono più economici, versatili e flessibili dei Terminali Remoti single-purpose. 19

30 SERVER DB MANAGER SERVER POLLING MES POSTAZIONE DI SUPERVISIONE Stampante ETHERNET Access Point scanner link PLC PC MACCHINE/LINEE Terminal e Palmare POSTAZIONI DI LAVORO Ethernet Ethernet-wireless Internet Illustrazione 2.1: Architettura per la raccolta dati, il controllo e la supervisione Alcuni esempi di sensori: Contapezzi elettromeccanici (schede 'link'); è la tipologia di sensori più semplice: un pezzo viene rilevato dalla chiusura di un interruttore con il passaggio del pezzo stesso. Sensori ottici: un fascio luminoso viene interrotto al passaggio del pezzo ed un fotodiodo rileva la variazione del flusso luminoso. Sensori di livello (per liquidi, polveri e materiali granulari): possono essere anch'essi di tipo ottico, oppure resistivo, capacitivo, ultrasonico Scanner ottici per codici a barre: sono utilizzati per decifrare i codici contenenti le informazioni utili sulla gestione del magazzino e sul movimento delle merci. 20

31 2.2.2 Programmable Logic Control I PLC trovano sempre più spazio d'impiego nei sistemi SCADA per via della loro flessibilità e scalabilità. Un PLC è composto da una CPU, da una memoria ROM contenente il firmware, una Memoria Utente di tipo EEPROM per ospitare il programma e una memoria volatile RAM. Hanno la possibilità di essere espansi con schede dotate di ingressi o uscite, ambedue in forma analogica o digitale. Sfruttando le grandi potenzialità offerte dall'uso dei microcontrollori, i PLC sono in grado di garantire, oltre ai requisiti di flessibilità, prestazioni impensabili per qualsiasi apparecchiatura elettromeccanica quali elaborazione di segnali analogici effettuazione di operazioni matematiche memorizzazione dati visualizzazione dati trasferimento dati collegamenti operativi con altri PLC, con calcolatori e con controlli numerici. Illustrazione 2.2: Schema a blocchi dell'hardware di un PLC 21

32 Un PLC può quindi essere definito come un sistema elettronico che consente di realizzare, in modo flessibile, l'unità di elaborazione di un comando automatico e, più in generale, di qualsiasi controllo industriale. I PLC sono progettati per il funzionamento in intervalli di temperatura estesi, sono immuni ai disturbi elettromagnetici e possono subire sollecitazioni meccaniche dovute a vibrazioni e impatti. Le principali differenze tra un pc desktop ed un PLC sono riassunte nella tabella 2.2 Caratteristica Spostamento di dati PC > kbyte/sec PLC < 10 kbyte/s Dimensione dei programmi > kbyte < 10 kbyte Operazioni binarie tipiche spostamento di 32 bit operazioni su 1 bit singolo > 1 GHz < 100 MHz 8 ore al giorno 24 ore su 24 scarsa elevata interno climatizzato da 0 a 55 C Frequenza Microprocessore Funzionamento tipico Immunità a disturbi elettrici Condizioni ambientali Tabella 2.2: Differenze tra pc e PLC L'elaborazione dei PLC è ciclica. Ad inizio ciclo, denominato ciclo di scansione, avviene la lettura degli ingressi (analogici o digitali), on board o su bus di campo. Il passo successivo è la scrittura in memoria nel registro immagine degli ingressi; la fase seguente consiste nell'elaborazione da parte della CPU della sequenza di istruzioni. Il risultato ottenuto dall'elaborazione viene salvato nel registro immagine delle uscite. L'ultimo passo è la scrittura dei valori sulle uscite fisiche che vengono attivate. L'intero ciclo dura qualche decina di millisecondi L'acquisizione dei dati Come visibile dall'illustrazione 2.1 fanno parte dell'architettura hardware anche due server, 22

33 in comunicazione tramite rete ethernet con i terminali remoti (RTU) e i controllori a logica programmabile (PLC). Il server denominato Server Polling Mes ha il compito, come il nome stesso suggerisce, di richiedere ciclicamente a tutte le unità di output il valore salvato nei registri di uscita; durante questa operazione il valore viene associato in modo univoco al dispositivo che lo ha prodotto. Il Server Db Manager assolve al compito di rendere persistenti sul suo database i dati raccolti prima che vengano sovrascritti da un successivo ciclo di polling. Nell'implementazione di Atomos esistono in realtà due gruppi di tabelle strutturalmente identiche, ma differenti dal punto di vista del contenuto, suddiviso in base a un semplice criterio temporale. I record contenuti nelle tabelle real-time vengono spostati ed accorpati ogni ventiquattr'ore ore a quelli presenti nelle tabelle dello storico dati. Le tabelle per i dati real-time sono tabelle allocate nella memoria RAM e permettono di avere accesso istantaneo al loro contenuto. Poiché la memoria fisica allocabile è in quantità finita si rende necessario il trasferimento delle informazioni dalla memoria volatile ad unità di memorizzazione permanente di massa contenenti lo storico dei dati. Oltre allo storico dati è presente anche un archivio storico dati contenente anche dati aggregati calcolati a partire da storico dati. Tempo di produzione per singoli pezzi, tempo di fermo dei macchinari, tempi di guasto e manutenzione, quantità di pezzi prodotti per unità di tempo, pezzi totali prodotti e pezzi difettosi, sono alcune tra le misure significative effettuate dal Manufacturing Execution System, in linea con i principi teorici espressi nel capitolo 1; è già stato discusso quali siano le cinque dimensioni chiave (qualità, costo, tempo, flessibilità e affidabilità) della misura della performance di produzione entro le quali i dati raccolti sono da collocare. Dal punto di vista operativo ogni indicatore ha un insieme di misure, che corrispondono ad altrettanti record salvati su database. Ogni record contiene una serie di attributi che identificano in modo univoco la misura di un indicatore effettuata su una particolare macchina della linea di produzione. In particolare deve contenere almeno i seguenti attributi: Valore: è il numero che esprime il risultato della misurazione. Una nome/identificativo univoco: serve per distinguere di quale indicatore sia il 23

34 valore misurato Istante di acquisizione: indica il momento in cui la misurazione è stata effettuata Unità di misura: esprime la quantità fisica. Esistono anche indicatori adimensionali, risultanti da rapporti di quantità dello stesso tipo. Per una trattazione completa degli attributi si rimanda al paragrafo sul database relazionale. La base di dati così strutturata risulta contenere le misure a livello atomico dei processi di produzione monitorati. Questo approccio di natura bottom-up, caratterizzato da un ottimo dettaglio ai bassi livelli della Supply Chain, permette di salire a livelli superiori attraverso operazioni di aggregazioni sugli indicatori di partenza. L'approccio bottom-up unisce sistemi per dare vita ad altri sistemi di dimensioni maggiori, rendendo così i sistemi originali sottosistemi di quello emergente. Il processo di unione può essere ripetuto a più livelli fino ad ottenere un sistema di livello massimo. 2.3 Definizione di un modello semplificato Per la valutazione della performance aziendale è stato scelto l'overall Equipment Effectiveness (OEE) che risulta largamente diffuso ed apprezzato per valutare la produttività degli impianti in special modo per la produzione. È una metrica di Best Practice e il suo utilizzo comporta alcuni vantaggi, primo tra tutti la sua semplicità; è di semplice comprensione e calcolo poiché il suo prodotto è composto solamente da tre fattori. Se i dati sono acquisiti automaticamente, come nel caso in esame, può essere calcolato in tempo reale continuamente. È una metrica standardizzata che permette di comparare la performance tra diversi processi, reparti, stabilimenti, od aziende intere. Permette di monitorare l'efficienza degli impianti e catalogare le più comuni fonti di perdita di produttività. L'Overall Equipment Effectiveness è così definito: OEE= prestazioni disponibilità qualità 24

35 L'OEE è adimensionale, essendo il prodotto di tre fattori anch'essi adimensionali, risultanti da rapporti di quantità dello stesso tipo. disponibilità= prestazioni = tempo di funzionamento tempo disponibile tempo ciclo teorico unitario pezzi prodotti tempo di funzionamento qualità = pezzi validi pezzi prodotti Disponibilità (Availability): è il rapporto tra il tempo effettivo di produzione e il tempo pianificato per la produzione. Questo parametro è una misura delle perdite causate dalle fermate significative non pianificate (Downtime Losses). Prestazioni (Performance Rate): nel discreto è dato dal rapporto tra il numero totale di pezzi prodotti e quello ideale calcolato in base alla velocità dichiarata. Questo parametro misura il throughput effettivo di un apparato rispetto a quello teorico, denotando l incidenza delle perdite legate alle riduzioni di velocità di funzionamento e alle fermate brevi (Speed Losses). Qualità (Quality Rate): nel discreto è dato dal rapporto tra il numero di pezzi buoni ed il numero di pezzi totali prodotti. È una misura delle perdite causate da produzione di scarti o rilavorati (Quality Loss). Il valore dell'oee può variare da 0 a 100% anche se difficilmente si incontrano nella pratica valori superiori all'85% [31][32]. Il tempo totale attribuibile alle perdite sottratto al tempo pianificato fornisce il tempo di produzione ideale, in cui ipoteticamente l apparato lavora senza subire fermate, alla velocità dichiarata e senza produrre scarti. Poiché l'oee è una metrica in grado di abbracciare l'intera Supply Chain e quindi id aumentarne la sua visibilità, risulta uno strumento fondamentale per realizzare l'eccellenza operazionale proposta dal modello DMAIC (par ). 25

36 Illustrazione 2.3: Fattori di perdita OEE L'Overall Equipment Effectiveness viene calcolato a partire dai dati provenienti dal Manufacturing Execution System; i fattori concorrenti al suo prodotto sono il risultato di aggregazioni su dati atomici acquisiti automaticamente dalle schede interfacciate alla linea di produzione. Nel capitolo 4 verrà affrontato in maggiore dettaglio l'esatta identità dei dati utilizzati per il calcolo. 2.4 Tecnologie IT a supporto della soluzione Il presente paragrafo analizza alcune soluzioni dell IT che dovrebbero essere adottate dall azienda per conseguire gli obiettivi esposti dal modello concettuale. Per realizzare la misura e la valutazione dell'overall Equipment Effectiveness sono necessarie alcune soluzioni tecnologiche note con i termini di Datawarehousing, Datamarting, Extraction Transform & Load, e Event & Alert Management. 26

37 2.4.1 Data Warehouse Il Data Warehouse (DW), come da traduzione letterale, è un Magazzino di Dati strutturato tramite un normale database ed è creato da una applicazione gestionale. L'integrazione dei dati costituisce la principale caratteristica distintiva del DW rispetto ad altri sistemi di supporto alle decisioni. Le caratteristiche distintive di un Data Warehouse sono [33]: Integrazione: in esso confluiscono dati provenienti da più sistemi transazionali (ad esempio il Manufacturing Execution System) e da fonti esterne. L'obiettivo dell'integrazione può essere raggiunto percorrendo differenti strade: mediante l'utilizzo di metodi di codifica uniformi, mediante il perseguimento di una omogeneità semantica di tutte le variabili, mediante l'utilizzo delle stesse unità di misura. Orientamento al soggetto: il DW è orientato a temi aziendali specifici piuttosto che alle applicazioni o alle funzioni. In un DW i dati vengono archiviati in modo da essere facilmente letti o elaborati dagli utenti. Si tratta di una modellazione dei dati che consenta una visione multidimensionale degli stessi. Variabilità nel tempo: i dati archiviati all'interno di un DW coprono un orizzonte temporale molto più esteso rispetto a quelli archiviati in un sistema operazionale. Nel DW sono contenute una serie di informazioni relative alle aree di interesse che colgono la situazione relativa ad un determinato fenomeno in un determinato intervallo temporale piuttosto esteso. Ciò differisce da quanto si verifica in un sistema transazionale, nel quale i dati corrispondono sempre ad una situazione aggiornata, solitamente incapace di fornire un quadro storico del fenomeno analizzato. Non volatilità: tale caratteristica indica la non modificabilità dei dati contenuti nel DW che consente accessi in sola lettura. Il Data Warehouse, quindi, descrive il processo di acquisizione, trasformazione e distribuzione di informazioni presenti all'interno o all'esterno delle aziende. 27

38 2.4.2 Data Mart Un Data Mart è un raccoglitore di dati specializzato in un particolare soggetto. Un Data Mart contiene un'immagine dei dati che permette di formulare strategie sulla base degli andamenti passati. Normalmente si colloca a valle di un Data Warehouse globale ed è un sottoinsieme logico o fisico di un Data Warehouse di maggiori dimensioni. La necessità di creare un sistema separato per il Data Mart rispetto al Data Warehouse può riassumersi nelle seguenti motivazioni: Accesso facilitato a dati usati frequentemente Migliorare le performance separando l'hardware dedicato. Garantire una maggiore sicurezza dovendo autorizzare l'accesso ad un insieme minore di dati Extract Transform & Load Per trasferire i dati dai database operazionali al DW occorre effettuare un operazione di caricamento dati controllata, per far si che le informazioni contenute nel DW siano corrette. È necessario definire quali dati scrivere sul datawarehouse, non solo perché non è detto che sia necessario portare tutti i dati nel datawarehouse. Bisogna dunque sapere quali dati prendere da quali database operazionali e con quale semantica. Questo tipo di problema è affrontato dagli strumenti che ricadono sotto la categoria di ETL (Extract, Trasform, Load). La prima parte di un processo ETL coinvolge l'estrazione dei dati sistemi sorgenti. La maggior parte dei progetti di Data Warehouse consolida dati da differenti sorgenti, che possono utilizzare differenti formati di memorizzazione; tra le sorgenti più comuni si annoverano Database e file testuali ( plaintext ). Lo scopo della fase estrattiva è la conversione in un unico formato appropriato per la successiva fase di trasformazione. Parte integrante delle operazioni di estrazione è il parsing, processo dal quale dipende l'accettazione o meno dei dati in base all'aderenza 28

39 della struttura o pattern desiderati. Illustrazione 2.4: Schema di un processo ETL Adattamento da ETL-Tools.info La fase di Trasformazione applica una serie di regole o funzioni ai dati estratti, al fine di derivare un nuovo set di dati da caricare nella destinazione. Alcuni dati possono richiedere manipolazioni modeste o nulle. In altri casi possono essere necessarie operazioni di selezione, codifica o decodifica, derivazione di nuovi valori, ordinamento, aggregazione, trasposizioni e pivoting e validazione. Nel caso in cui la validazione abbia esito negativo, essa può comportare la completa o parziale reiezione dei dati. La fase di Caricamento (Loading) inserisce i dati consolidati dalla trasformazione nel Data Warehouse. Gli intervalli di aggiornamento del Data Warehouse dipendo fortemente dal tipo di azienda e possono variare da ore a giorni. All'atto dell'inserimento nel Data Warehouse vengono applicati i vincoli definiti nello schema del database: integrità referenziale, unicità obbligatorietà degli attributi. Questi controlli contribuiscono alla consistenza e alla qualità finale dei dati. Occorre sempre prestare particolare attenzione alla granularità delle informazioni da 29

40 memorizzare nella struttura a valle che non solo devono essere aggregate in modo da non avere un dettaglio eccessivo), ma devono anche mantenere una granularità che consenta di effettuare le necessarie analisi sui dati Event & Alert Management La gestione degli eventi e delle notifiche si riferisce ai metodi che un'impresa utilizza per automatizzare il processo di inoltro di informazioni IT specifiche verso destinatari specifici. La gestione degli eventi e delle notifiche è innescata ogniqualvolta vengano rilevate condizioni significative per i servizi dell'infrastruttura. Lo scopo dell'e&ma è quello di stabilire procedure standardizzate per la manipolazione degli eventi IT attraverso la memorizzazione, classificazione, definizione e implementazioni delle azioni. L'Event & Alert Management contribuisce all'integrazione dei sistemi attraverso i seguenti compiti: Memorizzazione di ogni evento e informazioni correlate Elaborazione degli eventi attraverso attività standardizzate Inoltro selettivo delle notifiche a destinatari specifici Gli eventi possono essere distinti in base al significato: stati/operazioni regolari stati/operazioni che meritano attenzione e ulteriore approfondimento stati/operazioni critiche che richiedono azioni immediate Ognuna di tali condizioni può essere il risultato dell'applicazione delle logiche decise dell'utente sull'insieme delle informazioni in ingresso, applicate ad ambienti definiti sempre dall'utente stesso; ad esempio un evento può essere un allarme critico per un 30

41 reparto ma essere invece una semplice notifica per un altro. Nello sviluppo del prototipo sperimentale sono stati trascurati alcuni aspetti, data la complessità di realizzazione, riguardo la selezione appropriata del destinatario delle notifiche; ci si è limitati a realizzare la parte relativa alla generazione e classificazione delle notifiche associate agli eventi. 2.5 Strumenti Ambiente di sviluppo Delphi Con il termine Delphi si definisce sia un linguaggio di programmazione (conosciuto anche precedentemente come Object Pascal) sia un ambiente di sviluppo integrato (IDE), creato da Borland nel 1995 e ora sviluppato da Embarcadero Technologies. È stato scelto per l'implementazione del prototipo sperimentale perché è la maggior parte del software prodotto da Atomos è stato implementato tramite di esso. Questo ha permesso il riutilizzo di alcune classi software, in linea con la filosofia del riuso del codice. Delphi, come qualsiasi altro ambiente di sviluppo integrato, permette di implementare programmi compatibili con i sistemi operativi della famiglia Windows, senza l'onere di dover sviluppare la maggior parte di componenti grafici. Infatti molte delle librerie vengono fornite all'interno dell'ide, permettendo a chi sviluppa un applicativo di dedicarsi con maggiore attenzione al codice sorgente della parte algoritmica senza doversi preoccupare di creare anche le componenti grafiche di base (finestre, pulsanti, aree di testo, tabelle, etc.). La libreria grafica di Delphi prende il nome di Visual Component Library (VCL). La separazione tra parte algoritmica e interfaccia grafica rende intrinsecamente il codice più mantenibile; inoltre risulta più facilmente espandibile e migliorabile. Delphi è un linguaggio fortemente tipizzato, obbliga a specificare il tipo di ogni elemento sintattico (numeri interi, numeri a virgola mobile, stringhe etc.), rendendo il programma meno prono ad errori ed eccezioni in fase di esecuzione. Sono state utilizzate alcune librerie sviluppate da Atomos, senza l'utilizzo delle quali lo sviluppo del prototipo sarebbe stato oltremodo oneroso e dispersivo. 31

42 Si citano le tre più importanti: un parser per la lettura dei documenti in formato XML, un parser per il calcolo del valore di alcune formule ed un wrapper per le connessioni al Database che è stato creato con lo scopo non solo di semplificare alcune operazioni di connessione al database, ma di fornire connettività a differenti tipi di Database e non solo a Oracle di cui ci si è serviti per gli scopi di questa tesi. Si ricorda che un parser è un algoritmo di riconoscimento sintattico di un linguaggio. Una piccola nota riguardo i programmi Delphi: i programmi scritti in Delphi sono di tipo compilato, il che li rende più veloci nell'esecuzione, a differenza dei programmi interpretati. Se dal punto di vista prototipale non sembra rilevante, la differenza può risultare notabile in casi di applicazioni reali che operano su milioni di record Database relazionale Oracle Oracle fa parte dei cosiddetti RDBMS (Relational DataBase Management System) ovvero di sistemi di database basati sul Modello relazionale che si è affermato come lo standard dei database dell'ultimo decennio. Un database relazionale accoppia i dati utilizzando attributi comuni all'interno dell'insieme di dati stessi. Dal punto di vista matematico una relazione è un insieme formato da elementi distinti fra loro; ciascun elemento è una n-upla dove ciascuna delle n componenti dell'elemento è presa da un determinato dominio (numeri interi, numeri decimali, stringhe, caratteri...). A livello di database si riprende (con poche e sottili differenze) la definizione matematica di relazione. Per lo sviluppo del prototipo sperimentale sono state utilizzate tabelle appartenenti allo stesso database fisico, senza creare appositi Data Warehouse e Data Mart. Questa scelta trova giustificazione nel fatto che le risorse richieste dal test e la quantità di dati da trattare non sono le stesse di un sistema in un ambiente di lavoro reale. Resta comunque valido il modello concettuale esposto nei paragrafi e È stato fatto uso anche di Toad, un'interfaccia grafica per la gestione completa di basi di dati. È stato utilizzato per creare e modificare le tabelle necessarie ai test, non essendo stata prevista per il prototipo alcuna funzionalità di questo tipo. 32

43 2.5.3 File di configurazione e supporto A supporto dei moduli sviluppati è stato fatto anche uso di file XML e, seppur limitato, file INI. I file XML sono stati utilizzati per descrivere le trasformazioni da operare sui dati in ingresso al modulo ETL. È stato scelto questo Metalinguaggio di Marcatura per la sua semplicità e capacità di creare documenti strutturati secondo le esigenze definite dal contesto, in questo caso le formule di estrazione e trasformazione. Un file INI, è un formato di file testuale utilizzato dai programmi per la memorizzazione delle opzioni di funzionamento. L'API di Windows fornisce tutte le funzioni necessarie per gestire in maniera semplice file INI dall'interno di un'applicazione, per questo è stato scelto tale formato per salvare alcune impostazioni dei moduli prototipali senza accollarsi l'onere di sviluppare le operazioni che già vengono gestite nativamente. 33

44 3 Realizzazione del prototipo sperimentale 3.1 Metodo di sviluppo Per la realizzazione del prototipo è stato seguito il paradigma della programmazione orientata agli oggetti, ovvero un metodo di programmazione basato sull'utilizzo di classi ed oggetti, dove per classe si intende una struttura dati complessa usata come modello per creare oggetti cioè istanze della classe stessa. Nelle righe seguenti si richiameranno alcune peculiarità della programmazione orientata agli oggetti, per rendere più agevole la comprensione di quanto verrà descritto riguardo i moduli software sviluppati. Il modello comprende campi (caratteristiche) e metodi (azioni) condivisi da tutti gli oggetti istanziati a partire dalla classe, che è l'unità di base di incapsulamento. L'incapsulamento è un meccanismo di programmazione che unisce il codice e i dati che gestisce, mantenendoli entrambi al sicuro da interferenze e utilizzi non appropriati. All'interno di un oggetto, i dati, il codice, o entrambi devono essere privati per quell'oggetto o pubblici. Codice o dati privati, sono conosciuti e accessibili solo da un'altra parte dell'oggetto. Quando il codice o i dati sono pubblici, altre parti del programma possono accedervi anche se sono definiti all'interno di un oggetto. Polimorfismo è la qualità che permette a un'interfaccia di accedere a una classe generale di azioni. L'azione specifica viene determinata dall'esatta natura della situazione. Il polimorfismo aiuta a ridurre la complessità, permettendo alla stessa interfaccia di essere usata per specificare un classe generale di azione. È compito poi del compilatore selezionare l'azione specifica. L'ereditarietà è il processo grazie al quale un oggetto può acquisire le proprietà di un altro oggetto. Ciò è importante, perché supporta il concetto di classificazione gerarchica. Senza l'uso delle gerarchie, ogni oggetto dovrebbe definire in modo esplicito tutte le sue caratteristiche. Con l'ereditarietà un oggetto deve definire solo le qualità che lo rendono unico all'interno della sua classe. Può ereditare gli attributi generali dai genitori. Delphi, rispetto ad altri linguaggi di programmazione, oltre a campi e metodi supporta le 34

45 properties. Una property assomiglia ad un campo, ma può agire come un metodo. Le properties prendono posto dei metodi di accesso e modifica, ma sono più flessibili e potenti. Le properties sono una delle caratteristiche vitali di Delphi, insieme agli eventi. Un evento ha il compito di associare ogni interazione dell'utente con l'interfaccia grafica ad alcuni metodi degli oggetti. Particolari utilizzi delle caratteristiche richiamate verranno discussi contestualmente alla descrizione del modulo che ne fa uso. 3.2 Descrizione generale e schema a blocchi Per realizzare praticamente quanto esposto nel capitolo 2 occorre sviluppare un prototipo che realizzi le funzioni di estrazione, trasformazione e caricamento di un processo ETL e che inoltre realizzi le funzioni base di event e alert management di base. Inoltre è necessario implementare una porzione del prototipo dedicata alla definizione degli indicatori coinvolti nelle misure ed una porzione dedicata all'impostazione dei valori di confronto utilizzati per le regole di alerting. Alla realizzazione di un programma unico è stata preferita la realizzazione di tre programmi specializzati in un compito specifico: 1. Modulo per la creazione e la gestione dell'anagrafica degli indicatori 2. Modulo ETL 3. Modulo per la gestione degli eventi e notifiche La separazione in tre diversi moduli è stata effettuata per potersi concentrare di volta in volta sulla tematica specifica e sui problemi ad essa correlati. Durante la fase di programmazione è molto comune non riuscire a compilare il programma per verificarne il funzionamento; i motivi che impediscono la compilazione sono molteplici e vanno necessariamente risolti. Tra i più comuni sono errori sintattici, metodi utilizzati impropriamente, operazioni non consentite tra due tipi di dato (ad esempio cercare di eseguire un confronto tra un numero intero e una stringa di caratteri). Altri errori sono riscontrabili runtime, cioè durante l'esecuzione del codice compilato e vanno dalla cattiva 35

46 gestione della creazione e distruzione degli oggetti alla classica divisione per 0. L'operazione di debugging può essere laboriosa e di non immediata conclusione, perciò sviluppare tre moduli separati ha permesso di dividere i problemi concettuali e di rimozione dei bachi dal codice A supporto del prototipo sperimentale è necessario un database dal quale attingere i dati grezzi e sul quale è possibile salvare i dati consolidati. Nei paragrafi e si è discusso sulle nozioni di Data Warehouse e DataMart, sul loro scopo e sul beneficio derivante. Anche per questo aspetto sono state effettuate delle semplificazioni, innanzitutto a livello fisico: il server che ospita alcuni database di test è un server fisico unico. Su di esso vengono virtualizzati diversi database, perciò gli aumenti di prestazione previsti dalla separazione su macchine fisiche differenti ospitanti Data Warehouse e Data Mart non vengono posti in essere. Il database specificatamente utilizzato per i test è pertanto uno soltanto ed ospita sia le tabelle sorgenti del DW sia quelle di destinazione del DM. A livello di test questa differenza comporta solo un calo della velocità dei dati in lettura o scrittura nell'evenienza che due differenti utenti stiano utilizzando le risorse del sistema contemporaneamente; ciò non comporta nessuna alterazione dei risultati in termini qualitativi e quantitativi. Fatta questa premessa manterremo sempre valida la distinzione concettuale tra Data Warehouse e Data Mart. Il tipico flusso delle operazioni potrebbe essere descritto secondo i seguenti passi: 1. Definizione o modifica degli indicatori chiave (KPI) secondo i metodi descritti dalla letteratura (capitolo 1). Definizione o modifica dei loro intervalli temporali di validità. Salvataggio su Data Mart. 2. Processo ETL a) Extract: estrazione dei dati sorgente presenti sul Data Warehouse in base a specifiche query definite nei file XML; eventuale conversione di altre sorgenti dati di tipo plaintext e successiva estrazione. b) Transform: trasformazione dei dati estratti seguendo le formule negli appositi file XML di per la definizione delle formule c) Load: Salvataggio dei dati consolidati sul Datamart 36

47 3. Event Management & Alerting a) Valutazione dei dati trasformati negli intervalli di validità temporali specificati nel modulo dell'anagrafica degli indicatori. b) Emissione di notifiche in base all'esito della valutazione. 1 Data Mart Anagrafica indicatori -Anagrafica KPI -Dati Consolidati -Notifiche Data Warehouse -Dati di origine 2.c 2.a Modulo E.T.L. File plaintext 3.b 2.b Query SQL Formule Modulo gestione eventi e notifiche Regole 3.a Pubblicatori Legenda File eseguibile Database File plaintext Notifiche File XML File HTML Illustrazione 3.1: Schema a blocchi 37

48 3.3 Descrizione dei moduli software sviluppati In questo paragrafo vengono analizzati i moduli scritti in Delphi, introdotti nello schema del paragrafo 3.1. Verranno introdotti frammenti di codice, per una visione completa dei sorgenti (escluse le classi di proprietà di Atomos) e dei relativi eseguibili compilati si consiglia di consultare il cd allegato Anagrafica indicatori Questo modulo è sostanzialmente un'interfaccia per la definizione degli indicatori chiave di prestazione (KPI), dei loro attributi e degli intervalli temporali di applicabilità dei valori di confronto. Gli intervalli temporali servono per definire un periodo entro il quale siano da considerarsi validi i valori di confronto; è possibile specificare una data di inizio e una di fine qualsiasi, anche se nella pratica si creano intervalli riferiti solo all'ultimo periodo di produzione. I valori di confronto sono parametri utilizzati nelle regole di comparazione all'interno del modulo di Event & Alerting Management. Se presenti, vanno inseriti in questo contesto, poiché è possibile creare un associazione tra indicatore e intervallo solo nel modulo dell'anagrafica. Il programma è stato sviluppato con un'interfaccia grafica divisa in due aree di lavoro di natura tabulare: nella parte superiore vengono gestite gli attributi intrinseci dell'indicatore, mentre in quella sottostante sono gestiti gli intervalli di validità e relativi valori di confronto. La tabella possiede un'intestazione contenente il nome degli attributi da assegnare agli indicatori; essi corrispondono ad altrettanti campi presenti nella tabella delle testate degli indicatori, denominata TV_KPI_HEAD, presente sul database, realizzando una mappatura 1:1 tra le celle della tabella e i campi del database. Un discorso del tutto analogo vale per la tabella degli intervalli di validità e quella presente sul database, denominata TV_KPI_VALIDSOGLIE. Nella tabella delle intestazioni tra le voci di rilievo si evidenziano alcuni attributi, di maggiore rilevanza rispetto agli altri, di cui si è già discusso nel paragrafo

49 KH_KPI_ID è un identificativo numerico univoco, in grado di distinguere l'indicatore in qualsiasi contesto; questo attributo è di vitale importanza in quanto relaziona la testata di un indicatore ai dati presenti in altre tabelle. KH_KPI_COD è il campo dell'identificativo letterale, di tipo mnemonico, associato all'identificativo univoco. Il buon senso suggerisce di utilizzare nomi univoci anche per questo attributo, tuttavia può accadere che esistano identificativi uguali, ma differenziati in base al codice dell'applicazione che ne fa uso. KH_KPI_DES: è il campo per una descrizione estesa dell'indicatore. Quando il l'identificativo letterale non è sufficientemente chiaro si ricorre ad una descrizione più comprensibile. KH_KPI_UM è l'unità di misura dell'indicatore. Si noti che nella tabella delle intestazioni non è previsto un attributo che definisca l'istante di misurazione dell'indicatore, invece presente nella tabella contenenti i valori degli indicatori. Per ogni nuovo indicatore inserito viene assegnato un nuovo ID numerico incrementato automaticamente. È stata comunque prevista la possibilità di bypassare tale meccanismo incrementale per poter inserire manualmente identificativi numerici di propria scelta. Questo risulta utile nel caso in cui si vogliano inserire degli insiemi di indicatori raggruppandoli per decadi o centinaia: ad esempio è possibile inserire un gruppo di indicatori riguardanti un certo tipo di macchine, supponiamo a partire da 300, e altri indicatori che ne riguardano un tipo differente a partire da 400. Reimpostando il programma per l'inserimento incrementale l'id univoco riprende dal valore successivo a quello manuale di valore massimo inserito. Tale impostazione può essere memorizzata su un un apposito file.ini, dalla struttura riportata di seguito, di configurazione ricaricato al successivo utilizzo del modulo. Tale file di configurazione è utilizzato anche dagli altri moduli, almeno per quanto riguarda la sezione [Credentials] contenente le informazioni di accesso al database: [Credentials] Alias=OracleSuLNX Username=******** Pwd=*********** [Settings] ProgressiveKPI=-1 39

50 Illustrazione 3.2: Interfaccia del modulo per anagrafica degli indicatori 40

51 RememberDB=-1 In ogni caso prima dell'inserimento definitivo su database viene effettuato un controllo per evitare duplicati. Gli attributi obbligatori per poter inserire un nuovo indicatore su database sono KH_KPI_COD e KH_KPI_DES; questo vincolo permette di lasciare libertà di decisione a posteriori sugli altri attributi ma evita nel contempo di popolare il database di record contenenti solo l'id univoco. Su ogni colonna sono applicabili filtri per ricercare, ordinare o eseguire semplici confronti sui record presenti. Per una descrizione completa di tutti i campi si rimanda al capitolo riguardante la struttura del database. Tali funzionalità sono implementate nativamente nel componente Delphi utilizzato per gestire le tabelle. La tabella degli intervalli di validità non mostra indiscriminatamente un elenco completo di tutti gli intervalli di validità, ma di volta in volta carica al suo interno solo quelli correlati alla sola e unica testata selezionata nella tabella sovrastante. Si tratta di una relazione uno (testata) a molti (intervalli). Tra i campi di rilievo della tabella relativa agli intervalli riportiamo alcuni attributi. KH_KPI_ID è lo stesso identificativo univoco descritto in precedenza. È uguale per tutti gli intervalli associati ad una testata. Per ovvi motivi di coerenza e consistenza dei dati, in questo caso non è modificabile dall'utente KV_VALID_ID è il campo numerico che identifica un ambito definibile dall'utente in cui gli intervalli di validità abbiano legittimità. Può essere pensato come il nome di un gruppo di intervalli riferiti ad un indicatore. KV_DATA_INI e KV_DATA_FINE sono campi che indicano data di inizio e fine dell'intervallo di validità Nei restanti campi KV_VAL_*, dove '*' indica un numero da 1 a 10, sono inseriti soglie e valori di riferimento. Un semplice controllo sulle date inserite ne controlla la coerenza. Anche su questa tabella sono applicabili i filtri già menzionati. Vale la pena spendere qualche parola sul codice sorgente per offrire una visione macroscopica del funzionamento interno del modulo. 41

52 All'atto della creazione della finestra principale vengono create anche alcune strutture atte ad accogliere in memoria gli insiemi dei dati che sono stati caricati caricati o che devono essere salvati su database. procedure TMainForm.FormCreate(Sender: TObject); begin //...altro codice... FKPITable := TkbmMemTable.Create(Self); FSmallThresholdTable := TkbmMemTable.Create(Self); FFullThresholdTable:=TkbmMemTable.Create(Self); DatasourceKPI.DataSet := FKPITable; DatasourceThreshold.DataSet:= FSmallThresholdTable; //...altro codice... FSettings := TSettings.Create; FSettings.LoadSettings(IncludeTrailingPathDelimiter(GetCurr entdir) + 'settings.ini'); //...altro codice... end; FKPITable è una tabella in memoria RAM dedicata ad ospitare i valori degli attributi di ogni testata indicatore; FSmallThresholdTable è una tabella dedicata ad ospitare gli attributi degli intervalli di validità associati alla testata selezionata in un dato istante; FfullThresholdTable è una tabella ospitante tutti gli intervalli e serve come archivio locale per evitare di connettersi inutilmente al database ogni volta che si seleziona una testata e richiedere gli intervalli relativi. I tre oggetti appena nominati sono del tipo TkbMemTable, utilizzato in diversi frangenti dello sviluppo dei moduli prototipali per allocare in memoria tabelle prelevate da DB o altre sorgenti. Alle prime due tabelle sono associati i componenti grafici DataSourceKPI e DataSourceThreshold. A FfullThresholdTable non è associato alcun componente grafico, non dovendo mostrare a schermo il suo contenuto. L'oggetto Fsettings si occupa di recuperare le impostazioni di connessione al database (e anche le altre impostazioni), attraverso il metodo LoadSettings, da il file settings.ini di cui si è parlato nel paragrafo Ancora qualche dettaglio sulle connessioni al database: procedure TMainForm.Apri1Click(Sender: TObject); 42

53 begin //...altro codice... InitializeAliases(TRUE); FDatabase := TAtomosDbConnection.Create(Self); FAtomosAlias := TAtomosDbAliasesList.GetInstance.GetByName(FDBSettings.Alias) ; FAtomosAlias.UserName := FDBSettings.Username; FAtomosAlias.Password := FDBSettings.Pwd; FDatabase.Alias := FAtomosAlias; FDatabase.Open; FDatabase.Connected := TRUE; begin //...altro codice... CaricaSoglieDaDb(); CaricaKPIDaDB(); end //...altro codice... end; La porzione di codice compresa tra InitializeAliases e Fdatabase.Connected:=TRUE fa utilizzo di alcune delle funzioni di libreria Atomos cui è stato fatto riferimento nel paragrafo Con tale procedure viene assicurata la corretta connessione su server virtuale, porta e database specificando solo il nome simbolico del DB cui si desidera connettersi. Il nome simbolico viene associato ad un alias, ovvero un insieme di parametri che definiscono tutti i parametri della connessione, prelevato da un file di configurazione (esterno al modulo del prototipo e condiviso da più applicazioni Atomos) Modulo E.T.L. Il secondo modulo racchiude le funzioni necessarie per la realizzazione del processo di estrazione, trasformazione e caricamento. Nella maggior parte dei casi l'estrazione dei dati di partenza avviene da un database, ma essendo in questo caso disponibili anche dei file CSV (Comma Separated Value) si è provveduto ad implementare un metodo di importazione di questo ti po di file plaintext. Un file plaintext è un file dal contenente solo dati o testo, in forma umanamente leggibile, senza formattazione alcuna. Nel caso dei file CSV il contenuto ha struttura tabulare, 43

54 ovvero ogni riga corrisponde ad un insieme di dati ed ogni elemento compreso tra due ',' è un dato atomico. Ogni riga contiene lo stesso numero di separazioni, anche se uno o più elementi possono essere nulli. Nel paragrafo si è già discusso della capacità di estrazione da fonti differenti di un processo ETL e il caso specifico della lettura del contenuto di file CSV ne rappresenta un'implementazione specifica. Nel dettaglio, il contenuto di un file CSV che deve essere sottoposto al processo di estrazione è simile al testo di seguito riportato. "PROG=Integer,0,""Prog"","""",10,Data,""""" "RISORSA=String,15,""Risorsa"","""",15,Data,""""" "PARTIZIONE=DateTime,0,""Partizione"","""",18,Data,""""" //...altri descrittori... "VALMAX=Integer,0,""Valmax"","""",10,INV,Data,""""" "Prog","Risorsa","Partizione","Nrturno","Capacita","Lavoraz", "Attrezz","Avviam","Inritardo","Contoterzi","Overflow","Valma x", "1","CDL10","01/10/2009","0","24"," ","0","0", " ","0","0","0", "2","CDL10","02/10/2009","0"," ","0","0","0"," 0","0","0","0", "3","CDL10","03/10/2009","0","0","0","0","0","0","0","0",, //...altre righe di valori... In realtà il testo sopra riportato, oltre a contenere righe con valori separati da virgole racchiude anche alcune informazioni aggiuntive necessarie al modulo per capire come deve trattare i dati in ingresso. I termini compresi tra sono parole chiave riconosciute dall'oggetto di tipo TkbmCSVStreamFormat, un lettore di stream in formato CSV, con la funzione di fornire i dati ad un altro oggetto di tipo TKbMemTable ; in particolare TABLEDEF START e TABLEDEF END sono delimitatori contenenti descrittori. Ogni riga corrisponde alla descrizione della testata di un record, in modo simile (ma non 44

55 identico) al modulo dell'anagrafica. Dopo la sezione dei descrittori è presente una singola riga indicante l'ordine esatto col quale ogni riga successiva contiene i valori dei record: nel caso esaminato i valori dell'indicatore Prog sono contenuti nella prima posizione di ogni riga, i valori di Risorsa sono contenuti in seconda posizione, separati dal primo elemento con una ',' e via di seguito. Per migliaia o più di righe. Il caricamento in memoria del file avviene attraverso una funzione abbastanza semplice: procedure TTableFiller.LoadData(filename: string); var CSVFormat: TKbmCSVStreamFormat; begin CSVFormat := TKbmCSVStreamFormat.Create(nil); try FSimula_Table.LoadFromFileViaFormat(IncludeTrailingPath Delimiter(GetCurrentDir) + filename, CSVFormat); finally CSVFormat.Free; end; end; È possibile notare in questo frammento un tipico costrutto di Delphi utile per la gestione degli errori, try finally, in questo caso per errori relativi all'apertura del file. Più complicato, invece, è il salvataggio dei dati, una volta presenti in memoria, sul database: procedure TTableFiller.StoreData(tablename: string); var TempQuery: string; begin try //...altro codice per connessione al database... TempQuery:=GenerateQuery(TableName); FQueryStoreKpi.SQL.Append(TempQuery); FQueryStoreKpi.Prepare; FSimula_Table.First; while not FSimula_Table.Eof do begin begin AggiungiParametro ('PROG', FSimula_Table, FQueryStoreKPI, ftinteger); 45

56 //AggiungiParametro (... AggiungiParametro ('VALMAX', FSimula_Table, FQueryStoreKPI, ftinteger); end; FQueryStoreKpi.ExecSQL; FSimula_Table.Next; end; finally end; end; Innanzitutto occorre creare una connessione al Database come già illustrato in precedenza e creare una una query SQL per l'inserimento dei dati. Essa viene generata con l'ausilio della funzione GenerateQuery, che restituisce una stringa contenente statement SQL del tipo INSERT INTO nome_tabella VALUES (valore1, valore2, valore3,...). Ogni statement insert viene preparato attraverso un ciclo iterativo while do che scandisce le righe della TkbMemTable (contenente copia dei valori del file originario CSV) e ne preleva il contenuto. Grazie alla procedura di importazione di file testuali è possibile uniformare i dati provenienti dall'esterno del database (in questo frangente specifico del Data Warehouse) con quelli in esso già presenti. Il vantaggio di questa operazione consiste nell'arrivare ad ottenere dati in sole tabelle interrogabili query SQL. In questo modo è possibile sfruttare il motore del database per effettuare intersezioni, unioni, esclusioni e aggregazioni tra diverse tabelle senza dover progettare e realizzare un motore che esegua le stesse operazioni all'interno del modulo sperimentale. Se così fosse si dovrebbero implementare strutture complesse che carichino e mantengano contemporaneamente dati provenienti da tutte le sorgenti ed eseguano le stese operazioni del motore all'interno del database. 46

57 Una volta posti nella condizione di avere solo tabelle su database si può operare la trasformazione, che avviene grazie all'ausilio di file XML esterni al file eseguibile che assolvono la funzione di formulari. Nel file Queries_dictionary.XML vengono inserite le query per l'estrazione dei dati, mentre negli altri vengono inserite le formule di trasformazione. Il modulo è stato sviluppato con la possibilità di scegliere quali dizionari caricare. I restanti file hanno un nome specifico, derivato dal valore dell'attributo Name, definito all'interno di Queries_dictionary.XML e viene caricato automaticamente dopo di questo. Un possibile contenuto di Queries_dictionary.XML : <?XML version="1.0" encoding="windows-1252"?> <FormulasDictionary> <field Name="Query_A" QueryText="SELECT * FROM nome_tabella_1" /> <field Name="Query_B" QueryText="SELECT * FROM nome_tabella_2" /> </FormulasDictionary> Dopo aver letto le query dal dizionario ed averle inviata al database, il programma riceve in risposta altrettanti dataset contenenti i risultati desiderati e li alloca in memoria per essere trattati. Il passo successivo consiste nel creare un legame tra gli indicatori inseriti nell'anagrafica e i dati appena recuperati; per raggiungere tale scopo si utilizzano le formule specificate in nei file '*_dictionary.xml' dove * è sostituito dal valore dell'attributo Name del file precedente. Ogni nodo del documento XML contiene la coppia di attributi 'Name' e 'FormulaText' ed i relativi valori. Per semplicità di ragionamento ci riconduciamo ad alcune voci già incontrate nel file CSV: <?XML version="1.0" encoding="windows-1252"?> <FormulasDictionary> <field Name="KH_KPI_ID" FormulaText="KH_KPI_ID" /> <field Name="KR_GIORNO" FormulaText="PARTIZIONE" /> 47

58 <!--altri nodi XML --> <field Name="KR_VALORE" FormulaText="AVVIAM+LAVORAZ" /> </FormulasDictionary> L'attributo 'Name' indica quale colonna della tabella contenente i valori degli indicatori normalizzati andrà a includere il risultato della formula specificata per l'attributo 'FormulaTetx'. Per un'esposizione dettagliata dei campi di tale tabella si rimanda al paragrafo sul database relazionale. Il valore dell'attributo 'FormulaText' può essere atomico o il risultato di espressioni più complesse (ad esempio somma del valore di più campi) elaborate tramite un parser. Tra tutti i valori degli attributi 'Name' uno deve essere necessariemente KH_KPI_ID, ovvero l'id univoco specificato precedentemente nell'anagrafica. KH_KPI_ID è di vitale importanza giacché è ciò che lega tra di loro intestazione, intervalli e intervalli di validità e valore di un indicatore. Inoltre uno degli altri attributi 'Name' deve essere necessariamente KR_VALORE, cioè il valore estratto o calcolato per quell'indicatore. In sintesi l'algoritmo si occupa di preparare un nuovo dataset da salvare sulla tabella degli indicatori normalizzati, denominata TV_KPI_VAL : di questo dataset un campo è l'id univoco, un altro è il valore dell'indicatore e gli altri attributi contengono informazioni quali ad esempio il timestamp di estrazione, la risorsa utilizzata o l'impianto. Può essere utile osservare la definizione, senza entrare del dettaglio dell'implementazione effettiva delle funzioni, della classe TEngine fulcro del modulo ETL, per capire il suo funzionamento: TEngine = class strict private const // numero di colonne prefissato per la tabella dei KPI normalizzati NUM_OF_FIELDS = 19; var FInputDataset: Tdataset; FFormulasDictionary: TFormulasDictionary; FStrutturaCampi : array [0..NUM_OF_FIELDS] of TFieldInfo; 48

59 FParser : TTableEzParser; //...variabili per la connessione al DB... private procedure LoadFormulasDictionaryFromXML (path: string); procedure SetInputDataset(const Value: Tdataset); procedure AddParameter(FieldName: string; DestQuery: TAtomosQueryController; FieldType: TFieldType; avalore : Variant); function GenerateQuery (TableName: string) : string; function StoreValues():boolean; //...codice per la connessione al DB... public property InputDataset: Tdataset read FInputDataset write SetInputDataset; procedure InitTEngine(DictionaryName: string); procedure IterateInputDataset(); constructor Create; destructor Destroy; override; end; All'atto della creazione ( Create ) del motore del modulo vengono automaticamente inizializzati anche una serie di oggetti funzionali al suo utilizzo: il parser ( FParser ), la struttura residente in memoria che ospita le formule di trasformazione ( FFormulasDictionary ) e il descrittore della tabella di destinazione ( FStrutturaCampi ). Per ogni dataset restituito tramite query SQL, eseguita da una funzione chiamata in precedenza ed esterna al motore, esso viene caricato ( InitEngine ) con il dizionario delle formule di trasformazione e viene fatto iterare ( IterateInputDataset ) sul dataset al momento attivo; per ogni riga del dataset viene calcolato il valore delle formule tramite il parser e viene generata la query per l'inserimento ( GenerateQuery ), termine per termine attraverso la funzione AddParameter. Infine viene eseguita la query per il salvataggio su database ( StoreValues ). L'interfaccia di questo modulo è minimale poiché che il lavoro oneroso, svolto principalmente da un algoritmo iterativo avviene in modo invisibile all'utente. 49

60 Illustrazione 3.3: Interfaccia del modulo ETL Vale la pena però di menzionare un nano-editor integrato richiamabile dalla finestra principale per creare al volo i dizionari delle query e delle formule senza dover lanciare altri programmi di composizione testo Modulo gestione eventi e notifiche Il terzo modulo facente parte del prototipo ha il compito di gestire eventi e notifiche in base al risultato di confronti tra le misure degli indicatori normalizzati e i valori di confronto presenti nell'anagrafica degli intervalli di validità dei medesimi indicatori. Dal risultato di tale confronto possono essere generati eventi associabili a notifiche di differenti. Anche questo modulo svolge il suo compito attraverso l'utilizzo di cicli iterativi su dataset Le tabelle del Data Mart coinvolte in questo processo sono TV_KPI_VALIDSOGLIE, contenente i valori di riferimento per ogni intervallo di validità e TV_KPI_VAL, contenente gli indicatori normalizzati in precedenza. Un ciclo completo delle operazioni prevede il caricamento in memoria degli intervalli di validità di dalla tabella dell'anagrafica, la creazione di una lista per inserire eventuali eventi e tre cicli di scansioni annidate: una scansione di tutti gli intervalli per caricare gli indicatori del tipo cui tale 50

61 intervallo ne stabilisce la validità un sub-ciclo di scansione per ogni indicatore normalizzato per applicare le regole di confronto un ulteriore sub-ciclo annidato per applicare tutte le regole esistenti per quel tipo di indicatore. In base al risultato di questa ultima operazione può essere creato un evento. Quest'ultima entità altro non è che una struttura dati contenente tutti i campi dell'indicatore violante la regola ed altre informazioni aggiuntive quali il tipo di evento, la descrizione della violazione e il timestamp dell'istante in cui essa è stata riscontrata. Di seguito è riportata la funzione che si occupa di effettuare i primi due cicli. procedure TForm1.ScanThresholds(); var ConnectionKpiValues : TAtomosDbConnection; AtomosAlias : TAtomosDbAlias; QueryLoadKpiValues : TAtomosQuery; CurrentThresholdDefinition: TKpiValidSoglie; CurrentKPI : TKpi_Val; i: integer; begin for i := 0 to FThresholdsDefinitions.Count - 1 do begin FAlertCounter:=0; FWarningCounter:=0; CurrentThresholdDefinition:=FThresholdsDefinitions.GetThr esholdatpos(i); ConnectionKpiValues := TAtomosDbConnection.Create(nil); try //Codice per connessione al database... try QueryLoadKpiValues := TAtomosQuery.Create(nil, ConnectionKpiValues); QueryLoadKpiValues.SQL.Append('SELECT * FROM TV_KPI_VAL WHERE KH_KPI_ID=:AKPIID AND KR_GIORNO>=:DATAINI AND KR_GIORNO<=:DATAFINE'); QueryLoadKpiValues.Prepare; QueryLoadKpiValues.ParamByName('AKPIID').AsInteger := CurrentThresholdDefinition.kh_kpi_id; QueryLoadKpiValues.ParamByName('DATAINI').AsDate := CurrentThresholdDefinition.kv_data_ini; QueryLoadKpiValues.ParamByName('DATAFINE').AsDate := CurrentThresholdDefinition.kv_data_fine; QueryLoadKpiValues.Open; CurrentKPI := TKpi_Val.Create; try 51

62 while not QueryLoadKpiValues.Eof do begin CurrentKPI.LoadFromDataset(QueryLoadKpiValues.Dat aset); Compare(CurrentThresholdDefinition,CurrentKPI); QueryLoadKpiValues.Next; end; QueryLoadKpiValues.Close; finally //...altro codice... CurrentKPI.Free; end; finally QueryLoadKpiValues.Free; end; finally ConnectionKpiValues.Free; end; end; end; La funzione GetThresholdAtPos(i), all'interno del primo ciclo, seleziona dal primo all'ultimo seguendo l'incremento dell'indice 'i', l'intervallo di validità dei valori di soglia/confronto. In base agli estremi di tale intervallo, rappresentati da due date, viene preparata ed eseguita una query SQL ("QueryLoadKpiValues.SQL.Append", "QueryLoadKpiValues.Prepare", "QueryLoadKpiValues.Open"). Per ogni riga del dataset restituito, all'interno del secondo ciclo viene eseguita la funzione Compare, all'interno della quale vengono applicate le regole di confronto sul valore dell'indicatore. Per questo prototipo sono state implementate due regole di confronto: una regola per la violazione netta delle soglie limite inferiore e superiore una regola per la vicinanza del valore dell'indicatore alle soglie, basata su valori percentuali Per la prima regola è sufficiente un semplice comparazione per verificare se il valore è compreso tra soglia inferiore e superiore; per il secondo caso, viene calcolato un valore superiore alla soglia minima, di una percentuale pari ad un valore inserito dall'utente in uno dai campi KV_KPI_VAL* (in questo specifico caso KV_KPI_VAL1) che ricordiamo essere campi personalizzabili per l'inserimento di altre soglie o valori di riferimento 52

63 numerici: se ad esempio nell'anagrafica in tale campo è stato inserito '10', la regola indica se il valore dell'indicatore è in un intervallo compreso tra la soglia minima e il 10% in più della soglia minima; un discorso del tutto analogo vale per la soglia superiore e un valore ad esso inferiore di una percentuale scelta. È da fare una doverosa precisazione riguardo la definizione delle regole: esse sono codificate in Delphi all'interno del modulo, non sono caricate da file esterni come invece avviene per le formule di trasformazione. La possibilità di inserire regole definite dall'utente esternamente al codice avrebbe comportato la creazione di un linguaggio di scripting ad hoc ed un interprete di script; tale sviluppo sarebbe stato eccessivamente oneroso ai fini della tesi, quindi ci si è limitati ad utilizzare regole tramite codice inline. Se le regole non sono inseribili manualmente, resta la possibilità resta comunque la possibilità di impostare i valori di soglia tramite l'interfaccia per la gestione dell'anagrafica. Ogni qual volta sussiste una violazione delle regole viene creato un evento. È stato menzionato il fatto che esistono diversi tipi di eventi; si considerino le due regole descritte in precedenza, è chiaro che il superamento della soglia è un fatto di per sé più rilevante rispetto ad essere il 10% vicini alla soglia. Nel primo caso il tipo di evento è contrassegnato come 'alert', nel secondo caso come 'warning'. Per supportare questa differenziazione, in questo modulo è si è fatto uso di uno dei meccanismi tipici della programmazione ad oggetti: l'ereditarietà. Poiché si è deciso di implementare diversi tipi di eventi classificati in base al grado di attinenza alle regole si è deciso di sviluppare un oggetto progenitore, un evento generico, dal quale ogni altro evento specifico viene derivato. Si riporta il codice sorgente della definizione delle classi per illustrare come avviene nella pratica questo meccanismo: TdatamartEvent=class //Classe progenitrice private FIsOnKpi: boolean; FEventDate: TDateTime; FDescription: string; public property IsOnKpi: boolean read FIsOnKpi write FIsOnKpi; property EventDate: TDateTime read FEventDate write FEventDate; 53

64 property Description: string read FDescription write FDescription; end; TThresholdEvent = class (TdatamartEvent)//Classe derivata private FKh_kpi_cod: string; FKv_valid_id: smallint; FKpiData: Tkpi_val; FThresholdName: string; public Constructor Create; virtual; Destructor Destroy; override; function GetEventTypeString : string; virtual; abstract; property Kh_kpi_cod: string read FKh_kpi_cod write FKh_kpi_cod; property Kv_valid_id: smallint read FKv_valid_id write FKv_valid_id; property KpiData: Tkpi_val read FKpiData write FKpiData; property ThresholdName: string read FThresholdName write FThresholdName; end; TThresholdAlert = class (TthresholdEvent)//Casse derivata public function GetEventTypeString : string; override; end; TThresholdWarning = class (TthresholdEvent)//Classe derivata public function GetEventTypeString : string; override; end; La classe progenitrice è TdataMartEvent, rappresenta il modello per un evento generico, contiene alcuni campi e alcune properties di base, ereditati dalle classi derivate. TTHresholdEvent è classe derivata di TdataMartEvent e rappresenta il modello di un evento generato dal superamento di qualche soglia; oltre ad ereditare campi e properties della classe progenitrice, ne aggiunge alcune propri. TthresholdAlert e TthresholdWarning rappresentano un ulteriore grado di derivazione, specificando il tipo particolare di evento e implementando il metodo GetEventTypeString che nella classe padre è solo definito come astratto (cioè privo di implementazione). Tale procedimento ovviamente è estensibile per generare altre tipologie di eventi. 54

65 Al termine del ciclo di controllo di tutti gli indicatori si ottiene una lista di eventi, supponendo che si siano verificate violazioni; essa è l'anello di congiunzione tra la parte di gestione eventi e quella di emissione delle notifiche. L'emissione delle notifiche avviene ad opera dei pubblicatori, ovvero oggetti il cui compito è prelevare gli eventi dalla lista e formattarli secondo gli standard del formato di destinazione. Un evento diventa notifica nel momento in cui viene formattato e pubblicato. La differenza è più concettuale che pratica, dal momento che un evento e una notifica contengono le stesse informazioni. Per il prototipo sono stati implementati due pubblicatori: uno per database e uno per documenti HTML. Il primo è stato sviluppato per la semplice necessità di dover salvare in modo persistente gli eventi generati dai confronti con le regole; ad esso è affidato il semplice compito di creare un dataset e inserirlo su database tramite query SQL. Il pubblicatore HTML invece si occupa di aggiungere ai nomi dei campi e ai loro valori tutti i tag necessari per avere un documento rispondente alle specifiche W3C XHTML 1.0 Strict. L'aspetto finale del documento è di natura tabulare, con formattazione condizionata dal tipo di notifica (es. sfondo delle celle rosso per gli 'alert', giallo per i 'warning'). 55

66 Illustrazione 3.4: Pagina prodotta dal pubblicatore HTML Anche per questo modulo l'interfaccia è scarna perché le operazioni di confronto sono svolte da un algoritmo che non necessita interazione grafica. È presente una barra di menu per effettuare le operazioni di lettura del database. Alla finestra di esecuzione del programma è stato aggiunto un riquadro di log che mostra gli eventi a mano a mano che vengono rilevate violazioni delle regole. Non sostituisce i pubblicatori, ma è utile soprattutto se si è interessati solo a testare le regole senza essere obbligati a pubblicare gli eventi. Nel riquadro di log sono presentati il tipo di evento, il valore che lo ha generato e quello di riferimento; compaiono i contatori delle violazioni di regole e un timer che indica il tempo di elaborazione totale. 56

67 Illustrazione 3.5: Interfaccia grafica del modulo gestione eventi e notifiche Il database relazionale È già stato fatto riferimento al database nei capitoli precedenti, senza tuttavia soffermarsi in dettaglio sulle singole voci di ogni tabella. Si ricorda che Le tabelle sorgenti e di destinazione risiedono fisicamente sullo stesso database, la differenza tra Data Mart e Data Warehouse rimane a livello teorico. Per il Data Warehouse non è possibile stabilire a priori quali tabelle siano utilizzate in una specifica azienda né specificare quali indicatori siano in esso contenuti. Risulta invece possibile definire e costruire le tabelle da inserire nel Data Mart destinate a contenere gli indicatori sottoposti a processo ETL: TV_KPI_HEAD: contiene le testate degli indicatori chiave TV_KPI_VALIDSOGLIE: contiene gli intervalli di validità e le soglie TV_KPI_VAL: contiene i valori degli indicatori normalizzati TV_EVENTS: contiene la serie di violazione delle regole 57

Università degli Studi di Genova Facoltà di Ingegneria. Tesi di Laurea in Ingegneria Elettronica

Università degli Studi di Genova Facoltà di Ingegneria. Tesi di Laurea in Ingegneria Elettronica Università degli Studi di Genova Facoltà di Ingegneria Tesi di Laurea in Ingegneria Elettronica Performance measurement system per la gestione di eventi industriali complessi Candidato: Adriano Moretti

Dettagli

Introduzione alla Business Intelligence. E-mail: infobusiness@zucchetti.it

Introduzione alla Business Intelligence. E-mail: infobusiness@zucchetti.it Introduzione alla Business Intelligence E-mail: infobusiness@zucchetti.it Introduzione alla Business Intelligence Introduzione Definizione di Business Intelligence: insieme di processi per raccogliere

Dettagli

SCADA: struttura modulare

SCADA: struttura modulare Sistemi per il controllo di supervisione e l acquisizione dati o (Supervisory Control And Data Acquisition) Sistema informatico di misura e controllo distribuito per il monitoraggio di processi fisici

Dettagli

Introduzione alla Business Intelligence

Introduzione alla Business Intelligence SOMMARIO 1. DEFINIZIONE DI BUSINESS INTELLIGENCE...3 2. FINALITA DELLA BUSINESS INTELLIGENCE...4 3. DESTINATARI DELLA BUSINESS INTELLIGENCE...5 4. GLOSSARIO...7 BIM 3.1 Introduzione alla Pag. 2/ 9 1.DEFINIZIONE

Dettagli

Computer Integrated Manufacturing

Computer Integrated Manufacturing Computer Integrated Manufacturing Sistemi per l automazione industriale Ing. Stefano MAGGI Dipartimento di Elettrotecnica Politecnico di Milano lunedì 10 novembre 2008 Contenuti Il processo e l impianto

Dettagli

KPI e OEE con SIMATIC WinCC DowntimeMonitor

KPI e OEE con SIMATIC WinCC DowntimeMonitor KPI e OEE con SIMATIC WinCC DowntimeMonitor In un periodo in cui è imperativo per tutte le aziende contenere i costi di produzione, avere degli strumenti di raccolta dati ed analisi della produttività

Dettagli

AMBIENTE INDUSTRIALE: INTRODUZIONE AL CIM

AMBIENTE INDUSTRIALE: INTRODUZIONE AL CIM AMBIENTE INDUSTRIALE: INTRODUZIONE AL CIM CIM = Computer Integrated Manufacturing Fabbrica completamente automatizzata fabbrica ottimizzata Obiettivi di una strategia CIM incremento della qualità del prodotto

Dettagli

Sistemi Informativi Aziendali I

Sistemi Informativi Aziendali I Modulo 6 Sistemi Informativi Aziendali I 1 Corso Sistemi Informativi Aziendali I - Modulo 6 Modulo 6 Integrare verso l alto e supportare Managers e Dirigenti nell Impresa: Decisioni più informate; Decisioni

Dettagli

Il miglioramento delle performance produttive tramite l analisi di KPI: stabilimento food & beverage. Case history Parmalat

Il miglioramento delle performance produttive tramite l analisi di KPI: stabilimento food & beverage. Case history Parmalat Il miglioramento delle performance produttive tramite l analisi di KPI: stabilimento food & beverage. Case history Parmalat - Food-Beverage&Packaging Industry - Analisi del contesto esterno La competitività

Dettagli

Luigi Piroddi piroddi@elet.polimi.it

Luigi Piroddi piroddi@elet.polimi.it Automazione industriale dispense del corso 2. Introduzione al controllo logico Luigi Piroddi piroddi@elet.polimi.it Modello CIM Un moderno sistema di produzione è conforme al modello CIM (Computer Integrated

Dettagli

Energy Data Management System (EDMS): la soluzione software per una gestione efficiente dell energia secondo lo standard ISO 50001

Energy Data Management System (EDMS): la soluzione software per una gestione efficiente dell energia secondo lo standard ISO 50001 Energy Data Management System (EDMS): la soluzione software per una gestione efficiente dell energia secondo lo standard ISO 50001 Oggi più che mai, le aziende italiane sentono la necessità di raccogliere,

Dettagli

DATA WAREHOUSING CON JASPERSOFT BI SUITE

DATA WAREHOUSING CON JASPERSOFT BI SUITE UNIVERSITÁ DEGLI STUDI DI MODENA E REGGIO EMILIA Dipartimento di Ingegneria di Enzo Ferrari Corso di Laurea Magistrale in Ingegneria Informatica (270/04) DATA WAREHOUSING CON JASPERSOFT BI SUITE Relatore

Dettagli

Ph@ses 3003. Sistema informativo di fabbrica 1/12

Ph@ses 3003. Sistema informativo di fabbrica 1/12 Ph@ses 3003 Sistema informativo di fabbrica 1/12 1 Indice 1 Indice...2 2 Introduzione...3 3 Il prodotto: Ph@ses 3003...3 4 Tecnologia...3 5 Schema logico generale di produzione...4 5.1 Layuot logico di

Dettagli

E-Mail. Scheduling. Modalità d invio. E-Mail

E-Mail. Scheduling. Modalità d invio. E-Mail BI BI Terranova, azienda leader in Italia per le soluzioni Software rivolte al mercato delle Utilities, propone la soluzione Software di Business Intelligence RETIBI, sviluppata per offrire un maggiore

Dettagli

Data Warehousing e Data Mining

Data Warehousing e Data Mining Università degli Studi di Firenze Dipartimento di Sistemi e Informatica A.A. 2011-2012 I primi passi Data Warehousing e Data Mining Parte 2 Docente: Alessandro Gori a.gori@unifi.it OLTP vs. OLAP OLTP vs.

Dettagli

SCHEDE DI INFORMATICA GLI ARCHIVI E LE BASI DI DATI

SCHEDE DI INFORMATICA GLI ARCHIVI E LE BASI DI DATI SCHEDE DI INFORMATICA GLI ARCHIVI E LE BASI DI DATI Il Database è una collezione di archivi di dati ben organizzati e ben strutturati, in modo che possano costituire una base di lavoro per utenti diversi

Dettagli

Processi di Business e Sistemi di Gestione di Workflow: concetti di base. Prof. Giancarlo Fortino g.fortino@unical.it

Processi di Business e Sistemi di Gestione di Workflow: concetti di base. Prof. Giancarlo Fortino g.fortino@unical.it Processi di Business e Sistemi di Gestione di Workflow: concetti di base Prof. Giancarlo Fortino g.fortino@unical.it Introduzione Le aziende devono modificare la loro organizzazione per cogliere le nuove

Dettagli

Business Intelligence, OLAP e il monitoraggio del proprio Business

Business Intelligence, OLAP e il monitoraggio del proprio Business Business Intelligence, OLAP e il monitoraggio del proprio Business Con il termine business intelligence (BI) ci si può solitamente riferire a: 1. un insieme di processi aziendali per raccogliere ed analizzare

Dettagli

Sistemi Informativi. Catena del valore di PORTER

Sistemi Informativi. Catena del valore di PORTER Sistemi Informativi Catena del valore di PORTER La catena del valore permette di considerare l'impresa come un sistema di attività generatrici del valore, inteso come il prezzo che il consumatore è disposto

Dettagli

Data warehousing Mario Guarracino Laboratorio di Sistemi Informativi Aziendali a.a. 2006/2007

Data warehousing Mario Guarracino Laboratorio di Sistemi Informativi Aziendali a.a. 2006/2007 Data warehousing Introduzione A partire dalla metà degli anni novanta è risultato chiaro che i database per i DSS e le analisi di business intelligence vanno separati da quelli operazionali. In questa

Dettagli

Lista delle descrizioni dei Profili

Lista delle descrizioni dei Profili Lista delle descrizioni dei Profili La seguente lista dei Profili Professionali ICT è stata definita dal CEN Workshop on ICT Skills nell'ambito del Comitato Europeo di Standardizzazione. I profili fanno

Dettagli

ADVANCED MES SOLUTIONS

ADVANCED MES SOLUTIONS ADVANCED MES SOLUTIONS PRODUZIONE MATERIALI QUALITA MANUTENZIONE HR Open Data S.r.l. all rights reserved OPERA MES OPERA MES è il software proprietario di Open Data. È un prodotto completo, integrato,

Dettagli

E.T.L. (Extract.Tansform.Load) IBM - ISeries 1/8

E.T.L. (Extract.Tansform.Load) IBM - ISeries 1/8 E.T.L. (Extract.Tansform.Load) IBM - ISeries Quick-EDD/ DR-DRm ETL 1/8 Sommario ETL... 3 I processi ETL (Extraction, Transformation and Loading - estrazione, trasformazione e caricamento)... 3 Cos è l

Dettagli

Estratto dell'agenda dell'innovazione e del Trade Bologna 2011. Speciale: I casi. Introduzione dell'area tematica IL CASO FAGIOLI

Estratto dell'agenda dell'innovazione e del Trade Bologna 2011. Speciale: I casi. Introduzione dell'area tematica IL CASO FAGIOLI Estratto dell'agenda dell'innovazione e del Trade Bologna 2011 Speciale: I casi Introduzione dell'area tematica IL CASO FAGIOLI Innovare e competere con le ICT: casi di successo - PARTE I Cap.1 Gestire

Dettagli

Data warehousing Mario Guarracino Data Mining a.a. 2010/2011

Data warehousing Mario Guarracino Data Mining a.a. 2010/2011 Data warehousing Introduzione A partire dagli anni novanta è risultato chiaro che i database per i DSS e le analisi di business intelligence vanno separati da quelli operazionali. In questa lezione vedremo

Dettagli

Il Business Performance Management & QlikView

Il Business Performance Management & QlikView Il Business Performance Management & QlikView 1 I SISTEMI DI SUPPORTO ALLE DECISIONI O DI BUSINESS INTELLIGENCE sono oggi considerati componenti di sistemi più ampi conosciuti come: CPM - CORPORATE PERFORMANCE

Dettagli

INDICE. Domande di riepilogo... 28 Esercizi di riepilogo... 28 Domande tematiche... 29. Prefazione... XI

INDICE. Domande di riepilogo... 28 Esercizi di riepilogo... 28 Domande tematiche... 29. Prefazione... XI 1138A_03 Prime pagine 1-03-2004 17:16 Pagina v INDICE Prefazione.......................................................................... XI Capitolo 1 L era dell informazione in cui viviamo. Il nuovo

Dettagli

SOLUTION BRIEF CA ERwin Modeling. Come gestire la complessità dei dati e aumentare l'agilità del business

SOLUTION BRIEF CA ERwin Modeling. Come gestire la complessità dei dati e aumentare l'agilità del business SOLUTION BRIEF CA ERwin Modeling Come gestire la complessità dei dati e aumentare l'agilità del business CA ERwin Modeling fornisce una visione centralizzata delle definizioni dei dati chiave per consentire

Dettagli

uadro Business Intelligence Professional Gestione Aziendale Fa quadrato attorno alla tua azienda

uadro Business Intelligence Professional Gestione Aziendale Fa quadrato attorno alla tua azienda Fa quadrato attorno alla tua azienda Professional Perché scegliere Cosa permette di fare la businessintelligence: Conoscere meglio i dati aziendali, Individuare velocemente inefficienze o punti di massima

Dettagli

Informatica Documentale

Informatica Documentale Informatica Documentale Ivan Scagnetto (scagnett@dimi.uniud.it) Stanza 3, Nodo Sud Dipartimento di Matematica e Informatica Via delle Scienze, n. 206 33100 Udine Tel. 0432 558451 Ricevimento: giovedì,

Dettagli

Data warehouse. Architettura complessiva con OLTP e OLAP OLTP. Sistemi di supporto alle decisioni

Data warehouse. Architettura complessiva con OLTP e OLAP OLTP. Sistemi di supporto alle decisioni Data warehouse Data warehouse La crescita dell importanza dell analisi dei dati ha portato ad una separazione architetturale dell ambiente transazionale (OLTP on-line transaction processing) da quello

Dettagli

d 2 i e Visual Data Mining : Un ambiente integrato per l estrazione della conoscenza dai dati della produzione industriale

d 2 i e Visual Data Mining : Un ambiente integrato per l estrazione della conoscenza dai dati della produzione industriale d 2 i e Visual Data Mining : Un ambiente integrato per l estrazione della conoscenza dai dati della produzione industriale O b i e t t i v o Rendere le informazioni esistenti in azienda liberamente fruibili

Dettagli

Sistemi informativi aziendali

Sistemi informativi aziendali Sistemi informativi aziendali Lezione 12 prof. Monica Palmirani Sistemi informativi e informatici Sistemi informativi = informazioni+processi+comunicazione+persone Sistemi informatici = informazioni+hardware+software

Dettagli

Data Warehouse Architettura e Progettazione

Data Warehouse Architettura e Progettazione Introduzione Data Warehouse Architettura! Nei seguenti lucidi verrà fornita una panoramica del mondo dei Data Warehouse.! Verranno riportate diverse definizioni per identificare i molteplici aspetti che

Dettagli

Estratto dell'agenda dell'innovazione e del Trade Padova 2011. Speciale: I casi. Introduzione dell'area tematica IL CASO ARTELECTRA

Estratto dell'agenda dell'innovazione e del Trade Padova 2011. Speciale: I casi. Introduzione dell'area tematica IL CASO ARTELECTRA Estratto dell'agenda dell'innovazione e del Trade Padova 2011 Speciale: I casi Introduzione dell'area tematica IL CASO ARTELECTRA Innovare e competere con le ICT: casi di successo - PARTE II Cap.2 Gestire

Dettagli

II Modulo Organizzazione dei Sistemi Informativi

II Modulo Organizzazione dei Sistemi Informativi II Modulo Organizzazione dei Sistemi Informativi DA CHE COSA E COMPOSTO COME SI ACCEDE CHI LO USA A CHE COSA SERVE Risorse hardware e software: - Server - LAN (router, HUB Firewall,..) - Storage - pacchetti

Dettagli

Una piattaforma di componenti interconnessi per la gestione della tua realtà complessa

Una piattaforma di componenti interconnessi per la gestione della tua realtà complessa Una piattaforma di componenti interconnessi per la gestione della tua realtà complessa La Problematica Negli ultimi tempi la sempre maggior quantità di informazioni necessarie alla vita e allo sviluppo

Dettagli

t.fabrica wanna be smarter? smart, simple, cost effectiveness solutions for manufactoring operational excellence.

t.fabrica wanna be smarter? smart, simple, cost effectiveness solutions for manufactoring operational excellence. t.fabrica wanna be smarter? smart, simple, cost effectiveness solutions for manufactoring operational excellence. Per le aziende manifatturiere, oggi e sempre più nel futuro individuare ed eliminare gli

Dettagli

ERP Commercio e Servizi

ERP Commercio e Servizi ERP Commercio e Servizi Sistema informativo: una scelta strategica In questi ultimi anni hanno avuto grande affermazione nel mercato mondiale i cosiddetti sistemi software ERP. Tali sistemi sono in grado

Dettagli

Le Basi di dati: generalità. Unità di Apprendimento A1 1

Le Basi di dati: generalità. Unità di Apprendimento A1 1 Le Basi di dati: generalità Unità di Apprendimento A1 1 1 Cosa è una base di dati In ogni modello di organizzazione della vita dell uomo vengono trattate informazioni Una volta individuate e raccolte devono

Dettagli

L'automazione nei processi industriali

L'automazione nei processi industriali L'automazione nei processi industriali Un processo industriale è l insieme delle operazioni che concorrono a trasformare le caratteristiche e le proprietà di materiali, tipi di energia e/o informazioni

Dettagli

Il modello di ottimizzazione SAM

Il modello di ottimizzazione SAM Il modello di ottimizzazione control, optimize, grow Il modello di ottimizzazione Il modello di ottimizzazione è allineato con il modello di ottimizzazione dell infrastruttura e fornisce un framework per

Dettagli

INFORMATION TECHNOLOGY PER LA LOGISTICA DI MAGAZZINO

INFORMATION TECHNOLOGY PER LA LOGISTICA DI MAGAZZINO INFORMATION TECHNOLOGY PER LA LOGISTICA DI MAGAZZINO Una logistica di successo Esperienza e competenza nate per garantire l implementazione di una efficiente Supply Chain Execution in mercati competitivi,

Dettagli

TiQ Green Energy Management: La soluzione IT per il continuo miglioramento dell utlizzo dell energia. You cannot Manage What you cannot Measure

TiQ Green Energy Management: La soluzione IT per il continuo miglioramento dell utlizzo dell energia. You cannot Manage What you cannot Measure TiQ Green Energy Management: La soluzione IT per il continuo miglioramento dell utlizzo dell energia You cannot Manage What you cannot Measure 1. Moduli di GEM Energy Monitoring Misurare è il primo passo

Dettagli

Novità di Visual Studio 2008

Novità di Visual Studio 2008 Guida al prodotto Novità di Visual Studio 2008 Introduzione al sistema di sviluppo di Visual Studio Visual Studio Team System 2008 Visual Studio Team System 2008 Team Foundation Server Visual Studio Team

Dettagli

White Paper. Operational DashBoard. per una Business Intelligence. in real-time

White Paper. Operational DashBoard. per una Business Intelligence. in real-time White Paper Operational DashBoard per una Business Intelligence in real-time Settembre 2011 www.axiante.com A Paper Published by Axiante CAMBIARE LE TRADIZIONI C'è stato un tempo in cui la Business Intelligence

Dettagli

2EASY.MES MANUFACTORING EXECUTION SYSTEM. Raccoglie i dati sulla produzione e li trasforma in informazioni

2EASY.MES MANUFACTORING EXECUTION SYSTEM. Raccoglie i dati sulla produzione e li trasforma in informazioni 2EASY.MES MANUFACTORING EXECUTION SYSTEM Raccoglie i dati sulla produzione e li trasforma in informazioni 2EASY.MES PER GESTIRE L AZIENDA IN EVOLUZIONE I SISTEMI MES I sistemi MES raccolgono i dati sulla

Dettagli

MAX DOLGICER. Quando SOA non è sufficiente: Ottenere Agilità con il BUSINESS PROCESS EVENT

MAX DOLGICER. Quando SOA non è sufficiente: Ottenere Agilità con il BUSINESS PROCESS EVENT LA TECHNOLOGY TRANSFER PRESENTA MAX DOLGICER Quando SOA non è sufficiente: Ottenere Agilità con il BUSINESS PROCESS EVENT ROMA 23-25 GIUGNO 2008 RESIDENZA DI RIPETTA - VIA DI RIPETTA, 231 info@technologytransfer.it

Dettagli

Ciclo di vita dimensionale

Ciclo di vita dimensionale aprile 2012 1 Il ciclo di vita dimensionale Business Dimensional Lifecycle, chiamato anche Kimball Lifecycle descrive il framework complessivo che lega le diverse attività dello sviluppo di un sistema

Dettagli

PBI Passepartout Business Intelligence

PBI Passepartout Business Intelligence PBI Passepartout Business Intelligence TARGET DEL MODULO Il prodotto, disponibile come modulo aggiuntivo per il software gestionale Passepartout Mexal, è rivolto alle Medie imprese che vogliono ottenere,

Dettagli

I PRINCIPI DELL EFFICIENZA PRODUTTIVA

I PRINCIPI DELL EFFICIENZA PRODUTTIVA Academy dell Efficienza I PRINCIPI DELL EFFICIENZA PRODUTTIVA Nino Guidetti Direttore Commerciale Grandi Clienti Schneider Electric Metodologia Lean Six Sigma Organizzazione snella, fortemente orientata

Dettagli

Microsoft Dynamics NAV 2009 REALIZZARE GLI OBIETTIVI

Microsoft Dynamics NAV 2009 REALIZZARE GLI OBIETTIVI Microsoft Dynamics NAV 2009 REALIZZARE GLI OBIETTIVI Una soluzione ERP integrata CONNETTERE Microsoft Dynamics NAV 2009 SEMPLIFICARE ANALIZZARE Microsoft Dynamics NAV 2009 è un ERP innovativo, flessibile

Dettagli

TECNICO SUPERIORE PER L APPROVVIGIONAMENTO

TECNICO SUPERIORE PER L APPROVVIGIONAMENTO ISTRUZIONE E FORMAZIONE TECNICA SUPERIORE SETTORE INDUSTRIA E ARTIGIANATO TECNICO SUPERIORE PER L APPROVVIGIONAMENTO STANDARD MINIMI DELLE COMPETENZE TECNICO PROFESSIONALI DESCRIZIONE DELLA FIGURA PROFESSIONALE

Dettagli

Sistemi Informativi Distribuiti

Sistemi Informativi Distribuiti Corso di Laurea Magistrale in Ingegneria Gestionale Corso di Sistemi Informativi Modulo II A. A. 2013-2014 SISTEMI INFORMATIVI MODULO II Sistemi Informativi Distribuiti 1 Sistemi informativi distribuiti

Dettagli

Economia e gestione delle imprese

Economia e gestione delle imprese Anno accademico 2008-2009 Economia e gestione delle imprese Prof. Arturo Capasso 1 2 1 Ciclo dell informazione PROGRAMMAZIONE Decisioni ESECUZIONE Informazioni CONTROLLO Risultati 3 Organizzazione e Sistema

Dettagli

Self-Service Business Intelligence

Self-Service Business Intelligence Self-Service Business Intelligence VISUALIZZA DATI, SCOPRI LE TENDENZE, CONDIVIDI I RISULTATI Analysis offre a tutti gli utenti aziendali strumenti flessibili per creare e condividere le informazioni significative

Dettagli

Gestire l informazione aziendale in modo strutturato e flessibile

Gestire l informazione aziendale in modo strutturato e flessibile ated Gestire l informazione aziendale in modo strutturato e flessibile Strumenti di Business Intelligence e Corporate Performance Management Conferenza ATED Manno, 20 settembre 2005 Ing. Roberto Fridel,

Dettagli

Un approccio complessivo alla Gestione della Performance Aziendale. Sestri Levante 19-20 maggio 2003

Un approccio complessivo alla Gestione della Performance Aziendale. Sestri Levante 19-20 maggio 2003 1 Un approccio complessivo alla Gestione della Performance Aziendale Sestri Levante 19-20 maggio 2003 Performing - Mission 2 Performing opera nel mercato dell'ingegneria dell organizzazione e della revisione

Dettagli

Var Group Approccio concreto e duraturo Vicinanza al Cliente Professionalità e metodologie certificate In anticipo sui tempi Soluzioni flessibili

Var Group Approccio concreto e duraturo Vicinanza al Cliente Professionalità e metodologie certificate In anticipo sui tempi Soluzioni flessibili Var Group, attraverso la sua società di servizi, fornisce supporto alle Aziende con le sue risorse e competenze nelle aree: Consulenza, Sistemi informativi, Soluzioni applicative, Servizi per le Infrastrutture,

Dettagli

Microsoft Dynamics NAV 2009 REALIZZARE GLI OBIETTIVI

Microsoft Dynamics NAV 2009 REALIZZARE GLI OBIETTIVI Microsoft Dynamics NAV 2009 REALIZZARE GLI OBIETTIVI Una soluzione ERP ALL AVANGUARDIA CONNETTERE Microsoft Dynamics NAV 2009 SEMPLIFICARE ANALIZZARE Microsoft Dynamics NAV 2009 è una soluzione di gestione

Dettagli

Sviluppo Applicazione di BI/DWH. con tecnologia Microsoft. per il supporto della catena logistica

Sviluppo Applicazione di BI/DWH. con tecnologia Microsoft. per il supporto della catena logistica UNIVERSITÀ DEGLI STUDI DI MODENA E REGGIO EMILIA Dipartimento di Ingegneria Enzo Ferrari di Modena Corso di Laurea Magistrale in Ingegneria Informatica (270/04) Sviluppo Applicazione di BI/DWH con tecnologia

Dettagli

GE Measurement & Control. Guida al software di gestione di calibrazione e manutenzione

GE Measurement & Control. Guida al software di gestione di calibrazione e manutenzione GE Measurement & Control Guida al software di gestione di calibrazione e manutenzione Introduzione Calibrazione e manutenzione della strumentazione di processo sono fondamentali per tutta una serie di

Dettagli

Business Intelligence

Business Intelligence aggregazione dati Business Intelligence analytic applications query d a t a w a r e h o u s e aggregazione budget sales inquiry data mining Decision Support Systems MIS ERP data management Data Modeling

Dettagli

Università di Venezia Corso di Laurea in Informatica. Marco Fusaro KPMG S.p.A.

Università di Venezia Corso di Laurea in Informatica. Marco Fusaro KPMG S.p.A. Università di Venezia Corso di Laurea in Informatica Laboratorio di Informatica Applicata Introduzione all IT Governance Lezione 5 Marco Fusaro KPMG S.p.A. 1 CobiT: strumento per la comprensione di una

Dettagli

Relazione sul data warehouse e sul data mining

Relazione sul data warehouse e sul data mining Relazione sul data warehouse e sul data mining INTRODUZIONE Inquadrando il sistema informativo aziendale automatizzato come costituito dall insieme delle risorse messe a disposizione della tecnologia,

Dettagli

CORSO DI FORMAZIONE PER: TECNICO DELLE ATTIVITA' DI PROGETTAZIONE, SVILUPPO E AGGIORNAMENTO DI SITI WEB

CORSO DI FORMAZIONE PER: TECNICO DELLE ATTIVITA' DI PROGETTAZIONE, SVILUPPO E AGGIORNAMENTO DI SITI WEB Avviso Pubblico PROV-BR 02/2013 PO FSE 2007/2013 ASSE II OCCUPABILITA' Formazione per Inserimento-Reinserimento Lavorativo Approvato con D.D. n.85 del 24/01/2014, pubblicata sul BURP n. 17 del 06/02/2014

Dettagli

La soluzione per le aziende di trasformazione, produzione e distribuzione

La soluzione per le aziende di trasformazione, produzione e distribuzione La soluzione per le aziende di trasformazione, produzione e distribuzione Tutti i processi in un'unica piattaforma software Il software Quadra di Quadrivium è una soluzione applicativa di Supply Chain

Dettagli

Specialisti della Supply Chain

Specialisti della Supply Chain Specialisti della Supply Chain Link Management Srl Via S. Francesco, 32-35010 Limena (PD) Tel. 049 8848336 - Fax 049 8843546 www.linkmanagement.it - info@linkmanagement.it Analisi dei Processi Decisionali

Dettagli

EASY. Sistema EASy SOLUTIONS. Effectiveness Analysis System

EASY. Sistema EASy SOLUTIONS. Effectiveness Analysis System EASY SOLUTIONS Sistema EASy Effectiveness Analysis System Easy Solutions Visione Garantire ciò che serve quando serve al minor costo possibile. Missione Rendere e mantenere affidabili i vostri impianti.

Dettagli

Introduzione ai software gestionali. Corso Gestione dei flussi di informazione

Introduzione ai software gestionali. Corso Gestione dei flussi di informazione Introduzione ai software gestionali Corso Gestione dei flussi di informazione 1 Integrazione informativa nelle aziende Problemi: frammentazione della base informativa aziendale crescente complessità organizzative

Dettagli

Termini che è necessario capire:

Termini che è necessario capire: Per iniziare 1........................................ Termini che è necessario capire: Hardware Software Information Technology (IT) Mainframe Laptop computer Unità centrale di elaborazione (CPU) Hard

Dettagli

BIG DATA: HISTORIANS RDB DATABASE RELAZIONALI

BIG DATA: HISTORIANS RDB DATABASE RELAZIONALI BIG DATA: HISTORIANS & RDB DATABASE RELAZIONALI DUE APPROCCI PER DATA COLLECTION E OTTIMIZZAZIONE DI PROCESSI ServiTecno srl Via Francesco Koristka, 10 20154 Milano (MI) Tel 02 486141 Fax 02 48614441 info@servitecno.it

Dettagli

1. Hard Real Time Linux (Laurea VO o specialistica)

1. Hard Real Time Linux (Laurea VO o specialistica) 20/9/06 Elenco Tesi Disponibili Applied Research & Technology Dept. La Società MBDA La MBDA Italia è un azienda leader nella realizzazione di sistemi di difesa che con i suoi prodotti è in grado di soddisfare

Dettagli

La prossima ondata di innovazione aziendale introdotta da Open Network Environment

La prossima ondata di innovazione aziendale introdotta da Open Network Environment Panoramica della soluzione La prossima ondata di innovazione aziendale introdotta da Open Network Environment Panoramica La crescente importanza dei ruoli assunti da tecnologie come cloud, mobilità, social

Dettagli

ideas > action > result

ideas > action > result ideas > action > result 1 M ISSION La OPT Solutions è una società di consulenza e progettazione software che opera nel settore industriale, si pone come obiettivo primario il recupero di efficienza e di

Dettagli

Ottimizzate i processi IT, massimizzate il ROA (return on assets) e migliorate il livello dei servizi

Ottimizzate i processi IT, massimizzate il ROA (return on assets) e migliorate il livello dei servizi Soluzioni per la gestione di risorse e servizi A supporto dei vostri obiettivi di business Ottimizzate i processi IT, massimizzate il ROA (return on assets) e migliorate il livello dei servizi Utilizzate

Dettagli

Sistemi informativi aziendali

Sistemi informativi aziendali Sistemi informativi aziendali Lezione 12 prof. Monica Palmirani Sistemi informativi e informatici Sistemi informativi = informazioni+processi+comunicazione+persone Sistemi informatici = informazioni+hardware+software

Dettagli

Economia e gestione delle imprese

Economia e gestione delle imprese Anno accademico 2007-2008 Economia e gestione delle imprese Prof. Arturo Capasso 1 2 Ciclo dell informazione PROGRAMMAZIONE Decisioni ESECUZIONE Informazioni CONTROLLO Risultati 3 1 Organizzazione e Sistema

Dettagli

SISTEMI INFORMATIVI AZIENDALI

SISTEMI INFORMATIVI AZIENDALI SISTEMI INFORMATIVI AZIENDALI Prof. Andrea Borghesan venus.unive.it/borg borg@unive.it Ricevimento: Alla fine di ogni lezione Modalità esame: scritto 1 Sistema informativo. Prima definizione Un sistema

Dettagli

Data warehouse Introduzione

Data warehouse Introduzione Database and data mining group, Data warehouse Introduzione INTRODUZIONE - 1 Pag. 1 Database and data mining group, Supporto alle decisioni aziendali La maggior parte delle aziende dispone di enormi basi

Dettagli

Relazione Pinakes3 Analisi modello di business (BOZZA) di Valeriano Sandrucci 08/09/07

Relazione Pinakes3 Analisi modello di business (BOZZA) di Valeriano Sandrucci 08/09/07 Relazione Pinakes3 Analisi modello di business (BOZZA) di Valeriano Sandrucci 08/09/07 1. Introduzione...3 1.2. Application vs Tool... 3 2. Componenti logiche di un modello... 6 3. Ontologie e Semantic

Dettagli

LABORATORIO di INFORMATICA

LABORATORIO di INFORMATICA Università degli Studi di Cagliari Corso di Laurea Magistrale in Ingegneria per l Ambiente ed il Territorio LABORATORIO di INFORMATICA A.A. 2010/2011 Prof. Giorgio Giacinto INTRODUZIONE AI SISTEMI DI BASI

Dettagli

CARATTERISTICA / MODULO

CARATTERISTICA / MODULO NextWare Doc è il prodotto che consente di amministrare semplicemente tutte le p roblematiche inerenti la gestione dei documenti; è rivolto sia la settore privato che alla Pubblica Amministrazione, e copre

Dettagli

PER UNA PUBBLICA AMMINISTRAZIONE DI QUALITÀ

PER UNA PUBBLICA AMMINISTRAZIONE DI QUALITÀ PER UNA PUBBLICA AMMINISTRAZIONE DI QUALITÀ La qualità dei servizi e delle politiche pubbliche è essenziale per la competitività del sistema economico e per il miglioramento delle condizioni di vita dei

Dettagli

1. SISTEMA INFORMATICO GESTIONALE

1. SISTEMA INFORMATICO GESTIONALE 1. SISTEMA INFORMATICO GESTIONALE 1.1 Introduzione Il sistema informatico gestionale, che dovrà essere fornito insieme ai magazzini automatizzati (d ora in avanti Sistema Informatico o semplicemente Sistema),

Dettagli

Progetto di Applicazioni Software

Progetto di Applicazioni Software Progetto di Applicazioni Software Antonella Poggi Dipartimento di Informatica e Sistemistica Antonio Ruberti SAPIENZA Università di Roma Anno Accademico 2008/2009 Questi lucidi sono stati prodotti sulla

Dettagli

MAGAZZINI MOVIMENTAZIONE DEI MATERIALI TRACCIABILITÀ COSTI DI PRODUZIONE PER COMMESSA

MAGAZZINI MOVIMENTAZIONE DEI MATERIALI TRACCIABILITÀ COSTI DI PRODUZIONE PER COMMESSA ak TRACK GESTIONE MAGAZZINI MOVIMENTAZIONE DEI MATERIALI TRACCIABILITÀ COSTI DI PRODUZIONE PER COMMESSA IL SISTEMA DI TRACCIABILITÀ DEI MATERIALI NELLA PRODUZIONE La norma ISO 8402 definisce la tracciabilità

Dettagli

CICLADI. Gestione delle dosature e della produzione. per il settore della gomma e delle mescole

CICLADI. Gestione delle dosature e della produzione. per il settore della gomma e delle mescole Come disporre di un sistema gestionale costantemente aggiornato con le informazioni provenienti dal processo produttivo? La risposta è in un sistema MES CICLADI Gestione delle dosature e della produzione

Dettagli

Basi di Dati Complementi Esercitazione su Data Warehouse

Basi di Dati Complementi Esercitazione su Data Warehouse Sommario Basi di Dati Complementi Esercitazione su Data Warehouse 1. Riassunto concetti principali dalle slide della lezione di teoria 2.Studio di caso : progettazione di un Data Warehouse di una catena

Dettagli

MIGLIORA L EFFICIENZA OPERATIVA LEAN PRODUCTION SOLUTIONS. www.imytech.it

MIGLIORA L EFFICIENZA OPERATIVA LEAN PRODUCTION SOLUTIONS. www.imytech.it MIGLIORA L EFFICIENZA OPERATIVA LEAN PRODUCTION SOLUTIONS www.imytech.it «NON È VERO CHE ABBIAMO POCO TEMPO, LA VERITÀ È CHE NE PERDIAMO MOLTO» Lucius Annaeus Seneca MIGLIORA LA PRODUZIONE CON WERMA SIGNALTECHNIK

Dettagli

Architetture Informatiche. Dal Mainframe al Personal Computer

Architetture Informatiche. Dal Mainframe al Personal Computer Architetture Informatiche Dal Mainframe al Personal Computer Architetture Le architetture informatiche definiscono le modalità secondo le quali sono collegati tra di loro i diversi sistemi ( livello fisico

Dettagli

MES E SOA UN WHITE-PAPER DI SANTIN E ASSOCIATI MASSIMO SANTIN GENNAIO 2007

MES E SOA UN WHITE-PAPER DI SANTIN E ASSOCIATI MASSIMO SANTIN GENNAIO 2007 MES E SOA UN WHITE-PAPER DI SANTIN E ASSOCIATI MASSIMO SANTIN GENNAIO 2007 SOA e MES Un white paper - 2006-2007 Santin e Associati http://www.santineassociati.com 2 MES E SOA SOA (Services Oriented Architecture)

Dettagli

Kaseya. Perché ogni azienda dovrebbe automatizzare la gestione dei sistemi IT

Kaseya. Perché ogni azienda dovrebbe automatizzare la gestione dei sistemi IT Kaseya è il software per la gestione integrata delle reti informatiche Kaseya controlla pochi o migliaia di computer con un comune browser web! Kaseya Perché ogni azienda dovrebbe automatizzare la gestione

Dettagli

Speciale: I casi. Introduzione dell'area tematica IL CASO FEDERAZIONE DELLE BCC DELL'EMILIA- ROMAGNA

Speciale: I casi. Introduzione dell'area tematica IL CASO FEDERAZIONE DELLE BCC DELL'EMILIA- ROMAGNA Estratto dell'agenda dell'innovazione e del Trade Bologna 2011 Speciale: I casi Introduzione dell'area tematica IL CASO FEDERAZIONE DELLE BCC DELL'EMILIA- ROMAGNA Innovare e competere con le ICT: casi

Dettagli

SISTEMI INFORMATIVI. Definizione, classificazioni

SISTEMI INFORMATIVI. Definizione, classificazioni SISTEMI INFORMATIVI Definizione, classificazioni IL SISTEMA INFORMATIVO AZIENDALE A cosa serve una definizione? a identificare i confini del SI a identificarne le componenti a chiarire le variabili progettuali

Dettagli

L evoluzione delle competenze verso il Database Manager

L evoluzione delle competenze verso il Database Manager L evoluzione delle competenze verso il Database Manager Workshop sulle competenze ed il lavoro dei Database Manager Milano, 1 marzo 2011 Elisabetta Peroni consulente sui sistemi di gestione dati (betty.peroni@gmail.com)

Dettagli

Industrial Automation. Siemens HMI. Standardizzazione dell'interfaccia utente per massimizzare l'efficienza. SIEMENS S.p.A. IA - AS - Gruppo HMI

Industrial Automation. Siemens HMI. Standardizzazione dell'interfaccia utente per massimizzare l'efficienza. SIEMENS S.p.A. IA - AS - Gruppo HMI Siemens HMI Standardizzazione dell'interfaccia utente per massimizzare l'efficienza Hardware L introduzione di nuove tecnologie sia hardware che software e la diminuzione dei costi dei componenti ha modificato

Dettagli

Implementazione di soluzioni di ricerca per le aziende

Implementazione di soluzioni di ricerca per le aziende Implementazione di soluzioni di ricerca per le aziende Le soluzioni di ricerca per le aziende permettono agli utenti di sfruttare al massimo le informazioni di cui dispongono al fine di migliorare la loro

Dettagli

Si sente spesso parlare di Performance per identificare

Si sente spesso parlare di Performance per identificare Il Performance Management a supporto del miglioramento organizzativo di Roberto Bugatti e Marco Tottoli 1 Si sente spesso parlare di Performance per identificare concetti simili ma di fatto diversi tra

Dettagli

STRUMENTAZIONE. Il Sistema di supervisione e acquisizione dati: S.C.A.D.A. APPARATI SINGOLI MASTER RETE LOCALE SUPERVISIONE

STRUMENTAZIONE. Il Sistema di supervisione e acquisizione dati: S.C.A.D.A. APPARATI SINGOLI MASTER RETE LOCALE SUPERVISIONE Il Sistema di supervisione e acquisizione dati: S.C.A.D.A. Ing.Francesco M. Raimondi www.unipa.it/fmraimondi Lezioni del corso di Automazione Industriale Dipartimento di Ingegneria dell Automazione e dei

Dettagli