Centre de compétences Finance et BW

Allianz France (anciennement AGF) s'était construite par de nombreuses acquisitions dans l'assurance, l'assistance, l'assurance-crédit et la banque. Son centre de compétences SAP assurait les développements, la configuration et l'expertise pour tous les métiers, sur l'ensemble des systèmes SAP en production et en développement. Côté finance, plusieurs systèmes SAP couvraient les baux immobiliers, les dépenses de matériel informatique et de bureau, la comptabilité analytique et la comptabilité générale, ainsi que la consolidation multinorme pour la maison mère allemande. Une couche d'échange (SAP XI) transférait leurs données vers SAP BW pour l'informatique décisionnelle. La mission venait renforcer une équipe de cinq développeurs et un chef de projet pour les correctifs et évolutions sur FI, CO et BW.

Le paysage des systèmes finance

Chaque nuit, les données étaient extraites des systèmes finance vers des tables tampon, écrites dans des fichiers plats, transmises par XI et chargées dans BW par des routines de chargement.

Le circuit des demandes

1. Les demandes étaient saisies dans un outil de tickets relié à la gestion documentaire du projet. Le chef de projet planifiait le travail et assignait les tickets.
2. J'estimais chaque demande à partir de charges prédéfinies selon la complexité et le type de développement. Par exemple, une modification simple d'un report ABAP était estimée à deux jours, tests unitaires compris. Je l'ajustais selon la complexité et l'envoyais au métier pour validation.
3. Je rédigeais la spécification technique détaillée, en suivant les modifications pour que la personne qui reprendrait le sujet puisse voir chaque changement.
4. Je développais en ABAP : surtout des chargements de pièces comptables entre systèmes, mais aussi des user exits, des reports, des interfaces, des écrans Dynpro et des routines de chargement BW.
5. Un autre analyste relisait mon code selon les normes du projet. Je réalisais les tests unitaires et livrais aux équipes fonctionnelles pour les tests fonctionnels et d'intégration.
6. Je relisais aussi le code de mes collègues avec une grille des normes. Je consignais les anomalies, renvoyais les points bloquants pour correction et les vérifiais de nouveau avant de valider.

Zoom technique : refonte objet des chargements comptables

Le problème. Des interfaces extrayaient chaque jour les pièces de comptabilité générale et analytique saisies par chaque filiale. Elles les transformaient, les chargeaient dans des tables tampon et écrivaient les fichiers plats pour XI et BW. Ces interfaces étaient redondantes et procédurales, et chaque filiale avait ses propres règles. Chaque modification se répercutait sur tous les programmes et fonctions dépendants : le risque de régression était élevé, le code difficile à lire et le support se compliquait à chaque modification.

La solution. Pendant une période plus calme du projet, j'ai proposé et réalisé une refonte du chargement du système de comptabilité analytique et générale vers BW :

• J'ai regroupé les interfaces et mutualisé les traitements communs.
• Je suis passé du code procédural à l'ABAP objet. Chaque filiale est devenue une classe avec ses propres attributs et méthodes, et le comportement commun était hérité d'une classe mère, donc écrit une seule fois pour toutes les entités.
• Le polymorphisme gérait les différences. Par exemple, les filiales AGF IART et Calypso étaient des classes distinctes, et un seul appel à une méthode commune transcodait leurs centres de coût, chacune selon ses propres règles.
• J'ai arrêté le périmètre au chargement dans les tables tampon, pour que le reste de la chaîne (fichiers → XI → BW) fonctionne sans changement.

Les tests. Les volumes étaient importants et les critères nombreux. J'ai conservé l'ancien code et l'ai exécuté en parallèle de la nouvelle version. J'ai développé un programme de comparaison qui vérifiait automatiquement que les deux produisaient des données identiques dans les tables tampon, ce qui m'a permis de réaliser tous les tests nécessaires en un temps assez court.

Pourquoi. Une réécriture complète est risquée et difficile à justifier en coût et en régression. Mon pari était que le temps investi en amont ferait gagner du temps ensuite. La lisibilité et la fiabilité se sont nettement améliorées, le risque de régression a diminué, et comme le centre de compétences recevait des demandes d'évolution fréquentes de toutes les filiales, la refonte a réduit l'effort de développement futur de l'équipe.

Suivi de production des chargements BW

Les comptables saisissaient des pièces chaque jour et les analysaient dans les systèmes sources ou dans BW, par société et avec descente dans le détail. Les cubes BW offraient les vues multidimensionnelles qu'exigeaient ces volumes. Chaque nuit, les pièces comptables et les données des centres de coût, centres de profit et autres informations financières étaient extraites et chargées avec les données de la veille.

Ma routine quotidienne :

1. Vérifier l'export dans les tables tampon sur les machines de production.
2. Vérifier le transit par les interfaces XI.
3. Vérifier le chargement dans les InfoCubes BW. Certains chargements étaient automatiques, d'autres manuels. Le chargement BW s'exécutait en process chain de plusieurs étapes, avec du code spécifique dans des routines de chargement (calculs, formatage, découpage en paquets).
4. Comparer les volumes et l'intégrité pour chaque type de document (factures fournisseurs et clients, notes de crédit et de débit, paiements, échéances), et remonter ou corriger les bugs des routines de chargement ABAP.
5. Envoyer aux utilisateurs un compte rendu de statut avant le début de la journée des comptables, avec le statut par flux et par système.

Difficultés et résolution : un chargement en échec pendant la préclôture

Ce qui s'est passé. Un jour, plusieurs chargements ont échoué, et leur correction et rechargement ont pris des heures. Mon tableau de statut affichait chaque flux en « OK » vert ou « KO » rouge. Pendant la préclôture, un utilisateur s'est plaint de ne pas savoir quels chargements étaient disponibles, et les échanges d'e-mails sont devenus tendus.

La cause. J'ai averti mon équipe et analysé chaque étape de la chaîne :

• Extraction source : tables de la base (SQL ou affichage des tables SAP), logs d'extraction et logs système pour les crashs.
• Création et copie des fichiers : je me suis connecté aux serveurs FTP pour vérifier la présence des fichiers.
• Cible : les étapes de lecture, de formatage et d'intégration dans BW.

Les fichiers n'avaient pas été copiés parce que l'utilisateur système des batchs avait perdu ses droits : un paramètre de droits de lecture et d'écriture sur les serveurs FTP avait été modifié. J'ai rassemblé les captures d'écran des erreurs et ouvert un ticket à l'équipe Basis.

La correction de la communication. J'ai compris que l'utilisateur ne distinguait peut-être pas les couleurs, et que « OK » et « KO » se ressemblent. J'ai restructuré le compte rendu en deux sections titrées, « Chargements prêts » et « Chargements en anomalie », mis à jour le modèle d'e-mail et demandé à mes collègues de faire de même, car c'était plus clair et plus inclusif pour tout le monde.

Ce que j'en ai retenu

• L'ABAP objet était encore considéré comme une innovation à l'époque. Je l'ai réutilisé ensuite, par exemple pour une maquette Fiori de caisse enregistreuse pour L'Oréal.
• Les compétences BW acquises ici m'ont resservi sur les DataSources BW de L'Oréal.
• Le suivi de production, avec une communication claire et crédible sous des délais serrés, est au cœur de chaque hypercare après un go-live.