Yphise optimise en Coût Valeur Risque l informatique d entreprise

Transcription

1 Gérer le risque opérationnel ORM - Operational Risk Management Juin 2008 Xavier Flez yphise@yphise.com Propriété Yphise GM Gouvernance PR Projets IS Systèmes d Information SO Service Management 1

2 Le risque opérationnel Le risque opérationnel est le risque porté par les opérations de l entreprise Une part du risque opérationnel est relative au système d information Une part de ce risque concerne la production Processus métier (ex logistique) Opération métier (ex appro) Système d information 2

3 Gérer le risque opérationnel Gérer le risque opérationnel est une démarche préventive Il s agit d identifier et surveiller l évolution dans la durée des risques en Probabilité et Gravité De donner une compréhension aux décideurs de ces risques avec, en face, des propositions concrètes de réduction adaptées aux enjeux De savoir réduire le risque à chaque étape de la conduite opérationnelle de l activité considérée 3

4 Le risque opérationnel pour l entreprise et la Production (1/2) Le risque est la perturbation des opérations par l incapacité à tenir les engagements de service utiles ou à reprendre dans des conditions acceptables Les possibilités de points faibles, c est-à-dire les vulnérabilités, ont considérablement augmenté avec la distribution et le fil de l eau des SI La SOA va encore accroitre fortement les possibilités de points faibles et, en conséquence, la complexité d industrialisation (le Service Design ITIL) des SI 4

5 Le risque opérationnel pour l entreprise et la Production (2/2) Savons nous gérer ce risque opérationnel? Savons nous agir lors des projets et maintenances de manière à supprimer ou réduire au maximum les risques en production? Connaissons nous les risques résiduels, qui sont inévitables, ou y a-t-il des zones d ombre sur «ce qui se passerait si...»? Savons nous en apprécier la gravité pour l entreprise, la probabilité et l évolution dans le temps? Savons nous en donner une compréhension aux décideurs pour que se prennent les décisions d organisation, de méthode ou d investissement? 5

6 Ce que dit ISO La finalité du Service Management est de garantir le fonctionnement d une production selon les engagements de service utiles sur les opérations métier La norme insiste sur une boucle réflexion, action, mesure à partir des enjeux des métiers de l entreprise sur leurs opérations Un Service Management efficace selon ISO sait intrinsèquement gérer le risque opérationnel lié à la production 6

7 Ce qu apporte ITIL v3 Nous avons vu précédemment que gérer le risque est fondamentalement une démarche préventive ITIL v3 a sensiblement développé, renforcé et clarifié le volet préventif en distinguant le Service Transition et le Service Design (qui est aussi le moins avancé dans les DSI) et en développant le Continual Service Improvement Comme ISO , ITIL v3 a pris l orientation nécessaire pour que la gestion du risque opérationnel entre correctement dans le Service Management 7

8 Voyons concrètement comment avancer 1. Il faut savoir parler risque aux décideurs de sorte à ce que les décisions soient mises à plat et prises ; ceci amène le Service Catalog qui est un fondement d ITIL v3 et d ISO Il faut savoir réduire le risque et, si possible le supprimer, ce qui revient concrètement et pour l essentiel à savoir faire du Service Design efficace 8

9 Parler risque aux décideurs : lier l IT aux opérations métier (1/3) Fondamental : l expérience montre que l obtention de moyens de réduction de risques nécessite de toujours faire le lien avec les conséquences sur les opérations métier Ceci est vrai qu il s agisse de grands ou petits moyens de la création d un centre de secours à l obtention d une configuration haute disponibilité de l investissement dans une solution de BAM à la création de quelques alertes préventives dans un monitoring de production de l organisation de la mission d industrialisation à la réalisation de quelques tests de charge dans les projets etc. 9

10 Parler risque aux décideurs : lier l IT aux opérations métier (2/3) C est la raison de fond pour laquelle ISO et ITIL v3 insistent sur le catalogue de services : toujours savoir basculer d une perspective technique à ce qui intéresse les métiers à savoir leurs opérations C est la raison de fond qui fait que la perspective qui va orienter tous les efforts d amélioration de l organisation, des moyens et méthodes des DSI sur les 10 ans à venir est «l approche service» de la nouvelle génération du Service Management Processus métier (ex logistique) Opération métier (ex appro) Catalogue de services Service Métier Disponibilité Coût... Service Service CMDB SI 10

11 Parler risque aux décideurs : lier l IT aux opérations métier (3/3) Ceci d autant plus que le risque opérationnel lié aux SI en production doit, et devra de plus en plus, intégrer le risque sur différents prestataires ou partenaires La référence sur le catalogue de services est ITIL v3 Processus métier (ex logistique) Opération métier (ex appro) SI distribué Interne SI partenaire CMDB CMDB SI distribué = flux de services ou applications (synchrones ou asynchrones) sur différentes bases 11

12 Parler risque aux décideurs : la carte des risques (1/3) On vit forcément avec des risques. La situation idéale d une suppression totale du risque n existe pas L enjeu est donc que les décideurs aient une vue d ensemble en permanence de sorte à pouvoir réfléchir et prendre de bonnes décisions en temps utile Nous recommandons pour cela de constituer une carte des risques 12

