Università degli studi di Padova
Dipartimento di Tecnica e Gestione dei Sistemi Industriali
Corso di Laurea Magistrale in Ingegneria Gestionale
Project Management applicato allo
sviluppo di nuovi prodotti:
il caso AtTask in Selle Royal S.p.A
Relatore
Prof. Chiara Verbano
Correlatore
Ing. Andrea Cecchinato
Laureando
Pier Andrea Dolzan
Anno Accademico: 2013-2014
II
INDICE
Ringraziamenti .......................................................................... VII
Introduzione ................................................................................................................ IX
Obiettivi e metodo .................................................................... 1
Capitolo 1: Il Project Management ...................................... 9
1.1
COS’È UN PROGETTO? .............................................................................. 10
1.2
IL MODELLO DI PROJECT MANAGEMENT ......................................... 11
1.3
TOTAL LIFECYCLE PROJECT MANAGEMENT ................................... 12
1.3.1
La triade concettuale del Project Management ...................................... 13
Capitolo 2: Organizzazione della funzione di Project
Management ....................................................... 15
2.1
2.2
L’UNITÀ ORGANIZZATIVA DI PROGETTO ......................................... 15
2.1.1
L’organizzazion a matrice ......................................................................... 17
2.1.2
La task force di progetto ............................................................................ 18
LA COLLOCAZIONE ORGANIZZATIVA DEL PROJECT
MANAGER E IL PROJECT MANAGEMENT OFFICE........................... 19
Capitolo 3: Avvio e pianificazione del progetto ............. 21
3.1
LA PIANFICAZIONE DEL PROGETTO ................................................... 22
3.2
LE BEST PRACTICES NELLA PIANIFICAZIONE OPERATIVA DEI
PROGETTI ...................................................................................................... 24
3.2.1
Creazione della Work Breakdown Structure per la scomposizione del
progetto ........................................................................................................ 26
III
3.2.2
La schedulazione delle attività di progetto ............................................. 27
3.2.3
Il metodo del percorso critico (Critical Path Method) e gli scorrimenti 28
3.2.4
Il diagramma di Gantt ................................................................................ 31
3.2.5
Pianificazione delle risorse e tecniche di livellamento del carico
di lavoro ....................................................................................................... 32
Capitolo 4: Controllo delle performance di progetto .....
37
4.1
CONTROLLO DELL’AMBITO DI PROGETTO ...................................... 39
4.2
CONTROLLO INTEGRATO DEI TEMPI E DEI COSTI
DI PROGETTO .............................................................................................. 39
4.3
4.2.1
Ottimizzare la distribuzione delle risorse economiche nel tempo ...... 41
4.2.2
Un primo modello di controllo: la misurazione dell’avanzamento
del progetto a fronte della sua schedulazione ........................................ 45
4.2.3
Il modello dell’earned value ........................................................................ 46
CHIUSURA O ESTENSIONE DEL PROGETTO ..................................... 50
Capitolo 5: Il Project Portfolio Management strategico
53
5.1
I PROGETTI CHE FANNO CRESCERE UN’AZIENDA ........................ 53
5.2
IL PROJECT PORTFOLIO MANAGEMENT ........................................... 55
5.2.1
Obiettivi e vantaggi del Project Portfolio Management ........................ 57
5.2.2
Selezione e priorità dei progetti di un portfolio ..................................... 57
5.2.3
Gestione delle risorse aziendali e delle operazioni negli ambienti
multiprogetto............................................................................................... 59
Capitolo 6: Il sistema informativo di Project
Management ............................................................................ 61
6.1
IL SISTEMA INFORMATIVO INTEGRATO DI PROJECT
MANAGEMENT .......................................................................................... 61
6.1.1
6.2
IV
Cos’è un sistema informativo di Project Management? ........................ 62
SISTEMI INFORMATIVI DI PROJECT MANAGEMENT
WEB BASED .................................................................................................. 63
6.3
6.4
CATEGORIE DI SOFTWARE DI PROJECT MANAGEMENT .............. 65
6.3.1
Software di Process Management ............................................................ 65
6.3.2
Software di Schedule Management ......................................................... 66
6.3.3
Software di Cost Management ................................................................. 66
6.3.4
Software di Communication Management ............................................. 67
IL PROCESSO DI SELEZIONE DEI SOFTWARE DI PROJECT
MANAGEMENT ........................................................................................... 67
Capitolo 7: Selle Royal S.p.A .............................................. 71
7.1
SELLE ROYAL S.p.A .................................................................................... 72
7.2
STORIA DEL GRUPPO SELLE ROYAL .................................................... 75
7.3
LO SVILUPPO INDUSTRIALE ................................................................... 76
7.4
ESPENSIONE DEL MERCATO .................................................................. 78
7.5
BRAND DIVERSIFICATION ...................................................................... 79
Capitolo 8: Analisi della situazione AS IS nella gestione
dei progetti di sviluppo nuovo prodotto ........................... 85
8.1
STRUTTURA ORGANIZZATIVA PER LA GESTIONE
DEI PROGETTI .............................................................................................. 86
8.2
IL CONTESTO DEI PROGETTI DI SVILUPPO NUOVO
PRODOTTO ................................................................................................... 89
8.3
8.4
8.2.1
Classificazione dei progetti in Selle Royal S.p.A.................................... 89
8.2.2
Distribuzione commerciale: i canali di vendita ...................................... 92
IL PROCESSO DI SVILUPPO NUOVO PRODOTTO:
ANALISI AS IS .............................................................................................. 95
8.3.1
Analisi critica delle modalità AS IS di gestione delle
Proposte Nuovo Prodotto ......................................................................... 96
8.3.2
Analisi critica delle modalità AS IS di gestione
delle correlazioni e dei progetti .............................................................. 104
PROBLEMI EMERSI NELL’ATTUALE GESTIONE DEI
PROGETTI ................................................................................................... 106
V
8.5
LA SCELTA DI ATTASK........................................................................... 110
Capitolo 9: Analisi e implementazione di AtTask ......... 115
9.1
ANALISI PRELIMINARE DEGLI
OBIETTIVI DELL’IMPLEMENTAZIONE
DI ATTASK (Gathering Requirements) ...................................................... 116
9.2
TRAINING DEL CORE IMPLEMENTATION TEAM
E DEI TEAM MEMBER COINVOLTI NEI PROCESSI
DI SVILUPPO PRODOTTO (Schedule Education) ................................... 117
9.3
RE-ENGINEERING DEI BUSINESS
PROCESSES DI SELLE ROYAL E
CONFIGURAZIONE DI ATTASK (AtTask Configuration) ................... 119
9.3.1 Definizione del flusso delle richieste per l’apertura di
nuovi progetti......................................................................................................... 120
9.4
9.3.2
Categorizzazione dei progetti: portfolio e programmi ....................... 125
9.3.3
Mappatura del processo di gestione sviluppo nuovo prodotto ......... 127
9.3.4
Definizione e configurazione dei reports .............................................. 132
ESECUZIONE DEL TEST PILOTA (Pilot Test)....................................... 137
Conclusioni e futuri sviluppi .............................................. 141
Bibliografia ............................................................................. 145
Sitografia ................................................................................. 146
VI
Ringraziamenti
Ripercorrendo i cinque anni dedicati, nell’Università di Padova, allo studio di
Ingegneria Gestionale, giunto ormai al traguardo, mi accorgo che numerose
sono le persone che hanno contribuito a formare la persona che oggi sono.
Desidero ringraziare innanzitutto la mia famiglia per il grande aiuto e sostegno
che mai mi è mancato nella mia vita e in questi cinque anni accademici. Un
ringraziamento anche a mia sorella che con i suoi preziosi consigli mi ha aiutato
a vivere con più tranquillità e secondo la sua filosofia l’università.
Sono riconoscente a tutti gli amici che mi sono sempre stati vicini e hanno
pazientemente sopportato i miei continui ritardi dovuti allo studio, ed in
particolare a Irene che mi è sempre stata vicina lungo questo percorso. Ricordo
con affetto i miei compagni di corso e di Università con i quali sono certo di
continuare la forte e sincera amicizia scaturita, o rafforzatasi, nell’ambiente
accademico.
Un ringraziamento doveroso va fatto all’Ing. Andrea Cecchinato, che ha
creduto in me dandomi la possibilità di intraprendere un nuovo affascinante
percorso nel mondo del lavoro. Un ringraziamento speciale anche a tutti i
colleghi di Selle Royal per avermi accolto in ufficio sempre con il sorriso.
Un ultimo ringraziamento, last but not least, alla professoressa Chiara Verbano,
mia Relatrice, per i preziosi insegnamenti, per le numerose ore dedicate alla mia
tesi e per la grande pazienza e professionalità sempre dimostratami.
Pier Andrea
Cassola, 10 Ottobre 2014
VII
VIII
INTRODUZIONE
Questa tesi è stata sviluppata durante lo stage svolto all’interno di Selle Royal
S.p.A., presso lo stabilimento di Pozzoleone.
Selle Royal S.p.A, è l’azienda leader nella produzione di selle, con sei sedi
produttive sparse nel mondo ed una rete commerciale che opera in più di 70
paesi. Il
suo
core
business riguarda la progettazione, produzione
e
commercializzazione di selle da bicicletta, dove, grazie ai diversi brand di
proprietà, è diventata leader nei segmenti “Recreational” (con il marchio Selle
Royal), “Lifestyle” (con Brooks England), “Racing” e “MTB” (con Fi’zi:k, il
marchio di punta dell’azienda). Inoltre, negli ultimi anni, tramite l’acquisizione
di nuove società, ha iniziato un processo di espansione verso il mercato degli
accessori per ciclo (come borsette, lucette, manubri, pedali, ecc…) e dei prodotti
di abbigliamento legati all’utilizzo della bicicletta, diventando la quarta
“potenza mondiale” operante nel settore del ciclismo.
In questo elaborato viene eseguita un’analisi delle logiche attualmente in uso in
Selle Royal per la gestione dei progetti di sviluppo nuovo prodotto. Questo
studio permette pertanto di osservare come la ridefinizione delle procedure
operative, secondo i principi che caratterizzano la teoria del Project Portfolio
Management, e la parallela introduzione di un software specializzato,
permettano di minimizzare i problemi legati alla tipica gestione destrutturata
dei progetti.
IX
Dopo una parte introduttiva dove vengono descritte le principali tecniche del
Project Portfolio Management, si è analizzato il caso di Selle Royal, con l’intento
di fare uno studio preliminare sulle attuali modalità di gestione adottate nei
progetti di sviluppo prodotto, per poi delineare dei possibili interventi di
miglioramento. Le azioni apportate hanno interessato principalmente una
ridefinizione
dei
ruoli
e
della
categorizzazione
dei
progetti,
oltre
all’introduzione di un nuovo sistema informativo che ha favorito l’adozione dei
processi e delle tecniche tipiche del Project Management (piano di progetto in
fase di apertura, diagramma di Gantt per la pianificazione, controllo e chiusura)
per la gestione di tali progetti.
Questo percorso ha perciò messo in evidenza alcuni dei benefici che si possono
ottenere gestendo progetti unici e irripetibili tramite il ricorso a processi e
tecniche standard come quelle descritte nella letteratura del Project
Management.
X
OBIETTIVI E METODO
Il particolare quadro economico di questi ultimi decenni, caratterizzato da un
incremento esponenziale della complessità dei prodotti, dei servizi e dei
processi, affiancato ad una parallela e contrapposta riduzione del time-tomarket e dei margini, ha obbligato le piccole e medie imprese ad innovare il
proprio tessuto organizzativo e le proprie strategie per adattarsi alle continue
turbolenze e riuscire ancora a competere con successo in tali mercati. A partire
dalla fine degli anni ’70, l’abolizione delle barriere commerciali ha favorito la
diffusione della globalizzazione, che ha portato ad un notevole incremento
della pressione competitiva. Questo fenomeno ha perciò comportato un
profondo cambiamento nelle logiche che stanno alla base del mercato. Oggi,
infatti, grazie all’internazionalizzazione del commercio, il consumatore ha la
possibilità di scegliere tra un’enorme varietà di prodotti ed acquistare pertanto
l’articolo con le caratteristiche tecniche ed economiche che maggiormente lo
soddisfano. Per riuscire a sopravvivere in questo nuovo contesto, altamente
concorrenziale e dinamico, in cui il fulcro centrale è il cliente, le aziende devono
essere in grado di anticipare i trend, sviluppando prodotti innovativi e a prezzi
sempre più competitivi.
Di qui la necessità di disporre di un approccio gestionale flessibile, che consenta
di far fronte all’estrema variabilità delle richieste, ma che al tempo stesso si basi
su principi e tecniche comuni. Il nuovo paradigma manageriale in grado di
gestire queste criticità, e che nel corso degli ultimi anni si sta dimostrando
1
ideale per riuscire ad affrontare questa particolare situazione, è conosciuto
come Project Portfolio Management.
Come sottolineato poco sopra, al giorno d’oggi per le aziende è fondamentale
riuscire ad anticipare i competitors nello sviluppo di prodotti all’avanguardia,
mantenendo al contempo un buon rapporto qualità-prezzo. Si vuole dunque
rimarcare come l’applicazione dei concetti del Project Portfolio Management sia
adatta alla gestione dei progetti di sviluppo nuovo prodotto, in quanto,
nonostante la loro eterogeneità, il ricorso ai processi standard che caratterizzano
questa filosofia manageriale permettono di garantire un elevato livello di
efficienza ed efficacia grazie a:
miglioramento dei processi decisionali;
maggiore integrazione fra gli attori coinvolti;
trasparenza del progetto e riduzione dei rischi ad esso legati.
Il presente elaborato ha perciò l’obiettivo di descrivere come può essere gestito
il dualismo esistente tra l’univocità del progetto e la ripetitività dei processi che
consentono di passare dal piano di gestione alla sua esecuzione, nonché i
vantaggi che essi consentono di ottenere in termini di riduzione delle
tempistiche e degli investimenti da affrontare nel corso del progetto per riuscire
ad aumentare la propria competitività.
Tuttavia il successo del cambiamento verso un sistema organizzativo teso alla
gestione per progetti richiede una trasformazione contemporanea su più fronti,
riconducibili al rinnovamento della cultura e del comportamento interno, alla
struttura organizzativa, ai modelli di comunicazione da adottare e alla maturità
del relativo processo di sviluppo. Cambiare in azienda, infatti, non significa
solamente apportare delle modifiche, a livello organizzativo, nella gestione del
processo e quindi nella ridefinizione delle responsabilità e dei compiti di
ciascun membro, ma vuol dire soprattutto cambiare da un punto di vista
culturale, di attitudine delle persone a seguire delle linee guida ben chiare e
definite per ottenere il miglior risultato possibile. Infine, a tutti questi
2
cambiamenti organizzativi e culturali diventa fondamentale affiancare
l’introduzione di un sistema informativo, in grado di supportare efficacemente
le persone e le relazioni che governano l’intero processo, così da garantire il
successo dei progetti sviluppati. Dal momento che buona parte del lavoro
svolto si focalizza sull’implementazione di un software di Project Management,
questo lavoro permette infine di osservare come uno strumento di questo tipo
riesca a migliorare l’efficienza nella gestione di progetti complessi, che possono
prevedere l’esecuzione di attività in siti produttivi che si trovano anche a
migliaia di chilometri l’uno dall’altro.
Dopo un’approfondita trattazione della letteratura, per confermare come il
Project Portfolio Management possa essere la strada per le PMI per riuscire a
emergere in un mercato così aggressivo, nel corso dell’elaborato viene
approfondito il caso di Selle Royal S.p.A, un’azienda del territorio che opera
all’interno di un contesto internazionale e che sta iniziando ad abbracciare i
concetti propri di questa nuovo approccio manageriale, concentrando
prevalentemente l’attenzione sull’analisi delle motivazioni che ne hanno spinto
l’adozione e i principali benefici ottenuti.
Il Gruppo Selle Royal è attualmente attivo nella progettazione, produzione e
commercializzazione di selle da bicicletta, accessori per ciclo e prodotti di
abbigliamento per l’utilizzo della bicicletta. Ad oggi il Gruppo, tramite i propri
brand, è leader nei mercati “Recreational”, “Racing”, “Lifestyle” e “MTB”, e lo
stabilimento di Pozzoleone rappresenta il punto di riferimento per la
produzione di selle per le due ruote.
Una
premessa
fondamentale
per
poter
effettuare
qualsiasi
tipo
di
considerazione futura riguarda l’ambito di riferimento in cui opera Selle Royal,
che non è strettamente limitato alla gestione del singolo progetto, quanto
piuttosto alla gestione contemporanea di un numero considerevole di iniziative
che concorrono al raggiungimento di una strategia aziendale comune,
“sfruttando” risorse umane ed economiche appartenenti ad un medesimo pool,
ossia il cosiddetto portfolio. Da sottolineare che tra i numerosi progetti
3
sviluppati da Selle Royal, una quantità sempre maggiore viene eseguita da
Justek, precisamente nello stabilimento di Jiangyin (Cina). Infatti, a partire dal
2010, Selle Royal S.p.A ha acquisito il 52% di Justek, una delle aziende leader
nella produzione di selle per il mercato “Recreational” del Far East, diventando
così il più grande produttore mondiale di selle. L’oggetto del presente elaborato
non sarà pertanto circoscritto ai soli progetti gestiti nel plant italiano di
Pozzoleone, ma si estenderà in parte anche a quei prodotti che vengono ideati e
progettati in Italia, per poi essere industrializzati e prodotti in Cina: l’ambito
dell’analisi è quindi quello del Project Portfolio Management, a cui si aggiunge
l’ulteriore complicazione derivante dalla gestione internazionale di alcuni dei
progetti sviluppati.
Alla luce di queste premesse è chiaro come il contesto in cui si inserisce il caso
in questione riguardi la gestione del processo di sviluppo nuovo prodotto,
ritenuto particolarmente critico all’interno del Gruppo, in quanto di primaria
importanza per riuscire a mantenere la leadership mondiale, e continuare a
guidare l’innovazione da protagonisti. Infatti, nonostante l’importanza centrale
riconosciuta a tali processi, in Selle Royal vi sono ancora delle lacune nelle
relative modalità di gestione. Da qui la necessità di intervenire apportando
delle modifiche sostanziali e l’opportunità di svolgere uno stage all’interno del
Gruppo.
Durante questo periodo di tirocinio, in collaborazione con un team di
cinque/sei persone, sono state ridefinite prima di tutto le procedure da adottare
per migliorare la gestione dei progetti di sviluppo nuovo prodotto secondo le
logiche del Project Portfolio Management, per poi passare ad introdurre un
nuovo Project Management Information System (PMIS). Ma, come è stato detto
prima, il passaggio da una filosofia manageriale ad un’altra deve essere
affiancato da un parallelo rinnovamento della cultura aziendale. È risultato
perciò fondamentale, in questo arco di tempo, dopo un approfondito studio
della teoria, cominciare a diffondere i principi del Project Management e
sensibilizzare i principali enti coinvolti nel processo, mettendo in risalto come
4
l’efficienza delle loro prestazioni potesse migliorare con l’introduzione delle
nuove logiche e dei relativi strumenti a supporto.
Per riuscire a comprendere come il Project Management possa essere la chiave
di volta per migliorare la risposata delle aziende alle richieste sempre più
esigenti dei clienti, e come l’univocità tipica di ciascun progetto possa essere
gestita tramite delle tecniche standard indipendenti dallo specifico contesto, si
parte da un’approfondita analisi della letteratura. Nel primo capitolo si fornisce
una definizione dettagliata di progetto, in cui vengono specificate tutte le
caratteristiche intrinseche che esso deve avere per poter essere considerato tale.
Una volta chiarito questo concetto primario si introduce il tema del Project
Management, soffermandosi sulle principali linee guida che stanno alla base di
questa filosofia, come il Total life cycle project management, e sulla tipica
articolazione in cinque fasi della gestione del progetto. In questo primo capitolo
si comincia dunque a contestualizzare il dualismo esistente tra il concetto di
progetto e quello di processo di gestione.
Nel secondo capitolo ci si sofferma sulla descrizione delle principali figure
(in particolare quella del Project Manager e del Project Management Office) e
strutture organizzative dedicate alla gestione per progetti, elencandone per
ciascuna pregi e difetti in funzione della realtà in cui esse si trovano. Si
individuano pertanto le figure con un ruolo fondamentale all’interno del
processo, e i compiti che ognuno di loro deve svolgere per aumentare
l’efficienza nella gestione dei progetti.
Nei capitoli tre e quattro vengono poi approfondite, in tutte le loro
sfumature, le cinque fasi della gestione del progetto: avvio, pianificazione,
esecuzione, monitoraggio e controllo, chiusura. Qui vengono quindi riassunti i
principali concetti su cui si fonda la teoria del Project Management, analizzando
con particolare attenzione le best practices attualmente esistenti per la
pianificazione e il controllo dei progetti. Esse rappresentano le principali
tecniche adottate dalle aziende che abbracciano la filosofia del Project
Management e che hanno permesso a queste ultime di ottimizzare e migliorare i
propri risultati in termini di riduzione dei tempi e dei costi sostenuti.
5
Dopo aver assimilato i concetti propri del coordinamento del singolo
progetto, nel capitolo cinque viene presentato un breve excursus sulla gestione
del portfolio. I progetti infatti, non devono essere gestiti come entità isolate
indipendenti l’una dall’altra, ma come insiemi coerenti e ben assortiti finalizzati
ad implementare la strategia aziendale. Vengono quindi approfonditi i temi
della selezione e della prioritizzazione del portfolio, sottolineando i vantaggi e i
benefici ottenibili da una loro applicazione, come la massimizzazione del valore
del portfolio e la sua coerenza con la strategia aziendale.
Infine, il capitolo sei termina con una breve rassegna sulle principali
tipologie di software al supporto della gestione per progetti. Come detto sopra
infatti, ai cambiamenti organizzativi e culturali è importante affiancare
l’introduzione di nuovi strumenti in grado di migliorare l’efficacia delle
persone nella gestione delle diverse situazioni che si trovano ad affrontare.
Con il capitolo sei si chiude dunque l’analisi della letteratura, che ha permesso
di comprendere quali sono le migliori strategie operative che possono essere
adottate per migliorare l’efficienza nella gestione dei progetti. A questo punto,
dopo averne assimilato i contenuti essenziali, si può passare all’analisi del caso
Selle Royal S.p.A, che ricordiamo aver intrapreso un percorso di cambiamento
finalizzato
al
miglioramento
della
gestione
dei
progetti,
attualmente
contraddistinta da alcune carenze organizzative e strumentali.
Questa seconda parte inizia perciò con il capitolo sette, dove si ripercorrono
le fasi salienti della storia dello stabilimento di via Vittorio Emanuele a
Pozzoleone, in cui oggi ha sede Selle Royal S.p.A. Si apre con una breve
descrizione della sua struttura organizzativa, con una parentesi anche del
profilo economico, per poi proseguire con la presentazione delle principali
tappe storiche che hanno portato il gruppo a diventare leader in Italia e nel
mondo per la produzione di selle.
Dopo aver delineato il quadro d’insieme della storia della holding, nel
capitolo successivo si esamina lo specifico contesto in cui si inseriscono i
progetti di sviluppo nuovo prodotto. Tramite l’approccio bottom-up, fondato
sull’analisi preliminare del materiale aziendale interno, in cui sono
6
documentate le principali linee guida e procedure operative, e sul learning by
doing, in cui si affiancano i principali responsabili del processo, si ottiene una
panoramica abbastanza fedele dell’attuale classificazione dei progetti utilizzata
in Selle Royal, nonché della struttura organizzativa adibita alla loro gestione. A
partire da tale studio, presentato nel capitolo 8, sono perciò emersi con
chiarezza molti dei problemi che hanno fatto maturare nella direzione la
convinzione che per migliorare tale situazione fosse necessario apportare dei
cambiamenti sostanziali.
A questo punto, una volta analizzata la situazione AS IS e individuati i
problemi presenti, i concetti assimilati con lo studio della letteratura e l’apporto
fornito dai consulenti di AtTask (che, come testimonia il sito, sono tutti
certificati PMP) hanno permesso di cominciare ad apportare dei miglioramenti,
alimentando ed evolvendo pian piano i processi e le tecniche tipicamente
utilizzate dalla filosofia del Project Management. Nel capitolo nove viene perciò
riassunto il percorso di avvicinamento all’introduzione del nuovo software di
Project Management, osservando come la sua introduzione abbia permesso
all’azienda di cominciare a mettere in pratica i concetti fondamentali del Project
Management: apertura formale del progetto con presentazione degli obiettivi,
pianificazione dettagliata delle tempistiche di tutte le attività che lo
compongono, processo di monitoraggio puntuale sull’avanzamento del
progetto ed infine chiusura contabile dello stesso.
Infine, per concludere, vengono descritti i principali benefici che questo
percorso di riorganizzazione permette di raggiungere in termini di efficacia ed
efficienza nella gestione dei progetti.
7
8
1 IL PROJECT MANAGEMENT
Quando si parla di Project Management ci si riferisce ad un sistema gestionale orientato
ai risultati e basato sulla “gestione sistemica di un'impresa complessa, unica e di durata
determinata, rivolta al raggiungimento di un obiettivo chiaro e predefinito, mediante un
processo continuo di pianificazione e controllo di risorse differenziate e con vincoli
interdipendenti di costi-tempi-qualità” (Archibald, 2004, p.9).
Riflettendo sulla definizione di Project Management data da Archibald è
evidente come la nascita e la crescita di questa nuova filosofia possa portare,
nell’azione e nella cultura manageriale radicata all’interno delle nostre aziende,
un’eccellente ventata di innovazione. La crescita della complessità degli
apparati produttivi ha condotto ad un’eccessiva cristallizzazione della
dimensione organizzativa, con strutture poco flessibili, e decisamente slegate
dagli obiettivi del singolo progetto, ostacolando dunque la nascita di piccole
soluzioni diversificate, che fossero perfettamente allineate agli obiettivi
specifici. Di fronte alle continue domande e sfide poste dall’ambiente in cui
viviamo oggi, caratterizzato da un susseguirsi di cambiamenti turbolenti e
talvolta traumatici, questa eccessiva standardizzazione nel modo di operare,
che come si può ben comprendere è diametralmente opposta ai concetti su cui
si fonda la teoria del project management, è stata la causa principale della
staticità di questi apparati nel fornire delle risposte opportune a tali
cambiamenti.
9
Dunque è proprio la rapidità del mondo che caratterizza i nostri giorni che ha
obbligato le aziende ad abbandonare gradualmente la centralizzazione delle
attività, tipica di questi apparati paralizzati, per passare a “sistemi adattivi,
temporanei, formati da diversi specialisti e valutatori di problemi, legati
insieme da specialisti coordinatori e valutatori di compiti” (Archibald, 2004,
p.30) che permettono di far fronte più efficacemente a tale dinamicità del
mercato.
1.1 COS’È UN PROGETTO?
Prima di cominciare a parlare di project management a tutti gli effetti è
necessario innanzitutto dare una definizione preliminare di progetto.
Un progetto è uno sforzo complesso con un inizio e una fine ben definiti, un complesso
coordinato d’azioni finalizzato a creare un prodotto, un servizio o un risultato unico e
determinato, nel rispetto dei limiti stabiliti di tempo e di risorse impiegati per
raggiungere tale obiettivo finale. Si noti che il progetto non coincide con il suo risultato
finale, che potrà essere un nuovo prodotto, un nuovo processo produttivo o una nuova
struttura organizzativa, quanto piuttosto con il processo con il quale si ottiene il nuovo
risultato finale. Un progetto inoltre per definizione è caratterizzato da un elevato livello
di incertezza circa i tempi e i costi da sostenere per il conseguimento dei risultati
stabiliti, grado di incertezza che diminuisce mano a mano che vengono completate le
varie fasi del ciclo di vita (Project Kerzner Harold, 2005; Baglieri et al., 2004;
PMBOK Guide).
Nonostante l'estrema eterogeneità dei progetti esistenti, aventi ciascuno risultati
e obiettivi diversi, è possibile affermare che i principi del project management
moderno hanno validità universale, nel senso che risultano appropriati a tutti i
settori applicativi, pur con significative varianti nella pianificazione di dettaglio
e nell’esecuzione, fra i diversi contesti culturali nei quali essi si svolgono.
10
1.2 IL MODELLO DI PROJECT MANAGEMENT
I progetti, per riuscire a raggiungere i risultati prefissati, nel rispetto dei vincoli
assegnati di tempo e di costo, devono essere accuratamente concepiti e gestiti
sin dalla fase iniziale di pianificazione. L’assenza di una precisa analisi iniziale,
finalizzata alla corretta selezione dei progetti e alla concezione/definizione
progettuale, comporta una serie di limiti, tra cui in primis il rischio di allocare
risorse preziose (denaro, competenze, impianti, tempo) a iniziative che
potrebbero
non
avere
successo,
e
la
conseguente
esposizione
dell’organizzazione a rischi inaccettabili di ordine finanziario e concorrenziale.
Diversamente, il fatto che il project management non sia all'altezza nelle fasi di
pianificazione ed esecuzione dei progetti porta ad un costante ritardo nel lancio
di nuovi prodotti, con conseguenze negative sugli obiettivi aziendali, nonché
alla riduzione degli utili attesi a causa di costi eccessivi, ritardi e penali. In
figura 1.1 sono rappresentate tutte le fasi che costituiscono un classico processo
di gestione dei progetti.
Figura 1.1 Rappresentazione delle fasi di gestione del progetto (documento interno aziendale).
11
1.3 TOTAL LIFE CYCLE PROJECT MANAGEMENT
Prima che il concetto di Project Management affondasse le sue radici in ambito
aziendale un progetto, molto spesso concepito e autorizzato in maniera
approssimativa, veniva affidato a un project manager, il quale aveva il compito
di pianificare, schedulare e monitorare il corso delle sue fasi esecutive. Tuttavia
i numerosi insuccessi ottenuti nel conseguimento degli obiettivi di progetto, cui
questo modo di operare ha inevitabilmente portato, ha evidenziato come i
metodi di project management dovessero essere applicati sin dalle prime fasi
iniziali di concezione del progetto. In altri termini, oggi l’importanza primaria
del total life cycle management, combinato con il risk management, è riconosciuta
come mezzo per assicurare che i progetti approvati siano coerenti con gli
obiettivi strategici dell’organizzazione e comportino rischi accettabili (di natura
concorrenziale, economica, politica, di costo e di tempo) in merito al loro
raggiungimento (Archibald, 2004).
Naturalmente, come sostengono Desaulniers e Anderson (2001), il ciclo di vita
progettuale non è un processo rigido e immutabile; gli obiettivi, l’impostazione
organizzativa e le tecniche di management adottate, infatti, devono essere
concepiti e gestiti diversamente di volta in volta, in quanto influenzati dalle
specifiche caratteristiche organizzative, dal grado di familiarità con le tecniche
da impiegare e dalla pressione concorrenziale che induce ad avviare il progetto
in questione. Queste rappresentano le tre variabili lungo le quali si
contraddistingue il peculiare contesto in cui si opera. Ne consegue dunque che
il successo di un progetto non dipende tanto dalla logica e dalla
consequenzialità intrinseca della distribuzione dei ruoli, delle responsabilità e
delle risorse, quanto piuttosto dall’adattamento delle varie parti agli elementi
esterni, e dall’abilità del project manager nel comprendere tale contesto, in
modo da riuscire a definire e stabilire i nessi utili al successo dell’iniziativa.
Tuttavia, l’ambito in cui ci si muove è soggetto a continui cambiamenti e
stravolgimenti, indi per cui chi ha la responsabilità dell’intero progetto, deve
periodicamente rivederne gli elementi principali, per controllare e verificare la
12
presenza di tutti quegli aspetti ritenuti importanti per il successo del piano, ed
eventualmente apportare delle modifiche per riallinearlo con il sistema
corrente.
1.3.1 La triade concettuale del project management
Come sostiene Russel Archibald in “Project Management – La gestione di
programmi e progetti complessi” (2004), la teoria del project management si
fonda sui seguenti tre elementi cardine (Triade concettuale del Project
Management):
la presenza di responsabilità bene identificate per l’integrazione degli
apporti al progetto: nelle organizzazioni impegnate in progetti si
possono individuare numerosi ruoli responsabili dell’integrazione dei
singoli apporti. A livello di alta direzione i più importanti sono il CEO
(Chief Executive Officer), il direttore generale e lo sponsor dell’iniziativa; a
livello di singolo progetto troviamo invece il project o il program
manager, mentre a livello di unità specialistica vi possono essere i capi
funzione e i functional project leaders;
la pianificazione e il controllo del progetto con funzione predittiva e
integrativa dei singoli apporti: come detto più volte, uno degli elementi
principali della triade concettuale del Project Management consiste nella
pianificazione e nel controllo integrato di ciascun progetto, che deve
considerare tutti gli apporti provenienti dalle diverse unità specialistiche
e organizzative che vi partecipano, per l’intera durata dello stesso. Un
ulteriore aspetto da considerare in tale fase, derivante dalla presenza
simultanea di molti progetti diversi che sfruttano le risorse dalle
medesime unità specialistiche, riguarda il fatto che per molte
organizzazioni sorge l’esigenza di impiegare un sistema unificato di
pianificazione e controllo. La mancanza di un tale sistema unificato, che
prenda in considerazione tutto l’insieme dei progetti, e non il singolo
13
progetto isolato, impedirebbe di fatto di raggiungere la migliore
integrazione e il coordinamento efficace degli apporti.
la costituzione, gestione e conduzione del team di progetto come luogo
dell’integrazione dei singoli apporti al progetto: i progetti consistono di
molti compiti (o work packages) di varia natura, ciascuno dei quali,
necessitando di risorse e competenze specialistiche diversificate, viene
assegnato ad una specifica persona in grado di rispondere a tali esigenze.
L’insieme degli individui che contribuiscono a un certo progetto
costituisce il relativo team, e solo una stretta collaborazione tra tutti i
suoi membri, sotto la guida del project manager, può assicurare
l’integrazione armonica dei loro apporti.
Gestire i progetti equivale a gestire il cambiamento, migliorare le tecniche di
project management significa cambiare (Archibald, 2004, p.122). Tuttavia anche
l'implementazione o il miglioramento delle tecniche utilizzate richiedono
l’applicazione, a loro volta, di buone tecniche di project management che
devono essere impostate in una prospettiva di lungo termine. Concludendo
questa breve introduzione al project management è necessario ricordare che
per avere successo bisogna sempre adattare alle diverse situazioni i concetti
generali del project management, prendendo in considerazione la cultura
dell'organizzazione che conduce il progetto e il mix culturale del team che lo
gestisce.
14
2 ORGANIZZAZIONE DELLA
FUNZIONE DI PROJECT
MANAGEMENT
2.1 L’UNITÀ ORGANIZZATIVA DI PROGETTO
La gestione sistemica di un'impresa complessa secondo la prospettiva del
project management implica la definizione di un quadro organizzativo
adeguato, che definisca chiaramente tutti gli aspetti riguardanti il modo di
gestire
progetti
isolati.
Un
esempio
riguarda
la
distribuzione
delle
responsabilità fra il ruolo di project manager e gli altri ruoli che curano
l’integrazione dei singoli apporti al progetto, nonché l’identificazione di coloro
che dovranno fare parte a tempo pieno del project office, o che invece, pur
contribuendo al progetto, rimarranno nella propria unità specialistica. A
seconda della tipologia di progetti che vengono svolti la struttura organizzativa
potrà assumere la forma più adatta a garantirne la massima efficacia
nell’esecuzione, con rispettivi pregi e difetti.
Date le particolari caratteristiche che contraddistinguono i progetti, sarà infatti
utile che anche la struttura organizzativa aziendale si adatti alla nuova modalità
di gestire il proprio lavoro; si rende dunque necessario il passaggio dalla tipica
unità organizzativa specializzata per funzione, che esegue lavori ripetitivi su
base pressoché permanente, alla più flessibile unità organizzativa di progetto,
15
che implica importanti differenze gestionali, come riportato nella tabella tratta
da “Project Management” di Russel Archibald (2004).
Unità organizzativa di progetto
Unità operativa
1. "Ciclo di vita" specifico
1. Vita continua da un anno all'altro
2. Punti di inizio e di completamento
2. Nessuna
caratteristica
legata a date di calendario
definiti, con date di calendario
3. Possibilità di improvvisa interruzione
3. La funzione continuerà ad esistere
se gli obiettivi non possono essere
anche
conseguiti
riorganizzazione
sforzo
totale
deve
radicale
precedenti
entro i limiti del budget annuale
6. È difficile la previsione di tempi e
6. È relativamente semplice prevedere
costi definitivi
molte
e
le spese annue
conoscenze
discipline,
che
7. Comporta una sola o poche capacità
professionali e discipline
possono cambiare da una fase
8. Tasso e tipo di spesa relativamente
all'altra
costante
8. Cambiano costantemente il tasso e il
9. Di
tipo di spese
9. Di
natura
dinamica
di
5. Il lavoro massimo viene eseguito
secondo scadenze stabilite
professionali
caso
compiti ben poco diversi da attività
essere
completato con un budget fissato e
7. Coinvolge
in
4. In genere si esercitano funzioni e
4. Spesso originale, mai fatto prima
5. Lo
specifica
fondamentalmente
natura
fondamentalmente
stazionaria
Figura 2.1: Differenze tra unità organizzativa di progetto e unità operativa (Fonte: Project
Management, Russel D. Archibald, ed. Franco Angeli, 2004)
Sul tema della differenza esistente tra unità organizzativa di progetto e unità
operativa, da sottolineare quanto dice Galbreath in “Working with Pulses, Not
Streams: Using Projects to Capture Opportunity” (1987, p.9):
"L'unicità dello sforzo e del risultato caratterizza le situazioni progettuali, come
la ripetitività e l'uniformità caratterizzano le normali situazioni operative”.
Mentre la gestione operativa, grazie al flusso continuo e ininterrotto di sforzi
16
che la caratterizza, porta ad ottenere una successione di risultati prevedibili e
uniformi, il progetto, inteso come un singolo impulso di attività, produce un
risultato unico e irripetibile. Da ciò Galbreath desume che “le unità di gestione
operativa possono durare ben più dei loro risultati, invece le unità di progetto si
sciolgono con il conseguimento del loro risultato”.
In presenza di progetti relativamente semplici, si adotta tipicamente la classica
organizzazione gerarchica strutturata per funzioni, con le tradizionali unità di
linea e di staff; al crescere del numero e della difficoltà dei progetti, oltreché
dell’importanza di rispettare gli obiettivi di performance e i vincoli di tempo e
di costo, si è gradualmente abbandonata questa prima forma organizzativa per
passare prima all’organizzazione a matrice, poi, nei casi più estremi, alle
cosiddette task force di progetto. La ricerca di una soluzione diversa ha
l’obiettivo di individuare una struttura che permetta di minimizzare i ritardi e i
costi aggiuntivi, derivanti dalla presenza di un assetto inadatto alla gestione per
progetti.
2.1.1
L'organizzazione a matrice
La cosiddetta struttura a matrice si sviluppa parallelamente su due dimensioni:
una tipicamente funzionale ed un’altra specifica del business, ad esempio per
linea di prodotto/servizio o per mercato. Un esempio tipico di organizzazione a
matrice è quella che prevede più “project manager” (o “product manager”, o
“market manager” etc.) che sono responsabili di una specifica porzione di
business in senso orizzontale, e che attingono tempo e risorse dalle varie
funzioni.
Queste strutture hanno tendenzialmente il vantaggio di coniugare un elevato
grado di specializzazione e coordinamento, ma purtroppo sono al contempo
soggette a maggiori overhead di gestione. Il nocciolo del problema
dell’organizzazione a matrice consiste nel fatto che chi partecipa al progetto,
nelle singole unità specialistiche, si trova a ricevere disposizioni e indicazioni
da due fonti: il capo funzione e il project manager. La presenza contemporanea
17
di “due capi” può condurre, in assenza di una chiara definizione delle
responsabilità, anche a conflitti gravi e onerosi, onde per cui sarà necessario
prestare grande attenzione nel formalizzare tale tipo di struttura.
Figura 2.1 Rappresentazione di un’organizzazione a matrice (Fonte: “Materiale aziendale
interno”)
2.1.2
La task force di progetto
Per superare le difficoltà tipiche dell’organizzazione a matrice può essere utile
istituire una task force che prevede di riunire fisicamente in un solo luogo la
maggior parte del team di progetto, in modo da migliorarne la comunicazione,
il controllo e il lavoro di squadra. Nonostante la task force possa sembrare
un’organizzazione strutturata “per progetto”, è necessario sottolineare che si
tratta ancora di una struttura a matrice, in cui però la vicinanza fisica dei
membri del team di progetto attenua alcuni dei problemi dell’ordinamento
organizzativo a matrice e solitamente ne migliora l’efficacia. Per definizione la
sua esistenza è limitata nel tempo e il suo scioglimento coincide inevitabilmente
con il raggiungimento dell’obiettivo del progetto.
La figura 2.2 illustra il campo continuo delle forme organizzative, nel quale
l'organizzazione a matrice è intermedia tra i due estremi dell'organizzazione
18
ordinata esclusivamente per funzioni e di quella ordinata esclusivamente per
progetti.
Figura 2.2 Campo continuo delle forme organizzative (Project Management, Russel D.
Archibald, Edizione Franco Angeli, 2004)
2.2 LA COLLOCAZIONE ORGANIZZATIVA DEL PROJECT MANGER E
IL PROJECT MANAGEMENT OFFICE
Strettamente correlata con la definizione della struttura organizzativa più
adatta alle esigenze dell’azienda, vi è un’altra decisione cruciale da prendere
per la buona riuscita del progetto: decidere a quale livello e in quale parte
dell’organizzazione collocare il project manager.
Il criterio fondamentale da seguire per la collocazione gerarchica del project
manager è quello di far dipendere tale funzione dal dirigente di linea, o, nel
caso di progetti molto grandi che coinvolgono diverse aree, dal direttore
generale della lead house, in quanto essi sono in grado, in concreto, di risolvere
i conflitti fra i diversi progetti da realizzare e all’interno di ciascuno di essi. La
scelta del livello gerarchico in cui collocare il project manager ha una serie di
risvolti determinanti nell’efficacia con cui vengono gestiti i progetti. Se infatti il
livello è troppo alto ne può derivare un’inutile conflittualità con i dirigenti di
19
linea, nonché grandi difficoltà di comunicazione con i responsabili delle unità
che contribuiscono al progetto; viceversa se dipende dal capo di una delle molte
unità, e quindi si trova ad un livello troppo basso, il project manager potrebbe
incontrare delle difficoltà nell’ottenere la collaborazione delle altre unità.
Nelle organizzazioni più “mature”, oltre alla figura chiave del project manager,
si può trovare anche un’altra unità organizzativa molto importante, collocabile
sia a livello di impresa che a livello di unità di business o di divisione: il Project
Management Office (PMO). Il PMO, oltre a fornire un appoggio ai project
manager in materia di gestione del rischio, pianificazione progettuale, analisi
degli scostamenti, monitoraggio dei problemi e amministrazione del contratto,
si occupa anche di impostare, sviluppare e implementare i processi, i sistemi e
gli strumenti di project management dell’organizzazione, quali ad esempio il
processo di project portfolio management , il project life cycle management system e il
software applicativo di project management, fornendo consulenza e assistenza
in materia di project management.
L’introduzione del Project Management Office, come ha osservato Block (1998),
ha permesso di ottenere una lunga serie di benefici, tra cui i principali sono:
miglioramento della redditività;
aumento della produttività dei team di progetto;
miglioramento dell’efficacia organizzativa;
affinamento delle professionalità di project management.
Come sostiene Block (1998), dunque, il beneficio latente del Project
Management
Office
è
quello
dell’assimilazione
graduale
del
project
management nell’intera organizzazione, che rappresenta il fine ultimo della sua
istituzione.
20
3
AVVIO E PIANIFICAZIONE
DEL PROGETTO
L’efficacia nell’applicazione del project management può essere garantita
solamente se si dispone di buoni metodi e procedure per la pianificazione, la
schedulazione, la stima, l’autorizzazione dei lavori, il monitoraggio, il
rendiconto e la valutazione del progetto e dei singoli compiti che lo
costituiscono. Il concetto fondamentale della disciplina di project management
implica che ogni progetto venga adeguatamente pianificato e controllato su
base integrata, includendo tutte le funzioni e unità organizzative interessate e
abbracciando l’intero ciclo di vita del progetto, dalla sua concezione alla sua
chiusura, passando per l’impostazione, lo sviluppo e l’avviamento. Inoltre, per
riuscire a raggiungere un buon livello nella gestione dei progetti non è
sufficiente eseguire quanto detto finora, ma è anche necessario includere tutti
gli elementi informativi pertinenti alla situazione, nonché considerare
l’allocazione delle risorse e i metodi di valutazione dell’avanzamento,
analizzando gli appropriati rendiconti che evidenziano gli scostamenti di costo
e tempo assorbiti, rispetto a quanto preventivato.
L’integrazione in un insieme coerente di tutte le fasi progettuali e di tutti gli
elementi informativi, e la predizione di ciò che accade al progetto, in base ai
piani e alle stime correnti, rappresentano un requisito indispensabile per
21
riuscire a raffrontare i risultati effettivi con quelli previsti, prevedendo man
mano i tempi e i costi totali del progetto; sulla base di tale confronto si
elaborano una serie di valutazioni finalizzate a prevedere gli sviluppi non
desiderati del progetto, con un anticipo sufficiente a consentirne azioni
correttive capaci di prevenirli.
3.1 LA PIANIFICAZIONE DEL PROGETTO
“… La pianificazione è come l’assicurazione sulla vita: tutti ne hanno bisogno, ma non
viene apprezzata fino a quando non succede un disastro. Spesso si pensa di buttare via
per la pianificazione tempo prezioso, che si potrebbe impiegare in modo più costruttivo.
Invece quello che ci insegnano i veterani del project management è particolarmente
chiaro: una qualche forma di pianificazione è assolutamente indispensabile per il
successo di un progetto …, ma spesso non rientra nella cultura aziendale”(Baglieri et
al., 2004).
La pianificazione è una forma di comunicazione, una fonte di informazioni utili
per il team di progetto, e molto spesso la mancanza di una pianificazione
adeguata viene indicata come la causa principale del suo fallimento. Il piano di
progetto è il documento formalizzato che descrive come si possono realizzare
gli obiettivi tenendo in considerazione la disponibilità limitata delle risorse nel
tempo, nella quantità e nella tipologia; esso è
il risultato del processo di
pianificazione, ossia di definizione delle attività da svolgere, di allocazione
delle risorse nelle varie attività, di tempificazione e puntualizzazione dei costi
associati al lavoro. Esso si presta dunque a diventare la base per lo svolgimento
delle attività, in quanto solo con la presenza di un piano si può ottenere un
feedback sullo stato di avanzamento del progetto per quel che concerne il
conseguimento degli obiettivi, delle scadenze e dei tempi. Il confronto tra ciò
che è stato effettivamente realizzato, rispetto a ciò che era stato pianificato,
consente al project manager e al team di valutare obiettivamente i progressi
maturati e, qualora necessario, adottare i provvedimenti adatti per svolgere le
attività. Esso diventa quindi lo strumento di gestione del progetto in cui si
22
raccolgono tutte le informazioni utili per organizzare il lavoro e osservare le
attività più critiche ai fini del conseguimento dell’obiettivo.
I contenuti di un piano di progetto sono riconducibili a sei punti fondamentali
(Baglieri et al., 2004):
Definizione degli obiettivi del progetto:
i risultati che il committente e lo sponsor dichiarano di voler raggiungere e
che devono essere tradotti in obiettivi operativi direttamente dal team di
progetto. La definizione chiara e completa di tali traguardi - che devono
rispettare la strategia aziendale definita dall’alta direzione - e dell'ambito del
progetto, è la condizione necessaria per un’efficace attività di pianificazione,
la quale a sua volta ha il compito di specificare come raggiungerli nel rispetto
dei limiti stabiliti.
Identificazione delle attività da svolgere:
una volta individuati gli obiettivi da raggiungere si passa a mappare tutte le
attività, ciascuna delle quali può a sua volta essere descritta da uno o più
compiti elementari, che devono essere svolte per garantire il successo del
progetto. Questa fase ha l’obiettivo fondamentale di pervenire ad una visione
unitaria, condivisa con tutti i membri del team, di come si deve svolgere
l’intero processo.
Individuazione delle competenze necessarie e assegnazione delle risorse a
ciascuna attività:
l’esecuzione di ciascuna attività che costituisce il progetto richiede alle
persone coinvolte delle specifiche competenze e capacità tecnicheorganizzative-relazionali. Una volta individuati questi parametri si può
procedere ad assegnare a ciascuna attività le persone e le altre risorse (ad
esempio, mezzi fisico-tecnici) necessarie, specificandone le principali
responsabilità all’interno del progetto. Ovviamente tale processo di scelta
delle risorse dipende anche dall’attenta analisi del contesto e delle
conoscenze effettivamente utili.
23
Scheduling del progetto:
a questo punto si hanno a disposizione tutte le informazioni necessarie per
determinare esattamente i tempi di progetto, descrivendo le attività nella
loro sequenza e nell’eventuale loro parallelismo. In questo modo, sapendo
precisamente quando le diverse persone e i diversi mezzi sono coinvolti nel
progetto, è possibile stimarne, abbastanza fedelmente e a meno di grossi
imprevisti, i tempi di inizio e fine di ogni attività. Come si vedrà più avanti,
in questa fase di scheduling risulteranno di particolare aiuto alcuni strumenti,
come il PERT e il diagramma di Gantt.
Assegnazione delle risorse economiche di progetto ed elaborazione del
sistema di controllo:
in questa fase si può andare a definire l’ammontare delle risorse economiche
che è possibile destinare al singolo progetto. In alcuni casi l’importo massimo
disponibile è predeterminato, o perché stabilito in uno studio di fattibilità, o
perché già stimato in sede di budget degli investimenti annuali. Una volta
completati tutti i passi precedenti, l’ultimo punto che è fondamentale
specificare all’interno del piano di progetto è la definizione dei criteri e delle
modalità con cui si intende monitorare l’effettivo andamento del progetto,
con particolare attenzione alla scelta dell’oggetto del controllo. In un
progetto possono infatti essere controllate diverse variabili (qualità del
risultato, rispetto dei tempi e dei costi, soddisfazione delle persone, ecc.),
ciascuna delle quali con un peso diverso: è dunque importante capire cosa
conta veramente controllare per creare il sistema di controllo più opportuno.
In conclusione il piano di progetto risultante, che contiene tutte le informazioni
appena riportate, rappresenta il documento finalizzato ad autorizzare
ufficialmente il progetto (PMI PMBOK® 2000).
24
3.2
LE BEST PRACTICES NELLA PIANIFICAZIONE OPERATIVA DEI
PROGETTI
Secondo Baglieri et al. (2004), in base all’esperienza maturata nella gestione dei
progetti, i principali motivi, che ricorrono con maggiore frequenza, e che
giustificano i costi legati all’impiego di tecniche e strumenti nella fase di
pianificazione operativa possono essere così sintetizzati:
fornire una schedulazione delle attività che permetta di rispettare le deadline,
tenendo in considerazione le risorse disponibili in quel preciso istante;
identificare le persone responsabili di ciascun work package presente nella
Work Breakdown Structure;
identificare i possibili eventi di interfaccia e i punti intermedi di controllo del
progetto;
permettere un’eventuale riduzione della durata del progetto grazie alla
sovrapposizione di alcune attività, quando possibile;
facilitare la valutazione degli stati di avanzamento del progetto;
fornire le basi per un’analisi dei costi-benefici, e una valutazione del ritorno
del progetto.
Il momento della pianificazione, come si è potuto capire da quanto descritto
finora, è un momento cruciale nella vita del progetto. Una buona
programmazione aiuta non solo a comprenderne le sue fasi fondamentali – e
per questo l’output di questa attività può essere definito anche piano baseline ma supporta anche il rapporto con il cliente e con il management aziendale,
oltre ad aiutare il team nella sua responsabilizzazione e nella conoscenza del
progetto nel suo insieme e per la parte che gli compete. Di seguito si elencano
brevemente i principali passi da seguire per la pianificazione operativa di
progetto, secondo Kerzner (2005):
1. sviluppare la Work Breakdown Structure per ottenere una descrizione
completa delle attività;
25
2. determinare la sequenza delle attività precisando le date minime e massime
di inizio e di fine, gli scorrimenti delle attività e i percorsi critici attraverso
l’applicazione del Critical Path Method (CPM);
3. costruire il diagramma di Gantt, attribuendo le responsabilità per ciascuna
attività attraverso l’analisi del carico delle risorse rispetto alla loro
disponibilità;
4. sviluppare il budget per pacchetto di lavoro WBS;
3.2.1
Creazione della work breakdown structure per la scomposizione del
progetto
Il metodo più efficace per descrivere un progetto consiste nella creazione di
una “struttura analitica” (Project Breakdown Structure), talvolta chiamata anche
Work Breakdown Structure: si tratta di una rappresentazione in forma grafica che
individua tutti gli elementi e le attività, livello per livello, che formano l’oggetto
di consegna al cliente, nonché i compiti funzionali che debbono essere eseguiti
dalle singole funzioni aziendali per concepire, progettare, costruire, assemblare
e consegnare il risultato desiderato. Si tratta, in altri termini, di un
“procedimento ordinato e sistematico per la scomposizione del progetto in
sottosistemi sempre più piccoli, fino all’individuazione di work packages
chiaramente identificabili e quantificabili, una specie di stele di Rosetta del
project management che garantisce la presenza di una corretta interrelazione tra
i diversi elementi di informazione individuati e, di conseguenza, rappresenta
un’ottima base per una schedulazione di progetto efficace ed efficiente”
(Baglieri et al., 2004; Archibald, 2004). E’ necessario ricordare che la WBS non è
in grado di ordinare cronologicamente le fasi e i compiti del processo di
sviluppo dei prodotti, ordinamento che sarà demandato ad una fase successiva
di pianificazione che prevede la schedulazione generale del progetto (Project
Master Schedule) e dei suoi particolari.
Le logiche e i criteri di scomposizione di un progetto possono essere numerosi a
seconda degli obiettivi seguiti nell’attribuzione delle responsabilità. Una prima
26
modalità di scomposizione è quella “per obiettivi”, in cui il primo sottolivello è
costituito dai principali obiettivi, e sotto ciascuno di questi verranno riportate le
attività da svolgere per poterli perseguire. Un’altra possibile via da seguire
nella realizzazione della Work Break Down Structure è quella dei “processi di
lavoro”, secondo cui il progetto viene disaggregato in base ai processi che
devono essere posti in atto per la realizzazione dei deliverables; tale struttura
prevede dunque di collocare i macroprocessi in capo alla gerarchia, e nei livelli
sottostanti vengono invece riportati i blocchi di attività che caratterizzano tali
processi di lavoro. Qualora si vogliano rendere direttamente paragonabili e
confrontabili i progetti fra di loro, o qualora si vogliano analizzarne le interfacce
in un’ottica multiproject, si può adottare una WBS pro forma unica, che mantenga
la stessa struttura logica per tutti i progetti, andando a modificare solamente le
definizioni delle attività da svolgere.
Per concludere, la WBS, con la relativa assegnazione dei responsabili, diventa di
fatto lo strumento principe dal quale si procede per la definizione dei tempi, dei
costi e delle risorse, così come il punto di partenza per visualizzare il progetto
nella sua interezza e complessità e per l’impostazione dell’intero sistema di
controllo del progetto.
3.2.2 La schedulazione delle attività di progetto
Per riuscire a calcolare la durata totale del progetto, e definire la schedulazione
delle singole attività elementari (tasks) che lo compongono, è necessario
procedere alla costruzione del reticolo (o network, o diagramma di precedenza),
ossia una rappresentazione grafica finalizzata a illustrare la sequenza
elementare da seguire per riuscire a raggiungere gli obiettivi prefissati per il
singolo progetto.
A tale proposito è opportuno osservare come la WBS, descritta nel paragrafo
precedente, non sia in grado di analizzare le relazioni di precedenza esistenti
tra i vari tasks, e di studiare come esse si collocano nel tempo, ma costituisca
27
invece il legame logico di base per l’applicazione delle tecniche reticolari, in
quanto fornisce la lista completa di tutte le attività che compongono il progetto.
Dopo aver identificato le attività del progetto è possibile passare alla
definizione dei vincoli logici e temporali, vale a dire i legami che rappresentano
le dipendenze sequenziali che sussistono fra i diversi tasks. I vincoli di
sequenza ammessi dal reticolo sono quattro:
Finish to Start (FS): è il più comune e il più utilizzato nella prassi e
implica sequenze in serie che non consentono di avere parallelismi fra
attività che sono fra loro sequenziali. Esso sta ad indicare che l’attività B
non può iniziare fintanto che A non è completamente terminata;
Start to Finish (SF): esso prevede invece che l’attività successiva non
possa terminare finchè l’attività che la precede non è iniziata;
Start to Start (SS): questo vincolo stabilisce invece un legame fra le date di
inizio di due attività, permettendo di sovrapporre in tutto o in parte le
attività che si muovono in parallelo comprimendo di conseguenza i
tempi del progetto;
Finish to Finish (FF): l’ultimo vincolo impone invece che l’attività
successiva non possa terminare fino a quando non è terminata anche
l’attività precedente.
Se non ancora stimate nella fase iniziale di sviluppo della Work Breakdown
Structure, è necessario a questo punto attribuire a ciascuna attività una durata
prevista, la data di inizio o di fine progetto e il calendario standard (workpattern) in
cui vengono definiti i giorni lavorativi, in modo poi da disporre di tutte le
informazioni necessarie per elaborare lo scheduling di ciascuna attività che
compone il progetto. A partire dalla conoscenza delle durate di tutti i task e dei
vincoli di precedenza che li legano l’uno all’altro è possibile definire le date di
inizio e di fine di ciascun task, nonché la data pianificata di completamento
dell’intero progetto.
28
3.2.3 Il metodo del percorso critico (Critical Path Metod) e gli scorrimenti
Il metodo del percorso critico – conosciuto anche come Critical Path Method
(CPM) - è una tecnica reticolare che supporta la programmazione dei tempi
delle
attività
di
progetto,
sulla
base
delle
durate
deterministiche
precedentemente assegnate e nel rispetto dei vincoli di successione esistenti.
Grazie alla corretta applicazione del CPM è possibile ricavare alcune
informazioni fondamentali, come ad esempio le date minime e massime di
inizio e fine per ciascuna attività, la data di fine progetto, il percorso critico per
cui non è ammesso alcun scorrimento ed infine gli scorrimenti ammissibili delle
attività che non si trovano lungo tale percorso (PMBOK® Guide 2000).
Si comincerà innanzitutto dando alcune definizioni principali:
Early Start Date (ES): indica la data minima di inizio, ovvero la data alla quale è
possibile iniziare al più presto l’attività considerata se i suoi predecessori non
presentano ritardi nel loro completamento;
Early Finish Date (EF): essa rappresenta invece la prima data entro la quale può
finire l’attività, sempre se i suoi predecessori non hanno accumulato ritardo.
Come si può osservare ne deriva che la data minima di inizio di una qualsiasi
attività (i) corrisponde alla massima delle date minime di fine di quelle che la
precedono, secondo i vincoli di sequenza definiti nel reticolo
ES(i) = max{EF(p)} = max {ES(p) + Du(p)}
mentre la data minima di fine di qualsiasi attività (i) si ottiene dalla somma fra
la massima delle date minime di fine di quelle che la precedono e la durata
dell’attività stessa
EF(i) = max{EF(p)} + Du(i)
Late Start Date (LS): rappresenta la data massima entro la quale l’attività deve
assolutamente iniziare per non compromettere la data di fine progetto;
Late Finish Date (LF): data massima entro la quale l’attività considerata deve
essere completata per non compromettere il tempo totale di fine progetto.
29
Per il calcolo delle late date si procede a ritroso a partire dall’ultima attività, che
corrisponde con la data di fine progetto normalmente proposta dal
committente. Di conseguenza si vede che la data massima di inizio di ciascuna
attività (i) si ottiene andando a sottrarre la durata della singola attività alla
minima delle date massime di inizio dei rispettivi successori
LS(i) = min {LS(q)} – Du(i)
mentre la data massima di fine dipende dalla minima delle date massime di
inizio delle attività successive
LF(i) = min {LS(q)} = min {LF(q) - Du(q)}
A partire dalla conoscenza delle date minime e massime di un’attività è
possibile determinare lo “scorrimento” (float o slack), ovvero l’intervallo di
tempo che intercorre tra tali date, che rappresenta una misura della flessibilità
dell’attività, indicando per quanto tempo il suo completamento può essere
ritardato senza per questo inficiare la data di fine progetto. A differenza dello
scorrimento, un ritardo effettivo nel completamento del task implicherebbe il
superamento della data massima di fine progetto. Due sono le principali
tipologie di scorrimento che si possono tipicamente individuare:
1.
Scorrimento totale, o Total Float, ossia il ritardo che può essere tollerato in una
certa attività senza compromettere la durata del progetto. Può capitare che
alcune attività abbiano uno scorrimento totale nullo, il che implica che ogni
unità di ritardo accumulata da una di queste attività provoca un ritardo sulla
data finale del progetto di pari ammontare: la sequenza di attività a
scorrimento totale nullo, definite “attività critiche”, dal nodo di origine a
quello di fine reticolo, danno vita al percorso critico, da cui deriva il nome
Critical Path Method.
2.
Lo Scorrimento libero – Free Float – è invece il ritardo che può essere tollerato
in una certa attività senza compromettere la durata delle attività successive,
ovvero il ritardo massimo di fine attività rispetto alla sua data minima di
30
fine, che non implica alcun ritardo sulla data minima di inizio di tutte le
attività successive.
3.2.4 Il diagramma di Gantt
Il “diagramma a barre schedulato”, meglio noto con il nome “diagramma di
Gantt”, è uno strumento grafico di supporto alla gestione dei progetti, che
contiene tutte le informazioni relative alla pianificazione dei tempi di uno o più
progetti. Questo diagramma, principalmente usato nell’ambito del Project
Management, è costruito partendo da un asse orizzontale – a rappresentazione
dell’arco temporale totale del progetto, suddiviso in fasi incrementali (giorni,
settimane, mesi) – e da un asse verticale, a rappresentazione della lista delle
mansioni, con relativi descrizione e codice, che costituiscono il progetto.
All’interno di questo schema ciascuna attività è rappresentata sottoforma di
barre orizzontali di lunghezza proporzionale alla loro durata, e, a seconda della
loro posizione, indicano le date minime o massime di inizio e fine di ogni
attività; con il progredire del progetto delle barre secondarie, o delle barre
colorate possono essere aggiunte al diagramma per indicare le attività
sottostanti completate o la porzione che è stata completata.
Molto spesso però nel diagramma di Gantt non vengono indicate
esplicitamente le relazioni e i vincoli di sequenza, perdendo così la possibilità di
sapere da chi dipende un eventuale ritardo o quale attività deve fornire
sequenza a un’altra: con il diagramma di Gantt sì fatto se un’attività viene
ritardata non è possibile comprendere gli effetti che tale ritardo ha sulle altre
attività e sull’intero progetto. Questi limiti possono tuttavia essere facilmente
superati tramite l’impiego del Gantt associato ai reticoli e al CPM che
permettono di evidenziare, direttamente all’interno del diagramma, la presenza
di possibili vincoli di sequenza.
Si può dunque affermare che “il diagramma di Gantt permette una
rappresentazione grafica di un calendario di attività, utile al fine di pianificare,
coordinare e tracciare specifiche attività dando una chiara illustrazione dello
31
stato d'avanzamento del progetto rappresentato” (Wikipedia, l’Enciclopedia
libera).
3.2.5 Pianificazione delle risorse e tecniche di livellamento del carico di
lavoro
Queste considerazioni sono state fatte ipotizzando di lavorare in presenza di
risorse illimitate, ma purtroppo nella maggior parte dei casi le risorse a
disposizione non solo sono limitate, ma sono anche condivise con altri progetti.
In tale situazione diviene dunque fondamentale il legame inscindibile esistente
fra i tempi e le risorse: di conseguenza la possibilità di rispettare le date
pianificate in fase di schedulazione deve essere valutata sia in relazione al
raggiungimento delle milestones di progetto, ma anche e soprattutto in termini
di “come” e “quando” utilizzare le risorse con disponibilità limitata.
L’obiettivo di questo paragrafo è dunque quello di comprendere come integrare
la pianificazione dei tempi con la pianificazione delle risorse, con il fine di
ottimizzarne l’impiego riducendo il più possibile il gap esistente fra le risorse
richieste e quelle disponibili.
La relazione esistente fra impiego dell’unità tempo e impiego dell’unità risorsa
può essere riassunta facendo riferimento alle due seguenti situazioni:
situazione time-limited: questo primo contesto si riferisce al caso in cui la data
di completamento dell’intero progetto è fissata, e di conseguenza deve essere
obbligatoriamente completato entro la scadenza imposta. In questo caso la
variabile critica è rappresentata dal tempo e qualsiasi overloaded di risorsa
deve essere soddisfatto, anche incrementando la sua disponibilità, purché la
data richiesta venga rispettata;
situazione resource-limited: la variabile critica questa volta è rappresentata
dalla risorsa; il progetto deve quindi essere completato il prima possibile nel
rispetto dei vincoli imposti dalle risorse.
32
Una volta definite tutte le attività che compongono un progetto e i relativi
vincoli di sequenza che permettono di fornire un timing di schedulazione delle
singole attività, è possibile andare ad assegnare le risorse, stimando il loro
impiego e il loro carico complessivo; a questo punto della pianificazione è
inoltre necessario inserire nel piano di progetto, se esistono, tutti i vincoli
effettivi all’impiego e all’allocazione delle risorse, che permette di confrontare
le risorse richieste con le rispettive disponibilità.
Se non viene gestita, la situazione di sovraccarico (overload) di risorsa, che si ha
quando le richieste eccedono le disponibilità, provoca inevitabilmente un
ritardo nel completamento delle attività del progetto, con la conseguente
incapacità dell’organizzazione di raggiungere gli obiettivi definiti nel rispetto
dei vincoli di tempo prefissati.
Per riuscire a ridurre al minimo il sovraccarico delle risorse, così come anche il
loro sottoutilizzo, è possibile seguire due diversi approcci: i modelli euristici,
che ricercano le soluzioni migliori sulla base dei criteri impostati dal
pianificatore, o gli algoritmi di ottimizzazione che forniscono invece la
soluzione ottima, ma sono a loro volta limitati nella possibilità di gestire
situazioni caratterizzate da un’elevata complessità. Proprio per queste ragioni ci
si concentra qui solamente sulla prima tipologia di approccio.
Con gli approcci euristici, il cui studio parte dalla schedulazione definita
tramite il CPM, se si verifica che in un determinato periodo la disponibilità
della risorsa è inferiore alla sua richiesta a causa della presenza di vincoli di
disponibilità, la schedulazione del progetto che prevede un overload non può
essere confermata, ma si va a livellare tale risorsa – ossia riportare il suo carico
ad un livello consentito – seguendo un preciso algoritmo basato su dei criteri di
priorità predefiniti.
Ne consegue dunque che è necessario innanzitutto decidere quale priorità
attribuire fra le attività che condividono le medesime risorse, in modo tale da
riuscire a definire un’eventuale assegnazione di precedenza nel livellamento;
nella maggior parte dei casi tale livellamento delle risorse implica uno
33
slittamento in avanti dell’attività in questione, che a sua volta provoca un
ritardo nella data di fine progetto pari all’entità dello slittamento verificatosi.
L’impostazione degli ordini di priorità nel processo di livellamento, che
determinano quale attività può ricevere risorse e quale invece può attendere,
può seguire diverse modalità di assegnazione (Baglieri et al., 2004):
Attività che hanno maggiormente impatto sulla data di fine progetto: si dà la
precedenza a quelle attività che, all'interno delle conflict set, presentano il
maggior incremento della data di fine progetto;
Attività con minore data minima di inizio: secondo questa modalità di
assegnazione le risorse vengono allocate in via privilegiata a quelle
attività che devono partire prima;
Attività che hanno la domanda più elevata: viene data in questo caso priorità
alle attività che sono “colli di bottiglia” rispetto alle risorse, vale a dire
quei compiti che richiedono un maggior impiego di risorse stimate;
Attività con minore scorrimento totale: questo criterio prevede di assegnare
le risorse a quelle attività che possiedono un margine di flessibilità
minore;
Attività con maggior numero di attività critiche successive: l’ultimo criterio
prevede invece di attribuire le priorità sulla base del numero di attività
critiche successive; si procede
quindi assegnando prima di tutto le
risorse a quelle attività che, qualora ritardate, comporterebbero la rischedulazione di un numero significativo di attività.
Fra gli obiettivi del livellamento delle risorse bisogna citare anche quello di
regolare l’intensità di utilizzo della risorsa in tutto il progetto, riducendone al
minimo le fluttuazioni nel carico, e permettendo dunque di ottenere un piano
delle risorse più regolare, senza la presenza di picchi che potrebbero
inutilmente generare momenti di emergenza e di sottoutilizzo, ed una
conseguente distribuzione dei costi altrettanto irregolare e poco profittevole.
Il diagramma che viene tipicamente utilizzato per illustrare graficamente gli
impieghi delle risorse allocate alle diverse attività che compongono il progetto è
34
il digramma di carico. Questo diagramma però se non viene parallelamente
confrontato con il diagramma di Gantt non è in grado di dare alcuna
informazione in merito a quali attività sono eventualmente interessate a
sovraccarichi di risorsa. Di qui la necessità di creare dei report in forma
tabellare del diagramma di carico, che contenga informazioni rilevanti come ad
esempio le risorse incluse nel progetto e il relativo carico complessivo. Questi
report grafici e tabellari definiscono il piano di baseline, ovvero il documento che
qualifica le attività che si devono eseguire e come esse si svolgono in termini di
tempi, risorse e costi, chi sono le risorse coinvolte e i relativi responsabili.
Questo piano di baseline rappresenta il punto di partenza per la fase successiva
di esecuzione e controllo del progetto.
35
36
4 CONTROLLO DELLE
PERFORMANCE DI PROGETTO
Controllare in modo efficace il lavoro, la schedulazione e i costi relativi ad un
progetto è possibile solamente se le azioni di pianificazione sono correttamente
realizzate e se i piani, le schedulazioni e il budget del progetto e dei compiti
sono state adeguatamente documentate; ovviamente per riuscire a monitorarne
lo stato è necessario impostare un sistema di controllo in cui vengano
chiaramente definite tutte le misure di prestazione con riferimento alle quali il
progetto deve essere sottoposto a controllo.
Questa quarta fase del modello di project management vuole dunque misurare
l’economicità del progetto. Tale definizione può essere tipicamente scomposta
nelle due tradizionali dimensioni dell’efficacia e dell’efficienza; con il primo
termine si misura il grado di raggiungimento degli obiettivi definiti, ovvero il
rapporto tra risultati e obiettivi di risultato, in termini di livello di qualità, costi
e tempi, mentre con il termine “efficienza” si intende il livello di assorbimento
delle risorse impiegate per raggiungere gli obiettivi definiti, ovvero il rapporto
tra risultati e risorse consumate.
Le misure di performance che compongono il sistema di controllo, e che sono
correlate ai vari obiettivi, devono essere coerenti con la visione strategica
imprenditoriale e far leva su quelli che sono i fattori critici di successo
37
competitivo ed economico. Le misure di prestazione che permettono di valutare
le performance competitiva ed economica possono essere ricondotte a tre classi:
- prestazioni a livello di soddisfazione del cliente
- prestazioni a livello di flessibilità
- prestazioni a livello di produttività
a loro volta scomponibili in misure di performance attribuibili alle singole
attività aziendali – prestazioni a livello di qualità, di consegna, di tempi ciclo e di
sprechi (Stefano Biazzo et al., 2010, p.7).
Nell’ambito del project management la fase di monitoraggio è dunque una fase
centrale nella gestione del progetto, in quanto permette di verificare gli
scostamenti che esso sta subendo, rispetto al piano di riferimento definito nella
precedente fase di pianificazione, verificando la coerenza tra i costi che sono
stati effettivamente sostenuti e i costi che si era pianificato di sostenere. La
comparazione tra l’andamento reale del progetto e ciò che invece era stato
previsto ha l’obiettivo finale di consentire al project manager di individuare,
con un certo anticipo, tutte le criticità attuali e potenziali, in modo tale da
riuscire ad intervenire tempestivamente con azioni correttive finalizzate a
riallineare i risultati e gli obiettivi con quanto era stato precedentemente
richiesto.
Tutti i progetti, date le loro caratteristiche intrinseche di non ripetitività delle
attività e degli output, si propongono tipicamente di conseguire un obiettivo
unico e mai perseguito prima nelle stesse circostanze o condizioni, il ché
impedisce in fase di pianificazione di prevedere tutti i possibili problemi che si
potrebbero incontrare. Queste peculiarità, che si vanno ad aggiungere alla già
elevata complessità delle attività che compongono il progetto, dovuta alla
presenza di molteplici interconnessioni logiche tra le singole fasi, esigono di
presidiare in corso d’opera la correlazione tra obiettivi e risultati attraverso la
gestione dei frequenti cambiamenti che si verificano nell’ambito del progetto,
nella sua schedulazione e/o nei costi ad esso legati.
38
4.1 CONTROLLO DELL'AMBITO DEL PROGETTO
Come si è accennato nel paragrafo precedente, un primo aspetto da tenere sotto
stretta osservazione è l’ambito in cui il progetto si va ad inserire. Molto spesso
capita infatti che la causa primaria dei ritardi e dei costi elevati sia
l'incontrollata e inconsapevole estensione del suo ambito oltre il piano originale,
conseguenza del desiderio di raggiungere il miglior risultato possibile, anche se
esso non corrisponde con quanto concordato. Il project manager, che ha un
ruolo chiave nell’assicurare il rispetto di tali confini, deve quindi esigere che le
descrizioni dei compiti, così come la schedulazione e il budget siano
chiaramente documentati e firmati, in modo tale da poter monitorare, insieme
ai capi funzione, che le specifiche e le clausole contrattuali siano rispettate, ed
individuare eventuali compiti in cui l’ambito del lavoro possa essere esteso se
specificamente richiesto dai clienti.
4.2 CONTROLLO INTEGRATO DEI TEMPI E DEI COSTI DI PROGETTO
Da quanto detto finora è possibile desumere che ogni functional project leader e
ogni project manager debba misurare regolarmente l'avanzamento del progetto
a fronte della schedulazione, così da eseguire le proprie valutazioni per poi
recuperare i ritardi e ripianificare il lavoro che ancora deve essere completato.
Tuttavia, è responsabilità del project manager tenere sotto controllo
l’avanzamento del progetto, non solo in termini di tempi che ciascuna attività
deve rispettare, ma anche e soprattutto di costi, in modo tale da essere in grado
di identificare anticipatamente gli scostamenti tra le spese effettive e i budget
che necessitano di misure correttive per bilanciare il costo finale del progetto al
budget totale che era stato inizialmente previsto. Degli studi hanno dimostrato
come una delle cause principali dei problemi di costo sia solitamente
riconducibile alla tendenza da parte dei manager ad effettuare delle stime e dei
preventivi
irrealistici
e
insufficienti
per
fronteggiare
la
concorrenza,
presentando un prezzo d’offerta più basso, salvo poi accorgersi di non riuscire a
rispettare quanto definito. Tuttavia questo non è l’unico motivo individuato.
39
Molto spesso infatti accade che con il procedere delle attività si incontrino dei
problemi tecnici imprevisti, che implicano un successivo lavoro aggiuntivo di
modifiche ed estensioni, con conseguenti costi aggiuntivi rispetto al budget
pianificato.
La rilevanza temporale dei progetti rispetto ai normali processi operativi
aziendali, e la necessità di garantire un allineamento con quanto definito nel
piano, impone di considerare l'effetto della variante "tempo" all'interno di
misurazioni di carattere economico, sia in chiave previsionale che consuntiva,
attraverso il ricorso ad un controllo della schedulazione e dei costi su base
strettamente integrata. In genere, si ritiene che il sistema più utile
per il
controllo del progetto sia quello di andare a correlare la schedulazione e i costi a
livello di compito o di work package, presenti nella project break down structure
(Pbs), come illustrato in figura 4.1, dove a sinistra è riportata la Pbs, mentre i
compiti e i work packages sono rappresentati con delle barre posizionate in linea
con i rispettivi elementi della Pbs. La parte di piano generale riportata, collega i
compiti con i milestone ed altri eventi, mentre i budget, i consuntivi e le stime
“per completare” e “al completamento” sono indicati per alcuni compiti e per
l’intero progetto.
40
Figura 4.1 Correlazione di costi e tempi con la Pbs (Project Management, Russel D. Archibald,
ed.
4.2.1 Ottimizzare la distribuzione delle risorse economiche nel tempo
Il ricorso ad un sistema di controllo integrato dei tempi e dei costi deriva dal
fatto che i progetti presentano tipicamente un trend dei livelli di spesa non
lineare nel tempo, che porta ad avere delle situazioni nelle quali in alcuni
periodi vi è un elevato assorbimento di risorse economiche, affiancati ad altri in
cui invece la maggior parte dei progetti non assorbe significativi volumi di
costi. La distribuzione delle risorse economiche richieste nell’arco dell’intero
progetto tende a variare, allontanandosi in modo sempre più significativo
dall’ottimale distribuzione lineare, con la possibilità che nel periodo di picco
delle richieste l’azienda non sia in grado di supportare le spese necessarie. Tale
sistema di controllo permette dunque di analizzare la presenza di queste
situazioni critiche, consentendo, se possibile, di bilanciare nel tempo i costi da
sostenere per avvicinarsi il più possibile ad una distribuzione omogenea delle
uscite, durante l’intero ciclo di vita del progetto.
41
Il primo passo consiste nell’analizzare uno ad uno i costi previsionali delle
attività che compongono il progetto e calcolare, in funzione della durata
pianificata, il loro costo medio per unità di tempo, ovvero il cosiddetto cost slope
(costo previsionale / durata attività). Una volta calcolato questo valore per ciascuna
attività è possibile, attraverso l’osservazione del diagramma del progetto che
riporta il tempo di svolgimento di ognuna di esse e le relative sequenze critiche,
predisporre un riepilogo temporale, detto Project Cost Schedule, in modo da
poter misurare l’assorbimento di risorse economiche che il progetto comporta
per ogni unità temporale presa a riferimento. Arrivati a questo punto è
opportuno creare il Gantt Cost Schedule (figura 4.2), che permette di visualizzare
in un unico grafico sia la distribuzione temporale dei costi nei singoli periodi,
sia le sequenze critiche del progetto.
Figura 4.2: Gantt Cost Schedule (Organizzare e gestire progetti, Baglieri et al., ed. Etas 2004)
A partire dal Gantt Cost Schedule si crea il Bar Chart Cost Schedule, rappresentato
in figura 4.3, dalla cui analisi si riesce ad individuare la presenza di eventuali
42
picchi o periodi di sottoutilizzo delle risorse economiche. Incrociando i dati
emersi da questi ultimi due grafici il project manager ha disposizione tutte le
informazioni necessarie per poter prendere la decisione migliore, che permetta
di appiattire la distribuzione temporale delle spese.
Figura 4.3: Bar Chart Cost Schedule (Organizzare e gestire progetti, Baglieri et al., ed. Etas
2004)
Per raggiungere questo obiettivo si parte tipicamente col prendere le attività che
presentano un cost slope più elevato e che non si trovano nel cammino critico;
quest’attività, non essendo critica, ai fini della durata totale del progetto, può
essere convenientemente spostata in avanti lungo le settimane, fino ad eseguirla
in quell’intervallo di tempo che permette la redistribuzione omogenea dei costi
del progetto (Kerzner Harold, 2005).
Finora si è ipotizzato che la durata prevista rimanga costantemente invariata.
Nella realtà invece capita spesso che la durata delle attività che compongono il
progetto possa essere modificata in modo rilevante andando a forzare il
personale a comprimere i tempi di svolgimento del lavoro. Ovviamente la
capacità di spuntare performance migliori dal punto di vista temporale si
43
scontra inevitabilmente con i maggiori oneri dovuti a straordinari ed extra costi
per forniture urgenti. In queste condizioni si pongono dunque scelte di
convenienza economica tra alternative diverse: la prima consiste nella ricerca di
una prestazione temporale normale (normal timing), mentre la seconda prevede
la ricerca di una prestazione temporale di rottura (crash timing). A questo
proposito, per riuscire a valutarne la convenienza economica, considerando il
beneficio indotto dall’accorciamento della durata complessiva del progetto, è
opportuno correlare la differenza di costo tra le due alternative con la
corrispondente differenza temporale mediante il calcolo di un cost slope definito
come:
cost slope = (crash cost – normal cost) : (normal timing – crash timing)
Ovviamente tale valutazione deve partire dalla considerazione che la
diminuzione della durata del progetto comporta di intervenire riducendo
solamente la durata di quelle attività che rientrano nel percorso critico, in
quanto l’accorciamento dei tasks che non fanno parte di questo percorso non
porterebbe alcun beneficio in termini di durata complessiva del progetto.
Inoltre è necessario tenere presente che non risulta sempre proficuo puntare
alla massima riduzione della durata del progetto, in quanto il vantaggio
ottenuto dall’ottimizzazione temporale potrebbe essere più che compensato da
un aumento dei crash costs, in misura troppo rilevante per l’economicità del
progetto. Come dice Baglieri et al. (2004) risulterà pertanto necessario presidiare
il bilanciamento tra le esigenze di riduzione della durata del progetto
(performance sui tempi) e l’esigenza di mantenere il budget dei costi di
progetto entro livelli accettabili (performance sui costi). Per questo motivo
risulta preferibile attuare una riduzione dei tempi innanzitutto in quelle attività
che hanno un cost slope più basso, ovvero quelle per le quali la correlazione tra il
livello di riduzione della durata e il livello di aumento dei costi è più
favorevole.
44
4.2.2 Un primo modello di controllo: la misurazione dell'avanzamento del
progetto a fronte della sua schedulazione
Il controllo dell’avanzamento all’interno di un progetto consiste nel misurare di
volta in volta il lavoro eseguito, annotando le attività completate e la
percentuale di lavoro assolta, per le attività ancora in corso di completamento.
Per calcolare tale informazione è necessario che l’avanzamento di ogni attività
venga rapportato al proprio peso rispetto all’intero progetto: si parla in questo
caso di avanzamento ponderato, che viene calcolato con la seguente espressione
APx = Px * AVx
Dove APx rappresenta l’avanzamento ponderato relativo all’attività x, Px è
invece il costo previsto dell’attività stessa, ed infine AVx è la sua percentuale di
avanzamento. Ne consegue che l’avanzamento complessivo del progetto alla
data (timenow) è dato dalla somma degli avanzamenti di tutte le attività
APtot = Σ Apx
Tali rilevazioni effettuate in corso d’opera permettono di costruire la curva che
rappresenta l’avanzamento del progetto nel tempo
Curva del valore del lavoro svolto
Euro
300
250
200
150
100
50
0
1
2
3
4
5
6
7
8
9
10
Mese
Figura 4.4: Curva del valore del lavoro svolto (Fonte: “Materiale interno aziendale”)
45
La curva di avanzamento ponderato che si ottiene, confrontata con la curva di
previsione, fornisce al project manager, responsabile del controllo del progetto,
informazioni sull’eventuale ritardo/anticipo delle attività e sulla quantità di
lavoro non ancora eseguita.
Curve avanzamento - budget
Avanzamento
400
budget
300
200
effettivo
100
0
1
2
3
4
5
6
7
8
Mese
Figura 4.5: Analisi dello scostamento tra budget e spesa effettiva (Fonte: “Materiale interno
aziendale”)
Questo processo consente di individuare gli scostamenti dal piano che
richiedono misure correttive, per recuperare nei confronti della schedulazione
e/o del budget.
4.2.3 Il modello dell’earned value
Come si è detto anche all’inizio di questo capitolo il confronto tra gli obiettivi e i
risultati economici effettivamente raggiunti deve tenere conto del fatto che
“potrebbe succedere che i costi consuntivi siano più bassi, rispetto a quanto era
stato previsto a budget, non tanto per ragioni di efficienza, quanto piuttosto
perché a causa dei ritardi intercorsi nello svolgimento del progetto si è speso
meno di quanto era stato previsto, in riferimento ad un certo stato di
avanzamento” (Baglieri et al, 2004). In altri termini, i costi sostenuti in un certo
intervallo di tempo non dipendono solamente dall’efficienza nei processi di
utilizzo delle risorse, ma anche dal particolare stato di avanzamento in cui si
46
trova il progetto, ragion per cui l’analisi congiunta della “performance di costo”
e della “performance di avanzamento”, alla base del modello dell’earned value,
consente di realizzare il controllo di tipo budgetario di tutti i progetti, anche
quelli più prolungati nel tempo. L’earned value consente quindi di esprimere la
misura dello stato di avanzamento mediante la determinazione di un valore
economico attribuibile alla frazione di progetto completata.
Per comprendere questo modello è necessario prima di tutto dare alcune
definizioni fondamentali:
Budgeted Cost of Work Scheduled (BCWS): corrisponde al costo previsionale o di
budget delle attività programmate, dato dalla somma del totale dei costi
budgetati per il lavoro che deve essere eseguito, più il costo budgetato del
lavoro indiretto e il costo per compiti proporzionali, in un determinate arco di
tempo.
Budgeted Cost of Work Performed (BCWP): si tratta in questo caso del costo a
valori previsionali o di budget associato alle attività del progetto che sono state
realizzate (anche parzialmente); talvolta lo si chiama anche earned value (valore
assorbito).
Actual Cost of Work Performed (ACWP): il costo effettivo del lavoro eseguito
rappresenta il costo consuntivo associato alle attività di progetto effettivamente
realizzate (anche parzialmente) in un determinato periodo di tempo.
Il confronto tra i costi previsionali (BCWS) e i costi consuntivi (ACWP) non può
essere effettuato se non si considera parallelamente anche la dimensione
temporale, poiché gli scostamenti tra queste due grandezze potrebbero essere
imputabili anche al particolare stato di avanzamento raggiunto dal progetto. A
partire dalla conoscenza di questi valori è possibile calcolare non solo tutti gli
eventuali scostamenti di costo e di schedulazione, che possono essere sia
positivi che negativi, ma anche alcune misure di efficienza nell’avanzamento
del progetto, come ad esempio:
47
lo scostamento di costo (cost variance), ottenuto dalla differenza tra i costi
previsti a budget per il lavoro eseguito e il costo effettivamente sostenuto
per completare le attività:
scostamento di costo = BCWP – ACWP
A partire dagli stessi valori sarà inoltre possibile calcolare il Cost Performance
Index (CPI), dato dal rapporto tra il Budgeted Cost of Work performed e l’Actual
Cost of Work Performed. Questo indicatore della performance di costo esprime
un rendimento positivo se superiore a uno e viceversa.
lo scostamento di schedulazione (schedule variance), dato dalla differenza tra il
costo previsto a budget per le attività completate e il costo previsto a budget
per il lavoro programmato:
scostamento di schedulazione = BCWP – BCWS
Conoscendo il valore di questi due indicatori è possibile derivare l’SPI
(Schedule Performance Index), l’indicatore usato per misurare la performance
dei tempi. L’SPI si ottiene dividendo il BCWP per BCWS ed esprime un
rendimento positivo se superiore a uno e viceversa.
Nel grafico riportato in figura 4.6 si vede che il punto B rappresenta il livello di
costo raggiunto sulla base del lavoro effettivamente svolto alla data di
riferimento. Il punto A invece indica in quale momento temporale si sarebbe
dovuto sostenere lo stesso livello di costi di B, per cui si desume che la
differenza tra A e B lungo l’asse orizzontale esprime il ritardo temporale nello
svolgimento complessivo del progetto.
48
Figura 4.6: Il modello di analisi dell’earned value (Organizzare e gestire progetti, Baglieri et al.,
ed. Etas 2004)
Fleming e Koppelman (2006) hanno individuato una serie di metodi diversi che
assistono nel processo di misurazione dell’earned value:
metodo 50/50: si attribuisce un punteggio di 50% al work package nel
momento in cui l’attività viene iniziata, mentre i residui 50 punti sono
attribuiti al completamento del pacchetto;
metodo 0/100: questa tecnica prevede di attribuire un valore di 100 al
pacchetto di lavoro solamente nel momento in cui esso viene completato,
mantenendo fino a quel momento un valore pari allo 0%;
milestone ponderati: ad ogni milestone vengono attribuiti dei valori di budget
rapportabili al budget totale del progetto, in modo tale da associare
determinati pesi percentuali a ciascun milestone;
percentuale di completamento: in questo caso si associa al progetto una
percentuale che esprime la frazione di lavoro completato rispetto al lavoro
complessivamente previsto;
unità o standard equivalenti: ad ogni attività viene attribuito un valore
standard di completamento, utili soprattutto nel caso di progetti ripetitivi.
49
Oltre ad aiutare il project manager nell’effettuare valutazioni di economicità del
progetto sotto il profilo delle prestazioni di tempo e costo, il modello dell’earned
value è particolarmente utile anche per formulare delle previsioni aggiornate
circa il futuro svolgimento del progetto; tali previsioni si riferiscono spesso alla
misurazione preventiva dei costi totali stimati al completamento del progetto
(EAC: Estimated Costs at Completion), e possono essere svolte seguendo diversi
approcci possibili. Esso consiste nella somma dei costi di tutti gli incarichi
completati, più la stima di quelli da sostenere per completare tutti i compiti in
corso, più il valore attualmente previsto per completare tutti i lavori futuri.
4.3 CHIUSURA O ESTENSIONE DEL PROGETTO
Riprendendo la definizione generale di progetto “un progetto è uno sforzo
complesso con un inizio e una fine ben definiti, un complesso coordinato d’azioni
finalizzato a creare un prodotto, un servizio o un risultato unico e determinato, nel
rispetto dei limiti stabiliti di tempo e di risorse impiegati per raggiungere tale obiettivo
finale…” (Kerzner Harold, 2005; Baglieri et al., 2004; PMBOK® Guide 2000),
risulta evidente che ogni progetto deve avere una fine ben definita; il project
manager di conseguenza per completare il proprio compito deve occuparsi
anche di chiudere ufficialmente il progetto, nel rispetto delle scadenze. Per la
fase di chiusura il project manager appronta un piano e una schedulazione
dettagliati, che prevedono una serie di punti che devono essere assolutamente
affrontati. Per poter chiudere il progetto è necessario innanzitutto affrontare il
tema del contratto, con la consegna e l’accettazione da parte del cliente dei
prodotti o dei servizi offerti, per poter poi passare alla parte amministrativa
che prevede la riscossione dal cliente e la chiusura dei libri contabili; viste le
attività che si devono eseguire i massimi responsabili durante la fase di
chiusura saranno il project manager e l’amministratore del contratto.
In particolare il project manager deve assicurarsi che le attività del progetto
vengano chiuse in modo efficace ed economico, informando tutti
i settori
finanziari e le unità specialistiche della cessazione del progetto e controllando i
pagamenti del cliente, fino a quando il debito non sia stato saldato.
50
Dall’altra parte l’amministratore del contratto ha il compito di assicurarsi che
tutti i documenti formali inerenti l’accettazione da parte del cliente siano stati
regolarmente firmati, in modo tale da disporre di un accordo che attesti
l’adempimento di tutti gli obblighi contrattuali e che sollevi l’azienda da
ulteriori obblighi, a eccezione di quelli inerenti all’eventuale garanzia.
Al termine della chiusura si apre l’ultima importante fase della gestione di un
progetto: la sua valutazione. Se questa valutazione formale post completamento
non venisse eseguita l’esperienza maturata non servirebbe a nulla in quanto si
rischierebbe di ripetere gli stessi errori per diverse volte, a tutto danno
dell’organizzazione. Questo passo è dunque di fondamentale importanza in
quanto consente non solo di individuare chiaramente gli errori che sono stati
compiuti, ma anche di verificare le conseguenze che hanno portato e di
ipotizzare delle possibili soluzioni da adottare per evitare in futuro il ripetersi
degli stessi sbagli.
51
52
5 PROJECT PORTFOLIO
MANAGEMENT STRATEGICO
5.1 PROGETTI CHE FANNO CRESCERE UN’AZIENDA
Per assicurare la crescita costante di un’impresa, di un’istituzione, di un ente o
qualsiasi altra organizzazione è fondamentale la presenza di una guida a livello
strategico che definisca chiaramente una serie di aspetti, senza i quali tale
crescita sarebbe inimmaginabile. Innanzitutto, come afferma Archibald (2004), è
fondamentale che vi sia una totale trasparenza e chiarezza su quella che è l'idea
(vision) di che cosa sarà o dovrà essere l'organizzazione, che descriva il suo
orientamento generale per il futuro, in quanto la mancanza di tale requisito
fondamentale impedirebbe la maturazione, in tutti coloro che vi lavorano, del
consenso e della tensione (commitment) verso il raggiungimento del traguardo
strategico prefissato. In un secondo momento, solamente dopo aver condiviso la
vision e aver ottenuto il consenso e l’impegno di tutti, è necessaria la
pianificazione e l’implementazione di tutti i programmi e progetti specifici,
nell’ambito del portafoglio di progetti dell’organizzazione, che garantiranno
l’attuazione delle strategie necessarie a raggiungere gli obiettivi definiti. Come
si può osservare dalla figura 5.1, gli obiettivi e le strategie si inquadrano entro
una struttura articolata gerarchicamente, in cui le strategie del livello superiore
ispirano gli obiettivi per il livello intermedio i quali, a loro volta, si traducono
nelle relative strategie di conseguimento.
53
Figura 5.1: Gerarchia di obiettivi, strategie e progetti (Project Management, Russel D.
Archibald, ed. Franco Angeli 2004)
È assolutamente fondamentale osservare come i progetti siano il principale
veicolo della “crescita per salti”, espressione che indica la realizzazione di
iniziative di rilevante entità, necessarie all’espansione o ad un salto di qualità
(Archibald, 2004); in una qualsiasi unità organizzativa dunque la “crescita per
salti” può avvenire solamente attraverso l’esecuzione di progetti complessi, il
cui successo può essere garantito solamente ricorrendo a principi e metodi di
project management ben collaudati.
54
5.2 PROJECT PORTFOLIO MANAGEMENT STRATEGICO
Come già anticipato i progetti realizzati all’interno di un’azienda servono a
mettere in pratica le strategie aziendali e tradurre in realtà gli obiettivi stabiliti;
ne deriva dunque che i progetti non devono essere gestiti come entità isolate
indipendenti l’una dall’altra, ma come assiemi coerenti e ben assortiti che
implementano una strategia di livello superiore, secondo logiche di portafoglio
(Project Portfolio Management).
Secondo questa prospettiva gli alti dirigenti sono i “committenti”, ossia coloro
che definiscono la pianificazione strategica tracciando la rotta futura
dell’organizzazione e selezionando i progetti da inserire nel portafoglio. Poi,
per ciascun progetto, vi sarà un project manager che autorizza e realizza le
azioni specifiche con cui implementare le strategie di crescita.
La congiunzione che il Project Portfolio Management garantisce tra la
pianificazione strategica e il Project Management è un'interazione necessaria
all'efficacia dei progetti nell'implementare le strategie. Secondo Combe (2000) "è
importante che l'alta direzione concepisca i progetti come un mezzo per
l'implementazione delle strategie, e che li metta nelle migliori condizioni per
adempiere a questa loro funzione. Ma è altrettanto importante che i project
manager capiscano quali sono le strategie dell'impresa”. Da ciò si deduce che
l'organizzazione può conseguire il vero beneficio solamente quando la relazione
progetto-strategia presuppone uno scambio interattivo e biunivoco.
L’importanza di gestire l’intero portafoglio di progetti, in un quadro unitario ed
integrato, deriva dal fatto che nessuna organizzazione dispone di risorse
illimitate, tali da riuscire a pianificare e realizzare tutti i progetti concepibili; da
qui nasce la necessità di definire degli opportuni meccanismi di prioritizzazione
dei progetti appartenenti a un determinato portfolio, per riuscire quindi ad
ottenere i massimi benefici per l’intera organizzazione, evitando parallelamente
il rischio che un certo numero di progetti venga gestito singolarmente e che
55
l’azienda
venga
danneggiata
a
causa
dei
ritardi
conseguenti
alla
sovrapposizione degli stessi.
Di seguito (Tabella 5.1) è riportato il processo di Project Portfolio Management
così come dovrebbe essere gestito per riuscire a soddisfare i propri obiettivi in
maniera efficace ed efficiente.
Tabella 5.1: Processo di Project Portfolio Management (Fonte: “Project Management, Russel D.
Archibald, ed. Franco Angeli, 2004)
56
5.2.1 Obiettivi e vantaggi del Project Portfolio Management
La gestione integrata e unificata dell’intero portafoglio di progetti, così come
descritta sopra, permette di raggiungere una serie di obiettivi che possono
essere raggruppati in tre macro categorie (Archibald, 2004, p.228):
Massimizzazione del valore: il primo obiettivo di primaria importanza
che il Project Portfolio Management si propone di ottenere è la possibilità
di acquisire e allocare le risorse adeguate al complesso dei progetti, in
maniera tale da massimizzare il valore del portafoglio secondo il
parametro stabilito, assicurandosi che tali risorse vengano utilizzate
produttivamente ed efficacemente per i lavori necessari a completarli
tutti;
Bilanciamento del portafoglio: sviluppo di un portfolio equilibrato
rispetto ai parametri che l'impresa ha stabilito, con un compromesso
oculato fra il rischio e la remunerazione, la facilità di realizzazione e
l'attrattiva;
Coerenza strategica: selezione e gestione di tutti e soli quei progetti in
linea con la strategia di business concordata a livello direzionale, dando
quindi vita a un portafoglio di progetti coerente con il traguardo
strategico prefissato.
5.2.2 Selezione e priorità dei progetti di un portfolio
Analizzando
il
processo
di
Project
Portfolio
Management
descritto
precedentemente è possibile evidenziare immediatamente due attività
fondamentali, da cui dipende la capacità di ottenere o meno i vantaggi
derivanti dalla gestione del portafoglio di progetti. Le due fasi cui si sta facendo
riferimento sono, in ordine logico, la selezione dei progetti da assegnare al
portfolio e la successiva attribuzione delle priorità in riferimento alla strategia
aziendale.
57
Nonostante ciascuna categoria di progetti implichi un processo distinto di
selezione delle nuove iniziative, tale processo è finalizzato prevalentemente al
raggiungimento dei tre fini del Project Portfolio Management, cui si è fatto
riferimento anche nel precedente paragrafo. Nel sottolineare l’importanza del
processo di selezione per ottenere tali vantaggi, è utile però al contempo
sottolineare quanto affermato da Cooper (1999):
"Nessuno di questi tre fini sembra dominante, e nessun modello o metodo di gestione
del portfolio sembra idoneo al conseguimento di tutti e tre".
Ciò è dovuto al fatto che il processo di Project Portfolio Management ha una
natura dinamica e poggia esclusivamente su informazioni incerte e mutevoli.
Tuttavia, nonostante l’elevata variabilità delle informazioni disponibili la quasi
totalità dei modelli di Project Portfolio Management richiede dati di una
precisione impossibile da ottenersi con la necessaria affidabilità; in altre parole,
la sofisticazione dei modelli supera di gran lunga la qualità dei dati di input,
con conseguente perdita di efficacia nella gestione del portafoglio.
La necessità di stabilire un ordine nell’esecuzione dei progetti emerge nel
momento in cui diversi progetti competono per risorse limitate, e si pone quindi
il problema di come definire e comunicare le priorità relative di ciascun
progetto, rispetto a tutte quelle iniziative che appartengono al medesimo
portfolio. La decisione di fornire risorse aggiuntive, piuttosto che rallentare lo
svolgimento di uno o più progetti, può essere presa solamente quantificandone
opportunamente le priorità, attraverso l’attenta pianificazione del progetto e la
previsione dettagliata di tutte le sue necessità. Nel caso di mancanza di un
metodo efficace per la determinazione delle priorità, può infatti accadere che
siano prese decisioni dissimili, o contraddittorie, su due progetti simili, con il
risultato che ambedue ne risultano danneggiati.
Di seguito si elenca una serie di fattori che hanno un’influenza rilevante sulla
definizione delle priorità, sottolineando che ciascuno di essi ha un peso relativo,
58
variabile a seconda dell’organizzazione e del tipo di progetto (Kerzner Harold,
2005):
data di completamento o consegna e sua prossimità;
rischi penali;
rischi concorrenziali;
importanza del committente;
redditività dell'investimento
costi, degli investimenti e/o dei profitti, e relativa incertezza;
riflessi su altri settori dell'organizzazione;
Sulla base dei punteggi ottenuti da ciascun progetto si è dunque in grado di
stabilirne le priorità. Il migliore tra i modelli utilizzabili per l’assegnazione delle
priorità ai progetti prevede una classificazione in tre categorie:
1. progetti prioritari, che hanno la precedenza sugli altri,
2. progetti normali, che sono finanziati ma che non sono considerati prioritari;
3. progetti di riserva, che attendono la disponibilità di fondi e di altre risorse.
5.2.3
Gestione delle risorse aziendali e delle operazioni negli ambienti
multiprogetto
Come si può desumere da quanto detto finora riguardo il tema della gestione
degli ambienti multi progetto, una causa frequente di ritardo, che si traduce in
penalità, eccedenze dei costi e altre conseguenze indesiderabili, è l’impegno in
un numero di contratti e progetti eccessivo, rispetto alle risorse disponibili
all’interno dell’organizzazione. Per superare tale problema si è dunque
cominciato a gestire le risorse in maniera unificata per tutti i progetti. Per
riuscire a garantire l’acquisizione, la fornitura e l’allocazione delle risorse
necessarie a completare il lavoro in modo tempestivo ed efficiente è stata
introdotta una fase preliminare di previsione delle risorse necessarie nelle
singole funzioni coinvolte, ed una successiva di pianificazione del lavoro che
tenesse conto dei limiti delle risorse disponibili.
59
Oltre alla gestione delle risorse, l’altra fase critica nell'ambito dei progetti
multipli riguarda la pianificazione e il controllo delle operazioni (operations
planning and control) che integra e controlla, a livello generale, e per tutti i
progetti, gli apporti delle diverse funzioni aziendali.
Il successo di tale funzione è strettamente condizionato alla fiducia che l’alta
direzione ha nella validità della pianificazione, come strumento utile a valutare
e quantificare precisamente le conseguenze di determinate decisioni sui costi e
sulle strategie di business, attraverso l’elaborazione di un feedback adeguato
che permette di comparare i risultati effettivi derivanti da tali azioni correttive
con quelli previsti inizialmente. Ciò che occorre per raggiungere tali obiettivi e
offrire soluzioni a problemi che toccano un ambito più vasto è una funzione
centrale di pianificazione, in grado di valutare come le decisioni prese dalle
singole funzioni si riflettono sulle performance dell’intero progetto. Perciò i
principali compiti che la funzione di operations planning and control deve
svolgere sono:
coordinare le attività di pianificazione nelle funzioni di marketing,
engineering, produzione e installazione, attraverso l'approntamento di
schedulazioni generali di impresa;
coordinare la pianificazione delle singole funzioni e individuare le
dipendenze funzionali nell’esecuzione del progetto, con un orizzonte di
pianificazione commisurato alle attività già decise, a quelle proposte e a
quelli prevedibili per i singoli progetti;
mantenere l’uso di sistemi di simulazione per valutare le conseguenze di
strategie alternative e per suggerire soluzioni all’alta direzione.
60
6 IL SISTEMA INFORMATIVO
DI PROJECT MANAGEMENT
6.1
IL
SISTEMA
INFORMATIVO
INTEGRATO
DI
PROJECT
MANAGEMENT
L’organizzazione e la gestione di un progetto si basa prevalentemente sullo
scambio e trasferimento di informazioni; nel lavoro per progetti è dunque
fondamentale disporre di una grande quantità di informazioni di varia natura tecniche, economiche, organizzative, di prestazione temporale, di performance
qualitativa e così via - per riuscire a coordinare e gestire i diversi elementi che lo
compongono (attività, persone, mezzi). Il sistema di project management è
dunque lo strumento a supporto della gestione del progetto che permette di
rilevare dati, di produrre informazioni, di comunicare e di rendere disponibili
le medesime, nei tempi e nei modi opportuni, a tutti coloro che sono in qualche
misura coinvolti nel progetto stesso.
Nel caso in cui si debbano gestire più progetti contemporaneamente, sfruttando
le risorse provenienti da pool unificati, è necessario disporre di un sistema
informativo unificato di pianificazione e di controllo, che permetta di valutare e
gestire d’anticipo i rischi dei singoli progetti, coerentemente con i rischi
aggregati del portafoglio, di definire e controllare le specifiche di qualità dei
prodotti intermedi e finali dello stesso (i cosiddetti deliverable), di pianificare e
controllare la sequenza e le scadenze dei molteplici work package, di fornire
61
informazioni precise che riguardano l’avanzamento dei lavori e l’assorbimento
dei costi, nonché di effettuare delle previsioni per il futuro utili ad individuare e
prevenire eventuali problemi, aggiornando la direzione e i clienti sulla
situazione corrente e sulle sue prospettive in termini di qualità, costi e tempi.
6.1.1 Cos'è un sistema informativo di Project Management?
Archibald (2004, p.153) definisce il Project Management Information System
(PMIS) come un sistema costituito da documenti (contenitori di informazioni) e
procedure, processi e sistemi software per la preparazione, manutenzione,
conservazione, trasmissione e uso dei documenti. Questi processi, sistemi e
procedure sono finalizzati a creare, pianificare ed eseguire la generalità dei
progetti in una certa organizzazione. I principali elementi che costituiscono un
PMIS sono:
i dati. Essi sono la rappresentazione oggettiva della realtà del progetto;
dall’elaborazione dei dati, svolta secondo criteri, logiche e algoritmi propri
delle varie discipline che le utilizzano, si ottengono le informazioni
necessarie per la gestione efficace del progetto;
le procedure. Sono la descrizione del lavoro del progetto relativo al
funzionamento del suo sistema informativo, che descrive e determina la
sequenza e il parallelismo esistente tra le diverse attività o mansioni che lo
compongono;
i mezzi tecnici. Quando si parla di mezzi tecnici ci si riferisce alle tecnologie
utilizzate per elaborare e trasformare i dati in informazioni che vengono
poi successivamente archiviate, reperite e trasmettesse quando necessario
a chi deve utilizzarle per svolgere la propria attività o per prendere
decisioni. Appartengono a questa classe le apparecchiature hardware e
software di base, i software di rete e di trasmissione dati, nonché quelle
tecnologie che permettono il trattamento dell’informazione;
62
le persone. Le persone rappresentano una risorsa centrale nei sistemi
informativi, in quanto sono coloro che lavorano per progettare, sviluppare
e mantenere il Project Management Information System;
i principi ispiratori. Essi rappresentano i principi che ispirano il sistema
informativo di progetto; sulla base di tali principi ispiratori si definiscono
le modalità secondo cui i quattro elementi appena descritti devono
coordinarsi per perseguire le finalità stabilite per le quali viene costruito il
PMIS. Le principali decisioni in merito sono riferibili ai seguenti quesiti:
Sistema informativo accentrato o decentrato?
Ragioni di riservatezza dei dati e delle informazioni, lo stile di
direzione adottato in azienda, abitudini consolidate di gestione del
potere possono rientrare fra i fattori che incidono su una scelta
piuttosto che un’altra;
Gestione
interna
al
team
o
esternalizzazione
del
sistema
informativo di progetto?
A influenzare la scelta fra outsourcing e insourcing vi possono essere
diversi fattori, fra cui la criticità temporale dell’informazione
necessaria, l’esigenza di focalizzare il team sulle attività core del
progetto senza sovraccaricarlo con attività gestionali di scarsa
rilevanza ai fini del progetto.
6.2 SISTEMI INFORMATIVI DI PROJECT MANAGEMENT WEB BASED
Parallelamente all’avvento dell’era informatica e all’affermazione dei metodi di
pianificazione reticolare (PERT, Cpm, Pdm) si è sviluppato il software per la
pianificazione e il controllo dei progetti, diventando ben presto uno strumento
di fondamentale importanza per il project management. In particolare, con la
comparsa dei sistemi con funzionalità web, cui si è assistito negli ultimi anni, si
è potuto cogliere ancora più compiutamente tutte le potenzialità d’integrazione
dei documenti progettuali in un sistema unico.
63
Sempre più organizzazioni operano al giorno d’oggi su scala mondiale,
sviluppando distributed projects, che implicano la necessità da parte del project
manager di gestire dei distributed team. Tali necessità favoriscono la
consolidazione di tendenze ben definite, come quella dell’abbandono dei
complessi sistemi applicativi per PC e dell'adozione di sistemi di facile impiego
basati su browser Web. Il costante sviluppo e miglioramento dei software di
project management con funzionalità Web porta alla nascita di un nuovo
dominio applicativo, meglio noto con il nome di Distributed Project Management,
e di un nuovo grande mercato dei software tutt’ora in forte espansione
(Patterson, 2002).
Timmons (2000) afferma che il successo dei project manager dipende
fortemente da quanto si sanno applicare le potenzialità di Internet, facendo
diretto riferimento a tre requisiti fondamentali:
form data posting;
data linking;
process authorization.
Il form data posting rende possibile lo scambio delle informazioni con l’impiego
di comuni browser web; ciò è garantito dal fatto che esso implica lo sviluppo di
opportuni form elettronici che convertono i dati cartacei in database elettronici
favorendone di conseguenza la registrazione all’interno dei database.
Il data linking, reso possibile dall’uniformazione del database ad uno standard
aperto, che assicura il collegamento di sistemi software di vari fornitori, il che
permette di migliorare l’accuratezza dei dati inseriti ed evitare inutili
duplicazioni nel loro inserimento.
La funzione di process authorization si serve dell’impiego delle firme
elettroniche per controllare l'accesso ai database, e per sorvegliare il flusso dei
dati, salvaguardando l’affidabilità nel controllo di configurazione sui dati
progettuali più sensibili.
Il diffondersi di queste tre funzioni, tipiche del Project Management aperto al
Web, permette di ottenere numerosi vantaggi tra cui i principali sono lo
64
snellimento del processo di impostazione, il potenziamento dei rendiconti, la
disponibilità ininterrotta del repository progettuale, il miglioramento del
controllo di baseline del progetto e la semplificazione dell'archiviazione delle
informazioni, come disegni, manuali, verbali di collaudo e così via (Archibald,
2004, p.156).
Nei paragrafi che seguono si va a descrivere brevemente ciascuna delle
categorie di software applicativi di project management.
6.3 CATEGORIE DI SOFTWARE DI PROJECT MANAGEMENT
Prima di entrare nello specifico dei vari moduli software di project
management, tipicamente utilizzati nel contesto aziendale, viene fornita una
definizione di suite di software:
“Le suite di software applicativo sono insiemi coordinati di moduli software, dotati delle
funzionalità specifiche delle categorie considerate, ma sviluppati in determinati settori
applicativi. In molti casi i moduli che compongono le suite sono valutabili
separatamente, ma il grande vantaggio dell'impiego di una suite risiede nell'intima
integrazione fra suoi moduli e nell'agevole interscambio di informazioni che si può
stabilire fra questi. Le suite di software applicativo di project management sono adatte
all'intera gamma delle organizzazioni, grandi e piccole, e dei progetti, semplici e
complessi” (Archibald, 2004, p.158).
6.3.1 Software di Process Management
La prima categoria di software analizzata è quella dei software di Process
Management che, come attesta la PMBOK® Guide, ha l’obiettivo principale di
integrare il processo di project management con quelli delle singole unità
specialistiche
che
contribuiscono
allo
svolgimento
del
progetto,
o
semplicemente tramite la distribuzione della documentazione relativa alla
metodologia applicata, oppure addirittura estendendo il loro contributo alla
valutazione del rischio, all’analisi della redditività dell’investimento, così come
al monitoraggio dei problemi (issues logging) e al miglioramento continuo della
65
metodologia di gestione. Le principali caratteristiche che rendono questa
categoria di software un must nella gestione dei progetti sono:
capacità di elaborare i diagrammi di flusso dei processi;
sono totalmente basati sulla specifica metodologia di process management
dell'organizzazione;
sono collegabili automaticamente ad altri prodotti software di project
management.
6.3.2 Software di Schedule Management
I software di schedule management, a differenza del precedente, sono in grado di
pianificare e ordinare in sequenza le attività progettuali, producendo inoltre dei
rapporti dettagliati di schedulazione quali il diagramma di Gantt e/o i
diagrammi reticolari. Un’altra caratteristica saliente di questi moduli è
l’allocazione ottimale delle risorse, che si basa sull’analisi e sul trattamento della
critical chain o del resource critical path, con l’obiettivo di far corrispondere le
risorse disponibili con le risorse richieste, comunicando ai manager e ai
pianificatori dove e quando si presentano o si prospettano eventuali esuberi o
carenze.
Tuttavia i prodotti di questa categoria non supportano solamente la
pianificazione e la schedulazione, ma assicurano anche il monitoraggio e il
controllo sia di progetti isolati che dell’insieme dei progetti di un portfolio,
aggiornando la situazione e le previsioni di schedulazione secondo
l’avanzamento del progetto con riferimento a baseline controllabili.
Visto che l’attività di schedulazione è richiesta da tutti i progetti, in tutti i campi
applicativi e in tutti i settori, questa categoria di software trova vasto impiego
ed è quindi universalmente applicabile alla maggior parte dei processi di
business o dei processi progettuali.
66
6.3.3 Software di Cost Management
I software di cost management sono costituiti da programmi sofisticati in grado
di gestire, nell'arco dell'intera vita del progetto, tutti i suoi elementi di costo,
dalle stime iniziali fino alla loro consuntivazione e analisi, per la misura della
performance in termini di valore assorbito e scostamenti di schedulazione e
sforzo economico sostenuto.
6.3.4 Software di Communication Management
I prodotti software di questa categoria consentono la diffusione efficiente di
tutte le informazioni di progetto, ai manager e ai membri del team, sfruttando
l’utilizzo di dispositivi di notifica selettiva come i bullettin board e i message
trigger.
Fanno parte di questa categoria le cosiddette timesheet, ossia gli strumenti che
consentono ai membri del team di registrare le ore di lavoro che ciascuno di essi
effettivamente dedica ai singoli compiti che gli sono stati assegnati, favorendo
in questo modo il controllo del progetto. Le timesheet possono essere viste come
delle agende elettroniche in cui si tiene traccia di qualsiasi modifica apportata
al piano in termini di sforzo dedicato, fungendo per di più il ruolo di interfaccia
con i sistemi di controllo finanziari.
6.4
IL PROCESSO DI SELEZIONE DEI SOFTWARE DI PROJECT
MANAGEMENT
Il mercato dei software per il project management è particolarmente ampio e
variegato, motivo per cui la selezione del software più adatto alle specifiche
procedure di una determinata organizzazione è un compito assai complesso e
impegnativo. Come si può osservare dalla figura 6.1, molti degli aspetti da
considerare nella selezione non si riferiscono alle funzioni o alle caratteristiche
del software, ma anche ad aspetti puramente commerciali; ciò è dovuto al fatto
che in questo ambito l’evoluzione tecnologica espone rapidamente al rischio
dell’obsolescenza chi non resta al passo, ragion per cui l’aspetto legato
all’assistenza tecnico-commerciale e dello sviluppo del prodotto fornita dal
67
player diventa un fattore particolarmente critico per chi decide di acquistare il
software.
1. Affidabilità e reputazione del fornitore
anzianità in affari;
reputazione
mole dell’organizzazione;
specializzazione nelle applicazioni
di project management;
numero di prodotti offerti;
solidità finanziaria;
2. Caratteristiche del prodotto
informazioni generali sul prodotto;
sinergia con gli altri prodotti;
dati per la definizione dei progetti;
gestione della pbs;
gestione delle scadenze;
dati per la definizione delle attività;
interfaccia per l’utilizzatore;
distribuzione geografica dei punti
di vendita
presenza all’estero;
referenze, o elenco dei clienti;
offerta d’addestramento.
importazione ed esportazione dei
dati da e verso altri sistemi;
formati di calendario;
formati dell’output;
architettura di database;
dati di monitoraggio;
dati di costo.
3. Documentazione
guida on-line, a più livelli;
materiale per l’addestramento;
procedure ben documentate di
correzione degli errori;
manuale;
manuale on-line;
scheda di consultazione rapida.
4. Assistenza all’uso
linea telefonica dedicata;
numero verde;
seminari su argomenti specifici;
segnalazione degli aggiornamenti;
bollettini e notiziari;
assistenza su web;
corsi di addestramento;
servizi
di
consulenza
utilizzatori;
user groups;
posta elettronica.
5. Aspetti contrattuali
funzionalità fornite;
licenza d’installazione;
modifiche alla fornitura;
formazione e addestramento;
aggiornamento e miglioramento
del prodotto;
responsabilità del fornitore;
garanzia in caso di fallimento del
fornitore;
garanzia in caso di fallimento
dell’acquirente;
riservatezza sui dati;
efficienza del prodotto fornito;
installazione e accettazione;
garanzia tecnica e manutenzione;
prezzo e condizioni;
diritti di esclusiva.
agli
Figura 6.1 Aspetti tipici considerati da chi acquista software applicativo di project management
( “Project Management”, Russel D. Archibald, ed. Franco Angeli 2004)
68
Il processo di selezione, adattamento e applicazione di una moderna suite di project
management per la gestione unificata di tutti i progetti appartenenti ad un portfolio,
costituisce esso stesso un progetto vero e proprio, per la cui riuscita si rende a sua
volta necessario l’utilizzo delle best practices e di tutti i migliori strumenti di project
management finora descritti. Naturalmente la durata di questi progetti è strettamente
legata alla mole e alla complessità dell’organizzazione, e del suo grado di maturità
nella disciplina del project management. In molti casi si rende inoltre opportuno
strutturarli in più stadi, affrontando ogni volta una singola categoria progettuale, o
un singolo portafoglio di progetti.
Si conclude questo capitolo ricordando un aspetto che, nonostante la sua banalità,
viene tutt’ora molto spesso ignorato: il sistema informativo da solo non è in grado di
gestire nessun progetto. Sono infatti le persone a costituire l’unica vera risorsa per la
sua realizzazione, mentre i software di project management hanno solamente il
compito di incrementare l’efficacia di queste persone nella gestione dello stesso.
Ne deriva dunque che non si ottiene alcun vantaggio se ci si limita a dotare del
miglior software di project management un processo direttivo scoordinato,
inefficiente e arcaico.
69
70
7 SELLE ROYAL SPA
La bicicletta così come la si vede oggigiorno (con movimento a pedali e trasmissione a catena)
venne introdotta solo alla fine del 1800, mentre i primi prototipi furono sviluppati già
all’inizio dello stesso secolo. Ad oggi la bicicletta è il principale mezzo di trasporto in molte
aree del mondo. Si producono più di 130 milioni di biciclette all'anno e, già nel 2003, la
produzione di biciclette ha sorpassato quella di automobili con notevole distacco-100 milioni
contro 42 milioni.
Di seguito sarà presentata l'azienda Selle Royal, leader mondiale nella produzione di
selle per biciclette da oltre cinquant'anni. La sua storia è una continua innovazione
costruita sulla ricerca, sulla tecnologia e il design avanzato.
71
7.1
SELLE ROYAL S.P.A
Selle Royal S.p.A, azienda leader di mercato nella produzione di selle, è presente nel
mondo delle componenti per biciclette sin dal 1956, e ad oggi opera in più di 70 paesi
sparsi in tutto il mondo. Quella di Selle Royal è una storia lunga oltre 50 anni, partita
nel 1956 quando il dottor Riccardo Bigolin rinunciò alla prospettiva di un posto fisso
in una farmacia di Bassano, per cominciare a lavorare nella fabbrica dello zio
specializzato nella produzione di feltro per scarpe e per selle di bicicletta.
Da allora per il gruppo Selle Royal fù un escalation di successi e conquiste sul
mercato mondiale, fino a diventare il marchio di selle più ammirato al mondo, che
produce selle confortevoli di alta qualità per il ciclista amatoriale. Fu così che negli
anni divenne il punto di riferimento per tutto quello che riguarda la scelta per i
singoli ciclisti (AfterMarket), per i grandi produttori di biciclette (Original
Equipment Manufacturer), nonché per le grandi catene del mondo Private Label.
Il termine "Selle Royal” identifica oggi un brand, ed anche il relativo gruppo, che
negli anni è diventato globale: dal 1956 agli anni ‘90 il gruppo si è concentrato sui
mercati europei per poi focalizzarsi fortemente sui cosiddetti mercati “in via di
sviluppo”: nel 1996 apre una produzione di selle in Brasile (che viene chiamata Selle
Bra) che nel 2005, si fonde con Metal Ciclo dando vita a Royal Ciclo.
Nel corso dell’anno successivo, il 1997, viene lanciato Fi’zi:k, brand appositamente
creato e dedicato al mondo dello sportivo professionista. É il 2002 quando viene
acquisita Brooks England (UK), azienda storica inglese che produce selle tradizionali
in pelle. Ed è proprio con l’acquisizione di quest’ultima azienda che il gruppo Selle
Royal S.p.A dà vita a tre marchi completamente indipendenti l’uno dall’altro: Selle
Royal, Fi’zi:k e Brooks England. Tra il 2007 e il 2010 viene acquisita prima
l’americana Crank Brothers, specializzata nel mondo MTB, e successivamente (nel
2010) viene acquisito il 52% di Justek, colosso nella produzione di selle per il mercato
Asiatico. Con questa mossa strategica Selle Royal S.p.A non solo diventa il più
grande produttore mondiale di selle, ma raggiunge anche il fondamentale obiettivo
di rendere il gruppo fisicamente presente anche in Cina, ampliando il proprio
network internazionale verso l’enorme mercato asiatico. In 50 anni di attività il dottor
Riccardo Bigolin ha saputo trasformare quella che era partita come un’azienda di
72
famiglia in un enorme impresa, portandola ai livelli di una vera e propria industria
dallo spessore internazionale.
Con il passare degli anni e col modificarsi dei bisogni dei mercati, l’azienda ha
compreso quanto fosse importante mettere al centro del proprio operato il Cliente e
le sue esigenze: Selle Royal lavora duramente per capire le vere esigenze dei ciclisti
nell’uso della sella, ascoltandoli attentamente e analizzando nei minimi dettagli come
e perché vanno in bici, mettendo in campo costantemente il know-how maturato nel
corso degli anni nella produzione di componenti per biciclette, e proponendo una
costante innovazione tecnologica per riuscire a produrre selle, e non solo, che
rispondano nel migliore dei modi alle esigenze dei propri clienti e che garantiscano il
massimo comfort possibile anche al ciclista più esigente.
Questa mission, che l’azienda persegue sin dal 1956, implica necessariamente una
particolare attenzione anche e soprattutto al mondo che sta al di fuori del “Sistema
Fabbrica”, da cui nasce la necessità di creare una costante relazione per poter
supportare tutti gli stakeholder. Così facendo il valore del prodotto a marchio Selle
Royal, già riconosciuto a livello internazionale per i suoi standard qualitativi
superiori a qualsiasi altro competitor che opera in questo mercato, si consolida
ulteriormente proprio grazie alla relazione che l’azienda è stata in grado di
sviluppare con il Cliente.
Selle Royal S.p.A. però non è solo business e produzione di massa. Lo slogan
aziendale “Support Cyclists” vuole infatti ricoprire una vision di più ampio respiro
che può essere tradotta nelle seguenti parole: “Supportare i ciclisti è il vero impegno
quotidiano di Selle Royal. Sviluppiamo prodotti, servizi e progetti con profonda
passione per il ciclismo. Selle Royal sta evolvendo come un brand capace di ascoltare,
comprendere e anticipare i bisogni dei ciclisti, promuovendo uno stile di vita sempre
più legato all'utilizzo della bicicletta. Tutto questo è supportare i ciclisti. Tutto questo
è Selle Royal.”
Il gruppo Selle Royal, grazie alla diversificazione che ha attuato nel corso degli anni,
è attualmente attivo nella progettazione, produzione e commercializzazione di
numerosi prodotti diversi:
73
Selle da bicicletta che rappresentano ancora oggi il core business dell’azienda,
con più di 30 milioni di selle vendute all’anno;
Accessori per ciclo ( seat-post, bar tape, wheels, crank, ….);
prodotti di abbigliamento per l’utilizzo della bicicletta (borse, scarpe
racing,….).
Ad oggi il Gruppo Selle Royal, grazie anche ai numerosi brand entrati a far parte
dell’organizzazione, è leader indiscussa nei seguenti segmenti di mercato:
- Recreational
- Racing
- Lifestyle
- MTB
L’esercizio in esame, chiuso alla data del 30 giugno 2013, ha riportato un ricavo delle
vendite pari a € 100,7 milioni, in crescita dell’1,3% rispetto ai € 99,5 milioni
dell’esercizio precedente, con un utile netto di € 222.858, risultato che risente del
continuo incremento del costo delle materie prime, +1,0%, rispetto al costo medio
delle stesse registrato l’anno precedente, che segnava già un +2,8%. Nel corso del
2013, il settore del ciclo è infatti stato caratterizzato da dinamiche complesse che, in
parte, hanno rallentato la crescita, dopo un periodo di sviluppo senza eguali nella
storia recente. I fenomeni più salienti che hanno caratterizzato il settore nel corso
dell’esercizio in oggetto possono essere così sintetizzati: un’offerta sempre più
variegata e di qualità, con interessanti innovazioni di prodotto che hanno incontrato
il favore dei consumatori; una predisposizione al consumo che si è ridotta
sensibilmente soprattutto in taluni mercati maturi tradizionalmente rilevanti per i
produttori di cicli e per Selle Royal (come Germania ed Olanda); un contesto
legislativo di riferimento mutato con la cessazione, decretata dall’Unione Europea a
fine Marzo 2012, delle misure protezionistiche (dazi anti-dumping) precedentemente
74
applicate sulle importazioni di selle per biciclette prodotte nella Repubblica Popolare
Cinese.
Il Gruppo Selle Royal S.p.A, forte di un brand portfolio di eccellenza, di una bilanciata
ed efficace presenza globale tanto a livello produttivo che commerciale, nonché di
una chiara visione delle dinamiche attuali e prospettiche, ha tuttavia saputo
interpretare i fenomeni suddetti, anticipandoli e comunque adattandosi ad essi,
limitando al 5,4% il calo delle vendite, rispetto a quello dell’8,5%, subito dal settore
della bicicletta in Europa.
7.2
STORIA DEL GRUPPO SELLE ROYAL
La storia di Selle Royal comincia a Rossano Veneto, il piccolo comune vicentino
diventato quarant'anni fa la capitale mondiale della componentistica per biciclette,
ma soprattutto delle selle. Il Dottor Riccardo Bigolin scelse sin da subito la strada
della sella di qualità per il grande pubblico quando nel 1956, a Pozzoleone, diede vita
ad un piccolo laboratorio, che inizialmente aveva il nome di “Feltrificio Bassanese”,
fino a diventare oggi un marchio internazionale, grazie a una continua innovazione
basata su ricerca, tecnologia e design avanzato: filosofia che ancora oggi guida
l’intero Gruppo.
Nel 1965 la società prese l’attuale denominazione sociale di Selle Royal S.p.A. dando
così vita ad un marchio affermato a livello mondiale che ha oramai oltrepassato
l’obiettivo dei trenta milioni di selle da bicicletta prodotte ogni anno comprendendo
tutti i suoi brand.
Ripercorrendo e analizzando la storia del Gruppo balza immediatamente all’occhio
come essa possa essere frazionata in tre fondamentali steps successivi, ognuno dei
quali appartenente ad un definito arco temporale. Queste tre fasi successive, che
hanno progressivamente portato l’azienda a raggiungere il successo internazionale di
cui gode oggigiorno, possono essere così etichettate:
Lo sviluppo industriale
L’espansione del mercato
75
La brand diversification
Figura 7.1: Raffigurazione delle tappe storiche rilevanti del Gruppo Selle Royal (Fonte: “Materiale
interno aziendale”)
7.3
LO SVILUPPO INDUSTRIALE
La costante innovazione in termini di design e ricerca sui prodotti, ma anche in
termini di sviluppo industriale come mezzo di supporto alla qualità e all’efficienza,
sono stati indubbiamente i due principali driver che hanno caratterizzato i primi anni
della storia del Gruppo Selle Royal.
Nel corso degli anni ’70, anni in cui si è assistito ad uno scenario caratterizzato da
una costante espansione del settore del ciclo, Selle Royal sviluppa e introduce nel
mondo
della
sella
un’innovativa
tecnologia
di
produzione,
caratterizzata
dall’impiego di una schiuma a base di poliuretano integrale. Grazie a questa importante
novità tecnologica, che garantisce un’elevata capacità produttiva e una qualità dei
prodotti offerti assoluta, Selle Royal riesce a conquistare negli corso degli anni
successivi l’incontrastata leadership di mercato.
Con gli inizi degli anni ’80 il processo produttivo conosce una nuova e radicale
trasformazione ed innovazione nell’ambito del segmento delle selle di gamma
medio/alta, con la brevettazione del “Royal Vacuum System” (RVS), un sistema di
76
produzione automatizzato sotto vuoto che consente non solo di unire direttamente la
sella alla schiuma, ma anche di realizzare in serie nuove forme e profili fino a quel
momento impensabili utilizzando i metodi tradizionali.
Come anticipato però la storia di Selle Royal fonda le sue radici e i suoi successi sulla
continua innovazione tecnologica e sul design avanzato, garantiti da una ricerca
capillare di nuovi materiali e tecniche produttive. Ed è proprio seguendo questa
filosofia che negli anni ’90, in uno scenario che privilegia sempre di più il comfort,
Selle Royal inizia ad utilizzare il gel nella produzione delle selle: tale sostanza è
denominata Royalgel™ ed è stata brevettata da Bayer Material Science in Germania.
Grazie ad un innovativo ed avanzato processo di produzione sotto vuoto il
Royalgel™ viene iniettato, prima della schiumatura, tra il liquido poliuretanico (che
diventerà schiuma) e la copertina della sella: si tratta di un gel viscoelastico che ha
come caratteristica fondamentale l’isteresi, ovvero l’assorbimento degli shock con
ritorno molto lento. Inoltre questo materiale ha tra i suoi principali punti di forza il
fatto di non invecchiare, di non indurirsi e di non spostarsi, consentendo in tal modo
al ciclista di percepire una sensazione di comfort superiore.
Questo nuovo sistema di produzione ha permesso di ottenere tre principali vantaggi
rispetto ai modelli prodotti fino a quel momento:
selle più leggere del 20% rispetto alle altre selle normali della stessa categoria,
grazie all'impiego di una schiuma meno pesante della schiuma integrale;
selle sigillate al 100% con conseguente eliminazione dell'assorbimento di
acqua;
massimo livello di comfort garantito dalla speciale struttura tridimensionale
che, secondo precisi test scientifici, permette di ridurre di circa il 40% la
pressione sulla zona genitale ed ischiatica grazie ad una migliore distribuzione
del peso sulla sella.
77
7.4
L’ESPANSIONE DEL MERCATO
La continua evoluzione del mercato e le sempre più specifiche ed esigenti richieste
provenienti dai consumatori hanno spinto, a partire dalla seconda metà degli anni
’90 e, più decisamente, nella prima parte degli anni 2000, il management del Gruppo
a focalizzare le proprie strategie di sviluppo nell’individuazione e nello sviluppo di
nuovi prodotti innovativi che potessero soddisfare non solo i bisogni delle diverse
aree e segmenti di mercato che sempre più avevano cominciato a delinearsi, ma che
tenessero anche in considerazione i bisogni diversi di uomini e donne - l’importanza
dell’ergonomia della sella - assicurandosi che chiunque potesse andare in bici in
totale comfort. L’obiettivo di Selle Royal è quindi quello di permettere a chiunque di
scegliere la sella più adatta alla propria tipologia di uso della bicicletta.
Ed è proprio per riuscire a raggiungere tale obiettivo, e rispondere quindi alle
molteplici e diversificate esigenze dei propri clienti, che Selle Royal decide di
promuovere la nascita di cinque linee di selle che si rivolgono alla fascia di mercato
denominata “recreational” e che sposano un nuovo concetto di comfort nell’andare
in bicicletta.
Lookin: una linea che combina un design accattivante e la funzionalità e
comodità di una sella appositamente progettata per chi usa la bicicletta per
piacere. La sua caratteristica distintiva è la presenza di finestre centrali che
permettono di vedere il Royalgel™, tecnologia principale di questa sella;
Respiro: si tratta di una sella, per alcuni modelli handmade, molto innovativa,
che grazie alla presenza di un canale di ventilazione e ad uno speciale
materiale per la copertina, riduce il calore sulla sella, evitando dunque una
cattiva traspirazione;
Becoz: è la linea eco-friendly di Selle Royal. La principale tecnologia utilizzata si
chiama Corkgel, una combinazione innovativa di gel poliuretanico 20% bio con
sughero naturale, che dona un aspetto unico e naturale alla sella;
Premium: linea di selle 100% sigillate utilizzando la tecnologia Royal Vacuum
Light e il Royalgel™, che permettono un alleggerimento della sella e la
riduzione della pressione sulla zona ischiatica;
78
Classic: la linea confortevole di selle iconiche realizzate prevalentemente con
il Royalgel™.
Nel 1996 viene creato il marchio fi’zi:k tramite il quale il Gruppo, in pochi anni,
aggredisce e conquista una posizione leader nel settore “racing” e nei confronti del
consumatore “enthusiast” con un posizionamento di mercato elevato.
Così operando, negli anni 2000, Selle Royal diventa il primo produttore mondiale di
selle per biciclette sia nei settori “recreational”, in cui opera prevalentemente con il
marchio Selle Royal, sia nel settore “racing”, grazie alla presenza del nuovo marchio
fi’zi:k. Il successo riscontrato sul mercato permette al management del Gruppo di
adottare nuove scelte imprenditoriali che, in continuità con la scelta di operare per
“Brand”, consentano di estendere la gamma dei prodotti esistenti e di avviare un
concreto processo di internazionalizzazione.
7.5
BRAND DIVERSIFICATION
I primi anni 2000 segnano l’inizio di una nuova era per il Gruppo Selle Royal, che
apre una vera e propria fase di acquisizioni sul mercato internazionale. L’obiettivo
primario di questa terza fase della storia del gruppo è principalmente quello di
ampliare e supportare l’espansione geografica dell’azienda verso segmenti di
mercato-prodotto diversi da quelli già occupati, attraverso l’acquisizione o la
costituzione di accordi di joint venture con i principali brand che già vantavano un
posizionamento di tutto rispetto nel mercato in cui operavano. Nel 2002, Selle Royal
acquista Brooks England (UK), il più antico e rinomato marchio al mondo nel mercato
delle selle da bicicletta. Brooks England, operante nel segmento di mercato
denominato “lifestyle”, è sicuramente noto per la sua storica tradizione nella
produzione di selle di cuoio tradizionali, ma anche per la realizzazione di ulteriori
accessori quali borse per bicicletta e borse tradizionali in stile vintage, sempre
caratterizzate dallo stile e dalla qualità che da più di cent’anni contraddistinguono
questo storico brand.
Quattro anni più tardi, nel 2006, per favorire ed incrementare la crescita delle vendite
sul mercato statunitense, che presentava notevoli tassi potenziali di crescita, Selle
79
Royal costituisce Highway 2 (USA), una joint venture con la società Continental Tire
North America (attiva prevalentemente nel settore dei copertoni da bicicletta) per la
distribuzione diretta dei propri prodotti sul mercato statunitense.
Nel 2008, Selle Royal acquista Crank Brothers (USA), società statunitense leader
mondiale nel design di componenti e accessori d’alta gamma per mountain bike.
Inizialmente dedicata alla produzione di soli pedali, Crank Brothers ha poi ampliato in
modo esponenziale la sua offerta di prodotti, arrivando ad offrire sul mercato
meravigliose ruote e manubri, e concentrando tutte le sue forze sul mondo della
mountain bike, da cui ha fin da subito ottenuto risposte sempre molto positive da
parte del pubblico di appassionati che, in particolar modo negli ultimi anni aumenta
sempre di più, grazie soprattutto alla qualità dei prodotti proposti e alla miriade di
piccole innovazioni che costantemente inserisce nei propri prodotti.
Infine nel 2010, Selle Royal procede, per il tramite della società controllata Selle Royal
Asia, all’acquisizione di una partecipazione di maggioranza nel capitale del Gruppo
Justek (CINA), leader nella produzione di selle per il mercato cinese OEM (primo
equipaggiamento) nel segmento “recreational”. Questa joint venture permette a Selle
Royal di aumentare significativamente le sue quote di mercato in ambito
internazionale, e garantisce all’azienda un migliore accesso e servizio nel mercato
ciclistico del Far East, che rappresenta appunto una grande fetta del mercato globale
di biciclette. Inoltre con questa mossa Selle Royal ha voluto promuovere e offrire a
tutti i consumatori asiatici la stessa varietà di prodotti high-quality, lo stesso servizio
e lo stesso sviluppo che Selle Royal era in grado di offrire in Europa, in Brasile e negli
Stati Uniti; con questa acquisizione Selle Royal arriva oggi ad avere cinque plants
produttivi situati nelle principali posizioni strategiche: uno in Italia, uno negli UK
per rifornire il mercato Europeo, uno in Brasile per fornire servizi ai mercati Sud
Americani e due stabilimenti in Cina, a Jiangyin e a Tianjin, che assicurano la
copertura dell’intero mercato asiatico.
Così operando il Gruppo Selle Royal ha raggiunto e oramai sfatato l’obiettivo dei
trenta milioni di selle da bicicletta prodotte ogni anno, che corrisponde al 25% del
mercato mondiale, con un organico medio che conta ad oggi circa 1200 persone,
contro le precedenti 700. La Cina aggiungerà circa una quindicina di milioni di selle
80
l'anno ai 7 milioni che Selle Royal produce in Italia ed agli 8 che escono dalla fabbrica
in Brasile, senza contare la nicchia delle 300mila selle l'anno, tutte rigorosamente in
cuoio e lavorate a mano, che vengono realizzate in Inghilterra con il marchio Brooks.
In figura 7.2 viene rappresentata la struttura del Gruppo alla data del 30 Giugno
2013, con l’indicazione delle percentuali di partecipazione. Tale struttura risulta
modificata rispetto alla sua composizione al 30 Giugno 2012.
Figura 7.2: Composizione societaria del Gruppo Selle Royal (Fonte: “Materiale interno aziendale”)
In figura 7.3 invece è rappresentato l’organigramma dell’intero Gruppo Selle Royal
S.p.A. Questo organigramma è suddiviso sulla base delle diverse società che, come si
è visto sopra, compongono il Gruppo. Per ciascuna di esse si ha una struttura
ordinata per funzioni, ossia la classica forma organizzativa in cui vengono
raggruppate insieme tutte le persone che condividono discipline, skills e processi
lavorativi simili. Come accade tipicamente per le strutture funzionali si può notare la
presenza di alcune aree aziendali principali: amministrazione/finanza, acquisti, area
qualità, ufficio tecnico, operations ed infine l’area commerciale. Come si può
osservare dalla figura, tutta l’area commerciale, che comprende al suo interno anche
l’ufficio marketing e comunicazione, a differenza delle altre funzioni aziendali prima
81
elencate, è suddivisa in due Business Unit separate: una prettamente dedicata a
Fi’zi:k e l’altra dedicata invece a Selle Royal. Da notare infine come l’Area Sales
Manager Aftermarket e Private Label si trovino all’interno di queste Business Unit, a
differenza dell’OEM Sales Manager, che compone insieme all’OEM Junior Sales
Manager la Business Unit dedicata al singolo canale di vendita dell’Original
Equipment Manufacturer.
Questo tipo di struttura è tipicamente adottata da quelle organizzazioni che hanno
un core business predominante, e permette di ottenere due vantaggi principali, come
la possibilità di sviluppare un elevato grado di specializzazione e conoscenza
all’interno di ciascuna funzione, nonché la relativa facilità nel trasferire le risorse tra
attività diverse appartenenti alla medesima funzione.
82
Figura 7.3.b: Organigramma di Brooks
England (Fonte: “Materiale interno
aziendale”)
Figura 7.3.c: Organigramma di Crank
Brothers (Fonte: “Materiale interno
aziendale”)
Figura 7.3.a: Organigramma di Selle Royal
S.p.A (Fonte: “Materiale interno
aziendale”)
Figura 7.3.d: Organigramma di
Justek (Fonte: “Materiale interno
aziendale”)
83
84
8 ANALISI DELLA SITUAZIONE
AS IS NELLA GESTIONE DEI
PROGETTI DI SVILUPPO NUOVO
PRODOTTO
L’obiettivo di questo capitolo è quello di andare a comprendere qual era la
situazione, prima che venisse introdotto il nuovo PMIS (AS IS), nella gestione dei
progetti di sviluppo nuovo prodotto all’interno dello stabilimento italiano di
Pozzoleone, focalizzando l’attenzione sulle modalità con cui i progetti venivano
sviluppati, nonché sui ruoli e i principali compiti che gli enti interessati avevano
all’interno del progetto.
Prima di passare all’analisi vera e propria riguardante il flusso di gestione dello
sviluppo di una nuova sella, segue una breve introduzione al contesto in cui questi
progetti vengono eseguiti, esaminando la struttura organizzativa dell’azienda, le
tipologie di nuovi prodotti e i principali canali utilizzati da Selle Royal per la vendita
dei propri articoli.
85
8.1 STRUTTURA ORGANIZZATIVA PER LA GESTIONE DEI PROGETTI
La struttura organizzativa che si occupa delle gestione dei progetti di sviluppo
nuovo prodotto si concentra principalmente sul ruolo centrale del Dipartimento
Tecnico, anche se, essendo un progetto end-to-end, che parte dall’idea iniziale di
prodotto e termina con la mass production, interessa in maniera trasversale tutte le
aree aziendali: Sales, Marketing, Acquisti, Ufficio Tecnico, Operations, Qualità,
Controllo di Gestione, a cui vengono affiancate delle figure di staff dedicate full time
alla gestione dell’intero portfolio di progetti sviluppati in Italia, come il Product
Manager e il Project Controller. Trattandosi di sviluppo nuovo prodotto, come detto
sopra, la principale funzione organizzativa coinvolta all’interno del processo è quella
dell’ufficio tecnico, affiancato dal Product Manager, che come si vedrà ha un ruolo
chiave all’interno dell’azienda.
Perciò, per comprendere la struttura dedicata alla gestione di tali progetti, si propone
in questo paragrafo un approfondimento sulle principali figure coinvolte.
Dipartimento Tecnico: in un’ottica di sviluppo del prodotto finito, l’area tecnica
svolge il compito fondamentale di verificare e valutare, dopo un’attenta analisi, la
fattibilità tecnica e tecnologica, nonché gli investimenti e le previsioni di costo dei
prodotti da realizzare, definendo, in team con la Qualità, gli Acquisti e la
Produzione, gli obiettivi e le risorse necessarie a completare con successo il
progetto. All’interno di quest’area si trova inoltre una figura il cui compito è
quello di pianificare le attività di sviluppo (in realtà, come verrà analizzato più
avanti, per mancanza di strumenti non è mai riuscita ad eseguire una vera e
propria pianificazione) e di gestire la corretta attribuzione dei costi e degli
investimenti, così da controllare lo stato di avanzamento del progetto, i suoi
scostamenti e le azioni correttive da mettere in atto per rispettare le deadline
imposte. Senza entrare nel merito delle numerose persone che lavorano alla
progettazione del prodotto e alla sua industrializzazione, all’interno dell’ufficio
tecnico, si possono identificare due figure chiave nella gestione del progetto:
86
Product Developer: grazie alle specifiche competenze maturate, lavora in
stretta collaborazione con il Product Manager per la definizione dei contenuti
di prodotto e delle gamme, finalizzati all’amplificazione dei valori che
caratterizzano il brand. Il Product Developer ha la responsabilità di coordinare
la definizione delle proposte grafiche e le finiture dei prodotti relazionandosi,
per l’approvazione, con lo Stile e con il Product Manager. Inoltre, dal
momento che una buona parte delle attività di sviluppo del prodotto sono
date in outsourcing, collabora con l’Ufficio Acquisti e con il Controllo Qualità
nella scelta ed assegnazione dei fornitori di riferimento per il raggiungimento
dei target definiti;
Program Manager: si tratta di una funzione di staff che collabora nella gestione
delle attività dell’area tecnica. Questa figura ha innanzitutto la responsabilità
di curare l’integrazione logistica, per garantire la disponibilità dei materiali e
di supportare la definizione della distinta tecnica del nuovo prodotto; da
questo punto di vista quella del Program Manager è dunque una funzione di
supporto al Project Leader, che altrimenti si appesantirebbe di una serie di
attività non a valore aggiunto, che finirebbero per rallentare l’avanzamento
del progetto stesso. Un secondo compito del Program Manager consiste nella
simulazione del costo del prodotto finito, effettuata a partire da componenti
con caratteristiche tecniche analoghe a quelli che costituiscono il prodotto che
si sta andando a sviluppare. Il terzo ed ultimo incarico in capo al Program
Manager doveva essere la pianificazione ed il controllo dei progetti, attività
che però, prima dell’acquisto di AtTask, non è mai stata svolta sia per
mancanza di strumenti, sia per l’inconsistenza della cultura aziendale sui temi
del Project Management.
Area Qualità: quest’area ha il compito primario di verificare la conformità
strutturale e chimica dei prodotti sulla base dei requisiti di legge e di
omologazione, che vengono definiti in relazione alle normative internazionali e
agli obiettivi di prodotto che si vogliono soddisfare. Il quality inspector, in
particolare, si pone nei rapporti con i fornitori esterni come presidio della qualità e
87
dei processi durante lo sviluppo del prodotto, per garantire il raggiungimento e il
mantenimento degli standard di omologazione che vengono definiti dal quality
manager, che ha appunto il compito di assicurare la corretta definizione dei criteri
per l’omologazione di fornitori, materiali e prodotti.
Product Manager: questa figura all’interno dell’azienda ha il compito di
analizzare il posizionamento del brand all’interno del mercato, e capire dove il
brand che egli rappresenta deve essere follower e dove invece essere leader.
Durante questo studio il Product Manager individua tutti i principali competitor
che operano nello stesso segmento di mercato e gli eventuali “buchi” da andare ad
aggredire. Per riuscire a prendere delle decisioni corrette, in merito al tipo e alla
variabilità di prodotto da immettere nel mercato e al canale di vendita in cui
vendere il prodotto (da notare che comunque un prodotto può essere venduto
anche su più di un canale), sono necessarie considerevoli competenze tecnicocommerciali. Deve infatti essere un tecnico per riuscire a spiegare, con un
linguaggio specifico e puntuale, quali sono i requisiti che vuole soddisfare, ma
anche un commerciale per riuscire a vedere tutte le opportunità di mercato,
impostando una strategia a medio-lungo termine che permetta di far crescere il
fatturato dell’azienda.
Project Controller: il Project Controller verifica l’avanzamento dei progetti in
relazione al planning, agli investimenti ed ai costi, pianificando gli incontri di
design review gestionali di tutti i progetti appartenenti al portfolio di Selle Royal:
si tratta quindi di quello che in letteratura è stato chiamato Project Portfolio
Manager. Essa ha inoltre la responsabilità di chiudere la distinta base definitiva
per assicurare il benestare da dare alla produzione.
All’interno dell’organizzazione è dunque possibile identificare la presenza di una
sorta di Project Management Office, composto in modo pressoché esclusivo dal
Program Manager, che si occupa, in maniera abbastanza destrutturata, di elaborare la
documentazione ed in alcuni rari casi di pianificare i progetti con l’aiuto di
“Microsoft Project”. In aggiunta al Program Manager, come visto sopra, vi è il Project
Controller che, oltre ad occuparsi di controllare i costi del progetto, e a seguire alcune
88
fasi importanti legate all’anagrafica, ha anche il compito di controllare l’avanzamento
dei progetti appartenenti al portfolio, assicurando il rispetto delle richieste
provenienti dal Product Manager. Si osserva dunque come al giorno d’oggi sia totale
l’assenza di un Project Manager che pianifichi con regolarità i numerosi progetti che
vengono sviluppati e ne monitori ripetutamente l’avanzamento, prendendosi la
responsabilità degli eventuali ritardi intervenuti nel corso del progetto, e che abbia la
leadership di annullare un progetto per garantire una maggiore concentrazione di
risorse in progetti più redditizi per l’azienda.
8.2 IL CONTESTO DEI PROGETTI DI SVILUPPO NUOVO PRODOTTO
8.2.1 Classificazione dei progetti in Selle Royal S.p.A
Nel precedente paragrafo è stata descritta la struttura organizzativa che si occupa
della gestione dei molteplici progetti sviluppati in Selle Royal; qui invece si
approfondiscono i criteri di classificazione adottati, descrivendo, per ciascuna delle
tipologie individuate, le principali differenze in termini di esecuzione. Per classificare
i progetti di sviluppo nuovo prodotto che vengono eseguiti in Selle Royal è stata
adottata una categorizzazione basata principalmente sul grado di difficoltà che
ciascuno di essi richiede nelle attività di progettazione e industrializzazione del
nuovo articolo. Sulla base di questi criteri di complessità si individuano tre categorie
principali, al cui interno vengono raggruppati tutti i modelli sviluppati, che fanno
riferimento non solo al mondo della sella, che ovviamente rappresenta il core business
dell’azienda, ma anche a tutto il mondo degli accessori per la bicicletta, che
comprende articoli come le manopole, le borsette da bicicletta e le lucette di
illuminazione, ossia i cosiddetti commercializzati. Le classi di prodotto a cui ci si
riferisce sono state così definite:
PNP: si tratta di un acronimo che identifica la “proposta di un nuovo
prodotto” per cui si rende necessaria l’apertura di un nuovo progetto, che
richiederà uno studio di fattibilità di quanto richiesto nel documento ufficiale
che descrive il concept di prodotto (documento chiamato brief) e delle
89
conseguenti attività di progettazione e creazione degli stampi ad iniezione
(per il feltro o per le protezioni che compongono la parte strutturale della
sella) e di schiumatura, necessario per ottenere un semilavorato derivante
dall’unione di un feltro con la copertina. Questa macro categoria viene
ulteriormente scomposta in quattro ulteriori classi di prodotto a seconda del
fatto che quanto richiesto preveda solamente un nuovo shape della parte
superiore della schiumatura, oppure la presenza o meno del gel, che implica a
sua volta un cambiamento di tecnologia per la realizzazione dello schiumato:
PNP 1: nel caso di una PNP 1 la sella da sviluppare necessita dello
sviluppo e della creazione di un nuovo stampo di iniezione che dà vita
ad un nuovo feltro plastico, il quale deve essere sottoposto a delle
prove di laboratorio per verificare la sua conformità alle normative
vigenti;
PNP 2: in presenza di una proposta nuovo prodotto di questo secondo
tipo ci si trova di fronte all’esigenza di progettare esclusivamente un
nuovo stampo di schiumatura, in quanto la richiesta prevede il
semplice cambiamento della forma dello schiumato. Questa PNP non
necessita dunque di un nuovo stampo di iniezione poiché, per quanto
riguarda la parte strutturale della sella, si sfruttano feltro e forchetta
esistenti;
PNP 3: una tipica caratteristica delle selle prodotte da Selle Royal S.p.a è
la presenza addizionale del Royalgel (materiale brevettato da Bayer
Material Science in Germania, e che Selle Royal per prima ha utilizzato
per la produzione di selle), che si va ad aggiungere tra il liquido
poliuretanico e la copertina della sella, assicurando una superiore
sensazione di comfort per il ciclista. Tipicamente si apre una PNP 3
ogniqualvolta si voglia aggiungere al liquido poliuretanico il Royalgel,
il che non implica la necessità di creare un nuovo stampo di
schiumatura, ma ne richiede comunque un collaudo per verificare il
suo corretto funzionamento;
90
PNP 4: con questo acronimo si fa invece riferimento ai progetti che
vengono avviati per sviluppare nuovi accessori che, come ricordato
prima, potrebbero essere manopole, borsette, lucette ed altri tipi di
complemento,
e
che
sono
tradizionalmente
conosciuti
come
commercializzati.
A tal proposito un’importante decisione che è stata presa riguarda il fatto di
realizzare, ogni volta che viene richiesto lo sviluppo di un nuovo prodotto, una
versione base, con le caratteristiche più neutre ed economiche possibili – come ad
esempio l’utilizzo di una semplice copertina nera, della forchetta in acciaio e delle
plastiche nere per il feltro e le protezioni – in modo da minimizzare i costi legati a tali
attività nella fase iniziale di sviluppo del prodotto. In questo modo si ottiene la
versione 00 del nuovo modello, che può poi essere personalizzata con nuove grafiche
in modo da ottenere l’ampia varietà di versioni richieste. Da notare inoltre che nella
maggior parte dei casi questa versione base non viene nemmeno messa in
produzione, proprio perché la sua ragione d’esistere è strettamente legata alla
necessità di minimizzare i costi e i tempi di gestione del processo di sviluppo del
prodotto che è stato richiesto.
PROGETTO (CORRELAZIONE DIFFICILE): questa seconda classe di
progetti fa invece riferimento al caso in cui il Product Manager, il Business
Unit Manager o addirittura il cliente stesso emetta una particolare richiesta di
personalizzazione di un modello esistente, in termini di grafica da progettare
sulla copertina della sella e/o di un nuovo materiale con cui realizzare la
copertina, che comporta di conseguenza una modifica della distinta base,
nonché una serie di attività con fornitori esterni e/o interni con relativi costi di
realizzazione e benestare estetico o di packaging.
CORRELAZIONE SEMPLICE: l’ultima categoria di progetti che si può avere
prende il nome di “correlazione”. Si tratta della situazione in cui, a seguito
della richiesta di un singolo cliente, è necessario modificare una distinta base
esistente, aggiungendo o togliendo componenti già codificati e/o da
codificare,
per
cui,
al
contrario
del
caso
precedente,
si
possono
91
immediatamente consegnare dei campioni dimostrativi al cliente che lo
richiede, senza la necessità né del benestare strutturale né del benestare
chimico.
Queste due ultime categorie sono state introdotte principalmente per gestire le
personalizzazioni di prodotto che potrebbero essere richieste e che portano a creare
un codice prodotto finito univoco, relativo ad una nuova versione di un modello
precedentemente sviluppato.
Secondo alcuni dati che sono stati raccolti, ogni anno in Italia vengono sviluppate in
media circa 90 nuovi prodotti tra PNP 1, PNP 2 e PNP 4, contro i 70 sviluppati nello
stabilimento cinese di Jiangyin, oltre ad un numero elevatissimo di correlazioni, che
sfiora ad oggi le 2000 versioni all’anno. Come verrà esaminato più avanti nel corso
dell’elaborato, proprio questi grandi volumi di PNP, che ogni anno vengono ideate,
sono una delle cause principali dei continui ritardi della loro messa in produzione,
con il risultato che ci si trova molto spesso a dover spostare il prodotto alla gamma
successiva, perdendo la possibilità di generare un incremento di fatturato.
8.2.2 Distribuzione commerciale: i canali di vendita
Con il termine distribuzione commerciale ci si riferisce allo strumento attraverso il
quale le aziende produttrici e distributrici immettono sul mercato i propri beni e
servizi per renderli disponibili e usufruibili dal consumatore per l’uso. Il canale di
distribuzione invece, è il percorso che il bene segue nel suo trasferimento dal
produttore al consumatore finale, ed è costituito da una serie di stadi, in ciascuno dei
quali avviene un passaggio del titolo di proprietà. Il canale di distribuzione di un
prodotto termina in corrispondenza dell’ultima persona o dell’ultima azienda che lo
acquista senza apportarne alcuna modifica significativa. Nel momento in cui
vengono effettuate delle modifiche sul bene in questione, fino a trasformarlo in un
nuovo prodotto, da quel punto inizia un nuovo canale di distribuzione.
Il Gruppo Selle Royal S.p.A, proprietario di numerosi brand, tra cui ricordiamo in
particolare Fizik, Brooks e Selle Royal, per la distribuzione dei suoi prodotti
92
usufruisce di quattro principali canali di vendita indiretti, che gli permettono una
presenza a livello internazionale nei segmenti Recreational, Racing, Lifestyle e MTB.
Ovviamente a seconda del canale cui il prodotto è destinato si valutano, in fase di
progettazione, i materiali da utilizzare e il livello di qualità da soddisfare per la
specifica situazione; in particolar modo queste scelte sono di fondamentale
importanza a seconda che la sella sia destinata all’AM/OEM piuttosto che al Mass
Market, in quanto i relativi prezzi di vendita sono alquanto diversi, così come, lo
sono di conseguenza anche i target cost da rispettare.
Questi canali di vendita possono essere così brevemente descritti:
OEM
è
l’acronimo
dell’espressione
inglese
“Original
Equipment
Manufacturer”, letteralmente “produttore di apparecchiature originali”: le
selle e gli accessori che vengono venduti tramite questo primo canale di
distribuzione fanno riferimento a tutti i prodotti che vengono montati
direttamente dalla casa produttrice come componenti di una bicicletta finita.
Questo canale riflette dunque il caso in cui i prodotti con brand Selle Royal,
piuttosto che Fizik o Brooks, vengono incorporati come componenti di un
prodotto che viene realizzato da un’altra azienda e venduto con il nome del
brand di quest’ultima. Da osservare che qualsiasi articolo destinato all’OEM
potrà avere stampato il logo SR sul feltro e sulla copertina, ma, al contrario
dell’After Market, non richiederà alcun tipo di packaging, se non un semplice
contenitore in nylon, proprio perché invece di essere esposto in un negozio
viene montato direttamente sulla bicicletta.
L’After Market (AM) è il secondo grande canale di vendita attraverso cui
vengono venduti gli articoli sviluppati dal gruppo. Esso si distingue
dall’OEM in quanto i prodotti distribuiti tramite quest’altro mezzo vengono
tipicamente acquistati stand alone, per essere poi montati in un secondo
momento sulla bici. A differenza del caso precedente i destinatari della merce
non saranno più i produttori di biciclette, bensì i dealer, che esporranno
l’intera gamma di prodotti proposta su degli appositi pannelli espositivi.
Inoltre, come accadeva anche per l’OEM, su ciascun finished product si porrà in
93
evidenza il logo del brand di proprietà cui la sella o l’accessorio appartiene,
ma contrariamente a quanto definito per l’OEM, sarà necessario progettare
per ciascun articolo un opportuno packaging branded SR, che verrà appunto
utilizzato per esporre l’intera gamma nei led posizionati nei negozi dei clienti.
Private Label (PL): sotto la divisione After Market si trova il terzo canale di
distribuzione, conosciuto come Private Label, espressione usata per indicare i
prodotti o servizi solitamente realizzati o forniti da società terze (fornitore di
marca industriale o terzista vera e propria) e venduti con il marchio della
società che vende/offre il prodotto/servizio (distributore). Le Private
Label nascono con lo scopo di offrire al cliente consumatore un’alternativa
alla marca industriale, pur mantenendo lo stesso livello di qualità, ma con un
prezzo inferiore, data l’assenza del costo di marketing tipico dell’industria
di marca. Attualmente la Private Label è un uno degli asset fondamentali di
quasi ogni distributore moderno sia commercialmente, che per declinare le
proprie politiche di marketing.
Mass market: si tratta del quarto ed ultimo canale di cui si serve Selle Royal
per la distribuzione dei propri prodotti. Il Mass Market, come dice il termine
stesso, riguarda i prodotti che vengono venduti in volumi molto elevati e ad
un target molto ampio ed eterogeneo di consumatori. A causa dell’enorme
variabilità dei bisogni dei clienti che si servono tramite questo canale, risulta
difficile
raggiungere
ciascun
consumatore
finale,
perciò
risulterà
fondamentale suddividere il mercato in una serie di segmenti aventi le
medesime esigenze. Le caratteristiche che permettono di differenziare il mass
market dagli altri canali prima descritti sono l’ottimo rapporto qualità-prezzo
e l’elevata reperibilità dei prodotti che, nel caso specifico di Selle Royal,
potranno essere trovati in numerosi supermarket con brand SR e, così come
per l’AM, con un packaging dedicato che ne riporta il nome del brand.
94
Figura 8.1: Rappresentazione dei canali di distribuzione in Selle Royal S.p.A (Fonte: “Documento
interno aziendale”)
8.3 IL PROCESSO DI SVILUPPO NUOVO PRODOTTO: ANALISI AS IS
Adesso che è chiaro il contesto in cui si inseriscono i progetti di sviluppo nuovo
prodotto, è possibile analizzare le modalità di gestione adottate da Selle Royal prima
che iniziasse il percorso di riorganizzazione aziendale, che verrà approfondito nel
prossimo capitolo. Il processo di sviluppo su cui si focalizzerà l’attenzione durante il
corso dell’intero elaborato fa riferimento ai soli progetti relativi alla nascita di selle
con brand Selle Royal o Private Label. Dalla trattazione verrà quindi esclusa la
categoria dei commercializzati, a cui appartengono prodotti come le lucette e le
borsette che vengono tipicamente collegate alla sella attraverso un apposito sistema
di fissaggio chiamato Integrated Clip System (ICS), che vengono realizzate in
outsourcing. Questa scelta risiede nel fatto che per la categoria dei commercializzati,
come già precisato, non vi è pressoché alcuna attività interna, perciò risulta
maggiormente utile ai fini della tesi, concentrare l’attenzione sul core business
dell’azienda, che presenta al suo interno delle complicate logiche di gestione.
Come accennato nella parte introduttiva di questo lavoro, con il passare del tempo
sta aumentando sempre di più il numero di nuovi prodotti il cui modello di stile e la
95
cui progettazione vengono seguiti qua in Italia, per essere poi industrializzati e
direttamente commercializzati nel mercato del Far East.
Nonostante questa tendenza, nel prossimo paragrafo, seguirà un’analisi dettagliata
di come venivano gestiti i progetti interamente sviluppati in Italia prima
dell’introduzione di AtTask, per poi fare una breve digressione su come veniva
gestito lo sviluppo di un prodotto, sempre con brand Selle Royal o Private Label
indistintamente, che prevede l’esecuzione della maggior parte delle attività richieste
nello stabilimento presente in Cina, appartenente sempre al gruppo Selle Royal
S.p.A.
8.3.1
Analisi critica delle modalità AS IS di gestione delle Proposte Nuovo
Prodotto
Lo sviluppo di un nuovo prodotto in Selle Royal viene considerato come un progetto
a sé stante, con un obiettivo preciso ed unico, essendo diverso da qualsiasi altro
processo di sviluppo; esso rispecchia dunque tutte le caratteristiche che definiscono
correttamente un progetto: unicità e irripetibilità in termini di tempi, costi, risorse,
vincoli da rispettare e qualità che si vuole raggiungere. Proprio per queste
caratteristiche intrinseche il processo in questione merita una gestione dedicata in
termini di coordinamento del progetto.
La fase che precede l’apertura vera e propria del progetto riguarda lo studio del
mercato in cui il nuovo prodotto va ad inserirsi, nonché una definizione preliminare
delle caratteristiche estetico-funzionali che deve soddisfare per riuscire a raggiungere
gli obiettivi che l’azienda si è prefissata. Per quanto concerne il primo punto il
Product Manager (PM), in collaborazione con il Business Unit Manager (BUM),
analizza il mercato di riferimento in termini di volumi di vendita, prezzi medi e
principali players, effettuando un’analisi comparativa dei prodotti presenti nel
mercato, che permetta di raccogliere tutte le informazioni necessarie per posizionare
il prodotto nel segmento corretto. Per riuscire a proporre un articolo di successo è
fondamentale per il PM riuscire a incrociare la visione del mercato con quelli che
sono i valori che caratterizzano il brand (brand identity), con l’obiettivo non solo di
96
soddisfare i propri clienti, ma di sorprenderli con innovazioni che permettano di
incrementare la redditività del gruppo e di presidiare specifiche quote di mercato,
sulla base di quanto definito nella strategia aziendale. Ovviamente, per raggiungere
questo traguardo, ci deve essere uno scambio reciproco di competenze tra il Product
Developer e il Product Manager. Il primo, in particolare, ha il compito di condividere
tutte le informazioni riguardanti nuove tecnologie e/o nuovi processi, che vengono
poi sfruttate dal Product Manager per proporre un prodotto che contenga al suo
interno i nuovi concetti studiati. Questo primo step rappresenta dunque la fase di
raccolta delle idee innovative, che possono scaturire da persone appartenenti ad aree
diverse e con diverse modalità di azione. Una volta completata questa fase iniziale di
analisi del prodotto e del mercato, si tratta di andare a formalizzare nel “brief” tutte
le decisioni che sono state prese a seguito dell’analisi. Il brief è infatti il documento
ufficiale in cui vengono riportate tutte le variabili necessarie per poter procedere con
lo sviluppo di quanto richiesto. Al suo interno vengono dunque razionalizzate tutte
le informazioni di mercato, di estetica e di prodotto, nonché una descrizione del
posizionamento nel mercato e dei bisogni del cliente che il prodotto si propone di
soddisfare, specificando in particolar modo gli obiettivi di tempo, il target di costo
(target cost) e il target di prezzo (target price) a cui lo si vuole vendere, aspetti
fondamentali per riuscire a valutarne la fattibilità secondo le specifiche richieste.
Nonostante nel corso degli anni siano già stati compiuti dei passi in avanti – fino a
qualche anno fa l’idea di sviluppare un nuovo articolo non era nemmeno
accompagnata da un documento ufficiale, ma il contenuto veniva definito mano a
mano che il progetto avanzava – tutt’oggi si riscontrano delle mancanze che portano
ad una gestione inefficace del progetto. Ad esempio la tendenza a tralasciare, perché
sottovalutate, alcune informazioni fondamentali che permetterebbero all’ufficio
tecnico di valutare in maniera precisa come procedere allo sviluppo del prodotto e
quali strategie adottare per minimizzarne tempistiche e costi associati. Compilare il
brief infatti non serve solo a formalizzare i desiderata che si vogliono raggiungere, ma
anche a capire il motivo per cui si fanno determinate richieste, ed evitare dunque che
con il passare del tempo esse subiscano delle eccessive modifiche che
stravolgerebbero il progetto. Proprio la mancanza di informazioni e i continui
97
ripensamenti in corso d’opera sono due dei grandi problemi riscontrati all’interno di
Selle Royal: non si è infatti consapevoli che ogni cambiamento può comportare, oltre
alla necessità di ripetere nuovamente alcune attività, con conseguente allungamento
dei tempi di rilascio del prodotto definitivo e il rischio di non riuscire più a rispettare
le deadline imposte, anche ad un innalzamento delle spese sostenute per sviluppare il
prodotto, come si può vedere in figura 8.2 che riporta i cost of changes secondo
Ambler (2004).
Figura 8.2: Cost of changes (Fonte: Scott W. Ambler, The Object Primer: Agile Model-Driven
Development with UML 2.0)
A questo punto, nonostante l’incompletezza del brief consegnato dal Product
Manager, il Project Controller apre la PNP proposta all’interno del Lotus Notes, il
sistema informativo utilizzato per gestire l’intero portfolio prima dell’introduzione di
AtTask, ufficializzando attraverso l’invio di una e-mail l’inizio del progetto di
sviluppo del nuovo prodotto. Alla sua apertura in Lotus il Project Controller ha
inoltre il compito di classificare fin da subito, senza aver visto un modello di stile e
sulla sola base delle indicazioni che gli erano state fornite, di che tipo di PNP si tratta.
Ovviamente questo modo di procedere è molto rischioso, in quanto a seconda del
98
tipo di PNP le tempistiche di sviluppo e gli investimenti associati sono notevolmente
diversi, quindi classificandoli in modo approssimativo si possono creare delle
illusioni che poi, in un secondo momento, ci si accorge di non poter mantenere e
dover dunque attendere la gamma successiva per il lancio del nuovo prodotto, con
conseguente perdita di fatturato.
L’apertura del progetto, ottenuta a seguito dell’ufficializzazione e dell’approvazione
del brief da parte dei vari “attori” del brand e del Product Manager, in cui viene
esposta l’idea di prodotto, consente ai designer di sviluppare il modello di stile, a
partire dal quale vengono fatte considerazioni estetiche sul prodotto che si desidera
ottenere. Solamente una volta che il modello viene approvato esteticamente il
Product Developer può dare l’avvio allo studio di fattibilità.
L’ufficio tecnico con l’analisi di fattibilità ha il compito di individuare soluzioni
tecniche e tecnologiche che favoriscano lo sviluppo delle idee e di valutare il
raggiungimento delle performance, stabilendo, in collaborazione con la Qualità, le
criticità, i criteri di omologazione ed i fattori innovativi. L’analisi di fattibilità può
essere scomposta in tre sottofasi principali, che portano alla validazione del progetto
e quindi alla decisione di procedere nei tempi e nei costi definiti:
1. Verifica e definizione della fattibilità tecnica e del processo: in questa fase il
Product Developer definisce le tecnologie delle singole parti e le potenziali
criticità che si potrebbero riscontrare, verificando la disponibilità off the shelf di
tecnologie e materiali per la realizzazione del nuovo prodotto. In questa prima
parte dello studio di fattibilità, a partire dalla scansione del modello di stile,
viene ipotizzata una prima progettazione del prodotto finito cui fa seguito la
realizzazione del prototipo STL. Quest’ultimo viene utilizzato, dal Product
Manager e dal Product Developer, per capire se quanto è effettivamente
realizzabile (in fase di progettazione possono essere apportate delle correzioni
che modificano leggermente la forma della sella) può essere accettato
confrontandolo con l’obiettivo cui si desidera tendere il più possibile,
rappresentato dal mock up. Come è stato detto poco sopra è molto rischioso
che nella fase di apertura del progetto, dopo aver visionato solamente il brief,
99
il Project Controller si prenda immediatamente la responsabilità di classificare
il progetto. Risulta perciò evidente come un progetto possa essere
correttamente classificato solamente a valle di questa prima parte dello studio
di fattibilità, al termine del quale si dispone di un’analisi puntuale del
prodotto richiesto, sufficiente per evidenziare eventuali criticità e/o fattori di
innovazione che potrebbero richiedere delle attività di ricerca impensabili in
fase di apertura del progetto, o comunque la necessità di svolgere delle attività
che non si pensava di dover eseguire al momento della presentazione del
brief.
2. Investment Analysis e Cost Analysis: in questa fase il Product Developer
effettua una prima ipotesi dei tempi e dei costi di sviluppo dell’intero
progetto. Il concept di prodotto viene dunque completato con le valutazioni di
investimenti, spese e consulenze, con il contributo delle varie funzioni
aziendali: la Produzione che viene coinvolta nella definizione delle tecnologie
di processo (MAKE), gli Acquisti per la determinazione dei costi di acquisto
dei materiali nel caso di componenti/operazioni acquistate da fornitori esterni
(BUY) ed infine il Controllo di Gestione.
Durante lo studio di fattibilità l’ufficio tecnico si occupa di effettuare una
stima degli investimenti che il progetto in questione prevede, entrando in
alcuni casi anche nel dettaglio delle principali fasi in cui esso si articola (spese
previste per la progettazione, per la realizzazione degli stampi ad iniezione
del feltro, delle protezioni e degli inserti, così come per gli stampi di
schiumatura).
É
chiaro
che
per
poter
effettuare
una
previsione
sufficientemente puntuale di quanto si dovrà spendere per la realizzazione del
nuovo modello è fondamentale disporre di una definizione completa delle
specifiche richieste pervenute dal Product Manager. Solamente nel momento
in cui si dispone di informazioni chiare e precise, il Product Developer è in
grado di effettuare una progettazione preliminare del prodotto, da cui si
ricavano le informazioni fondamentali che permettono appunto di effettuare
la stima degli investimenti necessari. Tuttavia l’importanza dell’analisi degli
investimenti, in Selle Royal, è ancora un tema abbastanza sottovalutato, e il
100
risultato di questo studio al giorno d’oggi rimane semplicemente un numero
fine a se stesso, non venendo utilizzato per effettuare alcun tipo di
considerazione strategica. A partire dalla conoscenza di quanto risultato da
tale ricerca, e da altri dati che dovrebbero essere presentati nel brief – come le
previsioni di vendita, il target cost (C1) e il selling price - sarebbe opportuno a
questo punto calcolare il ROI (Return on Investment) di ciascun nuovo progetto,
in modo tale da definire un ordine di priorità ed eventualmente bloccare sul
nascere le iniziative che presentano un valore negativo. Come è stato detto
però questo tipo di approfondimento non è mai stato effettuato, con il rischio
di allocare risorse economiche e forza lavoro su progetti di secondaria
importanza, rallentando, e in alcuni casi anche bloccando, iniziative ben più
remunerative (problema che peraltro si riscontra abitualmente).
Comunque sia, nonostante l’importanza dell’analisi degli investimenti per il
calcolo del ROI, negli anni è stato osservato come un errore nella valutazione
di questo parametro non fosse così significativo per l’economicità del
progetto; ragion per cui non si è mai sentita l’esigenza di effettuare alcun tipo
di controllo puntuale di conformità rispetto al budget, limitandosi a
consuntivare, al termine del progetto, ciò che era stato previsto di spendere,
rispetto a quanto era stato effettivamente speso.
Ben più sentito è invece il tema del costo del prodotto, in quanto questo valore
presenta forti implicazioni sul posizionamento che il bene deve andare ad
occupare all’interno del mercato. Quest’analisi può essere effettuata solamente
una volta che è stata completata la progettazione preliminare della sella
eseguita durante lo studio di fattibilità. Al termine di questa attività infatti si
conoscono delle informazioni fondamentali (come i materiali da utilizzare, i
volumi del prodotto e la durata del ciclo), a partire dalle quali, per analogia
con componenti precedentemente utilizzati in selle esistenti, è possibile
stimare il costo del prodotto finito, e confrontarlo con il target cost riportato nel
brief.
È chiaro che man mano che si procede con lo sviluppo del prodotto i costi
sostenuti vengono monitorati, e, nel caso in cui questi eccedano il target cost, il
101
Prodcut Developer e il Product Manager si incontrano per definire eventuali
modifiche alle specifiche del prodotto (in termini di tecnologia, materiali ed
eventuali accessori) in modo da riuscire a trovare un compromesso per
rispettare il C1 richiesto.
3. Time Analysis: il quarto ed ultimo fattore che viene valutato durante lo studio
di fattibilità riguarda le tempistiche richieste per lo sviluppo del prodotto. Nel
corso degli anni il Program Manager, affiancato dal Product Developer, ha
elaborato dei fogli Excel in cui sono stati riportati i timing generici per lo
sviluppo di nuovi prodotti, individuando delle tempistiche specifiche per
ciascuna categoria di progetto, sia essa una PNP 1, una PNP 2 o un progetto
per lo sviluppo di una nuova grafica. L’obiettivo di questo calendario è quello
di condividere con l’intero team la durata standard del flusso di processo, in
modo tale da rendere evidente la scadenza entro cui il modello di stile (che
rappresenta un’attività critica) deve essere consegnato per rimanere in linea
con le tempistiche stimate.
Inoltre è stato creato un Gantt “standard” in cui sono state riportate le
macrofasi critiche in cui si articola il progetto. Questo strumento viene
utilizzato dal Product Developer per aver chiaro quali attività possono essere
eseguite in parallelo con altre, e per fornire al team un’indicazione delle date
entro cui le principali fasi devono terminare per non ritardare il progetto.
Nonostante l’utilità di tali informazioni, non si tratta però di una vera e
propria pianificazione dettagliata di tutte le attività che è necessario rispettare
per arrivare al prodotto finito, ma fornisce solo un’idea generale del flusso
standard da adottare, con le rispettive deadline, senza però chiarire l’eventuale
presenza di ritardi. Anche lo stesso Lotus Notes, come si può vedere in figura
8.3, presenta dei semplici pallini colorati che forniscono un’indicazione sullo
stato della fase in questione (aperta, chiusa o annullata), senza però chiarire, a
chiunque lo guardi, se si sono accumulati dei ritardi tali da impedire di
inserire nella nuova gamma il prodotto desiderato. L’assenza di uno
strumento adeguato ed efficace ha quindi portato a dover rinunciare a
qualsiasi tipo di attività di pianificazione - se non per i progetti più complessi,
102
per i quali si realizzavano dei Gantt personalizzati con Microsoft Project – il
che porta, come vedremo nei prossimi paragrafi, ad accorgersi troppo tardi
dei ritardi maturati, costringendo le persone coinvolte a continue attività di
“pompieraggio” per recuperare il tempo perso.
Figura 8.3: Rappresentazione della scermata del Lotus Notes (Fonte: “Materiale interno aziendale”)
Nella maggior parte dei casi, nonostante l’assenza di informazioni indispensabili, e i
conseguenti studi di fattibilità in un certo senso deficitari, si procede ugualmente con
lo sviluppo del prodotto in questione, con il rischio che, a progetto già inoltrato, la
strada intrapresa subisca un’improvvisa deviazione, dovuta allo stravolgimento di
decisioni precedentemente concordate (un esempio è il cambio di tecnologia per la
realizzazione della schiumatura della sella), con inevitabili ritardi nella presentazione
del prodotto ai propri clienti.
Al termine dell’analisi di fattibilità si procede poi con le successive attività di
prototipazione, attrezzaggio, campionatura e test, al termine del quale si avvia la fase
di mass production e chiusura contabile del progetto. In figura 8.4 è riportato uno
schema riassuntivo delle principali fasi che compongono l’intero processo di
sviluppo nuovo prodotto, dalla raccolta delle idee, fino alla messa in produzione
della nuova sella industrializzata.
103
Figura 8.4: Rappresentazione del processo seguito per lo sviluppo di una nuova sella (Fonte:
“Materiale interno aziendale”)
8.3.2
Analisi critica delle modalità AS IS di gestione delle “correlazioni” e dei
“progetti”
Come visto nel paragrafo dedicato alla classificazione dei progetti adottata in Selle
Royal, le PNP si differenziano dai “progetti” e dalle “correlazioni semplici” per il
grado di difficoltà legato alle attività di progettazione e industrializzazione del
nuovo prodotto. Ed è proprio grazie alla minore complessità che, per le ultime due
categorie, vengono adottate delle procedure di gestione semplificate rispetto a
quanto descritto nel paragrafo precedente per le più articolate PNP.
“Correlazione”: qualora venga richiesta una versione particolare di un codice
prodotto finito esistente, utilizzando le varianti proposte dal customizzatore – nel
caso di versioni OEM per il brand Selle Royal – è responsabilità del Customer Service
inserire la richiesta ed aprire quindi una nuova “correlazione” all’interno del Lotus
Notes, previa verifica in AS 400 che il codice figlio non sia già stato creato in
104
anagrafica. Una volta compilata la maschera di apertura della correlazione all’interno
del software, il Customer Service deve assolutamente inviare una mail, non integrata
con il Lotus, al Master Data, responsabile della creazione della distinta base del nuovo
codice prodotto finito e dei relativi componenti figli in AS 400. Questa figura, dopo
aver generato i codici e le anagrafiche dei componenti utilizzati, nonché i relativi
legami per la nuova distinta base, ha il compito di creare il codice e di legarlo con il
numero della “correlazione” che si ottiene dal Lotus Notes. Nel caso erroneamente
ne venisse aperta una per un codice PF già esistente deve essere il Project Controller
che, su segnalazione del responsabile della distinta base, e dopo aver effettuato gli
opportuni accertamenti, ha l’onere di annullare la richiesta.
“Progetto” (correlazioni difficili): qualora invece venga richiesta una versione
particolare di un codice esistente, utilizzando varianti non proposte dal
customizzatore, o che richieda l’utilizzo di nuovi codici figli che hanno necessità di
benestare estetico o di packaging, l’ente richiedente – che in questo caso può essere il
Business Unit Manager, il Product Manager o il Customer Service – deve avviare
tramite Lotus la richiesta di apertura di un nuovo “progetto” compilando l’apposita
maschera e, qualora necessario, allegarvi il brief. Una volta che la richiesta è stata
validata, il Project Controller provvede ad avviare le attività di campionatura,
informando l’ufficio tecnico tramite una mail inviata da Outlook e non direttamente
con Lotus Notes, che non prevede appunto la possibilità di inviare mail direttamente
da sistema. Una volta completate le attività di progettazione e sviluppo della
particolare variante, l’ufficio tecnico consegna al cliente o al Business Unit Manager
(a seconda di chi è l’ente richiedente) un campione del prodotto finito per ottenere
l’approvazione definitiva, che avvia successivamente le attività di benestare dei
nuovi componenti estetici e del packaging. Ottenuto il benestare di tutti i nuovi
codici figli il Master Data, come accade anche per le correlazioni, crea la distinta base
in AS400 e comunica il nuovo codice prodotto finito. A questo punto si apre una
nuova fase di analisi dei costi del prodotto: il responsabile dell’ufficio acquisti
comunica i costi al controllo di gestione, che inserisce il costo standard nell’archivio e
parallelamente verifica il corretto completamento della costificazione dei componenti
e del prodotto finito. Nel caso di identificazione di errori il controllo di gestione
105
richiede all’ufficio acquisti l’immediata correzione, mantenendo bloccata questa fase
fino al completamento positivo della verifica. Il Project Controller, una volta ricevuta
la validazione da parte del controllo di gestione e verificato che i nuovi codici siano
stati benestariati, chiude il progetto, consegnando il codice prodotto finito al
Customer Service per l’inserimento dell’ordine a sistema.
8.4 PROBLEMI EMERSI NELL’ATTUALE GESTIONE DEI PROGETTI
Come evidenziato nel corso dell’elaborato, uno dei problemi principali che sta
affrontando il Gruppo è l’enorme variabilità introdotta all’interno delle nuove
gamme di prodotti, che comporta un’ingiustificata complessità interna, senza
generare al contempo un corrispondente incremento delle vendite. Questa variabilità
però si contrappone inevitabilmente con il numero limitato di risorse disponibili ad
oggi nell’ufficio tecnico di Selle Royal. Come è immaginabile pensare, questo
continuo proliferare di nuovi modelli da introdurre nel mercato va a sovraccaricare
le persone che si occupano, ciascuno con il proprio ruolo, di sviluppare il prodotto,
con conseguenti ritardi rispetto alle tempistiche richieste dal mercato. Ancora oggi
infatti si tende a ragionare a capacità infinita, anche perché, prima dell’introduzione
di AtTask, non si disponeva di alcuno strumento in grado di misurare il carico di
lavoro che ciascuna persona doveva sostenere per svolgere le numerose attività di
cui era responsabile. A partire da questa considerazione è naturale evidenziare come
uno degli obiettivi principali, per cui si è deciso di ricorrere ad un software di project
management, è appunto quello di permettere di pianificare l’utilizzo delle risorse
ragionando a capacità finita. Questo obiettivo è a sua volta strettamente collegato con
il concetto di prioritizzazione del portfolio (e quindi al tema del Project Portfolio
Management), che permette, sulla base di criteri di valutazione individuati
dall’azienda, di identificare la sequenza ottimale da seguire nello svolgimento dei
progetti.
Incrociando
intelligentemente
queste
due
funzioni
–
conosciute
rispettivamente come capacity planning e portfolio prioritization (ramo del Project
Portfolio Management) - sarà dunque possibile procedere in primis con lo sviluppo dei
progetti ritenuti fondamentali per la strategia aziendale, fino a saturazione di tutte le
risorse interessate, per poi procedere con la pianificazione di quelli aventi priorità
106
più bassa, tenendo sempre in considerazione la disponibilità limitata delle persone
nei diversi intervalli temporali. Così facendo, si riuscirebbe dunque a filtrare il
numero di modelli che vengono sviluppati ogni anno, riducendo di conseguenza i
ritardi nel rilascio delle nuove gamme, ma lasciando al contempo al cliente un’ampia
libertà di personalizzazione del prodotto sulla base delle sue specifiche esigenze.
Potrebbe infatti risultare controproducente, nella fase di lancio di una nuova linea di
prodotti, proporre sin da subito una grande varietà di modelli diversi; la scelta più
ponderata è infatti quella di offrire un range di modelli mirati per capire come il
mercato reagisce, e, osservando l’andamento delle richieste, estendere in un secondo
momento la gamma con nuovi prodotti sulla base di quanto effettivamente il mercato
richiede in quello specifico momento.
Tuttavia il sovraccarico delle risorse non è l’unica causa individuata del costante
ritardo dei progetti. Come è stato sottolineato nel paragrafo dedicato alla descrizione
dei principali ruoli gestionali che intervengono nel processo di sviluppo del
prodotto, è pressoché assente la fase iniziale di pianificazione del progetto, fatta
eccezione per alcuni rari casi. La baseline che si ottiene in questa fase permette infatti
di confrontare ciò che è stato effettivamente realizzato con ciò che era stato
pianificato, consentendo al project manager, o chi per esso, di capire fin da subito se
il ritmo con cui procede l’avanzamento è tale da permettere di rispettare le deadline
inizialmente prefissate. Senza un piano ufficiale diventa pressoché impossibile avere
il pieno controllo sullo stato del progetto, il che porta ad accorgersi troppo tardi degli
eventuali ritardi fino ad allora intervenuti. Inoltre, la disponibilità di uno strumento
che permetta di pianificare i progetti con un elevato grado di dettaglio consente al
Project Leader di anticipare una serie di considerazioni sul modo di procedere, che
altrimenti potrebbero essere completamente trascurate, con conseguente dilatazione
dei tempi. Pianificare permette quindi di “scovare” a priori delle strategie che
altrimenti rimarrebbero all’oscuro, oppure si individuerebbero quando ormai il
progetto si trova ad un punto troppo avanzato per poter apportare qualsiasi tipo di
miglioramento.
107
Un altro grave problema riscontrato riguardava l’assenza di un efficace strumento
integrato, tra i vari stabilimenti di proprietà del Gruppo e anche all’interno dello
stesso stabilimento italiano, per la gestione dei progetti. Prima dell’introduzione di
AtTask, infatti, in Italia il sistema di riferimento era il Lotus Notes, che però non
consentiva di pianificare lo svolgimento del progetto, ma permetteva solamente di
gestire il portfolio (ossia avere una lista di tutti i progetti sviluppati nel corso degli
anni), con in più una scarna indicazione sul suo avanzamento, basata sulle sei macro
fasi principali. In aggiunta, per quanto riguarda la pianificazione - per le rare volte in
cui essa è stata eseguita (ci si limitava infatti a pianificare solamente i progetti più
complicati, con un certo grado di innovazione) - il Program Manager, insieme al
Product Developer, utilizzava Microsoft Project. Il punto debole risiedeva dunque
nel fatto che questo programma era totalmente slegato dal Lotus Notes, e quindi non
forniva alcun aiuto al responsabile per capire se il progetto procedeva secondo
quanto pianificato, o se al contrario si era accumulato del ritardo che inevitabilmente
ne posticipava il completamento: questa era la situazione da cui si partiva in Selle
Royal Italia. In Justek invece, che costituisce l’”anima produttiva”di Selle Royal, non
si aveva ancora a disposizione alcun tipo di software (nemmeno il Lotus Notes
perché si tratta di un software PC-based), e quindi si limitavano ad una gestione
sommaria del portfolio tramite l’uso di fogli Excel, in cui cercavano di riproporre
l’interfaccia del Lotus Notes italiano, riportando le sei principali macrofasi del
processo di sviluppo. Questa mancanza rappresentava sicuramente un grave limite
per tutto il gruppo, soprattutto quando si aveva a che fare con articoli progettati in
Italia, ma industrializzati e prodotti in Cina.
Il Project Controller dell’headquarter italiano era infatti costretto ad aprire la PNP
all’interno del Lotus – in modo da avere quantomeno traccia, in un unico sistema,
dell’esistenza del progetto – che poi però non poteva essere aggiornata man mano
dai responsabili in Justek, proprio perché si trattava di un sistema isolato, PC-based,
utilizzabile esclusivamente in Italia. Era quindi necessario che il Product Developer
e/o il Project Manager di Justek aggiornassero periodicamente il Project Controller
sull’avanzamento del progetto tramite strumenti destrutturati e disomogenei, come
fogli Excel, e-mail e chiamate Skype. È dunque evidente come le informazioni
108
venissero scambiate attraverso una molteplicità di canali diversi, con il rischio non
solo di non riuscire ad avere tutta la storia del progetto, ma soprattutto di avere dati
a volte tra loro fortemente discordanti a seconda del mittente. Era quindi condivisa
l’esigenza di disporre di un unico strumento integrato che permettesse a chiunque, e
in qualsiasi momento, di verificare lo stato del progetto e di scambiare qualsiasi tipo
di informazione rilevante per il progetto, attraverso un unico canale ufficialmente
riconosciuto. Perciò, grazie a uno strumento cloud based, si potrebbe riuscire a
facilitare la condivisione dell’informazione in maniera trasversale tra tutti gli enti
interessati nel processo, favorendo in secondo luogo una migliore collaborazione e
coordinamento tra le diverse aree aziendali coinvolte.
Rimanendo sempre in tema di miglioramento della collaborazione e del
coordinamento tra le persone, con l’introduzione di questo avanzato sistema di
project management si è cercato di trovare una soluzione in grado di porre fine
all’annoso problema della gestione dei progetti inter-company tra Italia e Cina. Il
nuovo PMIS infatti, in particolar modo per quel che riguarda i prodotti con brand
Selle Royal sviluppati in Cina – che quindi devono rispondere a dei ferrei standard
qualitativi di prodotto e soprattutto di processo – vuole garantire ai responsabili del
brand, che operano nella sede italiana di Selle Royal, di avere la massima trasparenza
e sensibilità sull’avanzamento e sugli eventuali problemi riscontrati durante lo
sviluppo in Justek, in modo da riuscire ad intervenire tempestivamente evitando
inaspettate cadute nel vuoto. Strettamente collegato con quanto appena discusso, vi è
il tema della reportistica, fino ad allora molto scarna sia in termini di contenuti che di
frequenza con cui essa veniva presentata ai vari attori. Questa lacuna era dovuta
principalmente al fatto che Lotus Notes non dava la possibilità di interrogare il suo
database per estrapolare dati rilevanti sull’avanzamento del singolo progetto, o sul
livello di ottimizzazione dell’intero portfolio (Project Portfolio Optimization). Si sentiva
dunque l’esigenza di dotarsi di uno strumento in grado di aumentare la visibilità, sia
a livello prettamente esecutivo/gestionale, che ad un livello più direzionale,
attraverso l’elaborazione di reports strutturati che contenessero tutte le informazioni
utili.
109
8.5 LA SCELTA DI ATTASK
Nel paragrafo precedente è emersa una lista di problemi che le persone che lavorano
in Selle Royal si trovano a dover affrontare quotidianamente, problemi che
inevitabilmente rendono il loro lavoro particolarmente inefficace e problematico,
anche e soprattutto in ottica di raggiungimento dei propri obiettivi. Si è quindi resa
pressoché necessaria l’esigenza di un cambiamento degli strumenti da adottare, che
accompagnasse parallelamente la riorganizzazione aziendale in atto. Per cercare di
risolvere questi numerosi inconvenienti si è quindi deciso di dotarsi di un software di
Project Management in grado di supportare i team member, ma anche la direzione,
per ottimizzare la gestione sia del singolo progetto, ma anche e soprattutto dell’intero
portfoglio. I risultati di un’azienda infatti migliorano con una buona organizzazione
e una chiara comprensione del lavoro da svolgere, il che permette di minimizzare i
processi superflui e l’eccessiva burocrazia che spesso ostacola il tentativo di creare
efficienza. Quello di cui si ha estremamente bisogno in Selle Royal è un software che
riesca a fondere gli strumenti chiave, necessari agli esecutori della gestione dei
progetti, con gli strumenti ideati per aiutare i membri del team a collaborare e
organizzare i loro compiti. Il software di Project Management ritenuto adeguato alla
situazione descritta nei paragrafi precedenti, in quanto in grado di risolvere alcuni
dei principali problemi evidenziati prende il nome di AtTask, un sistema interamente
web-based utilizzato per ottimizzare la gestione dei progetti.
Il primo motivo per cui è stato deciso di puntare su AtTask risiede nel fatto che si
tratta di un Project Portfolio Management Software, ossia uno strumento in grado non
solo di gestire la singola iniziativa, ma l’intera lista di progetti che vengono
sviluppati all’interno di un’organizzazione e che sfruttano il medesimo pool di risorse.
Con AtTask dunque, oltre a capire come il singolo progetto sta procedendo, è
possibile anche comprendere quanto performante è il portfolio nel suo complesso.
Questa funzione, oltre a monitorare se le milestone vengono raggiunte o meno nei
tempi previsti, aiuta anche a calcolare alcuni parametri fondamentali, come ad
esempio il ROI, che permettono di verificare se il portfolio nel suo insieme sta
aumentando il valore del business dell’azienda. In aggiunta, questo software dispone
110
di uno specifico tool, chiamato portfolio optimization, che permette di affinare e
ottimizzare il portfolio dell’azienda. Per ottenere questo risultato di portfolio tuning,
AtTask sfrutta i valori che vengono inseriti nel business case all’apertura di ciascun
progetto. Il form di tale business case richiede di compilare una serie di campi, tra cui:
i profitti che si prevede di ottenere (planned benefits);
i costi pianificati (planned costs);
rischi (risks);
ed infine una scorecard, che a sua volta permette di attribuire un valore
quantitativo a degli attributi strategici di carattere prettamente qualitativo,
con l’obiettivo di valutare i progetti rispetto ai key performance indicators (KPI)
definiti dal gruppo.
Sulla base delle risposte selezionate in ognuno dei campi che compongono il business
case, AtTask automaticamente assegna un punteggio a ciascun progetto del portfolio,
a partire dal quale viene definito l’ordine ideale di esecuzione che permette di
massimizzare il business.
Purtroppo però, per risolvere il problema dei ritardi dovuti al sovraccarico delle
risorse che lavorano allo sviluppo del prodotto, non è sufficiente uno strumento in
grado di stabilire semplicemente delle priorità, ma parallelamente devono essere
affiancate anche delle attività di resource planning, funzione che AtTask è in grado di
soddisfare efficacemente. Una volta selezionata una specifica timeframe il Capacity
Planner di AtTask individua le risorse disponibili in quell’intervallo di tempo
assegnandole a ciascuna delle attività che compongono i numerosi progetti,
individuando la prima data disponibile di partenza che permetta di minimizzare la
percentuale di sovraccarico. Ovviamente nel pianificare lo “sfruttamento” delle
risorse si devono considerare prima di tutto i progetti per cui è stata definita una
priorità elevata.
Un altro requisito fondamentale che deve assolutamente avere il PMIS in questione è
quello dello schedule and communication management. E la scelta è ricaduta su AtTask
111
anche perché questo software permette di pianificare (tenendo conto della
disponibilità di risorse) il progetto, o anche un programma complesso di progetti,
monitorando l’avanzamento e le milestone grazie alla presenza di diagrammi di Gantt
interattivi e real-time. Per la pianificazione dei progetti inoltre possono essere
utilizzati dei template, ossia dei modelli standard time-tested del flusso di processo da
seguire, che ne velocizzano l’impostazione. Una volta definito il workflow da seguire
ciascun team member conosce tutte le sue attività, e soprattutto entro quando queste
devono essere completate per non provocare un ritardo dell’intero progetto.
Vista la necessità di dotarsi di uno strumento che supporti i team member nella
gestione dei progetti di sviluppo nuovo prodotto, un requisito considerato primario
per la scelta del software più adatto alle esigenze riscontrate da Selle Royal, è
sicuramente la possibilità di sfruttare tale strumento anche come repository
documentale. AtTask, tra le numerose sue caratteristiche, fornisce anche la possibilità
di caricare e immagazzinare tutti i documenti e le immagini utilizzate nel corso del
processo di sviluppo. Si tratta infatti di un software web based che carica i documenti
nel cloud assicurando a tutti gli enti coinvolti un pieno accesso, indipendentemente
da dove questi si trovano a lavorare, garantendo al contempo un elevato grado di
riservatezza su tutte le informazioni sensibili che non devono in alcun modo essere
visibili. Grazie a questa ottimale modalità di gestione e condivisione, che raggruppa
tutte le informazioni inerenti uno stesso progetto in un unico posto, non vi sarà più la
necessità di “scavare” tra le numerose versioni dello stesso documento per trovare
ciò di cui si ha bisogno per prendere delle decisioni corrette.
Last but not least, vi è la necessità di distribuire dei report company wide che migliorino
la visibilità sui progetti in questione, in modo tale che sia trasparente per chiunque lo
stato di avanzamento del progetto e gli eventuali problemi riscontrati nel corso del
tempo che hanno generato un inevitabile ritardo del progetto rispetto a quanto era
stato pianificato inizialmente.
Infine, oltre a questa lunga lista di requisiti da soddisfare, che come è stato
dimostrato il software acquistato è ampliamente in grado di soddisfare, a conferma
del fatto che la scelta è giustamente ricaduta su AtTask, vi è sia la valutazione
112
pubblicata dal Gartner Group (un importante analista di software IT), che nel famoso
“Quandrante Magico” da loro inventato, ha posizionato AtTask proprio nel riquadro
in alto a destra, ossia il quadrante dedicato ai migliori software di project
management web based, sia il fatto che il sistema può essere implementato con una
certa rapidità e senza la necessità di disporre di specifiche competenze informatiche.
Per tutti questi motivi, supportati come detto anche da studi fatti da esperti nel
settore dei PMIS, la scelta è ricaduta su AtTask. Questo strumento dà infatti agli
amministratori e ai manager il potere di ottenere una maggiore visibilità sulle attività
assegnate alle risorse e la garanzia di un perfetto allineamento dei progetti alle
strategie aziendali, massimizzando al contempo l’efficacia e l’efficienza nell’utilizzo
delle risorse. Con AtTask, i team si impegnano a fornire informazioni dirette a livello
conversazionale e al flusso verso l’alto degli impegni, consentendo maggiore
precisione nelle proiezioni, maggiore visibilità e una quantità più elevata di
informazioni sulla tempistica di completamento dei lavori e dei progetti. Infatti, per
migliorare e semplificare il lavoro delle perone è utile creare un ecosistema in cui la
comunicazione e la collaborazione fluiscano efficacemente attraverso un sistema,
dando vita a un meccanismo di indirizzamento delle informazioni alle persone giuste
e al momento giusto, che colleghi i diversi livelli dell’organizzazione, assicurando
che tutti procedano verso la stessa meta. In conclusione, grazie alla trasparenza delle
informazioni e all’elevata visibilità garantita, AtTask aiuta a mantenere occupato il
team sul lavoro giusto, in armonia con le strategie, gli obiettivi e le mete principali,
consentendo loro di contribuire con il massimo del valore al raggiungimento di tali
risultati.
113
114
9 ANALISI E
IMPLEMENTAZIONE DI ATTASK
AtTask è una software house Americana con sede negli Utah, fondata nel 2001 da
Scott Johnson, che sviluppa software di Project Management cloud-based, grazie a
cui gli utenti abilitati possono accedervi direttamente tramite una semplice
connessione web. Si tratta dunque di un software che permette all’azienda che lo
utilizza di aumentare la propria abilità e efficienza nella gestione dei progetti, grazie
all’ottimale distribuzione dei dati, che consente di dimezzare il tempo sprecato per la
raccolta delle informazioni necessarie e di incrementare di conseguenza le ore che
ciascuna persona dedica effettivamente ad attività a valore aggiunto per
l’avanzamento del progetto.
Per riuscire ad implementare AtTask con il massimo successo, sfruttandone tutte le
sue potenzialità, è stata identificata una roadmap ideale, che può essere suddivisa in
quattro fasi principali, ciascuna con obiettivi e responsabili ben precisi:
1.
Analisi preliminare degli obiettivi dell’implementazione di AtTask (Gathering
requirements);
2.
Training del Core Implementation Team e dei team member coinvolti nei
processi di sviluppo prodotto (Schedule education);
3.
Analisi dei business processes di Selle Royal e configurazione di AtTask (AtTask
configuration);
115
4.
Esecuzione del test pilota (Pilot test).
9.1 ANALISI PRELIMINARE DEGLI OBIETTIVI DELL’IMPLEMENTAZIONE DI
ATTASK (Gathering Requirements)
Il primo importante passo per un’efficace implementazione di AtTask consiste
nell’identificazione degli obiettivi che si vogliono raggiungere e dei problemi che si
vogliono risolvere: si devono dunque identificare i cosiddetti success criteria.
All’interno delle aziende infatti, capita molto spesso che non si sia pienamente
consapevoli di cosa si voglia ottenere con l’introduzione del nuovo PMIS, rischiando
di dotarsi di uno strumento poco adatto alle proprie esigenze, che non verrebbe
quindi sfruttato al massimo delle sue potenzialità, ma che servirebbe solamente a
nascondere possibili problemi.
Una volta identificati gli obiettivi che si vogliono raggiungere, è possibile cominciare
a definire i success criteria, che testimoniano il successo dell’implementazione di
AtTask e che ovviamente rappresentano i motivi principali per cui è stato acquistato
il software. Nel capitolo precedente è stato dedicato un paragrafo alla descrizione dei
problemi e degli objectives che il board di Selle Royal si è prefisso di raggiungere con
l’introduzione del software, che vengono riassunti qui di seguito:
1. Migliore condivisione delle informazioni relative ad un progetto e maggiore
collaborazione tra le principali funzioni aziendali coinvolte;
2. Efficace pianificazione sia a livello di singolo progetto, che a livello di famiglia
di prodotti;
3. Maggiore visibilità sullo stato di avanzamento del progetto, in modo tale da
capire con sufficiente anticipo la presenza di eventuali ritardi rispetto alle
tempistiche richieste;
4. Possibilità di gestire progetti intercompany, di selle progettate in Italia ma
effettivamente prodotte in Cina, all’interno di un unico sistema integrato e
condiviso sia da Selle Royal Italia, che da Justek;
116
5. Prioritizzazione del portfolio attraverso l’utilizzo del Business Case e della
Scorecard, che permetterebbe al contempo anche la pianificazione a capacità
finita;
6. Ottimizzazione del processo di gestione di sviluppo nuovo prodotto, così da
riuscire a ridurre il time-to-market attualmente troppo dilatato nel tempo.
Nonostante le molteplici potenzialità di AtTask nella gestione del progetto end-toend e quella più ampia del portfolio, la sfida sta nel non cercare di ottenere tutto e
subito. L’implementazione ottimale prevede infatti la definizione di uno schedule, in
cui al termine di ogni intervallo di tempo corrisponde un preciso obiettivo da
raggiungere. Visto che in Selle Royal non è ancora largamente diffusa una forte
cultura sul tema della gestione per progetti, si è deciso di partire dagli aspetti più
semplici, cercando parallelamente di accrescere la sensibilità delle persone su certi
temi. Si è dunque pensato di cominciare innanzitutto a gestire in AtTask le PNP,
lasciando momentaneamente in disparte tutto ciò che rientra nel mondo delle
correlazioni; questo perché la seconda categoria di progetti rappresenta la grande
mole di lavoro quotidiano, che richiede perciò rapidità e abitudine. Inoltre il vecchio
Lotus Notes è abbastanza efficace nella gestione di questo tipo di progetti semplici. È
stata quindi presa la decisione di utilizzare le PNP della gamma 2016 come progetti
da sfruttare per formare il personale all’utilizzo del nuovo software, nonché per
cercare di migliorare ulteriormente quanto configurato fino ad allora. Con questa
prima tranche di progetti interamente gestiti in AtTask gli obiettivi da soddisfare
sono stati individuati nei primi quattro punti della lista, in modo da preparare il
terreno per i due successivi punti da implementare a partire dai progetti della
gamma 2017.
9.2
TRAINING DEL CORE IMPLEMENTATION TEAM E DEI TEAM
MEMBER COINVOLTI NEI PROCESSI DI SVILUPPO PRODOTTO (Schedule
Education)
Una volta chiariti gli obiettivi si può passare al secondo step del processo di
implementazione del software: la schedulazione di un corretto Education Plan. Il
programma di training viene suddiviso in due fasi principali: la fase iniziale, in cui
117
vengono coinvolti solamente i membri del Core Implementation Team, ed una seconda
fase in cui invece si provvede a farlo conoscere a tutti i principali enti coinvolti
nell’utilizzo di AtTask.
La definizione iniziale di un dettagliato piano di training diventa quindi un aspetto
cruciale, in quanto assicura che tutta la squadra abbia la conoscenza necessaria per
implementare ed utilizzare nei tempi più opportuni e nel modo più efficace possibile
AtTask.
Training del Core Implementation Team
Oltre a coinvolgere un team di consulenti specializzati nell’utilizzo di AtTask (AtTask
Team), il progetto di adozione del nuovo sistema richiede la formazione anche di un
Core Implementation Team interno all’azienda, composto quantomeno da un
Implementation Manager, da un System Adminstrator, dal Project Manager ed infine da
un Internal AtTask Trainer. Quest’iniziativa infatti non potrebbe in alcun modo aver
successo se all’interno del team non fossero presenti almeno queste quattro figure;
inoltre, il fatto di aver individuato fin dall’inizio questo team permette di
comprendere quali sono le persone che hanno un ruolo chiave nell’implementazione,
e che per questo motivo devono essere le prime a seguire il training più adatto a loro.
Questa prima fase prevede innanzitutto la presenza iniziale di un consulente di
AtTask, che per una settimana affianca i membri dell’Implementation Team, con
l’obiettivo di trasferire e chiarire quali sono le principali funzioni che il sistema è in
grado di supportare. Al termine della settimana le persone individuate sono quindi
consapevoli delle funzionalità del sistema e di come esso, in linea di principio, possa
essere d’aiuto per risolvere i problemi individuati. A questo punto, in parallelo
all’analisi delle attuali modalità di gestione dei progetti, ciascun membro del Core
Implementation
Team
partecipa
a
una
serie
di
corsi
interattivi,
studiati
meticolosamente per rispondere alle esigenze che ognuno di loro può avere,
connesse con il ruolo che essi svolgono all’interno del team di implementazione.
Questo training è perciò finalizzato a trasmettere una conoscenza approfondita dello
strumento che permetta non solo di preparare al meglio l’environment di AtTask che
118
verrà utilizzato dall’intera organizzazione, ma anche e soprattutto di utilizzarlo nel
miglior modo possibile per ottimizzare la gestione dei progetti.
Training dei Team Member
La seconda fase di training prevede invece la formazione del team che si occupa
dell’esecuzione del test pilota, composto da tutti gli enti che sono coinvolti, ciascuno
con una responsabilità diversa, all’interno del processo di sviluppo nuovo prodotto.
Questo team deve partecipare a dei “corsi di formazione” per poter poi essere in
grado di testare se il modo in cui è stato impostato AtTask da parte
dell’Implementation Team corrisponde ed è adatto alle modalità di gestione
effettivamente adottate all’interno dell’organizzazione. Questa fase di formazione
può essere svolta direttamente dall’Internal AtTask Trainer, il quale dopo aver
partecipato ai vari corsi previsti e aver maturato un buona conoscenza dello
strumento, è in grado di spiegare e trasmettere agli altri enti le notevoli potenzialità
di AtTask. Ovviamente la loro formazione viene effettuata sia durante il test pilota,
che permette appunto di testare quanto configurato precedentemente, ma anche nel
corso dei futuri progetti che verranno gestiti con il nuovo sistema. Questo permette
dunque di garantire un apprendimento progressivo, con il risultato di riuscire a
personalizzarne la configurazione sulla base delle esigenze di ciascuna persona.
9.3
RE-ENGINEERING DEI BUSINESS PROCESSES DI SELLE ROYAL E
CONFIGURAZIONE DI ATTASK (AtTask Configuration)
Prima di procedere con l’implementazione di AtTask all’interno della propria
organizzazione è fondamentale aver identificato innanzitutto come i progetti
vengono gestiti prima della sua introduzione; si tratta della cosiddetta analisi AS IS.
Mappando il processo adottato per la gestione dei progetti di sviluppo del nuovo
prodotto, dalla loro apertura alla loro chiusura contabile, è possibile identificare
immediatamente quali sono le aree più efficienti, e quali invece avrebbero bisogno di
un miglioramento. Il primo step da affrontare riguarda dunque la comprensione e
documentazione del workflow dei processi (modalità di apertura del progetto, di
pianificazione, di condivisione delle informazioni e di flusso delle attività da seguire
119
per arrivare al prodotto finito), dei ruoli delle persone chiave coinvolte ed infine delle
procedure che guidano l’avanzamento dei progetti all’interno dell’azienda. A partire
dall’analisi di questa situazione il team è dunque in grado di valutare quali best
practices adottare per ottimizzare la gestione dei propri progetti ed eventuali
opportunità di maggiore collaborazione e comunicazione che porterebbero, con
l’aiuto del software, a dei risultati migliori.
Una volta individuati gli obiettivi che si desidera raggiungere con l’introduzione di
AtTask si è dunque passati alla documentazione e formalizzazione del flusso di
processo che deve essere seguito e delle informazioni necessarie per ottimizzare
l’efficienza nella gestione dei progetti.
9.3.1
Definizione del flusso delle richieste per l’apertura di nuovi progetti
Come è stato detto nell’introduzione del capitolo 8, all’interno di Selle Royal possono
essere individuate tre macro categorie di progetti, ciascuna delle quali con un grado
di complessità notevolmente differente. Da una parte si ha il mondo delle PNP, ossia
delle proposte di sviluppo nuovo prodotto, che richiedono complesse attività di
progettazione e costruzione degli stampi ad iniezione e di schiumatura, che hanno
tempistiche piuttosto lunghe e seguono un percorso di gestione del progetto con
molti punti in comune. Dalla parte opposta vi sono invece le “correlazioni” che
richiedono lo sviluppo di nuove grafiche o di nuovi packaging, che a loro volta
prevedono delle figure e delle procedure a sé stanti, e che quindi meritano di essere
gestite indipendentemente rispetto alle PNP. L’ultima, nonché la più semplice
categoria, fa riferimento alle personalizzazioni specificate direttamente dal cliente,
ma che, a differenza del caso precedente, ricadono all’interno dello spazio di
prodotto offerto dall’azienda.
Prima del processo di analisi e ridefinizione delle modalità di gestione dei progetti,
tutte le attività di Project Management erano concentrate intorno alla figura del
Project Controller, sia che si trattasse di PNP sia di “correlazioni”. Tuttavia, dal
momento che questa figura ricopriva anche un ruolo fondamentale nella gestione
dell’anagrafica dei prodotti, non disponeva del tempo necessario per dedicarsi ad
120
attività di pianificazione e monitoraggio dell’avanzamento degli innumerevoli
progetti. Tutto ciò, aggiunto alla mancanza di uno strumento adeguato, impediva di
conseguenza di mettere in luce con un certo anticipo la presenza di eventuali ritardi.
Nel momento in cui tale ritardo diventava evidente, per riuscire a rispettare le date
richieste, le persone si trovavano a dover gestire le loro attività in una costante
situazione di urgenza. Per questa ragione, per ciascuna delle tre tipologie di progetti
prima descritti è stato previsto uno specifico flusso di apertura, in quanto per ognuna
di esse sono previsti percorsi di approvazione strutturati diversamente e che perciò
coinvolgono anche persone differenti all’interno dell’azienda.
Percorso di apertura della richiesta per lo sviluppo di una nuova PNP: vista la poca
esperienza in materia di Project Management presente fino ad allora all’interno di
Selle Royal, parallelamente all’implementazione del nuovo software si è colta
l’occasione per ridefinire delle precise procedure da seguire per la gestione dei nuovi
progetti, ed introdurre una chiara suddivisione dei ruoli e dei compiti che ciascuno
degli enti interessati aveva all’interno del progetto. Questa attività di Business Process
Reengineering ha portato ad una suddivisione del mondo delle PNP in due rami
principali, cui ha fatto seguito, per riuscire a supportare questo cambiamento,
l’introduzione di una nuova figura all’interno di Selle Royal, quella del Project
Manager. Allo scopo di ottenere una chiara definizione delle procedure di apertura e
gestione dei progetti, e delle responsabilità che ne derivano, sono stati impostati due
percorsi di richiesta indipendenti l’uno dall’altro:
1. Percorso di richiesta per l’apertura di una nuova “PNP interna” (Internal PNP):
si tratta di nuovi prodotti la cui ideazione è frutto esclusivamente del Product
Manager, che come si è anticipato, deve essere in grado con la sua esperienza
di anticipare i bisogni del mercato. È stato perciò deciso di affidare al Project
Manager la responsabilità di gestire questo tipo di processo di sviluppo nuovo
prodotto, dall’apertura del progetto fino alla fase finale di chiusura contabile,
corrispondente con la prima produzione di massa del nuovo articolo.
2. Percorso di richiesta per l’apertura di una nuova “PNP Customer”(Custom
PNP): si tratta prevalentemente di PNP 2 che vengono commissionate
121
direttamente dal cliente. A seconda del contratto che viene stipulato il
prodotto sviluppato può o essere venduto solamente al cliente che l’ha
richiesto, o in alcuni casi anche attraverso uno dei canali descritti.
Diversamente dal caso precedente, per questa categoria si è ritenuto
necessario mantenere inalterata la modalità di gestione – per chiari motivi di
fidelizzazione del cliente nei confronti della persona con cui fino a quel
momento aveva mantenuto i contatti - lasciando la responsabilità direttamente
al Project Controller, che deve monitorare l’avanzamento del progetto nel
rispetto delle richieste del cliente in termini di tempi e costi di sviluppo.
Percorso di apertura della richiesta per lo sviluppo di nuove “correlazioni”: prima
di intraprendere questo processo di Re-engineering nella gestione dello sviluppo
nuovo prodotto, tutte le “correlazioni” (che richiedevano delle attività all’interno
dell’Ufficio Tecnico), così come tutte le PNP, erano controllate, indipendentemente
da chi le richiedesse, da un’unica figura, ossia il Project Controller, con naturali
inefficienze gestionali dovute all’enorme mole di lavoro che si concentrava sulla
medesima risorsa.
Per cercare di migliorare questa situazione, e garantire livelli di servizio più elevati,
si è ritenuto necessario che anche all’interno della sfera delle “correlazioni”, come era
stato fatto per le PNP, venisse proposta una re-ingegnerizzazione del flusso di
processo, con l’obiettivo di ottenere una chiara suddivisione dei compiti e delle
responsabilità di ciascuno, che ripartisse in maniera omogenea i carichi di lavoro tra
il Project Controller e il nuovo Project Manager. A questo scopo le “correlazioni” più
complesse sono state suddivise in due rami differenti: le “correlazioni interne”
(Internal Customisations) e le “correlazioni” richieste dal cliente (Customer
Customisations).
Le Internal Customisations fanno riferimento alle versioni che nascono a partire dallo
sviluppo di una nuova PNP. Nel capitolo precedente si è infatti sottolineato come per
minimizzare i costi si proceda con lo sviluppo di una versione base, avente le
caratteristiche più economiche possibili. Ovviamente questa versione 00 non
rispecchia le specifiche grafiche richieste dal Product Manager, onde per cui la
122
suddetta variante non viene mai inserita all’interno della gamma. Quindi il Product
Manager oltre a fornire al Product Developer delle linee guida sul concept del
prodotto, avrà anche il compito fondamentale di definire le varie grafiche che si
vogliono avere su ciascun nuovo modello di sella da inserire nel catalogo. Da
sottolineare che ad ogni nuova versione corrisponde l’apertura di un progetto di
correlazione che prevede tra le altre delle attività di benestare. Dal momento che si
tratta di progetti strettamente collegati con lo sviluppo delle relative PNP, è stata
presa la decisione di affidare la gestione di questa tipologia di progetti direttamente
al Project Manager, che avrà la responsabilità di assicurare la consegna dei campioni
definitivi al Product Manager entro e non oltre la data richiesta.
Per quanto riguarda invece le Customer Customisations il discorso è leggermente
diverso. Si tratta infatti di tutti quei progetti che Selle Royal apre a partire da una
richiesta pervenuta dal cliente, che, come accade anche per le Internal Customisations,
implica delle attività di progettazione da parte dell’Ufficio Tecnico. Come è logico
immaginare il cliente non entra direttamente in contatto con il personale dell’Ufficio
Tecnico di Selle Royal, ma vi sono degli enti preposti ad interfacciarsi con il cliente
finale: il Customer Service e i commerciali/sales. Sono dunque questi ultimi ad
informare l’Ufficio Tecnico e gli altri membri coinvolti sulle caratteristiche grafiche
che il cliente desidera ottenere sul prodotto ordinato. Per questo tipo di progetti (che
rappresentano la maggior parte del lavoro quotidiano) il Customer Service o il
commerciale invia una richiesta al Project Controller, e quindi non più al Project
Manager, il quale ha il compito di controllare e filtrare le richieste del cliente (la
maggior parte delle richieste arriva da produttori di biciclette e capita molto spesso
che la stessa sella venga utilizzata in modelli di bicicletta diversi. Nel loro ordine di
acquisto tuttavia è comune che il medesimo codice prodotto finito sia presente su più
righe d’ordine e quindi il Project Controller deve essere in grado di raggruppare le
richieste che presentano le stesse specifiche) prima di poter aprire i progetti necessari
ad avviare lo sviluppo delle nuove versioni.
Questa nuova categorizzazione dei progetti di sviluppo nuovo prodotto, che prevede
appunto la distinzione tra richieste provenienti dal Product Manager e richieste
123
provenienti direttamente dal cliente (siano esse per l’apertura di PNP che di
“correlazioni”), e la successiva ridefinizione delle loro modalità di gestione, ha
permesso di aumentare il livello di pianificazione e monitoraggio dei progetti. Grazie
a questi interventi sia il Project Controller che il nuovo Project Manager si trovano
dunque nelle condizioni ottimali per riuscire a monitorare l’avanzamento del
progetto, dettando in maniera precisa le tempistiche di ciascuna attività, e ridurre
perciò l’incidenza dei ritardi.
Una volta formalizzate le nuove procedure è dunque fondamentale riuscire ad
automatizzare il più possibile questi flussi all’interno del nuovo software di project
management. Per far ciò sono state create all’interno del sistema delle queue topic
specifiche, a ciascuna delle quali è stata associata una precisa routing rule, in modo da
automatizzare perfettamente le procedure di emissione della richiesta. Le queue topic
corrispondono nel nostro caso alla categoria di progetto che si richiede di sviluppare,
mentre le routing rule identificano il flusso di destinazione che viene assegnato a
ciascuna categoria di queue topic. Di seguito, in figura 9.2, si riassume quanto è stato
configurato in AtTask, sulla base delle procedure analizzate, per la gestione della fase
iniziale di richiesta di sviluppo di un nuovo prodotto:
Auto-Routes to
Individual
Topics
Customer
Service/
Sales
Project
Manager
Custom
PNP
Auto-Routes
to Individual
Customer
Customisat
ions
Project Holding
Request Queue
BOM
Request
Request
Queue
Project
Internal
PNP
Master
Data
Auto-Routes
to Individual
Product
Manager
Internal
Customisat
ions
Figura 9.2 Rappresentazione dei flussi delle richieste per l’apertura di nuovi progetti
124
Project
Controller
Infine, oltre alla ridefinizione dei flussi delle richieste di apertura, un altro
importante passo compiuto per migliorare il processo in essere riguarda la presenza
di un momento ufficiale in cui il Product Manager espone ad un team di progetto,
composto dai membri del PMO, dal direttore dell’Ufficio Tecnico, dal Quality
Manager e dall’Operations Manager, le caratteristiche del prodotto che si desidera
sviluppare. Si tratta di un passaggio fondamentale in quanto ognuna di queste figure
può fornire un contributo basato sulla propria esperienza ed individuare, sin dalla
fase di apertura del progetto, eventuali criticità da prendere in considerazione in fase
di sviluppo del prodotto per minimizzare i problemi che tali criticità potrebbero
causare successivamente. Ovviamente durante questo incontro il Product Manager
ha anche il compito di sensibilizzare i vari enti sull’importanza strategica che il
prodotto può ricoprire per il successo del brand, in modo tale da condividere con
tutto il team le priorità dei diversi progetti che devono essere eseguiti. Con questo
meeting vengono dunque resi noti i principali obiettivi che si desiderano
raggiungere, ossia si cominciano a delineare i primi punti che descrivono il piano di
progetto. In questa fase, tuttavia, non si è ancora in grado né di impostare una
corretta pianificazione del progetto, in cui vengono individuate tutte le attività da
svolgere e i relativi responsabili, né di assegnare in maniera precisa e corretta le
risorse economiche di progetto. Pertanto il suddetto piano viene completato in tutta
la sua forma solamente al termine dello studio di fattibilità, quando si ha una
conoscenza più completa di come si deve procedere per sviluppare il prodotto
richiesto e del peso economico che esso comporta.
9.3.2
Categorizzazione dei progetti: portfolio e programmi
Un altro tema centrale su cui si è concentrata l’analisi preliminare per
l’implementazione di AtTask riguarda la modalità di gestione del portfolio di Selle
Royal. Uno degli obiettivi di AtTask, come visto, è infatti quello di riuscire a
diventare lo strumento ufficiale per la gestione dei progetti di Selle Royal S.p.A,
quindi di tutte le società di proprietà del gruppo come Selle Royal, Justek, Brooks e
Cranckbrothers. É dunque evidente che per poter gestire in maniera indipendente i
125
progetti di queste società sia necessario creare all’interno del software un portfolio
dedicato a ciascuna di esse. Il portfolio può essere infatti visto come un contenitore,
che raccoglie al suo interno tutti i progetti che sfruttano le medesime risorse e hanno
obiettivi simili, misurabili attraverso una scorecard comune. Grazie all’utilizzo del
Portfolio all’interno di AtTask i progetti non sono più visti come entità isolate
indipendenti l’una dall’altra, ma come assiemi coerenti e ben assortiti che
implementano una strategia di livello superiore, attingendo dallo stesso pool di
risorse, e che devono dunque essere gestiti in modo tale da massimizzare il risultato
per l’azienda. Tuttavia, visto l’inesperienza dell’azienda su certi temi, il board ha
ritenuto prematuro introdurre fin da subito i concetti della prioritizzazione dei
progetti e quindi dell’ottimizzazione del portfolio. Di conseguenza, quantomeno
finché non si sarà diffusa una certa confidenza sullo strumento, questa funzione del
portfolio in AtTask verrà sfruttata solo parzialmente come contenitore di tutti i
progetti eseguiti, come accadeva anche all’interno del Lotus Notes.
Oltre alla categorizzazione dei progetti per portfolio, AtTask garantisce un altro
livello di classificazione. Il portfolio può infatti essere ulteriormente scomposto in un
insieme di programmi. Il programma è essenzialmente un compartimento di progetti
all’interno del portfolio che condividono strategie di mercato e obiettivi comuni, che
in un certo senso trascendono i confini del portfolio. Per rispondere alle esigenze
incontrate in Selle Royal i programmi vengono utilizzati per raggruppare insieme i
modelli di selle appartenenti alla medesima famiglia di prodotto e che dunque
verranno progettati contemporaneamente per colpire un target di mercato ben
preciso. Infine un ultimo punto debole della categorizzazione dei progetti all’interno
del Lotus Notes era l’impossibilità di collegare le PNP 2 sviluppate alla PNP 1 di
riferimento con cui condividevano la parte strutturale della sella. L’introduzione di
AtTask ha dunque permesso di risolvere anche questo punto debole. All’interno di
ogni programma infatti si è creato un ulteriore raggruppamento che permette di
raccogliere insieme in un unico sottogruppo tutte le PNP sviluppate a partire dagli
stessi stampi d’iniezione. In questo modo diventa facile capire a primo impatto quali
sono i modelli che vanno ad ammortizzare i costi sostenuti per la creazione dello
stampo del feltro. Questa articolazione del portfolio permette dunque di avere
126
un’organizzazione chiara dei progetti, facilitando eventuali operazioni di analisi e di
ricerca.
9.3.3 Mappatura del processo di gestione sviluppo nuovo prodotto
Finora l’analisi si è concentrata esclusivamente sulla gestione delle procedure di
apertura dei nuovi progetti all’interno di AtTask e della descrizione di come essi
vengono organizzati all’interno del portfolio. È arrivato a questo punto il momento
di concentrarsi sull’analisi del flusso che viene quotidianamente seguito per
trasformare un’ idea iniziale in un prodotto finito vero e proprio, ossia nel cuore del
progetto. Quest’attività di mappatura del flusso è stata la parte più complicata e
dispendiosa di tutta la fase di preparazione; infatti non esisteva in azienda alcun
documento ufficiale che formalizzasse questo percorso.
In Selle Royal lo sviluppo di un nuovo prodotto è visto come un progetto a sé stante,
irripetibile e diverso da un qualsiasi altro progetto, in termini di tempi, costi, risorse
e costrizioni, e perciò meritevole di una gestione dedicata. In realtà, un’accurata
analisi ha permesso di mettere in evidenza come all’interno di questa affermazione ci
fosse un piccolo errore, che contraddiceva il concetto stesso di progetto. C’è
effettivamente un’unicità del progetto in termini di irripetibilità delle medesime
situazioni al contorno, che ne influenzano l’avanzamento, ma è anche vero che è
possibile identificare dei modelli di processo che possono essere quasi sempre
applicati al singolo progetto: questi modelli prendono il nome di template. Il template è
dunque il framework di un progetto, in cui sono stati assegnati a ciascun work package
dei responsabili e delle tempistiche stimate per portare a termine tale attività, nonché
dei vincoli di legame tra i vari tasks che compongono il processo. Questo strumento
consente di standardizzare le attività e catturare tutti i processi che si ripetono nel
tempo, in modo da massimizzare l’efficienza durante la pianificazione di progetti che
presuppongono attività tra loro molto simili.
Sono stati così individuati cinque template principali, corrispondenti ciascuno a una
specifica categoria di progetto, diversi l’uno dall’altro per la complessità delle attività
da eseguire e per il tempo necessario a sviluppare l’intero prodotto. Per creare questi
127
modelli di progetto si è partiti con l’analizzare il work flow di quella che era la
situazione attuale nel momento in cui è stata effettuata tale analisi. Una volta
ottenuto questo flusso sono stati individuati tutti i possibili punti di miglioramento
che potevano essere applicati fin da subito, andando quindi a ridisegnare il flusso
che si sarebbe voluto seguire nell’implementazione dei primi progetti che si
sarebbero gestiti con il nuovo software. Ma come è stata effettuata questa mappatura
e il successivo re-engineering del processo?
Per mappare l’intero processo di sviluppo si è sfruttato il metodo descritto da Steve
Spear in “High velocity edge” (2010), riadattandolo ovviamente alle specifiche esigenze
del contesto presenti in Selle Royal. Questo metodo presuppone che il punto di
partenza dell’analisi sia la definizione dell’output finale del sistema in questione, in
quanto secondo Spear questo è il punto più vicino al proprio cliente, dove è più
evidente cosa si deve fare per avere successo e soprattutto se si è effettivamente
riusciti ad ottenere il successo desiderato. Nel caso di Selle Royal il sistema è
rappresentato dalla parte dell’organizzazione che si occupa di tramutare possibili
idee in un prodotto finito e industrializzabile, mentre l’output non può che essere il
campione definitivo del prodotto che verrà fabbricato in grandi volumi. Si tratta
quindi dei campioni che i commerciali utilizzano per presentare la gamma ai propri
clienti durante le fiere che si svolgono nel corso dell’anno. Così facendo, oltre a
formalizzare il risultato finale del progetto, sono state rese note le tempistiche entro
cui questi campioni dovevano essere pronti, in funzione ovviamente del canale di
vendita a cui erano destinati (ogni canale di vendita ha infatti delle tempistiche
diverse dettate dal periodo in cui si svolgono le fiere). Una volta individuato il
risultato finale si è passati a disegnare step by step il percorso che porta a trasformare
una semplice idea in un prodotto finito, evidenziando inoltre i paralleli flussi di
informazioni e servizi. In questa fase perciò sono state mappate tutte le attività che
compongono il processo, specificando insieme al loro responsabile, la durata media
di tali attività e soprattutto gli input di cui ciascuno di loro aveva bisogno per poter
svolgere con la massima efficacia il proprio lavoro. Non si è trattato dunque di una
sterile analisi della situazione AS IS, ma si è anche cercato di individuare insieme ai
veri protagonisti del processo possibili miglioramenti da apportare nel flusso per far
128
sì che ciascuno di loro potesse lavorare nelle migliori condizioni, con tutte le
informazioni/materiali
disponibili
nel
momento
più
opportuno.
Uno
dei
miglioramenti che sono stati apportati fin da subito riguarda l’introduzione di alcuni
momenti formali di design review, ossia dei meeting da svolgere al termine di
ciascuna macrofase, secondo il principio dello Stage&Gate (alcune macrofasi sono la
definizione del prodotto, lo studio di fattibilità, l’attrezzaggio, la campionatura e i
test,…), per condividere quanto fatto e decidere se procedere alla fase successiva o
apportare delle ulteriori modifiche a seguito di eventuali problemi riscontrati. Questi
meeting, che rappresentano delle vere e proprie milestone all’interno del processo di
sviluppo, prendono il nome di P.A.C, acronimo che sta per Product Acceptance
Committee.
Il risultato di questa analisi si è dunque tramutato in un modello di processo
standard, come rappresentato in figura 9.2, dove sono state modificate le durate delle
singole attività per motivi di riservatezza.
129
130
Figura 9.2: Diagramma di Gantt per la rappresentazione del template standard per il processo di sviluppo di una sella (Fonte: “Materiale
interno aziendale”)
Ovviamente questo template non viene assegnato a tutti i progetti in maniera
meccanica, ma viene adattato di volta in volta a seconda di quanto le richieste che
pervengono dal Product Manager o dal cliente implicano delle attività diverse.
Nonostante lo sforzo che è stato sostenuto per formalizzare il work flow da seguire, è
necessario sottolineare che questo template non rimarrà sempre uguale nel tempo,
ma verrà migliorato di volta in volta secondo la filosofia del miglioramento continuo,
con l’obiettivo di ridurre il time-to-market attuale. L’ultimo punto importante da
sottolineare riguarda il fatto che questo flusso non è limitato allo stabilimento
italiano, ma è stato esteso ed adottato anche in Justek. Questo perché nello
stabilimento cinese producono dei prodotti con brand Selle Royal, per cui è
necessario pretendere i medesimi standard di qualità che ci sono qua in Italia, e per
raggiungerli si deve partire innanzitutto con un processo di sviluppo adeguato.
Come è stato specificato nel corso di questo paragrafo, i template ottenuti dalla
revisione dei processi attualmente adottati in Selle Royal rappresentano la base per la
pianificazione delle attività. Al termine dello studio di fattibilità, dopo aver
analizzato nel dettaglio le caratteristiche tecniche del prodotto e aver pertanto
individuato gli accorgimenti e le tecnologie da adottare nella sua fase di sviluppo, si
hanno tutti gli elementi necessari per portare a termine con successo la
programmazione delle attività, dei tempi e delle risorse umane da utilizzare: inizia
quindi il processo di pianificazione.
È in questa fase del processo che l’utilizzo dei template diventa particolarmente
rilevante, in quanto circa il 90% del processo da seguire per lo sviluppo di una nuova
sella è indipendente dalle specifiche richieste del singolo prodotto, e segue dunque
un modello “standard”. Una volta noti gli obiettivi operativi del progetto, a partire
da questi modelli, il PMO in collaborazione con il Product Developer, individua tutte
le attività che devono essere eseguite per garantire il successo del progetto,
assegnando a ciascuna di esse la risorsa interna o il fornitore esterno responsabile, e
le tempistiche entro cui esse devono essere completate. Ovviamente la durata delle
attività tende a variare rispetto a quella standard impostata nel template, a seconda
della complessità che la specifica richiesta può implicare. A questo punto, per
131
riuscire a calcolare la durata totale del progetto, e definire la schedulazione delle
singole attività elementari che lo compongono, si procede alla costruzione del
reticolo delle attività, ossia una rappresentazione grafica finalizzata a illustrare la
sequenza elementare della attività da svolgere, nonché le loro interdipendenze, per
riuscire a raggiungere gli obiettivi prefissati per il singolo progetto. Questa fase di
pianificazione ricopre oggi un’importanza centrale in quanto scandisce con
precisione le date in cui ciascuna persona deve iniziare e terminare le proprie attività
per riuscire a rispettare gli obiettivi definiti nel brief, e perché permette al Product
Developer di pensare la strategia migliore da adottare per riuscire a concludere con
successo il progetto. Da questa attività di pianificazione, che come detto sfrutta il
ricorso ai template, vista la ripetitività dei processi di sviluppo, si ottiene un
diagramma di Gantt molto dettagliato che descrive il piano di progetto. Tale
diagramma, che rappresenta una sintesi dell’intera fase di programmazione delle
attività, dei tempi e delle risorse da dedicare a ciascuna di esse, si presta dunque a
diventare la base per lo svolgimento delle attività, in quanto solo con la presenza di
un piano si può ottenere un feedback sullo stato di avanzamento del progetto per
quel che concerne il conseguimento degli obiettivi. Purtroppo però, non conoscendo
ancora il carico di lavoro che ciascuna attività richiede, si ricorre ancora oggi ad una
pianificazione a capacità infinita, con il conseguente rischio di sovraccaricare
inconsapevolmente
alcune
risorse
ed
avere
perciò
dei
naturali
ritardi
nell’avanzamento.
A questo punto, ultimato il piano di progetto, si è pronti per l’esecuzione vera e
propria, a cui grazie alla fase precedente di pianificazione potrà essere affiancata una
fase di controllo. Come si vedrà nel prossimo paragrafo, per svolgere al meglio
questo compito sono stati impostati degli appositi report, che permettono di
verificare
costantemente
lo
scostamento
tra
quanto
pianificato
e
quanto
effettivamente accade.
9.3.4 Definizione e configurazione dei reports
Come è stato evidenziato nel paragrafo dedicato alla analisi dei problemi riscontrati
in Selle Royal, da tempo si sentiva l’esigenza di distribuire dei report che
132
migliorassero la visibilità sui progetti in questione, in modo da rendere trasparente il
loro avanzamento e gli eventuali problemi riscontrati che ne rallentano o bloccano
l’esecuzione.
Prima di cominciare a configurare e utilizzare AtTask era necessario definire le
informazioni di cui ciascun team member necessitava per svolgere al meglio la
propria attività, o comunque per avere una panoramica generale sull’andamento
dell’intero progetto. Dato che questi report sono stati configurati prima che i vari
team member cominciassero ad utilizzare quotidianamente AtTask si è ritenuto
opportuno classificare inizialmente tali requisiti di reportistica sulla base del diverso
grado di apporto al progetto. Risultava infatti pressoché impossibile riuscire a creare
a priori dei report ad personam (prima dell’introduzione di AtTask non esisteva infatti
alcun sistema di distribuzione delle informazioni da cui poter attingere), anche e
soprattutto perché solamente dopo aver cominciato ad utilizzare AtTask con una
certa abitudine le persone sono in grado di capire quale tipo di informazione può
aiutarli nel loro lavoro quotidiano, per massimizzare l’efficacia nello svolgimento
delle loro attività. Per questo motivo si è deciso di partire con la realizzazione di
report standardizzati per le seguenti categorie di utilizzatori:
Executive;
Product Manager;
Project Manager.
Executive
Rientrano nella cerchia degli executives tutti gli stakeholders collegati con i progetti,
ossia coloro che non hanno un ruolo operativo, di completamento di un’attività per
lo sviluppo del nuovo prodotto, ma che hanno bisogno di una panoramica ad alto
livello per comprendere l’andamento dell’organizzazione nel suo complesso e
verificare il rispetto degli obiettivi stabiliti nella strategia aziendale. A tal proposito,
una funzione particolarmente interessante per questa categoria di stakeholder è
quella delle dashboard. “La dashboard è un sistema di misurazione e gestione delle
performance, ovvero un insieme integrato di indicatori o misure di prestazione
133
utilizzate per quantificare l’efficacia e l’efficienza delle azioni che consente di
prendere ben fondate decisioni attraverso l’interpretazione
di dati appropriati”
(Neely et al., 2002). In AtTask la dashboard è una pagina che raccoglie un insieme di
report diversi, offrendo un rapido accesso alle informazioni più importanti sia del
singolo progetto che dell’intero portfolio. Due esempi di report che sono stati
utilizzati per creare la dashboard fornita agli executives sono quelli rappresentati in
figura 9.3a e 9.3b. Il report di figura 9.3a riporta il numero di progetti sviluppati
all’interno di ciascun portfolio raggruppati sulla base del loro stato. In questo modo
per chi analizza questo grafico è immediatamente evidente il numero di progetti che
sono in via di sviluppo, che sono stati completati o che sono stati annullati in un certo
periodo di tempo. In figura 9.3b invece viene rappresentato il numero di progetti,
raggruppati
per
categoria,
che
vengono
sviluppati
per
ciascun
brand,
indipendentemente dal portfolio cui essi appartengono. Grazie a questa applicazione
è possibile tenere sotto controllo lo stato generale dei progetti, e soprattutto effettuare
delle analisi statistiche che permettano di mettere in luce dove è necessario
intervenire con maggior vigore per migliorare il processo di gestione adottato.
Figura 9.3a: Esempio di report inserito nella dashboard utilizzata dagli executives per la gestione del
portfolio (Fonte: “Materiale interno aziendale”)
134
Figura 9.3b: Esempio di report inserito nella dashboard utilizzata dagli executives per la gestione del
portfolio (Fonte: “Materiale interno aziendale”)
Product Manager e Project Manager
In questo secondo caso si tratta di report fondamentali per il monitoraggio
dell’avanzamento dei progetti nel tempo, per far sì che vengano rispettate le deadline
che vengono richieste nel brief. In realtà la reportistica creata per il Product Manager
si differenzia da quella destinata al Project Manager. Il primo, infatti, in quanto
responsabile del prodotto e della sua immissione all’interno del mercato, è
interessato a conoscere esclusivamente lo stato di quelle attività che danno come
output i campioni o il prodotto finito. Con questo report il Product Manager è
pertanto in grado di conoscere in qualsiasi momento se, secondo l’avanzamento del
progetto, riuscirà ad avere i campioni da presentare in tempo per le fiere che si
tengono durante l’anno, figura 9.4.
135
Figura 9.4: Esempio di report visualizzato dal Product Manager (Fonte: “Materiale interno
aziendale”)
Il Project Manager invece ha la responsabilità di seguir l’andamento dell’intero
progetto, evitando dunque che le attività terminino in ritardo causando uno
slittamento del progetto tale da impedire di soddisfare le richieste del Product
Manager. Per aiutarlo in questa attività di monitoraggio è stato creato un report
personalizzato che gli viene inviato automaticamente all’inizio di ogni settimana al
suo indirizzo di posta elettronica. In questo report sono indicate tutte le attività che
da pianificazione dovrebbero terminare entro quindici giorni dalla data di ricezione,
in modo tale da avvisare i responsabili dell’avvicinarsi della data ed eventualmente
dare una priorità maggiore a quelle attività che hanno una data di scadenza più
vicina.
L’efficacia della fase di controllo, supportata dalla presenza dei report, che
favoriscono una buona trasparenza e circolazione delle informazioni, è tuttavia
subordinata alla puntuale attività di pianificazione che viene svolta a monte. Ne
deriva perciò che l’utilità del processo di esecuzione e monitoraggio è strettamente
connesso con la qualità della pianificazione; per cui se quest’ultima presenta degli
136
errori il processo di controllo risulta inutile ai fini dell’individuazione e del recupero
di eventuali ritardi.
9.4 ESECUZIONE DEL TEST PILOTA (Pilot Test)
Una volta completata l’analisi dei business processes e configurato di conseguenza il
software sulla base delle esigenze evidenziate, il passo successivo nella roadmap
ideale prevede una fase di testing. Questo step ha la finalità di valutare non solo
quanto è stato configurato all’interno di AtTask, ma anche e soprattutto le nuove
procedure emerse durante la fase antecedente, in modo da identificare quali, tra le
soluzioni ipotizzate, possono funzionare, e quali invece richiedono un ulteriore
miglioramento e approfondimento (fine-tuning).
Per garantire la massima efficacia del test è fondamentale cercare di simulare il più
fedelmente possibile la situazione che ci si trova tipicamente ad affrontare nell’arco
di un progetto, cercando di concentrare ciò che per un progetto viene fatto
tipicamente nell’arco di un anno, in un’unica settimana. Il test pilota, e questa è senza
dubbio la sua grande finalità, permette così a tutti i team member di riprodurre un
tipico giorno di lavoro (day-in-life of walkthrough) e di capire come il nuovo software
può supportarli e aiutarli nella gestione delle loro attività quotidiane. Durante questa
settimana di prova a tutte le persone coinvolte nel processo viene affiancata una
figura interna specializzata nell’utilizzo di AtTask (AtTask Internal Trainer), con
l’obiettivo non solo di insegnare a ciascuno come utilizzare al meglio il nuovo
software, ma soprattutto con il fine di personalizzare le impostazioni e le funzioni di
AtTask a partire dalle specifiche richieste di ognuno. Così facendo si è riusciti a fare
in modo che AtTask non fosse visto solamente come un freddo strumento di
controllo dei progetti, ma piuttosto come un vero e proprio supporto nella gestione
individuale delle attività di chiunque lo utilizzasse.
Ovviamente per riuscire a testare l’ambiente del nuovo software e le nuove
procedure nel miglior modo possibile era assolutamente necessario trovare il
progetto più adeguato a soddisfare questi obiettivi. Come detto poco sopra era
necessario concentrare la fase di test in un arco temporale sufficientemente limitato,
137
in modo da velocizzare la diagnosi degli eventuali problemi di configurazione e
favorire una rapida implementazione dei cambiamenti necessari all’ottimizzazione
dell’environment di AtTask, per il suo successivo funzionamento a “pieno” regime.
Vista la decisione di cominciare ad utilizzare AtTask per la sola gestione delle PNP, il
test pilota è stato eseguito su una PNP 1, ossia sulla tipologia di progetti tipicamente
più lunga e complicata, che coinvolge, in misura diversa, almeno un responsabile per
ciascuna area aziendale, dal commerciale al controllo di gestione, passando per
l’ufficio tecnico e il reparto qualità. In particolare questa simulazione è stata
effettuata su un caso reale (che aveva al suo interno un certo grado di innovazione e
di problematicità), conclusosi proprio qualche settimana prima dell’inizio della fase
di test; la scelta è ricaduta su questo progetto, in primis, perché il ricordo di quanto
accaduto era ancora fresco tra le persone coinvolte, e ciò ne semplificava ovviamente
la simulazione, ed in secondo luogo perché, essendo stato un progetto abbastanza
complicato, dava la possibilità di testare in maniera pressoché trasversale tutte le
funzioni di AtTask che si era deciso di utilizzare sin dall’inizio. In questa settimana
l’Implementation team, che era stato creato fin dall’inizio del progetto di introduzione
del nuovo PMIS, si è dedicato all’esecuzione di questo test pilota per verificare
l’effettiva fattibilità delle procedure configurate, affiancati inoltre dall’Internal AtTask
trainer che aveva il compito di aiutare i protagonisti di ciascuna fase del processo a
capire come utilizzare AtTask a supporto delle procedure definite. Grazie all’apporto
di ognuno è stato perciò possibile testare quanto configurato, vale a dire:
I processi di richiesta di apertura del nuovo progetto, a seconda della tipologia
di prodotto che stava per essere sviluppato;
La correttezza del flusso di processo da seguire, compresa la forma degli input
per l’inizio di ciascuna delle attività e i percorsi di approvazione per poterla
considerare chiusa;
Descrizione e training su come AtTask supporta i team members nella
gestione delle issues incontrate nel corso del progetto;
Controllo dei report che erano stati pre-configurati e creazione di ulteriori
report sulla base delle specifiche informazioni che ognuno aveva bisogno di
monitorare
138
Una volta terminato il test pilota si è cominciato a gestire i nuovi progetti per la
gamma 2016 utilizzando AtTask e tutte le nuove procedure che fino ad allora erano
state ufficializzate e di cui abbiamo discusso nei paragrafi precedenti. Ovviamente
essendo questi i primi progetti completamente gestiti in AtTask non è ancora uno
strumento che funziona a pieno regime, ma si è ancora in una fase di studio e di
training per cercare di sfruttarlo al meglio.
139
140
CONCLUSIONI E FUTURI
SVILUPPI
L’esperienza di stage condotta per sei mesi all’interno di Selle Royal S.p.A. ha
permesso di prendere contatto con un’importante azienda leader mondiale nella
produzione di selle ed è risultata un’interessante opportunità per applicare in una
complessa realtà industriale alcuni aspetti del Project Management.
Questa tesi, attraverso l’applicazione pratica dei concetti noti in letteratura, ha
contribuito ad approfondire la conoscenza delle metodologie della gestione per
progetti e delle sue tecniche applicative. Interessante si è rivelato l’adattamento dei
principi e delle tecniche alla multiforme realtà aziendale in questione.
Il re-engineering delle procedure operative inerenti la gestione dei progetti di sviluppo
nuovo prodotto, e l’introduzione di un avanzato sistema di project management, ha
dato inizio ad un percorso di miglioramento finalizzato all’ottimizzazione di tali
processi. Nonostante non sia possibile toccare con mano tutti gli effetti dei
cambiamenti apportati (i primi progetti interamente gestiti secondo le nuove linee
guida sono appena partiti), è comunque realistico dedurre i potenziali vantaggi
derivanti da tale percorso, e soprattutto i futuri passaggi da eseguire per migliorare
ulteriormente.
Sicuramente il risultato più importante che è stato raggiunto è legato al tema della
pianificazione. Prima dell’inizio di questo percorso in Selle Royal, oltre a non esservi
una chiara suddivisione dei ruoli e dei compiti, mancava in modo pressoché assoluto
141
un’efficace pianificazione delle attività. Quest’ultimo punto, in particolare, impediva
di avere sotto controllo lo stato del singolo progetto, motivo per cui accadeva spesso
che le persone si trovavano a lavorare in tempi troppo stretti per riuscire a rispettare
le scadenze. Il fatto di aver definito un flusso di attività da seguire, ciascuna con una
precisa data di inizio e fine ed un preciso responsabile, fa sì che ognuno sia in grado
di eseguire il proprio compito nel momento migliore e con tutti gli elementi necessari
a disposizione. Perciò, grazie alla presenza di un preciso piano di progetto, le
persone non si trovano più a dover costantemente risolvere le urgenze dovute ai
ritardi maturati nei diversi progetti, ma ogni attività ha una sua puntuale
collocazione nel tempo che ne favorisce il tempestivo completamento. La migliore
consequenzialità delle attività, garantita da questa dettagliata pianificazione dei
progetti, permette infine di ridurre il time-to-market, obiettivo ulteriormente
migliorabile in futuro tramite la continua revisione del processo e della tecnologia
utilizzata, secondo la teoria del miglioramento continuo tipico del Lean Thinking.
Tuttavia, nonostante l’importanza di aver cominciato a pianificare i progetti, vi sono
ancora delle buone possibilità di miglioramento da questo punto di vista: la
pianificazione a capacità finita. Ad oggi, infatti, tale programmazione del lavoro
parte dal presupposto che si abbiano a disposizione delle risorse infinite per poter
completare il lavoro richiesto. Ovviamente questa premessa non rispecchia
propriamente quella che è la realtà di Selle Royal, che, come si è visto, dispone di un
numero abbastanza limitato di risorse all’interno dell’ufficio tecnico rispetto al
numero di progetti sviluppati ogni anno. Per questa ragione il prossimo obiettivo,
realizzabile anche grazie alla disponibilità di uno strumento in grado di supportare
questo tipo di funzionalità, è quello di pianificare lo svolgimento delle attività
tenendo in considerazione la disponibilità limitata di ore-uomo da dedicare
all’insieme dei tasks assegnati alla medesima risorsa. Tale risultato sarà tuttavia
raggiungibile solamente se verrà parallelamente gestita la prioritizzazione del
portfolio; solo in tal modo si potrà procedere in primis con lo sviluppo dei progetti
prioritari, fino a saturazione delle risorse, per poi passare ai progetti aventi priorità
più bassa. Il capacity planning e il portfolio optimization sono dunque i futuri obiettivi
142
da raggiungere per aumentare l’efficacia della gestione dei progetti all’interno di
Selle Royal.
Il progetto descritto in questo elaborato ha inoltre contribuito a diffondere la cultura
del project management alle aree aziendali interessate, in particolar modo alle risorse
dell’ufficio tecnico direttamente coinvolte, tramite formazione di base sui principi di
questo approccio; questo percorso trova perlopiù un forte appoggio da parte della
Direzione, che ha intrapreso il cammino per arrivare alla realizzazione di alcuni di
questi interventi. Vi è infatti piena consapevolezza dell’importanza centrale che
rivestono i progetti di sviluppo nuovo prodotto, conditio sine qua non il gruppo Selle
Royal non riuscirà più a soddisfare un mercato sempre più esigente ed altamente
competitivo, in termini di tempi, prezzi e qualità del prodotto finito. Questi tre
aspetti sono al centro della gestione per progetti.
Tramite l’analisi iniziale della letteratura e la successiva descrizione del caso di Selle
Royal è evidente come, per tutte le realtà organizzative che si muovono in un
mercato concorrenziale e si orientano sempre più alla qualità del servizio verso i
propri clienti interni o esterni, è indispensabile sviluppare una diffusa capacità di
raggiungere obiettivi prestabiliti in condizioni di uso efficiente di risorse. Pertanto,
nel contesto attuale di business, fatto di velocità e risparmio, il Project Management è
diventato una filosofia manageriale estremamente vincente, in quanto fornisce
concetti e best practices che permettono di adottare la strategia migliore per
raggiungere gli obiettivi prefissati al minor tempo e costo possibile. L’applicazione
della teoria del Project Management, basata sulle cinque fasi tipiche che costituiscono
il processo di gestione del progetto (avvio, pianificazione, monitoraggio e controllo,
esecuzione e infine chiusura) e sulle relative tecniche da adottare per ciascuna di esse
(Piano di progetto, Work Breakdown Structure, Diagramma di Gantt, Critical Path
Method, Gantt Cost Schedule, Earned Value,…), consente di colmare il gap esistente
tra l’elaborazione di un’idea e la sua successiva attuazione, permette di verificare la
sua concreta realizzabilità, ed infine mette a disposizione gli strumenti necessari per
analizzare e monitorare l’intero processo produttivo e correggere immediatamente
gli eventuali imprevisti.
143
I processi tipici del Project Management cui si è accennato poco sopra possono essere
supportati anche da un apposito software. L’analisi di questo elaborato ha dunque
dimostrato come, oltre ai principi elementari su cui si fonda la teoria, anche l’utilizzo
di strumenti adeguati, permetta di aumentare l’efficienza nella gestione dei progetti.
In particolare, lo studio del caso di Selle Royal S.p.A, ha evidenziato che l’utilizzo di
uno strumento web based, integrato tra i vari stabilimenti produttivi del Gruppo,
favorisce la gestione uniformata dei progetti intercompany, migliorando la
circolazione delle informazioni, riducendo pertanto i tempi persi nella ricerca delle
stesse ed aumentando il tempo dedicato alla effettiva esecuzione delle attività a
valore aggiunto.
Ne deriva che, in un mercato così complesso e variabile, grazie al dualismo esistente
tra processo e progetto e all’utilizzo di strumenti moderni, si ottiene un livello di
efficienza nella gestione dei progetti impossibile da ottenere altrimenti.
144
Bibliografia
Russel D. Archibald, “Project management. La gestione di progetti e programmi
complessi”, Franco Angeli, 2004.
E. Baglieri,
A. Biffi,
E. Coffetti,
C. Ondoli,
N. Pecchiari,
M. Pilati,
M. Poli,
M. Sampietro, “Organizzare e gestire progetti. Competenze per il Project
Management”, ed. ETAS, 2004.
Forti D., Masella F., “Lavorare per progetti”, Raffaello Cortina Editore, 2004.
Kerzner Harold, “Project Management. Pianificazione, scheduling e controllo dei
progetti”, Hoepli, 2005.
Project Management Institute, “A Guide to the Project Management Body of
Knowledge (PMBOK Guide)”, 2000.
Tonchia S., Nonino F., “La guida del Sole 24 Ore al Project management. Lo standard
internazionale di PM per gestire l'innovazione nei prodotti e nei servizi, le commesse,
i progetti di miglioramento”, Il sole 24 Ore, 2013.
Bruna Ferrarese, “Project Management. Impara a Gestire Efficacemente Tutte le Fasi
di un Progetto, dalla Pianificazione al Controllo”, Bruno editore, 2014.
Bove A., “Strategic Planning. Come definire, pianificare ed eseguire una strategia di
business vincente”, Hoepli, 2010.
Steve J. Spear, “The High-Velocity Edge: How Market Leaders Leverage Operational
Excellence to Beat the Competition”, McGraw-Hill, 2010.
Scott W. Ambler, “The Object Primer: Agile Model-Driven Development with UML
2.0, Cambridge University Press, 2004.
145
Sitografia
www.pmi.org
www.ipma.ch
www.apm.org.uk
www.selleroyal.com
www.justek.com
www.fizik.com
www.brooksengland.com
www.crankbrothers.com
http://www.bicycleretailer.com/north-america/2010/02/01/selle-royal-acquiresmajority-justek#.U0q7G6h_uSo
http://www.bike-eu.com/Home/General/2010/2/Selle-Royal-Gains-Access-toAsian-Industry--Markets--BIK003840W/
http://www.inc.com/encyclopedia/original-equipment-manufacturer-oem.html
http://www.disag.uniba.it/ALLEGATI/mat_dida/retail_MKT/trade_marketing_I.
pdf
www.attask.com
www.community.attask.com
146
