Ludovic FAVARETTE
Ludovic FAVARETTE est responsable de la maîtrise d'ouvrage des projets pilotage et décisionnel chez i-BP.
Au service de 17 Banques Populaires régionales, i-BP (informatique-Banque Populaire) est née du rapprochement de 4 centres informatiques créés entre 1968 et 1988
Présente sur 8 sites (Dijon, Lyon, Perpignan, Toulouse, Nantes, Saint-Quentin, Paris et Morangis) l'entreprise i-BP rassemble plus de 1000 collaborateurs dont près de 90% sont ingénieurs et techniciens.
Après une formation en gestion, puis une spécialisation en systèmes d’information, Ludovic rejoint la SGCIB en 2000, puis en 2004 la société informatique-Banque Populaire, où il prend en charge ses premiers projets décisionnels. Chef de projet, puis responsable assistance à la maîtrise d'ouvrage, il est aujourd'hui responsable de la maitrise d’ouvrage de l'ensemble des projets de pilotage et d'aide à la décision conduits par i-BP pour le compte de ses Banques Populaires clientes.
Au service de 17 Banques Populaires régionales, i-BP (informatique-Banque Populaire) est née du rapprochement de 4 centres informatiques créés entre 1968 et 1988
Présente sur 8 sites (Dijon, Lyon, Perpignan, Toulouse, Nantes, Saint-Quentin, Paris et Morangis) l'entreprise i-BP rassemble plus de 1000 collaborateurs dont près de 90% sont ingénieurs et techniciens.
Après une formation en gestion, puis une spécialisation en systèmes d’information, Ludovic rejoint la SGCIB en 2000, puis en 2004 la société informatique-Banque Populaire, où il prend en charge ses premiers projets décisionnels. Chef de projet, puis responsable assistance à la maîtrise d'ouvrage, il est aujourd'hui responsable de la maitrise d’ouvrage de l'ensemble des projets de pilotage et d'aide à la décision conduits par i-BP pour le compte de ses Banques Populaires clientes.
Ludovic FAVARETTE : Je m’appelle Ludovic FAVARETTE, je travaille pour i-BP (Informatique Banque Populaire) et suis responsable de la maîtrise d’ouvrage. Cette présentation sera effectuée avec Rémy VAZILLE, responsable décisionnel côté BPCE. La présentation sera orientée BPCE (Banque Populaire Caisse d’Épargne). Je laisse la parole à Rémy qui présentera l’organisation du groupe et fera une introduction sur le décisionnel BPCE. Je reprendrai ensuite la main pour me concentrer sur ce qui a été développé côté i-BP.
Rémy VAZILLE : Le groupe BPCE est le fruit du rapprochement, qui a eu lieu l’année dernière, entre les Banques Populaires et les Caisses d’Épargne. Il est devenu le deuxième groupe bancaire en France avec environ 37 millions de clients. Il est intéressant de noter l’organisation assez originale du groupe. Celui-ci comporte 3 étages : un premier étage comprenant nos maisons mères (20 Banques Populaires et 17 Caisses d’Épargne), banques de plein droit ; un deuxième étage comprenant un organe central, BPCE SA ; et un dernier étage comprenant les différentes filiales du groupe, dont la plus importante et la plus connue est Natixis, mais également de grandes marques comme le Crédit Foncier, la Banque Palatine et un certain nombre d’établissements en Outre Mer et à l’international.
En termes d’organisation, un groupe décentralisé comme le nôtre suppose plusieurs formes de pratiques de pilotage. Schématiquement, l’organe central pilote la communication financière et les échanges avec le régulateur ainsi qu’un certain nombre d’analyses et de production de chiffres auprès du marché. Dans notre rôle d’animation, des éléments de benchmark, de partage de bonnes pratiques entre les établissements du groupe peuvent également être distribués. Un certain niveau de pilotage stratégique s’applique également pour l’état-major. Dans chaque établissement, chaque maison mère et chaque filiale, il existe un pilotage d’établissement très fort permettant d’avoir une vision de leurs performances.
Quel est le rôle de chacun dans cette organisation un peu complexe ? La BPCE a en charge la partie pilotage qui se trouve au-dessus. i-BP, dont Ludovic est le responsable côté décisionnel, gère le pilotage des 20 Banques Populaires ; GSE Technologies offre le même service pour les 17 Caisses d'Épargne. Comme dans tout système de pilotage, des solutions communautaires sont mises à disposition des utilisateurs. Dans chaque banque et dans chaque Caisse d'Épargne, certaines personnes font également du pilotage dans leurs propres infrastructures.
Quelques principes :
Lorsque le groupe a été créé, la tentation a été assez forte d’organiser l’accès aux données côté organe central avec des entrepôts de données par établissement en faisant un grand data warehouse groupe avec nos référentiels et nos indicateurs côté groupe pour, ensuite, monter un certain nombre de data marts et des solutions de reporting. Nos utilisateurs côté organe central auraient été très heureux, bénéficiant ainsi d’un accès à des données de détail assez massives, aux data marts et aux tableaux de bord. Cela étant, dans nos maisons mères ou nos filiales, l’utilisateur, lorsqu’il analyse ses propres données au niveau établissement, remonte consulter ce que l’on peut lui distribuer. Il s’agit d’une attitude classique. Si l’organe central aurait ainsi eu l’avantage de bénéficier d’un gros data warehouse et de données de terrain, la probabilité, pour l’utilisateur, de retrouver la même chose dans son pilotage d’établissement et son pilotage groupe aurait néanmoins été assez faible. Nous avons donc, un peu contre nature, décidé de fonctionner autrement, en faisant disparaître cette brique et en faisant redescendre nos référentiels et nos indicateurs groupe. Dans ce monde rouge et bleu, je dois mettre du violet pour proposer des choses consolidées, agréger des données dans des couches de data marts sur la base de ces indicateurs groupe. Côté organe central, l’utilisateur a la possibilité de se connecter à ces data marts. En outre, l’accès direct aux entrepôts de données des différents établissements lui est ouvert. L’utilisateur, côté établissement, a ainsi l’avantage de se retrouver avec des référentiels et des informations identiques. Au niveau du groupe, nous avons moins de stockage de données dans la mesure où nous évitons de les répliquer, ce qui s’avère intéressant au niveau de la baisse des coûts.
Nous réduisons très fortement les délais. Les problématiques de réplication de données supposent en effet qu’elles soient copiées, ce qui entraîne des rejets et un délai de plusieurs jours voire de quelques semaines. Nous déclinons tous les indicateurs groupe et référentiels en local, ce qui nous permet d’avoir une seule vérité des données, donc une continuité d’analyse entre le pilotage au niveau groupe et le pilotage au niveau de chaque établissement. A un indicateur correspond toujours un même chiffre, que ce soit au niveau du total du groupe ou au niveau de l’agence bancaire directement. La satisfaction des utilisateurs est évidemment plus importante.
Je passe la main à Ludovic qui parlera de l’expérience Banque Populaire, de la constitution de cet entrepôt de données multi-entités au niveau de la banque.
Rémy VAZILLE : Le groupe BPCE est le fruit du rapprochement, qui a eu lieu l’année dernière, entre les Banques Populaires et les Caisses d’Épargne. Il est devenu le deuxième groupe bancaire en France avec environ 37 millions de clients. Il est intéressant de noter l’organisation assez originale du groupe. Celui-ci comporte 3 étages : un premier étage comprenant nos maisons mères (20 Banques Populaires et 17 Caisses d’Épargne), banques de plein droit ; un deuxième étage comprenant un organe central, BPCE SA ; et un dernier étage comprenant les différentes filiales du groupe, dont la plus importante et la plus connue est Natixis, mais également de grandes marques comme le Crédit Foncier, la Banque Palatine et un certain nombre d’établissements en Outre Mer et à l’international.
En termes d’organisation, un groupe décentralisé comme le nôtre suppose plusieurs formes de pratiques de pilotage. Schématiquement, l’organe central pilote la communication financière et les échanges avec le régulateur ainsi qu’un certain nombre d’analyses et de production de chiffres auprès du marché. Dans notre rôle d’animation, des éléments de benchmark, de partage de bonnes pratiques entre les établissements du groupe peuvent également être distribués. Un certain niveau de pilotage stratégique s’applique également pour l’état-major. Dans chaque établissement, chaque maison mère et chaque filiale, il existe un pilotage d’établissement très fort permettant d’avoir une vision de leurs performances.
Quel est le rôle de chacun dans cette organisation un peu complexe ? La BPCE a en charge la partie pilotage qui se trouve au-dessus. i-BP, dont Ludovic est le responsable côté décisionnel, gère le pilotage des 20 Banques Populaires ; GSE Technologies offre le même service pour les 17 Caisses d'Épargne. Comme dans tout système de pilotage, des solutions communautaires sont mises à disposition des utilisateurs. Dans chaque banque et dans chaque Caisse d'Épargne, certaines personnes font également du pilotage dans leurs propres infrastructures.
Quelques principes :
Lorsque le groupe a été créé, la tentation a été assez forte d’organiser l’accès aux données côté organe central avec des entrepôts de données par établissement en faisant un grand data warehouse groupe avec nos référentiels et nos indicateurs côté groupe pour, ensuite, monter un certain nombre de data marts et des solutions de reporting. Nos utilisateurs côté organe central auraient été très heureux, bénéficiant ainsi d’un accès à des données de détail assez massives, aux data marts et aux tableaux de bord. Cela étant, dans nos maisons mères ou nos filiales, l’utilisateur, lorsqu’il analyse ses propres données au niveau établissement, remonte consulter ce que l’on peut lui distribuer. Il s’agit d’une attitude classique. Si l’organe central aurait ainsi eu l’avantage de bénéficier d’un gros data warehouse et de données de terrain, la probabilité, pour l’utilisateur, de retrouver la même chose dans son pilotage d’établissement et son pilotage groupe aurait néanmoins été assez faible. Nous avons donc, un peu contre nature, décidé de fonctionner autrement, en faisant disparaître cette brique et en faisant redescendre nos référentiels et nos indicateurs groupe. Dans ce monde rouge et bleu, je dois mettre du violet pour proposer des choses consolidées, agréger des données dans des couches de data marts sur la base de ces indicateurs groupe. Côté organe central, l’utilisateur a la possibilité de se connecter à ces data marts. En outre, l’accès direct aux entrepôts de données des différents établissements lui est ouvert. L’utilisateur, côté établissement, a ainsi l’avantage de se retrouver avec des référentiels et des informations identiques. Au niveau du groupe, nous avons moins de stockage de données dans la mesure où nous évitons de les répliquer, ce qui s’avère intéressant au niveau de la baisse des coûts.
Nous réduisons très fortement les délais. Les problématiques de réplication de données supposent en effet qu’elles soient copiées, ce qui entraîne des rejets et un délai de plusieurs jours voire de quelques semaines. Nous déclinons tous les indicateurs groupe et référentiels en local, ce qui nous permet d’avoir une seule vérité des données, donc une continuité d’analyse entre le pilotage au niveau groupe et le pilotage au niveau de chaque établissement. A un indicateur correspond toujours un même chiffre, que ce soit au niveau du total du groupe ou au niveau de l’agence bancaire directement. La satisfaction des utilisateurs est évidemment plus importante.
Je passe la main à Ludovic qui parlera de l’expérience Banque Populaire, de la constitution de cet entrepôt de données multi-entités au niveau de la banque.
Ludovic FAVARETTE : Cet entrepôt de données a été développé sur la technologie Teradata. J’essaierai, dans un premier temps, de vous exposer la logique de la Banque Populaire avec 20 clients, 21 désormais. i-BP met à disposition de ceux-ci un data warehouse unique ayant la même structure que le data warehouse dupliqué 21 fois, et contenant des données propres à chacune des banques régionales. Notre système décisionnel porte également toute la partie CRM qui, en termes d’accès aux données, s’appuie sur un accès logique aux données du data warehouse. Chaque banque a la possibilité de développer ce que l’on appelle des « privatifs » (modélisation de données propres). Il s’agit soit de l’accès à de la donnée externe que la banque vient intégrer dans son environnement décisionnel, soit de la remodélisation des données présentes dans le data warehouse visant à faciliter l’accès aux utilisateurs métiers. Les privatifs sont représentés au moyen de modélisations différentes. En effet, par nature, chaque banque fait ce qu’elle souhaite. Il n’y a donc pas de possibilité d’union entre les différents privatifs des banques. L’intérêt fort qui a pu être mis en œuvre grâce à Teradata est la partie fusion de l’ensemble des 21 data warehouse présents dans les couloirs de production des banques, grâce à la création de ce que l’on appelle des « vues logiques », qui permettent d’avoir accès, côté groupe ou i-BP, à une vision consolidée des données de l’ensemble des banques. Nous avons 21 établissements, avec des data warehouse structurés de la même façon. Au niveau du groupe, il est possible d’accéder à une vision consolidée des données des 21 banques. Par exemple, si 21 structures de table contiennent des référentiels prêts pour chacune des banques, l’on retrouvera, au niveau groupe, avec un identifiant banque, les données des 21 banques. Si cela peut paraître assez simple, il s’agit, pour nous, de quelque chose de stratégiquement intéressant. Comme l’a dit Rémy, avant d’avoir cette vision groupe consolidée de façon logique, nous étions obligés de transférer les données et de générer beaucoup d’activité en termes de surveillance, de volume, de délai. Désormais, grâce à la mise en place de ces vues logiques, lorsque les traitements mensuels sont terminés pour l’ensemble des banques, nos collègues côté groupe ont désormais accès aux mêmes données que les banques régionales, en temps réel, comme les banques.
S’agissant de ce dont on dispose dans les couloirs de production de chaque banque, nos données sont, comme sur chaque système décisionnel, récupérées en provenance du SI opérationnel ou de plates formes associées (progiciels). Un ODS, sas de mise en format technique des données est alimenté, contrairement à ce qui est préconisé au niveau des bonnes pratiques côté décisionnel. En d’autres termes, des données provenant de sources hétérogènes sont positionnées dans un format identique au niveau de Teradata.
La première couche à valeur ajoutée est la couche entrepôt, consistant en une sorte d’ODS historisé. Notre structuration de données est encore applicative et non modélisée en étoile. Les données seront historisées sur une granularité fine au niveau contrat, client, opération et sur une profondeur historique minimale de deux ans outre l’année en cours.
La deuxième couche à valeur ajoutée métiers est la couche appelée « vue métiers ». Elle porte mal son nom, car il ne s’agit nullement de vues mais de tables physiques. Les données sont dupliquées. En outre, il s’agit plutôt d’orientation fonctionnelle de la donnée que de métiers. Prenons l’exemple d’un entrepôt comprenant une trentaine de tables avec des données sur des commissions. Lorsqu’un contrôleur de gestion souhaite obtenir une vision sur l’ensemble des commissions perçues pour un client, il a deux possibilités. Soit il passe par l’entrepôt, ce qui l’oblige à développer une requête avec une trentaine de jointures. Soit il va dans la couche vue métiers où un objet vient d’être créé, qui a la granularité client, avec autant de colonnes que de commissions perçues pour ce client. C’est de la préparation de données pure et simple, sur de la granularité fine (client, contrat, opération).
La troisième couche est une couche magasin assez classique data mart, avec de l’agrégation de données, où l’on ne parle plus de client, mais de segment de clientèle, ni de contrat mais de produit.
Sur les deux dernières couches (métiers et magasin), des vues logiques ont été positionnées pour l’accès des utilisateurs au niveau organe central. Cela a également été fait au niveau entrepôt, mais en raison de l’énorme volumétrie, seuls quelques experts de l’équipe de Rémi VAZILLE ont la possibilité d’y accéder.
Côté métiers, le SI décisionnel, i-BP, est un SI multi établissement : 21 clients sont présents sur cette plate-forme. C’est également un SI multi métiers, où l’on retrouve l’ensemble des métiers de la banque, à l’exception de la RH : finance, risques, marketing, partie commerciale (tableaux de suivis commerciaux et animations commerciales), production, crédit, épargne, audit et accès pour des informatiques internes. En termes d’outils, nous utilisons la base de données Teradata ; Genio de OpenText comme ETL. S’agissant des outils de reporting, que nous partageons avec BPCE, nous sommes sur COGNOS suite 4. Enfin, SAS 9.2 est utilisée au niveau des outils d’analyse statistique. Nous disposons également d’un requêteur SQL Teradata, fourni avec la base de données. Il est important de le préciser, car les utilisateurs finaux, notamment ceux qui font de l’analyse ad-hoc, utilisent de manière importante ces requêteurs SQL, avec ensuite, une mise en forme au moyen des outils bureautiques classiques.
Je laisse Rémy, l’un de nos plus gros clients, vous expliquer les utilisations qui peuvent être faites, par les utilisateurs métiers côté BPCE, de ces données mises à disposition à partir de notre système décisionnel appelé informationnel.
S’agissant de ce dont on dispose dans les couloirs de production de chaque banque, nos données sont, comme sur chaque système décisionnel, récupérées en provenance du SI opérationnel ou de plates formes associées (progiciels). Un ODS, sas de mise en format technique des données est alimenté, contrairement à ce qui est préconisé au niveau des bonnes pratiques côté décisionnel. En d’autres termes, des données provenant de sources hétérogènes sont positionnées dans un format identique au niveau de Teradata.
La première couche à valeur ajoutée est la couche entrepôt, consistant en une sorte d’ODS historisé. Notre structuration de données est encore applicative et non modélisée en étoile. Les données seront historisées sur une granularité fine au niveau contrat, client, opération et sur une profondeur historique minimale de deux ans outre l’année en cours.
La deuxième couche à valeur ajoutée métiers est la couche appelée « vue métiers ». Elle porte mal son nom, car il ne s’agit nullement de vues mais de tables physiques. Les données sont dupliquées. En outre, il s’agit plutôt d’orientation fonctionnelle de la donnée que de métiers. Prenons l’exemple d’un entrepôt comprenant une trentaine de tables avec des données sur des commissions. Lorsqu’un contrôleur de gestion souhaite obtenir une vision sur l’ensemble des commissions perçues pour un client, il a deux possibilités. Soit il passe par l’entrepôt, ce qui l’oblige à développer une requête avec une trentaine de jointures. Soit il va dans la couche vue métiers où un objet vient d’être créé, qui a la granularité client, avec autant de colonnes que de commissions perçues pour ce client. C’est de la préparation de données pure et simple, sur de la granularité fine (client, contrat, opération).
La troisième couche est une couche magasin assez classique data mart, avec de l’agrégation de données, où l’on ne parle plus de client, mais de segment de clientèle, ni de contrat mais de produit.
Sur les deux dernières couches (métiers et magasin), des vues logiques ont été positionnées pour l’accès des utilisateurs au niveau organe central. Cela a également été fait au niveau entrepôt, mais en raison de l’énorme volumétrie, seuls quelques experts de l’équipe de Rémi VAZILLE ont la possibilité d’y accéder.
Côté métiers, le SI décisionnel, i-BP, est un SI multi établissement : 21 clients sont présents sur cette plate-forme. C’est également un SI multi métiers, où l’on retrouve l’ensemble des métiers de la banque, à l’exception de la RH : finance, risques, marketing, partie commerciale (tableaux de suivis commerciaux et animations commerciales), production, crédit, épargne, audit et accès pour des informatiques internes. En termes d’outils, nous utilisons la base de données Teradata ; Genio de OpenText comme ETL. S’agissant des outils de reporting, que nous partageons avec BPCE, nous sommes sur COGNOS suite 4. Enfin, SAS 9.2 est utilisée au niveau des outils d’analyse statistique. Nous disposons également d’un requêteur SQL Teradata, fourni avec la base de données. Il est important de le préciser, car les utilisateurs finaux, notamment ceux qui font de l’analyse ad-hoc, utilisent de manière importante ces requêteurs SQL, avec ensuite, une mise en forme au moyen des outils bureautiques classiques.
Je laisse Rémy, l’un de nos plus gros clients, vous expliquer les utilisations qui peuvent être faites, par les utilisateurs métiers côté BPCE, de ces données mises à disposition à partir de notre système décisionnel appelé informationnel.
Rémy VAZILLE : Je vais vous parler d’une application assez importante pour nos dirigeants. A l’époque, dans le monde ex-Banques Fédérales des Banques Populaires, nous disposions d’un petit entrepôt de données de groupe, comprenant une centaine de tables. Notre terrain de jeux a considérablement augmenté depuis 3 ans environ, depuis la mise en place de ce système chez nous. Aujourd’hui, nous avons la capacité de requêter sur l’ensemble de l’entrepôt de données des banques. C’est important, nous travaillons les mêmes données et la même table que les banques. Ce que l’on peut ressortir est, par nature, validé ou, à tout le moins, n’est pas en écart avec ce qui se produit localement. De plus, nous avons accès à de l’information quotidienne. Pendant la crise financière, nous étions capables d’aller à Bercy donner la situation de vente des crédits aux PME à la veille. Pour un groupe mutualiste avec 20 banques sur la place, je pense que nous n’étions pas mauvais par rapport à nos confrères qui étaient plutôt dans des structures centralisées. C’est vraiment grâce à tout ce qui a été fait chez i-BP, c’est une vraie valeur.
Nous l’avons concrétisé dans un petit exemple appelé le « projet tableau de bord des dirigeants ». Sorte de cas d’école du décisionnel, il a été mis en place il y a un peu plus de 4 ans sur la base du constat que chaque grande direction de l’organe central diffusait auprès de l’état-major du groupe un certain nombre de tableaux de bord avec les mêmes destinataires (les patrons de l’organe central et des Banques Populaires) et la même finalité (donner à ces établissements des éléments de benchmark).
Si l’on n’apprend pas à une banque comment elle fonctionne – elle le sait mieux que nous – nous pouvons lui indiquer la manière dont ses consœurs se comportent sur un même axe, de manière à faire apparaître de meilleures pratiques. Comme tout le monde à l’époque, chacun a envoyé cela comme il pouvait (intranet, mail, format papier). Les sources étaient multiples puisque nous n’avions pas encore accès à l’entrepôt de données : il y avait le déclaratif, le petit entrepôt central, des enquêtes… avec des périodicités très différentes, une grande créativité au niveau des chartes graphiques, mais surtout une grande difficulté, l’absence de règle de gestion partagée.
Ainsi, en caricaturant, un directeur général de banque pouvait recevoir de la part de l’organe central un chiffre sur son nombre de clients de la part de la direction du développement ou de la direction financière avec un écart de 5 %, à deux jours près, sans bien comprendre pourquoi.
Par ailleurs, nous ne disposions pas de couche transverse. Globalement, chaque filière métier diffusait son niveau de reporting. L’idée a été de standardiser la production de ces tableaux de bord sur 3 axes. Le premier axe était de ne disposer que d’un seul point d’entrée aux chiffres du groupe. Pour ce faire, nous nous sommes appuyés sur la technologie COGNOS Suite avec un portail regroupant l’ensemble des chiffres pouvant être diffusés. L’application d’une charte graphique a, par ailleurs, permis de s’approprier plus facilement l’information.
Aujourd’hui, je pense, comme ceux qui travaillent dans le décisionnel depuis un certain nombre d’années, que l’on a complètement inversé la tendance. Il y a 10 ou 15 ans, nous étions contents lorsque nous étions capables de remonter des chiffres à nos patrons. Aujourd’hui, c’est l’inverse, nous avons des milliards d’informations. Encore faut-il savoir comment rendre cette information accessible, compréhensible et quel est le bon tri. A minima, il est important se doter d’outils de type charte graphique ou charte de représentation. Le gros du travail a été, naturellement, d’arrêter les mêmes règles de gestion pour un seul indicateur. Si la règle de gestion est différente, l’indicateur est renommé de façon différente. Dans un groupe mutualiste où chacun a sa façon de piloter, cela a demandé un certain effort. Une solution a été mise en place à 3 niveaux. Le premier, au cœur du projet, a été d’industrialiser les reporting existants, avec une cible de directeur filière, de rajouter le niveau de synthèse qui manquait pour les dirigeants, et de compléter cela en profitant de la puissance du système i-BP avec un accès dynamique à l’information (pour les analystes que l’on appelait « les gens du chiffre »). Généralement, quand un patron reçoit une information - souvent lorsqu’elle se dégrade d’ailleurs – quelqu’un dans la banque ou dans l’établissement demande au contrôleur de gestion ou au responsable des marchés pourquoi il est moins bon que son voisin. L’idée était d’outiller ces collaborateurs pour qu’ils puissent, sur les mêmes concepts, répondre à l’interpellation de leurs dirigeants, avec une vision plus détaillée vers la gauche et plus transverse vers la droite. L’idée est de remonter les informations dans un data mart au niveau du groupe, sur lequel les indicateurs sont calculés en dessous et comprenant les agrégations, les mêmes règles de gestion, des référentiels transverses, l’ensemble étant publié au sein d’un même portail.
Environ 900 personnes sont aujourd’hui habilitées à cette application, la moitié côté organe central et l’autre moitié dans les banques. Le groupe ne compte pas bien entendu 900 dirigeants, mais à peu près 200 (un comité de direction d’une Banque Populaire - il y en a 20 au total - est en effet constitué d’environ 10 personnes, auxquels s’ajoutent l’organe central et les gens du chiffre). Un peu plus de 500 indicateurs sont disponibles dans le dispositif ainsi qu’une quarantaine de tableaux de bord statiques. L’historique remonte à décembre 2004, avec globalement un pas mensuel, même si nous disposons de quelques tableaux de bord d’un rythme de publication quotidiens, grâce à l’accès direct à la donnée sans la recopier, qui va de J+1 fin de mois à J+30, la moyenne étant de J+20. La filière finances est la plus longue, avec la consolidation comptable qui prend un peu plus de temps. Par contre, sur le volet commercial des ventes, nous sommes quasiment en temps réel. Il existe des tableaux de bord de synthèse où, lors de la connexion, l’on dispose de quelques indicateurs clés de pilotage, où il est possible, de façon un peu dynamique, de choisir son établissement ou la période, et où une cartographie est disponible. En effet, nos banques opèrent, malgré tout, sur le territoire et il est intéressant de les benchmarker sur ce point. Nous disposons d’un tableau de bord de synthèse couvrant l’ensemble des métiers de la banque (ressources humaines, risques, commercial, finances, stratégie). Il contient une dizaine de pages et permet d’avoir un panorama complet d’une banque, en la comparant au groupe ou à son marché.
Nous l’avons concrétisé dans un petit exemple appelé le « projet tableau de bord des dirigeants ». Sorte de cas d’école du décisionnel, il a été mis en place il y a un peu plus de 4 ans sur la base du constat que chaque grande direction de l’organe central diffusait auprès de l’état-major du groupe un certain nombre de tableaux de bord avec les mêmes destinataires (les patrons de l’organe central et des Banques Populaires) et la même finalité (donner à ces établissements des éléments de benchmark).
Si l’on n’apprend pas à une banque comment elle fonctionne – elle le sait mieux que nous – nous pouvons lui indiquer la manière dont ses consœurs se comportent sur un même axe, de manière à faire apparaître de meilleures pratiques. Comme tout le monde à l’époque, chacun a envoyé cela comme il pouvait (intranet, mail, format papier). Les sources étaient multiples puisque nous n’avions pas encore accès à l’entrepôt de données : il y avait le déclaratif, le petit entrepôt central, des enquêtes… avec des périodicités très différentes, une grande créativité au niveau des chartes graphiques, mais surtout une grande difficulté, l’absence de règle de gestion partagée.
Ainsi, en caricaturant, un directeur général de banque pouvait recevoir de la part de l’organe central un chiffre sur son nombre de clients de la part de la direction du développement ou de la direction financière avec un écart de 5 %, à deux jours près, sans bien comprendre pourquoi.
Par ailleurs, nous ne disposions pas de couche transverse. Globalement, chaque filière métier diffusait son niveau de reporting. L’idée a été de standardiser la production de ces tableaux de bord sur 3 axes. Le premier axe était de ne disposer que d’un seul point d’entrée aux chiffres du groupe. Pour ce faire, nous nous sommes appuyés sur la technologie COGNOS Suite avec un portail regroupant l’ensemble des chiffres pouvant être diffusés. L’application d’une charte graphique a, par ailleurs, permis de s’approprier plus facilement l’information.
Aujourd’hui, je pense, comme ceux qui travaillent dans le décisionnel depuis un certain nombre d’années, que l’on a complètement inversé la tendance. Il y a 10 ou 15 ans, nous étions contents lorsque nous étions capables de remonter des chiffres à nos patrons. Aujourd’hui, c’est l’inverse, nous avons des milliards d’informations. Encore faut-il savoir comment rendre cette information accessible, compréhensible et quel est le bon tri. A minima, il est important se doter d’outils de type charte graphique ou charte de représentation. Le gros du travail a été, naturellement, d’arrêter les mêmes règles de gestion pour un seul indicateur. Si la règle de gestion est différente, l’indicateur est renommé de façon différente. Dans un groupe mutualiste où chacun a sa façon de piloter, cela a demandé un certain effort. Une solution a été mise en place à 3 niveaux. Le premier, au cœur du projet, a été d’industrialiser les reporting existants, avec une cible de directeur filière, de rajouter le niveau de synthèse qui manquait pour les dirigeants, et de compléter cela en profitant de la puissance du système i-BP avec un accès dynamique à l’information (pour les analystes que l’on appelait « les gens du chiffre »). Généralement, quand un patron reçoit une information - souvent lorsqu’elle se dégrade d’ailleurs – quelqu’un dans la banque ou dans l’établissement demande au contrôleur de gestion ou au responsable des marchés pourquoi il est moins bon que son voisin. L’idée était d’outiller ces collaborateurs pour qu’ils puissent, sur les mêmes concepts, répondre à l’interpellation de leurs dirigeants, avec une vision plus détaillée vers la gauche et plus transverse vers la droite. L’idée est de remonter les informations dans un data mart au niveau du groupe, sur lequel les indicateurs sont calculés en dessous et comprenant les agrégations, les mêmes règles de gestion, des référentiels transverses, l’ensemble étant publié au sein d’un même portail.
Environ 900 personnes sont aujourd’hui habilitées à cette application, la moitié côté organe central et l’autre moitié dans les banques. Le groupe ne compte pas bien entendu 900 dirigeants, mais à peu près 200 (un comité de direction d’une Banque Populaire - il y en a 20 au total - est en effet constitué d’environ 10 personnes, auxquels s’ajoutent l’organe central et les gens du chiffre). Un peu plus de 500 indicateurs sont disponibles dans le dispositif ainsi qu’une quarantaine de tableaux de bord statiques. L’historique remonte à décembre 2004, avec globalement un pas mensuel, même si nous disposons de quelques tableaux de bord d’un rythme de publication quotidiens, grâce à l’accès direct à la donnée sans la recopier, qui va de J+1 fin de mois à J+30, la moyenne étant de J+20. La filière finances est la plus longue, avec la consolidation comptable qui prend un peu plus de temps. Par contre, sur le volet commercial des ventes, nous sommes quasiment en temps réel. Il existe des tableaux de bord de synthèse où, lors de la connexion, l’on dispose de quelques indicateurs clés de pilotage, où il est possible, de façon un peu dynamique, de choisir son établissement ou la période, et où une cartographie est disponible. En effet, nos banques opèrent, malgré tout, sur le territoire et il est intéressant de les benchmarker sur ce point. Nous disposons d’un tableau de bord de synthèse couvrant l’ensemble des métiers de la banque (ressources humaines, risques, commercial, finances, stratégie). Il contient une dizaine de pages et permet d’avoir un panorama complet d’une banque, en la comparant au groupe ou à son marché.
En appui de votre lecture, vous pouvez télécharger le support de cette présentation sur http://www.forumdecideo.com/file/97869/
Voici quelques exemples de radars où, globalement, les parts de marché d’une banque sont comparées par rapport au groupe. Dans le cas présent, l’on remarque qu’elles sont meilleures sur tous les produits sauf les cartes bleues.
Voici également des analyses de progression et de production de crédit. Nous utilisons beaucoup les cadrans magiques, que l’on a appris de nos amis chez Gartner, pour positionner les banques : une position en haut à droite signifie que la banque est très bien positionnée ; une position en bas à gauche implique une marge de progression. Voici un exemple sur les clients actifs et leur progression : l’on note que certaines banques, qui partaient avec un stock de clients actifs très important, continuent à avoir une grosse progression sur les clients actifs. Le symbole est à chaque fois le même par établissement, peu importe le tableau de bord dans lequel on se trouve. Les chartes graphiques facilitent l’appropriation. Des choses sont donc proposées au niveau de la stratégie, du marketing, de la finance et des risques. Ce périmètre est assez complet.
Une partie dynamique a été ajoutée. Voici quelques exemples sur l’analyse de notre clientèle des particuliers, où le groupe, comme tout groupe bancaire, s’est doté d’une segmentation de type 1, 2, 3, 4, 5, 6, 7, en fonction, par exemple, du rattachement à tel type de portefeuille, et de la cible de tel type d’action marketing.
Voici un exemple d’interface graphique qui accède à des données extrêmement fines où il est possible de se positionner sur un choix mono ou multi établissements, de choisir ses analyses de segment et de s’intéresser à certains segments. Ces segments peuvent être affinés pour voir un niveau de clientèle beaucoup plus précis, une période d’analyse de manière à projeter, ensuite, des indicateurs et mesures. Un indicateur est ce que l’on veut mesurer. Une mesure est la façon dont je vais mesurer. Par exemple, je peux être en stock fin de mois en indicateur/mesure valeur fin de mois tout en étant en mesure en suivi de progression depuis un an. Il s’agit du même indicateur, mais de deux mesures distinctes.
L’approche est très graphique, les évolutions étant davantage visibles sur un graphique que sur un tableau de chiffres, avec la capacité d’accéder aux données de détail. S’agissant de notre exemple, la question était de savoir si, sur notre segmentation de clientèle des particuliers, la distribution était homogène dans le temps. Si l’on choisit l’ensemble des segments et que l’on opère une ventilation par segment, l’on se rend compte qu’effectivement, sur nos 7 segments de clientèle, la distribution est plutôt stable dans le temps. Si l’on souhaite connaître le profil de nos nouveaux clients par rapport à cette segmentation de groupe, l’on choisira un flux brut de conquête constituant, globalement, nos entrées en relation, que l’on va ventiler par segment. L’on constate que la distribution n’est pas la même, le premier segment (la clientèle des jeunes) se retrouvant davantage présent à chaque début d’année, en raison du phénomène « étrennes » que l’on retrouve en janvier, qui génère des ouvertures de compte. Cela crée une distorsion en chaque début d’année, une forme de saisonnalité. La question, au niveau du groupe, est de savoir si la situation est identique au niveau de chacune des Banques Populaires. L’on passe alors sur un plan d’analyse multi-établissements et l’on se rend compte qu’effectivement, pour certains établissements, la part bleue n’est pas identique sur le début d’année. Deux phénomènes l’expliquent : le premier est que, en fonction de la distribution géographique, la proportion de jeunes varie en fonction des régions de France, la Côte d’Azur étant peut-être différente du Nord. Pour autant, il existe également des stratégies différentes. Car, faisant ce constat, certaines banques, à une époque, ont réalisé des actions vis-à-vis des jeunes en début d’année. Constatant que ce phénomène était naturel, elles ont reporté leurs actions sur des mois d’avril et mai. Elles ont donc finalement deux pics au cours de l’année : l’un, naturel, en janvier et un second, provoqué grâce aux actions marketing. Au niveau du stock, l’on peut également regarder si ce phénomène se retrouve. Si l’on constate quelques écarts liés à la démographie, la situation est beaucoup plus simple.
On peut aller très loin et très finement dans la segmentation de clientèle, jusqu’à regarder le comportement de nos clients professionnels, des agriculteurs, parmi eux, des maraîchers. Les temps de réponse entre chaque clic sont compris entre 5 et 10 secondes, alors qu’avant, plusieurs heures étaient nécessaires pour avoir ce type d’analyse, par des requêtes assez lourdes dans les entrepôts de données.
L’apport de l’entrepôt i-BP est très clair : un accès direct à un entrepôt colossal (65 téraoctets de données), avec d’excellentes performances. S’ajoute à cela, dans notre contexte groupe, l’importance des vues transverses, nous évitant de répliquer ces 65 téraoctets dans nos infrastructures. Les requêtes sont effectuées sur les mêmes données en une seule passe pour l’ensemble des banques avec un même modèle de données, des référentiels qui restent encore à harmoniser, mais sur lesquels ces couches de transcodification sont appliquées.
Voici également des analyses de progression et de production de crédit. Nous utilisons beaucoup les cadrans magiques, que l’on a appris de nos amis chez Gartner, pour positionner les banques : une position en haut à droite signifie que la banque est très bien positionnée ; une position en bas à gauche implique une marge de progression. Voici un exemple sur les clients actifs et leur progression : l’on note que certaines banques, qui partaient avec un stock de clients actifs très important, continuent à avoir une grosse progression sur les clients actifs. Le symbole est à chaque fois le même par établissement, peu importe le tableau de bord dans lequel on se trouve. Les chartes graphiques facilitent l’appropriation. Des choses sont donc proposées au niveau de la stratégie, du marketing, de la finance et des risques. Ce périmètre est assez complet.
Une partie dynamique a été ajoutée. Voici quelques exemples sur l’analyse de notre clientèle des particuliers, où le groupe, comme tout groupe bancaire, s’est doté d’une segmentation de type 1, 2, 3, 4, 5, 6, 7, en fonction, par exemple, du rattachement à tel type de portefeuille, et de la cible de tel type d’action marketing.
Voici un exemple d’interface graphique qui accède à des données extrêmement fines où il est possible de se positionner sur un choix mono ou multi établissements, de choisir ses analyses de segment et de s’intéresser à certains segments. Ces segments peuvent être affinés pour voir un niveau de clientèle beaucoup plus précis, une période d’analyse de manière à projeter, ensuite, des indicateurs et mesures. Un indicateur est ce que l’on veut mesurer. Une mesure est la façon dont je vais mesurer. Par exemple, je peux être en stock fin de mois en indicateur/mesure valeur fin de mois tout en étant en mesure en suivi de progression depuis un an. Il s’agit du même indicateur, mais de deux mesures distinctes.
L’approche est très graphique, les évolutions étant davantage visibles sur un graphique que sur un tableau de chiffres, avec la capacité d’accéder aux données de détail. S’agissant de notre exemple, la question était de savoir si, sur notre segmentation de clientèle des particuliers, la distribution était homogène dans le temps. Si l’on choisit l’ensemble des segments et que l’on opère une ventilation par segment, l’on se rend compte qu’effectivement, sur nos 7 segments de clientèle, la distribution est plutôt stable dans le temps. Si l’on souhaite connaître le profil de nos nouveaux clients par rapport à cette segmentation de groupe, l’on choisira un flux brut de conquête constituant, globalement, nos entrées en relation, que l’on va ventiler par segment. L’on constate que la distribution n’est pas la même, le premier segment (la clientèle des jeunes) se retrouvant davantage présent à chaque début d’année, en raison du phénomène « étrennes » que l’on retrouve en janvier, qui génère des ouvertures de compte. Cela crée une distorsion en chaque début d’année, une forme de saisonnalité. La question, au niveau du groupe, est de savoir si la situation est identique au niveau de chacune des Banques Populaires. L’on passe alors sur un plan d’analyse multi-établissements et l’on se rend compte qu’effectivement, pour certains établissements, la part bleue n’est pas identique sur le début d’année. Deux phénomènes l’expliquent : le premier est que, en fonction de la distribution géographique, la proportion de jeunes varie en fonction des régions de France, la Côte d’Azur étant peut-être différente du Nord. Pour autant, il existe également des stratégies différentes. Car, faisant ce constat, certaines banques, à une époque, ont réalisé des actions vis-à-vis des jeunes en début d’année. Constatant que ce phénomène était naturel, elles ont reporté leurs actions sur des mois d’avril et mai. Elles ont donc finalement deux pics au cours de l’année : l’un, naturel, en janvier et un second, provoqué grâce aux actions marketing. Au niveau du stock, l’on peut également regarder si ce phénomène se retrouve. Si l’on constate quelques écarts liés à la démographie, la situation est beaucoup plus simple.
On peut aller très loin et très finement dans la segmentation de clientèle, jusqu’à regarder le comportement de nos clients professionnels, des agriculteurs, parmi eux, des maraîchers. Les temps de réponse entre chaque clic sont compris entre 5 et 10 secondes, alors qu’avant, plusieurs heures étaient nécessaires pour avoir ce type d’analyse, par des requêtes assez lourdes dans les entrepôts de données.
L’apport de l’entrepôt i-BP est très clair : un accès direct à un entrepôt colossal (65 téraoctets de données), avec d’excellentes performances. S’ajoute à cela, dans notre contexte groupe, l’importance des vues transverses, nous évitant de répliquer ces 65 téraoctets dans nos infrastructures. Les requêtes sont effectuées sur les mêmes données en une seule passe pour l’ensemble des banques avec un même modèle de données, des référentiels qui restent encore à harmoniser, mais sur lesquels ces couches de transcodification sont appliquées.
Ludovic FAVARETTE : Nous venons de terminer notre roadmap à l’horizon 2014. Il existe 3 grandes familles d’évènements que nous essayons de traiter et d’améliorer sur ces 3 ou 4 ans. Tout d’abord, la maîtrise et le partage de l’information. Ayant désormais une somme colossale d’informations, il sera important de pouvoir donner plus de visibilité sur les règles de gestion à l’ensemble de nos utilisateurs. Ces règles de gestion sont uniques, mais nous n’avons pas encore assez communiqué sur le sujet ni assez formé nos utilisateurs. Une grande partie développement de la visibilité sur ces règles de gestion est à réaliser à laquelle s’ajoute le développement d’une approche collaborative avec la fusion de deux outils déjà en notre possession : un dictionnaire des métadonnées assez techniques et un wiki, une base de connaissance, approche fonctionnelle des données. Nous mettons actuellement en œuvre un projet sous Sharepoint, ayant pour but de fusionner cette approche : à la fois analyse et vision des règles de gestion, accès aux structures de données, mais également, approche par une roadmap processus où l’utilisateur entre par le processus qu’il connaît bien. Voici, par exemple, l’approche crédit-vente du crédit immobilier, dans laquelle il est expliqué où se trouvent les principaux objets, les principaux indicateurs qui touchent à la vente de crédits immobiliers pour permettre à l’utilisateur de rebondir in fine sur les règles de gestion arrêtées au niveau groupe.
Au niveau des outils et usages, on a aujourd’hui un « trou dans la raquette » concernant les outils d’analyse (SAS). On fournit des outils d’analyse statistique (SAS). Par contre, les utilisateurs métiers, en banque, qui ont des besoins d’analyse, se trouvent aujourd’hui confrontés à la problématique suivante : soit ils utilisent le requêteur SQL et remettent en forme en Excel/Access, ce qui ne nous satisfait pas complètement, soit ils utilisent COGNOS. La problématique de COGNOS, comme de Business Objects, COGNOS, ou MicroStrategy, est qu’ils passent par une couche sémantique qui, par nature, est optimisée, dans notre contexte, pour des rapports en production.
Pour croiser des données qui proviennent de la rentabilité, de l’analyse du contentieux et de segment de clientèle, il y a lieu de redévelopper une couche sémantique dédiée, ce qui n’est pas possible pour de l’analyse ad-hoc. Les utilisateurs passent dès lors par du requêtage SQL. Nous sommes aujourd’hui en train d’analyser et de travailler avec 3 éditeurs QlikView, COGNOS pour la version 10 - qui nous apporte quelques nouveautés sur ce sujet - et avec Microsoft, pour toute la suite Microsoft BI afin d’équiper au mieux nos utilisateurs pour de l’analyse ad-hoc. Le dernier niveau que nous souhaitons optimiser est la partie rationalisation du SID, la ré-urbanisation de notre système.
L’informationnel existe depuis 2001. Les couches se sont succédées, les projets aussi, avec peut-être un oubli, pendant quelques années, des logiques d’urbanisation, qui pèsent aujourd’hui assez lourd sur la connaissance et l’accès à l’information le plus simple possible, notamment sur la couche vue métiers. Nous essayons de recentrer l’approche i-BP sur quelques objets, de façon à simplifier, pour nos utilisateurs finaux, la maîtrise complète de notre système d’information décisionnel.
Rémy VAZILLE : Côté BPCE, l’idée est d’organiser l’accès aux données. Il s’agit d’appliquer, côté Caisse d'Épargne, ce que nous avons réalisé côté Banque Populaire. Le projet est lancé. Depuis juin dernier, la plateforme GCE TEC (Groupe Caisse d’Epagne Technologies) regroupe l’ensemble des 17 Caisses d’Épargne et nous permet d’accéder directement à leur système d’information. Ce projet 2011 est lancé.
Nous menons également une vraie réflexion sur les filiales avec, naturellement, des réponses adaptées. On ne peut évidemment pas traiter la problématique Natixis et celle du Crédit Foncier ou de l’international de la même façon. Mais des réflexions sont en cours, en particulier autour de l’international, d’un même entrepôt, en particulier, pour les besoins de pilotage groupe et de pilotage local. Voici les principaux sujets pour 2011.
Nous avons, en 2010, lancé divers projets autour du refinancement de groupe. Toute banque aujourd’hui sur la place est en impasse, prête plus qu’elle ne collecte. Elle va donc chercher de l’argent sur le marché. Nous avons mis en œuvre un système d’information et de refinancement consolidant l’ensemble des créances et des titres du groupe, avec les critères de mobilisation sur les différents dispositifs, en appliquant ensuite les mêmes moteurs pour l’ensemble des entités et surtout le niveau de pilotage permettant de d’appréhender la liquidité ainsi que notre capacité à faire face à un reste de liquidités. Il s’agit à la fois de BI et à la fois pas de BI, dans la mesure où nous sommes sur une chaîne très opérationnelle, mais montée, malgré tout, sur la plateforme Teradata d’i-BP. L’ensemble de nos créances est consolidé dessus, ce qui nous permet de mettre la couche de pilotage appropriée. Il s’agit d’un dispositif extrêmement sensible dans un cadre bancaire naturel. Le premier lot de ce projet se termine cette année et sera complètement abouti l’année prochaine.
Très bleu dans la présentation, du violet se met ensuite en œuvre : en particulier l’extension des tableaux de bord des agences avec l’intégration des Caisses d'Épargne et des différentes filiales. Une première version de ces tableaux de bord transverses est à l’étude, autour des pôles banque, commercial et assurances pilotés par Olivier KLEIN avec une livraison, en fin d’année, de ce premier niveau de reporting.
Au niveau des outils et usages, on a aujourd’hui un « trou dans la raquette » concernant les outils d’analyse (SAS). On fournit des outils d’analyse statistique (SAS). Par contre, les utilisateurs métiers, en banque, qui ont des besoins d’analyse, se trouvent aujourd’hui confrontés à la problématique suivante : soit ils utilisent le requêteur SQL et remettent en forme en Excel/Access, ce qui ne nous satisfait pas complètement, soit ils utilisent COGNOS. La problématique de COGNOS, comme de Business Objects, COGNOS, ou MicroStrategy, est qu’ils passent par une couche sémantique qui, par nature, est optimisée, dans notre contexte, pour des rapports en production.
Pour croiser des données qui proviennent de la rentabilité, de l’analyse du contentieux et de segment de clientèle, il y a lieu de redévelopper une couche sémantique dédiée, ce qui n’est pas possible pour de l’analyse ad-hoc. Les utilisateurs passent dès lors par du requêtage SQL. Nous sommes aujourd’hui en train d’analyser et de travailler avec 3 éditeurs QlikView, COGNOS pour la version 10 - qui nous apporte quelques nouveautés sur ce sujet - et avec Microsoft, pour toute la suite Microsoft BI afin d’équiper au mieux nos utilisateurs pour de l’analyse ad-hoc. Le dernier niveau que nous souhaitons optimiser est la partie rationalisation du SID, la ré-urbanisation de notre système.
L’informationnel existe depuis 2001. Les couches se sont succédées, les projets aussi, avec peut-être un oubli, pendant quelques années, des logiques d’urbanisation, qui pèsent aujourd’hui assez lourd sur la connaissance et l’accès à l’information le plus simple possible, notamment sur la couche vue métiers. Nous essayons de recentrer l’approche i-BP sur quelques objets, de façon à simplifier, pour nos utilisateurs finaux, la maîtrise complète de notre système d’information décisionnel.
Rémy VAZILLE : Côté BPCE, l’idée est d’organiser l’accès aux données. Il s’agit d’appliquer, côté Caisse d'Épargne, ce que nous avons réalisé côté Banque Populaire. Le projet est lancé. Depuis juin dernier, la plateforme GCE TEC (Groupe Caisse d’Epagne Technologies) regroupe l’ensemble des 17 Caisses d’Épargne et nous permet d’accéder directement à leur système d’information. Ce projet 2011 est lancé.
Nous menons également une vraie réflexion sur les filiales avec, naturellement, des réponses adaptées. On ne peut évidemment pas traiter la problématique Natixis et celle du Crédit Foncier ou de l’international de la même façon. Mais des réflexions sont en cours, en particulier autour de l’international, d’un même entrepôt, en particulier, pour les besoins de pilotage groupe et de pilotage local. Voici les principaux sujets pour 2011.
Nous avons, en 2010, lancé divers projets autour du refinancement de groupe. Toute banque aujourd’hui sur la place est en impasse, prête plus qu’elle ne collecte. Elle va donc chercher de l’argent sur le marché. Nous avons mis en œuvre un système d’information et de refinancement consolidant l’ensemble des créances et des titres du groupe, avec les critères de mobilisation sur les différents dispositifs, en appliquant ensuite les mêmes moteurs pour l’ensemble des entités et surtout le niveau de pilotage permettant de d’appréhender la liquidité ainsi que notre capacité à faire face à un reste de liquidités. Il s’agit à la fois de BI et à la fois pas de BI, dans la mesure où nous sommes sur une chaîne très opérationnelle, mais montée, malgré tout, sur la plateforme Teradata d’i-BP. L’ensemble de nos créances est consolidé dessus, ce qui nous permet de mettre la couche de pilotage appropriée. Il s’agit d’un dispositif extrêmement sensible dans un cadre bancaire naturel. Le premier lot de ce projet se termine cette année et sera complètement abouti l’année prochaine.
Très bleu dans la présentation, du violet se met ensuite en œuvre : en particulier l’extension des tableaux de bord des agences avec l’intégration des Caisses d'Épargne et des différentes filiales. Une première version de ces tableaux de bord transverses est à l’étude, autour des pôles banque, commercial et assurances pilotés par Olivier KLEIN avec une livraison, en fin d’année, de ce premier niveau de reporting.
Philippe NIEUWBOURG : Première question, qui s’adresse plutôt à Ludovic FAVARETTE puisqu’elle date du moment de votre présentation : « Chez i-BP êtes-vous parti d’un modèle de données externes ou directement de la feuille blanche pour construire votre modèle de données ?
Ludovic FAVARETTE : Concernant le modèle de données, nous ne sommes pas partis, à l’origine, d’une feuille blanche. Comme je le mentionnais tout à l’heure, notre entrepôt est orienté applicatif en termes de modélisation. Ainsi, dans l’historique d’i-BP, avant l'informationnel, nous avions un infocentre comme dans de nombreuses entreprises. L’option a été prise, dès le départ, de partir sur un data warehouse qui n’était pas orienté « étoiles » mais modélisé comme le SI applicatif. Nous sommes, par contre, partis d’une feuille blanche pour la modélisation de la couche vue métiers, couche utilisée en direct en termes de requêtage par nos utilisateurs finaux. Nous sommes partis de l’animation de commission métiers dédiées sur le marketing, la finance, les risques pour réaliser la première version de cette couche vue métiers, qui date déjà de 2002. Nous l’avons ensuite fait évoluer de façon récurrente, au fil des projets. Le seul petit bémol concerne la nécessité de réurbaniser légèrement cette couche vue métiers qui comporte aujourd’hui 350 objets et que l’on aimerait recentrer sur une centaine d’objets, peut-être un peu plus denses mais plus faciles en termes de modèles, et plus faciles d’appréhension pour les utilisateurs finaux.
Philippe NIEUWBOURG : Une deuxième question : « Pourquoi Teradata ? »
Ludovic FAVARETTE : Quand le choix de Teradata a été fait, nous avions 17 clients. Il était important, dans la perspective d’intégrer de nouveaux clients (des banques qui rejoignaient la plateforme i-BP à l’époque) d’avoir une plateforme à la fois performante pour la partie décisionnelle, mais assurant également une scalabilité totale. Il s’agit d’un argument fort de Teradata, que l’on a pu éprouver. Nous étions un peu sceptiques au départ. Nous achetons effectivement du disque qui peut paraître un peu cher. Mais il ne faut pas regarder uniquement le prix du disque. Car lorsque l’on achète un disque Teradata, l’on achète également de la CPU, de la mémoire, etc. Finalement, chaque fois que l’on a intégré une banque et que l’on a réalisé de petites extensions de périmètre sur Teradata, les projets ont été transparents alors qu’historiquement, ces projets coûtaient 18 mois, avec beaucoup de ressources. Les performances et la scalabilité de Teradata ont été éprouvées depuis 3 années.
Ludovic FAVARETTE : Concernant le modèle de données, nous ne sommes pas partis, à l’origine, d’une feuille blanche. Comme je le mentionnais tout à l’heure, notre entrepôt est orienté applicatif en termes de modélisation. Ainsi, dans l’historique d’i-BP, avant l'informationnel, nous avions un infocentre comme dans de nombreuses entreprises. L’option a été prise, dès le départ, de partir sur un data warehouse qui n’était pas orienté « étoiles » mais modélisé comme le SI applicatif. Nous sommes, par contre, partis d’une feuille blanche pour la modélisation de la couche vue métiers, couche utilisée en direct en termes de requêtage par nos utilisateurs finaux. Nous sommes partis de l’animation de commission métiers dédiées sur le marketing, la finance, les risques pour réaliser la première version de cette couche vue métiers, qui date déjà de 2002. Nous l’avons ensuite fait évoluer de façon récurrente, au fil des projets. Le seul petit bémol concerne la nécessité de réurbaniser légèrement cette couche vue métiers qui comporte aujourd’hui 350 objets et que l’on aimerait recentrer sur une centaine d’objets, peut-être un peu plus denses mais plus faciles en termes de modèles, et plus faciles d’appréhension pour les utilisateurs finaux.
Philippe NIEUWBOURG : Une deuxième question : « Pourquoi Teradata ? »
Ludovic FAVARETTE : Quand le choix de Teradata a été fait, nous avions 17 clients. Il était important, dans la perspective d’intégrer de nouveaux clients (des banques qui rejoignaient la plateforme i-BP à l’époque) d’avoir une plateforme à la fois performante pour la partie décisionnelle, mais assurant également une scalabilité totale. Il s’agit d’un argument fort de Teradata, que l’on a pu éprouver. Nous étions un peu sceptiques au départ. Nous achetons effectivement du disque qui peut paraître un peu cher. Mais il ne faut pas regarder uniquement le prix du disque. Car lorsque l’on achète un disque Teradata, l’on achète également de la CPU, de la mémoire, etc. Finalement, chaque fois que l’on a intégré une banque et que l’on a réalisé de petites extensions de périmètre sur Teradata, les projets ont été transparents alors qu’historiquement, ces projets coûtaient 18 mois, avec beaucoup de ressources. Les performances et la scalabilité de Teradata ont été éprouvées depuis 3 années.