Mise en place d'un nouveau ERP ( Enterprise Resource Planning) . Cas de la société Bouchamaoui industries

IV. EXECUTION DU PROJET DE MISE EN PLACE DU NOUVEAU ERP

A. NOTION D'EXECUTION DE PROJET

L'exécution du projet est l'ensemble des processus de concrétisation ou mise en application de la planification déjà définie. Selon le PMI elle est un ensemble de « processus qui permettent d'accomplir le travail défini dans le plan de management du projet afin de respecter les spécifications du projet. Ce groupe de processus implique la coordination des personnes et des ressources, la gestion des attentes des parties prenantes, ainsi que l'intégration et l'accomplissement des activités du projet conformément au plan de gestion de projet»²¹.

Comme pour la planification, l'exécution du projet nécessite certaines compétences et expertises dans chaque domaine de projet. C'est pourquoi le gestionnaire de projet est responsable de plusieurs activités dans des domaines de connaissances différents tels que la qualité, la gestion des personnes en terme d'effectif et comportements, la communication, l'approvisionnement, etc. cette responsabilité lui incombe de donner lieu à la réalisation des objectifs du projet en terme de livrables, performance et qualité tout en mettant en oeuvre plusieurs technique et méthodes d'exécution du projet en fonction du plan de gestion du projet, des demandes de changement approuvées, des facteurs de l'environnement de l'entreprise et des actifs des processus organisationnel.

Pour un projet informatique, particulièrement la mise en place d'un nouveau ERP, le gestionnaire de projet peut se référer à certaines bonnes pratiques telles qu'ITIL pour pouvoir mener à bien l'exécution du projet. Dans le cas d'un projet pareil au présent projet qui consiste à mettre en place un ERP en place d'un autre, il est bien recommandé de prendre en compte les bonnes pratiques qu'ITIL liste au niveau de la transition des services comme par exemple la gestion des changements, la gestion des actifs des services et configuration, la gestion des déploiement et mise en production, test et validation des services, évaluation des changement et enfin la gestion des connaissance. Aussi il est opportun de se référer à « Early Life Support » d'ITIL pour pouvoir surmonter la courte période critique (les quelques jours) qui vient juste après la mise en production de l'ERP.

21 PMBOK 5^ème édition, PMI.

D.E.S. en Management des Systèmes d'Information IACE - ICHEC Entreprises - 2013

17

B. ACTIVITES DE PRE-IMPLEMENTATION DU NOUVEAU ERP

1. Analyse détaillée des besoins métiers

L'analyse des besoins métiers est une étape très importante dans la mise en place des solutions informatique. Cette étape est déterminante pour la mise en place des ERP étant donné qu'ils couvrent généralement un pourcentage très important du système d'information, voire sa totalité dans certaines entreprises. C'est pourquoi « l'implémentation d'un nouveau système ERP constitue une excellente occasion de repenser les processus »²² à travers une analyse de l'organisation de la société et surtout l'analyse des besoins métiers de ses processus métier.

L'analyse des besoins métier peut être basée sur différentes sources d'information. Parmi ces sources, on trouve l'organisation interne de la société à savoir ses processus et ses procédures et les utilisateurs qui sont la cible de la future solution à mettre en place. C'est pourquoi la personne ou l'équipe qui va mener cette analyse doit être bien vigilante pour bien orientée l'analyse au sens « métier » car si l'analyse va chercher à satisfaire tous les besoins que les utilisateurs manifestent ou se limiter à ce qu'il manifestent, peut ne pas donner une image cohérente et objective sur l'ensemble des besoins réels et nécessaires auxquels il faut apporter une solution bien fonctionnelle que ce soit par rapport aux exigences du métier ou aux processus et procédures organisationnels en place. Cette orientation métier de l'analyse des besoins doit prendre en compte les trois types d'utilisateurs :