13 Parler risque aux décideurs : la carte des risques (2/3) La carte des risques fait partie de la réflexion d alignement des SI, c est-àdire d architecture des SI La réflexion d alignement identifie où il faut investir sur le SI ; on parle souvent de zone d urbanisme Chaque zone d urbanisme est positionnée en criticité et profondeur pour l entreprise PROFONDEUR Programme Projet ZU kk ll ZU gg hh ii jj ZU dd ee ff ZU aa Exigence ZU bb cc Non critique Coûts non optimisés Fragilité métier Bloquant métier CRITICITE 13

14 Parler risque aux décideurs : la carte des risques (3/3) 1. La carte des risques est mise à jour sur chaque projet, selon les risques résiduels en fin d industrialisation 2. La carte évolue hors projet sur la base d une part des problèmes et d autre part des demandes nouvelles issues des métiers 3. Sur la base de cette carte peuvent être prises les décisions de projets ou d exigences sur des projets Gouvernance Comité de direction ou Project management office Projet Hors projet Industrialisation Problèmes Comité de pilotage Portefeuille Projets 14

15 Un Service Design efficace : réussir l industrialisation (1/2) Le risque opérationnel lié aux SI en production se supprime ou se réduit par le Service Design ITIL v3, c est-à-dire le processus d industrialisation Réussir les différentes disciplines du Service Design nécessite une analyse /conception /réalisation /test sur chaque projet applicatif ou technique Pilotage du projet Fonctionnel - SLM - Availability - Capacity - Security - IT SCM Technique = Industrialisation Analyse Conception Réalisation Test 15

16 Un Service Design efficace : réussir l industrialisation (2/2) L industrialisation mène une analyse systématique des risques sur chaque discipline du Service Design afin de trouver les moyens de suppression ou de réduction adaptés Cette réflexion en terme de risque nécessite une certaine expérience. On a donc intérêt à essayer de la limiter... Analyser le risque pour le supprimer ou le réduire Menace sur une Vulnérabilité qui entraîne une Supprimer une vulnérabilité Réduire la probabilité d une menace ou, réduire la gravité d une conséquence Conséquence 16

17 Un Service Design efficace : la check-list d industrialisation (1/2)... en définissant une bonne fois pour toutes les pratiques ou contrôles systématiques pour supprimer les vulnérabilités usuelles De la sorte, on limite le besoin d analyse spécifique du risque aux situations particulières, nouvelles ou difficiles Nous recommandons fortement l établissement d une telle check-list d industrialisation. En voici un exemple opérationnel... 17

18 Un Service Design efficace : la check-list d industrialisation (2/2) Fonctionnement Contrôle Les traitements sont stables et intègres Les temps de réponse sont conformes au niveau de service attendu Robustesse L exploitation est capable d arrêter, suspendre et reprendre les traitements et les flux sans perte d intégrité L exploitation de l application s intègre dans l exploitation du SI au niveau des business process et du plan de production Le taux de panne prévu est conforme au niveau de service attendu En cas de panne, le service repart selon le niveau de service En cas d échec de traitement ou de flux, le service ou l interface repart selon le niveau de service En cas d erreur humaine, le service repart selon le niveau de service Les actions d exploitation sont automatisées conformément aux standards de travail de l exploitation L exploitation peut agir à distance L exploitation peut agir avec ses rôles et ses droits. Les droits sont conformes aux exigences de sécurité En cas de corruption de données, le service repart selon le niveau de service Les performances (disponibilité et temps de réponse) sont conformes au niveau de service Visibilité Evolutivité Les patchs et upgrades sont applicables sans remise en cause du niveau de service L architecture et les procédures d exploitation sont documentées de manière accessible à l exploitation L état des éléments d infrastructure est connu et remonté à l exploitation L état et l avancement des traitements et des flux sont connus et remontés à l exploitation Les accès, les traitements et les erreurs sont loggés pour analyse. Les logs sont accessibles et conservés le temps nécessaire Les standards de solutions techniques sont respectés L architecture est extensible pour s adapter aux évolutions de charge L architecture est flexible pour s adapter aux évolutions des éléments techniques et des applications connexes Les incidents sont détectés et remontent des alarmes aux personnes appropriées, selon une criticité adaptées 18

19 En résumé, la solution pour réussir l ORM dans un cadre ITIL v3 Nous venons de faire de l ITIL v3 avec intelligence, c est-à-dire mis en oeuvre et complété de manière à ce que cela fonctionne bien dans une DSI Le fondement est de développer le catalogue de services à partir des opérations de l entreprise de sorte à toujours faire le lien entre IT et métier. ITIL insiste avec raison Il faut avoir en permanence une vue d ensemble, pertinente pour un décideur. La carte du risque telle que présentée n est pas dans ITIL Supprimer ou réduire le risque se fait en traitant les disciplines du Service Design lors de chaque projet applicatif ou technique. ITIL est clair Compte tenu de la relative difficulté d une réflexion en terme de risque, on a intérêt à définir les pratiques ou contrôles systématiques de suppression de vulnérabilités. La check-list d industrialisation n est pas dans ITIL 19

20 Merci Xavier Flez GM Gouvernance PR Projets IS Systèmes d Information SO Service Management 20