Choisir un Core Banking System?

Depuis les années 80, de nombreux progiciels sont apparus sur le marché, sous la dénomination de Core Banking Systems (CBS), promettant de traiter de manière intégrée toutes les problématiques bancaires : de la gestion de comptes à la comptabilité, en passant par le e-banking et le CRM.

Cette proposition est alléchante en première lecture. Or, toutes les banques ne sont pas comparables. Au delà des métiers, toutes les banques n’ont pas la même taille.

  • Grandes Banques (actifs > 100 milliards d’euros)
    • Nombreuses activités bancaires et de services financiers spécialisés
    • Implantations multiples aux niveaux géographiques, devises et réglementaires (architecture avec plusieurs coeurs de gestion)
    • Nombreux partenaires
    • Compétences importantes en système d’information (MOA/MOE)
    • Problématiques de fusion/acquisition
    • Besoins de pilotage global (entrepôts de données, consolidation groupe)
  • Petites et moyennes banques (actifs < 100 milliards d’euros)
    • Créations et développements d’activités
    • Centrées sur un nombre réduit d’activités (quelques coeurs de gestion)
    • Développement viral autour d’un centre de gravité (souvent le produit historique)
    • Nombre réduit d’implantations
    • Peu de partenaires
    • Peu de force de développement en système d’information

    Cette segmentation peut être réalisée à l’intérieur même d’un groupe bancaire pour caractériser ses entités (filiales, succursales, etc.).

    Ces différentes entités se trouvent également à des étapes différentes de leur développement, répondant à des objectifs stratégiques différents :

    • Entité en création : le principal objectif est ici de s’équiper rapidement en terme de SI. Dans ce cas précis, des solutions intégrées de type CBS adressent clairement ce besoin. A condition toutefois que l’innovation apportée par la création de cette entité ne réside pas dans le produit bancaire commercialisé. En acquérant un CBS, la banque acquiert une conception relativement standard de son backoffice et de la manière dont les contrats sont gérés.
    • Entité en développement : le SI, déjà existant, va nécessiter des évolutions spécifiques pour suivre la stratégie d’élargissement de l’entité. Ce développement peut prendre différentes formes : offre, implantation, clientèle. Le SI initial devra relever plusieurs défis :
      • Développement de l’offre : de nouvelles offres devront pouvoir être créées sur la base de produits existants. Il s’agit du cas le plus simple. Toutefois, l’impact sur le SI risque d’être plus profond si le développement de l’offre implique la gestion de nouveaux types de produits bancaires. Par exemple, la gestion d’un crédit amortissable est au final assez éloignée de celle d’un crédit revolving.
      • Développement des implantations : la banque va chercher à se développer dans de nouveaux pays. Le facteur limitant est ici les différences de réglementations qui amènent assez naturellement à cloner le SI en l’adaptant. La question du pilotage et de la consolidation groupe se fait immédiatement ressentir. Autant les CBS permettent de piloter leur propre activité, autant ils ne suffisent plus pour piloter l’activité des autres instances ayant des configurations locales différentes.
      • Développement de la clientèle : la banque va chercher à accroître sa clientèle par des opérations commerciales et marketing. Dans ce cas, ce sont les modules CRM et marketing des CBS qui risquent de devoir évoluer. Pour des raisons historiques, ces modules sont souvent restés en second plan dans les CBS car n’étant pas, à l’opposé de la gestion bancaire, leur coeur de métier.
    • Entité arrivée à maturité : L’objectif devient à ce stade la rationalisation et la réduction des coûts, essentiellement backoffice et support. Plusieurs stratégies sont applicables : mutualisation, externalisation ou automatisation des tâches manuelles. Les processus métiers s’industrialisent et deviennent de plus en plus éclatés. La notion même d’intégration des modules disparaît au profit d’une architecture ouverte, permettant à des applications de tout bord de communiquer. Les besoins de pilotage, contrôle et consolidation augmentent également. A ce stade, les CBS ne sont plus capables de couvrir l’ensemble du périmètre fonctionnel. Ils deviennent une brique parmi d’autres du SI.

    fig1
    fig 1. Evolution et objectifs en fonction du stade de développement des entités

    En première conclusion, la croissance naturelle des entités va structurellement remettre en question le CBS. Le CBS ne peut être qu’une réponse temporaire. Mais même si ce temporaire peut durer relativement longtemps, l’équation économique n’est pas forcément négative à condition que les limites du CBS soient maîtrisées.

    Les CBS ne sont pas identiques entre eux en terme de couverture fonctionnelle et de capacité à adopter les nouvelles technologies.
    fig2
    fig2. Le paysage des Core Banking Systems

    • Les « Tortues » : Ce sont des acteurs qui ont su investir une niche peu concurrentielle, qui ne remet pas en cause le périmètre de leur solution. Leurs clients sont également des acteurs qui évoluent peu de par leur positionnement.
    • Les « Lièvres » : Ce sont des innovateurs souvent positionnés sur des marchés de niche. Pour se maintenir dans le temps, ils rechercheront des partenariats afin d’étendre leur marché.
    • Les « Eléphants » : Ce sont des éditeurs ayant su faire évoluer leur Core Banking System en y ajoutant des fonctionnalités pour répondre aux demandes de leurs clients. Ils sont cependant limités par leurs choix architecturaux, reposant souvent sur des technologies anciennes. Même si ils investissent sur des connecteurs modernes, les fondamentaux fonctionnels et techniques restent les mêmes. Ils sont les acteurs de référence pour les activités bancaires très matures et devenues standards.
    • Les « Baleines » : Ces acteurs sont d’abord de très grands éditeurs de solutions intégrées de type ERP souhaitant maintenant se positionner sur des offres de CBS, soit via un partenariat avec des spécialistes (SAP en partenariat avec Misys, Callatay & Wouters), soit en introduisant leur nouvelle solution propriétaire (Oracle via Global Financial Services précédemment iFlex). Ils bénéficient avant tout d’une puissance de développement logiciel importante.

    Le marché des CBS en France est aujourd’hui essentiellement occupé par des « Éléphants ». Cependant, on annonce depuis longtemps la montée en puissance des « Baleines », mais sans rien observer de comparable avec le marché des ERPs. Ces grands éditeurs se heurtent à des problèmes de taille liés au secteur bancaire :

    • les spécificités réglementaires locales, qui imposent des configurations très différentes, ne permettent pas de capitaliser les développements à l’échelle mondiale
    • la complexité des métiers bancaires qui nécessitent des investissements très importants pour concurrencer ce qui a été initié il y a plus de 20 ans dans les banques

    A ce jour, les « Baleines » sont donc cantonnées à un rôle de challenger des baronnies occupées par les vieux acteurs du secteur (les « Éléphants »).

    L’alternative, pour les banques, semble plutôt se situer dans un assemblage intelligent entre les différentes solutions disponibles sur le marché (approche best of breed), en fonction des objectifs stratégiques :
    Fig3
    fig3. Pyramide stratégique du SI

    Le choix d’un CBS soulève donc la question de sa flexibilité en terme d’offres et d’implantations, ainsi que sa capacité d’intégration au reste du SI. Dans les Requests for Information (RFI), ces critères fondamentaux sont relativement noyés par rapport aux critères purement fonctionnels et techniques. Il semble donc pertinent d’inclure dans une démarche de choix une vision dynamique du SI et non simplement des besoins et des contraintes à un instant T.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *


Ce formulaire est protégé par Google Recaptcha