Benchmarking

4.5.1.1. UGG

Da parte del gruppo Koerber vi è la volontà di allineare il più possibile le varie BA dal punto di vista strategico e organizzativo. A questo scopo, vengono periodicamente fissati degli incontri su vari

23 _{Metodologia basata sul confronto sistematico che permette alle aziende che lo applicano di compararsi} con le migliori e soprattutto di apprendere da queste per migliorare.

47 temi, a cui i Manager delle BA sono tenuti a partecipare per confrontarsi sullo stato delle proprie aree.

Nel mese di Settembre 2017 si è tenuto il periodico incontro del KIMC, organo di governo delle strategie in ambito IT, con oggetto il tema del Demand Management, in occasione del quale è stato portato il caso UGG24 come esempio di implementazione di un sistema di IT Governance.

Tabella 3: Organizzazione reparto IT della BA UGG

Considerando l’area SAP (che corrisponde al Ring-in del presente progetto, ovvero il processo di IT Development), due sono i processi ITIL che sono stati implementati:

1. BPM (Business Relationship Management): l’obiettivo del processo è quello di costruire e mantenere relazioni positive con i clienti, identificando, e laddove possibile anticipando, il fabbisogno di clienti nuovi e potenziali e assicurando loro prodotti e servizi per incontrare i loro bisogni.

2. Demand & Project Management: il termine Demand Management si riferisce al processo

gestionale che prevede la ricezione di richieste da enti aziendali, la loro analisi e selezione sulla base di specifici driver, la loro prioritizzazione e il loro indirizzamento o meno verso le fasi esecutive. In un’accezione corretta il Demand Management non è che il primo passaggio gestionale di un processo che porta al Project Management. Non tutte le richieste, infatti, possono essere soddisfatte e non tutte diventano progetti: c’è una prima selezione che ne discrimina l’utilità, l’importanza e la fattibilità, che elimina le richieste meno significative e che trasforma le più significative in progetti potenziali. Il secondo filtro, noto come Project Selection, è una fase fondamentale del Portfolio

24 _{La Business Area UGG si occupa della fornitura di attrezzature per le operazioni di rettifica, finitura laser e} verifica/collaudo. Head of IT SAP SAP BPM (6) SAP Service Manageme nt (7) Demand & Project- Mana- gement (1) Infrastruttura IT Data Center (1) Network (2) Desktop Service (4) Application - & License- Mgmt (1) CAx (6)

48 Management. Sulla base di elementi come l’allineamento strategico, la rischiosità, i driver economico-finanziari ed altri parametri, un comitato di Portfolio (Portfolio Board) definisce la prioritizzazione delle iniziative, come primo step di un processo che prevede la promozione delle iniziative più significative al rango di progetto, anche a valle di un’analisi della capacità produttiva ed economica della struttura (Capacity Planning) ed altre valutazioni.

Figura 12: Sovrapposizione Demand e Project Management (Fonte: www.luigiatauro.com)

La funzione di Demand Management, in particolare, è nelle mani di un gruppo di Esperti IT suddivisi per aree di competenza corrispondenti alle diverse funzioni aziendali:

- Sales - Customer Care - Operations - Finance - Controlling - Technology

Il compito degli Esperti IT è quello di raccogliere le richieste specifiche della propria area di pertinenza, di armonizzarle, definire la priorità e di coordinarsi fra di loro in caso di progetti cross- funzionali, soprattutto riguardo i temi di digitalizzazione e Industria 4.0. In questo modo, richieste simili vengono accorpate e proposte di miglioramento che provengono da una specifico reparto possono essere estese anche ad altri reparti, massimizzando i benefici ottenibili dall’intera azienda.

49 4.5.1.2. ITIL Frame work

Il Team ha deciso di indirizzarsi verso il frame work ITIL v.3 ritenendolo il più chiaro e pratico per quanto concerne la tematica del Demand Management e apprezzandolo per la propria scalabilità e flessibilità; inoltre, in azienda era già presente una minima conoscenza del frame work. Infine, l’analisi del caso UGG come esempio di applicazione di ITIL, ha spinto il Team a proseguire in questa direzione, rispondendo all’esigenza di standardizzazione che il gruppo Korber desidera infondere a tutte le BA.

La metodologia con la quale sono stati modellati i nuovi processi di gestione dei servizi IT è definibile come “Adopt and Adapt”: tale metodo consente di inserire all’interno del frame work di riferimento il contesto organizzativo e tutte le peculiarità ed esigenze di business del cliente.

