MOE MOA quelles différences et utilité pour un projet chez Hargos

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.
MOE et MOA une collaboration indispensable pour mener à bien un projet SAP
MOE et MOA une collaboration indispensable pour mener à bien un projet SAP

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.
Les périmètres d'actions entre AMOA et MOA
Les périmètres d'actions entre AMOA et MOA

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 (Plan Qualité Projet) définit les méthodes et les outils à utiliser pour garantir la qualité des livrables
Le PQP (Plan Qualité Projet) définit les méthodes et les outils à utiliser pour garantir la qualité des livrables

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.

La méthode RACI utilisée pour définir les rôles et les responsabilités de chaque personne impliquée dans un projet.
La méthode RACI utilisée pour définir les rôles et les responsabilités de chaque personne impliquée dans un projet.

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.

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 compose. 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ée à 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.

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.

Notre équipe est prête à vous accompagner à chaque étape pour une gestion de projet optimale et sur mesure.


Illustration ERP SAP S/4 HANA

QM de SAP S/4 HANA intégrez la qualité dans vos process

Le module QM permet aux entreprises de gérer tous les aspects de la qualité dans leur ERP. Il permet d’avoir la maîtrise sur les processus liés à l'assurance qualité depuis la gestion des défauts et des non-conformités jusqu’à la traçabilité.

Lire la suite


proposer erp comite direction Hargos - HARGOS

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.

Discussion autour d'un projet Hargos

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.

Imaginer process changement ERP avec Hargos

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.

Repenser son SI avec Hargos

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

Equipe projet changement ERP Hargos

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.


Bandeau SAP S/4 HANA Gestion entrepot

Gestion des entrepôts dans SAP : quelle fonction (ou module) choisir ?

Introduction à la gestion d'entrepôts avec SAP

Beaucoup de clients nous parlent de WM, de WMS, de gestion d’entrepôts, de eWM, etc… Mais derrière tous ces acronymes barbares, que se cache-t’il précisément ?

Dans cet article, nous allons vous donner un rapide aperçu de ces solutions SAP et de ce qu’elles sous-entendent. Bien entendu, cet article ne fera qu’un rapide survol des différentes solutions sans entrer dans trop de détails techniques pour vous permettre de vous forger une opinion sur leur profondeur fonctionnelle.

Avec S/4 Hana, SAP fait évoluer son offre « WMS » (Warehouse Management System).

L’offre se décline en trois grands blocs :

  • Stock Room Management : Gestion avancée des stocks
  • Extended Warehouse Management – version Basic : Gestion très avancée des stocks
  • Extended Warehouse Management – version Advanced : Gestion experte des stocks

Alors quelles sont les différences et comment s’y retrouver ?

Nous retrouvons dans le schéma ci-dessous les différents degrés de gestion des stocks proposés par SAP à partir de 2022 !

Tout en haut de la pyramide, il y a la gestion des stocks « minimalistes » (Material Management ou SAP MM pour les intimes).

Cette brique permet de gérer les stocks en quantité et en valeur en ne partageant aucune information sur la localisation géographique. Par exemple, le système ne vous indiquera pas avec précision ou trouver vos palettes dans votre entrepôt. Cette brique est alimentée par défaut dans SAP car elle est au cœur de l’ERP.

Nous n’allons pas nous attarder sur cette partie car elle n’a finalement que peu d’intérêt vis-à-vis du besoin de gestion des emplacements

Pour compléter cette composante de base et afin de disposer d’un WMS intégré à l’ERP SAP, on dispose de trois alternatives ; évoquées en préambule.

Schéma SAP Gestion des entrepots

Stock Room Management (SRM)

Cette solution proposée par SAP avec S/4 HANA est « l’ancien » WM de la version ECC* de SAP.

L’éditeur a choisi de garder ce module pour simplifier les conversions de ECC vers S/4 HANA pour les clients utilisant déjà SAP WM.

La conservation de ce module permet de se concentrer sur la conversion des autres fonctionnalités (vente, achat, production, finance, …) et de rester isopérimètre sur la partie « gestion des entrepôts ».

De plus, ce module est éprouvé, stable et peut déjà répondre à beaucoup de problématiques « stock ».

Les points importants à noter sont :

  • SAP ne fera plus évoluer Stock Room Management car il n’est pas identifié comme produit stratégique.
  • Stock Room Management n’a pas d’interface Fiori.

Extended Warehouse Management (EWM) Basic vs. Advanced

La partie EWM n’est pas nouvelle. Ce module existait déjà sous ECC6 mais sous forme de système décentralisé ; c’est-à-dire complétement autonome.

SAP le proposait comme une composante additionnelle qui venait s’interfacer avec l’ERP.

Il faut savoir que EMW existe depuis 2007 ! SAP l’avait développé à l’époque pour ses clients Caterpillar et Ford ! Depuis, cette solution évolue constamment pour proposer toujours plus de fonctionnalités.

Avec l’arrivée de S/4 HANA, EWM est totalement intégré au cœur de l’ERP comme les autres fonctionnalités de ventes, achats, finances, etc … il devient le produit stratégique de SAP pour la gestion des entrepôts !

Cette offre se décline en deux parties :

EWM Basic : version embarquée nativement dans S/4 Hana

EWM Advanced : version avec des fonctions supplémentaires (et soumise à licence supplémentaire)

Dès la version « Basic », les fonctionnalités sont beaucoup plus avancées que SRM.

