Vous êtes sur la page 1sur 10

Gestion De Projet ERP

Réalisé par :

Introduction

Chapitre 1: Organisation et développement de la solution

Section 1 : Organisation et Management du Projet

Section 2 : Développement de la solution


ANNÉE UNIVERSITAIRE
2019/2020
Chapitre 2 :Test et mise en production de la solution
Section 1 : Test de la Solution

Phase de tests :

Une fois le(s) cahier(s) des charges fonctionnel(s) terminé(s) et validé(s), on entre
dans une phase de préparation des recettes informatiques. Une matrice des fonctions
est alors préparée.
Il s’agit de présenter dans un tableau les grands processus impactés par le progiciel.
Pour chaque fonction, des cas de tests sont préparés.
Pour chaque cas de test, des jeux d’essai ou jeux de données sont conçus.
Il s’agit de tester le fonctionnement correct de tous les processus de gestion de
l’entreprise.

Des logiciels existent pour gérer les cas de tests et assurer un suivi et un pilotage de la
phase de recette. (exemple, Bugzilla)
Cette étape permet une configuration itérative du système grâce aux corrections et
améliorations continues liées aux résultats des tests:

1. Tests Fonctionnels

Les tests fonctionnels doivent couvrir toutes les fonctions des processus configurés
dans l’ERP.

Ils sont réalisés, sous la responsabilité des responsables fonctionnels, par les
utilisateurs clés choisis lors de l’organisation du projet.

Ces utilisateurs valident la conformité du fonctionnement de l’ERP par rapport aux


spécifications définies au début du projet. Ils contrôlent la qualité du paramétrage.

Domaines fonctionnels :

● Finance / Comptabilité
● Produits
● Gestion d’inventaire (Stocks)
● Gestion des achats
● Gestion de production
● Gestion des ventes

2. Tests d’Intégration

Dans un contexte où l’ERP s’intègre dans un paysage contenant d’autres applications;
il est important de tester la capacité de communication de l’ERP avec ces applications
tiers. Ces tests valident la qualité des données échangées mais également la
performance du système global.

3. Tests des rapports

Les rapports demandés par les utilisateurs doivent être testés et validés par eux.
De manière générale, les tests doivent couvrir tous les domaines fonctionnels
implémentés dans l’ERP.
Pour cela toutes les fonctions et tous les processus doivent être couverts par les jeux
de test.
Lors du test d’intégration, contrôler les mouvements et les documents générés par
l’exécution complet du processus : commande client, ordre de production, commande
d’achat et mouvements comptables et financiers associés donne déjà un taux de
couverture proche de 80% de test des fonctionnalités de l’ERP.

4. Tests des interfaces

Décrire les interfaces consiste à expliquer la correspondance entre les données du


Système d'Information existant et celles du SI cible (l’ERP à implémenter). Par
exemple, la champs nommé « N° de commande » du SI existant sur 8 caractères
numériques devient le champs « PO number » dans l’ERP cible sur 9 caractères
alpha-numérique
La description des interfaces est incluse dans le dossier de conception détaillé.
Lors de la bascule d’un logiciel maison vers un ERP ou d’un ERP vers un autre ERP,
des correspondances entre champs ( zones de données)
doivent être trouvées. On parle aussi parfois de « mapping des données » ou bien
encore de « transcodification » des données.
La définition des interfaces va permettre aux développeurs/paramétreurs d’être
opérationnels rapidement. Ils sauront exactement le type de données et le format des
données à traiter ainsi que leur correspondance entre l’ancien et le nouveau système.
Afin de donner tous les éléments aux développeurs/paramétreurs, le dossier des
interfaces devra donner un maximum de détails sur les données existantes et cible,
leur format (numérique, nombre de caractères), le nom des champs (zones de
données) et les résultats attendus.
Si l’entreprise a décidé de mettre en place un seul module dans un premier temps, les
interfaces provisoires entre les SI existants et cibles doivent être décrites précisément
et le planning de bascule clairement établi.

Section 2 : Mise en Production de la Solution

La mise en production d'une application informatique dans une organisation donnée


