Blog ENI : Toute la veille numérique !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
💥 Du 22 au 24 novembre : Accès 100% GRATUIT
à la Bibliothèque Numérique ENI. Je m'inscris !
  1. Livres et vidéos
  2. Mettre en oeuvre et piloter un projet ERP
  3. L’avant
Extrait - Mettre en oeuvre et piloter un projet ERP
Extraits du livre
Mettre en oeuvre et piloter un projet ERP
2 avis
Revenir à la page d'achat du livre

L’avant-projet

La stratégie Système d’Information

Comment naît le projet ?

  • D’un incident majeur qui réveille les consciences ?

  • D’une analyse de risque qui fait peur ?

  • Du départ à la retraite de l’informaticien qui « connaît tout » ?

  • D’un évènement pour lequel il faut être prêt (ex. passage à l’Euro le 31 décembre 2001) ?

Ce sont, en effet, de très nombreuses fois les causes du lancement du projet ERP. Pourtant, la meilleure voie est encore de constater l’écart entre la stratégie SI et la situation actuelle, de ne pas être réactif à une situation devenue insupportable, mais de lancer ce type de projet « quand tout va bien ».

La stratégie SI découle de la stratégie de l’entreprise. Elle est là pour l’accompagner et la soutenir.

Pour la définir, il faut évidemment que la stratégie de l’entreprise soit définie. Dans le cas contraire, la stratégie SI peut être force de proposition.

Prenons quelques exemples :

  • Afin de pouvoir piloter efficacement, la direction générale veut avoir des chiffres fiables de ses différentes filiales dans le monde.

    Un des moyens est de mettre en place le même système partout avec les mêmes règles de calcul. Voilà un chapitre de la stratégie SI : définir un « core-système » unique et le mettre en place partout.

  • L’entreprise a une forte croissance.

    Le SI doit donc être « scalable », c’est-à-dire pouvoir grossir autant que la croissance de l’entreprise, ou a minima, ne pas l’empêcher.

  • L’entreprise a besoin d’utiliser son système 24 h sur 24 et 7 jours sur 7.

    Le SI doit donc être « robuste », c’est-à-dire être conçu pour avoir un taux de fonctionnement extrêmement élevé avec de multiples sécurités. Il doit également posséder un « plan B » en cas de panne majeure.

  • L’entreprise est française, mais compte se développer dans d’autres pays d’Europe, voire en dehors de l’Europe.

    Le SI doit donc être capable...

Le pré-projet

1. Un cahier des charges ?

Pour comparer les différents systèmes existants pouvant devenir la cible à atteindre, il est de coutume de définir un cahier des charges.

Cela prend la forme d’un questionnaire sous forme d’un tableau de questions.

Pour chaque question :

  • Est-ce que le système A sait faire ceci ? Oui, non, partiellement (donner un pourcentage).

  • Quel est le « poids » de cette question ? Il doit absolument faire cela : poids fort. S’il fait cela, c’est plutôt du confort : poids faible.

Cela donne au final un tableau avec des milliers de lignes dont la plupart sont jugées de « poids forts », car la tendance naturelle est de vouloir que le nouveau système fasse tout, y compris le superflu.

L’écriture d’un cahier des charges est une tâche très lourde. Elle demande un travail des fonctionnels pour décrire tout ce que le système doit faire précisément, et de peser chaque fonctionnalité.

Ensuite, il s’agit de remplir ou de faire remplir par les éditeurs (avec quelle confiance ?) ces milliers de lignes pour pouvoir comparer les différents systèmes.

Ensuite de donner une note finale, consolidation magique de toutes les notes de toutes les lignes avec tous leurs poids…

C’est, à mon avis, totalement inutile pour deux raisons :

  • Les fonctionnels, ce faisant, ont inévitablement envie de décrire leur système existant avec des améliorations souhaitées : ils vont juger satisfaisant ce qui ressemble à ce qu’ils connaissent déjà et insatisfaisant ce qui les en éloigne.

  • Les notes obtenues, au final, sont aujourd’hui extrêmement proches : en effet, les ERP importants ont sensiblement la même couverture fonctionnelle. Donc l’écart mesuré est, au final, du « bruit », résultat de toutes les approximations dans les notations et les poids.

