Gli strumenti di visual modeling come ponte tra progettazione organizzativa e progettazione informatica

 esplicitare le finalità e obiettivi del nuovo sistema, definire le 
risorse necessarie per realizzare i sistemi, individuare le iniziative di 
cambiamento inquadrandole in progetti definiti, ma soprattutto 
elaborare un quadro di riferimento complessivo in cui porre le 
specifiche iniziative informative, che consenta di realizzare un 
sistema informativo che sia efficace, quindi in grado di essere a 
supporto alla missione, agli obiettivi, alle operazioni 
dell’organizzazione e al tempo stesso efficiente. 
Ne consegue che la pianificazione dei sistemi informativi, oltre 
ad assumere un'ottica aziendale e non settoriale, non può che 
prendere spunto dalla pianificazione strategica mutuandone 
missione, strategie ed indirizzi; la pianificazione dei S.I. deve 
quindi partire da una precedente esplicitazione del piano strategico 
dell’organizzazione. 
Nella pianificazione dei S.I. si confrontano l'approccio top-down 
e l'approccio bottom-up; secondo il primo orientamento si parte 
dagli obiettivi strategici dell'organizzazione per definire poi le 
caratteristiche generali del sistema informativo, le aree di intervento 
e gli specifici progetti per realizzarlo, verificandone la coerenza con 
le esigenze espresse dagli uffici.  
Con l'approccio bottom-up vengono invece raccolte 
prioritariamente le indicazioni delle diverse unità organizzative, che 
successivamente vengono integrate e razionalizzate, definendo 
contemporaneamente le priorità all'interno del budget complessivo. 
L'approccio bottom-up è più conservativo e difficilmente riesce a 
produrre ipotesi di innovazione radicale, mirando sostanzialmente 
al miglioramento dell'esistente ma nello stesso tempo presenta 
scarsi rischi realizzativi. È da preferire quindi l'approccio top down, 
 che è più innovativo e discontinuo, e consente di individuare e 
pianificare anche soluzioni che rispondono a necessità di mutamenti 
radicali, consentendo quindi il BPR. 
Una volta effettuata questa fase, si potrà passare a fasi più tipiche 
dell’ingegneria del software come: l’analisi che consente di 
determinare  gli obiettivi del nuovo sistema, il disegno che permette 
di andarlo a rappresentare nei suoi elementi in una forma più vicina 
all’uomo che alla macchina, la codifica ossia la traduzione del 
disegno in un linguaggio comprensibile alle macchine, la fase di 
test per correggere eventuali errori, l’installazione e manutenzione, 
che consentiranno di ottenere il prodotto finale e funzionante. 
Quello che abbiamo analizzato è un percorso per così dire ideale, 
alla luce delle attuali conoscenze, da seguire per andare a realizzare 
sistemi informativi di qualità, ossia in grado di rispondere alle 
esigenze dell’utente in termini di efficacia e di efficienza. A questo 
punto possiamo: chiederci ma siamo veramente sicuri che le 
aziende che nel passato hanno realizzato un SI lo hanno veramente 
seguito? E inoltre, che pur avendolo seguito hanno realizzato un 
prodotto di qualità? 
La risposta a queste domande purtroppo è negativa. 
Infatti per molto tempo i sistemi informativi sono stati realizzati 
andando semplicemente ad introdurre, in tempi e con modalità 
differenti e in singole aree e funzioni, dei semplici programmi 
ottenendo quindi delle “isole di automazioni” che poi sono state 
accorpate per rispondere alle crescenti esigenze informative 
dell’azienda. Sebbene fosse funzionale, questa soluzione suscitò 
non pochi problemi: difficoltà di collegare tra loro sistemi, presenza 
massiccia di dati replicati, difficoltà di prevedere le conseguenze di 
 modifiche alle applicazioni e difficoltà ad implementarle. Per 
rifarmi a termini economici, la soluzione non era né efficace 
(spesso infatti non si potevano ottenere le informazioni che si 
desideravano perché non erano previste dal sistema) né efficiente in 
quanto richiede un notevole esborso finanziario per riuscire a 
mantenere ed integrare sistemi così diversi tra loro. Quindi alla 
prima domanda dobbiamo dare una risposta negativa, almeno fino a 
un certo periodo, visto che il percorso di sviluppo proposto è 
abbastanza recente. 
Se anche andiamo a considerare aziende che hanno realizzato i 
loro sistemi informativi in tempi più recenti, e quindi si presuppone 
che abbiano seguito il percorso indicato, otteniamo risultati in 
termini di efficienza e di efficacia negativi. Un celebre studio
1
 