peut être un évènement ordinaire ce qui n'est pas évidement le cas de la mise en
production d'un nouveau ERP qui prend place d'un autre auquel les utilisateurs sont
habitués depuis une décennie.
Certes, la mise en production du nouveau ERP est, pour différentes raisons, un
évènement marquant autant que pour l'utilisateur qu'à la société d'une manière
générale. L'utilisateur a des réflexes liés à l'ancien ERP et il trouvera des difficultés à
s'adapter facilement et rapidement aux nouveaux menus, aux nouvelles
fonctionnalités ou nouveaux flux d'information. Tout ce changement de
l'environnement et de l'ergonomie de l'outil informatique moyennant lequel
l'utilisateur accomplie son travail cause pour la société un ralentissement de
l'exécution des taches ce qui diminue la performance des processus et affecte la
qualité de leurs livrables. D'où la question qui se pose : Comment faire face à une
situation pareille ?

La conduite de changement :
Mettre en place un nouveau ERP c'est en fait changer la façon dont les employés
exécutent leurs taches. C'est pourquoi le chef du projet de mise en place du nouveau
ERP doit maitriser ce changement durant toutes les phases du projet.
En effet, le nouveau ERP à mettre en place est un moyen pour l'organisation pour
mettre à niveau ses processus pour les rendre plus performants et pour que leurs
livrables soient de meilleure qualité. Cette mise à niveau permettra à la société de
réaliser au fil du temps un progrès ce qui rassurera de plus en plus sa pérennité. Mais
il faut savoir que « Le progrès est impossible sans changement, et ceux qui ne peuvent
pas changer leurs esprits ne peuvent rien changer». D'où la mission fondamentale du
chef du projet pour changer les attitudes des employés qui résistent au changement et
assurer une bonne conduite de changement permettant de mener à bien son projet. Il
doit être conscient que les sources de résistance au changement sont de deux types :
Sources individuelles et sources organisationnelle.
Les sources de la résistance individuelle au changement sont les habitudes, la
sécurité, les facteurs économiques, la peur de l'inconnu et le traitement sélective de
l'information alors que les sources de résistance organisationnelle au changement
sont l'inertie structurelle, l'inertie des groupes, l'intérêt limité au changement, la
menace pour les expertises, la menace pour l'établissement des relations de pouvoir et
la menace pour l'établissement des allocations des ressources ». Le chef du projet doit
alors identifier au préalable les différentes réactions possibles et repérer les individus
par rapport à ces réactions pour agir en conséquence selon un plan d'action préétabli.

La formation :
La formation est définie par Larousse comme étant une « action de donner à
quelqu'un, à un groupe, les connaissances nécessaires à l'exercice d'une activité ». Elle
est une étape très importante de la mise en place d'une nouvelle solution informatique.
Cependant, la formation sur l'administration et l'exploitation du nouveau ERP a au
moins deux principaux effets sur les futurs utilisateurs.
D'abord, la formation constitue la découverte par les utilisateurs de la nouvelle
solution c'est pourquoi il faut faire attention car les attitudes des personnes sont
généralement influencées par les premières impressions. C'est pourquoi il est
préférable, que dans le cadre de la conduite du changement, de présenter aux groupes
d'utilisateurs les avantages que le nouveau ERP leurs apporte et spécialement dans le
module sur lequel ils seront formés.
Ensuite, vient l'étape la plus importante de la formation qui est la formation même sur
l'administration et l'utilisation du nouveau ERP. Cette étape aura des conséquences
très profondes sur son exploitation par l'organisation c'est pourquoi l'intégrateur à
l'aide du chef du projet doit bien se préparer et préparer le contenu de la formation.
Une formation bien préparée et bien orientée motive les utilisateurs à l'exploitation du
nouveau ERP alors qu'une formation mal préparée ou mal orientée peut provoquer
une déception et un refus de la solution que le nouveau système apporte. Dans ce
dernier cas, même si les utilisateurs savent que « le mal est fait » du fait que la société
est engagée dans la nouvelle solution et qu'ils doivent l'utiliser ne vont pas participer
activement à son amélioration jusqu'au son adéquation avec leurs besoins métiers.
Dans le cas du présent projet, pour mieux approcher les utilisateurs de la nouvelle
solution il est possible de faire la formation sur une copie de la base de données réelle
de la société qui contient les informations migrés de l'ancienne base de données.
Sinon, la formation peut être faite sur une base de données où tous les données sont
fictives.
Une formation n'est bien menée que si elle est réalisée suivant un plan de formation
bien élaboré et bien ciblé et qui aboutit à des bons résultats non seulement en termes
de réalisation des performances attendues de l'exploitation du nouveau ERP mais
aussi en termes de son amélioration continue à travers les feedback des utilisateurs et
leurs implications à son utilisation et son amélioration.

