Un nuovo modo di misurare il successo dei Progetti ICT

Transcript

1 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

2 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

3 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 Il Il business percepisce l IT l IT come un un fornitore di di tecnologia a cui cui chiedere di di contenere i i costi, non non come un un partner da da coinvolgere nelle iniziative strategiche in in modo strutturato

4 Organizzazione Scarsa industrializzazione dei processi IT 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, 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 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 duplicazione di di competenze competenze specialistiche, specialistiche, demotivazione demotivazione per per assenza assenza di di ruoli ruoli ben ben definiti, definiti, conoscenze conoscenze embrionali embrionali di di Project Project Management Management

5 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 Disallineamento con con gli gli obiettivi obiettivi della della committenza, committenza, maggiori maggiori costi, costi, ritardi ritardi nella nella consegna, consegna, inefficienza inefficienza nell utilizzo nell utilizzo delle delle risorse, risorse, rischi rischi di di progetto progetto non non adeguatamente adeguatamente presidiati presidiati

6 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 al fine di rispettare le scadenze concordate coi clienti e non costituisce il reale momento di verifica dell esercibilità del nuovo servizio Mancanza del piano dei rilasci in produzione 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, (WBS, PMP, RAM, compromissione etc.) degli investimenti effettuati in fase di sviluppo, Inefficienza, compromissione degli investimenti effettuati in fase di sviluppo, scarse scarse capacità capacitàdi di prevenzione prevenzione e di di controllo controllo dei dei cambiamenti cambiamenti

7 Esercizio Gestione dei Sistemi Informativi non integrata scarsa automazione ed informatizzazione dei processi di monitoraggio end-to-end, configuration mgmt, incident mgmt ed SLM 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 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 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 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 Disattesi gli gli accordi accordi presi presi con con il il business, business, compromissione compromissione degli degli investimenti investimenti effettuati effettuati in in fase fase di di sviluppo sviluppo

8 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 IT Service Service Management Management è la la disciplina disciplina che che inquadra inquadra il il modello modello di di governo governo del del Dipartimento Dipartimento IT IT in in modo modo standardizzato, standardizzato, consentendo consentendo di di definire definire le le priorità prioritàin in modo modo coerente coerente ai ai bisogni bisogni del del business business ed ed ai ai vincoli vincoli organizzativi organizzativi ed ed economici economici

9 Agenda Criticità nella gestione dell IT Convergenza tra ITSM e PM Il caso di studio Conclusioni Slide 9

10 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 Project Portfolio, Management Program e Project Management Sviluppo Esercizio

11 Le fasi dell integrazione Business requirements Business requirements Business requirements Business requirements Design and Development Pilot or Warranty Period Live Operation Project Management Document & Agree business Requirements (Strategy and Design) Service Strategy Design service Solution (Design) Develop service Solution (Design) SDP Build transition Solution (Transition) Test Service Solution (Transition) Service Design Service Transition Service Transition and Operation Involvement Service Operation Service Improvement

12 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

13 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

14 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

15 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

16 Agenda Criticità nella gestione dell IT Convergenza tra ITSM e PM Il caso di studio Conclusioni Slide 16

17 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 PROCESS RELEASE Programmazione Percorso di qualificazione Delivery HW Delivery SW Delivery Impianti Speciali Technical Support Gestione sistemi e servizi di rete Gestione DB Gestione rete Gestione applicativi PROCESSI CORE OPERATIONS Desktop Management Continuity Management Gestione impianti speciali Configuration Management Facility Management Availability 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

18 PROGRAM MANAGEMENT Direttore ICT Referente di Progetto Respons. d Area Project Controller DEMAND MANAGEMENT Demand Manager Referente Soluzione Applicativa Cliente Interno Project Manager PROJECT MANAGEMENT SOLUTION & SISTEM INTEGRATION CHANGE & RELEASE MANAGEMENT Deployment Manager Change Manager Release Manager Impianto di processi PORTFOLIO MANAGEMENT AREA 1 AREA 2 AREA n Responsabile dello Sviluppo Team di Sviluppo Continual Service Improvement Continual Service Improvement Service Transition Service Operation Governance Methods Standards Alignment Case Studies Service Design Service Strategies Templates ITIL Scalability Quick Wins Qualifications Knowledge & Skills Specialty Topics Continual Service Improvement Executive Introduction Study Aids

19 Framework di riferimento Pianificazione Esecuzione Controllo Vista Strategica Vista Operativa Definizione del piano investimenti, distribuzione del Bduget (definizione, aggiornamento, riprevisione) Definizione della Domanda (Esigenze, Requisiti, Priorità, Tempistiche) Definizione del Masterplan e allocazione delle risorse finanziarie (Pianificazione e ripianificazione) Verifica della congruenza tra le esigenze di business (prospect) e le risorse economiche allocate Verifica dell allineamento tra le esigenze di business e i risultati prodotti SAL tecnico-economico dei progetti; Verifica di adozione della metodologia; Piano Strategico Aziendale Domanda Programmi Progetti 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) Milestone Attività Deliverable Slide 19

20 Agenda Criticità nella gestione dell IT Convergenza tra ITSM e PM Il caso di studio Conclusioni Slide 20

21 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