Par exemple, celles que l’on peut retenir :

  • Des étapes de gestion plus importante : jusqu’à six étapes (contre 2 pour SRM)

Ces étapes peuvent être : déchargement, inspection qualité, déconsolidation, consolidation, rangement, …)

  • Une intégration native avec les dernières technologies (RFID -Radio-identification ou radio frequency identification, terminaux mobiles, etc…)

Les points importants à noter sont que EWM est :

# Stratégique pour SAP

# Intégré au sein de l’ERP

# Possède les dernières avancées fiori

# Intègre des fonctions WMS étendues

# Gère nativement les connexions avec les dernières technologies

Cas d'usage et comparaisons

Tableau des fonctionnalités SAP S/4 HANA gestion des entrepots

En complément des points vus dans les paragraphes précédents, nous avons récapitulé dans ce tableau les grandes différences en termes de fonctionnalités pour les trois alternatives.

On voit que l’intégration native de technologies comme la RFID ou la sélection vocale (Voice picking) est l’apanage de EWM.

La gestion des ressources consiste à piloter dans le système d’information les équipements logistiques (chariots élévateurs par exemple) et les équipes.

Dans les services à valeur ajoutée, nous allons trouver par exemple la fonctionnalité de « Réarrangement ». Cette fonction permet de modifier la cartographie de l’entrepôt en fonction de la saison afin d’optimiser les trajets. Ainsi, dans l’univers de la distribution automobile, on pourra mettre en bord d’allée les pneumatiques « pluie » en période hivernale. Inversement, les pneumatiques « été » seront placés à ces mêmes emplacements lors de la période estivale.

Le cross docking : permet de gérer en automatique le transbordement du quai de réception au quai d’expédition sans passer par une étape de stockage.

La fonction vague de prélèvement permet de mutualiser les préparations de commandes selon différents critères. Ainsi, les ordres de préparations peuvent être déterminés pour toutes les commandes devant être livrées dans un département précis.

Conclusion

Tous les clients SAP ont des contraintes différentes pour aborder la gestion de leurs stocks. C’est pourquoi SAP propose aujourd’hui plusieurs niveaux de gestion. Ainsi, en fonction de vos impératifs mais également en fonction de vos ambitions projets, vous aurez le choix entre plusieurs niveaux de fonctionnalités au sein de SAP S/4 HANA.

Toutefois il est important de noter que vos choix ne seront jamais fermes et définitifs. En effet, il est tout à fait envisageable de commencer son aventure SAP avec les simples fonctions SRM (ou SAP MM) puis, dans un second temps, déployer les fonctions EWM pour affiner votre gestion d’entrepôt.

Hargos, dans son approche pragmatique projet, aime à travailler en plusieurs lots pour aborder ces problématiques. Ainsi, nous saurons gérer vos stocks « manuellement » dans un premier lot, puis ensuite déployer les outils de code-barres ou de RFID- pour automatiser ces tâches manuelles.

Vous souhaitez en savoir plus sur la gestion des emplacements dans SAP ? Besoin de formation, implémentation, support, contactez-nous, nos consultants Experts se feront un plaisir de répondre à vos questions.


SURTECO avec HARGOS pour installer SAP S/4 HANA

SURTECO France bascule vers l’ERP Intelligent SAP S/4HANA

SURTECO France démontre qu’un ERP Intelligent SAP S/4HANA a du sens pour une PME de taille modeste. L’industriel a décidé de franchir le pas, avec l’appui d’Hargos. Un projet réussi, qui pourrait inspirer d’autres filiales du groupe SURTECO GmbH.

Lire la suite


Cloud versus On Premise

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).

Lire la suite


ERP SAP S/4 HANA Hargos

Groupe Hisi transforme ses processus avec l’ERP Intelligent SAP S/4HANA

Adopter un ERP Intelligent SAP S/4HANA en mode fit-to-standard est un véritable défi pour une PME habituée à une certaine liberté dans la gestion de ses processus. Ce défi, Groupe HISI l’a relevé, et réussi, avec l’aide de son partenaire Hargos.

Lire la suite


Facture électronique

Généralisation de la facturation électronique pour les entreprises : Serez-vous prêt ?

Les factures dématérialisées se sont installées depuis plusieurs années dans notre quotidien. Aujourd’hui, un particulier peut même recevoir la facture du supermarché directement sur son email. Cette tendance s’est accélérée depuis 2 ans avec la situation sanitaire.

L’état a la volonté de généraliser la facturation électronique pour tous les échanges entre les entreprises, qu’elles soient du secteur privé ou publique.

Lire la suite


Reprise des données SAP

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.

Lire la suite


doctor scientist conducting clinical experiment using micropipette - HARGOS

LIMS ou ELN ? Que choisir ?

Pour rester compétitifs dans le monde d’aujourd’hui, tous les laboratoires ont besoin d’utiliser un système informatique pour suivre leurs échantillons et leurs résultats d’analyse. Cette affirmation signifie donc qu’il faudra savoir choisir entre des applications appelées système de gestion des informations de laboratoire (ou LIMS ou Laboratory Information Management System) ou le cahier de laboratoire électronique (ELN = Electronic Laboratory Network). Ces deux types de solutions étant complémentaires, il sera donc important de choisir celui qui correspondra le mieux aux objectifs, aux enjeux et aux besoins du laboratoire.

Lire la suite