effettuato dallo Standish Group, nel 1994, su un campione di 8000 
progetti, riporta risultati sconfortanti: 16% di successi, 53% di 
fallimenti parziali (gravi problemi sulle funzionalità, sui costi e/o 
sui tempi), 31% di fallimenti completi (progetto cancellato); e come 
questa sono molte altre le statistiche in questa direzione. Alla 
domanda dobbiamo quindi, anche in questo caso, rispondere 
negativamente nel senso che nella maggior parte dei casi il risultato 
è di scarsa qualità. Lo studio riporta anche i motivi di questo 
fallimento e individua come cause principali problemi legati alla 
fase di analisi dei requisiti, e anche problemi manageriali come la 
mancanza della fase di pianificazione; da notare come nessuno dei 
problemi è di natura tecnica. 
                                          
1
 Dati tratti dall’articolo “I requisiti: l’anello debole dello sviluppo software” di Adriano 
Comai, pubblicato sul sito www.Analisi-Disegno.it.  
 Ma allora, se il fallimento di molti sistemi informativi è da legare 
a queste fasi non propriamente informatiche ma di comprensione 
delle esigenze e di modellazione concettuale della soluzione, perché 
non si pone una maggiore attenzione nello svolgerle, utilizzando 
anche degli strumenti a supporto per facilitarle? 
Al tempo in cui si riferisce questa statistica tali strumenti ancora 
non esistevano, o avevano un’applicazione ( e un mercato) limitata 
concentrandosi principalmente sullo svolgimento delle fasi di 
codifica, ma oggi sono presenti sul mercato degli strumenti che 
andiamo a chiamare tool per il Visual Modeling, che secondo 
quanto proposto dai venditori sono in grado di offrire un approccio 
completo e pienamente integrato per la realizzazione dei sistemi 
informativi, che parta dall’alto fino a giungere al prodotto finito. 
Per cui l’obiettivo di questa tesi è di andare a dimostrare quanto 
questi strumenti consentono non solo di effettuare una 
progettazione informatica (evidenziando da dove iniziano e fino a 
quale punto si spingono nel percorso che porta alla realizzazione dei 
SI), ma anche se consentono di realizzare una progettazione 
organizzativa. Ossia dobbiamo vedere se sono anche in grado di 
reingegnerizzare i processi, alla luce dei risultati positivi connessi 
con il BPR. Il tutto verrà realizzato tramite un’attività di prova 
diretta dei principali strumenti presenti sul mercato, e anche grazie 
ad una valutazione effettuata tramite una tabella apposita che è stata 
distribuita a vari utilizzatori degli stessi, al fine di migliorare la 
consistenza dello studio. 
 Capitolo 1 
Sistemi informativi ed 
Organizzazione 
 
Introduzione 
L’identificazione e l’analisi dei processi non rappresenta certo 
una novità per chi si occupa di sistemi informativi; nelle 
metodologie per la loro realizzazione è praticamente sempre 
presente una fase, in genere chiamata “analisi delle funzioni” e 
spesso parallela all’analisi dei dati, che esamina le attività per 
determinare le funzioni da sviluppare. 
La grande novità introdotta dal concetto di “reingegnerizzazione 
dei processi” non è quindi l’attenzione ai processi, alle attività e alle 
funzioni, quanto nel mettere il cambiamento dei processi al centro 
dell’analisi e della progettazione dei nuovi sistemi informativi. 
Tradizionalmente i processi e le attività erano infatti considerati 
sostanzialmente invarianti rispetto l’intervento di automazione, 
costituendo talvolta anche un “vincolo” nella realizzazione dei 
nuovi sistemi; i processi già c’erano e l’introduzione 
dell’informatica serviva solo per rendere automatiche le attività di 
cui non si mettevano in discussione né la logica, né la collocazione, 
né la sequenza. 
 1   La “visione per processi” 
 
