SAP, Visio e ViFlow: il Process Mapping come enabler del Change Management. Il caso MTU France.

F

ACOLTÀ DI

I

NGEGNERIA

R

ELAZIONE PER IL CONSEGUIMENTO DELLA LAUREA SPECIALISTICA IN

I

NGEGNERIA GESTIONALE

“Visio, ViFlow e SAP: il process Mapping come enabler

per il Change Management. Il caso MTU France”

RELATORI IL CANDIDATO

_________________________ ___________________

Ing. Riccardo Dulmin

Filippo Lubrano

Dipartimento di Sistemi Elettrici

ed Automazione

__________________

Dott.ssa Frédérique Loutte

MTU France

“Il 65% degli amministratori delegati preannuncia un drastico cambiamento nella propria organizzazione nei prossimi due anni. C’è un’ansietà di fondo, ma si sente soprattutto la forza del cambiamento. Il cambiamento come motore della

competitività”

Marc Chapman, capo della divisione Strategy&Change di Ibm (dati da un survey IBM che ha coinvolto 750 top manager in tutto il mondo) Da questa ansietà di fondo, nasce questo lavoro di tesi sul Change Management.

Abstract

Col presente elaborato, il candidato presenta il risultato di oltre tre mesi di lavoro presso la società MTU France, divisi in maniera temporalmente iniqua tra le sedi di Beauchamp (Paris) e Mandelieu-La-Napoule (Cannes).

Lo schema strutturale dell’elaborato segue logicamente e cronologicamente il lavoro operativo. Si inizia pertanto con una fase indispensabile di mappatura dei processi, che fa in qualche modo da “abilitatore” alle fasi successive (da cui il titolo del lavoro). Qui, attraverso una serie di interviste mirate, il candidato ha proposto una nuova vista della realtà aziendale – da funzioni a processi – e realizzato così una dettagliata Process Map che coprisse tutte le attività svolte in seno all’azienda. Questa fase ha costituito inoltre di fatto il primo passo per una SWOT Analysis, strumento gestionale ancora mai utilizzato in azienda prima d’ora.

Il Process Mapping ha rappresentato in sostanza il sostrato che ha reso possibile, oltre che il change management, anche un’analisi della catena del valore del Porter (una delle due anime della SWOT Analysis, appunto: quella interna) che altrimenti non avrebbe avuto altro basamento su cui poggiare.

Il vero task del periodo in azienda era però la gestione del cambiamento. Un change management rivelatosi per contro in realtà del tutto atipico, in quanto di fatto i cambiamenti, al momento dell’arrivo del candidato in azienda, erano già avvenuti. Cambiamenti significativi, che intaccavano sia il lato tecnologico, con l’introduzione del sistema ERP SAP R/3 appena effettuata, che quello gestionale, con un consistente aumento dell’headcount che ha portato ad un aumento del 40% del numero di dipendenti in azienda.

Il change management “ex post” ha costituito dunque la seconda sfida del lavoro, dovendo gestire sia il piano individuale che quello organizzativo. Abilitato dal Process Mapping, il change management stesso è risultato a sua volta enabler di un’attività che potremmo assimilare ad una sorta di pianificazione del miglioramento: le informazioni raccolte durante le interviste “a tappeto” effettuate in azienda dal candidato, infatti, sono state poi rielaborate e hanno costituito la base per proporre – e, laddove fosse temporalmente possibile, attuare – delle azioni tese al miglioramento dell’efficienza e dell’efficacia dell’azienda.

Abstract – English Version

In this work, the student presents the result of a period of more than 3 months at the MTU France company, shared not equally between the workplaces in Beauchamp (Paris) and Mandelieu-La-Napoule (Cannes).

The structural scheme of the present work logically and chronologically follows the operative work. Thus, it begins with a phase of process mapping, which is the enabler to successive phases (the title of the work is related to this). Here, by means of a series of focused interviews, the student suggested a new view of the company – from functions to processes – and managed to get a detailed Process Map covering all the activities taking place in the company.

This phase represented the first step of a SWOT analysis, a managerial tool never before used in the company.

The process mapping set up the base enabling not only change management, but also the well-known Porter’s value chain analysis (representing one of the two souls of SWOT analysis: the internal one) which could not have had any other base to rely on.

Anyway, the real task of the stage in MTU France was change management. Actually, we had to deal with a very atypical change management, because changes had already happened when the stagiaire arrived in the company.

Meaningful changes, involving both the technological – with the introduction of ERP SAP R/3 that had just taken place – and managerial – a growth in headcount of about 40% - side of the matter.

“Ex post” change management was therefore the second challenge of the work, coming to manage both the individual and the organizational aspect of the topic. Enabled by Process Mapping, change management itself resulted in an enabler of an activity we could call “Improvement Planning”: information kept during the interview phase, as a matter of fact, have been then elaborated again and constituted the base to suggest – and, whereas it was temporally possible, make – actions aiming the company effectiveness and efficiency improvement.

Indice

Introduzione ……… Pg. 6 1. Presentazione società ……… Pg. 7 1.1 Com’era ……… Pg. 7 1.2 Com’è ……… Pg. 8 2. La spinta al cambiamento ……… Pg. 9 2.1 L’influsso Tognum ……… Pg. 9 2.2 La crescita dell’headcount ……… Pg. 10 2.3 Il fattore ERP: l’introduzione di SAP R/3 ……… Pg. 11 3. Process Mapping & Description ……… Pg. 17 3.1 Pianificazione lavoro: trasferte, interviste e validazioni ……… Pg. 17 3.2 Preparazione interviste ……… Pg. 19 3.3 Interviste ……… Pg. 20 3.4 Stesura processi ……… Pg. 21 3.5 Validazione ……… Pg. 23 3.6 Il software ViFlow ……… Pg. 27 3.7 ViFlow Reporter ……… Pg. 32 3.8 Il corso di formazione ViFlow ……… Pg. 33 3.9 La Process Map ……… Pg. 34 4. Analisi punti di forza e di debolezza ……… Pg. 37 4.1 L’analisi interna ……… Pg. 37 4.2 L’analisi esterna ……… Pg. 40 4.3 Punti di forza e di debolezza (Strengths and Weaknesses) ……… Pg. 45

5. Il change management ……… Pg. 51

5.1 Le basi teoriche ……… Pg. 51 5.2 Change Management in ambito IT ……… Pg. 61 5.3 Il change management in MTU France ……… Pg. 82 5.4 Miglioramenti in uscita da Process Mapping e CM ……… Pg. 87 5.5 Conclusioni ……… Pg. 92

Bibliografia ……… Pg. 93

Ringraziamenti ……… Pg. 94

Introduzione

Questo elaborato rappresenta la sintesi del lavoro compiuto dal candidato in oltre tre mesi di lavoro presso la società MTU France, tra i siti di Beauchamp (Paris) e Mandelieu-La-Napoule (Cannes). Nel presente elaborato si condensano dunque i risultati di un operato trasversale, partito da un’attività di mappatura dei processi scaturita in una Process Map ed in una serie di dati che sono stati poi conseguentemente utilizzati dal candidato stesso per guidare il change management – atipico, in quanto “ex-post”, come meglio verrà spiegato nel corso della trattazione – e la proposta ed attivazione di tutta una serie di attività di miglioramento dedotte dall’analisi critica stessa.

In appendice all’elaborato si riporta una parte della documentazione prodotta dal candidato in sede di tirocinio presso la società MTU France, nella lingua originale (francese).

1. Presentazione società

1.1 Com’era

La MTU France di fine 2006 è una filiale di MTU Friedrichshafen, azienda tedesca leader nella produzione di motori diesel per applicazioni navali, militari, ferroviere ed industriali.

MTU è un brand forte che può contare su 17 filiali nel mondo (MTU Detroit Diesel Usa, MTU Asia Singapore, MTU Hong Kong, MTU Asia Thailand, MTU Engineering Suzhou Cina, MTU India, MTU Indonesia, MTU Japan, MTU Detroit Diesel Australia, MTU Detroit Diesel Benelux, MTU Italia, MTU do Brasil, MTU Detroit Diesel Israel, MTU Turkey, MTU France, MTU South Africa, MTU Detroit Diesel UK), un fatturato di 1,3 miliardi di euro l’anno ed oltre 6.000 dipendenti in totale, di cui circa 5/6 nello stabilimento tedesco di Friedrichshafen.

