Les ERP ont bien évolué
Le terme ERP évoque parfois un logiciel énorme et global, réservé aux grandes entreprises, long à mettre en place, coûteux à installer et à maintenir.
Ce type d’ERP a existé et existe encore. Mais depuis leur émergence il y a une vingtaine d’années, les ERP ont bien évolué.
Disposer d’un ERP n’est plus l’apanage des grandes organisations et n’implique plus nécessairement le jeu de contraintes évoqué plus haut.
Finalement, qu’est-ce qu’un ERP ? Pour faire simple, un ERP est une base de données unique, partagée par tous les acteurs de l’entreprise et avec laquelle chacun réalise les opérations de son périmètre de responsabilités.
Un ERP est une base de données centrale sur laquelle plusieurs modules fonctionnels permettent de réaliser des opérations
Un ERP favorise ainsi la circulation de l’information.
Prenons l’exemple des niveaux de stock : quand des produits sont fabriqués ou réceptionnés par les équipes d’achat et de logistique, le niveau de stock est mis à jour et les équipes de ventes sont immédiatement informées qu’elles pourront livrer leurs clients.
De même, il n’est plus nécessaire de gérer deux niveaux de stock, un dans le logiciel de fabrication ou d’achats et un autre dans le logiciel de ventes. Un ERP assure donc la présence d’informations à jour à l’ensemble des acteurs de l’entreprise, et limite ainsi les opérations redondantes.
Retour d’expérience : l’installation d’un ERP chez un de nos clients PME
Le choix de l’Open Source
Le premier enjeu était de nous adapter aux contraintes financières de notre client, PME en croissance, dont les ressources étaient concentrées sur son développement commercial.
La mise en place d’un ERP induit plusieurs types de coûts :
1. le projet d’intégration
2. les licences au démarrage
3. les coûts de maintenance au cours de la vie du logiciel
4. l’appropriation par les équipes du produit et des changements de pratique imposés
Nous nous sommes tournés vers un ERP Open Source très largement diffusé, dont le code est libre d’accès. Si l’avantage immédiat est l’absence de coûts de licence, cette particularité est également gage de fiabilité car des centaines de développeurs collaborent au quotidien pour corriger et améliorer l’outil.
Nous avons sélectionné un ERP phare du marché Open Source, pour les raisons suivantes :
- Sa scalabilité, soit sa capacité à gérer les PME comme les grandes entreprises
- Son ergonomie
- Sa pérennité gagée par une large base d’utilisateurs
- Sa facilité d’intégration avec les outils informatiques que notre client devait conserver
La non reprise de données : un choix décisif
Le choix, fait avec notre client, de ne pas reprendre les données des anciens outils de gestion dans l’ERP, mais de les stocker en format tableur, a été déterminant pour le coût et la rapidité du projet.
La reprise de données est en effet une étape difficile de tout projet informatique. La complexité qu’elle induit impose de se poser les questions suivantes :
- Les données historiques seront-elles utiles et utilisées par l’entreprise ?
- Les données ont-elles une complétude et une qualité suffisante ?
- Sont-elles aisément transférables dans le nouvel outil informatique ?
De manière générale il faut rapprocher l’investissement nécessaire à une reprise de données des gains attendus de la conservation des données dans l’outil.
Un ERP modulaire
L’ERP que nous avons sélectionné fonctionne par modules : achats, ventes, facturation, etc. Chaque module couvre un besoin fonctionnel. Et vous trouverez toujours un module adapté à vos besoins spécifiques (ex. la gestion d’un parc de véhicules, un réseau social) parmi les centaines proposés par la communauté. Ce mode de fonctionnement permet de limiter les coûts d’investissement en n’installant et ne paramétrant que les modules qui vous sont véritablement utiles. Il sera toujours possible d’augmenter le périmètre fonctionnel de votre ERP le jour où vous en aurez besoin.
L’ERP est installé par modules : chaque organisation dispose des briques correspondant à ses besoins
Chaque module dispose de paramétrages de premier niveau, qui permettent d’adapter l’outil à vos pratiques métiers. Il existe également des paramétrages simples qui permettent de modifier les processus transverses à différents modules.
Les étapes de notre intervention
Nous évaluons les besoins métiers puis sélectionnons les modules adaptés à ces besoins pour enfin former les utilisateurs individuellement. Nos consultants assurent ensuite un support réactif afin de simplifier la prise en main de l’outil par les équipes.
Nous avons procédé en trois temps : analyse des besoins et pratiques métiers puis sélection, installation et paramétrage des modules adaptés et enfin formation des utilisateurs.
En matière de formation, eu égard à l’ergonomie de l’outil et aux contraintes financières, nous avons fait le choix de formations individuelles légères et d’un support très réactif, notamment lors des premières semaines. L’expérience montre par ailleurs qu’une formation exhaustive des équipes n’est pas des plus efficace car elles ne peuvent pas retenir l’intégralité des informations communiquées : la pratique est nécessaire.
Au fil des mois, nous avons augmenté le périmètre fonctionnel de l’outil en suivant les mêmes principes : une formation centrée sur l’essentiel et un support fonctionnel et technique efficace et réactif. Les besoins de support, réguliers dans les semaines qui suivaient la mise en place de nouvelles fonctionnalités, étaient presque réduits à néant en vitesse de croisière.
L’erreur à éviter : adapter, à la virgule près, l’ERP aux pratiques métiers
Le code étant disponible, l’autre intérêt des ERP Open Source est en effet de pouvoir être modifiés en profondeur pour être adaptés aux besoins de l’entreprise si le paramétrage de premier niveau n’est pas suffisant.
Ce n’est pas une bonne idée.
En effet, les configurations natives de l’ERP correspondent aux pratiques courantes de milliers d’entreprises utilisatrices. On peut donc raisonnablement imaginer que ce sont des options réfléchies qui découlent de l’expérience de nombreux professionnels.
De plus, les besoins qui nécessitent des développements spécifiques de l’outil aujourd’hui seront-ils les mêmes dans 6 mois ? Les personnes qui expriment ces besoins spécifiques seront-elles encore au même poste dans 1 an ?
Réaliser des développements spécifiques induit un coût lors du projet mais également lors des futures montées de version de l’outil qui ne tiennent pas compte des modifications de code spécifiques à chaque projet.
