Logistique du trading pétrolier et ventes par oléoduc sur SAP TSW

Total implémentait SAP au niveau mondial pour la vente et l'acheminement du pétrole. Accenture assurait l'intégralité de la gestion du projet, avec une cinquantaine de consultants, pour la plupart fonctionnels, à Châtillon et les équipes de développement ABAP en offshore en Inde. Les achats, ventes et la planification des transports en masse s'effectuaient dans SAP IS-Oil TSW (Traders' and Schedulers' Workbench), une surcouche de SD et MM. Membre de l'équipe « bulk » de quatre personnes, chargée des nominations : les documents TSW qui planifient les transports en masse par bateau pétrolier, train et autres moyens de transport en masse. Cette mission a marqué le passage du rôle de développeur à celui de consultant technico-fonctionnel et le début d'une spécialisation dans la logistique.

Le défi

TSW gère l'achat, la vente et le transport des produits pétroliers à l'aide de plannings, contrats, nominations et tickets. Dans l'activité bulk, les volumes et les valeurs sont très importants. Une équipe « market » distincte gérait les flux de vente au détail, comme les livraisons par camion-citerne des stations-service.

Mon chef d'équipe m'a confié un projet complet : intégrer les ventes par oléoduc dans le système. Ce type de vente n'était pas encore géré par le système et faisait partie de la stratégie future de Total : le projet était donc très visible. C'était aussi mon premier rôle d'analyste fonctionnel après mes années de développeur. J'avais suivi la formation SAP SCM600 sur les processus de vente avant de démarrer, et j'ai passé plusieurs jours dans les locaux de Total avec un key user pour un transfert de compétences.

Le fonctionnement des nominations TSW

Les tickets enregistrent le chargement physique du produit dans un conteneur (bateau, citerne, camion, appartenant ou non au client), et c'est le volume réel mesuré qui sert à la facturation. Les contrats et documents portent des Incoterms, le plus souvent CIF (le vendeur organise et prend en charge le transport maritime et l'assurance) et FOB (le vendeur livre jusqu'au bateau, puis l'acheteur prend la main).

Conception de la solution : le flux de ventes par oléoduc

Les nominations couvraient déjà la planification et le transport : l'essentiel du travail portait donc sur la configuration standard des flux de vente SD dans l'IMG.

1. Contrat. Un contrat porte des échéances avec des dates, des quantités et des prix. Par exemple, un contrat de pétrole brut entre deux sites européens avec des livraisons toutes les deux semaines pendant un an.
2. Commandes de vente créées automatiquement à partir du contrat. J'ai configuré les échéances de contrat et de commande ainsi que les règles de copie (contrat → commande), pour qu'une commande soit générée toutes les deux semaines à partir des échéances du contrat.
3. Livraison. Elle enregistre la date réelle, la quantité exacte et le moyen de transport (oléoduc).
4. Facture. Elle est créée à partir de la livraison par d'autres règles de copie que j'ai configurées, et valorisée par un schéma de prix que j'ai créé spécialement pour les ventes par oléoduc.

J'ai créé de nouveaux types de commandes, de livraisons et de factures et associé les types de commandes aux schémas de prix que j'ai configurés, pour que la bonne détermination du prix s'exécute. L'impact principal portait sur la gestion des prix et les échéances de paiement.

Les ventes par oléoduc devaient aussi générer des pièces comptables. J'ai utilisé l'intégration SD-FI qui transforme les documents de vente en pièces comptables, et j'ai configuré des règles de substitution FI (remplacer un compte par un autre selon des critères) pour que les ventes par oléoduc soient comptabilisées dans les bons comptes. L'équipe comptable était sur le même plateau mais hors de mon périmètre. Je me suis coordonné avec elle pour qu'elle conçoive sa partie en fonction de ma conception SD, et la solution complète a été mise en production.

Mon passé de développeur m'a aidé à faire la part des choses entre ce que la configuration permettait et ce qui justifiait un développement ABAP spécifique.

Difficultés et résolution : l'incident des règles de substitution