Nata nel 2001 nello stabilimento di Mandelieu-La-Napoule (Cannes) per volontà della sede centrale di Friedrichshafen, MTU France si è allargata man mano fino ad aprire un secondo stabilimento nel 2004, a Beauchamp, nell’Ile-de-France intorno a Parigi. A grandi linee, e secondo una divisione non vincolante ma semplicemente frutto di una deduzione del candidato, lo stabilimento di Beauchamp è dedicato principalmente al settore della Difesa e delle applicazioni ferroviarie, mentre il sito di Mandelieu è focalizzato soprattutto sul servizio di assistenza dopo vendita per i numerosissimi yacht clienti MTU presenti in Costa Azzurra tra Saint Tropez e Montecarlo.

Il raggio d’azione di MTU France è limitato alla vendita ed all’assistenza post-vendita dei clienti MTU, Detroit Diesel e VM Motori della Francia (incluse le Antille francesi) e dell’Africa francofona. Fino al 2006, il numero di impiegati nei due stabilimenti non superava le 50 unità. Per rispondere in maniera più flessibile alla domanda dei numerosissimi clienti, MTU France ha sviluppato una consistente rete di Service Dealers, che operavano ed operano su tutto il territorio in maniera autonoma ma contrattualizzata da parte della società.

1.2 Com’è

Dalla fine del 2006, l’azienda fa parte della holding Tognum (nata dalla fusione di MTU Friedrichshafen e Detroit Diesel), il cui portfolio include inoltre motori a gas, turbine a gas, fuel cells e sistemi di monitoraggio e controllo elettronici.

Il fatturato del gruppo nel 2006 è ammontato a circa 2,5 miliardi di euro. 7150 impiegati figurano nel libro paga del gruppo che commercializza i marchi MTU, Detroit Diesel, Mercedes-Benz (per quanto riguarda i motori industriali), MDE, CFC-Solutions, L’Orange e Rotorion.

L’offerta di prodotti Tognum include ad oggi soluzioni per le applicazioni navali, yachts e commerciali, i generatori di potenza, le pile a combustibile, le applicazioni industriali, l’agricoltura, le ferrovie, la difesa, le automobili, i SUV, i sistemi d’iniezione ad alta e media velocità.

La Holding Tognum si appresta oggi a preparare l’entrata in borsa, e per questo sta uniformizzando i metodi lavorativi delle sue filiali a livello mondiale, pur rispettando l’autonomia e le peculiarità di ciascuna di esse.

Con il nuovo assetto societario, MTU France si è allargata in numero fino a 70 unità – il che equivale ad un 40% in più - ed ha uniformato le sue funzioni alla codifica “Corporate” della holding di cui fa parte.

Un importante ruolo nella standardizzazione di processi e procedure aziendali è stato giocato dall’introduzione da fine 2006 del sistema ERP SAP R/3, sviluppato da un centro di competenza interno alla società ed ubicato a Singapore ed introdotto nelle varie filiali al termine di un lungo quanto imprescindibile lavoro di formazione personalizzata durato nel complesso circa 6 mesi.

2. La spinta al cambiamento

In questa prima contrapposizione prima/dopo si intuiscono già in embrione i germi del cambiamento e, pertanto, della necessità intrinseca di gestirlo.

2.1 L’influsso-Tognum

Il più evidente momento di discontinuità tra l’azienda MTU France fino a fine 2006 e quella che esce, profondamente, strutturalmente sconvolta e rinnovata, dall’inizio del 2007 è l’entrata nell’orbita della holding Tognum. L’ingresso in un circuito di questo giro d’affari significa necessariamente compiere sforzi per uniformarsi a livello globale, anche tra piattaforme aziendali che non necessariamente hanno molto in comune. Questi sforzi non possono essere procrastinati nel tempo perché l’holding Tognum, tramite il suo a.d. Volker Heuer, ha già espresso ai propri dipendenti, azionisti e stakeholders la volontà di quotarsi in borsa in un futuro quantomai imminente.

Questo primo fattore già da solo rende di fatto urgente non solo una piattaforma, ma anche una “lingua” comune con cui parlarsi a livello corporate in ogni parte del mondo. La necessità di esplicitare il fatto di afferire ad uno stesso gruppo è qui tanto maggiore quanto più si capisce l’importanza di dover condividere la stessa vision, la stessa mission, incarnando gli stessi valori in tutto il mondo.

2.2 La crescita dell’headcount

Il numero di impiegati dell’azienda nei mesi a cavallo tra il 2006 ed il 2007 è quasi raddoppiato, passando di fatto da 50 a 70 unità equamente divise tra i due siti nord e sud della Francia (che si dividono anche mercato e zone di competenza, per regioni, con una “linea gotica” di demarcazione). La portata del cambiamento a questo livello è già esplicita nell’introduzione di due nuove figure che fino a questo momento non erano state reputate indispensabili all’azienda: il responsabile delle risorse umane e il responsabile IT.

Fino a questo momento, era infatti l’a.d. di MTU France a fare nella sostanza le veci del responsabile HR, mentre la mancanza di un responsabile IT era forse ancora più evidente: ogni problema a livello di Information Technology, dal semplice tutoring sui software fino ai problemi di reti ed hardware più complessi, venivano gestiti e risolti – in tempi, ovviamente, terribilmente lunghi – direttamente dalla sede centrale a Friedrichshafen, in Germania, dove un’équipe di specialisti divideva il suo tempo tra le segnalazioni delle varie filiali.

La crescita dell’headcount aziendale è stata resa possibile dopo una fase di intenso

recruitment da parte dell’azienda, con grande sforzo selettivo, e ha reso possibile

una divisione più nitida dei ruoli e dei compiti aziendali, tramite la redazione di appositi “Fichiers de poste”, sorta di dichiarazione delle responsabilità di ogni impiegato.

In questa prima fase è emersa sin da subito la difficoltà di gestire il cambiamento dal punto di vista organizzativo, di valutare le prestazioni degli impiegati tramite indicatori da costruire appositamente, ritagliandoli sulle singole funzioni.

2.3 Il fattore ERP: l’introduzione di SAP R/3

L’elemento che però più di tutti ha forse sconvolto, nel quotidiano, il modus

operandi degli impiegati e dell’azienda tutta è stato l’adozione del sistema SAP

R/3.

2.3.1 SAP R/3

SAP R/3 è un sistema di tipo ERP (Enterprise Resource Planning) basato su una base di dati unica a livello aziendale – che garantisce l’aggiornamento in real time dei dati, e previene la ridondanza e fenomeni di obsolescenza dei dati - e su una struttura modulare facente riferimento alle best-practices del settore. Si tratta nella sostanza di un prodotto per piattaforma architetturale client-server costituito da un modulo centrale a cui è possibile aggiungere moduli specifici. Il modulo principale (BC) è costituito da quei componenti essenziali e trasversali a qualsiasi attività quali, ad esempio, le componenti per la creazione e l'accredito degli utenti, l'ambiente di sviluppo (workbench), di personalizzazione (customizing) e di gestione della banca dati (Data Dictionary) e da moduli principali e trasversali a qualsiasi azienda quali quello dell'amministrazione e controllo di gestione, la logistica, la vendita e la distribuzione, sino alla pianificazione della produzione. I moduli più frequentemente riscontrabili in azienda sono i seguenti:

• BC Basic Component • FI Financial

• CO Controlling

• MM Material Management • SD Sales and Distribution • PP Production and Planning • PS Project System

• PM Plant Management • HR Human Resource

SAP R/3 è l'evoluzione di R/2 e delle piattaforme mainframe (2-tiered - database server con central instance e terminale di interazione uomo-macchina). E' basato sul modello client-server, a tre strati hardware (3-tiered): il cliente, nella maggior parte dei casi costituito da workstation; uno strato dedicato all'applicazione con uno o più server dedicati a erogare dei servizi, ed uno strato dedicato all'interazione di lettura e memorizzazione dati con un server dedicato al database od un sottosistema dischi e servizi per la gestione della coda di richieste utente. Uno strato del software SAP R/3 è dedicato all'astrazione del linguaggio SQL dal database relazionale nativo. Questo permette di utilizzare a discrezione del cliente uno dei maggiori sistemi di database relazionali disponibili sul mercato senza necessità di modificare il codice dell'applicativo SAP o custom. I programmi applicativi sfruttano la tecnica del linguaggio precompilato: il codice sorgente viene cioè compilato alla sua prima esecuzione e le successive modifiche al codice sorgente saranno interpretate da un modulo in tempo reale e ricompilate. Questo avviene con una tecnica simile a quella oggi usata dai prodotti Java.