En conclusion, ce très lourd et très coûteux travail donne très peu de résultats et ne permet pas de choisir la meilleure solution.

2. Les critères de sélection

Au final, je vous conseille de faire le choix de votre nouvel ERP non pas par rapport à sa couverture fonctionnelle...

L’objectif du projet

« Ceux qui ne savent pas où ils vont seront surpris d’arriver ailleurs » Pierre DAC.

J’entends trop souvent : « L’objectif du projet, c’est de le réussir ! ».

Bien sûr, mais pour le réussir, l’objectif du projet doit être clairement défini, connu de tous, acteurs du projet comme futurs utilisateurs, ainsi que de leurs managers.

Rappelez-vous de ceci : un projet est une aberration dans une organisation.

En effet, chaque service d’une organisation est construit pour gérer les trois flux qui traversent l’entreprise : flux d’information (commande client), flux matière (expédition de produits finis), flux d’argent (mon client règle sa facture). Chaque service est pérenne et nécessaire au bon fonctionnement de l’entreprise. Ce sont des rouages nécessaires au bon fonctionnement de l’entreprise.

Un projet, c’est tout le contraire : il a un début et une fin. Il ne faut pas confondre le projet de mise en place d’un ERP et sa maintenance récurrente et pérenne après le Go Live qui, elle, devient un nouveau rouage de l’organisation.

Ainsi donc, comment définir clairement l’objectif d’un projet ?

En définissant par une mesure claire et non ambigüe ce qui va marquer sa fin.

Voici quelques pièges à éviter…

1. Projets sans fin

« Augmenter la productivité » n’est pas un objectif de projet (il ne se finira jamais !).

« Augmenter la productivité de 5 % »...

Le planning du projet

Une fois l’objectif du projet décliné en sous-objectifs grâce aux fishbones (cf. La mise en place du projet - La conception : le "design" - L’atteinte des objectifs du projet), chaque livrable est estimé en jours x homme (mandays), non pas en délai mais en charge de travail, dans les WBS (Work Breakdown Structure, défini dans le chapitre Les méthodes et outils essentiels - WBS ainsi que dans le lexique anglais/français à la fin de ce livre).

Cette phase de planification intervient donc pendant la phase de design et ne peut se faire avant. En effet, il n’est pas possible de planifier la réalisation de quelque chose qui n’est pas conçu. Cette charge est répartie sur les acteurs du projet, internes et externes. Le planning sera alors la conséquence de la charge de travail de chaque livrable et de la disponibilité des acteurs du projet.

Utilisez des outils comme MS Project pour établir finement le planning. Les fishbones se traduiront en diagrammes de PERT. Les WBS serviront à calibrer la charge de chaque livrable. Le chemin critique donnera alors la date prévisionnelle de fin du projet.

