1
D
IPARTIMENTO DI
I
NGEGNERIA DELL
’E
NERGIA
,
DEI
S
ISTEMI
,
DEL
T
ERRITORIO E DELLE
C
OSTRUZIONI
RELAZIONE PER IL CONSEGUIMENTO DELLA
LAUREA MAGISTRALE IN INGEGNERIA GESTIONALE
IT Project Portfolio Management: un nuovo Sistema di
Gestione basato su Microsoft SharePoint.
Il caso Fabio Perini S.p.A.
RELATORE LA CANDIDATA
Prof. Dulmin Riccardo Sara Francioli
Dipartimento di Ingegneria dell’Energia, dei Sistemi, del Territorio e delle Costruzioni
Sessione di Laurea del 18/07/2018 Anno Accademico 2017/2018 Consultazione NON consentita
2
Indice
Sommario ... 4
Abstract ... 4
Indice delle figure ... 5
Indice delle tabelle ... 6
Capitolo 1: Introduzione... 6
1.1 L’esperienza di stage ... 6
1.2 Struttura della relazione... 7
Capitolo 2: Fondamenti teorici... 7
2.1 Importanza dell’IT per il Business ... 7
2.2 IT Service Management ... 10
2.2.1. ITIL v.3 Frame work ... 10
2.3 IT Demand Management... 13
2.4 IT Project Portfolio Management ... 15
Capitolo 3: Contesto operativo, il caso Fabio Perini S.p.A. ... 16
3.1 Struttura e organizzazione aziendale ... 16
3.2 IT: organizzazione e servizi ... 19
3.2.1. IT@Korber Organization ... 19
Capitolo 4: Lavoro di stage ... 21
4.1 Approccio impiegato ... 21
4.2 Define ... 25
4.2.1. Ambito e obiettivi del progetto (Project Charter) ... 25
4.2.2. Team di progetto ... 26
4.3 Measure ... 26
4.3.1. Raccolta dati ... 26
4.3.2. Analisi AS – IS di processo ... 33
4.4. Analyse ... 44
4.4.1. Individuazione dei punti critici ... 44
4.5. Improve ... 46
4.5.1. Benchmarking ... 46
4.5.2. Individuazione dei requirements informativi ... 53
Specifica del SI ... 70
Analisi costi-benefici e confronto fra diversi strumenti ... 70
4.5.3. Selezione strumento e tecnologia ... 71
3
4.6. Control ... 92
4.6.1. Change Assessment Template ... 93
4.6.2. Risultati e azioni correttive... 95
Risultati e sviluppi futuri ... 96
Conclusioni e ringraziamenti ... 97
Bibliografia ... 98
4
Sommario
In un contesto come quello in cui le aziende oggi si stanno muovendo, dove chi si occupa di ICT da un lato deve allinearsi velocemente ai mutamenti dei fabbisogni aziendali, e dall’altro garantire stabilità e performance soddisfacenti, è assolutamente necessario dotarsi di un modello di funzionamento atto a presidiare con metodi e strumenti strutturati l’assetto tecnico-organizzativo dei Sistemi Informativi.
Il presente elaborato, frutto di un’esperienza formativa e sperimentale svolta presso l’azienda Fabio Perini S.p.A., affronta la tematica dell’importanza di dotare le aziende di un modello di IT Governance atto a gestire i Sistemi Informativi mantenendo allineati obiettivi IT e di business, ispirandosi alle linee guida proposte dal frame work ITIL v.3, in particolare quelle riguardanti Demand Management e Change Management.
Lo studio, frutto dell’esperienza maturata all’interno del reparto Information Technology della sede di Lucca, è stato condotto secondo l’approccio Lean Six Sigma e si è concentrato sullo sviluppo di un Sistema di Gestione innovativo basato sul software Microsoft SharePoint, con l’obiettivo di ottimizzare l’attuale processo di IT Project Portfolio Management.
Abstract
In a context like the one in which companies are moving, where those involved in ICT have to quickly align with changes in corporate needs, and guarantee stability and good performances, it is absolutely necessary to have a structured operating model to manage Informatic Systems. This tesis project, result of a training and experimental experience performed in Fabio Perini S.p.A., concerns the importance of having an IT Governance model in order to manage Informatic Systems maintaining the aligniment of IT and business objectives. The project complies with ITIL v.3 frame work, in particular with Demand Management and Change Management.
The study focuses on the development of a new IT Management Systems based on Microsoft SharePoint, in order to optimize the as-is IT Project Portfolio Management process, according to Lean Six Sigma methodology.
5
Indice delle figure
Figura 1: Elementi che compongono un sistema di IT Governance (Fonte: www.mokabyte.it) ... 9
Figura 2: Struttura ITIL v. 3 (Fonte: www.seguetech.com) ... 11
Figura 3: Siti produttivi e filiali di vendita Fabio Perini nel mondo (Fonte: Presentazione FP Management Meeting) ... 17
Figura 4: Prodotti e principali tecnologie Fabio Perini (Fonte adattata da: Presentazione Aziendale FP) ... 18
Figura 5: Struttura IT@Korber ... 20
Figura 6: Organigramma area Finance Fabio Perini S.p.A. ... 21
Figura 7: DMAIC Cycle (Fonte: www.tqmi.com) ... 22
Figura 8: RACI Matrix ... 24
Figura 9: Matrice di Prioritizzazione (Fonte: presentazione Management Meeting FP) ... 35
Figura 10: Le 3 dimensioni della priorità (Fonte: presentazione Management Meeting FP) ... 37
Figura 11: Sovrapposizione Demand e Project Management ... 48
Figura 12: Fasi del processo di Change Management (Fonte: www.wikipedia.it) ... 50
Figura 13: Individuazione dei requirements per il nuovo Sistema Informativo ... 53
Figura 14: IT Project Charter ... 54
Figura 15: IT Request Form ... 56
Figura 16: RichIT - Menu principale ... 59
Figura 17: Maschera Gestione chiamata, “Base” ... 60
Figura 18: Esempio di report interno ... 61
Figura 19: Esempio di report cliente ... 62
Figura 20: Maschera Gestione chiamata - "Azioni" ... 62
Figura 21: Lista Chiamate per utente ... 63
Figura 22: Query di ricerca delle chiamate ... 64
Figura 23: Report Consuntivi ... 65
Figura 24: Esempio di diagramma BPMN 2.0 costruito con Nintex ... 73
Figura 25: Corrispondenza fasi del processo e stati della richiesta ... 76
Figura 26: Schermata generale "Richieste IT List" ... 77
Figura 27: Form di inserimento della richiesta IT ... 78
Figura 28: Funzione di salvataggio ... 79
Figura 29: Funzione di modifica ... 79
Figura 30: E-mail automatica generata da Nintex ... 80
Figura 31: Esempio di e-mail automatica generata da Nintex ... 81
Figura 32: Sezione "Solution Description" del Request Form ... 81
Figura 33: Esempio di e-mail generata da Nintex ... 82
Figura 34: Sezione Project Evaluation del Request Form ... 82
Figura 35: Sezione Project Execution del Request Form ... 83
Figura 36: Form di inserimento del Task ... 84
Figura 37: Richieste IT - Task List ... 85
Figura 38: Link per inserimento nuovo Task ... 86
Figura 39 Richieste IT - Tasks List ... 87
Figura 40: Richieste IT - Tasks List - Task Interno ... 87
Figura 41: Richieste IT - Consuntivi List ... 88
6
Figura 43: Richieste fittizie per fatturare i Task interni alle consociate ... 89
Figura 44: Estrazione Richieste IT List ... 90
Figura 45: Estrazione Richieste IT - Consuntivi List ... 91
Figura 46: Tabella Pivot per fatturazione ... 91
Figura 47: Tabella Pivot per valutazione andamento generale del processo ... 91
Figura 48: Modello ADKAR (Fonte: www.prosci.com) ... 93
Figura 49: Profilo ADKAR ... 95
Indice delle tabelle
Tabella 1: Processi ITIL ... 12Tabella 2: Riepilogo degli strumenti usati nel processo di gestione delle richieste IT ... 44
Tabella 3: Organizzazione reparto IT della BA UGG ... 47
Tabella 4: Processo To-Be ... 67
Tabella 5: Gestione Tradizionale e SharePoint a confronto ... 74
Capitolo 1: Introduzione
1.1 L’esperienza di stage
Il presente lavoro è frutto di uno stage che ho avuto l’opportunità di svolgere presso la sede Fabio Perini S.p.A. di Lucca, nel periodo che va da luglio 2017 a gennaio 2018.
Fin da subito ho potuto riscontrare la serietà dell’azienda attraverso: La presenza di un progetto formativo ben definito;
Una diretta e chiara comunicazione durante tutto il percorso formativo; Un ambiente di lavoro propositivo;
Una piena disponibilità a chiarire ogni mio dubbio e al confronto, da parte delle persone con cui ho collaborato;
La presenza di un tutor che ha partecipato attivamente al progetto e si è dimostrato sempre disponibile a convocare riunioni periodiche per valutarne lo stato di avanzamento;
La possibilità di interagire con persone di ogni livello e appartenenti a diverse aree aziendali;
Il coinvolgimento in iniziative aziendali, tra cui la possibilità di assistere alla presentazione della nuova linea di macchinari in occasione del MIAC 2017, la partecipazione ad un corso di formazione sulla sicurezza e ad un corso tecnico interno sul mondo del Converting.
7 Il progetto che ho seguito durante lo stage è stato dettato dalla volontà dell’azienda di migliorare il proprio Sistema di Gestione dei progetti IT, consapevole che oggi disporre di un buon modello di IT Governance costituisce un importante fattore critico di successo per le imprese, perché consente di trarre il massimo beneficio dagli investimenti in tecnologie informative e di mantenere un portafoglio di progetti IT coerente con gli obiettivi strategici aziendali.
1.2 Struttura della relazione
La relazione si suddivide in due parti. La prima è dedicata ai fondamenti teorici che sono alla base del progetto e tratta, in particolare, di IT Portfolio Management, IT Service Management e IT Demand Management.
La seconda, invece, riguarda più da vicino Fabio Perini S.p.A: dopo una prima parte di presentazione dell’azienda, il resto del documento si concentra su quanto svolto durante lo stage. La struttura della seconda parte segue un preciso ordine logico e riflette il metodo DMAIC adottato per gestire il progetto di miglioramento. Essa è suddivisa in capitoli corrispondenti alle diverse fasi del ciclo di problem solving appena menzionato; per ogni fase, vengono illustrati gli strumenti utilizzati, come è stata condotta l’analisi ed i risultati.
Capitolo 2: Fondamenti teorici
Il presente capitolo costituisce la base accademica per le successive analisi e discussioni.
Partendo con una descrizione iniziale per sottolineare l’importanza della connessione fra business e IT e alcuni dei frame work esistenti per impostare un modello di IT Governance a supporto della gestione dei Sistemi Informativi, la trattazione si sofferma poi sulla gestione dei portafogli di progetti IT, illustrando i principali metodi e modelli per la gestione dei portafogli.
2.1 Importanza dell’IT per il Business
Negli ultimi decenni stiamo assistendo alla graduale trasformazione dell’Infomation Technology in Fattore Critico di Successo per le imprese e propulsore del business. Gli investimenti in IT, infatti, impattano sulle modalità di gestione delle informazioni e sulla qualità delle stesse, ed è noto come questi due fattori siano determinanti per il raggiungimento degli obiettivi aziendali.
8 Il legame fra il mondo IT e il business risulta ancora più chiaro riferendosi più in generale al concetto di Gestione dei Sistemi Informativi. Quando si parla di investimenti in IT siamo portati erroneamente a pensare esclusivamente ad investimenti nel mantenimento delle attuali tecnologie o nello sviluppo/introduzione di nuove. Tuttavia il concetto di Sistema Informativo è più ampio e racchiude:
- Processi da attivare per gestire le informazioni; - Modalità organizzative legate ai processi; - Strumenti tecnologici a supporto dei processi.
Questi tre elementi devono essere progettati con attenzione per far sì che l’Information Technology apporti valore aggiunto alle imprese.
In un contesto generale in cui le imprese devono lottare per rimanere competitive, anche l’Information Technology, quindi, deve essere gestita in maniera consapevole ed i relativi processi ottimizzati, eliminando le inefficienze.
Secondo gli esperti del settore, infatti, le modifiche ai Sistemi Informativi non previste e mal gestite sono all’origine dell’80% dei problemi legati all’inefficienza dell’infrastruttura IT1. Senza un’analisi approfondita degli effetti delle variazioni sull’attuale infrastruttura, ci si rende vulnerabili a modifiche che possono avere un impatto fortemente negativo su tutto il sistema; senza pensare all’impegno delle risorse IT, che avrebbe potuto essere destinato a progetti a maggior valore aggiunto per il business.
Il Management deve, quindi, impegnarsi nella ricerca della giusta via per: - Favorire l’allineamento della strategia IT con quella del business; - Supportare il raggiungimento degli obiettivi aziendali;
- Garantire che le strutture organizzative facilitino il raggiungimento di tali obiettivi; - Trarre il massimo valore dagli investimenti in IT;
- Gestire i Sistemi Informativi pensando al loro intero Ciclo Vita. Per far questo, è necessario adottare un modello di IT Governance.
L‘IT Governance 2rappresenta quella parte della più ampia Corporate Governance che si occupa di gestire i Sistemi Informativi e di controllare e gestire costi e tecnologie affinché rispondano al meglio agli obiettivi di business dell’azienda.
1
IT Governance: stato dell’arte delle soluzioni CMDB, http://www.datamanager.it/news/mercato/it-governance-stato-dell-arte-delle-soluzioni-cmdb, 12/04/2010
9 Le cinque aree che caratterizzano un sistema di IT Governance sono:
- Allineamento strategico: assicurare che l'IT sia allineata con le strategie e le finalità di business dell'azienda;
- Erogazione del valore: assicurare che l'IT produca i benefici promessi (valore) rispetto agli obiettivi strategici, tenendo i relativi costi sotto controllo;
- Gestione delle risorse: assicurare che le risorse IT (applicazioni, informazioni, infrastruttura, risorse umane) siano usate in modo responsabile ed efficace;
- Gestione del rischio: assicurare che i rischi informatici siano opportunamente gestiti; - Misurazione delle performance: tracciare, gestire e controllare l'implementazione e le
prestazioni della strategia IT.
Figura 1: Elementi che compongono un sistema di IT Governance (Fonte: www.mokabyte.it)
Secondo un’indagine3 commissionata a NetConsulting che risale al 2008 circa la conoscenza, l’adozione e l’evoluzione prospettica da parte delle grandi organizzazioni italiane di strumenti afferenti al tema dell’IT Governance, emerge che non sono ancora stati fatti grandi investimenti nella Governance dei Sistemi Informativi. La diffusione di una cultura di Governance stenta ad affermarsi, in quanto il Top Management si dimostra poco ricettivo a queste tematiche e non le ritiene a priorità di investimento. Esiste una diffusa conoscenza della metodologia ITIL, ma essa non viene supportata in modo organico all’interno delle organizzazioni. I rischi derivanti dal
3 Indagine rivolta ad aziende e gruppi di grandi dimensioni; campione costituito dal 50% da realtà con più di 5000 dipendenti, 20,5% sotto i 1000 dipendenti, tra 1000 e 5000 30%. Ricerca rivolta a 44 casi provenienti da vari settori economici, interviste svolte nel corso del 2008 principalmente ai CIO. (www.datamanager.it)
10 sottovalutare l’importanza di questi strumenti, si traducono in una ridotta capacità di gestione e controllo delle risorse del Sistema Informativo e, quindi, in un debole governo dell’IT.
A supporto delle attività di gestione dei sistemi informativi sono nati e si sono diffusi molti sistemi di conoscenza strutturata e codificata, che di caso in caso hanno preso la forma di standard, raccolte di good practices o checklist/modelli di riferimento.
Nei prossimi paragrafi vengono presentati alcuni dei più importanti studi e frame work di riferimento per l’IT Governance.
2.2 IT Service Management
IT Service Management (ITSM) 4è una disciplina che si occupa della gestione dei Sistemi Informativi su larga scala, ponendo il focus sulla qualità del servizio percepita dal cliente e sul contributo dell'IT per il business, anziché sulla tecnologia.
L’ITSM non si occupa della definizione dei dettagli tecnici dei sistemi, bensì della schematizzazione di processi di riferimento per strutturare le attività del reparto IT, tenendo conto delle interazioni con gli utenti.
Il tema dell’ITSM è stato ampiamente trattato e attualmente esistono molti frame work di riferimento per questa disciplina, i quali possono essere seguiti dalle aziende per impostare il proprio modello di IT Governance: uno dei più noti è il frame work ITIL (Information Technology Infrastructure Library), che verrà presentato nel dettaglio nel prossimo paragrafo.
2.2.1. ITIL v.3 Frame work
ITIL è un insieme completo di indicazioni e di linee guida (“Best Practices5”), derivate dall’esperienza pratica degli esperti che le hanno elaborate, per organizzare ed erogare al meglio i Servizi Informativi, intesi come assets strategici.
4
IT Service Management, http://www.itil-italia.com/itsm.htm
5Le best practices sono modelli di conoscenza, i cui contenuti sono ottenuti a partire da esperienze significative e ricorrenti, concretamente "provate sul campo" da organizzazioni nell'ambito delle proprie
11 Sviluppato alla fine degli anni ’80 a cura dell’ente governativo OGC (Office of Governement Commerce), con la pubblicazione della v.2 nel 2001, ITIL è diventato lo standard de facto nell’ IT Service Management. Nel giugno 2007 è stata pubblicata la v.3 di ITIL, che, a differenza della precedente versione incentrata principalmente sui processi, si basa su un approccio globale al ciclo vita dei servizi (Service Lifecycle).
ITIL focalizza in generale l’attenzione sui seguenti punti fondamentali:
• Orientamento al servizio: l’organizzazione IT deve garantire al proprio “Cliente” servizi di elevata qualità e strettamente connessi con il business aziendale;
• Visione del “Ciclo di Vita” dei servizi: ogni servizio IT va seguito a partire dalle decisioni strategiche fino all’operatività, attraverso le fasi di progettazione, sviluppo e messa in funzione, considerando in ogni fase le esigenze per gli step successivi;
• Condivisione dell’esperienza: l’organizzazione IT deve tendere a migliorarsi attraverso la condivisione dell’esperienza di tutti;
• Misurazione delle performance: attraverso parametri di misura della qualità dei processi (KPI) si deve innescare un ciclo di miglioramento continuo;
• Utilizzo di strumenti di supporto: l’uso di adeguati strumenti informatici a supporto dei processi facilita il lavoro.
Il frame work ITIL v.3 è composto da 5 testi principali, ognuno corrispondente ad una fase del Service Lifecycle; a loro volta, ogni fase si suddivide in una serie di processi.
Figura 2: Struttura ITIL v. 3 (Fonte: www.seguetech.com)
attività di realizzazione di progetti ed erogazione di servizi IT. Queste esperienze sono state successivamente generalizzate e astratte, codificate in processi e arricchite di istruzioni operative, check list, schemi documentali (template) e altra documentazione complementare (esempi, use case, blueprint, ...)
12
Fase Descrizione Processi
Service Strategy Deployment della strategia aziendale sulla strategia IT
- Service Portfolio Management;
- Demand Management; - Financial Management.
Service Design Progettazione del servizio
- Service level Management; - Availability Management; - Capacity Management; - IT Service Continuity Management; - Information Security Management; - Service Catalogue Management; - Supplier Management. Service Transition
Erogazione del servizio e gestione della transizione da
sistemi vecchi a nuovi
- Service Asset and Configuration Management; - Change Management; - Release and Deployment Management; - Knowledge Management;
- Transition Planning and Support;
- Service Validation and Testing;
- Evaluation.
Service Operation Gestione ordinaria del servizio
- Incident Management; - Problem Management; - Event Management; - Access Management; - Request Fulfillment; - Service Desk; - Technical Management; - Applications Management; - IT Operations Management. Continual Service Improvement
Miglioramento continuo del servizio
- Service Reporting; - Service Measurement; - Service Improvement.
13
2.3 IT Demand Management
Preliminare e propedeutica alla gestione dei progetti, la raccolta e gestione delle richieste di servizi IT proveniente dagli utenti è un processo tanto delicato quanto vitale per fare della funzione IT un fattore di competitività.
La gestione del rapporto che, all’interno di una qualsiasi organizzazione, si instaura tra chi eroga i servizi informativi (IT) e chi ne fruisce (Utenti dei Sistemi Informativi) è un tema fondamentale se si intende far sì che il reparto IT contribuisca alla crescita e competitività dell’impresa.
Dalla qualità di questo rapporto, dal fatto, cioè, che si sviluppi nell’ambito di un’effettiva collaborazione tra le parti, dipende infatti la maggiore o minore capacità della funzione IT di assolvere al suo compito di sostegno e propulsore del business.
Se per l’IT Service Management esistono strumenti consolidati per la strutturazione dei modelli di gestione soprattutto grazie a best practices di riferimento, per quanto riguarda il Demand Management, il legame stretto con le situazioni specifiche dei processi di business non consente una facile standardizzazione per ogni situazione. Il Demand Management è, infatti, una caratteristica peculiare del processo di business. Tuttavia il frame work ITIL fornisce delle buone indicazioni da cui partire per strutturare il processo.
Il processo di Demand Management può essere definito come un processo strutturato che ha l’obiettivo di raccogliere, e se possibile anticipare, i fabbisogni informativi dei clienti interni dei reparti IT, di comprenderne le finalità e di valutarne le priorità. In aziende dotate di un’utenza interna vasta e differenziata, che genera un grande volume di richieste sempre più spesso riguardanti personalizzazioni, diventa inevitabile come processo a monte che vada ad alimentare l’altro processo chiave, l’IT Project Portfolio Management, indirizzato a gestire la funzione IT assegnando al meglio risorse e priorità.
IT Demand Management IT Project Portfolio Management Business Strategy
14 Nell’ambito del frame work ITIL v.3, il processo di Demand Management 6appartiene alla prima fase del Service Lifecycle, Service Strategy. Questo sta a significare che anche il processo di raccolta e analisi delle richieste è un processo chiave per garantire che l’IT supporti le strategie aziendali. In questo senso, il Demand Management ha il fine ultimo di razionalizzare ed ottimizzare l’impiego delle risorse IT, allocandole ai progetti a maggior valore aggiunto per l’impresa, ma anche di valutare l’utilizzo corrente dei sistemi da parte degli utenti e monitorare il loro grado di soddisfazione circa il servizio, in modo da anticipare i loro futuri fabbisogni.
Fattore critico di successo per il processo di Demand Management è sicuramente la scelta di un buon Demand Manager, figura professionale che costituisce il raccordo fra il mondo IT e il business. Anche in questo caso, la natura, le competenze e le conoscenze che il Demand Manager deve possedere dipendono molto dalla struttura organizzativa e dal business delle imprese, ma in generale queste sono le caratteristiche che dovrebbe possedere7:
- Leadership;
- Capacità di muoversi in ambiti poco strutturati e turbolenti; - Autorevolezza;
- Capacità relazionali;
- Ottima conoscenza sia del processo di business, sia dei processi IT.
Spesso il Demand Manager proviene dalle Direzioni ICT, dove ha maturato diverse esperienze progettuali che gli hanno permesso di acquisire una profonda conoscenza dei processi di business e si è occupato di Change Management; in altri casi, invece, è possibile che il Demand Manager provenga dalle linee di business; altre volte ancora, può essere un Key-User che diventa per attitudine il referente aziendale per un’intera area di processo (in questo caso i Demand Manager possono essere moteplici, fino a coprire tutte le aree).
Le principali attività di cui il Demand Manager è responsabile sono le seguenti: - Raccolta delle richieste provenienti dagli utenti dei sistemi;
6What is ITIL Demand Management?, http://www.bmcsoftware.it/guides/itil-demand-management.html 7
M, VANETTI, Demand Management: un ruolo in lenta evoluzione G, BELLANDI, Il Talento del leader
15 - Analisi della redditività dei progetti;
- Analisi del rischio e degli impatti dei progetti sul business; - Contributo alla pianificazione strategica.
2.4 IT Project Portfolio Management
Nel contesto generale appena descritto, i Portafogli8, ben noti strumenti di supporto per le decisioni in letteratura, si presentano come contenitori di elementi da gestire, i quali devono essere categorizzati in base ai parametri che guidano il processo decisionale.
Per cogliere a pieno le potenzialità del tool Portfolio, è necessario apprezzarne la natura dinamica: esso rappresenta, in un dato istante, il set di investimenti selezionati dal management con l’obiettivo di raggiungere determinati obiettivi di business. È necessario revisionarlo periodicamente, in modo da garantire che sia allineato con gli obiettivi strategici.
Il termine Portfolio, quindi, sottolinea l’esigenza di trovare un bilanciamento fra varie opportunità di investimento, in modo da apportare più valore possibile nel tempo all’organizzazione.
Per “IT Project Portfolio” si intende l’insieme di progetti IT che un’organizzazione gestisce in un periodo di tempo correlato al piano strategico aziendale.
Ciascun progetto presente nel portafoglio è quindi associato a specifici obiettivi di business e viene valutato in relazione al proprio contributo per il business aziendale.
La gestione del portafoglio (IT Project Portfolio Management) ha l’obiettivo di assicurare che la priorità dei singoli progetti venga periodicamente rivista al fine di allocare le risorse e gli investimenti in modo coerente ed in linea con gli obiettivi organizzativi e gli obiettivi strategici.
16
Capitolo 3: Contesto operativo, il caso Fabio Perini S.p.A.
3.1 Struttura e organizzazione aziendale
Fabio Perini S.p.A., azienda storica nel comparto produttivo del Tissue italiano, viene fondata nel 1966 come struttura a conduzione familiare e, in un arco temporale abbastanza ristretto, è diventata una struttura multinazionale gestita dalla Holding Koerber, con sede ad Amburgo, la quale opera in diverse Business Areas:
- BA Automation: sviluppa e produce nei campi della Motion, Sensor e Energy Technology;
- BA Logistics: offre ai propri clienti soluzioni logistiche flessibili;
- BA Medipak: offre soluzioni per la produzione, il test e il confezionamento di prodotti
farmaceutici;
- BA Tissue: sviluppa e produce macchinari per la produzione ed il confezionamento di
prodotti Tissue, offrendo soluzioni personalizzate e flessibili;
- BA Tobacco: offre ai clienti supporto e consulenza nel campo della lavorazione del
tabacco (filtri, sigarette e aromi);
- BA Machine Tools (UGG): si occupa della fornitura di attrezzature per le operazioni di
rettifica, finitura laser e verifica/collaudo.
Negli stessi anni si è verificata un’espansione in termini di struttura organizzativa: l’azienda è passata da una produzione su singolo stabilimento, ad una delocalizzata su più stabilimenti.
17
Figura 3: Siti produttivi e filiali di vendita Fabio Perini nel mondo (Fonte: Presentazione FP Management Meeting)
Oggi Fabio Perini S.p.A. vanta la presenza di numerose sedi nel mondo, suddivise in: Siti produttivi:
Fabio Perini S.p.A. – Lucca/Bologna (Italia); Fabio Perini Ltda. – Joinville (Brasile);
Fabio Perini North America - Green Bay (Stati Uniti); Körber Engineering Shanghai, Co Ltd. – Shanghai (Cina). Filiali di vendita ed erogazione di servizi:
Fabio Perini Germany GmbH – Germania; Fabio Perini Japan Co., Ltd. – Giappone; Fabio Perini UK – Inghilterra.
18 Focalizzandosi sul distretto italiano, l’azienda è presente sul mercato con due siti produttivi diversi:
Fabio Perini -Converting di Lucca; Fabio Perini KPL- Packaging di Bologna.
Figura 4: Prodotti e principali tecnologie Fabio Perini (Fonte adattata da: Presentazione Aziendale FP)
Le attività produttive realizzate dalle due società possono dirsi sequenziali lungo la catena logistica; infatti se il Converting si occupa di fornire macchinari per la trasformazione di bobine di carta semilavorate in prodotti finiti, il Packaging fornisce quelle relative all’imballaggio del prodotto finito. Le due aziende, seppur diverse per core business, sono molto simili per assetto organizzativo e per tipo e grado di informatizzazione. Dal 2015 entrano a far parte di un’unica società, “Fabio Perini S.p.A”.
La Engraving Solutions S.r.l., situata a Lucca, è l’ultima azienda che è stata acquisita da Fabio Perini S.p.A, anch’essa costituisce un'altra porzione della catena logistica. La sua attività si sovrappone a quella di Fabio Perini S.p.A per quanto riguarda la progettazione, test e produzione di rulli goffratori personalizzati secondo le esigenze dei vari clienti, i quali vengono poi installati sulle macchine Fabio Perini.
19 La vision aziendale consiste nel “porsi come leader nella fornitura di valore per i professionisti del Tissue, attraverso una continua innovazione, lo sviluppo dei talenti e l’eccellenza operativa, nel pieno rispetto dell’ambiente e della sicurezza”.
La mission, invece, è quella di “offrire un’innovazione che consenta ai clienti di migliorare qualsiasi aspetto della propria attività e la qualità della vita di tutti i giorni”.
3.2 IT: organizzazione e servizi
Il presente lavoro è stato realizzato in collaborazione con la Business Unit Information Technology, cuore dell’IT dell’intera BA Tissue.
Il reparto IT riporta sia al Management di Fabio Perini S.p.A., ma ha una forte identità globale a livello di gruppo Korber, infatti sono presenti due IT Manager: uno locale (IT Manager) e uno globale (IT Manager BA Tissue).
Di seguito, ci soffermeremo prima sulla descrizione dell’organizzazione IT a livello di gruppo Korber, per poi passare a quella locale a livello di gruppo Fabio Perini.
20
Figura 5: Struttura IT@Korber
Come è possibile notare dall’organigramma sopra riportato, ogni BA del gruppo Korber dispone di un BA IT Manager che, da un lato, riporta al management della BA, e dall’altro ad una figura trasversale a tutte le BA, ovvero il CIO.
Il CIO è una figura globale a livello di gruppo Korber, comune a tutte le aziende delle varie BA. In Fabio Perini S.p.A. non esiste un CIO a livello di gruppo FP.
IT@Korber è una struttura formata dal Corporate Center IT con a capo il CIO, Korber IT, Korber IT Solutions GmbH e i vari BA IT Teams.
Questa struttura denota una forte volontà, da parte del gruppo Korber, di standardizzare le procedure e dar vita ad una linea strategica IT comune per tutte le BA.
Secondo le Linee Guida 9erogate internamente dal CIO il 2/1/2017, i Team delle BA IT sono responsabili per le seguenti attività all’interno delle proprie BA:
- BA IT Demand Management; - BA IT Process Consulting;
- BA IT Project Portfolio Management;
- Pianificazione, implementazione, gestione operativa ed ottimizzazione delle applicazioni della Business Area;
- Applicazione della IT@Korber guideline e di ulteriori standard tra cui quello inerente alla “License Compliance” e alla “IT Security”.
9 Korber Corporate Guideline Information Technology
21 Il processo di IT Demand Management, secondo la Linee Guida, include la raccolta e la valutazione delle richieste provenienti da tutto il business, in modo da valutarle per decidere, in base alla coerenza con gli obiettivi strategici aziendali, se implementarle oppure no.
Il processo di IT Project Portfolio Management, invece, riguarda l’inclusione dei requirements pianificati nel Piano allo stato attuale, secondo i criteri di rilevanza strategica, economicità e rischio. Le Linee Guida affermano che solo i progetti in accordo con le linee strategiche aziendali possono essere implementati. La gestione del Project Portfolio permette di ottimizzare l’allocazione delle risorse a disposizione, con l’obiettivo di supportare i progetti che contribuiscono maggiormente a raggiungere gli obiettivi strategici aziendali.
Passando alla descrizione della struttura di Fabio Perini S.p.A (Lucca-Bologna), il reparto IT riporta al CFO:
Figura 6: Organigramma area Finance Fabio Perini S.p.A.
Capitolo 4: Lavoro di stage
4.1 Approccio impiegato
Come metodologia per il miglioramento dei processi da adottare per lo svolgimento del progetto, l’azienda ha proposto l’adozione dell’approccio Lean Six Sigma, declinabile a livello operativo nella
22 metodologia di problem solving DMAIC10, di cui sono elencati di seguito i passi ed una loro breve spiegazione:
- Define: identificazione del problema, definizione dello scope del progetto e degli
obiettivi ad esso collegati;
- Measure: raccolta dati e descrizione dello stato attuale dei processi;
- Analyse: analisi dei dati raccolti, individuazione dei problemi e ricerca delle cause
scatenanti;
- Improve: progettazione dell’iniziativa di miglioramento;
- Control: elaborazione di un Piano di Monitoraggio del nuovo processo, monitoraggio
del nuovo processo ed eventuale proposta di azioni correttive.
Figura 7: DMAIC Cycle (Fonte: www.tqmi.com)
Di seguito viene riportato il quadro d’insieme delle attività svolte durante il progetto, ricorrendo ad una matrice RACI11 in modo da definire in modo chiaro compiti e responsabilità dei soggetti coinvolti nella sua realizzazione. Le righe riportano le attività realizzate in ordine cronologico, mentre le colonne i soggetti coinvolti nel progetto. In corrispondenza dei vari incroci abbiamo il livello di responsabilità che lega il soggetto ad una specifica attività.
I livelli di responsabilità utilizzati sono i seguenti:
R: RESPONSIBLE (esecutore dell’attività);
10
A. LUCI, DMAIC: la metodologia di Problem Solving più conosciuta, http://www.qualitiamo.com/approfondimento/dmaic-six-sigma.html 11 Matrice delle responsabilità
23
A: ACCOUNTABLE (responsabile ed approvatore); C: CONSULTED (collaboratore);
I: INFORMED (soggetto che deve essere informato sull’attività svolta).
IT MANAGER BA TISSUE AUTORE SAP CONSULTANT WEB DEVELOPER UTENTI Elaborazione Project Charter A R I I I Analisi documentazione interna A C R C C C
Interviste rivolte agli
stakeholders A C R C C C Formalizzazione VOC A R I I I Mappatura processo AS-IS A R I I I Elaborazione Tabella Strumenti/Sistemi A R I I I Riunione iniziale R A C C C C Elaborazione tabella punti critici A C R C C C I M EA SU R E A N A LY SE D EF IN E Definizione del problema R A C I I
24
Figura 8: RACI Matrix
IT MANAGER BA TISSUE AUTORE SAP CONSULTANT WEB DEVELOPER UTENTE Benchmarking BA - UGG A C R I I I Benchmarking framework ITIL v.3 A C R I I I Analisi strumento "Project Charter" A C R I I I Analisi strumento "Request Form" A C R I I I Analisi sistema "RichIT - ITAMS" A R C I I Elaborazione Requirements List A C R C C C Mappatura processo TO-BE A C R C C C Sviluppo prototipo su Excel A C R I I I Analisi costi/benefici e selezione strumento migliore A R C C I Workshop su SharePoint e Nintex I C I R I Sviluppo prototipo su SharePoint A C I R I Elaborazione procedura operativa A R I C I Elaborazione documentazione tecnica A C I R I Presentazione e seduta di training per gli stakeholders
A I C I R I Test C C C R C Riunione per rilevazione criticità A C C C R C ADKAR Self-Assessment A R C C C Elaborazione profilo ADKAR A R I I I Predisposizione misure correttive A R I I I C O N TR O L IM P R O V E
25
4.2 Define
4.2.1. Ambito e obiettivi del progetto (Project Charter)
4.2.1.1.Definizione del problema
La struttura IT gestisce un numero crescente di sistemi e applicazioni ed ha molti nuovi progetti in sviluppo ogni anno. In questo contesto, caratterizzato da crescente complessità, non solo tecnologica, le risorse IT si trovano a dover gestire decine e decine di Richieste Utente non pianificate, speso afferenti a bisogni dei singoli, senza un vero e proprio indirizzo strategico, o con un obiettivo non coerente con l’indirizzo strategico generale seguito dall’azienda.
I rischi della situazione attuale sono schematizzabili come segue:
- Tempo delle risorse IT speso sempre più su micro – richieste (riunioni, chiarimenti, analisi …);
- Riduzione della capacità disponibile per supportare i progetti di sviluppo e l’innovazione;
- Perdita del contributo strategico dell’IT Project Portfolio.
4.2.1.2. Obiettivi
L’obiettivo dell’intervento di miglioramento è quello di identificare una procedura di IT Project Portfolio Management tale da:
Alimentare in modo efficace ed efficiente il Korber Project Portfolio; Gestire tutte le richieste di modifica world wide ai sistemi IT;
Distinguere le richieste a valore aggiunto da quelle non a valore aggiunto; Definire la priorità per le richieste a valore aggiunto;
Schedulare le attività del reparto IT;
26 4.2.1.3. Business Case
L’attuale Sistema di Gestione comporta il rischio di investimenti di tempo e denaro in attività non a valore aggiunto. Ottimizzando il Sistema attuale sarà possibile eliminare gli sprechi e garantire un IT Project Portfolio in linea con gli obiettivi strategici aziendali.
4.2.1.4. Ring In
Ottimizzazione del processo di “IT Development”: il focus di progetto riguarda la gestione delle richieste di modifica e dei progetti sul sistema SAP.
4.2.1.5. Ring Out
Ottimizzazione del processo di “IT Operation” (mantenimento delle infrastrutture, help desk): per queste attività è in atto un progetto più ampio, voluto dalla Korber.
4.2.2. Team di progetto
Il Team che ha lavorato al presente progetto è un Team interfunzionale, composto sia da risorse IT, sia da utenti, in modo da mantenere una duplice prospettiva durante l’intero svolgimento del lavoro.
4.3 Measure
4.3.1. Raccolta dati
Ci sono due principali definizioni del risultato del processo di raccolta dati12: dati primari e dati secondari. I dati primari riguardano tutto il materiale che è stato raccolto per uno scopo preciso, mentre i dati secondari si riferiscono a materiale collezionato da terzi e riutilizzato dai soggetti responsabili della raccolta.
Il processo di raccolta dati, ai fini del presente lavoro, è durato da luglio a settembre ed è servito da input per l’analisi AS-IS (comprensione del background, delle dinamiche interne ed esterne all’ufficio IT circa il processo di gestione delle richieste IT, delle procedure di lavoro, degli strumenti impiegati e delle esigenze di tutti gli stakeholders coinvolti nel processo).
27 Gli strumenti utilizzati per archiviare i dati sono stati Excel e Word; infine, sono stati salvati anche nella raccolta documenti dedicata al progetto nell’area “Finance Information Technology” sulla Intranet aziendale (Microsoft SharePoint).
In questo caso, i dati primari sono stati raccolti mediante interviste ai soggetti partecipanti al processo, atte a raccogliere la VOC13.
Quelli secondari, invece, consistono in documenti interni di vario tipo, forniti dal Tutor aziendale e reperiti autonomamente dall’archivio su SharePoint, che sono stati rielaborati.
4.3.1.1.Analisi di documentazione interna
Durante lo stage ho potuto analizzare vari documenti interni per inquadrare la struttura organizzativa ed i processi e per capire se ci sono stati dei tentativi di miglioramento circa l’area di ricerca interessata.
Già nel 2016, durante un Management Meeting, erano state evidenziate varie problematiche inerenti alla struttura IT, la quale si è trovata negli ultimi tempi a dover gestire un numero crescente di sistemi ed applicazioni, frutto di grandi progetti di sviluppo, e al tempo stesso a dover gestire decine e decine di richieste utente. Questo contesto caratterizzato da una complessità tecnologica crescente, ha comportato la necessità di rivedere il modo di lavorare del reparto IT. I rischi della situazione attuale, infatti, sono la riduzione della capacità disponibile per supportare progetti di sviluppo innovativi e ad alto valore aggiunto e l’eccessiva focalizzazione delle risorse IT su attività operative e di manutenzione. (Technology Trap).
Il reparto IT con sede a Lucca è suddiviso in due aree:
- IT Maintenance & Operation: si occupa della gestione dell’infrastruttura IT hardware e
software;
- IT Project Management: i Project Manager sono consulenti SAP che si occupano di
gestire progetti di varia natura riguardanti il sistema informativo aziendale (modifiche, aggiornamenti, implementazioni di nuovi moduli). Tali progetti possono rispondere ad iniziative locali, oppure possono essere multi-company. Oltre a progetti spot, i consulenti si occupano anche della manutenzione del sistema informativo.
13
“Voice of Customer”: è un termine usato per descrivere il processo di acquisizione dei dati inerenti le aspettative, i bisogni e le lamentele dei clienti. È uno strumento, in ottica Lean, necessario a garantire che i miglioramenti di processo vengano portati avanti nel rispetto dei bisogni della clientela.
28 I servizi erogati dal reparto IT sono gratuiti se rivolti ai reparti delle sedi di Lucca e Bologna, a pagamento per tutte le altre consociate.
I consulenti SAP sono 5 e così suddivisi: - Consulente modulo SD e CRM; - Consulente moduli FI-CO-HR; - Consulente moduli PP-PS-QS-MM; - Sviluppatore ABAP14;
- Responsabile autorizzazioni SAP.
Le figure presentate lavorano a stretto contatto e sono fra di loro complementari.
I consulenti funzionali SAP sono professionisti che, analizzati i flussi e i processi aziendali, intervengono nel customizzare il sistema sulla base delle richieste del cliente, lavorando e modificando le funzionalità dei singoli moduli rimanendo, però, all’interno del ventaglio di personalizzazioni possibili offerto da SAP. Sono anche definiti “analisti-funzionali” poiché analizzano le esigenze dei clienti prima di proporre la soluzione a sistema più indicata.
Il Programmatore ABAP è, invece, un profilo informatico puro che lavora sul linguaggio nativo dell’ambiente SAP, definito appunto ABAP. Questo profilo si interfaccia spesso con i consulenti funzionali, dai quali riceve le indicazioni per le modifiche del sistema. Con l’intervento su linguaggio, il programmatore ABAP crea funzionalità del sistema ancora più personalizzate come, ad esempio, la predisposizione di report e transazioni custom.
All’interno dell’azienda, le richieste di modifica ai sistemi IT vengono raccolte con continuità durante tutto l’esercizio, sia durante il periodo di raccolta delle richieste Capex15 che oltre. Ogni anno, infatti, si cerca di stilare un elenco degli investimenti da effettuare l’anno successivo, suddividendoli per funzione aziendale di provenienza e stimandone valore strategico ed impatto economico. Quest’operazione aiuta il management a pianificare le attività e ad allocare le risorse necessarie ai progetti.
14
ABAP è l’acronimo di “Advanced Business Application Programming”.
15 Il termine CapEx si riferisce ai fondi che un’azienda utilizza per acquistare prodotti o servizi volti a migliorare la sua capacità di generare i profitti. Gli elementi costitutivi del CapEx variano da settore a settore e da azienda ad azienda, ma per quanto riguarda l’IT possono essere rappresentati da un nuovo laptop, una nuova stampante, nuove applicazioni, un nuovo server o l’infrastruttura di rete collegata.
29 Il problema, però, è che l’anno successivo solo una parte del tempo delle risorse IT risulterà poi effettivamente dedicato alle richieste Capex; durante il corso dell’anno, infatti, il reparto IT continua a ricevere decine e decine di richieste che vengono portate avanti senza un’opportuna valutazione costi/benefici e che si sovrappongono ai progetti stabiliti l’anno precedente, comportando notevoli sforzi per ripianificare le attività.
Allo stato attuale delle cose, il processo di raccolta delle richieste non viene gestito in maniera efficace, in quanto viene speso tempo su attività delle quali non vengono valutati l’impatto e la coerenza con il piano strategico aziendale.
Nel corso degli anni sono stati fatti degli sforzi volti a formalizzare il processo e a sviluppare un sistema di gestione efficace.
- Piattaforma SharePoint (progetto S@Perini): Microsoft SharePoint è una piattaforma
software di Content Management System (CMS)16 sviluppata da Microsoft, ovvero un programma che girando lato server permette la creazione e distribuzione di particolari siti web principalmente ad uso aziendale (Intranet), ma che possono anche essere distribuiti in rete e quindi essere utilizzati come normali siti web. Il progetto S@Perini ha portato alla realizzazione di una piattaforma SharePoint di gestione delle richieste IT, utilizzata dagli utenti per inoltrarle ai consulenti. La piattaforma, però, non è mai stata utilizzata dai consulenti per gestire le attività operative.
- Gestione con modulo Excel, “Richieste – IT”: modulo in formato Excel che doveva essere
compilato a 4 mani (consulente e richiedente) per chiarire la problematica alla base della richiesta e sviluppare una soluzione congiunta.
- Gestione con applicazione RichIT/ITAMS: database centralizzato ad uso solo interno IT
per la gestione delle richieste.
16
In informatica un Content Management System, in acronimo CMS (sistema di gestione dei contenuti), è uno strumento software, installato su un server web, il cui compito è facilitare la gestione dei contenuti di siti web, svincolando il webmaster da conoscenze tecniche specifiche di programmazione Web.
30 4.3.1.2. Interviste
Tutte le interviste realizzate sono definibili come semi-strutturate17, un compromesso tra un’intervista strutturata e un’intervista libera. Si definiscono tali proprio perché sono state individuate a monte le aree da esplorare, ma gli intervistati sono stati lasciati liberi di procedere secondo l’ordine e le modalità preferite, seguendo il flusso della discussione. Al suo interno si coniugano pianificazione e flessibilità e si alternano momenti di domande prefissate a momenti dipendenti dai singoli interlocutori.
Un’intervista semi-strutturata è una conversazione provocata dall’intervistatore, rivolta a soggetti scelti in base ad un piano di rilevazione e in numero consistente, avente finalità di tipo conoscitivo, guidata sulla base di uno schema flessibile e non standardizzato di interrogazione18. Una prima analisi della documentazione interna è stata propedeutica alla preparazione delle domande riguardo ai punti da affrontare durante i colloqui.
In generale, i punti da cui partire e su cui è stato ritenuto rilevante soffermarsi sono i seguenti: - Ricostruzione del processo attuale di gestione delle richieste in termini di soggetti
partecipanti, attività e strumenti di supporto impiegati: questo ha consentito l’elaborazione della Mappa di Processo AS-IS e della Tabella degli strumenti usati;
- Rilevazione dei punti critici del processo e delle potenziali aree di miglioramento: questo ha consentito di formalizzare in una tabella le esigenze degli stakeholders.
17
Un primo criterio con il quale categorizzare le interviste è il grado di strutturazione. Ogni intervista può essere collocata lungo un continuum che va da un massimo grado di “non strutturazione” a un massimo grado di “strutturazione”, con un punto intermedio di “semi-strutturazione”; la distinzione avviene in base alla pianificazione, direttività, comunicazione, flessibilità, ai tempi e alla standardizzazione.
31 I risultati delle interviste sono di seguito schematizzati e formalizzati in due tabelle, distinguendo i soggetti intervistati in base alla propria posizione rispetto al processo in analisi:
REPARTO IT
Ruolo VOC
IT Specialist
“ E’ molto complicato rispettare una determinata data di consegna, perché arriva una mole esagerata di richieste e ognuna, a detta dell’utente, è urgente”
“Per molte richieste, in base alla provenienza e al richiedente, non viene effettuata un’imparziale analisi di profittabilità per decidere se rilasciare l’autorizzazione”
“Con l’attuale Sistema di Gestione è impossibile assegnare un Ticket alle richieste; esse arrivano per e-mail, per telefono ed è difficile sapere cosa arriva prima e cosa dopo”
“L’utente non accetta che la priorità che egli attribuisce alla propria richiesta venga rivista in base alle esigenze di IT”
“Le richieste non vengono gestite tutte allo stesso modo”
“Gli utenti inviano richieste a dismisura, anche per bisogni personali e non
rilevanti per l’azienda”
“Troppi sistemi diversi da usare per gestire le richieste, ciò comporta una gestione non efficiente”
“Gli utenti, spesso, propongono già soluzioni al reparto IT, anziché discutere con loro per individuare la soluzione migliore (rapporto costi/benefici) per risolvere i problemi”
IT Manager
“Tempo sempre più dedicato a micro - richieste (riunioni, chiarimenti), piuttosto che ai progetti in sviluppo”
“Ci sono problemi di fondo di cultura aziendale: il personale è, spesso, restio a seguire le procedure, cercando la strada più facile e veloce”
“Gli IT Specialists prendono spesso in carico attività in modo nascosto, senza tracciarle in modo rigoroso; questo comporta una pianificazione non in linea con i reali impegni di ogni risorsa e un, costante, mancato rispetto dei piani”
32
“Gli IT Specialists non consuntivano in modo regolare le ore lavorate sui vari progetti, ma solo in occasione della scadenza della fatturazione19”
“L’attuale gestione comporta la perdita del contributo strategico del portafoglio progetti IT”
“Spesso, soprattutto per i grandi progetti, manca una chiara attribuzione formale delle responsabilità”
“Il ruolo del Key-User è un ruolo fondamentale che non viene opportunamente riconosciuto ed incentivato; potrebbe snellire il lavoro delle risorse IT, formalizzando le richieste per la propria area di competenza ed occupandosi di fare formazione ai propri utenti, ma ad oggi queste attività non sono svolte con costanza da tutti i Key-Users aziendali”
UTENTI
Ruolo VOC
Utente generico
“Dal momento che IT prende in carico una richiesta, non è più possibile avere informazioni al riguardo, perché viene gestita su sistemi interni, ai quali l’utente non può accedere”
“Si perde il controllo sullo stato di avanzamento dei progetti”
“IT, spesso, non fornisce una spiegazione circa l’allungarsi dei tempi di consegna” “La gestione attraverso e-mail e telefono spesso non è efficiente; le risorse IT impiegano troppo tempo nel rispondere”
Key-User20
“Il ruolo del Key-User non è correttamente riconosciuto ed incentivato e nessuno è più motivato a ricoprirlo; si deve occupare di raccogliere le richieste, analizzarle e formalizzarle in modo da renderle chiare per l’IT, infine deve occuparsi di fare formazione all’utente; ma questo lavoro si somma al lavoro quotidiano in qualità di utente generico SAP, quindi non è umanamente possibile sostenerli entrambi”
19
Secondo quanto previsto da procedura aziendale, i servizi erogati dalle risorse IT vengono fatturati alle consociate (FP Nord America, FP China, FP Brasile) secondo un costo giornaliero/risorsa (480€/gg), e la fatturazione viene erogata a trimestre; la fatturazione non è prevista per il gruppo Fabio Perini S.p.A (Lucca, Bologna, Engraving Solutions).
20
Il Key User SAP è un utente esperto , con buone competenze sia dei processi aziendali, sia del sistema informativo. È la figura interna all’azienda che viene scelta per affiancare il team di consulenti informatici SAP nel momento dell’implementazione del sistema informativo e in caso di modifiche o aggiornamenti al sistema. In Fabio Perini S.p.A. è presente un Key User per ogni area aziendale.
33
4.3.2. Analisi AS – IS di processo
L’analisi della documentazione interna e le interviste svolte hanno consentito di analizzare il processo e di ricavare una mappa di processo, una descrizione dettagliata delle varie fasi e una panoramica dei vari strumenti e sistemi usati attualmente per gestire il processo, con informazioni circa il relativo stato di utilizzo.
Le macro-fasi del processo di gestione delle richieste sono le seguenti:
1) RACCOLTA DELLE RICHIESTE
Fatta eccezione per le richieste Capex, tutte le altre arrivano dagli utenti in ogni momento dell’anno direttamente ai consulenti IT, con una descrizione sommaria del problema e la soluzione desiderata.
Gi utenti inviano le proprie richieste via e-mail, per telefono oppure, saltuariamente, servendosi della piattaforma appositamente creata su SharePoint.
I consulenti IT sono spesso costretti a richiedere chiarimenti agli utenti, a volte convocando riunioni, in quanto essi nella maggior parte dei casi propongono già soluzioni, senza spiegare bene la problematica di fondo che li ha spinti a richiedere il loro intervento.
I punti critici emersi sono i seguenti:
Le richieste arrivano attraverso molti canali diversi; aumentando la complessità degli strumenti da gestire, aumenta la possibilità di compiere errori, perdere informazioni importanti ed incorrere in inefficienze;
È difficile capire quali richieste siano arrivate prima di altre ed assegnare loro un ticket;
Il formato libero con cui arrivano le richieste fa sì che esse siano spesso confuse o incomplete. Ciò comporta la necessità di dedicare altro tempo per chiarire la questione con l’utente;
Il metodo attuale di raccolta delle richieste non permette di accorpare richieste simili, di presentarle in modo chiaro e di analizzarle;
34 Spesso, non c’è nessuna analisi da parte degli utenti dietro alle richieste proposte;
Spesso gli utenti propongono già soluzioni, dimostrando di non avere chiara la problematica che si intende risolvere.
2) ANALISI E CLASSIFICAZIONE DELLE RICHIESTE
Dopo aver chiarito la questione con l’utente, IT Specialist analizza nel dettaglio la richiesta e, dopo aver determinato se è fattibile, stila un elenco di attività da fare indicando le relative risorse da allocare.
Le richieste fattibili vengono suddivise in due categorie:
- Job: richieste con durata stimata di evasione inferiore a 2 giorni;
- Project: richieste con durata stimata di evasione superiore a 2 giorni.
Mentre i primi passano direttamente alla fase di pianificazione, i secondi, essendo più onerosi, vengono analizzati più dettagliatamente nella fase successiva del processo.
IT Specialist, inoltre, ha il compito di verificare se le richieste siano dettate da requisiti legali o errori bloccanti; in caso lo siano, esse avranno una priorità superiore rispetto alle altre. Gli strumenti di supporto impiegati dai consulenti IT sono vari e vanno da un semplice foglio Excel ad Outlook.
I punti critici emersi sono i seguenti:
Non esiste uno strumento unico che accompagni le richieste durante il proprio ciclo vita, infatti al diverso formato di raccolta, si aggiunge un secondo formato di analisi, che varia a seconda del modo di lavorare dei vari consulenti IT;
Possibilità di perdere informazioni importanti;
Non esiste comunicazione fra i vari IT Specialists; ognuno ha un modo di lavorare diverso.
35
3) VALUTAZIONE DEI PROJECT
Questa fase è prevista solo per le richieste che sono state classificate come “Project”: sono richieste più onerose e quindi necessitano di una procedura di valutazione più approfondita. La valutazione viene guidata dal consulente IT che ha preso in carico la richiesta, in presenza del richiedente. I due, seguendo la check – list di punti proposta dal Request Form, definiscono:
- Titolo della Richiesta; - Data di evasione desiderata;
- Stima delle ore necessarie per l’evasione; - Situazione iniziale e problema da risolvere; - Obiettivi;
- Scope;
- Rischi prodotti da un mancato intervento; - Benefici attesi dalla risoluzione del problema;
- Livello di priorità alla richiesta analizzando tre dimensioni: “Risk of doing nothing”, “Strategic Significance”, “Economic Significance”.
Per l’attribuzione della priorità è stato recepito un modello di prioritizzazione utilizzato in Korber, il quale prevede di collocare ogni richiesta all’interno di una matrice e di calcolare la priorità con l’ausilio di un foglio di calcolo.
36 Il parametro “Risk of doing nothing” è qualitativo e misura il rischio che l’azienda corre se il progetto proposto non viene approvato o se viene posticipato. Se la mancata esecuzione della richiesta impatta negativamente con dei requisiti legali o con le politiche aziendali, il rischio è alto e pari a 3, altrimenti viene valutato pari a 0.
Il secondo parametro è la “Strategic Significance”: esso misura l’importanza strategica del progetto su una scala che va da 0 a 3 e pone l’attenzione sul contributo del progetto al raggiungimento degli obiettivi strategici aziendali ed alla sua coerenza con il piano strategico. Il terzo e ultimo parametro, “Economic Significance”, è quantitativo e viene calcolato come ritorno dell’investimento usando l’indice ROI. Occorre, quindi, fare una proiezione dei costi che l’azienda dovrà sostenere per evadere la richiesta e dei benefici attesi. A seconda del valore del ROI ottenuto si attribuisce un valore di “Economic Significance” secondo una scala da 0 a 3. Vengono stimati i benefici attesi dal progetto e vengono rapportati costi relativi all’intero ciclo vita dell’investimento (progettazione, sviluppo, implementazione, test, training, mantenimento), facendo distinzione fra End Users, Key Users e IT Resources.
Figura 10: Schema usato per la stima dei costi di un progetto IT
End Users Days
Macro Analysis of the topic with the Key User Discuss and clarify with the Key User Document the topic with the Key User
Support Key User in the definition of authorization Final training on the solution
Post go live impacts Key Users Days
Macro Analysis of the topic with the user Document the topic with the User
Discuss and clarify with other Key User impacted by the changes Discuss and clarify with IT
Support IT in the detail analysis and implementation Receiving training from IT
Test execution
Documentation for End Users Definition of authorization
Final training of the solution to the End Users Update official documentation
Post go live support End User support IT Resources Days
Discuss and clarify with Key User Detail analysis
Implementation of the modification Internal test of the modification Training of the Key User
Support the Key User during the test of the modification SetUp production environment
37
Figura 11: Le 3 dimensioni della priorità (Fonte: presentazione Management Meeting FP)
Il modello proposto da Koerber prevede anche un processo di escalation nei casi in cui il consulente IT ed il richiedente non riescano a trovare un accordo sulla definizione della priorità, che arriva a coinvolgere, in casi di estrema difficoltà, anche il CFO.
In base al punteggio ottenuto, il progetto viene approvato, o viceversa. I progetti approvati passano alla fase di Pianificazione.
I punti critici emersi per la fase di valutazione sono i seguenti:
Input troppo variabili, per cui è difficile condurre un’analisi oggettiva e seguire una procedura standard;
La procedura non viene seguita con costanza, in quanto viene percepita dai soggetti interessati come troppo rigida ed eccessivamente burocratica.
4) PIANIFICAZIONE DEI JOB
I Job (richieste con evasione stimata in meno di 2 giorni), vengono pianificati autonomamente da ogni consulente IT secondo la regola “First in – First out”, fino a dedicar loro massimo il 30% del tempo giornaliero disponibile, dando ovviamente la priorità alle richieste dettate da requisiti legali o errori bloccanti. Secondo quanto dichiarato dai consulenti, però, negli ultimi anni è sempre più complicato limitare al 30% il tempo dedicato ai Job: le micro – richieste sono all’ordine del giorno ed il carico di lavoro è sempre più alto.
38 Ogni consulente ha un proprio strumento di lavoro a supporto del processo di pianificazione, c’è chi usa Excel e chi, invece, sfrutta le potenzialità del calendario fornito da Outlook Activities. Il punto di partenza è l’elenco delle attività da fare elaborato in fase di analisi.
I punti critici emersi sono i seguenti:
Non tutte le attività vengono pianificate; i consulenti prendono, spesso, in carico attività senza tracciarle e IT Manager perde il controllo su ciò che viene effettivamente portato avanti dal reparto, rendendo inutile ogni sforzo di pianificazione;
La comunicazione fra i consulenti è limitata allo stretto necessario, ognuno lavora in modo diverso;
È difficile definire una data di fine certa, perché non esiste una pianificazione chiara e condivisa e non vi è un’analisi approfondita delle richieste, quindi quello che sembrava essere un Job si può trasformare in un Project per effetto dello “scope creep” 21, oppure a causa di errori di valutazione iniziali;
La regola che dovrebbe essere seguita per pianificare i Job non viene seguita da tutti i consulenti in modo formale: questo comporta una gestione non oggettiva delle richieste.
5) PIANIFICAZIONE DEI PROJECT
Per i progetti più complessi la pianificazione ha luogo in occasione di una riunione con tutti i soggetti interessati, durante la quale vengono definite con precisione le attività con le relative date di inizio e fine previste, ed i vari responsabili.
Anche per questa fase, come per le altre presentate, non viene seguita una procedura formale. Il grado di strutturazione varia a seconda della complessità del progetto.
Ove necessario, soprattutto per progetti molto ampi e multi – company, dove è fondamentale coordinare i vari soggetti interessati che, spesso, sono localizzati in aree
21Nel Project Management, si riferisce a cambiamenti improvvisi e alla crescita incontrollata dello scope di un progetto, dopo l’avvio del progetto stesso. Questo può accadere se lo scope non viene circoscritto con precisione in fase preliminare, o se non viene monitorato in modo opportuno.
39 geografiche diverse, viene elaborato un Diagramma di Gantt 22che viene condiviso con tutte le parti interessate ed aggiornato durante l’esecuzione del progetto.
Input:
- Request Form compilato;
- Calendario attività delle risorse IT;
- Calendario attività delle risorse non IT coinvolte nel progetto (se serve il supporto di un consulente esterno).
Output:
- “Project Plan and Effort” su Excel (elenco delle attività, responsabilità e durata prevista): ne viene prodotto uno diverso per ogni progetto.
I punti critici emersi sono i seguenti:
È difficile definire una data di fine prevista, perché non vi è una tracciatura chiara di tutte le attività in corso;
Non esiste una pianificazione chiara, condivisa e visibile da tutti.
6) ESECUZIONE DELLE RICHIESTE
Input:
- Request Form compilato;
- Per i job: documentazione varia elaborata da IT specialist con i dettagli delle attività da fare;
- Per i Project: Project Plan and Effort;
22
Il Diagramma di Gantt, usato principalmente nelle attività di Project Management, è costruito partendo da un asse orizzontale che rappresenta l’arco temporale totale del progetto, suddiviso in fasi incrementali (ad esempio, giorni, settimane, mesi) , e da un asse verticale a rappresentazione delle mansioni o attività che costituiscono il progetto. Il grafico è costituito da barre orizzontali che indicano la collocazione temporale e la durata di ogni attività. La sovrapposizione di due o più barre indica la possibilità di svolgere in parallelo le relative attività.
40
Output:
- Richieste completate; - Post-Go live documentation; - Training documentation.
Modalità:
- L’esecuzione delle attività viene gestita internamente con RichIT, anche se non sempre da tutti: attraverso RichIT viene aperto un job oppure un Project e vengono inviate delle chiamate per le attività da fare, con la possibilità di allegare schermate o esempi per chiarire le attività.
- Spesso le comunicazioni avvengono tramite email, anche all’interno dello stesso reparto IT.
- A chiusura di Job/Project da fatturare all’esterno, alcuni usano ITAMS per scaricare le ore.
- Per quelle da non fatturare, ITAMS non viene più usato.
Sistemi/strumenti:
- RichIT per gestione interna delle attività;
- ITAMS per la consuntivazione delle ore legate ai Job/Project da fatturare alle consociate;
- File Excel della Pianificazione da aggiornare.
I punti critici emersi sono i seguenti:
L’utente non ha visibilità dello stato di avanzamento della richiesta, in quanto l’esecuzione viene gestita internamente attraverso RichIT;
RichIT non viene aggiornato da molto tempo;
I consulenti IT hanno affermato che ITAMS era pratico da usare quando era esterno a RichIT ed era possibile consuntivare tutte le attività (appartenenti anche a richieste diverse) tutte insieme alla fine del trimestre: adesso è inserito all’interno di RichIT ed è necessario aprire ogni job/Project e scaricare le relative ore. Concettualmente la modifica apportata al sistema ha risolto il problema di non avere le ore consuntivate suddivise per richiesta, ma il reparto IT vede in questo cambiamento della procedura un’eccessiva perdita di tempo;