La parte sicuramente più critica nella fase di installazione di SAP R/3 per un'azienda riguarda la customizzazione (a livello di parametrizzazione e/o di programmi specifici), che richiede un attento monitoraggio e tutoring ed aggiunge nuovi costi alla base già elevata delle licenze. L'implementazione, comunque, permette a SAP R/3 di adattarsi appieno alle specifiche esigenze di un'azienda qualsiasi sia il suo ambito, categoria commerciale, produttiva o di servizi, sia essa operante in un solo mercato o worldwide.

2.3.2 Valutazioni preliminari all’introduzione di SAP R/3

La volontà di introdurre un sistema di tipo ERP è stata comune al management della casa madre a Friedrichshafen e della filiale francese.

La prima fase preliminare dunque è stata un’analisi dei costi e dei benefici legati all’introduzione del sistema in azienda. La valutazione è stata più di tipo qualitativo che quantitativo: i fattori contingenti sovraesposti facevano già propendere assolutamente per l’introduzione di uno strumento informatico che facesse riferimento ad una base dati unica ed aggiornata real time.

Una volta ottenuto l’avallo dell’azionariato di entrambe le società – filiale e casa madre -, dunque, si è passati ad una ricerca di mercato per valutare quale prodotto si ritagliasse meglio sulle necessità dell’azienda.

In un primo momento, il management sembrava orientato in maniera risoluta verso la soluzione del fornitore Oracle, più economica rispetto all’alternativa SAP, che è comunque il leader di mercato. L’intervento del management della casa madre, però, ha spostato la scelta verso il fornitore inizialmente scartato, essenzialmente per due ragioni: la leadership del mercato ERP è stata reputata un fattore determinante per un’azienda che si trova ad operare in un contesto in alcuni casi assimilabile al monopolio, quindi sostanzialmente senza punti di riferimento dati da altre aziende potenzialmente concorrenti; inoltre – ed è forse questo il fattore che ha poi fatto propendere definitivamente per questa opzione – il gruppo MTU aveva già al suo interno un pool di sviluppatori SAP R/3 nella propria piattaforma asiatica (MTU Asia, con sede a Singapore).

Sebbene dunque il costo d’installazione fosse molto più esoso (600.000 euro, quasi il doppio rispetto alle 350.000 della soluzione Oracle), si è deciso di propendere per un investimento che sarebbe comunque rimasto all’interno del gruppo MTU.

2.3.3 Le fasi di implementazione

Effettuata l’analisi costi/benefici e scelto il fornitore SAP, si è passati alla delicatissima fase di vera e propria implementazione del sistema ERP nel contesto aziendale.

La conoscenza del modus operandi aziendale dovuta al fatto di afferire alla stessa società ha facilitato sensibilmente il lavoro, specialmente per quanto riguarda le prime fasi della progettazione e dello sviluppo del sistema.

Il primo step dunque che ha coinvolto in prima persona i dipendenti MTU France è stato quello della cosiddetta “Fase Blue Print”. In questa fase, la prima che accompagna il sistema ERP aldifuori dell’azienda che l’ha progettato e sviluppato, viene effettuato il testing dei moduli da parte degli utenti finali, e vengono aggiunti i “legal requirements” al business case installato.

Alla fine di questa fase vi è un primo step di validazione: tutti i moduli usciti dal

“Blue Print” vengono stampati e firmati da parte dei Process Owners

appositamente individuati preliminarmente per ogni singola attività.

A validazione ultimata, parte dunque la realizzazione vera e propria, con l’implementazione delle modifiche decise nella fase di Blue Print. In questa fase, nessun dipendente di MTU France è stato coinvolto in prima persona: tutto il carico di lavoro è stato sviluppato da parte degli sviluppatori.

In seguito, è stato il turno della formazione: in questo delicato periodo, dapprima i

Process Owner (definiti anche “Champions”), poi i “Key users” si sono recati

appositamente nel centro di sviluppo a Singapore, dove hanno ricevuto corsi personalizzati sui singoli moduli a loro indispensabili nella pratica operativa.

E’ solo a questo punto che è avvenuta la migrazione dei 3 livelli del sistema legacy

verso il nuovo SAP R/3.

Il sistema legacy precedentemente installato era un mainframe comunque dotato

di Graphic User Interface, ma che per alcuni comandi si basava ancora su

interfacce di tipo carattere, e non era assolutamente centralizzato né dotato di un sistema

Il sistema legacy era comunque assimilabile a un sistema altamente decomponibile, il che ha permesso di trasferire separatamente i 3 livelli database – applicazioni - interfaccia utente separatamente e senza grossi problemi operativi. Inoltre, la migrazione è stata realizzata nelle due settimane a cavallo del nuovo anno (tra il 25 dicembre 2006 ed il 5 gennaio 2007), in un periodo tipicamente festivo, in modo da impattare il meno possibile sui ritmi lavorativi dell’azienda. Il 5 gennaio 2007 il vecchio sistema legacy veniva del tutto “spento”: era l’inizio del “Roll-Out”, l’immissione in servizio del nuovo sistema ERP, anticamera del “ Go-Live” e del “Run”, veri ultimi due scalini verso l’introduzione completa del sistema in azienda. Una fase che aveva seguito per tutto il mese successivo (fino al 5 febbraio 2007, dunque) nel “Post-Production Support”, sorta di tutoraggio sul posto assicurato da una troupe di esperti del sistema inviati direttamente da

Singapore per assistere nei primi, difficilissimi giorni di lavoro sul nuovo sistema gli impiegati di tutte le funzioni.

“Il calo operativo nei primi giorni è stato evidente” ha ammesso l’a.d. dell’azienda Christian Courcelles “per fare un semplice preventivo, operazione che prima non richiedeva più di 10 minuti, raramente si impiegava meno di mezz’ora”.

Ad oggi, però, il tempo medio di emissione di un preventivo standard è calato drasticamente sotto i 5 minuti, limitando al minimo inoltre la possibilità di sviste e di errori nell’invio finale al cliente.

2.3.4 Variazioni IT a corollario di SAP R/3: il Business Portal

A complicare ulteriormente il change management in ambito IT è arrivata la scelta concomitante di sostituire il vecchio approccio di tipo “Extranet” dell’azienda verso un portale integrato (Business portal) che permettesse diversi livelli di permessi in base al tipo di interazione prevista con esso.

Il Business Portal implementato in azienda è stato interamente sviluppato in tedesco, per la casa madre, e poi tradotto e declinato nelle varie versioni inglese, asiatica, spagnola, portoghese e, appunto, francese.

Il Business Portal permette un’interfaccia unica per tutti gli stakeholders

dell’impresa, con vari livelli di permesso in base al ruolo esercitato dentro o nei confronti dell’azienda.

L’implementazione del portale aziendale ha richiesto un importante sforzo di

content management: per quanto riguarda la proposta grafica, si è optato per

un’interfaccia molto leggera e poco impattante.

Effettuando il login, a seconda della propria funzione nell’azienda si visualizzano diverse informazioni, organizzate espressamente per un certo ruolo. Il gestore del sistema (responsabile IT) e l’a.d. dell’azienda hanno pieno accesso ad ogni funzione. Il sistema è decentralizzato, ma entro certi limiti e con un controllo puntuale: ogni modifica al Business Portal deve essere validata (firmando i fogli modificati stampati) dall’a.d. stesso.

Il Business Portal non si rivolge unicamente all’interno dell’azienda ma si offre al suo esterno, verso clienti, fornitori, azionisti e portatori d’interesse in senso lato

dell’azienda. Entrando nella propria area privata, ciascuno di essi potrà visualizzare informazioni riservate a lui esclusivamente dedicate.

Il Business Portal si connota dunque come un importante passo avanti nell’ottica di offrire uno strumento integrato e tecnologicamente avanzato rispetto alla vetusta Extranet precedente, ma aggiunge un fattore di ulteriore “smarrimento” nel personale già sconvolto dal terremoto-SAP.

3. Process Mapping & Description

E’ in questo contesto tumultuoso che si inserisce la necessità di ottenere una mappa dei processi completa, coerente e puntuale. La necessità è intrinseca, non formale: non è dettata da particolari mode di certificazioni ISO (anche se comunque, un giorno, potrebbe costituirne un’ottima base), ma solo da una precisa volontà aziendale di formalizzare il proprio modus operandi per poter gestire meglio i postumi di un cambiamento che ha sconvolto per sempre l’attitudine al lavoro dei propri dipendenti.

