Quel Modèle d Entreprise pour l Assurance de demain?

(1)

1 Les challenges de l’assurance |

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.

(2)

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 ».

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.

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.

(3)

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

(4)

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-you- drive » 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.

(5)

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).

(6)

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 « run- offs » (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.

(7)

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.

(8)

8 Les Solutions actuelles ne permettent pas d’évoluer rapidement |

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.

(9)

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).

(10)

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

(11)

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.

(12)

12 Commencer par Modéliser le métier de l’assurance avant de se doter d’une Solution. |

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.

(13)

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).

(14)

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…

(15)

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.

(16)

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.

(17)

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 Personne

physique

Evénements Accident Auto Dégât des eaux

Accident du travail

Consultation Opération

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

(18)

 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.

(19)

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é

(20)

o gestion du contrat : choix de l’offre, simulation, proposition, souscription, avenants au contrat, facturation, règlements o 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

(21)

21 Commencer par Modéliser le métier de l’assurance avant de se doter d’une Solution. | o gérer des avenants

o 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)

(22)

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 ?

(23)

23 Quel Modèle global cible ? |

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

(24)

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

(25)

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.

(26)

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 à

(27)

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é…