Gli enterprise systems - corsi tenuti dal prof. m. bochicchio e dalla

Transcription

Cap2-ES-v14
Architettura funzionale dei sistemi nelle
imprese
1
2
3
4
5
6
7
Introduzione : architettura funzionale dei sistemi e processi gestionali....................................... 3
Architettura del processo gestionale ............................................................................................ 5
2.1
Il paradigma CRASO: i processi gestionali come cicli di servizio end-to-end.................... 5
2.2
Descrizione dei processi : gerarchia..................................................................................... 8
2.3
Descrizione dei processi : flusso .......................................................................................... 9
2.4
Estensione organizzativa dei processi ................................................................................ 10
2.4.1
Livelli di descrizione della struttura organizzativa delle imprese.............................. 10
2.4.2
Processi gestionali e struttura organizzativa delle imprese ........................................ 12
2.4.3
Processi funzionali ..................................................................................................... 13
2.4.4
Processi interfunzionali .............................................................................................. 14
2.4.5
Processi interorganizzativi/ interaziendali ................................................................. 15
Architettura aziendale dei processi gestionali ............................................................................ 16
3.1
Perché una classificazione globale..................................................................................... 16
3.2
Le famiglie di processi ....................................................................................................... 16
Processi di supporto ................................................................................................................... 17
4.1
Processi contabili................................................................................................................ 18
4.2
Gestione del personale ....................................................................................................... 19
4.3
Servizi informatici.............................................................................................................. 20
4.4
Outsourcing dei processi .................................................................................................... 21
Processi manageriali e di analisi ................................................................................................ 23
5.1
La piramide di Anthony e lo schema dei livelli manageriali ............................................. 23
5.2
La prospettiva decisionale.................................................................................................. 28
5.3
Processi di analisi e gestione delle conoscenze.................................................................. 30
Processi primari.......................................................................................................................... 30
6.1
Teorie e modelli ................................................................................................................. 30
6.1.1
Il portafoglio applicativo............................................................................................ 30
6.1.2
La value chain di Porter ............................................................................................. 32
6.1.3
Schemi di settore, best practices e business maps .................................................... 34
6.2
Livelli dei processi primari ................................................................................................ 36
6.2.1
Pianificazione delle operazioni .................................................................................. 37
6.2.2
Esecuzione.................................................................................................................. 38
6.2.3
Tracciamento e monitoraggio..................................................................................... 40
6.2.4
Controllo delle operazioni.......................................................................................... 40
6.2.5
Gestione delle informazioni ....................................................................................... 41
6.2.6
La griglia dei moduli ES ............................................................................................ 42
Framework settoriali .................................................................................................................. 43
7.1
SCOR e Supply Chain....................................................................................................... 43
7.1.1
Lo schema SCOR ....................................................................................................... 43
7.1.2
Mappatura dei processi con lo SCOR e definizione dei requisiti informativi .......... 47
7.1.3
Mappature alternative................................................................................................. 52
7.2
Framework settoriali: Progettazione .................................................................................. 53
7.3
Framework settoriali : Telecomunicazioni......................................................................... 54
7.4
Framework settoriali : Energia e utilità.............................................................................. 56
Pagina 1 di 66
Cap2-ES-v14
7.5
Framework settoriali : Grande distribuzione organizzata .................................................. 56
7.6
Framework settoriali : Banche ........................................................................................... 56
7.7
Framework settoriali : Pubblica Amministrazione............................................................. 57
8
Note sullo scenario ES ............................................................................................................... 58
8.1
Fasce di utenza ................................................................................................................... 58
8.2
La offerta di soluzione ES.................................................................................................. 59
8.3
Partnership.......................................................................................................................... 60
9
Riferimenti ................................................................................................................................. 60
Pagina 2 di 66
Cap2-ES-v14
1 Introduzione : architettura funzionale dei sistemi e processi
gestionali
Questo capitolo illustra il modello funzionale dei sistemi informativi usati nelle imprese, detti
Enterprise Systems (ES). Il modello funzionale di un sistema descrive “che cosa un sistema fa”
prescindendo dalla implementazione del sistema stesso (un medesimo modello funzionale può
essere implementato in diversi modi, per esempio su architetture client server o, invece, su
architetture orientate ai servizi web).
Il modello funzionale dei processi gestionali descrive i cicli operativi di una data impresa. Fra i vari
modelli funzionali adottati per gli ES, è il più utilizzato. Si basa sulla assunzione che la architettura
funzionale dei sistemi di una impresa AS rispecchia la architettura dei suoi processi gestionali AP,
ovvero che AS = f (AP). Conseguentemente più complessa sarà la architettura dei processi di una
impresa, più complessa sarà la architettura dei suoi ES.
Il modello dei processi gestionali è usato non solo nella ricerca ma è anche largamente utilizzato
dagli stessi produttori software per classificare la propria offerta ES. Per esempio sia SAP sia
Oracle, due fra i massimi produttori di software ES, offrono software per le gestione delle risorse
umane, detto Human Capital Management, le cui funzionalità corrispondono ai processi di gestione
delle risorse umane, come selezione, gestione, amministrazione ecc.
Ovviamente la modellazione dei processi gestionali può essere svolta a diversi livelli di astrazione. Alcune
modellazioni operano ad un basso livello di astrazione, considerando ogni singolo passo dei processi. Tali
modellazioni sono utili per definire le singole transazioni del sistema ma sono troppo dettagliate per dare una
visione di insieme. Altre modellazioni operano invece a livello molto alto producendo mappe sintetiche, utili per
tracciare i primi lineamenti della strategia informatica, ma poco utilizzabili in una analisi dettagliata. E’ evidente
che una modellazione ideale deve essere comprensiva, spaziando dai più elevati livelli di astrazione sino ai livelli
minimi, costituendo quindi un continuo che vada dalla pianificazione strategica sino alla implementazione.
Usando la celebre metafora di Hegel, una modellazione comprensiva deve vedere sia gli alberi (dettaglio) sia la
Pagina 3 di 66
Cap2-ES-v14
foresta (sintesi). A questo scopo, la nostra modellazione dei processi gestionali procede su tre livelli successivi
Livello azienda
Livello processo
Livello attività
Architettura aziendale
aziendale
Architettura
Radice:
azienda
Radice: azienda
Foglia ::processo
processo
Foglia
Architettura processo
processo
Architettura
Radice: processo
processo
Radice:
Foglia
:
attività
elementare
Foglia : attività elementare
Architettura attività
attività
Architettura
Radice: attività
attività
Radice:
Foglia
:
azione
e/o
casid’uso
d’uso
Foglia : azione e/o casi
(
Figura 1):
1. architettura aziendale, che costituisce il livello più elevato di astrazione;
2. architettura del processo (gerarchia e flusso), che costituisce il livello intermedio di
astrazione;
3. architettura della attività, che costituisce il livello minimo di astrazione e costituisce il punto
di intersezione fra ingegneria dei processi e ingegneria del software ;
Consideriamo brevemente le caratteristiche di ciascun livello di astrazione.
L’architettura aziendale è, come si è detto, il massimo livello di astrazione. Essa mostra le classi di
dei processi cui partecipa una data impresa e le loro relazioni. Nella sua forma più semplice,
l’architettura che può essere rappresentata da un albero, che ha per radice la azienda, per nodi le
classi di processi e per foglie i processi. La letteratura manageriale propone diversi schemi
architetturali, spesso basati su rappresentazioni informali, che rispecchiano diverse concezioni della
azienda. Per il progettista dei sistemi e per lo ingegnere dei processi l’architettura aziendale ha un
uso analogo a quello di una carta geografica. Essa infatti dà una visione complessiva delle possibili
aree in cui usare ES, guida quindi semplifica la formulazione della strategia e la valutazione della
della informatizzazione di una impresa.
Il secondo livello è la architettura del processo. Essa individua le attività di un dato processo e le
loro relazioni, e, inoltre, descrive proprietà delle attività stesse. L’architettura del processo è
normalmente rappresentata da digrammi di gerarchia e diagrammi di flusso. La gerarchia è in
genere raffigurata da una albero, la cui radice è il processo e le cui foglie sono attività elementari,
cioè attività che non possono essere scomposte. A sua volta il flusso mostra le relazioni di
precedenza e sequenza fra le attività del processo. Come sarà precisato successivamente, la
Pagina 4 di 66
Cap2-ES-v14
architettura di un processo deve sottostare ad alcune condizioni di buona formazione. La
architettura del processo è fondamentale per la progettazione del processo gestionale e dello ES che
lo deve supportare, in quanto definisce quali attività devono essere svolte, da chi, quali sono gli
output del processo ed altri elementi.
Il terzo livello, attività elementare, esplode i contenuti della singola attività elementare e descrive gli
elementi della attività e le rispettive relazioni. L’attività può includere sia azioni compiute da
persone sia azioni sul sistema informatico. Le azioni compiute da persone (p.e. prelevare materiale
dallo scaffale di un magazzino) possono essere descritte da vari tipi di diagramma, da descrizioni
testuali ed altri schemi. Le azioni sul sistema (p.e. registrare sul sistema il prelievo compiuto) sono
spesso descritte dai cosiddetti Casi d’uso e da rappresentazioni complementari come mock-up o
schemi delle schermate attraverso cui l’utente dialoga con il sistema. Lo sviluppo dei casi d’uso è
materia di ingegneria del software.
Livello azienda
Livello processo
Livello attività
aziendale
Architettura
Radice: azienda
azienda
Radice:
Foglia
:
processo
Foglia : processo
processo
Architettura
Radice:
processo
Radice: processo
Foglia ::attività
attivitàelementare
elementare
Foglia
attività
Architettura
Radice:
attività
Radice: attività
Foglia
azione e/o
e/ocasi
casid’uso
d’uso
Foglia ::azione
Figura 1 Livelli di descrizione dei processi: azienda, processo, attività
Scopo specifico di questo capitolo è l’approfondimento dei modelli funzionali di primo livello, cioè
la architettura dei processi delle imprese. Il primo paragrafo illustra la architettura dei processi
gestionali, esemplificandone le principali tipologie. Questo paragrafo introduce concetti e
definizioni indispensabili per comprendere i paragrafi successivi.
La parte successiva è dedicata alla architettura aziendale dei processi. In primo luogo illustriamo i
termini generali della architettura dei processi, che sono classificati nelle grandi famiglie di processi
manageriali e di analisi, processi di supporto e processi primari. Le famiglie sono illustrate nei
paragrafi seguenti, con uno schema che integra i richiami alle teorie elaborate dalla letteratura
manageriale con la trattazione di casi reali. In generale, i processi di supporto sono esemplificati dal
caso della gestione delle risorse umane, che è una area in continuo sviluppo. La illustrazione dei
processi manageriali è sostenuta dal di alcune teorie fondamentali, come quelle di Simon e di
Pagina 5 di 66
Cap2-ES-v14
Anthony,, che bene inquadrano il ruolo del supporto informatico al management. La trattazione dei
processi primari occupa la maggiore parte del capitolo, in quanto abbiamo voluto esemplificare la
architettura dei processi gestionali e degli ES su un ventaglio ampio di settori industriali, affinché il
lettore si renda conto della diversità dei ruoli che gli ES svolgono nelle imprese e della importanza
di schemi settoriali, come SCOR e eTOM.
L’ultima parte include propone metodi e considerazioni. In primo luogo tracciamo un semplice
schema per valutare il grado di supporto informatico ai processi gestionali, che risponde a domande
quali “Quali processi sono supportati dagli ES ed in quale misura?”, “Quali sono le aree di
potenziale investimento degli ES?”. Un successivo paragrafo traccia un quadro molto sommario
dello scenario ES, cioè su quali sono i principali attori della offerta e quali sono invece le fasce di
domanda. La trattazione è preliminare, in quanto il problema è affrontato in maggiore dettaglio nei
capitoli dedicati alle varie famiglie di ES, cioè CRM, ERP e Business Intelligence.
2 Architettura del processo gestionale
Questo paragrafo illustra la architettura dei processi gestionali, esemplificandone le principali
tipologie ed introducendo concetti e definizioni indispensabili per comprendere i paragrafi
successivi. Innanzi tutto definiamo il concetto di “processo gestionale”, introducendo il paradigma
CRASO. In secondo luogo introduciamo le due prospettive di descrizione dei processi, cioè la
gerarchia e il flusso, che costituiscono il nucleo degli innumerevoli linguaggi di modellazione dei
processi, grafici od astratti. Definito il concetto di processo gestionale e quello delle sue descrizioni,
passiamo a considerare alcune proprietà tipiche dei processi gestionali, cioè la loro estensione
funzionale. Per una migliore comprensione di tali proprietà, richiamiamo alcuni concetti elementari
relativi alla struttura organizzativa aziendale, e analizziamo la correlazione fra struttura
organizzativa e processo gestionale, che rappresentano, rispettivamente, il modo in cui sono
articolaste le responsabilità (chi comanda che cosa) e il modo in cui una impresa opera.
2.1 Il paradigma CRASO: i processi gestionali come cicli di servizio
end-to-end
Secondo Wikipedia (2009) “un processo gestionale (business process) è una raccolta di passi
interrelati, che sono finalizzati a conseguire uno specifico obiettivo”. Il riquadro qui sotto espone un
breve esempio di processo gestionale che rispecchia questa definizione, per altro piuttosto vaga.
L’esempio riguarda i passi attraverso i quali la Nike acquista materie prime. Si può facilmente
notare che il processo gestionale sequenzia vari passi e, inoltre, persegue uno specifico obiettivo,
ovvero acquistare (al meglio) materie prime.
L’acquisto dei materiali alla Nike (adattato dal sito web della Nike e dal MIT Process Handbook)
Nike progetta e vende calzature, abbigliamenti ed accessori marchiati ma affida a terzi la produzione e la
distribuzione. Nike vende a catalogo, ed acquista in base a previsioni , prima cge si manifesti una specifica esigenza o
richiesta da parte di clienti. Acquistare un articolo per il magazzino è utile quando il costo dell’articolo stesso è
contenuto o quando la immediata disponibilità è critica.
Per produrre le calzature, Nike deve comprare le materie prime corrispondenti (plastica, pelle, tessuto ed altre) che
saranno poi impiegate in diversi modelli. Per comprare un articolo, Nike individua tutti i potenziali fornitori delle
materia prime che potrebbero soddisfare le sue esigenze. Stabilito il contatto, Nike precisa le caratteristiche della
Pagina 6 di 66
Cap2-ES-v14
fornitura richiesta: oggetto e quantità della fornitura, località di consegna, quale periodo e frequenza. Ciò può essere
eseguito in molti e diversi modi.
A questo punto i fornitori inviano a Nike le loro offerte e Nike sceglie il quale fornitore da cui servirsi. La selezione del
fornitore applica criteri, che possono variare secondo i casi, di tempo, costo ed altri.
Finalmente Nike paga la forniture ricevute. Anche la procedura di pagamento è variabile: il pagamento può infatti
corrispondere o non corrispondere al valore della forniture. Il materiale viene consegnato in tempo per la produzione.
Riquadro 1 Processo gestionale : esempio Nike
Tuttavia la definizione Wiki è troppo generica per essere utile al progettista. Infatti non indica gli
elementi necessari a progettare un processo gestionale né definisce le proprietà di un buon processo
gestionale. Qui di seguito diamo una definizione più ampia, assumendo che un processo gestionale
sia una sequenza di attività eseguite da una o più organizzazioni per produrre un risultato utile per i
clienti (Motta 2008). Il risultato risponde a una richiesta esplicita fatta dal cliente; per esempio la
consegna di un’automobile risponde a un ordine fatto da un cliente. Schematicamente definiamo
quindi un Processo Gestionale come segue:
P = (C, R, A, S, O)
dove:
•
•
•
•
•
C = Cliente = un processo gestionale serve almeno un cliente che riceve i risultati in risposta
alla propria richiesta;
R = Richiesta = un processo è avviato da almeno una richiesta emessa da un cliente;
A = Attività = un processo include una sequenza di attività (= una serie di attività
interconnesse) che sono eseguite da una o più organizzazioni;
S = Organizzazioni = le organizzazioni riuniscono gli attori che sono coinvolti nel processo
in quanto eseguono una o più attività;
O = Output = l’output è formato dai risultati consegnati al cliente; l’output più essere
materiale od immateriale e può consistere di prodotti e / o servizi.
Pagina 7 di 66
Cap2-ES-v14
Customer
S1
A1
S2
S3
A3
Request
A4
Output
A2
Business Process
Figura 2 schema CRASO dei processi gestionali
Livello azienda
Livello processo
Livello attività
aziendale
Architettura
Radice: azienda
azienda
Radice:
Foglia
:
processo
Foglia : processo
processo
Architettura
Radice:
processo
Radice: processo
Foglia ::attività
attivitàelementare
elementare
Foglia
attività
Architettura
Radice:
attività
Radice: attività
Foglia
azione e/o
e/ocasi
casid’uso
d’uso
Foglia ::azione
La
Figura 1 rappresenta lo schema CRASO di un processo gestionale. Nella parte superiore della figura
è rappresentato il cliente che emette la richiesta e riceve l’output del processo. La richiesta è
elaborata attraverso una sequenza di attività A1, A2, … An che sono eseguite dalle organizzazioni
S1, S2, … Sn. Il caso Nike può essere facilmente descritto con lo schema CRASO; lo schema aiuta
infatti a strutturare la descrizione come mostriamo qui sotto (Tabella 1).
Cliente
Richiesta
Attività
Organizzazioni partecipanti
Output
Pagina 8 di 66
Cap2-ES-v14
Cliente
Nike /
Direzione
Produzione
Richiesta
Richiesta
Acquisto
Attività
Organizzazioni partecipanti
1. Individuazione dei fornitori
1.
Fornitori (inviano le offerte e
potenziali (a fronte della
pianificano la produzione e
Richiesta di Acquisto)
la spedizione delle materi
2. Scelta del fornitore (I fornitori
prime alla Nike)
2.
Reparto Acquisti Nike
inviano le offerte e Nike
(individuazione fornitori,
decide)
3. Esecuzione fornitura (Nike
richiesta della offerte,
ordina i materiali da Nike e il
emissione ordini)
fornitore li consegna ai
3.
Magazzino Nike (ricezione ed
magazzini Nike)
immagazzinamento forniture)
4. Pagamento (Nike paga i
4.
Contabilità Nike
(pagamento)
materiali consegnati)
Output
Materie prime
consegnate al
magazzino
Tabella 1 Descrizione del caso Nike mediante lo schema CRASO
Lo schema CRASO è un paradigma, cui la identificazione di un processo gestionale si deve
conformare; esso cioè definisce che cosa è un processo gestionale. La descrizione della architettura
rappresenta invece gli elementi dei processi, le loro rispettive relazioni e le loro proprietà. Esistono
molti modelli di descrizione dei processi. Qui ci limitiamo da illustrare due modelli elementari, cioè
il modello gerarchico, che appunto rappresenta la gerarchia del processo e permette di individuare
la attività elementari, e lo schema di flusso, un modello certamente più ricco, che rappresenta la
dinamica del processo.
2.2 Descrizione dei processi : gerarchia
La struttura di un processo è rappresentata come un albero. La radice dell’albero è il processo,
mentre le foglie dell’albero rappresentano attività elementari. Le attività elementari sono attività
atomiche, omogenee rispetto all’attore, alla frequenza, alla tecnologia utilizzata per la loro
esecuzione, alle regole applicate. Qualunque processo include un certo numero attività elementari,
ottenute scomponendo il processo in sotto-processi, i sotto-processi in sotto-sotto-processi e cosi
via, fino ad arrivare appunto alle attività elementari.
Pagina 9 di 66
Cap2-ES-v14
ACQUISTI
INDIVIDUAZIONE
FORNITORI
SCELTA
FORNITORE
ESECUZIONE
FORNITURA
PAGAMENTO
ANALISI BISOGNI
FORMULAZIONE
OFFERTE
PIANIFICAZIONE
CONSEGNE
RICERCA
FORNITORI
VALUTAZIONE
OFFERTE
SPEDIZIONE
PAGAMENTO
ANTICIPO
CONSEGNA
CALCOLO SALDI
INVIO RICHIESTE
OFFERTA
PROTOCOLLO
OFFERTE
VALUTAZIONE
TECNICA
RICEZIONE
VALUTAZIONE
ECONOMICA
COLLAUDO
SELEZIONE
FORNITORE
CARICO A
MAGAZZINO
ORDINE AL
FORNITORE
RESTUTUZIONE
SCARTI
ANTICIPO / SALDI
PAGAMENTO
SALDI
PAGAMENTO A
FINE FORNITURA
CALCOLO
PENALITA
PAGAMENTO
FORNITURA
La
Figura 3 esemplifica l’albero di un processo ispirato al caso Nike. Il processo è scomposto nei
quattro sotto-processi già elencati nella descrizione CRASO (Tabella 1). I sotto-processi sono a loro
volta scomposti sino ad individuare attività elementari, che costituiscono le foglie dell’albero.
Consideriamo brevemente l’albero esemplificato.
In primo luogo l’albero comprende tutte le attività del processo siano esse svolte da Nike (caratteri
chiari su fondo scuro) o dal fornitore (caratteri scuri su fondo chiaro). Ciò rispecchia il nostro
paradigma CRASO, secondo il quale vanno considerate tutte le attività del processo da chiunque
siano svolte. La divisione del processo fra più organizzazioni complica, e parecchio, la sua
informatizzazione, come vedremo successivamente.
In secondo luogo la gerarchia include relazioni di due tipi, rispettivamente composizione e
specializzazione. La scomposizione (PART-OF) è la relazione che intercorre fra un elemento e i
suoi componenti, p.e. un’auto è composta da meccanica, scocca, allestimento ed impianto elettrico.
La specializzazione (IS-A) indica che un dato elemento può avere certune od certe altre
caratteristiche. P.e. un’auto può essere a due ruote o a quattro ruote motrici. Nel nostro esempio il
sotto-processo Pagamento è specializzato in due sotto-processi, in quanto può essere svolto secondo
due modalità alternative, rispettivamente il pagamento periodico a fronte di un estratto conto con
una quota in acconto sulla consegna e una quota a saldo e il pagamento interamente erogato a fine
fornitura. Specializzazione e scomposizione si possono trovare in qualunque punto della gerarchia.
Alla specializzazione può seguire la scomposizione e viceversa. Nel nostro esempio, entrambe le
specializzazioni di Pagamento sono scomposte.
Pagina 10 di 66
Cap2-ES-v14
ACQUISTI
INDIVIDUAZIONE
FORNITORI
SCELTA
FORNITORE
ESECUZIONE
FORNITURA
PAGAMENTO
ANALISI BISOGNI
FORMULAZIONE
OFFERTE
PIANIFICAZIONE
CONSEGNE
RICERCA
FORNITORI
VALUTAZIONE
OFFERTE
SPEDIZIONE
PAGAMENTO
ANTICIPO
CONSEGNA
CALCOLO SALDI
INVIO RICHIESTE
OFFERTA
PROTOCOLLO
OFFERTE
VALUTAZIONE
TECNICA
RICEZIONE
VALUTAZIONE
ECONOMICA
COLLAUDO
SELEZIONE
FORNITORE
CARICO A
MAGAZZINO
ORDINE AL
FORNITORE
RESTUTUZIONE
SCARTI
ANTICIPO / SALDI
PAGAMENTO
SALDI
PAGAMENTO A
FINE FORNITURA
CALCOLO
PENALITA
PAGAMENTO
FORNITURA
Figura 3 Gerarchia di un processo (per la interpretazione si veda il testo)
Consideriamo infine le attività elementari. Le attività elementari comprendono un certo numero di
azioni, che possono essere svolte da:
•
•
Azioni manuali svolte da esseri umani: nel nostro esempio potrebbe essere
l’immagazzinamento, eseguito da robusti carrellisti;
Azioni svolte da sistemi, in modo automatico (p.e. il pagamento, attivato da un impiegato
contabile ed eseguito da un opportuno software) o semiautomatico (p.e. il riconoscimento del
materiale mediante codice a barre o RFID nell’attività di ricevimento).
Possiamo a questo punto definire la corrispondenza fra processo ed ES. Un processo può essere
scomposto e/o specializzato in sotto-processi. I sotto-processi includono attività elementari, che a
loro volta sono composte da azioni, che rappresentano i passi attraverso cui una data attività
elementare è eseguita, che a loro volta possono essere specializzate in azioni manuali e IT. Queste
ultime sono descrivibili come casi d’uso, che, come già osservato nel capitolo 1, sono azioni sul
sistema.
2.3 Descrizione dei processi : flusso
La gerarchia è utile per individuare le attività elementari, in quanto il procedimento è semplice e la
stessa povertà della rappresentazione facilita la analisi. Tuttavia una completa comprensione del
processo richiede anche una descrizione semanticamente più ricca, che includa anche la sua
dinamica. I diagrammi di flusso sono la rappresentazione più diffusa. Gli innumerevoli linguaggi e
convenzioni grafiche per rappresentare il flusso dei processi comunque condividono alcuni concetti,
quali attività, flusso (sequenza), scelta.
Pagina 11 di 66
Cap2-ES-v14
Qui di seguito esemplifichiamo sul solito caso Nike un diagramma di flusso, che include attività,
flusso, scelta, input / output, organizzazioni (swim pools nel gergo UML); in sintesi può essere
considerato una versione più ricca del diagramma CRASO.
La gerarchia costituisce un’eccellente base di partenza per disegnare il corrispondente flusso del
processo. Basterà infatti disporre le attività elementari (individuate nella gerarchia) in colonne,
ciascuna delle quali corrisponde all’organizzazione che le svolge. Posizionate le attività, si passerà
a descrivere la sequenza delle attività mediante archi orientati (frecce). Nel nostro flusso
semplificato, la sequenza potrà rappresentare successioni temporali o scelte . Le scelte, aperte dai
rombi di branch, che evidenziano le variabili della scelta, e chiuse dai rombi di merge, che
ricongiungono le sequenze alternative, corrispondono a specializzazioni della struttura (nel nostro
esempio i pagamenti) od esiti di decisioni (nel nostro esempio il collaudo può accettare o non
accettare il materiale, dando luogo rispettivamente al carico a magazzino od alla restituzione del
materiale scartato). Infine gli input ed output del processo sono individuati e congiunti alle
corrispondenti attività.
ACQUISTI
FORNITORE
MAGAZZINO
CONTABILITA
ESTRATTO CONTO
Richiesta
Acquisto
ANALISI
BISOGNI
FORMULAZIONE
OFFERTE
COLLAUDO
OK
KO
CALCOLO SALDI
PAGAMENTO
SALDI
RESTITUZIONE SCARTI
PROTOCOLLO
OFFERTE
VALUTAZIONE
TECNICA
PAGAMENTO UNICO
RICERCA
FORNITORI
INVIO RICHIESTE
PAGAMENTO
ANTICIPI
RICEZIONE
CALCOLO
PENALITA’
Materiale
scartato
PIANFICAZIONE
CONSEGNE
VALUTAZIONE
ECONOMICA
PAGAMENTO
FORNITURA
CARICO A
MAGAZZINO
SPEDIZIONE
SELEZIONE
FORNITORE
ORDINE AL
FORNITORE
Materiale
OK
Pagamenti
Figura 4 Struttura di un processo (per la interpretazione si veda il testo)
2.4 Estensione organizzativa dei processi
2.4.1 Livelli di descrizione della struttura organizzativa delle imprese
Una impresa è una organizzazione, formata da persone che operano in una data struttura
organizzativa che opera secondo determinati processi gestionali. Analogamente ai processi, la
struttura organizzativa può essere descritta a diversi livelli:
•
•
Macrostruttura;
Microstruttura;
Pagina 12 di 66
Cap2-ES-v14
•
Mansione.
La macrostruttura è descritta dall’organigramma, che mostra la gerarchia di un’impresa. Normalmente
l’organigramma è rappresentato da un albero, la cui radice rappresenta il massimo livello gerarchico e le cui
foglie rappresentano strutture organizzative elementari. La
Livello azienda
Livello processo
Livello attività
aziendale
Architettura
Radice:
azienda
Radice: azienda
Foglia ::processo
processo
Foglia
processo
Architettura
Radice: processo
processo
Radice:
Foglia
:
attività
elementare
Foglia : attività elementare
attività
Architettura
Radice: attività
attività
Radice:
Foglia
:
azione
e/o
casid’uso
d’uso
Foglia : azione e/o casi
Figura 1 esemplifica la macrostruttura di una media impresa industriale. Al vertice si trova il
presidente (Chairman) cui risponde un solo ufficio istituzionale, cioè le Relazioni Esterne.
L’Amministratore Delegato (President) guida le operazioni della azienda (per questo spesso
designato come CEO - Chief Executive Officer): da esso infatti dipendono tutte le strutture operative
della azienda. Alcune strutture sono più grandi e complesse e sono articolate su più livelli (p.e.
Produzione), altre invece non sono nemmeno suddivise (p.e. Relazioni Esterne). Le strutture sono
distinte fra strutture dirette, che svolgono attività direttamente connesse al ciclo di servizio al cliente
(caratteri chiari su sfondo scuro), e strutture indirette, che svolgono attività di supporto alle strutture
dirette, che quindi ne sono i clienti, sia pure interni.
Pagina 13 di 66
Cap2-ES-v14
PRESIDENTE
RELAZIONI
ESTERNE
AMMISTRATOR
E DELEGATO
PROGETTAZIONE
ACQUISTI
PRODUZIONE
VENDITE
AMMISTRAZION
E
RISORSE
UMANE
SERVIZI
INFORMATIVI
COMPONENTI
PIANI E
LOGISTICA
VENDITE
ITALIA
CONTABILITA
SVILUPPO
SVILUPPO
SISTEMI
PRODOTTI
TECNOLOGIE E
QUALITA’
VENDITE
ESTERO
CONTROLLO
GESTIONE
AMMINISTRAZIONE
ESERCZIIO
SISTEMI
STABILIMENTO
STUTTGART
ASSISTENZA
POST VENDITA
BANCHE &
FINANZA
SERVIZI
GENERALI
STABILIMENTO
BOLOGNA
RICEVIMENTO
E MAGAZZINO
FUSIONI
LAVORAZIONI
MONTAGGI E
SPEDIZONI
STABILIMENTO
SHANGHAI
Figura 5 Macrostruttura organizzativa (esempio)
Le strutture della impresa sono dette anche “funzioni”, in quanto svolgono attività finalizzate ad un
dato risultato. Il termine “funzione organizzativa” o “funzione” sarà largamente usato in questo
paragrafo.
La microstruttura esplode le strutture elementari della macrostruttura indicandone le attività svolte
e/ o i compiti e e/o la organizzazione del lavoro. P.e. la microstruttura del reparto Ricevimento e
Magazzino specificherà che il reparto è condotto da un caporeparto che a sua volta coordina un certo
numero di addetti (l’esempio è indicativo). Come si nota, la microstruttura indica la effettiva
organizzazione del lavoro di una struttura della impresa; spesso è corredata anche dai dati di
organico (indicati fra parentesi) e da una sommaria descrizione delle attività svolte da ciascun
addetto (riportata sotto la struttura).
Pagina 14 di 66
Cap2-ES-v14
RICEVIMENTO E
MAGAZZINOcaporeparto (1)
• Coordinamen
to con
Direzione
Stabilimento
• Ottimizzazion
e layout
magazzino
RICEVIMENTO (1)
• Controllo e
registrazione
ingressi ed
uscite
• Assistenza
scarico
camion
COLLAUDO
MATERIALI (2)
• Collaudo
materiali
• Documentazi
one collaudo
• Gestione
scarti
CARRELLISTI (4)
Carico a
magazzino
• Prelievo
• Trasporto ai
reparti
•
GESTIONE
MAGAZZINO (2)
• Registrazione
carichi,
scarichi e
prelievi
• Inventari di
controllo
Figura 6 Microstruttura organizzativa (esempio)
La mansione descrive i compiti svolti da ciascun addetto nell’ambito di una data organizzazione del
lavoro. Sono esempi di mansioni il “carrellista”. La mansione (job) specifica quindi il tipo di attività
richieste per svolgere un dato compito in una organizzazione. In genere la mansione è descritta da
un testo detto “mansionario” (job description).
2.4.2 Processi gestionali e struttura organizzativa delle imprese
Processi e struttura sono dimensioni complementari di analisi e progettazione di una impresa. La
struttura specifica la gerarchia della impresa (macrostruttura) e la distribuzione delle
specializzazioni fra gli addetti (microstruttura e mansioni) mentre i processi descrivono che cosa la
impresa fà e come agisce. Fra struttura e processi si pone quindi una relazione molti a molti: una
struttura può partecipare a molteplici processi e uno stesso processo può interessare molteplici
strutture, appartenenti ad una o più imprese.
Per rappresentare la intersezione fra processi e struttura usiamo una griglia, in cui indichiamo la
partecipazione attiva di una data struttura (colonna) a un dato processo (riga) con la etichetta P e la
partecipazione come cliente con la etichetta C. Le colonne includono, volutamente, sia le strutture
della nostra immaginaria azienda manifatturiera sia due fondamentali classi di attori esterni, cioè
clienti e fornitori (Tabella 1).
I processi esemplificati hanno profili diversi. Al primo, “Produzione di rapporti gestionali”,
partecipa una sola funzione aziendale ed i clienti sono tutti interni alla impresa; questa classe di
processi è quindi detta “funzionale”. Il secondo processo, “Evasione degli ordini dei clienti”,
attraversa molteplici funzioni, specificatamente Produzione e Vendita, ed ha clienti esterni; è perciò
detto “interfunzionale”. Il terzo processo, “Approvvigionamento”, coinvolge molteplici aziende ed
Pagina 15 di 66
Cap2-ES-v14
organizzazioni, cioè i fornitori, ed è perciò detto “interaziendale” od “interorganizzativo”. Nei
paragrafi successivi illustriamo brevemente le caratteristiche di ciascuna classe di processi.
Strutture della impresa
C
C
Clienti esterni
Servizi informativi
P
Fornitori
Risorse umane
C
P
Amministrazione
Vendita
Produzione
Progettazione
Acquisti
Produzione analisi gestionali
C
C
C
Evasione ordini cliente
P
Approvvigionamento
P
C
Tabella 2 Incrocio fra processi e strutture organizzative
Attori esterni
C
P
P
2.4.3 Processi funzionali
Le attività dei processi funzionali sono svolte da una sola struttura aziendale e spesso sia l’esecutore
sia il cliente appartengono alla stessa organizzazione. È questo il caso di molti processi di supporto.
Per esempio le analisi gestionali interessano il reparto Amministrazione che raccoglie, elabora e
fornisce rapporti ai reparti della medesima azienda. I reparti che ricevono i rapporti sono quindi i
clienti del processo.
Le vendite di un supermercato sono invece esempio di processi funzionali con clienti esterni. Infatti
la richiesta (implicita) proviene dalla casalinga che preleva e sperabilmente paga la merce alla cassa.
Lo stesso avviene in una variegata serie di interazioni frontali come agli sportelli bancari, negli
sportelli di informazione ed altri.
I servizi funzionali possono essere prodotti a richiesta (come avviene nella spesa al supermercato,
che avviene solo se i clienti entrano nel supermercato) o secondo un calendario predefinito (come
avviene nel caso dei rapporti gestionali, che sono emessi a scadenze predeterminate).
I processi funzionali sono normalmente strutturati, quindi facili da progettare e da informatizzare.
Non casualmente processi come la retribuzione del personale, la fatturazione, la contabilità ed altri
sono stati fra i primissimi oggetti dell’informatizzazione. Lo schema CRASO di un processo
funzionale è illustrato qui sotto (Figura 7)
Pagina 16 di 66
Cap2-ES-v14
Corporate Dpts
Finance Dpt
Informa
tion
request
Collect data
Publish
report
Report
Analyze data
Business
Process
Customer
Request
Activities performed
(summary)
Organizations involved
(summary)
Output
(summary)
Management
reporting
Corporate
Departments
Information
request
Data-collection
Data-analysis
Report-publication
Finance
Report
Figura 7 Schema CRASO di un processo funzionale
2.4.4 Processi interfunzionali
Gli attori dei processi interfunzionali appartengono a reparti diversi di una stessa organizzazione. I
clienti possono essere interni o esterni. Il primo caso è esemplificato delle evasione degli ordini dei
clienti, dove il processo inizia dalla elaborazione delle richieste dei clienti alle vendite, e coinvolge
il reparto “piani produzione”, che assembla il piano di produzione necessario ad evadere gli ordini, e
gli stabilimenti, che eseguono il piano.
Un secondo caso, con clienti esterni, è lo sviluppo di applicazioni software, dove sono coinvolti
molteplici dipartimenti nel disegnare, realizzare, collaudare e mettere in esercizio il software, mentre
i clienti sono interni all’organizzazione.
I processi interfunzionali sono più complessi e implicano numerosi problemi politici e organizzativi.
Non sorprendentemente, sono stati oggetto solo di una seconda generazione di informatizzazione.
La Figura 8 rappresenta lo schema CRASO di un processo interfunzionale.
Pagina 17 di 66
Cap2-ES-v14
Corporate Dpt
Supplier Order Dpt
Supplier
Shipment
Order-entry
Supply/
delivery
Supplyorder
Supply
delivered
Order-fulfilment
Business Process
Customer
Request
Activities performed
(summary)
Organizations involved
(summary)
Output (summary)
Production Planning
Sales-dpt
Production-request
Assemble-production-plan,
Give-information,
Negotiate and execute the plan
Production-planning-dpt, Materialsmanagement-dpt,
Factories
Approved
production plan
Service Engineering MS in University of
Pavia - 081125
9
Figura 8 Schema CRASO di un processo gestionale interfunzionale
2.4.5 Processi interorganizzativi/ interaziendali
Nei processi interorganizzativi i dipartimenti che eseguono il processo appartengono ad
organizzazioni diverse. Consideriamo il ben noto caso di Amazon. Amazon si limita a raccogliere
gli ordini dei clienti, mentre le attività di prelievo dei libri dei depositi e la spedizione/consegna sono
affidate a terzi. Il processo è quindi eseguito da imprese diverse ed indipendenti. Analogamente,
nella Sanità un esame radiologico richiede la collaborazione del medico di famiglia, che prescrive
l’esame, del laboratorio che lo esegue, della azienda sanitaria che monitora il processo e rimborsa i
costi corrispondenti, e di altre organizzazioni.
Lo schema CRASO evidenzia la concezione “end-to-end” dei processi interaziendali che si
contrappone alla tradizionale concezione ad isole (Figura 2Figura 9). Infatti i processi interaziendali
sono talvolta percepiti come unitari dal cliente mentre gli attori non percepiscono solo la propria
isola di servizio ribaltando la cliente l’onere di costruire la catena di servizio. Pratiche burocratiche
come i permessi di costruzione per case ed edifici sono portate avanti dal cittadino che deve trovare i
documenti necessari, portare la pratica da una stazione di servizio a quella successiva, mentre gli
enti che operano nel processo si concepiscono come supremi controllori della regolarità dei singoli
passi compiuti dal disgraziato cittadino.
Pagina 18 di 66
Cap2-ES-v14
Customer
Amazon
front-end
Bookshops
Logistic
services
Pick
Deliver
Request
Output
Process
orders
Customer
Request
Activities performed (summary)
Organizations involved (summary)
Output (summary)
Private customer
Book order
Process-order,
Order-picking,
Book-delivery
Front-end,
Bookshop,
Logistic services
Delivery of books
Service Engineering MS in University of
Pavia - 081125
10
Figura 9 Schema CRASO di un processo interaziendale
3 Architettura aziendale dei processi gestionali
Questo paragrafo illustra il primo livello della architettura dei processi, cioè la architettura
aziendale, in cui si considerano tutti i processi gestionali di una impresa, secondo le definizioni e i
criteri descritti nel paragrafo precedente. Il paragrafo definisce le tre fondamentali famiglie di
processi gestionali, cioè i processi di supporto, i processi manageriali e di analisi, i processi primari.
Le rispettive caratteristiche sono approfondite successivamente in paragrafi dedicati.
3.1 Perché una classificazione globale
Come abbiamo già accennato, l’architettura aziendale mostra la relazione fra le classi dei processi
cui partecipa una data impresa. Il livello minimo della descrizione è il singolo processo.
Le letteratura manageriale propone diversi schemi architetturali, ciascuno dei quali richiamano una
specifica e diversa visione gestionale. Qui di seguito proponiamo una classificazione globale, che
incorpora vari schemi proposti dalla letteratura come interpretazioni di specifiche classi di processi
(Motta 2002). Questa classificazione, come si vedrà, divide i processi in grandi famiglie funzionali,
che rispecchino i diversi ruoli degli ES nelle imprese.
3.2 Le famiglie di processi
Nel loro insieme i processi di un’azienda sono divisi in tre grandi famiglie funzionali,
rispettivamente Processi Manageriali (Management Processes), Processi di Supporto (Support
Processes), Processi Primari (Primary Processes). Questa classificazione di processi può essere
raffigurata con uno schema a T, le braccia della quale sono i Processi Manageriali e i Processi di
Pagina 19 di 66
Cap2-ES-v14
Supporto, mentre i processi Primari formano la gamba (Figura 10). La forma della T rispecchia la
variabilità dei processi nell’ambito dei settori di attività: bassa nei processi manageriali e di supporto
– che quindi sono orizzontali – ed elevata nei processi primari – che sono quindi verticali.
I processi primari comprendono le attività attraverso cui si producono i prodotti e i servizi per i
clienti della azienda od ente governativo: le automobili ed il servizio di assistenza di una azienda
automobilistica, i servizi al cittadino di un ente governativo, i servizi alle imprese offerti da una
banca.
I processi direzionali comprendono le attività svolte dalla dirigenza della impresa: pianificazione
strategica, controllo di gestione (management control). Ad essi assimiliamo le attività di analisi dei
dati (business analysis / business intelligence). Scopo di questi processi è governare la azienda.
I processi di supporto corrispondono, grosso modo, alle attività burocratiche svolte da un’impresa
per rispondere agli adempimenti di legge e/o regolare il funzionamento interno: contabilità,
gestione del personale e delle risorse aziendali, servizi di supporto al business (servizi IT, servizi
generali), adempimenti vari di legge come comunicazioni al governo, certificazioni ….. Scopo di
questi processi è adempiere a richieste di legge e/o fornire servizi ai processi primari.
Processi
manageriali
(Management
processes)
Pianificazione strategica
Controllo di gestione
Business intelligence
Altri
SCOPO: governare le
azienda
Processi
Processi di
Primari supporto (Support
(Primary
processes)
processes)
Produzione ed
erogazione dei
prodotti e servizi
della azienda
SCOPO : servire
i clienti aziendali
Contabilità
Gestione risorse aziendali
(risorse umane, investimenti
e patrimonio ecc.)
Servizi di supporto al
business : servizi IT, servizi
generali, altri
Altri
Scopo: fornire servizi alla
azienda ed adempiere agli
obblighi di legge
Figura 10 Famiglie di processi gestionali: uno schema
Pagina 20 di 66
Cap2-ES-v14
4 Processi di supporto
Questo paragrafo illustra i processi di supporto. Un panorama schematico è dato dallo schema di
PROCESSI DI
SUPPORTO
AMMISTRAZIONE
SERVIZI
INFORMATIVI
RISORSE UMANE
ALTRI PROCESSI
CONTABILITA
SEZIONALI
PIANIFICAZIONE
RELAZIONI
INDUSTRIALI
PIANI &
STRATEGIA
CLIENT
MANAGEMENT
CONTABILITA
ISTITUZIONALE
GESTIONE
AMMIN.NE
PROGETTI E
MANUTENZIONE
ESERCIZIO
SISTEMI
CONTABILITA
GESTIONALE
PROCESSI VARI
GESTIONE
PRESTAZIONI
PROCESSI VARI
ALTRI SERVIZI
CONTABILI
Figura 11. Nel seguitone illustriamo brevemente alcuni classi. In primo luogo illustriamo i processi
contabili in quanto rappresentano il cuore dei processi di supporto e probabilmente il più antico
esempio di regolamentazione procedurale dei processi. In secondo luogo consideriamo la gestione
del personale, in quanto esemplifica un ciclo operativo dedicato alla gestione di risorse della impresa
(le ricorse umane). In terso luogo consideriamo un processo nato proprio con la informatica, cioè la
gestione dei sistemi informativi su elaboratore. Infine analizziamo un fenomeno essenziale per la
architettura dei processi, cioè la tendenza, molto forte a partire dagli anni Ottanta del secolo scorso,
ad appaltare parzialmente o totalmente processi di supporto, dando origine la fenomeno dello
outsourcing.
Pagina 21 di 66
Cap2-ES-v14
PROCESSI DI
SUPPORTO
AMMISTRAZIONE
SERVIZI
INFORMATIVI
RISORSE UMANE
ALTRI PROCESSI
CONTABILITA
SEZIONALI
PIANIFICAZIONE
RELAZIONI
INDUSTRIALI
PIANI &
STRATEGIA
CLIENT
MANAGEMENT
CONTABILITA
ISTITUZIONALE
GESTIONE
AMMIN.NE
PROGETTI E
MANUTENZIONE
ESERCIZIO
SISTEMI
CONTABILITA
GESTIONALE
PROCESSI VARI
GESTIONE
PRESTAZIONI
PROCESSI VARI
ALTRI SERVIZI
CONTABILI
Figura 11 Processi di supporto
4.1 Processi contabili
Le procedure contabili sono stati fra i primi processi codificati. Il modello del processi può essere
fatto risalire a Luca Pacioli (1494), che descrive e modella la partita doppia. .Lo schema rigodo e
formale delle registrazioni contabili obbliga le imprese a codificare un modo preciso di procedere,
detto appunto procedura. L’evoluzione dello schema contabile è continuata in modo lineare, e i due
sistemi contabili europeo (fondato appunto sulla partita doppia) e anglosassone si sono avvicinati, ed
oggigiorno sono regolati da standard IAS / IFRS (Wikipedia). Per semplicità distinguiamo i processi
contabili nelle classi Contabilità sezionali, Contabilità istituzionale, Contabilità gestionale.
La contabilità sezionale registra transazioni a debito e credito verso terzi, conseguenti ad attività
aziendali, che formano la contabilità verso fornitori (accounts payable), clienti (accounts
receivable), banche ecc. Per esempio, l'emissione di una fattura crea una registrazione nella
contabilità dei clienti.
La contabilità istituzionale, tipico oggetto centrale IAS/IFRS, include la elaborazione del bilancio e
delle comunicazione societarie complementari; tale processo è complesso nei grandi gruppi
multinazionali, che da una parte devono rispettare molteplici regole societarie e fiscali e dall’altra, in
quanto gruppi, devono consolidare i bilanci delle società del gruppo. Il problema del
consolidamento, della certificazione e delle comunicazioni pubbliche, moltiplicatosi in questi ultimi
venti anni, ha dato luogo a sistemi e processi specifici.
La contabilità gestionale (management accounting) serve a governare imprese complesse ed è nata,
con l’affermarsi delle grandi imprese, agli inizi del Novecento. Essa risponde a scopi interni e
cattura transazioni intra-aziendali (contabilità analitica) i cui creditori e debitori sono strutture della
impresa. Una contabilità gestionale dei Servizi Informativi registrerà costi e ricavi; i ricavi derivano
Pagina 22 di 66
Cap2-ES-v14
tipicamente dai servizi resi ai clienti aziendali. Per esempio il ricavo del software commissionato dal
reparto Acquisti ai Servizi Informativi potrebbe essere calcolato valorizzando le ore spese dai
Servizi Informativi. La contabilità gestionale permette anche di controllare la efficienza della
impresa paragonando le prestazioni attese con le prestazioni effettive. Come suggerisce il termine
“management accounting”, la contabilità gestionale alimenta i sistemi di controllo di gestione cui è
dedicato un apposito capitolo di questo libro.
Come è evidente da questi pochi cenni, i processi contabili, di limitata ampiezza organizzativa ed
altamente strutturati, sono stati automatizzati sino dalla preistoria della informatica. Le prime
automazioni, parziali, furono realizzate agli anni Trenta e Quaranta del secolo scorso con tecnologie
meccanografiche. I sistemi software di supporto alla contabilità sono oggi parte delle piattaforme
ERP (si veda il capitolo corrispondente).
4.2 Gestione del personale
Seguendo un paradigma notorio, diffuso in molti testi manageriali (p.e. Huselid 2005),dividiamo la
numerosa famiglia dei processi di gestione del personale (Human Resource Management) in ragione
del ciclo vitale del personale nella azienda, nelle tre classi Pianificazione, Gestione,
Amministrazione, Relazioni industriali.
La pianificazione (manpower plannig, human resources planning) determina i fabbisogni di addetti
confrontando da una parte la evoluzione naturale del capitale umano (per anzianità, carriera e
sviluppo delle competenze) e dall’altra il profilo delle richieste derivanti dalla presumibile strategia
della impresa. La differenza fra il profilo del capitale umano risultante dalla evoluzione naturale e
quello ottimale per la strategia sarà colmato attraverso opportuni programmi di formazione,
addestramento, riqualificazione, selezione.
Le relazioni industriali includono le attività di comunicazione e negoziazione con le organizzazioni
sindacali e/o le rappresentanze dei dipendenti. E’ un processo tipicamente manageriale, che è parte
integrante della direzione di impresa, e che è poco strutturabile.
La gestione operativa include vari processi. Questi processi, molto curati nelle imprese ad elevato
contenuto professionale (consulenza, aziende informatiche, settori ad alta tecnologia ecc.),
rispecchiano le fasi del ciclo vitale del personale nella impresa. Illustriamo brevemente le principali
fasi del ciclo.
•
•
•
Il ciclo di ricerca, selezione ed assunzione è ampiamente basato anche su informazioni
esterne ed in molti casi è affidato parzialmente o totalmente a ditte esterne (outsourcing).
La informazioni al personale include (a) la pubblicazione di comunicazioni aziendali p.e.
sulla organizzazione, il contratto, nuovi incarichi ecc. (b) l’accesso del singolo dipendente
alle informazioni sulle proprie ferie, permessi ed altri (c) transazioni di iscrizione a circoli,
attività dopolavoristiche ecc.; nell’insieme queste attività sono informatizzate dai sistemi di
Employee Relationship Management, a loro volta parte delle suite ERP (si veda il capitolo
dedicato agli ERP).
La valutazione periodica delle prestazioni e del potenziale e gestione della carriera è un ciclo
periodico in cui sono decisi gli avanzamenti in ragione dei risultati ottenuti; nelle imprese di
Pagina 23 di 66
Cap2-ES-v14
•
•
consulenza è un processo manageriale supportato da appositi software; una variante è la
gestione della carriera nella Pubblica Amministrazione, basata su norme più che su giudizi.
La formazione ed addestramento include la pianificazione, progettazione ed erogazione delle
iniziative di formazione come corsi, tirocini, affiancamenti ecc.
Il rilascio e ricollocazione comprendono le attività relative alla ricollocazione professionale
di personale interno (outplacement).
La amministrazione, molto variabile di nazione in nazione, include a sua volta varie fasi, fra le quali:
•
•
•
•
Rilevazione delle presenze e delle assenze
Calcolo ed erogazione delle retribuzioni
Adempimenti fiscali
Adempimenti previdenziali
I sistemi di supporto alla gestione del personale, oggi inseriti delle piattaforme ERP, sono in larga
misura orizzontali per i processi di pianificazione e gestione, mentre i sistemi di amministrazione,
data la diversità dei sistemi previdenziali, sono serviti da moduli software locali. Gli ES di supporto
alla gestione del personale possono essere variamente integrati a tecnologie di automazione della
formazione (Computer Aided Instrunction, Computer Aided Learning) e di gestione delle
conoscenze (Knowledge Base Systems).
4.3 Servizi informatici
I servizi informatici sonno una classe di processi doppiamente interessante. In primo luogo sono nati
con la tecnologia informatica. In secondo luogo essi sono ampiamente appaltati al fenomemdo dello
outsourcing.
Una prima sistematica classificazione dei servizi informatici risale a David Norton, celebre per la
Balanced Score Card, che divide i servizi informatici nelle tre classi di pianificazione, sviluppo (=
progetti software) ed esercizio (Norton 1973). La classificazione qui proposta riflette il ciclo vitale
delle risorse IT e del servizio ai clienti interni (Capé 2005): Pianificazione, Client Management,
Progettazione e manutenzione delle applicazioni software, Esercizio dei sistemi, Gestione delle
prestazioni. Illustriamo brevemente ciascun processo.
La pianificazione programma i fabbisogni IT incrociando la evoluzione naturale delle applicazioni e
degli impianti (per obsolescenza tecnologica, obsolescenza funzionale) con le future esigenze dalla
della impresa, e definisce i relativi progetti. Questo processo, di livello manageriale, è ampiamente
discusso nel capitolo sulla pianificazione IT.
Il client management comprende le attività di supporto alle funzioni organizzative della impresa ,
che sono clienti interni dei Servizi Informatici, finalizzate alla analisi ed alla formalizzazione delle
esigenze dei processi gestionali. Questa analisi si concreta in progetti di nuovi sistemi e/o di
evoluzione/messa a punto di applicazioni esistenti. Si tratta di un processo poco strutturato, dove
compito dei sistemi è registrare documenti e mappare le esigenze sulla architettura dei processi e dei
sistemi della impresa.
Pagina 24 di 66
Cap2-ES-v14
Il progetto del software è un processo complesso, che copre il ciclo vitale del progetto, dalla analisi
delle esigenze alla messa in esercizio, la cui struttura e flusso sono illustrati in un apposito capitolo.
Si tratta di un processo non ripetitivo, tendenzialmente poco strutturato, difficile da informatizzare,
analogo a quello di sviluppo dei prodotti in una azienda industriale. Una apposita classe di sistemi
supporta la gestione del progetto (Project Management Systems) e quella dei documenti prodotti
(Document Management Systems). Al progetto software è assimilata la manutenzione delle
applicazioni che include interventi di natura correttiva, che rimuovono i malfunzionamenti, adattiva,
che adeguano il software a nuove prescrizioni p.e. legali, migliorativa od evolutiva che aggiunge o
modifica funzionalità del sistema.
L’esercizio dei sistemi include attività operative necessarie a mantenere in esercizio sia gli impianti
su cui operano gli ES sia il software degli ES. Include operazioni di pulizia della base dati e delle
software, conduzione dei centri di elaborazione, supporto alla informatica distribuita (personal
computer installati presso gli utenti, reti locali ecc.).
La complessità degli ES nelle aziende ha portato allo sviluppo di una famiglia di processi legati alla
gestione delle prestazioni spesso a fronte di un accordo di servizio (Service Level Agreement).
Questo processo, che comprende la definizione del livello di servizio e i processi di mantenimento
del livello di servizio a fronte di malfunzionamenti (Incident Management) o anche disastri
(Disaster Recovery), porta a sistemi molto sofisticati (Gay 2008).
4.4 Outsourcing dei processi
A partire dagli anni Ottanta del secolo scorso, le grandi imprese hanno iniziato ad appaltare i
processi di supporto. Caso emblematico è la manutenzione impianti degli stabilimenti chimici,
petroliferi e siderurgici, che é svolta da imprese specializzate. La terziarizzazione ha toccato anche
le aree contabili, l’amministrazione del personale, la selezione del personale, la logistica ed i servizi
informatici, generando il mercato dello outsourcing, che ha sua volta creato una ampia gamma di
industrie di servizi alle imprese. Va sottolineato che l’outsourcing di servizi è diverso dallo
outsourcing di risorsa, che avviene quando una impresa ricorre a personale esterno per svolgere
compiti interni, p.e. nel caso di venditori.
L’outsourcing trasforma i processi di servizio sia nella impresa cliente sia nella impresa fornitrice.
Nella impresa fornitrice il processo di supporto diviene un processo primario di erogazione di un
prodotto o servizio erogato al mercato. Nella impresa cliente si crea uno specifico processo di
gestione delle prestazioni, in genere basato su accordi di servizio (Service Level Agreement) come
già accennato a proposito dei servizi informatici. Lo SLA può essre sostituito e/o integratio da
capitolati o specifiche. Come hanno messo in luce già le prime ricerche sistematiche
sull’outsourcing dei servizi IT (Lacity 1993, Motta 1993), il rapporto di outsourcing crea un
caratteristico schema a L, dove si separano le attività di governo e controllo del servizio da parte
della impressa cliente dalle attività di erogazione dei servizi da parte della impresa o delle imprese
fornitrici.
L’outsourcing quindi modifica la architettura dei processi di una impresa in quanto non solo
esternalizza in tutto o in parte attività operativa ma anche in quanto duplica i controlli,
rispettivamente nella impresa cliente, che negozia non solo le condizioni economiche ma anche il
livello di servizio fornito, e nella impresa fornitrice, che pianifica e controlla a sua volta il livello di
Pagina 25 di 66
Cap2-ES-v14
servizio ricevuto. La procedura e le regole SLA sono ampiamente sviluppate dallo ITIL ( www.itilofficialsite.com ) e da omologhi organi e consorzi.
Processi ed attività strategiche del
cliente
Governo del livello di servizio (SLA) da parte
del cliente
Pianificazione e controllo del servizio da
parte del fornitore
Erogazione dei servizi da parte del fornitore
Figura 12 Schema a L dell’outsourcing dei servizi
La tabella qui sotto, indicativa, esemplifica la frequenza di outsourcing di alcuni processi di
supporto. Come si nota, l’outsourcing si concentra su compiti operativi che richiedono massa critica
e che sono governabili mediante capitolati (formazione) e/o specifiche (progetti software) e/o
contratti di servizio ( amministrazione del personale, esercizio di sistemi).
Classe
processo
Servizi
informativi
Sottoclasse
Processo
Pianificazione
Progetti e manutenzione software
Client management
Gestione
personale
Frequenza
Outsourcing
Da bassa a
nulla
Elevata
Esercizio dei sistemi
Da bassa a
nulla
Media
Governo servizio
Nulla
Pianificazione
Nulla
Gestione
operativa
Ricerca, selezione ed
assunzione
Media elevata
Commenti
Non in outsourcing in quanto assicura
il governo strategico
I progetti sono spesso affidati ad
aziende di systems integration in
quanto il personale interno non
possiede la esperienza necessaria;
anche la manutenzione è spesso
affidata a terzi
Non in outsourcing in quanto governa
le esigenze degli utenti della impresa
Outsourcing motivato da ragioni di
costo e di affidabilità
il governo dei servizi informatici
il governo strategico delle risorse
umane (analogamente alla
pianificazione dei servizi informativi)
La ricerca e la selezione sono spesso
affidate a ditte specializzate
Pagina 26 di 66
Cap2-ES-v14
Informazione al
personale
Nulla
Valutazione delle
prestazioni
Nulla o bassa
Formazione ed
addestramento
Elevata
Rilascio e ricollocazione
Variabile
Relazioni industriali
Nulla
Amministrazione
Media
Rilevazione presenze,
Retribuzioni,
Adempimenti fiscali,
Adempimenti
previdenziali
Tabella 3 Outsourcing di processi di supporto
Processo tipicamente interno in quanto
connesso con le relazioni con il
personale
Processo tipicamente interno in quanto
connesso con le relazioni con il
personale
La erogazione di formazione e
addestramento è tipicamente affidata
a terzi (università, consulenti) in
quanto le imprese raramente
posseggono le capacità necessarie.
In alcuni casi le imprese si rivolgono a
ditte specializzate
In quanto parte integrante della
direzione di impresa
L’outsourcing si concentra sul calcolo
delle retribuzioni
5 Processi manageriali e di analisi
Tra gli anni Sessanta e Ottanta del secolo scorso la riflessione teorica sul management ha raggiunto
una sostanziale maturità ed ha elaborato schemi che sono divenuti classici, come quelli di Anthony
(1965) e di Gorry e Scott-Morton (1971), affinati negli anni Novanta e nei primi anni da una serie di
teorie sul controllo strategico, quali la Balanced Score Card di Kaplan e Norton (1996). Tali schemi
perfettamente attuali anche oggi.
5.1 La piramide di Anthony e lo schema dei livelli manageriali
Robert Anthony è quasi unanimemente considerato il fondatore del controllo di gestione, che è
elemento essenziale del governo delle imprese. Alla travolgente crescita dimensionale delle imprese,
iniziata dagli anni Settanta, ha infatti largamente contribuito lo sviluppo e la diffusione di robusti e
strutturati processi di pianificazione e controllo. Tale sviluppo è stato a sua volta reso possibile dalla
informatica, che ha fornito il carburante per la realizzazione pratica. Oggi i sistemi di controllo sono
in grado di elaborare mensilmente i budget di migliaia di strutture organizzative – stabilimenti,
filiali, uffici – con milioni di registrazioni, a loro volta ricavate dalla aggregazione di milioni di
transazioni elementari. Un celebre articolo degli anni Sessanta (Dearden 1972) titolava
“Management Information System is a mirage”. Oggi si può invece dire “Seamless information”.
La teoria di Anthony è esposta in un sistematico trattato (Anthony 1965) che è stato ed è la bibbia di
centinaia di migliaia di manager di tutto il mondo. Essa classifica e rende comprensibile la
informazioni elaborata per governare la impresa. Anthony distingue i processi di governo della
impresa in tre livelli (Figura 13):
1. Pianificazione Strategica (Strategic Planning) che fissa gli obiettivi complessivi della
impresa (per esempio, quali prodotti introdurre e in quali mercati entrare).
Pagina 27 di 66
Cap2-ES-v14
2. Controllo Direzionale (Management Control), che definisce gli obiettivi economici (per
esempio budget) e verifica i risultati ottenuti;
3. Controllo Operativo (Operations Control), che agisce in tempo reale sulle singole attività
esecutive (per esempio la fabbricazione di una automobile) ed assicura che procedano nel
modo prefissato;
Notiamo che i livelli dei processi corrispondono ai livelli gerarchici delle strutture organizzative
delle imprese. La Pianificazione Strategica corrisponde infatti alla Direzione Generale, il Controllo
Direzionale al management intermedio ed il Controllo Operativo ai capiufficio e ai capisquadra. In
secondo luogo, con perfetta simmetria, ogni livello compie un ciclo di feedback competo, che
include la definizione degli obiettivi (piano), il controllo dei risultati e le eventuali azioni correttive
(controllo). La tabella qui sotto, rielabora lo schema originale e ne descrive il profilo CRASO, cui è
stata aggiunta la colonna frequenza (Tabella 4).
s
es
r
og
Pr
o
e
on
i
z
Pianificazione
za
z
it
Strategica
a
m
r
(Strategic
fo
in
Planning)
Controllo Direzionale
(Management Control)
Controllo Operativo
(Operations Control)
Figura 13 La piramide di Anthony ed il potenziale supporto informatico ai livelli di pianificazione e controllo (tratteggiato)
La Pianificazione Strategica di una impresa è eseguita “ogni volta che serve”, e sarà più frequente in
periodi di crisi o di innovazione e meno in periodi di stabilità. Output fondamentale è il piano delle
iniziative strategiche, che descrive e programma i progetti che attuano la strategia, siano essi di
ricerca & sviluppo (sviluppo di una nuova linea di prodotti), organizzativi (p.e. la fusione con e/o
acquisizione di una impresa), di mercato (p.e. entrare in un nuovo mercato). La periodicità del
controllo sarà quindi fissata dal piano dei progetti che attuano le iniziative strategiche.
Osserviamo che la analisi dei concorrenti e del mercato è oggi fortemente potenziata dalle
informazioni disponibili in quantità enormi grazie alle tecnologie di Business Intelligence (cui è
dedicato un apposito capitolo) come sottolineato da un fortunato testo manageriale (Davenport
2006).
Pagina 28 di 66
Cap2-ES-v14
Il processo strategico è oggi, forse, il processo manageriale più chiaramente strutturato, grazie alle
elaborazioni di Kaplan e Norton sulla Balanced Score Card (BSC). La BSC, illustrata in un capitolo
successivo, struttura e guida sia la definizione degli obiettivi sia il controllo delle iniziative
strategiche, fornendo un modello normativo. Chiave di volta della BSC è lo schema a quattro
quadranti degli obiettivi strategici, che appunto bilancia obiettivi di breve (redditività), di medio
(presenza sul mercato e sui clienti ed efficienza dei processi interni) e di lungo (sviluppo delle
risorse umane, delle tecnologie e della ricerca). Nella fase di attuazione e controllo della strategia
gli obiettivi sono opportunamente assegnati a manager e sono definiti e controllati i relativi piani
azione. obiettivi ai manager. Fra i best seller manageriali di tutti i tempi, la BSC, formulata nel
1992 (Kaplan 1992), è sviluppata in una lunga serie di scritti (Kaplan 1993, 1996, 2001, 2004,
2008). Alla BSC dedichiamo un paragrafo apposito in un capitolo successivo ( Figura 14).
PRESTAZIONI & OBIETTIVI
ECONOMICI E PATRIMONIALI
Redditività
Crescita
PRESTAZIONI & OBIETTIVI SU
CLIENTE E MERCATO
Quota di mercato
Soddisfazione cliente
Visione &
strategia
FUNZIONAMENTO INTERNO
(PROCESSI)
Ciclo di innovazione
Ciclo operativo
APPRENDIMENTO E CRESCITA
Risorse umane
Risorse tecnologiche
Conoscenze
Figura 14 Balanced Score Card esemplificata su una generica azienda industriale
La fase di pianificazione del Controllo Direzionale ha frequenza annuale (in quanto coincide con
l’esercizio di bilancio) e può essere, nelle grandi imprese multinazionali, molto complessa. La fase
di controllo è tipicamente mensile, e comporta un analisi dei risultati sulla dei centri di budget
(centri di costo, centri di profitto) in cui è articolata la impresa, il cui numero può raggiungere,
anche in una media impresa, il migliaio. L’analisi di solito, come noto, avviene in comitati di
dirigenti, dove ciascun dirigente giustifica / spiega i suoi risultati e propone le eventuali azioni
correttive. Lo schema del controllo direzionale è quasi universale, ed un sistema di controllo
direzionale di una azienda telefonica può essere trasportato quasi invariato ad una azienda
automobilistica.
Anche il Controllo Operativo comprende una fase di pianificazione ed una fase di controllo. Lo
schema più classico è nelle imprese automobilistiche, in cui la pianificazione operativa è scatola
cinese, con un ciclo di pianificazione annuale, un ciclo mensile e uno settimanale (detto anche
Pagina 29 di 66
Cap2-ES-v14
programmazione operativa), ed infine il ciclo di schedulazione (scheduling), che arriva ai minimi
dettagli operativi e da molti considerato esecuzione più che pianificazione. Come suggerisce la
stessa definizione, il Controllo Operativo rispecchia le caratteristiche operative di ciascuna impresa
e, conseguentemente, ha caratteristiche molto variabili di settore in settore. In generale la
complessità del Controllo Operativo è funzione della complessità del prodotto e di quella del
processo produttivo. Essa è quindi massima nelle industrie aerospaziali e minima nelle imprese di
servizio, come assicurazioni o banche, dove la pianificazione operativa in pratica non esiste.
Classe
processo
Pianificazione
Strategica
(strategic
planning)
Controllo
Direzionale
(management
control)
Controllo
Operativo
(operations
control)
Sottoclasse
Frequenza
Cliente
Richiesta
Attività
Pianificazione Variabile
“quando
necessario”
Direzione
generale
Richiesta
di piano
strategico
Controllo
Periodica,
variabile (p.e.
mensile o
bimestrale)
Direzione
generale
Piano di
controllo
Budgeting
Annuale
Direzione
generale
Richiesta
di budget
Definizione
obiettivi
strategici
Analisi della
domanda
Analisi della
concorrenza
Definizione
iniziative
strategiche
Controllo
periodico
iniziative
strategiche
Azioni correttive
Definizione
obiettivi di
ricavo e di costo
Formulazione
budget
Controllo
risultati
Mensile
Direzione
generale
Piano di
controllo
Controllo
mensile risultati
Azioni correttive
e aggiornamento
budget
Management Richiesta
operativo
di piano
Definizione
obiettivi di
periodo
(vendita,
produzione,
distribuzione cc.)
Formulazione
piano
Pianificazione Formulazione
piano : da
annuale a
mensile a
giornaliera
Controllo
Variabile: da
mensile a
giornaliera e
istantanea
Organizzazioni
partecipanti 1
Uffici di
pianificazione
Esperti esterni
Management
intermedio
Output
Piano
strategico
Rendiconti di
avanzamento
Piano azioni
correttive
Uffici
amministrazione
e controllo
Direzione
generale
Budget e
aggiornamenti
Analisi
scostamenti
Piano azioni
correttive
Uffici
Piani e
pianificazione
aggiornamenti
operativa vendita,
produzione ecc.
Management
intermedio
Analisi
scostamenti
Piano azioni
correttive
Tabella 4 Profilo CRASO dei processi direzionali di Anthony
1
Alcuni autori considerano la pianificazione operativa come un processo esecutivo e non manageriale. Per esempio lo
schema SCOR (discusso più avanti) considera pianificazione operativa ed esecuzione come fasi complementari delle la
gestione operativa della supply chain.
Pagina 30 di 66
Cap2-ES-v14
Anthony inoltre caratterizza il profilo informativo di ciascuno livello di direzione (Tabella 5). Il
controllo operativo usa un numero elevato di informazioni elementari. Per esempio la
programmazione della produzione di una fabbrica automobilistica dovrà elaborare, in tempo reale o
molto frequentemente, informazioni dettagliate, come le specifiche delle singole macchine da
produrre, la descrizione delle singole attività di fabbricazione, la capacità produttiva del singolo
impianto e molti altri dati. Il corrispondente sistema di controllo direzionale opererà su una gamma
di informazioni molto più limitata, che, nel caso dello stabilimento, includerà le voci di costo dello
stabilimento e le voci di ricavo, con un ciclo di elaborazione settimanale o mensile. La
pianificazione strategica non solo ha frequenza variabile, ma una gamma ampia di informazioni, in
larga parte esterna. Nel caso della fabbri automobilistica, potrebbe includere studi, analisi di
mercato, ricerche ed altro. In sintesi, come evidenzia la Tabella 5, il peso dei SI è tanto maggiore
quanto più elementari ed interne sono le informazioni da trattare; inoltre, la quota di informazioni
strutturate decresce a mano a mano che ci si sposta dal controllo operativo al controllo direzionale
ed alla pianificazione strategica.
Lo schema di Anthony è potente e offre una convincente interpretazione della relazione fra
architettura dei processi ed architettura dei sistemi. La architettura dei processi direzionali è rimasta
invariata dai tempi di Anthony ad oggigiorno. La tecnologia informatica ha invece progredito,
aumentando progressivamente la quota di processi informatizzati, grazie a una crescente
integrazione, che permette di collegare informazioni “non strutturate”, come documenti ed
immagini, ad informazioni “strutturate”, come dati numerici.
PROFILO
INFORMAZIONI
CONTROLLO
OPERATIVO
Dati elementari
Predefinita
Continua
Interna
LIVELLI DI CONTROLLO
CONTROLLO
DIREZIONALE
Sintesi
Predefinita
Periodica
Interna ed esterna
Formato
Struttura
Frequenza
Fonte
Tabella 5 Livelli di controllo e profilo delle informazioni in Anthony
PIANIFICAZIONE
STRATEGICA
Sintesi
Variabile
Non prefissata
Prev. esterna
5.2 La prospettiva decisionale
Lo schema di Anthony definisce lo schema di pianificazione e controllo della impresa dal punto di
viste delle variabili ma non classifica il processo decisionale, cioè il modo in cui un manager decide
una data azione. La prospettiva decisionale nasce con Simon (1958), che può essere considerato
fondatore della teoria manageriale, concepisce la impresa come un sistema articolato su tre livelli:
•
•
•
i processi fisici, produttivi e distributivi;
le decisioni che controllano le operazioni ordinarie, relative cioè ai processi fisici;
le decisioni che valutano il risultato delle decisioni operative e ne variano le regole.
Le decisioni possono essere strutturate o non strutturate. Una decisione è strutturata quando segue
uno schema, e con un certo input produce sempre lo stesso output. Una decisione è invece
destrutturata quando è presa sulla base di cognizioni e/o emozioni soggettive. Le decisioni operative
sono strutturate, possono essere programmate ed essere riprodotte via software.
Pagina 31 di 66
Cap2-ES-v14
Gorry e Scott-Morton (1971) fondono la teoria di Simon con quella di Anthony, introducendo anche
la tipologia decisionale “semi-strutturata”in cui sono definiti gli output ma il processo decisionale
non è riducibile ad una regola unica e predefinita. Le tipologie decisionali e i livelli di Anthony
sono incrociati in una griglia a nove caselle. Gli esempi della tabella qui sotto sono auto-esplicativi e
non richiedono molti commenti (Tabella 6)
LIVELLO DI CONTROLLO
CONTROLLO
CONTROLLO
PIANIFICAZIONE
OPERATIVO
DIREZIONALE
SRATEGICA
Strutturato
Approvvigionamento scorte
Budget manutenzione
Localizzazione impianti
Semi-strutturato
Compravendita di titoli
Budget vendite
Acquisizione di finanziamenti
Non-strutturato
Scelta della copertina di una Assunzione di dirigenti
Strategia di Ricerca & Sviluppo
rivista
Tabella 6 La griglia attività-decisioni di Gorry e Scott-Morton
PROCESSO
DECISIONALE
L’incrocio fra profilo delle decisioni e profilo delle informazioni è rilevante, poiché contribuisce a
definire la area elettiva della informatizzazione nei processi manageriali. Uno schema è dato nel
quadrante illustrato qui sotto, che incrocia la strutturazione delle decisioni con la strutturazione delle
informazioni. Una informazione è strutturata se può essere descritta da un tracciato record (esempio
notorio le registrazioni contabili), cioè una tupla, i cui singoli elementi hanno valori definiti su
specifici domini. Una decisione è strutturata se riducibile ad una regola logica e/o algebrica
(esempio notorio sono le decisioni di approvvigionamento). Le frecce indicano la espansione del
supporto informatico grazie al progresso da una parte della elaborazione / memorizzazione di testi,
immagini e suoni, e dall’altra dei motori di ricerca (Yahoo,Google ecc.) su Internet, e, infine, dei
sistemi di Business Intelligence, fondati su basi dati appositamente realizzate per le consultazione ed
alimentate dai dati elementari ricavati dai sistemi di supporto operativo.
Alta
Bassa
Strutturazione informazione
Strutturazione decisione
Bassa
Alta
Informatizzazione
parziale (anello aperto)
Informatizzazione
completa (anello
chiuso)
Memorizzazione documenti
Figura 15 Quadrante della informatizzazione dei processi direzionali .
Pagina 32 di 66
Cap2-ES-v14
Il quadrante della strutturazione completa è esemplificato da sistemi di controllo operativo, come la
pianificazione dei materiali di una fabbrica. La quantità di materiale da approvvigionare NR si
ottiene sommando il materiale assorbito dalla produzione GR (elaborato da un apposto calcolo),
sottraendo le scorte disponibili S e il materiale già ordinato OR, e sommando le scorte di sicurezza
MS, secondo la formula (semplificata) NR = GR - (S + OR) + MS. Il processo decisionale equivale
alla esecuzione di una regola.
Il quadrante della strutturazione decisionale parziale (con informazioni strutturate) è esemplificato
dalla pianificazione della costruzione di una nave, dove tutte le informazioni sui materiali sono
strutturate e memorizzate in basi dati, ma nessuna formula è applicata od applicabile per decidere
che cosa approvvigionare e quando. Analogo esempio è la pianificazione di un progetto software. In
questi casi il supporto informatico è finalizzato a fornire informazioni per valutare le possibili
alternative.
Il quadrante della alta strutturazione decisionale e della bassa strutturazione informativa é
esemplificato dalla accettazione di derrate alimentari in un supermercato, dove il decisore considera
non solo informazioni strutturate ma anche percezioni (aspetto esterno del materiale, fragranza ecc.),
ma segue regole precise e rigide.
Il quadrante della bassa strutturazione decisionale e della bassa strutturazione informativa è
esemplificato da decisioni emozionali, come la decisione di partecipare o non partecipare ad una
gara di appalto. Si noti che la bassa strutturazione non esclude l’uso del computer che offre la
possibilità di consultare ed analizzare documenti correlati. .
5.3 Processi di analisi e gestione delle conoscenze
Accenniamo infine per completezza ai processi di analisi, che hanno lo scopo di fornire conoscenza
alla impresa e/o di permettere verifiche e/o di migliorare il funzionamento dei processi primari,
manageriali e di supporto Fra questi processi menzioniamo la gestione della qualità e la analisi delle
conoscenze
La gestione della qualità è pervasiva, ed avviene in molteplici ambiti, nei servizi informativi come
anche nelle attività di gestione dei materiali o nella fabbricazione. Molte aziende hanno un referente
specifico, che cura la gestione della qualità e la applicazione di standard ISO. In generale il processo
di qualità può essere definito da un paradigma CRASO, che si specializza sui vari domini.
L’approfondimento del tema fuoriesce dal nostro ambito.
Ancora più trasversale e variabile è la gestione delle conoscenze. Una prima prospettiva rispecchia
un ciclo vitale della conoscenza, che attraversa le fasi di conoscenza esplicita e di conoscenza tacita
(Nonaka 1995). La produzione e di gestione della conoscenza diviene quindi essenziale per
competere in quanto aumenta le capacità di una impresa (capacità di migliorare continuamente, di
formalizzare ed industrializzare le proprie pratiche). Il supporto alla conoscenza è obiettivo specifico
dei sistemi di Knowledge Management, termine introdotto nel 1986 da Karl Wiig, autore anche del
primo trattato sistematico (Wiig 1999).
Pagina 33 di 66
Cap2-ES-v14
6 Processi primari
6.1 Teorie e modelli
6.1.1 Il portafoglio applicativo
La prima definizione di una tassonomia dei Sistemi Informativi (SI) risale a Blumenthal (1969).
Blumenthal intende fornire un quadro di riferimento (framework) per uno sviluppo modulare del SI :
i moduli sono gruppi autosufficiente di programmi software, fra loro collegati da flussi di dati. Per
definire i moduli, usa due criteri fondamentali:
•
•
i livelli di controllo individuati da Anthony: controllo direzionale, controllo operativo;
la tipologia delle risorse aziendali definita da Forrester nella sua Dinamica Industriale
(1959), cioè personale, danaro, materie prime, prodotti finiti, attrezzature.
Ciascun modulo del SI tratta perciò informazioni che riferiscono a un dato livello di controllo (p.e.
operativo) ed a un dato flusso di risorse (p.e. materie prime). Poiché il meccanico incrocio fra i
cinque flussi di risorse e i due livelli di controllo porta a moduli troppo ampi, Blumenthal scende a
un maggior livello di dettaglio applicando regole ad hoc. Un esempio è dato in figura 12. I SI per il
controllo operativo sono suddivisi in "amministrativi" e "fisici", e questi ultimi fra quelli che
controllano i flussi dei materiali e quelli invece che trattano le informazioni relative alle attrezzature.
Le suddivisioni finali, come per esempio "Materie Prime", costituiscono dei moduli. Anche se soffre
di tutti i limiti delle concezioni pionieristiche (è libresca e manca una validazione una ricerca a sul
campo che validi lo schema), la tassonomia di Blumenthal ha influenzato la teoria manageriale.
CONTROLLO
OPERATIVO
CONTROLLO
FLUSSI
AMMINISTRATIVI
CONTROLLO
FLUSSI FISICI
LOGISTICA
FINANZA
(DANARO)
IMPIANTI
PERSONALE
MATERIE PRIME
INSTALLAZIONE
CASSA
ASSUNZIONE
SEMILAVORATI
ESERCIZIO
CONTABILITRA
PAGHE
PRODOTTI FINITI
Figura 16 Scomposizione dei sistemi informativi della impresa secondo Blumenthal
Pagina 34 di 66
Cap2-ES-v14
Strategic Planning
Management Control
Payroll
Human Resources Management
Receivables
Payables
General Ledger
Equipment Maintenance
After Sales Service
Distribution & Outbound Logistics
Sales & Marketing
Production Planning
Materials Management
Procurement & Purchasing
Product Development
Figura 17 Il portafoglio applicativo di Nolan: informatizzazione corrente e pianificata delle funzioni aziendali
(esempio)
Pochi anni dopo, Nolan (1974) propone uno schema semplificato, il fortunato Applications Portfolio
Lo schema è sui tre livelli: strategic planning, management control, operations. Questo ultimo
livello, che include i due sotto-livelli operations control (p.e. production planning) ed transactions
processing (p.e. Payroll).
Un esempio è dato in Figura 17. Il portafoglio delle applicazioni per operations control (p.e.
production planning) e transactions processing è diviso in colonne, ciascuna delle quali rappresenta
una data funzione aziendale (le funzioni esemplificate sono, con alcune semplificazioni,
caratteristiche di una azienda automobilistica). L’altezza del riempimento rappresenta il tasso di
informatizzazione, rispettivamente corrente e pianificato, misurato sul supporto fornito alle attività
della impresa. Tale misura è una scala qualitativa ed è ricavata da interviste al management ed
analisi comparative. Il tasso di informatizzazione esemplificato è tipico degli stadi iniziali della
informatica della impresa, in cui sono informatizzati prevalentemente i processi di supporto. Lo
schema di Nolan, grazie alla sua semplicità ed immediatezza, è usato anche oggi.
6.1.2 La value chain di Porter
La protostoria dei reference framework si può dire conclusa con la notissima Value Chain di M.
Porter (1985) che qui brevemente illustriamo. Secondo Porter, le aziende creano il valore del
prodotto o servizio venduto al cliente attraverso una successione di fasi.
Pagina 35 di 66
Cap2-ES-v14
Figura 18 Lo schema canonico della Value Chain di Porter
Lo schema canonica della Value Chain di Figura 18 rappresenta le fasi in cui le aziende
manifatturiere creano valore:
•
•
•
•
•
Logistica in entrata (inbound logistics), cioè la gestione del flusso in entrata delle materie
prime usate per la produzione del prodotto;
Trasformazione (operations), che include le attività attraverso cui le materie prime sono
trasformate in prodotti finiti mediante procedimenti di fabbricazione, miscelazione,
elaborazione ed altri;
Logistica in uscita (outbound logistics), che comprende le operazioni attraverso le quali il
prodotto finito è consegnato ai clienti;
Marketing e vendita (marketing and sales), che comprendono le operazioni attraverso cui
sono promossi i prodotti e sono negoziate le vendite con i clienti;
Postvendita (Service), che comprende le attività di assistenza post vendita, di manutenzione,
di fornitura dei ricambi e simili, particolarmente importanti per beni durevoli come
automobili, autocarri, trattori, frigoriferi, elaboratori, eccetera.
Secondo Porter il valore che il cliente è disposto a pagare dipende anche dal valore che il cliente
stesso percepisce essere stato creato nelle diverse fasi. Siamo disposti a pagare un’auto di lusso più
di un’utilitaria perché pensiamo che il valore dell’assistenza, delle materie prime, della
fabbricazione e delle altre fasi, sia superiore. Il margine quindi è dato dalla differenza fra valore
percepito dal cliente e il costo sostenuto dalla azienda
Le fasi di creazione del valore sono dette da Porter “attività primarie”. Sono invece classificate
“attività di supporto” quelle attività che non creano direttamente valore ma sono necessarie al
funzionamento dell’azienda, come la gestione della infrastruttura organizzativa ed amministrativa
Pagina 36 di 66
Cap2-ES-v14
della azienda (Infrastructure), la gestione del personale(Human Resources Management), la
tecnologia di processo e di prodotto (technology) e infine le acquisizione delle risorse e delle
conoscenze (procurement).
Vogliamo infine sottolineare i limiti di applicabilità della Value Chain. Certamente la distinzione
fra attività primarie e attività di supporto è assolutamente universale, ed è stata da noi adottata nello
schema generale dei processi (Figura 10). La classificazione delle attività di supporto è troppo
grossolana per potere esser usata come tassonomia. A sua volta la classificazione delle attività
primarie è perfetta per definire il primo livello dei processi gestionali della industria manifatturiera,
ma non è applicabile ad altri settori, per cui sono invece stati sviluppati specifici framework.
Lo schema della value chain è rapidamente divenuto perno della concezione manageriale della
impresa e la idea della catena del valore è stata estesa oltre i confini delle singole imprese con la
definizione del concetto di value system cioè di un sistema di value chain interconnesse, che
iniziano dal fornitore delle materie prime ed includono imprese produttrici e distributrici (Wikipedia
2009). Tale concezione è stata sviluppata nello schema della Supply Chain, cui accenniamo di
seguito.
Lo schema di Porter è rilevante strategicamente, poiché condiziona il management a comportamenti
decisionali decisivi per il ruolo della IT nelle imprese. In primo luogo, porta il management a
finalizzare gli investimenti, inclusi gli investimenti IT, e le attività di supporto alla massimizzazione
del valore. Ciò porta a usare la IT per rafforzare le attività primarie piuttosto che le secondarie. In
secondo luogo, porta il management, per la stessa ragione, a minimizzare i costi delle attività di
supporto, quindi anche della IT, in quanto da una parte non aumentano il valore al cliente e,
dall’altra, riducono i margini.
6.1.3 Schemi di settore, best practices e business maps
Gli schemi di settore descrivono la architettura dei processi di un dato settore industriale. In generale
la descrizione è sui livelli livello impresa, processo ed attività, e include la struttura e / o il flusso e/o
altri attributi. Questi schemi offrono una classificazione standard a tutte le imprese di un settore e
sono di grande valore per il progettista cui forniscono un riferimento da adattare di caso in caso,
risparmiando il tempo e gli errori di una analisi ad hoc. Fra gli schemi di settore citiamo:
•
•
•
Pubblica Amministrazione: i governi EU hanno adottato / suggerito una tassonomia comune
dei servizi basata sugli eventi della vita del cittadino e della impresa Life Events per favorire
la interoperabilità (cfr. il capitolo sui sistemi della Pubblica Amministrazione e il paragrafo
7.7 di questo stesso capitolo)
Industria Manifatturiera: un consorzio di circa 1.000 di tutto il mondo ha sviluppato lo
schema di riferimento SCOR della supply chain (cfr. paragrafo 7.1 ivi) e per la progettazione
DCOR (cfr paragrafo 7.2 ivi) cui fanno riferimento in varia misura anche i maggiori
produttori di software ERP e simili.
Telecomunicazioni : le maggiori aziende di telecomunicazione hanno elaborato una propria
tassonomia delle applicazioni, detta TMN (cfr paragrafo 0 ivi)
I “modelli proprietari” sono schemi non pubblici ma usati in esclusiva da una azienda, in genere una
società di consulenza organizzativa o di systems integration. Le maggiori società di systems
Pagina 37 di 66
Cap2-ES-v14
Integration iniziano infatti i progetti dall’analisi dei processi. A questo scopo strutturano le loro
raccolte di processi in appositi manuali o in knowledge base di uso interno. In questo modo è
accelerato il ciclo di analisi. Il giovane analista infatti non dovrà rilevare attraverso faticose
interviste e laboriose diagrammazioni il flusso dei processi su cui intervenire, ma, semplicemente,
userà il diagramma memorizzato sull’elaboratore e lo adatterà allo scopo. Una volta adattato, il
diagramma fornirà la base per mappare le funzionalità del sistema che informatizzerà il processo.
Tali knowledge base sono anche dette “best practice” in quanto memorizzano le migliori soluzioni.
Con l’uso le knowledge base e la best practice aumentano di volume e di qualità arrivando quindi ad
essere uno strumento prezioso. Diversamente dai reference framework le best practice sono
patrimonio privato dalle società di consulenza. Qui sotto esemplifichiamo un’architettura dei
processi gestionali IBM in India, che include sia processi di supporto (Business Administration) sia
processi primari (Product, Marketing ecc.); da notare la suddivisione dei processi sui tre livelli Plan,
Manage, Execute invece che quella classica di Pianificazione operative ed esecuzione.
Figura 19 Mappa dei processi e delle applicazioni per le operazioni IBM in India (Cherbakov 2005)
Pagina 38 di 66
Cap2-ES-v14
Figura 20 Business Map SAP per il Waste Management ( www.sap.com )
Le business map sono classificazioni commerciali di processi gestionali, in genere a livello impresa.
Esse hanno lo scopo di mostrare a quali processi i moduli della suite software sono applicabili. Si
tratta insomma di cataloghi strutturati. La mappa di Figura 20 elenca i moduli software per la
gestione dei servizi ecologici (waste management) proposti da SAP, suddivisi per classe di processi
primari e di supporto. I primi includono le gestioni Waste ed il Customer Relationship Management;
i secondi comprendono la congerie un poco eterogenea di “Business Support” ed “Enterprise
Management”.
Alcuni produttori hanno sviluppato ed offrono piattaforme per la definizione di architetture di
processi e/o knowledge base di processi a livello di impresa e/o processo e/o attività, collegate o
non con le relative soluzioni software. Fra le più note nel mondo ERP, ARIS correla progettazione
del flusso operativo del processo con strutture organizzative e sistemi di controllo (Scheer 1999).
6.2 Livelli dei processi primari
Mentre teorie e modelli dei processi direzionali propongono una classificazione per livelli, cioè
basata sulla classe di obiettivi che i processi si propongono, teorie e modelli dei processi operativi
propongono una classificazione per funzioni, che distingue i processi in base al loro contenuto. Qui
di seguito proponiamo una classificazione a livelli dei processi primari, che distingue le classi di
processi in ragione dell’obiettivo che si propongono, del tipo di output /servizio che producono e,
non ultimo, del tipo di informazioni che elaborano (Motta 2005, Motta 2001). Tali classi,
evidenziate in Figura 21, comprendono attività di:
1. Pianificazione delle operazioni,
2. Esecuzione,
3. Monitoraggio e rilevazione degli eventi,
Pagina 39 di 66
Cap2-ES-v14
4. Controllo,
5. Gestione delle informazioni.
Pianificazione
Esecuzione
Controllo
Rilevazione &
monitoraggio
Gestione delle informazioni comuni
Figura 21 Livelli dei processi primari
Ciascun livello di processo, dato il proprio caratteristico profilo, corrisponde a un diverso ruolo dei
sistemi IT. Per esempio, nella pianificazione il sistema deve elaborare un risultato ottimale, con il
vantaggio di bilanciare centinaia di vincoli e di obiettivi. Nella esecuzione, deve elaborare le
transazioni tipiche dei flussi informativi o gli eventi tipici dei flussi fisici. Nel monitoraggio, deve
rilevare eventi e/o avanzamento di un processo. Nel controllo deve attuare un circuito di feedback,
che corregge la esecuzione in ragione degli obiettivi assegnati. Nella gestione delle informazioni
deve generare e strutturare le centinaia di parametri necessari ed ad attuare i processi informatizzati.
L’incrocio fra livelli e domini individua i potenziali moduli ES. Nel settore manifatturiero, i domini
sono Approvvigionamento (Inbound Logistics), Produzione (Operations), Vendite e Distribuzione
(Outbound Logistics). Un potenziale modulo ES è quindi la Pianificazione (livello) della
Produzione (dominio).
Qui di seguito consideriamo le caratteristiche di ciascun livello. La matrice dei domini e dei livelli è
brevemente illustrata ed esemplificata sul caso della impresa manifatturiera.
6.2.1 Pianificazione delle operazioni
Pianificare significa definire azioni future. Le pianificazioni operative sono distinte a seconda del
loro orizzonte temporale e del grado di dettaglio. In generale, i piani a lungo termine sono meno
dettagliati dei piani a breve termine; in generale, il grado di dettaglio di un piano è inversamente
proporzionale al suo orizzonte temporale. La pianificazione delle operazioni è un processo rilevante
Pagina 40 di 66
Cap2-ES-v14
in tutto il settore industriale ed anche in alcuni servizi come trasporti, manutenzione degli impianti.
E’ invece irrilevante in settori di servizio che operano a sportello, come le banche, le assicurazioni e
una grandissima parte della pubblica amministrazione. Come caso paradigmatico illustriamo
brevemente la pianificazione della produzione della industria automobilistica.
La industria automobilistica è caratterizzata da un sistema di piani che da un lato collega le fasi centrali della catena del
valore (Inbound Logistics, Operations, Outbound Logistics) e dall’altro si articola su più livelli distinti per orizzonte
temporale, obiettivo, grado di dettaglio (annuale, operativo mensile, esecutivo settimanale). In sintesi:
•
•
•
Il piano annuale stabilisce i quantitativi mensili da produrre per ciascun stabilimento: in altri termini la
granularità è modello / mese / stabilimento. In generale il piano annuale viene esteso periodicamente, p.e. ogni
tre mesi è esteso tre mesi.
Il piano operativo è un livello di pianificazione più dettagliato. Esso definisce i quantitativi settimanali da
produrre per ciascun stabilimento per modello/allestimento. Anche il piano operativo, che copre i successivi 56 mesi, é esteso periodicamente.
Il piano esecutivo programma giorno per giorno gli ordini emessi dalla rete di vendita. Il dettaglio del piano
esecutivo è eguale a quello degli ordini con cui i clienti richiedono le automobili. Il piano esecutivo in genere
copre due settimane ed è esteso ogni settimana.
Come si è accennato, i piani della industria automobilistica sono collegati verticalmente ed orizzontalmente.
Verticalmente, in quanto il piano di livello inferiore opera nel perimetro tracciato dal piano di livello superiore.
Orizzontalmente, in quanto i piani di Approvvigionamento (Inbound Logistics), Produzione (Operations), Vendite e
Distribuzione (Outbound Logistics) sono interdipendenti. Una variazione dei piani di vendita porta ad una variazione
dei piani di produzione ed una variazione dei piani di produzione porta a sua volta ad una variazione dei piani di
approvvigionamento.
Riquadro 2 Processi di pianificazione: industria automobilistica
6.2.2 Esecuzione
I processi di esecuzione consistono di attività di tipo operativo. In prima e larga approssimazione
conviene distinguerne due sotto-tipi:
•
•
operazioni su oggetti fisici;
operazioni su oggetti informativi e virtuali.
Tale distinzione è fondamentale per il diverso ruolo dei sistemi IT. Nelle operazioni fisiche guidano
e/o assistono le attività, fornendo una tecnologia di coordinamento e controllo che integra la
tecnologia di produzione, e che sono invece una tecnologia di produzione nel caso delle operazioni
su oggetti informativi e virtuali.
6.2.2.1 Operazioni su oggetti virtuali e transaction processing
Le operazioni su oggetti virtuali includono la vastissima gamma delle transazioni gestionali lo scopo
primario delle quali è registrare ( p.e. scrivere un ordine) o consultare informazioni (p.e. consultare
cataloghi). Tali attività sono largamente informatizzate e i loro passi elementari coincidono con casi
d’uso, cioè con azioni compiute da persone su sistemi IT. Nelle attività esecutive il sistema IT ha il
ruolo di:
Pagina 41 di 66
Cap2-ES-v14
(a) guidare la esecuzione
(b) eseguire materialmente la attività.
Il sistema IT rappresenta cioè una tecnologia di produzione. Ciò non solo è esemplificato dalle
migliaia di operazioni in tutti i servizi finanziari e bancari, pubblici ecc. ma dalla quasi totale
scomparsa della scrittura manuali di documenti. La corrispondente forma di elaborazione è nota
come transaction processing.
Prototipo dei sistemi di elaborazione delle transazioni sono state le prenotazioni aeree. Le transazioni (=attività)
fondamentali elaborate dal sistema includono prenotazione, cancellazione, conferma. Consideriamo in particolare la
prenotazione, che richiede, come noto, di bloccare un posto su un volo. La prenotazione è un evento che è registrato
sulla base dati. Alla prenotazione segue spesso la transazione di pagamento, che richiede una serie di azioni, quali la
verifica della carta di credito, la accettazione del pagamento, addebiti e accrediti fra i sistemi della azienda della carta
di credito, i sistemi dell’agenzia e i sistemi della compagnia aerea.
I sistemi di elaborazione delle transazioni, che formano la larga maggioranza degli ES, datano da molti decenni. Già
nella protostoria informatica (anni 1950-1960), furono realizzati sistemi, allora chiamati “procedure meccanizzate”, per
semplici transazioni, come paghe e fatture. In questo caso il software si limitava, consultando poche informazioni
anagrafiche, a calcolare il cedolino delle paghe o la fattura di un acquisto. I sistemi di prenotazione, apparsi nel 1963,
segnano il passaggio dalla protostoria alla storia della informatica. A un potente (per allora) elaboratore centrale erano
collegati centinaia, poi migliaia, di terminali video, installati presso i centri di prenotazione telefonici o le agenzie di
viaggio, sui quali gli operatori registravano prenotazioni e cancellazioni. Questi sistemi sono erano anche dotati di una
base dati comune “on line”.
La stessa formula è stata utilizzata per informatizzare le transazioni bancarie ed altri servizi al pubblico, e
successivamente, dai tardi anni Sessanta, per i processi delle imprese. La architettura applicativa di questi sistemi è
rimasta largamente invariata, al punto che i sistemi di prenotazione aerea e sistemi bancari usano ancora oggi software
concepito e scritto da trenta e più anni.
Riquadro 3 Processi operativi di elaborazione delle transazioni : le prenotazioni aeree
6.2.2.2 Operazioni su oggetti fisici
Le operazioni su oggetti fisici includono una ampissima gamma di attività lo scopo delle quali sono
azioni su oggetti, come:
•
•
•
Operazioni di movimentazione di materiali
Operazioni di fabbricazione, raffinazione, miscelazione e simili tipiche del settore industriale
Operazioni di trasporto (guida di treni, aerei, automobili ecc.)
Tali operazioni sono tipiche dei processi fisici più che dei processi gestionali. Tuttavia sono qui
accennate poiché la loro automazione interagisce con la automazione delle informazioni gestionali,
come illustra l’esempio qui sotto.
Pagina 42 di 66
Cap2-ES-v14
I processi di gestione dei magazzini includono in genere due filiere di attività, dette rispettivamente gestione fisica e
gestione contabile. La gestione contabile è simile a qualunque processo di elaborazione di transazioni,. Consiste infatti
nello scrivere su un registro (memorizzato nella base dati del sistema IT) la posizione e la quantità di tutti i materiali
presenti in magazzino e le loro movimentazioni – prelievi,versamenti ecc. La gestione fisica consiste invece nelle
operazioni fisiche sui materiali, come prelevare, spostare, travasare, che sono registrate dalla gestione contabile. La
gestione contabile opera quindi su un flusso informativo mentre la gestione fisica su un flusso fisico.
Ora la gestione fisica può essere attuata da magazzinieri (persone) o macchine. Nella gestione attuata da persone, il
magazziniere regge le istruzioni elaborate dalla gestione contabile e le esegue. Nella gestione automatizzata, le
istruzione gestionali sono trasmesse al sistema che esegue le operazioni, che le esegue e fornisce le opportune
conferme. Al suo interno il sistema che automatizza il magazzino è governato da ulteriori strati software, che guidano i
movimenti fisici – p.e. il posizionamento dell’ascensore sulle scaffalature del magazzino. Le due gestioni, fisica e
contabile, sono quindi interdipendenti. La gestione contabile (detta anche “logica”) governa la gestione fisica e la
gestione fisica attua la gestione contabile.
Tale stratificazione si ritrova in innumerevoli attività operative e nei corrispondenti sistemi IT. Nella architettura CIM
(Computer Integrated Manufacturing) l’automazione è integrata con i processi gestionali di pianificazione delle
operazioni e di gestione degli ordini.
6.2.3 Tracciamento e monitoraggio
Elemento fondamentale delle operatività è “sapere a che punto si é”, “sapere dove è una data cosa”
“rilevare in che stato è”. La acquisizione., elaborazione e distribuzione di queste informazioni sono
scopo di quelle attività che vanno sotto il nome di tracciamento o monitoraggio. Esse implicano la
rilevazione periodica o continuativa dei dati di stato di un processo od oggetto ovvero la
registrazione della sua cronistoria. Queste attività, quasi infattibili se eseguite manualmente,
divengono efficaci ed economiche da opportuni sistemi IT. Elenchiamo alcuni esempi intuitivi:
•
•
•
•
Rilevazione di processo / catena di servizio: monitoraggio delle attività fiche e/o gestionali
o Ordine via internet: tracciamento della spedizione e della consegna
o Servizio al pubblico di una pubblica amministrazione : avanzamento della pratica
o Richiesta di mutuo: stato della richiesta di mutuo
o Ecc.
Assistenza sanitaria:
o Monitoraggio paziente
Monitoraggio processi fisici e macchinari:
o Rilevazione delle condizioni di impianti industriali
o Rilevazione del funzionamento e delle anomalie del veicolo via sistema di bordo
Tracciamento:
o Moda: tracciamento dei lotti di produzione via sistemi RFID
o Sicurezza: geo-posizionamento mediante tecnologie GPS
o Assistenza: geo-posizionamento delle squadre di lavoro con tecnologie GPS
6.2.4 Controllo delle operazioni
Usiamo il termine controllo in un senso stretto, cioè la serie di attività con cui é analizzato
l’avanzamento di un piano e sono individuati gli scostamenti fra risultati effettivi ed obiettivi attesi,
ed, infine, sono definite le eventuali azioni correttive, che possono includere anche la rielaborazione
del piano. Il controllo è a valle della pianificazione e a monte del monitoraggio.
Pagina 43 di 66
Cap2-ES-v14
Un esempio classico è la riallocazione dei prodotti. Consideriamo il caso di una industria siderurgica
che produce laminati. Per imprevisti scostamenti della temperatura esterna e/o della composizione
dell’acciaio, il laminato non risulta conforme al programma. Il sistema, operando in tempo reale,
ricerca un ordine che richieda un acciaio simile, cui assegnare il laminato. Il piano di produzione è
aggiornato contestualmente e l’ordine inevaso é ripianificato.
Osserviamo infine che lo schema del controllo operativo è simile al controllo di gestione, ma con
importanti differenze:
•
•
Il controllo è più frequente, p.e. giornaliero od anche in tempo reale invece che mensile
Le variabili di controllo sono fisiche e non finanziarie
6.2.5 Gestione delle informazioni
La gestione delle informazioni è un processo trasversale, difficilmente catalogabile ma
fondamentale. In quasi tutte le aziende infatti sono presenti grandi basi dati che contengono le
informazioni caratteristiche del settore (informazione di dominio) e che sono utilizzate dai principali
processi primari.
Tali grandi basi dati, che costituiscono un vero e proprio patrimonio, senza il quale l’azienda non
potrebbe operare, si riferiscono tipicamente ai prodotti e/o ai clienti e/o ai fornitori. Le attività di
gestione comprendono tipicamente il ciclo vitale delle informazioni, ovvero Creazione,
Aggiornamento / Modifica, Consultazione, Cancellazione. Citiamo alcuni esempi (Tabella 7).
Settore industriale
Agenzia Entrate
Base dati
Anagrafe fiscale
Comuni
Anagrafe
cittadini
Anagrafe
generale clienti
Distinta base
Banche
Descrizione
Contiene i dati strutturali dei
contribuenti
Contiene i dati strutturali dei
cittadini
Registra i dati strutturali dei clienti
e i loro rapporti con la banca.
Descrive la struttura dei prodotti
Aziende
automobilistiche
Aziende
Cicli di
Descrive la sequenza delle
automobilistiche
lavorazione
lavorazioni
Tabella 7 Esempi di basi dati trasversali
Utilizzi
Elaborazione delle dichiarazioni,
emissione cartelle esattoriali ecc.
Certificazione e servizi ai cittadini
Tutte le operazioni bancarie
Pianificazione della produzione ;
Calcolo dei costi dei prodotti
Pianificazione della produzione;
Calcolo dei costi delle lavorazioni
Per illustrare la complessità e la dimensione di queste basi dati, consideriamo la distinta base delle
aziende automobilistiche. La distinta descrive la gerarchia dei componenti del prodotto, dove:
•
•
•
la radice è il modello di automobile,
i nodi sono insiemi (motore)
le foglie sono componenti elementari (p.e. bulloni, pneumatici) o materiali (p.e. fondo
antiruggine).
I livelli dei nodi possono essere numerosi, oltre dieci, e le foglie migliaia . La gerarchia dei
componenti di ciascun prodotto è rappresentata nella base dati, che descrive anche gli impieghi di
ciascun componente. In altre parole, la base dati non rappresenta solo la distinta di un prodotto, ma
anche quella di tutti i prodotti della azienda, che condividono una quota maggiore o minore di
Pagina 44 di 66
Cap2-ES-v14
componenti. La rappresentazione del duplice legame di composizione (“la scocca MN è composta
del bullone XYZ e del fondo antiruggine ABC ”) e di impiego (il bullone XYZ è usato dalla scocca
MN, MO, MP e il fondo antiruggine ABC è usato dalla scocca MN, MR, NS) è il cuore della
distinta base informatizzata.
Gli ES di gestione dei dati tecnici sono di servizio sia ai sistemi di elaborazione delle transazioni sia
ai sistemi di pianificazione delle operazioni. La registrazione di un prelievo da magazzino usa i dati
anagrafici dei materiali che sono stati creati e mantenuti dalle applicazioni per la Distinta Base. La
pianificazione della produzione calcola i componenti da approvvigionare usando i dati di
composizione della distinta base.
6.2.6 La griglia dei moduli ES
Quanto detto nei precedenti paragrafi implica che i processi gestionali primari della amplissima
gamma di imprese ed enti pubblici che operano in base a piani è riconducibile a uno schema a
griglia.
Descrizione dei livelli
Livello
Sottolivello
Pianificazione
operativa
Progettazione
Domini
Approvvigionamento
Produzione
& Acquisti
Piano annuale
Piano annuale
produzione
Lungo
periodo
Piano progettazione
Breve
periodo
Piano singoli
progetti
Piano consegne fornitori
Operazioni
fisiche ed
assimilate
Produzione disegni
(tecnologie CAD) e
prototipi (tecnologie
varie)
Ricevimento materiali
Magazzini Materie
Prime
(tecnologie di
automazione dei
magazzini, sistemi di
campo, RFID ecc.)
elaborazione
transazioni
Non rilevante
Ordini ai fornitori
Ordini alla
produzione
Rilevazione e monitoraggio
---
Controllo dell’avanzamento piano
e ripianificazione
Gestione informazioni tecniche di
dominio
Controllo progetti
Tracciamento lotti
fornitura
Controllo consegne
fornitori
Anagrafe fornitori
Catalogo acquisti
Tracciamento ordini
clienti e prodotti
Controllo
produzione
Distinta base
produzione
Cicli e procedimenti
di produzione
Esecuzione
Archivio disegni e
documentazione
tecnica
Piano operativo
(mensile/
settimanale)
Lavorazioni e
controlli
(tecnologie di
automazione, robot,
sistemi di campo,
RFID ecc.)
Distribuzione
Piano annuale
vendite
Piano operativo
spedizioni (mensile/
settimanale)
Spedizioni e
trasporto
Magazzino prodotti
finiti (tecnologie di
automazione dei
magazzini, sistemi
di campo, RFID
ecc.)
Ordini dei clienti
Ordini di spedizione
e trasporto
Controllo
distribuzione
Anagrafe clienti
Catalogo prodotti
Tabella 8 livelli di processi primari: esempio
La Tabella 8 riproduce con molte semplificazioni il caso di una azienda automobilistica. Le colonne
elencano i domini funzionali fondamentali dei processi (Progettazione, Approvvigionamento,
Produzione, Distribuzione). Le righe indicano i livelli di processi. Le celle corrispondono a moduli
candidati di sistemi. Più precisamente in scuro sono evidenziati i processi gestionali cui sono
applicati gli ES, con tecnologie informatiche classiche (basi dati, elaborazione ad oggetti, ecc.). In
chiaro sono evidenziati i processi cui è applicata una ampia gamma di tecnologie di automazione. In
particolare, i sistemi di supervisione della produzione e gestione materiali interagiscono con i
Pagina 45 di 66
Cap2-ES-v14
sistemi gestionali da cui ricevono istruzioni e programmi e cui forniscono dati per il monitoraggio e
per il controllo.
Lo schema è specializzabile su altri settori industriali o di servizi. Per esempio nella gestione
alberghiera i domini includerebbero le vendite, le operazioni (erogazione dei servizi di reception,
centralino, business center, ristorante, bar ecc.), gli approvvigionamenti. In questo caso la gestione
delle transazioni (consumazioni dei clienti, prenotazioni, checkin, checkout) è ovviamente il cuore
dei sistemi ES (cfr. la voce Hotel Management Systems su www.Wikipedia.com)
7 Framework settoriali
7.1 SCOR e Supply Chain
7.1.1 Lo schema SCOR
SCOR (Supply Chain Operations Reference) è un reference framework che descrive una catena di
fornitura (supply chain) cui partecipano più aziende. Lo SCOR è sviluppato dal Supply Chain
Council, un consorzio non profit organizzato nel 1996 da Pittiglio, Rabin, Todd e McGrath (PRTM)
e da MR Research, che comprende all’inizio 69 aziende e raggiunge oggigiorno oltre mille adesioni
in tutto il mondo (Bolstorff 2007, www.supply-chain.org , www.Wikipedia.com alla voce SCOR).
Qui di seguito illustriamo lo SCOR 5.0 in quanto ancora freeware.
Prima di illustrare la struttura dello SCOR conviene definire che è una supply chain. Una supply
chain è una sequenza di stabilimenti (facility) collegati da direttrici di trasporto. Le facility possono
essere di produzione e/o di immagazzinamento. Le direttrici di trasporto possono valersi di diverse
modalità, come ferrovia, strade, aerei, navi. Una classica supply chain è l’industria automobilistica,
che include:
•
•
•
produttori di componenti, cioè pneumatici, ruote, componenti meccanici vari;
produttori di motori ed assemblatori finali, cioè le fabbriche automobilistiche per
antonomasia;
distributori e concessionari.
Il flusso dei beni e servizi all’interno della supply chain può operare secondo diverse modalità:
•
•
•
•
Make To Stock (MTS): è il caso classico di chi produce per il magazzino e vende su listino,
come avviene per gli elettrodomestici;
Assemble To Order (ATO): il cliente sceglie fra le opzioni presenti a listino ed il prodotto è
composto specificatamente per ciascun ordine; è il caso dell’industria automobilistica dove il
cliente sceglie gli allestimenti, e ciascuna vettura é assemblata per un singolo cliente;
Make to Order (MTO): il prodotto é fabbricato solo su ordinazione, come nel caso di una
sartoria che confeziona i vestiti a partire solo se ordinati dal cliente; è anche il caso degli
aerei che sono prodotti su commessa delle varie compagnie aeree; tuttavia la progettazione è
fatta una volta per tutte e il cliente compra un prodotto già progettato e definito;
Purchase to Order (PTO)/ Engineer to Order (ETO): è il caso di prodotti che sono disegnati
su specifica del cliente, come avviene nel settore cantieristico, dove le navi sono progettate e
Pagina 46 di 66
Cap2-ES-v14
realizzate su commessa, o nelle aziende di ascensori, dove gli ascensori di un grattacielo
sono progettati e prodotti di volta in volta; non solo la progettazione ma anche gli
approvvigionamenti e la scelta dei fornitori avvengono di volta in volta.
Passiamo ora a commentare lo schema su cui è articolato lo SCOR. Lo SCOR identifica cinque
domini funzionali di processo. Il primo dominio è la pianificazione (Plan) della supply chain, che
coincide in larga misura con la pianificazione operativa di cui abbiamo detto al paragrafo
precedente. I domini esecutivi comprendono
•
•
•
•
Source, che corrisponde alla logistica in entrata (inbound logistics) della value chain di
Porter;
Make: che corrisponde alle Operations della della value chain di Porter, ed include la
realizzazione di prodotti attraverso miscelazione, separazione, lavorazione meccanica,
trasformazioni chimiche;
Deliver: consegna dei prodotti finiti, che include le operazioni di preparazione, spedizione,
trasporto; corrisponde quindi alla logistica in uscita ( outbound logistics) della value chain
di Porter;
Return: resa dei materiali dal cliente della catena al fornitore: per esempio materiali resi
perché non hanno superato il collaudo o la certificazione di qualità, oppure prodotti finiti
difettosi resi dal cliente finale.
Source, make, deliver e return, in quanto processi esecutivi (execution), sono governati dal processo
di plan. Lo SCOR descrive inoltre una ampia classe di processi, detti enable, volti alla
preparazione, archiviazione, gestione delle informazioni necessarie ai processi di pianificazione ed
esecuzione. Si tratta quindi di processi analoghi alle attività di supporto della value chain di Porter,
che includono anche la gestione delle informazioni illustrata al paragrafo precedente.
Lo schema SCOR è articolato su successivi livelli di dettaglio (Figura 22):
•
•
•
•
Livello 1 (top level), che include le macro classi di processo (Plan, Source, ecc.);
Livello 2 (configuration level), che suddivide le macroclassi in tipologie;
Livello 3 (process element), che corrisponde alle fasi dei processi.
Livello 4 (implementation level), che descrive come la singola impresa svolge una data
attività del livello 3; questo livello é disegnato di volta in volta dall’analista, che dettaglia la
mappa SCOR con opportune tecniche di modellazione.
Pagina 47 di 66
Cap2-ES-v14
Schema
Livello
1
Plan
Top Level
Source
Return
Make Deliver
Return
Configuration
Level
Process
Element Level
P1.1
Identify, Prioritize, and
Aggregate Supply-Chain
Requirements
P1.3
P1.4
P1.2
Balance Production
Resources with Supply-Chain
Requirements
Establish and
Communicate
Supply-Chain Plans
Identify, Assess, and
Aggregate Supply-Chain
Requirements
4
Implementation
Level
Il livello 1 elenca le classi dei processi
PLAN
SOURCE
MAKE
DELIVER
RETURN
Il livello2 segmenta le classi a seconda del
flusso :
MTS - Make to stock
ATO - Assemble to order
MTO - Make to order
ETO - Engineer to order
2
3
Note
Il livello 3 identifica processi elementari.
Ciascun processo elementare è descritto da una
scheda termini di:
• le informazioni I/O
• le metriche di performance
• le best practice, ove possibile
• i tool di supporto
A questo livello le aziende implementano
specifiche pratiche personalizzando lo
schema SCOR
Figura 22 Livelli SCOR
Lo schema SCOR, raccolto in un manuale di centinaia di pagine, non contiene solo schemi, ma
schede che descrivono le proprietà di ciascun process element, esemplificate in Figura 23. Ogni
scheda contiene:
•
•
•
Una descrizione testuale del process element;
I criteri con cui sono misurate le prestazioni gestionali del processo dal punto di vista
dell’affidabilità (reliability), della reattività (responsiveness), della flessibilità (flexibility),
dell’efficienza (cost), delle implicazioni patrimoniali (asset);
Soluzioni (best practices) che descrivono le soluzioni paradigmatiche adottate per svolgere il
process element ovvero per informatizzarlo e che mettono in luce le particolarità che
rendono competitive le soluzioni; per esempio una pianificazione della produzione in una
supply chain è eccellente se bilancia domanda e offerta.
Pagina 48 di 66
Cap2-ES-v14
Figura 23 Scheda descrittiva di un process element SCOR
In sintesi lo SCOR è un catalogo strutturato, che fornisce alle imprese industriali una base di
partenza per descrivere la architettura dei propri processi operativi (ma non dei processi manageriali
e di supporto). Tale descrizione si posiziona ai due livelli di “azienda” e “processo” definiti al
paragrafo 1 di questo capitolo.
In Figura 24 descriviamo in modo informale il meta-modello dello SCOR; ogni livello è
rappresentato da un blocco e le frecce rappresentano le dipendenze funzionali dei livelli. Come si
nota i process element rispecchiano una doppia chiave rispettivamente data dalla modalità di
funzionamento (MTS, MTO, …) e dal tipo di processo (P, M, …).
Pagina 49 di 66
Cap2-ES-v14
Level 1
Process
Family
•
•
•
•
•
PLAN
SOURCE
MAKE
DELIVER
RETURN
Level 2
Flow
Family
1.
2.
3.
4.
MTS
ATO
MTO
ETO
Level 3
Process
Element
Scheda
Level 4
Custom
Process
Specializzazi
one /
personalizza
zione del
Livello 3
Figura 24 Metamodello SCOR
7.1.2 Mappatura dei processi con lo SCOR e definizione dei requisiti
informativi
Per completare la illustrazione SCOR riteniamo fondamentale esemplificare la applicazione dello
SCOR a un semplice caso, al fine di illustrare :
•
•
la personalizzazione dello schema standard su un caso individuale
lo sviluppo del livello 4 e dei requisiti informativi.
A questo scopo useremo come esempio il caso di una impresa che produce turbine operando in
modalità Engineer To Order (ETO).
L’analista inizia la modellazione dei processi definendo il perimetro dell’analisi al livello 1 (top
level) ed identificando clienti fornitori ed elementi della supply chain. Successivamente l’analista
scende al livello 2, e seleziona le famiglie di processi applicabili alla supply chain precedentemente
definita, come esemplificato in Figura 25.
Pagina 50 di 66
Cap2-ES-v14
S2
(Engineer
-to-Order)
M3
(MakeEngineer To-Order)
D3
(Deliver
Engineer to-Order)
Costumers
Suppliers
Plan Supply Chain
Ambito dell’analisi
Figura 25 Mappatura livello 2 per una azienda Engineer-To-Order
A questo punto l’analista identifica i processi di livello 3 applicabili al caso considerato. Per ogni
processo di livello 3 (process element level) lo schema SCOR propone un certo flusso di fasi. Il
flusso, esemplificato in Figura 26, indica, per ogni process element le relazioni con altri process
element dello stesso flusso o di altri flussi. In generale la freccia orizzontale rappresenta il flusso
fisco o la sequenza di esecuzione, mentre le frecce verticali indicano flussi informativi da o verso
altri processi.
Consideriamo brevemente la figura. Il process element M3.1 “Finalize Engineering”, che ha lo
scopo di mettere a punto il progetto di turbina richiesto dal committente, ha in input le informazioni
sugli ordini provenienti dal processo Delivery 3.1 ed ha in output una distinta dei procedimenti di
fabbricazione che alimenta la fase successiva M3.2 “Schedule Production Activities”. L’analista
personalizza lo schema aggiungendo, modificando o togliendo processi. Nel nostro caso il process
element M3.4 è stato suddiviso in M3.4.1. Foundry, M3.4.2 Mechanical Works, M3.4.3 Assembly &
test che rappresentano le fasi rispettivamente di fusione di elementi della turbina, della loro
lavorazione, del montaggio e collaudo della turbina. Infine l’analista ha aggiunto elementi in input e
in output (in corsivo) come per esempio i documenti di fabbricazione (Shop Doc).
Pagina 51 di 66
Cap2-ES-v14
M3: Make Engineer-to-Order
•
(D3.3)
Order
Information
(P3.4) Production
Plan
• (M3.3, M3.4, M3.5,
M3.6, M3.7)
Information Feedback
• (S1.1,S2.1,S3.3)
Scheduled Receipts
• (EM.5) Equipment &
Facilities Schedules
and Plans
• (S1.4,S2.4,S3.6)
Inventory
Available
• (EM.4) WIP
Handling Rules,
Move Info &
Methods
• (EM.6) WIP
Location Rules
M3.1
M3.2
M3.3
M3.4*
M3.4**
M3.4***
M3.5
Finalize
Engineering
Schedule
Production
Activities
Issue
Product
Foundry
Mechani
cal
works
Assembly
& test
Package
•
•
Methods,
Procedures,
Processes (M3.2)
• Shop Doc
• Production
Schedule
(P3.2,S1.1,
S2.1,S3.3,D3.3,
D3.7)
• Shop doc
• Shop Plans • Factory
•Factory doc
Doc
• Info Feedback (M3.2) • Shop
• Replenishment Signals
Doc
(S1.1,S2.1,S3.1)
• Sourced Product
• Location Info (EM.6)
• Shop doc
• Shop Doc
• Parts
• Factory Doc
•
•
Info Feedback
(M3.2)
Product Release
• Product
Release
•
Info
feedback
(M3.2)
Figura 26 Mappatura del livello 3 Engineer to Order : processi Make
S
2.1.1
S2.1
M3.1
D3.1
D3.2
M3.2
S2.2
M3.3
D3.3
M
3.4.1
D3.9
S2.3
M
3.4.2
M
3.4.3
D3.9
M3.5
D3.1
1
Figura 27 Schema SCOR di livello 3 personalizzato : sintesi dei flussi
L’analista continua nella descrizione e nella personalizzazione della mappa SCOR di livello 3 dei
processi Execution inseriti nel perimetro di analisi cioè Make, Delivery e Source. Uno schema
Pagina 52 di 66
Cap2-ES-v14
sintetico è in Figura 27. Le caselle più chiare indicano i processi di livello 3 introdotti dall’analista
per rispecchiare le caratteristiche individuali dell’impresa esaminata, mentre gli archi orientati
indicano il flusso fisico e/o la sequenza di esecuzione dei processi.
Per arrivare a descrivere la architettura dei processi al livello delle attività elementari ed individuare
quindi le funzionalità del sistema (casi d’uso), l’analista compie una serie di passi:
1. Scomposizione gerarchica dei processi SCOR di livello 3 sino ad individuare attività
elementari attraverso operazioni di divisione e specializzazione (vedi paragrafo 1 di questo
capitolo)
2. Descrizione dei flussi delle attività elementari
3. Individuazione dei casi d’uso e delle entità candidate
4. Descrizione dei requisiti del sistema informativo ES, che a loro volta sono descritte da:
a. Modelli di presentazione delle informazioni, che descrivono lo schema con cui le
informazioni sono presentate all’utente e la navigazione dell’utente sul sistema
b. Casi d’uso, che descrivono la logica e le funzionalità delle azioni sul sistema
(scenari, requisiti di dettaglio, eccezioni ecc.)
c. Modelli delle informazioni (classi di dati o schema entità relazione)
Qui sotto (Figura 28) esemplifichiamo il primo passo, descritto con una estensione UML proposta
da Eriksson & Penker (2000). I process element M3.1, M3.2 ecc. sono specializzati in
corrispondenti processi elementari del produttore di turbine: il process element M3.1 Finalize
Engineering (Figura 26) è specializzato nel corrispondente processo di “Ultimare la
ingegnerizzazione”, che a sua volta è scomposto in attività, che l’analista rileva sul campo mediante
interviste ed osservazioni :
•
•
•
•
•
Ricezione delle specifiche del prodotto (emesse dal cliente)
Realizzazione dei bozzetti di ingombro
Realizzazione dei disegni e della distinta base del progetto
Gestione delle modifiche in corso d’opera
Organizzazione di incontri interfunzionali (fra progettazione, commerciale e produzione)
Pagina 53 di 66
Cap2-ES-v14
Figura 28 Descrizione del livello 4 SCOR con la notazione UML proposta da Eriksson & Penker: gerarchia dei
processi ed attività elementari
Il secondo passo traccia il flusso delle attività di ciascun processo; l’analista inizia considerano le
attività elementari indicate nella gerarchia dei processi ed evidenzia la sequenza delle attività, gli
eventi in ingresso ed in uscita. Nella definizione del flusso, l’analista può espandere o cassare le
attività già individuate con la predente analisi gerarchica. Nel caso del processo M3.1 l’analista ha
cassato le attività “Ricezione delle specifiche del prodotto (emesse dal cliente)” e “Organizzazione
di incontri interfunzionali (fra progettazione, commerciale e produzione)” ed ha espanso le altre
attività, indicandogli eventi di ingresso e di uscita, con una apposita notazione.
Nel terzo passo (Figura 29) l’analista analizza il flusso delle attività elementari del processo, nel
nostro esempio M3.1 “Ultimare la ingegnerizzazione”. Il flusso descrive attività, scelta (rombi),
eventi in ingesso (frecce cave) e uscita (frecce) ed è abbinato con entità potenziali della base dati,
rappresentate da linee dette Assembly Lines (Specifiche Tecniche, Bozzetti d’ingombro, Distinta
Base, Disegno). Queste entità sono raffinate successivamente, e sono perciò dette “entità
candidate”. P.e. l'entità candidata “Distinta base” sarà successivamente raffinata nelle entità
“Anagrafe-prodotto”, “Struttura-prodotto”, “Progetto-cliente”, “Modifica”. L’analista inoltre
evidenzia la interazione fra attività elementari ed entità candidate indicando le operazioni di lettura
(bollino banco) o scrittura (bollino nero). Per esempio la attività “Realizzazione dei disegni e della
distinta base del progetto” legge le informazioni di Specifiche Tecniche e Bozzetti d’ingombro, ed
inserisce le informazioni di Distinta Base e Disegno. Infine l’analista individua i casi d’uso
candidati, evidenziati con un cerchio, che sono raggruppamenti di operazioni di lettura/scrittura
omogenee rispetto alle entità ed alle attività sono casi d’uso candidati. Per esempio la interazione fra
la attività “Realizzazione dei disegni e della distinta base del progetto” e le entità candidate
corrisponde al caso d’uso “Creazione progetto e distinta base”.
Pagina 54 di 66
Cap2-ES-v14
Il quarto passo inizia l’analisi e lo sviluppo dei requisiti informativi rispetto alle informazioni della
base dati (Modellazione Entità Relazione e/o Relazionale) alla presentazione delle interfacce (p.e.
con metodi di tipo Goal Oriented Analysis) e delle funzionalità di elaborazione (p.e. metodo dei casi
d’uso). Il terzo passo costituisce quindi lo snodo fra archiettura dei processi gestionali e architettura
funzionale degli ES.
Salva specifiche
nel sistema
Creazione progetto
e distinta base
Aggiorna
specifiche
Crea progetti e
distinte modificati
Aggiorna bozzetti
d’ingombro
Specifiche
tecniche
Bozzetti
d’ingombro
Disegno
Distinta base
Figura 29 Descrizione del flusso con individuazione dei casi d’uso candidati e delle entità candidate della base
dati del sistema
7.1.3 Mappature alternative
La mappatura esemplificata segue per il livello 4 un paradigma UML esteso. Ovviamente la
rappresentazione dei processi si può basare su altre modellazioni. Fra le più recenti e più orientate
alla SOA (Service Oriented Architecture) citiamo la notazione di Business Process Modelling, nota
come BPMN (www.bpmn.org ) standardizzata OMG come lo UML. Le differenze notazionali del
diagramma di flusso sono limitate: il BPMN adotta una notazione più ricca per la scelta (branch /
merge) e modella ritardi ed attese; tuttavia non prevede (come invece lo UML nella estensione
Erksson Penker) la individuazione di casi d’uso e di entità candidate e quindi appare meno adatta ad
assicurare un corretto passaggio dalla architettura dei processi alla architettura ES.
Pagina 55 di 66
Cap2-ES-v14
Figura 30 Notazione BPMN (da http://dret.net/lectures/services-fall06/img/bpmn-discussion.jpg )
7.2 Framework settoriali: Progettazione
Il framework DCOR, che si basa sullo stesso meta modello dello SCOR, con una decomposizione su
3 + 1 livello, è applicato al dominio della progettazione e completa quindi la visione interaziendale
dei processi industriali iniziata dallo SCOR. Uno schema generale delle fasi del DCOR è dato in
Figura 31. I porcesis di livello 1 sono quindi Research, Design, Integrate e mentre processo di
Return è rimpiazzato dal processo Amend.
Pagina 56 di 66
Cap2-ES-v14
Plan
Research
Design
Integrate
Amend
Figura 31 Schema DCOR (ridisegnato da www.supply-chain.org )
7.3 Framework settoriali : Telecomunicazioni
Il ciclo operativo delle telecomunicazioni segue uno schema ovviamente completamente diverso
dall’azienda meccanica. In termini generalissimi la filiera delle telecomunicazioni comprende la
gestione dei servizi di telecomunicazione (service provider), la gestione delle infrastrutture di rete su
cui viaggia il segnale (network provider), la gestione infine delle attività esecutive di installazione e
di lavori sulla rete, simili piuttosto alle attività di un’azienda edile più che di un’azienda di
telecomunicazioni (scavi, allacciamenti, installazioni, ecc). Tali attività vanno sotto il nome di
workforce management e sono molto spesso terziarizzate. Il ciclo operativo è piuttosto complesso in
quanto deve servire sia consumatori sia aziende ed enti e, inoltre, fornisce una gamma molto ampia
di servizi, voce, dati, entertainment ed altri. La Figura 32illustra uno schema corrispondente.
Pagina 57 di 66
Cap2-ES-v14
SVILUPPO
PRODOTTO
VENDITA
MARKETING
PRODOTTI
VENDITA
RETAIL
(FRANCHISING)
MARKETING
CLIENTI
VENDITA
RETAIL
(RETE
DIRETTA)
MARKETING
BUSINESS
VENDITA
BUSINESS
(RETE
DIRETTA)
ATTIVAZIONE SERVIZIO
FATTURAZI
ONE
DELIVERY
SERVIZI VOCE
E CORRELATI
GESTIONE
ORDINI DI
ATTIVAZIONE
DELIVERY
SERVIZI DATI
(ADSL, FIBRA)
E INTRATTEN.
DELIVERY
SERVIZI
COMPLESSI
BUSINESS
SERVIZIO
POST
VENDITA
BILLING VOCE
BILLING DATI
ASSISTENZA
TECNICA E
AMM.VA
BILLING
SERVIZI
BUSINESS
GESTIONE
RECLAMI
GESTIONE
INCASSI E
CREDITI
CLIENTI
ASSISTENZA
BUSINESS
GESTIONE RETE
PIANIFICAZIONE RETE
PROGETTAZIONE RETE
ESERCIZIO E MANUTENZIONE
GESTIONE CAMPO (Work Force Management)
PIANIFICAZIONE
SQUADRE
ESECUZIONE
LAVORI
• Gestione richieste
• Interventi programmati
• Interventi su chiamata
GESTIONE RICAMBI
E MATERIALI
GESTIONE
DOCUMENTAZIONE
TECNICA
Figura 32 Mappa dei processi di una azienda telefonica
Il consorzio TM Forum ha pubblicato una mappa operativa delle operazioni di telecomunicazione
chiamata appunto eTOM (enhanced telecom operations map), affine allo SCOR, ma nettamente più
orientata all’informatica piuttosto che ai processi gestionali. La mappa eTOM è illustrata in Figura
33.
Pagina 58 di 66
Cap2-ES-v14
Figura 33 Mappa eTOM (da www.wikipedia.com alla voce Enhanced Telecom Operations Map)
7.4 Framework settoriali : Energia e utilità
L’articolazione del settore energia è largamente determinata dalla struttura della filiera energetica,
articolata sulle ben note fasi di produzione/approvvigionamento, trasporto, distribuzione, vendita
sostanzialmente comuni al settore del gas e a quello dell’energia elettrica. I processi più complessi
sono ovviamente quelli di distribuzione e di vendita. Uno schema, ovviamente esemplificativo, dei
processi di vendita è dato in figura 33. il processo comprende varie fasi che vanno dalla
pianificazione delle azioni di vendita dei “prodotti” (= modalità di offerta al pubblico) alla
negoziazione dei contratti alla fatturazione e alla postvendita. La normativa europea infatti impone
la separazione societaria fra distributore e venditore. Il ciclo operativo del distributore ha alcuni
punti in comune con quello delle società telefoniche in quanto il distributore pianifica, costruisce,
risarcisce una rete di distribuzione. Diversamente dalle società telefoniche i clienti del distributore
sono tipicamente aziende di vendita e non consumatori.
7.5 Framework settoriali : Grande distribuzione organizzata
La grande distribuzione organizzata (GDO) è un sistema formato da una direzione centrale di
acquisto e da un sistema logistico che include un certo numero di punti di smistamento e un numero
piuttosto elevato di punti di vendita (POS). In termini informali, la direzione acquisti svolge tutto il
ciclo di pianificazione strategica della offerta (che cosa vendere, su quale catena, in quale regione),
la scelta dei fornitori, la definizione dei contratti ecc. A loro volta i punti di vendita svolgono le
consuete operazioni di rifornimento degli scaffali (attraverso un software apposito), di preparazione
della merce e di cassa. Infine i punti di smistamento concentrano a livello regionale le spedizioni dei
fornitori e li smistano nei punti di vendita in ragione delle istruzioni ricevute. Come si nota
l’architettura dei processi è estremamente semplice e si presta a grandi, grandissimi volumi.
Il caso Wal-Mart è emblematico. Con 1,6 milioni di dipendenti è la più grande azienda del mondo.
Grande parte del successo di Wal-Mart si basa appunto su un disegno di processi estremamente
efficiente e su una strategia di acquisto mirata a scarnificare i costi ed i prezzi, e ad eliminare non sia
assolutamente indispensabile all’acquisto di un articolo, come arredi, layout razionale, ecc. In
generale proprio per la scalabilità dei processi la grande distribuzione sta eliminando gradualmente i
piccoli negozi di rivendita al dettaglio.
Lo schema dei sistemi di distribuzione replica piuttosto da vicino l’architettura dei processi che
abbiamo illustrato. I sistemi di punto di vendita (POS) registrano le transazioni di acquisto da parte
dei consumatori e in generale le movimentazioni delle merci nei punti vendita. I sistemi di
marketing fidelizzano i clienti attraverso la carta fedeltà e i corrispondenti concorsi a premi. I
sistemi di acquisto, non molto distanti di quelli di un’azienda industriale, correlano prodotti
(“referenze”) e fornitori, mentre la pianificazione operativa si basa fortemente sul sistema delle
campagne di promozione e vendita. Un sistema con un numero così elevato di punti di vendita e di
articoli richiede a sua volta un processo di analisi (business intelligence) sofisticato, che permetta di
incrociare le curve di preferenza della clientela con le vendite degli articoli ecc.
7.6 Framework settoriali : Banche
I processi elementari delle banche sono numerosissimi in quanto a ciascuno delle centinaia e a volte
migliaia di prodotti corrisponde un distinto processo. I processi gestionali delle banche possono
essere classificati in alcune grandi filiere che rispecchiano I domini di business delle banche stesse:
Pagina 59 di 66
Cap2-ES-v14
•
•
•
•
Servizi al consumatore, rivolti ai privati e alla piccola e media impresa, che comprendono
tutte le transazioni attive e passive: conti correnti, mutui, servizi di domiciliazione delle
bollette, carte di credito, prestiti personali ed altri;
Servizi alle aziende, che includono crediti commerciali, gestione dei fidi commerciali,
gestione stipendi e servizi simili;
Servizi alla clientela privata, che includono la gestione degli investimenti e dei patrimoni
della clientela abbiente, con patrimonio superiore a 1-5 milioni di euro;
Servizi di consulenza per fusioni e acquisizioni.
Questi processi verso la clientela possono essere anche lunghi e complessi ed includere molte fasi
decisionali. A titolo di esempio riportiamo qui sotto il flusso di un mutuo.
Come si nota il processo comprende una fase di informazione, una di negoziazione, una di
approvazione, una di accettazione, una di erogazione, e può durare parecchi giorni. questi processi
di finanziamento sono paradigmatici dei cosiddetti iter burocratici che, letteralmente, si
tradurrebbero in italiano in “viaggi attraverso gli uffici”. In essi una domanda (= richiesta del
cliente) passa da un ufficio all’altro e viene integrata da contributi esterni. Nel caso del mutuo il
contributo esterno è dato dal notaio. L’architettura operativa di questi processi e la loro
informatizzazione è fondamentale per la loro prestazione.
Altri processi della banca sono invece estremamente ingegnerizzati e talmente rapidi da ridursi a una
transazione, tipico l’esempio dell’anticipo contante via bancomat. In esso il collegamento fra
molteplici attori, cioè la banca che eroga il contante, la banca del cliente titolare del conto e la SIA
che fornisce il sistema informatico del servizio, è automatico, codificato, universale e
ragionevolmente sicuro. Rispetto all’architettura dei processi, l’architettura dei sistemi bancari è
quasi ortogonale. Semplificando molto essa è composta da tre strati fondamentali, rispettivamente
costituiti dai canali di front-end verso la clientela (canale web, canale telefonico, filiali), dallo strato
di erogazione dei servizi (depositi, conti correnti, altri), e dallo strato di gestione dei dati su clienti e
prodotti, marketing e analisi dei clienti (CRM analitico).
7.7 Framework settoriali : Pubblica Amministrazione
I sistemi della pubblica Amministrazione sono discussi in uno specifico capitolo di questo stesso
libro. Qui ci limitiamo a delinearne le famiglie fondamentali. La Pubblica Amministrazione Centrale
e Locale opera secondo le stesse tre categorie di processo tipiche di qualunque altra impresa:
processi manageriali, processi di supporto, processi primari.
Pagina 60 di 66
Cap2-ES-v14
I processi manageriali dovrebbero essere simili a quelli delle aziende con solo alcune differenze,
anche se in effetti spesso sono incompleti e/o assenti. In molte Pubbliche Amministrazioni, per
esempio, manca completamente il ciclo di budget integrato con il controllo budgetario.
I processi di supporto, che includono contabilità, gestione del personale, ed altri, sono stati l’oggetto
prevalente della informatizzazione. Molto sorprendentemente non esiste nella Pubblica
Amministrazione italiana un manuale di riferimento analogo allo SCOR, né nell’Unione Europea. I
processi primari includono i servizi ai cittadini e alle imprese che sono oggetto caratteristico dei
cosiddetti sistemi di e-government.
Una seconda famiglia di processi primari sono i processi politici, cioè i cicli attraverso i quali gli
organi legislativi Parlamento europeo, Parlamenti nazionali, Parlamenti regionali, Assemblee
provinciali, Assemblee comunali) progettano, discutono, approvano e promulgano provvedimenti,
leggi, regolamenti che sono oggetto caratteristico dei cosiddetti sistemi di e-democracy.
La Unione Europea ha definito uno standard per i servizi per la verità molto lasco, basato sul
concetto degli “eventi della vita”. Gli “eventi della vita” sono macro categorie di fasi del ciclo vitale
dei cittadini e delle organizzazioni, per esempio “sposarsi”. A ogni evento della vita corrispondono
n servizi erogati, gratuitamente o a pagamento, da una supply chain di enti. Il relativi procedimento
(endo-procedimento) è definito dai processi che sono caratteristici della Pubblica Amministrazione.
L’alto decentramento architetturale e decisionale della Pubblica Amministrazione europea non ha ad
oggi sviluppato uno schema di riferimento sufficientemente granulare.
8 Note sullo scenario ES
L’analisi dei processi aziendali e la realizzazione degli ES costituiscono un vasto mercato che in
Italia è valutabile nell’ordine dei 10 miliardi di euro e nel mondo supera i 1.000 miliardi di euro.
Consideriamo brevemente la domanda e l’offerta di questo mercato.
8.1 Fasce di utenza
La domanda degli ES, piuttosto varia di settore in settore è classificabile secondo due assi,
rispettivamente il settore industriale e la fascia dimensionale delle aziende. Dal punto di vista
dimensionale, le aziende possono essere distinte in tre grandi fasce:
•
•
•
grandi aziende multinazionali che richiedono sistemi software operanti su più nazioni, con
più lingue e capaci di consolidare ed interfacciare più mercati e più supply chain;
piccole e medie imprese, generalmente localizzate in una nazione o comunque in un ristretto
numero di località che producono componenti o semplici prodotti;
micro imprese, come studi professionali, negozi, ecc. dove gli ES sconfinano nella
automazione d’ufficio.
Ciascuna fascia è anche dotata di diverse e decrescenti autonomie informatiche e anche di un
diverso e decrescente budget di spesa. Come si vede dalla tavola 3.5 solo le grandi imprese
multinazionali e assimilabili sono dotate di un proprio reparto informatico completo, in grado di
svolgere completamente tutto il ciclo di pianificazione, controllo ed esecuzione relativo a un sistema
ES.
Pagina 61 di 66
Cap2-ES-v14
Analogo ragionamento si applica alla Pubblica Amministrazione, dove solo la Pubblica
Amministrazione Centrale e le grandi amministrazioni locali (grandi regioni, grandi province e
comuni oltre i 500.000-1 milione di abitanti) raggiungono la soglia dimensionale dell’autonomia
informatica. Le aziende e gli enti di dimensioni minori sono quindi costrette a usare piattaforme ES
di minor costo e con modifiche minime.
8.2 La offerta di soluzione ES
La offerta di enterprise system include varie famiglie di attori. Una prima famiglia è costituita dai
produttori delle tecnologie hardware e di rete, sistemi operativi, DBMS (Data Base Management
System), software EAI (Enterprise Application Integration) ed altri simili. Una seconda famiglia è
data dai produttori di piattaforme ES, che propongono soluzioni a catalogo per le filiere ERP/SCM e
CRM. Nei produttori e nelle piattaforme ES si individuano tipicamente una serie di fasce, che
corrispondono grosso modo alla stratificazione dimensionale della clientela.
Una prima fascia è data dai produttori multinazionali, che hanno come clienti tipici proprio le
multinazionali, i cui campioni sono Oracle e SAP. Questi produttori offrono una gamma completa di
ES per molti settori industriali e sono presenti in quasi tutti i paesi sviluppati, e, in misura più
limitata,anche in Cina.
Alla fascia compresa fra le imprese multinazionali e le piccole-medie si rivolgono Microsoft e
analoghi produttori, fra i quali i produttori di soluzioni per micro settori, p.e. per l’industria del
mobile, l’abbigliamento, componentistica meccanica ed altri.
La fascia delle micro imprese è servita da operatori a base nazionale, che propongono prodotti
semplici, finalizzati ad adempimenti legali e normativi, come la gestione dei magazzini, paghe, la
contabilità, la fiscalità.
La grande parte delle piattaforme sul mercato è “proprietary”, cioè il cliente non può modificare il
codice sorgente e paga una licenza d’uso, come avviene con Microsoft Office. Limitata fortuna ha
avuto sinora l’offerta Open Source, dove invece il cliente può modificare il codice sorgente, per la
ancora scarsa diffusione di queste piattaforme.
Menzioniamo infine i produttori di software per Business Intelligence. Questi software, come già
abbiamo visto, sono comuni a più settori industriali; ciò ha favorito lo sviluppo di produttori
software indipendenti, che però dal 2000 in poi sono stati gradualmente assorbiti dai produttori di
piattaforme integrate.
La terza famiglia è data dai system integrator. I system integrator sono in larga misura grandi
aziende (10.000 dipendenti ed oltre) che offrono su scala multinazionale servizi di analisi dei
processi gestionali, di personalizzazione e realizzazione di piattaforme gestionali, di esercizio e
manutenzione di piattaforme. In questa famiglia di operatori sono confluite le emanazioni di società
di revisione (Accenture, Deloitte e simili), grandi software house che hanno gradualmente coperto
l’intero ciclo di attività legato agli ES come Cap Gemini, Engineering ed altre simili, aziende
produttrici o ex produttrici di hardware come Hewlett Packard ed IBM, che fra l’altro ha largamente
promosso la Service Science e l’analisi dei processi, ed infine le grandi software house che
realizzano software su commessa.
Pagina 62 di 66
Cap2-ES-v14
Un ultimo strato è formato da aziende, di minori dimensioni, che offrono servizi professionali sul
governo e la strategia degli ES aziendali, ma che non realizzano software. Alcune di queste aziende
sono focalizzate sulla strategia (vedi McKinsey, Booz Allen, BIP, KPMG).
8.3 Partnership
Sono stati scritti fiumi di inchiostro sulla scelta del software. In appendice a questo capitolo
proponiamo un metodo in sette passi. In larga misura la scelta considera (dovrebbe considerare) in
eguale misura la validità della soluzione e la validità del fornitore. La soluzione è valida se c’è
funzionalmente aderente (quante attività elementari sono assistite dal software considerato? In quale
misura?), se la piattaforma software applicativa è valida e se l’architettura di elaborazione e di rete è
aggiornata e flessibile. Il “sistema di fornitura” è essenziale in quanto assicura la corretta
applicazione della soluzione acquisita; sono quindi essenziali: la capacità del produttore della
piattaforma software di assistere il progetto, la capacità e l’esperienza del system integrator che
realizzerà il progetto, adattando le piattaforme ES alle specificità del processo dell’azienda, gli altri
fornitori. Le due condizioni hanno egual peso e il risultato del progetto è l’intersezione, non la
somma, di una soluzione valida e di un fornitore valido. Non necessariamente un’eccellente
soluzione implica successo se i fornitori non sono all’altezza (e viceversa). Un’attenta valutazione di
entrambe le situazioni è prerequisito per un progetto efficace. Una piattaforma software scadente
con un system integrator eccellente porterà a un sistema zoppo, viceversa una piattaforma eccellente
mal installata o mal personalizzata da un system integrator incompetente farà fallire il progetto.
Come è stato sottolineato da alcuni responsabili informatici (Motta 2005) la scelta della piattaforma
è determinante nel lungo periodo. Il costo di abbandono di una piattaforma per un’azienda è infatti
proibitivo poiché richiede il ri-addestramento di tutto il personale interno e il rifacimento delle molte
interfacce dello ES da sostituire.
9 Riferimenti
[Anthony 1965] Anthony, R.N., Planning and control systems: a framework for analysis, Boston,
Division of Research, Harvard Graduate School of Business Administration, 1965
[Blumenthal 1969] Blumenthal, S., Management Information Systems: a Framework for Analysis,
Englewood Cliffs, New Jersey, 1969
[Bolstorff 2007] Bolstorff P., Rosenbaum R., Supply Chain Excellence: A Handbook for Dramatic
Improvement Using the SCOR Model, 2nd edition, Amacom, 2007
[Capè 2005] Capè C., Motta G., Troiani F, “Chief Information Officer”, Sviluppo &
Organizzazione, n. 212, Novembre- Dicembre 2005 (riassume le tesi del libro Cape C., Motta G.,
Troiani F, Chief Information Officer, Il sole 24 ore, Milano 2005)
[Cherbakov 2005] L. Cherbakov et al.. “Impact of Service Orientation at the Business Level”. IBM
Systems Journal, Vol. 44, Number 4, 2005.
[Gorry & Scott-Morton 1971] Gorry G.A., Scott-Morton M.S., “A framework for management
information systems”, Sloan Management Review, Vol.13, n.1,1971
[Davenport 2006] Davenport Thomas H., Harris Jeanne G., Competing on Analytics The New
Science of Winning, Mc Graw Hill 2006
[Dearden 1972] Dearden J., “MIS is a mirage”, Harvard Business Review, January/February, 1972.
[Eriksson & Penker 2000] Eriksson H.E., Penker M., Business Modeling With UML: Business
Patterns at Work, Wiley , NY 200
Pagina 63 di 66
Cap2-ES-v14
[Gaj 2008] Gaj F., Germani G.U., “Dealing with Availability in an international Service
Management scenario”, in Motta G. (ed.), Service Science, Springer, Berlin, 2008
[Forrester 1959] Forrester J., Industrial Dynamics, The MIT Press, Boston,1959.
[Huselid 2005] Mark A. Huselid, Brian E. Becker, Richard W. Beatty , Workforce Scorecard:
Managing Human Capital to Execute Strategy , HBS Press Book, Cambridge, USA, 2005
[Kaplan 1991] Kaplan R. S., Norton D. P., “The Balanced Scorecard – Measures that Drive
Performance”, Harvard Business Review, n°1, January-February 1992.
[Kaplan 1993] Kaplan R. S., Norton D. P., Putting the Balanced Scorecard to Work, Harvard
Business Review, n° 5, September-October 1993.
[Kaplan 1996] Kaplan R. S., Norton D. P., “Using the Balanced Scorecard as a Strategic
Management System”, Harvard Business Review, n1., January- February 1996.
[Kaplan 2001] Kaplan R. S., Norton D. P., The Strategy-Focused Organisation. How Balanced
Scorecard companies thrive in the new business environment, Harvard Business School Press,
Boston, 2001
[Kaplan 2004] Kaplan R. S., Norton D. P., Strategy Maps: Converting Intangible Assets into
Tangible Outcomes, Harvard Business School Press, Boston 2004
[Kaplan 2008] Kaplan R. S., Norton D. P., The execution premium: linking strategy to operations
for competitive advantage, Harvard Business School Press, Boston 2008
[Lacity 1993] Lacity M.C., Hirscheim R., Information Systems Outsourcing, Johm Wilet & Sons,
New York, 1993
[Motta 1994] Motta G., “La struttura della domanda aziendale”, in Outsourcing delle tecnologie
della informazione, Etas Libri, Milano, 1994
[Motta 2001] Motta G., “xxx”, Bracchi G. , Francalanci, G., Motta G, Sistemi infornativi e imprese
in rete, McGraw-Hilll, Milano, 2001
[Motta 2002] Motta G., “ERP e trasformazione della impresa”, Mondo Digitale, n.1, 2002
[Motta 2005] Motta G., “xxx”, Bracchi G., Francalanci, G., Motta G, Sistemi infornativi e imprese
digitali, McGraw-Hilll, Milano, 2001
[Motta 2008] Motta G., Pignatelli G. , “Designing business processes for business performance: a
framework”, Business And Information (BAI), Seoul, 2008
[Nonaka 1995] Nonaka I., Takeuchi H., The Knowledge Creating Company, University Press,
Oxford 1995; tr. it. The Knowledge Creating Company, Guerini e Associati, Milano 1997.
[Norton 1996] Kaplan R.S., Norton D.P., The Balanced Scorecard: Translating Strategy into
Action, Harvard Business School Press, 1996
[Nolan 1974] Nolan R.L., Gibson C., “Managing the four stages of edp growth”, Harvard Business
Review, Vol.52, n.1(1974);
[Norton 1973] Norton D. “Information Systems Centralization: the issues”, in Mc Farlan W.F.,
Nolan R.L. ; Norton D. P. Information Systems Administration, Holt Rinehart & Winston, New
York, 1973
[Porter 1985] Porter M.E., Competitive advantage, Free Press, New York, NY 1985
[Pacioli1494] Pacioli L., Summa de arithmetica, geometria, proportioni e proporzionalità, Venezia
1494
[Scheer 1999] Scheer A.W., ARIS - Business Process Frameworks, Springer Verlag, Berlin 1999
[Simon 1958] March J.G., Simon H.A., Organizations, Wiley, 1958
[Wiig 1999] Wiig K. "Knowledge Management: An Emerging Discipline Rooted in a Long
History." in Daniele Chauvel & Charles Despres (Editors), Knowledge Management, Theseus, Paris
1999.
Pagina 64 di 66
Cap2-ES-v14
1. [Anthony 65] Anthony R.N., Planning and control systems: a framework for analysis, Harvard
Graduate School of Business Administration, Boston, Ma. 1965
2. [Archibald 76 ] Archibald R.D., Managing high technology programs and projects, John Wiley
& Sons , New York 1976, tr.it. Angeli Milano
3. [AAVV 89] The executive information systems report, Business Intelligence, London 1989
4. [Alter 80] Alter Steven C., Decision support systems, Addison-Wesley,1980
5. [Batini 92] Batini C., Ceri S., Navathe S.B. , Conceptual database design, The Benjamin
Cummings Publishing Company, 1992
6. [Benjamin 83] R.I. Benjamin, J.F. Rockart, M.S. Scott Morton, J. Wyman, Information
technology: a strategic opportunity, CISR working paper # 108, Massachusetts Institute of
Technology, Cambridge, MA, 1983
7. [Benjamin 88] R. Benjamin, D.W. De Long, M.S. Scott-Morton, The realities of electronic data
interchange: how much a competitive advantage?, Management in 1990's, Working Paper
88.042, Sloan School of Management
8. [Bemelmans 84] Bemelmans Th.M.A. (editor) Information systems development for
organizational effectiviness, North Holland, Amsterdam 1984
9. [Bower 88] J.L Bower and T.M. Hout, Fast-cycle capability for competitive power, Harvard
Business Review, November-December 1988
10. [Bowman 87] B. Bowman, G.B. Davis, J. Wetherbe, Modeling for MIS, Datamation, July 1981
11. [Bracchi 78] Bracchi G. Martella G., Pelagatti G., Sistemi per la gestione delle basi di dati,
ISEDI, Milano 1978
12. [Bracchi 78] Bracchi G., Lockemann P.C. (eds), Information systems methodologies, SpringerVerlag, Berlin 1978
13. [Bracchi 85] Bracchi G., Motta G., Sistemi informativi e imprese, Angeli, Milano 1985
14. [Brandt 83] I. Brandt, A comparative study of information systems design methodologies, in:
T.W. Olle, H.G. Sol, C.J. Tully (editors), Information systems design metodologies: a feature
analysis, North-Holland, Amsterdam 1983
15. [Briefs 83] Briefs U., Ciborra C., Schneider L. (editors), Systems design for, with, and by the
user, North Holland, Amsterdam 1983
16. [Castellani 75 e 83 ] Castellani X., Methode general d'analyse d'une application informatique,
Masson, Paris 1975, 1983 ; tr.it. Masson , Milano 1985
17. [Capozza 83] Capozza F., Esposito F., Gallo C., Strumenti grafici per il software design, Note di
Spoftware, N. 21-22, dic 1983
18. [Carlson79] W.M. Carlson, Business information analysis and integration technique, Data Base,
Vol 10, N.4, Spring 1979
19. [Ceri 81] Ceri S., La progettazione di basi di dati, CLUP, Milano 1981
20. [Ceri 86] Ceri S., Requirements collection and analysis for information systems design, in:
Kugler H.J. (ed.) 10th IFIP world computer congress, Dublin, September 1986
21. [Chen 83] Chen P. (ed.) Entity relationship approach to information modeling and analysis,
North Holland, Amsterdam 1983
22. [Chomsky 57 ] Chomsky N., Syntatic structures, Mouton & Co, The Hague-Paris, 1957
23. [Ciborra 80] Ciborra C., Bracchi G., Maggiolini P., A multiple contingency review of systems
analysis methods and models, in [Lucas 80]
24. [Ciborra 89] C. Ciborra, Tecnologie di cordinamento, Angeli Editore, Milano 1989
25. [Colter 84] Colter M.A., A comparative analysis of systems analysis techniques, MIS Quarterly,
Vol. 8, N.1, March, 1984
26. [Crockett 92] Crockett F., Revitalizing information systems, Sloan Management Review, ..., pp
39-47, 1992
Pagina 65 di 66
Cap2-ES-v14
27. [Couger 73] Couger J.D., Evolution of business systems analysis techniques, Computing
Surveys, vol. 5, N.3, September, 1973
28. [Couger 74] Couger J.D., Knapp R.W. (editors) Systems analysis techniques, John Wiley &
Sons, New York, NY, 1974
29. [Couger 82] Couger J.D., Colter M.A., Knapp R.W., Advanced system development / feasibility
techniques, John Wiley & Sons, New York, NY, 1982
30. [Date 83] Date C..J., An introduction to database systems, Addison-Wesley, Reading, 1983 e
successive edizioni
31. [Davis 82] Davis G.B., Strategies for information systems requirement determination, IBM
systems Journal, Vol. 21, N. 1, 1982
32. [de Marco79] de Marco T., Structured analysis and system specification, Prentice-Hall, New
York, NY, 1979
33. [Di Gianmarino 91] Di Gianmarino Peter, Kuckuk Mathew, The move to advanced decision
support and strategic support systems, The bankers magazine, May-June 1991, pp 11-16
34. [Dufloux 92] Dufloux Jean-Louis, Court Stéphane, Y-a-t-il un pilote dans la banque?,
Bancatique, N. 81, avril 1992, pp 210-216
35. [Ellis 79] Ellis C.A., Information control nets: a mathematical model of office information flow,
ACM conference on simulation, modeling and measurement of computer systems, 1979
36. [Episkopou 86] Episkopou D.M., Wood-Harper A.T., Toward a framework to choose the
appropriate IS approaches, The computer Journal, Vol. 29, N.3, 1986
37. [Galbraith 73] Jay Galbraith, Designing complex organizations, Addison Wesley, 1973
38. [Fitzgerald 93] Fitzgerald G., Approaches to the development of executive information systems
and the contrast with traditional systems development, in Avison D. et alii (editors), Human,
organizational and social dimensions of information systems development, IFIP Trancations,
North Holland1993
39. [Freedy 90] Freedy D., The theory and practical use of executive information systems,
International Journal of Information Management, vol 10, pp 96-104, 1990
40. [Furlan 88] La contabilità : il sistema unico adeguato alla realtà italiana, Anegeli, Milano 1988
41. [Ghezzi 91] Ghezzi Carlo et al., Ingegneria del software, Mondadori, Milano 1991
42. [Grenetier 92] Grenetier Ivan, Les EIS, Systèmes de pilotage, Bancatique, N. 81, avril 1992, pp
217-220
43. [Gorry & Scott-Morton 71] Gorry G.A., Scott-Morton M.S., A framework for management
information systems,Sloan Management Review, Vol.13, n.1,1971
44. [Hammer 90] Hammer, Michael, Don't automate, obliterate, Harvard Business Review, JulyAugust 1990
45. [Hanani 86] Hanani Michael Z., Shoval Peretz, A combined methodology for information
systems analysis and design based on ISAC and NIAM", Information Systems, Vol.11 n.3, mayjune 1986, pp.245-253
46. [Hee 89] van Hee Kees H., Houben Geert-Jan, Dietz L.G., "Modeling of discrete dynamic
systems - framework and examples", Information Systems, Vol.14 n.4, luglio-agosto 1989,
pp.277-289
47. [Honeywell 73] Honeywell Information Systems, BISAD Manual, 1973
48. [Holohan 92] Holohan James, Use of executive information systems in measuring business
performance, Journal of Information Technology, vol. 7, pp 177-186, 1992
49. [IBM 75] Business Systems Planning, IBM, GE 20-0257-1, 1975; Business systems planning:
planning for distributed information systems, IBM, GE 20-0655-1
50. [Kerner 79] Kerner D.V., Business information characterization study, Data Base, Vol. 10, N. 4,
Spring, 1979
Pagina 66 di 66
Cap2-ES-v14
51. [Jackson 83]
Jackson M.A., System development, Prentice-Hall International, Inc., 1983
52. [Johnson 87] Johnson Thomas H., Kaplan Robert S., Relevance lost. The rise and fall of
management accounting, Harvard Business School Press, Boston , Ma. , 1987 tr.it. ISEDI,
Torino 1989
53. [Juvara 92] Juvara M., Una rassegna dei metodi di analisi delle procedure, ricerca non
pubblicata, Politecnico di Milano, Milano 1992
54. [Lafitte 92] Lafitte Michel, Choix des outils EIS/DSS; les réponses du prototypage, Bancatique,
N. 81, avril 1992, pp 226-230
55. [Lorino 91] Lorino Philippe, Le controle de gestion stratégique. La gestion par les activités,
Dunod, Paris 199, tr.it. Angeli , Milano 1992
56. [Lucas 80] Lucas H.C., Land F.F., Lincoln T.J., Supper K. (editors), The information systems
environment, North Holland, Amsterdam 1980
57. [Lundberg 81] Lundberg M., Goldkuhl G., Nilsson A., Information systems development: a
systematic approach, Prentice-Hall, Englewood Cliffs, New Jersey,1981
58. [Lundberg 82] Lundberg M., The ISAC approach to specification of information systems and its
application to the organization of the IFIP conference, in Olle T.W., Sol H.G., Verrijn-Stuart
A.A. (editors), Information systems design metodologies: a comparative review, North-Holland,
Amsterdam 1982
59. [Macdonald 88] I. MacDonald, Automating the Information Engineering methology with the
Information Engineering Facility, in Olle T.W., Verrijn-Stuart A.A., Bhabuta I. (editors),
Computerized assistance during the information systems cycle, North Holland, Amsterdam 1988
60. [Madnick 90] Madnick J., Management in the 1990s, Sloan School of Management,
Massachusetts Institute of Technology
61. [Magnani 93] Magnani E., Il cruscotto della produzione: un caso reale, progetto di laurea,
Politecnico di Milano, aa 91-92
62. [Malone 87] T.W. Malone, J. Yates, R.I. Benjamin, Electronic markets and electronic
hierarchies, Communications of ACM, Vol. 30, N. 6, June 87, pp 484-497
63. [Malone 89]
Thomas W. Malone, Jo Anne Yates and Robert Benjamin, The logic of
electronic markets, Harvard Business Review, May-June 1989
64. [March & Simon 58] March J., Simon H.A., Organizations, John Wiley & Sons, 1958
65. [Marque 92] Marque Jean-Noel, Lafitte Michel, Le systemes de pilotage assisté par ordinateur:
les étapes de mise en oeuvre, Bancatique, N. 79, fevrier 1992, pp 76-81
66. [Martin 67] Martin J., Design of real-time computer systems, Prentice Hall, Englewood Cliffs,
NJ, 1967 e successive edizioni
67. [Martin 67] Martin J., Design of real-time computer systems, Prentice Hall, Englewood Cliffs,
NJ, 1967 e successive edizioni
68. [Martin 84] A. Martin, D. Weiss, Implications of electronic order exchange systems for logistic
planning and strategy, Journal of Business Logistics, vol 5, n. 1, 1984
69. [Michelin 92] Michelin Philippe, Le développement d'un système de pilotage bancaire,
70. [Motta 85] Motta G., Trattamento delle informazioni nelle imprese e sistemi informativi
aziendali: un esame di alcune teorie fondamentali, Rivista di informatica, Vol XVI, n. 3, LuglioSettembre 1985
71. [Motta 87] Motta G., (ed.) Il metodo ISAC nell'analisi e progettazione di sistemi informativi
aziendali, CLUP, Milano 1987
72. [Motta 88] Motta G., Modelling management information systems: a case in human resource
management, in Organizational decision support systems, R.M. Lee, A.M. McCosh P.
Migliarese (editors), North Holland, Amsterdam, 1988
Pagina 67 di 66
Cap2-ES-v14
73. [Motta 90] Motta G., Sistemi informativi aziendali: la analisi dei requisiti, CLUP, Milano 1990
74. [Munro 77] Munro M.C., Davis G.B., Determining management information needs: a
compareson of methods, MIS Quarterly, Vol. 1, N. 2, June, 1977
75. [Munro 82] M. Munro, B.R. Wheeler, Planning, critical success factors and management's
information requirements", MIS Quartely , n 2, 1982
76. [Nolan 71] Nolan R.L., Systems analysis for computer-based systems design, Data Base, Vo.3,
N.4, Winter, 1971
77. [Nolan 75] Nolan R.L., Data base: the future is now, Harvard Business Review, SeptemberOctober 1975
78. [Olle 82] Olle T.W., Sol H.G., Verrijn-Stuart A.A. (editors), Information systems design
metodologies: a comparative review, North-Holland, Amsterdam 1982
79. [Olle 83] Olle T.W., Sol H.G., Tully C.J. (editors), Information systems design metodologies: a
feature analysis, North-Holland, Amsterdam 1983
80. [Olle 88] Olle T.W., Verrijn-Stuart A.A., Bhabuta I. (editors), Computerized assistance during
the information systems cycle, North Holland, 1988 , pp XV-539
81. [Orr 77] Orr K., Structured systems development, Yourdon, New York, NY 1977
82. [Orr 80] Orr K., Structured requirements definition, Kenn & Orr Associates, Topeka, Kansas,
1980
83. [Palmer 82] MacDonald I.G., Palmer I.R., Systems development in a shared data environment,
in [Olle 82]
84. [Porter 85a] M.E. Porter, V.E. Millar, How information gives you competitive advantage,
Harvard Business Review, vol. 63, n. 4, pp. 149-161, 1985
85. [Porter 85b] Porter M.E., Competitive advantage, Free Press, New York, NY 1985
86. [Pernici 89a] Pernici B., Barbic F., Fugini M., Maiocchi G., Rames J.R., Rolland C., "CTODOS : an automatic tool for office system conceptual design", ACM Transactions on Office
Information Systems, October 1989
87. [Pernici 89b] Pernici B., Fugini M.G. et alii, Un approccio alla progettazione di sistemi
informativi di ufficio, Rivista di informatica, Vol. 19, n. 4, ott-dic 1989
88. [Pernici 90] Pezrnic B. , Rolland C. (Eds), Automatic Tools for Designing Office Information
Systems: the TODOS Approach, Springer Verlag AG, Berlin 1990
89. [Peterson 77] Peterson J.L., Petri nets, ACM Computer Surveys, Vol. 9, N. 3, Sept. 1977
90. [Pressman 87] Pressman, Roger S., Software engineering: a pratictioner's approach, McGraw
Hill, New York 1987
91. [Rainer 92] Rainer R. Kelly jr, Snyder Charles A., Watson Hugh J., The evolution of executive
information system software, in: Decision Support Systems, North Holland, 1992, pp 333-341
92. [Rolland 82] Rolland C., Richard C., The REMORA methodology for information systems
design and management, in [Olle 82]
93. [Roveri 92] Roveri F., Il cruscotto logistico: un caso reale, progetto di laurea, Politecnico di
Milano, aa 91-92
94. [Rockart 79] J. Rockart, Chief executive define their own data needs, Harvard Business Review,
Vol .57, N. 2, March-April, 1979
95. [Rockart 81] J. Rockart, C. Bullen, A primer on critical success factors, Center for Information
Systems Research, CISR Working Paper # 69, Massachusetts Institute of Technology,
Cambridge, Ma, 1981
96. [Rockart 87] J. Rockart, The line takes the leadership, Management in the 1990s, Working Paper
90-87.039, Sloan School of Management, Boston
97. [Ross 77] Ross D.T., Structured analysis (SA): a language for communicating ideas, IEEE
Transactions on Software Engineering, Vol. SE-3, January, pp 16-34, 1977
Pagina 68 di 66
Cap2-ES-v14
98. [Schneider 79] Schneider H.J. (ed.), Formal models and practical tools for information systems
design, North Holland, Amsterdam, 1979
99. [Schneider 82] Schneider H.J., Wasserman A.I., Automated tools for information systems
design, North Holland, Amsterdam 1882
100. [Sernandas 85] Sernandas A., Bubenko J. jr., Olivè A. (editors), Information systems:
theoretical and formal aspects, North Holland, Amsterdam 1985
101. [Schneider 79] Schneider H.J. (ed.), Formal models and practical tools for information
systems design, North Holland, Amsterdam, 1979
102. [Schneider 82] Schneider H.J., Wasserman A.I., Automated tools for information systems
design, North Holland, Amsterdam 1882
103. [Shoval 88] Shoval Peretz, "ADISSA, Architectural Design of Information Systems Based
On Structured Analysis", Information Systems, Vol.13 n.2, march-april 1988, pp.193-201
104. [Softech 78] Softech INC., An introduction to SADT, Report, Waltham, MA, 1978
105. [Spitezki 92] Spitezki Henri, Le pilotage stratégique: une organisation et des outils,
106. [Stay 76] Stay J.F., HIPO and integrated program design, IBM systems Journal, vol 15, N.2,
1976, pp. 145-154
107. [Tsichritzis 82] Tsichritzis D.C., Lochovsky F.H., Data models, Prentice-Hall, Englewood
Cliffs, NJ, 1982
108. [Teichroew 77] Teichroew D., Hershey E.A., PSL/PSA: a computer-aided technique for
structured documentation and analysis of information processing systems, IEEE Transactions
on Software Engineering, Vol. 3, N.2, 1977
109. [Venkatraman 89] Venkatraman J., Koh H., Joint ventures in the information technology
sector, Working paper n. 89.068, Management in the 1990s, Sloan School of Management,
Massachusetts Institute of Technology
110. [Yates 92] Yates Joanne, Benjamin Robert I., Information technology and change, in The
Hystory of telecommunications, Maryland University Press, in pubblicazione
111. [Warnier 76] Warnier J.D., Logical construnction of programs, Van Nostrand - Reinhold,
New York, NY, 1976
112. [Warnier 76] Warnier J.D., Logical construnction of programs, Van Nostrand - Reinhold,
New York, NY, 1976
113. [Watson 91] Watson Hugh J., Rainer R. Kelly jr., Koh Chang E., Executive information
systems : a framework for development and a survey of current practices, MIS Quarterly, march
1991, pp 13-30
114. [Warmouth 92] Warmouth M.T., Yen D., A detailed analysis of executive information
systems, International Journal of Information Management, vol 12, pp 192-208, 1992
115. [Wood-Harper 82] Wood-Harper A.T., Fitzgerald G., A taxonomy of current approaches to
systems analysis, The Computer Journal, Vol. 25, N. 1, 1985
116. [Wood-Harper 85] Wood-Harper A.T., Antill L., Avison D.E., Information systems
definition: a multiview approach, Blackwell scientific publications, Oxford, 1985
117. [Wrycza 90] Wrycza Stanislaw, The ISAC-driven transition between requirements analysis
and ER conceptual modelling", Information Systems, Vol.15 n.6, november-december 1990,
pp.603-614
118. [Zaini 92] Zaini D., Il cruscotto della area tecnica: un caso reale, progetto di laurea,
Politecnico di Milano, aa 91-92
Pagina 69 di 66

Gli enterprise systems - corsi tenuti dal prof. m. bochicchio e dalla

Transcription

Similar documents

Arch. Francesca Esposito

View

Composizione

LP - Politecnico di Torino

Projects

PORTFOLIO AIAC - Associazione Italiana di Architettura e Critica

Numero 1 - Kore Edizioni

Roll-Ring® Self Adjusting Chain Tensioner Roll

scarica il pdf - Università Iuav di Venezia

In copertina, Giorgio Milani, Eco di passi nella memoria

TAO . PDF - Ordine Architetti Torino

OPERE DI LUIGI MOTTA

Sack, Bags, Box, Dll

C1 Repertorio dei beni storico culturali