Governo dell`ICT - The Innovation Group

Transcript

The Innovation Group
Aggiornamento n.15 della
Circolare Banca d’Italia
n. 263/2006
Gli aspetti organizzativi e gli
impatti su sistemi informativi e
processi: punti d’attenzione
Milano, 15 aprile 2014
Agenda
• Premessa
• Considerazioni sulle novità normative
• Ricadute su ICT
• Conclusioni
© 2014 KPMG S.p.A., KPMG Advisory S.p.A., Nolan, Norton Italia S.r.l., KPMG Fides Servizi di Amministrazione S.p.A., KPMG Audit S.p.A., società per azioni di diritto italiano, e Studio Associato Consulenza legale
e tributaria, un'associazione professionale di diritto italiano, fanno parte del network KPMG di entità indipendenti affiliate a KPMG International Cooperative ("KPMG International"), entità di diritto svizzero. Tutti i diritti
riservati.
1
Premessa
L’entrata in vigore delle disposizioni di vigilanza di Banca d’Italia (Circolare 263 del 27 dicembre 2006,
15º aggiornamento del 2 luglio 2013) ha posto agli Istituti bancari italiani un’esigenza di rilevante
aggiornamento/ evoluzione negli ambiti oggetto della Normativa, per quanto l’effettivo impatto
possa variare in funzione dell’attuale livello di maturità del singolo intermediario negli specifici
ambiti.
Nelle slide seguenti sono riportati….
….un minimo di inquadramento normativo
…. alcune considerazioni sul significato operativo di cosa implica applicare la normativa 263 in
ambito ICT
riservati.
2
Premessa: l’aggiornamento normativo
La normativa in materia di sistema dei controlli interni, sistema informativo e continuità operativa è finalizzata a:
FINALITÀ
• Rafforzare le capacità delle banche nella gestione dei rischi aziendali;
• Rivedere in modo organico e omogeneizzare il quadro normativo relativo alla materia in oggetto.
2012
SETT
2013
DIC
4/09/2012
3/12/2012
Pubblicazione
Termine
documento di consultazione
consultazione
GIU
26/06/2013
Emanazione
CRD IV
e CRR
2014
LUG
DIC
2-3/07/2013
Emanazione
documento e
entrata in vigore
2015
2016
LUG
FEB
LUG
LUG
1/07/2014
Efficacia
disposizioni
Cap. 7 e
Cap.9
1/02/2015
Efficacia
Disposizioni
Cap. 8
1/07/2015
Efficacia disposizioni
su funzioni risk
management e
compliance (Cap.7,
sez. III, par.1, lett. b)
1/07/2016
Efficacia esternalizzazione
funzioni aziendali (sez. IV,
V) e sistema informativo
(sez. VI )
Interventi di adeguamento
PRINCIPALI TEMATICHE TRATTATE
Sistema dei controlli interni
Sistema Informativo
Continuità Operativa
(Titolo V, Capitolo 7)
riservati.
3
L’aggiornamento normativo: i temi chiave
Capitolo
Sezione
Stima di impatto
sulla funzione IT
• Il ruolo degli organi aziendali (Org. con funzione di supervisione
Capitolo 7
Sistema dei
controlli interni
strategica, Org. con funzione di gestione, Org. con funzione di controllo)
• Funzioni aziendali di controllo
• Risk appetite Framework
PARZIALE/
BASSO
• Esternalizzazioni di funzioni aziendali (outsourcing)
• Governo e Organizzazione del Sistema Informativo
Capitolo 8
Sistema
Informativo
• L’analisi del rischio informatico
• La gestione della sicurezza informatica
ALTO
• Il sistema di gestione dei dati
• L’esternalizzazione del Sistema Informativo
Capitolo 9
Continuità
Operativa
• Disposizioni di carattere generale
• Requisiti per tutti gli operatori
MEDIO/
BASSO
• Requisiti particolari per i processi a rilevanza sistemica
L’entrata in vigore delle nuove disposizioni di vigilanza comporta un notevole cambiamento/aggiornamento per
gli intermediari finanziari. La magnitudo dell’impatto dipende dalla specificità di ogni intermediario.
riservati.
4
L’aggiornamento normativo: i punti di attenzione
Impatti in mabito ICT per
organizzazione e processo
significativi
Interazioni tra rischio
informatico e rischi
operativi
Ruolo chiave delle attività e
dell’approccio di analisi e
gestione del rischio
Complessità degli interventi
(tecnologici/organizzativi)
richiesti
Interrelazioni con altre
normative (es. D. Lgs.
196/2003, D. Lgs. 231/2001
ecc.)
Complessità della
documentazione per la
gestione dell’ICT (slide
seguente)
L’aggiornamento normativo ha un impatto significativo su una molteplicità di aspetti.
Si delinea inoltre un tema di sostenibilità degli interventi da parte delle strutture coinvolte, sia in termini di
progetto (oneri one-off), sia di esercizio nel continuo e di manutenzione dell’impianto complessivo
riservati.
5
L’aggiornamento normativo: l’impatto diretto sui Sistemi Informativi
 Organizzazione della funzione di ICT, sicurezza informatica, controllo del rischio
informatico, compliance ICT e i compiti della funzione di revisione interna
 Strategie di sviluppo del sistema informativo e modello di riferimento per l’architettura dello
stesso
 Valutazione dell’adeguatezza dei servizi erogati in rapporto all’evoluzione aziendale e ai costi
sostenuti
Sistema dei
controlli
interni
 Approvazione del disegno dei processi di gestione del sistema informativo
 Valutazione del rischio potenziale cui sono soggette le risorse informatiche esaminate
(Titolo V, Cap. 7)
Sistema
Informativo
(Titolo V, Cap. 8)
Continuità
Operativa
 Individuazione delle misure di sicurezza idonee a conseguire il contenimento del rischio
individuato (trattamento del rischio)
 Policy di sicurezza informatica approvata dall’organo con funzione di supervisione strategica e
comunicata a tutto il personale e terze parti
 Sicurezza delle informazioni e delle risorse ICT (presidi fisici, accessi logici, autenticazione,
monitoraggio, tracciamento, sviluppo sicuro del SW, gestione del personale, ecc.)
 Gestione dei cambiamenti
 Gestione degli incidenti di sicurezza
(Titolo V, Cap. 9)
 Disponibilità delle informazioni e dei servizi ICT
 La gestione dei dati deve soddisfare specifici requisiti (es.: data governance, data warehouse,
documentazione delle procedure di gestione dei dati, ecc. ...)
 Applicazione della politica di esternalizzazione (anche in funzione dei requisiti alla sezione IV del
cap. 7) con disposizione di specifiche indicazioni
 Valutazioni dei rischi connessi al cloud computing
L’aggiornamento normativo pone l’accento (che “arbitrariamente” evidenziamo) su una serie di aspetti:
Governo
(strategico e
operativo) dell’ICT
• Il presidio dell’Architettura
• Il presidio del Software Development
LifeCycle - SDLC(processi di gestione)
Gestione del
Rischio in ambito
informatico
• L’applicazione del Risk Appetite
Framework in ambito ICT (e
collegamento con coerente con il cap.7)
riservati.
6
Governo dell’ICT: il presidio dell’architettura
ICT Architecture
Insieme di principi, linee guida o regole utilizzate per guidare il processo di acquisizione,
sviluppo, modifica ed interfaccia di componenti IT.
Gartner, IT Glossary
I livelli di astrazione dell’architettura
Perché è importante
• Conservazione e valorizzazione degli asset
aziendali
• Gestire il cambiamento per minimizzare impatti e
valorizzare gli investimenti
• Risolvere le complessità derivanti dalla
eterogeneità degli ambienti in ambiti enterprise
• Indirizzare in modo organico i nuovi modelli di
business e le evoluzioni tecnologiche
• Conciliare aspetti economici ed organizzativi
legati all’integrazione dei sistemi
Per garantire efficacia di azione all’ICT Architecture devono esserne chiaramente definiti: Mission e Ruolo,
Ampiezza dei domini (infrastrutture, applicazioni, dati, processi, logiche di integrazione), Autorevolezza / Skill need
riservati.
7
Innovazione
Architettura come
presidio delle
“regole”
S.I.
stabile
Il ruolo in
strutture
complesse
Architettura come
guida e responsabile
del turnaround del
sistema
• Ruolo che oscilla tra due estremi:
 Innovazione ↔ controllo coerenze tecnologiche
 Ruolo guida ↔ bulk di competenze a disposizione
Razionalizz.
Il ruolo
dell’ICT
Architecture
Architettura come
stimolo alle “nuove”
soluzioni
• Ogni realtà ha un suo percorso specifico sul ruolo di
architettura dovuto a “contingenze” e “cultura
manageriale” esistente
Architettura come
gestore delle
coerenze e delle
relazioni
S.I. In forte
evoluzione
• Oltre al ruolo dichiarato è indispensabile definire i
“meccanismi di funzionamento”, in termini di:
 responsabilità decisionali
 meccanismi di ingaggio
 confini con funzioni “vicine” (demand,
organizzazione, strutture di delivery)
• In strutture complesse i diversi ruoli rappresentati in matrice sono “giocati” da più attori all’interno
dell’organizzazione (es. demand management, organizzazione, aree applicative, etc.)
• Non sempre lo stesso ruolo è interpretato su tutti i domini ICT (infrastrutture, applicazioni, etc.)
• In strutture complesse il ruolo giocato dall’ICT Architecture potrebbe essere differente a seconda
dell’ambito funzionale o del dominio tecnologico al quale viene applicato
riservati.
8
Budget ICT
annuale
Comitato
Architettura?
Direzione Sistemi
Informativi
Necessità di
presidio delle
regole
d’ingaggio
Servizio Canali
Servizio Sistemi
Applicativi Core
Servizio Sistemi
Applicativi CRM
Servizio Sistemi
Applicativi Finanza
•
•
•
•
•
•
Servizio
Infrastrutture
Tecnologiche
Servizio Governo
ICT
Servizio
Architetture
•
•
•
Lesson Learned in realtà complesse
• Partecipazione a comitati di budget per governare l’adeguato
finanziamento degli investimenti architetturali
• Partecipazione a comitati di demand per la corretta
interpretazione delle “spinte verticali” e delle esigenze di “breve
periodo”
• Presidio forte di architettura sull’introduzione di nuove
componenti architetturali (applicazioni e tecnologie) al fine di
governare l’evoluzione dei sistemi
• Stimolare la collaborazione e l’accettazione degli architetti da
parte delle aree applicative attraverso meccanismi di “federazione”
Il governo dell’architettura richiede un’attenta definizione dei meccanismi di ingaggio
e di coinvolgimento al fine di garantire l’efficacia dell’azione di indirizzo dell’architettura
riservati.
9
Governo dell’ICT: il presidio del SDLC
I meccanismi di lancio dei progetti
Ciclo di vita
del Software
Inception
Discovery
Elaboration
Mission &
Vision
IT
Strategy
Mission &
Vision
Enterprise
Architecture
• Fattibilità tecniche su progetti di trasformazione
Objectives
Strategic
capabilities
Critical
success
factors
Policies
Org. and Opt.
model
Standard &
guidelines
Service
Delivery
model
Blueprints
Projects
Business needs
To-Be architecture
Manage gap with
standards and guidelines
Business Priorities
Business
Requirements
Project Portfolio
Management
Delivery Planning
Program
prioritization
Small Change
• Selezione di soluzioni abilitanti coerenti con il disegno
complessivo / con le policies
I conflitti da risolvere tra “demand” e “architecture”
• Conciliare la visione di m/l periodo con le esigenze tattiche e il
time-to-market
As-Is architecture
Demand
Management
Maintenance
• Indirizzo e guida della domanda utente
Critical
success
factors
Objectives
Transition
Elementi da presidiare
Meccanismi di lancio dei progetti
Business
Strategy
Construction
• Conciliare la visione verticale (business silos) rispetto al disegno
architetturale
• Colloquio con gli utenti per condividere la direzione nel m/l periodo
• Presidio dell’innovazione
• Architettura dei processi di business
• Modello attivo vs passivo
riservati.
10
I processi di controllo qualità e misurazione del software
Ciclo di vita
del Software
Discovery
Inception
Elaboration
Construction
Transition
Maintenance
Approccio alla Qualità del software
• Regole di ingegneria del software
• Processi e strumenti di qualità del software
• Metriche e KPI per il continuous improvement
• Presidio della comunicazione a diversi livelli della struttura e
verso i partner /outsourcer
• Interfacce d’integrazione
• Politiche e contrattualistica con i fornitori
riservati.
11
I processi di Test e validazione del software
Ciclo di vita
del Software
Discovery
Inception
Elaboration
Construction
Transition
Maintenance
Framework KPMG-NNI per Test e QA
• Definizione di Test strategies e plans
• Management controls e governance
• Presidio e trasformazione negli ambiti People, Process,
Technology e Risk & Controls
• Strumenti
• Approccio risk-based (“testing early and often”)
• Politiche e contrattualistica con i fornitori /outsourcer
riservati.
12
La qualità dei Servizi ICT
Ciclo di vita
del Software
Discovery
Inception
Elaboration
Construction
Transition
Maintenance
Approccio alla Qualità dei Servizi IT
• Definizione Modello di KPI
• Analisi e Realizzazione strumenti a supporto
?
• Benchmarking performance esercizio
CSF_03
CSF_04
CSF_05
O_02
Accuratezza del Budget
CSF_06
CSF_07
CSF_08
O_03
Misurare e dimostrare che l’IT realizza miglioramenti continui
O_06
Misurazione dell'effettiva qualità del servizio IT
(anche al fine di verificare il gap tra qualità
percepita ed erogata)
CSF_12
O_07
Misurazione della efficienza ed efficacia del
Customer Care
Verificare la reale Disponibilità dei servizi IT end-to-end lungo l'intera
catena tecnologica a supporto degli stessi ( dal server su cui il servizio
è pubblicato all'interfaccia di fruizione utente attraverso la rete e tutti
gli altri apparati necessari)
Verificare la reale Performance dei servizi IT end-to-end lungo l'intera
catena tecnologica a supporto degli stessi (dal server su cui il servizio
Verificare la reale Usabilità dei servizi IT end-to-endlungo l'intera
catena tecnologica a supporto degli stessi ( dal server su cui il servizio
Misurare l’efficacia del servizio di HD sia in ottica end-to-end sia per il
solo I/II livello (non specialistico)
Misurare l’efficienza del servizio di HD sia in ottica end-to-end sia per
il solo I/II livello (non specialistico)
di
Meto
sfac
tion
e
RPA
Fina
nce
enti
M
A
M
?
Metriche
A
A
A
A
M
A
A
M
A
A
A
Migliorare Accuratezza e Tempestività del I/II livello di Help Desk
A
A
CSF_20
M
M
A
M
Analizzare ticket connessi a richieste informative inerenti l'utilizzo
delle nuove applicazioni/funzionalità
Rendere maggiormente efficaci la classificazione del ticket e la
conseguente assegnazione al supporto specialistico evitando il
sovraccarico dei livelli specialistici con attività a informative a basso
valore aggiunto
Riduzione dei ticket riaperti a causa di risposte poco pertinenti o non
esaustive a tutti i livelli di assistenza (specialistica e non)
CSF_21
A
A
CSF_18
CSF_22
A
A
A
M
CSF_19
CSF_15
M
M
M
CSF_17
CSF_16
Migliorare i processi di pianificazione e
gestione dei Patrimoni Applicativi
A
Avere a disposizione metriche che permettano di valutare e
monitorare correttamente i consuntivi relativi alla gestione dei
patrimoni rispetto al Budget
Definire un modello di KPI per i Servizi IT oggetto di contratti di
fornitura che consenta di mettere a confronto le diverse forniture sui
diversi patrimoni
O_08
A
Definire un modello di KPI per i Servizi IT oggetto di contratti di
fornitura che consenta di mettere a confronto le diverse forniture sui
diversi patrimoni
Avere a disposizione un set di indicatori che permetta di stimare con
maggiore precisione il costo dei servizi richiesti da ProPa a
Produzione Informatica necessari alla gestione del Patrimonio
Avere a disposizione metriche che permettano una stima accurata
delle necessità di budget per la gestione dei patrimoni
CSF_05
CSF_13
M
Avere a disposizione informazioni puntuali e strutturate sulla crescita
nel tempo della dimensione tecnico-funzionale dei patrimoni (a valle
degli interventi di sviluppo/manutenzione)
CSF_10
CSF_14
Sati
Evolvere verso un modello di cost accounting che tenga conto delle
specifiche techiche e funzionali dei singoli servizi offerti dai Patrimoni
CSF_09
Misurare e dimostrare l’efficienza dell’IT
Standardizzazione dei Contratti di Sourcing
Indicatori Teorici
A
A
Sviluppare un modello di valorizzazione dell’“indice di complessità dei
Patrimoni” che abiliti corretti benchmark di costo tra i diversi Patrimoni
Migliorare il controllo ex-post dei consuntivi
O_04
CSF_11
• Presidiare attraverso strumenti e processi di customer survey la
qualità dei servizi erogati
Utilizzare metriche/tecniche riconosciute dal mercato per la corretta
valorizzazione del costo complessivo di gestione dei Patrimoni
Applicativi (Produzione e Manutenzione Applicativa)
Utilizzare metriche/tecniche best practice sul mercato per il corretto
cost accounting (attribuzione dei costi di erogazione del servizio e di
manutenzione alle singole funzioni di business)
O_05
IT
Descrizione
CSF
IT
CSF_01
IT
CSF_02
Stum
ID_CSF
Trasparenza nelle regole di cost accounting
verso gli utenti finali
IT
Descrizione
Obiettivo
O_01
Cus
tom
er
ID_Obi
ettivo
Cha
nge
Obiettivi e CSF
Garantire l’efficacia dell’AM in termini di pianificazione tra MOA, MOE
e Produzione nei processi di manutenzione evolutiva
Misurare la percentuale di SW rilasciato dal Patrimonio gestita tramite
release
Rendere disponibili misure oggettive a supporto dei SAL di Patrimonio
M
A
A
• Sotware quality review
• Bilanciamento qualità/costi
Cluster Dimensionale Z
• Interazione con outsourcer
Patrimonio Efficiente
Spending contenuto con bassa
concentrazione sulla tecnologia ed elevata
sulla manutenzione Evolutiva
Complessità Tecnico/Organizzativa
• n° di risorse impiegate nell’AM
• n° di interventi di
manutenzione(MEV,MAC)
• n° di piattaforme
• Anzianità delle applicazioni:
• Classe di disponibilità delle applicazioni
Complessità Business
• numero di processi supportati
• numero di utenti per Classe (nominali
e concorrenti)
• consumo CPU
• criticità processo supportato
• tipologia di Utenti (FO,BO,Direzione)
Complessità
Tecnico/Organizzativa
G
MG
M
MP
P
P
MP
M
MG
G
Complessità Business
Economics
Costo totale di Gestione
Patrimonio Critico
Spending considerevole con elevata
concentrazione sulla tecnologia (package
acquistato male, processi di gestione
inefficaci, qualità tecnica del codice
scadente)
Patrimonio Inefficiente
Spending elevato sia in ambito tecnologico
sia in ambito applicativo
Costo ProPA
riservati.
13
Gestione del Rischio Informatico
Il Risk Appetite Framework definisce:
1
Obiettivi di rischio
Individuati ex-ante dal framework stesso,
coerenti con risk capacity, business model e
indirizzi strategici
Soglie di tolleranza
Declinate con evidenza degli interventi
gestionali da adottare al loro raggiungimento
Limiti operativi
Stabiliti sia in condizioni di normale operatività,
sia di stress. Sono definiti in termini di misure
espressive del capitale a rischio o capitale
economico (VaR, expected shortfall, ecc.);
adeguatezza patrimoniale; liquidità
Declinati a seconda di
2
3
4
5
6
Procedure ed
interventi gestionali
Attivabili nel caso in cui sia necessario
ricondurre il livello di rischio entro i limiti
stabiliti
Tempistiche di
aggiornamento RAF
Stabilite in base alla strategia aziendale
Compiti di organi e
funzioni aziendali
Definiti a seconda delle responsabilità in capo a
ciascun organo/funzione
Rischi
quantificabili
Rischi non
quantificabili
Credito /
Controparte
Strategico
Mercato
Reputazionale
Operativo
Compliance
 la declinazione di
propensione al rischio, soglie
di tolleranza, limiti di rischio
deve avvenire attraverso
opportuni parametri
quantitativi
I parametri quantitativi e qualitativi
utilizzati nella definizione del RAF
devono essere coerenti con quelli
utilizzati in sede di pianificazione
patrimoniale (ICAAP) e strategica.
 per i rischi difficilmente
quantificabili e/o per eventuali
statement generali sulle
politiche di rischio che la
banca intende seguire, va
fatto ricorso a indicazioni di
tipo qualitativo in grado di
orientare la definizione e
l’aggiornamento di
processi e sistemi di
controllo
riservati.
14
Gestione del Rischio Informatico
Modello di analisi
Analisi dei risultati
Evento
N.
1
2
3
4
5
6
Severity
10 M€
1
3
Ambito
Perdita annua
attesa
• Sistemi centrali,
dipartimentali,
distribuiti, etc.
Requisiti
informazioni
• Disponibilità,
Integrità,
Riservatezza, etc.
500k€
Categoria
Integrità dei dati
Virus
Intrusioni
Procedure batch
Continuità operativa
Errori interni
4
6
50k€
5
2
Frequenza
• Numero di eventi
all’anno
Azioni
Severity
• Perdita del singolo
evento
Valore/ Classe
• Perdita attesa su
base annua (valore
o classe di valore)
• ICT Governance for Risk/ Control Assurance
2
• Security of Information & Systems
Bassa
Media
Alta
Frequency
• Continuity of ICT
• Project & Change Management
riservati.
15
Conclusioni
Industrializzazione
• Le evoluzioni normative e il contesto di mercato stanno
sollevando una serie di elementi di riflessione sui temi
del Governo dell’ICT e della Gestione dei Rischi
• L’ultimo aggiornamento della Normativa 263/06 di
BankIt fornisce una serie di elementi di pressione per
l’evoluzione verso una maggiore maturità, sia in
termini di efficacia che di industrializzazione, dei
processi ICT
• Si tratta di un percorso graduale e continuo, di cui le
pressioni normative costituiscono solo un aspetto
Efficacia
riservati.
16
Grazie per l’attenzione
Andrea Beretta
Associate Partner
Nolan Norton Italia – Kpmg Advisory
© 2014 KPMG Advisory S.p.A., an Italian limited liability
share capital company and a member firm of the KPMG
network of independent member firms affiliated with
KPMG International Cooperative ("KPMG International"),
a Swiss entity. All rights reserved.
The KPMG name, logo and "cutting through complexity" are
registered trademarks or trademarks of KPMG International
Cooperative ("KPMG International").
Email: [email protected]
Mob: 348 011 32 12

Governo dell`ICT - The Innovation Group

Transcript

Documenti analoghi

Stage Data Scientist

Stage IT Forensic

FORUM BANCASSICURAZIONE 2016_Pasquale Ambrosio.pptx

Banca, l`online fa il pieno

Competitive Alternatives, 2006 - Competitive Alternatives 2016

delle imprese

PREMIO DI LAUREA: “MIRM Master in Insurance and Risk

L`Enterprise Risk Management in Italia

Forensic Services Rischi, opportunità e risposte ai conflitti Advisory