Automatiser le reporting réglementaire

Si produire un état périodique suppose qu'une personne ouvre plusieurs systèmes, exporte vers un tableur, applique des ajustements qu'elle garde en tête et colle le résultat dans un gabarit, le problème n'est pas l'absence d'outil de reporting. Le problème est que la donnée sous-jacente ne contient pas ce que l'état demande, et que l'écart est comblé par un humain à chaque période.

Le signe distinctif est la colonne d'ajustement. Chaque ajustement manuel est un morceau de logique métier qui vit hors du système, appliqué de façon inconstante, et invisible pour tout le monde sauf pour celui qui l'applique.

Le modèle qui fonctionne, c'est qu'il existe un jeu de données d'exploitation, assez bien structuré pour que chaque état soit une requête dessus. Les états le découpent, l'agrègent et l'étiquettent différemment, mais aucun n'introduit de faits que la donnée d'exploitation ne contient pas déjà.

Y parvenir suppose que les dimensions existent dans la donnée au moment de l'événement plutôt que d'être déduites après coup. Si le reporting distingue des types de paiement, des catégories de clients, des géographies, des canaux ou des identifiants de schéma, chacun doit être enregistré sur le mouvement quand il se produit. Déduire une catégorie de client huit mois plus tard depuis une donnée qui a changé depuis produit un nombre non reproductible, et un nombre non reproductible est pire qu'un nombre en retard.

Les chiffres réglementaires sont des énoncés à une date. Encours de monnaie électronique au dernier jour de la période. Nombre de clients à une date. Exposition à un instant. Les systèmes d'exploitation, laissés à eux-mêmes, stockent l'état courant et l'écrasent.

Deux mécanismes règlent cela et se combinent bien. D'abord l'historique immuable d'événements pour tout ce qui bouge, que le grand livre fournit déjà. Ensuite des enregistrements temporels pour tout ce qui est un état plutôt qu'un mouvement : statut client, notation de risque, configuration produit, plafonds. Un enregistrement temporel porte un intervalle de validité, de sorte que demander quelle était la notation d'un client en mars est une requête plutôt qu'une fouille archéologique.

Les équipes ajoutent souvent la temporalité au grand livre et l'oublient pour les données de référence, puis découvrent qu'un état n'est pas reproductible parce qu'un client a été reclassé en juillet et que la table de classification a une ligne par client.

Un état mérite le même traitement que n'importe quelle autre sortie régulée. Rapprochement entre l'état et la source, vérification que les totaux concordent entre états liés, comparaison à la période précédente avec explication exigée au-delà d'un seuil, et trace de qui a approuvé la remise.

L'analyse des variations d'une période à l'autre est le contrôle qui se rentabilise le plus vite. La plupart des erreurs de reporting se voient comme un saut invraisemblable, et les attraper avant remise fait la différence entre une correction et un retraitement.

Quand un chiffre est contesté, la réponse utile consiste à descendre du nombre remis jusqu'aux mouvements individuels qui le composent. Cela suppose que le pipeline garde le lien plutôt que d'agréger et d'oublier.

En pratique : stockez le jeu de résultats intermédiaire de chaque chiffre remis, ou au minimum la requête exacte et ses paramètres, avec une empreinte de la population d'entrée. La descente reste alors possible même après que les tables sous-jacentes ont grossi d'une année.

L'économie n'est pas dans les heures d'assemblage, même si elles sont réelles. C'est la disparition d'une catégorie de risque dans laquelle un chiffre remis à un superviseur a été produit par un processus que personne ne sait décrire.

L'effet secondaire est plus discret et compte davantage : le même jeu de données répond aux questions de la direction et à celles du superviseur avec les mêmes nombres. Quand le pack du conseil et l'état réglementaire divergent, la conversation qui suit ne porte jamais sur l'arithmétique.