- Ceux qui ont une attitude que suite à l'analyse des besoins métiers la solution à mettre en place ne marchera jamais ! ils ne seront pas donc des sources d'information fiable sur les besoins métier et ils sont des résistants au changement qu'apportera la future solution.

- Ceux qui convaincu et motivés pour le changement qui aura lieu. L'analyse donc doit se profiter bien de la motivation de ce type d'utilisateurs et les intégrer dans la communication du projet de mise en place de la nouvelle solution. Ce sont les utilisateurs qui participent activement dans le projet et qui sont l'un des facteurs clés de la réussite du projet. Mais ça n'empêche qu'il faut aussi bien examiner les besoins qu'ils expriment car ils sont généralement très ambitieux !

- Ceux qui sont sans avis. C'est-à-dire qui ne sont ni pour ni contre la future solution. Ils sont les
utilisateurs qui peuvent, peut-être, manifester les besoins métiers réels. Ils sont aussi susceptibles, moyennant une bonne communication, de changer d'avis et devenir parmi les utilisateurs convaincus et motivés pour la future solution. Ils commencent alors à participer activement dans le projet.

Par définition, selon la norme AFNOR, «Un besoin est un désir (ou une nécessité) exprimé par l'utilisateur d'un système »²³.

L'analyse des besoins est de trois types :

- L'analyse détaillée des besoins : définition exhaustive et précise des besoins

- L'analyse fonctionnelle des besoins : définition des fonctions que la solution devra remplir par un niveau de performance donné

22 Quatre conseils aux entreprises pour bien choisir leurs ERP, Christophe Letellier, 15/03/2013, http://www.erp-infos.com

23 Définition du Besoin, Norme AFNOR X50-151

18

D.E.S. en Management des Systèmes d'Information IACE - ICHEC Entreprises - 2013

- L'analyse technique : définition de la solution technique pour remplir les fonctions et leurs

performances.

Dans cette partie, on va mettre l'accent sur l'analyse fonctionnelle des besoins métiers de mise en place du nouveau ERP beaucoup plus que l'analyse technique puisque la nouvelle solution ne sera pas développée sur mesure pour la société BI mais plutôt une solution parmi celles qui existent sur le marché des ERP et qui offrent plus ou moins les mêmes caractéristiques techniques et que leurs principaux modules sont standards tel que le module achat ou approvisionnement, le module comptabilité, le module RH, etc. donc ne sert à rien à « réinventer la roue » en mettant du temps et d'efforts dans ce qui d'ordre analyses techniques. L'analyse technique va être considérée plutôt les contraintes techniques (informatiques) auxquelles doit répondre le futur ERP.

Etant avancé dans le chapitre précédent qu'il y avait un audit des dysfonctionnements de l'organisation de la société BI en 2010 et qu'une grande partie de ces dysfonctionnement sont en relation avec l'ERP existant, l'analyse fonctionnelle du présent projet va se référer au rapport de cet audit et à l'organisation existante pour organiser des ateliers avec les utilisateurs de tous les processus de la société en les regroupant dans des équipes de travail. Ce travail dans les dits ateliers sera axé sur la description par les utilisateurs de ce qu'ils fassent pour mener à bien leurs tâches au sein des processus auxquels ils sont affectés. Bien évidemment, ils seront aidés par des questions dans le but de dégager au maximum les informations nécessaires à la formulation des besoins métiers de l'ensemble des processus de la société.

La formulation de ces besoins dans un document d'analyse fonctionnelle donnera lieu à un cahier des charges fonctionnelles pour l'ERP à mettre en place. Il sera donc défini les fonctions de services principales ainsi que les fonctions de services contraintes de chacun des modules de l'ERP. Quant aux fonctions de services principales sont dites aussi fonction d'usage qui doivent satisfaire le besoin de l'utilisateur alors que les fonctions de services contraintes sont dites aussi fonctions d'adaptation qui caractérisent l'adaptation nécessaire de l'action de la fonction à l'environnement qui peut être informatique ou organisationnel (par exemple les relations entre les processus). La méthode qui peut être utilisée pour présenter les besoins fonctionnels est de les schématisés selon le schéma des fonctions de service appelé « Bête à cornes » de la APTE²⁴.

