Les sociétés de gestion et les compagnies d’assurance font face à une double complexification de l’environnement réglementaire et de l’architecture de marché. Les flux d’information sont décuplés et rendent nécessaire la mise en place de solutions informatiques intégrées qui permettent d’optimiser la gestion des flux opérationnels entre les services de gestion et le back office.
L’objectif final est de minimiser le risque opérationnel, de garantir la transparence des informations, de réduire les coûts de gestion et les délais de production (clôture comptable, reporting réglementaire et contractuel).
La mise en place de ces solutions intégrées touche une grande partie de la chaîne de production d’une compagnie d’assurance (ou d’une mutuelle). Direction financière, direction des investissements et directions des systèmes d’information en sont les principaux acteurs. Sont également impliqués, en tant qu’utilisateurs des informations, la direction technique, la gestion actif/passif, la direction des risques et la trésorerie.
Comment garantir une bonne coordination entre les différentes directions impliquées ? Comment fédérer les collaborateurs autour d’un projet contraignant en termes de flexibilité et de relation au travail ? Quels sont les critères de sélection de la solution informatique et quelle est l’architecture optimale compte tenu des objectifs finaux ?Autant de questions auxquelles les consultants SeaBird apportent des réponses concrètes, tirées de leur expérience auprès des acteurs de l’assurance, de la mutualité ou de la protection sociale.
Règle N°1 : Définir les priorités de la migration selon la méthode MSCW
La réussite de la migration des données nécessite une planification détaillée. Il faut définir les principes structurants de la migration (calendrier, budget, contraintes métiers, techniques et réglementaires) et délimiter son périmètre pour enfin fixer la stratégie globale.
La migration représente une excellente opportunité d’auditer et de fiabiliser les données tout en intégrant les dernières normes de data quality. Un travail préalable d’analyse permet de définir les priorités mais aussi les exigences en termes de données.
Pour réaliser ce travail de priorisation, nous privilégions la méthode MSCW :
M (Must have this) :
données impératives à la migration « Vital »,
S (Should have this if at all possible) :
données importantes mais non urgentes « essentiel »,
C (Could have this if it does not affect anything else) :
données valides pour ajout mais sans impact « confort »,
W (Won’t have this time but would like in the future) :
données intéressantes à migrer mais qu’on n’utilisera pas « luxe ».
L’utilisation de ce modèle est idéale dans le cas d’un pilotage par les délais : il permet à la migration de s’appuyer sur les niveaux de contrainte successifs tout en réduisant le périmètre fonctionnel. Les efforts de travail se trouvent ainsi réduits sur des données inutiles, sans valeur démontrée à ce stade pour le projet de migration.
Dans tout projet, le bon fonctionnement de l’outil SI est corrélé à la qualité des données entrantes qui sont stockées dans des référentiels. La qualité du référentiel est liée à la fiabilité des données sources, à la fréquence de mise à jour et à la facilité de requête. Il est primordial de créer une « équipe référentiel » transversale qui prend en compte les impacts et les besoins de tous les intervenants. Dans la pratique, la direction des investissements prend le lead sur le référentiel en raison des compétences métier ; mais il est très dangereux de négliger la direction financière parce que le paramétrage des écritures comptables est lié aux données d’un référentiel unique en front-to-back.
Les référentiels peuvent être regroupés en trois types, selon la nature des données :
- le référentiel valeurs contient tous les titres et les contrats négociables qui composent les portefeuilles d’investissement ;
- le référentiel tiers contient les données toutes les contreparties (broker, dépositaires, sociétés intra groupe, etc) ;
- le référentiel produits regroupe les caractéristiques des différents fonds et portefeuilles d’investissement (divers fonds euros, euro-croissance, unités de comptes, etc).
La définition du périmètre de migration passe par la cartographie des sources de données des différents référentiels et de reprise des positions historiques. La migration des actifs traditionnels (obligations, actions, OPCVM) peut être automatisée au maximum pour la recette et pour la phase de production (après fiabilisation du référentiel). A noter : la reprise des positions historiques doit se faire en lignes FIFO par contraintes réglementaires, à l’exception de short-cuts sur certains actifs, tels que les fonds alternatifs et le private equity. Par ailleurs, dans le cadre de IFRS9, il sera nécessaire de garder un historique des provisions et de certaines données du référentiel (rating par exemple) pour le calcul de l’ECL.
Point de vigilance : certaines données peuvent se trouver dans des applicatifs non urbanisés. C’est notamment le cas de certains actifs non traditionnels (immobilier, prêt, emprunt, fonds private equity) qui peuvent être suivis dans des fichiers excel. Il est alors nécessaire de créer des liens avec ces référentiels de données. Cela peut passer par la création d’une task force pour automatiser et fiabiliser ces données non urbanisées.
Enfin, il est souhaitable de migrer sur les stocks d’ouverture de début d’année pour éviter une reprise coûteuse des transactions et les anomalies liées aux différences de méthodes entre les outils (calcul des amortissements surcote/décote par exemple). De plus, il est indispensable que la stratégie de migration intègre une période de parallèle run afin de fiabiliser le référentiel et de réconcilier les données dans les deux systèmes (source vs cible).
Règle N° 2 : Optimiser le degré d’intégration
La définition de l’architecture optimale dépend du niveau d’intégration de la solution choisie. L’offre standard sur le marché ne répond pas forcément aux spécificités organisationnelles et aux particularités des portefeuilles de tous les assureurs. Cependant, il s’avère inutile et très coûteux de vouloir intégrer toutes les fonctions existantes avant d’aller en go-live ; l’objectif doit être l’intégration du maximum de fonctions possibles et la garantie d’une adéquation entre les différents systèmes de l’architecture.
Le choix de la solution devra prendre en compte le business modèle, la taille des actifs sous gestion et l’importance des actifs non traditionnels dans le portefeuille. Les critères de sélection doivent aussi intégrer la flexibilité de l’outil par rapport aux évolutions réglementaires et comptables, ainsi que sa capacité de gestion des produits complexes (immobilier, dérivés, OST, private equity, dettes privées) et de matérialisation du contrôle interne.
Premièrement, tout ce qui est complexe ne fonctionnera pas directement sans anomalie dans un outil intégré. C’est notamment le cas de la comptabilisation des dérivés, la gestion et la comptabilisation des OST complexes, la gestion de l’immobilier, des dettes privées, des fonds alternatifs, des appels de marges et des collatéraux. Certaines fonctions nécessiteront des ajustements en phase de production. Il faudra suivre les anomalies en gestion et les corriger par OD pour la comptabilité.
Concernant les reporting réglementaires et contractuels qui sont inclus dans les offres de solution front-to-back, il faut favoriser la livraison des reportings en production, parce que c’est un chantier qui arrive au bout de la chaîne. Il faudra en particulier automatiser des corrections palliatives en dehors de l’outil front-to-back et continuer le développement des reportings en phase de production, notamment les QRT de Solvabilité II.
Deuxièmement, le développement de l’outil front-to-back se fait dans une architecture globale et non pas en autarcie. Cette architecture globale regroupe notamment les outils de gestion des ordres UC (non intégrée dans la solution front-to-back), la gestion des flux de trésorerie, les flux dépositaires, les suites comptables (comptabilité des assurances, consolidation) et le dataware.
Il est ainsi primordial de penser à l’imbrication de ces différents outils avec pour objectif final, l’automatisation du maximum de flux et de contrôles. L’architecture optimale doit donc intégrer des STP (Straight-through processing) internes et externes qui facilitent l’automatisation et l’interfaçage des applications (en temps réel ou par batch quotidien).
Règle N°3 : Une organisation par chantier
L’organisation en « stream value » (par chantier) est, selon nous, indispensable. C’est un concept emprunté au lean management des usines dans l’industrie. Il décrit une séquence d’activité qu’une organisation entreprend de mettre en œuvre pour répondre à des besoins définis (produit final), tout en optimisant les coûts, le temps et la satisfaction des utilisateurs. Chaque stream représente une chaîne de valeur et les différents streams sont à la fois interconnectés et indépendants.
L’avantage d’une telle organisation est que chaque référent est responsable de son sujet et est capable d’en suivre l’avancement. Il y a donc un seul interlocuteur pour chaque sujet. Cette organisation permet de ne pas travailler en silo, les responsables de chaque stream échangent régulièrement lors de réunions hebdomadaires. La communication est fluide. Le risque principal est d’avoir des streams trop chargés : il faut donc veiller à bien répartir la charge de travail en fonction des sujets et que tous les chantiers « vivent » tout au long du projet.
Le découpage du projet peut s’effectuer de différentes manières :
- en streams « fonctionnels » (par phase/maille de donnée)
- en streams par niveau d’intervention/macro-process
Nous conseillons une organisation hybride, combinant des streams fonctionnels (par exemple le stream migration, qui est une étape primordiale d’un projet de migration Front-to-back avec derrière une réelle stratégie de migration à adopter) et des streams découpés par niveau d’intervention (par exemple un stream lié à la comptabilité -avec les schémas comptables et les dérivations-, la modélisation des instruments financiers…). Le découpage dans le temps est également indispensable : certains streams vivront tout au long du projet quand d’autres ne seront activés qu’à un certain moment. Pour gagner du temps, il ne faut pas hésiter à ne pas faire démarrer tous les streams en même temps.
Un projet de cette envergure évolue au fil du temps, l’organisation doit pouvoir s’adapter. La charge devra être revue au fur et à mesure. Fonctionner de manière Agile sera la clé afin de s’adapter plus facilement aux aléas. Cette méthode particulièrement flexible, elle repose sur l’idée que planifier la totalité d’un projet dans les moindres détails avant de le développer est contre-productif. Elle prône 4 valeurs :
- L’équipe (des individus et des interactions plutôt que des processus et des outils) ;
- L’application (des fonctionnalités opérationnelles plutôt que de la documentation exhaustive) ;
- La collaboration avec le client plutôt que la contractualisation des relations ;
- L’acceptation du changement plutôt que le suivi d’un plan.
Une organisation adéquate préserve les ressources et permet de veiller à la correcte répartition des tâches. Des outils de suivi permettent d’organiser les différents streams, de planifier chaque tâche du projet, d’allouer les ressources humaines et budgétaires, d’assurer le suivi au quotidien en un clic et de restituer des états de synthèse macro pour le comité de pilotage. Un panel de logiciels est disponible : Microsoft Project (MSP), JIRA, Nqi Orchestra, Scoro.
Focus outils de suivi
JIRA est un outil qui est de plus en plus utilisé grâce à son rapport qualité/prix. C’est un outil de suivi des problèmes (tickets), qui peut être étendu à un outil de suivi des defects, à un centre d’assistance et à un outil de gestion de projet avec de nombreuses fonctionnalités pour les équipes agiles. Les modules peuvent être adaptés aux besoins du projet : Jira Core, Jira Software et Jira Service Desk. Avantages : facilité d’utilisation, interfaces différenciées (mobiles en déplacement par exemple), facilité d’intégration dans divers systèmes (peu de problème de compatibilité), workflow simple et suivi complet des anomalies et des bugs.
Zoom : 5 moyens efficaces pour fédérer les intervenants
Dans un projet de ce type, il est indispensable que n’émerge pas de rivalité entre les différents acteurs. Impliquer tous les intervenants dès le début du projet permet de fédérer de toutes les forces autour d’un objectif commun. De la même manière, si certains acteurs peuvent avoir des réticences face au changement d’outil, il sera judicieux de les embarquer dès le début dans le choix de la solution informatique. Quels en sont les vecteurs ?
- une gouvernance transversale et partagée incluant un comité de pilotage qui regroupe DSI, équipes Investissement et Direction Finance
- une communication auprès des équipes pour expliquer les décisions stratégiques et identifier les points bloquants
- une implication concrète des équipes opérationnelles, par exemple dans la rédaction des expressions de besoins
- des événements informels, par exemple des petits déjeuners, qui fédèrent les équipes, permettent de mettre à niveau les informations de chacun, dans un cadre informel où il est plus facile de s’exprimer et de désamorcer les tensions
- des back-fillings rigoureusement choisis (autonomie, fiabilité) pour assurer le relai sur la production et permettre aux équipes internes/métiers de participer pleinement au projet.