Due sono le principali azioni sviluppate sui processi: parliamo infatti di Process Mapping e Process Description come di due momenti separati, laddove nel primo si vuole soprattutto creare una sorta di “cartina aziendale” per orientarsi nella giungla delle funzioni e delle attività, individuando responsabilità e competenze, mentre nel secondo si entra nel dettaglio di ogni singolo processo, sviscerandolo, per capire innanzitutto i problemi che nasconde, e comprendere così dove e come sia possibile andare ad agire capillarmente per migliorare sulla base di obiettivi numerabili ed evidenti.

3.1 Pianificazione lavoro: trasferte, interviste e validazioni

La prima attività necessaria per implementare il lavoro oggetto di questa esperienza è stata la pianificazione del lavoro. In questa fase, il candidato ha sottoposto all’attenzione del tutor aziendale un diagramma di Gantt iniziale, basato su stime dei carichi di lavoro, in modo da ottimizzare e minimizzare le trasferte nello stabilimento di Mandelieu-La-Napoule.

La pianificazione del lavoro è un vero e proprio processo a sé stante, costituito da una serie di momenti logicamente interdipendenti, che possono essere riassunti in questa lista di passi:

• Preparazione interviste • Interviste

• Stesura processi

• Seconda validazione processi – con il “Process Owner” (ed eventuali modifiche)

• Terza validazione processi – con il Tutor (ed eventuali modifiche)

• (eventuale) Quarta validazione processi – con l’a.d. (ed eventuali modifiche) Preliminare a questa scaletta è la decisione, di comune accordo con il tutor, dell’individuazione di una serie di figure chiave da intervistare, da cui è uscita come output la “lista delle interviste”, documento interno informale a sole finalità operative avente lo scopo di evitare interviste “doppioni” (non sono rari i casi in azienda di persone che sono dedite alle stesse attività, magari per clienti diversi) ed al contempo di riuscire ad ottenere una mappatura completa dei processi aziendali, in modo da non perdere nessuna informazione rilevante.

La pianificazione del programma delle interviste è stato organizzata in modo da analizzare la struttura aziendale a partire dalle funzioni individuate nell’organigramma societario: una settimana ad esempio è stata interamente dedicata al servizio Vendita, un’altra a quello di Assistenza Post-Vendita, un’altra ancora a quello Finanza e così via, fino a coprire interamente lo scheletro della società.

3.2 Preparazione interviste

Prima dell’effettuazione dei Rendez-Vous con i vari dipendenti, il candidato ha ritenuto opportuno analizzare preliminarmente per ciascuno di essi il documento

“Descriptif du Poste”, una sorta di mansionario interno alla società, in modo da

non correre il rischio di incorrere in qualche dimenticanza. Questo documento costituiva dunque la base per costruire la traccia per l’intervista, redatta appositamente su misura dell’interlocutore prima di ogni incontro.

La traccia delle domande era costituita da una serie di questioni da porre, ma più che una scaletta vera e propria si trattava di una sorta di check-list assai flessibile. Nella traccia si è cercato di distinguere un livello operativo (le attività veramente manuali) da quello informatico, ed una grossa fetta delle domande erano proprio destinate a comprendere nel dettaglio l’utilizzo degli strumenti software messi a disposizione dall’azienda. Ovviamente, in questa fase un ruolo di primaria importanza è stato dedicato al sistema SAP R/3: nella preparazione delle interviste spesso il candidato si è avvalso del sostegno del manuale (e, laddove questo non bastasse, dell’interfaccia con il responsabile IT dell’azienda).

Una parte della traccia riguardava infine domande iterative sui modelli documentali a supporto della comunicazione e dell’informazione inter e intra-aziendale.

3.3 Interviste

Durante lo svolgimento dell’intervista vera e propria, il documento precedentemente preparato non era dunque vincolante: si è anzi preferito in ogni circostanza dare sempre massima libertà all’interlocutore di seguire il proprio flusso di pensieri, in modo da annotare anche i problemi quotidiani riscontrati nello svolgimento delle attività di riferimento. Solo laddove la rappresentazione delle attività risultasse poco chiara o troppo superficiale, si è intervenuto puntualmente per stimolare una più puntuale descrizione del lavoro.

Tendenzialmente, si è cercato di operare, laddove possibile, con una logica

bottom-up, ovvero dai livelli gerarchici più bassi man mano salendo verso i livelli

più alti dell’organigramma all’interno della funzione stessa.

Se la traccia constava sostanzialmente dei 3 livelli operativo-informatico-informativo, durante l’esecuzione delle interviste spesso il candidato ha preferito porre insieme le domande relative ai 3 distinti approcci, in modo da non dover ritornare pedissequamente su argomenti già trattati e prolungare oltremodo la durata delle interviste, che tipicamente già raramente venivano concluse entro le due ore di intensa conversazione.

Anche nell’esposizione dei problemi, il candidato ha preferito non dedicare una parte apposita dell’intervista, magari in coda quando l’intervistato rischiava di risultare particolarmente “affaticato” dalle domande, optando invece per un approccio più atto a stimolare continuamente l’esplicitazione delle principali

impasses esperite nelle attività, ed invitando infine l’intervistato a provare a

proporre delle possibili migliorie ai problemi enucleati.

Per raccogliere le informazioni si è scelto di non registrare le interviste (per non “incutere timore” all’intervistato), optando dunque per degli appunti organizzati principalmente in forma discorsiva o, talvolta, già abbozzando un’impostazione grafica di alcuni processi.

Ogni volta che il candidato intuiva che si stesse parlando di un nuovo processo, si assicurava di comprendere bene i dati del problema (input) ed il risultato finale (output).

3.4 Stesura processi

Alla fine di ogni intervista, il materiale raccolto veniva organizzato ancora “a mano”, in una forma comunque già grafica, pronta per un’immediata digitalizzazione. La fase di implementazione dei processi dentro il software ViFlow, quello designato dall’azienda per il lavoro, è iniziata parzialmente anche prima dell’effettuazione del corso di formazione presso la casa madre di Friedrichshafen, grazie alla guida del software ed al prezioso sostegno del responsabile IT e dei colleghi tedeschi responsabili del progetto. Questo anticipo dell’implementazione dei processi già nella nuova base dati ha velocizzato molto il lavoro, e semplificato inoltre la fruizione della formazione stessa.

Per ogni singolo elemento del processo, comunque, ci si è sempre premurati di verificare che fossero ben chiari input, output, documenti e strumenti software collegati, indicando, laddove fossero presenti (in verità: in pochissimi casi) eventuali indicatori predisposti per il monitoraggio.

Per i processi più semplici e quelli che non coinvolgevano un gran numero di dipendenti, spesso era possibile descrivere interamente il processo direttamente a partire dal materiale raccolto dopo una singola intervista.

Talvolta, invece, per descrivere un solo processo si sono dovute effettuare più interviste, giacché è noto come i processi siano trasversali alle funzioni e dunque spesso sono diversi gli attori coinvolti in gioco nello snodo di una singola attività. Operativamente, i punti critici di questa fase sono stati dapprima l’individuazione delle singole attività a partire dal materiale raccolto ed organizzato a seguito delle interviste, poi la necessità di scegliere e mantenere un livello omogeneo e coerente di dettaglio per ogni processo, ed infine quelli più prettamente operativi legati alle problematiche del software ViFlow, strumento poggiante su MS Visio appositamente progettato in Germania e con diversi limiti tecnici (e.g.: impossibilità di fare copia/incolla di alcune parti dei progetti) che ne hanno pesantemente complicato la fruizione.

In uscita da questa fase si ottengono dunque dei documenti in formato proprietario (.vsd) dal software ViFlow, che possono essere poi facilmente stampati e sottoposti all’attenzione dei vari responsabili per il processo di validazione seguente.

Alcuni dati, però, rimangono “invisibili” nella versione cartacea: tutto ciò che rappresenta il “backoffice” proprio del software ViFlow e che non è esportabile sull’interfaccia Visio è fruibile solo nella versione digitale. Questo ha portato ad una leggera complicazione del processo di validazione, dato che alcuni dati, apparentemente mancanti nella versione cartacea, erano in realtà già stoccati nel database. Questo problema sarebbe potuto essere aggirato effettuando i processi di validazione direttamente tramite una proiezione del software nell’apposita sala riunioni o una visualizzazione a schermo direttamente nell’ufficio del candidato, ma durante l’analisi dei processi il lavoro del personale non si è certo fermato, ed era perciò indispensabile che fosse il candidato ad “andare a trovare” i dipendenti nel loro contesto lavorativo e non viceversa, per continuare a garantire la copertura del servizio (fattore particolarmente importante per i servizi come l’Assistenza Post-Vendita).

