4.4.1 Méthodes
4.4.1.1 Conception détaillée
Le premier élément nécessaire dans le déploiement de l’ERP est l’utilisation de connaissances sur l’application. Pour exploiter cette connaissance, le client, l’intégrateur et l’éditeur ont à choisir le niveau de granularité de l’analyse et éventuellement un formalisme de représentation. Le niveau de granularité du modèle pour la spécification détaillée est une question délicate. L’entreprise peut employer des processus standard et rester à un niveau très macroscopique, ou elle peut descendre à un niveau très fin de détail sur tout ou partie d’un processus donné pour vérifier des éléments critiques de son mode de gestion. Le modèle doit donc permettre la modification du niveau de généralité de la représentation des processus, au gré de l’utilisateur. Pour le formalisme, en ingénierie des Systèmes d’Information, la méthode MERISE est très employée. Elle est basée sur deux composantes : la représentation des données du système par le modèle de données, la représentation des traitements du système (les processus) par le modèle de traitement. Elle est employée dans beaucoup de projets, mais souvent avec une variation du formalisme de base sur les traitements. Comme par exemple la technique de modélisation d’ARIS, utilisée par l’éditeur SAP, qui propose un traitement par les EPC (Event Process Chain) pour décrire les processus.
Actuellement, quelques éditeurs proposent un modèle de l’application qui est une source utile de connaissance. Cela peut constituer un appui pour l’expression de besoins. Pour les intégra- teurs de SAP, l’utilisation du modèle dans la démarche de déploiement ASAP fût un échec alors que les intégrateurs d’Oracle continuent de déployer leur système au travers de leur modèle et leur outil. La possession d’un modèle de la solution et son utilisation dans une démarche d’intégration est un avantage concurrentiel pour les éditeurs dans la qualité (coût, délai et performance) du déploiement de leurs solutions.
4.4.1.2 Paramétrage
Le paramétrage est la configuration de la solution logicielle pour l’adapter au contexte de l’entreprise, afin d’obtenir ainsi le Système d’Information.
Jean-Louis Tomas (1999, 2002) définit la configuration d’une solution logicielle comme la réa- lisation de trois étapes (adéquation, configuration et prototype) afin d’obtenir une acceptation de la part de la MOA sur le résultat obtenu. Nous pouvons synthétiser cette démarche par la spirale décrite par la figure suivante (fig. 4.2).
L’étape d’adéquation permet d’identifier un à un les processus et les documents de l’entreprise, définis précédemment lors de l’étape d’analyse, dans la solution logicielle. Si cela n’est pas possible, s’il existe une inadéquation, cela veut dire que nous avons identifié un TFP (Trous Fonctionnels Potentiels). Deux solutions sont avancées : modifier l’ERP par le développement d’un spécifique pour cette entreprise ou modifier l’organisation de l’entreprise.
L’étape de configuration est composée de deux tâches : le paramétrage de la solution et la réalisation de scénarios pour le prototypage. Le paramétrage de la solution logicielle consiste à exécuter les décisions prises durant l’étape d’adéquation. C’est-à-dire paramétrer, valuer les différentes données structurelles. Nous pouvons citer par exemple :
Fig. 4.2 – La spirale adéquation/configuration/prototypage
– définition des processus de l’entreprise,
– identification des acteurs, rôles et groupes de l’organisation, – affectation des rôles pour tel processus,
– identification des documents de l’entreprise, – codification des documents,
– identification des événements attachés au processus, – définition des règles métiers.
La deuxième tâche consiste à documenter les scénarios qui seront exécutés dans l’étape de prototypage. Cette documentation permet de transférer les informations, à la personne en charge du prototypage, sur :
– les fonctions de l’ERP utilisées, – les paramètres,
– les fonctions de navigation utilisées,
– les écrans (affichage des champs, des valeurs paramétrées...).
L’étape de prototypage consiste donc à tester la solution paramétrée afin de vérifier à l’aide d’un scénario, reproductible à volonté, que pour la réalisation de tel processus nous obtenons le résultat souhaité. Si ce processus ne donne pas satisfaction, ne respecte pas le cahier des charges, alors nous pouvons boucler sur la spirale adéquation, configuration et prototypage. Dans le cas contraire, s’il y a acceptation du scénario, alors nous pouvons sauvegarder la configuration de l’ERP et passer à l’étape suivante d’intégration et de passage en production. Des travaux de recherche sont menés pour faciliter la réalisation de ces étapes. Jon Atle Gulla et Terje Brasethvik (2002) travaillent actuellement à la réalisation d’un outil pour SAP afin de faciliter le paramétrage de la solution R/3. Il existe actuellement, dans l’outil ARIS, un modèle de SAP R/3 permettant d’avoir une vision des différents éléments (processus, informations, règles) paramétrables. Ces auteurs précisent qu’ils sont arrivés jusqu’aux limites des outils d’aide au paramétrage, tel que ARIS, et favorisent l’utilisation d’un formalisme plus générique et adaptable au contexte de paramétrisation d’un ERP. Ils proposent donc d’utiliser le formalisme UML (Unified Modeling Language) et, plus particulièrement, le diagramme d’activités pour représenter l’enchaînement logique des processus de l’entreprise et réaliser une projection entre les éléments du diagramme (activités, note, objet, logique d’enchaînement) et les éléments de la solution (écran, codification, document, workflow).
Dans le cas de grands comptes, l’étape de paramétrage est généralement longue et difficile (plus de 15 % de la durée du projet) due à la complexité de l’organisation. Dans le contexte
52 CHAPITRE 4. GESTION DES PROJETS ERP
de PME/PMI, nous avons moins de processus et de documents à paramétrer, par contre, nous avons une grande variété d’entreprises (secteurs d’activités variés), avec des processus plus « standard », et des durées de projet proportionnellement inférieures à celle des grands comptes. Les éditeurs proposent donc de plus en plus des solutions pré-configurées. Après avoir identifié le mode de fonctionnement de l’entreprise, le secteur d’activités (négoce, industrie fabrication, industrie process) avec des outils tels que les grilles GRAI (§ 7), nous pouvons fournir une pré-configuration adaptée à cette entreprise et à son mode de gestion.
4.4.2 Outils des éditeurs ERP
Les éditeurs ont des outils d’aide pour le déploiement de leurs solutions. Les outils des gros éditeurs sont :
– ARIS1 pour la méthode ASAP2 (Accelerated SAP) de SAP, – DEM3 (Dynamic Enterprise Modelling) de BAAN,
– Fast Forward4 d’Oracle.
Nous n’avons pas trouvé, à notre connaissance, de documents sur le retour d’expérience lié à l’utilisation de ces outils. Les seules descriptions en notre possession proviennent des sites Web des éditeurs à vocation trop commerciale.
Les objectifs de ces outils sont :
– d’accélérer l’implémentation de l’ERP,
– de structurer le projet en utilisant l’outil comme support, – de proposer un outil d’aide à la configuration de la solution,
– de fournir un moyen de représentation de l’organisation de l’entreprise
– d’offrir la possibilité, avec l’outil, de faire évoluer les paramètres et l’organisation de la solution logicielle.
Ces outils apportent une aide aux différents équipiers du projet en facilitant la gestion des informations sur les processus ou les documents mise en œuvre de la solution logicielle. Si nous devions gérer, à la main, l’ensemble de ces informations sur un tableau mural d’un simple processus représentant le suivi d’une commande dans une entreprise, cela deviendrait illisible et ingérable.