Riassunto libro processi aziendali e sistemi informativi

Libro di testo: Giampio Bracchi, Gianmario Motta: “Processi aziendali e sistemi informativi” (ed. FrancoAngeli)

Capitolo 1 – Ingegneria dei processi gestionali

Paragrafo 1.1 – Ingegneria dei processi gestionali e Business Process Reengineering

Tradizionalmente, il progettista di sistemi informativi si limitava ad automatare i processi esistenti, cercando di minimizzare i cambiamenti alle procedure aziendali (partendo dal presupposto che il cambiamento fosse “male”). L’avvento del BPR (Business Process Reengineering) ha ribaltato questa idea: il cambiamento è “bene” ed i sistemi devono servire a cambiare (in meglio).
In generale, il BPR può essere definito come un procedimento di innovazione (cioè composto da una serie di azioni che permettono di passare da una situazione A ad un’altra situazione B) organizzativa (agisce sull’assetto organizzativo dell’impresa e non sui procedimenti produttivi), incentrato sui business process (cioè sul flusso delle attività svolte dall’azienda).

Paragrafo 1.2 – Lo sviluppo delle teorie BPR

Gli stadi di sviluppo della letteratura BPR possono essere sinteticamente ridotti a:

• fondazione teorica del BPR;
• sviluppo delle metodologie BPR;
• integrazione multidisciplinare.

Paragrafo 1.2.1 – La fondazione teorica del BPR

In un contesto caratterizzato da una generale critica alle TI (tecnologie informatiche), accusate di generare esclusivamente benefici marginali, M. Hammer pubblica una serie di lavori, nei quali sostiene che le moderne TI sono inefficaci perché applicate a contesti aziendali invariati. Per migliorare le performance, questa la sua idea, occorre integrare l’innovazione TI con quella organizzativa.

 

Paragrafo 1.2.2 – Hammer: la rimodellazione radicale dei processi

L’approccio di Hammer (prima fase dello sviluppo del BPR) all’innovazione è decisamente radicale, in quanto la considera essenziale nei mercati maturi, dove tutti i concorrenti sono in grado di offrire gli stessi prodotti ed i vantaggi competitivi devono pertanto essere ricercati altrove. La sua definizione di BPR è infatti: “il ripensamento di fondo e il ridisegno radicale (non è una modifica, ma un reinvenzione del modo di lavorare) dei processi aziendali, finalizzato a realizzare straordinari miglioramenti (e non miglioramenti incrementali) nei parametri critici delle prestazioni come i costi, la qualità, il servizio e la tempestività”. Hammer non propone una vera metodologia, ma fornisce una serie di linee guida per affrontare i progetti di reengineering, composta da tre macrofasi principali:

1. selezione dei processi
2. comprensione del processo
3. riprogettazione (o attuazione) del processo

 

Il reengineering deve essere selettivo (oltre che radicale), e deve quindi riguardare solo un sottoinsieme opportunamente selezionato di business process. Tali processi sono individuati in base a tre parametri: cattivo funzionamento (patologie operative), importanza (misurata in base all’utilità del processo per il cliente finale dell’azienda) e fattibilità (probabilità di successo dei progetti BPR, inversamente proporzionale al loro impatto organizzativo).
La comprensione del processo, intesa come analisi dei contenuti, si deve limitare all’individuazione degli input e degli output del processo stesso (e non focalizzarsi su un’analisi approfondita delle attività svolte, perché scopo del reengineering non è migliorare, ma rivoluzionare il processo). La comprensione delle prestazioni e delle criticità del processo, invece, deve iniziare dal punto di vista del cliente, cioè del destinatario dell’output.
Note le reali esigenze dei clienti e gli input/output necessari per soddisfarle, Hammer propone sei principi da seguire per la riprogettazione/attuazione dei processi:

• organizzarsi in ragione dei risultati da ottenere e non dei compiti da svolgere: la classica struttura aziendale “a reparti” deve essere sostituita da una serie di case managers (gestori dell’intero ciclo di risposta al cliente), che si appoggiano a piccoli nuclei di esperti per i problemi più complessi;
• ove possibile, far svolgere il processo a chi ne deve usare l’output: principio complementare al precedente, suggerisce di decentrare alcune operazioni al cliente del processo (ad esempio delegare la manutenzione di una linea di produzione agli operai che su questa lavorano);
• integrare l’elaborazione delle informazioni nel lavoro di raccolta delle stesse: l’attuale sviluppo delle TI consente di eliminare la separazione tra reparti operativi e reparti che trattano le informazioni;
• trattare le risorse distribuite geograficamente come se fossero accentrate: le TI permettono una gestione centralizzata delle risorse distribuite geograficamente. I vantaggi sono nell’azione coordinata e nella realizzazione di economie di scala, pur mantenendo i benefici derivanti dalla flessibilità e dal livello di servizio che può dare la presenza locale;
• collegare le attività parallele anziché integrarne i risultati a valle: per ridurre il time to market, le attività dei vari processi venivano solitamente parallelizzate e non svolte in ordine strettamente sequenziale. Ciò poneva il problema dei risultati finali, non sempre del tutto compatibili tra loro. Hammer risolve il problema alla radice, proponendo di collegare le attività parallele in maniera così stretta da poterle considerare una sola macroattività;
• mettere i punti decisionali dove il lavoro è effettivamente eseguito ed incorporare il controllo dentro il processo (empowerment): le enormi potenzialità delle TI permettono di arricchire le mansioni affidate ai singoli.

Paragrafo 1.2.3 – Lo sviluppo della metodologia

La seconda fase del BPR coincide con una serie di pubblicazioni uscita sull’onda del successo di Hammer. Alla sua teoria radicale, si contrappone la teoria gradualista di Davenport, in cui il BPR è finalizzato al miglioramento della performance aziendale, da ricercarsi attraverso il miglioramento aziendale (BPI, business process improvement): il management non riconcepisce il processo partendo da zero, ma lo modifica con gradualità ed in tappe successive.

Paragrafo 1.2.4 – Davenport: l’ingegneria metodologica e il ruolo delle TI

Secondo Davenport, l’innovazione radicale di processo è molto difficile da realizzare e va quindi considerata come caso estremo. L’obiettivo strutturale dell’ingegneria dei processi deve quindi essere il miglioramento dei processi aziendali esistenti. Davenport dedica particolare attenzione alle TI, che considera tra i principali fattori abilitanti (enablers) dell’innovazione e del miglioramento del processo (performance). Esse possono però costituire anche un vincolo (constraints).

Paragrafo 1.2.5 – L’integrazione multidisciplinare

La terza fase delinea l’integrazione tra le teorie del BPR e alcune metodologie parallele come:

• benchmarking: metodologia sistematica per l’analisi dei prodotti, dei servizi e dei processi di quelle organizzazioni che sono riconosciute avere le migliori prestazioni (best in class);
• workflow: comprende sia tecniche di analisi dei processi (incentrate sul flusso del lavoro), sia tecnologie software specificatamente orientate ad automatare il flusso del processo.

 

Paragrafo 1.2.6 – Morris e Brandon: progettazione dei processi e progettazione informatica

Morris e Brandon propongono il cosiddetto Dynamic Business Reengineering (DBR), ponte di collegamento tra le metodologie BPR pure che si concentrano sul processo di innovazione organizzativa, e le metodologie di progettazione dei sistemi informativi (che si concentrano invece sui flussi informativi). Punto centrale della teoria sono le mappe delle business activities (BAM), che rappresentano la struttura delle attività svolte dall’azienda, e i successivi relation diagrams (RD) che definiscono, all’interno di un dato segmento di attività, i compiti svolti rispettivamente dalle persone e dai computer.

