Infocentre

On définit par Infocentre toute base de données permettant de regrouper et d’agréger dans un même endroit des données provenant de sources différentes et permettant de produire des analyses consolidées de ces données. Ces données, désormais toutes au niveau des opérations ou contrats, constituent la matière première des systèmes de synthèse et de reportings.

Historiquement les Directions Finance se sont principalement appuyées sur leur système comptable pour répondre aux besoins règlementaires et de pilotage.

Cela était cohérent et répondait à une logique : les états comptables font référence auprès des tiers (autorités de tutelle, agences de notation).
Ce dispositif pouvait être complété par des solutions spécifiques se basant directement sur les outputs des systèmes de gestion, complétés par des ajustements manuels, la source du système comptable étant constituée de l’ensemble des systèmes de gestion. La granularité des données transmises est fonction de la profondeur du plan de compte ainsi que de la clé comptable plus ou moins détaillée.
En parallèle, la fonction Risques s’est dotée de bases risques permettant de consolider les engagements Bilan et hors Bilan à une granularité plus fine, de niveau contrat.

De manière plus large, on constate que chaque filière Métier s’est créée sa propre collecte de flux à partir des mêmes systèmes de gestion de la banque pour alimenter ses propres outils de restitution. Tout ceci s’est fait de manière plus ou moins anarchique et sans aucune vision d’ensemble concernant l’architecture du SI de la banque. Ce silotage a généré ainsi des efforts coûteux et incessants de rapprochements entre les données comptables et les données risques. 

C’est ainsi que l’idée et/ou opportunité de création d’infocentres communs Finance/Risques a progressivement émergé.

Il apparaît aujourd’hui que la nécessité d’un tel outil fait consensus et la question réside davantage dans les conditions de sa mise en œuvre.En effet, trois catalyseurs puissants ont rendu indispensable ces Infocentres mutualisés Finance / Risques :

L’accroissement de la pression règlementaire depuis la crise de 2008. La réglementation exige de produire des états mettant en jeu toujours plus de données, à des mailles de plus en plus fines et dans des délais de plus en plus contraints. Par exemple, BCBS 239 challenge les établissements de Crédits sur leur capacité à consolider les données Risques, tout en en garantissant la fiabilité. La supervision des régulateurs se décline par des revues sur site nécessitant de pouvoir produire des analyses à la demande.

La mise en œuvre de la norme IFRS 9 a gravé dans le marbre le rapprochement des référentiels Risques et des référentiels Comptables. L’émergence de la fonction de contrôle de gestion stratégique, cherchant à doter les banques d’outils de pilotage financier au plus près des reportings règlementaires. Ainsi la donnée est désormais considérée comme un actif stratégique par les établissements bancaires.

Guidelines et mise en œuvre

Les principes structurels d’un infocentre sont simples sur le papier mais leur mise en œuvre peut constituer un véritable challenge pour les équipes projet.

Si l’un des critères essentiels de lancement  du projet est la réduction des risques opérationnels et des coûts (ex : décommissionnement d’infocentres redondants et obsolètes), il faut pouvoir répondre aux besoins réels des Métiers préalablement partagés, aussi bien pour les besoins de pilotage que pour les besoins réglementaires, tout en garantissant que le périmètre fonctionnel reste le reflet de l’activité de la banque tant organisationnelle (Directions Métiers) que structurelle (filiales, business spécifiques…). Tout en restant le reflet de la gestion via une vision stock (fin de journée, fin de mois…), le Datawarehouse doit pouvoir s’interfacer avec les outils éditeurs (ALM, Risques de Crédits) mais ne pas générer de comptabilité.

L’infocentre a vocation à être le cœur du SI de la banque et c’est au travers de la constitution de son modèle de données que ce positionnement prend tout son sens. En effet, la définition du modèle de données doit se faire au travers de l’étude des process Métiers qui s’appuieront à terme sur l’infocentre, cette étude pouvant servir de socle à une rationalisation/simplification des process menée en parallèle.

En s’appuyant sur le dictionnaire des données critiques et indispensables au sens des Métiers, le modèle de données doit être « ouvert » et donc évolutif afin de servir l’inflation des besoins règlementaires (ex : modèle en étoile). De plus, le niveau de granularité doit être suffisamment fin pour servir les besoins métiers sachant que le recensement des besoins doit permettre de fiabiliser les données (détection des doublons par exemple)

Même si un Infocentre global a beaucoup de vertus, il n’en présente pas moins quelques limites, il n’est évidemment pas un calculateur et n’a donc pas vocation à créer de la donnée via des règles de gestion complexes pour pallier aux manques des systèmes de gestion. Un volume important de données à traiter peut aussi engorger les chaines de traitements pour mise à disposition de l’information. Une donnée disponible à j+2 en période d’arrêté peut être déjà obsolète.

