METODOLOGIA LEAN SIX SIGMA APPLICATA AI PROCESSI FINANZIARI:

Transcript

1 UNIVERSITÀ DEGLI STUDI DI SIENA Facoltà di Ingegneria Corso di Laurea Magistrale Ingegneria Gestionale METODOLOGIA LEAN SIX SIGMA APPLICATA AI PROCESSI FINANZIARI: CONSORZIO OPERATIVO MPS Tesi di Laurea di Mattia Guidi Relatore Prof. Gianluca Murgia Correlatore Ing. Alessandro Ciulli Anno Accademico 2011 / 2012

2 Ringraziamenti Ringrazio veramente di cuore tutti quelli che mi hanno sostenuto fino ad oggi e che hanno creduto in me, alla mia famiglia ed ai miei amici. Un ringraziamento speciale e particolare va ai miei genitori ed alla mia ragazza perché mi hanno sempre aiutato, supportato e confortato nei momenti più difficili. Inoltre ringrazio il mio tutor aziendale del Consorzio Operativo MPS che mi ha formato e sostenuto in questi mesi di stage, e che mi ha dato la possibilità di seguire un progetto veramente interessante e innovativo. i

3 Indice Premessa... iv 1 Origini del Lean Six Sigma Introduzione - Lean Six Sigma applicato ai servizi Metodologia Lean Six Sigma Introduzione alla Metodologia LSS Obiettivi da conseguire Lean Six Sigma Misura dei risultati La direzione da seguire Ostacoli interni Terminologia LSS Elementi Lean Elementi Six Sigma Applicazione della Metodologia Fasi del DMAIC Define Measure Analyze Improve Control Metodologia Kaizen del DMAIC Case Study Incident Management Mission ed obiettivi Input e Output del Processo Perimetro del Processo e Interazioni con altri Processi Strumenti a supporto Glossario Acronimi Unità Organizzative e Ruoli Flusso del Processo standard KPI del processo DMAIC Gantt Kick Off di progetto Define Pain Point Workshop ii

4 7.3.2 SIPOC Map Voice of Customer KANO Matrix Project Charter Measure Value Stream Map Veline Spaghetti Diagram Evidenze Measure Analyze Statistica Descrittiva Analisi di Regressione a Analisi preliminare b Identificazione del modello c Regressione Improve Interventi Operativi Interventi Tecnologici Control Conclusioni Elenco delle Figure Elenco delle Tabelle Elenco dei Grafici Bibliografia Allegati...v iii

5 Premessa Lean Six Sigma è un approccio manageriale che deriva dalla combinazione tra il Lean Manufacturing ed il Six Sigma finalizzate al miglioramento delle performance aziendali ; Qual è il significato strategico di Lean Six Sigma? Io vorrei che investissimo nella testa delle persone. Non sto chiedendo soldi per computer. Sto chiedendo un investimento in persone in modo tale che possiamo ottenere la sostenibilità a lungo termine dei risultati che abbiamo già ottenuto. 1 Non confondete l azione con i risultati. I team possono mostrarvi le cose più brillanti, passare in rassegna ogni strumento teorico, ma se non possono mostrare i risultati sulla bottom line cosa hanno ottenuto? Avete bisogno di rimanere focalizzati sugli obiettivi di business. 2 Finora, siamo stati capaci di ridurre il costo degli acquisti del 50% riducendo il tempo di esecuzione del processo degli ordini di acquisto di oltre il 40%, migliorando notevolmente la nostra produttività interna verso il cliente e la sua soddisfazione. 3 Se le persone hanno qualcosa da fare che credono utile, hanno uno scopo, possono comportarsi diversamente in un modo molto definito e quantificabile. Se fanno la differenza e sono ricompensati, ritrovano energia, sono motivati e vogliono venire a lavorare per fare la differenza. E se riuscite a fare questo alle persone, sarà magia! 4 La mancanza di enfasi sul Six Sigma nelle aree non produttive fu un errore che costò a Motorola almeno cinque miliardi di dollari per un periodo di quattro anni 5 Io vedo i partecipanti agli eventi nella veste di catalizzatori del cambiamento, mentre gli sponsor sono i catalizzatori per il cambiamento. Senza interazioni o comunicazioni quotidiane fra ambo le parti, il progetto in se stesso fallirebbe senza dubbio. 6 1 Mike Joyce, Vice President LM21, Lockheed Martin 2 Myles Burke, Master Black Belt, Lockheed Martin 3 Myles Burke, Master Black Belt, Lockheed Martin 4 Geoff Turk, Corporate 6sigma Champion, Caterpillar 5 Bob Galvin, Ex - CEO, Motorola 6 Jim Kaminski, Ass t VP, Bank One iv

6 Capitolo 1 Origini del Lean Six Sigma La metodologia Six Sigma nasce nel 1979, quando Motorola decise di iniziare i lavori per un progetto pilota innovativo. Il progetto venne affidato a 23 ingegneri provenienti da reparti funzionali diversi dell organizzazione con a capo Mikel Harry, con l obiettivo di realizzazione un pager nuovo, mai concepito. Il team aveva autonomia sia sul piano organizzativo, sia sui metodi applicativi. Un giovane ingegnere, Smith, lavorando sul costo dei componenti difettosi, ebbe l idea geniale di notare che aumentando la qualità finale del pager e dei processi produttivi, i costi diminuivano drasticamente. Risultato, un prodotto innovativo realizzato con costi ridotti ed una qualità superiore. Da questa esperienza Mikel Harry scrisse un documento, The yellow brick road to Six Sigma, che riportava le linee guida per migliorare la qualità dei processi e dei prodotti. Questo documento giunse alla scrivania dell amministratore delegato della Motorola, Galvin; nel 1990 la metodologia fu implementata in tutta l azienda. La metodologia Lean Manufacturing nasce con Henry Ford nel 1940 all interno della Ford Motor Company, con l invenzione della linea di assemblaggio in movimento, considerando qualsiasi elemento che rallenta il flusso produttivo, uno spreco. La Lean Manufacturing è divenuta poi la base per il sistema produttivo della Toyota, che ha introdotto il Toyota Production System. Il TPS permetteva di superare la necessaria flessibilità produttiva dell azienda introducendo alcuni nuovi concetti, quali la produzione Pull (produrre sulla base delle richieste del cliente, stoccando la minima quantità di prodotti, necessaria per far fronte alle esigenze del mercato) e la riduzione dei tempi di Setup, rendendo la linea di assemblaggio più flessibile al cambio di produzione. Ancora oggi, alla Toyota è riconosciuto un alto prestigio per: La qualità dei suoi output. La flessibilità e l elevata produttività. I tempi di ciclo minimi. Nasce poi il concetto di metodologia Lean Six Sigma, che deriva dalla combinazione delle due metodologie. LSS si diffuse ad importanti compagnie nel panorama mondiale, dalla Toyota, alla General Electric, alla Microsoft, alla Lockheed Martin fino alla Bank One. Di seguito è riportato un semplice esempio del successo di una compagnia e del trionfo della metodologia che è stata implementata: la LSS. 1

7 Lockheed Martin si formò dalla fusione di LM e Martin Marietta nel 1995, anche se in realtà nasceva da un insieme di diciotto società diverse. L azienda presentava un forte legame con innovazione e progresso, e con l introduzione del LSS si creò una realtà del tutto nuova. Ciò che garantì il successo di LM fu l avvento di LM21 Operational Excellence realizzato attorno alla metodologia LSS. Si decise di investire e migliorare le aree dei servizi di supporto, quali progettazione, supporto post vendita, ingegneria, assunzione del personale, ecc, piuttosto che il processo produttivo stesso, attraverso i 5 Principi dell Eccellenza : Comprensione del valore dal punto di vista del cliente finale. Comprensione del valore del prodotto o servizio creato dall azienda stessa. Comprensione del flusso delle attività. Focalizzazione sul tempo di ciclo. Sforzo per la perfezione continua. I risultati raggiunti furono straordinari: oltre 5000 progetti di cui oltre 1000 in aree di servizio, quattro miliardi di dollari di risparmi documentati, invece dei 3,7 miliardi previsti in quattro anni. 2

8 Capitolo 2 Introduzione - Lean Six Sigma applicato ai servizi..la gente guardava alla piramide qualità, costo e tempo e pensava: Non riuscirò ad ottimizzare tutte e tre le variabili.. Con Lean Six Sigma la gente inizia a rendersi conto che si possono avere tutti e tre i risultati 7 Il service management tradizionale si è focalizzato esclusivamente sull analisi di mercato e dei bisogni del cliente, ma non è stata posta attenzione alle modalità operative in cui i clienti sono serviti e ai costi necessari per erogare i servizi. La ricerca di nuove tecnologie manageriali e approcci organizzativi sono il principale obiettivo della aziende di servizi. Tali aziende, come le Banche, oggi all interno del panorama internazionale, hanno la necessità di raggiungere l Eccellenza Operativa, riducendo notevolmente i costi, puntando ad incrementare la Customer Satisfaction. I due imperativi principali sono: 1. Migliorare gli standard qualitativi dei processi di erogazione. 2. Ridurre i costi di erogazione dei servizi. I principali driver su cui focalizzarsi sono essenzialmente tre, che permettono di ottenere un miglioramento effettivo all interno dell azienda: Semplicità: in opposizione alla complessità. Cercare di ridurre la complessità dell offerta e dell azienda attraverso la riduzione dei prodotti da catalogo, lo snellimento organizzativo e normativo interno, l eliminazione dei servizi non differenziati per il cliente. Si elimina la complessità che il cliente non vuole pagare, e si sfrutta quella che invece vuole pagare, si cercano di minimizzare i costi della complessità. La semplicità si raggiunge tramite: Eliminazione di output o attività a non valore aggiunto. Riduzione della periodicità di output o attività. Alleggerimento di alcuni output o attività, attraverso meno informazione, meno dettaglio ed un canale di trasmissione diverso. Limitare i Roll-Back, ovvero spiegazioni, dettagli e chiarimenti una volta che il servizio è stato erogato. Standardizzare o modularizzazione gli output o componenti interni, in modo che un basso numero di essi possa essere assemblato in molti servizi diversi che rispondano alle esigenze del cliente. 7 Bryan Carey, Executive Vice President, DeLeeuw Associates 3

9 Ottimizzazione gli output, ovvero eliminare le linee di offerta che generano un profitto economico negativo, in particolare quando l azienda si trova in condizioni di svantaggio o in un mercato in declino. Fluidità: in opposizione agli sprechi di processo. Eliminare sprechi nel processo e nelle attività eseguite quotidianamente, attraverso le eliminazioni delle duplicazioni, delle attività a basso valore aggiunto e rilavorazioni, la riduzione degli errori e l aumento del valore offerto al cliente. Nella maggior parte dei processi le attività a valore aggiunto rappresentano soltanto il 5 10% del processo contro il 90 95% delle attività a non valore aggiunto. Individuare le sette forme di spreco più comuni in ambito di servizi e focalizzarsi su di esse, indicate come T.I.M.W.O.O.D.: Trasportation: movimenti di materiali o informazioni non necessari. Eliminare il trasporto in eccesso attraverso eliminazione di alcuni cicli del processo e la riorganizzazione dello spazio di lavoro. (Trasporto) Invetary: WIP in eccesso rispetto a quanto richiesto di produrre per i clienti. Qualsiasi WIP genera costi senza valore aggiunto con il conseguente innalzamento dei lead time e l insoddisfazione dei clienti finali. Il work in process eccessivo deriva solitamente dalla sovrapproduzione di output necessario. (Scorte o Arretrato) Motion: movimento inutile di persone. Risolvere il problema con semplici accorgimenti, come riordinare la postazione di lavoro, oppure utilizzare dei sofware per la circolazione di informazioni. (Moto) Waiting: ritardo tra un attività o fase di processo che finisce e la successiva che inizia. Soluzione del problema con la mappatura dei processi, essenziali per individuare i ritardi. (Tempo di Attesa) Overprocessing: voler aggiungere valore ad un servizio per il quale il cliente non è disposto a pagare. Deriva dal fatto che nella maggior parte dei casi l azienda non conosce cosa, i clienti desiderano e questa porta all inserimento all interno del progetto di un attività senza valore aggiunto. (Sovralavorazione o Sovraprocesso) Overproduction: produzione di output di servizio oltre quanto necessario per l utilizzo immediato. Eliminare gli elevati tempi di setup permette di contribuire a risolvere questo problema. (Sovrapproduzione) Defets/Rework: qualunque aspetto del servizio che non corrisponde alle necessità del cliente. Sistemare un difetto può genera costi aggiuntivi molto 4

10 piccoli a monte, ma creare un costo opportunità a valle enorme, come la perdita di cliente a favore della concorrenza. (Difetti) Disciplina: in opposizione ai comportamenti non ottimali. Modificare la cultura aziendale ed i comportamenti, attraverso la realizzazione di una cultura basata sulla gestione dei risultati e sull esecuzione. Applicazione del metodo delle 5S. Figura 2.1 Miglioramento continua con LSS 5

11 Capitolo 3 Metodologia Lean Six Sigma 3.1 Introduzione alla Metodologia LSS Nelle aziende di servizi il lavoro che non aggiunge valore agli occhi del cliente comprende oltre il 50% del totale dei costi di servizio. Questo rappresenta un enorme potenziale di miglioramento per le aziende, le quali possono trarre un enorme vantaggio competitivo rispetto alla concorrenza. Perché ricorrere a Lean Six Sigma? I risultati di qualsiasi processo sono l output di ciò che entra nel processo. Qualsiasi output Y come profitto o Return on Invested Capital, dipende dalle variabili di processo X come qualità o costo che entrano in esso; ed ecco l equazione valida a livello organizzativo: I processi dei servizi sono lenti e quindi costosi, di bassa qualità, caratterizzati da elevati sprechi con il risultato di una bassa soddisfazione del cliente e una riduzione dei ricavi; i processi sono caratterizzati da un eccesivo numero di work in process (WIP o TIN), come risultato di un inutile complessità dell offerta dei servizi; l 80% del ritardo deriva da meno del 20% delle attività. Lean Six Sigma è una metodologia di miglioramento aziendale che cerca di massimizzare lo Shareholder Value Obiettivi da conseguire Generalmente gli obiettivi da conseguire sono molteplici e variano a seconda dell azienda, del tipo di business, dei protagonisti interessati, del mercato in cui l azienda si muove, ma i principali possono essere ricondotti a due categorie. Efficienza di processo: Incrementare la velocità dei processi riducendo attività a non valore aggiunto (processi cognitivi e creativi come il Marketing). Incrementare la velocità dei processi e la qualità degli output risparmiando Full Time Equivalent o risorse umane a tempo pieno e riducendo attività a non valore aggiunto (processi transazionali). Riduzione errori e varianza (processi di tipo batch). Snellimento del processo. 6

12 Obiettivi Generali: Migliorare il margine lordo del 5-10%. Aumentare il Return on Invested Capital del 5-15%. Aumentare la crescita dei ricavi del 10% l anno. Aumentare la capacità aziendale del 12-18%. Guadagnare il 4% di quote di mercato ogni anno. Acquisire nuovi clienti importanti. Ridurre il numero di addetti indiretti del 12% e il time to market. Generare un ritorno medio di dollari per Black Belt (risorsa full-time responsabile della conduzione dei progetti). Coprire l 80% del fabbisogno di capitale con i profitti operativi Lean Lean permette di: Massimizzare la velocità del processo, il tempo di ciclo e la flessibilità. Analizzare il flusso di processo e i tempi di attesa di ogni attività. Identificare lo spreco con la Value Stream Map che descrive le varie fasi funzionali del processo, e controllare i flussi di lavoro in input al processo. Quantificare ed eliminare i costi della complessità, e riduzione dei passaggi intermedi. Identificare il lavoro a valore aggiunto e separarlo da quello a non valore aggiunto ed eliminarlo, bilanciamento dei carichi di lavoro. Strumenti specifici per la velocità e metodi per azioni rapide come il processo Kaizen DMAIC, che è un processo intensivo per il miglioramento di un attività o processo. Lean realizza velocità di processo tramite la riduzione del tempo di ciclo ed efficienza del processo tramite tempo, capitale investito, eliminazione dello spreco e costi minimi Six Sigma Six Sigma permette di: Riconoscere le opportunità ed eliminare i difetti che creano variabilità e le rilavorazioni, attraverso le esigenze Customer Critical to Quality. Riconoscere la variabilità dei processi che aumenta il WIP ed il lead time, creata dai servizi offerti dall azienda, dai processi realizzati per erogare l offerta e dalla domanda. Prendere decisioni sulla base dei dati e utilizzando una grande quantità di strumenti. 7

13 Realizzare un infrastruttura culturale aziendale, ovvero un ambiente all interno dell azienda che consente un facile raggiungimento/mantenimento dei risultati. Six Sigma realizza un processo privo di difetti e variabilità, massimizzando la qualità del processo, che permetterà di erogare un servizio migliore per il cliente con costi ridotti, incrementando la Customer Satisfaction. In sintesi la combinazione dei due aspetti permette di ottenere miglioramento radicale nei servizi con il focus sullo Shareholder Value, ottenere un potente strumento per attuare le strategie del CEO, ed ottenere uno strumento tattico per i responsabili dei centri di profitto e raggiungere i loro obiettivi. La strada migliore per raggiungere performance di 6sigma (processo che produce solo 3,4 difetti per milione con una resa del 99,9997%) è migliorare la qualità e contemporaneamente applicare i principi Lean per eliminare i passaggi del processo senza valore aggiunto Misura dei risultati Un metro di misura per i risultati raggiunti dalle aziende di servizi attraverso l applicazione della metodologia è il Return on Invested Capital o %ROIC (rapporto tra profitti dopo le tasse e capitale investito, ovvero attività totali meno le passività). Nell approccio Lean Six Sigma se un progetto non evidenzia un ritorno economico superiore al costo del capitale non deve essere attivato 8. Il ROIC è il driver più forte, seguito da altri indicatori molto importanti che misurano i risultati conseguiti all interno del mercato: 1. Market to Book Value, ovvero il rapporto tra il valore di mercato delle azioni dell impresa ed il valore contabile del patrimonio netto. 2. Economic Profit, in altre parole lo spread tra la percentuale del ROIC e il WACC o Costo del Capitale e cioè se la percentuale guadagnata sul patrimonio supera la percentuale che potrebbe essere guadagnata se tale patrimonio fosse investito in un titolo di stato. 3. Tasso di Crescita dei Ricavi. Grazie a questa serie di indicatori è necessario individuare delle priorità sui progetti a cui applicare la metodologia, in base alla capacità di contribuire al %ROIC aziendale ed innalzare il valore degli altri indicatori. 8 George Sanders, Director of Sourcing, Northern Material Acquisition Center, Lockheed Martin 8

14 3.1.5 La direzione da seguire Legge del Mercato: il cliente definisce la qualità e le Critical to Quality ed è il primo driver da tenere in considerazione, seguito dal ROIC e NPV. Comprendere il valore dal punto di vista del cliente. Legge della Flessibilità: la velocità del processo è direttamente proporzionale alla sua flessibilità. Comprendere il flusso delle attività. Legge del Focus: il 20% delle attività genera l 80% del ritardo. Comprendere i Value Stream. Legge della Velocità: la velocità è inversamente proporzionale al WIP ed è definita dalla Legge di Little. Focalizzarsi sul tempo di ciclo e sul pull. Legge della Complessità e dei Costi: la complessità del servizio offerto genera un aumento dei costi, del WIP e problemi di processo con una scarsa qualità e basse velocità Ostacoli interni Non sempre l applicazione della metodologia LSS viene accettata di buon grado all interno dell azienda, e questo può provocare una serie di ostacoli interni: Scarso impegno del CEO e dei responsabili dei centri di profitto. Scarso coinvolgimento e comunicazione all interno dell azienda. Assegnazione errata delle risorse. Identificazione non corretta del progetto sulla base degli obiettivi e delle priorità. Management data-driven non sempre utilizzato, ovvero le decisioni non sempre sono prese sulla base dei dati. Non avere un approccio Lean e cercare di raggiungere gli obiettivi soltanto con il miglioramento della qualità, ignorando ritardi e sprechi. 3.2 Terminologia Lean Six Sigma Terminologia utilizzata: Approvazione/hands-off: elevate approvazioni prima che il lavoro sia completato o molti passaggi di mano tra le persone o i gruppi di lavoro interessati. Complessità: l insieme dei compiti diversi che un attività deve processare per ogni periodo di tempo considerato. Capacità: quantità di pratiche che si riesce a produrre in modo continuo. Difetti Sigma: tasso di difetti che si presentano per possibilità di difetto. 9

15 Efficienza di processo: la percentuale del tempo totale di ciclo spesa per attività a valore aggiunto, che dovrebbe avere valori superiori al 20%, calcolata con la formula: Lead Time: tempo impiegato per consegnare il servizio una volta che l ordine è arrivato; deriva dalla Legge di Little e ci dice quanto tempo è necessario per completare un qualunque elemento di lavoro, contando il lavoro in attesa di essere completato e quanto lavoro possiamo completare in un intervallo di tempo preso in considerazione: Ritardi e Tempo di Coda: qualsiasi tempo per il quale il lavoro resta in coda. Rendimento first-pass: la percentuale di work-in-process che attraversano il processo la prima volta senza necessità che siano riparati. Setup, curva di apprendimento e tempo di fermo: qualsiasi ritardo o perdita di produttività che si ha nel momento in cui le persone cambiano la loro mansione. Spreco: qualcosa che non aggiunge valore agli occhi del cliente, proporzionale a quanto ritarda il lavoro svolto. Task Time: tempo di lavorazione di pratiche all interno di una qualunque fase del processo aziendale. Tempo di completamento medio/exit Rate: numero medio di elementi/pratiche che sono completati nell unità di tempo. Valore Aggiunto (CVA): valore per cui i clienti sarebbero disposti a pagare. Non Valore Aggiunto (NCVA): insieme del lavoro per cui i clienti si rifiutano di pagare e preferiscono trasferire i loro affari, cercando altri fornitori che non abbiano tali costi. Non Valore Aggiunto di Business (NBVA): attività per il quale il cliente non vuole pagare ma che vengono richieste per qualche motivo, come scopi legali, contabili o di pagamento. Variabilità della domanda: l insieme delle fluttuazioni della domanda per l output, dipendenti dal trend, dalla stagionalità, ciclicità e aleatorietà. Work-in-process: qualunque lavoro o pratica che fa parte del processo e che ancora non è stato completato. 3.3 Elementi Lean 1. Molti processi non sono Lean: oltre il 80% dei processi di servizio sono a non valore aggiunto e quindi sono caratterizzati da un elevato spreco; agli occhi del clienti non aggiungono valore e all interno dell azienda aumentano soltanto la complessità e i costi. Agire per ridurre lo spreco. 10

16 2. Riduzione del WIP per controllare il lead time: aumentare il tasso di completamento investendo risorse finanziarie o sostenendo costi per il lavoro oppure limitare il WIP più semplicemente attraverso un costo di risorse intellettuali. 3. Creare un sistema Pull per ridurre la variabilità del lead time: prendere decisioni ponderate circa le scelte del momento opportuno per rilasciare lavoro all interno del processo; quando un elemento esce dal processo viene rilasciato un nuovo elemento sulla base del livello di servizio da raggiungere e sulla base delle priorità, tenendo conto che nei processi in cui si ha di fronte il cliente si deve mantenere il giusto tempo di risposta e capacità offrendo un servizio accettabile. 4. Quantificare le opportunità attraverso l efficienza del tempo di ciclo o Process Cycle Efficency: solitamente il PCE è pari soltanto al 5%, mentre nei processi Lean la percentuale sale al 20%, con l ausilio di una Time Value Map che traccia ogni elemento di lavoro dell intero processo come scorre classificando il lavoro a valore aggiunto, il lavoro a non valore aggiunto o sprechi e ritardi, il lavoro a non valore aggiunto necessario al processo. 5. Il 20% delle attività causa l 80% del ritardo: rimuovere qualunque attività che rallenta il processo mappando l intero processo e raccogliendo dati necessari per l analisi. 6. Migliorare il lavoro invisibile: ovvero ridurre il WIP all interno del processo di erogazione del servizio, anche c è grande difficoltà nell individuare il flusso di lavoro, attraverso strumenti di Visual Management come il Takt Board (mantenere un certo passo per soddisfare le esigenze dei cliente impostando un tetto massimo sul WIP). Il Visual Management è un metodo che aiuta le strutture operative a misurare, incrementare e analizzare le performance aziendali utilizzando segnali visuali e simboli intuitivi. Permette di definire obiettivi per tutte le risorse coinvolte e creare un ambiente pieno di dati e informazioni. Questo metodo definisce gli indicatori per il monitoraggio delle attività e dei relativi problemi alla base, per il coinvolgimento globale e per accelerare il piano di azione (Action Plan) per il miglioramento continuo. Gli strumenti a cui Lean fa ricorso sono in grado di migliorare velocità, costi e flessibilità: Kaizen Event per miglioramenti rapidi. Value Stream Map per identificare le opportunità su cui intervenire. 5S per pulire, ordinare e standardizzare la postazione di lavoro. Kanban per ottimizzare il cambiamento. Value Add-Analysis per migliorare la qualità dei processi. Tempi di Coda e Tempi di Setup eliminati o ridotti per ridurre i Tempi di Attesa e migliorare la flessibilità. Mistake Proofing per prevenire i difetti ed eliminare le rilavorazioni. Complexity Analysis sulle attività di approvvigionamento. 11

