Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Gestion De Projet ERP Réalisé par : Introduction Chapitre 1: Organisation et dé

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) terminé(s) et validé(s), on entre dans une phase de préparation des recettes informatiques. Une matrice des fonctions est alors préparée. Il s’agit de présenter dans un tableau les grands processus impactés par le progiciel. Pour chaque fonction, des cas de tests sont préparés. Pour chaque cas de test, des jeux d’essai ou jeux de données sont conçus. Il s’agit de tester le fonctionnement correct de tous les processus de gestion de l’entreprise. Des logiciels existent pour gérer les cas de tests et assurer un suivi et un pilotage de la phase de recette. (exemple, Bugzilla) Cette étape permet une configuration itérative du système grâce aux corrections et améliorations continues liées aux résultats des tests: 1. Tests Fonctionnels Les tests fonctionnels doivent couvrir toutes les fonctions des processus configurés dans l’ERP. Ils sont réalisés, sous la responsabilité des responsables fonctionnels, par les utilisateurs clés choisis lors de l’organisation du projet. Ces utilisateurs valident la conformité du fonctionnement de l’ERP par rapport aux spécifications définies au début du projet. Ils contrôlent la qualité du paramétrage. Domaines fonctionnels : ● Finance / Comptabilité ● Produits ● Gestion d’inventaire (Stocks) ● Gestion des achats ● Gestion de production ● Gestion des ventes 2. Tests d’Intégration Dans un contexte où l’ERP s’intègre dans un paysage contenant d’autres applications; il est important de tester la capacité de communication de l’ERP avec ces applications tiers. Ces tests valident la qualité des données échangées mais également la performance du système global. 3. Tests des rapports Les rapports demandés par les utilisateurs doivent être testés et validés par eux. De manière générale, les tests doivent couvrir tous les domaines fonctionnels implémentés dans l’ERP. Pour cela toutes les fonctions et tous les processus doivent être couverts par les jeux de test. Lors du test d’intégration, contrôler les mouvements et les documents générés par l’exécution complet du processus : commande client, ordre de production, commande d’achat et mouvements comptables et financiers associés donne déjà un taux de couverture proche de 80% de test des fonctionnalités de l’ERP. 4. Tests des interfaces Décrire les interfaces consiste à expliquer la correspondance entre les données du Système d'Information existant et celles du SI cible (l’ERP à implémenter). Par exemple, la champs nommé « N° de commande » du SI existant sur 8 caractères numériques devient le champs « PO number » dans l’ERP cible sur 9 caractères alpha-numérique La description des interfaces est incluse dans le dossier de conception détaillé. 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 données) doivent être trouvées. On parle aussi parfois de « mapping des données » ou bien encore de « transcodification » des données. La définition des interfaces va permettre aux développeurs/paramétreurs d’être opérationnels rapidement. Ils sauront exactement le type de données et le format des données à traiter ainsi que leur correspondance entre l’ancien et le nouveau système. Afin de donner tous les éléments aux développeurs/paramétreurs, le dossier des interfaces devra donner un maximum de détails sur les données existantes et cible, leur format (numérique, nombre de caractères), le nom des champs (zones de données) et les résultats attendus. Si l’entreprise a décidé de mettre en place un seul module dans un premier temps, les interfaces provisoires entre les SI existants et cibles doivent être décrites précisément et le planning de bascule clairement é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 uploads/Industriel/ word-pgi.pdf