3.5 Validazione

3.5.1 Validazione con l’intervistato

Una volta terminata la fase di schematizzazione dei processi e di implementazione degli stessi nel software designato ViFlow, il primo step di validazione è stato sempre quello con l’intervistato. Per i processi più semplici, quelli che interessano un solo attore (ed altri in maniera marginale), in questa prima fase, lo scopo era soprattutto quello di verificare la coerenza di quanto emerso nel corso dell’intervista con il processo inserito dal candidato nel software. Difficile infatti aspettarsi qualcosa di più di una mera verifica formale di correttezza da questa fase, dato che gli attori coinvolti sono sempre gli stessi: ovvio che dunque raramente in questa fase di validazione ci si è resi conto di eventuali lacune o carenze a livello descrittivo del processo, o di un’eventuale incoerenza del livello di dettaglio della descrizione in confronto ad altri processi.

Per i processi più complicati, non si è purtroppo potuto organizzare riunioni a più partecipanti (sempre per il problema della continuità operativa), e si è dunque operato per validazioni “a blocchi successivi”, facendo validare in maniera ridondante il processo dagli attori coinvolti. Nel caso si presentassero diverse opinioni circa uno stesso processo, si è seguita la logica di scomposizione del processo in attività e si è scelto di dare sempre la precedenza al responsabile dell’attività stessa.

In uscita da questo processo, si otteneva o una validazione da parte dell’intervistato, o l’indicazione di eventuali modifiche da compiere al processo. In quest’ultimo caso, un secondo (o terzo, quarto...) incontro di validazione veniva richiesto, fino a quando non si ottenesse la validazione definitiva da parte dell’intervistato.

3.5.2 Validazione con il Process Owner

Una volta ottenuta una prima stesura della mappa dei processi aziendali, si è provveduto, durante il corso di una riunione chiave per lo svolgimento dei lavori, a decidere di concerto con l’a.d. della società i cosiddetti “Process Owners” degli oltre 60 processi individuati. Ogni aggiornamento della mappa dei processi (aggiunta/modifica di un processo) ha richiesto uno step di validazione e di

indicazione da parte dell’a.d. del Process Owner per l’eventuale nuovo processo inserito.

Redatta dunque la lista di Process Owners e ottenuta la prima validazione dell’intervistato/degli intervistati, si passava a sottoporre il processo al Process Owner designato. La validazione dei processi da parte del Process Owner era genericamente svolta in maniera aggregata: si valutavano insieme con ciascun Process Owner tutti i processi di sua competenza. E’ dunque solo in questa fase che si presenta un nuovo concetto finora non esplicitato nel lavoro: la coerenza trasversale tra processi. Il Process Owner può infatti ora comparare e valutare più processi insieme, e grazie ad un livello di conoscenza più approfondita e ad una visione sicuramente più d’insieme è pertanto in grado di stabilire le modifiche necessarie per descrivere in maniera completa e non ridondante i vari processi. Le indicazioni da lui fornite porteranno dunque a processi talvolta nuovi, talaltra solo marginalmente modificati: la nuova fase di validazione, però, in questo caso non passerà più per i singoli intervistati ma direttamente per il Process Owner. In questa fase, inoltre, il Process Owner può fornire indicazioni suppletive relative ai problemi dei processi e sugli indicatori e gli obiettivi degli stessi, in modo da supplire ad eventuali lacune con informazioni che risulteranno preziosissime anche nell’ottica-Change Management.

3.5.3 Validazione con il tutor aziendale

Una volta “ripuliti” dalla fase di validazione con il Process Owner, i processi passano attraverso un ulteriore filtro: quello del tutor aziendale. Qui si tratta di un lavoro che trascende il formale, ma è piuttosto di sintesi: si parte dai processi già sottoposti ad una duplice validazione, e si taglia laddove serve, si confronta con tutti gli altri processi, si assembla laddove è possibile, si lascia dove è necessario. Dalla validazione con il tutor aziendale escono dunque i processi finali, laddove non sia considerata necessaria un’ultima fase di validazione con l’a.d. della società (per i processi più critici e più peculiari dell’azienda).

3.5.4 Validazione con l’amministratore delegato

L’amministratore delegato figura già nella validazione a livello di Process Owner di diversi processi, ed ovviamente a livello di intervistato per i processi che lo coinvolgono operativamente in prima persona. Inoltre, per i processi più peculiari e più critici dell’azienda, inoltre, si è ritenuta opportuna un’ultima fase di validazione dei processi stessi su cui è già stato compiuto qualcosa di più che un semplice “labor limae” con le 3 precedenti validazioni. Per tutti gli altri processi, invece, si è bypassata quest’ultima fase, in un’ottica di empowerment e di responsabilizzazione ai livelli inferiori.

Anche in questo caso, in uscita dagli incontri di validazione si sono ottenute a margine ulteriori indicazioni sugli obiettivi dei singoli processi, il loro “perché” ed il loro inquadramento nei valori, nella mission e nella vision aziendale, che sono poi stati riutilizzati in larga parte come spunto per proporre miglioramenti nel loro svolgimento.

3.5.5 Il sito di Mandelieu – process mapping e change management in trasferta

Il piano di lavoro concernente la parte di descrizione e mappatura dei processi è stato pensato in un’ottica di minimizzazione del numero delle trasferte sull’altro sito dell’azienda, quello di Mandelieu-La-Napoule. Tutti i processi centralizzati sono stati dunque mappati direttamente nel sito di Beauchamp, così come quelli svolti parallelamente nei due stabilimenti. A Mandelieu, dunque, sono state portati i processi già validati dai Process Owner: questi processi sono stati poi sottoposti all’attenzione dei responsabili coinvolti negli stessi nello stabilimento sud. Essi hanno esplicitato le differenze tra le modalità di esecuzione delle singole attività, ed hanno permesso una molto più rapida – ed omogenea – mappatura dei processi anche nel sito di Mandelieu, effettuata sostanzialmente per comparazione.

La comparazione stessa ha costituito al contempo un momento di riflessione circa

le best-practices all’interno dell’azienda: si è qui capito quali sono le differenze

operative (le strategie e le linee guida sono ovviamente allineate), e si è potuta iniziare una riflessione circa la possibilità di lavorare su alcuni processi allo stesso

modo, secondo la logica giudicata più sensata ed opportuna. In sostanza, questa fase è stata utile anche per garantire un benchmarking interno, fermo restando che alcuni processi sono effettuati diversamente per necessità intrinseca, e che dunque non tutto è propriamente riconducibile allo stesso modus operandi.

3.6 Il software ViFlow

Il software scelto dalla casa madre per effettuare la mappatura dei processi a livello Corporate è ViFlow, prodotto commercializzato dall’azienda tedesca ViCon, leader di mercato in questo campo.

ViFlow è uno strumento di modellizzazione grafica dei processi in grado di provvedere ad una rappresentazione dei processi aziendali rapida ed accurata, costituendo la base per una documentazione estensiva in grado di garantire un’ampia gamma di informazioni dettagliate.

ViFlow è una sorta di middleware che va ad operare in ambito MS Office, avvalendosi di fatto del supporto di MS Visio per quanto riguarda l’elaborazione grafica dei processi. Questa funzionalità permette dunque un’altissima interoperabilità con tutta la suite del pacchetto Office (Word, Excel, Access, PowerPoint, Project et similia), pur garantendo un livello più dettagliato di informazioni stoccate nel proprio database.

Il database di ViFlow, dunque, è di tipo relazionale (E/R) classico, le cui chiavi sono proprio i nomi (“Short Names”) dei processi stessi.

Oltre ai processi, esistono altre due categorie nel database di ViFlow: le informazioni e le aree.

Le informazioni sono presenti in corrispondenza “1:1” con le “frecce” che mettono in relazione i vari processi. Possono rappresentare essenzialmente documenti, o risposte a domande (tipicamente di tipo “Si/no”).