17 Time Trap da identificare per bilanciare i carichi di lavoro e incrementare la produzione, attraverso il Process Balancing. Work Flow da rendere più efficiente per eliminare attività a non valore aggiunto e ridurre gli spostamenti inutili. Hiejunka per gestire i bisogni di risorse e scorte, ovvero livellamento del lavoro. 3.4 Elementi Six Sigma 1. Coinvolgimento del CEO e del management, comunicazione e coinvolgimento nel processo di cambiamento di ogni singolo componente del gruppo dirigente e formazione nel gestire la cultura aziendale. 2. Allocare risorse appropriate ai progetti con alta priorità, basandosi sul numero e sulla natura delle risorse. 3. Formazione per chiunque sia coinvolto e influenzato dalla metodologia LSS. 4. Eliminazione della variabilità, vista come input iniziale per il cambiamento. 12

18 Capitolo 4 Applicazione della Metodologia 4.1 Applicazione del LSS Lean Six Sigma potrà avere successo all interno di un organizzazione solo se tutti i componenti saranno in comunicazione costante tra di loro, se sarà presente un elevato coinvolgimento globale per il raggiungimento degli obiettivi attraverso integrazione e collaborazione. Il deployement è diviso in quattro fasi principali: Preparazione: comprendere la situazione attuale in modo da prendere le decisioni migliori su come avviare Lean Six Sigma; questa fase si articola in cinque passi fondamentali. 1. Selezionare il Champion: qualificato ed esperto che dovrà presentare una combinazione di capacità personali e abilità nel comprendere il business, poiché riferirà direttamente al CEO. 2. Individuare la baseline dell azienda: ovvero ricercare informazioni sullo stato attuale del business, le sue divisioni principali e le conoscenze e attitudini verso il cambiamento, attraverso anche benchmarking con le altre aziende. 3. Interviste one-to-one con il top management: per identificare gli elementi critici di successo per l azienda, come esperienze passate, comprensione della strategia e delle priorità, attitudine verso il Lean Six Sigma, come prendono le decisioni e come viene svolto il lavoro collaborativo, formazione personale, apertura a nuovi approcci. 4. Coinvolgimento degli influenzatori importanti interni con interviste e focus di gruppo: considerando che la loro influenza su ogni reparto dell organizzazione, può dar luogo ad un avvio, diffusione e sostenibilità della metodologia nel lungo periodo. 5. Valutare la preparazione acquisita: delle aree aziendali rispetto alla formazione Lean Six Sigma e capire le aree più o meno ricettive. Nonostante ogni azienda abbia struttura, dimensioni e business diversi ci sono alcuni punti chiave in questa fase che dovrebbero essere osservati: costruire e mantenere capitale umano per il vantaggio competitivo; creare un forte orientamento alle persone che sono la risorsa fondamentale per la riuscita della metodologia; orientamento al processo e massiccio utilizzo dei dati necessari per prendere le decisioni; standardizzazione per rimanere competitivi ed 13

19 offrire servizi di alta qualità in modo continuativo; considerare Lean Six Sigma non come un sovraccarico di lavoro, ma come parte integrante del lavoro quotidiano. Coinvolgimento: l interazione tra le persone, il linguaggio comune, la rimozione delle emozioni, basando la maggior parte delle decisioni sui fatti e sui dati ha fatto cose meravigliose per lo sviluppo delle nostre persone 9. Questa fase si basa su due regole fondamentali: 1. Avere una piattaforma articolata in uno o più obiettivi da due a cinque anni, assicurandosi che riflettano i tipi di benefici che si vogliono ottenere dalle attività Lean Six Sigma. 2. Creare un disegno di come cambierà il modo di operare delle persone all interno dell azienda. Mobilitazione: gli scopi di questa fase sono i seguenti, 1. Incaricare un team direzionale di supervisionare il deployement: il CEO deve assegnare la responsabilità dello sviluppo del business case e di un piano dettagliato dei primi 100 giorni ad un Gruppo di Progetto o Deployement, che deve creare una visione, definire gli obiettivi e i budget e prendere le decisioni che assicurino un collegamento con le strategie del CEO. Il team deve determinare i gap tra la situazione corrente e quella desiderata e determinare le attività Lean Six Sigma che devono colmare tali gap, sviluppare un progetto preliminare e confrontare le prestazioni rispetto alla concorrenza (gap-analysis). Il progetto deve definire gli obiettivi ed i programmi di implementazione, la struttura organizzativa e le risorse umane, le metriche finanziarie collegati con gli obiettivi strategici, i costi stimati in perdita di calo del servizio dovuto ad uno spostamento di personale nelle attività Lean Six Sigma. 2. Creare l infrastruttura adatta: che metta insieme persone che lavorano quotidianamente per l organizzazione e persone che possano introdurre il miglioramento. Posizioni con responsabilità principali di linea. o CEO: determina se l azienda adotterà Lean Six Sigma, si occuperà di rafforzare i legami tra attività Lean Six Sigma e strategie aziendali, effettuerà una costante comunicazione attraverso l azione con collaboratoti diretti e tutta l azienda, controllerà i risultati di roll-up rispetto al programma, creerà un linguaggio comune integrando la terminologia. o P&L o Responsabili di BU: lavorano con il Champion per definire la strategia della loro business unit che sarà poi il criteri per selezionare i 9 Geoff Turk, Corporate Champion, Caterpillar 14

20 o o o progetti ed i Value Stream. I responsabili utilizzano Lean Six Sigma per trovare soluzione ai problemi con alta priorità, creano un piano di deployement, identificano e supportano i componenti delle Black Belt, monitorano continuamente l avanzamento del gruppo di progetto. Responsabili di linea o Sponsor: sono le persone che lavorano sui processi che saranno migliorati da Lean Six Sigma e quindi devono formarsi sulla metodologia, aiutare nella scelta del progetto sulla base delle conoscenze e dell esperienza sui processi stessi e nella selezione delle Black Belt, selezionare i componenti del gruppo assieme alle Black Belt, fornire dati alle Black Belt e alle Unit Champion, controllare l avanzamento del progetto applicando il processo DMAIC, sviluppare un ambiente di successo. Green Belt: componenti del gruppo che lavorano su un progetto part-time, su uno specifico processo sul quale hanno le conoscenza adatte; i componenti riceveranno due settimane di formazione dalle Black Belt ed impareranno ad applicare le competenze DMAIC. White/Yellow Belt o colore dell azienda: una risorse part-time che solitamente ricevono dalle due alle quattro ore di formazione, non hanno l obbligo di partecipare ai progetti, ma possono dare il loro contributo ed ampliare il bacino delle risorse umane indirizzate a questo nuovo modo di lavorare. Posizioni con responsabilità Lean Six Sigma. o Champion: poche persone che grazie alle loro qualità e all abilità nel gestire le persone hanno un ruolo fondamentale. La responsabilità principale e di monitorare che l azienda esegua un costante deployement, poi qui sono elencate le altre responsabilità: lavorare con i responsabili delle Business Unit per selezionare i progetti e i Value Stream con potenziale più elevato, sviluppare la programmazione Lean Six Sigma e successiva supervisione, assicurarsi che l 1% del personale diventi Black Belt, gestire le code di progetto, eliminare le barriere interne e gestire al meglio la comunicazione ed il coinvolgimento, accertarsi che la Voce del Cliente o VOC sia considerata, risolvere i conflitti interni. o Black Belt e Master Black Belt: sono una risorsa full-time (FTE), responsabili della conduzione dei progetti che ricevono una formazione di almeno cinque settimane che ruota attorno alla metodologia Lean Six Sigma e agli strumenti e alle capacità di leadership. Devono far si che gli obiettivi 15

21 del progetto vengano raggiunti, lavorare con lo sponsor del progetto ed il Champion per formulare ed implementare i progetti e selezionare i componenti del gruppo, formare e guidare le Green Belt nel processo DMAIC, promuovere un approccio standard alla soluzione dei problemi. Le Master Black Belt sono degli esperti consulenti interni alle Black Belt che diventano tali dopo che le Black Belt raggiungono un esperienza tale da essere certificate. Il personale chiave viene scelto sula base della loro leadership oltre che sullo capacità tecniche e di problem-solving. Innanzitutto il personale selezionato deve essere formato, in seguito si devono affrontare i problemi legati alle posizioni lasciate vuote anche se molte aziende decidono di non rimpiazzare tali ruoli perché i vantaggi ottenuti con il miglioramento fanno si che tali ruoli non siano più necessari. Una Matrice RACI aiuta a ordinare e chiarire le responsabilità ed i ruoli, aumentando la produttività, la pianificazione, la comunicazione tra i soggetti ed il raggiungimento dei risultati e contemporaneamente riducendo la duplicazione delle attività e gli errori di rilavorazione. Una matrice RACI si basa su: Responsable: persone a cui si richiede una partecipazione attiva, colui che svolge un compito. Accountable: persone responsabili dei risultati. Consulted: persone che hanno la capacità di contribuire a decisioni importanti e devono essere consultate prima di prendere delle decisioni finali o conseguire un azione. Informed: persone informate su attività svolte e decisioni prese. Figura 4.1 Matrice RACI 16

22 Nonostante queste linee guida ogni azienda è diversa dalle altre e quindi sarà necessario individuare un equilibrio interno sulla base delle caratteristiche peculiari. Il primo aspetto è capire se sono necessarie risorse part-time o full-time. Con risorse full-time i risultati vengono raggiunti più rapidamente perché le Black Belt concentrano la loro attenzione in modo continuativo, posso preparare contemporaneamente un numero elevato di gruppi di progetto, esaminare la cause dei problemi di qualità e velocità, acquisire una notevole esperienza in tempi rapidi. Con risorse part-time il problema è che i manager coinvolti possono ritornare alla loro quotidiana occupazione perdendo di vista i processi di miglioramento. Il secondo aspetto è individuare delle relazione gerarchiche che possano favorire l integrazione, nonché la comunicazione e l interfacciamento dei diversi soggetti coinvolti nei processi di miglioramento. Terzo aspetto è individuare un sistema di incentivazione adeguato sulla base dei risultati, cercando di motivare il clima aziendale e non creare dei dissensi. 3. Sviluppare la formazione: sulla base del ruolo e delle responsabilità. Formazione che va dai tre giorni dei dirigenti, ad una settimana dei process owner, alle due settimane delle Green Belt, alle cinque settimane delle Black Belt. La formazione è un aspetto fondamentale per capire la metodologia da adottare ed avere un orientamento Lean Six Sigma. 4. Scegliere e formare i primi progetti: lo scopo è assicurarsi che i progetti supportino le necessità di business. Il primo passo è creare un Charter di progetto collegato ad obiettivi strategici e finanziari, che descriva il servizio, un business case, gli obiettivi, l ambito, un piano di progetto e l elenco dei componenti. 5. Metriche da adottare: individuare le informazioni da sapere, quali sistemi generano questo tipo di informazioni, quali informazioni sono necessarie per colmare i gap. Sotto elencati, ecco un certo numero di indicatori: Risultati Finanziari: ROI di progetto, Ritorno Medio per Black Belt o progetto. Risultati di progetto prima e dopo: Tempo di Ciclo di Processo, Livello di Difetti, Soddisfazione del Cliente, Spreco e Scarti, Rilavorazioni. Ambito dell attività: Numero di Black Belt e Green Belt formate e progetti completati, Tempo Medio per certificare le Black Belt. Durata del progetto: Tempo complessivo di Completamento, Tempo Medio speso in ogni fase DMAIC, Numero di progetti per Black Belt per anno. 6. Performance e Controllo: le performance aziendali si basano essenzialmente su nove principi base del deployement che sono i seguenti, Coinvolgimento dell alta direzione e attori chiave. 17

23 Comunicazione tra CEO e Corporate Deployement Champion. I responsabili dei centri di profitto dispongono di risorse Black Belt. Utilizzare l 1% delle Black Belt a tempo pieno. Identificare i progetti all interno del business, basandosi sulla creazione del valore. Ridurre il WIP per ridurre i tempi di ciclo secondo la Legge di Little. Tenere traccia dei risultati. Formazione sulla leadership per le Black Belt. Fornire una piattaforma di miglioramento per innovazioni future. Per garantire risultati continuativi ed evitare sorprese nei risultati è necessario evitare alcune trappole insidiose, quali: Andare alla deriva rispetto alle priorità: risolvere il problema attraverso le mappature della catena del valore e monitoraggio valutando se il progetto segue la traiettoria stabilita oppure sta deviando. Troppi progetti nella pipeline: evitare di impiegare le risorse in maniera errata e cercare di focalizzare l attenzione su un numero ridotto di progetti ad alto potenziale, per massimizzare i risultati con brevi tempi di ciclo dei progetti. Conoscere il numero Black Belt è fondamentale per fissare un tetto massimo di progetti e prevenire un eccessivo WIP. Controllo non adeguato dei risultati. Scarsa condivisione delle best pratics tra i gruppi: cercare di condividere le prassi migliori per poi applicarle ad altre aree ed altri progetti; creare una documentazione web-based in un database che contenga le prassi adottate con i relativi risultati. Dimenticarsi delle persone non direttamente coinvolte nel deployement: questo può generare risentimento e dissenso all interno dell organizzazione portando le persone ad opporsi al miglioramento. Risultato conseguente è l isolamento di Six Sigma con ritorno ai vecchi metodi di lavoro. 18

24 Capitolo 5 Fasi del DMAIC Il processo DMAIC si suddivide in cinque fasi sequenziali, che possono essere viste come un ciclo continuo. Define: definire gli obiettivi del progetto sulla base delle criticità del processo considerato e degli indicatori di progetto. Individuare le opportunità per il miglioramento dal punto di vista del cliente e del business. Measure: misurare in modo quantitativo i dati delle varie fasi del processo, definendo la Baseline di partenza. Analize: analizzare i dati misurati nelle varie fasi del processo, identificando i dati più significativi e che hanno un maggiore impatto sulle performance, al fine di implementare azioni correttive e migliorative nella fase successiva. Improve: miglioramento continuo, inteso come implementazione delle azioni correttive da applicare alle fasi più critiche e impattanti sulle performance. Control: controllo delle implementazioni effettuate per evidenziare eventuali scostamenti rispetto alla Baseline del processo e da quanto pianificato nella fase di definizione. Le fasi di implementazioni e monitoraggio sono svolte in parallelo e sono l input per una nuova fase di Define sempre sullo stesso processo. Figura 5.1 DMAIC 19

25 5.1 Define Un team ed i suoi sponsor definiscono il progetto ed i risultati attesi. Si cera di definire il problema, ovvero individuare il legame tra il progetto e la strategia aziendale, i limiti del progetto, individuare gli indicatori e le metriche utilizzare per valutare i risultati finali (Customer Satisfaction, velocità e lead time, miglioramento del livello Six Sigma, risultati finanziari e mantenimento dei ricavi e crescita, riduzione dei costi e come evitarli). In questa fase due aspetti sono importanti: identificare le persone giuste da inserire nel team e assicurarsi che ogni persona parta dalle stesse aspettative. Si dovrebbe sviluppare un piano di comunicazione che fornisca le informazioni importanti ed i feedback sul progetto. E una fase di configurazione del lavoro in cui si vuole determinare la fattibilità del progetto, tenendo in considerazione gli aspetti sotto indicati: 1. Cosa deve essere analizzato. 2. Quali sono gli obiettivi da raggiungere con il progetto. 3. Quali sono le risorse necessarie. 4. Il tempo necessario per la conclusione del processo. Sintesi dettagliata: Individuare le fasi principali del processo, definendo la SIPOC Map per identificare l obiettivo del progetto o processo; mappare i processi di Business. Raccogliere i requisiti/necessità da clienti e Process Owner per le performance di processo, attraverso la VOC-Voice of Customer (performance in termini di velocità e qualità) e VOB- Voice of Business (performance in termini di velocità e costi richieste dal Top Management). Sviluppare i Critical Customers Requirement a i Critical Business Requirement, ovvero gli output del processo, attraverso classificazione e prioritizzazione. Capire se il problema esiste, è importante per il consumatore, per il business e se è possibile attraverso LSS ottenere miglioramenti. Identificare i benefici finanziari in termini monetari e come vengono raggiunti, calcolando costi, profitti, margini o altri indicatori finanziari rilevanti. Creare un piano di comunicazione, identificando i partecipanti del progetto a gli stakeholders e sviluppare un piano per tenerli informati circa lo sviluppo. Sviluppare il Project Charter (Schedule, Budget and Milestone), che deve contenere il problema (definito dalla Leadership di progetto e dalle opportunità per il business), gli obiettivi, le risorse coinvolte e le possibili soluzioni. Definire il Charter che descrive le opportunità di miglioramento e se queste sono in linea con la strategia aziendale. Il Project Charter sarà poi 20

26 assegnato alle Black Belt che identificherà i clienti chiave ed i loro requisiti e validerà quest ultimo. Identificare il problema selezionando la Leadership di Business e l area di opportunità. Definire i Charter, descrivendo le opportunità di miglioramento allineate con la strategia di Business. Assegnare il Project Charter al Black Belt che identifica i clienti chiave ed i loro requisiti, valida l obiettivo, le ipotesi ed i benefici del Project Charter. Garantire l allineamento tra le parti coinvolte del progetto attraverso una fase di revisione finale. Principali deliverable della fase di Define: o Pain Point Workshop: strumento per identificare le fasi critiche del processo facendo riferimento all ambito di lavoro, descrizione delle macrofasi del processo, tempistiche di accadimento, grado di diffusione, impatto e rischi. Si rappresenta graficamente, come una mappa ad alto livello del processo, sequenziale, in cui fase per fase vengono identificati i Pain, detti Mal di Pancia, ovvero le criticità. Rappresenta l input per iniziare la SIPOC Map. Figura 5.2 Pain Point Workshop o SIPOC Map: mappa ad alto livello del processo che identifica i fornitori, gli input, le fasi, gli output ed i clienti coinvolti. Supplier, Input, Process, Output and Customer. Lo scopo è creare un livello di conoscenza comune all interno del gruppo di progetto. Una SIPOC MAP si realizza identificando Inizio e Fine del progetto; identificando i clienti interni ed esterni e classificandoli sulla base delle priorità; definendo una lista di output sulla base delle esigenze e dei requisiti dei clienti, delle priorità e delle CTQ, oltre alle possibili esigenze riguardo alle attese definite da CTDelivery e CTCost (si occupa anche dei requisiti di business come incremento della produttività e riduzione dei costi); definendo le fasi del processo e gli input fondamentali; individuando i fornitori degli input. Si presenta in forma tabellare verticale, dove in ogni colonna sono riportate le informazioni necessarie, ma viene realizzata orizzontalmente, poiché per ogni fase del 21

27 processo abbiamo fornitori, input, output e clienti; solitamente il cliente (interno oppure esterno) sarà il fornitore dell input necessario per la fase successiva del processo. Figura 5.3 SIPOC Map o Voice of Customer: insieme di strumento per identificare quello che il cliente desidera, ovvero le necessità che devono essere soddisfatte fruendo del servizio e tradurre il tutto in caratteristiche misurabili e quantificabili, le Critical To Quality. VOC è utilizzato per determinare i parametri del progetto e verificare l importanza degli indicatori utilizzati, per chiarire cosa è critico per il cliente e quali sono le priorità per la buona riuscita del progetto. VOC si basa sulle CTQ, ovvero un insieme di parametri misurabili che misurano l output del processo (Y) e che devono essere sempre definiti dal cliente e non dall esperto aziendale. Inizialmente è necessario valutare il legame tra gli attuali servizi con le necessità CTQ, poi è necessario raccogliere i dati VOC per generare dei requisiti di progetto per nuovi o riprogettati servizi, attraverso metodi reattivi (i dati arrivano) oppure metodi proattivi (raccogliere i dati). VOC si basa su alcuni semplice passaggi e sarà l input per la successiva costruzione della KANO Matrix: Capire se le priorità aziendali corrispondono a quelle dei clienti (VOC). Creare una lista completa e organizzata dei bisogni del cliente, dove quelli con maggiore priorità saranno gli input per il progetto. Identificare i clienti sulla base della creazione di valore per l azienda; fare le ricerche opportune sui clienti tramite interviste, Indagini, Focus Group, visite in loco oppure storico dati dei clienti, che aiutano il team ad organizzare le decisioni sui vari segmenti di mercato, ad individuare i rappresentanti di ogni segmento e con quale scopo; analizzare le informazioni. Convertire i dati VOC e VOB quando necessari (requisiti del Top Management), in requisiti di progetto e performance tramite il Quality Function Deployement, che trasforma i bisogni del cliente in caratteristiche funzionali e 22

28 poi in caratteristiche di progetto evitando molti problemi successivi e riducendo il tempo di ciclo del processo (un esempio è la Casa della Qualità che elenca le funzionalità richieste dal cliente e la loro importanza, la capacità che possiede l azienda per affrontare tali esigenze e la loro combinazione, il confronto con la concorrenza nell esaudire i bisogni). o KANO Matrix: strumento utilizzato per sviluppare servizi che permettano di raggiungere gli obiettivi che derivano dalla soddisfazione del cliente finale. Il modello prevede alcuni basilari passaggi, che sono: identificare le caratteristiche da analizzare dopo aver condotto un accurata indagine tra i clienti (VOC), analizzare le risposte, stabilire le priorità dei miglioramenti in base ai dati raccolti. Il modello di Kano si propone di classificare i bisogni del cliente attraverso una matrice che presenta sull asse delle ordinate il Grado di raggiungimento dei CTQ (ovvero la presenza o meno del CTQ), mentre sull asse delle ascisse il Livello di soddisfazione del cliente. Mi permette di determinare quali CTQ sono: Must Be Qualità di base: requisiti che il processo garantisce; non generano grande soddisfazione, ma che creano ampia insoddisfazione qualora vi sia anche una lieve disfunzionalità; sono tutti quei requisiti che dovrebbero essere presenti all interno del processo. Linear o Soddisfacenti Qualità eccellente e performante: requisiti che il processo garantisce; generano un grado di soddisfazione direttamente proporzionale al grado di performance raggiunta dagli stessi. Delighter: requisiti che il processo non garantisce, ma se assolti possono creare una grande soddisfazione nel cliente, fino a deliziarlo, e che potrebbero dare maggior valore nello sviluppo del servizio perché corrispondenti ad un alto livello di soddisfazione del cliente. Neutral: requisiti non presenti e che non creano un elevato grado di soddisfazione per il cliente. Una volta identificati i CTQ, l obiettivo è individuare i requisiti mancanti, fotografando lo stato attuale del processo, quindi sarà necessario: Garantire la presenza dei Must Be e dei Satisfier. Individuare le priorità per agire sui requisiti mancanti o Delighter. Il passaggio ideale di un CTQ sarebbe Delighter Satisfier - Must Be.) 23

29 Figura 5.4 KANO Matrix o Milestone: indica il raggiungimento di obiettivi stabiliti in fase di definizione del progetto stesso. Per la rappresentazione delle Milestone solitamente si utilizzano degli strumenti grafici definiti Diagrammi di Gantt. o Stakeholders Analysis. o Quad-Chart: strumento utilizzato per descrivere sia attraverso un diagramma a quattro quadranti sia a parole, le idee, le proposte di soluzioni innovative. I quadranti riportano l idea innovativa, la struttura del processo, l impatto che questo potrà avere e lo Schedule delle operazioni. o Piani Multigenerazionali: permettono di determinare il livello di miglioramento all interno del progetto fissando gli obiettivi attuali ed i target per i futuri servizi da erogare. Determina le priorità degli obiettivi all interno del progetto corrente ed eventuali confini. o Project Valuation/ROIC Analysis Tools. o Project Charter: la fase di Define termina con la formalizzazione finale dei parametri chiave del progetto, che sintetizzano il piano di azione. La Carta di Progetto offre una panoramica di alto livello, che permetterà di capire: l ambito ed il perimetro del progetto entro il quale si deve operare, il processo da analizzare e migliorare, le attività e gli strumenti da utilizzare, lo stato attuale del progetto, gli indicatori in termini di influenza del problema, il successo del progetto, gli obiettivi, i benefici per il cliente, i 24

30 benefici di business in termini finanziari, le priorità sui requisiti, i costi, l analisi dei rischi, i soggetti da coinvolgere quali stakeholders e membri del team e l orizzonte temporale. Il Project Charter sinteticamente conterrà: Problem Statement: lo stato attuale del processo. Obiettivi da raggiungere. KPI su cui agire. In Scope: gli aspetti che rientrano nell ambito del progetto. Out of Scope: gli aspetti che non rientrano nell ambito del progetto. Figura 5.5 Project Charter 5.2 Measure Questa è la fase in cui vengono effettuate le misure e quindi vengono raccolti i dati, perché combinare i dati con la conoscenza e l esperienza assicura un miglioramento reale e duraturo nel lungo periodo. Il presupposto principale è che ogni attività sia misurabile. Il primo step coincide con l identificare una o più Critical-to-Quality sulle quali intervenire per ottenere il miglioramento e conseguentemente individuare i dati necessari da raccogliere e separarli dai dati superflui che non portano nessuna informazione cruciale per il processo. Le metriche da monitorare in questa fase sono il work-in-process, il tasso di completamento medio, il lead time, la variabilità della domanda, il rendimento first-pass, i passaggi di mano e approvazioni, le curve di apprendimento, il tempo di fermo e setup, difetti e capacità Sigma, la complessità. Una volta definite le metriche è necessario osservare il processo da parte di esperti neutrali coinvolgendo anche il personale di ufficio per stabilire gli obiettivi dell osservazione: Cosa vogliamo imparare da questo processo?. L osservazione diretta è fondamentale già nelle prime fasi di miglioramento, per verificare le idee pianificate e concentrarsi su aspetti chiave che necessitano di maggiore attenzione, perché cruciali. La raccolta dati è il passo successivo e deve 25

31 essere fatta partecipando attivamente al processo. I dati devono descrivere se il servizio erogato è ciò che i clienti finali si aspettavano, e alcune volte possono rappresentare una vera sorpresa, perché possono evidenziare problemi mai posti. Sono necessari incontri periodici tra le Black Belt ed i team di miglioramento del processo. Gli strumenti utilizzati in questa fase servono essenzialmente per: 1. Descrivere il processo. 2. Focalizzazione e assegnazione di priorità. 3. Raccolta dati e accuratezza. 4. Quantificazione e descrizione della variabilità. Sintesi dettagliata: Definire la Value Stream Map, identificando gli input chiave (i dati necessari per identificare le cause radice del processo), le metriche di output e le metriche del processo. Sviluppare le Operational Definitions, ovvero la metriche per misurare i dati chiave. Sviluppare un piano per la raccolta dei dati (sviluppo formale di un Template) e valutare che il sistema di misurazione sia efficace, individuando: I valori di Baseline per i dati misurati. Le performance e la capacità del processo detta Process Capability, attraverso l individuazione degli scostamenti tra la Voce del Cliente/Business ed il processo stesso. Validare le opportunità modificando il Project Charter sulla base degli scostamenti individuati nella misurazione, identificare i Quick Win ovvero gli interventi rapidi di miglioramento. Revisionare i dati raccolti e le prime osservazioni emerse. Principali deliverable della fase di Measure, che si dividono in quattro categorie: Descrizione di processo: o Top Down Flow Chart: fornisce un focus molto dettagliato sulle attività del processo da esplodere partendo dal livello più alto e generale fino ad individuare le cause radice particolari e specifiche. Questo strumento visivo è l input per la Value Stream Map che permette la descrizione attraverso una vista verticale del processo. Le varie fasi di cui si compone sono: Identificare le fasi di Inizio e Fine del processo individuate nella SIPOC. 26

32 Definire tra 6 e 12 attività del processo ad alto livello. Esplodere i singoli livelli di attività in altre 6/12 attività di livello medio, in modo da incorporare all interno di esse, la cause radice del problema. Esplodere fino a quando non si sono individuate le cause radice del problema (microprocesso). o Value Stream Map: strumento visivo, utilizzato dal Team di Progetto, che permette di catturare tutti i flussi chiave di informazioni, materiali e lavoro in un processo e le importanti metriche di processo; permette di distinguere le attività a valore aggiunto da quelle a non valore aggiunto con il fine di rimuovere lo spreco e di individuare le priorità di miglioramento. Comprende gli obiettivi strategici di business, i processi di business e le metriche ad alto livello; individua le differenze tra le strategie adottate e la Voice of Customers. La VSM deriva dal flusso di processo che identifica le variabili chiave ed i passaggi fondamentali. La VSM si costruisce esplodendo ogni macrofase del processo descritto precedentemente nella SIPOC Map, quindi attraverso una serie di passaggi che sotto descritti: Determinare la relazione tra Prodotti e Processo attraverso una semplice matrice, questo perché il processo in questione può essere caratterizzato da una molteplicità di output e quindi sarà necessario focalizzarsi soltanto sulle CTQ richieste dal cliente e dai requisiti di business. Mappare il flusso del processo in ogni singolo fase specifica, che attraversa la catena Fornitori Input Processo Output - Clienti finali. Aggiungere alla VSM il flusso delle pratiche e delle informazioni riguardanti l intero processo. Aggiungere alla VSM l insieme dei dati che stanno alla base del processo (PLT, WIP, Task Time, Quantità, Attesa), individuando anche le 7 forme di spreco. La costruzione si basa esclusivamente su simboli che traducono tutto il processo da un punto di vista grafico, evidenziando: Cliente e/o Fornitore, Uffici Interni ed Esterni all azienda, Clienti della Business Unit. Controllo sulle fasi del processo, Flusso dell informazione telematica e cartacea, Flusso fisico del processo. Spostamento fisico pratica, Riciclo, Flusso del riciclo, Arretrati, Tempi di attesa e Passaggi di mano (sette forme di spreco T.I.M.W.O.O.D.). 27

33 Figura 5.6 Esempio Value Stream Map o Complexity Value Stream Map: strumento visivo che combina il flusso di processo, i dati sull utilizzo del tempo, i dati che indicano quanti diversi servizi scorrono attraverso la VSM, ovvero la complessità del processo. Per ogni attività di processo è necessario raccogliere i dati riguardo il costo stimato per attività (ABC Cost), process time (tempo a valore aggiunto per unità di ogni tipo di servizio), tempo di cambiamento (tempo totale che trascorre per il cambiamento da un servizio ad un altro e la curva di apprendimento), tempo di attesa, takt time (tasso di domanda dei clienti per ogni tipo di servizio), complessità, difetti e rilavorazione, uptime (tempo di lavorazione giornaliera meno gli intervalli e le interruzioni). o Spaghetti Diagram: diagramma che mappa un processo (workflow) in modo semplice, un flusso fisico di informazioni, materiali o persone in un processo individuando i passaggi di mano o hands-off, i ritardi più significativi e le code. È utilizzato per migliorare ed organizzare la struttura del luogo di lavoro, identificando gli sprechi insiti nel processo eliminandoli. Si costruisce da alcuni semplici passaggi: Individuare il layout dell ambiente operativo. Individuare il flusso ed i singoli passi del processo in sequenza attraverso brainstorming, oppure da manuali operativi. Individuare il punto di partenza e mappare con archi e frecce l intero processo fino ad arrivare all ultimo passo (flussi fisici con linee pine e flussi informatici con linee tratteggiate). Discutere il diagramma finale cercando di migliorare il flusso del processo, facendo anche pulizia eliminando frecce superflue che possono introdurre notevoli hands-off e code. 28

34 Figura 5.7 Spaghetti Diagram Raccolta dati e accuratezza: o Gage R&R: metodo per studiare e regolare i sistemi di misurazione migliorando l affidabilità. Si basa su Riproducibilità, ovvero persone diverse che misurano un singolo elemento otterranno gli stessi risultati; su Ripetibilità, ovvero chi prende le stesse misure sullo stesso elemento, con lo stesso strumento di misura otterrà gli stessi risultati. Quantificare e descrivere la variabilità: o Carte di Controllo: riporta i dati tracciati in ordine di tempo, calcolando se la variazione osservata è una parte normale del processo o se sta accadendo un fatto inaspettato, quindi su cui agire. Focalizzazione e assegnazione delle priorità: o Pareto Analysis: diagramma a barre per rappresentare il contributo relativo ad ogni causa di un problema. Strumento grafico che determina le priorità dei problemi su un processo considerato. L asse orizzontale rappresenta solitamente categorie di difetti o errori, mentre l asse verticale rappresenta la percentuale o l impatto di quest ultimi. Individua le poche cause essenziali su cui porre attenzione e modificare e su cui focalizzarsi per avere un maggiore impatto finanziario, attraverso una percentuale cumulata. Solitamente si basa sulla Regola 80/20, ovvero l 80% dei difetti deriva dal 20% delle cause. 29

35 Figura 5.8 Pareto Analysis 5.3 Analyze L obiettivo di questa fase è comprendere tutte le informazioni ed i dati raccolti nella fase di Measure e di utilizzarli per individuare le cause dei ritardi, degli sprechi e della scarsa qualità del servizio. Saranno individuate tutte le possibili cause della variabilità delle CTQ e le conseguenze derivanti da esse. La sfida principale da parte delle persone sta nel prendere decisioni non solo con l esperienza passata e le opinioni più rilevanti di alcuni soggetti, ma utilizzare anche i dati raccolti. Sintesi dettagliata: Individuare le variabili di processo tramite Brainstorming (Y) ed i possibili input chiave critici del processo (X). Analizzare le variabili critiche, definendo le priorità e individuando le principali X sulla base del livello di importanza; validare le variabili critiche X più importanti all interno del Team di progetto; analizzare le cause radice che sono alla base delle variabili critiche X e che hanno un legame con le variabili di processo Y; stimare l impatto di ogni X sulle variabili di processo Y. Quantificare le opportunità per migliorare il processo e infine revisionare la fase. Principali deliverable della fase di Analyze: o Brainstorming: metodo strutturato che si basa sulla generazione di nuove idee e soluzioni riguardanti un certo problema, da parte di un gruppo di persone che si riuniscono. Produce molte idee in breve tempo, facilita il processo di Creative Thinking 30

36 e permette di separare la fase di generazione da quella di separazione delle idee, incoraggia la creatività del personale e crea tematiche di discussione omogenee che ruotano intorno al problema affrontato. o Failure Mode and Effects Analysis: metodologia per valutare le modalità dei difetti ed i loro effetti sul processo. Permette di individuare ed eliminare i difetti migliorando lo struttura del processo e la soddisfazione del cliente. Utilizzato nella fase di Define e Measure per comprendere i rischi del progetto, mentre nelle altre fasi DMAIC viene utilizzato per comprendere e dare priorità alle principali variabili del processo e relativi indicatori (fase di Analyze), per comprendere i rischi legati all implementazione dei processi di miglioramento (fase di Improve), valutare l efficacia dei piani di controllo (fase di Control). Determinare per ogni input del processo i possibili modi di difetto e i possibili effetti individuando un livello di gravità (Severity) per ognuno in un intervallo numerico da 1 (non grave) a 10 (molto grave). Individuare le possibili cause dei singoli difetti assegnando un livello di periodicità (Occurency), ovvero probabilità che si verifichino in un intervallo numerico da 1 (improbabile) a 10 (molto probabile). Determinare la probabilità di individuare/prevenire ogni singola causa (Detectability) in un intervallo numerico da 1 (probabile da rilevare) a 10 (improbabile da rilevare). Calcolo del Risk Priority Number (indicatore quantitativo che varia in un intervallo tra ) che indica il livello di priorità. Individuare esatte azioni correttive e di miglioramento per ridurre le principali cause che stanno alla base dei difetti, ricalcolando l indicatore RPN. Comparare gli RPN calcolati nei due casi, definendo le priorità ed implementando le azioni. Figura 5.9 Failure Mode and Effects Analysis 31

37 o Affinity Diagram: strumento che consente di organizzare fatti, opinioni e questioni in gruppi riguardo a problemi complessi, semplicemente con l utilizzo di post-it posizionati su un flip-chart in cui vengono elencati gli input del processo e poi organizzati sulla base di tematiche comuni. Permette di organizzare molte idee derivanti dal Brainstorming, di individuare il tema centrale in una grande quantità di idee, utile quando le informazioni riguardo ad un problema non sono ben organizzate e utili per supportare idee innovative. o NGT o Nominal Group Technique: tecnica che integra il brainstorming tramite un approccio strutturato che genera nuove idee e le classifica in base alle priorità. Produce molte idee e soluzioni in breve tempo, permette di focalizzarsi su problemi, definire linee di comunicazione e ricercare il trade-off tra le idee contrastanti. o Multivoting: è una tecnica per selezionare e dare priorità ad un set di alternative dopo la fase di Brainstorming. Migliora l abilità del team nell esprimere giudizi senza essere giudicati e permette di selezionare alcune alternative valide avendo eliminato precedentemente duplicati e avendo accorpato le alternative simili. o Ishikawa Diagram o Fishbone Diagram: rappresentazione grafica tra un effetto e le sue possibili cause radice che permette di classificarle sulla base di aspetti comuni. Assicura un giusto equilibrio nella lista delle idee generate nel Brainstorming, dettagliandole maggiormente; determina la causa reale di un problema e non solo i sintomi selezionando i fattori che impattano maggiormente sul processo; individua le cause sulla base delle 6M, ovvero manodopera, macchine, materiali, metodi, misure e madre natura; permette di superare gli errori fatti nel Brainstorming, ovvero concentrarsi troppo su poche tematiche; indica il livello di comprensione del problema da parte del gruppo. Figura 5.10 Ishikawa Diagram 32

38 o Matrice Causa Effetto: strumento per analizzare il livello di correlazione tra input e output del processo, espressi sulla base delle esigenze del cliente. Mi permette di identificare e valutare (Piani di Controllo) le cause/input (FMEA) che impattano maggiormente sugli effetti/output e comprendere gli output chiave su cui concentrare l attenzione per soddisfare i bisogni del cliente. o Time Trap: è una qualsiasi fase del processo che introduce ritardo e genera il rallentamento più elevato; limita la quantità di output, non rappresenta una fase fissa ma varia continuamente nel processo ed è sempre presente; può essere causato da problemi fisici (stress, lontananza di comunicazione) o non fisici (variabilità del processo, WIP, informazione e Balancing). TP può essere un Constraint, se non permette di produrre un certo numero di pratiche che non soddisfano le richieste del cliente. Introduce lunghi LT, aumenta il WIP, i tempi morti di macchine e personale, aumenta i tempi di Setup, ecc.., quindi è necessario prestare un elevata attenzione ad individuare le Time Trap per aumentare l efficienza di lavorazione, concentrarsi sulle fasi più critiche del processo, aumenta la capacità di soddisfare i cliente e incrementa la capacità del processo (quantità massima di pratiche producibili in un tempo continuo). Per individuare le Time Trap è necessario utilizzare l equazione sottostante del Driver di Spreco, dove: D = domanda totale N = numero di processi S = tempo di Setup X = % di difetto P = tempo di processo Inoltre implicitamente considera il fermo umano, del macchinario ed il tempo di Setup per la rilavorazione. Indica due risultati principali, il Time Delay Diagram (grafico che mostra per persona il tempo necessario per concludere il tempo di ciclo attraverso tutti i compiti associati) ed il Cost Driven Analytic (mostra l impatto della qualità a fronte dei problemi di Lean della VSM). o Take Time: utile quando si vuole rendere esplicito l output di una fase del processo (tempo/unità). 33

39 o Take Rate: rappresenta la voce del cliente, ed il Time Trap è la fase che più si avvicina a questo rapporto (unità/tempo) e deve essere maggiore altrimenti il Time Trap diventa anche Constraint. o Analisi statistiche: distribuzione Normale (Gaussiana), distribuzione di Weibull, distribuzione cumulata, media, mediana, moda, varianza, deviazione standard, correlazioni tra i dati, Curtosi. o Analisi Force-Field: strumento che esamina le forze che guidano o si oppongono al cambiamento. Supporta il pensiero creativo focalizzato sul cambiamento e costruisce consenso verso le forme di cambiamento e opposizione alle forze contrarie; fornisce input per il miglioramento. o Pareto Chart. o ANOVA o ANalysis Of VAriance: strumento statistico per analizzare la relazione tra due o più gruppi confrontando la variabilità interna ai gruppi con la variabilità esterna. Confronto tra Key Process Input Variable e Key Process Output Variable per individuare le alternative migliori e quantificare l impatto delle variabili di input sugli output. o Analisi ad Albero: metodo problem - solving da utilizzare quando la ricerca delle cause radice è molto complessa. Da utilizzare assieme al Brainstorming e al Metodo delle 5Why, ovvero chiedersi il perché di una causa almeno cinque volte. o Diagrammi a Dispersione: semplice strumento grafico per determinare se esiste una relazione tra due misure o indicatori. 5.4 Improve Lo scopo di questa fase è di apportare delle modifiche e miglioramenti ad un processo, eliminando difetti, sprechi e ritardi che non sono collegati al bisogno del cliente (definiti nella fase di Define) e che quindi generano soltanto costi di non valore aggiunto. E necessario individuare le variabili di input che influiscono maggiormente sulle CTQ considerate e stabilire gli interventi di miglioramento. Le CTQ devono essere portate entro certi limiti di specifica programmati riducendo gli sprechi individuati nelle fasi precedenti. 34

40 Sintesi dettagliata: Definire le potenziali soluzioni per i problemi più rilevanti dopo aver individuato le rispettive priorità; sviluppare i criteri di valutazione e selezionare le migliori soluzioni basate sulla strategia dell azienda e sulle esigenze dei clienti; ottimizzare le soluzioni sulla base della probabilità di successo, cercando di ridurre i rischi al minimo e l impatto sul processo. Sviluppare la Process Map To Be ed un piano di implementazione; sviluppare un piano di azione ed una soluzione pilota; revisionare la fase monitorando i miglioramenti apportati. Principali deliverable della fase di Improve: o Process Flow Improvement: migliora la gestione del lavoro con l eliminazione delle fasi a non valore aggiunto e la semplificazione delle fasi a valore aggiunto; aumenta la flessibilità del lavoro, permette l eliminazione dei Constraint; definisce gli obiettivi del processo sulla base del cliente (Takt Time); definisce le operazioni standard e la riduzione del tempo; elimina la possibilità di commettere errori. Si basa su: Raccolta informazioni e misurazione: Value Stream Map. Spaghetti Diagram Analisi del processo: Analisi Time Trap. Analisi Attività a Non valore aggiunto. Applicazione tecniche per il miglioramento: Eliminazione attività a Non valore aggiunto. Ridurre gli hands-off e i tempi di attesa. Definire il flusso di processo lineare. Standardizzazione fasi del processo: Definire gli strumenti di controllo dei difetti. Creare una cultura della formazione. Stabilire l Ownership delle attività. o 5S+1: metodo che cerca di mantenere organizzato e pulito il posto di lavoro al fine di elevare le performance, permette di individuare problemi nelle fasi del processo; è la base del miglioramento continuo, della riduzione dei costi e dei difetti. Aumenta la 35

41 produttività, l efficienza e la sicurezza, il coinvolgimento del personale, costituisce un processo di squadra. Separazione/SEIRI: identifica gli elementi necessari per ridurre i superflui; Sistemazione/SEITON: sistemare le fasi del processo per semplificare il flusso; Pulizia/SEIZO: mantenere la postazione di lavoro pulita e organizzata, manutenzione periodica delle procedure; Standardizzazione/SEIKETSU: creare regolamenti guida per le attività, modalità standardizzata nello svolgere le attività; Miglioramento/SHITSUKE: miglioramento continuo. Sicurezza: eliminare rischi e pericoli. (aggiuntiva). o Risk Analysis: si basa sulla metodologia FMEA. Si suddivide in 4 fasi che sono: individuazione del rischio che possono rappresentare sia una minaccia che un opportunità del business; quantificare il rischio e stabilire la probabilità di accadimento e le priorità; sviluppare una risposta e definire le soluzione più adeguate con le rispettive attività da implementare, le soluzioni sono di tre tipi: eliminare la minaccia, mitigare l impatto del rischio, accettazione delle conseguenze; controllo della risposta, valutando e coinvolgendo le strutture che si occupano dell analisi e inserendo tutto in una documentazione. o Work Control System: metodologia per stabilizzare il processo, aumenta l'efficienza, migliorare la qualità e facilitare il controllo, controllando e riducendo il WIP, il LT, stabilire un tetto massimo al WIP di alcune fasi del processo. Permette di determinare il Lead Time, il Lead Time Target, il PCE, il WIP target. o Process Balancing: per migliorare/bilanciare i flussi del processo e soddisfare il Takt Time, riducendo le attività a Non valore aggiunto, riducendo il LT, minimizzando il WIP, ottimizzando gli spazi fisici, assecondando la variabilità della domanda. Il PB si basa essenzialmente sulla comparazione tra la VOC e la Voce del Processo (Potenzialità del processo), e questo permette di raggiungere gli obiettivi e soddisfare le esigenze dei clienti entro un certo limite. 36

42 o Diagramma PICK: strumento Lean per ridurre i tempi di setup. Aiuta il team ad organizzare ed assegnare le priorità alle idee di soluzione suddividendole in 4 categorie: possibile, da implementare, difficile, da annullare. o Strumenti Lean per gestire le code e ridurre il congestionamento e ritardi: Pooling: formazione del personale per intervenire nei momenti di picco di carico. Triaging: ordinare le attività in categorie che richiedono differenti livelli di impegno e sviluppare delle strategie apposite, con il giusto impiego di risorse. Capacità di riserva: per affrontare un picco di carico prolungato. Ridurre la variabilità nel tempo di lavorazione. o Defect Prevention: permette di individuare i punti critici del processo e effettuare l analisi della qualità, cercando di ridurre i controlli nella fase a valle per ridurre i costi. Abbiamo la Prevention prima che l errore possa accadere, la Detection prima che l errore sfugga al controllo, l Inspection dopo aver eseguito una certa qualità, la Rejection dopo che il prodotto è consegnato al cliente. Ci sono diverse tipologie di ispezione, dall ispezione tradizionale, dai controlli a campione, all autocontrollo. La tecnica principale è la correzione degli errori o Poka Yoke. o Poka Yoke: consente eliminare gli errori e di individuare le cause relative, poiché gli errori generano difetti e l insoddisfazione del cliente. 5.5 Control Una volta raggiunto un certo risultato, questo deve essere monitorato e protetto fino a quando non viene individuato un metodo migliore per far funzionare il processo. Il controllo si attua in sei passi: Il processo di miglioramento deve essere documentato, poiché le best pratics contenute nei documenti dovrebbero essere utilizzate regolarmente per svolgere quel processo specifico. Convertire sempre i risultati raggiunti in termini monetari, perché prima di poter validare il progetto deve essere identificato un buon ritorno economico in termini di ROIC. I benefici raggiunti sono monitorati costantemente. 37

43 Installare un sistema di monitoraggio automatico che rilevi le fasi fuori controllo, per esempio attraverso un cruscotto digitale web-based che fornisca i numeri in tempo reale relativi agli indicatori chiave del processo. Implementare in area pilota, ovvero un test in scala ridotta della soluzione, da far funzionare abbastanza a lungo per ottenere i dati necessari che permettano di individuare eventuali problemi che impediscano il corretto funzionamento del processo. Elaborare un piano di controllo per garantire che i requisiti siano soddisfatti nel tempo. Sintesi dettagliata Implementare le modifiche di processo ed i controlli opportuni; monitorare e stabilizzare il processo per assicurarsi che gli obiettivi vengano raggiunti. Sviluppare la SOP, il piano di Training e il sistema di controllo del processo affinché siano duraturi nel tempo; trasferire i miglioramenti del processo al Process Owner. Definire le linee guida verso le migliori soluzioni, assicurandosi la replicabilità del progetto nel tempo; calcolare i Benefit finanziari, ovvero i risparmi derivanti dal progetto; revisionare la fase di Control. Principali deliverable della fase di Control: o Ciclo PDCA o Deming Cycle: strumento per il miglioramento continuo della qualità, che si basa essenzialmente su quattro fasi: Plan: pianificazione. Do: esecuzione del programma di azione. Check: test e controllo, studio e raccolta dei risultati e dei feedback. Act: azione per rendere definitivo il miglior manto nel lungo periodo. o Control Chart & Visual Management. 5.6 Metodologia Kaizen nel DMAIC Per Kaizen intendiamo un applicazione che ricorre agli strumenti Lean per ridurre gli sprechi T.I.M.W.O.O.D. ed i relativi costi, migliorare la qualità, la velocità, la flessibilità, e la reattività alle esigenze del cliente. Tale applicazione è implementata da Team dedicati al conseguimento del miglioramento continuo in 3/5 giorni quando sono necessari risultati urgenti e si vuole accelerare il processo implementando interventi Lean nel breve periodo. Utilizzato nei casi in 38

44 cui le opportunità o le minacce del business sono facilmente individuabili, così come le soluzioni. La terminologia utilizzata è la seguente: Kaizen: miglioramento continuo. Kaikazu: cambiamento radicale. Jidoka: auto-rilevazione delle anomalie. 3M: Muda - spreco, Mura - anomalia, Muri - sforzo o stress. Gli step per implementare il Kaizen sono: 1. Identificare e pianificare le azioni da svolgere nel breve periodo, pre-evento che varia da 3 a 5 giorni. 2. Implementazione veloce delle azioni, evento Kaizen (3/5 giorni). 3. Proseguimento delle attività di miglioramento, follow-up dell evento da 15 a 20 giorni. La metodologia applicata al DMAIC: 1. Define: definire gli obiettivi, selezionare e formare un team di 6-8 persone, definire le attività logistiche da svolgere. 2. Measure: costruire la VSM individuando le fasi del processo, determinando il PLT, i Task Time ed il Waiting Time; definire il layout dei flussi delle pratiche con lo Spaghetti Diagram; raccogliere le misure per ogni fase del processo; individuare e separare le attività a valore aggiunto da quelle a non valore aggiunto attraverso la rilevazione delle spreco durante Brainstorming. 3. Analyze: determinare le cause radice degli sprechi del processo, i Waiting Time ed i PLT attraverso l analisi Takt Time (Takt Time Chart), individuare le possibili tecniche per eliminare gli sprechi; eliminare le attività non a valore aggiunto (NCVA); individuare le attività a valore aggiunto per il cliente (CVA) e per il Business (BVA); prioritizzare le idee migliori (Brainstorming). 4. Improve: creare una lista di azioni di miglioramento; implementare i processi di miglioramento formando i dipendenti, testando e ottimizzando i processi, preservando la sicurezza e la qualità del processo, assicurando la Process Capacity; adattare gli obiettivi di miglioramento rispetto a quanto deciso in fase di Define; ridurre WIP e PLT, incrementare la qualità e la produttività del processo (Training e Visual Management). 5. Control: creare procedure operative standard attraverso formazione del personale, metriche e cruscotti per il monitoraggio continuo, comunicazione e reporting continuo; presentazione dei risultati raggiunti e raggiungimento degli obiettivi di miglioramento. 39

45 Capitolo 6 Case Study 6.1 Incident Management Durante il periodo di stage svolto presso il Consorzio Operativo del Monte dei Paschi, nel periodo 3 Ottobre Dicembre 2011 ho preso parte al progetto Lean Consorzio. Il progetto è legato all implementazione della metodologia Lean Six Sigma a vari processi aziendali, ma il focus è rivolto al processo di Incident Management Mission ed Obiettivi Il processo di Gestione Incidenti/Incident Management è reattivo ed è finalizzato a ripristinare le operazioni normali di servizio il piu' velocemente possibile con la minima interruzione di servizio al business, assicurando che i migliori livelli di servizio e disponibilità siano mantenuti. 10 Il processo di Incident Management definisce la modalità di Gestione degli Incidenti di tipo tecnologico, considerati come tutti gli eventi che impattano negativamente sulla qualità dei servizi IT. Il processo di Gestione Incidenti ha come obiettivo principale la gestione dei malfunzionamenti, relativi a tutti i servizi nell ambito IT in erogazione ed all intera infrastruttura IT che li supporta. Obiettivi: Gestione del ciclo di vita dei Problemi, individuando la soluzione opportuna e definitiva all interno dell ambiente IT (velocità, efficacia ed efficienza). Documentazione degli Incidenti e aggiornamento dello strumento. Funzione Proattiva: prevenzione degli Incidenti e Problemi. Funzione Reattiva: risoluzione degli Incidenti correnti. Ripristino della normale operatività dei servizi, cercando di minimizzare l impatto sul Business, sia dell organizzazione sia degli utenti, garantendo la qualità e disponibilità del servizio Input ed Output del Processo Gli Input del processo Incident Management sono gli Incidenti, gli Eventi, le Richieste di 10 Documento CoMPS: Guida di Processo_Incident Management 40

46 Servizio, le Informazioni riguardanti l implementazione delle modifiche da attuare, le informazioni su infrastruttura e servizi IT, richieste da altri processi che sono innescati dagli input di Incident Management. Gli Output del processo Incident Management sono le richieste di modifiche, l Incidente risolto, le informazioni riguardanti l Incidente, richieste da altri processi che sono innescati dagli output di Incident Management Perimetro del Processo e Interazioni con altri Processi L Incident Management è parte del Macroprocesso Gestione della Sicurezza, ed ha dipendenze funzionali con altri processi del System Management. L ambito del processo riguarda l erogazione dei servizi IT e l infrastruttura che li supporta. In ambito (In Scope): Incidenti dal 1 Livello. Incidenti derivanti dall attività di monitoraggio. Sviluppo di una Soluzione Temporanea. Incidenti relativi alla Telefonia IP. Fuori ambito (Out of Scope): Incidenti relativi alla Telefonia Mobile. Incidenti di Sicurezza. L Incident Management innesca i seguenti sotto processi: Gestione dei Problemi (Problem Management): analizzare gli Incidenti ricorrenti in modo da prevenire la causa alla base del malfunzionamento e formulare una Soluzione. L Incident Management è innescato dai seguenti sotto processi: Gestione degli Eventi (Event Management): rilevare un evento legato ad un malfunzionamento che potrebbe essere la causa scatenante di un Incidente. Gestione modifiche allo Sviluppo ICT (Modello per lo Sviluppo): applicare le opportune modifiche applicative a progetti software. Gestione rilasci in Produzione di Soluzioni Infrastrutturali (Release and Deployment Management): rilevare dei malfunzionamenti nel momento in cui sono rilasciati in produzione nuovi servizi. Passaggio in Produzione (Modello per lo Sviluppo): identificare la causa e la soluzione che impedisce il rilascio in produzione del software applicativo. 41

47 Monitoraggio Esecutivo di Progetto (Modello per lo Sviluppo): rilasciare gli input di conferma dell implementazione di una modifica software. L Incident Management interfaccia i seguenti sotto processi: Gestione delle Richieste di Servizio (Request Fulfillment): rilevare eventuali Richieste di Servizio aperte non in modo corretto o tipologie di intervento autorizzate. Gestione delle modifiche Infrastrutturali e Correttive (Change Management): modificare il software da utilizzare (modifiche infrastrutturali e correttive). Gestione Incidenti di Sicurezza Logica (Information Security Management): gestire malfunzionamenti in ambito di Sicurezza Logica Strumenti a supporto REMEDY: applicativo di Help Desk che raccoglie le segnalazioni di Incidenti con la conseguente interruzione del servizio, sia da fonti esterne come telefono o oppure da fonti interne come ticket generati dallo stesso applicativo (DSO), ma a livelli diversi di HD oppure da operatori. Permette la tracciabilità dell intero Incidente, dalla segnalazione alla risoluzione. Strumento integrato che permette di ridurre il numero dei problemi da gestire ed il tempo medio di risoluzione. La gestione integrata dell infrastruttura e dei processi IT permette una migliore e più corretta gestione dell ambiente IT, accentrando tutti i processi di cui si compone, dall Asset Management al Change Management, fino al Problem e Configuration Management. Comporta una maggiore efficienza dei processi, un maggiore controllo sui costi IT ed un aumento della qualità dei servizi erogati al cliente. Figura 6.1 Interfaccia Applicativo REMEDY 42

48 CMDB: Configuration Management Data Base è un deposito della conoscenza / informazioni relative a tutti i componenti di un Sistema Informativo. Contiene tutti i dettagli degli elementi che stanno alla base della configurazione nelle infrastrutture IT, permettendo di determinare l impatto e l urgenza della soluzione. Tools asset Management Glossario Acronimi Acronimo CoMPS DCI Framework DSO GBS GC GCO GCS GDS GE GF GI GIT GMI GMS GP GPA - MM GRPI GRPS GRS GISL KPI ITIL Esteso Consorzio Operativo MPS Service Level Management Definizione convenzioni infragruppo Quadro di riferimento Distributed Service Option per l inserimento in REMEDY del Ticket Asset Management Gestione beni strumentali IT Capacity Management Gestione capacità infrastruttura IT IT Service Continuity Management Gestione della continuità operativa Service Catalog Management Gestione del Catalogo dei Servizi IT Availability Management Gestione della disponibilità dei Servizi IT Event Management Gestione eventi Supplier Management Gestione Fornitori Incident Management Gestione Incidenti Configuration Management Gestione informazioni infrastruttura e servizi IT Change Management Gestione modifiche infrastrutturali e correttive Change Management Gestione modifiche allo Sviluppo ICT Problem Management - Gestione Problemi Measurement & control - Gestione dei processi aziendali Release and Deployment Management - Gestione rilasci in produzione di soluzioni infrastrutturali Passaggio in produzione Request Fulfillment - Gestione richieste di servizio Information Security Management - Gestione incidenti di sicurezza logica Key Performance Indicator IT Infrastructure Library Tabella 6.2 Glossario Acronimi 43

49 6.1.6 Unità Organizzative e Ruoli Il processo Incident Management ricorre ad una serie di strutture interne ed esterne al Consorzio Operativo del MPS che si dividono in: Help Desk di 1 livello: Fornitore Esterno. Help Desk di 1 livello: HD Interno. o Gestisce le chiamate degli Utenti dei servizi che il COG offre alla Banca, e si suddivide nelle diversi sedi, dislocate nel territorio Italiano: Siena, chiamate relative ai Servizi Credito ed Estero. Mantova, chiamate relative ai Servizi Bancari e Contabili. Lecce, chiamate relative ai Servizi Investimenti e Marketing. Help Desk di 1 livello: HD Esterno. o Gestisce le chiamate degli Utenti dei servizi che la Banca offre al cliente, come l Home Banking ed il Corporate Banking. Help Desk di 2 livello, Tecnico (sede di Siena e Firenze). o La struttura si suddivide in due parti: Segnalazioni Incidenti da Utenti periferici: Filiali e Uffici DG, che contattano direttamente l HD di 1 Livello e se non in grado di identificare una soluzione, scalerà la chiamata all HD Tecnico. Ticket Diario Incidenti: qualsiasi operatore del COG, deve aprire una segnalazione in caso di malfunzionamento, che possa degradare l immagine dell azienda o impattare sull operatività del servizio. Il Tavolo di Regia si occupa della gestione delle segnalazioni, e se ritiene opportuno può trasformarle in Incidenti generando un ticket da assegnare ai diversi responsabili delle strutture. Help Desk di 3 livello, Strutture Specialistiche. L HD è un servizio che fornisce informazioni e assistenza a tutti gli utenti che ne richiedono l impiego, attraverso un software che consente di tracciare le segnalazioni ricevute. L obiettivo è gestire situazioni problematiche riguardanti la fruizione di un servizio o l utilizzo di un prodotto da parte di un utente, ripristinando la corretta operatività. Tipici malfunzionamenti / Incidenti sono relativi a problematiche Hardware (configurazioni PC / Posto Di Lavoro, 44

50 Stampanti / Multifunzione..), problematiche Software (gestione e installazione Applicativi in genere), problematiche di Networking (installazioni, gestioni e configurazioni Reti, Modem, Router, ), problematiche WEB. I tre Livelli sono caratterizzati da alcune tipologie di Help Desk, dotati di funzionalità e competenze diverse, con la possibilità di gestire una gamma ampia di richieste. Il 1 Livello ha competenze per gestire problemi di base che potrebbero essere risolti o con una FAQ o con la semplice esperienza personale. Se la soluzione non viene individuata, allora è necessaria un escalation funzionale ai Livelli successivi ( ), per permettere la risoluzione definitiva del malfunzionamento. Il 3 Livello, disponendo di competenze ed esperienze elevate, necessariamente ha l obbligo di identificare la più opportuna soluzione per ripristinare la corretta operatività. Ovviamente ogni Livello può comunicare l esito positivo della risoluzione all utente finale. Ogni livello individua specifiche figure professionali, con proprie responsabilità per garantire un processo che al tempo stesso sia fluido ed efficiente. La corrispondenza tra il ruolo funzionale svolto e la singola persona non è biunivoca, ma una risorsa può ricoprire più figure professionali, e una figura professionale può essere assegnata a più risorse. Il processo si compone di tre ruoli funzionali: Incident Manager: responsabile della corretta esecuzione del processo. Coordinare le attività e le risorse operative. Focal Point per il team nella gestione dei malfunzionamenti. Responsabile di numero e livello delle competenze delle risorse team durante la valutazione e la modifica. Responsabile della revisione post risoluzione dell incidente. Incident Assignee: responsabile della gestione dell incidente e dell apertura del ticket (DSO) nel momento in cui avviene il malfunzionamento. Rilevare e registrare il malfunzionamento attraverso l apertura del ticket. Assegnare la categoria e la priorità all Incidente. Identificare un Incidente Grave, di Sicurezza, Richiesta di Servizio. Ricercare una Soluzione Temporanea. Effettuare l escalation funzionale al gruppo di supporto competente. Risolvere il malfunzionamento con la Soluzione Temporanea. Verificare il ripristino del servizio. 45

51 Chiusura dell Incidente e aggiornamento del ticket. Presenza del Tavolo di Regia che si occupa della gestione delle segnalazioni dei vari Utenti, e che se ritiene opportuno può trasformarle in Incidenti generando un ticket da assegnare ai diversi responsabili delle strutture. Incident Analyst: responsabile di uno o più ambiti di competenza e nel fornire un analisi dell Incidente ed una soluzione per ripristinare il servizio. Coinvolto dall Incident Assignee quando non c è una risoluzione. Analizzare l Incidente Grave fornendo un supporto per la ricerca di una Soluzione Temporanea. Identificare o sviluppare una Soluzione Temporanea e documentazione. Definire un piano di risoluzione dell Incidente. Risolvere l Incidente applicando la Soluzione Temporanea. Revisionare la documentazione post risoluzione. Segnalazione di Problemi. Ripristino del servizio. Figura 6.3 Struttura organizzativa del processo Gestione della Sicurezza 46

52 6.1.7 Flusso del Processo standard Il processo utilizza una terminologia necessaria per poter capire ed affrontare l operatività quotidiana coerente con le best practices ITIL v3: Incident: ogni evento che non costituisce parte dell esercizio standard di un servizio e che causa, o potrebbe causare, una interruzione o la riduzione della qualità del servizio. Un Problema è la causa di o più incidenti. Tempi di risoluzione: tempi di risoluzione degli Incident devono essere concordati per ogni livello di gestione e possono differire in base al livello di priorità individuato. Essi sono concordati e accettati nel Service Level Agreement (SLA). Incidente Grave o Major Incident: Incidente con impatto molto elevato sull utente oppure con alto livello di urgenza. Workaround: Soluzione temporanea per evitare difficoltà tecniche. Il processo Gestione Incidenti utilizza come riferimento il framework IT Infrastructure Library, una libreria di best practices nel Service Management di alto livello. L ITSM si suddivide in due aree principali, che a loro volta sono composte da processi correlati e interagenti: Service Delivery e Service Support. Il Service Support si scompone nei processi di Service Desk, di Incident Management, di Problem Management, di Configuration Management, di Change Management e di Release Management. I tre principali obiettivi dell ITSM sono: Incrementare la qualità dei servizi IT erogati al cliente. Ottimizzare i costi di erogazione dei servizi. Garantire la corretta erogazione dei servizi per il cliente e le necessità del Business aziendale. L ITIL v3, a cui si fa riferimento rappresenta un evoluzione delle best practices ITIL, un miglioramento continuo che introduce nuovi concetti e cambiamenti della versione base ITIL. I maggiori cambiamenti si evidenziano nell introduzione del LifeCycle dei servizi, si definiscono le integrazioni fra la strategia di business e la fornitura del servizio IT, si introduce il concetto di ROI che consente una migliore valutazione dell output, vengono fornite informazioni più dettagliate per gli specifici processi dell ITSM. I benefici nel ricorrere a questo tipo di tecnologia sono molteplici: Coordinamento fra strategia di business e del servizio IT. 47

53 Monitoraggio e controllo continuo in un ambiente altamente dinamico, ad alto rischio e ad alta volatilità, per l identificazione delle criticità più impattanti. Monitoraggio e controllo continuo della fornitura esterna e dei loro modelli. Migliore progettazione del servizio attraverso il miglioramento continuo nel Ciclo di Vita del servizio, e con l impiego di modelli di transizione adatti per rispondere alle innovazioni esistenti. Le fasi di cui si compone il processo sono correlate in un flusso sequenziale: 1. Rilevare e Registrare il malfunzionamento. Fase iniziale in cui si cerca di identificare il malfunzionamento in modo da attivare le strutture competenti per la sua gestione in tempi rapidi. Viene aperto un ticket (DSO) relativo all Incidente, all interno dell applicativo, raccogliendo tutte le informazioni necessarie del malfunzionamento. a. Attività svolta da Utente GI Segnalare il malfunzionamento. Segnalazione da Cliente esterno tramite telefonata, interfaccia web oppure e- mail; da Utente tramite telefonata, interfaccia web oppure , Personale Tecnico; Processi esterni (GRPI, GRPS, GE). b. Attività svolta da Incident Assignee di ogni Livello GI Aprire il ticket e ricerca informazioni. Controllare e validare il profilo dell Utente ed aprire il ticket (DSO) all interno dello strumento applicativo, contenente un identificativo univoco, il nome dell Utente, data e orario, il canale adottato per la segnalazione. L Incident Assignee compila un ulteriore campo note specificando dettagli sulle cause in modo da facilitare la successiva fase di analisi; inoltre identifica i beni strumentali impattati ricercando le informazioni all interno del Configuration Management Data Base. Di seguito viene riportata la Matrice RACI, Ruolo-Responsabilità della fase numero 1: Codice attività GI Utente Assignee Analyst 2 Livello A/R GI C A/R Analyst 3 Livello Manager Tabella 6.4 Matrice RACI fase1 2. Classificare l Incidente e fornire il supporto iniziale. 48

54 Fase successiva in cui si classifica l Incidente specificando la categoria e la priorità in conformità a valutazioni impatto-urgenza del malfunzionamento, attraverso criteri appartenenti allo strumento applicativo del processo. La fase prosegue con la ricerca di Soluzioni Temporanee già utilizzate per, ripristinare il servizio in tempi molto brevi. Se non ci sono disponibili Soluzioni, l Incidente è assegnato al 2 Livello attraverso un escalation funzionale. Tal volta possono verificarsi Incidenti Gravi con elevata urgenza, che sono trattati in modo dedicato. a. Attività svolta da Incident Assignee 11 GI Categorizzare il malfunzionamento. Classificare il malfunzionamento sulla base delle informazioni contenute nel ticket (DSO), ricorrendo ad un albero decisionale contenuto nello strumento. Questa fase può generarsi dall attività GI oppure da GISL. b. Attività GI Incidente di Sicurezza? Se è identificato tale Incidente, viene attivato il processo GISL che si occuperà di dare priorità e gestire la situazione nel modo opportuno. Nel caso, in cui, l Incidente non possa essere gestito dal processo GISL, si cerca di verifica se tale malfunzionamento è reale, oppure si tratta semplicemente di una Richiesta di Servizio. c. Attività GI Service Request? Attraverso un opportuno controllo, è possibile individuare una Richiesta di Servizio segnalata erroneamente come un Incidente. Si attiva quindi il processo GRS per una corretta gestione. Nel caso, in cui, sia realmente un malfunzionamento, si procede con la fase di prioritizzazione gestita dall attività GI d. Attività GI Attribuire Impatto e Urgenza. Calcolare l impatto e l urgenza attraverso criteri definiti e condivisi, considerando il probabile effetto che l Incidente potrà avere sul processo di Business. La stessa codifica è poi utilizzata per la definizione di impatto e urgenza del Problem. Tale impatto, terrà conto se l Utente che ha effettuato la segnalazione è VIP, sulla base del ruolo che ricopre nella struttura organizzativa. La priorità è assegnata in automatico dallo strumento in base ai valori ricavati dall equazione:. 11 Tutte le attività della fase Classificare l Incidente e fornire il supporto iniziale sono svolte dall Incident Assignee di 2 Livello 49

55 e. Attività GI Incidente Grave? Controllare il livello di priorità, assegnando livelli alti di impatto e urgenza ad un Incidente Grave, che dovrà essere gestito con rapidità ed in modo dedicato. Procedere con l attività GI Se l Incidente non è critico, si procede alla ricerca di una Soluzione Temporanea GI f. Attività GI Notificare Incidente Grave. Escalation gerarchica con Notifica di Incidente Grave alla Direzione Generale, A.D. e ad altri attori coinvolti. Si può procedere ad individuare una Soluzione Temporanea GI g. Attività GI Cercare una Soluzione Temporanea dell Incidente. Ricercare una Soluzione Temporanea adatta, già utilizzata con successo. h. Attività GI Soluzione Temporanea disponibile? Controllare la presenza di un Soluzione Temporanea da applicare, procedendo con l assegnazione del ticket all Incident Analyst di 2 Livello se tale non è disponibile (attività GI.02.09), oppure procedere con l attività GI di risoluzione dell Incidente. i. Attività GI Assegnare Incidente. Nel momento in cui la Soluzione Temporanea non sia disponibile, si esegue un escalation funzionale all Incident Analyst di 2 Livello, che cercherà di identificare la soluzione opportuna. Di seguito viene riportata la Matrice RACI, Ruolo-Responsabilità della fase numero 2: Codice attività GI GI GI Utente Assignee Analyst 2 Livello A/R A/R A/R Analyst 3 Livello Manager GI R A GI R C A GI I A/R GI GI A/R A/R GI A/R I 3. Analizzare e Diagnosticare l Incidente. Tabella 6.5 Matrice RACI fase2 50

56 Fase intermedia in cui le due principali attività sono analisi dell Incidente e di tutte le informazioni ad esso associate e diagnosi con l obiettivo di individuare una Soluzione Temporanea da applicare al malfunzionamento. In alcuni casi si può interrogare direttamente l Utente che ha effettuato la segnalazione e lo strumento a supporto del processo, per ottenere maggiori informazioni con conseguente velocizzazione del piano di risoluzione. Tutti gli Incidenti non risolvibili, vengono scalati tramite un apposita escalation funzionale, verso ulteriori Livelli con competenze specifiche. a) Attività GI Approfondire e Valutare l Incidente. Raccogliere le informazioni riguardanti l Incidente, necessarie per la gestione ed eventualmente per l analisi e la diagnosi; inoltre capire la storia del ticket (DSO) con tutti gli elementi registrati. L Incident Assignee può decidere se contattore le fonti per la ricerca delle informazioni (l Utente che ha effettuato la segnalazione o l Incident Assignee che ha aperto il ticket), raccogliere documentazione aggiuntiva, avvalersi dell esperienza personale maturata, raccogliere informazioni all interno del CMDB (Configuration Item impattati). b) Attività GI Incidente Grave? Controllare se il ticket (DSO) è riferito ad un Incidente Grave, indirizzando l operatività verso due vie: escalation funzionale all Incident Assignee di 3 Livello se l Incidente è catalogato come grave, proseguendo con l attività GI.03.05; l Incidente è catalogato come non grave, allora si prosegue con l attività GI c) Attività GI Ricercare Soluzioni Temporanee e alternative per risolvere l Incidente. Ricercare una Soluzione Temporanea impiegata per la risoluzione di Incidenti con causa comuni o simili. d) Attività GI Soluzione Temporanee disponibili? Individuare la possibile Soluzione Temporanea, se c è la disponibilità si prosegue con l attività GI.03.02, altrimenti avviene l escalation funzionale al 3 Livello che proseguirà con l attività GI e) Attività GI Progettare Soluzioni Temporanee definendo un Piano. Può accadere che non sia disponibile una Soluzione Temporanea, allora l Incident 12 Le attività fino a GI della fase Analizzare e Diagnosticare l Incidente sono svolte dall Incident Assignee di 2 Livello 13 Attività della fase Analizzare e Diagnosticare l Incidente svolta dall Incident Assignee di 3 Livello 51

57 Assignee di 3 Livello dovrà individuarne una apposita, attraverso l utilizzo degli strumenti e dell esperienza professionale maturata. L operatore dovrà poi creare un piano di risoluzione e creare un record all interno dello strumento, sviluppando conoscenza condivisa che sarà utile per situazioni analoghe future. Di seguito viene riportata la Matrice RACI, Ruolo-Responsabilità della fase numero 3: Codice attività Utente Assignee Analyst 2 Livello GI C C A/R GI C C A/R GI GI A/R A/R Analyst 3 Livello Manager GI C R A Tabella 6.6 Matrice RACI fase3 4. Risolvere l Incidente e Ripristinare il servizio. Fase in cui viene applicata la Soluzione Temporanea individuata, ed avviene la verifica del ripristino del servizio. Eventualmente si attivano i processi GMS e GMI nel caso la Soluzione richieda una modifica, per valutare gli impatti e coordinare l implementazione. a. Attività svolta da Incident Assignee di 1 Livello GI Applicare il Piano risoluzione all Incidente di 1 Livello. Questa attività viene svolta, nel momento in cui è stata individuata la Soluzione Temporanea, nel corso dell attività GI L Incident Assignee dovrà decidere se comunicare le istruzioni da seguire all Utente per applicare la Soluzione, oppure applicarla direttamente da remoto. b. Attività svolta da Incident Assignee di 2 Livello GI Applicare il Piano risoluzione all Incidente di 2 Livello. Questa attività viene svolta, nel momento in cui è stata individuata la Soluzione Temporanea, nel corso dell attività GI L Incident Assignee dovrà decidere se comunicare le istruzioni da seguire all Utente per applicare la Soluzione, oppure applicarla direttamente da remoto. c. Attività svolta da Incident Assignee di 3 Livello GI Applicare il Piano risoluzione all Incidente di 3 Livello. Questa attività viene svolta, nel 13 Attività della fase Analizzare e Diagnosticare l Incidente svolta dall Incident Assignee di 3 Livello 52

58 momento in cui è stata individuata la Soluzione Temporanea, nel corso dell attività GI L Incident Assignee dovrà decidere se comunicare le istruzioni da seguire all Utente per applicare la Soluzione, applicarla direttamente da remoto, oppure attivare le strutture del processo GMS, nel caso si richieda l implementazione di una modifica infrastrutturale o software. d. Attività svolta da Incident Assignee di 3 Livello GI Necessaria modifica? Nel caso in cui si debba implementare una modifica per l applicazione di una Soluzione Temporanea, l Incident Assignee richiede l intervento del processo GMS per eventuali modifiche infrastrutturali e/o software su progetti chiusi, tramite una Request for Change (anche nel caso di Incidenti Gravi). Si dovrà valutare l impatto della modifica, attivando le strutture competenti. Nel caso di una modifica software per progetti aperti, per la conseguente applicazione di una Soluzione Temporanea, l Incident Assignee richiede l intervento del processo GMI, tramite una Request for Change. Nel caso non sia necessaria nessuna modifica, si procede con l attività GI e. Attività svolta da Incident Assignee di 1 Livello GI Verificare e Validare il ripristino del servizio. Applicata la Soluzione Temporanea / modifiche, si verifica la normale operatività del servizio interrotto, contattando l Utente. f. Attività svolta da Incident Assignee di 1 Livello GI Servizio ripristinato? Valutare se il ripristino del servizio è effettivo dopo l applicazione della Soluzione Temporanea. Se il servizio è ripristinato correttamente, si chiude l Incidente ed il relativo ticket, con l attività GI.05.01; se il servizio non è stato ripristinato correttamente, l Incident Assignee procederà con l attività GI per poter indirizzare correttamente l Incidente. Di seguito viene riportata la Matrice RACI, Ruolo-Responsabilità della fase numero 4: Codice attività Utente Assignee Analyst 2 Livello GI I A/R GI I A/R Analyst 3 Livello GI I A/R GI Manager GI C R A GI C R A A/R Tabella 6.7 Matrice RACI fase4 53

59 5. Chiudere l Incidente. Fase ultima del processo in cui si chiude l Incidente, una volta che il servizio è stato ripristinato, è stata eseguita la comunicazione all Utente ed è stata redatta tutta la documentazione necessaria. Successivamente, è possibile valutare la causa dell Incidente, aprendo un Problema, attraverso il Problem Management, per evitare che si ripresenti e cercando una Soluzione duratura nel tempo. a. Attività svolta da Incident Assignee di ogni Livello GI Completare le informazioni sull Incidente e Aggiornare la categoria. Verificare che il ticket (DSO) sia completo, per assicurare una corretta e completa classificazione ed analisi del trend dell Incidente prima della chiusura. Verificare la presenza della Soluzione Temporanea adottata nella documentazione, per poterla utilizzare eventualmente negli Incidenti Gravi con particolare impatto e urgenza. b. Attività svolta da Incident Assignee GI Chiudere l Incidente e Notificare la chiusura. Chiusura formale del ticket (DSO) relativo all Incidente e notifica all Utente che aveva effettuato la segnalazione. c. Attività svolta da Incident Assignee GI Valutare il riverificarsi dell Incidente. Valutare la possibilità che l Incidente si ripresenti, se la causa non è stata rimossa in modo definitivo appoggiandosi al processo GP. d. Attività svolta da Incident Assignee GI Apertura del Problem? Necessità di aprire un Problema per identificare e rimuovere in modo definitivo la causa radice dell Incidente. Nel caso in cui, si percepisce che l Incidente potrebbe ripresentarsi viene attivato il processo GP, altrimenti il processo di Incident Management può concludersi. Di seguito viene riportata la Matrice RACI, Ruolo-Responsabilità della fase numero 5: Codice attività Utente Assignee Analyst 2 Livello Analyst 3 Livello GI A/R C C GI I A/R Manager GI R C C A GI R C C A Tabella 6.8 Matrice RACI fase5 54

60 Sintesi grafica del Processo: [GI.01] Rilevare e registrare il malfunzionamento Interfacce Tool Incident Assignee Utente Fasi/Sottoprocessi Segnalare Malfunzionamento [GI.01.01] GE GRPS GRPI Aprire il ticket e ricercare ulteriori informazioni sul malfunzionamento [GI.01.02] Strumento di Gestione Incidenti Tool di Asset management [GI.02.01] Classificare il malfunzionamento e fornire supporto iniziale Incidente Registrato CMDB Figura 6.9 Rilevare e Registrare il malfunzionamento Segnalare il Malfunzionamento GI Aprire il Ticket e ricercare ulteriori informazioni sul malfunzionamento GI

61 [GI.02] Classificare l Incidente e fornire supporto iniziale Interfacce Incident Assignee Utente Fasi/Sottoprocessi No [GI.01.02] Rilevare e registrare il malfunzionamento Incidente Registrato GISL Categorizzare il malfunzionamento [GI.02.01] GISL Sì Incidente sicurezza? [GI.02.02] No GRS Sì Service Request? [GI.02.03] No Attibuire impatto e urgenza [GI.02.04] Sì Incidente Grave? [GI.02.05] Ricevere La Notifica Dell Incidente Grave Notifica alla Direzione Notificare Incidente Grave [GI.02.06] No Incidente Grave Cercare una soluzione temporanea all Incidente [GI.02.07] [GI.04.01] Risolvere l Incidente e ripristinare il servizio Soluzione temporanea disponibile Sì Soluzione temporanea disponibile? [GI.02.08] [GI.04.06] Risolvere l Incidente e ripristinare il servizio Servizio NON ripristinato No [GI.03.01] Analizzare e diagnosticare l Incidente Incidente Classificato Assegnare l Incidente [GI.02.09] Tool Strumento di Gestione Incidenti Figura 6.10 Classificare l'incidente e fornire il supporto iniziale Categorizzare il Malfunzionamento GI Incidente di Sicurezza GI Service Request GI Attribuire Impatto e Urgenza GI Incidente Grave GI Notificare Incidente Grave GI Cercare una Soluzione temporanea GI Soluzione temporanea disponibile? GI Assegnare l Incidente GI

62 [GI.03] Analizzare e diagnosticare l Incidente No Interfacce Incident Analyst 2 Livello Utente Fasi/Sottoprocessi [GI.02.09] Classificare l incidente e fornire supporto iniziale Incidente Classificato Approfondire e valutare l incidente [GI.03.01] GMI Cambiamento infrastrutturale e/o SW progetto chiuso rifiutato GMS Cambiamento SW progetto aperto rifiutato Incidente Grave? [GI.03.02] Si No Ricercare soluzioni temporanee alternative per risolvere l incidente [GI.03.03] Soluzione temporanea disponibile? [GI.03.04] No [GI.04.02] Risolvere l Incidente e ripristinare il servizio Piano di risoluzione dell Incidente Sì [GI.04.03] Risolvere l Incidente e ripristinare il servizio Piano di risoluzione dell Incidente Incident Analyst 3 Livello Progettare soluzione temporanea per incidente e definire un piano [GI.03.05] Strumento di Gestione Incidenti Tool Tool di Asset management CMDB Figura 6.11 Analizzare e Diagnosticare l Incidente Approfondimento e valutare l incidente GI Incidente Grave GI Ricercare Soluzioni temporanee alternative GI Soluzione temporanea disponibile? GI Progettare Soluzioni temporanee e definire un piano GI

63 [GI.04] Risolvere l Incidente e ripristinare il servizio Utente Confermare Il Ripristino Del Servizio Interfacce Fasi/Sottoprocessi [GI.02.08] Classificare l incidente e fornire supporto iniziale Soluzione temporanea Disponibile [GI.03.04] Analizzare e diagnosticare l Incidente Piano di risoluzione [GI.03.05] Analizzare e diagnosticare l Incidente GMS RFC SW progetto aperto GMI RFC Infrastruttura e/o SW progetto chiuso GMI Modifica Infrastruttura e/o SW progetto chiuso implementata MEP Modifica SW progetto aperto Implementata [GI.02.09] Classificare l incidente e fornire supporto iniziale Servizio NON ripristinato [GI.05.01] Chiudere l Incident Incidente Risolto dell Incidentde Piano di risoluzione No Incident Assignee Applicare piano di risoluzione incidente al 1 livello [GI.04.01] dell Incidentde Verificare e validare il ripristino del servizio [GI.04.05] No Servizio ripristinato? [GI.04.06] Sì Incident Analyst 2 Livello Applicare piano di risoluzione incidente al 2 livello [GI.04.02] Incident Analyst 3 Livello Applicare piano di risoluzione incidente al 3 livello [GI.04.03] Sì Necessaria modifica? [GI.04.04] No Tool Strumento di Gestione Incidenti Figura 6.12 Risolvere l'incidente e Ripristinare il servizio Applicare il piano di risoluzione al 1 Livello GI Applicare il piano di risoluzione al 2 Livello GI Applicare il piano di risoluzione al 3 Livello GI Necessaria modifica? GI Verificare e validare il ripristino del servizio GI Servizio ripristinato? GI

64 [GI.05] Chiudere l Incidente Utente Ricevere La Notifica Di Chiusura Del Ticket Interfacce Fasi/Sottoprocessi [GI.04.06] Risolvere l Incidente e ripristinare il servizio Incidente Risolto Notifica di chiusura del ticket GP Sì No Incident Assignee Completare le informazioni sull incidente e aggiornare categoria [GI.05.01] Chiudere l Incidente e notificare la chiusura [GI.05.02] Valutare il riverificarsi dell Incidente [GI.05.03] Apertura Problem? [GI.05.04] No End Tool Strumento di Gestione Incidenti Figura 6.13 Chiudere l'incidente Completare le informazioni sull Incidente e aggiornare la categoria GI Chiudere l Incidente e notificare la chiusura GI Valutare il riverificarsi dell Incidente GI Apertura Problem GI End 59

65 6.1.8 KPI del processo Esistono tre macro categorie di Key Performance Indicator, che si suddividono in: Assicurare la soddisfazione degli utenti finali in merito all'offerta di servizi e ai livelli di servizio: KP_XXX_Valore_GI_001: % di Incidenti gestiti entro i tempi di risoluzione concordati (rapporta il totale degli Incidenti gestiti entro i tempi di risoluzione concordati (SLA) al totale degli Incidenti gestiti nell intervallo di riferimento). Misurazione mensile con unità di misura percentuale. KP_XXX_V_GI_002: % di Incidenti chiusi da HD di 1 Livello (calcola la percentuale degli incidenti chiusi dal primo livello, senza rivolgersi ai successivi livelli di supporto, sul totale degli incidenti gestiti). Misurazione mensile con unità di misura percentuale. KP_XXX_Conformità_GI_001: Frequenza di abbandono delle chiamate (calcola il numero di chiamate abbandonate dall Utente, che quindi non ricevono risposta entro un intervallo concordato). Misurazione mensile con unità di misura numero intero. Assicurare un idoneo utilizzo e adeguate performance delle soluzioni applicative e tecnologiche: KP_XXX_V_GI_001 KP_XXX_V_GI_002 Assicurare che i servizi IT siano disponibili quando richiesto: KP_XXX_Qualità_GI_001: Numero totale di Incidenti (calcola la quantità di malfunzionamenti gestiti dal processo in un determinato intervallo temporale). Misurazione di tipo mensile percentuale. 60

66 KP_XXX_Q_GI_002: Numero di Major Incident (misura puntualmente il numero di Incidenti Gravi in un determinato intervallo temporale). Misurazione mensile con numero intero. KP_XXX_Q_GI_002: % di Major Incident (calcola la percentuale di Incidenti Gravi gestiti dal processo rispetto al totale di tutti gli incidenti). Misurazione mensile percentuale. KP_XXX_Prestazioni_GI_001: Tempo di risoluzione degli Incidenti (calcola il tempo medio di risoluzione di un Incidente. Indica la capacità del processo di gestire rapidamente ed in modo efficace gli incidenti). Misurazione mensile con unità di misura tempo. KP_XXX_V_GI_

67 Capitolo 7 DMAIC 7.1 Gantt Strumento di supporto alle Gestione dei Progetti che permette di pianificare l allocazione delle risorse. Tempistiche. Risorse Umane. Attività. La durata del progetto Lean Six Sigma è stata stimata in circa tre mesi, dal 5 Ottobre 2011 fino al 22 Dicembre 2011, con una fase finale di Control che si protrarrà anche nei mesi successivi. Fase di Define: 5 Ottobre 26 Ottobre. Fase di Measure: 27 Ottobre 25 Novembre. Fase di Analyze: 7 Novembre 5 Dicembre. Fase di Improve: 5 Dicembre 22 Dicembre. Fase di Control: Dicembre ancora in corso. Figura 7.1 Gantt 62

68 7.2 Kick Off di progetto Presentazione del progetto, in cui sono evidenziati gli aspetti principali. Gli Obiettivi e l Ambito del progetto / cantiere: Motivazioni: Assorbimento di Full Time Equivalent (FTE) o Risorse a tempo pieno impiegate nell operatività del processo. Livello di servizio richiesto dal processo, in termini di Service Level Agreement (SLA) o Accordi sul Livello di Servizio, ovvero strumenti attraverso i quali si definiscono le metriche del servizio erogato. Rischio Operativo, connesso alle possibili ripercussioni del mancato funzionamento del processo e dei servizi correlati. Obiettivi: Aumentare la Velocità del processo riducendo gli Sprechi. Sviluppare le performance del processo in termini di trade-off tra Qualità e ottimizzazione dei Costi focalizzandoci sul valore creare per il Cliente (massimizzare la Customer Satisfaction). Deliverables: gli strumenti del LSS. L Organizzazione del progetto / cantiere: Organigramma: Comitato Guida. Responsabile di Progetto. PMO. Comitato Operativo. Unità Organizzative. Processo interessato: Incident Management Relazioni: Problem, Change, Configuration e Asset Management. Matrice Obiettivi Responsabilità (RACI). Risorse coinvolte (FTE). La Pianificazione del progetto / cantiere: Allocazione delle Risorse. 63

69 Orizzonte temporale: 5 Ottobre Dicembre Prossimi momenti di comunicazione. 7.3 Define Identify Key Business Issues Con la fase di Define, il nostro scopo è di identificare il processo da ottimizzare, migliorare e correggere, traducendo le necessità del cliente in requisiti base. Da questa fase ci aspettiamo di specificare gli obiettivi del progetto, le risorse coinvolte, l orizzonte temporale, le risorse umane e l impatto sul business. L innovazione e la potenza di questa fase deriva dal metodo con cui viene realizzata. Brainstorming e coinvolgimento globale delle risorse aziendali sono gli aspetti chiave. Durante tutte le ore degli incontri, il metodo che abbiamo utilizzato per costruire i deliverables è stato attraverso il dialogo, l interazione, il coinvolgimento di tutte le risorse presenti e libertà di espressione soprattutto riguardo gli aspetti negativi incidenti sulle performance del processo. Tutti i deliverables sono stati realizzati tramite semplici post-it apposti sulla parete della stanza, riportanti la macro o micro fase del processo, le criticità evidenziate, i KPI, le forme di spreco T.I.M.W.O.O.D, e tutti gli altri elementi appartenenti al processo di Incident Management. Questa è una tecnica di Visual Management, che consente di identificare rapidamente il processo in questione nella sua globalità, monitorare ogni singola attività con le relative criticità, coinvolgere tutte le risorse e accelerare il piano di azione per il miglioramento continuo Pain Point Workshop La fase di Define è iniziata con la partecipazione delle risorse coinvolte nel processo, al Pain Point. Il deliverable prodotto dal PPW è una descrizione ad alto livello del processo costruita evidenziando le macrofasi in cui è strutturato, le principali criticità / mal di pancia ( Mappa dei Punti di Dolore ) ed i principali Key Performance Indicator su cui agire. Il primo passo da cui siamo partiti per la costruzione del PPW è stato individuare i responsabili del processo di Incident Management e i principali attori coinvolti direttamente e con maggiore esperienza riguardante l operatività quotidiana. L obiettivo era di acquisire una conoscenza di massima del processo, utilizzabile poi per la costruzione dei deliverables successivi. Durante le ore dell incontro sono emerse le principali macrofasi sottostanti il processo con le principali criticità. Il PPW presenta la forma di una mappa orizzontale, realizzata tramite 64

70 semplici post-it colorati, riportanti la Fase del processo (colore bianco), le Criticità (colore giallo) e i KPI (colore arancione), e apposti su una parete della stanza. Le principali linee guida seguite per la realizzazione del deliverable sono state: 1. Individuare le macrofasi del processo. 2. Capire attraverso il personale coinvolto, le principali criticità del processo. 3. Dirigere la conversazione verso tutti gli aspetti negativi che potessero incidere sul processo. 4. Individuare i principali KPI da monitorare. 5. Riportare ogni singolo elemento all interno di un post-it per la costruzione della mappa. 6. Concentrare l attenzione soltanto sul processo, lasciando domande, spunti di miglioramento, aspetti in e out scope, osservazioni aggiuntive per le fasi successive. Di seguito, riporto i risultati. Input PPW: Macrofasi del processo da noi identificate. 1. Segnalazione del problema. 2. Presa in carico del problema da parte dell HD di 1 Livello. 3. Analisi del problema. 4. Soluzione del problema. 5. Segnalazione problema e passaggio ad HD di 2 Livello. 6. Presa in carico del problema da parte dell HD di 2 Livello 7. Analisi del problema. 8. Soluzione del problema. 9. Segnalazione problema e passaggio ad HD di 3 Livello. 10. Presa in carico del problema da parte dell HD di 3 Livello 11. Analisi del problema. 12. Verifica risoluzione del problema. 13. Comunicazione della risoluzione del problema. 14. Comunicazione risoluzione a utente. 15. Chiusura ticket. 16. Report. Pain Point del processo Aspetti Critici evidenziati. Molteplicità di canali di ricezione. Formazione alle filiali. 65

71 Mancanza di priorità legate al problema (metodologia / impatto e urgenza). Numerose code di richieste. Richieste non destinate ad HD di 1 Livello (stima di c.a.60%). Mancanza della registrazione del ticket Mancanza di un programma automatico che analizzi i ticket. Tre versioni di REMEDY per i vari HD (Fornitore Esterno, Esterno e Tecnico). Mancanza di un problema / soluzione standard. Difficoltà nel classificare i problemi. Mancanza di un filtro automatico. Mancanza di anagrafica comune tra HD di 1 e 2 Livello. HD di 1 Livello perde lo stato (traccia) di avanzamento del ticket. Numerosi ticket scalati ma risolvibili da HD di 1 Livello Ticket in lista d attesa. Criticità relative al rispetto delle tempistiche concordate con cliente. Difficoltà nel trovare gli interlocutori. Procedure strutturate per risoluzioni radicate nel tempo. Processo di analisi non standard. Presenza di errori non parlanti (senza codice). Processo di escalation non strutturato. Mancanza di un catalogo elettronico di servizi tecnologici Risoluzione del problema. Criticità relative all ambiente di collaudo valido. Mancanza di stress test. Mancanza di informazioni sulle capacità del sistema. Key Performance Indicator del processo, intesi come le misure che determinano come il processo IT sta operando per consentire il raggiungimento degli obiettivi, la probabilità che un obiettivo possa essere raggiunto o meno. Numero di chiamate/ segnalazioni giornaliere. Frequenza di abbandono delle chiamate in coda (performance). Numero di casi che impattano sulla Customer Satisfaction. Numero di chiamate in lista d attesa. Percentuale dei problemi con alta priorità. Numero di chiamate instradate con l applicativo REMEDY. Numero di chiamate instradate correttamente. 66

72 Numero di incidenti ripetuti nel tempo (qualità). Numero di chiamate scalate al giorno. Evidenze: Il PPW è un efficace strumento visivo che una volta completato ci ha permesso di capire come si svolge effettivamente il processo e le principali fasi critiche; invece ha permesso alle risorse interne di razionalizzare ed evidenziare le criticità con cui devono rapportarsi quotidianamente. Le principali evidenze che sono emerse sono riassumibili in due categorie: le fasi del processo di Incident Management e le principali criticità. Non sempre il processo reale descrittoci, coincide con le linee guida operative del processo, in altre parole l operatività quotidiana si discosta dal processo normativo, riassumibile in alcune macrofasi: L Utente esegue la segnalazione del malfunzionamento riscontrato all HD di 1 Livello, a cui è associato un Incidente, che prende in carico il problema, lo analizza e che eventualmente avrà due possibilità: 1) trovare la risoluzione del problema e comunicare tempestivamente all utente il ripristino del servizio, oppure 2) può scalare il problema all HD di 2 Livello. In questa circostanza sarà proprio l HD2 che dovrà trovare la soluzione al problema, ma anche in questo situazione, avrà due alternative come nel caso precedente. Una volta che la soluzione non è stata identificata, il problema sarà preso in carico dall HD di 3 Livello. L HD3, dovrà identificare la soluzione più opportuna per ripristinare il servizio, poiché rappresenta l ultimo stadio, dotato di maggiori strumenti ed esperienza delle risorse coinvolte. Una volta che la risoluzione è stata verificata, dovrà andare a comunicare direttamente all utente, e conseguentemente ci sarà la creazione di un report. Le principali criticità riscontrate, invece sono riassumibili in: La presenza di elevati canali di ricezione per la segnalazione dell Incidente, le molteplici segnalazioni di richieste di servizio per c.a. il 60% non destinate all HD1, la mancanza di una totale classificazione dei problemi, la mancanza di categorizzazione e prioritizzazione degli Incidenti riscontrati, la mancanza di procedure strutturate che consentano di identificare soluzioni radicate nel tempo, tempi di risoluzioni elevati con potenziale insoddisfazione del cliente, la mancanza di un processo di escalation tra HD strutturato dovuto anche alla presenza di tre applicativi REMEDY di versioni diverse che non comunicano tra loro. 67

73 Output PPW: Figura 7.2 Pain Point Workshop Cartaceo SIPOC Map Il PPW è l input per costruire la SIPOC Map. Rappresenta una mappa ad alto livello del processo, che riprende le macrofasi del Pain Point e le verticalizza. L aspetto principale di tale strumento è l identificazione di: Supplier, sono i Fornitori degli input del processo. Input o Ingressi del processo. Output o Uscite del processo. Customer, ossia i Clienti dell output del processo. Si presenta in forma tabellare verticale, dove in ogni colonna sono riportate le informazioni necessarie, ma viene realizzata orizzontalmente, poiché per ogni fase del processo abbiamo fornitori, input, output e clienti; solitamente il cliente (interno oppure esterno) sarà il fornitore dell input necessario per la fase successiva del processo. La SIPOC Map l abbiamo costruita a partire dal primo fornitore del processo, che in questo caso è l Utente, che fornisce l input per iniziare la prima fase. Al Fornitore e all Input abbiamo 68

74 associato una macrofase del processo, che ha restituito l Output corrispondente, e che a sua volta è stato associato al Cliente interno o esterno (cliente finale o risorsa interna). La costruzione è iterativa, ed è terminata con il cliente finale che è nuovamente l Utente. L obiettivo era di ottenere come output una SIPOC Map, utilizzabile per identificare i principali Fornitori e Clienti del processo, necessari per realizzare le interviste successive, che permetteranno di dare Voce al Cliente e di identificare i requisiti Critical to Quality chiave, ovvero quelle caratteristiche che opportunamente tradotte in requisiti, rappresentano lo specchio di ciò che il cliente realmente desidera. Le principali linee guida seguite per la realizzazione del deliverable sono state: 1. Tracciare i limiti del processo mantenendoci ad alto livello. 2. Identificare i principali output del processo e i relativi clienti. 3. Identificare i principali input del processo e i relativi fornitori. 4. Identificare i CTQ richiesti dal processo. 5. Riportare ogni singolo passo all interno di post-it, separando in modo opportuno Fornitori, Input, Process, Output e Customer. 6. Discutere il risultato ottenuto, capendo l effettivo scostamento dalla realtà del processo. E stato necessario muoversi in entrambe le direzioni del processo, analizzando la situazione dal punto di vista del fornitore e del cliente finale. 7. Concentrare l attenzione soltanto sul processo, lasciando domande, spunti di miglioramento, aspetti in e out scope, osservazioni aggiuntive per le fasi successive. Di seguito, riporto i risultati. Input SIPOC Map: Input: Utente, Help Desk di 1 / 2 / 3 Livello, COG e Control Room, Società esterne. Supplier: segnalazione, inserimento in REMEDY e ticket, tool di gestione, team tecnici ed esperienza, informazioni riguardanti il malfunzionamento. Output: informazioni riguardanti il malfunzionamento, ticket e ticket aggiornato, identificazione della soluzione, ticket da scalare all HD di 2 / 3 Livello, problema risolto o mancata soluzione, Soluzione verificata. Customer: Utente, Help Desk di 1 / 2 / 3 Livello, Audit. 69

75 Evidenze: La SIPOC Map è un efficace strumento visivo che una volta completato ci ha permesso di identificare i principali Fornitori e Clienti del processo, cui poi sottoporre le interviste per la Voice of Customer. Le principali evidenze riguardano la molteplicità di attori coinvolti nel processo e la differente posizione nelle strutture, sono: 1. L Utente che effettua la segnalazione. 2. Le Filiali e la CapoGruppo (Rete). 3. L Help Desk di 1 / 2 / 3 Livello. 4. La Control Room. 5. Le Risorse del Consorzio COG. 6. Le Società Esterne. 7. L Audit. Output SIPOC Map: Figura 7.3 SIPOC Map Cartacea 70

76 7.3.3 Voice of Customer Una volta che abbiamo opportunamente identificato Fornitori e Clienti, siamo andati a costruire delle Interviste non strutturate, tramite opportune domande mirate, che ci hanno permesso di capire la percezione reale del processo, di chi lo vive quotidianamente. Criticità, aspetti negativi e positivi, possibili miglioramenti, sono tutti elementi che possono emergere dall intervista. Le tipiche domande che abbiamo posto all intervistato, cercando di indirizzare la conversazione verso gli aspetti di nostro interesse, sono state: 1. Come percepisce il processo? 2. Quali sono gli aspetti negativi che si trova ad affrontare nell operatività quotidiana? 3. Quali sono gli aspetti positivi che si trova ad affrontare nell operatività quotidiana? 4. Quanto per lei sono importanti e le danno soddisfazione? In che misura sono presenti nel processo? 5. Quali sono gli aspetti più critici? La VOC, è uno strumento che permette di identificare quello che il cliente desidera, in altre parole l insieme degli elementi che devono essere soddisfatti nel momento in cui si fruisce o si interagisce con il servizio. Il passo successivo è tradurre le risposte in caratteristiche (requisiti) misurabili e quantificabili, le Critical To Quality. Gli aspetti principali per cui utilizziamo questo strumento sono: 1. Cercare di capire gli aspetti che preoccupano il cliente. 2. Cercare di impostare gli obiettivi e le priorità con le esigenze dei clienti, che rappresentano il punto di vista fondamentale. 3. Cercare di identificare i clienti più opportuni per raccogliere le informazioni di interesse. Le interviste che abbiamo svolto, sono state portate avanti, per due settimane circa, cui durante le quali sono stati intervistati colleghi interni del CoMPS, colleghi delle Filiali e della CapoGruppo, colleghi dei vari Livelli degli Help Desk, compresi i Fornitori esterni. La VOC può essere portata avanti con diverse tipologie di strumenti, ma abbiamo deciso di utilizzare interviste telefoniche con schema libero per cercare di ottenere le informazioni più rilevanti, che mirassero verso il nostro obiettivo principale: capire le criticità principali di impatto sul business. Le modalità standard di raccolta delle VOC sono comunque classificabili nei seguenti macrogruppi: 1. Interviste: utilizzate per sviluppare una profonda comprensione delle esigenze del cliente e come interagisce / utilizza il prodotto o servizio. 71