Paragrafo 1.2.7 – Conclusione: verso un’organizzazione processiva

In molti casi, la finalità di un intervento di BPR è una configurazione gestionale (relativa cioè all’assetto organizzativo dell’azienda) di tipo processivo (che privilegia il servizio ai clienti, minimizzando, con l’integrazione, lo smembramento dei flussi di attività che costituiscono il processo). Elementi tipici di un’organizzazione processava sono che:

• ogni singolo reparto svolge tutte o comunque molte delle attività necessarie ad eseguire un processo;
• il singolo individuo svolge un’attività dall’inizio alla fine.

 

Le TI permettono di uniformare l’informazione (eliminando la parcellizzazione del lavoro, correlata a quella dell’informazione), accorciare le gerarchie aziendali (eliminando quei livelli che si occupano di raccogliere e classificare le informazione), eliminare i tempi burocratici di trasmissione delle informazioni e fornire nuovi servizi.

Paragrafo 1.3 – Il concetto di business process

L’elemento di maggior innovatività introdotto dal BPR è il concetto di processo aziendale, scarsamente considerato nelle teorie organizzative tradizionali.

Paragrafo 1.3.1 – Definizione di business process

E’ possibile definire il business process come tupla concettuale BP = (A,I,O,C), dove:

• A: attività, intese come serie di operazioni su oggetti fisici o informativi, o di decisioni svolte da vari attori (ad esempio dagli uffici di aziende);
• I: input, formati da materie prime e risorse aziendali (uomini e mezzi);
• O: output, che può essere formato da oggetti fisici, beni immateriali o servizi;
• C: clienti, intesi come destinatari dell’output di processo.

 

Paragrafo 1.3.2 – Famiglie di processi

I BP sono cicli di servizio ai clienti, dove, come clienti, sono considerati anche quelli interni all’azienda. La classificazione sui BP si basa proprio su questo criterio e dà origine a:

• BP primari: i processi i cui clienti sono clienti esterni. In generale, il numero di processi primari di un’azienda rispecchia la gamma dei prodotti/servizi offerti dall’azienda ed il numero delle categorie di clienti di tali prodotti e servizi;
• BP di supporto: i processi che supportano quelli primari, avendo clienti interni all’azienda.

 

Per l’identificazione dei BP possono essere adottati vari metodi:

• catena del valore: individua i modelli primari e di supporto (che corrispondo rispettivamente alle attività primarie e di supporto), ma risulta spesso troppo generico;
• check list standard: elenco dei processi normalmente svolti da un’azienda appartenente ad un certo settore di attività. E’ un sistema valido per quei settori standardizzati o fortemente regolamentati come quello bancario. Esistono anche check list che rappresentano l’insieme di tutti i possibili processi di un’azienda di qualsiasi genere;
• criteri soggettivi: è il management che individua i processi gestionali in base alla propria percezione dell’impresa. Ha il vantaggio di aumentare il coinvolgimento del management, ma non offre garanzie sulla qualità ingegneristica dell’output.

 

Paragrafo 1.3.3 – Gerarchie di processi

In genere, il semplice elenco dei processi non è sufficiente a descrivere il funzionamento di un’impresa ed è pertanto necessario disaggregare opportunamente i processi stessi, a tre livelli principali di dettaglio:

• BP o macroprocessi: dove i clienti possono essere interni o esterni, l’output è ben definito ed ha un valore che lo rende acquistabile/vendibile sul mercato (ciò vale anche per i BP di supporto, come ad esempio la progettazione) ed infine richiedono competenze multifunzionali (nonostante materie prime e competenze varino di caso in caso);
• processi: sono ricavati dai macroprocessi secondo una duplice logica: da un lato disaggregazione e/o scomposizione sequenziale (un processo è parte di un macroprocesso) e dall’altro specializzazione (un processo è sottotipo o variante di un macroprocesso). I processi hanno dunque come clienti macroprocessi o altri processi;
• fasi: anche per le fasi, le logiche di scomposizione sono disaggregazione/scomposizione e specializzazione. Ogni fase ha clienti (processi o altre fasi), output ben definiti ed input che generalmente comprendono competenze monofunzionali. Può talvolta capitare di dover suddividere ulteriormente le fasi in attività (determinate componendo i processi secondo una logica sequenziale) ed operazioni (parti di attività, svolte da una sola persona).

 

Paragrafo 1.4 – La griglia metodologica BPR

Per approfondire i fattori caratteristici dell’approccio BPR all’innovazione, proponiamo una metodologia di progettazione suddivisa in tre elementi fondamentali:

• schema generale di riferimento: indica fasi del progetto ed argomenti della progettazione;
• procedure di progettazione: rappresentano la sequenza logica di attività da svolgere;
• modelli e tecnologie adottabili per specifiche attività: ad esempio diagrammi di flusso per l’attività di rilevazione dei flussi gestionali e tecnologie CASE per la riprogettazione dei sistemi informativi.

 

Paragrafo 1.4.1 – Struttura della griglia metodologica BPR

Lo schema generale di riferimento è rappresentato da una griglia, in quanto derivante dal prodotto delle fasi di progettazione e degli argomenti (leve gestionali del reengineering ed attività necessarie a dirigere ed amministrare il progetto BPR) che il progetto considera. L’intersezione tra fasi ed argomenti individua “segmenti metodologici”, ciascuno dei quali caratterizzato da procedure, modelli e tecnologie. E’ bene sottolineare come i segmenti metodologici abbiano pesi relativi differenti e che ogni progetto BPR percorre un sottoinsieme più o meno ampio di tali segmenti.

Paragrafo 1.4.2 – Fasi del progetto

Le fasi qui proposte rappresentano i passi logici attraverso cui si svolge un progetto di BPR e sono state identificate a partire da un’analisi comprata delle metodologie proposte al paragrafo 1.2. Esse sono nel dettaglio:

1. rilevazione della situazione esistente: è il primo passo di ogni progetto BPR. Il suo grado di approfondimento dipende dall’approccio al BPR (analisi superficiale nel caso di radical reengineering e viceversa nel caso di improvement), dalla complessità/dimensione dell’impresa e dalla sua particolarità. Gran parte dell’impegno richiesto è per ricostruire i processi gestionali, di cui raramente esistono schemi o descrizioni;
2. diagnosi e confronto: consiste nella valutazione del processo in termini di efficienza (produttività), livello di servizio e qualità. In un contesto competitivo, la valutazione non può ovviamente prescindere dal confronto con le performance delle aziende concorrenti. La fase di diagnosi e confronto si divide in due fasi:

 

• confronto quantitativo: si opera in seguito alla parametrazione delle attività del processo. E’ significativo se i parametri sono confrontati con analoghe valutazioni riferite ad aziende concorrenti;
• confronto qualitativo: identificazione delle cause delle diverse performance registrate, considerando le diverse leve gestionali, così da individuare le aree nelle quali è necessario intervenire con un progetto BPR;

3. ridefinizione: si divide in due fasi, ovvero la definizione della nuova vision (che fornisce una rappresentazione sintetica degli elementi fondamentali della soluzione proposta) e l’analisi del cambiamento (basata sul gap emerso definendo la vision, porta alla creazione della “griglia as is/to be” sulla base delle leve gestionali);
4. attuazione: consiste nel mettere in atto il processo riprogettato. Comprende dunque l’addestramento dei dipendenti e, in generale, l’introduzione del nuovo assetto organizzativo a scapito di quello precedente.

