Quel Modèle d Entreprise pour l Assurance de demain? Préambule Partageant leur constat sur la difficulté des acteurs de l assurance à évoluer rapidement, Stéphane Arbus et Jean-René Lyon ont confronté leur vision respective en tant qu experts du secteur de l assurance et des systèmes d information. Ce document représente donc leur réflexion sur les évolutions du secteur de l assurance et la nécessité de simplifier les systèmes d information pour y faire face. A propos de Jean-René Lyon Ingénieur Ecole Centrale Paris et MS Stanford, Jean-René Lyon n a exercé qu un métier : simplifier les systèmes d information complexes. D abord en tant que Consultant, puis comme DSI du Crédit du Nord et du Groupe Axa, et enfin comme Entrepreneur en créant Lyon-Consultants, puis Wyde qui est l éditeur international de la Solution Assurance «Wynsure». Par ailleurs il a créé le CEISAR au sein de l Ecole Centrale pour formaliser et enseigner l Architecture d Entreprise. A propos de Stéphane Arbus Ingénieur des Mines, Stéphane Arbus accompagne depuis de nombreuses années les transformations des acteurs du monde de l assurance. Il a occupé des fonctions au sein de sociétés de services informatiques, consultant chez Lyon-Consultants et Directeur Assurance chez CGI France, et a également travaillé au sein du Groupe CRI (actuellement Aprionis) dans des fonctions de pilotage de grands projets métier. Il a créé depuis 2005 un cabinet de conseil en organisation et management, EVEHO conseil, dédié au secteur de l assurance. 1 Les challenges de l assurance
Les assureurs veulent évoluer beaucoup plus vite qu ils ne l ont fait dans le passé: approche client, produits mixtes, évolution vers les services, transfert des taches vers les clients, différents réseaux de distribution, optimisation des processus, synergies internationales, utilisation des nouveaux medias, Mais leur Modèle d assurance, constitué d une multitude de Solutions disparates qui se sont progressivement ajoutées est devenu trop complexe pour permettre cette évolution. Mieux gérer les échanges entre les différentes Solutions ne suffit pas, il est nécessaire de réduire le nombre de Solutions. Mais comment faire alors qu il existe autant de différences entre IARD et Vie, Individuel et Collectives, gestion de contrats et gestion de sinistres? Il faut rechercher ce qui est commun dans les produits d assurance, les processus de souscription ou de gestion de sinistres, les informations partagées sur les clients, les interfaces utilisateurs, les fonctions de sécurité ou de production de documents puis les Modéliser dans une Fondation puissante commune à toutes les lignes métier. Cette Fondation a pour vertu non seulement de simplifier l ensemble du Modèle et donc d accélérer les développements, mais aussi d offrir un usage cohérent qui autorise toutes les formes d organisation. Pour y parvenir, il faut convaincre la Direction Générale, qui est seule dépositaire du Bien Commun que représente la Fondation, pour obtenir des moyens et son appui dans la durée. Il faut adapter la gouvernance, les équipes, faire le bon choix de Fondation et trouver une trajectoire progressive. Il faut aussi que les Editeurs de Logiciels acceptent de mettre à disposition des Fondations que les assureurs n ont plus le temps de bâtir. Les assureurs qui gagneront à terme ne sont pas forcément ceux qui ont les meilleures idées, mais ceux qui ont la capacité à mettre en place rapidement les bonnes idées des autres parce qu ils sont devenus agiles. Ce document est une tentative pour expliquer les enjeux essentiels et donner des pistes aux dirigeants des compagnies d assurance et de tous ceux qui sont concernés par ce débat : la stratégie, le marketing, l organisation, ou l informatique. L exercice est difficile parce que les aspects organisation et surtout informatiques sont souvent ignorés de ces dirigeants : ils ont rarement eu l occasion d acquérir une culture informatique, et les informaticiens n ont pas toujours fait preuve de la meilleure pédagogie. Nous espérons néanmoins aider à éclairer ce débat complexe en évitant autant que possible d utiliser le jargon informatique. 1859 Charles Darwin et la révolution industrielle «Ce n est pas l espèce la plus forte ou la plus intelligente qui survit. C est celle qui sait le mieux s adapter au changement». PS : par souci de rigueur, nous avons réutilisé le langage du CEISAR (www.ceisar.org) dont quelques définitions sont données en annexe telles que «Modèle», «Modèle d Entreprise», «Opération», «Transformation», «Solution», «Fondation». On a conservé dans le texte une majuscule pour chacun de ces termes, afin de les reconnaitre plus aisément. 2 Les challenges de l assurance
1 Les challenges de l assurance 4 1.1 Les challenges concernant les Produits 4 1.2 Les challenges concernant les Opérations 6 1.3 Les challenges concernant la Transformation 7 2 Les Solutions actuelles ne permettent pas d évoluer rapidement 8 2.1 Trop de solutions différentes 8 2.2 La multiplicité de solutions disparates est incompatible avec l agilité attendue 10 2.3 Les délais et les coûts engendrent une culture de l échec 11 2.4 Peut-on faire mieux? 11 3 Commencer par Modéliser le métier de l assurance avant de se doter d une Solution. 12 3.1 Interopérabilité et Solutions transverses 12 3.2 Est-il possible de réduire le nombre de Solutions dans un monde aussi diversifié que l assurance, 14 3.3 Y a-t-il des invariants dans les différents Produits de l assurance? 17 3.4 Y a-t-il des invariants dans les différentes Opérations de l assurance? 19 3.5 Y a t il des invariants dans les différents projets de Transformation? 22 4 Quel Modèle global cible? 23 4.1 Modèle actuel d une Compagnie d assurance 23 4.2 Système cible d une Compagnie d assurance 24 4.3 Quels scenarios pour une Compagnie indépendante? 27 4.4 Quels scenarios pour un Groupe de Compagnies? 30 4.5 En quoi le «Cloud» change-t-il les règles du jeu? 33 4.6 Quelle Valeur? 33 5 Comment y parvenir? 35 5.1 Est ce le bon moment pour un «bond en avant»? 35 5.2 Quelle ambition? 35 5.3 Qui doit fournir la Fondation et la Solution cible? 35 5.4 Quels critères de choix pour une Fondation? 36 5.5 Quelle gouvernance? 36 5.6 Se réapproprier la modélisation du métier 37 5.7 Quelles Solutions doivent utiliser la Fondation? 38 5.8 Comment choisir une Solution externe? 39 5.9 Progressivité 39 5.10 Quelles ressources humaines et comment les organiser? 40 5.11 Comment initier la démarche? 41 6 Annexe : le Modèle d Entreprise et quelques termes associés 43 7 Questions/Réponses 46 3 Les challenges de l assurance
1 Les challenges de l assurance Le potentiel de croissance du secteur de l assurance n est plus à démontrer, surtout à l échelle mondiale où des millions d individus des pays émergents souhaitent s ouvrir à l assurance et accéder aux produits auto, habitation, santé, prévoyance... Malgré cette croissance, l avenir est loin d être tout tracé pour les acteurs de l assurance et de la protection sociale qui subissent de nombreux changements. L émergence de nouveaux concurrents (qu il s agisse de banques, d enseignes de distribution, de compagnies d assurance 100% internet très compétitives, de compagnies étrangères ), la multiplicité des canaux de distribution (Internet, mobile, concept-stores ), la mondialisation de l offre font que les assureurs traditionnels vont devoir se transformer, et cela bien au-delà de l optimisation des processus existants. Paradoxalement, les assureurs ont peu évolué ces dernières années: ils sont restés en situation défensive, ils n ont pas investi de nouveaux métiers ; par contre, ils se sont fait concurrencer sur leur propre terrain par de nouveaux entrants. La banque-assurance est un succès, alors que l assur-banque ne l est pas. 1.1 Les challenges concernant les Produits 1.1.1 D une approche cloisonnée par branche vers une approche globale des besoins client Jusqu à présent structurée par branche (Automobile, Santé, Retraite ), l offre des assureurs va s orienter vers des produits «multi-branches» couvrant l ensemble des besoins pour un segment donné de clients (par exemple une offre unique d assurance «Senior» couvrant la Santé, la Dépendance, la Retraite, l automobile et l habitation). Cette approche par les besoins et non plus par branche a les conséquences majeures suivantes : La disparition des acteurs indépendants positionnés sur une seule branche de produits ou leur marginalisation sur des marchés de niche (ex : mutuelle Santé professionnelle) ; Le décloisonnement des activités des différentes branches (exemple : capacité à gérer simultanément et pour un même client des prestations dommages et des prestations Santé). Ce décloisonnement des offres devrait également s opérer au niveau de la couverture géographique. Certains produits devraient en effet être commercialisés au niveau international. 1.1.2 Le développement du sur-mesure et une plus grande segmentation A l image de la génération Y, les consommateurs souhaitent disposer de plus en plus de produits qui correspondent exactement à leurs propres besoins. Ces nouvelles habitudes de consommation impliquent de proposer des produits ayant un niveau très fin de choix et de particularisation. L approche «packagée» va donc être concurrencée par une approche basée sur les besoins. L assureur devra proposer un ensemble de services correspondant à un budget global ou à un usage donné. Les premières initiatives relatives à cette nouvelle approche ont vu le jour avec notamment le «pay-as-youdrive» en Automobile: le client définit lui-même son budget d assurance en jouant sur le nombre de kilomètres parcourus annuellement. Ce développement du sur-mesure implique un changement important dans la structure de l offre et dans les modèles de tarification. Les offres seront moins monolithiques et beaucoup plus segmentées. Demain, c est le client qui choisira le niveau de ses prestations en fonction de ses propres besoins, construisant ainsi son propre produit. L approche de vente s appuie alors sur une étape de description formalisée des besoins. A partir de ces besoins, l assureur formulera des propositions «sur-mesure» aussi bien en termes de services proposés que de tarifs. Déjà initiée en assurance-vie par une obligation réglementaire, cette dimension «conseil» et analyse des besoins sera demain généralisée à toutes les branches. 4 Les challenges de l assurance
Tout ceci participe à la multiplication des offres de produits, et à la complexification du Modèle. En effet, autant on sait créer de nouveaux produits, autant on a du mal à réduire le catalogue produit. 1.1.3 La menace de devenir un simple sous-traitant De nombreux acteurs (banques, distributeurs ) proposent aujourd hui des produits d assurance en complément de leur offre de services. C est le cas des opérateurs de téléphonie, des fournisseurs de crédits, des tour-operators et il est fort probable que cette tendance se développe à l avenir (les distributeurs d électricité ont par exemple la légitimité et le portefeuille de clients pour intégrer dans leurs offres une assurance habitation). Cette situation présente le risque de positionner les assureurs dans un rôle exclusif de «producteurs» auprès d acteurs maîtrisant mieux la «distribution» Cette menace renforce d autant la nécessité de «sortir» du cadre exclusif de l assurance et de proposer une approche plus large basée sur la fourniture de services. 1.1.4 De l indemnisation à la fourniture d un service Le développement des services a déjà débuté dans le domaine de l assurance automobile et habitation avec les prestations en nature lors de la survenance du sinistre (par exemple l envoi et la prise en charge financière de réparateurs suite à un dégât des eaux). Ces services sont proposés actuellement au moment du sinistre et évolueront progressivement en une offre globale indépendante. 1. Exemples de services liés au sinistre La fourniture d hébergements dans des établissements spécialisés pour la dépendance ; Des prestations Santé dans le domaine dentaire ou optique par exemple ; Télémédecine 2. Exemples de services indépendants du sinistre Télésurveillance ; Services de diagnostic (amiante, métrage ) lors de la vente d un bien immobilier Ce positionnement de fournisseur global de services permettra également aux assureurs de multiplier les contacts et donc de disposer d une meilleure connaissance de leurs clients. Aujourd hui, un client en assurance habitation qui ne subit pas de sinistres a très peu de contacts avec son assureur. L intégration des services nécessitant un réseau physique de prestataires (entretien, centres médicaux ) impose aux assureurs de nouer des partenariats avec des enseignes spécialisées. Pour certains services, l utilisation des nouvelles technologies permettra aux assureurs d en être les fournisseurs directs (télémédecine ou optique en ligne). 5 Les challenges de l assurance
1.2 Les challenges concernant les Opérations 1.2.1 De nouveaux canaux de distribution et de communication Alors qu il permet l apparition de nouveaux acteurs dans le monde de l assurance et représente donc une menace, Internet et les nouvelles technologies présentent également de nombreuses opportunités. L utilisation d Internet permet aux assureurs de réduire leur coût en déportant auprès des clients et partenaires la majorité des actes de gestion. En termes de distribution, Internet représente également un moyen simple et rapide de développer des partenariats. La mise à disposition de services de vente en ligne intégrables sur des portails facilite la distribution des produits par des tiers. Sur un plan de l offre et comme nous l avons vu précédemment, Internet est également un formidable vecteur de développement de nouveaux services, en complément de l assurance. 1.2.2 Des centres de services industriels et mutualisés De nombreux secteurs de l assurance sont dans une situation de forte concurrence tarifaire. C est le cas de l automobile et de la santé qui sont des marchés saturés en termes d équipement. C est aussi le cas du marché de l assurance vie pour lequel les frais sur les versements ont fortement diminué grâce à Internet. Cette pression sur les prix impose aux assureurs de réduire leurs coûts de gestion et d améliorer la qualité de services par la mise en place de centres industriels de gestion. Ces centres s appuient sur : Une organisation industrielle des opérations (approche processus et qualité) ; Une mutualisation accrue entre plusieurs branches et pays. Jusqu à présent, les assureurs sont majoritairement organisés par branche (auto, santé, vie, prévoyance) et les opérations de gestion sont également structurées en domaines de gestion (gestion des contrats d une part, gestion des sinistres/prestations d autre part). Ce cloisonnement fort des activités de gestion ne favorise pas la polyvalence et la qualité de services au client tout en limitant la productivité. Le développement des produits «multi-branches» évoqué ci-dessus imposera la mise en place de centres de gestion polyvalents. Demain, un même acteur de gestion devra être capable de gérer aussi bien un contrat auto qu une prestation prévoyance. La mise en place de ces centres industriels de gestion nécessitera des outils de gestion identiques (SI et processus communs pour toutes les branches). 1.2.3 Le développement du BPO «Business Process Outsourcing» Compte tenu de frais de gestion souvent élevés, une offre d outsourcing s est développée pour gérer les «runoffs» (les contrats toujours actifs alors que l on ne commercialise plus le produit correspondant) ou les gros portefeuilles de produits standards. Ces entreprises sont aujourd hui des partenaires, mais peuvent devenir un jour des concurrents parce qu ils sauront Opérer avec efficacité. Les processus de gestion sont de plus en plus éclatés sur des acteurs multiples (internes ou externes) dont on ne maîtrise pas forcément le Modèle. 6 Les challenges de l assurance
1.3 Les challenges concernant la Transformation 1.3.1 Etre rapide pour faire face à ces nombreux changements Compte tenu de l accélération constatée des changements, les acteurs gagnants de demain seront donc ceux qui seront les plus rapides dans la mise en œuvre de ces multiples évolutions. Il est par exemple surprenant de constater que la fréquence de mise à jour des tarifs techniques est restée annuelle chez la majorité des assureurs et que très peu d acteurs arrivent à lancer une nouvelle offre en moins de 18 mois. La réduction du time-to-market passe notamment par l amélioration des méthodes de transformation mais surtout par la capacité du système d information à s adapter et à supporter ces changements. Les multiples fusions et rapprochements qui ont eu lieu dans le secteur de l assurance ne sont souvent toujours pas finalisés au bout de plusieurs années : Les offres ne sont pas complètement fusionnées ; Les anciens SI peuvent perdurer plusieurs années. Le maintien de cette complexité en termes d offres et d outils rend toute transformation plus lourde et plus complexe à gérer. Le secteur de l assurance va encore vivre de nombreux rapprochements dans les années à venir (plus de 800 opérateurs sont encore présents sur le marché français de l assurance Santé) et les acteurs qui réussiront seront ceux qui auront la capacité à les mener rapidement au niveau des offres et de l organisation. Enfin et indépendamment de ces rapprochements, l organisation des opérations est amenée à évoluer souvent sous la pression du marché. Ces changements d organisation peuvent être liés à des lancements de nouveaux services ou à des besoins d amélioration de la qualité et du coût de la gestion. 1.3.2 Des compétences pluridisciplinaires «pointues» Les Transformations du Modèle Produit et du Modèle d Opération ne concernent pas seulement un département ou une branche mais impliquent l ensemble de l entreprise. Les équipes en charge de ces transformations doivent donc disposer des compétences suivantes: Connaissance du métier de l assurance pour bien apprécier les enjeux et priorités métier ; Connaissance des SI du fait de leur forte implication dans les offres de services ; Maitrise de la gestion de projets pour être capable de mener à bien ces transformations ; Maitrise de la gestion du changement pour déployer un nouveau Modèle auprès des équipes Opérationnelles. 7 Les challenges de l assurance
2 Les Solutions actuelles ne permettent pas d évoluer rapidement 2.1 Trop de solutions différentes Aujourd hui la majorité des Compagnies d assurance doivent opérer avec beaucoup trop de Solutions. Cette complexité les empêche d évoluer pour faire face aux challenges déjà cités. 2.1.1 La multiplication des produits génère de nouvelles Solutions Comme indiqué ci-dessus, les assureurs ont multiplié les produits pour des raisons marketing ou pour faire suite aux changements réglementaires, ce qui est une première raison de la multiplicité des Solutions et de la complexité du Modèle des assureurs. 2.1.2 Autant de Solutions que d unités organisationnelles Les assureurs sont organisés selon des dimensions différentes: par pays, par type de clientèle, par ligne de produit, par domaine de processus, par canal de distribution, Comme chaque entité organisationnelle est jugée sur ses résultats et son efficacité, elle est donc naturellement conduite à rechercher la Solution qui optimise son domaine. Une organisation par pays génère des Solutions différentes par pays. Une organisation par type de clientèle génère des Solutions différentes pour les particuliers et les entreprises. Une organisation par ligne produit génère des Solutions différentes pour la vie et l iard, ou pour l individuelle et les collectives. Une organisation par famille de processus génère des Solutions différentes pour la conception de produit, le CRM, la souscription, la gestion de sinistres, la gestion des distributeurs, Une organisation par canal de distribution génère des Solution différentes pour la «distribution par agents» et la «distribution directe». Quand les dimensions se combinent, on multiplie les Solutions. A titre d exemple, si une compagnie est organisée par pays, puis, au sein de chaque pays, par ligne métier, puis au sein de chaque ligne métier en séparant les domaines de processus tels que gestion des contrats et gestion des sinistres, on aboutit à autant de Solutions qu il existe de combinaisons «pays * ligne Métier * domaine de processus». Si l organisation évolue et que l on souhaite, par exemple, s organiser mondialement par ligne métier, la compagnie se retrouve avec un problème difficile sur les bras : comment faire converger tous les pays vers une solution commune alors que l organisation précédente a conduit à les isoler? Et que se passe-t-il si on décide de changer à nouveau l organisation 3 ans après? 2.1.3 Le développement des formes de distribution participe à la complexité croissante Un assureur fait aujourd hui appel à un nombre croissant de distributeurs. Le distributeur peut utiliser le Modèle de l assureur : de multiples distributeurs utilisent aujourd hui des Solutions internet proposées par l assureur. Mais le distributeur peut aussi conserver son Modèle pour vendre les Produits de l assureur. C est le cas par exemple des courtiers qui doivent utiliser leur propre Modèle pour offrir des produits de différents assureurs, ou des bancassureurs qui doivent utiliser le Modèle du réseau bancaire pour respecter le mode d usage des employés de la banque. Dans ces deux cas, il faut soit que l on duplique fonctions et données dans les solutions-distributeur et solutions-assureur soit que la Solution-distributeur puisse accéder à des services-logiciel assurances («calculer tarif», «controler éligibilité», «recueillir les souscriptions», ) mis à disposition par l assureur. 8 Les Solutions actuelles ne permettent pas d évoluer rapidement
2.1.4 Le développement du BPO participe à la complexité croissante Un assureur fait appel à un sous-traitant pour Opérer une partie de ses processus soit parce que les ressources du sous-traitant sont plus productives, soit parce que le Modèle du sous-traitant est plus efficace, soit pour les deux raisons. Dans le premier cas, le sous-traitant utilise le Modèle fourni par l assureur et le fait Opérer par ses équipes qui sont plus productives : la situation n est pas vraiment plus complexe qu auparavant. La seule difficulté est de déployer le Modèle chez le sous-traitant : former, installer les matériels, initialiser les paramètres Dans le deuxième cas, la complexité s accroit puisqu un nouveau Modèle est introduit, celui du sous-traitant, avec lequel il va falloir coexister. 2.1.5 Les fusions-acquisitions génèrent encore plus de solutions La concentration du secteur de l assurance accentue ce phénomène : certaines fusions sont mal digérées. On fusionne bien l équipe de direction, les réseaux et les back offices, l image mais on laisse en place les Solutions de chacun parce que la fusion Opérationnelle et la reprise des clients, des contrats, et des sinistres dans un système unique est une affaire difficile : chaque fusion laisse une strate de Solutions supplémentaire. 2.1.6 Des Solutions transversales complémentaires Les Solutions qui gèrent le cœur du métier, c'est-à-dire les contrats et les sinistres sont souvent appelées «Solutions verticales» parce qu elles sont spécialisées par ligne métier. Mais il existe aussi des «Solutions transversales» qui ne sont pas dépendantes des lignes produits telles que les Solutions de «gestion du client», de «comptabilité générale», de «pilotage», «d éditique», de «gestion des ressources humaines», Il est souhaitable que les assureurs ne choisissent qu une seule Solution pour chacun de ces domaines transversaux. Tant que les liens entre ces Solutions Transversales et les Solutions Verticales sont peu nombreux et que le nombre d utilisateurs concernés est faible, ces Solutions donnent satisfaction. Dans le cas contraire, la complexité du Système s accroit. Un exemple bien connu est celui du CRM, le fameux «Customer Relationship Management». Les Modèles traditionnels de l assurance ont été conçus pour gérer des contrats et non des clients. Le CRM a pour objectif d intégrer une approche client. La Solution CRM Transversale était destinée à offrir une vision globale du client puisque chaque Solution Verticale ne pouvait en donner qu une vision partielle. Elle s est par la suite élargie à : offrir au client une Solution Internet homogène qui lui permet d interagir avec les différentes Solutions verticales en place puisque chacune ne peut offrir qu une fraction de cette interaction avec une ergonomie bien spécifique ; gérer les contacts successifs avec le client ; gérer les campagnes commerciales ; faire des devis et des propositions ; gérer les centres d appel ; gérer les nouveaux médias utilisés par les clients (iphone, ipad). 9 Les Solutions actuelles ne permettent pas d évoluer rapidement
Le CRM s est finalement positionné en Solution pour gérer tous les processus commerciaux et non plus en Solution pour gérer uniquement les informations client ou l interface ergonomique offerte au client. Mais une Solution CRM dissociée des autres Solutions génère de la complexité : synchronisation des mises à jour de différents fichiers de clients ou de contrats dont on ne sait plus qui est maitre fonctions redéveloppées : comme la tarification ou les contrôles d éligibilité dont les mises à jour doivent être synchronisées mode d usage original qui isole les commerciaux des administratifs alors qu il y a continuité entre les contacts clients, les propositions, la souscription, les avenants jusqu à la terminaison du contrat : tous utilisent les personnes, les contacts, les produits, la tarification, les contrats Au final, les atouts des Solutions CRM ont été bridés par la difficulté de coexistence avec les Solutions en place. 2.2 La multiplicité de solutions disparates est incompatible avec l agilité attendue Lorsque l on doit insérer une évolution dans un patchwork de Solutions, tout devient compliqué : chacun doit comprendre la structure globale pour identifier les impacts de chaque modification sur les autres Solutions. On dépense trop d énergie à faire de la «plomberie» et non du «métier». Les Projets deviennent lents et coûteux, que ce soit pour créer ou modifier des produits ou des processus. En outre : Chaque Solution impose son usage spécifique ce qui génère des coûts de formation élevés, une productivité plus faible et conduit à spécialiser les acteurs par Solution. On a du mal à automatiser des processus de bout en bout puisque chaque activité du processus s appuie sur une Solution indépendante : pour prendre un exemple simple en assurance-vie, en cas de décès, il faut délivrer des prestations gérées par la Solution «Sinistre», mais aussi mettre à jour 10 Les Solutions actuelles ne permettent pas d évoluer rapidement
le Contrat qui est géré par la Solution «Contrat», et les informations clients gérées par la Solution «CRM». On duplique les informations. On doit synchroniser des mises à jour de Solutions construites par des équipes différentes. On doit exploiter des Solutions informatiques disparates ce qui a des impacts sur les coûts, la qualité et les délais de mise en production. On isole les équipes de développement par Solution. 2.3 Les délais et les coûts engendrent une culture de l échec Malgré les progrès effectués en matière de pilotage de projets, la majorité des projets sont en retard, coûtent plus que prévu et ne délivrent qu une partie des fonctions prévues, tout simplement parce que le Modèle est devenu trop complexe. Ces difficultés créent des relations conflictuelles entre les acteurs, et en particulier entre le métier et l informatique. Pour se protéger, les équipes de Transformation finissent par restreindre leurs ambitions et n acceptent que des projets limités, sans vision globale. 2.4 Peut-on faire mieux? Pour résumer, une adjonction de nombreuses Solutions indépendantes, aussi bonnes soient-elles, ne fait pas un bon Modèle d Entreprise. Peut-on faire mieux? Si oui, quelle cible ambitieuse peut-on définir? Comment l atteindre? Nous allons essayer d apporter quelques réponses. 11 Les Solutions actuelles ne permettent pas d évoluer rapidement
3 Commencer par Modéliser le métier de l assurance avant de se doter d une Solution. 3.1 Interopérabilité et Solutions transverses Les compagnies d assurance ont commencé par mettre de l ordre en permettant à leurs différentes Solutions d interopérer. Pour résumer, elles définissent ce qui est échangé entre les Solutions (les «interfaces») et quelle plateforme de communication permet de les transférer : c est ce que nous appelons la «Fondation d échange». Pour aboutir à ce résultat elle adoptent ce que l on appelle fréquemment une démarche d Urbanisme. Les échanges concernent : l accès aux données partagées : par exemple, le référentiel client qui appartient à une Solution CRM peut être accessible par les Solutions Contrat ou Sinistres. l appel de services : par exemple, un service «calcul de tarif» peut être logé dans une Solution Contrat, mais aussi être utilisé par une Solution CRM ou une Solution Quittancement. des flux d évènements : par exemple, la Solution comptable reçoit des flux d écritures comptables de la part de multiples Solutions. Les différentes Solutions sont celles de l assureur, mais ce sont aussi celles des partenaires avec lesquels on coopère : partenaires de BPO pour la production ou partenaires de distribution. Les échanges internes à l assureur et leur évolution peuvent être maitrisés par une instance de décision claire puisqu ils appartiennent à la même entreprise. Par contre, les échanges avec les partenaires nécessitent que des instances neutres définissent des standards qui s appliquent à tous. C est le cas par exemple de EDI Courtage qui représente un Modèle des échanges à respecter entre assureurs et courtiers. Des échanges normés et bien organisés apportent : la possibilité de répliquer des informations pour donner l autonomie d exécution à chaque Solution en gérant bien la fraicheur d information si les échanges sont asynchrones ; l absence de double saisie. un isolement de chaque Solution qui ne communique avec les autres que par des interfaces bien définies, ce qui réduit la complexité globale ; le partage de référentiels à condition que toutes les Solutions respectent un modèle de données convergent, par exemple pour les informations partagées sur les clients ou pour les informations de pilotage ; Les échanges peuvent être synchrones ou asynchrones. 12 Commencer par Modéliser le métier de l assurance avant de se doter d une Solution.
3.1.1 Echanges asynchrones Dans le cadre d échanges asynchrones, chaque Solution réplique une partie de ses données maîtres vers les Solutions qui peuvent avoir besoin de copies. Par exemple, la Solution CRM réplique des données Client vers les Solutions Gestion de Contrats et gestion de Sinistres. La fraicheur d information est liée au rythme des réplications. Les Solutions génèrent aussi des flux en sortie qui alimentent d autres Solutions : par exemple, la Solution quittancement génère des flux d écritures comptables vers la Solution comptable. Mais tous les services synchrones comme «calculer tarif» doivent être alors redéveloppés dans chaque Solution qui en a besoin : par exemple les Solutions CRM, gestion de contrat et quittancement. Avantages : les Solutions sont autonomes en exploitation, le cœur du Modèle de haque Solution n est pas modifié. Désavantages : la fraicheur d information est liée au rythme des réplications, la même fonction peut être modélisée dans plusieurs Solutions : c est plus couteux et plus difficile à synchroniser ; il faut gérer les échanges asynchrones. 3.1.2 Echanges synchrones Dans le cadre d échanges synchrones, chaque Solution exécute immédiatement les échanges dont elle a besoin. Par exemple, elle lit les informations maîtres des autres Solutions, ou elle déclenche des fonctions exécutées immédiatement par une autre Solution. Il s agit de l approche «SOA» : chaque Solution met à disposition des Solutions extérieures un certain nombre de Services dont elle publie «l interface» et la fonctionnalité réalisée, sans avoir besoin de détailler son «implémentation», c'est-à-dire comment elle est construite. A titre d exemple, pour un contrat auto, l interface décrit : donnez moi le Modèle de voiture, les garanties souscrites et je vous renverrai le tarif ; mais ne décrit pas la façon dont se calcule le tarif (l implémentation). 13 Commencer par Modéliser le métier de l assurance avant de se doter d une Solution.
Avantages : fraicheur d information immédiate, pas de duplication de fonctions et donc rapidité de mise à jour et de synchronisation entre Solutions Désavantages : modifier les Solutions pour qu elles fassent appel aux données ou aux «services» d autres Solutions. Mais, quelque soit le mode (synchrone ou asynchrone) choisi, cette structuration des échanges ne permet d atteindre ni l agilité espérée, ni la souplesse d organisation, ni une véritable intégration des métiers : Modèle Produit : difficile de proposer des offres mixtes qui combinent des garanties de différentes lignes de produits ; Modèle d Opération : l organisation est contrainte par le découpage en Solutions : o pas d homogénéité d usage (ergonomie, processus transversaux, sécurité) pour aider les utilisateurs externes tels que clients, distributeurs, unités décentralisées, qui peuvent être amenés à utiliser des Solutions diverses o pas d homogénéité d usage pour aider les utilisateurs internes et leur offrir davantage de polyvalence o difficultés à créer des centres de service partagés qui couvrent plus que le domaine d une Solution o complexité de l exploitation informatique de la multitude de solutions, ce qui nécessite des procédures lourdes à chaque changement Modèle de Transformation : toute création de produit nécessite de mettre à jour et de coordonner les évolutions dans différentes Solutions CRM, gestion de contrats, gestion de sinistres, commissionnement et idem pour les évolutions de Processus. 3.2 Est-il possible de réduire le nombre de Solutions dans un monde aussi diversifié que l assurance, On a beau interfacer les Solutions, elles restent aussi nombreuses. Pour réellement simplifier leur Modèle, les assureurs ne doivent donc pas se contenter d interfacer leurs Solutions : ils vont devoir réduire le nombre de Solutions d une part parce qu il est plus facile de gérer et de faire évoluer un système de 5 Solutions qu un système de 20 Solutions d autre part parce que la réduction du nombre de Solutions signifie : réduction dans la diversité des usages, réduction du nombre de bases de données, réduction des plateformes technologiques, réduction des mises en production, réduction des équipes de Transformation 14 Commencer par Modéliser le métier de l assurance avant de se doter d une Solution.
Mais fusionner des Solutions suppose de trouver des éléments communs entre ces Solutions disparates ; ce que l on propose d appeler «Fondation» (ceux qui sont intéressés peuvent télécharger le livre blanc du CEISAR consacré aux Fondations : www.ceisar.org ) On peut réutiliser les mêmes fonctionnalités de base comme l ergonomie, le mode d usage, la sécurité, le workflow ce qui conduit à une Fondation technique commune. Mais pour aller au bout de la démarche, on doit aussi se doter d une Fondation Assurance qui regroupe les éléments communs Métier. 15 Commencer par Modéliser le métier de l assurance avant de se doter d une Solution.
Mais comment Modéliser une Fondation s Assurance alors que les métiers de l assurance sont si différents? Au niveau Produit : Un produit IARD n a rien à voir avec un produit de prévoyance ; les Collectives n ont rien à voir avec l Individuelle ; L assurance aux USA n a rien à voir avec l assurance en France. Au niveau Opérations : La gestion de sinistres n a rien à voir avec la gestion de contrat ; La gestion des entreprises n a rien à voir avec la gestion des particuliers ; la distribution par agent n a rien à voir avec la vente directe. Au niveau Transformation, chaque Solution importe ses propres approches et outils que l on ne peut mettre en commun. Si le regroupement de Métiers différents au sein de la même Solution ne conduit qu à une juxtaposition de ce qui existait auparavant, on aboutit à une Solution énorme qui s avèrerait pire que des Solutions indépendantes. Le regroupement n a de sens que si on arrive à identifier des «invariants métier» communs, ce qui est extrêmement difficile tant on identifie mieux ce qui nous différencie que ce qui nous ressemble. Notre objectif est donc de décrire maintenant ces invariants métier de l assurance pour prouver qu il possible d isoler une Fondation d assurance puissante qui permet ce regroupement de métiers différents au sein de la même Solution. Nous proposons de démontrer qu il existe des éléments communs dans les produits puis dans les processus de l assurance. 16 Commencer par Modéliser le métier de l assurance avant de se doter d une Solution.
3.3 Y a-t-il des invariants dans les différents Produits de l assurance? Quelle que soit la branche, l assurance repose sur le principe du cycle inversé de production, à savoir que le prix de revient du service vendu au client n est pas connu à l avance. En échange d une prime, l assureur couvre les conséquences de la survenance d un événement (accident, consultation médicale, arrêt de travail ). Les concepts manipulés par les assureurs restent donc invariablement les mêmes : le client, le risque, le produit, le contrat, la prestation, la tarification et la facturation du contrat. On doit donc être capable de construire des outils qui permettent d assembler de nouveaux produits en s appuyant sur cette structure uniquement par paramétrage. C est la meilleure réponse à la contrainte citée en 1.1 : produits de niche, produits sur mesure et meilleure segmentation. 3.3.1 Le Client Les assureurs sont passés d une logique de contrats à une logique de clients. Alors qu ils étaient jusqu à présent essentiellement organisés par lignes produit (ou branches), ils s organisent progressivement autour du «Client» qui regroupe des rôles identiques quelque soit la branche : le Décideur, le Souscripteur, le Payeur, l Assuré ou le Bénéficiaire des prestations. 3.3.2 Le Risque Quelque soit la ligne produit, le «Risque» regroupe : l objet assuré qui peut être soit un bien (automobile, habitation), soit une personne (une personne physique, une entreprise, un ensemble de personnes) ; l événement couvert qui donne lieu à indemnisation en cas de survenance. Lorsqu un Risque se réalise, il peut donner lieu à un préjudice (perte de revenus, bien endommagé ). Cette notion de risque est invariante quelle que soit la branche d assurance considérée. Néanmoins, les spécificités de chaque branche se retrouvent dans la nature des objets et événements. Risque Biens et RC Prévoyance Santé Vie Objet assuré Véhicule Flotte Habitation Entreprise Salarié Personne physique Evénements Accident Auto Dégât des eaux Accident du travail Consultation Opération Personne physique Décès 3.3.3 le Produit Le Produit représente les prestations proposées par l assureur pour couvrir les préjudices subis en cas de réalisation d un ou plusieurs risques. Sur un plan réglementaire, les prestations relatives à un même risque sont normalisées et regroupées au sein de garanties (on parle de garanties ministérielles). Ces garanties servent alors d agrégat fiscal (niveau de taxation) et réglementaire (niveau de reporting). Afin de faciliter la commercialisation et d assurer une plus grande lisibilité, le regroupement de prestations est également utilisé en souscription sous la forme de garanties proposées (garanties commerciales). Exemple : Garantie Dégât des Eaux Risque : Dégât des Eaux 17 Commencer par Modéliser le métier de l assurance avant de se doter d une Solution.
Evénement : Dégât des Eaux Objet assuré : Habitation Prestations o Réparation des dommages à l habitation (peintures ) o Remboursement du mobilier endommagé o Financement de la recherche de fuites Le Produit doit définir non seulement les Risques couverts et les Prestations associées, mais aussi : les règles de souscription ou d évolution du Contrat telles que le tarif, les conditions d éligibilité, les modalités de règlement ou les règles de suspension, de résiliation de reconduction les règles de gestion des sinistres et des prestations. 3.3.4 Le Contrat Pour formaliser l accord entre le Client et l Assureur, un Contrat est établi. Il comporte systématiquement : un ou n souscripteurs un ou n bénéficiaires des prestations des garanties souscrites en regroupant pour chacune d elles : o le risque assuré (association d événements et d objets assurés) o les types de préjudices couverts o les prestations proposées le prix les modalités de règlement par le client la période de validité du contrat (date d effet et date de fin) Quelle que soit la ligne produit, les mécanismes de gestion des contrats sont identiques. En effet, ces mécanismes ne dépendent pas des objets de risques ni des événements propres à chaque branche. Il existe seulement des spécificités de gestion relatives à la nature collective ou individuelle du contrat. Les mécanismes de gestion des contrats dans le domaine collectif impliquent généralement des activités spécifiques de déclaration des objets de risques (population de salariés à couvrir, véhicules d une flotte ). 3.3.5 La Prestation La prestation représente le service rendu par l assureur en cas de réalisation de certains risques. Ces prestations se basent toujours sur: une déclaration de sinistres qui décrit les conditions de survenance de l événement (constat amiable en auto, décompte de la sécurité sociale en santé ) o la date de l événement o L objet assuré impliqué dans le sinistre o les circonstances de l événement (lieu ) o le préjudice constaté (réel ou estimé) la détermination et le déclenchement de la prestation que doit rendre l assureur qui peut prendre plusieurs formes : o une indemnisation financière du préjudice subi par le client (remboursement des frais de réparation, capital décès) o une indemnisation en nature (réparation ou remplacement du bien endommagé) o un service complémentaire destiné à limiter les «désagréments» causés par le sinistre (assistance, services à la personne ). Les différences entre les branches d assurance résident essentiellement dans la nature des événements couverts et les processus de gestion d un sinistre. En effet, la description d un sinistre automobile ne regroupe pas les mêmes informations que celles utilisées pour un remboursement en santé, mais encore une fois la structure est la même. 18 Commencer par Modéliser le métier de l assurance avant de se doter d une Solution.
3.3.6 La tarification et la facturation du contrat En assurance, le mécanisme de tarification est basé sur des calculs actuariels destinés à estimer, sur des bases statistiques et probabilistes, les coûts futurs des risques couverts. Les principaux mécanismes s appuient sur les notions de fréquence de survenance des événements couverts et sur les coûts moyens (observés ou estimés). Les principaux paramètres à prendre en compte dans la tarification sont donc liés à la nature des risques à couvrir : Les données de l objet assuré Les événements couverts Les prestations proposées en cas de survenance de l événement. En résumé tous les Produits, Contrats et Sinistres de l assurance respectent la même structure. Comment en tirer partie? Proposé Souscrit Réel Produit Contrat Proposé Contrat (Souscrit) Garantie Garantie Proposée Garantie Souscrite Risque Evènement Evènement Proposé Evènement Couvert Evènement réel Objet Type d objet proposé Objet Couvert Préjudice Type de préjudice proposé Type de préjudice couvert Préjudice subi Prestation Type de prestation proposée Type de prestation souscrite Prestation délivrée 3.4 Y a-t-il des invariants dans les différentes Opérations de l assurance? La durée de vie d une Solution est généralement de 10 à 20 ans. On trouve encore aujourd hui dans les compagnies d assurance, des logiciels qui ont 30 ans! Mais les organisations évoluent aujourd hui environ tous les 3 ans : on change la structure des équipes et les rôles de chacun, on travaille davantage avec des partenaires, on «out-source» un certain nombre d activités Il faut donc désynchroniser les changements d organisation des changements de Solutions. Peut-on isoler ce qui est invariant dans le métier de l assurance, des différentes formes d organisation successives? Peut-on en déduire un découpage de Solutions qui soit indépendant d une organisation volatile et qui permette à des Solutions stables de supporter des organisations successives? 3.4.1 Les invariants des processus contrat et sinistre Les Processus Opérationnels d une compagnie d assurance peuvent être classifiés en : gestion des ressources : RH, distributeurs, informatique, finances, locaux pilotage : pour contrôle de gestion, risques, marketing, réassurance, comptabilité générale, processus primaires de l assurance: o gestion du client : contact avec un prospect, campagne commerciale, analyse des besoins du client, gestion d un compte client, analyse du risque et de la rentabilité 19 Commencer par Modéliser le métier de l assurance avant de se doter d une Solution.
o o gestion du contrat : choix de l offre, simulation, proposition, souscription, avenants au contrat, facturation, règlements gestion du sinistre : déclaration, évaluation, exécution des prestations La gestion des ressources, le pilotage et la gestion du client sont des processus transversaux communs aux différentes lignes produits. Par contre, les gestions du contrat et du sinistre sont des processus verticaux dépendants de chaque ligne produit (Remarque : le Processus de Gestion de Produit fait partie des Processus de Transformation et non des Processus opérationnels). On a donc développé des Solutions verticales par ligne produit. Pour réduire le nombre de Solutions, est-il possible de concevoir des Solutions qui couvrent plusieurs lignes produits? Quels sont les invariants de ces différentes Solutions, sont ils suffisamment importants pour justifier de construire des Solutions plus globales? A vrai dire, les cycles de vie des contrats et des sinistres ont de nombreux points communs : le cycle de vie du contrat est le même pour tous les produits : o obtenir le contact avec le client o comprendre les besoins du client et l objet à assurer o choisir l offre adaptée o faire n propositions successives jusqu à accord ou refus du client o choisir les options et garanties o tarifer o contrôler éligibilité o souscrire le contrat o facturer o recevoir les règlements 20 Commencer par Modéliser le métier de l assurance avant de se doter d une Solution.
o o gérer des avenants terminer le contrat le cycle de vie du sinistre est le même pour tous les produits : o déclarer le sinistre o rechercher le ou les contrats concernés o vérifier l éligibilité du risque o évaluer le préjudice et les prestations à servir au client. Cette évaluation peut nécessiter de mettre en œuvre des activités complémentaires (expertise ) et de provisionner le coût de la future prestation. o délivrer les prestations (indemnité ou service) qui est le domaine où la diversité est la plus forte. A titre d exemple, en IARD, les processus de gestion reposent sur les conventions CGIRSA alors qu en Santé, les règles de service des prestations dépendent du régime obligatoire Peut-on offrir un canevas général qui suit ces cycles de vie et qui serait personnalisable produit par produit? 3.4.2 L accès aux Informations partagées (les référentiels) Tous les Processus de gestion de contrat ou de sinistres font appel aux mêmes référentiels que l on pourrait mettre en commun : client, produit, comptes, distributeurs, structure d organisation de l assureur, 3.4.3 Les Fonctions réutilisables par tous les processus Tous les Processus de gestion de contrat ou de sinistres font appel à des fonctions identiques : contrôle d autorisation envoi de messages (y compris dans une corbeille) génération d évènements vers les Solutions de o comptabilité client o comptabilité distributeur o autres comptabilités tiers o réassurance o éditique o GED 3.4.4 Les invariants de la distribution Le secteur de l assurance utilise une grande diversité de canaux de distribution : Les agents généraux et courtiers (souvent appelés «intermédiaires») Les banques Les réseaux salariés propres aux assureurs (mutuelles, MSI, réseaux salariés des compagnies) Les partenaires qui vendent de l assurance en inclusion d autres offres (opérateurs de téléphonie, constructeurs automobiles ). Les assureurs proposent de ce fait à ces partenaires des produits en marque blanche. L assurance directe (internet, téléphone) Pour chaque réseau, il est nécessaire de mettre en place un protocole qui est toujours structuré de la même façon : Les produits distribués Les règles de rémunération (commissionnement) Le niveau de délégation de gestion (souscription, gestion des contrats, gestion de sinistres) Les procédures de gestion entre l assureur et le distributeur Les circuits financiers entre l assureur et son distributeur (encaissement confié ou direct) 21 Commencer par Modéliser le métier de l assurance avant de se doter d une Solution.
On peut donc, comme pour les contrats et sinistres, offrir un canevas de gestion de la distribution qui est commun à toutes les formes de distribution. 3.4.5 Harmonisation d usage Par «usage» nous entendons tout ce qui aide l acteur à utiliser une Solution : ergonomie : présentation, navigation, bureau mécanismes d organisation : gestion de corbeille, workflow, autorisation Si chaque Solution importe son propre mode d usage, il est plus difficile pour chaque acteur de passer d une Solution à l autre. A l inverse, une harmonisation de l usage facilite la polyvalence. C est fondamental pour les acteurs externes : les prospects, clients, courtiers, partenaires divers utiliseront davantage les outils de la compagnie d assurance si l usage en est toujours le même. Une compagnie qui a pour objectif de transférer progressivement le maximum d activités à ses clients et partenaires doit soigner l homogénéité d usage. C est aussi important pour les acteurs internes, non seulement pour les Agents et les unités décentralisées qui doivent utiliser une grande diversité de Solutions, mais aussi pour les back offices, les centres d appel : on peut élargir leur champ d action et les rendre plus polyvalents si l effort est plus faible pour passer d un domaine fonctionnel à l autre, ce qui a des conséquences sur la productivité globale, la capacité à répartir dynamiquement les charges et les opportunités de carrière. 3.5 Y a t il des invariants dans les différents projets de Transformation? Chaque Solution peut être construite avec son propre environnement de Transformation : approche, outils d analyse, de développement, de test, d intégration, infrastructure technologique Le partitionnement de ces environnements induit un partitionnement des équipes. En outre il empêche de partager une banque de composants réutilisables entre différentes solutions ce qui est le facteur essentiel d accroissement de l agilité. Pourquoi ne pas choisir de développer des Solutions différentes sur un même environnement de Transformation? En résumé il existe de nombreux invariants dans le métier de l assurance. Pourquoi ne pas se doter d une Solution construite sur ces invariants du métier, qu il serait aisé de personnaliser produit par produit, et processus par processus? 22 Commencer par Modéliser le métier de l assurance avant de se doter d une Solution.
4 Quel Modèle global cible? Nous avons essayé de démontrer que le métier de l assurance comporte de nombreux invariants dans la structure des Produits et des Processus. Comment peut-on se doter d un Modèle cible qui s appuie sur ces invariants pour, d une part, réduire le nombre de Solutions, et, d autre part simplifier les évolutions? L effort pour modéliser le métier de l assurance avant de construire une Solution globale, a pour vertu non seulement de réduire le nombre de Solutions, mais aussi d identifier les domaines où l on peut paramétrer le Modèle pour le rendre plus agile. C est ce que nous allons présenter maintenant. 4.1 Modèle actuel d une Compagnie d assurance Il est constitué d un ensemble de Solutions indépendantes qui échangent entre elles. 4.1.1 La part croissante des progiciels Le nombre croissant de fonctions à informatiser fait que les équipes internes sont surchargées et que les Solutions sont de moins en moins développées en interne et de plus en plus acquises à l extérieur sous forme de progiciels. Chaque progiciel doit être personnalisé, soit sous forme de développement spécifique, soit sous forme de configuration (utilisation de paramètres, de moteur de règles, ou de moteur de workflow). L avantage de la configuration est double : il ne nécessite pas de compétence technique et il s inscrit dans une architecture déjà testée, ce qui accélère les phases de test, intégration, performances. Grace à la configuration, les métiers peuvent effectuer directement une large part des Transformations sans passer par l informatique : on accélère considérablement le processus de Transformation 23 Quel Modèle global cible?
En outre il faut développer des interfaces entre ce nouveau progiciel et les autres Solutions déjà en place. Les développements spécifiques et les interfaces représentent la partie lourde dans l intégration d un progiciel : comment les réduire? 4.2 Système cible d une Compagnie d assurance Comme illustré précédemment, un Modèle d assurance comprend finalement beaucoup plus de points communs qu on ne l imagine a priori. On peut donc définir une Cible ambitieuse qui s appuie sur ces invariants. La cible la plus simple est de disposer d une seule Solution qui sait prendre en compte tous les besoins de l assurance parce qu elle s appuie sur une Fondation d assurance unique qui modélise toutes les fonctions techniques et tous les invariants de l assurance qui ont été décrits ci-dessus (modèle d information, patterns de processus, fonctions communes, référentiels partagés, environnement de transformation ). Certains qui ont adopté cette approche ont réussi à diviser par 5 la taille de chaque Modèle-branche : la partie spécifique à chaque Branche ne représente plus que 20% de ce qu elle représentait autrefois, le reste étant fourni par la Fondation d assurance. Des compléments pour chaque ligne métier (IARD, Vie, Prévoyance ) complètent la Fondation : plus la Fondation est puissante, plus ces compléments se réduisent. Les fonctions métier spécifiques telles que calcul de tarification, contrôle d éligibilité, calcul d évaluation de prestation restent propres à chaque produit. Si la Fondation est bien structurée selon les invariants de l assurance décrits ci-dessus, chaque Solution est personnalisable par ligne produit ou par pays avec un minimum de développements spécifiques et un 24 Quel Modèle global cible?
maximum de configuration : l efort de Modélisation du métier de l assurance a pour effet mécanique d agrandie le champ de la configuration. La configuration, c'est-à-dire le paramétrage et l utilisation de moteurs de règles, permettent aux concepteurs de produits de rapidement construire ces règles sans avoir à passer par le cycle lourd des développements logiciels : c est la clé du «time to market». Remarque : pour simplifier le travail des concepteurs de produits, il est recommandé de prédéfinir quelles informations peuvent être utilisées pour chaque type de règles pour éviter de rechercher dans le foisonnement d informations disponibles. Entre la situation actuelle caractérisée par la multitude des Solutions, et cette cible ambitieuse constituée d une seule Solution, il existe des scenarios intermédiaires qui permettent néanmoins de réduire la complexité du Système cible à quelques Solutions. 4.2.1 Une Fondation d assurance modélise les invariants Comme présenté ci-dessus, la structure des produits d assurance est identique et les processus de l assurance respectent des modèles similaires. La Fondation de la Solution modélise ces invariants sous forme : d un Atelier Produit pour concevoir de nouveaux produits ou les faire évoluer ; de Patterns de processus qui servent de structure aux multiples Processus de l assurance ; de composants réutilisables ce qui diminue considérablement la taille de chaque Solution et donc simplifie le Modèle global : o composant d accès aux référentiels clients, structure, pilotage o composants pour standardiser ergonomie et navigation par canal et par media ; o composants d interface avec les autres Solutions ; o composants pour éditique, GED, authentification, autorisation d une infrastructure technique homogène qui supporte les différentes Solutions. 25 Quel Modèle global cible?
Note: pour mieux comprendre l utilité des composants, on peut utiliser l analogie avec l industrie automobile qui sait concevoir de nouveaux Modèles à partir de composants réutilisables ; plus le taux de composants est élevé, plus la conception de nouveaux Modèles s accélère, et plus les véhicules sont fiables. Pour être concret, reprenons l exemple du CRM décrit dans la 2 partie. Plutôt que d installer une Solution autonome CRM, il faut faire en sorte que les Processus commerciaux tels que «accéder à une synthèse client», «gérer des campagnes commerciales», «gérer des contacts successifs jusqu à signature du contrat» s appuient sur : les mêmes fichiers client, produit, contrat ; les mêmes fonctions de calcul de tarifs, de contrôle d éligibilité, d impression de contrat ; les mêmes mécanismes d usage : ergonomie, navigation, sécurité, corbeille, messagerie. On aboutit alors à un Modèle beaucoup plus simple décrit ci-dessous qui consiste à enrichir la Solution existante (les parties roses) et non à juxtaposer une Solution indépendante qui a du mal à coexister. Il est plus facile de rajouter ces enrichissements à une même Solution que de construire les échanges entre Solutions distinctes, et surtout de les faire évoluer en parallèle. C est aussi la bonne méthode pour entretenir un référentiel client utilisable par tous. 4.2.2 Configurer ce qui change souvent Si le Modèle d assurance est suffisamment riche, on peut ranger les différentes composantes des produits dans une structure où se logent les garanties, les prestations, les règles d éligibilité, de tarification, de calcul des prestations, de commissionnement et mettre entre les mains des métiers un atelier produit qui permet de concevoir et de mettre à jour les produits, ce qui réduit la chaîne classique «expression du besoin, analyse, conception, développement, tests, documentation, intégration, recette». Si on dispose non seulement d un atelier produit, mais aussi de patterns de processus pour la gestion de contrats et de sinistres, on peut automatiquement générer les processus de chaque produit en s appuyant sur les règles définies grâce à l atelier produit sans passer par la chaine de développement habituelle. On parvient alors à 26 Quel Modèle global cible?
obtenir un «time to market» extrêmement court parce que le métier prend en main directement la création de produits, et que les utilisateurs retrouvent le même mode d usage et n ont donc pas besoin de nouvelle formation. On recommande de définir les Processus en deux temps : 1. s appuyer sur les patterns de processus pour enchainer les actions métier de tous les processus qui en dépendent ; 2. affecter les tâches aux acteurs dans le cadre d un outil de BPM («Business Process Modeling») qui s appuie sur du paramétrage pour définir les règles d affectation aux différents acteurs. Chaque fois que l on modifie l organisation, on n effectue que l étape 2. Au-delà de la conception de produits et de processus, on peut appliquer les principes de configuration (paramétrage, moteur de règles) à des domaines complémentaires tels que : la facturation ; le commissionnement ; l éditique ; la réassurance. La configuration peut aussi être utilisée pour adapter les parties du Modèle qui sont propres à chaque pays: langue, devise, réglementation et fiscal. 4.2.3 Spécifique Moins il y a de spécifique à développer, plus la Solution sera installée rapidement. Comme indiqué précédemment, la puissance de la configuration est clé puisqu elle réduit la part de spécifique. Pour construire ce qui reste spécifique, il est souhaitable : d isoler les parties qui peuvent être modifiées : c est le cas par exemple des interfaces utilisateurs propres à différents médias qui réutilisent les fonctions (comme la tarification) et les informations communes (comme le référentiel client) ; de mettre à disposition des Acteurs de la Transformation une banque de composants qui réduit l effort dans des proportions importantes. Un autre facteur peut limiter le spécifique : comme, lors de la rénovation de leurs Solutions, les utilisateurs ont souvent tendance, à vouloir reproduire ce qu ils connaissent, il faut leur demander de poser des problèmes et de ne pas imposer de solutions. Un même problème peut être résolu par différentes solutions : il vaut mieux choisir celle proposée par le progiciel plutôt que de faire développer une solution spécifique qu il faudra ensuite maintenir. Enfin, il faut outiller les tâches de construction d interfaces avec les autres Solutions et de migration de données d une Solution ancienne à une Solution nouvelle pour en réduire les couts et les délais. 4.3 Quels scenarios pour une Compagnie indépendante? Le Modèle de départ est un Modèle éclaté généralement constitué par autant de Solutions qu il existe de combinaisons entre lignes métier et domaine de processus. A titre d exemple une compagnie qui gère l IARD et la santé a 4 Solutions : gestion de contrats IARD, gestion de sinistres IARD, gestion de contrats santé et gestion de sinistres santé. En complément de ces Solutions métier se rajoutent des Solutions transversales pour la gestion des distributeurs, le CRM, la comptabilité 27 Quel Modèle global cible?
Le Modèle cible est un Modèle cohérent constitué d une seule Solution qui couvre tous les domaines parce qu elle est construite sur une Fondation unique. Il existe des Modèles intermédiaires qui permettent de se rapprocher de la cible. Et la plupart des assureurs finiront par adopter des Modèles intermédiaires. Parmi ces Modèles intermédiaires on doit favoriser le regroupement par ligne métier plutôt que par domaine de processus : il vaut mieux une Solution IARD et une Solution Santé indépendantes qu une Solution Gestion de contrat et une Solution Gestion de Sinistres indépendantes. Il y a en effet plus de synergie entre gestion des contrats et des prestations IARD qu entre gestion des prestations IARD et vie. Un exemple de cible intermédiaire est de : choisir des Solutions transversales indépendantes pour la comptabilité, le pilotage ; choisir une seule Solution par ligne métier qui regroupe gestion des contrats et gestion des sinistres dans la même Solution : il faut donc faire converger vers la Solution IARD ce qui était traité par les différentes Solutions IARD, ce qui était éclaté en Solution contrat et Solution sinistre, et ce qui était éclaté en particulier et entreprise ; limiter la Solution CRM à la gestion d un référentiel client et aux processus purement CRM (gestion de contacts, gestion de campagnes), en laissant chaque Solution-métier gérer le cycle de vie des contrats, y compris dans la phase de vente (simulation, devis, proposition). 28 Quel Modèle global cible?
29 Quel Modèle global cible?
4.4 Quels scenarios pour un Groupe de Compagnies? Pour un Groupe de Compagnies, le point de départ est encore plus complexe puisqu il peut exister autant de combinaisons de Solutions qu il existe de Compagnies dans le groupe. Quel axe de simplification choisir pour réduire le nombre de Solutions? 30 Quel Modèle global cible?
4.4.1 Stratégie du «Best of breed» Le Groupe définit une bonne Solution pour chaque besoin, mais ne se préoccupe pas de savoir si elles sont ou non bâties sur la même Fondation. Chaque fois qu une filiale du Groupe a besoin de changer une Solution, elle doit choisir la Solution préconisée par le Groupe. Une Compagnie ne peut ignorer l investissement fait par le Groupe. Le Groupe n impose pas de rythme de migration aux filiales : chacune doit définir son planning en fonction de ses besoins d amélioration. Cette approche a pour avantage d harmoniser les Solutions entre filiales : il sera plus facile par la suite d échanger des Produits ou des Processus, ou de créer des back offices communs. Les filiales n ont pas besoin d investir dans l étude de la cible : on centralise la fonction achat et on réalise des économies d échelle auprès des éditeurs. Si le Groupe a les moyens de pré-intégrer les différentes Solutions entre elles, les filiales n auront pas besoin de refaire chacune ce travail d intégration ; elles auront ainsi davantage confiance dans la capacité de ces différentes Solutions à s exécuter ensemble. Par contre, cette stratégie ne simplifie pas le Modèle de chaque Filiale qui continue à être constitué de Solutions disparates : elle n apporte ni l agilité, ni la souplesse d organisation. 31 Quel Modèle global cible?
4.4.2 Stratégie d une Fondation Groupe Le Groupe se dote d un Modèle d assurance bâti sur une Fondation unique. Dans ce cas, les avantages précédents sont conservés : harmonisation à terme entre les Solutions des différents filiales, centralisation des achats. Mais en outre chaque filiale va progressivement converger vers une cible qui diminue ses couts, accroit son agilité et sa souplesse d organisation. C est la stratégie la plus efficace pour un Groupe. Pour réussir ce type d approche long terme, il faut : que le Groupe fasse un bon choix en terme de Modèle cible : ce Modèle doit être plus simple pour chaque filiale et il doit respecter les spécificités locales ; que le Groupe pré-intègre les différentes Solutions recommandées pour que chaque filiale n ait pas à le faire ; que le Groupe dispose d une équipe centrale pour supporter les filiales dans l adaptation du Modèle commun ; que chaque filiale joue le jeu du Groupe ; que la gouvernance qui accompagne cette politique ne fasse pas porter le poids des investissements aux premières filiales qui vont essuyer les plâtres d un Modèle nouveau ; cela suppose que le Groupe ait dégagé des moyens pour se doter d un Modèle cible cohérent et pour le supporter auprès de ses filiales. En résumé, il faut que le Groupe se comporte vis-à-vis de ses filiales comme un éditeur de logiciel se comporte vis-à-vis de ses clients : une équipe de R/D centralisée, une équipe de support, un processus de définition des versions futures, une école de formation, une documentation propre 32 Quel Modèle global cible?
4.5 En quoi le «Cloud» change-t-il les règles du jeu? Le Cloud consiste à exploiter la Solution informatique dans un environnement technique qui n est pas géré par l utilisateur : il se trouve quelque part dans les nuages. Le fournisseur peut gérer l infrastructure sur laquelle s exécute la Solution qui est développée par le client ou le fournisseur. La généralisation d Internet permet d utiliser la Solution sans avoir besoin de l installer sur ses propres machines. Les intérêts sont évidents : le coût est lié à l usage, donc à la valeur que l on en retire, on peut faire face à des pointes de consommation, on n a pas à gérer l exploitation informatique. Par contre, les interfaces entre progiciels exécutés dans des «Clouds» différents est problématique. C est donc une approche qui sera adaptée à des progiciels indépendants : soit une Solution qui traitent des fonctions isolées ; soit une Solution qui traite toutes les fonctions d une entreprise : ce peut être le cas pour les petites entreprises, telles que les courtiers, les agents, les experts 4.6 Quelle Valeur? Nous avons essayé de résumer dans ce tableau la valeur apportée par chaque scénario. Pour résumer, un système cible construit sur une Fondation unique apporte de la valeur à différents niveaux : Valeur en termes d impact marché : visibilité de l offre globale et capacité à assembler des produits mixtes rapidité du développement de Solutions pour de nouveaux services intégration des processus de CRM 33 Quel Modèle global cible?
échanges de produits entre filiales Valeur en terme d efficacité des Opérations harmonisation de l usage gage de polyvalence, d évolution du personnel, de productivité et de décentralisation : c est un des facteurs clés qui va faciliter la gestion du changement. Une fois fait l effort au nouveau mode d usage, il est très facile d utiliser d autres fonctionnalités si elles s appuient sur les mêmes ergonomies, mêmes présentations, mêmes navigations échanges de Modèles de Processus entre filiales souplesse de l organisation : adaptation de la chaine de valeur, réorganisation interne, décentralisation d une partie des opérations chez les partenaires et/ou les clients, création de back-office à destination de différentes filiales Valeur en terme d efficacité de la Transformation réduction des coûts et délais d évolution et de maintenance simplification du déploiement même utilisation : ce qui réduit les besoins de formation ou d initialisation de Solutions même infrastructure informatique : ce qui réduit les efforts d installation et configuration de l infrastructure informatique. 34 Quel Modèle global cible?
5 Comment y parvenir? Plutôt que de raisonner sous la forme d un portefeuille de projets indépendants qui sont négociés chaque année lors de la phase budgétaire, nous proposons que chaque compagnie définisse le Modèle d Entreprise cible qu elle souhaite atteindre, quitte à y migrer progressivement au fur et à mesure des programmes d action successifs. 5.1 Est ce le bon moment pour un «bond en avant»? Un assureur se doit de poser la question suivante : «puis-je faire mieux que mes concurrents dans les 5 ans avec mon modèle d Opération (métier et informatique) en place?». Pour répondre à cette question, prenons l exemple suivant d évolution à mener dans les 5 ans : On souhaite créer un produit unique qui propose la Santé, la Dépendance, l Epargne/Retraite et qui intègre des services complémentaires : o Télémédecine facturée à l utilisation o La fourniture de bouquets de services en cas de dépendance (nombre d heures de services) Le lancement d un tel produit implique : o Un processus unique de souscription et de gestion d un contrat incluant tous ces services o La possibilité pour le client de gérer son contrat unique via internet (avenants, modifications administratives ) o Une organisation basée sur une plate-forme unique de gestion capable de fournir l ensemble de ces services au client. L objectif est qu un même gestionnaire soit capable de gérer l ensemble de la gamme de services o La capacité de facturer des services en fonction de leur consommation (télémédecine) Si la réponse est «oui, notre Modèle actuel est capable de le mettre en place», il suffit de faire évoluer progressivement son système actuel. Si la réponse est «non», une rupture est nécessaire. Nous ne présentons que ce deuxième cas. 5.2 Quelle ambition? La cible se doit d être ambitieuse. Il ne faut pas chercher à la restreindre au départ sous prétexte que l écart serait trop important avec l existant et que le chemin est difficile : on n a que rarement l occasion de se projeter dans le futur. C est aussi le bon moyen pour remotiver des équipes de Transformation souvent désabusées. Le risque doit être maitrisé par la progressivité de la trajectoire et non par la réduction de la cible. Pour que la cible soit simple, il faut un minimum de Solutions, l idéal étant de sélectionner une seule Solution qui s appuie sur une Fondation puissante modélisant sous forme de composants les invariants de l assurance décrits ci-dessus. Si des fonctions sont manquantes, la progressivité de la mise en place donnera le temps de les ajouter à la Solution grâce à l efficacité de la Fondation. 5.3 Qui doit fournir la Fondation et la Solution cible? Il est extrêmement difficile pour les assureurs, qui doivent déjà gérer leur système en place, de construire une telle Fondation Globale : ils n en ont ni le temps, ni les ressources. C est donc aux éditeurs de logiciels de mettre à leur disposition une nouvelle génération de produits : une Fondation qui permet de supporter différentes fonctionnalités d assurance, que ces fonctionnalités soient aussi proposées par l éditeur, ou construites par la compagnie d assurance. 35 Comment y parvenir?
A un éditeur qui propose une Solution, ne pas hésiter à demander si la Fondation sous-jacente est ou non accessible au client pour qu il puisse faire évoluer la Solution, voire construire de nouvelles fonctions si l éditeur n a pas l intention ou les ressources pour les proposer. De même que nous avons expliqué en introduction que les assureurs qui gagneront demain seront ceux qui maitrisent un Modèle multi-lignes métier, il est probable que les éditeurs qui gagneront seront ceux qui ont su proposer une Fondation puissante sur laquelle ils délivrent progressivement un nombre croissant de fonctions de l assurance. 5.4 Quels critères de choix pour une Fondation? Les critères de choix de la Fondation sont simples : 1. Couvre-t-elle le bon périmètre? une Fondation prévue pour l individuelle ne pourra pas être «tordue» ultérieurement pour satisfaire les besoins du collectif une Fondation prévue pour un seul pays aura du mal à s adapter par la suite à plusieurs pays 2. Quelle agilité donne-t-elle à la compagnie pour lancer de nouveaux produits, créer de nouveaux processus? 3. La Fondation peut-elle aisément évoluer, par exemple pour prendre en compte de nouveaux médias, ou développer de nouveaux Services? 4. Produit-elle des Solutions qui peuvent s interfacer aisément avec les autres Solutions? 5. Génère-t-elle des Solutions qui s exécutent dans des environnements technologiques standards avec une bonne qualité de service (fiabilité, performance)? Rien n est pire qu une mauvaise Fondation que l on impose à toutes les fonctions de l assurance. Le choix doit donc être fait avec de grandes précautions : il ne suffit pas de s appuyer sur les déclarations des fournisseurs, il est indispensable de juger sur pièces en analysant l architecture de la Fondation, en construisant des prototypes qui illustrent l efficacité de la Fondation ou en prenant contact avec ceux qui ont déjà mis en place la même Fondation. 5.5 Quelle gouvernance? Aucune direction métier ne demande une Fondation : ils réclament des Solutions. La Fondation fait partie du bien commun et représente donc un choix de Direction Générale. Il est nécessaire de faire preuve de pédagogie pour convaincre la DG d investir dans une Fondation : il faut expliquer que l on peut satisfaire des besoins différents avec des composants communs, qu il existe des invariants dans le métier de l assurance sur lesquels on peut s appuyer pour construire moins de Solutions plus riches, et il faut illustrer la valeur concrète de la Fondation. Ainsi la DG pourra décider, financer et supporter sur la durée la diffusion progressive de la Fondation d assurance qui va devenir la colonne vertébrale de la compagnie. Cette démarche nécessite des bascules progressives et couteuses, métier par métier, avant d obtenir l essentiel de la valeur qui sont l agilité, la rationalisation, l indépendance de l organisation, le déport d une bonne partie des activités vers les clients et les partenaires Pour convaincre les dirigeants il faut apporter une justification financière qui doit prendre en compte différents domaines : Quels gains de productivité dans les Opérations: déport des activités vers le client ou le partenaire, polyvalence des acteurs grâce à l homogénéité d usage, absence de doubles saisies et d erreurs? Les gains peuvent être considérables : certains assureurs ayant choisi ce type d approche prétendent avoir réalisé des gains de productivité de 40%! 36 Comment y parvenir?
Quels gains de productivité dans les Opérations informatiques : moindre nombre de Solutions à exploiter, moindre nombre de serveurs? Quels gains de productivité dans la Transformation : moindre nombre de Solutions à maintenir, apprendre une seule Fondation, puissance de la configuration, puissance de la réutilisation de composants? Les projets informatiques représentent souvent la moitié du budget informatique d un assureur. Les gains peuvent se chiffrer là encore en dizaines de pourcents ; mais nombreux sont ceux qui choisissent alors d en faire plus plutôt que de réduire les coûts de Transformation. Mais une partie de la valeur reste difficile à expliciter financièrement: il s agit de la simplification du Modèle d entreprise et de l agilité associée. Combien vaut la réduction du time to market? Combien vaut la rapidité de fusion de nouvelles entreprises qui rejoignent un groupe? Combien vaut une plus grande cohérence dans la culture d entreprise? Le «Business case» associé est donc difficile à détailler comme dans le cas de projets court terme qui s inscrivent dans une architecture existante et dont on peut évaluer un retour sur investissement précis qui facilite les décisions financières. Il s agit là d un investissement structurel qui nécessite bien sûr des justifications financières, mais aussi un acte de foi dans la valeur immatérielle de la cible. La décision ne peut être uniquement financière, elle doit être portée par un sponsor qui a une vision. Si les membres de la DG qui ont supporté la démarche sont remplacés, rien ne garantit que leurs successeurs reprennent le flambeau. La seule garantie de continuité tient au fait qu une partie significative des Opérations utilise la nouvelle Solution et que la preuve a été faite de son efficacité : la «planche est alors savonnée dans le bon sens», et il devient naturel pour tous de poursuivre une politique qui est acceptée par la majorité. Il est donc indispensable d obtenir des résultats rapides et probants, pour ne pas prendre le risque d une remise en cause en cas de départ des sponsors. Pour y parvenir, il ne faut pas attendre d avoir construit une Fondation de toutes pièces, il faut s appuyer sur une Fondation déjà existante et particulièrement efficace, qui permet d offrir les premiers résultats concrets en moins d un an et qui apporte des résultats tangibles en moins de deux ans. Si on n arrive pas à convaincre la Direction Générale de la nécessité stratégique d une cible simplifiée, on peut réduire son ambition au périmètre d un grand projet, choisir une Fondation, faire la preuve de son efficacité et espérer que ce sera suffisamment convaincant pour généraliser la Fondation à l issue de ce projet. Dans ce cas, le délai de convergence est plus long, la valeur sera atteinte plus tardivement, et le financement doit être intégré au sein de ce projet. Pour éviter tout surcoût, il faut pouvoir facturer la Fondation externe à l usage, ce qui suppose que les Editeurs de logiciels comprennent la progressivité de l approche. Le coût est alors faible pour le premier projet pilote, et ne grimpe que si l avantage financier a été prouvé par les premiers projets. Il faut enfin que la Direction Générale ait prévu d évaluer les conséquences du nouveau Modèle : les indicateurs définis au moment de la décision doivent être contrôlés progressivement aussi bien sur le plan financier que sur le plan qualitatif. 5.6 Se réapproprier la modélisation du métier Ces dernières années, les rôles ont évolué dans les projets : l expression des besoins métier ou la gestion de projet ont été définies comme des fonctions nobles, alors que la fabrication de logiciels est progressivement devenue une fonction mineure que l on peut externaliser, comme on le fait pour l entretien des locaux. On oublie que c est le logiciel qui s exécute et non le cahier des charges : c est même souvent le logiciel qui est le réceptacle du Modèle de l Entreprise tout simplement parce qu il est mis à jour, alors que la documentation n a pas suivi. La perte de connaissance de leur Modèle, et en particulier de leur logiciel, a des conséquences graves pour les compagnies : elles deviennent incapables de décider des compromis entre souhaits fonctionnels et possibilités techniques, parce qu elles ne savent plus évaluer les possibilités et les coûts des évolutions. Elles finissent par devenir dépendantes de fournisseurs à qui elles ont délégué l essentiel : l évolution de leur Modèle. Les Compagnies doivent se réapproprier la connaissance de leur Modèle, même si elles sous-traitent en partie son évolution. Pour cela, il faut redéfinir des rôles d architectes qui ne sont pas les esclaves de ceux qui expriment des besoins, mais leurs partenaires avec qui ils décident des évolutions. 37 Comment y parvenir?
5.7 Quelles Solutions doivent utiliser la Fondation? Les Solutions de gestion des ressources ou de pilotage peuvent être indépendantes de la Fondation : elles ont surtout besoin d Interopérer avec les autres Solutions. Par contre, les Solutions cœur de métier (gestion des clients, des contrats et des sinistres) doivent progressivement utiliser la Fondation commune. C est grâce à cette Fondation que la compagnie atteindra l agilité souhaitée ou la standardisation d usage. C est grâce à cette Fondation que l on pourra beaucoup plus aisément construire des offres mixtes, que l on pourra mettre en place une véritable approche client et que l on atteindra la bonne souplesse d organisation. Comme décrit ci-dessus, une Compagnie peut aussi envisager d utiliser une Fondation distincte par ligne produit parce que les fournisseurs de progiciel ne couvrent qu une partie du périmètre produit : une Fondation pour l IARD, une Fondation pour la vie Individuelle et une Fondation pour les Collectives. Chaque fois qu une décision est prise de choisir une Solution qui importe une nouvelle Fondation, il faut en décrire les conséquences. A titre d exemple : Si on choisit une Solution IARD différente par pays o coûts plus élevés que ce soit pour la Transformation ou les Opérations o difficulté à transférer les bons produits d un pays à l autre o difficulté à transférer les bonnes pratiques d un pays à l autre o difficulté à offrir des contrats et des prestations exécutables sur plusieurs pays pour le même client o difficulté à concentrer les données de pilotage Si on choisit une Solution pour la gestion de sinistre qui n a pas la même Fondation que pour la gestion de contrats o coûts plus élevés que ce soit pour la Transformation ou les Opérations o nécessité de construire des interfaces entre solutions : les sinistres doivent accéder aux clients, aux contrats o conception de produit scindée en 2 parties : ceux qui décrivent les règles contrat et ceux qui décrivent les règles sinistres o synchronisation plus complexe lors des mises à jour des Solutions o processus discontinus lorsqu un sinistre (comme un décès) nécessite la mise à jour des contrats o opérations informatiques spécifiques à chaque solution o effort de cohérence entre des données de pilotage provenant de Solutions conçues indépendamment Si on choisit une Solution CRM indépendante des Solutions contrats et sinistres o coûts plus élevés que ce soit pour la Transformation ou les Opérations o usages différents pour tous les acteurs qui doivent utiliser les 2 : les clients, les distributeurs, les unités décentralisées, les centres d appel o duplication d information sur les clients et les contrats o discontinuité dans la chaine de gestion du contrat : proposition, souscription, facturation, avenants ; on fige la séparation des rôles commerciaux et administratifs o opérations informatiques spécifiques à chaque solution o effort de cohérence entre des données de pilotage provenant de Solutions conçues indépendamment 38 Comment y parvenir?
5.8 Comment choisir une Solution externe? Chaque fois que possible, l assureur doit choisir d implémenter les nouvelles fonctionnalités sur sa Fondation : c est ce qui lui garantit la simplicité, l agilité et l harmonisation des usages. Si cette option n est pas possible, il faut choisir un Progiciel indépendant : quels en sont les critères de choix? Un choix de progiciel est généralement fait sur la base des fonctionnalités disponibles que l on compare aux besoins actuels. Mais des besoins nouveaux apparaissent sitôt le cahier des charges finalisé. Le critère de choix majeur d un progiciel doit donc être sa capacité à évoluer : s il manque des fonctionnalités, elles seront aisées à ajouter. Le deuxième critère est sa capacité de personnalisation : comme expliqué ci-dessus, un maximum de personnalisation doit être exécuté par configuration. Enfin le dernier critère est sa capacité à s interfacer avec les autres Solutions en place ce qui suppose qu il puisse accéder à des informations ou des fonctions offertes par les autres Solutions, et qu il puisse leur offrir l accès à ses propres fonctions ou informations. Pour juger de la capacité d un progiciel à évoluer, il faut en comprendre l architecture, ce qui suppose que le fournisseur accepte de la communiquer : on peut rajouter des fonctions compatibles avec une architecture existante, mais on ne peut modifier profondément une architecture. Comme les progiciels sont construits généralement à partir d une première expérience client et que les clients ont, par le passé, recherché des Solutions indépendantes, il y a encore peu d exemples de progiciels dont l architecture permette une couverture totale. Mais la pression des clients pour avoir des solutions globales fait progressivement apparaitre de nouvelles solutions plus complètes, comme SAP l a progressivement fait pour l industrie. 5.9 Progressivité La définition d une cible ambitieuse n est pas incompatible avec la progressivité de l implémentation. Il est recommandé de se rapprocher progressivement de la cible par incréments successifs. C est un processus itératif et progressif qui offre de la valeur aux utilisateurs à chaque étape. Un exemple de trajectoire est le suivant : On choisit une Solution pourvue d une Fondation puissante qui permet un périmètre large. On commence par utiliser la Solution pour un périmètre limité : par exemple, pour une ligne produit, et un domaine de processus (par exemple la gestion de contrats IARD) pour des produits nouveaux, pour un seul réseau de distribution, dans un seul pays. Il faut interfacer cette première version aux Solutions existantes. Puis on ajoute les produits anciens, ce qui nécessite de reprendre l historique et de migrer les informations. Puis on étend progressivement la Solution ligne produit par ligne produit, domaine de processus par domaine de processus, réseau de distribution par réseau de distribution, pays par pays, ce qui permet de basculer progressivement les Solutions éclatées vers la Solution cohérente. Par exemple : o ajouter la gestion de sinistre IARD o ajouter une autre ligne métier ; par exemple la prévoyance o élargir la Solution à un autre réseau de distribution Puis y ajouter le CRM Les adjonctions fonctionnelles peuvent être fournies par l Editeur de logiciels ou par le client ou par une association des deux. L important est que la Solution cohérente s appuie sur la même Fondation. 39 Comment y parvenir?
5.10 Quelles ressources humaines et comment les organiser? On distingue l organisation des Opérations, ceux qui exploitent la Solution, et l organisation de la Transformation, ceux qui sont en charge des projets. 5.10.1 Organisation des Opérations Comme défini ci-dessus, la durée de vie des logiciels est beaucoup plus longue que la durée de vie des organisations. Une même Solution devrait donc être capable de supporter des organisations différentes dans le temps : par exemple, passer d une organisation par réseau de distribution à une organisation par ligne produit (ou l inverse) ; Une même Solution devrait aussi être capable de supporter plusieurs organisations à un même moment : c est le cas des groupes multi-entreprises ou des groupes internationaux. Pour supporter des organisations différentes, la Solution doit bien séparer le «Quoi», c'est-à-dire les fonctions invariantes de l assurance (tarifer, connaitre le client, contrôler l éligibilité ) du «Quand», «Qui», c'est-à-dire de l affectation des tâches aux acteurs. Il faut en outre que la Solution possède une Fondation suffisamment puissante pour une gestion cohérente des droits et des devoirs de chaque acteur et pour garantir un usage cohérent pour toutes les fonctions, ce qui facilitera les changements de rôles. 5.10.2 Equipes de Transformation Si la Solution offre un large périmètre de fonctions bâties sur la même Fondation, on aboutit à créer autant d équipes Projet qu il existe de paquets de fonctions à livrer. Un projet doit n avoir qu un responsable qui coordonne à la fois les compétences métier et informatiques : il ne doit pas y avoir antagonisme entre le métier qui exprime son besoin et l informatique qui essaie de le satisfaire, mais plutôt un partenariat solidaire pour réussir ensemble le difficile compromis entre espoirs fonctionnels et possibilités techniques. Leur objectif n est pas de se protéger pour faire porter à l autre la responsabilité des difficultés, mais de construire rapidement une première version de fonctions utiles aux acteurs opérationnels. Le chef de projet doit être capable non seulement de gérer le projet mais aussi de comprendre l architecture de la Solution qu il met en place pour décider rapidement des bons compromis en cours de projet, sans avoir besoin de réunir des comités trop fréquents qui diluent les responsabilités. Pour que cette somme de projets différents aboutissent à une Solution bien construite, il faut en outre une équipe Fondation qui, non seulement fait évoluer la Fondation, mais qui la supporte auprès de ses «clients», les équipes Projet. Elle inclut des experts métier qui définissent les invariants de l assurance (le langage de l assureur, les processus communs, les normes ergonomiques, les règles de sécurité, les informations partagées, ) et des experts informatiques. Si l Entreprise a l intention d aboutir à une seule Solution bâtie sur une seule Fondation, qui couvre tous les besoins, l équipe Fondation est rattachée à la direction de la Transformation, si elle existe, ou à la direction générale si elle n existe pas. 40 Comment y parvenir?
5.10.3 D excellentes compétences métier dans la Transformation Tant que l assurance Opérait avec un Modèle stable, les Opérations étaient le véritable centre de pouvoir et ce d autant plus que ce sont les Opérations qui génèrent le revenu et qui ont les plus gros effectifs. Mais le rythme du changement s accélérant, les assureurs réalisent que la plus grande difficulté réside aujourd hui dans la Transformation : pour caricaturer, il est plus difficile de gérer un projet (la Transformation) que de gérer un sinistre (les Opérations). Il faut donc valoriser davantage la Transformation si l on souhaite que les meilleurs talents métier s orientent non vers l Opérationnel, mais vers les projets de Transformation dont l assureur a tant besoin : on doit pouvoir devenir Directeur Général parce que l on a su mener à bien des projets de Transformation, et pas seulement parce que l on a su bien gérer les Opérations. On peut juger de la volonté d un assureur à évoluer non pas sur ses déclarations, mais au nombre de professionnels de talents qu il détourne des Opérations pour les orienter vers la Transformation. Les assureurs qui gagneront à terme ne sont pas forcément ceux qui ont les meilleures idées, mais ceux qui ont la capacité à mettre en place rapidement les bonnes idées des autres : la clé du succès est dans la Transformation. 5.11 Comment initier la démarche? Si vous terminez la lecture de ce document en vous interrogeant sur la manière de mettre en œuvre concrètement ces quelques idées, nous vous recommandons de réunir les responsables des parties prenantes (marketing, ressources humaines, opérations, informatique..) pour répondre ensemble à la questionclé : «pouvons nous faire face aux défis de l assurance dans les 5 ans avec le Modèle d Entreprise en place». Comme la majorité pense généralement que tout va bien, que peu ont le temps de réfléchir au moyen terme et que l on dispose de peu d informations sur les Transformations en cours dans les autres secteurs économiques, il serait utile qu un intervenant extérieur vienne présenter ce qui se passe ailleurs. A titre d exemple : les transformations importantes d autres secteurs économiques, comme le secteur des télécoms qui a été bouleversé depuis 10 ans ; pourquoi la banque a réussi dans l assurance et pas l inverse ; les innovations de l assurance dans d autres pays. Puis organiser des séances de réflexion internes sur l adéquation des modèles et des ressources, et décider si l Entreprise a ou non besoin d un bond en avant. Si la réponse est négative, il faut poursuivre les évolutions continues sur la base du Modèle existant : aucun bouleversement n est nécessaire. Si la réponse est positive il faut organiser une «task-force» dont le premier livrable doit être un Modèle d Entreprise cible à 5 ans, avec ses 3 volets : les Produits, les Opérations et la Transformation. Ce Modèle doit être explicité en adressant les questions suivantes : quelles évolutions des ressources pour en tirer parti? quelles grandes étapes permettent d atteindre des résultats concrets dès la première année? quel bilan financier et immatériel? quelles conditions du succès : gouvernance (porté par DG/Actionnaires), équipe? 41 Comment y parvenir?
afin de fournir à la Direction Générale l ensemble des éléments qui lui permettront de décider ou non de ce «bond en avant». Le processus réel est bien loin d une démarche cartésienne : il doit passer par l'éveil, puis la compréhension, puis l'assimilation, puis l'adhésion et enfin l'action. Un document comme celui-ci est notoirement insuffisant, il faut du concret que ce soit des études de cas ou des prototypes. On ne peut attendre de convaincre tout le monde. Au minimum, il faut convaincre : le top management pour obtenir les moyens, la gouvernance les équipes de Transformation pilote pour qu ils mettent en œuvre les premiers projets pilote La majorité des autres équipes de Transformation seront convaincues si elles constatent le succès des premières. Les Opérationnels seront convaincus après le déploiement de la nouvelle Solution, si elle leur apporte plus de confort et d efficacité. 42 Comment y parvenir?
6 Annexe : le Modèle d Entreprise et quelques termes associés Le CEISAR a défini un langage de la Transformation que nous avons utilisé dans ce document et que nous résumons dans cette annexe. Une Entreprise est un ensemble de Ressources appliquant un Modèle d Entreprise pour atteindre un but commun. On sait aisément identifier les Ressources : acteurs-humains (qu ils soient des employés ou des partenaires ou des clients), acteurs-ordinateurs, information, ressource financière, locaux Mais il est beaucoup plus difficile de définir ce qu est un Modèle d Entreprise. Comme l objet de ce document est de proposer des pistes pour un futur Modèle d Entreprise, nous devons donc commencer par définir avec précision ce qu est un Modèle d Entreprise. Ce schéma nous permet de résumer les quelques termes qui sont utilisés tout au long de ce document : Opération, Transformation, Modèle, Solution, Fondation. Produits et Clients : Comme toute Entreprise, un Assureur a pour objectif de délivrer des produits à ses clients. Chaque produit délivré fait référence à son Modèle produit qui décrit la décomposition en garanties, les indemnités à verser ou les services à rendre en cas de sinistre, le segment de clientèle, le territoire, et le prix. Les Opérations : Pour délivrer ses produits, l Assureur doit Opérer c'est-à-dire distribuer ses produits, produire ses prestations, gérer ses ressources et piloter l entreprise à tous les niveaux. Ces différents processus sont exécutés par des ressources Opérationnelles : les acteurs-humains et les acteurs-ordinateurs. Le Modèle d Opération : 43 Annexe : le Modèle d Entreprise et quelques termes associés
Lorsque les Opérations se complexifient, on ne peut s appuyer uniquement sur l expérience des différents acteurs opérationnels, on doit prendre le temps de formaliser comment bien Opérer : le Modèle d Opération décrit les Modèles de processus que ces acteurs vont exécuter, sous forme de procédures pour les acteurshumains ou de logiciels pour les acteurs-ordinateurs: comment bien vendre, comment bien gérer un sinistre ou un avenant Ces Modèles de processus sont complétés par le Modèle d information de l entreprise (quelles informations sur chaque client, quelles données de reporting, quelles informations sur le personnel ) et les rôles de chacun (quels sont les droits et devoirs des agents, des administratifs, des responsables sinistres). Les Solutions : Les différents Modèles de processus sont regroupés dans des Solutions (Solution CRM, Solution comptable, Solution sinistre IARD ). Il s agit du logiciel, mais aussi des procédures humaines nécessaires aux processus. L ensemble constitué par les Solutions représente le Modèle d Opération de l Assureur. La Transformation : Sous la pression de l environnement ou de sa propre ambition, l assureur doit faire évoluer son Modèle c'est-àdire modifier le Modèle Produit, les Solutions, les Fondations : la modification du Modèle et le déploiement de ce nouveau Modèle auprès des Acteurs Opérationnels, n est pas du ressort des Opérations mais de la Transformation. Les Acteurs de la Transformation ne sont pas des distributeurs ou des administratifs, mais des stratèges, des concepteurs produit, des chefs de projets, des architectes, des maitrises d ouvrage ou des développeurs informatiques. Il existe donc 2 grands métiers dans l assurance : ceux qui Opèrent et ceux qui Transforment. Le Modèle de Transformation : Pour bien Transformer ils ont besoin de s appuyer sur un Modèle de Transformation qui inclut la méthodologie, les outils (pour aider à spécifier, développer, tester ) et les composants qui aident à assembler de nouvelles Solutions. Le Modèle d Entreprise (en rouge ci-dessus) est finalement la somme de Modèle Produit + Modèle d Opération + Modèle de Transformation. Note : on pourrait y ajouter l Image de l Entreprise (vision externe) ou la Culture de l Entreprise (vision interne) qui sont la partie non formalisable du Modèle d Entreprise mais qui ne sont pas pris en compte dans ce document. La Fondation : Nous utiliserons deux derniers termes : Fondation d échange et Fondation de Solution. Les Solutions peuvent interopérer entre elles grâce à une Fondation d échange qui définit la plateforme de communication et les formats de message échangés : à titre d exemple comment envoyer des informations à la Solution Comptable? quelles informations envoyer à la Solution de pilotage? comment la Solution sinistre peut-elle demander des informations à la Solution gestion des Contrats? La Fondation de Solution regroupe les éléments communs aux différents processus au sein de chaque Solution : interface utilisateur cohérente, Modèle d information cohérent, fonctions de sécurité, de workflow, de gestion de corbeille, de calcul de tarif 44 Annexe : le Modèle d Entreprise et quelques termes associés
Cette décomposition, qui peut paraitre abstraite, permet de mieux comprendre et analyser l Entreprise. Par exemple il permet d identifier que la Stratégie d Entreprise porte sur 3 niveaux : la Stratégie Produit définit les nouveaux Produits, les nouveaux Territoires, les nouveaux segments de clientèle la Stratégie d Opération définit la chaine de valeur, les partenaires, les processus, les rôles la Stratégie de Transformation définit comment gagner en agilité, et en «time to market». Si vous avez accès à la définition de la stratégie de votre entreprise, essayez de rapprocher son contenu de ces 3 domaines stratégiques : vous réaliserez le plus souvent qu il existe bien une Stratégie Produit et une Stratégie d Opération, mais que la Stratégie de Transformation est absente : on n identifie que très rarement qu il faut aussi investir pour améliorer le Modèle de Transformation et gagner en agilité. 45 Annexe : le Modèle d Entreprise et quelques termes associés
7 Questions/Réponses Nous avons regroupé les questions que nous ont posées les relecteurs de ce document et les réponses associées. Question sur le BPO : Le développement du BPO : des sociétés comme AIS ou Packsolution deviennent à la fois des partenaires et des concurrents des compagnies en s'appropriant progressivement leur marge de gestion (sur le runoff ou les gros portefeuilles de produits standards). Comment faire rentrer cette tendance dans le modèle d entreprise? Réponse Si le sous-traitant utilise le Modèle de l assureur, il ne s agit que d un problème de déploiement : le BPO n a alors de sens que parce que le partenaire a une meilleure productivité que les équipes de l assureur. Si le sous-traitant utilise son propre Modèle, il va falloir gérer les échanges comme on le fait entre 2 Solutions distinctes du Modèle interne de l entreprise. Mais la problématique est la même. Pour définir le modèle d échange, il est alors utile de rechercher s il existe des standards comme «EDI Courtage», la plateforme d échange entre courtiers et assureurs qui représente un nouveau Modèle commun. Question sur le rythme de déploiement de la Cible J'ai du mal à croire et au scénario du big bang (pose one shot des fondations) et au scénario des petits pas (incrémentation de la cible projet par projet). Le premier parce que la temporalité d'une DG est incompatible avec celle d'un tel projet. Et ce, durablement... Le deuxième parce que l'étirement d'un projet de transformation dans le temps conduit immanquablement à sa dilution et à son enlisement, tous les acteurs historiques portant la vision initiale quittant progressivement le navire. Réponse Il est clair que l on ne peut utiliser le scenario du «big bang» que dans les petites structures. Chez les grands assureurs, l approche sera forcément progressive. Il faut néanmoins que le sponsor du projet reste suffisamment longtemps pour que le nouveau Modèle soit en place sur un domaine suffisamment important. Il doit aussi être reconnu par les Opérationnels comme plus efficace que le précédent. La démarche devient alors irréversible parce que l Entreprise s est appropriée la démarche : les acteurs peuvent alors changer de poste progressivement. Pour accélérer cette phase d initialisation et d appropriation, s appuyer sur une Fondation efficace déjà existante, et une équipe commando qui concentre toutes les ressources métier et informatique nécessaires à la réussite des premiers projets. Les membres de l équipe commando seront dispersés dans la structure une fois la première phase réussie. Question sur la justification économique Il est extrêmement difficile d'établir un «Business case» sur un tel projet vu son ambition et sa durée. Il sera donc très difficile de se faire un allié de la Direction Financière dans une telle aventure. Nous sommes quelque part dans un projet qui demande un peu de "folie" et de "passion" partagée par un noyau dur, autour de la DG, car ce projet ne sera jamais complètement réductible à des chiffres de retours sur investissements ; Réponse Effectivement, une grande partie des bénéfices de l approche proposée tient à la simplification du Modèle, à un meilleur time to market, une meilleure synergie interne qui sont tous difficiles à quantifier financièrement. Heureusement il existe par ailleurs des justifications économiques qui portent essentiellement sur les gains de productivité dans les Opérations et sur la réduction des dépenses de Transformation. Il faut donc qu un responsable de Direction Générale supporte le projet parce qu il en a compris la valeur et qu il est prêt à en prendre le risque. Une fois la phase pilote passée, les fonctions offertes par le nouveau Modèle convaincront l essentiel de la population opérationnelle. On entre alors dans une phase d évolution continue où on ne se pose plus la question de la pertinence de l approche : le plus difficile est au début. Question sur le rattachement de l équipe Fondation 46 Questions/Réponses
La préconisation qui consiste à rattacher l'équipe Fondation à la DG est claire et marque l'aboutissement logique du raisonnement déroulé. Maintenant, si cette proposition est intellectuellement convaincante, combien de DG ont ou peuvent acquérir cette "intelligence de la situation" qui permettrait concrètement de remporter la conviction selon laquelle un tel ancrage est une nécessité? Réponse L équipe Fondation comprend des informaticiens et des compétences métier pour identifier les informations, processus, fonctions communs aux différents métiers. Si le Modèle cible est une Solution bâtie sur une Fondation, il va bien falloir un responsable unique de cette Fondation qui ne dépende pas d un seul des métiers. Il faut donc logiquement la rattacher à la Direction Générale. Si la démarche est défendue non par la DG, mais par un sponsor métier, il faut rattacher l équipe Fondation au sponsor motivé. Encore une fois, il vaut mieux dans un 1er temps se contenter d une équipe-commando provisoire qui sera éclatée dans la bonne structure une fois le processus devenu irréversible. Question sur comment initier la démarche Le dernier chapitre "comment initier la démarche" me semble devoir être un peu plus développé. Nous voyons aujourd hui que le processus réel est bien loin d une démarche cartésienne : il doit passer par l'éveil, puis la compréhension, puis l'assimilation, puis l'adhésion et enfin l'action. Tout le sujet est comment économiser à court terme tout en bâtissant un système futur qui me permet de garantir que l économie perdurera. Réponse Nous n avons fait qu esquisser cette démarche dans ce document. Détailler la démarche nécessiterait un autre document. Pour résumer la démarche : poser la question «mon modèle actuel me permet-il de faire face aux évolutions à venir dans les 5 ans» ; si la réponse est «non», il faut définir une cible ambitieuse identifier qui est le sponsor qui doit fournir budget et support continu créer une équipe commando qui doit réussir les 1ers projets pilote généraliser progressivement par la suite Question sur la bancassurance En début de document, j ai eu l impression que la suite concernerait essentiellement les assureurs classiques. Après avoir tout lu, ce n est pas le cas et heureusement car les bancassureurs ont exactement la même problématique. Je pense même que la situation est encore plus complexe chez un bancassureur qui doit également s intégrer dans un système bancaire global, ne serait-ce que pour la distribution de ses produits. Cette intégration est parfois légère (épargne) ou très lourde (prévoyance, auto, MRH). En effet, on vend plus facilement une assurance des emprunteurs ou une MRH avec un crédit immobilier, alors qu un contrat d épargne n est que rarement lié à la vente d un autre produit bancaire. Le modèle d entreprise du bancassureur est dépendant du modèle d entreprise du banquier généralement plus gros que lui, donc la Fondation Assurance est liée à ce qui pourrait être la Fondation Banque. Réponse Le réseau de détail d une banque est un des distributeurs essentiels de l activité assurance. Il faut décider si le réseau bancaire utilise son Modèle de réseau bancaire ou celui de l assureur. Dans le premier cas il faut offrir aux acteurs de la Transformation du réseau bancaire, les Services-logiciels qui leur permettent de tarifer, contrôler, enregistrer On se trouve dans le cas où 2 Modèles doivent coexister au mieux. Dans le 2 cas, l assureur doit offrir la Solution assurance au réseau : c est en général une Solution internet. On peut alors adapter l interface utilisateur pour qu elle ressemble à celle utilisée normalement par le réseau bancaire pour ses opérations bancaires. Question sur le Modèle de Distribution Le modèle de distribution n est pas évoqué en tant que tel (notamment par rapport à tous les apporteurs d affaire extérieurs à la compagnie captif ou non). Réponse 47 Questions/Réponses
Pour récapituler, si un assureur souhaite coopérer avec différents réseaux de distribution il a le choix entre les scenarios suivants : le Distributeur extérieur conserve son Modèle : il échange de façon asynchrone avec le Modèle de l assureur ; Dans ce cas o les 2 Modèles doivent être modifiés et synchronisés à chaque mise à jour des produits, des tarifs ou des conditions o les données doivent être dupliquées et synchronisées dans les 2 Modèles le Distributeur extérieur conserve son Modèle, mais il le modifie pour qu il puisse appeler les Services offerts par le Modèle de l assureur : pour accéder aux informations ou pour exécuter des Services. dans ce cas o un seul Modèle à modifier à chaque mise à jour de produit o synchronisation automatique o pas de duplication de données le Distributeur extérieur utilise directement le Modèle de l assureur (en général via Internet) Question sur la coopération entre partenaires Quelle est la logique de collaboration, de co-construction transverse (cas des entreprises qui se mettent à plusieurs pour construire une offre) Réponse Tout dépend de la stratégie de collaboration (voir question précédente) : si le Distributeur conserve son Modèle, il faut que o les spécifications du produit, des processus, des fichiers répliqués et des échanges soient décidés d un commun accord o chacun adapte ensuite sa Solution o les déploiement soient synchronisés à chaque mise à jour si le Distributeur utilise le Modèle de l assureur, ce n est qu un problème de déploiement du Modèle de l assureur Question sur la justification d une Fondation pour un grand projet C est une grande difficulté d introduire une Fondation dans un grand projet car cela représente un surcoût qu il faut argumenter. Réponse Pour éviter un surcout trop élevé, il faut pouvoir facturer une Fondation à l usage : le cout est alors faible pour le 1er projet pilote, et ne grimpe que si la Fondation est réutilisée par d autres projets, ce qui suppose que l avantage financier ait été prouvé par les 1ers projets. Question sur la facturation de la cible aux petites filiales Il est difficile pour un groupe avec des filiales étrangères de financer un Modèle global cible. De la même façon, il est difficile pour une filiale de taille modeste de participer au financement d une Fondation sans déstabiliser son compte d exploitation. Réponse Si l équation économique devient globalement positive, on trouvera toujours un moyen de répartir les bénéfices de la démarche entre petites et grandes filiales. Le problème est de financer le démarrage : encore une fois, le problème ne se pose vraiment que si on choisit de fabriquer sa propre Fondation ; le financement sera plus simple si l on acquiert une Fondation à l extérieur. Question sur les inconvénients du progiciel On ne voit pas clairement les inconvénients d un progiciel comme, par exemple, les métiers doivent s adapter au SI et non l inverse ou encore les coûts (formation, maintenance, etc.). Réponse Ce livre blanc traite de la simplification du Modèle de l assureur grâce à une Fondation commune. Le thème des progiciels n est abordé que marginalement. Le Progiciel qui pose le moins de problème est celui qui : 48 Questions/Réponses
autorise toutes formes d organisation s adapte au langage métier en place (prime/cotisation, client/adhérent/sociétaire, ) Mais il ne faut pas tordre le progiciel pour que le mode d usage soit le même que dans le système précédent ; il vaut mieux faire l effort de former les Opérationnels pour limiter la personnalisation du progiciel et sa maintenance ultérieure. Question sur les Directions des Systèmes d information Les départements SI des assureurs sont si dépassés que décrit dans ce document? Réponse Notre intention n est pas de critiquer les directions informatiques en place, mais de les aider à faire passer quelques messages auprès des responsables métiers. Le message essentiel est plutôt : «la gouvernance en place impose de choisir au coup par coup des solutions distinctes, ce qui complexifie l ensemble» : nous incriminons le système, pas les individus. Nous espérons au contraire donner des armes aux DSI pour que l on arrête de choisir des Solutions disparates. Question sur la politique des Editeurs de logiciel Une première façon de faire pour respecter vos préconisations reste le développement interne, mais il n est pas à la mode, nos DSI ne le préconisent pas et nous n avons pas toujours le temps. Une autre pourrait être de trouver une solution externe, de l acquérir et de la faire évoluer en interne. Mais nous sommes bien placés pour savoir que quel que soit l auteur de cette solution, éditeur ou autre, la reprise de compétences est très difficile. Le modèle n existe pas d éditeurs qui développent pour vendre et laisser les clients prendre en charge les évolutions, et donc qui les forment et leur fournissent une documentation adaptée. Réponse Les assureurs, comme les autres, font de plus en plus appel à des progiciels aux dépens des développements internes. La question posée est intéressante : si un éditeur accepte de fournir non seulement son progiciel, mais aussi la Fondation associée, différents scenarios sont possibles : la Fondation est maintenue par l éditeur : l assureur développe des fonctions complémentaires à celles disponibles dans le progiciel la Fondation est maintenue par l assureur qui s en sert comme point de départ puis diverge ; il doit alors maintenir aussi toutes les fonctions construites à partir de la Fondation. Le 1er scenario est le plus viable parce qu il permet de ne pas payer 2 fois la maintenance de la Fondation. L assureur peut concentrer son énergie sur les Fonctionnalités qui lui donnent un avantage concurrentiel. Si l Editeur ne veut pas communiquer sur sa Fondation, alors l assureur doit avoir une confiance totale en l éditeur et en sa capacité à suivre les évolutions du métier aussi rapidement que ses concurrents. Question sur la qualité de la Fondation Que se passe t il si la Fondation choisie s avère inefficace pour satisfaire certains besoins? Réponse Il n y a rien de pire qu une Fondation inefficace que l on impose aux différents acteurs : mieux vaut encore une juxtaposition de Solutions indépendantes que l on fait coexister. Il ne faut pas non plus jeter le bébé avec l eau de bain, c'est-à-dire rejeter la Fondation au moment où elle est introduite et avant qu elle n ait fait ses preuves. Le choix de la Fondation est stratégique pour un Groupe : encore une fois, jugez sur pièces, à l aide de prototypes qui démontrent concrètement la flexibilité, le time to market, la souplesse d organisation Question sur la stratégie de rupture Il est très long et couteux de Transformer un grand assureur : il faut vaincre les conservatismes, modifier les relations avec les partenaires et les clients, basculer les contrats et sinistres d un Modèle à un autre Ne pourrait-on imaginer un scenario différent où un Groupe convaincu par cette démarche crée de toutes pièces une nouvelle compagnie d assurance qui s appuie sur un nouveau Modèle à Solution unique? 49 Questions/Réponses
Une fois prouvé le succès de cette approche, il sera beaucoup plus simple de faire basculer les compagnies existantes. Réponse Créer une nouvelle Compagnie a plusieurs avantages : pas de bascule de portefeuilles de contrats ou sinistres à gérer liberté pour imaginer de nouveaux produits multi-branches liberté pour imaginer de nouveaux processus où l essentiel des Opérations est traité par les clients ou les partenaires liberté pour tirer partie des gains de productivité : on n est pas contraint par l organisation et la culture en place liberté pour mettre en place une nouvelle gouvernance, une nouvelle approche agile, définir de nouveaux rôles et éviter la bureaucratie indicateurs de productivité, de time to market, de qualité de service plus facile à établir Les conditions du succès: disposer dès le départ d un Modèle d assurance puissant qui correspond aux caractéristiques décrites ci-dessus des ressources humaines d excellente qualité regroupant assureurs et informaticiens au sein d un commando indépendant des ressources financières consacrées au déploiement du Modèle existant Il est évident que ce type d approche apporte aux sceptiques la preuve qu un nouveau mode est réaliste. Il concentre l énergie sur l acte de création d une nouvelle forme de compagnie d assurance et non sur une Transformation lourde d un système en place. Mais il suppose l association étroite d un entrepreneur-assureur et d un entrepreneur-informatique disposant déjà d un Modèle d assurance innovant. 50 Questions/Réponses