Le aree sono invece il dominio d’afferenza dei singoli processi. Ogni processo porta con sè una o più aree. Un’area può essere indifferentemente una funzione aziendale, un servizio, o anche un sistema informativo. Le aree hanno dunque lo scopo di inquadrare a colpo d’occhio dove ci troviamo quando parliamo di un singolo processo.

Graficamente, il software ViFlow sfrutta gli schemi a blocchi più tipici di MS Visio: i processi sono quindi rappresentati come rettangoli, le aree al loro interno come rettangoli grigi. I rombi indicano dei momenti di scelta: sono domande, e come tali non necessitano dunque di aree a cui afferire. I processi sono legati tra loro evidentemente con frecce: ma non basta un link grafico per ottenere una vera e propria “liaison” a livello del database. Bisogna invece entrare nel dettaglio del

processo ed andare a selezionare le persone e le funzioni coinvolte (e specificare in che modo: “I” sta per “informato”, “C” per “collabora”, “D” per “Decide”, “R” per “Responsabile”) in modo da eseguire la procedura in maniera corretta.

In questo modo, si otterrà in maniera del tutto automatica una sorta di matrice delle mansioni e delle responsabilità che potrà risultare molto utile anche in altri campi allo svolgimento delle attività aziendali ed alla gestione dei carichi di lavoro.

Fig. 3.1 Il Pacchetto di software ViFlow-ViFlow Reporter (courtesy of ViCon GmbH) I principali vantaggi che hanno permesso al software ViFlow di imporsi sul mercato sono sicuramente la facilità d’uso e d’illustrazione dei processi, che risultano alla fine comprensibili anche ad un lettore “profano”, chiari e logicamente strutturati in maniera del tutto coerente con il processo vero e proprio, permettendo inoltre un altissimo livello di informazioni nel backoffice.

Un altro vantaggio non trascurabile del software, specie per un’azienda che opera su scala mondiale, è la funzionalità di WebModel: con un semplice click, infatti, il software permette di effettuare la trasposizione dei files in versione .html e .xml in modo da rendere possibile un’immediata pubblicazione sulla rete (nel caso di MTU France, è stata scelta la pubblicazione sulla rete Intranet, risultando così un

modello di riferimento anche per le altre aziende sussidiarie di MTU Friedrichshafen).

I processi, una volta compilati nel linguaggio macchina destinatario (il candidato ha effettuato il testing e debugging sui browser IE e Mozilla Firefox, non riscontrando alcun problema di visualizzazione) e pubblicati, risultano navigabili con la tipica interfaccia grafica.

I processi possono infine essere facilmente importati/esportati da/verso altri database, con migrazioni piuttosto semplici (alla fine del lavoro l’intero database di MTU France non superava i 20 MB): anche questo è stato sicuramente un fattore vincente per un’azienda che aveva come scopo anche la missione di riuscire a fare dialogare meglio e più frequentemente le varie realtà sparse nel mondo, creando un sentimento di partecipazione e di affezione diffuso ancor prima che un mero scambio informativo tout-court.

Il software permette infine una customizzazione massima, rendendo editabili di fatto tutte le figure presenti nel programma. Quanto all’azienda MTU, comunque, questa funzionalità è stata usata molto poco, in realtà, preferendo optare per standard universalmente riconosciuti e per una scelta di abbinamenti di colori sobria.

D’altronde, è altresì vero che durante lo svolgimento delle attività diversi problemi -ovviamente non palesati nelle caratteristiche di prodotto - sono emersi.

Una prima impasse operativa è stata costituita dalla difficoltà ad allungare le pagine millimetrate su cui costruire i processi: ogniqualvolta si volesse aumentare lo spazio di lavoro, infatti, ci si trovava a dover riordinare tutti i processi e i vari “link” già creati, che venivano purtroppo “mescolati” da questa operazione, complicando ed allungando oltremodo il lavoro, facendo incappare in fastidiose perdite di tempo.

Un grosso limite invece più a livello “logico” che operativo è la scelta – di cui abbiamo già discusso, e che è in effetti molto discutibile – di aver preliminarmente stabilito che la chiave relazionale fosse il nome (Short name) del processo, e non, piuttosto, ad esempio un numero progressivo. Questa scelta è estremamente limitante e fastidiosa, ancor più perché non configurabile in alcun modo, dato che

in alcuni casi un processo nominato nello stesso modo può avere bisogno di specificazioni ben diverse a seconda del contesto in cui viene utilizzato.

Prendiamo ad esempio il semplice processo “Emissione fattura”: che si tratti di un servizio di vendita o di un servizio di assistenza post-vendita o ancora di una semplice formazione per i clienti, è evidente come il processo cambi sensibilmente le proprie caratteristiche, rendendo di fatto impossibile di ricongiungersi ad un unico processo (non foss’altro ad esempio per la descrizione dei moduli di SAP da utilizzare, ad esempio). In questi casi, dunque, si è dovuti ricorrere a perifrasi o ridondanze (es.: “Emissione fattura formazione”, “Emissione fattura post-vendita”) che hanno minato la leggibilità e la chiarezza del flusso del processo stesso.

Un’altra miglioria che sarebbe realizzabile senza eccessivi sforzi da parte del fornitore del software è quella di abilitare la funzione di “cut-and-paste” selezionando i processi nell’interfaccia grafica di ViFlow: in questo modo si riuscirebbe sicuramente a scorciare sensibilmente i tempi di lavoro nel caso ci si trovi a descrivere processi simili.

Fig. 3.2 L’interfaccia di ViFlow così come si presenta all’utilizzatore, con la grafica scelta da MTU (il flusso grafico è implementato con MS Visio).

3.7 ViFlow Reporter

Il pacchetto ViFlow include anche “a corollario” il software ViFlow Reporter, potente strumento che poggia sullo stesso database del programma-gemello per effettuare analisi e report utili alle varie funzioni aziendali.

Tramite il solo ViFlow, infatti, non si può andare a stampare altro che il flusso dei processi, senza poter ottenere alcuna informazione suppletiva, alcun commento o alcuna traccia della grandissima mole di dati “nascosta” nei meandri del database. ViFlow Reporter è lo strumento tramite il quale è possibile recuperare e far emergere tutti questi dati, offrendoli con viste diverse a seconda dei fabbisogni di ciascuna funzione/responsabile.

Una delle funzionalità più utili di ViFlow Reporter è proprio quella di aggregazione, sia essa effettuata per processi, per aree o per informazioni. E’ infatti possibile in questo modo verificare dove e quante volte un singolo documento viene utilizzato, o quanto è sfruttato un certo modulo di SAP, o ancora in quanti processi è chiamato ad intervenire un responsabile commerciale, piuttosto che una segretaria amministrativa. O ancora dove e con che intensità vengono utilizzati certi processi. ViFlow Reporter è dunque un software in grado solo di lavorare su dati già immessi: non è possibile infatti di qui inserirne di nuovi o ancora modificarne altri. ViFlow Reporter è in grado di dialogare con altri software, importando ed esportando matrici, indicatori, KPI, monitoraggi di prestazioni e grafici comparativi sulle stesse, liste di dati e di applicazioni. In particolare, alcuni sistemi di integrazione sono stati messi a punto con il famoso MS Access in modo da assicurare la massima interoperabilità tra i due sistemi, che usano ovviamente formati proprietari diversi ma comunque facilmente convertibili in entrambi i sensi.

3.8 Il corso di formazione ViFlow

Per utilizzare in maniera corretta e soprattutto a livello “corporate” il software ViFlow, il candidato ha partecipato, insieme ad un gruppo di responsabili giunti da tutto il mondo e responsabili del progetto per la propria filiale, ad un corso di formazione effettuato presso la casa madre, nello stabilimento di Friedrichshafen, sul lago di Costanza, in Germania.

Il corso di formazione, della durata di 18 ore spalmate su due giorni lavorativi, è stato diviso in due momenti distinti: un primo momento di “acclimatamento” con il software stesso, dove il formatore – un responsabile di ViCon - , dopo una prima, breve parte esclusivamente teorica, ha fatto principalmente impratichire i formandi con il software stesso, tramite esempi di difficoltà crescente; ed una seconda parte in cui sono stati presentati invece gli standard scelti dalla società MTU, senza spiegarne palesemente le ragioni.

E’ infatti più sulla semantica dell’ambiente di sviluppo che ci si è concentrati, che sul “lessico” vero e proprio del software. Le policies aziendali ed il modus operandi sono state soggetto del corso più che la semplice rappresentazione grafica dei flussi dei processi.

