WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


Home | Publier un mémoire | Une page au hasard

 > 

Le risque opérationnel au sein des Banques:Quelle stratégie pour une meilleure maitrise?

( Télécharger le fichier original )
par sénoussi EPAYE
ESG Business School Paris - ESGF 2009
  

précédent sommaire suivant

Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy

5.2.3.1. La qualité du tableau de bord

Pertinence des indicateurs : typologie de libellés d'incidents. Les indicateurs ne doivent pas apparaitre comme un moyen habile de noyer les dysfonctionnements dans la masse d'informations. L'utilisateur doit retrouver son propre constat vécu au quotidien dans les chiffres et les graphiques fournis. L'idéal est que les applications incorporent dès leur conception la fourniture de leurs propres indicateurs qui alimentent les tableaux de bord.

Définition : chaque information doit être définie sans ambigüité. II faut un consensus sur l'interprétation des données. L'efficacité du tableau de bord dépend en grande partie de son adaptation au besoin de celui qui le reçoit et a sa compréhension des problèmes. Des outils comme la cartographie des processus et les schémas d'architecture fonctionnel et techniques permettent a tous de se comprendre et de pouvoir analyser un incident ;

Fiabilité : précisions, degré de certitude et du suivi des évolutions anormales. Il faut éviter de signaler plusieurs fois la même chose sur des noms différents ;

Fraicheur de l'information et fréquence : dimension temporelle, évolution visible dans le temps, alerte par anticipation des conséquences différées mais inéluctable d'un incident qui viens de se produire ;

Ergonomie : qualité de la présentation de graphiques, tableaux ; lisibilité, compréhension immédiate des évolutions, comparaison possible par rapport à des normes acceptées. Possibilité de descendre /remonter entre les niveaux de détails et la synthèse.

5.2.3.2. Critique de l'existant

1. Prolifération des tableaux de bord, redondances et difficulté à s'y retrouver face à une question précise. Difficulté à cibler la communication en fonction de l'interlocuteur.

2. Faiblesse des tableaux de bord de contrôle de gestion interne (risques de gestion, qualité et productivité des développements, surveillance de la sous-traitance).

3. Le risque informatique opérationnel n'est pas intégré. Par exemple il est difficile d'avoir une idée sur le niveau global de risques de la sécurité du dispositif opérationnel. Les informations sur les incidents ne constituent pas un échantillon représentatif de la qualité perçue par l'utilisateur.

4. Libellés des incidents peu explicites, typologie des causes très faible, évaluation des impacts à la louche, aucune échelle de gravité hormis la dichotomie grave : manque de maitrise sur la prévision des conséquences différées et multiples d'un incident (cascades de relations causes impacts) ;

5. Focalisation sur les incidents graves, mais peu sur les dysfonctionnements chroniques et les incidents récurrents.

6. Peu d'audit sur les incidents graves ;

7. Peu de sanctions réelles sur le non respect des clauses de qualité de service : suivi de la rapidité et l'organisation du dispositif de résolution des incidents, efficacité des mesures correctives et préventives après l'intervention à chaud.

8. Aucune analyse des récurrences et des réapparitions d'anomalies ; il manque un bureau de suivi de la qualité en prise directe sur l'exploitation, effectuant les interprétations des indicateurs et doté d'outils d'analyse statistiques et de reporting. Aucune étude sur les chaines de causes, la fréquence et la répartition des incidents sur une échelle de gravité. Peu de mesures préventives résultant de la détection de l'émergence probable d'une détérioration.

9. Faiblesse de la communication externe : peu de feed back sur la perception réelle de l'incident par les utilisateurs. L'incident est surtout vu de l'exploitation, sans prise en compte des effets secondaires perçus et de la gène globale occasionnée chez les utilisateurs.

10. Il faut aussi s'intéresser aux dégradations qui n'entrainent pas directement un incident, mais perturbent le bon fonctionnement des services utilisateurs (dégradations du temps de réponse, déni de service, mauvais fonctionnement des imprimantes).

11. C'est seulement pour les incidents graves qu'il existe une relation directe entre la qualification de l'incident et le franchissement d'un indicateur défini par le contrat de service. Le suivi de la réalisation des contrats de service passés avec les utilisateurs doit aussi être effectué même quant il y a pas d'incident.

12. Les enquêtes de satisfaction et de benchmarking doivent pouvoir être rapprochés des indicateurs du tableau de bord.

précédent sommaire suivant






Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy








"Aux âmes bien nées, la valeur n'attend point le nombre des années"   Corneille