Attention également à planifier les « prérequis ». Ce sont d’autres projets de l’entreprise qui peuvent être SI (montée de version d’autres briques...

Le coût du projet

Le périmètre du coût du projet doit être clairement défini dès le départ :

  • Les coûts prennent fin lorsque le projet est terminé, c’est-à-dire lorsque l’objectif est atteint.

  • S’il y a un deuxième lot, c’est-à-dire un deuxième projet ayant lui-même son propre objectif, alors il faudra clore le premier projet en termes de coût et en ouvrir un second.

  • Il ne faut pas confondre le coût du projet et les coûts récurrents une fois le Go Live effectué. Le coût du « RUN » est un coût récurrent qui ne doit pas être confondu avec le coût du projet.

Le coût du projet se décline en plusieurs thèmes :

  • Le coût d’achat des licences de l’ERP et de la base de données. Si ces licences sont en location, en mode SAAS, ils ne seront pas inclus dans le coût du projet, mais dans le « RUN ». Si ces licences sont achetées, elles représentent alors un investissement qui se retrouve dans le bilan comptable de la société. Les licences peuvent être dépréciées sur 5 ou 7 ans, en estimant la durée d’utilisation de cet ERP.

  • Le coût d’achat de nouveaux matériels « hardware » (serveurs…). Dans le cas où ces serveurs sont hébergés chez un tiers, ce coût sera alors inclus dans le « RUN ». La dépréciation de ces matériels n’est pas liée au projet, mais au matériel lui-même par rapport à sa durée de vie. À titre d’exemple, un serveur peut se déprécier sur 3 ans, un PC sur 2 ans, etc.

  • Le coût...

Les gains du projet

Il n’est pas fréquent d’établir un ROI (retour sur investissement) d’un projet ERP, c’est-à-dire ce que le projet va rapporter par rapport à ce qu’il va coûter. En effet, la décision de changer de SI est rarement une décision économique, même si cela devrait l’être le plus souvent.

Il s’agit souvent d’une décision prise dans l’urgence pour les raisons suivantes :

  • La technologie utilisée devient obsolète : plus de maintenance du hardware ou du software.

  • Incapacité à maintenir le SI : l’éditeur n’existe plus, l’intégrateur non plus. Les compétences sur le système sont rares.

  • Les montées de versions sont devenues impossibles : trop de développements spécifiques ; écart trop grand entre la version utilisée et la dernière version de l’éditeur ; l’éditeur ne propose plus de nouvelle version, ou celle qu’il propose demande un changement complet de l’infrastructure (hardware, base de données, réseaux…).

  • Les compétences internes sont trop peu nombreuses : quelques-uns, voire parfois une seule personne, connaissent le système actuel.

  • Départ des compétences internes : démissions, retraites, évolutions.

  • Exigences clients, exigences légales impossibles à satisfaire.

Bien que très souvent prise dans l’urgence, cette décision peut bien évidemment être anticipée par un suivi régulier des risques de l’entreprise liés au SI.

En effet, une obsolescence n’arrive pas du jour au lendemain. Elle s’anticipe. Tout comme la santé financière de l’éditeur et de l’intégrateur, la maîtrise des développements spécifiques, le suivi inconditionnel des montées de versions de l’éditeur, la gestion prévisionnelle des compétences internes, etc. (cf. chapitre Le démarrage du nouveau SI - L’après-projet - Le tableau de bord de l’ERP).

Donc, même si les gains du projet ne sont pas un « driver » de la décision de changer de SI, cela signifie-t-il pour autant qu’il...

La stratégie de déploiement

Il existe plusieurs façons pour déployer un nouveau SI.

Voici les différents types possibles :

  • Le déploiement en Big Bang, c’est-à-dire toutes les fonctionnalités et entités en même temps.

  • Le déploiement par groupe de fonctionnalités : par exemple, commencer par la finance sur toutes les entités (sociétés juridiques ou géographiques) puis, une fois que ce premier lot est stabilisé, faire basculer toutes les entités avec les autres fonctionnalités.

  • Déployer par pays (ou région) toutes les fonctionnalités : changement du SI pour toutes les fonctionnalités sur le pays historique du groupe, puis déployement de ce SI sur les autres pays.

  • Déploiement mixte : déployer en Big Bang les fonctionnalités « back-office » (tout ce qui ne touche pas le client, comme la comptabilité, les achats, le transport des matières premières, etc.) sur toutes les entités. Puis, déploiement pays par pays des autres fonctionnalités « sensibles » en contact avec le client (administration des ventes, transport des produits finis…).

images/DP02-04.png

Le Kick Off

Le Kick Off est le lancement officiel du projet.

Ce n’est pas le moment où l’entreprise se met à travailler sur le projet, mais le moment où elle communique largement sur le projet. Ce qui veut dire que de nombreux points ont déjà été définis en amont.

La communication du Kick Off doit contenir les éléments suivants :

  • Le sponsorship de la direction générale : engagement fort, mot du directeur, sa signature…

  • Le « pourquoi » du projet : donner du sens à ce qui va être fait.

  • L’analyse critique (mais positive) de la situation actuelle.

  • L’objectif (clair et mesurable) du projet (cf. chapitre L’avant-projet - L’objectif du projet) : la situation future.

  • Les acteurs du projet : le pilote du projet, les pilotes métier, le chef de projet, les Key Users, le comité projet, le comité de pilotage, le comité stratégique, l’intégrateur, l’éditeur… (cf. chapitre Les acteurs du projet et chapitre La mise en place du projet). 

  • Les rôles et responsabilités de chacun (cf. chapitre Les acteurs du projet - Les acteurs du projet). 

  • Le planning prévisionnel (cf. chapitre Les méthodes et outils essentiels - Le suivi du planning). 

  • Le budget du projet (à ne communiquer qu’avec prudence...