Per il cliente MTU, ViCon ha sviluppato infatti una versione customizzata del proprio software: in luogo della consueta rappresentazione dei processi del tipo “a corsie di nuoto” (“swimlanes”), sviluppata in senso orizzontale, per il proprio cliente la casa di software tedesca ha presentato, su esplicita richiesta, una versione più compatta, da svilupparsi invece in verticale.

E’ stata dunque sviluppata da parte del fornitore del software tutta una guida customizzata sulle esigenze e i desideri del cliente MTU, capace di illustrare nel dettaglio il modus operandi di implementazione dei processi nel software, le importazioni, le esportazioni, le modalità di aggiornamento ed altri dettagli più meramente operativi.

Il formatore ha pertanto istruito i formandi sulle dimensioni delle caselle dei processi (da standardizzare), sulla altezza dei caratteri, sulla numerazione delle attività, così come sulla lingua da utilizzare (doppia versione in lingua madre e in lingua inglese, ma la traduzione è tutta centralizzata in Germania presso una società esterna che lavorerà direttamente sul software).

3.9 La Process Map

Dal lavoro di analisi dei processi partito con le interviste e via via migliorato con le fasi successive di validazione sono dunque nati un totale di oltre 70 processi costituenti l’ossatura del lavoro in azienda. Già dalla semplice giustapposizione di questi processi si riesce infatti ad ottenere uno stampo fedele del modus operandi della società; ma è solo attraverso l’organizzazione di queste risorse che si può tracciare la vera e propria mappa dei processi, vero documento d’identità dell’azienda.

Lo sforzo di mappatura di MTU France è collocabile in un più vasto cambiamento d’attitudine da parte del gruppo a cui la filiale afferisce: un cambiamento che ha come linee guida la qualità e la trasparenza delle proprie attività orientate al cliente.

E’ dunque naturale che lo stabilimento-madre di Friedrichshafen abbia richiesto alle sue filiali di canalizzare i loro sforzi verso una casa comune, una mappa condivisa entro cui inserirsi, ognuna con le proprie peculiarità, le proprie diverse risorse, il proprio background e la propria professionalità.

Tutti gli oltre 70 processi individuati sono dunque stati inseriti come tessere nel mosaico complesso dello scheletro fornito dal file della casa-madre (e visibile qui sotto), andando a costituirne polpa e tessuti.

Fig. 3.3 La process Map aziendale

Per facilitare la condivisione e promuovere la conoscenza reciproca delle filiali tra loro, è stato predisposto un sistema di download/upload su server comune che ha permesso alle aziende di mantenere i propri processi in maniera univoca sulla propria base di dati, ma anche di confrontarli con gli altri in modo da stimolare così una proficua ricerca delle best practices, per usarle poi come leva al fine di superare i punti di debolezza intrinseci ad ogni azienda.

Il confronto tra le best practices è anzi uno degli strumenti più validi per implementare poi il Change Management, specialmente in ambito IT: dal confronto tra i differenti sistemi a supporto dello scambio informativo e della gestione delle basi dati sono già nate proficue migliorie tra i due siti di Beauchamp e Mandelieu, che migliorano la produttività della singola azienda ma anche la capacità di parlarsi, e dunque la comunicazione tra le due branche di MTU France. Da ciò, si intuisce che lo stesso concetto riportato su scala mondiale non può che portare benefici ancora maggiori.

L’utilizzo dello stesso software su scala nazionale ha semplificato notevolmente questo tipo di lavoro: accanto ad un database centralizzato, i tanti database locali, uniformati nel linguaggio grazie al corso di formazione a cui hanno partecipato rappresentanti di tutte le filiali mondiali del gruppo Tognum, hanno contribuito a velocizzare confronti, aprire discussioni condivise, e prendere pertanto decisioni più accurate.

La Process Map in uscita da questa fase del lavoro è pertanto un complesso documento di sintesi, a più strati, tra direttive aziendali a livello holding e considerazioni contestualizzate sul territorio di riferimento. Un tipico esempio per esplicitare questa convivenza a duplice livello di alcuni processi è la Messa in servizio: oltre ad un processo di riferimento a livello “corporate”, esistono delle sue variazioni/declinazioni a livello locale. Per esempio, nel sito di Beauchamp il know how aziendale per questa attività è particolarmente significativo per quanto riguarda i prodotti “Rail”, ossia di tipo ferroviario; nel sito di Mandelieu-La-Napoule, invece, ci si distingue per quanto riguarda il settore della nautica da diporto, ed in particolare nel segmento degli yacht, con clienti le cui dimensioni però talvolta rischiano di sfociare nel settore delle crociere. La Messa in servizio in questo caso dunque ha bisogno di essere ulteriormente specificata in un nuovo processo, denominato “Prove in mare”, per riuscire a descrivere con maggior efficacia e ad un livello di dettaglio più puntuale l’attività stessa.

Nel complesso, dunque, si può concludere che l’attività di Process Mapping ha fornito in output non solo una fotografia meramente “statica” della società, ma piuttosto una mappa flessibile, dinamica, piegata in avanti e “viva”, un sostrato fondamentale da cui partire per capire i punti di debolezza da correggere e quelli di forza su cui puntare, dopo la grande evoluzione accelerata – “rivoluzione” forse sarebbe un termine più adatto, in questo caso – che ha subito l’azienda negli ultimi mesi. Proprio dall’analisi di questi punti di forza e di debolezza, dunque, partiamo, per volgere il nostro strumento di Process Mapping in direzione Change Management.

4. Analisi punti di forza e di debolezza

L’analisi dei punti di forza e di debolezza dell’azienda può essere considerata come il primo passo verso l’effettuazione di un’analisi di tipo SWOT (Strengths, Weaknesses, Opportunities and Threats). Essa infatti consta di due diverse direttrici: l’analisi interna (quella, appunto, circa i punti di forza e debolezza) e quella esterna.

4.1 L’analisi interna

L’analisi interna è proprio quella mirata ad individuare i punti di forza e di debolezza della struttura (Strengths e Weaknesses, appunto). Il suo studio si caratterizza per il focus sugli elementi critici di competitività, ed un’analisi che prende in considerazione la catena del valore del Porter.

Fig. 4.1 La catena del valore del Porter

La catena del valore è una metodologia di analisi del vantaggio competitivo introdotta da Michael E. Porter, professore dell’Harvard Business School, nella metà degli anni 80.

Essa costituisce uno strumento valido per valutare dinamicamente se e quanto il vantaggio competitivo venga raggiunto, mantenuto e difeso. Tale strumento può

essere utilizzato quindi anche per considerare in maniera efficace e formalizzata le opportunità offerte dalle tecnologie dell'informazione.

La catena del valore permette, infatti, di considerare l'impresa come un sistema di attività generatrici del valore, inteso come il prezzo che il consumatore è disposto a pagare per il prodotto che soddisfa pienamente i propri bisogni.

Le tecnologie dell'informazione possono influenzare tali attività notevolmente, alcune volte migliorandone semplicemente l'efficacia, altre modificandole profondamente.

Le attività aziendali, per poter valutare la capacità competitiva di un’azienda, sono suddivise in nove categorie generali: cinque sono denominate attività dirette o primarie, quattro attività di supporto.

Le attività primarie sono:

1. logistica in entrata (beni che “entrano” nell’azienda)

2. attività operative (produzione di beni e servizi)

3. logistica in uscita (beni che “escono” dall’azienda)

4. marketing e vendite

5. servizi post-vendita (assistenza tecnico-commerciale, etc.)

Le attività di supporto vengono dette ausiliarie in quanto sostengono le attività primarie e, come scrive Porter si sorreggono a vicenda fornendo input acquistati, tecnologie, risorse umane e varie funzioni estensibili a tutta l’azienda. Si dividono in quattro categorie:

1. approvvigionamento (riguarda la problematica centrata sull’acquisto delle

risorse fisiche impiegate nella catena del valore)

