Blog ENI : Toute la veille numérique !
En raison d'une opération de maintenance, le site Editions ENI sera inaccessible le mardi 10 décembre, en début de journée. Nous vous invitons à anticiper vos achats. Nous nous excusons pour la gêne occasionnée
En raison d'une opération de maintenance, le site Editions ENI sera inaccessible le mardi 10 décembre, en début de journée. Nous vous invitons à anticiper vos achats. Nous nous excusons pour la gêne occasionnée

La mise en place du projet

La conception : le "design"

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 :

  • Analyser les process actuels, parfois différents d’une entité à une autre, d’un pays à un autre.

  • Les comparer avec les « best practices » du secteur (à l’aide d’une expertise externe nécessaire).

  • Les comparer également avec ce que l’ERP peut modéliser.

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 :

Arguments

Option 1

Option 2

Option 3

Fonctionnel

+/-

+/-

+/-

Coût

+/-

+/-

+/-

Savings

+/-

+/-

+/-

Efficience

+/-

+/-

+/-

Sécurité

+/-

+/-

+/-

Simplicité

+/-

+/-

+/-

Pérennité

+/-

+/-

+/-

Respect des obligations légales

+/-

+/-

+/-

Autres…

+/-

+/-

+/-

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...

Build

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 :

  • Des données d’entrée, internes ou externes.

  • Des actions qui décrivent le scénario lui-même.

  • Des données de sortie, vers l’interne ou vers l’externe (clients, fournisseurs, banques, etc.).

  • Un groupe qui va avoir pour fonction de réaliser ce scénario.

images/DP03-32.png

Vérifications

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

  • Soit des données externes.

  • Soit des données de sortie d’autres scénarios.

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

  • Soit des données vers l’externe, et vérifier que « l’externe » en a toujours besoin. 

  • Soit des données d’entrée d’autres scénarios.

  • Dans le cas contraire, ces données de sortie ne servent à personne et la pertinence du scénario doit être remise en cause.

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

Tests (recettage)

Il ne s’agit pas ici de faire les tests dans tous les sens sans organisation, de « cliquer partout pour voir si ça fonctionne ». Les scénarios de tests ont été rédigés lors de la phase de conception et ils vont précisément servir à cette phase. Ils ont été modifiés en fonction des arbitrages de modification de process ou d’organisation. Ils ont ensuite été transformés en mode opératoire c’est-à-dire en décrivant le « comment » dans le nouveau SI.

Les tests consistent à dérouler les modes opératoires et vérifier que les résultats sont ceux attendus. Si ce n’est pas le cas, un incident sera créé identifiant le mode opératoire concerné ainsi que l’écart entre ce qui est attendu et ce qui est produit. Les tests doivent être d’abord réalisés par l’équipe projet, puis par les KU. Ils doivent être exhaustifs pour permettre de prendre la bonne décision lors du Go/Nogo.

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 :

  • Incident de type A : impossibilité...

La reprise de données

La reprise de données consiste à intégrer dans le nouveau système, automatiquement ou manuellement, les données des anciens systèmes.

Mettre en place un ERP se fait rarement « à partir de rien ». Le plus souvent, il existe déjà un ou plusieurs systèmes opérationnels, dans les entités, dans les pays. Reprendre les données de base (clients, fournisseurs, produits, nomenclatures, gammes, etc.) peut être un travail très lourd s’il est fait manuellement dans le nouvel ERP.

Il peut être automatisé si l’ERP permet la reprise de données en masse : il propose alors un format de fichier qui va permettre d’intégrer automatiquement les données. Il faut donc développer, si ce n’est pas le cas, des programmes d’extraction de ces données des systèmes en place et ce, au format prédéfini par l’ERP. Ces développements doivent se faire lors de la phase de build, mais leur lancement (qui ne se fera qu’une fois) ne sera réalisé qu’à une date très proche du Go Live. En effet, une fois cette reprise faite dans le futur environnement de production, toute nouvelle donnée (un nouveau client par exemple) devra être entrée dans le système actuel ainsi que dans le nouvel...

La formation

Dans tous les plannings, il y a une case « formation des utilisateurs » un peu avant le Go Live.

Ces formations sont trop souvent données par des membres du projet, voire par des consultants externes.

C’est une erreur pour plusieurs raisons :

  • L’objectif n’est pas que les utilisateurs soient formés mais qu’ils sachent utiliser le nouveau système. La formation y concourt, mais n’est pas suffisante : elle doit être vérifiée par un « contrôle des acquis ». Il arrive parfois qu’une personne ayant été formée n’arrive pas à maîtriser totalement le nouveau système. Dans ce cas, il est préférable de ne pas lui en donner l’accès, la correction d’erreurs peuvant être très chronophage.

  • La formation est un process continu de l’entreprise. Elle ne doit donc pas être considérée comme un one-shot. Les personnes initialement formées ne seront peut-être plus là un an plus tard, de nouveaux arrivants vont également devoir être formés. Ce qui pose les questions suivantes : qui est le plus légitime pour former ? Qui doit former ? Qui doit gérer ces formations ? La réponse à ces questions doit forcément faire appel à des organisations pérennes de...

Les livrables

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.

  • Exemple : tous les fournisseurs sont réglés par virement.

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.

  • Exemple : les factures fournisseur doivent être conservées 10 ans.

… mais peuvent les compléter.

  • Toutes les factures fournisseur de l’année sont conservées au service comptable. 

  • Toutes les factures de l’année précédente sont archivées à l’extérieur chez notre prestataire X.

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...

Le Go/Nogo

Le Go/Nogo est la décision de basculer du Système d’Information actuel au futur système. Cette décision est très importante et doit être prise par le comité de pilotage qui doit en évaluer tous les aspects.

Voici un tableau qui peut aider à prendre la décision : images/DP03-37.png

CRITÈRES

État

Les règles de gestion sont définies et validées.

Tous les process sont testés dans le nouveau système.

Tous les matériels nécessaires sont installés et testés.

Tous les users sont dans le SI Prod avec les profils adéquats.

Les données importées et ajoutées manuellement sont vérifiées.

Les users savent utiliser les nouveaux SI, process et Orga.

L’environnement de production est opérationnel.

La nouvelle organisation est opérationnelle.

L’organisation des supports est opérationnelle.

L’organisation récurrente de la formation est opérationnelle.

L’organisation de l’évolution du SI est opérationnelle.

L’organisation de l’évolution des accès est opérationnelle.

L’organisation du Go Back est opérationnelle.

La date du Go Live est largement communiquée en interne + externe

Anciens SI déconnectés et sauvegardés.

L’organisation de l’exploitation...