1 Introduzione
1.1 Ingegneria di processo: l’esigenza del cambiamento
La dinamicità del mercato richiede alle aziende l'adozione di strutture organizzative fles- sibili, la definizione di processi aziendali in tempi sempre più brevi e l'utilizzo di nuove modalità di comunicazione, sia all'interno che all'esterno dell'impresa, rendendo spesso necessario un progetto di re-ingegnerizzazione di processi.
Il numero sempre maggior di informazioni da immagazzinare e da gestire all'interno di un'azienda costituisce al giorno d'oggi un problema dall'impatto non irrilevante. Solo chi è in grado di sfruttare al meglio la conoscenza è in grado di competere, o almeno di sopravvivere, all'interno dell'attuale scenario.
Ogni area aziendale produce quotidianamente una quantità crescente di dati che necessi- tano di essere organizzati in modo coerente e facilmente accessibile da tutti. Al fine di migliorare la sicurezza dei dati, di ridurre i tempi di ricerca delle informazioni e di creare una struttura efficiente del flusso informativo, diventa indispensabile l'intro- duzione di nuovi Sistemi Informativi che consentano la gestione non solo del ciclo di vita dei prodotti e dei processi, ma anche delle informazioni all'interno dell'azienda e verso l'esterno. Risulta evidente per ogni azienda la necessità di possedere una meto- dologia di classificazione dei dati propria in base al contesto in cui ci si trova ed alla gestione specifica del processo a cui queste informazioni prendono parte. Pertanto voler introdurre un sistema nuovo in una realtà aziendale richiede che questo venga ripro- gettato per le specifiche esigenze di gestione delle informazioni del processo in cui si deve inserire. Operazione questa che risulta essere piuttosto laboriosa sia per la comples- sità intrinseca delle infrastrutture informatiche da implementare, sia perché solo adattan- dolo nel miglior modo possibile ai processi aziendali esso risulterà realmente efficiente.
Per questo motivo spesso l’implementazione di sistemi nuovi si accompagna ad una re-ingegnerizzazione di quei processi aziendali che risultano essere pesantemente influenzati dall'introduzione di queste nuove soluzioni. L'approccio e gli scopi seguiti
nella fase di re-ingegnerizzazione variano notevolmente con le necessità aziendali che devono essere affrontate, ed in particolare con il tipo di dati che devono essere gestiti nell'ambito dello sviluppo del prodotto.
Tutte le teorie manageriali affrontano congiuntamente al tema della re-ingegnerizzazione dei processi anche il problema dell'innovazione, identificando concettualmente i seguenti fattori chiave:
• differenziarsi dai concorrenti;
• puntare sulle discontinuità offerte dal mercato o dalle tecnologie;
• allearsi con fornitori, clienti e perfino concorrenti per innovare;
• ridurre costi e tempi;
• focalizzare le proprie risorse sui propri fattori distintivi.
Tali fattori non sono tuttavia sufficienti, infatti nelle recenti teorie manageriali si pone anche l'accento sulle risorse umane, considerate spesso come unica vera fonte di innova- zione oggi in azienda. I concetti di re-engineering si basano appunto sul fatto che oggi disponiamo di personale qualificato al quale si possono conferire responsabilità allargate, in ottica quindi di sviluppare empowerment. I concetti relativi all'innovazione sono quindi strettamente collegati al concetto di libertà che associato a personale qualificato e creativo porta a seguire strade diverse dal passato. L'esigenza di migliorare le pratiche esistenti e di condurre l'azienda ad intraprendere re-ingegnerizzazioni può perciò nascere dalla libera intuizione del singolo [8].
1.2 Metodologia e modelli per la gestione di un processo di sviluppo
Per le varie fasi di sviluppo di un sistema informativo sono state proposte innumerevoli metodologie e accanto a queste sono stati progettati ed implementati molti strumenti di supporto. Tuttavia, studi realizzati in ambienti e tempi diversi hanno messo in evidenza come l'uso di metodologie e strumenti più potenti non siano da soli garanzia di successo.
Dagli esperimenti condotti è stato dedotto che i fallimenti possono verificarsi a qualsiasi livello: a livello temporale, ovvero progetti che non vengono portati a compimento nei ter- mini previsti o con un ritardo tale da pregiudicarne la tecnologia, a livello operativo,
esigenze dell’utenza, infine a livello progettuale, ovvero sistemi informativi che non pro- ducono quei guadagni in efficienza/efficacia preventivati, con un ritorno inadeguato rispetto alla massa di risorse investite.
Numerosi sono i miti alla base di questi fallimenti e alcuni di essi si ripropongono con regolarità. Ne possiamo citare alcuni, fra quelli più diffusi ed evidenti:
• Se un progetto è ben impostato verrà portato a termine;
• Se si usano strumenti e metodologie potenti il completamento del progetto è facilitato;
• Se un Sistema Informativo è tecnicamente valido verrà usato.
Sono tutti miti riconducibili ad una radice comune, rappresentata dall'errata convinzione che l'uso di metodologie e metodi riduca la complessità dello sviluppo di sistemi, e soprat- tutto dall'errore comune di attribuire quindi agli strumenti caratteristiche di flessibilità e versatilità che non possono avere e ruoli che non possono giocare.
In particolare per quanto riguarda l'approccio Object-Oriented, benché ci siano indubbia- mente dei vantaggi e in alcuni settori esso abbia portato ad evidenti benefici economici, siamo ancora una volta davanti a un mito: "Se si usa una metodologia OO si ottengono applicazioni migliori e vantaggi economici". Per ricordare solo uno degli aspetti più fre- quentemente citati fra i vantaggi conseguibili con un approccio OO, è ormai accertato che il riuso è un obiettivo facilitato dalle tecnologie OO, ma non ne è un risultato automatico, sia a livello di codice che di modelli di analisi e progettazione; d'altronde, lo sviluppo del software è un processo, e come tale anche efficienza e efficacia economiche devono essere quantificate e valutate.
Si assiste in particolare nei confronti dell'approccio Object-Oriented a un fenomeno di esaltazione che richiama quanto era avvenuto per le metodologie strutturate. Proprio per la loro natura di fissare passi e attività da realizzare, le metodologie sono intrinsecamente limitate, e vanno usate per quello che sono: strumenti la cui versatilità e utilità deve essere verificata in relazione al problema in esame.
L'abbandono di metodologie tradizionali, che separano dati e processi, è sul piano tecnico il primo passo verso la gestione del cambiamento per i sistemi informativi; ad esso corri- sponde, sul piano aziendale, l'adozione di un approccio che superi i modelli organizzativi gerarchici. L'idea che il sistema informativo e l'organizzazione aziendale debbano essere
progettati congiuntamente è ormai accettata, e si parla anche di convergent engineering, il cui obiettivo è quello di costruire modelli che rappresentino la struttura e le operazioni di un'azienda in maniera semplice e diretta.
Un nuovo tipo di Sistema Informativo, denominato "Expressive Information System"
(Pawson et al., 1995) sta emergendo in ambito aziendale. Si tratta di sistemi progettati per favorire la creazione e personalizzazione di nuovi prodotti e servizi, aumentando il valore aggiunto al cliente. L'aspetto innovativo di questi sistemi non è legato solo alla tecnologia, ma al fatto che non si tenta di soddisfare un insieme predefinito di requisiti utente, ma piuttosto di modellare il linguaggio, in modo che sia l'utente stesso, interagendo diretta- mente col sistema, a realizzare gli strumenti che servono. Si tratta di un cambiamento di prospettiva, che porta il sistema informativo nella direzione di chi ha le competenze, tenuto conto del nuovi profili dell'utente (usa il sistema in maniera sempre più evoluta), del cliente (che riceve un servizio personalizzato), dei servizi informatici aziendali (il cui ruolo viene modificato) e dell'azienda (che deve rivedere il Sistema Informativo) [3].
In questo contesto si inserisce l'applicazione denominata Electronic Parts Catalogue (EPC).
Il servizio EPC permette ai clienti di AnsaldoBreda di avere un'applicazione Web che, attraverso l'utilizzo di pagine Web navigabili ed organizzate in una struttura ad albero, consente di ricercare, visualizzare e stampare liste parti e i corrispondenti disegni esplosi di un veicolo ferroviario secondo uno sviluppo top-down a partire dai macro-apparati fino ai componenti elementari.
L'innovazione di EPC può intendersi sia dal punto di vista tecnologico che organizzativo.
Tecnologico perché racchiude in un'unica applicazione user-friendly diverse funzionalità generalmente supportate da sistemi differenti. Dal punto di vista organizzativo perché ha sostituito il precedente flusso cartaceo, ha semplificato i processi di scambio informazioni con i fornitori e propone un supporto grafico alla scelta dei ricambi e alla didattica.
L’introduzione di EPC permette altresì di rispondere a requisiti di capitolato del cliente che in precedenza non potevano essere soddisfatti.
1.3 La riprogettazione dei processi: il re-engineering
discipline organizzative risponde al nome di Business Process Reengineering (BPR), o semplicemente re-engineering. L'idea centrale dell'approccio consiste nell'impiegare gli strumenti di ICT (Information and Communication Technology) come strumenti di ripro- gettazione dei processi aziendali, in un'ottica di innovazione oltre che di semplice miglio- ramento. La re-ingegnerizzazione dei processi è dunque l'attività volta al riesame fondamentale e alla riprogettazione talvolta anche radicale di tutti quei processi organiz- zativo gestionali in un'ottica di uso efficace ed efficiente delle risorse e di contestuale riduzione dei costi. In questo contesto il ruolo della tecnologia informatica è assoluta- mente centrale, in quanto "enabler" nella modifica dei processi aziendali.
Il BPR consiste quindi in un procedimento di innovazione organizzativa centrato sui Busi- ness Processes, dove si va a modificare "il come" un'azienda opera, e con un focus speci- fico, a differenza di altri metodi di innovazione organizzativa, sui flussi di attività.
In sintesi il BPR porta alla definizione di una configurazione gestionale, poiché imposta l'assetto organizzativo mediante leve strategiche quali flusso di attività, divisione del lavoro e competenze professionali, di tipo processivo ovvero centrata sui processi.
I principi sui quali trova fondamento il BPR sono i seguenti:
• una visione dei processi in un'ottica che ne privilegia gli aspetti intrafunzionali;
• la necessità di una riprogettazione radicale ex novo della struttura dei processi;
• l'importanza assunta dai fattori umani, culturali e organizzativi che devono accom- pagnare modifiche nella tecnologia.
Sono idee e modelli che non presentano il carattere di assoluta novità: il valore dato dall'approccio BPR sta esattamente nel come essi vengono ripresi e tra loro riorganizzati per la prima volta in una nuova sintesi, a testimonianza del fatto che quello che più è man- cato per una storia di successi nell’interazione tra informatica e scienze aziendali non siano tanto la disponibilità di strumenti e modelli, ma piuttosto strutture capaci di unire specifici paradigmi in maniera sinergica, in una corretta ed equilibrata visione comune rispetto alla natura delle problematiche affrontate.
Solitamente il BPR precede l'introduzione di nuovi sistemi informativi e servizi innova- tivi con l'obiettivo di cablare all'interno del nuovo sistema processi ottimizzati che meglio supportano la gestione. La creazione di valore per il cliente è il fattore principale per il BPR e gli strumenti di ICT svolgono spesso un ruolo abilitante molto importante. Esi-
stono diverse elaborazioni teoriche della tecnica del BPR, illustrate di seguito, tra le quali il focus è stato reso nello specifico sulla metodologia gradualista, che identifica un approccio che meglio si sposa con lo studio dei processi presi in esame nel progetto di questa tesi.
1.3.1 Il re-engineering radicale
Il concetto di "Business Process Reengineering" nasce all'inizio degli anni '90, principal- mente per impulso di Michael Hammer, un professore di informatica del MIT. In un con- testo caratterizzato da una generale critica alle tecnologie informatiche, accusate di generare esclusivamente benefici marginali, Hammer pubblica una serie di lavori, nei quali sostiene che le moderne TI sono inefficaci perché applicate a contesti aziendali inva- riati. Hammer parte quindi dalla constatazione degli scarsi risultati raggiunti dalle orga- nizzazioni che hanno applicato le tecnologie dell'informazione lasciando invariati i loro processi di lavoro.
Hammer è il primo che ha studiato il re-engineering con il famoso articolo dal titolo
"Reengineering Work: Don't Automate, Obliterate", dal quale è nata la definizione di re- engineering: "Ripensamento di fondo e ridisegno radicale dei processi aziendali finaliz- zato a realizzare straordinari miglioramenti nei parametri critici delle prestazioni quali costi, qualità, servizio, tempestività".
Questa definizione mette in luce tre caratteristiche della visione di Hammer ovvero il ripensamento di fondo delle regole per gestire le imprese, la reinvenzione totale nel modo di lavorare e non una semplice modifica, ed infine i miglioramenti straordinari ottenibili con la sola modifica dei processi.
Il BPR nasce pertanto come completo ripensamento e radicale ridisegno dei fonda- mentali processi di un'organizzazione, teso al raggiungimento di fortissimi migliora- menti nei risultati. L'accento è quindi sulla discontinuità, sul "salto" in termini di prestazioni, sulla completa assenza di vincoli nella riprogettazione. Il Business Process Reengineering, in senso proprio, è quindi un intervento che deve rispondere a queste caratteristiche.
Successivamente altri autori e altre esperienze hanno mitigato questi concetti.
affrontare i progetti di re-engineering, composta da tre macrofasi principali:
1. selezione dei processi;
2. comprensione del processo;
3. riprogettazione (o attuazione) del processo.
Il re-engineering deve essere selettivo (oltre che radicale), e deve quindi riguardare solo un sottoinsieme opportunamente selezionato di business processes. Tali processi sono individuati in base a tre parametri: cattivo funzionamento (patologie operative), impor- tanza (misurata in base all'utilità del processo per il cliente finale dell'azienda) e fattibilità (probabilità di successo dei progetti BPR, inversamente proporzionale al loro impatto organizzativo).
La comprensione del processo, intesa come analisi dei contenuti, si deve invece limitare all’individuazione degli input e degli output del processo stesso (e non focalizzarsi su un'analisi approfondita delle attività svolte, perché scopo del re-engineering non è miglio- rare, ma rivoluzionare il processo). La comprensione delle prestazioni e delle criticità del processo, invece, deve iniziare dal punto di vista del cliente, cioè del destinatario dell'output.
Per la riprogettazione dei processi Hammer propone una metodologia basata sui seguenti sei principi base, divenuti ormai la teoria fondamentale per il reengineering:
1. Organizzazione in ragione dei risultati da ottenere e non dei compiti da svolgere;
2. Ove possibile, far svolgere il processo a chi ne deve usare l'output;
3. Integrare l'elaborazione delle informazioni nel processo di raccolta stesso;
4. Trattare le risorse distribuite geograficamente come se fossero accentrate;
5. Collegare le attività parallele anziché integrarne i risultati a valle;
6. Mettere i punti decisionali dove il lavoro è effettivamente eseguito ed incorporare il controllo dentro il processo (empowerment).
Lo sviluppo del BPR coincide con una serie di pubblicazioni sull'onda del successo di Hammer. Alla sua teoria radicale, si contrappone la teoria gradualista di Davenport, in cui il BPR è finalizzato non più ad una riprogettazione totale dei processi esistenti, bensì al miglioramento della performance aziendale, da ricercarsi attraverso il miglioramento gra- duale; dalla seguente teoria nascerà la metodologia del BPI, ovvero del Business Process Improvement orientato a modifiche graduali ed in tappe successive dei processi aziendali.
Gli anni '90 vedono l'integrazione delle metodologie di BPR con altre tecniche di supporto alla riprogettazione dei processi quali il Benchmarking (metodologia sistematica per l'analisi dei prodotti, dei servizi e dei processi di quelle organizzazioni che sono ricono- sciute avere le migliori prestazioni), ed il Workflow (tecniche di analisi dei processi incen- trate sul flusso del lavoro specificatamente orientate ad automatizzare il flusso del processo.
1.3.2 La scelta dell’ingegneria metodologica
Dopo il successo avuto da Hammer sono quindi proliferati gli studi sul re-engineering a partire dalla "Teoria Gradualista" (Business Process Improvement) che si poneva l'obiet- tivo non tanto di riprogettare i processi partendo da zero, ma di razionalizzarli e miglio- rarli per passi successivi, all'Ingegneria Metodologica scaturita dagli studi di Davenport.
Thomas H. Davenport suggerisce la necessità di combinare l'approccio radicale con ini- ziative e metodi miranti al miglioramento continuo delle prestazioni, che svilupparono di lì a poco concetti oggi basilari quali il Continuos Process Improvement (CPI) ed il Total Quality Management (TQM).
Per il progetto analizzato nella seguente tesi è stata scelta come base teorica proprio la teoria avente origine dagli studi di Davenport [2].
Davenport si concentrò infatti sull'utilizzo delle tecnologie come "fattore abilitante", inte- grando l'intervento tecnologico con il cambiamento organizzativo, ed enfatizzano la necessità di gestire correttamente i progetti di cambiamento allo scopo di minimizzarne i rischi.
L'ideazione e lo sviluppo di Electronic Parts Catalogue ha avuto esattamente origine da una necessità di trasformazione e perfezionamento di un processo aziendale esistente e la sua creazione si è posta come tecnologia abilitante il miglioramento.
Uno degli approcci migliorativi di maggior successo esaminati da Davenport fu proprio quello che vide il coinvolgimento dei "clienti" all'interno dei gruppi di lavoro per la re- ingegnerizzazione. Anche per lo sviluppo di EPC è stato scelto il supporto dei clienti chiave tramite momenti di confronto e questionari, dai quali sono state evinte numerose esigenze utili da implementare come funzionalità.
In generale Davenport propone un approccio strutturato e controllato che alterna momenti di re-ingegnerizzazione radicale con fasi di controllo e miglioramento con- tinuo.
Allo stesso modo è stato mantenuto l'approccio gradualista di Davenport in questo pro- getto, alla base del quale è stata presa la decisione di non cambiare radicalmente il pro- cesso esistente, che infatti è stato semplicemente trasformato da cartaceo a informatizzato, e di migliorarlo soprattutto in ottica di efficienza, ovvero di ottimizzazione di tempi, costi e risorse.
L'ingegneria metodologica deve far conoscere le leve su cui si può operare il cambia- mento, gestire in maniera strutturata gli interventi, e definire il modo corretto di applicare gli strumenti di ICT.
La metodologia proposta da Davenport nello specifico si basa sui seguenti passi princi- pali:
• Identificazione dei processi;
• Identificazione dei drivers del cambiamento;
• Definizione delle strategie di processo (process vision);
• Comprensione e miglioramento dei processi esistenti;
• Progettazione e realizzazione progetti pilota dei nuovi processi;
• Ogni passo sarà realizzato come insieme di sotto fasi.
Davenport considera le ICT come fattori abilitanti (enablers) dell'innovazione poiché offrono le migliori opportunità del re-engineering. Nello specifico le opportunità offerte sono essenzialmente di:
• Automazione: riduzione del lavoro manuale e ottenimento economie di sostituzione;
EPC durante l’importazione popola automaticamente il Data Base a partire da una tabella prodotta secondo una specifica.
• Informatizzazione (informational): prelievo di informazioni sul processo per miglio- rarne la comprensione;
La possibilità di navigare attraverso la struttura di un veicolo e di effettuare ricerche in modo flessibile, permette di risalire alle informazioni desiderate in tempi brevi.
• Sequenzializzazione (sequential): possibilità di cambiare la sequenza delle attività del processo;
EPC è implementato sulla base delle attività pre-esistenti, tuttavia apporta all'organizza- zione notevole flessibilità avendo semplificato la maggior parte delle attività ed eliminato operazioni ridondanti.
• Tracciamento: monitoraggio continuo dello stato del processo;
EPC durante l’importazione dei dati crea un file di testo (comunemente chiamato “log”), nel quale in righe successive inserisce data e ora dell’inizio/fine di ogni operazione, numero di records importati ed eventuali errori riscontrati.
• Supporto Analitico: miglioramento della qualità delle informazioni e delle decisioni;
La qualità dei dati di EPC viene controllata subito in fase di importazione, attraverso dei parametri di “bontà” dell’operazione svolta. Sui dati importati è possibile in seguito effet- tuare una ricerca diretta e sistematica di eventuali errori residui.
• Supporto Geografico: coordinamento dei processi svolti in località separate;
EPC raccoglie dati sottoforma di liste ed immagini, che in genere provengono da fornitori diversi. Inoltre dal cliente stesso è possibile ricevere una lista parti con i propri codici, da integrare nella lista globale.
• Integrazione: coordinamento del lavoro di processi diversi in relazione alle possibi- lità dei database comuni;
La trasformazione di attività prima manuali in attività semi-automatizzate ha permesso una migliore coordinazione del lavoro tra gli enti. La creazione di un database completo e facilmente accessibile ha dato origine ad un focal point della documentazione all'interno dell'azienda, agevolando lo scambio di informazioni tra gli enti.
• Intellettuale: distribuzione dei beni intellettuali;
EPC fornisce un valido strumento di ricerca di parti e disegni, di conoscenza della strut- tura del veicolo e all’occorrenza di supporto alla didattica.
• Disintermediazione: riduzione di intermediari di un processo.
L'implementazione di EPC ha garantito una notevole riduzione di attività a non valore e delle operazioni ridondanti, in particolare tutte quelle attività di controllo dati e manuten- zione che EPC ha reso automatizzate. Questo ha snellito i processi, ridotto i tempi ed incrementato la qualità complessiva.
1.4 Critiche del metodo BPR
Il metodo del Business Process Reengineering è fortemente orientato alla tecnologia e permette un cambiamento radicale, ma richiede abilità manageriali considerevoli nelle tecniche di gestione del cambiamento. Riprogettare i processi non è semplice, in quanto crea problemi nel rapporto con la gerarchia, ridisegna i confini tra una funzione e l'altra unendo anche tra di loro figure professionali e andando a creare team eterogenei. Bisogna quindi ripensare le aziende a partire dai partner esterni e dai propri processi aziendali.
Il re-engineering ha guadagnato una cattiva reputazione perché tali progetti hanno provo- cato spesso licenziamenti voluminosi. Nonostante l'uso massiccio di pubblicità, che ha riguardato l'introduzione del Business Process Reengineering, il metodo non ha soddi- sfatto le aspettative.
Principalmente il re-engineering presuppone che il fattore che limita le performance dell'organizzazione sia l'inefficacia dei suoi processi, tuttavia ciò può non sempre essere vero e il metodo non offre mezzi per convalidare questo presupposto.
Inoltre la riprogettazione dei processi può vincolare alla necessità di iniziare il processo di miglioramento delle performance ignorando lo status quo e anche per questo il più delle volte gli vengono preferiti metodi che puntano ad un cambiamento incrementale.
In generale il paradigma della tabula rasa (o clean slate), con il conseguente annullamento degli schemi produttivo/gestionali correntemente utilizzati, appare quantomeno eccessivo e la maggior parte dei manager la ritengono una condizione fortemente limitante e la con- siderano una strada spesso poco praticabile [7].
1.5 Il concetto di Business Process (BP)
L'elemento di maggior innovazione introdotto dal BPR è il concetto di processo azien- dale, scarsamente considerato nelle teorie organizzative tradizionali. E' possibile definire il business process come tupla concettuale
BP = (A, I, O, C) dove si definiscono:
• A: attività, intese come serie di operazioni su oggetti fisici o informativi, o di deci- sioni svolte da vari attori;
• I: input, formati da materie prime e risorse aziendali;
• O: output, che può essere formato da oggetti fisici, beni immateriali o servizi;
• C: clienti, intesi come destinatari dell'output di processo.
Figura 1-1. Schema di BP
I BP non sono altro che i cicli di servizio ai clienti dove, come clienti, sono considerati anche quelli interni all'azienda. La loro classificazione si basa proprio su questo criterio e dà origine alla divisione tra Business Processes Primari e Business Processes Secondari.
I Business Processes primari sono tutti quei processi i cui clienti sono clienti esterni. In generale, il numero di processi primari di un'azienda rispecchia la gamma dei prodotti/ser- vizi offerti dall'azienda ed il numero delle categorie di clienti di tali prodotti e servizi;
I Business Processes secondari sono tutti quei processi che supportano quelli primari e che quindi hanno clienti interni all'azienda, ovvero coloro che beneficiano degli output generati dai BP di supporto a monte.
Per l'identificazione dei BP possono essere adottati vari metodi, tra i principali troviamo la Catena del Valore di Porter per l’individuazione dei modelli primari e di supporto (che corrispondo rispettivamente alle attività primarie e di supporto), e se è necessario un maggiore livello di dettaglio si può utilizzare la Standard Check List che rappresenta l'elenco dei processi normalmente svolti da un'azienda appartenente ad un certo settore di attività offrendo un valido e oggettivo supporto alla loro classificazione [1][8].
Business Process
attività input
output
clienti
Figura 1-2. Catena del Porter
Tuttavia spesso il semplice elenco dei processi non è sufficiente a descrivere il funziona- mento di un'impresa ed è pertanto necessario disaggregare opportunamente i processi stessi, "esplodendo" la struttura nei tre seguenti livelli di dettaglio:
macroprocessi: dove i clienti possono essere interni o esterni, l'output è ben definito ed ha un valore che lo rende acquistabile/vendibile sul mercato (ciò vale anche per i BP di supporto, come ad esempio la progettazione) ed infine richiedono competenze multifun- zionali (nonostante materie prime e competenze varino di caso in caso);
processi: sono ricavati dai macroprocessi secondo una duplice logica: da un lato disag- gregazione e/o scomposizione sequenziale (un processo è parte di un macroprocesso) e dall'altro specializzazione (un processo è sottotipo o variante di un macroprocesso). I pro- cessi hanno dunque come clienti macroprocessi o altri processi;
attività (o fasi) ricavate dai processi sempre con le logiche di scomposizione sono disag- gregazione/scomposizione e specializzazione. Ogni attività ha clienti processi o altre atti- vità, output ben definiti ed input che generalmente comprendono competenze mono- funzionali.
Il concetto di Business Process è stato la base dell'evolversi di tutte le teorie di riproget- tazione moderna, e ad oggi costituisce il concetto principale di uno dei metodi più diffuso a supporto del re-engineering, ovvero la Mappatura dei Processi.
1.5.1 La mappatura dei processi
Il Process Mapping è il fulcro dell'analisi delle attività e dei processi aziendali, e rappre- senta una metodologia formalizzata di identificazione degli output principali (pro- dotti, servizi, informazioni, regole, procedure, principi, norme) di una determinata impresa al fine di ricostruire i processi che li hanno generati [4].
Si tratta di scomporre un'organizzazione complessa in attività elementari facili da gestire, di definire un modello di riferimento per i processi gestionali al fine di ricostruire, attra- verso appropriate tecniche di modellizzazione, una mappa dei legami di tipo logico tra le attività lungo i processi gestionali, e l'obiettivo del processo, oltre che tutti gli elementi necessari al suo raggiungimento.
Ad oggi le tecniche e le metodologie di modellizzazione per attività e processi attualmente impiegate nelle diverse realtà aziendali sono il frutto di sviluppi compiuti in differenti aree di ricerca, quali lo studio delle operazioni produttive in ottica di organizzazione scientifica del lavoro, il controllo statistico di processo e l'analisi della Catena del Valore, per citare le principali.
L'identificazione dei Processi (metodo Top-Down e Bottom-Up) è presupposto fondamen- tale per effettuare una Mappatura dei Processi, che significa sinteticamente:
• definire l'obiettivo (scopo) del processo;
• definire gli elementi necessari all'obiettivo;
• rilevare dati ed informazioni sugli elementi definiti;
• costruire un “modello” rappresentativo;
• validare il modello.
Gli obiettivi che stanno alla base della mappatura dei processi aziendali possono essere riassunti come in tabella seguente.
Tabella 1-1. Tabella obiettivi del Process Mapping
Obiettivo Sviluppo
Comprendere ciò che real- mente viene fatto
identificare il modo in cui le risorse aziendali (umane, tecnologiche e di struttura) vengono impiegate
Esplicitare le interdipendenze far emergere le interdipendenze esistenti tra le differenti attività anche se svolte da funzioni aziendali distinte
Valutare la convenienza eco- determinare i costi delle attività connessi ai differenti corsi d'azione per
In senso ampio è possibile affermare che la costruzione di un modello delle attività e dei processi aziendali (Business Process Model) risponde a finalità molteplici: dalla revisione del sistema di contabilità direzionale, alla riprogettazione dei flussi di processo e delle relative procedure informativo-informatiche, al ridisegno dei ruoli organizzativi e delle professionalità.
Il successo della fase di mappatura è tuttavia garantito dalla presenza nell'azienda di alcuni presupposti di carattere sia organizzativo sia strategico, quali:
• la definizione della missione aziendale e degli obiettivi di medio-lungo termine;
• la programmazione degli interventi e dei relativi tempi di realizzazione;
• la scelta della metodologia da seguire;
• la formazione del gruppo di lavoro alle tecniche di mappatura dei processi;
• la raccolta e la condivisione delle informazioni esistenti.
Strettamente legate alla definizione degli obiettivi di breve e di medio-lungo termine dell'azienda e, a sua volta, del progetto, vi sono le scelte circa le risorse da dedicarvi e i tempi di svolgimento. La fase di raccolta delle informazioni sulle attività e sui processi è importante quanto il momento della loro analisi e della definizione delle azioni di miglio- ramento. Ecco perché deve esserle riservato il tempo necessario, impedendo che sullo slancio dei primi risultati si pongano in essere interventi a carattere locale, che avrebbero il solo scopo di spostare il problema in un'altra area o di ritardarne la comparsa.
Dati gli obiettivi del progetto, altri elementi concorrono alla definizione delle sue caratte- ristiche. Si tratta, in particolare, della cultura e del clima aziendale, in termini di resistenza al cambiamento e natura dello stile di direzione. Il numero e il profilo professionale delle
Effettuare una corretta attri- buzione dei costi
imputare i costi delle attività aziendali, soprattutto quelle legate a pro- cessi di natura manageriale e di supporto, agli oggetti ultimi di calcolo, quali i prodotti, i servizi, le tipologie di clienti, i canali distributivi, le aree geografiche
Budgeting di processo determinare il mix e il livello appropriati di risorse da assegnare ai diversi processi
Semplificare i processi gestionali
identificare le attività che non apportano valore alla soddisfazione del cliente, ovvero quelle attività ridondanti e non necessarie, che assor- bono risorse, aumentando i costi aziendali, senza, però, generare bene- fici significativi in termini di posizione competitiva detenuta
dall'azienda
Obiettivo Sviluppo
persone coinvolte, la strumentazione hardware e software resa disponibile nonché le fasi e le modalità di conduzione dell'analisi (la partecipazione al progetto di consulenti esterni, lo svolgimento di incontri di formazione sulle metodologie e sulle finalità dell'analisi, l'impiego di un questionario, lo svolgimento di interviste personali ai responsabili d'uffi- cio e ad alcuni loro collaboratori) possono variare da azienda a azienda appunto per le peculiarità distintive di ciascuna.
1.5.2 Modellizzazione di attività e processi
“Ogni azienda è un insieme di attività che vengono svolte per progettare, produrre, vendere, consegnare e assistere i suoi prodotti” (Porter, 1985).
In relazione a definiti assetti organizzativi e a prescelte tecnologie produttive, distributive e di elaborazione dati, abbiamo persone, materiali, attrezzature, strutture e metodologie che si combinano nello svolgimento di un'attività. Attraverso lo svolgimento delle diffe- renti operazioni che compongono un'attività, vengono trasformati input fisici e/o informa- tivi (fabbisogni, dati, e informazioni) in output significativi, di natura fisica o informativa, oppure gli input stessi subiscono un passaggio di stato o condizione [9].
È importante specificare che i confini organizzativi di un'impresa devono guidare il rico- noscimento delle attività ma non condizionarlo in modo eccessivo.
La collocazione organizzativa di un'attività nasce dal fatto che essa mostra con le altre interdipendenze di tipo reciproco, affinità tecniche e di orientamento cognitivo.
In particolare, due attività sono inter-dipendenti perché tra loro si verifica un passaggio di materiali dall'una all'altra, ma anche perché condividono le stesse fonti informative e devono elaborare e trasmettere dati di interesse reciproco, o perché operano con obiettivi ed usano competenze assai simili. Tra due attività dunque possono essere comuni gli stru- menti richiesti e identico il bagaglio di conoscenze necessarie (affinità tecniche), oppure possono essere le attitudini e gli atteggiamenti di quanti sono chiamati a svolgere quelle attività ad essere affini (affinità di orientamento cognitivo).
In senso gestionale, invece, due attività dovrebbero essere isolate e separate se soddisfano almeno una delle seguenti condizioni:
• se la determinante ultima dei costi (cost driver) della prima attività è differente da quella della seconda attività;
• se le due attività sono svolte dai concorrenti con modalità differenti;
• se ciascuna delle due attività è fonte distinta di differenziazione per l'azienda.
Tuttavia solo l'esperienza può essere d'aiuto nella definizione dei confini di un'attività, soprattutto per quanto riguarda la scomposizione, poiché se un'attività risulta indifferente a fini del rilevamento dei costi e delle performances vuol dire allora che si è arrivati al giusto livello di dettaglio, oppure se un'attività non può essere oggetto di modifica, allora vi è poca utilità a scomporla ulteriormente.
Inoltre, per sottolineare che ciascuna attività è un'azione che produce un risultato, il suo nome deve essere composto da un verbo e da un complemento oggetto.
In sintesi quindi l'attività è un insieme di operazioni e di compiti realizzati da un indivi- duo, da un gruppo o da un apparecchio meccanico, che rispondono ad un know-how spe- cifico. L'esplicitazione dei legami di tipo logico esistenti tra le diverse attività guida l'identificazione dei processi gestionali. I processi gestionali raggruppano attività che, solo insieme, permettono di ottenere un output globale significativo, quale ad esempio l'industrializzazione del nuovo prodotto, la progettazione del nuovo impianto produttivo, l'acquisto dei prodotti finiti da commercializzare. Pertanto si definisce processo gestio- nale un sistema di attività altamente inter-dipendenti da un punto di vista logico, correlate per produrre uno specifico output significativo per il raggiungimento di un determinato obiettivo e per la soddisfazione del cliente (interno o esterno all'azienda), dati gli obiettivi strategici, le norme organizzative e le caratteristiche del settore (in termini di concorrenti esistenti e potenziali, prodotti sostitutivi, clienti, fornitori, tecnologie di produzione e di distribuzione) nel quale l'azienda opera [10].
Le differenti attività di un processo gestionale sono legate tra loro dalle informazioni e dai prodotti o dai servizi che si scambiano. Uno specifico evento dà inizio alla prima attività del processo che, a sua volta, permette lo svolgimento delle successive. La natura, la siste- maticità e la frequenza delle transazioni tra le attività stabiliscono una relazione di tipo causa-effetto tra le stesse e permettono di tracciare i confini del processo che le raggruppa.
Lo svolgimento di un processo richiedere la partecipazione e l'operato sia di diverse sotto- unità appartenenti alla medesima impresa sia di entità organizzative differenti.
Alle funzioni aziendali è lasciata la ricerca delle economie di specializzazione, ai processi gestionali viene, invece, assegnato il miglioramento dell'efficacia e della tempestività di risposta nelle transazioni lungo la catena cliente-fornitore interno.
Si distinguono processi inter-organizzativi (che avvengono tra due distinte organizza- zioni aziendali), inter-funzionali (ai quali partecipano le funzioni aziendali o le unità appartenenti alla medesima impresa) ed inter-personali (che coinvolgono ristretti gruppi di persone all'interno di definite funzioni o unità organizzative) con riferimento alle entità organizzative lungo le quali si snoda il processo. Rispetto ai tipi di oggetti, ovvero a seconda che siano le informazioni (ad esempio il processo di formulazione di una propo- sta di offerta a cliente) o piuttosto gli oggetti fisici (ad esempio il processo di manuten- zione di un impianto di produzione) ad essere sottoposti a trasformazione si può procedere ad un'ulteriore classificazione.
Si distinguono, infine, processi di tipo operativo (ne sono un esempio i processi di acqui- sizione ed evasione dell'ordine da un cliente) da processi di tipo manageriale (la sequenza di attività necessarie, per esempio, alla predisposizione del budget) a seconda della tipologia di attività.
La rappresentazione di un'azienda in termini di processi gestionali fornisce una descri- zione delle attività svolte, diversa da quella organizzativa che generalmente viene espressa in termini di ruoli e responsabilità funzionali e divisionali, invariante rispetto ai cambiamenti della struttura organizzativa formale, e rappresentate le finalità strategiche perseguite. I processi gestionali traducono gli obiettivi e le criticità strategiche in sistemi di attività, metodologie e procedure ad essi coerenti.
Secondo questa vista gestionale, l'intera realtà aziendale è un insieme di processi che ne spiegano il funzionamento. Rispetto ad essi, allora, devono essere giudicate le perfor- mance dell'impresa e devono essere decisi i miglioramenti da conseguire nel medio lungo periodo.
Il sistema dei processi viene definito modello di riferimento dei processi aziendali (Busi- ness Process Model) valido per la realtà per la quale viene costruito. Tale modello com- prende l'esplicitazione dei processi di cui si compone, e delle principali relazioni che li legano, della loro missione che costituisce il punto di partenza per determinare i parametri
macro-attività che devono farne parte, le materie prime o le informazioni che sono oggetto di trasformazione lungo i processi, le risorse impiegate, i prodotti e i servizi erogati, e i fattori che ne determinano i risultati [5].
1.5.3 Tecniche e finalità della mappatura dei processi
La finalità della mappatura dei processi è principalmente quella di fornire una rappresen- tazione sintetica del business aziendale sotto il profilo gestionale, organizzativo ed ammi- nistrativo.
Quindi si propone di progettare il sistema organizzativo chiarendo responsabilità delle attività, e il sistema di controllo a livello di processo per stabilire cosa controllare e come ed infine di disegnare il sistema informatico più adeguato.
Le principali tecniche usate sono descritte sinteticamente nella tabella sottostante:
Tabella 1-2. Metodologie di Process-Mapping
La tecnica scelta per sviluppare una mappatura dei processi nella seguente tesi è la Meto- dologia IDEF, che rappresenta la tecnica ad oggi maggiormente diffusa a supporto delle attività di process mapping.
Metodo Descrizione Finalità
SERVICE SYSTEM MAPPING
identifica in relazione al cliente finale i points of contact con l'azienda durante l'intero ciclo di vita
individuare problemi di presta- zione
SYSTEM
FLOWCHARTING
Rappresentazione dinamica di problemi relativi ad attività, risorse e output
evidenziare flussi di processo e unità organizzative coinvolte CONTROL
FLOWCHARTING
individua una serie di mappe che forni- scono una rappresentazione di processo/
attività a diversi livelli di sintesi e analisi
sviluppare analiticamente pro- cessi/attività principali
METODOLOGIA IDEF-0
rappresentazione dei processi secondo un approccio top-down di scomposizione in sotto-processi e attività
individuare e analizzare vin- coli esistenti e risorse necessa- rie
MEDOTO SPARK utilizza un simulatore computerizzato in cui alle differenti attività sono collegate delle caratteristiche di performance (costo/tempi, etc)
calcolare il livello di perfor- mance medio associabile ad un certo processo
METODOLOGIA RAD Rappresentazione di ruoli, composti da atti- vità, che producono e operano su entità, e che comunicano e si coordinano tramite interazione
evidenziare le interazioni in termini di informazioni e rela- zioni di dipendenza gerarchica
Si tratta di una tecnica di mappatura sviluppata in campo ingegneristico, che prevede una rappresentazione dei processi secondo un approccio top-down di scomposizione dell'azienda in sotto-sistemi, processi, sotto-processi e attività. I processi vengono rappre- sentati ai vari livelli di aggregazione, con i relativi input, output, vincoli e risorse.
1.5.4 La tecnica IDEF-0
Negli anni '70 la USAF (United States Air Force) lanciò il programma ICAM (Integrated Computer Aided Manufacturing) con l'obiettivo di incrementare la produttività industriale attraverso l'applicazione sistematica delle tecnologie informatiche. Nell'ambito del pro- getto ICAM sono stati prodotti alcuni strumenti IDEF (ICAM Definition) quali:
• IDEF-0 per la generazione di modelli funzionali: un modello funzionale è una rap- presentazione strutturata delle funzioni, delle attività e dei processi all'interno del sistema in fase di modellizzazione;
• IDEF-1 per la generazione di modelli informativi: un modello informativo rappre- senta la struttura e la semantica delle informazioni all'interno del sistema in fase di modellizzazione;
• IDEF-2 per la generazione di modelli dinamici: un modello dinamico rappresenta il comportamento e l' evoluzione nel tempo delle caratteristiche del sistema in fase di modellizzazione.
Nel 1983 è stato prodotto IDEF-1X (IDEF-1 Extended) per la modellizzazione semantica dei dati.
Nel 1991 il NIST (National Institute of Standard and Technology) ha ricevuto l'incarico di produrre uno standard FIPS (Federal Information Processing Standards) per le tecniche di modellizzazione. IDEF-0 e IDEF-1X sono stati scelti come strumenti per la modelliz- zazione delle funzioni e delle informazioni. IDEF-0 nel particolare è una tecnica di modellizzazione basata sulla combinazione di grafici e testi presentati in modo orga- nico e sistematico. Il risultato della sua applicazione è un modello, cioè una rappresen- tazione di un insieme di componenti di un sistema, utile per supportare la comprensione, l'analisi, il miglioramento o la sostituzione del sistema. Il modello pro- dotto da IDEF-0 è costituito da una serie gerarchica di diagrammi, testo e glossari che illu- strano, con livello di dettaglio crescente, le funzioni del sistema e il loro interfacciamento [11].
Gli elementi principali dei diagrammi sono le funzioni, rappresentate mediante scatole, e i dati o gli oggetti che collegano tali funzioni, rappresentate mediante frecce. Il testo e il glossario forniscono informazioni aggiuntive utili alla comprensione dei diagrammi.
Ogni scatola rappresenta una funzione del sistema, e deve essere di forma rettangolare, deve possedere un nome o una frase che esprime un'azione, e deve essere identificata da un numero posto nell'angolo in basso a destra.
Figura 1-3. Blocco di IDEF-0
Ogni modello IDEF-0 possiede un diagramma di contesto iniziale, identificato dalla sigla
“A-0”, nel quale devono essere specificati lo scopo della modellizzazione, ciò che può essere osservato nel modello e con quale punto di vista. Questo diagramma contestuale contiene un'unica scatola, individuata dal numero “0” e rappresentante l'intera funziona- lità del modello, mentre le frecce rappresentano l'interfacciamento del sistema in analisi con l'ambiente circostante.
Lo schema grafico che proponiamo, e che utilizziamo a supporto della mappatura dei pro- cessi presi in esame da questa tesi, è caratterizzato da una serie di diagrammi correlati fra loro da una struttura gerarchica a più livelli. Nei vari diagrammi le attività dei processi sono rappresentate da figure bidimensionali ed i flussi che entrano o escono dai processi sono rappresentati da frecce.
Il significato delle frecce riportate nei diagrammi, dipende dalla posizione in cui le frecce sono riportate rispetto alla figura che rappresenta l'attività del processo; in particolare:
PROCESSO
A0 VINCOLI
RISORSE
INPUT OUTPUT
• Le frecce posizionate a sinistra del processo, rappresentano flussi di informazioni o di materiali in input al processo;
• Le frecce posizionate a destra del processo, rappresentano i flussi di materiali e di informazioni in output dal processo;
• Le frecce posizionate nella parte superiore del rettangolo rappresentano dei vincoli alla esecuzione delle attività del processo;
• Le frecce posizionate nella parte inferiore del rettangolo vengono utilizzate per indi- care gli attori del processo (funzioni organizzative o posizioni di lavoro) oppure sistemi di supporto all'esecuzione delle attività del processo.
1.5.5 Vantaggi di IDEF-0
IDEF-0 contiene un linguaggio grafico di modellizzazione e una metodologia coerente per lo sviluppo di modelli. L'utilizzo di IDEF-0 fornisce diversi vantaggi.
Consente l'analisi e la rappresentazione di tutti i livelli di un sistema, sia esso composto da uomini, macchine, materiali, calcolatori o informazioni di qualunque genere e sia esso esteso ad un'impresa, un settore produttivo o un'area particolare;
Nel nostro caso IDEF-0 ha supporto l'analisi dei processi esistenti permettendo una scom- posizione top-down mirata fino ai livelli di dettaglio attività desiderato per gestirne l'ana- lisi e la riprogettazione in ottica di miglioramento.
Un altro importante vantaggio è dato dal fatto che per sviluppare la mappatura viene incre- mentato lo scambio di informazioni tra analisti, progettisti, utenti e gestori. Questo gene- ralmente consente la condivisione degli obiettivi mediante una reale comprensione e diffusione dell'informazione, e nel nostro caso specifico ha permesso di raccogliere pre- ziose informazioni circa i nodi critici del processo esistente da correggere, oltre che la suc- cessiva diffusione e conoscenza del software EPC anche prima della sua implementazione in azienda.
Complessivamente IDEF-0 permette la gestione di progetti di grandi dimensioni e com- plessità, fornendo misure qualitative degli avanzamenti e un'architettura di riferimento per l'analisi di impresa, l'ingegnerizzazione dell'informazione e la gestione delle risorse.
1.6 L’azienda AnsaldoBreda
Le origini di AnsaldoBreda S.p.A. risiedono nella fusione tra Ansaldo Trasporti e Breda Costruzioni Ferroviarie, due aziende eredi della tradizione italiana nel settore dei trasporti
elettrificati. Entrambe derivano a loro volta dalle storiche società "Giovanni Ansaldo", costituita nel 1854 a Genova a cui si deve la prima locomotiva a vapore italiana, e "Società Italiana Ernesto Breda", fondata nel 1886 a Milano che nel 1907 consegnava già la mille- sima locomotiva della sua produzione. Forte dell'esperienza e del prestigio di entrambi i marchi, nasce quindi da questa fusione una società proprietaria di un notevole know-how e già in grado di competere nel mercato internazionale.
Ansaldobreda, costituita nel 2001, è oggi articolata negli stabilimenti di Napoli, Pistoia, Reggio Calabria e Palermo; ha divisioni operative all'estero e conta circa 2400 dipendenti.
La fusione ha permesso l'integrazione della competenza meccanica con quella elettrica, rendendo AnsaldoBreda capace di progettare e costruire in autonomia il sistema veicolo completo: progettazione e costruzione di parti meccaniche come cassa e carrello, proget- tazione e costruzione di equipaggiamenti elettrici di trazione e ausiliari, attività di service, nonché concezione sistemistica del veicolo completo.
1.6.1 Mercato di riferimento: prodotti e clienti
Realizzare veicoli per il trasporto pubblico di massa, ha rappresentato e rappresenta tut- tora l'area di maggiore interesse per l'impresa, basti pensare alla Piattaforma Tram Sirio, che costituì una vera e propria rivoluzione nel settore.
Si tratta di un "tram su misura" altamente innovativo, in grado di consentire notevoli eco- nomie su più livelli: azienda, committente, mercato in generale. Sirio è una realtà già pre- sente in parecchie città italiane, e anche in numerose città straniere. Per quanto riguarda il mercato italiano è attualmente in corso di completamento anche la fornitura di Treni per il Servizio Regionale per le Ferrovie Nord di Milano, la nuova piattaforma dedicata alle linee ad alta frequentazione, e la Circumvesuviana, un elettrotreno metropolitano di ultima generazione, per styling, meccanica ed elettronica.
Oltre allo scenario nazionale, l'azienda è impegnata ad affrontare le ancor più difficili sfide del mercato internazionale e la sua presenza ormai trentennale negli Stati Uniti ne rappresenta sicuramente una testimonianza. Nello specifico, i tram per Cleveland, San Francisco e Boston, i treni metropolitani per Atlanta, Washington ed infine Los Angeles, per cui l'azienda ha realizzato anche la metropolitana leggera. Questo dimostra la capacità
di adattare con precisione il veicolo alle diverse esigenze dei committenti contestualmente al contenimento dei tempi di progettazione, sviluppo, produzione e consegna.
L'obiettivo dell'AnsaldoBreda è dunque duplice: da una parte consolidare i mercati in cui è già presente e dall'altra aprirsi alle nuove opportunità di confronto. Da qui il profondo interesse per il Nord Europa e in particolare per Norvegia, Svezia, nonché Danimarca, per la quale AnsaldoBreda ha realizzato la Metropolitana Automatica di Copenhagen e i treni Diesel Multiple Unit IC4 per il servizio intercity.
Importante anche la presenza in Spagna: le due linee della metropolitana di Madrid sono un indiscutibile successo dell'azienda, la quale ha dimostrato la propria capacità di realiz- zare gli elevati standard qualitativi richiesti dal sistema del committente, aggiudicandosi anche un contratto di Global Service della durata di 17 anni, per la manutenzione integrale dei veicoli della serie 9000 forniti.
Infine il successo dei tram consegnati ad Atene ed in servizio durante le ultime Olimpiadi, la recente acquisizione del contratto per la Metropolitana di Salonicco di tipo driverless, nonché quella dei treni a due piani in Marocco, sottolineano la volontà dell'impresa di aprirsi a tutto il Mediterraneo, pur con la consapevolezza di confrontarsi con mercati molto diversi tra loro e da quello nazionale, con lo scopo di rendere sempre più completa l'offerta sul mercato [12].
1.6.2 Struttura ed organizzazione aziendale
La Società AnsaldoBreda S.p.A. è organizzata secondo l’organigramma di primo livello mostrato in Figura 1-4. All’Amministratore Delegato/Direttore Generale riportano:
• le Unità di Business:
- Alta Velocità e Main Line (AVM);
- Mass Transit (MTS);
- Sirio (SIR);
- Service (SER);
• la Direzione Operativa;
• le funzioni:
- Chief Financial Officer (CFO);
- Risorse Umane e Organizzazione (RUO);
- Legale e Societario (LEG);
- Assicurazione Qualità (AQU);
- Marketing e Commerciale (COM);
- Piano di Competitività Industriale (PCI);
- Pianificazione Strategica (PSR);
- Risk Management (RKM).
Figura 1-4. Organigramma di primo livello
Alla Direzione Operativa (DOP) riportano i seguenti siti di funzione:
• Progettazione (DOP/PRG);
• Produzione (DOP/PRD);
• Approvigionamenti (DOP/APP);
• Sistemi Informativi (DOP/SIN);
• Infrastrutture, Impianti, Sicurezza ed Ambiente (DOP/ISA).
Amministratore Delegato/Direttore
Generale Presidente
Internal Auditing
Assicurazione Qualità
Risk Management
Direzione Operativa
Approvvigionamenti Unità di Business
Mass Transit
Unità di Business Sirio
Unità di Business Service
Infrastrutture, Impianti, Sicurezza e
Ambiente Relazioni Esterne Legale e Societario
Risorse Umane e Organizzazione Chief Financial
Officer
Sistemi Informativi Pianificazione
Strategica
Produzione Marketing e
Commerciale
Unità di Business Alta Velocità e Main Line
Piano di Competitività
Industriale
Progettazione
Figura 1-5. Organigramma di secondo livello della funzione Progettazione
Nell’ambito della funzione Progettazione vengono definiti i seguenti incarichi:
• Ricerca & Innovazione (PRG/RIC);
- Gestione Finanziamenti (RIC/GFI);
• Servizi Tecnici (PRG/STE);
- Pianificazione (STE/PIA);
- Documentazione (STE/DOC);
- Normalizzazione (STE/NOR);
- Sistemi Informativi di Progettazione (STE/SIF);
• Design Assurance (PRG/DAS);
- Safety (DAS/SAF);
• Progettazione Meccanica (PRG/MEC);
- Strutture (MEC/STU);
- Carrelli (MEC/CAR);
- Calcoli (MEC/CAL);
- Dinamica di Marcia (MEC/DIN);
- Laboratorio Strutture (MEC/LST);
• Progettazione Elettrica/Elettronica (PRG/ELE);
- Progettazione Sistemi di Propulsione (ELE/PPL);
- Progettazione Elettrica Veicolo (ELE/PEV);
- Train Control (ELE/TRC);
- Sistemi Diagnostici (ELE/SID);
Progettazione
Progettazione
Elettrica/Elettronica Sperimentazione
Servizi Tecnici
Materiali &
Tecnologie Ricerca &
Innovazione
Progettazione Veicolo Ingegneria di
Sistema UdB
Progettazione Meccanica
Design Assurance
- Progettazione Main Line (VEC/MLP);
- Progettazione Mass Transit (VEC/MTP);
- Progettazione MLA (VEC/MAP);
- Progettazione Sirio (VEC/SIP);
- Impianti di Bordo (VEC/IMB);
- Stile (VEC/STL);
• Sperimentazione (PRG/SPE);
- Veicoli Pistoia (SPE/VPT);
- Veicoli Napoli (SPE/VNA);
- Sala Prove e Laboratori (SPE/SPL);
• Materiali & Tecnologie (PRG/MAT);
- Ambiente e Sicurezza (MAT/AMS);
- Antincendio (MAT/ATN);
- Materiali (MAT/MRL);
- Camera Climatica (MAT/CLI).
1.6.3 Servizi Tecnici (PRG/STE)
Il dipartimento dei Servizi Tecnici è responsabile, nel rispetto degli standard e delle pro- cedure del Sistema di Qualità aziendale, della ottimizzazione dei processi di progetta- zione, ovvero della definizione e attivazione dei metodi, degli strumenti, delle norme e degli standard operativi.
Assicura la definizione e la standardizzazione delle applicazioni ICT (Information Com- munication Technology) in ambito di progettazione di concerto con l'ente Sistemi Infor- mativi, la normalizzazione dei prodotti e l'elaborazione delle pubblicazioni tecniche.
Le principali attività e responsabilità sono di seguito espresse sinteticamente:
• assicurare, nel rispetto degli standard e delle procedure del Sistema di Qualità azien- dale ed in coerenza con la pianificazione delle commesse, la programmazione della funzione in un'ottica di ottimizzazione delle risorse;
• assicurare l'elaborazione e l'aggiornamento dei preventivi operativi relativi ai costi di commessa, ai costi controllabili e agli investimenti di pertinenza della funzione e dei progetti di ricerca e sviluppo, acquisendo i contributi dai singoli enti di progettazione;