Transfert de données :
La reprise des données doit être considérée comme un sous-projet de votre projet
ERP. Une équipe dédiée doit être constituée en interne. Cette équipe doit d'abord
maîtriser "techniquement" votre ancien système d'information pour être en mesure
d'en extraire les données.
Elle doit aussi intégrer des référents fonctionnels pour réaliser ensuite les travaux de
consolidation, de "nettoyage" et de validation des données avant intégration dans le
système cible.

Pour éviter de se retrouver dans une situation très inconfortable, il faut bien
comprendre les tenants et les aboutissants du processus de reprise de données et
appliquer dans la mesure du possible les bonnes pratiques.
La reprise des données commence par les données de structure, puis les données
de référentiel, et enfin les données de gestion.
 Les données de structure : plan comptable, axes analytiques, la numérotation
des pièces de gestion ...

 Les référentiels : les clients, les fournisseurs, les contacts, la nomenclature des


produits vendus et achetés…
 Les données de gestion : report à nouveau comptable, les factures de ventes et
d'achats avec leurs soldes, les commandes client et fournisseur en cours, le
stock...

La reprise des données doit se faire dans l'ordre décrit ci-dessus ,car ce sont les
données de structure qui permettront d’avoir une exploitation optimale des
informations. La migration doit permettre de relier les différents types de données.
Cependant, si les structures des deux systèmes d’information sont différentes. Vous
devrez impérativement effectuer un retraitement, afin de trouver des équivalences
entre les deux ERP. Pour les données pour lesquelles un retraitement sera nécessaire,
vous réaliserez des scripts, ou vous les traiterez manuellement.
Quant à la documentation, bien entendu, elle sera reprise, son stockage pourra se
faire à travers le Cloud.

Test du système intégré :


Etant donné que le présent projet est un projet de mise en place d'un nouveau ERP qui
prend place d'un ancien ERP il est évident qu'il comportera une activité
supplémentaire par rapport à un projet de la mise en place d'un ERP pour la première
fois dans une société donnée.
Comme en planification du projet qui doit prévoir cette activité supplémentaire,
l'exécution du projet aussi donne lieu à cette activité et leur donner une grande
attention car à ce niveau que les enregistrements dans l'ancien ERP vont être migrées
vers le nouveau ERP. C'est l'historique de toutes les transactions de la société
effectuées moyennant l'ancien ERP qui doit rester pérenne. Cette migration doit être
bien étudiée et bien exécutée par l'intégrateur en inspectant de façon profonde
l'architecture de la base des données de l'ancien ERP.
L'installation d'un ERP requiert un travail préliminaire de préparation de
l'infrastructure informatique matérielle et système sur lequel sera implémenté l'ERP.

