---

Accenture accompagne actuellement plusieurs acteurs français et internationaux de l’industrie de l’assurance dans leurs programmes de transformation IFRS 17. L’introduction de la norme implique de nouveaux besoins nécessitant la mise en place de solutions informatiques. Mais quelles solutions ? D’un côté, plusieurs éditeurs proposent des applications pré-packagées devant répondre aux exigences règlementaires. De l’autre, la plupart des assureurs ont développé des compétences en interne leur permettant de pouvoir envisager un « développement maison ». La question est donc posée : « Make » or « Buy » ? Nous vous proposons de partager ici notre point de vue sur les éléments à considérer pour prendre cette décision dans le contexte IFRS17

Episode #5 – « Make or Buy » : acquérir ou développer en interne une solution IFRS17. Comment prendre la bonne décision ? 

La question d’acheter un produit ou de le développer soi-même en interne ne se pose pas que dans un contexte informatique. A chaque investissement -où la solution « buy » existe- la question peut être posée. La littérature sur le sujet est d’ailleurs très vaste et les éléments de décision sont assez clairs :  

• La stratégie : est-ce un élément différenciateur ? La solution donnera-t-elle un avantage compétitif à l’entreprise ?  Ne mieux vaut-il pas garder ou développer l’expertise en interne ?  

• Le risque : Est-ce critique pour les opérations ? L’entreprise a-t-elle la capacité à faire (dans les délais) ? En cas d’externalisation, comment gérer la dépendance vis-à-vis du fournisseur ? Et puis d’ailleurs, la solution du fournisseur est-elle fiable ? Répond-elle vraiment aux besoins de l’entreprise aujourd’hui ? Et demain ? 
• Les coûts d’achat et de maintenance : le « total cost of ownership » (TCO), ou « coût global de possession ». Seul facteur purement quantitatif, mais qui reste difficile à évaluer dans le contexte de solutions adressant des enjeux règlementaires encore incertains et mouvants, et s’appuyant sur des technologies (qu’ils s’agissent du make comme du buy) qui n’offrent pas encore un historique de déploiement permettant un niveau de certitude des estimations élevé. 

Il appartient à chaque organisation de faire ce choix en fonction de l’évaluation des différents critères -dans son contexte-.  

Il est néanmoins possible de préciser quelques éléments dans le cas d’IFRS17 quant à la solution de CSM / reporting règlementaire. 

Nous vous proposons ici quelques pistes qu’il peut être intéressant d’explorer pour contextualiser les critères de décision : 

1. « Jeter un coup d’œil dans le rétroviseur » : quels choix ont été faits pour répondre aux besoins Solvency II ? Donnent-ils satisfaction ? 

Il existe des similarités entre les traitements requis par IFRS17 et Solvency II. Ne serait-il donc pas judicieux d’analyser les possibilités de réutilisation des solutions déjà mises en œuvre pour la norme prudentielle. 

Dans le cas d’acteurs ayant par exemple investi dans une solution in house répondant aux besoins Solvency II, une extension de la solution pourrait alors permettre de faire levier sur cet investissement en répondant – avec un coût marginal limité – aux besoins IFRS17. A voir néanmoins si la solution est réellement évolutive et si elle serait en mesure de produire les données dans les délais de production IFRS, beaucoup plus serrés que ceux de la norme prudentielle… 

Cette même logique peut aussi s’appliquer aux éditeurs. Pour les acteurs ayant déjà acheté une solution Solvency II, il peut ainsi s’avérer intéressant de se rapprocher de son éditeur pour échanger avec lui sur l’extension de sa solution aux besoins IFRS17.

2.  « L’intégration : le nerf de la guerre » : regarder le paysage applicatif existant, les applications clé et les flux de données de bout en bout  

Il est souvent plus facile d’intégrer des outils appartenant à la suite d’un même éditeur : des connecteurs natifs existent dans la plupart des cas, les modèles de données correspondent et permettent de s’affranchir de couches d’intégration pénibles à mettre en œuvre et à maintenir. 

Dans le cas d’architectures possédant déjà plusieurs outils d’un même éditeur, la piste du buy peut donc s’avérer judicieuse d’un point de vue de l’intégration. Reste néanmoins à valider avec les équipes que les solutions existantes apportent satisfaction, que la relation commerciale avec l’éditeur est au beau fixe et surtout que la solution proposée est mature et offre le niveau de flexibilité attendue.  

Une autre solution permettant de limiter l’effort d’intégration peut aussi être d’enrichir un outil in house existant – et donc déjà intégré dans l’écosystème – au lieu d’ajouter une N+1ème brique applicative à laquelle les utilisateurs devront se connecter.  

3.  « Regarder loin » : Et demain ? Comment les différentes options make or buy s’inscriraient-elles dans la feuille de route finance et risque de l’entreprise ? 

Au moment de faire le choix d’un tel investissement, il convient de s’interroger sur la feuille de route à moyen et long termes afin de s’assurer de la cohérence de l’architecture cible en regard des objectifs de l’entreprise et de la stratégie définie. 

En effet, dans un contexte où l’exploitation des données est devenue critique, il faudra non seulement se poser la question de la réponse aux besoins à court terme de mise en conformité avec la norme mais également – et surtout ? – de la stratégie à long terme vis-à-vis des enjeux d’outillage de la direction financière, notamment dans l’optique de lui permettre de participer plus activement à l’analyse de la stratégie de développement de l’entreprise, et d’une plus grande création de valeur via une grande maîtrise et une meilleure utilisation des donnés. 

Se pose alors la question du niveau d’ambition de l’investissement : la réponse à un agenda réglementaire pouvant alors se transformer en projet stratégique (misant sur les nouvelles technologies telles que le big data ou l’analytics) apportant un avantage concurrentiel. Et dans ce cas, le développement en interne peut prendre tout son sens en comparaison à un partenariat avec un éditeur dont l’agenda n’est pas forcément celui de l’entreprise.