1. ADOPT: selezione del frame work che meglio soddisfa le esigenze ed obiettivi aziendali; 2. ADAPT: adattare il frame work alle peculiarità del business.

Il Team ha delimitato l’ambito di analisi di ITIL v.3 ai processi di Demand Management e Change Management, ritenendoli i più adatti a risolvere le criticità riscontrate con l’analisi as-is.

Demand Management

L’ambiente in cui si inserisce il processo di Demand Management è, per sua natura, non strutturato e non ripetitivo; per questo, ITIL non fornisce una procedura strutturata di riferimento, bensì delle linee guida descrittive generali da cui partire per modellizzare il processo in base alle peculiarità aziendali.

Di seguito viene fornito un elenco delle attività imprescindibili di cui il Demand Manager deve farsi promotore:

- Gestione delle Richieste Utente non pianificate;

- Gestione del rapporto IT – Utente puntando su una collaborazione proattiva;

- Analisi del comportamento degli Utenti finalizzata ad anticipare l’emergere di potenziali problemi e fabbisogni futuri;

- Armonizzazione di iniziative simili che provengono da diverse aree aziendali;

- Valutazione della possibilità di estendere iniziative ad altre aree (quindi il Demand Manager può farsi esso stesso promotore di nuove richieste);

50 - Valutazione del contributo delle richieste al raggiungimento degli obiettivi strategici

aziendali.

Change Management

Il processo di Change Management, secondo ITIL, assicura l'utilizzo di metodi e procedure standard finalizzati alla gestione efficace ed efficiente di tutte le proposte di cambiamento ai Sistemi Informativi, alla riduzione di ogni eventuale impatto sulla qualità del servizio e al miglioramento della normale operatività. Al fine di consentire una transizione rapida e semplice dai sistemi vecchi a quelli nuovi, è fondamentale che il processo di Change Management abbia un'ampia visibilità e disponga di efficaci canali di comunicazione.

Le attività di Change Management si possono così sintetizzate: - Richiesta di cambiamento RFC (Request For Change); - Classificazione e autorizzazione del cambiamento; - Test, rilascio,analisi e chiusura del cambiamento.

Sono fattori critici di successo per il Change Management: - Ripetibilità dei processi di realizzazione dei cambiamenti;

- Rapidità e correttezza nei cambiamenti;

- Protezione dei servizi durante i cambiamenti o Efficienza e efficacia del processo.

Sottolineando la propria connotazione di frame work flessibile e scalabile, ITIL suggerisce di adattare la Best Practice alle dimensioni e alla maturità e cultura organizzativa aziendale, per non incorrere nel rischio di un’eccessiva burocratizzazione e rigidità delle procedure.

51

Fase 1: Proposta

Ogni membro dell’organizzazione dovrebbe essere incoraggiato a richiedere un cambiamento; questo incoraggia l’innovazione e fa emergere potenziali problemi. ITIL raccomanda di far transitare le RFC (Request For Change) attraverso una struttura che sia in grado di filtrarle e di rigettare quelle inapplicabili. Dopodiché il Change Manager deve attribuire una priorità alla RFC ed individuare se ci sono i requisiti per categorizzarle come Change in Emergenza, che avranno una procedura particolare. Altrimenti, deve essere decisa la categoria di appartenenza. ITIL propone 3 Change Models che classificano le RFC in base all’impatto e alle risorse necessarie:

- Minor; - Significant; - Major.

52 Scopo della fase di “Approvazione” è la discussione e valutazione di tutte le proposte di cambiamento. Il livello di approvazione della RFC varia in funzione del rischio, il quale deve essere valutato tenendo conto dei seguenti tre parametri:

- Rischio Tecnico;

- Rischio Finanziario;

- Rischio di Business;

Inoltre ITIL propone un diverso grado di escalation a seconda del Change Model a cui appartiene la RFC, chiamando in causa per le RFC Significant il CAB (Change Advisory Board) e per quelle Major un Executive Team.

Fase 3: Esecuzione

Scopo della fase di Esecuzione è quello di gestire e coordinare tutte le attività di implementazione necessarie per rilasciare in produzione la RFC.

È importante sottolineare come sia fondamentale che tutti gli stakeholders coinvolti nel processo mantengano una efficace comunicazione durante tutta la fase, affinché tutto venga portato a termine con efficacia.

53 Obiettivo della fase di Chiusura è quello di confermare il buon esito dell’esecuzione della RFC. Inoltre, è consigliabile verificare nuovamente tutte le RFC dopo un periodo predefinito, per verificare che abbiano condotto ai risultati sperati.