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
