Gestion de projets ERP
Migration SAP : comment réussir en accompagnant vos équipes au changement
Pourquoi l'accompagnement au changement est crucial lors d'une migration SAP S/4 HANA
Les enjeux d'une migration SAP pour les équipes internes
Lors d’une migration vers SAP S/4 HANA, les équipes internes sont directement impactées par les nouveaux processus et outils à adopter. Cette transition peut être intimidante pour certains collaborateurs, qui craignent de perdre leurs repères ou de ne pas s’adapter. Pourtant, la réussite de cette migration repose en grande partie sur l’adhésion de vos équipes, car elles sont les acteurs principaux de ce changement.
Sans un accompagnement adapté, une migration SAP peut entraîner des retards, des erreurs, et des interruptions d’activité coûteuses. Il ne s’agit pas seulement de passer d’un ancien système à un nouveau, mais de réorganiser la manière dont les équipes travaillent ensemble, accèdent à l’information, et exécutent leurs tâches quotidiennes.
Les enjeux pour les équipes :
- Nouveaux processus de travail : les collaborateurs doivent comprendre les nouvelles logiques de gestion des flux, ce qui peut nécessiter une révision des habitudes de travail.
- Outils de reporting intégrés : l’introduction de nouvelles fonctionnalités telles que des indicateurs communs peut soulever des questions sur la transparence et la responsabilité.
- Changements dans la communication interservices : les services doivent adapter leurs interactions pour maximiser les avantages de SAP, une démarche souvent complexe sans accompagnement.
Impact du changement organisationnel sur les collaborateurs
Le changement que représente la migration SAP peut provoquer des réactions émotionnelles et comportementales chez les collaborateurs. Les résistances au changement sont fréquentes : peur de ne pas être à la hauteur, crainte de perdre son emploi, ou simplement refus de changer des habitudes bien ancrées.
Un accompagnement personnalisé permet d’anticiper ces résistances en comprenant les peurs des collaborateurs, d’encourager une attitude positive face au changement, et d’impliquer les équipes dans le processus. En proposant des formations adaptées et en valorisant les efforts de chacun, on peut atténuer les craintes et renforcer l’adhésion.
Réduire les interruptions d’activité grâce à un accompagnement adapté
La migration vers SAP S/4 HANA est une opération complexe, mais cela ne signifie pas que l’activité quotidienne doit en souffrir. Un bon accompagnement ne se contente pas de guider les équipes, il permet aussi de minimiser les erreurs opérationnelles.
Par exemple, une erreur sur les conditions d’expédition lors de la saisie d’une commande client peut avoir un impact très coûteux sur la logistique : erreur de préparation de la commande, problème d’emballage, choix du transporteur erroné, livraison défectueuse, réclamation client, retour marchandises, coût de destruction, pénalités… La liste peut être longue.
Voici quelques éléments essentiels pour réduire au minimum les interruptions :
- Planification précise des étapes : chaque phase de la migration doit être anticipée et alignée avec les besoins de l’entreprise.
- Formations adaptées aux équipes : offrir des formations progressives et continues permet aux collaborateurs de se familiariser avec les nouveaux outils sans interrompre totalement leur travail.
- Communication transparente : les collaborateurs doivent être tenus informés des échéances et des impacts possibles sur leur travail quotidien, ce qui les rassure et leur permet de mieux se préparer.
Communiquer efficacement auprès des équipes et des parties prenantes externes
Préparer les équipes en interne : objectifs et bénéfices du changement
Dès le début, il est indispensable de clarifier les objectifs de cette migration. Expliquez pourquoi ce changement est nécessaire et quels bénéfices les équipes peuvent en tirer. Les résistances proviennent souvent d’une incompréhension des enjeux ou de la peur de l’inconnu. Pour surmonter ces obstacles, il est primordial de :
- Mettre en avant les avantages concrets pour les collaborateurs : simplification des processus, accès plus rapide aux informations, amélioration de la communication entre les services, réduction de la complexité technique, etc.
- Présenter les impacts positifs pour l’entreprise : optimisation des coûts, meilleure gestion des flux, amélioration de la satisfaction client, etc.
- Insister sur l’accompagnement proposé : formation continue, support technique et assistance pour les collaborateurs.
Rassurer les parties prenantes externes : clients, fournisseurs et partenaires
La migration n’impacte pas uniquement les équipes internes, elle touche aussi les partenaires externes tels que les clients, fournisseurs et prestataires. Il est donc essentiel de communiquer avec eux de manière proactive pour éviter toute perturbation dans la relation commerciale.
Voici quelques éléments clés pour une communication externe efficace :
- Informer en amont des changements : anticipez les questions de vos partenaires en partageant les délais et les impacts possibles sur les commandes ou les livraisons.
- Garantir la continuité des services : rassurez-les sur le fait que la migration a pour but d’améliorer la qualité des services et la gestion des commandes.
- Ouvrir des canaux de communication : invitez vos partenaires à poser des questions et à discuter des solutions envisagées.
Adapter la communication à chaque département et chaque niveau de responsabilité
Une migration aussi importante que celle vers SAP S/4 HANA concerne tous les départements de l’entreprise. Si un service des ventes entre des conditions d’expédition erronées dans le système, cela peut entraîner des problèmes à tous les niveaux : la logistique peut mal préparer la commande, le transporteur ne sera pas bien choisi, et le client pourrait recevoir un produit défectueux ou en retard.
Il est essentiel d’adapter les messages en fonction du public, car chacun vit le changement à sa manière.
Quelques conseils à retenir :
- Messages personnalisés par service : chaque département doit comprendre comment la migration impactera ses processus spécifiques.
- Adapter la communication selon les niveaux hiérarchiques : ajustez les informations et le ton en fonction des responsabilités de chacun.
Former efficacement vos collaborateurs à SAP S/4 HANA
Structurer des sessions de formation engageantes et interactives
Pour que vos collaborateurs s’impliquent activement, les formations doivent être interactives et adaptées à leur rythme. Voici quelques méthodes pour structurer des formations efficaces :
- Diviser les formations en sessions courtes : permet une assimilation progressive sans surcharge.
- Utiliser des démonstrations pratiques : invitez les participants à s’entraîner en situation réelle pour se familiariser rapidement avec le système.
- Intégrer des exercices collaboratifs : favorise l’entraide et permet de résoudre plus facilement les éventuels blocages.
Utiliser les "master data" pour faciliter la montée en compétences
Les master data (données de base) sont essentielles pour l’apprentissage de SAP S/4 HANA. En se basant sur des éléments familiers, les collaborateurs peuvent plus facilement comprendre les nouveaux processus.
Voici comment faciliter cette montée en compétences :
- Commencer par les données existantes : manipuler des informations connues rend la transition plus intuitive.
- Clarifier les nouveaux concepts : présentez les changements de manière progressive.
- Encourager l’apprentissage itératif : les collaborateurs découvrent les nouvelles fonctionnalités à leur rythme.
Impliquer les key users pour un apprentissage en profondeur
Les key users jouent un rôle central dans la réussite de la formation. Leur implication permet de créer un réseau interne de soutien et d’amplifier l’adoption du nouveau système.
Voici comment tirer parti de leur expertise :
- Former les key users en amont : en leur offrant une formation plus approfondie dès le début, vous leur donnez les outils pour aider leurs collègues à comprendre les nouveaux processus et à surmonter les difficultés.
- Encourager les key users à animer des sessions : ils peuvent co-animer certaines parties des formations ou organiser des ateliers pratiques pour répondre aux questions spécifiques de leur service.
- Créer un réseau de soutien interne : en étant les premiers à expérimenter et à maîtriser SAP S/4 HANA, les key users deviennent des ressources précieuses, capables de répondre rapidement aux interrogations des autres utilisateurs.
Renforcer la collaboration interservices pour une transition fluide
Créer des groupes de travail interservices pour optimiser les flux
Les groupes de travail interservices permettent à chaque service de comprendre les enjeux des autres départements et d'ajuster les processus en conséquence. Quelques bonnes pratiques pour ces groupes :
- Impliquer des représentants de chaque service pour garantir que les besoins de tous sont pris en compte.
- Identifier les points critiques des flux pour éviter les goulets d’étranglement.
- Favoriser la communication ouverte pour encourager l’innovation.
Comprendre les interdépendances entre services pour éviter les erreurs
Chaque service étant interconnecté, un changement dans un département peut affecter les autres. Par exemple, une petite erreur dans le service des ventes peut rapidement se transformer en un problème de grande ampleur pour la logistique et le service client : mauvaise saisie des conditions d’expédition, erreur dans le choix du transporteur, et au final, un client mécontent.
Clarifier ces interdépendances dès le départ permet de :
- Minimiser les erreurs de communication.
- Optimiser les processus transversaux.
- Renforcer la responsabilité collective.
Utiliser des réunions régulières pour suivre l’avancement du projet
Des réunions fréquentes rassemblant des représentants de chaque service permettent de :
- Faire le point sur l’avancement des phases.
- Identifier et résoudre les problèmes rapidement.
- Maintenir l’engagement des équipes en partageant les réussites et les prochaines étapes.
Vous souhaitez en savoir plus sur notre approche ?
Nous proposons un accompagnement personnalisé pour chaque projet de migration vers SAP S/4 HANA. Contactez-nous dès maintenant :
- Via notre formulaire de contact pour plus d'informations.
- Ou prenez un rendez-vous directement avec nos experts.
Cas client : Surteco adopte SAP S/4 HANA avec l'accompagnement d'Hargos
Surteco, une entreprise spécialisée dans la production de surfaces décoratives pour l'industrie du meuble et de la construction, a entrepris une migration vers SAP S/4 HANA. Cette initiative faisait partie d'une démarche stratégique de son groupe, visant à moderniser l’ensemble de ses filiales à travers un ERP intelligent. Surteco a été choisie comme unité pilote, donnant le ton pour les futures implémentations dans les autres entités du groupe.
Un projet pilote pour une transformation exemplaire
En tant que première entité du groupe à basculer vers SAP S/4 HANA, Surteco devait non seulement réussir la migration, mais aussi servir d'exemple pour les autres unités. Cette responsabilité ajoutait une dimension stratégique et exigeait un accompagnement à la hauteur de l'enjeu. Notre choix s'est donc porté sur leur capacité à respecter les transactions standards et à appliquer les best practices SAP, un critère essentiel pour garantir une mise en œuvre en douceur.
Focus sur l'accompagnement : une transition en douceur pour Surteco
Chez Hargos, l'accompagnement au changement est au cœur de chaque projet. Pour Surteco, cela a impliqué un transfert de savoir sur mesure, où nos consultants ont travaillé main dans la main avec les équipes internes.
- Étape clé : pour faciliter l'adoption, nous avons analysé les besoins métiers spécifiques de Surteco, en identifiant les indicateurs clés utiles pour leur quotidien.
- Approche collaborative : plutôt que de livrer une solution toute prête, les équipes de Surteco ont co-construit leurs rapports et états, avec un accompagnement personnalisé des experts Hargos.
Cette approche a permis à Surteco d'approprier SAP S/4 HANA comme leur propre outil. Résultat ? Une transition fluide, avec un lancement en production sans aucun impact négatif sur l'activité ni sur les clients de Surteco.
Adoption et évolution : les utilisateurs comme moteurs du changement
Accompagner les utilisateurs, c’est aussi leur faire comprendre que leur rôle évolue avec l’outil. Après quelques mois d’utilisation, les équipes de Surteco ont commencé à proposer des améliorations pour maximiser les fonctionnalités de SAP S/4 HANA.
Exemple : les utilisateurs ont suggéré l’ajout de nouveaux services pour mieux répondre aux demandes des clients et des fournisseurs.
Ce retour proactif témoigne d’une adoption réussie, où les utilisateurs sont devenus des acteurs du changement, cherchant à faire évoluer la solution pour l’adapter aux besoins croissants de l’entreprise.
Contactez Hargos pour un accompagnement sur mesure lors de votre migration SAP S/4HANA
Bénéficiez d'un accompagnement personnalisé à chaque étape du projet
Chaque entreprise a des besoins uniques. Chez Hargos, nous proposons un accompagnement sur mesure à chaque étape de votre migration. Nos services incluent :
- Un audit personnalisé de vos processus actuels.
- Une gestion proactive des résistances pour accompagner vos équipes dans l'adoption du nouveau système.
- Des formations sur mesure pour vos collaborateurs.
Nos services d'accompagnement au changement pour les PME
Chez Hargos, nous comprenons que les PME ont des ressources limitées et des impératifs de continuité opérationnelle. C’est pourquoi nous vous offrons des solutions pragmatiques et accessibles, sans sacrifier la qualité de l’accompagnement.
Prenez contact avec Hargos pour réussir votre migration SAP
Avec Hargos à vos côtés, vous bénéficiez d’un partenaire fiable et expérimenté capable de gérer les aspects techniques et humains de votre projet.
- Pour en savoir plus, contactez-nous via notre formulaire de contact
- Ou planifiez directement un rendez-vous avec nos consultants.
VLM SAP, évaluer la pertinence économique des projets ERP
Introduction à VLM et Hargos
Timestamp : 0:00-1:09
Hargos, partenaire et intégrateur des solutions SAP spécialisé pour les PME, présente VLM (Value Lifecycle Management), un outil conçu pour améliorer les performances économiques des projets ERP.
Qu'est-ce que VLM ?
Timestamp : 3:28-6:44
VLM est une plateforme développée par SAP destinée à évaluer la pertinence économique des projets ERP. Elle est basée sur plus de 50 ans d'expérience et alimentée par des données clients anonymisées et publiques.
Comment VLM peut aider les prescripteurs ERP
Timestamp : 6:45-10:58
L'outil aide à évaluer et à justifier économiquement les projets ERP auprès de leurs clients en fournissant une analyse comparative avec des entreprises similaires, en identifiant les points forts et les points à améliorer.
Analyse SWOT avec VLM
Timestamp : 10:59-11:26
VLM propose une analyse SWOT pour déterminer les forces, faiblesses, opportunités et menaces liées au projet ERP envisagé, aidant ainsi à concentrer les efforts sur les aspects les plus pertinents.
Fixation des objectifs avec VLM
Timestamp : 11:27-15:46
Les utilisateurs peuvent définir des objectifs spécifiques pour chaque KPI, ce qui permet d'aligner le périmètre du projet ERP avec les besoins métier du client.
Calcul du ROI avec VLM
Timestamp : 15:47-22:59
VLM permet de calculer le retour sur investissement (ROI) d'un projet ERP en se basant sur des données financières réelles fournies par le client, aidant ainsi à justifier économiquement le projet.
Utilisation des résultats VLM
Timestamp : 23:00-fin
La plateforme génère un rapport détaillé sous forme de PowerPoint qui peut être utilisé pour présenter les conclusions de l'étude au comité de direction du client, facilitant la prise de décision basée sur des données concrètes.
Optimisation et challenges : la durée d'un projet SAP dans une PME industrielle
Dans un monde en constante évolution où on nous parle de nouvelles technologies, d’intelligence artificielle, de machine learning et de MES (Manufacturing Execution System), les petites et moyennes entreprises (PME) industrielles sont de plus en plus nombreuses à se poser des questions autour de l’adoption de solutions ERP (Enterprise Resource Planning).
Ces solutions doivent apporter une réponse à des problématiques organisationnelles, à des clients qui ont de nouvelles exigences, à des marchés en mouvement, et à une gouvernance environnementale de plus en plus contraignante. Ainsi, dans beaucoup de cas, les entreprises envisagent de s’équiper de SAP pour améliorer leur efficacité opérationnelle.
Cependant, la durée d'un projet SAP dans une PME industrielle peut être un défi crucial. Cet article a pour objectif d’explorer les facteurs qui influent sur la durée de mise en œuvre de projets SAP, les avantages potentiels pour les entreprises et les meilleures pratiques pour garantir le succès du processus.
Les facteurs influant la durée d'un projet SAP
La taille et la complexité de l'entreprise
C’est presque faire une Lapalissade que d’affirmer que la durée d'un projet SAP dans une PME industrielle dépend souvent de la taille et de la complexité de cette même entreprise. Cependant, il est facile de comprendre que plus une PME sera petite, plus on saura modéliser facilement ses processus lors de la mise en œuvre des solutions SAP. A contrario, les entreprises de plus grande envergure vont nécessiter une planification et une exécution plus approfondies.
Ces PME, appelées aussi ETI (Entreprises de Taille Intermédiaire), vont nécessiter :
- de mobiliser plusieurs services,
- de contrôler la cohérence des décisions prises,
- d’unifier les modes de fonctionnement
- d’organiser la mise en œuvre de SAP pour que chaque tâche soit en parfaite coordination pour respecter la cohérence globale du périmètre de la solution à déployer.
De plus, dans ces ETI, il est même souvent souhaitable de savoir anticiper les besoins futurs pour ne pas avoir à défaire plus tard ce qu’on a fait lors de la première mise en œuvre :
- anticiper des déploiements internationaux,
- anticiper la mise en place de flux EDI avec les clients,
- anticiper une extension d’activité, etc…
Il semble donc évident que la taille et la complexité organisationnelle d'une petite ou moyenne entreprise (PME) sont des facteurs déterminants qui influent significativement sur la durée d'un projet de mise en place d'une solution SAP S/4 HANA.
Mais la taille de l’entreprise ne conditionne pas à elle seule la complexité d’un projet SAP. En effet, de nombreux autres facteurs peuvent impacter le calendrier de mise en œuvre.
L’étendue des processus opérationnels
Lorsqu’on parle du temps de mise en œuvre d’une solution SAP, le premier élément qui nous vient naturellement à l’esprit est le périmètre du projet. En effet, la solution SAP sait couvrir des pans entiers de l’entreprise et ne connaît quasiment pas de limites dans sa couverture fonctionnelle.
Mais, le projet de notre client est-il sans limites ? Quel est notre point de départ et quel point d’arrivée nous sommes nous fixé ? En toute logique, plus le chemin à parcourir sera long, plus long sera le projet.
Par expérience, chez Hargos, nous avons constaté que les PME ont souvent des processus opérationnels aussi complexes et aussi diversifiés que les grandes entreprises. Le seul écart qu’on pourra constater avec les grandes entreprises va concerner le volume d’informations à traiter et la complexité du réseau d’interconnexion, habituellement plus simple pour les PME.
En conséquence, la mise en place de SAP S/4 HANA peut être plus rapide en raison de la plus grande simplicité pour récupérer les données des anciens systèmes.
On recherche aussi des accélérateurs en nous concentrant sur la simplification des flux de travail. Les consultants Hargos vont simplement décliner la solution SAP en s’appuyant sur les « Best Practices » fournis par l’éditeur et en chargeant le système avec des données de base qui sont connues et maîtrisées par le client.
Et lorsqu’une entreprise grossit pour atteindre une taille intermédiaire, on peut alors être confronté à des processus plus étendus et interconnectés. La nécessité de comprendre, modéliser et adapter ces processus peut prolonger la durée du projet.
On saura toujours utiliser les « Best Practices » pour accélérer la mise en œuvre de la solution. Toutefois, les données à traiter ne seront pas connues et maîtrisées par une seule personne, mais nécessitent souvent l’intervention de plusieurs sachants qui devront se coordonner sur la cohérence de ces données.
Ainsi, pour bien maîtriser le planning de son projet et pour éviter les dérives calendaires de celui-ci, il est très important de savoir bien définir le périmètre du projet. Inutile d’avoir des ambitions démesurées dès le lancement du projet pour changer la totalité des processus de travail.
Un projet bien délimité, bien défini et qui reste dans les limites du raisonnable et du gérable permettra alors de garder ses process sous contrôle. Ensuite, une fois la solution démarrée et stabilisée, il sera temps de travailler sur le développement de la solution par l’ajout de fonctionnalités complémentaires.
Le besoin de personnaliser la solution
Comme stipulé dans le paragraphe précédent, les PME peuvent généralement adopter des solutions SAP S/4 HANA avec moins de personnalisation grâce à la simplification de leurs besoins. On s’appuiera alors sur l’activation des « Best Practices » qui est un vrai accélérateur de projet et permet une mise en œuvre plus rapide.
Cependant, il ne faut jamais confondre vitesse et précipitation. C’est pourquoi, chez Hargos, nous préconisons de prévoir un temps de travail non négligeable à la consécration du projet pour permettre aux futurs utilisateurs de reformuler leur organisation, de repenser celle-ci et de formaliser ces nouveaux processus dans la nouvelle solution.
Ainsi, un projet bien conçu doit impérativement prévoir du temps autour de l’échange, du partage, de la communication projet et de la réflexion sur l’organisation. Comme nous le disons si souvent, un projet ERP n’est pas un projet informatique, mais bien un projet de réorganisation. Ainsi, la dimension technique, même si importante, ne doit pas être le principal sujet à prendre en considération.
Deuxièmement, comme stipulé au paragraphe précédent, si le périmètre du projet a été clairement décrit, Hargos va cibler et activer les meilleures « Best Practices » SAP.
L’objectif de ces outils consiste à fournir une solution la plus adaptée possible pour minimiser les personnalisations de la solution et ainsi proposer des accélérateurs de projet efficaces. Ainsi, grâce à ces composants SAP, on constate des gains projet de l’ordre de 25 à 40%.
Bien entendu, lorsqu’on doit prendre en compte une complexité organisationnelle de l’entreprise plus importante, les « Best Practices » vont alors nécessiter d’être retravaillés pour s’adapter aux flux du client. Cette personnalisation de SAP S/4 HANA peut être plus importante. Cela nécessite donc du temps avec des consultants Hargos pour comprendre la complexité des flux, les modéliser dans la solution, prendre en compte la cohérence globale de la solution et enfin tester les résultats.
Au-delà de la simple personnalisation de la solution, il ne faut pas oublier que le carburant de base de toute solution ERP est constitué par les données de base. On va donc particulièrement insister sur cette partie souvent reléguée au second plan du projet alors que le bon fonctionnement de votre solution va s’articuler principalement autour de ce composant. Nous vous invitons à relire notre article du 19 janvier 2022 sur la reprise des données.
Les besoins spécifiques de l'entreprise en matière de personnalisation des solutions SAP peuvent également influencer la durée du projet. Une personnalisation complexe pour répondre aux exigences industrielles spécifiques peut prolonger le calendrier de mise en œuvre.
La structure organisationnelle
La première étape d’un projet SAP consiste à décrire la structure organisationnelle du client. Celle-ci peut être très simple comme très complexe. De plus, une structure organisationnelle pourra être mouvante dans le temps et nous nous devons d’imaginer ces futures évolutions.
Ainsi, nous décrirons dans un premier temps :
- les sites impliqués sur le projet,
- la ou les sociétés à intégrer,
- les organisations commerciales et leurs découpages,
- les organisations achats (centralisées/décentralisées), les entrepôts à inclure dans le projet, etc…
Dans une petite entreprise, on est souvent confronté à des entreprises avec une structure organisationnelle relativement plate ; les décisions sont prises rapidement par un, deux ou trois décideurs. Cette prise de décision rapide est un vrai accélérateur de projet, facilitant la coordination et la prise de décision pendant la mise en œuvre.
De plus, modéliser une structure organisationnelle à plat reste relativement simple et standard dans la solution SAP et ne nécessitera pas de nombreux allers-retours valider cette organisation.
En revanche, dans les entreprises de taille moyenne ou dans les ETI, nous risquons d’être confronté à des structures plus complexes.
Ces organisations vont souvent compter plusieurs niveaux de hiérarchie répartis sur plusieurs entités ou plusieurs sociétés et qui nécessitent alors un consensus général pour sa modélisation : recherche de consensus qui peut entraîner des délais supplémentaires sur notre projet.
En effet, ces niveaux hiérarchiques sous-entendent souvent une prise de décision plus lente car nécessitant de trouver des compromis entre les services.
Cet aspect du projet impliquera donc souvent une coordination et une communication plus complexe entre les acteurs du projet : le client, Hargos et éventuellement le cabinet AMOA impliqué sur la mise en œuvre de la solution.
Budget et ressources
Le budget alloué au projet et les ressources affectées à la mise en place de la solution SAP sont aussi un élément important sur l’estimation de la durée d’un projet ERP. Ainsi, les petites entreprises ont souvent des ressources limitées tant budgétairement qu’en terme de bande passante du personnel affecté au projet.
Toutefois, par définition le projet sera moins ambitieux et la taille plus modeste du projet peut aussi être un accélérateur puisqu’il permet une gestion plus agile du projet et une utilisation plus efficace des ressources mises à disposition.
Et pour compléter notre propos, les entreprises de taille moyenne (ou ETI) par définition plus complexes et plus exigeantes en termes de périmètre devront impérativement intégrer ces dimensions budgétaires et allocations de ressources dans leur plan projet. Ainsi, la complexité supplémentaire apportée par l’organisation peut nécessiter des budgets et des ressources plus importants.
Les ETI devront alors allouer suffisamment de moyens pour éviter les retards liés à des contraintes budgétaires. Or, par expérience, on constate que ce manque de moyens génère souvent des retards sur les projets.
Nous tenons à préciser que la notion de moyens ne doit pas forcément être vu uniquement sous le prisme financier mais englobe plutôt une notion de ressources humaines mises à disposition du projet : groupe de projet, comité de pilotage, comité projet, instance qualité, etc…
La capacité d'adoption des utilisateurs
Un aspect souvent négligé est la formation des utilisateurs. Plus l'équipe est nombreuse, plus la formation prend du temps. Un bon programme de formation contribue à une adoption plus rapide et à une utilisation efficace du nouveau système.
Comme nous l’expliquons souvent chez Hargos, un projet réussi n’est pas un projet qui a démarré à la date prévue et au budget prévu.
Et même si ces deux indicateurs restent importants, chez Hargos nous considérons qu’un projet est réussi lorsque les utilisateurs ont pris pleinement possession de leur solution. Or, pour bien comprendre un système, il faut être bien formé à celui-ci.
Naturellement on comprendra que plus les processus modélisés dans la solution sont simples et plus facilement les utilisateurs vont pouvoir intégrer toutes les subtilités de leur nouvel outil. Ainsi, la réussite du projet va forcément passer par l’organisation d’un plan de formation adapté et pensé pour les utilisateurs.
Ces formations :
- devront être portées par le groupe de projet qui a œuvré au paramétrage de la solution
- ne devront pas arriver trop tard dans le projet, ni trop tôt. Et surtout, les utilisateurs devront être accompagnés pour leurs premiers pas dans la solution.
Hargos prévoit toujours une période de quelques semaines après le démarrage où les consultants sont mis à la disposition des utilisateurs pour les guider sur leurs premières transactions SAP.
Comment évaluer la durée d'un projet SAP ?
Comme vous l’avez compris et comme on a essayé de l’argumenter sur les paragraphes précédents la durée d’un projet SAP sera facteur d’un ensemble de variables différentes d’une entreprise à l’autre.
Ainsi, la taille de l’entreprise et la complexité de son organisation seront une première base pour estimer une durée de projet. Mais, en tant que professionnel, nous nous devons également de prendre en compte :
- la complexité du marché adressé par notre client,
- la complexité des produits vendus ou fabriqués,
- les exigences des clients,
- les contraintes règlementaires et administratives.
Un ensemble de paramètres qui vont considérablement influer sur la durée du projet puisque influant sur la modélisation des données de base.
Lorsqu’une entreprise initie un projet ERP, elle part d’une situation à un instant T et envisage un point d’arrivée idéal. Cette projection sous-entend forcément une charge de travail conséquente. En effet, un projet ERP implique pour le client les éléments suivants :
- Mettre noir sur blanc son organisation et sa façon de travailler,
- Recenser son ou ses marchés, leurs spécificités et leurs exigences
- Recenser ses clients et leurs attentes en termes de services clients, de transparence, de traçabilité, etc…
- Recenser ses produits et leur complexité : nomenclatures multi-niveaux ou pas, produits configurables, sérialisation, lotissement…
- Recenser les exigences administratives et fiscale
Une fois que toutes ces informations sont clairement identifiées il conviendra alors de travailler sur la cible. Comment, dans le meilleur des mondes, je projette mon organisation à l’issue de mon projet ? Il y a fort à parier que les objectifs décrits soient irréalistes et hors de portée de notre client.
Cependant, sur cette base nous allons pouvoir alors faire des projections de charge de travail et pouvoir alors adapter le périmètre de notre projet aux moyens possibles à allouer au projet.
En résumé, bien que chaque entreprise soit unique, les PME de différentes tailles peuvent rencontrer des défis distincts lors de la mise en place de SAP S/4 HANA. Une compréhension approfondie de la taille, de la complexité et des besoins spécifiques de l'organisation est cruciale pour élaborer un plan de mise en œuvre réaliste et pour anticiper les éventuels obstacles, ce qui contribuera à optimiser la durée du projet.
Et pour conclure, un projet SAP n’a pas de durée idéale. Il est impossible de faire des généralités et d’affirmer qu’un projet SAP durera quatre, six, huit, douze ou dix-huit mois.
Implémentez SAP dans votre PME
Nous pouvons vous affirmer que chez Hargos nous militerons pour que votre projet ne dépasse pas la barre des douze mois. En effet, au-delà de ce délai on constate souvent un effet de lassitude du groupe de projet et les forces vives affectées au projet ont souvent tendance à s’écarter petit à petit des objectifs initialement fixés.
Et pour vous donner un aperçu de notre savoir-faire : la durée moyenne d’un projet de mise en œuvre de SAP avec les équipes Hargos est 8,6 mois.
Les tests : étape clef d'une mise en production réussie d’un projet SAP
Introduction
Vous avez lancé votre projet SAP S/4 HANA Cloud depuis quelques mois. Celui-ci arrive bientôt à son terme et vous allez bientôt commencer à mettre en œuvre la stratégie de démarrage pour la mise en production de votre nouvelle solution.
Cependant, avant cette mise en production votre partenaire intégrateur insiste pour qu’une période de tests soit mise en place et respectée par l’ensemble de votre groupe de projet. Mais pourquoi tant d’insistance de votre intégrateur sur cette partie tests ? Lors de la mise en place d'un projet SAP S/4HANA Cloud public, les tests avant la mise en production sont une étape cruciale pour assurer la fiabilité et la performance du système.
Il convient donc, lors de cette phase de conception de la stratégie de démarrage de bien prendre en compte cette étape clé qui va sécuriser le passage en production. Les tests visent à identifier et à corriger les éventuels problèmes avant que le système ne soit mis à disposition des utilisateurs finaux. Dans cet article, nous explorerons la logique des tests avant la mise en production dans un projet SAP S/4HANA Cloud public et donnerons quelques conseils pour réussir ces tests essentiels.
I. Importance des tests avant mise en production dans SAP S/4HANA Cloud Public
Les tests avant la mise en production dans un projet SAP S/4HANA Cloud public revêtent une importance capitale pour garantir le bon fonctionnement et la fiabilité du système. Cette phase de test est essentielle pour identifier et corriger les problèmes potentiels avant que le système ne soit déployé pour les utilisateurs finaux.
En assurant la qualité du système avant la mise en production, les organisations peuvent éviter des dysfonctionnements coûteux et préjudiciables à leurs opérations commerciales. :
- Fiabilité du système : Les tests avant la mise en production sont essentiels pour vérifier la fiabilité du système SAP S/4HANA Cloud. Ces tests permettent de s'assurer que toutes les fonctionnalités du système fonctionnent correctement et qu'elles répondent aux spécifications techniques. Les tests unitaires au niveau des composants individuels permettent de détecter les erreurs de codage, tandis que les tests d'intégration évaluent la cohérence entre les différents modules et composants du système. Grâce à ces tests rigoureux, les organisations peuvent garantir que le système fonctionne sans heurts et qu'il est prêt à être utilisé en production.
- Qualité des données : Un autre aspect critique des tests avant mise en production concerne la qualité des données. Les données incorrectes ou incohérentes peuvent entraîner des résultats imprévisibles et fausser les rapports, ce qui peut avoir des conséquences négatives sur la prise de décision. Et il ne faut pas oublier que le plus gros risque identifié sur un projet ERP réside dans la qualité et la fiabilité des données. En effet, des données erronées impliqueront des dysfonctionnements sur votre futur système qui pourraient prendre des mois voire des années à résoudre. Ainsi cette étape de tests de validation et de tests d'intégration permet de s'assurer que les données sont correctement migrées et que les interfaces fonctionnent correctement pour garantir l'intégrité des données tout au long du processus.
- Optimisation des performances : L'optimisation des performances est un objectif clé des tests avant la mise en production. Les tests de performance sont réalisés pour évaluer comment le système se comporte sous différentes charges de travail. Ces tests incluent souvent des scénarios de charge graduelle pour déterminer les limites du système. En identifiant les goulots d'étranglement et en effectuant les ajustements nécessaires avant la mise en production, les organisations peuvent s'assurer que le système répond efficacement aux besoins opérationnels, même dans des situations de forte demande.
- Réduction des risques : Les tests avant la mise en production jouent un rôle essentiel dans la réduction des risques associés au déploiement d'un nouveau système. En identifiant les problèmes potentiels tels que des erreurs de configuration, des incompatibilités ou des failles de sécurité, les tests permettent d'atténuer les risques avant qu'ils n'affectent les activités commerciales en production. Cette approche proactive aide à prévenir les temps d'arrêt coûteux et les retards de projet. Hargos, avec sa méthodologie projet (cf notre article de blog à ce sujet : "Quelle méthodologie projet pour intégrer une ERP avec succès et soutenir sa transformation ?"), met tout en œuvre pour anticiper les difficultés et pour que l’intégration soit la plus fluide possible.
- Satisfaction des utilisateurs finaux : En fin de compte, la réussite d'un projet SAP S/4HANA Cloud public est mesurée uniquement à travers la satisfaction des utilisateurs finaux. Les tests avant la mise en production ont pour principal objectif de s’assurer que le système réponde du mieux possible aux besoins opérationnels et que celui-ci fonctionne de manière fiable et efficace. En impliquant les utilisateurs finaux tout au long des tests, les organisations peuvent recueillir leurs commentaires et leurs suggestions, ce qui permet d'améliorer l'expérience utilisateur et d'optimiser l'adoption du système. C’est pourquoi Hargos prévoit des points d’intégration et des étapes de validation intermédiaires dans son approche méthodologique. Ces jalons permettent alors de mettre tout le monde au même niveau d’information et d’avoir une vision éclairée de la future solution.
En résumé, les tests avant la mise en production dans un projet SAP S/4HANA Cloud public sont cruciaux pour assurer la fiabilité du système, la qualité des données, l'optimisation des performances, la réduction des risques et la satisfaction des utilisateurs finaux. La phase de test doit être planifiée avec soin dès le début du projet pour garantir suffisamment de temps et de ressources pour mener à bien les tests de manière exhaustive.
Souvent négligée et utilisée comme une réserve de jours pour terminer les paramétrages, la phase de test est extrêmement importante dans l’accompagnement au changement et peut être utilisée comme un outil de communication interne pour emmener toute l’équipe dans le projet.
II. Les Différents types de tests dans SAP S/4HANA Cloud Public
Dans un projet SAP S/4HANA Cloud public, différents types de tests sont utilisés pour évaluer la solidité et la fiabilité du système mis en œuvre.
Chaque type de test vise à vérifier un aspect spécifique du système, ce qui contribue à une évaluation globale complète de sa performance et de sa fiabilité.
- Tests Unitaires : Les tests unitaires sont réalisés au niveau des composants individuels du système, tels que les programmes, les fonctionnalités ou les modules spécifiques. L'objectif est de vérifier le bon fonctionnement de chaque unité de code. Les développeurs effectuent généralement ces tests pour s'assurer que chaque composant répond aux spécifications et fonctionne comme prévu. Les tests unitaires peuvent être automatisés pour faciliter leur exécution et permettre une vérification continue du code lors des modifications ultérieures.
- Tests d'Intégration : Les tests d'intégration sont conçus pour vérifier le bon fonctionnement des interfaces entre les différents composants du système SAP S/4HANA Cloud. Dans un système ERP complexe, de nombreux modules interagissent pour soutenir les processus métier de l'entreprise. Les tests d'intégration s'assurent que les données circulent correctement entre les modules et que les processus sont bien connectés. Ils permettent de détecter les éventuels problèmes d'interopérabilité et de garantir une communication fluide entre les différentes parties du système.
- Tests de Validation : Les tests de validation sont essentiels pour vérifier si le système répond aux spécifications et aux exigences du client. Ces tests sont conçus pour valider que le système SAP S/4HANA Cloud prend en charge les processus métier de l'entreprise de manière précise et complète. Ils sont généralement effectués en collaboration avec les utilisateurs finaux pour s'assurer que le système reflète fidèlement les besoins opérationnels réels de l'entreprise.
- Tests de Performance : Les tests de performance évaluent les capacités du système SAP S/4HANA Cloud à traiter des charges de travail réalistes. Ils visent à identifier les goulets d'étranglement et à mesurer les temps de réponse pour différentes opérations. Les tests de performance permettent de s'assurer que le système peut gérer la charge de travail attendue sans compromettre ses performances. Ils sont particulièrement importants pour les entreprises ayant un grand nombre d'utilisateurs et des volumes de données importants.
- Tests de Sécurité : La sécurité est un aspect critique de tout système ERP, en particulier lorsqu'il s'agit de données sensibles et confidentielles. Les tests de sécurité évaluent la robustesse du système face aux menaces internes et externes. Ils vérifient la résistance du système aux attaques potentielles et aux tentatives de piratage. Ces tests permettent de découvrir et de corriger les vulnérabilités avant que le système ne soit exposé à un environnement de production en direct.
En combinant ces différents types de tests, les équipes de projet SAP S/4HANA Cloud public peuvent s'assurer que le système est complet, bien intégré, fiable, performant et sécurisé avant sa mise en production.
III. Conseils pour des tests réussis avant mise en production
La réussite des tests avant la mise en production dans un projet SAP S/4HANA Cloud public repose sur plusieurs facteurs clés.
Voici quelques conseils pour garantir des tests réussis et une transition en douceur vers le nouveau système :
- Planification Précoce : Intégrer la phase de tests dans la planification globale du projet dès le début est essentiel. Les tests doivent être considérés comme une étape cruciale du processus de mise en place du système et non comme une activité accessoire. En planifiant les tests dès le début, vous pouvez vous assurer que suffisamment de temps et de ressources sont alloués pour mener à bien cette tâche critique.
- Implication des Utilisateurs Finaux : Impliquez les utilisateurs finaux tout au long du processus de test. Leur implication est précieuse pour évaluer la convivialité du système et l'adéquation aux besoins opérationnels réels. Les utilisateurs finaux peuvent également fournir des commentaires précieux sur les fonctionnalités du système et identifier les éventuels problèmes liés à leurs activités quotidiennes.
- Scénarios Réalistes : Concevez des scénarios de test qui reflètent de manière réaliste les processus métier de l'entreprise. Les scénarios de test doivent être basés sur des cas d'utilisation réels et couvrir différents flux de travail. Cela permet d'obtenir des résultats plus pertinents et de mieux évaluer les performances du système dans des situations réelles.
- Automatisation des Tests : L'automatisation des tests permet d'accélérer le processus de test, d'améliorer la couverture des tests et de réduire les erreurs humaines. Certaines tâches de test peuvent être répétitives et fastidieuses, ce qui les rend parfaitement adaptées à l'automatisation. Cela permet également d'exécuter des tests de manière cohérente à chaque itération, garantissant ainsi une évaluation précise des fonctionnalités à chaque étape.
- Tests de Charge Graduelle : Lors des tests de performance, il est recommandé d'augmenter progressivement la charge sur le système. Cela permet d'identifier son seuil de tolérance et ses limites. Les tests de charge graduelle aident à détecter les problèmes de performance potentiels et permettent de prendre des mesures correctives avant la mise en production.
- Sélection de Testeurs Qualifiés : Assurez-vous que les testeurs possèdent les compétences techniques et fonctionnelles nécessaires pour mener à bien les tests de manière rigoureuse. Les testeurs doivent être formés sur les spécificités de SAP S/4HANA Cloud et être capables de comprendre les processus métier pour réaliser des tests pertinents.
- Documenter et Suivre les Problèmes : Tout au long des tests, il est essentiel de documenter soigneusement les problèmes identifiés et de suivre leur résolution. Utilisez un système de suivi pour enregistrer les problèmes et les corrections apportées. Cela permettra de maintenir une traçabilité claire et d'assurer que tous les problèmes sont résolus avant la mise en production.
- Formation des Utilisateurs Finaux : Avant la mise en production, assurez-vous de former les utilisateurs finaux sur le nouveau système. Une formation appropriée et adéquate permettra aux utilisateurs de se familiariser avec les nouvelles fonctionnalités et d'être à l'aise avec le nouveau système. Cela minimisera les problèmes résultant d'une mauvaise compréhension du système et contribuera à une transition en douceur vers SAP S/4HANA Cloud.
Conclusion
Les tests avant la mise en production dans un projet SAP S/4HANA Cloud public sont essentiels pour garantir un système fiable, performant et sécurisé. La planification précoce, l'implication des utilisateurs finaux, la conception de scénarios réalistes, l'automatisation des tests et l'attention portée aux tests de performance et de sécurité sont autant de facteurs clés pour réussir ces tests.
En suivant ces conseils, les organisations peuvent minimiser les risques associés à la mise en production du système SAP S/4HANA Cloud et s'assurer qu'il répond pleinement aux besoins opérationnels de l'entreprise et de ses utilisateurs finaux. La réussite des tests avant la mise en production est essentielle pour assurer une transition fluide et réussie vers le nouveau système ERP.
L’objectif de cet article était de partager avec le lecteur l’importance considérable des tests avant mise en production. Or, on ne devient pas un expert des tests d’un simple claquement de doigt. C’est pourquoi dans son approche méthodologique, Hargos propose en option à ses clients de leur dédier une ressource exclusivement sur cette partie de gestion des tests.
Le rôle de ce consultant affecté aux tests va donc consister à vérifier et valider la bonne tenue de chacune des étapes précédemment décrites. Le consultant va également recenser les difficultés rencontrées, et surtout reporter au comité de pilotage les dysfonctionnements et les corrections à apporter.
Aussi, si vous voulez fiabiliser et réussir votre projet, nous vous invitons à nous contacter pour vous aider sur cette partie sensible de votre projet et trop souvent négligée.
Comprendre les rôles clés de MOE et MOA dans la gestion de projets ERP
MOE et MOA : décryptage de leurs rôles distincts dans les projets ERP
Certains projets d’implémentation d’ERP peuvent être complexes du fait de leur dimensionnement et nécessitent une collaboration étroite entre les différents acteurs impliqués, notamment entre les personnes qui expriment le besoin et les personnes qui mettent en œuvre la solution.
Dans ce cadre, des rôles et des fonctions sont définies pour chaque acteur du projet de façon à organiser celui-ci et permettre une fluidité entre les différentes composantes du projet.
Ces rôles sont associés à des responsabilités précises et clairement définies pour éviter tout malentendu sur le projet. Ces rôles sont ceux du MOE et de l’AMOE d’un côté et ceux du MOA et de l’AMOA d’un autre côté. La relation entre ces acteurs peut parfois être formalisée dans un document nommé le Plan Qualité Projet qui définit les contours du projet les responsabilités de chacun selon la Méthode RACI.
Rôles expliqués : MOE, MOA, AMOE, et AMOA dans le contexte ERP
- MOE (Maîtrise d’œuvre) : Le MOE est responsable de la mise en œuvre technique du projet SAP. Il est chargé de concevoir, réaliser et déployer les solutions SAP dans le cadre du projet. Le MOE doit avoir une expertise technique approfondie sur SAP pour pouvoir réaliser les tâches qui lui sont confiées.
- AMOE (Assistance à Maîtrise d’œuvre) : L’Assistance à Maîtrise d’Œuvre est là pour aider le Maître d’Œuvre dans l’accomplissement de ses nombreuses missions. Pour certains projets, notamment dans l’informatique, il existe même des consultants dédiés AMOE (terme fortement utilisé dans le Conseil). Ce sont des intervenants externes à l’entreprise qui viennent renforcer l’équipe projet en rajoutant de la compétence sur le projet selon les objectifs QCD (qualité, coûts et délais) fixés par le cahier des charges.
- MOA (Maîtrise d’ouvrage) : Le MOA représente le prescripteur du projet. Le MOA est responsable de la partie fonctionnelle du projet SAP. Il est chargé de définir les besoins métier de l’entreprise et de veiller à ce que la solution SAP mise en place réponde à ces besoins. Le MOA est donc chargé de la définition des processus métier, des spécifications fonctionnelles et de la validation des résultats du projet.
- AMOA (Assistance à Maîtrise d’Ouvrage) : L’AMOA est un acteur qui assiste le MOA dans la mise en œuvre du projet. L’AMOA peut être interne ou externe à l’entreprise. Il a pour rôle d’accompagner le MOA dans toutes les étapes du projet SAP, de l’expression des besoins métier à la mise en place de la solution SAP. L’AMOA doit être capable de communiquer efficacement avec le MOA et les MOE / AMOE pour garantir une bonne coordination entre les différents acteurs du projet.
Les rôles du MOA et de l’AMOA peuvent être regroupés d’une part pour définir l’entité qui est responsable de la définition du besoin, les rôles du MOE et de l’AMOE, quant à eux, définissent l’entité qui réalise le besoin exprimé.
Analyse du périmètre d’action : comment MOE et MOA agissent dans les projets ERP
- MOE: Lorsqu’on parle de MOE , on peut désigner aussi bien la fonction (la Maîtrise d’Œuvre) que la personne (le Maître d’Œuvre). Arrêtons-nous un instant sur le MOE en tant que personne. Il est une personne physique ou morale : Chef de projet, Architecte solution, Consultant, Développeur, etc. C’est lui qui dispose des compétences techniques nécessaires à la conception, au chiffrage, à la réalisation et au pilotage d’un projet donné.
Le Maître d’Œuvre est l’interlocuteur privilégié durant toute la durée du projet. En tant que gestionnaire et organisateur du projet, le MOE est le garant de la bonne exécution des tâches demandées par le MOA. Il est chargé de la mise en place technique de la solution SAP.
Il doit être capable de concevoir une architecture SAP adaptée aux besoins de l’entreprise, de réaliser les développements spécifiques, de configurer les modules SAP et de déployer la solution SAP dans l’ensemble du système d’information de l’entreprise. Le MOE doit travailler en étroite collaboration avec le MOA pour garantir que la solution SAP mise en place répond aux besoins de l’entreprise. On peut assimiler le MOE à l’intégrateur de la solution sur le projet. - AMOE : L’Assistance à Maîtrise d’Œuvre est là pour aider le Maître d’Œuvre dans l’accomplissement de ses nombreuses missions. Pour certains projets, notamment dans l’informatique, ce sont des intervenants externes à l’entreprise qui viennent renforcer l’équipe projet sur des sujets nécessitant une compétence particulière. On peut associer l’AMOE à une entité qui accompagne l’intégrateur sur des sujets précis.
- MOA : Le MOA est responsable de la partie fonctionnelle du projet SAP. Il doit travailler en étroite collaboration avec le MOE pour s’assurer que la solution SAP mise en place répond aux besoins métier de l’entreprise. Le MOA doit être capable de définir les processus métier de l’entreprise, de rédiger les spécifications fonctionnelles et de valider les résultats du projet. Le MOA doit également coordonner l’ensemble des acteurs du projet SAP et veiller à la bonne communication entre eux. Généralement, le MOA définit le donneur d’ordre du besoin, soit le client lui-même.
- AMOA : L’AMOA a pour rôle d’assister le MOA dans la mise en place du projet SAP. Il doit être capable de comprendre les besoins métier de l’entreprise et de les traduire en spécifications fonctionnelles compréhensibles par le MOE.
L’AMOA intervient lorsque le MOA estime ne pas avoir les compétences ou le temps pour modéliser les besoins du projet de façon claire et précise et les transmettre au MOE. L’AMOA est généralement représentée par un ou plusieurs consultants qui va assister le MOA dans la définition et la description du besoin.
Dynamique de collaboration : interactions entre MOE/AMOE et MOA/AMOA
Les interactions entre le MOE et le MOA sont cruciales dans la réussite d’un projet SAP. En effet, ces deux acteurs sont complémentaires et doivent travailler en étroite collaboration pour s’assurer que la solution SAP mise en place répond aux besoins métier de l’entreprise. Dans les plus petits projets, cette relation représente directement la relation entre le client (le MOA) et l’intégrateur (le MOE).
Le MOA, c’est-à-dire le client, est intrinsèquement responsable de l’identification et de la description de ses besoins métier. Il doit expliciter les processus métier et ses souhaits de fonctionnement au MOE, autrement dit l’intégrateur qui se charge de la mise en place technique de la solution SAP. Le MOE doit concevoir une architecture SAP adaptée aux besoins de l’entreprise, réaliser les développements spécifiques, configurer les modules SAP et déployer la solution SAP pour l’ensemble des fonctionnalités et des besoins exprimés par le MOA.
Pour que le projet SAP soit un succès, il est primordial que le client et l’intégrateur (le MOA et le MOE) travaillent en étroite collaboration dès le début du projet. Le MOA se doit d’expliquer le plus clairement possible les besoins métier et la culture de l’entreprise au MOE, qui doit alors concevoir une solution SAP adaptée à ces besoins. Dans l’autre sens, il est indispensable que le MOE transmette au MOA les limitations techniques et la « philosophie » de SAP, afin que le MOA puisse faire converger ces désidératas vers une solution fonctionnelle la plus standard.
Pendant les différentes phases d’un projet, le MOA doit valider les livrables réalisés par le MOE (document de conception, paramétrage de la solution, développements spécifiques) et s’assurer qu’ils répondent bien aux besoins métiers exprimés.
En somme, l’interaction entre les couples MOE/AMOE (intégrateur) et MOA/ AMOA (client + cabinet de conseil qui l’accompagne éventuellement) est cruciale dans la réussite d’un projet SAP. Les deux acteurs doivent travailler en étroite collaboration pour s’assurer que la solution SAP mise en place répond aux besoins métier de l’entreprise. Une bonne communication entre le MOE et le MOA est donc essentielle pour garantir la réussite du projet.
Assurer la qualité dans les projets ERP : le rôle clé du Plan Qualité Projet
Le PQP (Plan Qualité Projet) a pour objectif la définition et le suivi des dispositions à prendre pour un projet afin d’en assurer la qualité et d’atteindre les résultats attendus.
À cet effet, le PQP fixe les droits et les responsabilités de chaque partie prenante en vue d’assurer l’atteinte de cet objectif. Ainsi sont déterminés d’un commun accord :
- L’organisation globale du projet quant aux structures à mettre en place ;
- Le Plan de développement détaillé ;
- Le Plan de gestion du projet ;
- La répartition des responsabilités entre les organismes dans la structure,
- Le Plan de développement et le Plan de gestion du projet ;
- Les limites du projet.
Dans la relation entre le MOE et le MOA, le PQP est un outil fondamental pour définir les critères de qualité qui devront être respectés par le MOE lors de la réalisation du projet SAP (Paramétrage, Développements spécifiques, cohérence de l’ensemble). Le PQP est généralement initié par le MOA ou l’AMOA, qui définit les critères de qualité à respecter en fonction des besoins métier de l’entreprise.
Le PQP définit les méthodes et les outils à utiliser pour garantir la qualité des livrables, ainsi que les procédures à suivre pour effectuer les tests et la validation. Le MOE est responsable de suivre les directives du PQP et de fournir des livrables conformes aux critères de qualité établis.
Le PQP peut contenir des exigences de qualité pour les aspects suivants :
- La documentation : Le PQP peut spécifier les types de documents à produire, la liste des documents et la responsabilité associée (décrite dans le chapitre suivant), leur contenu et leur format. Le MOE doit s’assurer que la documentation produite est complète, claire et conforme aux exigences du PQP.
- Le code ou le paramétrage : Le PQP peut spécifier les normes de codage à respecter, les formats de paramétrages ou de nommage des Ordres de Transports (Regroupements de modifications dans SAP) et les tests unitaires à effectuer. Le MOE doit s’assurer que la solution mise en place est cohérente, maintenable et conforme aux normes établies.
- Les tests : Le PQP peut définir les types de tests à effectuer, les critères d’acceptation et les procédures à suivre pour effectuer les tests. Le MOA doit s’assurer que les tests sont réalisés conformément aux exigences du PQP et permettent la validation de la solution mise en œuvre par le MOE de façon objective.
Outil de suivi et de gestion, le PQP est employé tout au long du projet. C’est un document évolutif qui est destiné à être constamment modifié en fonction des circonstances. De nouvelles données y sont intégrées selon une procédure d’actions correctrices, elles-mêmes définies dans ce document. Au terme du projet, le PQP modifié et annoté constituera l’un des documents de résultats du projet.
Optimiser la gestion de projet ERP avec la méthode RACI
Le RACI est un acronyme qui signifie Responsable, Accountable, Consulted, Informed (en français, Responsable, Compte-rendu, Consulté, Informé). C’est une méthode de gestion de projet utilisée pour définir les rôles et les responsabilités de chaque personne impliquée dans un projet. Le RACI permet de clarifier qui fait quoi, qui prend les décisions, qui est consulté et qui est informé.
Le RACI est souvent représenté sous forme de matrice qui croise les activités ou les tâches du projet avec les personnes impliquées. Les colonnes de la matrice sont : Responsable, Accountable, Consulté et Informé. Les lignes représentent les activités ou les tâches à accomplir. Chaque personne impliquée dans le projet est ensuite affectée à une ou plusieurs des quatre catégories RACI pour chaque activité ou tâche.
Voici ce que signifie chaque lettre de l’acronyme RACI :
- Responsable (R) : la personne qui est responsable de la réalisation de l’activité ou de la tâche. C’est la personne qui effectue le travail et prend les décisions nécessaires pour mener à bien la tâche.
- Accountable (A) : la personne qui est responsable de la tâche dans son ensemble. C’est la personne qui a la charge de s’assurer que la tâche est réalisée dans les temps, dans les budgets et selon les spécifications définies.
- Consulted (C) : les personnes qui doivent être consultées pour fournir des informations, des conseils ou un soutien pour la réalisation de la tâche.
- Informed (I) : les personnes qui doivent être informées des résultats de la tâche une fois celle-ci terminée.
L’utilisation d’une matrice RACI aide à clarifier les rôles et les responsabilités de chaque entité impliquée dans un projet. Elle permet de réduire les malentendus et les erreurs de communication qui peuvent survenir lorsqu’il y a confusion sur les rôles et les responsabilités.
Le RACI peut également aider à améliorer l’efficacité du projet en s’assurant que chaque personne est assignée à la bonne tâche en fonction de ses compétences et de son expertise et de son positionnement. Cette méthode est fréquemment utilisée pour définir les rôles de chacun, notamment pour tous les livrables décrits dans un PQP.
Étude de cas : audit et optimisation d'une solution SAP après un rachat d'entreprise
Contexte
Une entreprise récemment rachetée se retrouve avec un site de production équipé de SAP. Hargos est sollicité pour auditer la solution existante et proposer une trajectoire d’évolution.
Mission d'AMOA
Objectif
Audit de la solution SAP en place et élaboration d'une stratégie d'optimisation.
Durée
25-30 jours sur 2 mois
Livrables
Rapport d'audit de 90 pages présenté au comité de direction
Points clés de l'audit
- Analyse des processus actuels
- Évaluation du respect des bonnes pratiques
- Examen des développements spécifiques et produits tiers
- Identification des bons et mauvais usages de la solution
- Évaluation de la qualité des données de base
Recommandations et roadmap
- Bonnes pratiques à conserver
- « Quick wins » pour des résultats rapides
- Alternatives logicielles avec planning et budget
Options proposées
Refonte du système actuel : stabilisation et nettoyage
Migration vers une version plus récente (brownfield)
Refonte totale avec une version récente (greenfield)
Passage à une version Cloud de SAP
Résultat
Le client a choisi une orientation et a confié à Hargos une mission d’AMOE pour le pilotage du projet et la mise en place des processus adaptés.
Chronologie
Audit AMOA
2 mois
Prise de décision client
1,5 mois
Mise en place
9 mois
Synthèse et perspectives : tirer le meilleur des rôles de MOE et MOA dans l’ERP
La bonne conduite d’un projet ERP s’appuie sur la définition claire et précise des rôles de chacun lors des différentes phases qui le composent. La relation entre les (A)MOA et (A)MOE est un critère essentiel de réussite.
La définition et les règles associées à cette relation peuvent être décrite dans un PQP pour bien définir et expliciter les rôles et responsabilités de chaque acteur tout au long du projet.
Chez Hargos, nous avons la capacité et l’expertise pour accompagner tous les projets en tant que MOE et AMOE, c’est notre métier. Nous avons aussi les compétences pour accompagner les entreprises nécessitant une aide pour leur maitrise d’ouvrage, c’est-à-dire d’endosser le rôle d’AMOA sur un projet.
Faq
Questions fréquentes : rôles MOE et MOA dans les projets ERP
Notre équipe est prête à vous accompagner à chaque étape pour une gestion de projet optimale et sur mesure.
Pour bénéficier de notre expertise en MOE et AMOA et assurer le succès de vos projets ERP, contactez Hargos dès aujourd’hui.
MOE signifie Maîtrise d’Œuvre, tandis que MOA signifie Maîtrise d’Ouvrage. Dans le contexte des projets ERP :
- La MOA représente le client ou le commanditaire du projet. Elle est responsable de la définition des besoins et des objectifs du projet.
- La MOE est chargée de la réalisation technique du projet. Elle met en œuvre la solution ERP selon les spécifications de la MOA.
Les principales responsabilités de la MOA incluent :
- Définir les objectifs et les besoins du projet
- Valider les spécifications fonctionnelles
- Prendre les décisions stratégiques
- Allouer le budget
- Valider les livrables à chaque étape du projet
- Assurer la communication avec les parties prenantes internes
La MOE est responsable de :
- Concevoir la solution technique répondant aux besoins de la MOA
- Réaliser le paramétrage et les développements spécifiques de l’ERP
- Gérer les aspects techniques du projet (architecture, interfaces, migrations)
- Effectuer les tests techniques
- Assurer le déploiement de la solution
- Fournir le support technique post-implémentation
AMOA (Assistance à Maîtrise d’Ouvrage) : elle assiste la MOA dans la définition des besoins, la rédaction des cahiers des charges, et le suivi du projet. L’AMOA apporte une expertise métier et méthodologique.
AMOE (Assistance à Maîtrise d’Œuvre) : elle soutient la MOE dans la réalisation technique du projet. L’AMOE apporte des compétences techniques spécifiques, comme l’expertise sur certains modules de l’ERP.
Une collaboration efficace entre MOE et MOA implique :
- Une communication claire et régulière
- Des réunions de suivi fréquentes
- Une définition précise des rôles et responsabilités
- Un processus de validation des livrables bien défini
- Une gestion conjointe des risques et des problèmes
- Une flexibilité mutuelle pour s’adapter aux changements
Les défis courants incluent :
- Divergences dans la compréhension des besoins : organiser des ateliers de travail communs pour aligner les visions.
- Difficultés de communication : mettre en place des canaux de communication efficaces et des réunions régulières.
- Gestion des changements de périmètre : établir un processus formel de gestion des changements.
- Conflits sur les priorités : définir clairement les critères de priorisation dès le début du projet.
Pour choisir une bonne MOE, considérez :
- Son expérience dans des projets ERP similaires
- Sa connaissance de votre secteur d’activité
- Ses certifications et partenariats avec l’éditeur de l’ERP
- Sa méthodologie de gestion de projet
- La qualité de ses références clients
- Sa capacité à comprendre vos besoins spécifiques
Le Plan Qualité Projet (PQP) :
- Définit les rôles et responsabilités de chaque partie
- Établit les processus de validation et de contrôle qualité
- Fixe les critères d’acceptation des livrables
- Détermine les méthodes de communication et de reporting
- Aide à garantir que le projet répond aux attentes de qualité de la MOA
La méthode RACI (Responsible, Accountable, Consulted, Informed) permet de clarifier les rôles :
- Responsible : Qui fait le travail ? Souvent la MOE pour les tâches techniques.
- Accountable : Qui est responsable du résultat ? Généralement la MOA pour les décisions finales.
- Consulted : Qui doit être consulté ? Les experts métier de la MOA, par exemple.
- Informed : Qui doit être informé ? Les parties prenantes du projet.
Faire appel à une entreprise spécialisée comme Hargos offre plusieurs avantages :
- Expertise technique et fonctionnelle approfondie
- Expérience dans la gestion de projets ERP complexes
- Méthodologies éprouvées pour assurer le succès du projet
- Capacité à combler les lacunes entre la MOE et la MOA
- Flexibilité pour s’adapter aux besoins spécifiques du projet
- Accès à un réseau d’experts et de ressources spécialisées
Comment présenter un projet ERP à votre comité de direction ?
Cet article a pour ambition de vous donner quelques pistes de réflexions qu’il conviendra d’adapter à votre contexte particulier. Nous n’avons pas l’ambition de vous dicter le contenu de votre argumentaire pour justifier un projet ERP au sein de votre entreprise. En revanche, nous allons vous partager notre vécu et nos retours d’expérience pour vous donner quelques pistes qu’il nous semble intéressant d’explorer.
Introduction
Votre entreprise a initié un projet ERP et vous êtes mandaté pour présenter celui-ci à votre comité de direction. Or, présenter un projet ERP à votre comité de direction mérite une préparation professionnelle car sans l’aval de votre comité de direction votre projet ne verra jamais le jour. Dans un premier temps, les motifs qui justifient ce projet doivent être parfaitement clairs pour vous.
En général, un projet ERP est motivé par deux raisons principales : la recherche de gains de productivité ou la réponse à des événements exceptionnels qui ponctuent la vie d’une entreprise (croissance externe, nouveaux produits, fusion/acquisition, nouvelles normes, etc).
Dans cet article nous allons essayer de vous donner quelques pistes pour vous aider à construire une démarche pour convaincre votre comité de direction de se doter d’un nouvel outil de gestion.
La recherche de gains de productivité
Le projet de votre entreprise est donc motivé par une recherche d’amélioration de son organisation et de ses processus pour mieux produire, et de façon plus rentable. Ainsi, on pourrait résumer votre projet en affirmant que le nouvel ERP est un outil au secours de la productivité de votre entreprise.
A noter que nous rencontrons souvent des entreprises qui initient un projet ERP pour pallier la défaillance de leur système actuellement installé.
Défaillances dues à un logiciel en fin de vie plus maintenu par l’éditeur, à un système non suivi car pas ou peu de compétences disponibles pour gérer le système, ou un programme développé en interne et un responsable parti depuis à la retraite avec ses connaissances.
Dans ces cas assez fréquents au sein des PME on considère alors que l’entreprise concernée est également en recherche de gains de productivité avec l’acquisition d’un nouveau système de gestion.
Le diagnostic
Dans cette situation fréquemment rencontrée, vous devrez forcément adopter la démarche la plus simple possible pour convaincre votre comité de direction d’avaliser le projet. Ainsi, l’approche par le « story telling » (vous devrez raconter une histoire) permettra d’impliquer directement votre comité de direction dans votre démarche, même si aucun des participants ne sera utilisateur de l’ERP. L’histoire que vous allez dérouler doit s’appuyer sur les résultats d’une phase d’audit que vous aurez préalablement menée en interne auprès des différents services, permettant d’organiser la « défense » de votre projet.
L’objectif de cette démarche se divise en deux grandes parties :
- Démontrer concrètement que les outils actuellement utilisés sont mal adaptés aux enjeux métiers de votre entreprise
- Lenteur,
- Manque de fiabilité,
- Saisie complexe,
- Fonctionnalités insuffisantes, etc…
- Et il faudra également savoir susciter l’empathie du comité de direction à l’égard des utilisateurs de votre solution actuelle qui ne travaillent pas avec les bons outils.
Pour mieux illustrer notre propos, nous pouvons imaginer que nous déroulions le récit du traitement d’une commande dans le système d’information actuel par exemple. Au cours de ce récit on s’appliquera alors à donner le détail des erreurs et des pertes de temps auxquels les utilisateurs sont confrontés avec la solution actuellement utilisée. On insistera bien entendu sur les multiples re-saisies entre les devis, les commandes, les factures, les stocks, etc. Il faudra également recenser les interfaces coûteuses avec des solutions externes et mettre l’accent sur les dysfonctionnements et les bugs identifiés.
Est-ce que le process, tel qu’il est aujourd’hui modélisé dans le système d’information, ne prête pas le flanc à des erreurs humaines (mauvaise communication entre services, erreurs de saisies ou erreurs d’interprétation) ? Et enfin, il faudra mettre l’accent sur la puissance des reporting de l’outil actuel et vos capacités internes à créer de nouvelles interrogations de la base.
Il nous semble évident que ces constats ne se feront pas sur la base de simples ressentis. C’est pourquoi il est important que vous travailliez sur un audit d’organisation en amont de votre présentation au comité de direction. Cet audit vous permettra ainsi de décrire la situation actuelle en vous appuyant sur des éléments factuels et chiffrés. Vous vous appliquerez à valoriser le temps passé par vos collaborateurs sur des tâches avec peu ou pas de valeur ajoutée. Ensuite, il sera facile de chiffrer le coût de ces activités chronophage pour votre entreprise.
En résumé, il faut être concret et ne pas hésiter à appuyer là où le bât blesse…
À la fin de votre démonstration, il est désormais clair pour vos interlocuteurs que la situation que vous venez de décrire ne peut plus durer. Mais comment la résoudre ? Voici venu le moment des préconisations.
Après le diagnostic, le traitement !
Une fois le ou les diagnostics posés, il conviendra de présenter un projet mature au comité de direction. Il est donc important que vous ayez une vision claire des objectifs à atteindre. A ce stade, on ne parle pas encore de faire le choix d’un outil mais simplement d’identifier distinctement les enjeux et objectifs à atteindre pour chacune des fonctions concernées par votre diagnostic.
L’objectif de cette étude consistera donc à mettre en exergue et valoriser les gains de temps qu’un nouvel outil pourraient apporter. Par exemple, une illustration pourrait être de recenser les modes opératoires mis en place par les utilisateurs pour récupérer des informations et les mettre en forme. Est-ce qu’un nouvel outil qui centralise toutes les informations pourrait nous faire gagner en efficacité sur ces extractions ?
Dans un troisième temps, vous aurez à cœur de trier les optimisations possibles par ordre de priorité pour votre entreprise et vous proposerez la mobilisation d’une équipe à affecter au projet. Toutes ces étapes vous permettront alors de valoriser les gains attendus par un nouvel outil. C’est précisément ce que nous appelons le ROI (Return On Investment) ou retour sur investissement.
Les situations particulières au sein de l’entreprise
Dans ce deuxième cas de figure, le projet n’est plus motivé par la simple recherche de gains de productivité mais par des événements internes ou externes à l’entreprise qui vont vous contraindre à une réorganisation.
On pense à l’acquisition d’une nouvelle société, à une opération de fusion ou à un Carve-Out. On peut également imaginer une organisation qui est totalement repensée à la suite d’une pandémie comme celle que nous avons connu récemment.
Quels changements au sein de l’écosystème contraignent à repenser son SI ?
Notre monde change extrêmement rapidement aujourd’hui. Souvent de nouvelles annonces, de nouveaux événements, ou des considérations sociétales peuvent contraindre les entreprises à repenser leur modèle pour s’adapter.
Nous pouvons citer par exemple la mort annoncée du moteur thermique dans le monde de l’automobile. On peut également évoquer la fin du tout hydrocarbure ou la crise énergétique que nous sommes en train de traverser.
Bref, pleins d’éléments qui peuvent directement ou indirectement influer sur une organisation et l’obliger à repenser son positionnement marché.
Ces opérations sont souvent structurantes dans la vie d’une entreprise et implique la remise en question des process et de l’organisation. L’intégration de nouveaux sites dans l’organigramme, l’ajout ou la suppression de lignes de produits, la réorganisation complète de toute une chaîne logistique qui est devenue obsolète, etc génère le besoin d’équipement d’un nouvel outil informatique capable d’aider au pilotage.
Ainsi, lorsqu’une entreprise doit se réinventer (mot très à la mode en ce moment grâce aux réseaux sociaux) elle doit souvent repenser son organisation et son modèle. Or, repenser son modèle implique pour l’entreprise de savoir s’entourer des éléments (internes et/ou externes) qui sauront se projeter dans la future organisation pour valoriser les fameux retours sur investissements recherchés dans tout projet industriel.
Comment changer son modèle ?
Un changement de modèle nécessite de travailler en étroite relation avec la direction générale qui va insuffler ce vent nouveau sur l’organisation. En effet, les dirigeants de l’entreprise ont identifié les événements qui perturbent ou impacteront le développement de leur société.
Face à ce constat des décisions doivent être prises. S’équiper d’un nouveau système d’information est souvent une piste étudiée dans ce processus de réingénierie.
A ce niveau de l’étude, un travail de réflexion devra être mené avec la direction générale. En effet, les enjeux et objectifs de la nouvelle stratégie de l’entreprise devront impérativement être partagés en toute transparence avec l’équipe chargée de l’étude du projet.
La connaissance des objectifs doit permettre alors de rédiger une feuille de route et inscrire le projet dans une trajectoire. En effet, pour que le projet soit réussi et donc, pour que nous puissions argumenter son bien-fondé, il sera impératif de déterminer une cible à atteindre.
La définition d’une nouvelle stratégie et l’impact d’un nouveau système d’information pour piloter cette réorganisation implique de pouvoir prendre de la hauteur. Nous serons alors presque dans la peau d’un entrepreneur et devrons alors valoriser les nouveaux process à mettre en place.
En d’autres termes, l’équipe en charge de l’étude va devoir travailler sur un business plan pour identifier les leviers de valeurs d’un nouveau système d’information. Par exemple, la mise en place d’un process de eCommerce va potentiellement augmenter les ventes de 15% mais implique la mise en place d’une équipes marketing dédiée au numérique.
Autre exemple, l’externalisation des process logistiques sous-entend une contractualisation avec un prestataire qui portera la responsabilité des retards de livraison et influera donc sur nos flux de gestion des réclamations clients.
Toute dépense doit donc être un investissement. Tout investissement doit donc conduire au calcul d’un retour sur investissement (ROI).
La démarche de l’étude ?
Ainsi, aligner une nouvelle stratégie d’entreprise avec un nouveau système d’information implique de se discipliner et de respecter plusieurs étapes clés pour projeter l’entreprise dans une solution durable.
La première étape va donc consister à clairement exprimer la cible à atteindre et donc les besoins qui en découlent.
Ensuite, dans une seconde étape, il conviendra de clairement identifier les processus à déployer, à optimiser ou à automatiser pour mettre en place cette nouvelle stratégie. Cette phase de l’étude nécessitera donc de savoir se projeter et savoir imaginer la future organisation.
Cependant, il ne faudra pas oublier que nous ne partons pas d’une feuille blanche et dans cette perspective il faut impérativement assurer le quotidien. Il faut donc prendre en compte les process déjà existants dans notre projection.
Il ne faut jamais perdre de vue l’objectif de cette étude : nous devons convaincre notre comité de direction de libérer les ressources financières et humaines pour initier un projet.
Le changement doit donc être acceptable, mesurable et atteignable. En d’autres termes, il faudra savoir promouvoir l’évolution plutôt que la révolution et savoir s’intégrer dans un système déjà existant.
Lorsque tous ces éléments seront parfaitement identifiés et formalisés au sein d’un document qui aura été validé par vos collègues et managers, il conviendra de réfléchir à un plan projet détaillé.
En effet, l’arrivée d’un nouveau système d’information devra s’inscrire du mieux possible dans le calendrier de votre entreprise. Il faudra alors se poser les questions sur l’opportunité de choisir telle ou telle date pour le lancement du projet et qui pénalise au minimum l’activité quotidienne de notre activité.
A cette étape il conviendra également de réfléchir à une équipe projet. Il est important de préparer une équipe de projet compétente pour gérer l’implémentation de l’ERP. Assurez-vous que l’équipe est bien formée et qu’elle possède les compétences nécessaires pour gérer les différentes étapes du projet.
Enfin, la dernière étape de notre étude va consister à énumérer le plus objectivement possible les avantages pour l’entreprise d’un nouvel outil de gestion : réduction des coûts, amélioration de l’efficacité, meilleure prise de décision, suppression des tâches répétitives, etc.
Toutefois, il ne faudra pas non plus occulter les difficultés que va pouvoir engendrer un tel projet : mobilisation de moyens humains et financiers, désorganisation temporaire des services, ruptures de services dans certaines phases du projet, pertes financières possibles, etc.
Il reste important d’être transparent sur les risques liés à l’implémentation d’un ERP et de présenter les moyens de les gérer. Cela montrera à votre comité de direction que vous avez bien réfléchi au projet et que vous êtes préparé à faire face aux défis qui se poseront
Conclusion
En conclusion, si vous suivez ces étapes, vous serez alors en mesure de présenter efficacement votre projet ERP à votre comité de direction et de convaincre ses membres de l’importance de mettre en place un système ERP adapté à votre entreprise et à ses ambitions.
Et surtout, vous saurez emporter l’indispensable adhésion de votre comité de direction pour la réussite de votre futur projet.
Hargos, en tant qu’intégrateur spécialiste SAP à destination des PME, sait accompagner ses clients dans ce type de démarche. Ainsi, Hargos propose toujours dans son approche une mise en œuvre raisonnable qui ne met pas en péril l’activité commerciale de ses clients.
La méthodologie utilisée par Hargos sur de nombreux projets a été spécifiquement pensée pour des PME avec des ambitions de croissance fortes.
Cette méthodologie met l’accent sur l’efficacité et le meilleur ROI possible pour atteindre ensemble des objectifs raisonnables et discutés en amont.
Solution Cloud versus solution on Premise
Cet exposé ne se veut pas exhaustif et a pour objectif de vous donner un rapide aperçu des principales différences notables entre l'informatique sur site (dite On Premise ou On Prem) et l'informatique dans le nuage (ou dans le Cloud).
Maîtriser la reprise de données pour une transition ERP réussie
Au premier abord, la reprise de données pour la mise en place d’un ERP semble facile ; c’est un simple transfert des données d’un système A vers un système B. Mais le projet peut s’avérer beaucoup plus compliqué que ce simple transfert et nécessiter une approche méthodique et réfléchie pour garantir la réussite de cette reprise des données.
Quelle méthodologie projet pour intégrer un ERP avec succès et soutenir sa transformation ?
S'équiper d'un nouveau système d'information
Votre entreprise a décidé de s’équiper d’un nouveau système d’information. Ainsi, après une première étape de sélection, un outil et un intégrateur ont été choisi pour vous accompagner sur ce projet. Et désormais, il va falloir se mobiliser pour installer ce nouvel outil. Mais que sous-entend réellement cette mobilisation ? Et comment s’organiser au mieux pour que ce projet ne désorganise pas totalement votre société qui doit continuer à assurer son business ?
Méthodologie de projet
Cet article n’a pas vocation à donner une recette miracle qui garantit 100% de réussite sur un projet d’intégration ERP. Toutefois, nos très nombreuses expériences de gestion de projet nous donnent un recul suffisant pour vous partager quelques bonnes pratiques à ne jamais perdre de vue.
La première étape d’un projet ERP va consister à former une équipe de projet.
Formation de l'équipe projet
Cette équipe va être constituée de-quelques consultants spécialistes de leur domaine chez l’intégrateur, de membres de votre entreprise, spécialiste de leur métier, d’un chef de projet côté client et d’un chef de projet côté intégrateur. Il sera également important à ce stade que le comité de pilotage, constitué des instances dirigeantes côté client, soit clairement identifié par l’ensemble des acteurs.
Maintenant que l’équipe projet est embarquée sur le projet, on va aborder un point qui nous semble primordial pour la réussite de votre projet : le partage d’information.
Le partage d'information
En effet, les premiers ateliers qui réunira l’ensemble des acteurs devra impérativement :
- Expliquer ce qu’est un ERP ?
- Détailler le périmètre du projet
- Partager les objectifs du projet
- Expliquer la méthodologie appliquée
- Attribuer et détailler le rôle de chacun des acteurs
- Partager le vocabulaire employé
Pourquoi expliquer les concepts de base d’un ERP ? Le projet s’articule autour d’un outil intégré qui va donc faire interagir toutes les fonctions de l’entreprise.
Si chacun comprend et visualise ces interactions, nous faciliterons alors la notion d’intégration de l’outil.
Il est important que chaque utilisateur clé du groupe de projet puisse sortir de son strict domaine de compétence, à savoir son métier ou son service, pour raisonner en transversalité sur toute l’organisation de l’entreprise.
En effet, il est important de comprendre qu’un mauvais choix entraînant une rupture de stock par exemple, aura des conséquences sur la gestion des stocks bien sûr, mais aussi sur la fabrication, sur les achats, sur le commerce et sur les finances.
Il faut également garder à l’esprit que notre projet est contraint budgétairement et dans le temps. Pour respecter ces enveloppes, un périmètre a été arrêté au moment de la contractualisation du projet.
Ce périmètre doit donner un détail des fonctions métier couvertes. Il faut que chacun des acteurs soit parfaitement informé de ce périmètre et se concentre sur celui-ci lors de la mise en œuvre. Bien entendu il va de soi que ce périmètre pourra évoluer en même temps que des besoins nouveaux apparaitront, mais cette évolution se fera au prix d’une renégociation commerciale.
Garder à l'esprit les objectifs du projet
Les acteurs du projet doivent également garder les objectifs du projet comme cible à atteindre tout au long de leurs ateliers. Ces objectifs ne doivent pas être différents entre le client, l’intégrateur et l’éventuel AMOA qui peut vous assister sur le projet. En effet, nous avons déjà vécu des projets où ces objectifs n’étaient pas clairs pour les acteurs et les conséquences ont été très chronophage.
Apprentissage de la méthodologie de projet
Enfin, le dernier point à ne pas négliger non plus est l’apprentissage de la méthodologie de mise en œuvre. Dans cette partie il faudra être très précis sur le rôle de chacun, sur l’organisation du projet et sur les tâches précises qui seront attribuées à chacun des intervenants.
En effet, le métier de key user (ou utilisateur clé) n’existe pas. Ainsi, chacun abordera le projet avec sa propre vision métier en n’ayant aucune idée précise de ce qu’il aura à faire et comment le faire.
De plus, chacun de nous a tendance à utiliser son propre vocabulaire métier. C’est pourquoi, nous proposons également de mettre en place dès le début du projet un glossaire des expressions, acronymes et autres éléments de langage qui seront propres au projet pour que chacun se comprenne.
En résumé, un projet ERP est avant tout porté par une bonne communication entre les différents acteurs qui composent l’équipe de mise en œuvre. Du chef de projet aux utilisateurs finaux, en passant par les instances de direction, les objectifs doivent être clairs et transparents pour tout le monde. Tout le monde doit avoir une vision éclairée de l’avancement du projet et des difficultés rencontrées.
Le Key User : un rôle clef
C’est pourquoi, chez Hargos, nous avons développé le manuel du Key user, qui propose un outil de suivi de projet spécifiquement dédié aux intervenants et qui servira de pense-bête tout du long de la mise en œuvre de la solution.
Ce manuel partage tous les fondamentaux à connaître pour réussir le projet et pour qu’à aucun moment le client ne se sente dépassé par les travaux qui lui sont demandés : que dois-je tester ? Comment tester ? Quel tableau de suivi je dois remplir et pourquoi ? Qui décide ? Que signifie telle ou telle expression employée par les consultants ? Etc…
Une fois ces informations partagées et comprises par l’équipe projet, il conviendra alors d’entrer dans le vif du sujet de la mise en œuvre de la solution. A ce stade, deux approches sont traditionnellement proposées : la méthode en V ou plus récemment (et à la mode en ce moment) la méthode agile.
Méthode en V
La méthode en V est plutôt réservée à de très gros projet d’envergure qui vont nécessiter beaucoup de travail de préparation.
Cette méthode consiste à découper le projet en 5 phases :
- conception générale,
- conception détaillée,
- réalisation,
- tests d’intégration et
- démarrage.
Cette approche est plutôt dans une logique d’adaptation du produit à l’organisation en place.
La méthode privilégiée par Hargos va à contresens de la méthode en V. En effet, nous faisons la promotion du respect du standard dans la solution en poussant l’organisation à s’adapter aux bonnes pratiques développées dans SAP.
Méthode Agile
Cette approche n’est pas totalement agile car l’agilité est plutôt réservée aux développements de programme spécifiques.
Néanmoins la philosophie de l’approche méthodologique de Hargos reste dans une logique approchante.
Ainsi, il sera important que chacun des acteurs identifie la raison d’être des process existants et qu’il imagine une nouvelle façon de travailler pour faire correspondre ces flux au mode de fonctionnement SAP.
Attention, tous les process ne seront pas à repenser et souvent on s’aperçoit que nos clients respectent de nombreuses bonnes pratiques. Auquel cas la mise en place de l’outil est facilitée. Cette démarche nous permet ainsi de nous concentrer uniquement sur les écarts, sur les données (cf article de blog sur ce sujet) et sur la stratégie de démarrage de la solution.
Conclusion
Enfin, en conclusion, j’espère que à la lecture de cet article vous avez compris qu’un projet SAP ne doit surtout pas être abordé comme un projet informatique mais bel et bien comme un projet de transformation de vos organisations.
De plus, SAP va permettre à votre entreprise d’élargir son champ des possibles avec une multitude de fonctions à disposition qui vous engagerons certainement sur des chemins que vous n’imaginez pas possible aujourd’hui :
- IA, deep learning, planning prédictif, logistique business network, field services, intégration du réseau de partenaires, etc.
Le fait que nous vous poussions à respecter le standard de l’outil facilitera d’autant plus la mise en œuvre de nouveaux services tout en simplifiant l’administration de vos systèmes.
En résumé, un projet ERP réussi est un projet de transformation de l’entreprise qui est compris par l’ensemble des intervenants sur le projet, qui est évolutif dans le temps et avec une solution maîtrisée. C’est ce à quoi nous croyons fermement chez Hargos et pour lequel nous nous battons tous les jours : Notre mission : rendre accessible SAP S/4 HANA aux PME