Con il nuovo approccio la "reingegnerizzazione" dei processi e 
delle attività viene interpretata come il punto chiave per il 
miglioramento dell'organizzazione, finalizzato al raggiungimento 
degli obiettivi. 
Questa riprogettazione tende ad abbracciare il processo nella sua 
globalità, intervenendo in genere su tutte le sue componenti (flussi 
operativi, organizzazione, risorse umane, tecnologie), dando origine 
a un insieme di interventi tra loro correlati. Questa nuova visione 
modifica completamente il ruolo delle tecnologie dell'informazione 
e della comunicazione. Esse non sono più le componenti 
fondamentali su cui intervenire per la ricerca di efficienza delle 
operazioni ripetitive e a minor valore aggiunto, ma rappresentano 
soprattutto un insieme di opportunità per il cambiamento, che 
consentono non solo e non tanto di ridurre tempi, costi e risorse 
fisiche necessarie ma anche: 
• l’introduzione di nuovi servizi 
• la modifica della natura e delle caratteristiche dei servizi 
esistenti 
• la modifica del flusso delle attività operative 
• il miglioramento del flusso dei servizi  
• il miglioramento della qualità dei servizi stessi. 
 In sostanza le tecnologie rendono possibile una revisione 
complessiva dei processi in tutte le loro componenti, da cui il loro 
ruolo di "fattore abilitante" o “leva principale” del cambiamento. 
C’è quindi stata una inversione delle attività rispetto al passato 
nella realizzazione dei SI, visto che una volta si prendevano i 
processi così come erano e l’obiettivo era di introdurre su essi la 
migliore tecnologia; ora invece l’obiettivo è di focalizzarsi sui 
processi e sul loro miglioramento alla luce delle opportunità offerte 
dalla tecnologia dell’informazione e comunicazione.  
Questa assunzione della centralità dei processi e del loro 
miglioramento è tanto importante da essere chiamata “visione per 
processi” o “approccio per processi” e da aver influenzato l’insieme 
delle modalità di cambiamento di una organizzazione, indirizzando 
in maniera coerente a questa visione le scelte su vari terreni. Da ciò 
deriva infatti: 
1. l’evoluzione verso una “organizzazione per processi” che 
definisce strutture organizzative responsabili per intero del 
ciclo di processo, individuando quindi per questa via il 
“proprietario” 
2. lo snellimento dell’organizzazione, anche con la creazione 
di gruppi di lavoro interfunzionali, responsabilizzati su 
obiettivi comuni e capaci di governare direttamente tutte le 
leve che determinano la prestazione 
3. la ricomposizione del lavoro e la modifica delle 
professionalità richieste, superando la parcellizzazione dei 
compiti e competenze 
 4. l’instaurazione di modalità formali di gestione dei processi 
con l’adozione di metriche e di sistemi di rilevazione delle 
prestazioni continuamente operanti ed integrati con il 
sistema di controllo di gestione. 
2   Definizione di processo 
 
Rifacendosi alla definizione di Hammer, che è stato il fautore del 
Business Process Reengineering, possiamo dire che “la differenza 
tra compito e processo è la stessa che separa una parte dal tutto”. 
 
 
                                        Processo maggiore 
                                        
                            Sottoprocesso   
 
 
 
F
o
r
n
i
t
o
r
i
 
 
 
 
 
 
C
l
i
e
n
t
i
 
Procedure o Attività 
 
 
Figura 1.1  -  La composizione di un processo 
 
Un compito è un’unità di lavoro, un’attività svolta di norma da 
una sola persona.  
 Diversamente un processo è un insieme di compiti che 