2. sviluppo della tecnologia (si articola in una gamma di attività finalizzata al

3. gestione delle risorse umane (ricerca, selezione, assunzione, addestramento, formazione, aggiornamento, sviluppo, mobilità, retribuzione,sistemi premianti, negoziazione sindacale e contrattuale, etc.)

4. attività infrastrutturali (le altre attività quali: pianificazione, contabilità,

finanza, organizzazione, informatica, affari legali, direzione generale, etc.) Come quelle primarie, le attività di supporto sono scomponibili e disaggregabili in attività più specifiche ed elementari, proprie di ogni organizzazione nello sviluppo della tecnologia, per esempio, fra le attività specifiche possiamo elencare la progettazione dei particolari, il collaudo sul campo, l’ingegnerizzazione del processo e la scelta delle tecnologie.

In modo analogo l’approvvigionamento può essere suddiviso in attività tra le quali: la certificazione dei nuovi fornitori, l’approvvigionamento distinto dei diversi gruppi di acquisto, il monitoraggio continuo delle prestazioni e del servizio reso dai fornitori. Il vantaggio competitivo dipende da un migliore svolgimento di attività ad alto potenziale in termini di valore rispetto ai concorrenti.

Queste attività significative sul piano del contributo si chiamano attività “chiave”. Un’attività “chiave” è tale se ha e sviluppa un ampio potenziale per la riduzione dei costi e/o per la differenziazione. Diventano chiave e centrali alcune delle attività primarie e alcune delle attività ausiliarie in relazione al contesto interno e a quello ambientale.

4.2 L’analisi esterna

L’analisi esterna ha come fine quello di stabilire l’attrattività del settore. Il modello più utilizzato per questo scopo è quello delle 5 forze competitive del Porter.

Nella formulazione di una strategia un passo fondamentale è la definizione e lo studio delle principali caratteristiche del settore in cui si opera. Lo schema di riferimento più utilizzato per questo tipo di analisi è il modello delle 5 forze competitive di Porter, che, sulla base di alcuni fattori strutturali, descrive il sistema competitivo in cui opera l’azienda. La struttura competitiva di un settore dipende quindi dalla contemporanea interazione delle 5 forze competitive che sono:

1. Intensità della competizione tra imprese nello stesso settore; 2. Potere contrattuale dei fornitori

3. Potere contrattuale degli acquirenti (clienti)

4. Minacce derivanti dall’ingresso sul mercato di nuovi concorrenti (potenziali entranti)

5. Minacce derivanti dall’introduzione sul mercato di prodotti/servizi sostitutivi 4.2.1 Analisi dei concorrenti

Nell’analisi del mercato una speciale attenzione va posta sui concorrenti diretti, le altre imprese che operano sullo stesso mercato nello stesso settore produttivo. Secondo questo schema ci sono in genere 5 fattori che determinano la posizione competitiva di ciascun concorrente:

- La concentrazione: si riferisce al numero di imprese operanti in un dato mercato. Nel caso infatti ci sia una sola impresa leader quest’ultima avrebbe un notevole potere discrezionale nell’imporre i propri prezzi al mercato. Quando invece il settore è frammentato, costituito cioè da molte imprese, allora è più difficile controllare i prezzi ed è facile che questi si riducano (guerra dei prezzi). - La diversità strutturale: quanto più le imprese si assomigliano per obiettivi, strategie, strutture di costo, origini, tanto più difficile sarà sottrarsi alla concorrenza basata solo sul prezzo.

- La differenziazione dell’offerta: quanto più i prodotti offerti alla clientela saranno simili tra le imprese, tanto più il cliente è disposto a scegliere in base unicamente al prezzo; questo spinge le imprese a ribassare ulteriormente i prezzi nella speranza di incrementare le vendite.

- La capacità produttiva: se c’è eccesso di capacità produttiva le aziende sono incoraggiate ad abbassare i prezzi per ricevere più ordini e riuscire a distribuire i costi fissi su un volume di vendite più ampio. Inoltre è da sottolineare che investimenti in capacità produttiva elevati possono essere difficilmente smobilizzabili in breve tempo, costituendo delle vere “barriere all’uscita” dal mercato.

- Struttura di costo: in termini di rapporto tra costi fissi e costi variabili.

L’obiettivo dello schema di analisi è quello di avere un quadro completo di come si muovono gli attori nel mercato reale, con riferimento alle loro strategie attuali messe a

confronto con la strategia attuale della nostra azienda. 4.2.2 Analisi dei Clienti

In questo tipo di analisi si fa riferimento ai principali clienti dell’azienda, quelli il cui peso contrattuale è in grado di indurre comportamenti tali da ridurre i margini di profitto (riduzione dei prezzi, miglioramenti della qualità o del servizio). Il potere contrattuale dei clienti è influenzato dai seguenti fattori:

- Dimensioni degli acquisti: ovviamente se il volume di acquisti generato dallo stesso cliente è una parte notevole del fatturato totale, tanto maggiore è il potere contrattuale del cliente, specialmente quando può avere lo stesso prodotto da altri abbastanza facilmente.

- Concentrazione della clientela: quanto più basso è il numero di clienti che l’azienda ha nel proprio portafoglio, tanto maggiore sarà il loro potere contrattuale.

- Possibilità di integrazione verticale: questo punto fa riferimento alla possibilità che ha un cliente di scegliere se comprare un dato prodotto oppure se produrlo da se. Per esempio si pensi ad un commerciante di abbigliamento all’ingrosso che, invece di continuare a comprare i capi da altre imprese

manifatturiere, decida di produrre con un proprio marchio attraverso propri stabilimenti oppure attraverso contoterzisti. Nel caso questo accada l’azienda avrebbe perso un cliente e guadagnato un concorrente. Questo è un caso di integrazione verticale: un distributore che sceglie di integrarsi a monte con il settore della produzione.

4.2.3 Analisi dei fornitori

Analogamente ai clienti, l’analisi dei fornitori mira a mettere in evidenza chi sono e come possono influire sulla capacità competitiva dell’azienda i principali fornitori. I fornitori possono influenzare l’intero ciclo di approvvigionamento attraverso il livello dei prezzi di acquisto, le modalità di pagamento (dilazionate o no), la qualità e la continuità delle forniture, il livello dell’assistenza tecnica se necessaria, la puntualità nelle consegne. la forza contrattuale del fornitore dipende dai seguenti elementi:

- % di acquisti presso un unico fornitore: se esistesse un unico fornitore probabilmente avrebbe un potere elevatissimo, visto che senza di lui

l’azienda chiuderebbe.

- Esistenza di prodotti sostitutivi: se il bene che il fornitore procura ha delle caratteristiche esclusive, allora tanto maggiore sarà il potere contrattuale dello stesso. In questo caso l’azienda non può sostituire il fornitore almeno fino a quando non trova un altro che venda un prodotto con le stesse caratteristiche. - Costi di cambiamento del fornitore: quanto maggiori sono le spese (risoluzione di contratti prima del termine, ecc) in caso di interruzione dei rapporti con il fornitore e maggiore sarà il suo potere contrattuale. Anche in assenza di clausole contrattuali onerose, ci possono essere delle consistenti diseconomie legate al fatto che il nuovo

fornitore può non accordarci lo stesso sconto, o lo stesso livello di servizio del precedente.

- Possibilità di integrazione verticale: come visto in precedenza nell’analisi della clientela, in questo caso un fornitore di filati può decidere di produrre magliette e capi d’abbigliamento, oppure può integrarsi con la distribuzione creando “a valle” un proprio canale distributivo.

4.2.4 Analisi dei potenziali entranti e dei prodotti sostitutivi

La minaccia di potenziali entranti dipende dalle cosiddette “barriere all’entrata”. Quanto più esse saranno alte tanto più difficile sarà entrare nel mercato; quanto più alte saranno, tanto più protette saranno le imprese che sono riuscite ad entrare. Le tradizionali barriere all’entrata sono :

- La dimensione degli investimenti necessari - L’identità del brand

- L’accesso ai canali di distribuzione

- Le economie di scala e di apprendimento - Le politiche governative

4.2.5 Analisi dei prodotti sostitutivi

L’altro tipo di minaccia esterna è la possibilità che ci siano prodotti sostitutivi. Questa minaccia impone spesso un tetto ai prezzi praticabili al consumatore/cliente, oltre il quale il cliente troverà conveniente passare da un prodotto all’altro. Tuttavia la minaccia esiste solo se c’è un elevato grado di similitudine tra i prodotti, ed inoltre solo se i costi di riconversione, ossia i costi che il consumatore dovrà sostenere nel passare da un prodotto all’altro, siano modesti. I costi di passaggio da un prodotto all’altro si possono riassumere in quelli dovuti alla poca dimestichezza con il nuovo prodotto, necessità di adattamento, possibilità che non soddisfi pienamente i bisogni

del cliente, ecc.

Nella figura seguente viene illustrato lo schema del modello delle 5 forze competitive di Porter nella sua veste grafica tradizionale: