Un nuovo modo di misurare il successo dei Progetti ICT - PMI-NIC
annuncio pubblicitario
Con il patrocinio di: Sponsorizzato da: Il Framework ITIL® e gli Standard di PMI®: possibili sinergie Milano, Venerdì, 11 Luglio 2008 Un nuovo modo di misurare il successo dei Progetti ICT Ing. Stefano Aiello – Partner HSPI SpA Agenda • Criticità nella gestione dell’IT – – – – – – Relazione con il cliente Organizzazione Sviluppo Change e Deployment Esercizio So What? • Convergenza tra ITSM e PM • Il caso di studio • Conclusioni Slide 2 Relazione con il cliente • • • • • Non esiste una definizione dei servizi IT condivisa con il business Nelle Direzione IT è scarsa la comprensione di come i servizi IT contribuiscano al business aziendale Non è chiaro come sia effettuata la costificazione dei servizi IT fruiti dal Business La qualità (performance, disponibilità, tempi di risoluzione malfunzionamenti) dei servizi IT non è concordata con i clienti Scarsa integrazione con le Divisioni di Business – Assenza o immaturità dei processi di Demand, Portfolio Mgmt, Service Level Mgmt, ICT Costing • Prevalenza di un rapporto con il cliente reattivo piuttosto che pro-attivo – Frequente ingaggio in soluzione di emergenze e contingenti IlIlbusiness businesspercepisce percepiscel’IT l’ITcome comeun unfornitore fornitoredi ditecnologia tecnologia aacui cuichiedere chiederedi dicontenere contenereiicosti, costi,non noncome comeun unpartner partner da dacoinvolgere coinvolgerenelle nelleiniziative iniziativestrategiche strategichein inmodo modostrutturato strutturato Organizzazione • Scarsa industrializzazione dei processi IT – – – • Mancanza della cultura dell’accountability e del controllo – • Assenza di referente unico a cui è assegnata in modo chiaro la responsabilità di un processo Ruolo del Project Manager non sempre definito esplicitamente – • unità organizzative dedicate a piattaforme: silos all’interno dei quali sono replicate tutte le attività (Acquisto, sviluppo e gestione dell’IT) difficilmente i vari silos coinvolti nelle medesime attività sono in grado di raccordare i vari contributi, sia in pianificazione che in esecuzione, per Progetti e servizi Assenza di un’organizzazione del lavoro per processi: progettazione, sviluppo, deployment, gestione operativa, supporto utente, … selezione del PM legata prevalentemente alle conoscenze tecnologiche richieste dallo specifico progetto e al grado di anzianità in Azienda proporzionale alla dimensione del Progetto Mancanza Piano di Formazione – – aggiornamento competenze specialistiche Scarsa considerazione delle competenze gestionali e relazionali Inefficienza, Inefficienza,duplicazione duplicazionedi dicompetenze competenzespecialistiche, specialistiche,demotivazione demotivazioneper per assenza di ruoli ben definiti, conoscenze embrionali di Project Management assenza di ruoli ben definiti, conoscenze embrionali di Project Management Sviluppo • Mancanza di interfacce uniche tra il cliente e il Dipartimento IT – • • insufficiente visibilità delle iniziative in corso, duplicazione delle attività, inefficienze nella gestione delle risorse condivise Servizi IT che non soddisfano le esigenze del business – errata interpretazione dei requisiti espressi dal business, – mancanza di rilevamento requisiti sulle modalità di erogazione all’utente finale Scarsa integrazione della funzione di Esercizio – Difficilmente il Team di Progetto contempla, sin dalla concezione dell’iniziativa, il coinvolgimento strutturato di risorse dell’Esercizio per il capacity mgmt, il SLM, il change mgmt (anche allocando risorse adeguate) • Gestione dei progetti ICT poco strutturata e formalizzata • Architetture scarsamente razionali • – Soluzioni eterogenee, con conseguenti difficoltà a presidiare le competenze necessarie – Tecnologie le cui potenzialità sono parzialmente adottate, duplicazione di strumenti, … Raramente vengono analizzati i rischi di progetto – informatici, organizzativi, di pianificazione, di comunicazione, etc. al fine di ridurre in anticipo, di concerto con il business, le cause di rischio e di governarne gli eventuali impatti Disallineamento Disallineamentocon congli gliobiettivi obiettividella dellacommittenza, committenza,maggiori maggioricosti, costi,ritardi ritardinella nella consegna, consegna,inefficienza inefficienzanell’utilizzo nell’utilizzodelle dellerisorse, risorse,rischi rischidi diprogetto progettonon non adeguatamente presidiati adeguatamente presidiati Change e Deployment • • Assenza di un processo definito di analisi ed autorizzazione delle change request – Analisi costi, impatti in esercizio, tempi, priorità – ) e di integrazione nelle regole complessive di gestione del Progetto Il passaggio in esercizio è effettuato spesso in emergenza – • Mancanza del piano dei rilasci in produzione – • al fine di rispettare le scadenze concordate coi clienti e non costituisce il reale momento di verifica dell’esercibilità del nuovo servizio Collaborazione di Sviluppo ed Esercizio alla definizione e revisione della programmazione dei passaggi in produzione su finestre temporali di 2-3 mesi Mancanza di requisiti di esercibilità – Documentazione, monitorabilità, formazione operatori, … – Definiti in collaborazione tra Sviluppo ed Esercizio e verificati prima del passaggio di consegne • Le risorse economiche del progetto sono esaurite prima della fase di passaggio in produzione, che quindi deve essere gestita in economia • Non si tiene traccia in modo regolare dei cambiamenti effettuati agli ambienti di produzione – e di come questi cambiamenti siano inclusi e gestiti all’interno di strumenti specifici di Project Management Inefficienza, compromissione degli Inefficienza, compromissione degliinvestimenti investimentieffettuati effettuatiin infase fasedi disviluppo, sviluppo, (WBS, PMP, RAM, etc.) scarse scarsecapacità capacitàdi diprevenzione prevenzioneeedi dicontrollo controllodei deicambiamenti cambiamenti Esercizio • Gestione dei Sistemi Informativi non integrata – • • • • L’Esercizio non è responsabile del layer applicativo La responsabilità del Deployment non è assegnata in modo esplicito All’interno dell’Esercizio vi sono limitate competenze di Project Management Sistemi di misura delle performance non strutturati – – • • scarsa conoscenza dei propri asset, del loro stato e del controllo delle corrispondenti attività di competenza dei fornitori Tempi molto lunghi per la risoluzione di incidenti – • osservazione delle misure effettuate solo in seguito ad eventi critici Performance dei fornitori (UC) non definite in funzione della qualità dei servizi end-to-end (SLA) da erogare ai clienti e non monitorate adeguatamente Eccessiva dipendenza dai fornitori anche per i sistemi critici – • scarsa automazione ed informatizzazione dei processi di monitoraggio end-to-end, configuration mgmt, incident mgmt ed SLM conseguenza anche di passaggi in produzione in emergenza L’Esercizio fa affidamento quasi unicamente su poche figure senior (eccezionali problem solver) ai quali chiede grandi sacrifici L’IT non analizza regolarmente i malfunzionamenti al fine di individuare eventuali trend o pattern Disattesi Disattesigli gliaccordi accordipresi presicon conililbusiness, business,compromissione compromissionedegli degliinvestimenti investimenti effettuati effettuatiin infase fasedi disviluppo sviluppo So What? • Non tutti Dipartimenti IT esperimentano queste criticità e non tutte le azienda necessitano di un Dipartimento IT che funzioni in modo perfetto • Occorre trovare un equilibrio tra i bisogni dell’azienda ed i bisogni di risorse per il miglior funzionamento del Dipartimento IT, combinando competenze, conoscenze e strumenti specifici di Project Management L’IT L’ITService ServiceManagement Managementèèlaladisciplina disciplina che inquadra il modello di governo che inquadra il modello di governodel del Dipartimento DipartimentoIT ITin inmodo modostandardizzato, standardizzato, consentendo consentendodi didefinire definirelelepriorità prioritàin in modo coerente ai bisogni del business modo coerente ai bisogni del businessed ed aiaivincoli organizzativi ed economici vincoli organizzativi ed economici Agenda • • • • Criticità nella gestione dell’IT Convergenza tra ITSM e PM Il caso di studio Conclusioni Slide 9 Integrazione PM e IT Service Mgmt Ieri • • • il Project Management supporta la realizzazione di un servizio IT nel rispetto degli obiettivi, dei tempi e dei costi concordati con il committente il Project Management appannaggio solo delle funzioni IT di Sviluppo L’introduzione della disciplina limitata a singoli contesti progettuali particolarmente complessi, nessuna connotazione “Enterprise” della soluzione di Project Management Oggi e domani • • • • i clienti delle Direzioni IT richiedono/richiederanno non solo il rispetto dei requisiti funzionali, ma anche che il Servizio IT sia/sarà erogato nel rispetto di livelli qualitativi e costi concordati in fase di definizione del servizio garantire tale qualità richiede/richiederà il coinvolgimento delle funzioni e dei processi di Esercizio nelle fasi di progettazione e realizzazione dei nuovi servizi IT Necessario garantire un governo centralizzato delle risorse coinvolte nella Direzione dei SI contemplando tutte le fonti di consumo (Program, Project, Operation, etc.) e i flussi di integrazione con gli altri processi aziendali impattati dal mondo dei progetti (Procurement, Quality, Human Resource, etc.) Adottare la metodologia di Portfolio, Program e Project Mgmt a supporto dei meccanismi di funzionamento della Direzione dei Sistemi Informativi nel suo complesso Portfolio, Program e Project Management Project Management Sviluppo Esercizio Le fasi dell’integrazione Business Business requirements requirements Business Business requirements requirements Business Business requirements requirements Business Business requirements requirements Pilot or Warranty Period Design and Development Live Operation Project Management Document Document && Agree Agree business business Requirements Requirements (Strategy (Strategy and and Design) Design) Design Design service service Solution Solution (Design) (Design) Develop Develop service service Solution Solution (Design) (Design) Service Strategy Build Build transition transition Solution Solution (Transition) (Transition) Test Test Service Service Solution Solution (Transition) (Transition) SDP SDP Service Design Service Transition Service Transition and Operation Involvement Service Operation Service Improvement Un nuovo modo di misurare il successo dei progetti IT • Per quanto detto, il successo di un progetto IT non può essere misurato solo alla fine delle fasi di progettazione e realizzazione con la verifica del rispetto dei requisiti funzionali, dei tempi e dei costi di progetto, ma anche verificando: – Il contenimento degli impatti sull’esercizio al passaggio in produzione dei servizi implementati – Il rispetto dei livelli di servizio concordati con il Cliente Contenere gli impatti sull’esercizio • Ottenere questo obiettivo presuppone: – Nella fase di progettazione: • valutare gli impatti di nuovi servizi IT o di loro variazioni (Change Mgmt, Capacity Mgmt) – FM, rete, sicurezza, elaborazione, storage, … FTE, skill, … Strumenti di gestione • concordare con l’Esercizio i requisiti di esercibilità – Documentazione, formazione, monitorabilità, … • prevedere il coinvolgimento dell’Esercizio nella definizione degli SLA dei servizi da implementare – Prevedere risorse dell’Esercizio nel Team di Progetto sin dall’avvio del Progetto – Costruire il Progetto attraverso tecniche di pianificazione multi livello che coprano l’evoluzione dell’intervento progettuale dalla definizione dei requisiti del servizio e impostazione del corrispondente Progetto alla programmazione delle attività del rilascio in esercizio riportando esplicitamente i vincoli e i fabbisogni dichiarati dall’Esercizio e ne integrino in un unico Piano di Progetto i relativi contributi Slide 13 Rispetto dei livelli di servizio concordati • Includere la qualità percepita dal cliente come KPI di Progetto significa – Concordare sulla base delle esigenze del cliente i livelli di servizio e i relativi costi programmati nella fase di progettazione dalle funzioni di Sviluppo ed Esercizio – Prevedere la misurabilità dei principali anelli della catena produttiva che consentano il calcolo corretto degli SLA – Identificare un periodo significativo successivo al rilascio in produzione nel corso del quale effettuare la misura dei livelli di servizio erogati confrontandoli con quelli concordati. Slide 14 Punti di attenzione organizzativi delle best practice • Tra i ruoli organizzativi identificati da ITIL v3 non compare alcun ruolo riconducibile al Program manager o al Project Manager • Mentre è abbastanza chiaro come il Portfolio Management possa essere ricondotto al Service Portfolio Management il cui attore di riferimento è il Product Manager • Le responsabilità della figura del Product Manager potrebbero essere estese a quelle di Program Manager e di Project Manager • Nell’ITIL v3 non vi sono elementi ostativi alla realizzazione di modelli di funzionamento della Direzione Sistemi Informativi che adottino un’organizzazione a matrice forte e che prevedano la realizzazione della struttura organizzativa del PMO Agenda • • • • Criticità nella gestione dell’IT Convergenza tra ITSM e PM Il caso di studio Conclusioni Slide 16 EPM - DSI Trenitalia SpA Programma di progettazione e implementazione di un Modello di Governo dell’ICT basato su una logica “A Servizi” in grado di esprimere capacità di presidio sull’intera catena dell’ICT, di interagire con l’Outsourcer ed i fornitori attraverso un approccio orientato ai servizi e secondo i propri modelli operativi (metodologie, standard, procedure, tool, KPI, SLA, etc.) CATEGORY MAJOR PROCESS RELEASE PROCESS Programmazione Technical Support OPERATIONS Desktop Management Percorso di qualificazione Gestione sistemi e servizi di rete Gestione impianti speciali Delivery HW Gestione DB Configuration Management PROCESSI CORE Continuity Management INCIDENT & PROBLEM MANAGEMENT Incident Management Problem Management GESTIONE SICUREZZA Gestione sicurezza fisica Gestione Sicurezza logica Scomposizione di I livello Modello dei processi Modello organizzativo Job description Delivery SW Gestione rete Facility Management Delivery Impianti Speciali Gestione applicativi Availability Management Impianto di processi PORTFOLIO MANAGEMENT Direttore ICT Governance Methods e dg le w no K Continual Service Improvement AREA 2 AREA n en t pics alty To Service Transition ic Qu Aid s kW in Sc alab ility Co n Im tinu pro al vem Ser en vic e t Speci Templates AREA 1 nm ies Stud Cliente Interno Ali g ITIL n tio DEMAND MANAGEMENT s se uc trod e In tiv cu Demand Manager Stu dy Project Manager rd Service Strategies Service Operation ice erv t lS ua men tin rove Con Imp Referente di Progetto Project Controller nd a Service Design Exe Respons. d’Area Sta ills Sk Ca PROJECT MANAGEMENT PROGRAM MANAGEMENT & s Qualifications SOLUTION & SISTEM INTEGRATION CHANGE & RELEASE MANAGEMENT Referente Soluzione Applicativa Responsabile dello Sviluppo Deployment Manager Team di Sviluppo Change Manager Release Manager Framework di riferimento Pianificazione Esecuzione • Definizione del piano Vista Strategica • Verifica della investimenti, distribuzione del Bduget (definizione, aggiornamento, riprevisione) congruenza tra le esigenze di business (prospect) e le risorse economiche allocate • Verifica • Definizione della dell’allineamento tra le esigenze di business e i risultati prodotti Domanda (Esigenze, Requisiti, Priorità, Tempistiche) Vista Operativa Controllo • Definizione del Masterplan e allocazione delle risorse finanziarie (Pianificazione e ripianificazione) Piano Strategico Aziendale Domanda Programmi • SAL tecnico-economico dei progetti; Progetti • Verifica di adozione della metodologia; Fasi Dimensioni di Analisi CLIENTE; APPLICAZIONE; PROCESSI; DIVISIONE TIPO ATTIVITA’ (NUOVO SVILUPPO, EVOLUZIONE, STUDI; TIPO DI INVESTIMENTO (INNOVAZIONE, CRESCITA, EFFICIENZA, …) PRIORITA’ PER CLIENTE (ALTO, MEDIO, BASSA) INDICATORI ECONOMICI (Analisi del piano operativo: pianificato, consuntivi e stime al completamento) INDICATORI DI PROGETTO (Andamento tempi, effort e scopo dei progetti e dei rilasci) Slide 19 Milestone Attività Deliverable Agenda • • • • Criticità nella gestione dell’IT Convergenza tra ITSM e PM Il caso di studio Conclusioni Slide 20 Conclusioni • PM e ITSM sono le due leve con cui il CIO attua l’IT Governance • Dalla loro integrazione dipende: – il valore erogato al business – Il controllo dei costi e dei tempi complessivi del ciclo di vista dei servizi IT • Il Pj Mgr dovrebbe essere misurato anche in base agli impatti sull'esercizio ed il rispetto dei livelli di servizio • Le discipline (PMI e ITIL) vanno convergendo Slide 21
