La mise en place du projet

1. BPR : Business Process Reengineering

La mise en place d’un ERP n’est pas un projet informatique.

Il naît de la volonté d’unifier, d’harmoniser, d’optimiser les fonctionnements de l’entreprise, quitte même à en changer complètement les process. Ceci a très souvent comme conséquence de créer une nouvelle organisation qui exécutera ces nouveaux process.

Le BPR (Business Process Reengineering) est la réflexion qui consiste à optimiser les process et les organisations d’une entreprise.

Comment définir ces nouveaux process ? En procédant de la sorte :

Ensuite, et ceci afin de limiter la résistance au changement, faites évaluer les différentes possibilités par les acteurs du projet : Key Users, membre du comité projet…

Cette évaluation doit se faire sur différents aspects :

La décision se prendra à la suite de l’analyse des différentes options possibles, et en ayant pesé les arguments sur toutes les dimensions énoncées ci-dessus. Cette décision sera prise au plus près des opérationnels, dans le comité métier si elle ne concerne qu’un métier, dans le comité projet intermétiers si elle concerne plusieurs métiers.

En cas de non-consensus, la décision suivra alors la « procédure d’escalade » (cf. chapitre Les acteurs du projet - Les instances de décision).

2. Core Model

Le « Core Model » est un ensemble de règles de gestion, de process, d’organisations, de paramètres...

1. Définition

Le « build » signifie la construction du nouveau système. Une fois le Core Model défini, il s’agit de le mettre en œuvre.

Si le Core Model définit le plan d’un édifice à bâtir, le « build » consiste à construire l’édifice en question.

Concernant l’ERP, il s’agit de réaliser les paramétrages et les développements nécessaires pour dérouler les scénarios de test.

2. Les scénarios dans la phase de Build

Chaque scénario doit être analysé individuellement. Tout d’abord, pour en vérifier l’exhaustivité.

Comment le faire ?

Définition

Un scénario est défini par :

Vérifications

Pour vérifier l’exhaustivité, il faut que toutes les données d’entrée soient :

Pour vérifier le travail « utile », il faut que toutes les données de sortie soient :

Pour vérifier la pertinence du scénario, il faut que toutes les actions soient conformes aux règles de gestion décidées....

1. Criticité des bugs

Tous les incidents n’ont pas la même importance. Il faut donc prioriser leur résolution.

Voici, par exemple, une classification, à adapter à chaque contexte :

1. Les règles de gestion

L’idée étant de construire un Core Model applicable par tous, il convient de définir les règles qui vont s’appliquer à tous : les règles de gestion.

Qu’est-ce qu’une règle de gestion ?

Une règle de gestion est une loi définie par l’entreprise.

Elle s’exprime généralement par une phrase d’obligation ou d’interdiction.

Les règles de gestion ne reprennent pas les contraintes légales.

… mais peuvent les compléter.

Les règles de gestion, ainsi que leurs mises à jour, doivent être validées par le métier, voire par la direction générale.

Exemple : après analyse, il est décidé que les entités ne pourront plus faire de chèque (sauf procédure exceptionnelle contrôlée).

Cette règle va être un changement majeur dans certaines entités. Il est fort probable qu’il y ait donc de la résistance au changement. Mais cette règle n’étant pas tombée du ciel, mais travaillée par tous à l’aide d’une matrice de décision, et décidée par le métier (ici la finance) ou plus haut (direction générale), cette règle a la légitimité de s’appliquer. Pour agiliser la transformation, il est important que cette règle de gestion soit dans un document commun au métier, ou aux métiers, avec l’instance qui l’a décidée. La transition sera également facilitée si la communication du projet explique le pourquoi de cette règle.

Exemple de la newsletter du projet : « L’équipe finance a travaillé sur les meilleures pratiques du métier, avec l’aide de consultants expérimentés qui ont la connaissance de nombreuses autres...