77 2. Punto di Osservazione: utilizzato per visitare direttamente il posto di lavoro e osservare il punto di contatto tra il cliente e il prodotto o servizio. 3. Focus Group: utilizzate per ottenere un feedback sui prodotti o servizi e sulle idee proposte dal nuovo punto di vista dei clienti. Chiarire e definire le esigenze dei clienti. 4. Survey: utilizzate per confermare e quantificare le teorie sviluppate dopo il contatto con i clienti, per identificare i problemi più critici e per ottenere informazioni quantitative su un intero segmento di clienti o su una parte di esso. Le principali linee guida seguite per la realizzazione delle interviste sono state: 1. Individuare i clienti (interni ed esterni) opportuni, poiché non tutti i clienti creano lo stesso valore per il business, segmentando i clienti sulla base delle strutture lavorative e del livello di responsabilità. 2. Individuare le domande più opportune per ottenere le informazioni. 3. Condurre le interviste in modo professionale, così da lasciare una buona impressione, sensibilizzando l intervistato sul suo eventuale contributo. 4. Estrarre i dati di interesse dal mare magnum delle informazioni che abbiamo ottenuto, in modo da identificare gli aspetti a maggiore priorità e più elevato impatto sul business. 5. Convertire le informazioni in CTQ. Di seguito riporto un esempio di una sintesi delle interviste da noi effettuate. Output VOC: Consorzio Operativo MPS VOC Processo Nome Contributo alla discussione integrazioni/correzioni/commenti Lavoro nel gruppo di Desktop Management e mi occupo di Informatica individuale. Incident Management Riceviamo le segnalazioni di incident dall'help Desk: siamo attivati da Fornitore Esterno che raccoglie le segnalazioini e le indirizza verso di noi che forniamo il supporto iniziale. Le attività di supporto iniziale vengono svolte prima della categorizzazione e prioritizzazione. Questo è quanto previsto dal processo. questo non succede per il sottoscritto Incident Management Incident Management Incident Management Incident Management/ Request Fulfillment Incident Management Incident Management Incident Management A volte il processo non viene rispettato e i promotori finanziari contattano direttamente noi perchè ci conoscono. Solo nel caso in cui i malfunzionamenti arrivati direttamente a noi siano particolarmente gravi, allora attivo Fornitore Esterno. Nel corso della gestione suggerisco al cliente di chiamare le strutture competenti, ma non apro alcun ticket. Non c'è una struttura che concentra tutte le chiamate e le smista, pertanto le persone fanno liberamente. Nel 2009 i promotori non contattavano l'hd di Fornitore Esterno ed ora, per abitudine, chiamano personalmente le persone che conoscono e che gli hanno già risolto dei malfunzionamenti. Contattano le persone per disponibilità, non per competenza. Riceviamo non solo segnalazioni di malfunzionamenti ma anche richieste di servizio. Non viene effettuata prioritizzazione nella gestione: o si risolve il malfunzionamento o indico al cliente a chi rivolgersi. L'incident più diffuso che ci troviamo a gestire è la la mancanza di connessione rete dati. In futuro un intervento molto importante è quello di definire delle matrici RACI che indichino in modo chiaro chi deve fare cosa. se non risolvo direttamente suggerisco al cliente di chiamare le strutture competenti ma non attivo direttamente Fornitore Esterno Figura 7.4 Voice of Customer 72

78 La Voce del Cliente, è fondamentale ai fini della metodologia, poiché è proprio la chiave che sta alla base del successo. Capire le necessità del cliente, traducendole in requisiti CTQ, rappresenta il primo passo per creare un processo solido e stabile nel tempo. Le principali evidenze che sono emerse dalle VOC, sono le macro categorie di CTQ che ci hanno permesso la costruzione della KANO Matrix KANO Matrix La Matrice di Kano consente di classificare i bisogni del cliente attraverso una semplice matrice in cui gli assi riportano rispettivamente il Grado di raggiungimento dei CTQ e il Livello di soddisfazione del cliente. I CTQ con cui abbiamo costruito la KANO Matrix, li abbiamo individuati attraverso uno strumento chiamato AFFINITY DIAGRAM, combinato con le interviste. Ci ha permesso di: Organizzare le criticità e le informazioni in gruppi simili in modo da poter analizzare e diagnosticare la situazione che avevamo di fronte. Identificare le criticità più rilevanti e diffuse. Eliminare duplicati e ridondanze e le criticità meno importanti. I passi seguiti per realizzare l Affinity Diagram sono stati: 1. Raccolgiere le informazioni tramite le VOC. 2. Annotare tutte le informazioni su carta derivanti da tutte le interviste. 3. Raggruppare gli aspetti simili in macro categorie di criticità principali identificando un opportuna etichetta di intestazione. Figura 7.5 Affinity Diagram 4. Trasformare le esigenze dei clienti in requisiti CTQ (poiché non tutti i requisiti sono critici rispetto alla qualità percepita dal cliente), da utilizzare come input per la KANO Matrix (Brainstorming). 73

