A travers l’initiative Solvabilité II, le régulateur manifeste son intention de normaliser la manière dont les compagnies d’assurance doivent mesurer leurs risques, gérer leur portefeuille en conséquence et reporter leurs résultats en la matière à l’autorité de contrôle.
Un tel changement va conduire les entreprises à réorganiser leurs processus de pilotage: certaines tirées par une dynamique interne et désireuses d’obtenir des différentiateurs de marché, d’autres tirées principalement par les contraintes réglementaires. Quel que soit le point de vue adopté, il va entrainer des transformations métier majeures et, pour certaines entreprises, une recombinaison via fusions/acquisitions afin d’optimiser leurs portefeuilles.
Heureusement, la plupart des acteurs ont lancé des programmes de transformation et, comme le précise l’enquête de Deloitte de 2011, plus de 52% des companies britanniques en étaient à la phase de mise en œuvre en 2011 avec 75% chez les plus grandes. Par ailleurs le même rapport indique que les budgets devraient être compris entre 1,2 m et 12m d’euros, les montants plus élevés étant le fait des très grandes organisations.
Mais, si les comités exécutifs semblent être conscients des nouvelles responsabilités et opportunités, les projets et programmes ont encore beaucoup d’incertitudes et de questions:
- sur les méthodes de calcul du capital qui doivent encore être affinées et, pour certaines complètement spécifiées
- sur les données qui doivent être collectées, traitées, vérifiées et validées pour chaque méthode de calcul
- sur l’organisation qui doit définir les responsabilités pour chaque sous-processus et définir comment ils entendent les assurer
- sur le management qui doit préparer les collaborateurs et demander les investissements pour les ressources
Au final, les transformations subissent deux forces opposées: les dépendances entre les différents aspects de Solvabilité II et les forces de la fragmentation engendrées par la démarche de projet adoptée pour faire face à la complexité : d’ordre technique (actuaire, informatique, affaires, …) et sociale (acteurs, la gouvernance, l’influence, … ). La fragmentation technique provient de la nécessité d’adopter, même partiellement, une approche analytique. La fragmentation sociale vient du climat relationnel, de la culture business et de la compétition interne.
Tout ceci crée un réseau de questions à plusieurs facettes dont certaines sont tricotées avec les unes avec les autres. Par exemple, dès que les programmes commencent à envisager les données, ils doivent rapidement répondre aux questions posées par les modèles de risques et les processus métier. Doivent-ils affiner les modèles de risques qu’ils doivent aussi instruire la stratégie, le management des risques et la qualité des données. Il résulte qu’une incertitude à propos d’un aspect du sujet devient une incertitude pour tous les autres aspects.
Ainsi les programmes Solvabilité II ne sont pas en mesure de définir une cible précise, mais juste une vision de scénarios associés à des règles et des directions. Ils créent des feuilles de route composées d’étapes qui tendent vers un ou plusieurs scénarios. Plus les étapes sont partagées par les feuilles de route, plus les programmes ont des options devant eux et sont flexibles. Évidemment, ces plans comprennent les activités IT, les développements de plates-formes et les déploiements sinon les transformations pourraient avoir à faire face à une fragmentation sociale encore plus forte qui pourrait sérieusement entraver leur réussite.
Le démarrage d’une dynamique de changement Solvabilité II ne se révèle donc pas une chose aisée.
Les transformations touchent:
- les services financiers qui doivent réduire drastiquement le délai de production de la balance et, pour cela, remodeler leurs processus,
- les départements d’actuariat qui doivent changer radicalement leur mode de travail,
- les dirigeants d’entreprises qui doivent réviser leurs processus de décision pour prendre en compte le coût du risque
- les top managers qui doivent revoir le système de gestion des performances et mieux récompenser une meilleure gestion des risques.
Comment ne pas impliquer tous ces acteurs dans la spécification et la gestion de la transformation s’ils doivent s’entendre sur les gains rapides au démarrage des feuilles de route et sur les objectifs finaux à atteindre ? Pour faire face à l’incertitude, les programmes doivent mettre en place une structure de management solide, capable de décider tout au long de l’exécution des feuilles de route. En effet, les meilleures approches de transformations sont agiles et pilotées par les risques.
Les transformations doivent envisager 2 types de risques:
- L’instabilité des exigences due à une publication tardive des directives réglementaires et à la difficulté de trouver une solution efficace pour produire le reporting Solvency II dans le temps requis, 14 semaines.
- Les difficultés d’intégration dues à des pratiques et des processus existants fondés sur des outils d’utilisateur ni spécifiés, ni standardisés et très peu intégrés à cause de nombreuses procédures manuelles
Si les technologies de l’information n’étaient pas apparues critiques au démarrage, elles deviendront rapidement un sujet, car la plupart des risques proviennent du traitement des données et des calculs associés qui se font souvent dans des feuilles de calculs Excel ou avec d’autres solutions d’utilisateur comme SAS PC ou d’autres SGBD sous Windows. Ces solutions qui permettent de corriger rapidement les données d’entrée et les règles de calcul sont apparues extrêmement flexibles.
Mais elles augmentent les risques d’erreurs, les risques d’intégrité et de confidentialité des données. Elles ont ralenti l’intégration car tous les échanges d’informations se font manuellement et sont spécifiques à chaque acteur. Changer cela est difficile car la flexibilité s’avère souvent un avantage métier inestimable.
Pourtant, les activités de préparation, de collecte, de vérification des données, de calcul des provisions, de réconciliation avec les données comptables, d’analyse vont être totalement remaniées par Solvabilité II car la méthode des flux futurs de trésorerie actualisés nécessite des données au grain le plus fin et car les règles Solvabilité II exigent un haut niveau de qualité et une auditabilité complète des données. Le reporting Solvabilité II peut être comparé à une cascade de données qui contient non seulement des données opérationnelles détaillées, mais aussi des données d’organisation, de coût, des données financières et de perspectives économiques.
Dans ce contexte, toute démarche de datawarehouse entrainerait un grand nombre de spécifications d’objets métier stables ou devrait s’appuyer sur une technologie d’interface capable de soutenir de fréquentes évolutions.
À ce stade, il semble que certains programmes Solvabilité II ont fait une erreur en se précipitant sur la modélisation afin d’être en mesure de fournir rapidement des indications sur les tendances de charge en capital. Il aurait été préférable de gérer tous les aspects en même temps et d’aspirer à une progression équilibrée.
Certains éditeurs ont développé des solutions qui peuvent aider à faire face aux problèmes dus aux tableur Excel:
- CIMCON Software (XLAudit and XLRisk)
- Prodiance (Spreadsheet IQ)
- ClusterSeven (Enterprise Spreadsheet Manager)
- Finsbury Solutions (EUC Enterprise)
- ComplyXL from Lyquidity.com
Les transformations Solvabilité II ont le choix entre trois types d’organisation:
- une organisation centralisée qui prépare des plans pour tous les acteurs et gère leur exécution. Elles pourraient bientôt buter sur des questions de conception puisque personne ne maîtrise au démarrage de la transformation, la méthode de calcul de flux futurs de trésorerie actualisés, par exemple. Et lorsque les transformations suivent leur cours, elles peuvent être rapidement désalignées avec les attentes des acteurs et générer des risques importants.
- une organisation décentralisée qui soutient les acteurs pour la préparation des plans et la gestion de l’exécution. elles pourraient bientôt faire face à des questions d’intégration, à une fragmentation des points de vue et à des objectifs divergents. Dans ce contexte, la décision de mettre en œuvre une plate-forme partagée peut arriver en retard, entraver l’efficacité du reporting et générer des risques de délai et de qualité.
- une organisation mixte qui dessine un cadre de conception commun dans laquelle chaque partie prenante doit développer ses propres étapes de la feuille de route. Ce cadre permet de garder la cohérence de tous les points de vue et crée une autonomisation des acteurs qui sont alors capables de trouver des optimisations locales et de réduire la résistance au changement.
Il est difficile d’identifier le périmètre détaillé de la transformation lorsqu’on doit normaliser les processus et les données dans un contexte où les acteurs aspirent d’abord à partager des plates-formes de traitement. Cette décision peut s’avérer délicate car prise trop à l’avance, elle peut conduire à un désalignement, surtout quand les éditeurs et les entreprises n’ont pas en leur possession toutes les exigences réglementaires. Si elle est prise trop tard, elle peut causer l’inefficacités des processus. Pour ces raisons, certaines entreprises ont décidé de commencer avec des prototypes.
Ce document montre que les questions métier et les questions de technologies de l’information sont étroitement imbriqués dans les transformations Solvabilité II. Elles doivent être gérées de conserve pour éviter toute fragmentation nuisible. Les métiers contribuent à diriger le programme et, dans le même temps, doivent être soutenus pour définir leur nouveau rôle.
Pour réussir, il faut créer ou accroître l’empathie entre métiers et informaticiens : ils doivent travailler main dans la main pour concevoir les feuilles de route et prendre les bonnes décisions en temps opportun. Tout cela fait pencher la balance vers l’adoption d’une organisation de programme de type mixte.
Enfin, les programmes de transformation trouveront un appui favorable et déterminant dans la démarche d’architecture d’entreprise car elle donne les bases pour construire le cadre de conception partagé par les acteurs, IT et non IT, et toutes les conditions qui leur permettront d’être efficaces.