Paragrafo 1.4.3 – Leve del progetto

Le leve della griglia rappresentano la gamma delle variabili considerate in un tipico progetto BPR. Considerando ciascuna leva, i modelli utilizzabili e le eventuali tecnologie sono i seguenti:

• flussi delle attività: la modellazione più semplice è quella degli schemi di sequenza, che si limitano ad indicare la successione delle attività. Modellazioni più complesse, come i workflow, permettono di aggiungere alle attività altri elementi (attori, eventi, informazioni, ecc…). Nei processi di radical engineering, tuttavia, i workflow possono essere eccessivamente dettagliati e si può pertanto ricorrere a modelli basati su un minor numero di elementi, come i process flow;
• strutture organizzative: a fianco di organigrammi, funzionigrammi e mansionari, è caratteristico dell’approccio BPR l’esame incrociato tra flusso delle attività e strutture organizzative. La più semplice rappresentazione di questo tipo è la griglia LRC (line responsability chart), che incrocia le attività (o le operazioni) dei processi con le strutture organizzative coinvolte, facendo emergere il grado di parcellizzazione del lavoro;
• informazioni e tecnologie informatiche: il BPR, per quanto riguarda il rapporto con le TI, non influenza le singole modellazioni infologiche, ma modifica l’approccio alla progettazione. Nell’approccio BPR, infatti, il progettista informatico partecipa attivamente alla fase di diagnosi/ridisegno di processi per quanto riguarda l’individuazione di criticità, l’illustrazione delle possibilità offerte dalle TI, ecc…;
• risorse umane: vengono utilizzati i correnti strumenti di gestione e sviluppo delle risorse: inventario della capacità (skills), valutazione dei fabbisogni (manpower planning), analisi dei bisogni di formazione;
• strategie e misurazione delle prestazioni: tra le modellazioni per la misura delle prestazioni dei processi è possibile citare il metodo dei Key Performance Indicators (KPI), che considera l’intera gamma delle prestazioni competitive (e non solo le misure monetarie) ed è orientato a misurare il processo anziché la singola funzione aziendale;
• gestione del progetto: le attività relative alla gestione del progetto sono presenti in tutte le fasi e consistono nell’organizzare, coordinare, sequenziale, tempificare e controllare le attività da svolgere e nel gestire i partecipanti al progetto. Per la gestione delle attività si utilizzano tecniche e modelli classici di project management; per la gestione dei partecipanti, invece, occorre creare una struttura di progetto (che specifichi i diversi ruoli/gruppi ed i compiti di ciascuno) e quindi scegliere i partecipanti (sulla base della competenza, della loro influenza sull’organizzazione e della conoscenza/condivisione dei principi del BPR.

 

Paragrafo 1.4.4 – Considerazioni normative

Dall’analisi di una trentina di casi aziendali reali, si è potuto notare che i progetti di BPR riusciti sono quelli dove gli sforzi si sono concentrati soprattutto sulle fasi di ridisegno e di attuazione. In quelli falliti, invece, l’impegno è stato profuso soprattutto nella fase di rilevazione.
Per quanto riguarda l’impegno profuso sulle sei leve, si osserva che nei progetti di successo gli argomenti su cui ci si concentra maggiormente sono i flussi di attività e l’organizzazione aziendale.

Paragrafo 1.5 – La metodologia di rilevazione e diagnosi dei business process

La metodologia qui presentata si propone di fornire uno strumento operativo per la rilevazione dei business process e consente una fotografia, piuttosto ricca e dettagliata, del funzionamento della realtà aziendale. La metodologia prevede quattro passi principali:

• identificazione dei macroprocessi;
• dettagliazione dei processi;
• incrocio processi/unità organizzative;
• valutazione dei processi.

 

Paragrafo 1.5.1 –Passo 1: identificazione dei macroprocessi

L’identificazione dei macroprocessi è possibile a partire da un’analisi del business svolta con la collaborazione del management, utilizzando: il modello della catena del valore di Porter, una check list standard oppure criteri soggettivi. Dall’analisi emerge una lista dei macroprocessi che deve specificare: quali sono i clienti del macroprocesso (interni o esterni), il tipo di processo (primario o di supporto), l’output del macroprocesso (prodotto/servizio fornito ai clienti), input necessari (materie prime, mezzi e competenze necessarie a svolgere il macroprocesso).

Paragrafo 1.5.2 – Passo 2: dettagliazione dei processi

Le caratteristiche dei macroprocessi sono dettagliate scomponendoli in processi, fasi e attività. La scomposizione dei macroprocessi in processi può essere fatta sia seguendo criteri soggettivi, sia optando per check list standard. Stessa regola vale per la scomposizione dei processi in fasi e per la scomposizione delle fasi in attività.

Paragrafo 1.5.3 – Passo 3: incrocio processi/unità organizzative

L’incrocio tra processi ed unità organizzative serve per definire la corrispondenza tra unità organizzative e fasi (o processi) ed individuare le unità che vanno coinvolte nel successivo passo di valutazione del processo. Le attività da svolgere in questo passo sono la rilevazione delle unità organizzative e successivamente l’incrocio di queste con le fasi/processi.

Paragrafo 1.5.4 – Passo 4: valutazione del processo

Quest’ultimo passo prevede la valutazione dei processi da parte dei loro esecutori e dei loro clienti. Gli esecutori sono chiamati a valutare le risorse dedicate ad ogni fase e ad ogni processo ed il tempo di completamento della fase/processo. I clienti devono invece dare una valutazione del prodotto/servizio che ricevono in termini di utilità/calore (esprimibile in termini monetari, rappresenta il prezzo che il cliente è disposto a pagare per acquistare il prodotto/servizio), tempestività, qualità e livello di servizio (questi ultimi tre parametri possono essere valutati numericamente, in riferimento al valore atteso).

Capitolo 2 – Le esigenze informative direzionali

Paragrafo 2.1 – Introduzione

In questo capitolo vengono esaminate le esigenze informative (e le corrispettive soluzioni) per i sistemi direzionali, complementari ai sistemi operativi e con essi interagenti.
Il sistema direzionale comprende in particolare le attività svolte dai dirigenti d’azienda, che includono la definizione degli obiettivi da raggiungere, il controllo dei risultati ottenuti e la definizione delle azioni correttive. Il sistema operativo comprende invece le attività esecutive attraverso cui l’azienda progetta, produce e vende i propri prodotti e servizi.
Scopo dei sistemi informativi direzionali è quello di supportare il sistema direzionale di un’azienda. Le esigenze direzionali comprendono generalmente due finalità primarie: il feedback sui risultati (che consiste nel fornire ai dirigenti l’analisi dei risultati ottenuti rispetto agli obiettivi) ed il supporto alle decisioni (che comprende invece una serie di informazioni, analisi ed elaborazioni attraverso cui sono definiti gli obiettivi).

Paragrafo 2.2 – Il modello di Anthony

Anthony propone una classificazione del sistema direzionale che è diventata canonica. Il sistema è concepito come una serie di cicli di pianificazione e di controllo, in cui si definiscono gli obiettivi da raggiungere, si verificano i risultati e si decidono le eventuali azioni correttive. Questi cicli sono distinti in tre livelli, ordinati gerarchicamente in un modello a forma piramidale:

• pianificazione strategica: determina e controlla gli obiettivi globali dell’impresa;
• controllo direzionale: si concentra sulla definizione e sulla verifica degli obiettivi economici;
• controllo operativo: definisce gli obiettivi delle attività esecutive, verificando che esse procedano nel modo prefissato.

 

Paragrafo 2.2.1 – Pianificazione strategica

Le informazioni necessarie alla pianificazione strategia sono ampie e variegate e pertanto poco adatte al rigido formato della basi di dati. Il valore delle informazioni è proporzionale alla capacità, tipicamente umana, di interpretarle (intelligence) e difficilmente surrogabile ad un elaboratore. Anche a questo livello si ritrovano comunque sistemi informativi di controllo strategico, attraverso cui monitorare alcune variabili comunque interessanti ai fini decisionali.

Paragrafo 2.2.2 – Controllo direzionale e controllo operativo

I sistemi informativi di controllo direzionale hanno lo scopo di confrontare periodicamente gli obiettivi ed i risultati e di svolgere l’analisi dei relativi scostamenti (aggregando e classificando i dati elementari elaborati dai sistemi di supporto operativo). Mentre il controllo direzionale utilizza prevalentemente variabile valorizzate, i sistemi di controllo operativo, invece, misurano grandezze fisiche (volumi di produzione, tempi, ecc…).

 

Paragrafo 2.3 – La griglia di Gorry e Scott-Morton

Da molti punti di vista, l’azienda può essere vista come un sistema decisionale. Riprendendo gli studi di Simon, Gorry e Scott-Morton hanno elaborato una griglia che incrocia i tre livelli della piramide di Anthony con le tre tipologie decisionali aziendali che hanno elaborato:

• decisioni strutturate: quelle decisioni per cui il processo di scelta è riducibile ad un algoritmo (essendo predefinite e note le variabili da considerare, le alternative di scelta ed i criteri decisionali);
• decisioni semi-strutturate: quelle decisioni in cui la scelta non è predefinibile, ma sono note e predefinite le variabili ed il procedimento di elaborazione (scelta tra più alternative);
• decisioni non strutturate: quelle decisioni in cui la scelta non è predefinibile e, in larga misura, non lo sono nemmeno le variabili da considerare.

 

Paragrafo 2.3 – La natura dell’informazione direzionale

Paragrafo 2.4.1 – Griglia di classificazione dell’informazione direzionale

Le informazioni direzionali sono un sistema che misura le prestazioni aziendali secondo prospettive rilevanti. I resoconti presentano sempre una serie di indicatori, che misurano le prestazioni obiettive ed effettive dell’azienda. Gli indicatori possono essere di varia natura (contabili, fisici, scale di giudizio), tempificati (in quanto si riferiscono ad un periodo di tempo più o meno lungo), aggregati (per il processo decisionale non servono informazioni relative alle singole transazioni, ma valori aggregati), multidimensionali (le tabelle forniscono una gamma di indicatori, segmentati rispetto alle dimensioni) e riferiti a diverse fasi gestionali (ad esempio budget, valori consuntivi, previsioni, preconsuntivi, ecc…).

Paragrafo 2.4.2 – Concetto di “dimensioni di analisi”

Le informazioni direzionali sono un sistema di coordinate, di cui due (rispettivamente gli indicatori ed il tempo) specificano la natura e la tempificazione dell’informazione, mentre le altre ne definiscono la segmentazione. E’ bene definire innanzitutto il concetto generico di dimensione, che si applica sia agli indicatori, sia alla dimensione tempo, sia alle dimensioni di analisi vere e proprie.
Definiamo dimensione un insieme di elementi appartenenti allo stesso dominio (ad esempio indicatori, centri di costo, date, ecc…). Il numero degli elementi presenti nell’insieme è definito cardinalità “C” della dimensione. Sugli elementi di una dimensione possono essere costruite delle gerarchie di aggregazione, ciascuna delle quali dà origine ad un albero di aggregazione. Gli elementi possono inoltre essere caratterizzati da attributi o proprietà, mediante primitive di specializzazione. Le specializzazioni possono anche essere multiple, quando un elemento appartiene a due o più specializzazioni. Esse suddividono una dimensione in sottodimensioni, ciascuna delle quali è identificata dalla proprietà differenziante.

Paragrafo 2.4.3 – Concetto di tempificazione

Le informazioni direzionali sono serie temporali che rappresentano l’andamento nel tempo di indicatori gestionali. Il dettaglio temporale di un indicatore è detto granularità ed indica l’intervallo di tempo minimo rilevato (ad esempio, il minuto). Le gerarchie di aggregazione temporale sono precostituite in base al calendario, mentre quelle di specializzazione si basano tipicamente sulle proprietà (o attributi) dei giorni (ad esempio giorni feriali/festivi).
Paragrafo 2.4.4 – Principali dimensioni di analisi

Nonostante il numero delle possibili dimensioni di analisi sia ovviamente elevato, nella maggior parte dei sistemi informativi direzionali è presente un numero relativamente limitato di dimensioni fondamentali:

• responsabilità: formata dalle unità organizzative in cui l’azienda è suddivisa. L’azienda è scomposta in una gerarchia di centri, secondo uno schema che ricalca l’organigramma aziendale. Abbinando alla gerarchia di centri un’opportuna lista di indicatori contabili e fisici, si ottiene una rendicontazione delle prestazioni, che responsabilizza i singoli dirigenti sui risultati di propria competenza ed è perciò detta responsability accounting;
• prodotto: finalizzata all’analisi di costi e ricavi dei singoli prodotti/servizi dell’azienda. Agli indicatori di contabilità si possono aggiungere scale di giudizio qualitative (ad esempio gli indici di qualità);
• cliente: ha lo scopo di analizzare le informazioni sulla redditività e sul volume di affari in base alle gerarchie dei clienti;
• attività e processi: finalizzata al controllo sistematico della performance dei processi dal punto di vista dei costi e degli indicatori fisici di efficienza ed efficacia (time to market, soddisfazione del clienti);
• progetto: tipica delle aziende che lavorano su commessa, ha lo scopo di pianificare e controllare periodicamente l’avanzamento dei progetti, fornendo una gamma di indicatori di prestazioni, sia di tipo economico/finanziario che di tipo fisico.

 

Paragrafo 2.5 – I metodi per valutare le esigenze informative direzionali

Obiettivo di un sistema informativo direzionale è fornire tutti e soli gli indicatori significativi. A tale scopo, il progettista può servirsi di diversi metodi per definire un insieme di indicatori coerenti con le priorità e la criticità manageriali. Dato per scontato che lo schema contabile del legal accounting è incompleto e troppo dettagliato, sono stati elaborati alcuni metodi classici per la valutazione:

• metodo dei Critical Success Factors (CSF);
• metodo dei Key Performance Indicators (KPI);
• metodo del management accounting.

 

Paragrafo 2.5.1 – Metodo dei CSF

I Critical Success Factors sono quelle poche aree nelle quali l’ottenimento di risultati positivi determina il conseguimento del successo nell’intero business, sia a livello individuale che di intera azienda. I CSF sono dunque aree di eccellenza, che come tali si distinguono dagli obiettivi (risultati da conseguire, espressi in termini ampi) e dai traguardi (quantificazioni tempificate degli obiettivi). Possibili fonti dei CSF sono:

• struttura del settore di attività: questi CSF rispecchiano le aree di eccellenza comuni a tutte le aziende operanti in un dato settore (ad esempio possono essere CSF la “qualità del personale” per le aziende di consulenza ed il “costo” per le aziende di produzione, ecc…);
• competizione: specifici della situazione aziendale nell’ambito del proprio settore di attività e del suo posizionamento competitivo (CSF possono essere, ad esempio, la “qualità del servizio” e la “gestione del viaggiatore abituale” per le compagnie aeree);
• fattori ambientali: rispecchiano vincoli esterni all’azienda, che tuttavia condizionano il successo aziendale (ad esempio, la “certificazione dei prodotti e dei processi”, le “normative in materia di ecologia”, ecc…);
• fattori temporali: sono CSF che si riferiscono al superamento di una situazione contingente, specifica dell’azienda (ad esempio il “recupero di una certa immagine presso i clienti”).

 

I CSF si evolvono nel tempo e possono arrivare a variare considerevolmente con il passare degli anni. In un’azienda è inoltre possibile individuare più livelli gerarchici di CSF, che si accompagnano alle corrispondenti strategie, obiettivi, traguardi.
Ai CSF sono abbinati opportuni indicatori di prestazione, dedotti in collaborazione con il manager o individuati mediante altri procedimenti. Non tutti gli indicatori si prestano però ad essere elaborati da un sistema informativo su elaboratore ed è pertanto utile operare una verifica della robustezza. Per tale verifica, si utilizza solitamente una griglia di criteri formata da:

• facilità di comprensione: direttamente legata all’intuitività dell’algoritmo con cui l’indicatore è calcolato;
• costo dell’informazione: dà una valutazione del costo di produzione di un certo indicatore;
• significatività: indica il contributo, espresso in termini percentuali, che l’indicatore dà alla misurazione del CSF considerato;
• frequenza: periodicità con cui l’indicatore viene campionato;
• strutturazione: valutazione, in termini relativi, della determinatezza delle informazioni.

 

La robustezza dell’indicatore in esame, si calcola quindi come giudizio complessivo sulla base degli attributi elencati. Gli indicatori “non robusti” devono essere scartati o comunque modificati.
A differenza degli altri metodi per la selezione delle informazioni direzionali, il metodo dei CSF si basa sulla derivazione delle informazioni, a partire dalle priorità del manager. A questo non viene infatti chiesto di quali informazioni necessita, ma quali sono le aree in cui pensa di dover eccellere per avere successo.

Paragrafo 2.5.2 – Metodo dei KPI

I Key Performance Indicators servono per misurare le prestazioni dei processi gestionali (business process). Nell’attuale ambiente competitivo, il valore per il cliente non è dato esclusivamente dal prezzo, ma dalla valutazione complessiva di varie categorie di prestazioni tra cui:

• efficienza: indicatori che misurano la produttività ed i costi unitari con cui sono ottenuti gli output per i clienti del processo ;
• qualità: indicatori che misurano la conformità dell’output alle attese del cliente;
• livello di servizio: parametrazione dei tempi di risposta alle richieste del cliente e della flessibilità del fornitore.

 

Queste tre misure di prestazioni verso il cliente possono essere integrate da altri indicatori che aggiungono informazioni sul contesto: volumi (in input ed output) e risorse impegnate nel processo.
Il paniere degli indicatori è specifico di ogni processo e cambia, pure per lo stesso processo, da azienda ad azienda. Scopo del metodo KPI è quello di individuare un numero ridotto di indicatori, che misurino le prestazioni competitive di un dato processo. Tale individuazione avviene con riferimento ai tre livelli succitati (efficienza, servizio e qualità) e ciò fa sì che, concettualmente, il metodo dei KPI sia analogo a quello dei CSF (in entrambi i casi, infatti, le informazioni sono derivate da un analisi dei processi gestionali). Identificate le informazioni, il progettista le valida da diversi punti di vista, verificando la robustezza degli indicatori ed incrociando i KPI con gli indicatori CSF. L’”esame della copertura CSF” consiste nel verificare l’incrocio tra KPI e CSF, in quanto è desiderabile che una parte dei KPI coprano le aree CSF: in caso contrario, infatti, i processi sarebbero monitorati attraverso indicatori non correlati alle aree critiche di successo aziendale.

Paragrafo 2.5.4 – Management accounting

Il sistema di management accounting ha lo scopo di rilevare le prestazioni, dal punto di vista economico e patrimoniale, di ogni segmento aziendale avente rilevanza ai fini decisionali. Le dimensioni di analisi e la gamma delle voci economico/patrimoniali possono variare su di una scala molto ampia. Aspetto caratteristico del metodo del management accounting rispetto ai CSF e KPI è l’orientamento prevalentemente contabile degli indicatori (che possono essere ad esempio ricavi lordi, sconti, promozioni, ecc…).

Paragrafo 2.6 – L’architettura informatica direzionale

Tutti i sistemi informativi aziendali sono caratterizzati da un’architettura informatica su più livelli, corrispondenti ai diversi stadi di trasformazione dei dati elementari provenienti dai sistemi di supporto operativo o da altre fonti.

Paragrafo 2.6.1 – Lo schema a livelli

In linea generale, l’architettura dei SI direzionali è stratificata su quattro livelli, ciascuno dei quali caratterizzato da propri obiettivi e tecnologie:

• livello 1 - basi dati transazionali: sono i serbatoi dei dati, che forniscono la “materia prima “ al sistema direzionale;
• livello 2 – alimentazione: può essere manuale (i dati sono digitati sulle tastiere di PC) o automatica (vi è una serie di programmi che estraggono i dati e, dopo averli opportunamente “normalizzati” ed aggregati, li riversano nella base dati direzionale);
• livello 3 – base dati direzionale: comprende le informazioni strutturate secondo il formato tipico dell’informazione direzionale;
• livello 4 – elaborazione e presentazione delle informazioni: è costituito dai sistemi che calcolano e presentano i contenuti della base dati direzionale e comprende sia il motore di calcolo, sia i sistemi di presentazione dell’informazione (suite OLAP), nelle due modalità EIS/GUI e Report/Query.

 

Paragrafo 2.6.2 – Livello 1: basi dati transazionali

Le basi dati transazionali memorizzano singole transazioni, che registrano eventi gestionali (ad esempio l’emissione di una fattura). Le registrazioni contenute nella base dati transazionale sono classificabili in registrazioni anagrafiche e registrazioni transazionali.

Paragrafo 2.6.3 – Livello 2: alimentazione della base dati direzionale

Una base dati direzionale raccoglie le informazioni che si riferiscono ad un dato tema (ad esempio i clienti, o il controllo di un’azienda). Le informazioni raccolte sono multidimensionali e tempificate: conseguentemente, l’alimentazione della base dati implica una vera e propria trasformazione dei dati transazionali che ne determina la tempificazione, la selezione delle misure da rilevare, il dimensionamento ed eventuali algoritmi di calcolo.
Paragrafo 2.6.4 – Livello 2: alimentazione manuale dei dati (Data Entry)

Siccome non tutti i dati di un sistema informativo direzionale sono ricavati dalle basi di dati transazionali, il sistema è alimentato anche da procedure di data entry (registrazione da tastiera). Il data entry è rilevante nei sistemi facenti capo alle aziende complesse e territorialmente distribuite (approccio bottom-up al budget).

Paragrafo 2.6.5 – Livello 3: base dati direzionale

La base dati direzionale è un particolare tipo di base dati, caratterizzato dal contenuto (informazioni tempificate ed aggregate) e dallo schema multidimensionale. Tale schema può essere immaginato come un ipercubo, ogni asse del quale è formato da una delle dimensioni di analisi, e la cui cardinalità è data dal prodotto delle cardinalità delle sue dimensioni, ivi inclusi il tempo e la dimensione degli indicatori. La cardinalità indica il numero massimo di celle contenute nell’ipercubo. Ogni cella è individuata da una tupla di coordinate (una per ciascuna dimensione dell’ipercubo). I valori contenuti nelle celle possono essere anche nulli (celle “vuote”) e su questa base definiamo come “sparsità” il rapporto tra le celle piene e le celle totali dell’ipercubo (anche se sarebbe più appropriato utilizzare il termine di “tasso di riempimento”). In molti casi, può essere opportuno introdurre le gerarchie di aggregazione/specializzazione all’interno di ciascuna dimensione dell’ipercubo.

Paragrafo 2.6.6 – Livello 3: soluzione relazionale (Data Warehouse)

La realizzazione della base dati multidimensionale può seguire due soluzioni principali, rispettivamente relazionale e multidimensionale pure. Nel caso della tecnologie relazionale, la base dai è rappresentata da tabelle raggruppabili in tre tipi:

• tabelle dei fatti: che riportano i valori delle misure;
• tabelle delle dimensioni: che elencano gli elementi delle varie dimensioni considerate;
• tabella del tempo che elenca le date considerate.

 

Siccome le dimensioni (e di conseguenze le tabelle delle dimensioni) sono multiple e sono correlate alla tabella dei fatti, lo schema relazionale assume la caratteristica forma “a stella” (star-schema).
La tabella dei fatti può contenere una chiave esterna composta (composite foreign key), ottenuta dall’unione delle chiavi identificative di tutte le dimensioni: essa determina il valore delle coordinate nel vettore delle dimensioni. Lo schema relazionale qui esemplificato è detto Data Warehouse. Nel gergo commerciale, le soluzioni OLAP basate sulla tecnologia relazionale prendono il nome di ROLAP (Relational OLAP). I requisiti tecnologici della Data Warehouse sono perlopiù gli stessi di una qualsiasi BD relazionale, salvo per sistemi informativi ampi, nei quali sorgono esigenze di multi-utenza, architettura client/server, ecc….

Paragrafo 2.6.7 – Livello 3: soluzione multidimensionale (MOLAP)

La base dati direzionale può essere realizzata anche con tecnologie non relazionali, memorizzando direttamente le celle dell’ipercubo. Tale modello multidimensionale puro è detto MOLAP (Multidimensional OLAP) e la sua definizione è molto semplice: tutte le dimensioni (incluso il tempo) e le misure sono considerate vettori di una matrice multidimensionale (ovvero assi di un ipercubo). Questa tecnologia ha il grosso vantaggio della rapidità notevolmente maggiore rispetto a quella relazionale, ma soffre ancora la mancanza di uno standard.
Paragrafo 2.6.8 – Livello 4: strato di calcolo e presentazione (OLAP)

Il quarto livello dell’architettura informatica direzionale comprende tre classi di strumenti software: i motori di calcolo, i sistemi EIS/GUI ed i sistemi di Reporting/Query. Essi sono definiti strumenti OLAP, in quanto offrono un insieme di funzionalità specifiche, così come definito con l’acronimo FASMI. Tale acronimo sta ad indicare:

• fast: obiettivo fondamentale del sistema è la velocità di risposta;
• analysis: l’applicazione deve essere in grado di svolgere qualsiasi analisi rilevanti ai fini direzionali;
• shared: esprime l’esigenza di un uso condiviso dell’applicazione;
• multidimensional: vista multidimensionale dei dati;
• information: l’accesso ai dati deve essere indipendente dalla piattaforma fisica su cui essi risiedono e dal formato di codifica.

 

Paragrafo 2.6.9 – Livello 4: tecnologia EIS/GUI

Obiettivo della tecnologia EIS/GUI è permettere una navigazione guidata attraverso una gerarchia di indicatori, mediante un’interfaccia utente di tipo GUI (Graphical User Interface), con bottoni ed icone di immediato utilizzo. La navigazione abilita:

• l’esplosione a livelli di dettaglio successivi (drill down) di un indicatore nell’ambito di una stessa dimensione di analisi;
• la navigazione attraverso le dimensioni (drill across);
• la combinazione delle due navigazione precedenti (drill anywhere).

 

Le funzionalità dei prodotti EIS/GUI possono essere articolate nelle quattro macro-categorie di navigazione, presentazione, elaborazione e comunicazione:

• navigazione: può essere distinta in navigazione infologica (slice & dice), limitata all’esplorazione in ottica multidimensionale di un singolo indicatore ed in navigazione a valore aggiunto, che si sposta tra indicatori correlati ed organizzati secondo una struttura che rispecchia le relazioni causa-effetto esistenti fra di essi;
• presentazione: principale requisito è la presenza di un’interfaccia grafica dotata di menu di scelta e bottoni di utilità per navigare, impostare calcoli o comunicare;
• elaborazione: richiede tempi di risposta compatibili con la dinamica delle speculazioni condotte sui dati dall’analista;
• comunicazione: un’applicazione EIS deve consentire l’accessibilità delle risorse del Web e l’invio di e-mail contenenti porzioni delle analisi svolte.

 

Paragrafo 2.6.10 – Livello 4: tecnologia Query/Reporting

Finalità del sistema di Query/Reporting è facilitare la composizione di prospetti riepilogativi (“viste” della base dati direzionale, ottenute mediante operazioni di algebra relazionale o algoritmi). In sintesi, il software di Query/Reporting è uno strumento finalizzato ad assistere il gestore del sistema nel compiere analisi “ad hoc”.
Requisiti fondamentali dei sistemi di Q/R devono essere la gestione del formato (possibilità di aggiungere/rimuovere colonne), l’amministrazione del report (possibilità di progettare report alimentati in batch e distribuirli ad un’utenza distribuita differenziata secondo profili di utenza), il supporto import/export dei dati (da e verso formati di office automation) e le funzionalità di supporto alla certificazione dei dati (per l’emissione di report “ufficiali”).

Paragrafo 2.6.11 – Livello 4: motore di calcolo

Il termine “motore di calcolo” designa qualsiasi software finalizzato ad elaborazioni di tipo algoritmico. Esso deve generalmente essere in grado di costruire modelli previsionali, modelli per il calcolo del budget (nonché per il raffronto tra varie alternative/scenari di budget), effettuare controlli budgetari (responsability accounting) e calcolare la contabilità industriale. Per ottenere tali obiettivi, i motori di calcolo offrono le seguenti funzionalità:

• totalizzazione dei dati lungo le gerarchie di aggregazione (roll-up) tipiche di tutte le strutture di controllo;
• calcolo di formule ed equazioni di varia complessità.

 

Paragrafo 2.7 – Le applicazioni informatiche direzionali

Dalla reciproca interazione tra i concetti di informazione direzionale e le correlate tecnologie informatiche, sono venute emergendo alcune famiglie di soluzioni, che condividono l’architettura informatica a quattro livelli e le caratteristiche logico-strutturale dell’informazione direzionale, distinguendosi invece per destinatari, contenuti e tecnologie. Tra queste soluzioni, esamineremo i tableau de bord, l’EIS, i cruscotti gestionali ed i sistemi di management accounting.

Paragrafo 2.7.1 – Tableau de bord

Il tableau de bord è una serie di informazioni sintetiche di varia natura e fonte, finalizzate a dare all’amministratore delegato le indicazioni utili per guidare l’azienda sia nei rapporti con i suoi dirigenti, sia nelle relazioni con l’esterno (stampa, azionisti, ecc…). Nella pratica aziendale, elemento critico del tableau de bord non è tanto l’informatizzazione (che spesso è semplicemente questione di office automation), quanto le attività di approvvigionamento/lavorazione delle informazioni.

Paragrafo 2.7.2 – EIS

Oltre ad indicare il “contenitore tecnologico” (paragrafo 2.6.9), il termine Executive Information System può denotare anche il contenuto, cioè le informazioni destinate ai dirigenti. In questo secondo senso, l’EIS indica un sistema informatizzato, che memorizza in apposite basi dati le informazioni (prevalentemente strutturate) selezionate da sistemi informativi interni (prevalentemente direzionali) e da fonti esterne. Scopo dell’EIS aziendale è fornire ai dirigenti una banca dati unica e certificata, i cui contenuti possono essere molto vari (coincidenti con il tableau de bord, così come limitati ad un sistema di navigazione tra le basi dati esistenti).

Paragrafo 2.7.3 – Cruscotti gestionali

Il cruscotto gestionale ha lo scopo di offrire al dirigente responsabile di un processo gestionale i parametri delle prestazioni critiche, selezionati con il criterio dei KPI descritto precedentemente.

 

Paragrafo 2.7.4 – Management accounting

Dal nostro punto di vista, il management accounting (contabilità gestionale e direzionale) è un sistema informativo direzionale, che organizza le informazioni secondo uno schema contabile o paracontabile. Dal punto di vista del flusso delle informazioni, il sistema può essere considerato come un procedimento di riclassificazione dei dati catturati da sistemi amministrativi (ad esempio contabilità fornitori, fatturazione ai clienti, ecc…). Le informazioni fornite sono finalizzate al confronto tra obiettivo e risultato (con analisi del gap) e sono segmentate secondo la dimensione “responsabilità”, in modo da poter controllare obiettivi e risultati di ciascuno dei centri di responsabilità in cui l’azienda è suddivisa (responsability accounting). Grazie ai progressi della tecnologia, è oggigiorno possibile una classificazione contestuale delle informazioni contabili. Al momento della sua registrazione, in sostanza, la transazione è codificata secondo un tracciato unificato, che serve sia la contabilità civilista che quella gestionale (sistema informativo “unico”).

Capitolo 3 – I sistemi di supporto operativo

Paragrafo 3.1 – Introduzione

I sistemi informativi di supporto operativo sono in larga parte costituiti da elaborazioni interattive di transazioni (ad esempio le prenotazioni di posti sugli aerei), dette OLTP (On Line Transaction Processing), elaborazioni a lotti transazionali (batch processing) (ad esempio l’elaborazione delle bollette telefoniche), anagrafi aziendali (ad esempio dei prodotti di un’azienda) o interaziendali. L’informazione contenuta nei sistemi informativi di supporto operativo è generalmente un dato anagrafico o la registrazione di un evento o atto gestionale.

Paragrafo 3.2 – Le finalità dei sistemi di supporto operativo

Le finalità delle informazioni operative possono essere distinte in tre grandi categorie:

• elaborazione delle transazioni;
• pianificazione delle operazioni;
• acquisizione ed organizzazione della conoscenza.

 

Paragrafo 3.2.1 – Elaborazione delle transazioni

Un’azienda può essere vista come una serie di processi gestionali interconnessi, che generano transazioni. Per transazione, intendiamo una categoria logica molto ampia, che comprende varie sottocategorie (scambi e contratti tra impresa ed attorni interni/esterni, operazioni ed eventi, quali trasformazioni, movimenti fisici, atti, eventi vari) e che si rispecchia in documenti e/o registrazioni trasferibili nel tempo o nello spazio. A parità di fattori, il numero di transazioni aumenta al crescere di passaggi di luogo o di stato (un processo di produzione geograficamente distribuito, in sostanza, genera un numero maggiore di transazioni rispetto ad un processo eseguito in una sola officina).

Paragrafo 3.2.2 – Pianificazione delle operazioni

Nelle aziende industriali sono presenti procedure di programmazione, che hanno lo scopo di fissare gli obiettivi e di fornire le istruzioni di lavoro. Un esempio caratteristico è la programmazione della produzione.

Paragrafo 3.2.3 – Conoscenza e banche dati

Terza finalità dell’informazione operativa è la creazione di archivi capaci di fornire tutte le informazioni relative ad un certo tema. Ne sono esempi l’anagrafe dei clienti di una banca o la distinta base dei prodotti di un’azienda.

Paragrafo 3.3 – La natura dell’informazione operativa

Nonostante sino ad oggi non sia stata elaborata una definizione comunemente accettata dell’informazione operativa, è conveniente procedere ad una classificazione delle tipologie rilevanti di informazioni operative ed all’analisi delle loro caratteristiche.

Paragrafo 3.3.1 – Tipologie di informazioni operative

In generale è possibile distinguere tre categorie di informazioni operative, particolarmente significative per l’elaborazione delle transazioni:

• informazioni anagrafiche: che riportano le caratteristiche fisse (invarianti) relative a prodotti, macchinari, progetti, materiali, attori o rapporti tra attori (contratti, ordini, ecc…);
• movimenti: che registrano gli attributi delle transazioni, indicando l’attore che compie la transazione, il bene oggetto ed il rapporto che regolamenta la transazione stessa;
• informazioni di stato: associate alle informazioni anagrafiche o ai movimenti, qualificano la disponibilità dei beni/servizi oggetto delle transazioni.

 

In sintesi si può quindi affermare che l’informazione operative descrive la struttura del processo (informazioni anagrafiche), misura lo stato del sistema (informazioni di stato) e documenta le transazioni (movimenti).

Paragrafo 3.3.2 – Caratteristiche delle informazioni operative

In via indicativa, le informazioni operative possono essere caratterizzate rispetto a tre criteri:

• aggregazione: misura il grado di sintesi delle registrazioni rispetto agli eventi del mondo reale (il grado di aggregazione è 1 quando ogni registrazione corrisponde ad un solo evento);
• tempificazione: riguarda l’arco temporale cui l’informazione si riferisce (l’informazione è puntuale quando è modificata ogni volta in cui si verifica un evento, altrimenti cumulativa);
• dimensionalità: proporzionale al numero di chiavi necessarie all’individuazione univoca di una specifica informazione.

 

Analizzando le informazioni operative sotto questa prospettiva notiamo che:

• le informazioni anagrafiche hanno livello di aggregazione unitario (ogni registrazione corrisponde ad un solo elemento, ad esempio singolo cliente o prodotto), una tempificazione puntuale (vengono aggiornate appena si verifica o viene comunicato un evento, come il cambio di residenza nell’anagrafe comunale) ed una dimensionalità contenuta (normalmente prossima ad 1, come nel caso dell’anagrafica fiscale che ha come chiave il codice fiscale);
• le informazioni di stato hanno livello di aggregazione maggiore di uno (ogni dato è determinato sommando e/o sottraendo degli elementi da un dato iniziale), tempificazione puntuale o aggregata (a seconda che il valore di saldo sia aggiornato in tempo reale o periodicamente) ed una dimensionalità contenuta (normalmente prossima ad 1);
• i movimenti hanno livello di aggregazione unitario (ogni registrazione corrisponde ad un solo evento), una tempificazione puntuale (le informazioni sono registrate nel momento in cui si verifica l’evento) ed una dimensionalità generalmente maggiore o uguale a due (ogni transazione è solitamente individuata precisando l’oggetto e l’attore della transazione).

 

Paragrafo 3.4 – L’intensità informativa e l’attrattività informatica

In generale, la potenzialità che l’informatica offre ad un’organizzazione appare funzione di tre fattori complementari ma distinti tra loro: P = f (D, A, I), dove:

• P: potenzialità informatica;
• D: discrezionalità del management nell’utilizzare la leva delle tecnologie informatiche;
• A: attrattività informatica, cioè la capacità oggettiva delle TI di soddisfare il fabbisogno informativo dell’azienda;
• I: intensità informativa dell’azienda, cioè il livello e la complessità delle informazioni utilizzate nel business aziendale.

 

Paragrafo 3.4.1 – Intensità informativa e complessità organizzativa

Tra i modelli che illustrano il rapporto tra intensità informativa, complessità organizzativa ed utilizzo delle TI, merita una citazione quello di Galbraith. Secondo lo studioso, l’intensità informativa può essere considerata funzione di due variabili: I = f (U, C). Le due variabili in questiono, U e C, sono rispettivamente l’incertezza (data dalla differenza tra le informazioni disponibili all’inizio del compito e le informazioni necessarie a svolgere il compito stesso) e la complessità del compito (proporzionale al numero dei componenti dei prodotti, al numero dei fornitori ed al numero dei prodotti). E’ evidente che aziende con elevata incertezza o con compiti molto complessi devono aumentare la propria capacità di elaborare informazioni, oppure ridurre l’intensità informativa.

Paragrafo 3.4.2 – Intensità informativa

Porter e Millar, affermano che il fabbisogno informativo di un’azienda (I) è dato dalle combinazioni di due determinanti complementari e parzialmente indipendenti: l’intensità informativa del prodotto (determinata dalla natura del prodotto e dall’intensità informativa dell’uso del prodotto) e l’intensità informativa del processo (che rispecchia il peso dei sistemi informativi ed il numero delle transazioni operative che accompagnano i processi di progettazione, produzione, vendita e distribuzione).

Paragrafo 3.4.3 – Attrattività informatica

L’attrattività informatica è parzialmente indipendente dall’intensità informativa. Si tratta della capacità oggettiva delle TI di soddisfare il fabbisogno informativo di un’azienda. Determinanti che favoriscono l’adozione delle tecnologie informatiche sono:

• proceduralità: designa il grado di strutturazione del processo attraverso cui l’informazione viene elaborata;
• volumi: indica quantità di dati elaborati da una singola procedura;
• ripetitività: indice della frequenza con cui una certa elaborazione viene ripetuta, utilizzando una procedura standard;
• semplicità di elaborazione: valutata in base al numero di operazioni algebriche, statistiche e logiche contenute nella procedure di elaborazione, oppure in base al numero di operazioni relazionali sulla base dati.

 

Paragrafo 3.5 – L’architettura dei sistemi di supporto operativo

L’architettura informativa dei sistemi di supporto operativo comprende due elementi: la base dati (che contiene le informazioni memorizzate) e le elaborazioni (che leggono e scrivono sulla base dati). L’unicità logica dei dati è obiettivo fondamentale dei sistemi informativi aziendali, in quanto più elaborazioni devono poter condividere la medesima base dati.

Paragrafo 3.6 – La base dati operativa

Si è visto che la base dati operativa contiene una gamma vasta e diversificata di registrazioni. E’ comunque evidente che le informazioni operative dell’azienda sono distribuite su numerose basi dati che possono essere classificate, in ragione della loro finalità, in due categorie:

• banche dati aziendali: raccolgono tutte le informazioni relative ad un dato tema (ad esempio, anagrafe prodotti o datawarehouse clienti);
• basi dati transazionali: raccolgono e memorizzano i movimenti relativi alle transazioni di un processo.

 

Paragrafo 3.7 – La segmentazione dei bisogni: il portafoglio applicativo

Per valutare i bisogni informativi aziendali, la letteratura ha elaborato una forma di segmentazione basata sul concetto di “portafoglio applicativo”. Con il termine “portafoglio” si intende l’insieme delle possibili applicazioni della tecnologia dell’informazione e più precisamente quella dei sistemi informativi aziendali (SIA). Il portafoglio può essere diviso in tre segmenti principali: portafoglio direzionale (già trattato nel capitolo 2, contiene le applicazioni utilizzate dai manager nelle loro attività di decisione e di analisi), portafoglio istituzionale e portafoglio operativo.

Paragrafo 3.7.1 – Portafoglio istituzionale

Il portafoglio istituzionale contiene le applicazioni di supporto a quel sottoinsieme di attività, che nella catena di Porter sono classificate come “infrastrutturali” (ovvero quelle che hanno normalmente lo scopo di eseguire adempimenti di legge o di amministrare le risorse). I contenuti del portafoglio istituzionale sono generalmente influenzati da vari fattori: la regolamentazione esterna (che riflette i criteri della legislazione nazionale, determinando il contenuto delle procedure), la dimensione ed organizzazione dell’azienda (che influiscono sulla complessità dei processi) ed i settori di attività in cui l’azienda opera (che incidono, limitatamente, su alcuni contenuti procedurali, come ad esempio i contratti di lavoro).
Date le procedure particolarmente adatte all’automazione (grossi volumi, forte proceduralità, ripetitività, periodicità e semplicità di elaborazione) il portafoglio istituzionale è stata la prima area informatizzata delle aziende.

 

Paragrafo 3.7.2 – Portafoglio operativo

Il portafoglio operativo comprende le applicazioni informatiche utilizzate dalle attività che, nella catena del valore di Porter, sono classificate come attività primarie o di supporto diretto. Siccome le attività primarie sono determinate dalle caratteristiche del mercato, il portafoglio operativo è specifico di ogni settore industriale.

Paragrafo 3.9 – Le applicazioni nell’area della logistica (MRP)

Intorno agli anni ’70, grazie alla maturazione della tecnologie e delle cognizioni sul SIA, si affrontò strutturalmente il problema del sistema informativo logistico di produzione, consolidando una famiglia di sistemi noti sotto il nome di Manufacturing Resource Planning (MRP). Materialmente, un sistema MRP è formato da una serie di applicazioni software che coprono produzione ed approvvigionamenti, dal livello della programmazione operativa sino alla gestione dei flussi fisici dei materiali e, in modo più limitato, alle operazioni fisiche delle officine. Caratteristiche principali di un sistema MRP tradizionale sono un’unica base dati condivisa (da cui attingono ed a cui versano tutti i programmi elaborazione, assicura la sincronizzazione/integrità del sistema informativo), elaborazioni periodiche a lotti e l’orientamento al coordinamento della produzione ed alla programmazione degli obiettivi. Tra i limiti di questi sistemi, va segnalato che la ricerca dell’ottimizzazione attraverso la concatenazione dei piani di produzione ed approvvigionamento a cadenza mensile, settimanale, giornaliera e talvolta di turno, irrigidisce la produzione.

Paragrafo 3.11 – I sistemi integrati di gestione (ERP)

Poiché oggigiorno quasi tutte le aree di possibile utilizzo delle TI sono state coperte, il problema non è informatizzare, ma integrare le applicazioni esistenti, spesso divenute isole di automazione sviluppate secondo logiche gestionali e tecnologie differenti. E’ venuta così evolvendo una nuova generazione di soluzioni software, le cosiddette soluzioni ERP (Enterprise Resource Planning), che di fatto propongono un sistema integrato di gestione (ovvero un insiemi di moduli software che operano su un’unica base dati opportunamente concepita) in sostituzione, parziale o completa, dei sistemi precedenti. L’adozione di sistemi integrati risolve all’azienda i molteplici problemi di interfacciamento che sorgono con applicazioni separate (creazione e mantenimento di diverse interfacce software). D’altro canto, però, l’introduzione di un sistema ERP provoca una “declassificazione” dei programmatori a semplici “parametrizzatori” ed un aumento delle spese in consulenze specialistiche. Altri aspetti negativi sono la difficoltà di installazione (data proprio dalla completa integrazione del sistema) e i lunghi tempo di “messa in marcia” del sistema.