collettivamente creano un risultato che ha valore per il cliente. Un 
processo è così uno specifico ordine logico dato alle attività 
lavorative nel tempo e nello spazio, con un inizio, una fine, e con 
input e output chiaramente identificati: una struttura per agire. 
Basandoci su un flowchart, possiamo schematizzare una 
gerarchia di processo: come indicato dalla figura 1.1 individuiamo 
un processo maggiore, sottoprocesso ed attività o compiti,. 
Un processo maggiore è un processo che coinvolge la gran parte 
delle funzioni all’interno della struttura organizzativa, è un percorso 
end-to-end che va dall’acquisizione dei materiali al rilascio del 
prodotto finale, orientato al cliente. 
Un sottoprocesso è una porzione del processo maggiore, ma è 
compiuto da un numero più limitato di persone, e si completa 
sempre con il rilascio del prodotto finale, sia esso un bene o un 
servizio. 
L’attività o compito è la componente elementare di un processo, 
è il lavoro individuale di un singolo lavoratore, ma a sua volta è 
composto da altri processi di natura più semplice.  
Due sono gli elementi fondamentali nuovi rispetto i vecchi 
orientamenti aziendali; il primo è la figura del cliente che non è solo 
una persona esterna all’azienda, ma può anche essere un dipendente 
interno, riprendendo concetti propri della qualità totale. Nel 
momento in cui si va a ridisegnare un nuovo processo si deve 
partire dalla sua definizione e dalla identificazione dei suoi bisogni. 
Quindi dobbiamo chiederci “quali attività dobbiamo compiere 
per soddisfare le sue esigenze?” ed in funzione delle risposte andare 
 a individuare quelle attività che messe insieme costituiranno il 
processo orientato al cliente. 
Il secondo elemento da osservare è che il processo è trans-
funzionale, ossia ora l’azienda si focalizza su questa nuova entità 
che va ad abbracciare differenti funzioni e in alcuni casi superano 
anche i confini esterni dell’organizzazione estendendosi a fornitori 
e clienti esterni, come per esempio la gestione degli ordini. 
 
 
Ricerca e 
sviluppo 
Marketing Produzione 
                   Sviluppo del nuovo prodotto 
C
l
i
e
n
t
e
 
 
 
F
o
r
n
i
t
o
r
i
 
 
 
 
Figura 1.2  -  Natura trans-funzionale di un processo 
(Fonte: “Innovazione dei processi: riprogettare il lavoro attraverso 
l’information technology” Tomhas H. Davenport, 1994 Franco Angeli Milano) 
 
Dell’elevato numero di funzioni che costituiscono un processo se 
ne accorse la Xerox utilizzando un diagramma a matrice, dove 
erano posti nella riga superiore i processi esistenti, e nella colonna 
di sinistra le aree funzionali. 
Nella matrice è stata tracciata una X ogni volta una funzione 
veniva usata per un processo; ci si rese conto che quasi tutti i 
riquadri delle funzioni contenevano una X. Da questo si comprese 
come quasi tutti i reparti erano coinvolti nei processi, ma che allo 
stesso tempo nessun individuo aveva la responsabilità dell’intero 
flusso di azioni. 
 3   Le informazioni che scaturiscono dalle transazioni 
 
L’output di un processo può consistere sia in prodotti fisici (siano 
essi beni o servizi) che vengono prodotti dalla normale attività 
lavorativa, sia in prodotti informativi; questa duplice natura è di 
fondamentale importanza per evidenziare uno dei presupposti che 
stanno alla base della nostra tesi, ossia la necessità di coniugare la 
gestione organizzativa dell’azienda con la gestione delle 
informazioni. 
Nel passato l’attenzione era posta solo sui prodotti fisici, ma 
oggi, in presenza di una competizione sempre più agguerrita che si 
avvicina in alcuni settori all’ipercompetizione, l’attenzione si è 
spostata sempre più sulla risorsa informazione; i manager 
necessitano sempre più, per prendere le decisioni, di informazioni 
che siano nella forma loro consona, e quindi la stessa ha assunto un 
ruolo di primo piano come arma strategica. 
Quando andiamo ad effettuare una transazione, da intendersi 
come tutti gli scambi (ordini, contratti) e da tutte le operazioni 
(produzione di beni e servizi), da questa scaturiscono una grande 
quantità di dati che rappresentano, insieme ai dati ricavati 
esternamente all’azienda, la base informazionale, ossia la 
conoscenza che può essere formalizzata. 
Può essere utile considerare uno schema riportato da De Marco 
che è esplicativo dei tipi di informazioni presenti nell’azienda (fig. 
1.3). Dalle transazioni effettuate dai dipendenti scaturiscono dati 
operativi; basti pensare ai dati sulla produzione che riguardano la 
 quantità realizzata, il tipo di bene prodotto, le caratteristiche, gli 