Enfin, l’intégralité des données de l’infocentre ne peut faire l’objet d’un processus de certification (contrainte de coût), il faut donc cibler/privilégier les informations structurantes et stratégiques.

Quelle architecture alors envisager ?

L’architecture du produit fini doit ressembler à une fusée à 4 étages.
Le premier serait les systèmes de gestion (Crédits, outil Front-to-Back Marchés, outils de gestion des référentiels…) qui nourrissent l’infocentre en données cœur pour chaque transaction
Le second, l’ODS : Operational (ou Origin) Data Store, qui correspond à la zone de captation de l’information fournie par les systèmes amont
Vient ensuite le CDS : Common Data Store, qui est le cœur du réacteur, la zone où les données fournies par les systèmes amont sont mises en commun et intégrées au modèle de données défini pour l’infocentre
Enfin, l’UDS : User Data Store, le niveau final où les métiers viennent exploiter les données véhiculées par l’Infocentre via des requêtes (ex : Business Objects) et où les calculateurs spécifiques viennent chercher les données nécessaires à leur fonctionnement (ex : Fermat RAY, FOCUS…)

Changement de paradigme

A l’heure des évolutions digitales, il est intéressant d’analyser les impacts de la Business Intelligence, du Big Data et du Data Lake : si ces approches sont différentes, elles peuvent néanmoins être complémentaires.

Bien que la Business Intelligence en est aujourd’hui à son seuil de maturité tant en termes de technologies que de compétences techniques requises, le Big Data et surtout le Data Lake semblent aujourd’hui être une suite logique et une évolution naturelle du décisionnel.
L’ambition du Big Data est de valoriser le capital informationnel de la banque en utilisant les données pour piloter les établissements en donnant de la visibilité aux décideurs dans leurs choix stratégiques et opérationnels.
Par ailleurs, la Business Intelligence (informatique décisionnelle) est devenue au fil des années une activité structurée qui répond toujours aux besoins de pilotage des entreprises.

Cependant, des difficultés et contraintes sont inhérentes aux phases de collecte et de chargement dans les systèmes.

Les Datawarehouse sont à la fois lourds à mettre en place et très rigides : un infocentre transmet les données de leurs origines vers leurs utilisateurs (chaque datamart étant sensé satisfaire un besoin, avec un risque de silotage). Les échanges entre les SI opérationnels métiers et le SI décisionnel ne vont souvent que dans un sens (SIO vers SID).

De plus, l’accroissement démesuré de la volumétrie des données a mis en évidence une contrainte/limite technique (en termes de stockage notamment) des architectures classiques. Le data lake pourrait ainsi apporter un certain nombre de réponses.
Le concept de Data Lake ou lac de données, issu du Big Data permet de gagner en agilité et en flexibilité avec une approche différente de celle des entrepôts de données, en cassant les silos des systèmes d’information :

. Absence de schéma strict imposé aux flux entrants.
. Démarche d’ELT (Extract-Load-Transform qui exploite les technologies des SI existants sur la base des données sources et/ou cibles pour transformer les données) plutôt que d’ETL (Extract-Transform-Load qui s’appuie sur des moteurs propriétaire avec du code généré puis compilé).
. Stockage global des informations présentes dans la Banque, ce qui permet de charger toutes les données (brutes, natives) de les transformer ensuite pour les rendre exploitables rapidement.
. Capacité d’ingestion de flux en temps réel et de réaction aux données autorise des applications à interagir directement dessus.

Les clefs de la réussite

Comme pour tout projet ambitieux, la mise en œuvre d’un Infocentre passe par plusieurs facteurs clé de succès à mettre en regard des risques inhérents à ce type de projet complexe.

Face à l’inadaptabilité de la solution logicielle avec les besoins réels :
. Ne pas anticiper le choix de la solution logicielle avant l’analyse des besoins réels pour éviter la non-couverture des besoins.
. Permettre l’évolutivité de l’infocentre et notamment permettre aux outils éditeurs de s’y interfacer.
. Compléter, si nécessaire, la solution logicielle par des applications satellites pour des besoins ponctuels (End-user computing)

Face à Périmètre fonctionnel mal défini ou trop ambitieux :
. Cerner les besoins réels des métiers, capacité à identifier et formaliser ces besoins (phase dictionnaire de données) : « Il faut voir grand et commencer petit ».
. Couvrir les usages adaptés aux besoins et éviter leur démultiplication.
. Associer les utilisateurs de manière progressive et pragmatique.

Face à la difficulté de mise en place de la conduite du changement :
. Mettre en place en place une structure de support de communication pour permettre d’intéresser et d’associer les utilisateurs.
. S’assurer des compétences disponibles en externe et surtout en interne pour garantir la bonne réalisation du projet. Ce seront les futurs utilisateurs qui seront les meilleurs commerciaux de la nouvelle solution fonctionnelle : un infocentre complet, modulaire et donc …agile !