24 APTE : méthode universelle d'analyse fonctionnelle créée par Gilbert Barbey en 1964 et nom déposé de « Application aux techniques d'entreprises » qui est un cabinet de conseil spécialisé dans l'analyse la valeur.

D.E.S. en Management des Systèmes d'Information IACE - ICHEC Entreprises - 2013

Sur quoi agit-il ?

Contrainte

EME1

EME4

Utilisateur

Commande fournisseur

A qui rend-t-il service ?

FS1

Sur quoi agit-il ?

FS2

FS5

EME2

Réception des livraisons

FS3

FS4

Règles de qualité

E3

Module Achat de l'ERP

19

Graphique 5: Exemple illustratif de « Bête à cornes » du module Achat de l'ERP

Dans ce graphique 5 on trouve que par exemple pour le module Achat une présentation des différents éléments du milieu externe appelés par abréviation EME qui sont de natures différentes et qui se relient au module par des fonctions de service notées FS. Ce module doit donc assurer à l'utilisateur des fonctions de service principales qui sont FS1 et FS2 qui consistent successivement l'élaboration d'un bon de commande fournisseur et l'élaboration d'un bon de réception de la livraison tout en respectant la fonction contrainte FS4 qui est relative aux règles de qualité.

Une fonction de service est donc l'action attendue du module de l'ERP et qu'il réalise pour répondre à un besoin utilisateur donné. Toutefois, cette fonction doit être caractérisée en la qualifiant par des termes de critères et en la quantifiant en attribuant un niveau de performance pour chacun de ces critères en vue de le valider et le contrôler par la suite.

Tableau 1: Exemple de tableau de caractérisation des FS

Ce tableau montre comment regrouper toute les fonctions de service dans une première colonne et attribuer pour chacune un ou plusieurs critère. Chaque critère doit avoir un niveau et une flexibilité donnée. Par exemple pour le cas de la fonction FS1 attendu par EME1 du module Achat de l'ERP on peut définir un critère « Bon de commande modifiable après la réception de marchandise» dont la valeur est 0 (0=non et 1=oui) et sa flexibilité et aussi = 1. Dans un cas pareil il est possible qu'un utilisateur modifie une donnée au niveau de la commande s'il est nécessaire et que cette flexibilité doit être indiquée dans quelle condition elle est permise.

D.E.S. en Management des Systèmes d'Information IACE - ICHEC Entreprises - 2013

20

L'analyse fonctionnelle doit être aussi accompagnée simultanément par une analyse des flux de documents et d'informations qui seront généré par l'exécution des actions des fonctions de service.

Suite à l'analyse fonctionnel il devient plus clair quels sont les processus que leurs couverture par le nouveau ERP est indispensable. Le graphique ci-dessous est un exemple des modules d'un ERP que chacun couvre normalement un processus bien déterminé.

Graphique 6: Exemple de modules d'un ERP

Il est à noter que les ERP de nouvelle génération tendent vers la mise à disposition des utilisateurs les fonctionnalités des réseaux sociaux tels que le partage, le suivi et le commentaire des flux d'informations. « L'objectif consiste à intégrer des processus non structurés dans le fonctionnement de l'entreprise, en considérant les conversations comme des éléments à part entière des processus professionnels »²⁵. De telles fonctionnalités permettent donc une couverture plus large et une meilleure exploitation de l'ERP à mettre en place.

Après avoir achevé l'analyse des besoins et la formulé dans un document spécifique il est indispensable de le valider auprès des utilisateurs ou les maitres des processus de la société, en leurs expliquant en cas de besoin pourquoi une fonction est définie, avant de passer à l'étape suivante qui est l'élaboration du cahier des charges fonctionnel.