5.1. Intégrer une infrastructure de support dans
la banque
5.1.1. Définir l'architecture SI
Une difficulté majeure, lors de l'implémentation
d'une stratégie globale de gestion du risque opérationnel, est
d'intégrer ses différentes composantes dans un ensemble
cohérent. Il y a très peu d'applications disponibles sur le
marché qui fournissent tous ces éléments sous la forme
d'un package intégré. Il est donc essentiel de commencer par
définir une architecture qui facilite l'intégration de toutes ces
composantes. Si les aspects techniques de cette intégration sont
déterminants, il va sans dire qu'il est tout aussi important de
s'assurer que la logique d'activité de la banque entre ces
différents éléments est préservée. En
d'autres termes, il est nécessaire de déterminer comment ces
composantes devront interagir. À titre d'exemple, le system workflow de
la banque peut contenir des informations très utiles sur
l'efficacité des processus et l'application de méthodes ou
décisions. Cette information peut être utilisée à la
fois comme un indicateur de risque (par exemple, le nombre de processus non
achevés à temps par un individu ou une ligne d'activité)
ou comme une donnée explicative (par exemple, quelle était la
cause de cette défaillance ?).
Les indicateurs de risque jouent un rôle très
important à la fois au niveau de l'interprétation et de la
prévention du risque opérationnel. Ils proviennent de diverses
sources (par exemple, ressources humaines, systèmes de front-office,
etc.) au sein de la banque, et sont étalonnés sur une
période de temps déterminée en fonction de
mécanismes de déclenchement pré
spécifiés.
Le volume considérable de données en jeu et les
difficultés techniques liées à la gestion du risque
opérationnel exigent d'actionner une infrastructure de support dans la
banque. L'objectif est de faire apparaître les principaux domaines
fonctionnels que l'infrastructure de soutien doit nécessairement
intégrer pour être vraiment efficace. Outre les aspects
traditionnels de data warehousing, de reporting, et de monitoring qui sont
à considérer, le rôle de la plateforme d'intégration
(middleware) est essentiel car les données nécessaires à
la gestion du risque opérationnel proviennent souvent de sources
multiples, à la fois internes et externes. Les
spécificités de l'architecture IT de chaque institution
financière doivent bien entendu orienter les caractéristiques
futures de cette plateforme d'intégration. Cela étant, le
triptyque recueil/contrôle/surveillance des données
d'événements de perte sur l'ensemble des lignes d'activité
reste essentiel. Sur ce point, la responsabilisation des acteurs
concernés revêt une importance particulière. Les banques
s'appuient, en effet, sur une infrastructure technologique de plus en plus
sophistiquée et complexe. Elles s'exposent donc à des risques
opérationnels endogènes liés à la conception de
cette infrastructure et à son degré d'efficacité.
Il faut également prévoir un processus
d'automatisation des flux/transferts de données dans l'infrastructure de
support. Dans ce but, il est nécessaire de codifier et
d'institutionnaliser ces flux et transferts au sein d'un système
d'information, que le risk manager pourra mobiliser dans le cadre de la prise
de décision. Un tel système d'information doit être capable
de produire un état des anomalies et défaillances. Il ne fait
aucun doute que les institutions financières seront de plus en plus
incitées à divulguer, au-delà des obligations
légales, des informations concernant leurs pratiques de gestion du
risque opérationnel. L'importance des processus de flux/transferts de
données ne doit donc pas être sous-estimée.
| 
