PROCESSUS ET RISQUES : deux approches complémentaires (2ème partie)

 Deux démarches fortement imbriquées

On note de nombreux points communs entre COSO2 et la mise en œuvre d’un référentiel processus et les premières étapes d’une démarche projet seraient dans les deux cas identiques :

– comprendre et cartographier le ou les métiers de base de l’entreprise,
– les décomposer macro-processus métier ou support,
– puis en processus métier et processus support,
– obtenir la validation des organes de direction sur la pertinence de la représentation du tableau ainsi obtenu par rapport à leur connaissance de leur entreprise et de sa stratégie.

Sur cette base, un projet référentiel processus va poursuivre la décomposition « top down » jusqu’à parvenir à un niveau de détail par entité organisationnelle permettant d’éditer les procédures en vigueur, mais aussi de lister les applications informatiques touchées, les postes de travail concernés, tâche par tâche, éventuellement les compétences ou les systèmes de pilotage mis en oeuvre.

Comment intégrer les risques au référentiel

Un projet risques va devoir introduire une dimension ou une vue risques dans ce tableau et structurer les différentes caractéristiques des risques pour pouvoir les gérer (nature, probabilité, évaluation..). La collecte des incidents selon Bâle 2 ou toute autre forme de recensement permettra de positionner chaque risque à un niveau adéquat, qui n’est généralement pas le niveau de granularité le plus fin d’une analyse référentiel processus.

Comparé à un projet de référentiel d’entreprise au périmètre maximal intégrant l’ensemble des prismes d’analyse des processus et du S.I., le travail d’analyse, pour un projet strictement orienté « risques », apparaît considérablement allégé.

Tout d’abord, avec une démarche et des étapes intermédiaires très largement communes, et en dehors d’une course aux échéances de première mise en œuvre SOA ou Bâle 2, il serait vraiment dommageable pour une entreprise – notamment s’ils coexistent déjà- de ne pas lier ces deux projets dans la même base de donnée – référentiel.

On notera qu’insérer un projet risque au sein d’un projet référentiel processus offre une garantie de revue exhaustive de l’organisation et des processus sur le périmètre choisi.

Mais au-delà, les textes réglementaires n’ont pas vocation à produire de belles cartographies de risques mais bien à les maîtriser ou mieux, à les supprimer.

Les apports de l’intégration de la vue Risques

Positionner un risque en haut de la pyramide des processus qui le génère (dans le cadre d’un projet processus), permet d’avoir immédiatement à disposition l’ensemble des procédures, acteurs, et systèmes concernés -autrement dit l’environnement de contrôle-. C’est tout de même la matière première, dans toute sa diversité, des changements nécessaires à la gestion du risque, qu’il s’agisse d’automatisation de tâches ou de contrôles, de formation ou de modifications de procédures.

La base de données référentiel apparaît aussi comme un outil indispensable pour « l’entité indépendante » responsable de la gestion des risques opérationnels, des procédures et des contrôles de « l’approche avancée » de Bâle 2.

On ajoutera que positionner un contrôle dans un contexte qui permet d’identifier les ressources qu’il consomme permet d’en réévaluer rapidement le coût, et le cas échéant la pertinence, s’il n’est plus en rapport avec les bénéfices qui en sont attendus.

Cependant, insérer un projet risques dans un projet référentiel processus, si cela ne retire rien aux bénéfices précédemment décrits, ne suffit pas. L’obligation de documenter les contrôles nécessite plusieurs étapes supplémentaires :
– sélectionner des contrôles à effectuer au sein des systèmes opérationnels,
– les adresser à chacun des contrôleurs,
– suivre les contrôles et en conserver l’historique,
– générer documentation des rapports.

Toutes choses qui nécessitent de s’appuyer sur des outils complémentaires à la base de données référentiel (parfois proposés par les mêmes éditeurs), et des interfaces avec systèmes opérationnels en amont.

Tirer profit des contraintes réglementaires

En conclusion, plus les législateurs se sont adressés à des structures puissantes (cotées SEC) et homogènes (établissements financiers) plus ils ont pu être exigeants sur la définition d’un cadre d’analyse des risques poussant les entreprises à s’auto évaluer, pour aligner stratégie et profil de risques acceptés.

Nous aurions tendance à être encore plus ambitieux et à proposer d’utiliser les outils de modélisation de processus désormais matures pour appliquer la stratégie de façon cohérente non seulement avec la politique de risques, mais simultanément avec l’organisation des processus et avec toute autre dimension de ressource suivie dans la base de données.

Pour les dirigeants des entités qui ne sont pas concernées par SOA et Bâle 2, et donc avec moins de contraintes formelles sur les contrôles, mener un projet référentiel processus en intégrant la dimension risques peut s’avérer une façon extrêmement stimulante de rechercher une meilleure maîtrise de l’avenir de son entreprise, tout en recherchant pas à pas une utilisation plus rationnelle des ressources de l’organisation.

  Lire la première partie de l’article

  Auteur : Laurent Hassid

PROCESSUS ET RISQUES : deux approches complémentaires (2ème partie)