ordini che sono stati evasi. 
 
 
Figura 1.3  -  Tipi di informazioni aziendali 
(Fonte: Tommaso Federici ne “Il progetto di sistemi informativi”2001 Franco 
Angeli s.r.l. Milano; grafico ripreso e adattato da De Marco) 
 
Oppure in uno sportello bancario, la registrazione del numero di 
conto corrente, della operazione, dell’operatore, dell’importo, 
l’identificazione dell’assegno. Ancora alla cassa di un supermercato 
la registrazione dei beni venduti che consente di gestire meglio il 
magazzino, oppure la identificazione del cliente cui vengono chiesti 
alcuni dati sulle proprie generalità per effettuare analisi di 
marketing. 
Tutti questi dati sono registrati per rispondere alle esigenze 
operative; quindi sono molto dettagliati come si vede anche dalla 
figura 1.3 e presentano un’elevata quantità, sono creati tramite 
 applicazioni precostituite come interfacce create appositamente per 
lo svolgimento dei compiti di routine e sono dei dati elementari ed 
attuali, ossia riguardano le operazioni recenti. 
Man mano che si sale nel tipo di informazione, diminuisce il 
livello di dettaglio indicato dalla freccia alla sinistra della figura e 
aumenta l’astrazione, ossia i dati sono maggiormente aggregati per 
rispondere alle diverse esigenze informative. 
Per le informazioni per il controllo abbiamo bisogno di un certo 
livello di aggregazione, che è sicuramente ancora maggiore nel 
momento in cui i manager necessitano di dati per effettuare la 
pianificazione; conseguentemente avremo un minore livello di 
dettaglio quando ci spostiamo verso l’alto. 
Un’ulteriore differenza con i dati operativi sta nel fatto che i 
processi informazionali, e tali sono quelli da cui scaturiscono le 
informazioni per il controllo e per la pianificazione, riguardano dati 
attuali e storici. Per finire le informazioni per la pianificazione 
ricevono anche dati dall’ambiente esterno, una volta acquisiti ed 
elaborati. 
 
4   L’intervento sui processi 
 
Per realizzare il nostro obiettivo della creazione di un nuovo 
sistema informativo tramite “l’approccio sui processi” dobbiamo 
necessariamente partire con degli interventi di miglioramento degli 
stessi; da notare come in questo primo capitolo andiamo a 
considerare solo elementi organizzativi, lasciando per il futuro una 
visione maggiormente orientata all’informatica, per cui nel 
 prossimo capitolo il miglioramento dei processi sarà compreso 
all’interno del percorso che porta alla realizzazione materiale del 
nuovo sistema informativo con l’uso dell’Enterprise Model.  
Il percorso, limitato al disegno dei nuovi processi, inizia con la 
descrizione della situazione attuale, attraverso modelli per la loro 
rappresentazione e analisi. Esistono parecchie tecniche per la 
modellazione, tra queste si annoverano sia modelli “tradizionali” 
mutuati dall’analisi organizzativa e dall’analisi dei sistemi 
informativi, quali le carte di processo, i diagrammi di flusso, i “Data 
Flow Diagram” che rivestono una notevole importanza all’interno 
del nostro discorso, la tecnica SADT/IDEF 0, sia modelli più 
innovativi quali ad esempio l’Action Diagram Workflow o i 
diagrammi delle attività presi dall’UML (questo lo analizzeremo nel 
dettaglio in un capitolo successivo). 
Una volta rappresentato il processo attuale passiamo alla fase di 
diagnosi che mira ad evidenziare su quali componenti e su quali 
attività si concentrano le attuali criticità ed in che cosa consistono, 
nonché a stabilire delle misure capaci di quantificarle e pertanto 
utilizzabili per definire obiettivi concreti di cambiamento.  
Queste indicazioni rappresentano pertanto dei "requisiti" per la 
successiva fase di riprogettazione. Anche in questo caso sono 
presenti svariate tecniche, che riportiamo nella figura 1.4 seguente, 
che presentano caratteristiche e obiettivi di intervento diversi; in 
alto nella figura sono introdotte le tecniche usate principalmente per 
la modellazione mentre in basso riportiamo quelle che consentono 
la diagnosi dei processi.