Selon le plan du projet et le choix de la société, cette infrastructure peut être locale où
la société achète, installe et configure le matériel et systèmes informatiques
nécessaires à l'accueil de l'ERP. Si la société opte pour le Cloud elle peut dans ce cas
implémenter l'ERP soit en mode IaaS, PaaS ou aussi en mode SaaS.
Une fois l'installation du nouveau ERP et la migration des données sont bien
effectuées l'intégrateur commence à paramétrer l'ERP et notamment à mettre en place
les personnalisations nécessaires. Il est à noter que les personnalisations aident la
société à adapter au maximum l'ERP au fonctionnement de ces processus mais
beaucoup de personnalisation peut freiner les mises à jour de la version mise en place
vers les nouvelles versions car il est difficile que l'éditeur envisage toutes les
personnalisations de tous ses clients dans les nouvelles versions.
Par la suite, l'intégrateur accompagné du Service Système d'Informations effectue les
tests sur l'ERP mis en place pour vérifier qu'il est bien fonctionnel par rapport à toutes
les règles et conditions convenues. Durant cette phase du projet l'intégrateur corrige
tous les disfonctionnements et toutes les erreurs constatées. Les tests sont de grandes
importance car elle aide l'intégrateur de minimiser autant que possible voire éliminer
définitivement tout disfonctionnement et toute erreur pour qu'elles ne rencontrent pas
les futurs utilisateurs surtout pendant la période de formation et des premières
semaines d'exploitation. Malgré que de tels incidents et problèmes soient inévitables il
faut que l'intégrateur à l'aide de l'équipe du système d'information du client essaie de
minimiser leurs impacts non seulement sur le travail des utilisateurs mais surtout sur
leurs perceptions et acceptation du nouveau ERP.

Organisation de l’exploitation :
La clôture du projet de mise en place d'un ERP ne signifie pas qu'il ne reste rien à
faire par l'équipe du système d'information. Au contraire tout un travail lié à
l'exploitation de l'ERP doit être fait tout au long de son existence dans la société. Ce
travail consiste à la gestion des incidents, à la gestion des problèmes, à la gestion des
évènements, à la gestion des requêtes et à la gestion des accès. Sans ce travail
quotidien, l'ERP, et éventuellement tout autre logiciel, finira par être abandonné.

Un nombre élevé d'incidents, de problèmes, de requêtes ou de demandes d'accès


signifie que soit les besoins n'étaient pas bien identifiés et bien formulés soit que
l'ERP choisi et mis en place n'est pas celui qui répond convenablement aux besoins
métiers soit aussi que les utilisateurs n'ont pas été bien formés à l'utilisation de l'ERP.
Sauf pour les requêtes, si son nombre est élevé c'est que peut être les utilisateurs
trouvent intérêts et satisfaction de l'ERP et veulent l'exploiter encore beaucoup plus.
Donc, il est nécessaire que l'équipe du système d'information assure un suivi
rigoureux et de près du nouveau ERP mis en place pour bien gérer son exploitation et
analyser son efficacité et surtout évaluer le degré auquel il a rempli les fonctions
attendus par les utilisateurs. Aussi, il est obligatoire que le chef du projet évalue le
degré auquel le projet de mise en place du nouveau ERP a rempli les fonctions
attendu par la direction générale dans la feuille de cadrage et le tableau du cahier des

charges fonctionnel présentés précédemment. Ces évaluations sont obligatoires pour


situer l'ERP par rapport aux attentes de l'ensemble de l'organisation. Un rapport
d'évaluation devra être élaboré et présenté par le chef du projet à la direction générale.
Conclusion
Le projet de mise en place d'un ERP ne peut être réussi que s'il est considéré un projet
d'entreprise auquel tous les employés adhèrent et participent. Un chef de projet
informatique doit maitriser la gestion des différents aspects et phases du projet en
faisant références aux bonnes pratiques du domaine de management et du domaine
informatique car « en réalité, de nombreuses entreprises se retrouvent face à un
monstre qu'elles n'osent plus affronter. Toute tentative de mise à niveau de l'une de
leurs applications ou développements spécifiques pourrait entraîner l'écroulement de
l'ensemble du système et le risque encouru par l'entreprise est tout simplement
beaucoup trop important ».

Le responsable du système d'information ne doit pas considérer l'ERP « la baguette


magique » par laquelle il va résoudre tous les problèmes de l'organisation et que c'est
aux outils informatique seuls revient la résolution des dysfonctionnements et
l'amélioration des performances des processus. Il doit donc bien maitriser la conduite
du changement et bien veiller à l'amélioration continue de la solution mise en place.
L'application informatique idéale n'existe pas et il existera toujours des besoins
métiers non couverts.

Vous aimerez peut-être aussi