Sistemi Informativi Aziendali PDF

Sistemi Informativi Aziendali Appunti per il corso Luca Ardito Fulvio Corno Marco Torchiano Politecnico di Torino – Dipartimento di Automatica e Informatica Versione 0.9.1 30 novembre 2022 ...

Sistemi Informativi Aziendali Appunti per il corso Luca Ardito Fulvio Corno Marco Torchiano Politecnico di Torino – Dipartimento di Automatica e Informatica Versione 0.9.1 30 novembre 2022  I NDICE Indice i 1 Introduzione 1 1.1 Presentazione........................................ 1 2 Definizione di sistema informativo 3 2.1 Definizione.......................................... 4 2.1.1 Dati e Informazioni................................ 5 2.1.2 Materiale vs. Immateriale............................ 5 2.1.3 Gestione delle informazioni........................... 7 2.1.4 Organizzazione................................... 7 2.2 Punti di vista del SI.................................... 8 2.3 Modello funzionale..................................... 9 2.3.1 Dati.......................................... 10 2.3.2 Processi....................................... 10 2.3.3 Interazioni...................................... 11 2.3.4 Esempio di processo................................ 11 2.4 Modello IT.......................................... 14 2.4.1 Modello tecnologico (Hardware)........................ 14 2.4.2 Modello Applicativo (Software)......................... 15 2.5 Modello Organizzativo................................... 17 3 Famiglie di sistemi informativi 19 3.1 Classificazione........................................ 19 3.1.1 Livelli e Funzioni................................. 20 3.1.2 Contenuto informativo.............................. 21 3.1.3 Modello a T..................................... 22 3.2 Livelli organizzativi e funzioni.............................. 23 3.2.1 Livello operativo.................................. 24 3.2.2 Livello gestionale................................. 24 3.2.3 Livello strategico.................................. 25 3.2.4 Tipologie di SI................................... 25 3.3 Processi di Supporto.................................... 26 3.3.1 Processi amministrativi............................. 27 3.3.2 Procesi per le Risorse umane.......................... 27 3.3.3 Processi per i sistemi informativi....................... 27 3.4 Processi di gestione..................................... 28 3.4.1 Controllo....................................... 29 3.4.2 Decisioni strategiche............................... 29 3.5 Processi primari....................................... 29 3.5.1 Catena del Valore (Value Chain)........................ 31 3.5.2 Catena di fornitura (Supply Chain)...................... 31 3.5.3 Segmentazioni per dominio........................... 32 4 Modellazione concettuale 39 i ii INDICE 4.1 Linguaggi di modellazione e UML........................... 39 4.2 Livelli di astrazione.................................... 40 4.3 Classi............................................. 41 4.3.1 Classe......................................... 41 4.3.2 Oggetto........................................ 42 4.3.3 Attributi....................................... 42 4.4 Associazioni......................................... 43 4.4.1 Definizione di Associazione........................... 43 4.4.2 Molteplicità delle associazioni......................... 45 4.4.3 Interpretazione operativa............................ 46 4.4.4 Association class.................................. 47 4.4.5 Aggregazione.................................... 48 4.5 Generalizzazione e specializzazione.......................... 49 4.6 Metodo di analisi...................................... 51 4.6.1 Procedura...................................... 51 4.6.2 Qualità dei modelli concettuali......................... 52 4.6.3 Pattern di modellazione............................. 52 4.7 Esempio di analisi..................................... 56 5 Modellazione di processo 63 5.1 Modelli di processo e workflow.............................. 63 5.1.1 Modello di processo................................ 63 5.1.2 Workflow....................................... 64 5.2 BPMN: elementi base................................... 64 5.2.1 Attività........................................ 65 5.2.2 Eventi terminali.................................. 66 5.2.3 Flusso di esecuzione................................ 66 5.2.4 Gateway....................................... 66 5.2.5 Semantica di esecuzione............................. 66 5.3 BPMN: costrutti base................................... 67 5.3.1 Sequenza....................................... 67 5.3.2 Parallelo....................................... 68 5.3.3 Scelta esclusiva................................... 69 5.3.4 Pool e Swimlane.................................. 71 5.3.5 Commenti e connettori.............................. 72 5.4 BPMN: costrutti complessi................................ 72 5.4.1 Processi strutturati................................ 72 5.4.2 Ciclo strutturato.................................. 73 5.4.3 Terminazione implicita ed esplicita...................... 74 5.4.4 Scelta implicita................................... 75 5.4.5 Azione complessa................................. 76 5.5 BPMN: eventi........................................ 78 5.5.1 Eventi temporali.................................. 78 5.5.2 Messaggi....................................... 80 5.5.3 Segnali........................................ 81 5.5.4 Scelta differita................................... 82 5.6 BPMN: eventi asincroni.................................. 83 5.6.1 Eventi a margine.................................. 84 5.6.2 Sotto-processi per eventi............................. 85 5.7 Esempio di modellazione di processo.......................... 86 5.7.1 Processo....................................... 86 6 Formalizzazione dei requisiti 89 6.1 Processo di Sviluppo del Software............................ 89 6.2 Specifica dei requisiti................................... 90 6.3 Tipologie di requisiti.................................... 91 INDICE iii 6.4 Qualità del software.................................... 92 6.5 Documento dei Requisiti................................. 92 7 Requisiti funzionali e casi d’uso 97 7.1 Definizione di Caso d’Uso................................. 97 7.1.1 Attori e obiettivi.................................. 99 7.1.2 Contesto....................................... 100 7.2 Diagrammi dei casi d’uso................................. 100 7.2.1 Relazioni....................................... 101 7.2.2 Livelli di dettaglio (Granularità)........................ 103 7.3 Narrativa dei Caso d’Uso................................. 106 7.3.1 Template....................................... 106 7.3.2 Main Success Scenario.............................. 107 7.3.3 Extensions...................................... 109 7.3.4 Trigger........................................ 111 7.3.5 Processo di scrittura di un caso d’uso..................... 111 7.4 Esempio - Lista d’attesa al ristorante......................... 113 7.4.1 Identificazione degli attori............................ 114 7.4.2 Diagramma dei casi d’uso............................ 114 7.4.3 Narrative dei casi d’uso.............................. 115 8 Web Information Systems 121 8.1 Web Information System................................. 121 8.2 Basic Web Architecture.................................. 122 8.2.1 Server HTTP.................................... 123 8.2.2 Misure di prestazioni............................... 123 8.3 Server-side Applications.................................. 124 8.3.1 Application server................................. 124 8.3.2 Database server.................................. 124 8.4 Client-side Applications.................................. 125 8.4.1 Javascript...................................... 126 8.4.2 AJAX......................................... 126 8.5 Real-world challenges................................... 126 9 Progettazione delle interazioni utente 129 10 Stima dei costi 131 10.1 Stima tramite misure................................... 132 10.1.1 Function points................................... 132 10.2 Use case points....................................... 133 10.2.1 Calcolo Actors Weight............................... 134 10.2.2 Calcolo Use Case Weight............................. 134 10.2.3 Calcolo Unadjusted Use Case Points..................... 135 10.2.4 Technical Complexity Factors.......................... 135 10.2.5 Environmental Complexity Factors...................... 138 10.2.6 Calcolo della produttività............................ 140 10.3 Esempio............................................ 141 11 Indicatori di performance 143 11.1 Management IS....................................... 143 11.2 Cenni di teoria della misura............................... 146 11.2.1 Definizioni...................................... 146 11.2.2 Modello concettuale della misurazione.................... 147 11.2.3 Teoria della misura................................ 148 11.2.4 Affermazioni sulle misure............................ 150 11.2.5 Scale di misura................................... 151 iv INDICE 11.3 Key Process Indicators.................................. 155 11.3.1 Categorie di KPI.................................. 156 11.3.2 Definizione dei KPI................................ 160 11.3.3 Applicazione dei KPI a un caso concreto.................... 161 Bibliografia 165  CAPITOLO 1 I NTRODUZIONE All things begin with one Isshinkai Manual 1.1 Presentazione Questo libro contiene la raccolta delle dispense dell’insegnamento di Sistemi Informati- vi Aziendali tenuto nel Corso di Laurea Magistrale in Ingegneria Gestionale presso il Politecnico di Torino. Gli argomenti presentati hanno delle dipendenze che sono illustrate in figura 1.1. Non tutti gli argomenti trattati in questa collezione fanno parte del programma attuale dell’insegnamento; si è scelto di lasciarli comunque perchè rappresentano temi rilevanti per i sistemi informativi. 2. Definizione di SI Sistemi Informativi 3. Famiglie di SI 11. Indicatori di 8. Web Information Modellazione performance Systems 4. Concettuale 5. Di processo 6. Dei requisiA 10. Stima dei costi 9. Interazioni 7. Casi d’uso utente Figura 1.1: Dipendenze tra gli argomenti 1  CAPITOLO 2 D EFINIZIONE DI SISTEMA INFORMATIVO As a general rule the most successful man in life is the man who has the best information. Benjamin Disraeli Un sistema informativo (SI, o Information System, IS) è un sistema che memorizza ed elabora informazioni utilizzate per il funzionamento di una organizzazione. Un sistema informativo gestisce informazioni utilizzate per supportare le azioni svolte all’interno di un’organizzazione: Decisioni, Controllo dei processi, Esecuzione delle attività primaria dell’azienda (produzione o erogazione di servizi). Il sistema informativo rappresenta un punto di incontro di vari aspetti, un’intersezione tra: Struttura organizzativa: di un organizzazione, che prevede unità ed allocazione di compiti e resposnsabilità, Management: metodi e strategie per la gestione, Tecnologia: strumenti tecnologici per il supporto alle attività svolte nell’organizzazio- ne. In linea di principio non è necessariamente vero che un sistema informativo utilizza sistemi informatici per far circolare le informazioni. La circolazione dell’informazione può infatti avvenire anche utilizzando supporti cartacei, fogli, moduli, o tramite le persone, o attraverso scambio di oggetti, ecc. Tuttavia tutti i sisemi informativi moderni sono basati su sistemi informatici. Sistema informativo consiste in: Componente Hardware Componente Software Conoscenza tecnica (know-how) Conoscenza organizzativa Si tratta quindi più di un sistema informatico (computer system) che normalmente comprente solamente i primi due elementi. Come ogni sistema complesso, un sistema informativo non può essere descritto da un solo punto di vista ma utilizzando più punti di vista. 3 4 CAPITOLO 2. DEFINIZIONE DI SISTEMA INFORMATIVO ENVIRONMENT Customers Suppliers ORGANIZATION INFORMATION SYSTEM INPUT PROCESS OUTPUT FEEDBACK Regulatory Stockholders Competitors Agencies Figura 2.1: Il contesto in cui si inserisce il sistema informativo 2.1 Definizione Un Sistema informativo è un insieme di elementi correlati che lavorano as- sieme per raccogliere, elaborare, immagazzinare e disseminare informazioni a supporto di decisioni, coordinamento, controllo e analisi all’interno di un’orga- nizzazione. La realizzazione del sistema informativo come aggregazione di moduli indipendenti è nata per dare risposta all’esigenza di cambiamento ed evoluzione nel tempo del SI. Esso deve infatti essere sempre in grado di soddisfare le esigenze di chi lo utilizza e quindi potersi sviluppare e adattare nel tempo con relativa facilità. Come illustrato in figura 2.1, un SI serve un organizzazione e agevola le operazioni della stessa. Esso necessita di componenti per acquisire info, per elaborarle e per fornire risultati in output. Tutti i sistemi dotati di tali caratteristiche vengono detti IS. Si presuppone che l’output generi, in maniera più o meno diretta, dei risultati o feedback. Per poter concepire, definire e progettare un SI è necessario identificare 1. gli Input, ovvere i dati grezzi che vengono raccolti o catturati all’interno dell’organiz- zazione; 2. gli Output, ovvero la disseminazione di informazioni elaborate alle persone che le useranno 3. l’elaborazione, ovvero le operazioni di trasformazione, aggregazione ed immaggazzi- namento scolve sulle informazioni. Il sistema informativo è inserito all’interno di un’organizzazione, per la quale si intende una qualsiasi entità che svolge attività per uno scopo. L’organizzazione si inserisce all’interno di un certo ambiente (Enviroment), che com- prende i fornitori, i clienti ed eventualemente sono i principali concorrenti. Fondamentale per il funzionamento e la progettazione dell’IS è il contesto dell’orga- nizzazione. Si considerano dunque clienti e fornitori, così come altri elementi quali: en- ti regolatori che definiscono l’insieme di vincoli (es: regolamentazioni sulla produzione), stockholders e competitors. 2.1. DEFINIZIONE 5 2.1.1 Dati e Informazioni È importante, parlando di sistemi informativi fare una precisazione sul termine informa- zioni e distinguerlo da quello di dati: dati i dati sono sequenze di semplici fatti, che rappresentano eventi che accadono all’in- terno di un’organizzazione (ad esempio transazioni commerciali) o nel mondo fisico, prima che siano stati organizzati e disposti in una forma che possa essere compresa ed utilizzata dalle persone. Un semplice numero a se stante (o una sequenza di numeri) è un esempio di un dato: 42. informazioni sono dati a cui è stata data un forma che ha un significato per gli esse- ri umani all’interno dei processi che avvengono nell’organizzazione, ad esempio il prendere decisioni. Il numero interpretato come la misura di qualche fenomeno rilevante per il funzio- namento dell’organizzazione rappresenta un esempio di informazione: 42 scatole di un prodotto ordinate. Mi permette ad esempio di capire se le scatole ordinate sono disponibili a magazzino o se è necessario avviare la produzione. 2.1.2 Materiale vs. Immateriale Le informazioni, che rappresentano l’entità trattata dai SI, introducono una nuova dimen- sione che è quella immateriale. È bene sottolineare come le informazioni (ed i dati) sebbene immateriali (ovvero non corrispondenti ad un oggetto meteriale) non sono virtuali ma sono bensì reali e concrete, infatti e sulla loro base si svolgono azioni e si prendono decisioni. Il confronto tra la dimensione materiale ed immateriale è ben descritta da S.Quintarelli ed è sintetizzata, per gli aspetti rilevanti ai SI, nella tabella 2.1 Tabella 2.1: Caratteristi fondamentali delle dimensioni materiale ed immateriale (adattata da ) Dimensione: Materiale Immateriale Produzione CCC CCCC CC Riproduzione CCCC Ccent Immaggazinamento CC Ccent Trasferimento CC Ccent Trasferimento   Durata Perishable Eternal Intergrazione Disconnected Connected Rivalità Rivalrous Non-rivalrous Escludibilità Maximum Marginal Ritorni Decreasing Increasing In termini di costi di produzione, i beni materiali hanno un costo iniziale di sviluppo ed un costo variabile relativo alle materie prime ed alla produzione, i beni e servizi imma- teriali hanno un costo legato allo sviluppo ed un costo variabile trascurabile di produzione / erogazione. Questo perchè la riproduzione delle informazioni ha attualmente un costo infinite- simo rispetto alla produzione di beni materiali. Per riprodurre software, ad esempio per installare una App sul nostro smartphone, il costo è quello necessario al server dell’app store per recuperare i dati ed inviarli. I costi di immaggazzinamento dei beni materiali possono essere elevati, non solo per il volume occupato, ma anche per il packaging ed eventuali attrezzature per ragioni di 6 CAPITOLO 2. DEFINIZIONE DI SISTEMA INFORMATIVO sicurezza. Le informazioni possono essere memorizzate in dispositivi molto compatti e con costi molti ridottiEh s Secondo dati recenti i costi delle memorie sono molto bassi: 2.800$ / GByte per la RAM1 0.019$ / GByte per hard disk2 0.080$ / GByte per dischi allo stato solido (SSD)3 Il trasferimento di oggetti materiali è costoso e dipende da volume, peso e caratteri- stiche dei beni, oltre che dalla distanza. Il trasferimento di informazioni è estremamente economico: il costo di tasferimento dei dati su internet è praticamente trascurabile. Ol- tre al costo, il trasferimento di informazioni, nella dimensione immateriale, è agli effetti pratici immediato. Nella realtà limitato dalla velocità di trasmissione dei segnali elettrici, ovvero la velocità della luce. Un aspetto importante della dimensione immateriale è che è naturalmente connessa, i diversi frammenti di informazione sono (ad esempio tramite internet) collegati tra loro e le applicazioni che ne hanno bisogno possono scambiarseli facilmente. La diffusione e la connessione sono la base del paradigma chiamato Internet of Things (IoT): la rete di oggetti fisici che contengono al loro interno (embedded) la tecnologia per comunicare, rilevare or integire con il proprio stato interno o con l’ambiente esterno. Un aspetto chiave dell’informazione è la non rivalità nel suo uso: è possibile che più persone consumino contemporaneamente la stessa informazione (grazie alla facilità di riproduzione e di trasferimento). Mentre questo spesso non è vero per i beni materiali. Inoltre naturalmente l’informazione non è escludibile, non è possibile impedire l’uso dell’informazione dopo che uno ne è entrato in possesso. Mentre è possibile per beni e ser- vizi impedire o limitare l’uso. Per poter avere la possibilità di escludere l’uso dell’informa- zione è necessario adottare meccanismi di Digital Rights Management (DRM) che tramite diversi meccanismi (ad es. crittografia ed ambienti protetti per la fruizione) impediscono (anche a distanza) l’uso dell’informazione. Un altro importante aspetto che caratterizza la dimensione immateriale dell’informa- zione (e di SI che la manipolano) sono i ritorni crescenti (increasing returns). Quan- do un’organizzazione produce prodotti (o servizi) ci sono due possibilità secondo la teoria economica: ritorni decrescenti: prodotti o aziende che iniziano a dominare un mercato prima o poi raggiungono dei limiti, questo porta a raggiungere un equilibrio (predicibile) di prezzi e quote di mercato. I limiti riguardano principalmente le risorse (materie prime) e la dimensione del mercato. Questo tipo di economia è tipica della produzione in massa di prodotti materiali. ritorni crescenti: un prodotto o azienda (o tecnologia) – uno tra tanti che competono in un mercato – inizia a dominare un mercato per puro caso o per attenta strategie, tale vantaggio viene amplificato, e il prodotto o azienda (o tecnologia) può procedere e bloccare il mercato (lock in). Questo tipo di economia è tipica dell’industria high tech. I fattori che portano ad un mercato a ritorni crescenti tipici di molti prodotti e servizi high tech sono: Costi anticipati (up-front): i costi di ricerca a sviluppo sono grandi rispetto ai costi di produzione unitaria 1 Memory prices: https://jcmit.net/memoryprice.htm 2 Disk drives prices: https://jcmit.net/diskprice.htm 3 Flash and SSD prices: https://jcmit.net/flashprice.htm 2.1. DEFINIZIONE 7 Effetto di rete: i prodotti devono essere compatibili con una rete di altri utenti, cambiare prodotto ridurrebbe tale compatibilità. Familiarità e confidenza: i prodotti sono complessi, una volta che gli utenti han- no investito per l’apprendimento, preferiscono aggiornare le conoscenze le versioni successive dello stesso prodotto invece di cambiarlo. 2.1.3 Gestione delle informazioni La gestione delle informazioni effettuata da un SI è finalizzata a dare un supporto alle atti- vità che vengono svolte all’interno dell’organizzazione. Possiamo identificare due principali tipi di azioni: automazione di attività (altrimenti manuali): la focalizzazione è sulla produttivi- tà delle attività, che viene incrementata tramite la sostituzione di (parte di) lavoro umano con la tecnologia supporto alle decisioni: qui l’obiettivo è di raccogliere la maggior quantità possibile di informazione rilevante per poter avere una base solida su cui prendere le decisioni (informed decisions). Inoltre un SI permette di valutare nella maniera più veloce e precisa un elevato numero di alternative nelle decisioni. Oltre a questi vantaggi, la gestione ed elaborazione delle informazioni tramite i SI ha ovviamente dei costi che sono misurabili dovuti a: acquisto o licenze di hardware e software, addestramento del personale e gestione del sistema. È decisamente più difficile quantificare precisamente i benefici derivanti da un investi- mento in un SI. Si tratta principalmente di riduzione dei tempi e/o costi. Il rischio è che tali vantaggi vengano considerati come scontati e che manchi il supporto per tale tipo di investimenti. 2.1.4 Organizzazione Quando ci si riferisce all’organizzazione si intende un’entità complessa che include diversi aspetti: persone che operano all’interno dell’organizzazione: manager, lavoratori della conoscen- za, lavoratori di produzione o di servizio; struttura : il diagramma organizzativo, la distribuzione geografica, i gruppi di specialisti, i team che seguono dei prodotti; funzioni aziendali , ovvero il compito specifico svolto da un’unità all’interno dell’organiz- zazione, ad esempio: contabilità; processi , ovvero come vengono organizzate e coordinate le attività. Quando si parla di funzioni aziendali ci si riferisce ad una suddivisione spesso standard: produzione o manifattura vendite marketing finanza contabilità risorse umane 8 CAPITOLO 2. DEFINIZIONE DI SISTEMA INFORMATIVO Un SI è in grado di integrare diverse attività svolte da diverse funzioni aziendali all’in- terno di un process. Si intende per processo il modo caratteristico in cui un’organizzazione coordina ed or- ganizza le attività, le informazioni e la conoscenza per produrre un bene o servizio. Talvolta si userà, in alternativa al termine organizzazione, quello di azienda. Un’azien- da è un particolare tipo di organizzazione che produce beni o servizi per un profitto. 2.2 Punti di vista del SI Un sistema informativo può essere rappresentato da diversi punti di vista. Per questo sono stati categorizzati nelle seguenti tipologie: 1. Tecnologico: ci dice con quali tecnologie è fatto il SI, nonché le componenti che ne fanno parte, 2. Funzionale: ci dice cosa fa il SI, quali sono i dati che deve gestire e quali sono le funzioni che deve svolgere. 3. Organizzativo: riguarda il livello aziendale in cui il sistema si inserisce. Evoluti- vo: il sistema informativo deve aiutarmi a gestire cambiamenti nei processi e nelle attività aziendali, non può bloccare le scelte di business. Esso cambia ed evolve in parallelo all’ente che lo usa. Fondamentale per lo studio da questo punto di vista è la documentazione riguardante le metodologie di processo. All’interno di un SI di un’azienda nuove tecnologie entrano in uso soppiantando quel- le vecchie. Tuttavia in un dato istante, un’orgasnizzazione ha al suo interno un mix di tecnologie diverse che si devono integrare tra loro, ossia l’azienda deve essere in grado di gestirle tutte insieme. Lo specifico mix di tecnologie non è una costante, ma cambia nel tempo. Valutare i due aspetti innovativo e conservativo è sempre molto importante: l’introduzione dell’aspetto innovativo, se coerente con l’assetto organizza- tivo aziendale, può infatti portare ad una diminuzione dei costi. Dall’altra non si può ignorare l’impatto negativo che l’innovazione può portare sull’intera organizzazione a causa della sua inerzia al cambiamento. 4. Economico: il fatto di avere alcune funzioni aziendali gestite dal SI porta da un lato a dei costi ma dall’altro dei benefici in termini di maggiore qualità, minor numero di errori e implementazioni più efficienti in termini di tempo. 5. Transazionale: riguarda come il sistema informativo gestisce i dati e le loro mo- difiche. I dati non vengono scambiati solo all’ interno dell’azienda, ma anche con l’esterno. I dati gestiti e scambiati all’esterno possono infatti avere effetti all’esterno dell’azienda. 6. Di progetto: è la parte legata all’ ingegneria del software e alla gestione del progetto per realizzare il sistema informativo. 7. Decisionale: Il sistema informativo gestendo tutte le attività, contiene in sé tutti i dati in aggregato. Questi dati possono quindi essere analizzati al fine di ricavare degli indicatori di sintesi che permettono di prendere le decisioni (KPI). Il sistema informativo è quindi anche di supporto ai processi decisionali. I sistemi informativi si distinguono in sistemi informativi privati (aziendali) e i sistemi informativi pubblici. I due sistemi informativi si rivolgono a utenti differenti e di conse- guenza pongono l’attenzione su aspetti diversi. Il team di progetto di una azienda punta a realizzare un sistema informativo adatto alle funzioni dell’azienda. Esso dovrebbe essere progettato per essere usato facilmente dai propri dipendenti (anche se nella maggior parte dei casi nella fase di progettazione i dipendenti non vengono interpellati). 2.3. MODELLO FUNZIONALE 9 (what?) (how?) (who?) Figura 2.2: Principali punti di vista sui sistemi informativi I sistemi informativi pubblici invece sono progettati con l’obiettivo di mantenere gli utenti sul sito: risulta quindi importante la facilità d’uso dell’interfaccia. Questo dimostra un’attenzione molto forte al cliente/utente. I principali punti di vista rispetto ai quali in questo testo analizzeremo un sistema informativo sono i tre illustrati in figura 2.2: Funzionale: Quali attività deve svolgere sistema Organizzativa: Chi deve fare quale attività Tecnologica: Come queste attività possono essere svolte (implementazione) Questi tre punti di vista non sono alternativi ma si completano nel fornire una descri- zione (modello) di un sistema informativo. 2.3 Modello funzionale Il modello funzionale come già accennato si occupa di cosa fa il sistema senza concentrarsi sul come lo faccia. Nel modello funzionale si cercano quali sono le informazioni che il siste- ma gestisce e come si sviluppano i dati; a valle di questo si devono poi costruire i processi che vengono poi concretizzati tramite interfacce in base alla tipologia di informazione e a chi ne fa uso. Il modello funzionale è composto principalmente da: 1. Dati/informazioni : quali sono le informazioni che il sistema informativo gestisce, utili allo svolgimento del processo. 2. Processi: quali sono le operazioni e le azioni che vengono svolte sui dati, sia dagli utenti che in autonomia da parte del SI. Quali sono le regole per decidere, quali azioni svolgere, quando e da chi vengono svolte. 3. Interazioni: sono i momenti in cui gli utenti ed il sistema si scambiano informazioni. In generale l’interazione tra un utente ed il SI avviene per poter permettere all’utente di raggiungere un proprio obiettivo. 10 CAPITOLO 2. DEFINIZIONE DI SISTEMA INFORMATIVO Process Interactions Functional Model Data IS Model IT Model Organizational Model Figura 2.3: Modello funzionale 2.3.1 Dati Le informazioni sono descritte grazie ad un modello concettuale (UML Class Diagram) , linguaggio di descrizione delle informazioni visuale e grafica (si veda il capitolo 4). Non è un modello direttamente traducibile nella struttura di un database, il modello concettuale rappresenta il punto di arrivo di una fase di analisi del problema in cui si risponde a tre domande fondamentali: quali sono i concetti principali trattati dal SI? Quali sono le caratteristiche, i dati, che caratterizzano tali concetti? Quali sono le relazioni che legano i concetti identificati? I dati su cui operano i SI sono solitamente di due categorie principali: master data : sono dati che rappresentano informazioni statiche, che non cambiano una volta raccolte dal SI, o cambiano molto raramente. Ad esempio, le informazioni su clienti e fornitori, il listino dei prodotti. transactional data : sono dati che riguardano eventi e vengono aggiornati e creati molto frequentemente. Ad esempio: i nuovi ordini, il materiale ricevuto, la registrane degli ingressi. 2.3.2 Processi I processi possono essere descritti con diverse notazioni ed a vari livelli di dettaglio. Ten- denzialmente si utilzzano notazioni grafiche che sono sintetiche e relativamente facili e veloci da comprendere (si veda il capitolo 5). Si possono utilizzare notazioni semi-formali come ad esempio i diagrammi di attivi- tà (Activity Diagram) UML. Oppure con notazioni formali, che hanno una semantica più precisa e meno ambigua, come BPMN (Business Process Modeling and Notation). 2.3. MODELLO FUNZIONALE 11 2.3.3 Interazioni Oltre a specificare quali informazioni (dati) sono trattate e quale flusso di lavorazione de- vono seguire (processi), è importante definire come il SI informativo interagisce con gli utenti. È bene ricordare che un SI deve essere pensato per aiutare gli utenti a svolgere in maniera più semplice ed efficiente il proprio lavoro. Le interazioni possono essere descrotte a diversi livelli di astrazione: contesto: quali sono gli obiettivi (degli utenti) che il sistema permette di raggiungere dettaglio di uso: quali passi vengono seguiti nello scambio di interazioni tra SI e utenti esperienza dell’utente: come è strutturata l’interfaccia utente che consente di svolgere i diversi passi dell’interazione Uno strumento adottato per descrivere i primi due aspetti è rappresentato dai casi d’uso (si veda il capitolo 7). Mentre l’esperienza dell’utente può essere modellata definendo dei mock-up dell’interfaccia che il sistema presente (si veda il capitolo 9). 2.3.4 Esempio di processo A titolo di esempio, consideriamo un reparto di produzione di una società di medie dimen- sioni. Tale società deve fare una serie di ordini per Materie prime in modo tale da far funzionare il processo di produzione. Tali materiali devono essere: Ordinati Esaminati per verificarne la qualità Immagazzinati Registrati contabilmente Pagati Ogni operazione suddetta deve essere inoltre controllata. Questo semplice processo richiede almeno 8 attori, ovvero figure che interagiscono per portare avanti tutta questa serie di attività: 1- Produzione Production: requires the raw materials needed for the the production plans from the warehouse 2- Magazzino Warehouse: when the raw material is not available, first make a request to the pur- chase office; once the order has been received checks the quality, conformance to request, and stores it. 3- Ufficio acquisti Purchase office: in charge of negotiating price, quantity, and delivery time with different suppliers 4- Fornitori Supplier: the one chosen to fulfill the order, must deliver the raw materials to the warehouse, and possibly get back the portion not complying with the specifications 5-Ufficio qualità Quality assurance: monitors the efficiency and quality of suppliers by producing statistics for the management 12 CAPITOLO 2. DEFINIZIONE DI SISTEMA INFORMATIVO Accounting Production 9 (Administration) 1 5C 7 8B Purchase 2 Warehouse 5A 3 4 5B Finance Quality Supplier Assurance 8A 6 Figura 2.4: Esempio: processo operativo 6-Contabilità Accounting: check the orders, receive the delivery receipt from the warehouse, ask the finance department to execute the payment of the supplier invoice, records all transactions 7-Manager Manager: is a role external to the individual business process that supervises the good working of the enterprise system and controls the economical efficiency. Needs information to take decisions. 8-Ufficio finanziario Finance department: fiscally performs the payment to the supplier and then informs the accounting Gli attori sono il primo componente che ci serve per descrivere un processo: Chi è coin- volto nelle operazioni è la prima cosa da capire. La seconda cosa da capire sono le attività che costituiscono il processo, ovvero cosa ogni attore fa. Nel caso in esame avremo i vari attori descritti e una serie di passi da eseguire (Figura): 1- Reparto di produzione chiede a magazzino se materiale è presente. 2- Se materiale non presente, magazzino ordina a ufficio acquisti il materiale 3- Ufficio acquisti negozia con fornitori prezzo e quantità 4- Fornitore fornisce materiale precedentemente richiesto 5A-Materiale consegnato sottoposto a controllo qualità 5B-Eventuale materiale fallato è restituito al fornitore 5C- Materiale non fallato viene immagazzinato ed il costo dell’ordine segnalato dalla contabilità 6-Fornitore nel frattempo invia una fattura dell’ordine soddisfatto alla contabilità 2.3. MODELLO FUNZIONALE 13 Production Accounting 2 Manager 3 (Administration) 3 Purchase Warehouse 1 Finance Quality Supplier Assurance Figura 2.5: Esempio: processo di controllo 7-Contabilità richiede alla tesoreria di effettuare il pagamento 8A-Tesoreria paga il fornitore 8B- A fronte del pagamento viene inviata una notifica alla contabilità che effettuerà tutte le registrazioni necessarie 9- Infine, la merce verificata e pagata è inviata alla produzione In parallelo a tale processo operativo deve essere messo insieme un processo decisionale e di controllo. Il manager, ad esempio: 1- Decide come fare controllo qualità e con quali standard 2- Verifica con la produzione la produttività effettiva 3- utilizza info di contabilità per capire quali sono i flussi di vendita, di magazzino ecc.. Vi sono dunque due processi: uno operativo ed uno di gestione e controllo. Questa dua- lità è comune a molti processi aziendali. Riassumendo, per creare un sistema informativo dobbiamo: Farci carico di descrivere le informazioni che devono essere scambiate e capire “su cosa” andremo a lavorare Descrivere gli attori che intervengono in un processo Descrivere e modellare l’interazione fra questi operatori e le attività di ognuno Con il passaggio da un attore all’altro passano delle informazioni. (es: produzione a magazzino). Le informazioni sono sia quelle che transitano da un operatore all’altro sia quelle che IS mantiene per fornire supporto al processo decisionale. 14 CAPITOLO 2. DEFINIZIONE DI SISTEMA INFORMATIVO Figura 2.6: Modello modello IT 2.4 Modello IT Il modello IT (figura 2.6) tiene conto di due aspetti fondamentali: il modello tecnologico (più legato all’Hardware) ed il modello applicativo (più relativo al Software). 2.4.1 Modello tecnologico (Hardware) Riguarda essenzialmente cosa fanno i processori (CPU), quali sono i nodi di elaborazione, i processi, le reti etc. Il modello tecnologico riguarda quindi più in generale l’implementa- zione dal punto di vista fisico-realizzativo. Possiamo in quest’ottica parlare delle cosiddette architetture di tipo client-server. Le Architetture di tipo client-server che prevede la presenza di vari livelli, chiamati tier, ciascuno dei quali utilizza i servizi resi dai livelli sottostanti. I vari livelli lavorano in modo indipendente, ma interagiscono tra loro. Si possono vedere come una gradinata, in cui ciascun gradino costruisce qualcosa in più rispetto a quello che ha fornito il livello sottostante. Nello schema sottostante si esplica quella che è l’organizzazione in livelli di un generico SI del tipo client-server: ciascun livello interagisce con quello sottostante, usando i servizi da essi resi. Una tendenza consolidata negli ultimi anni è quella di non investire in componenti hardware quali i server, ma sfruttare il paradigma del cloud commputing. Si tratta della possibilità di accedere da qualunque luogo (purchè connesso), con costi ridotti, non appena c’è la necessità ad un gruppo di risorse di elaborazione condivise. Consiste nella pratica di condividere tali risorse per avere una piattaforma uniforme e sfruttare economie di scale. In pratica si usa l’infrastruttura di calcolo di una terza parte che la gestisce e la offre ai propri clienti. Da un punto di vista economico si tratta di trasformare quelli che erano investimenti di capitale (CAPEX) in spese per l’operatività (OPEX) Network levels I sistemi distribuiti parlano attraverso delle reti di comunicazione. Le reti hanno tecnologie diverse e in particolare si distinguono in: 2.4. MODELLO IT 15 Client web server Database server Mobile client Application servers Client side Server side Figura 2.7: Livelli dell’architettura 1. Reti di accesso: ultimo segmento che collega l’utente con la centrale più vicina; 2. Reti backbone: collegamento tra le varie centrali; 3. Reti MAN (metropolitan network area): reti che collegano le varie istituzioni della città. Le informazioni viaggiano tra i 100mega bit al secondo all’ 1 Giga bit a secondo. 4. Reti LAN (local network area): lunghezza pochi km, l’informazione viaggia a 100 Mega byte al secondo. 5. Reti WAN (Wide network area): lunghezza maggiore della LAN, l’informazione viag- gia ad 1 Tera byte al secondo. Internet è invece una rete pubblica che ha come obiettivo di permettere a tutti i nodi (utenti) di comunicare tra loro. Per rispondere alle esigenze di protezione dei dati delle aziende sono nate le Intranet. Esse si basano sugli stessi protocolli di internet ma sono reti private, normalmente interne ad un azienda. Le intranet sono disconnesse dalle al- tre reti ossia manca il collegamento con la linea telefonica. Questo impedisce l’accesso ai dati dall’ esterno e quindi risolve il problema di sicurezza degli stessi. Dal punto di vista dell’hardware, le intranet prevedono spesso il collegamento delle macchine tramite cavi. Esistono anche le extranet: esse sono un collegamento privato creato tramite una connessione pubblica tra diverse intranet. Questo permette l’accesso dall’ esterno a certe informazioni, ma solo alle intranet che hanno l’abilitazione per farlo. 2.4.2 Modello Applicativo (Software) Descrive l’organizzazione dell’architettura del software, quali sono i moduli che lo compon- gono e come parlano tra loro i vari moduli. Esso si occupa anche di gestire certe funzionalità applicative predefinite che si distinguono su tre livelli: Gestione dei dati: è la più semplice dal punto di vista tecnologico in quanto si deve preoccupare solo di ottimizzare l efficienza del database nel quale sono salvati/orga- nizzati i dati. Esistono database di due tipi: Relazionali e Non Relazionali. Regole di Business: devono essere codificate negli algoritmi e ci dicono quali sono i modi leciti per poter gestire e modificare i dati. Sono sostanzialmente di due tipi: Regole di correttezza dei dati e regole sui processo da fare che hanno un certo impatto sui dati. Presentazione: riguarda quella che è l’interfaccia utente. Rappresenta il modo in cui il sistema presenta all’utente le funzioni che offre, la possibilità di modificare/in- serire dati e i dati su cui lavora. E’ importante che rimanga separato dagli altri due 16 CAPITOLO 2. DEFINIZIONE DI SISTEMA INFORMATIVO Distributed Distributed Distributed Remote Distributed Remote Data Data Logic and Data Presentation Presentation Logic Management Management Management Presentation Presentation Presentation Presentation Presentation Presentation Application Application Application Application logic logic logic logic Client Data Data management management Presentation Application Application Application Application logic logic logic logic Server Data Data Data Data Data Data management management management management management management Figura 2.8: Fat/Thin Client, possibili variazioni livelli perché io voglio interfacce diverse per le stesse regole di business a seconda di chi sia l’utente con cui sistema interagisce. La separazione tra i livelli può essere declinata in diversi modi. In funzione di quanta computazione è delegata al lato client, si parla di thin client (poca) o fat client (molta). Inizialmente tutto il software era centralizzato sul server, ma con il passare degli anni si è passati ad una decentralizzazione del software, mantenendo una parte sul server ma anche una parte sul computer dell’utente. I mainframe sono calcolatori molto potenti a cui gli utenti si collegavano attraverso terminali (dispositivo e tastiera). Nelle applicazioni tradizionali (quelle più vecchie come i siti web tradizionali) tutta la logica applicativa e tutti i database erano contenuti a livello server. Il livello client si occupava solo di organizzare i dati provenienti dal livello server in una presentazione ossia di creare un’interfaccia utente. Non c’è nulla da installare sul client se non il browser. Nelle applicazioni più moderne, la logica applicativa viene duplicata ossia non è solo più presente sul lato server ma viene installata anche sul lato client. Sul dispositivo del client girano quindi la logica applicativa e la parte di interfaccia utente (presentazione). Normalmente i database sono presenti a livello server, ma per le logiche più complesse è possibile trovare una duplicazione non solo della logica applicativa, ma anche una copia in locale di dati di lavoro sul lato client oltre che sul lato server. Se avessi la logica applicativa solo sul lato client, questo vorrebbe dire che in caso di aggiornamento questo dovrebbe essere svolto separatamente sugli n-computer client, il che implicherebbe perdite di tempo e di soldi a dir poco assurdi (non implementabile come sistema). Nel caso della duplicazione della logica applicativa come appena spiegato cosa succede? Qualsiasi cambiamento che io voglio apportare alla logica applicativa la apporto dal lato server: appena il computer client verrà acceso si accorgerà del cambiamento nella logica applicativa e l’aggiornamento avverrà in automatico. Requisiti di qualità del SI I requisiti base di un’architettura web in grado di offrire un buon servizio sono: Velocità di risposta alle richieste dell’utente. Per avere un tempo di risposta più breve alle richieste dell’utente è necessario avere più server in parallelo. 2.5. MODELLO ORGANIZZATIVO 17 Scalabilità che rappresenta la caratteristica del sistema di riuscire a gestire con- temporaneamente un grande numero di utenti. Questa voce di costo operativo è proporzionale al numero di dispositivi che possono usare il SI contemporaneamente. Disponibilità ossia la percentuale di tempo per cui sistema è disponibile senza rotture. Affidabilità ossia la capacità di far funzionare il sistema informativo anche in presen- za di guasti, dal momento che fermare i processi spesso comporta un costo. L’obietti- vo è quindi quello di riuscire ad aggiustare il guasto senza interrompere il servizio e senza che i clienti se ne accorgano. Questi sono fattori che hanno determinato il successo del cloud computing. Con l’utilizzo di questa tecnologia gli utenti pagano un canone tanto più alto quanto più alta è la scala- bilità che si vuole avere e quanto più basso è il tempo di risposta alle richieste dell’utente. Il cloud computing permette agli utenti di variare il numero di server che si utilizzano in modo semplice e veloce, permettendo quindi agli investimenti fatti di non essere un onere illimitato nel tempo, ma circoscritto al periodo nel quale se ne abbia esigenza. Questa ri- sulta essere un aspetto di grande convenienza rispetto al modello di affitto tradizionale dei data server che necessita il dimensionamento sul picco a causa della minore flessibilità e la maggiore inerzia al cambiamento. 2.5 Modello Organizzativo Con organizzazione si intendono le persone che vi lavorano, la struttura organizzativa, le business function ed i processi aziendali. Per definire IS dobbiamo capire bene cosa avviene e come. In genere, con business function si intendono delle mansioni a livello macroscopico presenti in (quasi) ogni azienda: Manufacturing Vendite e marketing Risorse umane Contabilità Finanza Attenzione, perché le principali business functions non sono scorrelate fra loro, ma an- zi interagiscono fra loro e risultano interdipendenti. Un IS deve essere in grado di far comunicare correttamente le varie business function Business Process: Si tratta del modo in cui un’azienda organizza le proprie attività per raggiungere un determinato obiettivo o svolgere un determinato lavoro.  CAPITOLO 3 F AMIGLIE DI SISTEMI INFORMATIVI... è scritto che gli animali si dividono in (a) appartenenti all’Imperatore, (b) imbalsamati, (c) ammaestrati, (d) lattonzoli, (e) sirene, (f) favolosi, (g) cani randagi, (h) inclusi in questa classificazione, (i) che s’agitano come pazzi, (j) innumerevoli, (k) disegnati con un pennello finissimo di pelo di cammello, (l) eccetera, (m) che hanno rotto il vaso, (n) che da lontano sembrano mosche. J.L.Borges, Altre Inquisizioni Nello sviluppo di un Sistema Informativo è necessario comprendere a fondo le esigenze degli stakeholder per costruire un prodotto che sia in grado di soddisfarle. Sebbene ogni organizzazione abbia proprie peculiarità, è frequente che le esigenze, almeno a livello ma- croscopico, possano essere simili, se non identiche, in organizzazioni diverse. Questo ci porta a considerare la possibilità di riuso dei sistemi informativi, in ‘contesti’ diversi che hanno processi aziendali simili. Si possono identificare delle tipologie, o famiglie, di SI che supportano specifiche catego- rie di processi aziendali. Spesso queste famiglie di SI corrispondono a tipologie di prodotti offerti sul mercato a tutte le aziende che abbiano delle esigenze compatibili. Si và da veri e propri pacchetti da comprare e installare direttamente senza dover apportare partico- lari modifiche a prodotti estremamente complessi e da personalizzare accuratamente per adeguarli alle esigenze aziendali. È importante conoscere queste famiglie per capire se a fronte delle esigenze di un’orga- nizzazione è necessario sviluppare un SI ad-hoc o se sul mercato ne esiste già uno che le soddisfi o che possa essere facilmente adattato ad esse. 3.1 Classificazione È importante poter classificare le tipologie di processi e quindi dei SI che li supportano in modo da poter avere una nomenclatura comune con cui indicare le diverse tipologie di SI, 19 20 CAPITOLO 3. FAMIGLIE DI SISTEMI INFORMATIVI una struttura predefinita per organizzare i moduli di SI, un quadro di riferimento per poter valutare e progettare dei SI, un supporto per decidere dove focalizzare gli investimenti in SI. L’obiettivo è quello di classificare i diversi tipi di processi/SI in macro-aree. La classifi- cazione dei SI può seguire diverse strategie: 1. Livelli e funzioni 2. Organizzazione in famiglie 3.1.1 Livelli e Funzioni Questo tipo di classificazione, riportata in figura 3.1, si basa sulla Piramide di Anthony che riporta i vari livelli organizzativi (operativi, manageriale e strategico). Lo schema si basa su due dimensioni di classificazione: il livello organizzativo la funzione aziendale Organizational level STRATEGIC LEVEL MANAGEMENT LEVEL OPERATIONAL LEVEL SALES & MANUFACTURING FINANCE ACCOUNTING HUMAN MARKETING RESOURCES Business functions Figura 3.1: Piramide di Anthony I livelli aziendali sono, dal basso verso l’alto: Operativo che rappresenta le attività “quotidiane” che servono a far procedere l’organiz- zazione; è caratterizzato da un’elevata frequenza di operazioni e da elevate quantità di dati; questo livello gestisce transazioni ed eventi da cui il nome generale per i SI che coprono questo livello di Transaction Processing Systems (TPS). Gestionale che rappresenta le attività di gestione dei processi (svolti al livello operativo); è caratterizzato da una frequenza di attività più lenta e da una quantità di infor- mazioni fornite ai manager più sintetica, spesso derivante dall’aggregazione dei dati utilizzati a livello operativo e da indicatori (si veda il capitolo 11). 3.1. CLASSIFICAZIONE 21 Strategico che rappresenta le attività di indirizzo strategico dell’organizzazione (o di sue parti); è caratterizzato da un periodo di lavoro decisamente più lungo degli altri e da quantità di indicatori forniti ai propri utenti (manager di alto livello) ancora più ridotte e informazioni più astratte. La seconda dimensione, sulla base della piramide, corrisponde alle diverse funzioni aziendali; in figura sono riportate alcune delle più comuni funzioni azindali nel settore manifatturiero, ma esso possono variare da un settore ad un altro. Per ogni intersezione funzione-livello è possibile trovare una serie di processi dell’azien- da e dei tipi di SI che li supportano. La tecnologia ha gradualmente permesso l’automazione dei livelli operativi (quelli più bassi) per avere maggiore efficienza e maggiore controllo. Anche i sistemi più alti sono in parte intaccati dall’IT perchè molti dei calcoli che una volta venivano fatti a livello mana- gement ora vengono fatte da computer o business intelligence e danno come output dei dati su cui il management prenderà poi le decisioni. Ciò che si stanno automatizzando sono le parti ripetitive svolte dai manager. Questa rappresentazione grafica a piramide ha un po’ un difetto ossia quello di mettere le funzioni (base piramide) tutte sullo stesso piano anche se alcune funzioni in realtà sono più specifiche per quella azienda e altre invece più trasversali (vanno bene per tutte le aziende). 3.1.2 Contenuto informativo I vantaggi competitivi che possono essere ottenuti tramite l’uso di SI dipende (tra gli altri fattori) dall’intensità informativa dei prodotti e dei processi. È possibile classificare le attività o i domini applicativi secondo lo schema illustrato in figura 3.2. Tale classificazione può fungere da strumento per decidere dove e se focalizzare gli investimenti in SI. Information intensity of process Low High University & schools Medical labs Traditional Banks & Insurance High editorial industries Telephone companies PA Information intensity Engineering companies of product Tobacco industry Gas, electricity Low Traditional companies manufacturing industries Distribution Figura 3.2: Intensità informativa e utilità dei SI (adattato da ) Storicamente si è osservato un avanzamento della copertura delle diverse tipologie di attività a partire dai settori che hanno un elevato contenuto informativo sia del processo che del prodotto. Infatti, escluso il settore militare, i primi settori che hanno adottato tec- nologie informatiche per il supporto dei propri processi aziendali sono state assicurazioni e banche (presenti nel quadrante in alto a sinistra), in cui i processi organizzativi richiedono una significativa elaborazione delle informazioni e i cui prodotti hanno una componente informativa preponderante. 22 CAPITOLO 3. FAMIGLIE DI SISTEMI INFORMATIVI I settori a contenuto informativo elevato per i processi e ridotto per i prodotti (quadrante in basso a destra) sono rappresentati dalle industrie di "utility" (es. gas ed elettricità) o della distribuzione in cui il prodotto venduto è di per sè semplice, ma richiede complesse procedure di gestione. Le industrie con elevato contenuto informativo del prodotto ma limitato contenuto in- formativo del processo (quadrante in alto a sinistra) sono rappresentate, ad esempio, dal settore editoriale tradizionale (mentre la moderna editoria che si affaccia sui nuovi media richiede processi con un intenso contenuto informativo). Infine (quadrante in basso a sinistra) troviamo industrie che hanno prodotti informati- vamente semplici che sono gestiti con processi semplici: le tipiche industrie manifatturiere. È ovvio che anche tali industrie, nel momento in cui adottano processi agili o si integrato in articolate catene di produzione, necessitano di processi informativamente molto ricchi. 3.1.3 Modello a T Management Support Primary Figura 3.3: Modello a T I processi, e di conseguenza i sistemi informativi che li supportano, possono essere clas- sificati in tre grosse famiglie che possono essere rappresentate graficamente formando una T, come indicato in figura 3.3. Le tre famiglie sono: Management processes, sono processi che hanno l’obiettivo di gestire e guidare l’or- ganizzazione (controllo, pianificazione, definizione degli obiettivi, controllo dell’anda- mento delle attività). Support processes, Forniscono servizi comuni all’organizzazione che sono necessari ma non sono caratteristiche dell’azienda oppure servizi che sono obbligatori per leg- ge. Essi hanno un impatto indiretto sull’impresa, ossia sono di supporto all’attività produttiva. Alcuni esempi di processi di supporto sono la gestione della logistica, la gestione del personale, le risorse umani, la gestione di ferie e stipendi, information system, la contabilità..). Sono di supporto alla produzione ma in modo indiretto. Concernono gli aspetti ba- silari senza i quali l’azienda non potrebbe funzionare. Hanno l’obiettivo di creare le condizioni per poter eseguire i processi primari. Primary processes, sono i processi direttamente utili alla produzione e fornitura di prodotti e servizi e di conseguenze sono dipendenti dallo specifico prodotto o servizio erogato dall’organizzazione. L’obiettivo è in questo caso gestire processi che servono e sono utili al cliente. Que- sto ramo verticale si differenzia molto a seconda del tipo di business che viene fatto (manufacturing, industria, sanità, PA...). 3.2. LIVELLI ORGANIZZATIVI E FUNZIONI 23 I primi due tipi sono abbastanza neutri al tipo di prodotto, ed è possibile osservare una forte somiglianza anche tra aziende molto diverse. Al contrario i processi primari sono specifici per uno specifico settore, all’interno di uno stesso business si usano processi molto simili. Lo schema a “T” riportato in figura 3.3 evidenzia l’orientamento (orizzontale o vertical) delle tre famiglie. I sistemi verticali sono quelli che risultano specifici per un’organizzazio- ne o per un dominio. I processi primari sono specifici, essi consentono di fornire il prodot- to/servizio e dunque sono verticali. I processi orizzontali sono invece generici, applicabili a diverse aziende o diversi contesti. I processi di management e di support risultano invece molto più generici e sono quindi orizzontali. Tali processi potrebbero essere gli stessi per una serie di famiglie di SI tra loro relativamente simili. Quindi è lecito pensare che lo stesso SI possa essere riutilizzato per diverse organizzazioni. 3.2 Livelli organizzativi e funzioni I processi che i sistemi informativi devono supportare possono essere classificati in base al livello aziendale (Operativo, Gestionale, Strategico). Tabella ?? riporta esempi di pro- cessi nei tre livelli per diversi tipi di organizzazioni: una città, una banca ed una generica azienda manifatturiera. Tabella 3.1: Esempio di processi nei tre livelli organizzativo Città Banca Azienda Operativo citizen payment ac- management of recording of orders counting, road mainte- accounts nance Gestionale payment control, review of negative ba- check weekly budget reminders, monthly lances vs. actual comparison of budget vs. actual income, pollution monitoring Strategico check costs and inco- assess performance of select most promising mes of social servi- a service, decision to market areas ces, definition of new activate a new service prices, building plans Quando parliamo di dati trattati dai SI nei diversi livelli, è bene distinguere due aspetti: la quantità di indicatori forniti da un SI in uscita verso i propri utenti il volume di dati elaborati da un SI in ingresso Nel caso dei SI al livello operativo dovendo gestire direttamente la attività quotidiane (di produzione o erogazione di servizio) gli utenti devono gestire tanti indicatori, general- mente focalizzati su alcuni casi specifici, i dati in ingresso riguardano ad esempio la singola filiale di una banca quelli in uscita i vari indicatori dei singoli correntisti. Nel caso dei SI strategici, è necessario tenere sotto controllo tutta l’azienda (es. tutti i correntisti di una banca, in tutte le filiali) ma è necessario fornire a chi deve prendere le decisioni dei dati molto aggregati (l’amministratore delegato non guarda i movimenti dei correntisti) quindi il SI attingere da una quantità di dati molto ampia per sintetizzare e presentare pochi indicatori. 24 CAPITOLO 3. FAMIGLIE DI SISTEMI INFORMATIVI 3.2.1 Livello operativo A livello operativo l’importanza di un sistema informativo, ovvero il vantaggio che l’azien- da può ricavare è proporzionale all’intensità di informazione dei prodotti (o servizi) che l’organizzazione produce e dei processi legati alla loro erogazione : I S = f (I O, I P ) dove: IO Information intensity of product IP Information intensity of process Information intensity of process Low High intensity of product University & schools Medical labs Traditional Banks & Insurance Information High editorial industries Telephone companies PA Engineering companies Tobacco industry Gas, electricity Low Traditional companies manufacturing industries Distribution Figura 3.4: Importanza di un SI in funzione dell’intensità informativa Come illustrato in figura 3.4 possiamo identificare quattro casi rappresentativi, in fun- zione del contenuto informativo – alto o basso – dei prodotti e dei processi. Nel riquadro in alto a destra sono riportati domini caratterizzati da un’elevata intensità informativi, sia dei prodotti che del processi; ad esempio banche e assicurazioni, aziende di telecomunizaioni, pubblica amministrazione, sanità. Questi sono i domini in cui maggior- mente un’organizzazione può beneficiare dalla presenza di un sistema informativo a livello operativo. Nei due riguadri, in alto a sinistra e in basso a destra rappresentano domini in cui o i prodotti o i processi hanno una bassa intensità informativa. Ad esempio l’editoria produce prodotti con elevato contenuto informativo ma i processi di pubblicazione hanno un ridotto contenuto informativo; viceversa le utilities o la grande distribuzione trattano prodotti dal ridotto contenuto informativo (per il gas il rubinetto può essere apero o chiuso, per l’elettricità l’interruttore è acceso o spento) che tuttavia richiedono processi sofisticati per la loro erogazione e gestione. Questi domini possono beneficiare dall’adozione di sistemi informativi a livello operativo ma meno del primo gruppo. Infine nel riquadro in basso a sinistra si trovano domini in cui sia i prodotti che i relativi processi hanna una ridotta intensità informativi: questi sono quelli che beneficiano meno dall’introduzione di sistemi informativi a livello operativo. 3.2.2 Livello gestionale A livello gestionale hanno luogo i processi di controllo. I sistemi informativi a questo livello realizzano il ciclo di controllo: Definizione degli obiettivi, tipicamente economici o di budget 3.2. LIVELLI ORGANIZZATIVI E FUNZIONI 25 Analisi dei risultati Decisione della azioni correttive I sistemi informativi a questo livello si distinguono da quelli a livello operativo per il tipo di informazioni trattate e per la frequenza con cui vengono utilizzati, come illustrato in tabelle 3.2. Tabella 3.2: Caratteristiche distintive dei sistemi a livello operativo e gestionale Operational Management Usage Continuous Periodic (eg. weekly) Information Simple, Current Aggregate, Historical 3.2.3 Livello strategico A livello strategico i processi richiedono l’analisi di grandi quantità di dati. In particolare vengono analizzati i dati dei clienti (profiling) per capire le abitudini e le attitudini all’acquisto dei prodotti o servizi dell’azienda. Si analizzano i dati sull’affidabi- lità dei prodotti (dependability) per identificare possibili debolezze. Viene svolta un’analisi delle prestazioni di diversi processi aziendali sintetizzandoli in un insieme ridotto di in- dicatori spesso presentati in un cruscotto informativo (dashboard). Vengono analizzati i tempi di risposta ed i livelli di qualità dei servizi. In generali si analizzano i costi ed i ricavi dei diversi prodotti (o linee di prodotto). Alcuni esempi di analisi strategiche svolte in diversi settori sono riportati in tabella 3.3. Tabella 3.3: Dimensioni e analisi strategiche per vari settori Sector Number of usual customers Example of analysis Telephony Profitability More than 10 Milion (eg. EU monopolists) Behavior / preferences Profitability Bank (large banks) More than 1 Milion Behavior / preferences Electricity and gas Profitability Between 100.000 and 1 Milion (eg. EU monopolists) Behavior / preferences Sectorial study PA / Finance (Europe) More than 10 Milion Segmentation of customer Identify potential Distribution Between 100.000 and 1 Milion Behavior / preferences 3.2.4 Tipologie di SI In funzione del livello aziendale a cui sono indirizzati, solitamente si possono identificare alcune categorie standard (figura 3.5): ESS Executive support systems: sono i sistemi che supportano le attività al livello stra- tegico, si basano su dati aggregati, provenienti sia dall’interno che dall’esterno del- l’organizzazione, sono utilizati dai senior manager e producono delle proiezioni che permetto di prendere decisioni strategiche. 26 CAPITOLO 3. FAMIGLIE DI SISTEMI INFORMATIVI MIS Management information systems: sono i sistemi che permetto di svolgere le prin- cipali attività a livello gestionale, producono informazioni sintetiche a partire dalle transazioni del livello operativo, perciò elaborano grandi quantità di dati; permet- tono di produrre i rapporti periodici e di effettuare analisi base, sono pensati per i manager di livello medio. DSS Decision support systems: sono sistemi che permettono di prendere decisioni infor- mate, solitamente si alimentano da basi di dati ad-hoc e non necessitano di gran- di quantità di dati per costruire dei modelli analitici che consentano ai manager di prendere le loro decisioni. KWS Knowledge work systems: sono i sistemi che permettono di automatizzare le attività di progettazione, si basano su modelli di vario tipo e consento di effetture simulazioni. OAS Office automation systems: sono i sistemi di base che trattano documenti di vario tipo (testi, fogli di calcolo, pianificazioni, email) per gestire, comunicare e pianificare. TPS Transaction processing systems: rappresentano tutti i sistemi che svolgono le attivi- tà essenziali a livello operativo, trattano transazioni (ovvero operazioni semplici ed indivisibili sui dati) ed eventi, effettuano operazioni basilari su flussi di dati relati- vamente semplici ma trattano molti flussi contemporaneamente. Sono i sistemi che permettono di far funzionare l’azienda svolgendo i servisi di base. Figura 3.5: Tipologie di SI per livello organizzativo 3.3 Processi di Supporto I processi di supporto sono decisamente orizzontali. Le principali tipologie sono illustrate in figura 3.6. Possiamo identificare tre categorie più importanti: amministrativi risorse umane sistemi informativi 3.3. PROCESSI DI SUPPORTO 27 SUPPORT PROCESSES HUMAN INFORMATION ADMINISTRATION OTHER RESOURCES SYSTEMS SECTIONAL INDUSTRIAL PLANNING & CLIENT PLANNING ACCOUNTING RELATIONS STRATEGY MANAGEMENT INSTITUTIONAL PROJECTS & MANAGEMENT ADMINISTRATION SYSTEMS ACCOUNTING MAINTENANCE MANAGERIAL OTHER PERFORMANCE OTHER ACCOUNTING PROCESSES MANAGEMENT PROCESSES OTHER ACCOUNTING Figura 3.6: Processi di supporto 3.3.1 Processi amministrativi I processi amministativie inclusdono principalmente la contabilità. Sono quelli storicamente più anziani, si pensi che la contabilità in partita doppia risala a Luca Pacioli (1494). Esistono diversi standard, sia nazionali che internazionali; ad esempio il regolamento EC 1606/2002 : è obbligatorio per le aziende quotate in borsa nell’EU dal 2005. 3.3.2 Procesi per le Risorse umane Tali processi si occupano di pianificazione e gestione delle risorse umane come per quanto riguarda gli stipendi e la gestione del dialogo con i sindacati, della ricollocazione e della gestione delle competenze ( quali sono le competenze necessarie per supportare i processi caziendali e chi sono le persone che hanno queste competenze) 3.3.3 Processi per i sistemi informativi Questi processi comprendono pianificazione e strategia, gestione dei sistemi, gestione delle reti, ecc L’obiettivo è quello di costruire e mantenere l’infrastruttura tecnologica di supporto alle attività di produzione. Esistono diversi framework standard che definiscono metodi e processi per svolgere que- ste attività, il principale è probabilmente ITIL (IT Infrastructure Library). Lo standard ITIL prevede cinque fasi principali con i relativi sotto-processi: IT Service Strategy ha l’obiettivo di sviluppare ed implementare la gestione dei servizi agevolando una pianificazione strategica. I processi legati a questa fase sono: Strategy Generation Service Portfolio Management Demand Management Financial Management IT Service Design ha l’obiettivo di progettare e sviluppare o acquisire i servizi. I processi legati a questa fase sono: 28 CAPITOLO 3. FAMIGLIE DI SISTEMI INFORMATIVI Service Catalogue Management Service Level Management Capacity Management Availability Management IT Service Continuity Management Information Security Management Supplier Management IT Service Transition ha l’obiettivo di gestire l’evoluzione dei servizi. I processi legati a questa fase sono: Transition Planning and Support Change Management Service Asset and Configuration Management Release and Deployment Management Service Validation and Testing Evaluation Knowledge Management IT Service Operations ha l’obiettivo di curare l’operatività dei servizi. I processi legati a questa fase sono: Event Management Incident Management Request Fulfillment Problem Management Access Management Continuous Service Improvement ha l’obiettivo di migliorare i servizi tramite un si- stema basato su metriche ed indicatori. 3.4 Processi di gestione I processi di gestione permetto di attuare il ciclo di controllo (figura 3.7) in cui è necessa- rio da una parte effettuare il controllo, ovvero raccogliere misure e costruire indicatori, e dall’altro prendere decisioni. Goal definition (Planning) Identification of corrective actions Outcome control (Delta analysis) Information about outcomes EXECUTION / MONITORING Figura 3.7: Ciclo di controllo 3.5. PROCESSI PRIMARI 29 3.4.1 Controllo Le operazioni di controllo vengono svolte a diversi livelli: Planning strategico : si tratta di definire la strategia generale dell’azienda, ad esempio capire su quali mercati puntare, quando sviluppare o lancuare un nuovo prodotto. Gli strumenti qui utilizzati sono ad esempio i CSF. Gli aspetti strategici sono difficili da automatizzare perché non esistono delle soluzioni preconfezionate. Controllo aziendale : si tratta dell’accezione più classi del controllo e gestione, ci si basa su indicatori, ad esempio KPI per valutare l’andamento dei processi a livello operativo e intraprendere azioni correttive (si veda il capitolo 11 sugli indicatori). Controllo operativo : Controllo di aspetti semplici di produzione del prodotto o eroga- zione del servizio. Gli aspetti di gestione a livello operativo sono abbastanza semplici. Si tratta infatti di regole generali e dunque facilmente automatizzabili. 3.4.2 Decisioni strategiche Una fase importante della gestione consiste nel prendere decisioni. Le decisioni vengono in genere prese seguendo delle regole o linee guida. In base a quanto sono precise e definite tali indicazioni è possibile distinguere le decisioni in: Strutturate: sono definite delle regole o algoritmi dettagliati che possono essere ese- guiti in maniera completamente automatica; ad esempio il riordino di merci quando la disponibilità di magazzino scende sotto una data soglia. Semi-strutturate: Vi sono alcune regole a disposizione ma non permettono di arrivare univocamente a una scelta. compra vendita delle obbligazioni ( non basta la formu- la, devo avere un minimo di visibilità e criterio, ho bisogno di molte informazioni complesse da incrociare e confrontare) Non strutturate: non esistono regole precise ma le decisioni vengono invece prese in base all’esperienza pregressa e alla sensibilità. La decisione se assumere una persona dopo un colloquio e l’analisi del CV. Spesso si distingue tra regola e algoritmo: un algoritmo è una serie di passaggi precisi e non ambigui che portano ad un risultato, una regola fornisce delle indicazioni non così precise. Oltre al livello di strutturazione della decisione è fondamentale considerare anche quan- to sono strutturate (ovvero aderenti ad uno schema ben definito) le informazioni necessarie per prendere la decisione. Un conto è prendere una decisione in base a precisi valori nu- merici (ad esmpio il prezzo di una materia prima da acquistare), un altro è prenderla sulla based di informazioni espresse in maniera ambigua e non precisa (ad esempio il contenuto di una chiacchierata). Come illustrato in figura 3.8, le due dimensioni identificano quattro principali tipologie di decisioni. Quando sono ben strutturate sia le regole che le informazioni è relativamente semplici automatizzare il processo decisionale. Quando le regole o le informazioni risultano meno stutturate, risulta più difficile automatizzare le decisioni; in tale caso il ruolo di un sistema informativo è fornire tutte le informazioni necessarie al decisore. 3.5 Processi primari I processi primari sono quelli verticali per eccellenza, ovvero si tratta di processi specifici per un particolare settore, tipo di industria e, spesso, anche per le singole organizzazioni. Essendo verticali, ovvero specifici per un particolare problema o obiettivo, è utile classi- ficarli in base al dominio applicativo: le aziende manifatturiere ne hanno alcuni, quelle 30 CAPITOLO 3. FAMIGLIE DI SISTEMI INFORMATIVI Building site Stock management systems with planning fixed rules Decision Structuredness Low High Information Structuredness Partial automation Full automation (open loop) (closed loop) High Document storage Low Acceptance of food supply in a Decision whether to apply for a public tender supermarket Figura 3.8: Strutturazione delle devisioni automobilistiche altre ma per ogni azienda dello stesso settore sono generalmente molto simili. In generale, per la definizione dei processi e la costruzione del relativo SI di supporto non si parte da zero a meno che non si tratti di un’esigenza molto specifica. Solitamente il punto di partenza è un modello di riferimento più o meno astratto che poi viene dettagliato per adattarsi alle esigenze della singola azienda. Buona parte dei processi sono dettati dal settore, perciò la strategia che si segue è spesso quella di comprare un software già esistente e poi personalizzarlo (customization). I modelli di riferimento possono derivare da: modelli e teorie proposte in letteratura da studiosi, spesso distillate a partire da di- versi casi concreti, che propongono un quadro di riferimenti, ad esempio la catena del valore (value chain); modelli definiti da consorzi o organizzazioni che mirano a standardizzare alcuni aspet- ti dei processi, questo porta vantaggi in termini di interoperabilità e di comunicazione tra diverse organizzazioni, ad esempio SCOR; modelli definiti da “vendor” (produttori) – ad es. SAP, Oracle – di sistemi informativi che tendono a declinare i processi di una qualunque azienda in termini di composi- zione dei sistemi che vengono venduti, spesso questi modelli sono specifici per diversi domini; modelli definiti da “integrator” (integratori) – ad es. Accenture, IBM, HP – ovvero aziende che possono produrre alcuni sistemi informativi ma principalmente li svilup- pano o integrano prodotti di diversi vendor per fornire una soluzione ritagliata sulle esigenze della singola organizzazione; modelli aperti, spesso sviluppati da organizzazioni indipendenti da pressioni, ad esem- pio www.bpmi.org e www.mit.edu. Spesso nei cataloghi di vendor e integrato, a fianco dei processi primari troviamo una serie di processi orizzontali che corrispondo a soluzione pronte che vegono offerte pronte per essere integrate con quelle verticali. 3.5. PROCESSI PRIMARI 31 È lecito chiedersi quanto possa essere flessibile un SI già sviluppato rispetto alle esi- genze delle specifiche aziende. Spesso succede che l’acquisizione ed implementazione di un SI imponga anche i relativi processi a cui l’azienda e le persone che ci lavorano non sono abituati e che non necessariamente accettano di buon grado. Modificare i processi e quindi il modo di lavorare delle persone può essere sconvolgente per un’azienda. In alcuni casi tali variazioni sono necessarie, in altre situazioni risultano delle forzature inutili dettate dalla rigidità di chi fornisce il SI. 3.5.1 Catena del Valore (Value Chain) Drawing by Dinesh Pratap Singh Figura 3.9: Value Chain Una serie di concetti abbastanza standard nelle aziende, specie manifatturiere, è quella di catena del valore (figura 3.9). L’idea di base è che un’azienda è in grado di generare dei prodotti attraverso una serie di passi ciascuno dei quali trasforma un prodotto e aggiunge valore rispetto al proprio input. Nella catena del valore si trovano: la logistica in ingresso, la gestione operativa, la logistica in uscita, il marketing, ed i servizi. Ogni tassello della catena aggiunge valore, ma ovviamente ha un costo. Da questo schema a catene è possibile stabilire il costo dell’intero processo e poter poi stabilire il prezzo di vendita del prodotto. Per stabilire il costo del processo si procede con l’accumulo dei costi di trasformazione sul prodotto man mano che esso attraversa il processo. Questo modello può essere usato come base concettuale dei sistemi informativi che si possono poi quindi occupare di ciascun segmento della catena del valore e specializzarsi. Si crea quindi una specie di portfolio di sistemi informativi ognuno per ogni segmento della catena di valore (segmenti pressocchè costanti nell’ambito manifatturiero) ognuna delle quali possa essere poi personalizzabile a livello di processo, in modo che poi questi moduli messi insieme siano in grado di gestire l’azienda nel suo complesso. 3.5.2 Catena di fornitura (Supply Chain) Un aspetto molto importante per in molte aziende è la gestione della “supply chain”, la catena di fornitura (figura 3.10). Quando si ha bisogno di un prodotto in ingresso lo si deve richiedere al fornitore diretto, il quale avviserà i propri fornitori, e così via avviando un processo a catena. Per gestire questa catena caratterizzata dalla sequenza di forniture in maniera snella sono stati definiti tutta una serie di processi di riferimento, che sono poi stati standardizzati dal consorzio SCC (Supply Chain Council). 32 CAPITOLO 3. FAMIGLIE DI SISTEMI INFORMATIVI Figura 3.10: Supply Chain Operations Reference-model Ad alto livello, lo standard prodotto da questo consorzio prevede una serie di processi di alto livello che riguardano la fase di pianificazione, acquisizione, costruzione e consegna. A livello intermedio (configuration) ci sono diverse tipologie di processo, ad esempio la co- struzione può essere fatta in base ad un ordine oppure per essere stoccata in un magazzino, oppure può richiedere una fase di progettazione preliminare. Ogni azienda implementerà una o più varianti di questi procesi. A livello inferiore, gli specifici processi sono ulterior- mente dettagliati in termini di attività che possono essere composte e personalizzate per adattarsi alle singole esigenza aziendali. Una volta definito il processe si tratta di metter- lo in pratica nel contesto dell’azienda (implementazione) quest’ultima fase non è descritta dallo standard in quanto troppo specifica. 3.5.3 Segmentazioni per dominio Manifattura Nel settore manifatturiero sono definiti modelli organizzativi ormai consolidati da decenni; essi sono la base per la costruzione di sistemi informativi orientati a questo settore. Una possibile suddivisione prevede di distinguere due principali famiglie di processi: quelli di pianificazione e quelli di esecuzione. Esse possono a loro volta essere suddivise in sotto-famiglie: Pianificazione – Analisi strategica – Pianificazione con diversi orizzonti temporali: anno, mese, settimanta · · · s Esecuzione – Dati di prodotto e di processo 3.5. PROCESSI PRIMARI 33 Design Supply Manufacture Distribute Technology and Market studies. Strategic plan Survey suppliers -- market overview Customer studies Plan new Sales forecast and Plan – 1 year Plan purchases Plan production products/plants sales plan Plan/assign design Plan and assign Plan production – Plan – 1 month Plan distribution tasks purchases plant Plan purchases. Plan/assign design Plan production – Plan / assign Plan – 1 week Expedite late tasks cells distribution tasks supplies List of parts: List of plants, List of customers. Process product List of suppliers. specifications, machines, working Catalogue of data designs Bill of materials cycles products Move parts and Store and Manage and ship assemblies. Physical flow distribute designs, products. Manage Monitor state of specs inventories production. Send orders to Send orders to Orders flow Receive orders suppliers production Test and store Material flow received parts Figura 3.11: Processi secondo fasi e famiglia – Gestione degli ordini – Gestione dei materiali – Operatività fisica Questo tipo di classificazione può essere affiancata ad una per fase della produzione manifatturiera