79 Avendo a disposizione le categorie di CTQ, li abbiamo posizionati nei vari quadranti, suddividendoli in: Must Be, rappresentano requisiti che il processo garantisce, sono tutti quei requisiti che dovrebbero essere presenti. Le potenziali azioni da implementare hanno l obiettivo di mantenere intatti tali requisiti di base, ed eventualmente crearne dei nuovi che il processo non garantisce. Linear o Soddisfacenti, rappresentano requisiti che il processo garantisce, e generano un grado di soddisfazione direttamente proporzionale al grado di performance raggiunta dagli stessi. Le potenziali azioni da implementare hanno l obiettivo di mantenere intatti tali requisiti soddisfacenti. Delighter, rappresentano requisiti che il processo non garantisce, ma se assolti possono creare una grande soddisfazione nel cliente e che potrebbero dare maggior valore nello sviluppo del servizio. Le potenziali azioni da implementare hanno l obiettivo di individuare e sviluppare i requisiti con alta priorità, trasformandoli in Must Be. Neutral, rappresentano requisiti non presenti e che in realtà non sono oggetto delle azioni potenziali. Di seguito, riporto i risultati. Input KANO Matrix: Velocità tempi di risoluzione del problema. Chiarezza su destinatari delle richieste. Velocità tempi di indagine e risposta HD 1 Livello. Semplicità utilizzo portale per inserire Incidenti. Disponibilità ed efficienza operatori HD 1 Livello. Disponibilità risorse di 2 Livello. Comunicazione tempestiva dei rilasci. Anagrafica allineata tra REMEDY diversi (tra 1 e 2 Livello). Prioritizzazione e categorizzazione Incidenti. Chiarezza e univocità del canale di input. Corretto indirizzamento delle richieste (#). Problem e Change Management. Escalation strutturata. Tracciabilità del ticket. Categorizzazione degli Incidenti. Grado di formazione degli utenti. Repository condivisa della conoscenza. 74

80 Reportistica puntuale. Evidenze: La KANO Matrix permette di individuare i CTQ principali cu cui agire, definendo le priorità sulla base della posizione che assumono all interno dei quadranti. Le principali evidenze che sono emerse riguardano alcune categorie di CTQ con più elevata priorità. CTQ con alta priorità che dovrebbero essere presenti per garantire alta soddisfazione del cliente: La prioritizzazione e la categorizzazione degli Incidenti per stimare l impatto e l urgenza, la chiarezza e l univocità del canale di input, il numero corretto di indirizzamento delle richieste, la velocità dei tempi di risoluzione del problema, la chiarezza sui destinatari delle richieste, la velocità dei tempi di indagine e di risposta dell HD 1 Livello, la semplicità utilizzo portale per inserire Incidenti. CTQ con alta priorità già garantiti dal processo, che devono essere inseriti perché alla base di prestazioni performanti, oppure mantenuti e rafforzati per garantire il funzionamento del servizio: La comunicazione tempestiva dei rilasci, l anagrafica allineata tra gli applicativi REMEDY diversi (tra 1 e 2 Livello), la presenza del Problem e Change Management, la presenza di un processo di escalation strutturato, il grado di formazione degli utenti, la presenza di una Repository condivisa della conoscenza, la presenza di una Reportistica puntuale. Output KANO Matrix: Figura 7.6 KANO Matrix Cartacea 75

81 7.3.5 Project Charter La prima fase della metodologia DMAIC, si conclude con il Project Charter, che rappresenta la formalizzazione finale e sintetica della fase di Define. Questo documento rappresenta una sintesi e un controllo della fase di Define, che deve essere presentato agli Sponsor e a tutti gli Stakeholder in modo tale da chiarire alcuni aspetti: La direzione da seguire. I benefici attesi dal progetto. La possibilità di proseguire il progetto sulla base di un analisi Costi Benefici. Abbiamo identificato: 1. Un Titolo del progetto che lo identifichi in maniera univoca. 2. Le Risorse Umane coinvolte. 3. Il Problem Statement, in altre parole lo status quo attuale del processo di IM. 4. Gli Obiettivi da raggiungere con l implementazione delle azioni correttive. 5. I Key Performance Indicator su cui agire. 6. L Ambito (In Scope) del progetto, ovvero gli aspetti che rientrano nel perimetro. 7. Tutto ciò che non rientra nel perimetro del progetto (Out of Scope). Di seguito, riporto i risultati. Input Project Charter: Pain Point Workshop Criticità del processo. SIPOC Map Fornitori e Clienti del processo. Voice Of Customer CTQ Requisiti del processo. KANO Matrix Requisiti con maggiore priorità Delighter e Must Be. Evidenze: Con il Project Charter si formalizza la fase di Define, per capire la direzione verso cui muoversi durante le altre fasi della metodologia LSS, e descrivere i possibili benefici agli Sponsor di progetto ed a tutti gli Stakeholders. Titolo: INcipIT 76

82 Team: Risorse CoMPS Problem Statement: Elevato numero di contatti in arrivo agli Help Desk (60% di telefonate al 1 Livello non di competenza, voce altro ). Alto numero di chiamate perse da HD1 (media del 15%). Elevato e non prevedibile tempo di risposta. SLA inadeguato (eccessivo per l utente). Molteplicità di canali utilizzati per la segnalazione di problematiche. Obiettivi da raggiungere: I. Riduzione dei tempi di intervento (- 30%). II. Riduzione del numero di telefonate altro (- 10%). III. Riduzione del numero di chiamate perse (- 40%). IV. Revisione degli SLA sia interni che verso l utente finale. V. Ri disegno di un processo codificato e condiviso. VI. Identificazione delle difficoltà presenti in processi collegati all IM. Key Performance Indicator: Tempi medi di intervento / Risoluzione dell incidente. Numero di segnalazioni in ingresso per ogni tipologia di canale individuato e per singoli Help Desk. Tempi medi di attesa in coda per ticket e telefonate. PLT = WIP / Exit Rate. In Scope: Incidenti di tipo tecnologico da HD Tecnico. Segnalazioni da Risorse BMPS / Filiali / HD Interno / HD Esterno. Segnalazioni da Diario Incidenti. HD 1 / 2 / 3 Livello. Out of Scope: Problem Management. Change Management. Asset Management. Configuration Management. Tutti i processi del mondo IT. 77

83 Output Project Charter: Figura 7.7 Project Charter Cartaceo 7.4 Measure Current Performance Levels Con la fase di Measure, il nostro scopo è di identificare la Baseline del processo su cui intervenire, ovvero la fotografi attuale del processo. In questo periodo, il nostro obiettivo è stato la raccolta dati, perché partiamo dal presupposto che ogni attività è misurabile, e i risultati prodotti sono la base per effettuare un confronto con quanto pianificato dagli SLA aziendali Value Stream Map La VSM è una mappa dettagliata del processo, che mi consente di tracciare tutti i flussi di ogni singola attività, di identificare la rispettiva posizione di fornitori e clienti nella catena del valore, di capire la complessità del processo con i suoi input ed output prodotti, di individuare il flusso di materiali ed informazioni, di distinguere le attività a valore aggiunto da quelle a non valore aggiunto con il fine di rimuovere lo spreco e di individuare le priorità di miglioramento. La Value Stream Map si costruisce esplodendo ogni macrofase del processo descritto in precedenza nella SIPOC Map. 78

84 Con una maggiore conoscenza e consapevolezza del processo di IM, abbiamo potuto identificare le forme di spreco T.I.M.W.O.O.D. in termini qualitativi e quantitativi, definendo durata dell intero processo, stime sui dati di input, possibili tempi di attesa e ricicli annidati nelle singole fasi, WIP, spostamenti fisici degli output prodotti, possibili richieste di informazioni cartacee e telematiche. L idea è avere una stima quantitativa dell ordine di grandezza delle informazioni trattate. Di seguito, riporto i risultati. Input VSM: SIPOC Map Categorie di Fornitori. Categorie di Clienti. Macrofasi del processo da esplodere Singoli Fornitori (considerando anche la risorsa interna che fornisce un input) e Clienti (considerando anche la risorsa interna che richiede un output) Utente. Operatore e Focal-Point del Fornitore Esterno. Operatore HD Interno. Operatore COG. Operatore HD Esterno. Operatore di Filiale. Help Desk di 1 Livello. Help Desk di 2 Livello. Help Desk di 3 Livello. Control Room. Singole attività del processo di Incident Management, considerando: Segnalazioni da Utente. Ricerca delle Soluzioni. Eventuale escalation. Comunicazioni di avvenuto ripristino del servizio. Vedere la sintesi riportata di seguito e il dettaglio nell allegato della VSM. 79

85 Output VSM: Figura 7.8a VSM Cartacea Figura 7.8b VSM Sintesi Formalizzata Le principali evidenze che sono emerse dalla VSM, riguardano il dettaglio del processo di Incident Management, e le varie stime che si sono potute calcolare a partire dalle informazioni iniziali. Nella sintesi, ho riportato le fasi sintetiche dell intero processo, che può essere così descritto: 80

86 L Utente può effettuare la segnalazioni di Incidente attraverso due strade: formale o non formale, sula base del fatto che il canale di comunicazione sia o meno approvato dallo standard di processo. Nel caso in cui l Utente decida di utilizzare la prima via, questa è rappresentata da telefonate, mail personali e Intranet aziendale come Messenger. Nel secondo caso, invece ci sono telefonate e mail di servizio e Applicativo REMEDY. Le strutture adibite a raccogliere le segnalazioni sono i tre HD di vario Livello. L HD I, ha come input la chiamata o la mail da Utente o HD Interno, oppure una segnalazione da Intranet da Utente e provvederà a registrare il malfunzionamento con l apertura del ticket. Una volta che l HD I ha preso in carico il problema può risolverlo e comunicare l avvenuto ripristino del servizio, oppure scalarlo all HD II. L HD II ha come input, o il ticket scalato che proviene dall HD I, oppure la chiamata da Utente, oppure la chiamata o la mail da HD Interno. Anche in questo caso, l HD II una volta preso in carico il problema, può risolverlo e comunicare l avvenuto ripristino del servizio, oppure scalarlo all HD III. L HD III ha come input, o il problema scalato dall HD II, oppure la chiamata o la mail da Utente, o la chiamata e la mail da HD Esterno, oppure la segnalazione da Diario Incidenti. In questo caso, l HD III una volta preso in carico il problema dovrà risolverlo e comunicare l avvenuto ripristino del servizio. Le prime stime ottenute e che abbiamo calcolato con i dati di input, sono state: Input Rate HD I: 1000 segnalazioni / g. Input Rate presa in carico del problema HD I: 700 ticket / g. Escalation ad HD II: 60 ticket / g. Task Time HD I: 15 min. Input Rate HD II: 150 segnalazioni / g. Input Rate presa in carico del problema HD II: 210 / g. Task Time HD II: 20 min. Input Rate HD III: 50 segnalazioni / g. Task Time HD III: 30 min Incident Check Sheet, Veline Le Veline sono uno strumento per la raccolta dati, che permettono di delineare la Baseline del processo, da cui partire per implementare azioni correttive. Abbiamo costruito le Veline, focalizzandoci solo sui dati necessari per effettuare le analisi successive, tralasciando i dati superflui ai fini della raccolta. Dopo un opportuna comunicazione e condivisione delle Veline al Responsabile della struttura degli Help Desk e agli operatori è iniziata la raccolta dati. La comunicazione è stata necessaria, poiché i fogli di raccolta dovevano essere compilati dagli operatori nel modo più corretto ed esaustivo possibile. Il periodo di 81

87 raccolta dati presso le strutture è stato svolto dal 7 Novembre 2011 al 25 Novembre Abbiamo costruito tre tipi di Veline: Di seguito, riporto i risultati. Input TCS: Raccolta dati da HD di 2 Livello su Siena (A): ID Incidente. Canale di Ricezione: Telefono (HD I, Barra Telefonica, HD Interno, Linea di Emergenza, Personali e Messenger). Mail (HD I, di Servizio, HD Interno, Personali). Ambito o Struttura richiedente. Il contatto era necessario / corretto? (SI / NO) Data e Ora di: Ricezione richiesta. Inizio Lavorazione richiesta. Risoluzione / Chiamata a Utente. Numero di telefonate / contatti per trovare la soluzione. Numero e Durata di interruzioni. Modalità di Escalation (se si effettua: Telefono o Mail). Struttura verso la quale si fa Escalation. La Struttura era corretta? (SI / NO) Data e Ora di: Escalation. Chiusura della richiesta e Conferma risoluzione a Utente. Note. Raccolta dati da HD di 2 Livello su Firenze (B): stessi fogli di raccolta Raccolta dati da HD di 3 Livello su Siena: ID Incidente. Canale di Ricezione: Telefono (HD II, HD Esterno, Applicativi, Personali e Messenger). Mail (HD II, Applicativi, HD Esterno, Personali). Ambito o Struttura richiedente. Il contatto era necessario / corretto? (SI / NO) 82

88 Inserito in Diario Incidenti? (SI / NO) Data e Ora di: Ricezione richiesta. Inizio Lavorazione richiesta. Risoluzione / Chiamata a Utente. Numero di telefonate / contatti per trovare la soluzione. Numero e Durata di interruzioni. Modalità di Escalation (se si effettua: Telefono o Mail). Struttura verso la quale si fa Escalation. La Struttura era corretta? (SI / NO) Data e Ora di: Escalation. Chiusura della richiesta e Conferma risoluzione a Utente. Note. Output TCS: Figura 7.9 Incident Check Sheet 83

89 7.4.3 Spaghetti Diagram La Spaghetti Diagram ci ha permesso di tracciare il flusso fisico delle informazioni e delle richieste attraverso la struttura organizzativa del processo Gestione delle Sicurezza. La Spaghetti Diagram ci ha permesso di capire visualizzando su carta il reale flusso di dati e informazioni del processo di Incident Management, l insieme delle escalation che sono alla base della gestione degli Incidenti, i reali passaggi di mano tra le strutture e le eventuali code all interno del processo (segnalazioni da Utente e Risoluzione Incidente). Per ogni Livello abbiamo evidenziato i canali di ricezione e scambio delle informazioni e dei dati. Telefono, Mail, REMEDY HD Tecnico 2 Livello Fornitore Esterno HD Interno HD Esterno HD Tecnico 3 Livello Telefono e Mail (Personali e di Servizio), REMEDY Telefono, Mail, Messenger Telefono e Mail (Personali e di Servizio) Figura 7.10 Spaghetti Diagram Formalizzata 7.5 Evidenze Measure Le principali evidenze, che abbiamo riscontrato durante le prime fasi della metodologia LSS e le tempistiche di progetto sono riportate di seguito: Nella fase di Define abbiamo rilevato: 1. Un elevato numero di segnalazioni in ingresso del processo, sia di competenza sia non di competenza dell HD, ovvero fuori dal proprio perimetro di azione. 2. La presenza di canali non formali e non tracciati dai sistemi di reportistica, come telefonate o mail personali, Messenger interno, etc. 3. La mancanza di una prioritizzazione delle richieste Inbound. (PPW) 84

90 4. La presenza di tre strutture o Livelli che svolgono attività analoghe in sequenza temporale, ma con criticità e problemi differenti. 5. La molteplicità di hands off per la gestione della singola richiesta. 6. Una definizione non chiara e condivisa del processo di gestione degli esiti degli Incidenti. (SIPOC Map) 7. Le richieste da parte del cliente di: a. Maggiore trasparenza sullo stato della pratica. b. Maggiore chiarezza del processo. (KANO Matrix) Obiettivi del nostro Team LSS: I. Ridurre del -10% le chiamate non di competenza, con conseguente riduzione dei tempi di intervento del - 30%, e la riduzione del numero di chiamate perse o abbandonate del - 40%. II. Razionalizzazione dei canali di ingresso. III. Definizione di un processo condiviso e formalizzato, con conseguente revisione degli SLA interni e identificazione delle difficoltà presenti nei processi collegati all Incident Management. Nelle fasi di Measure e Analyze abbiamo rilevato: 1. Un aumento, per l HDI del tasso di abbandono delle chiamate dal 3% al 11%. 2. Circa un 60% di chiamate in ingresso / Inbound non di competenza, quindi fuori dal perimetro di azione. 3. Modalità operative da parte degli Utenti non formale che incide sul 40% delle richieste Inbound (prevalgono le telefonate e mail personali) e sul 33% del tempo totale di lavorazione dell HDII; conviene agire sull eliminazione delle attività a non valore aggiunto, NVBA. 4. L analisi nel dettaglio dell intero processo con la VSM evidenzia la molteplicità dei canali di ingresso non formali per tutti i Livelli degli HD. 5. Elevati tempi di attesa, che variano dai minuti per ogni fase di escalation. I grafici sottostanti descrivono in parte, le evidenze che abbiamo riscontrato: 1. Tasso di chiamate Abbandonate. 2. Chiamate di Competenza e Non di Competenza. 3. Canali di Input Formali e Non Formali ed il relativo tempo di lavorazione che viene dedicato. 4. La VSM. 85

91 Chiamate Inbound in % di Competenza Non di Competenza 40% 60% Grafico 7.11 Tasso di Abbandono di HDI e Chiamate in Ingresso Canali di Ingresso in % solo HD III Tempo lavorativo in % solo HD II Canali Informale Canali Formale Canali Informale Canali Formale 40% 33% 60% 67% Grafico 7.12 Canali in Ingresso e Distribuzione del tempo lavorativo Figura 7.13 VSM Sintetica 86

92 Da quanto evidenziato dalle analisi, abbiamo capito che i possibili benefici ottenibili dagli interventi di miglioramento sono legati a tre aspetti fondamentali: 1. La mancanza di un analisi congiunta di tutti i processi del mondo IT, Change, Problem, Configuration e Asset Management, che sono caratterizzati da un elevata dipendenza e integrazione. 2. La limitata possibilità di intervenire e modificare il processo, già soggetto a contratti e SLA già definiti e condivisi (HDI). 3. Implementare funzionalità aggiuntive sullo strumento condiviso, l applicativo REMEDY, tra le varie Strutture di HD, che consenta di tracciare il flusso della richiesta di Incidente (ticket), di effettuare un escalation standard e condivisa, di creare una reportistica puntuale e aggiornata, di disporre di un DB della conoscenza. 7.6 Analyze Understand Current Performance Levels Con la fase di Analyze, sulla base delle informazioni a disposizione e dei dati raccolti dalla fase precedente, il nostro scopo è di identificare le cause che stanno alla base degli sprechi e degli aspetti negativi del processo, cercando di capire l impatto che hanno sul processo stesso in termini di CTQ e sul Business. Analizzare i dati per identificare le cause, cercando di delineare le prime modalità di intervento con i risultati ottenuti Statistica Descrittiva Situazione di partenza % di Incidenti non tracciati. 2. Elevati tempi di attesa da parte dell Utente durante l escalation dell Incidente, rispettivamente con: 45 minuti tra HD I ed HD II. 2,5 ore tra HD II ed HD III. 3. Mancata categorizzazione degli Incidenti % di chiamate non di competenza rivolte alle strutture. 5. Carenza di requisiti fondamentali per una corretta gestione degli Incidenti. 6. Processo non formale consolidato tra gli Utenti. 7. Impossibilità di apertura automatica del ticket dalla Barra Telefonica. Si evince che circa il 60% delle segnalazioni di problematiche sono legate a Stampanti, Multifunzione e Problemi dell applicativo SIO; mentre per un 21% le problematiche non sono categorizzabili, poiché troppo diverse tra loro. 87

93 Possiamo notare inoltre, che il 10% delle chiamate sono destinate all HD Tecnico erroneamente, poiché sarebbero destinate all HD I. Grafico 7.14 Distribuzione Chiamate HD I Percentuale Cumulata App.vo SIO 25,1% 25,15% Stampanti 23,4% 48,54% Richiesta Errata 11,2% 59,70% Stampe 7,2% 66,90% Posta Elettronica 6,8% 73,72% Altro 4,8% 78,50% Internet 4,4% 82,91% Tabella 7.15 Tipologie di Incidenti Particolare attenzione va rivolta a due parametri fondamentali legati al processo, che ne possono modificare sostanzialmente efficacia ed efficienza: 1. Tempi di Abbandono delle chiamate da parte dell Utente, nel caso in cui il Tempo di Attesa in coda (tipologia QRP) sia eccessivo [hh:mm:ss]: Tempo medio di Abbandono: 00:03: Tempi di Attesa o Waiting Time, ovvero il tempo medio di attesa da parte dell Utente in coda (tipologia QRPxxx), nel momento in cui viene effettuata una segnalazione [hh:mm:ss]: 88

94 Tempo medio di Residenza in coda: 00:02:27. Abbandoni: Media del 16% 100% 50% 0% QRP360 77% 89% 79% 86% 90% 82% 23% 11% 21% 14% QRP501 QRP502 QRP503 10% 18% QRP506 QRP507 QRP360 QRP501 QRP502 QRP503 QRP506 QRP507 % Abbandoni 23% 11% 21% 14% 10% 18% % Gestite 77% 89% 79% 86% 90% 82% Grafico 7.16 Tempo medio di Abbandono Chiamate HD I Le principali tipologie di richiesta ricevute dall Help Desk di 1 Livello, sono: Tipo Richiesta SERVICE_RICHIESTA INFO ,5% SERVICE_SOLLECITO ,4% TROUBLE_CHIAMATA ERRATA ,0% TROUBLE_POSTA 365 2,1% TROUBLE_FILIALE 337 1,9% TROUBLE_PDL 301 1,7% TROUBLE_PROBLEMA GENERALIZZATO 176 1,0% TROUBLE_SOFTWARE 10 0,1% Totale ,0% Richiesta di informazioni per la risoluzione dell Incidente Tabella 7.17 Tipologie di Richieste Richiesta di sollecito per la risoluzione dell Incidente Chiamata errata e non destinate all HD I 80% delle segnalazioni Il Pareto Diagram successivo mostra le tipologie di Incidenti più impattanti sulla struttura di 1 Livello. Mentre il successivo istogramma permette di identificare la corretta percentuale giornaliera dell Incidente. 89

95 Grafico 7.18 Tipologie di Incidente Di seguito riporto la statistica descrittiva, che mi permette di sintetizzare le informazioni riguardanti i miei dati acquisiti, relativi alle 4 tipologie di Incidenti più frequenti. Sistema Stampanti Media Media Errore standard Errore standard Mediana Mediana Deviazione standard Deviazione standard Varianza campionaria Varianza campionaria Curtosi Curtosi Asimmetria Asimmetria Intervallo Intervallo Minimo Minimo Massimo Massimo Somma Somma

96 Richiesta Errata Internet Outlook Media Media Errore standard Errore standard Mediana Mediana Moda Moda Deviazione standard Deviazione standard Curtosi Varianza campionaria Asimmetria Asimmetria Intervallo Intervallo Minimo Minimo Massimo Massimo Somma Somma Punto di max della distribuzione. Tabella 7.19 Statistica descrittiva Range = Xmax - Xmin Valore sotto al quale cade la metà dei valori campionari. Di seguito riporto gli istogrammi relativi ai tempi medi di risoluzione giornaliera (1-21 giorni) del particolare Incidente, in modo da evidenziarne l andamento nel tempo. Media Grafico 7.20 Media risoluzione Sistema 91

97 Media Grafico 7.21 Media risoluzione Stampanti Media Grafico 7.22 Media risoluzione Chiamate Errate 92

98 Media Grafico 7.23 Media risoluzione Internet Nelle tabelle successive vado a riportare i dati di sintesi, ottenuti con la fase di Measure nella struttura di 2 Livello. I dati riguardano le metodologie di raccolta: 1. Canali non tracciabili (tutti gli Incidenti per cui non è stato aperto un Ticket in automatico): abbiamo utilizzato gli Incident Check Sheet (Veline). Abbiamo una sintesi di tipo giornaliero riferita all Help Desk II di Siena e Firenze. Statistiche legate all Help Desk di 2 Livello: Tempo medio di Attesa dalla richiesta: 01:00:43. Tempo medio di Risoluzione dell Incidente: 01:01:30. Mediana: 00:30:00. Tempo medio di Scalata e Chiusura a Utente: 04:27:54. Media Lavorazione: 03:05:38 [hh:mm:ss] Mediana Lavorazione: 01:00:00 [hh:mm:ss] Deviazione Standard: 03:48:33 [hh:mm:ss] Nella tabella si possono evidenziare informazioni importanti, come: Il numero di contatti che si riferiscono alla struttura, e quali di questi è corretta oppure indirizzato alla struttura non di competenza. I canali di ricezione utilizzati per effettuare le segnalazioni (Mail e Telefono). 93

99 Le modalità di escalation e il numero di escalation alla struttura di competenza. 2. Canali tracciabili (tutti gli Incidenti per cui è stato aperto un Ticket in automatico): abbiamo utilizzato il report dell applicativo REMEDY (DSO), in seguito ad opportuna estrazione. Nella tabella si possono evidenziare informazioni importanti, come: Il numero di contatti che si riferiscono alla struttura. I canali di ricezione utilizzati per eseguire le segnalazioni (DSO - Ticket, Diario Incidenti e Telefono). Le modalità di escalation e il numero di escalation alla struttura di competenza. Veline (Siena +Firenze) HELP DESK II Totale Incidenti Totali tot 379 Contatti necessari/corretti SI 321 NO 36 Canali di ricezione MAIL Help Desk I 37 di Servizio 55 HD Interno 1 Personali 68 TELEFONATE Help Desk I 36 Barra Telefonica 2 HD Interno 14 Linea di Emergenza 24 Personali/Messanger 124 # Escalation tot 53 Modalità Escalation MAIL 17 TELEFONATE 34 Remedy Totali DSO 860 Rete 742 Capogruppo 50 COG 22 Altro 3 Scalate al III 88 Telefono 112 Rete 75 Capogruppo 2 COG 7 Altro 27 Scalate al III 1 Diario Incidenti 16 Rete 0 Capogruppo 0 COG 6 Altro 7 Scalate al III 1 Totale 988 Scalate 90 % scalate da II al III 9% Tabella 7.24 Sintesi giornaliera Veline Tabella 7.25 Sintesi giornaliera REMEDY Di seguito riporto le sintesi globali, dell intero periodo di misurazione, riferite alla struttura di 2 Livello, da cui è possibile evidenziare: Il numero di contatti che si riferiscono alla struttura, e quali di questi è corretta oppure indirizzato alla struttura non di competenza. 94

100 I canali di ricezione utilizzati per effettuare le segnalazioni (Mail e Telefono), le rispettive percentuali e le cumulate. Le modalità di escalation e il numero di escalation alla struttura di competenza. Delta che intercorre tra l inizio della lavorazione e la successiva escalation, effettuata nel momento in cui non è stata individuata una soluzione, alla struttura opportuna. Dalle tabelle si evince, che oltre il 50% è composto da Mail e Telefonate Personali (non formali) che vanno a incidere sul totale delle segnalazioni ricevute dalla struttura. I problemi principali che si vengono a creare sono: 1. La presenza di un processo non formale e strutturato. 2. Gli elevati tempi di attesa da parte degli Utenti che rispettano il processo, e di conseguenza di risoluzione dell Incidente. DATI DI SINTESI - Incident Management HELP DESK II Totale Incidenti tot 400 Contatti necessari/corretti SI NO Canali di ricezione MAIL % Cumulata Personali 42% 42% di Servizio 35% 77% Help Desk I 22% 99% HD Interno 1% 100% TELEFONATE % Cumulata Personali/Messanger 62% 62% Help Desk I 18% 80% Linea di Emergenza 12% 92% HD Interno 7% 99% Barra Telefonica 1% 100% Modalità Escalation MAIL TELEFONATE 31% 69% Delta Inizio Lavorazione ed Escalation tot gg hh mm ,0 0,0 31,0 Tabella 7.26 Sintesi HD II 95

101 Incidenza Mail su HD II 77% 99% 100% Incidenza Telefono su HD II 99% 100% 92% 80% 62% 62% 42% 42% 35% 22% 18% 12% 7% 1% 1% Personali di Servizio HD I HD Interno Grafico 7.27 Incidenza Mail HD II Grafico 7.28 Incidenza Telefonate HD II Incidenza Canali di Ricezione su HD II Canali di Ricezione 89% Cumulata 95% 99% 100% 73% 53% 53% 20% 16% 6% 5% 1% Personali HDI di Servizio Emergenza HD Interno Barra Tel Grafico 7.29 Incidenza Mail + Telefonate HD II Di seguito riporto le sintesi globali, dell intero periodo di misurazione, riferite alla struttura di 3 Livello, da cui è possibile evidenziare: Il numero di contatti che si riferiscono alla struttura, e quali di questi è corretta oppure indirizzato alla struttura non di competenza. I canali di ricezione utilizzati per eseguire le segnalazioni (Mail e Telefono), le rispettive percentuali e le cumulate. Le modalità di escalation e il numero di escalation. 96

102 Delta che intercorre tra l inizio della lavorazione e il momento in cui viene individuata una soluzione. Statistiche legate all Help Desk di 3 Livello: Tempo medio di Attesa dalla richiesta: 00:10:43. Tempo medio di Risoluzione dell Incidente: 02:07:38. Mediana: 00:24:00. Dalle tabelle si evince, che soltanto il 18% delle Mail e delle Telefonate Personali (non formali) incidono sul totale delle segnalazioni. I problemi principali riscontrati, sono: 1. L elevato tempo di risoluzione dell Incidente. 2. L elevato tempo di attesa dell Utente. DATI DI SINTESI - Incident Management HELP DESK III Totale Incidenti tot 69 Contatti necessari/corretti SI NO 61 4 Canali di ricezione MAIL % Cumulata Help Desk II 64% 64% HD Esterno 27% 91% Personali 9% 100% Applicativi 0% 100% TELEFONATE % Cumulata Help Desk II 75% 75% Personali/Messanger 21% 96% Applicativi 4% 100% HD Esterno 0% 100% # Escalation tot 13 Modalità Escalation MAIL TELEFONATE 38% 62% Delta Inizio Lavorazione ed Escalation tot gg hh mm ,0 2,0 29,0 Tabella 7.30 Sintesi HD III 97

103 Incidenza Mail su HD III 100% 100% 91% 64% 64% Incidenza Telefono su HD III 100% 100% 96% 75% 75% 27% 21% 9% 0% 4% 0% HD II HD Esterno Personali Applicativi HD II Personali Applicativi HD Esterno Grafico 7.31 Incidenza Mail HD III Grafico 7.32 Incidenza Telefonate HD III Incidenza Canali di Ricezione su HD III Canali di Ricezione 90% Cumulata 97% 100% 72% 72% 18% 8% 3% HDII Personali HD Esterno Applicativi Grafico 7.33 Incidenza Mail + Telefonate HD III Analisi di Regressione 7.6.2a Analisi preliminare Il primo passo è stato quello di rappresentare i dati da analizzare sotto forma di vettori da poter applicare al software MATLAB. Ho caricato una matrice su MATLAB di dimensione 1189 x 3, dove: La prima colonna rappresenta i tempi di risoluzione (output), 98

104 o y = data (:,1); La seconda colonna la prima variabile di input (categorie di Incidente), o x1 = data (:,2); La terza colonna la secondavariabile di input (tipologie di Incidente), o x2 = data (:,3); Il secondo passo è stato quello di standardizzare le variabili da analizzare. dvs = std(); mu = median(); mu = mu(ones(size(data(:,1)))); dvs = dvs(ones(size(data(:,1)))); norm = (-mu')./dvs'; Occorre valutare il grado di probabilità con cui le quantità sono in relazione lineare. Quando non vi è alcuna correlazione, allora non c è la tendenza per una quantità di incrementare o diminuire con il variare dei valori dell altra quantità. Il coefficiente rappresenta la misura della forza della correlazione tra le quantità. Il coefficiente varia tra -1 ed 1, quindi valori prossimi ad 1 esprimono correlazione positiva, valori prossimi a -1 esprimono assenza di correlazione e valori prossimi allo 0 indicano una relazione di tipo non lineare. Ho deciso di concentrare l attenzione sull HD di 1 Livello, andando a individuare le possibili relazioni tra le variabili del report che avevo a disposizione. La variabile che ho deciso di considerare come output, è il vettore dei tempi di risoluzione degli Incidenti, opportunatamente trasformati in uno scalare, per poterli trattare sul software MATLAB. Per quanto riguarda le variabili di input, che secondo me, possono influenzare in modo significativo l output, ho deciso di considerare le categorie di richieste di Incidente e le varie tipologie di Incidente, anch esse opportunamente trasformate in uno scalare. Covarianza tra y,x1,x2: Valori prossimi allo zero indicano una relazione di tipo non lineare (y,x1) e (y,x2)!

105 Correlazione tra y,x1,x2: Di seguito riporto il passo di trasformazione delle variabili effettuato con Microsoft Excel: var_tempi var_tempi 0, , , , , , , , , , , , Categorie Tipologie Service Trouble RICHIESTA INFO 1 CHIAMATA ERRATA 2 POSTA 3 FILIALE 4 PDL 5 GENERALE 6 SOFTWARE 7 RICHIESTE ERRATE 8 INTERNET 9 STAMPANTI 10 APPLICATIVO 11 Attraverso uno scatter plot o grafico a dispersione è possibile identificare la relazione tra le distribuzioni numeriche bivariate. Date le coppie (x 1,y 1 ),, (x n,y n ), ottenute dalle rilevazioni delle variabili, il grafico mi permette di rappresentare l insieme dei punti P 1 =(x 1,y 1 ), P 2 =(x 2,y 2 ) fino a P n =(x n,y n ). Lo scatter plot di due variabili aleatorie con forte correlazione positiva mi restituisce una nuvola di punti distribuiti in prossimità di una retta crescente (a pendenza positiva), viceversa per la correlazione negativa, mentre per variabili aleatorie scorrelate (o debolmente correlate) mi restituisce una nuvola di punti che non individua alcuna retta. Gli scatter plot sottostanti evidenziano la stretta relazione tra la variabile di output y, e le variabili di input,rispettivamente x1 e x2. La concentrazione dei punti evidenzia una chiara correlazione positiva e dipendenza tra i tempi di risoluzione, le categorie e le tipologie di Incidente. 100

106 Tipologia Categoria Quadrature Quadrature Scatter plot Scatter plot In-Phase In-Phase Grafico 7.34 Scatter plot tra le variabili y e x1 e y e x2 Dai grafici sottostanti si evince, come i tempi di risoluzione siano strettamente collegati alle categorie 5 e 7 che corrispondono a problemi sulla postazione di lavoro (PDL) e problemi si tipo software, con il conseguente allungamento dei tempi stessi. Inoltre risalta, come i tempi di risoluzione siano strettamente collegati alle tipologie 10 e 11 che corrispondono a Incidenti legati all Applicativo sulla postazione di lavoro e alle Stampanti / Stampe. Da tenere in considerazione le tipologie di Incidente Errate (8) che non sarebbero destinate all HDI, ma che allungano in alcuni casi (11%) i tempi di risoluzione, con conseguente incremento del carico di lavoro degli operatori (maggiore carico di lavoro, maggiori tempi di risoluzione) Tempi Tempi Grafico 7.35 Scatter tra le variabili y e x1 e y e x2 101

107 Sample Autocorrelation Tempi 7.6.2b Identificazione del modello E necessario, individuare il corretto modello di regressione, che mi consenta di eseguire una corretta analisi. Ho deciso di applicare i modelli tipici delle serie storiche per valutare la possibilità di individuare la giusta funzione per modellare la relazione tra le quantità in gioco. Attraverso il software MATLAB, ho svolto la mia analisi (in allegato riporto anche il codice). Di seguito ho riportato l andamento dei tempi di risoluzione degli Incidenti, e l andamento dell autocorrelazione e dell autocorrelazione parziale, che evidenzia in modo molto accentuato la stagionalità della serie Numero Campioni Grafico 7.36 Andamento dei tempi di risoluzione Sample Autocorrelation Function (ACF) Lag Grafico 7.37 Andamento ACF della Serie 102

108 Sample Partial Autocorrelations 2 Sample Partial Autocorrelation Function Lag Grafico 7.38 Andamento PACF della Serie Ho identificato la struttura più adeguata che potesse descrivere l andamento della serie dei tempi di risoluzione, da modelli semplici caratterizzati dalla sola componente ARMAX (R,M,X), per poi aggiungere successivamente la componente GARCH (P,Q). 1. La migliore componente ARMAX modella la media condizionale. 2. La migliore componente GARCH modella la varianza condizionale. La struttura migliore che permette di identificare l andamento della serie dei tempi di risoluzione è: ARMAX (2,4,0) GARCH (0,0). y t = *y t *y t *ε t * *ε t *ε t *ε t-4 + ε t h t = La validazione del modello è stata eseguita attraverso due metodi (nell analisi sono considerate le innovazioni standardizzate (innovations/sigmas), ciò serve a togliere la componente determinata dalla varianza condizionale (eteroschedasticità) e a ripulire la serie di tutti gli effetti dovuti alla varianza): 1. Studio della funzione di autocorrelazione delle innovations standardizzate per verificare la correttezza della componente ARMA nel modello (ovvero residui scorrelati o compresi nelle fasce di confidenza della funzione ACF). 103

109 Sample Autocorrelation 2. Funzione di autocorrelazione delle innovations standardizzate al quadrato per verificare la correttezza della componente GARCH nel modello. Per la validazione del modello ho utilizzato il Ljung-Box-Pierce Q-Test (lack of fit) e l ARCH Test a sostegno dell analisi dei residui, applicato per fittare le innovazioni e per individuare l esistenza di momenti del primo momento. LBQ Test parte dall ipotesi nulla H 0, che rappresenta il caso in cui non c è correlazione tra un osservazione e la successiva per i vari istanti di tempo e prosegue calcolando il valore della variabile booleana H. Gli argomenti di output della funzione rappresentano: Variabile booleana H assume valore pari a 0, se l ipotesi nulla non viene rigettata, ed implica che non esistono significative correlazioni tra i dati, mentre assume valore pari a 1 se esiste correlazione tra i dati e si rigetta l ipotesi nulla. pvalue è un vettore di valori che esprimono il livello di significatività per cui LBQ test rigetta l ipotesi nulla per ogni valore del campo Lags. Qstat rappresenta i valori del LBQ test per ogni intervallo. CV o valore critico della distribuzione chi-quadro che corrisponde agli elementi presenti in Qstat. Sample Autocorrelation Function (ACF) H1 pvalue1 Qstat1 CV Lag Grafico 7.39 ACF dei Residui standardizzati ARMAX (2,4,0) GARCH (0,0) 104

110 Sample Autocorrelation Sample Autocorrelation Function (ACF) H2 pvalue2 Qstat2 CV2 1.0e+003 * Lag Grafico 7.40 ACF dei Residui standardizzati al quadrato ARMAX (2,4,0) GARCH (0,0) Il migliore risultato possibile lo possiamo ottenere con questa struttura, poichè aumentando il grado si peggiora esponenzialmente! 105

111 Residuals 7.6.2c Regressione Questo tipo di analisi mi permette di spiegare la relazione esistente tra una variabile risposta Y (output), ed una o più variabili dette covariate o input (X 1,X 2,,X N ), in modo da ottenere una funzione andando a considerare un opportuna componente di errore (sistematico o casuale): 11 Residual Case Order Plot 10 9 Andamento dei residui con le relative barre di confidenza, dopo un opportuna regressione Lineare. I Residui oscillano attorno allo zero, eccetto i valori in rosso (1160:1189) Case Number Grafico 7.41 Andamento dei Residui Nel grafico sottostante vado a riportare rispettivamente l andamento dei tempi di risoluzione y (linea blu) e i relativi tempi stimati (linea rossa) con la regressione Lineare. Si può vedere chiaramente come il tipo di regressione applicata non esegue un corretto fitting dell andamento dei tempi di risoluzione reali Andamento: y yhat Diff = y-yhat R^2: dovrebbe avere valori prossimi ad 1 Fstat 6 6 p-value 4 4 MSE Grafico 7.42 Andamento delle y stimate e dell errore di stima 106

112 Nel caso in cui vado ad utilizzare un fittaggio polinomiale (regressione polinomiale) di grado due, si vede chiaramente che una parte dei valori non vengono spiegati (vedere l andamento dei residui). Una regressione lineare non è corretta Grafico 7.43 Regressione Polinomiale di grado 2 Non individuando una chiara relazione tra l output e le variabili di input ho deciso di eseguire una regressione per singoli passi, identificando la relazione tra: 1. Tempi di Risoluzione e Categoria Service (1,2) con relative Tipologie (8); Interpolazione di tipo SPLINE: fitting che utilizza la funzione spline, che rappresenta un insieme di polinomi collegati tra loro, il cui obiettivo è interpolare un certo numero di punti (nodi) interni ad un intervallo in modo da essere continua. Dato A = {a = x 0 < x 1 < < x n = b}, una suddivisione dell intervallo chiuso [a,b], una funzione spline di grado p con nodi nei punti x i con i = 0,1,2,,n è una funzione indicata con s p (x) tale che nell intervallo chiuso si abbia: In ogni sottointervallo [x i,x i+1 ] con con i = 0,1,2,,n-1, la funzione s p (x) è un polinomio di grado p; La funzione s p (x) e le sue prime p-1 derivate sono continue. La variabile y è collegata alla categoria Service ha come tipologia soltanto le chiamate Errate (8), quindi è stato possibile applicare questo tipo di regressione. Di seguito sono forniti sia l andamento del fitting che i relativi residui. 107

113 0.012 y spline R 2 1 MSE e Grafico 7.44 Interpolazione spline di y rispetto a x1 e x residuals spline Grafico 7.45 Andamento dei Residui 2. Tempi di Risoluzione e Categoria Trouble (3,4,6) con relative Tipologie (8,10); Ho applicato un tipo di regressione esponenziale (la cubica mi restituisce lo stesso risultato) per fittare la relazione tra la variabile di output y, la categoria Trouble e la tipologia chiamate Errate (8) e Stampanti (10). Fitting Robusto LAR (Least Absolute Square): ricerca una curva che minimizza la differenza assoluta dei residui, piuttosto che la differenza quadratica. Quindi valori estremi hanno minore influenza sul fitting. 108

114 10 x2 vs. y cubic fit y = 8*exp(-3.745e-005*x) e-005*exp(12.91*x) R 2 : 1 MSE: 2.27e-005 Data and Fits x2 vs. y fit 1 y = 3.4*x 3-0.8*x *x+8 R 2 : 1 MSE: 0.992e Grafico 7.46 Regressione esponenziale - cubica di y rispetto a x1 e x x 10-5 Residuals 0 fit 1 6 x 10-3 residuals 4 cubic Grafico 7.47 Andamento dei Residui della regressione esponenziale e cubica 3. Tempi di Risoluzione e Categoria Trouble (7) con relative Tipologie (11); Ho applicato un tipo di regressione esponenziale per fittare la relazione tra la variabile di output y, la categoria Trouble e la tipologia relativa all Applicativo (11). Fitting Robusto BisSquare: minimizza una somma pesata di quadrati, in base alla distanza dei punti dalla linea di fitting; i punti vicini hanno maggiore peso e viceversa quelli più lontani. Questo metodo utilizza un algoritmo iterativo, che si suddivide in cinque passaggi: 1. Eseguire il fitting iniziale; 2. Calcolare i Residui Aggiustati e standardizzarli: r i minimi quadrati h i effetto leva che aggiusta i residui 109

115 K = 4, Standardizzare i Residui Aggiustati : s = Median Absolute Deviation Residual/0, Calcolare i pesi come funzione di u: 5. Se il fitting converge l algoritmo finisce, altrimenti si procede con una nuova iterazione. 9 y fit y = *exp(2.042*x) e-005*exp(2.246*x^3) R 2 : MSE: Data and Fits y fit Grafico 7.48 Regressione esponenziale di y rispetto a x1 e x Residuals 4 fit Grafico 7.49 Andamento dei Residui della regressione esponenziale 110

116 4. Tempi di Risoluzione e Categoria Trouble (5) con relative Tipologie (8); Ho applicato un tipo di regressione esponenziale per fittare la relazione tra la variabile di output y, la categoria Trouble e la tipologia chiamate Errate (8). Fitting Robusto BisSquare. Per cica l 11% le richieste errate incidono sul totale, creando un carico di lavoro eccessivo sugli operatori e quindi anche sui tempi di risoluzione y fit y = 6.63e-020*exp(0.4399*x) R 2 : MSE: Data and Fits y fit Grafico 7.50 Regressione esponenziale di y rispetto a x1 e x Residuals fit 1 Grafico 7.51 Andamento dei Residui della regressione esponenziale 5. Tempi di Risoluzione e Categoria Trouble (5) con relative Tipologie (10,11). Le tipologie (10) e (11) incidono per l 80% sul totale delle richieste Trouble e quindi sull allungamento dei tempi di risoluzione. Ho applicato un tipo di regressione gaussiano per 111

117 fittare la relazione tra la variabile di output y, la categoria Trouble e la tipologia e Stampanti (10) e Applicativo (11). Fitting Robusto BisSquare. 16 y 14 fit y = 6.154e+013*exp(-((x-896.7)/ 33.54)^2) *exp(-((x-915.1)/ 118.5)^2) R 2 : MSE: Data and Fits y fit Grafico 7.52 Regressione gaussiana di y rispetto a x1 e x Residuals 6 fit Grafico 7.53 Andamento dei Residui della regressione gaussiana Dall analisi di regressione si riesce a ricavare relazioni parziali tra le variabili in gioco. Forse una possibile causa, va ricercata nel fatto che non sono tenute in considerazioni variabili che sarebbero fondamentali per una corretta analisi, e per valutare una relazione di tipo complessivo tra i tempi di risoluzione dell Incidente e le variabili del processo. Gli aspetti rilevati sono: 1. Relazione di tipo esponenziale tra la richieste derivanti da PDL e di tipo Software e tipologie di Incidente legate all Applicativo e alle Stampanti. 112

118 2. Circa un 11% di chiamate Errate, non destinate all HDI, che allungano esponenzialmente i tempi di risoluzione degli Incidenti, incentivando anche i tassi di abbandono da parte dell Utente. 3. La possibili mancanza di variabili chiave non mappate, che non consento una precisa analisi di regressione su le variabili considerate. 7.7 Improve Achive Breakthrough Improvement Con la fase di Improve, sulla base delle analisi effettuate e sulla base delle cause principali e più impattanti si propongono e si attuano le azioni migliorative e correttive. Si cerca di pianificare gli interventi da implementare in modo tale da collocare i requisiti tradotti in CTQ entro i limiti di specifica, cercando di creare un miglioramento continuo e duraturo nel tempo. L obiettivo è ottimizzare i risultati conseguiti. Alla luce, da quanto è emerso dalla fase di Analyze, gli interventi che abbiamo deciso di implementare sono suddividibili in due categorie e sui tre Livelli degli HD Interventi Operativi Interventi Operativi su HD I: o Pulsantiera automatica con Albero Vocale, per la ricezione delle segnalazioni da Utente e per la categorizzazione dei principali problemi. o Periodo limitato di Task Force educativa per problemi specifici, che aiuti gli Utenti a individuare le risoluzioni di problemi standard con strumenti alternativi. Abbiamo deciso di proporre sul tavolo di lavoro con il Fornitore Esterno, la creazione di un processo, con la possibilità di incanalare su gruppi con specifiche competenze, determinate categorie di problemi standard. Il nuovo processo dovrebbe essere così sviluppato, con l inserimento di un Albero Vocale e la conseguente categorizzazione dei principali problemi riscontrati (c.a. un 70% Stampanti, SIO, Outlook): 113

119 Figura 7.54 Nuovo processo HDI Albero Vocale: a oggi, a causa di un disallineamento tra Anagrafica Banca e Fornitore Esterno, non è possibile aprire in automatico un ticket dalla Barra Telefonica, perdendo parte della tracciatura delle segnalazioni effettuate dell Utente. Con gli opportuni interventi tecnici del COG, sarà possibile aprire un ticket in automatico, con una corrispondenza biunivoca tra segnalazione e ticket, e offrire un servizio di richiamata in automatico in caso di linee occupate entro 30 minuti. Categorizzare il problema: a oggi non c è nessuna tipologia di categorizzazione del problema. Con le quattro categorie, stabilite in base alla stagionalità e ai rilasci, è stato possibile assegnare a ciascuna tipologia un gruppo specifico di operatori, dimensionato per fascia oraria e impatto e urgenza. La diretta conseguenza sarà una diminuzione del numero di ticket scalati all HD di 2 Livello, e la possibilità di creare Task Force formative per la Rete, in grado di insegnare all Utente come risolvere alcune categorie standard di problemi. Inoltre sarà necessario standardizzare le categorie utilizzate sia dall HD I sia dal COG, poiché non esiste a oggi, una regole precisa per la compilazione del ticket in REMEDY. Questo permetterà una migliore, più facile e più accurata estrazione dei dati e semplificherà il processo di escalation del ticket. Interventi Operativi su HD II: Garantire la tracciabilità di tutti gli Incidenti, attraverso l eliminazione di tutti i canali Inbound personali, indirizzando le richieste degli Utenti su un centralino / mail di 114

120 servizio per il COG e le richieste con elevata urgenza, mentre all HD I tutte le altre tipologie di Incidente. Creazione di un canale formale di input / ingresso attraverso la Barra Telefonica, per le richieste COG (non HW) e per le Linee di Emergenza. Creazione di indirizzi mail parlanti, che permettano una più facile ed intuitiva identificazione della struttura su cui indirizzare la segnalazione. Eliminazione di tutte le attività a non valore aggiunto (NVBA), per la riduzione dei tempi di risoluzione e di attesa dell Utente. Creazione di una struttura flessibile per la gestione dei ticket (Applicativo REMEDY e Barra Telefonica) sulla base del numero e della priorità delle richiesta, con la possibilità di poter effettuare un escalation interna sulla base delle competenze del personale. Abbiamo deciso di proporre sul tavolo di lavoro con il COG, la creazione di un processo, che preveda una struttura flessibile con due strade: un ingresso diretto da HD II tramite un apposito Centralino / mail per richieste di competenza o richieste urgenti, e un ingresso da REMEDY da HD I. Il nuovo processo dovrebbe essere così sviluppato con l inserimento di un Centralino per lo smistamento delle chiamate, e quindi due nuovi ingressi per il 2 Livello. Tale processo, prevede la possibilità per chiamate non formali, di reindirizzare la corretta segnalazione alla struttura competente, tramite i giusti contatti ( Altro per HD I, e COG per HD II). Figura 7.55 Nuovo processo HDII 115

121 Due Input con Centralino: la possibilità di due ingressi per tipologie di richieste differenti, permette la diminuzione del carico di lavoro cui è sottoposto l HD II, e la conseguente diminuzione dei tempi di risoluzione dell Incidente. Tutte le strutture devono essere dotate di Applicativo REMEDY, per tracciare il percorso del malfunzionamento segnalato dall Utente, e per eliminare tutti i tempi morti che sono alla base delle comunicazioni telefoniche con l operatore. Interventi Operativi su HD III: Assegnazione per tutte le 30 strutture del HD III dell Applicativo REMEDY, attraverso le Licenze disponibili, con l obiettivo di tracciare tutto il processo ed eliminare i tempi di attesa telefonici. Abbiamo deciso di proporre sul tavolo di lavoro con il COG, la creazione di un processo, che preveda una struttura simile al precedente con due strade: un ingresso diretto da HD III per richieste urgenti, e un ingresso da REMEDY da HD II. Il nuovo processo dovrebbe essere così sviluppato, con due nuovi ingressi per il 3 Livello. Figura 7.56 Nuovo processo HDIII Due Input: la possibilità di due ingressi per tipologie di richieste differenti, permette la diminuzione del carico di lavoro cui è sottoposto l HD III, e la conseguente diminuzione dei tempi di risoluzione dell Incidente. Tutte le strutture devono essere dotate di Applicativo REMEDY, per tracciare il percorso del malfunzionamento segnalato dall Utente, per mettere in correlazione il singolo problema con il rispettivo interlocutore, e per creare una conoscenza 116

122 globale delle soluzioni individuate, attraverso l opportuna compilazione dei campi REMEDY. Con tale processo si ha la possibilità di capire se l interlocutore contattato è corretto o meno, con la seguente nuova escalation del ticket. Comunicazione: Revisione del Portale del Consorzio, con modifica dell Home Page, mettendo in evidenza i numeri telefonici da contattare in caso di segnalazione, suddividendoli in numeri di riferimento per la Rete, la Capogruppo ed il COG. o o Identificare quali sono problemi di competenza dell HD Tecnico, evidenziando i numeri da chiamare. Ulteriore suddivisione per il COG, riguardo a problemi hardware e altro software, da indirizzare rispettivamente ad HD I ed HD II. Creare delle sottocategorie di problemi, sviluppando una campagna di comunicazione e formazione per l Utente, per l utilizzo di strumenti innovativi e alternativi per la risoluzione self service (Tutorial, Survey, MPS Channel). Abbiamo deciso di modificare la pagina Web del Portale del Consorzio, in modo da renderla più intuiva nel caso di contatto dei vari Help Desk. Il nuovo Portale permetterà di ridurre / eliminare il numero di chiamate indirizzate alle varie strutture, in modo da sviluppare un processo formale e di ridurre le segnalazioni non di competenza. La suddivisione prevedrà: 1. Help Desk Interno per problemi legati alle transazioni, all utilizzo di Applicativi (per esempio SIO o REMEDY), etc. Nella competenza dell HD Interno rientrano tutti i problemi di tipo software. 2. Help Desk Tecnico per problemi tecnici, quali configurazioni, PC e stampanti / multifunzione. Nella competenza dell HD Tecnico rientrano tutti i problemi di tipo hardware. Aggiornamenti in tempo reale riguardo a malfunzionamenti generali, che potrebbero compromettere le funzionalità dell intero servizio. 3. Nuova sezione riguardante Tutorial (utilizzo di appositi link per avere a disposizione l ausilio di filmati di pochi minuti che descrivono i passi principali delle varie operazioni da seguire per l Utente), per la risoluzione semplice e veloce di problemi standard. 117

123 Figura 7.57 Fac-simile Portale Interventi Tecnologici Interventi Tecnologici: Definire i Requisiti e le Linee Guida dell Applicativo REMEDY, da implementare in due fasi successive, sulla base del budget: o Definire Categoria, Impatto, Urgenza e Priorità degli Incidenti; gestire Task, Ruoli e Criteri di assegnazione degli Incidenti; creare un Interfaccia Tool User Friendly (software di facile utilizzo che grazie a un interfaccia grafica accattivante, menù, pulsanti e icone accompagnano l utente alla realizzazione dello scopo); integrare REMEDY con IBM Maximo Asset Management e Symantec Security Information Manager (SSIM, per aprire in automatico Incidenti di sicurezza). o Implementazione futura: integrare la gestione degli Incidenti con la gestione degli SLA interni; creare un database della conoscenza ( Know Error DataBase ); gestire la correlazione automatica di Incidenti e Problemi; creare un Sistema di Monitoraggio e Reportistica efficace; creare una Reportistica dei KPI sulla base di Qualità (la correttezza e l accuratezza del processo), di Compliance (l insieme delle conformità del processo rispetto 118

124 ai requisiti definiti), di Performance (la produttività del processo in termini di velocità, rendimento e utilizzo delle risorse) e di Valore (i risultati attesi dal processo). Sarà inoltre possibile l apertura dei ticket via Web per le Filiali. La possibilità di intervenire direttamente sugli strumenti, con la ridefinizione dei Requisiti principali e di maggiore importanza, permetterà di ottenere significativi miglioramenti al processo di Incident Management e al processo di GdS. I principali Requisiti su cui si è scelto di intervenire, sono: Categorizzazione dell incidente: rappresenta la distinzione tra le varie tipologie di un Incidente che viene effettuata nel momento in cui avviene l apertura, in seguito ad una segnalazione. Riduzione delle attività a non valore aggiunto. Riduzione delle attività a valore aggiunto. Riduzione della variabilità delle fasi critiche. Codifica Impatto, Urgenza e Priorità: Riduzione delle attività a non valore aggiunto. Riduzione delle attività a valore aggiunto. Riduzione del Cycle Time e del PCE. Riduzione della variabilità delle fasi critiche. Prioritizzazione dell Incidente. Rappresentano grandezze importanti per valutare i tempi di risoluzione dell Incidente e la procedura di escalation alla rispettiva struttura; inoltre sono grandezze fondamentali per sviluppare un adeguata reportistica a posteriori. Impatto: misura il potenziale danno causato dall Incidente sul processo di Business, si suddivide in quattro categorie, è può essere alterato anche dal possibile ruolo della struttura organizzativa VIP. 1. Critico: BU, LOB e Filiali altamente strategiche, altissimo numero di Utenti (Top Management). 2. Alto: BU, LOB e Filiali strategiche, alto numero di Utenti (Utenti VIP ). 3. Medio: BU, LOB e Filiali mediamente strategiche, medio numero di Utenti (singolo Utente VIP ). 4. Basso: BU, LOB e Filiali non strategiche, basso numero di Utenti. Urgenza: misura la velocità con cui un Incidente di un certo impatto deve essere risolto, poiché un Incidente ad alto impatto non sempre è di alta urgenza. 119

125 1. Critica: Servizi di Core Business, che impattano direttamente sugli aspetti finanziari, sull immagine e la sicurezza dell azienda. 2. Alta: Servizi medium di Core Business, che dipendono dalle strategie dell azienda. 3. Media: Servizi a Supporto del Business. 4. Bassa: Servizi non urgenti. Priorità: definisce l importanza di un Incidente su cui concentrare gli sforzi per identificare la migliore soluzione, sulla base del contesto e del tempo di risoluzione. Sarà quindi necessaria una codifica efficace che mi permetta di stabilire la priorità di un Incidente, sulla base di un determinata formula (1) e (2) e un range di valori quantificabili. Peso Impatto Classe Critico Alto Medio Basso Peso Urgenza Classe Critica Alta Media Bassa Impatto Urgenza Critica (20) Alta (30) Media (40)Bassa (50) Critico (4) C 24 C 34 A 44 A 54 Alto (5) C 25 A 35 A 45 A 55 Medio (20) A 40 A 50 M 60 M 70 Basso (35) M 55 M 65 M 75 B 85 Pesi 24<p<34 35<p<50 55<p<75 76<p<80 Descrizione Tempo di Risposta Tempo di Risoluzione Critica Alta Media Bassa 15 min 30 min 4 h 8 h 1 h 2h 8 h 24 h Tabella 7.58 Categorizzazione e Priorità 1. Priorità Critica: sforzo continuativo, utilizzando tutte le risorse a disposizione per la ricerca della risoluzione dell Incidente. 2. Priorità Alta: risposta immediata, con possibile interruzione delle attività a media / bassa priorità. 3. Priorità Media: risposta mediante le procedure standard. 4. Priorità Bassa: risposta mediante le procedure standard, senza vincoli di tempo. Know Error DataBase: rappresenta una fonte dati dove verranno registrate le procedure per ripristinare un servizio a valle di un Incidente, con la conseguente possibilità di attingere soluzioni per problemi simili in modo da velocizzare i tempi di diagnosi e risoluzione Riduzione delle attività a non valore aggiunto. Migliore efficacia della Risoluzione. 120

126 Reportistica: Migliore efficienza dei processi. Migliore efficacia dei processi. Studio delle interazioni esistenti tra il processo di Incident Management e tutti gli altri processi IT: Change, Problem, Configuration, Release e Asset Management. Abbiamo deciso di mappare l intero flusso del processo Gestione della Sicurezza, andando a considerare tutte le relazioni funzionali tra i vari processi del mondo IT, per la gestione ottimale dell intera organizzazione. Nuove Interazioni: L Incident rappresenta una singola parte dell intero processo GdS, e quindi sarà necessario l introduzione e lo sviluppo degli altri processi, per garantire la possibilità di risoluzione in tempi molto rapidi dei malfunzionamenti, una soluzione robusta e duratura nel tempo e il minimo disagio dei vari Utenti con il ripristino immediato del servizio. Event Management: permette di gestire gli Eventi della struttura IT, considerati come cambiamenti di stato. Il processo rappresenta un input e interagisce con: Incident: l Evento è alla base di un Incidente. Problem: l Evento è alla base di un Problema. Change: l Evento per la gestione del Cambiamento. Incident Management: permette di ripristinare l operatività con il minimo tempo e riducendo l impatto sul Business. Il processo rappresenta un input e interagisce con: Problem: l Incidente è alla base di un Problema. Configuration: l Incidente definisce l Impatto sull operatività. Change: l Incidente è base per la gestione del Cambiamento. Problem Management: permette di minimizzare l impatto sul Business degli Incidenti e dei Problemi del mondo IT, cercando di prevenirne la ricorrenza nel tempo. Il processo rappresenta un input e interagisce con: Incident: la Soluzione identificata è alla base della risoluzione dell Incidente. Configuration: il Problema definisce l Impatto sulla struttura IT. Change: la Soluzione identificata da implementare è alla base della gestione del Cambiamento. 121

127 Configuration Management: permette di fornire un Modello Logico dell infrastruttura per la gestione, il controllo e la verifica degli elementi attraverso. Il processo rappresenta un input e interagisce con: Problem: il Modello è alla base delle info sulla struttura IT. Change: il Modello è alla base delle info sulla struttura IT. Change Management: permette l utilizzo di metodi e procedure per un efficiente e rapida gestione del cambiamento all infrastruttura, cercando di minimizzare l impatto dell Incidente. Il processo rappresenta un input e interagisce con: Incident: la Gestione del Cambiamento è alla base dell Incidente. Configuration: la Gestione del Cambiamento è alla base dell infrastruttura IT. Release: la Gestione del Cambiamento è alla base di servizi del mondo IT. Release Management: permette di gestire i cambiamenti dei servizi del mondo IT. Di seguito viene riporto il processo GdS come realmente dovrebbe essere implementato. Figura 7.59 Intero processo GdS 122

128 7.8 Control Transform How day to day Business is Conducted Con la fase di Control, basandoci sugli interventi pianificati e attuati nella fase precedente, si cerca di quantificare l entità del miglioramento ottenuto, attraverso un monitoraggio continuo. L obiettivo è assicurarsi che gli interventi creino effettivo valore per il processo nel tempo, ovvero siano abbastanza robusti e integrati, in modo tale da evitare ricadute fuori dal perimetro. Questa fase, è tutt oggi in via di svolgimento, poiché è necessario un costante e continuo monitoraggio, per capire se le effettive implementazioni possono essere considerate o meno Best Practices. Sicuramente, viste le tipologie di intervento, che abbiamo effettuato, la fase di Control, avrà un orizzonte temporale di alcuni mesi. Il monitoraggio inizialmente verrà effettuato tramite delle Veline, con una struttura più semplice e di più veloce compilazione, dopo di che verranno valutati gli scostamenti dei dati raccolti, da quanto pianificato in fase di Define. La soluzione migliore, sarebbe introdurre un cruscotto digitale Web Based, che fornisca in tempo reale i dati ai tradizionali indicatori di processo. La fase finale di Control, è sicuramente un inizio, che permetterà di individuare aspetti cu cui introdurre nuovi miglioramenti. La quinta fase non è altro che l input per una nuova fase di Define, e per una nuova sfida Lean Six Sigma. Cambiamenti e miglioramenti continui e Requisiti sempre più performanti sono gli aspetti chiave su cui si basa la metodologia. 123

129 Capitolo 8 Conclusioni La metodologia Lean Six Sigma, ha permesso di determinare tutti i possibili benefici ottenibili dall implemetazione degli interventi di miglioramento, che abbiamo deciso di mettere in atto. Ad oggi non è possibile determinare con una certezza assoluta il raggiungimento degli obiettivi che ci siamo prefissati nel Project Charter, poiché la fase di Control è in via di svolgimento ed il processo essendo molto articolato e complesso non consente una tempistica soltanto di qualche settimana di monitoraggio. Benefici ottenibili ed in parte verificati: 1. La possibile eliminazione di tutti i canali per la segnalazione di malfunzionamento non formali, come: a. Chiamata o Mail personale dell Utente verso HD I. b. Mail da HD Interno verso HD I. c. Chiamata o Mail da HD Interno verso HD II. d. Chiamata dell Utente verso HD II. e. Chiamata o Mail personale dell Utente verso HD III. f. Chiamata o Mail da HD Esterno verso HD III. 2. La possibile riduzione dei tempi di attesa, dovuti al processo di escalation tra le varie strutture, nel momento in cui non viene identificata dal Livello interessato un opportuna soluzione. La possibile riduzione dei tempi di comunicazione tra la struttura che ha identificato la soluzione per il corretto ripristino del servizio, e l Utente finale. a. Waiting Time da 30 minuti a valori prossimi allo zero, durante il processo di escalation tra HD di 1 Livello ed HD di 2 Livello. b. Waiting Time da 10 minuti a valori prossimi allo zero, durante il processo di escalation tra HD di 2 Livello ed HD di 3 Livello. c. Waiting Time da 2 ore a valori prossimi allo zero, durante la comunicazione dell HD di 3 Livello all Utente finale. 3. La possibilità di sviluppare un processo maturo di Gestione della Sicurezza, con l interazione tra i vari processi del mondo IT, e con un processo di Incident 124

130 Management maturo e completo, all interno del quale ogni Livello (HD), ha la piena responsabilità di una parte di esso. 4. La possibilità di formalizzare in modo corretto, per ogni Incidente e Problema il giusto Interlocutore a cui rivolgersi, evitando la duplicazione di ruoli e competenze, la diminuzione del carico di lavoro per determinati operatori, ed infine una maggiore Qualità nell erogazione della Soluzione e del Servizio in genere. I benefici ottenuti e rilevati nel mese di Gennaio, nella fase di Control sono stati: % degli Incidenti tracciati dai sistemi, con l utilizzo dell applicativo REMEDY per tutti i Livelli. 2. Riduzione dei tempi di attesa durante la fase di escalation tra le strutture, grazie all introduzione di un filtro automatico alle telefonate: o o Riduzione del 17% con 37 minuti tra HD I e HD II. Riduzione del 70% con 44 minuti tra HD II e HD III % di categorizzazione degli Incidenti standard, attraverso un tavolo di lavoro per il miglioramento continuo del servizio (connessione diretta e costante tra HD I e HD II, mantenendo costantemente allineata l anagrafica oppure aggiornando periodicamente i rami dell albero vocale.) 4. Eliminazione del 14% di chiamate non di competenza, con lo smistamento automatico alle strutture di competenza (problemi di tipo standard legati alle Stampanti laser e Multifunzione). 5. Eliminazione di tutti i canali per le segnalazioni non formali. 125

131 Benefici Attesi: Figura 8.1 Benefici attesi Benefici Attesi con il Nuovo Albero Vocale per HD I: Riduzione di -14% Problemi Stampanti Altro Chiamate Errate, Altro Problemi Outlook, Internet Chiamate Errate, Altro, Problemi SIO Figura 8.2 Benefici con Albero Vocale per HD I 126

132 Benefici Attesi con il Nuovo Processo per HD I: Figura 8.3 Benefici con Nuovo processo HDI Benefici Attesi con il Nuovo Processo per HD II: Figura 8.4 Benefici con Nuovo processo HDII 127

133 Benefici Attesi con il Nuovo Modello di Gestione dell IT integrato: Figura 8.5 Benefici con Intero processo GdS 128

134 Elenco delle Figure 2.1 Miglioramento continuo con LSS Matrice RACI DMAIC Pain Point Workshop SIPOC Map KANO Matrix Project Charter Value Stream Map Spaghetti Diagram Pareto Analysis FMEA Ishikawa Diagram Interfaccia Applicativo REMEDY Strutture Organizzative del processo Gestione della Sicurezza Rilevare e Registrare il malfunzionamento Classificare l Incidente e fornire il supporto iniziale Analizzare e Diagnosticare l Incidente Risolvere l Incidente e Ripristinare il servizio Chiudere l Incidente Gantt Foto Pain Point Workshop Cartacea Foto SIPOC Map Cartacea Foto Voice of Customer Cartacea Affinity Diagram Foto KANO Matrix Cartacea

135 7.7 Foto Project Charter a Foto Value Stream Map Cartacea b Foto Value Stream Map Formalizzata Foto Travel Check Sheet Spaghetti Diagram VSM sintetica Nuovo processo HDI Nuovo processo HDII Nuovo processo HDIII Fac simile Portale Intero processo GdS Benefici ottenibili Benefici con Albero Vocale per HD I Benefici con Nuovo Processo HD I Benefici con Nuovo Processo HD II Benefici con Intero Processo GdS Elenco delle Tabelle 6.2 Glossario Acronimi Matrice RACI fase Matrice RACI fase Matrice RACI fase Matrice RACI fase Matrice RACI fase Tipologie di Incidente Tipologie di Richieste

136 7.19 Statistica descrittiva Sintesi giornaliera Veline Sintesi giornaliera REMEDY Sintesi HD II Sintesi HD III Categorizzazione e Priorità Elenco dei Grafici 7.11 Tasso di Abbandono di HDI e Chiamate in Ingresso Canali di Ingresso e Distribuzione del tempo lavorativo Distribuzione Chiamate HD I Tempo medio di Abbandono Chiamate HD I Tipologie di Incidenti Media risoluzione Sistema Media risoluzione Stampanti Media risoluzione Chiamate Errate Media risoluzione Internet Incidenza Mail HD II Incidenza Telefonate HD II Incidenza Mail + Telefonate HD II Incidenza Mail HD III Incidenza Telefonate HD III Incidenza Mail + Telefonate HD III Scatter plot tra le variabili y e x1 e y e x Scatter plot tra le variabili y e x1 e y e x Andamento dei tempi di risoluzione

137 7.37 Andamento ACF della Serie Andamento PACF della Serie ACF dei Residui standardizzati ARMAX (2,4,0) GARCH (0,0) ACF dei Residui standardizzati al quadrato ARMAX (2,4,0) GARCH (0,0) Andamento dei Residui Andamento delle y stimate e dell errore di stima Regressione Polinomiale di grado Interpolazione spline di y rispetto a x1 e x Andamento dei Residui Regressione esponenziale - cubica di y rispetto a x1 e x Andamento dei Residui della regressione esponenziale e cubica Regressione esponenziale di y rispetto a x1 e x Andamento dei Residui della regressione esponenziale Regressione esponenziale di y rispetto a x1 e x Andamento dei Residui della regressione esponenziale Regressione gaussiana di y rispetto a x1 e x Andamento dei Residui della regressione gaussiana

138 Bibliografia Introduzione e Capitolo1: [1] Sito web: [2] Sito web: Introduzione e Corpo: [3] Libro: Michael L.George, John Maxey, The Lean Six Sigma Pocket Toolbook - A Quick Reference Guide to Nearly 100 Tools for Improving Process Quality Speed &Complexity McGraw Hill, [4] Libro: Michael L.George, Lean Six Sigma for Service, McGraw Hill, [5] Dispense: Gestione Progetti e RU, Project Management e Gestione delle Risorse Umane, [6] Dispense: Alfio Pelli, Applicazione del LSS per l innovazione didattica, Padova, [7] Sito web: [8] Materiale Accenture, [9] Materiale interno: Slides Consorzio Operativo del MPS, [10] Sito web: 133

139 Allegati Pain Point Workshop Formalizzato v

140 SIPOC Map Formalizzata vi

141 KANO Matrix Formalizzata Project Charter Formalizzata vii

142 viii

143 VSM Formalizzata ix