Ce qui s'est passé. Toutes les règles de substitution étaient rattachées à un seul et même schéma. Lors du transport de ma modification, tout le schéma est parti avec, y compris les modifications en cours et non testées d'autres équipes. Peu après la mise en production, les utilisateurs ont constaté de mauvais comptes généraux sur des ventes et des achats, sur tous les flux générant des pièces comptables. Les flux oléoduc eux-mêmes étaient corrects, car ils avaient été testés. Les autres documents pouvaient être affectés au bon compte comme à un mauvais, et l'impact était très grave pour la comptabilité.

Ce que j'ai fait :

1. J'ai averti le métier et arrêté les opérations en production le temps d'analyser le problème, puis j'ai informé les experts comptables. Ils ont rapidement évalué les impacts et construit un plan pour identifier et corriger les écritures erronées. La correction des données comptables ne faisait pas partie de mon rôle.
2. J'ai restauré les règles de substitution de production à l'aide des outils SAP de comparaison entre systèmes, qui comparent programmes, paramétrage et contenu des tables d'un système à l'autre. Je me suis appuyé sur le système de préproduction, rafraîchi chaque jour avec une copie de la production de la veille, comme référence pour comparer et restaurer correctement les règles.
3. J'ai réintégré mes modifications oléoduc sur la version de production et je les ai transportées de nouveau, isolées des autres projets en cours qui avaient causé les erreurs.
4. Pendant la semaine où l'équipe FI/CO a corrigé chaque compte impacté, j'ai assuré leur hotline pour leur libérer du temps.

Je me suis senti responsable de la gêne occasionnée. Cet incident a changé ma façon de gérer la qualité des livraisons depuis.

Travailler avec l'équipe de développement offshore

Les développements ABAP étaient réalisés en offshore en Inde. J'étais le consultant fonctionnel face à eux. Tous les documents, e-mails, appels et le système lui-même étaient en anglais : c'était mon premier projet international où l'anglais était obligatoire.

Mon processus pour chaque besoin :

1. Le chef d'équipe m'assignait le besoin.
2. Je me rapprochais du métier et des key users, par téléphone ou en présentiel, pour confirmer ma compréhension.
3. J'estimais l'analyse fonctionnelle, le développement et les tests. Mon chef validait l'estimation et la présentait au client pour revue des coûts.
4. Une fois l'accord de Total obtenu, je réalisais l'analyse fonctionnelle et rédigeais la spécification. Je comparais le besoin au standard SAP et aux solutions existantes pour réutiliser au maximum et limiter les coûts. J'utilisais des diagrammes de flux (surtout pour les interfaces), les points de paramétrage, les noms de tables et les valeurs.
5. J'écrivais des cahiers de test couvrant chaque cas métier et des cas de non-régression.
6. En tant qu'ancien développeur, j'ajoutais une seconde partie avec l'algorithme et la logique : variables, tables à créer, fonctions et classes à utiliser. Le document combiné, une spécification fonctionnelle et technique détaillée (SFT), était déposé dans la base documentaire du projet et envoyé en Inde.
7. Pendant la réalisation, je répondais aux questions des développeurs. Je n'avais pas d'accès en développement, mais je pouvais consulter les programmes et débugger pour les aider.

Niveaux de test que j'ai pris en charge ou accompagnés :

Le client exigeait des preuves documentées des tests. Les mises en production étaient mensuelles : un développement en retard était donc décalé d'un mois entier. Les équipes offshore ne ressentaient pas directement la pression du client, et il fallait gérer le décalage horaire de six heures, la langue et les différences culturelles. La facturation était à la demande : des retards ou des anomalies pouvaient entraîner des pénalités financières.

Le paysage système

Ce que j'en ai retenu

• La configuration des flux de vente et la détermination des prix sont au cœur de SD, et elles sont devenues la base de ma spécialisation logistique dans les missions SD et intercompany suivantes.
• Toute modification en production peut créer une régression ailleurs. Les tests de non-régression et la documentation ne sont pas optionnels.
• Les modifications abandonnées ou inutilisées doivent être supprimées des systèmes de test, sinon quelqu'un qui ignore leur présence finira par les envoyer en production.
• La gestion des transports et la comparaison entre systèmes sont devenues une pratique courante sur chacun de mes projets suivants.
• Rédiger des spécifications suffisamment précises pour une équipe à distance, en anglais, et les tester de manière exhaustive, est une compétence que j'ai réutilisée dans chaque collaboration offshore qui a suivi.