Blog Conseils-Plus

Damien en visite de l'usine de production

Dans le cadre de la restructuration du groupe pétrolier Spirou (le nom du client est gardé confidentiel pour des raisons de confidentialité commerciale), les utilisateurs clés d’une des filiale de ce groupe étaient à la rechercher de quelqu’un capable de les coacher dans l’appropriation de leur nouvel ERP. Cette mission concerne plus particulièrement les utilisateurs FICO.

Origine du projet

Le groupe pétrolier rachète cette année le fonds de commerce d’une société de fabrication de graisse et intègre la possibilité de l’implémentation du SI dans cette filiale.

Dans le cadre de fin de maintenance de l’application locale, il est prévu d’intégrer les activités de la filiale dans le système SAP d’une des entités du groupe pétrolier.

Objectif du projet

Le projet vise la mise en place de SAP R/3 4.6C au sein de la filiale, sur les processus de planification, production, achat, ventes et finance.
Cette implémentation sera l’occasion d’harmoniser les processus du site avec ceux de la Direction métier.

Périmètre d’intervention

Plus que de l’AMOA, j’interviens comme coach sur la partie finance et contrôle de gestion des utilisateurs clés. Mon périmètre de responsabilité est large :

• Modélisation de l’AB costing : harmoniser le CCR (calcul du coût de revient) de la filiale à celui du groupe et formuler la solution à la DSI.
• Proposition de solutions pour répondre aux besoins du métier : cela comprend la compréhension du métier, la compréhension du système SAP du groupe, l’écriture des documents de conceptions et de paramétrage.
• Création du plan de test et accompagnement des utilisateurs à réalisation de la recette.
• Formation des utilisateurs.
• Création du cut-over et de la stratégie de reprise.
• Accompagnement lors du démarrage et analyse des incidents avec indication de la solution SAP.

L’AMOA n’est pas véritablement impliquée dans la production de la solution ERP. Cependant, la présence de l’AMOA agit comme un catalyseur sur le projet, accélère l’appropriation par les utilisateurs, améliore l’adéquation de la solution avec les besoins et au final optimise le ROI du projet.

Avant le démarrage d’un projet il faut s’assurer que l’ensemble des acteurs (utilisateurs clefs, responsables de systèmes « legacy », consultants, chefs de projets fonctionnels et techniques) partagent une vision commune sur la séquence des opérations à mener pour basculer d’un système à un autre. Un ou plusieurs documents de synthèse permettent de définir des grandes étapes jusqu’aux micro-tâches (à l’heure ou plus finement) qu’il faudra effectuer.

Ce plan de bascule porte très fréquemment le nom de « cut-over plan ». Il se présente sous la forme d’un diagramme de gant au format Microsoft Project ou en format Excel .

Il comporte en général plusieurs documents, car il faudra souvent condenser en format Powerpoint les grands jalons par domaine pour communiquer vers les Business Process Owners et responsable de projet (DAF, responsable de production, responsable commercial…) sans se perdre inutilement dans le détail.

Il est normalement de la responsabilité du chef de projet de lancer l’élaboration d’un tel document donc :

• demander à chaque domaine fonctionnel la séquence des opérations à mener et de fédérer l’ensemble des intervenants à travers ;
• des réunions d’intégration pour valider le planning global ;
• de s’assurer de la communication vers les différents intervenants ;
• de faire le suivi et le reporting, notamment l’analyse de risque .

Plus génériquement le terme « cut-over » désigne la phase du projet qui va conduire à basculer d’un environnement à un autre, à mobiliser les équipes, parfois 24h/24. La phase déborde souvent le simple démarrage pour s’étendre jusqu’à la dernière reprise comptable voire jusqu’à la première clôture.

Fréquemment des KPI (Key Performance Indicators) vont permettre de suivre l’appropriation du nouvel outil, le bon fonctionnement des interfaces. Ils sont cruciaux car ils permettent de communiquer en langage business sur le succès/les problèmes d’un démarrage (et accessoirement de prendre les mesures et actions correctives) :

• nombre de commandes passées/de livraisons/de factures ;
• nombre de rejets liés aux interfaces quelle que soit la technologie employée ;
• nombre de pièces intégrées en comptabilité et en contrôle de gestion et validité de leur imputation ;
• …

Un plan de bascule doit toujours comporter une solution de back-up et des jalons pour mesurer l’avancement et permettre à la gestion de projet de jauger le ratio « risques encourus à poursuivre/objectifs de démarrage » (par exemple, si l’on suit la reprise des stocks dans un entrepôt géré sous SAP WM -Warehouse Management- et l’on se rend compte que les stocks ont certes été correctement chargés d’un point de vue comptable, mais que le cariste ira les chercher à l’autre bout du magasin alors qu’ils sont physiquement ailleurs, on aura a minima un point de correction de reprise).

Le cut-over plan (plan de bascule) représente, pour résumer, un livrable clef permettant :

• de jauger de la capacité des différents intervenants à se projeter vers la cible en avance de phase ;
• de mesurer l’avancement des différents sous-chantiers tout au long de la phase ;
• de communiquer de façon détaillée sur un point particulier et sur l’avancement par domaine ;
• d’estimer la viabilité du démarrage pendant les phases les plus critiques de ce dernier ;
• d’initier toute mesure corrective pendant et après le démarrage.

Philippe Meyer, Directeur.