Voici quelques pièges à éviter dans le cadre d’un projet ERP :
- Sous-estimer le temps et les ressources nécessaires : il est important de prévoir suffisamment de temps et de ressources pour réaliser le projet de manière efficace. Si le projet est sous-estimé, il y a un risque de dépassement de budget et de délais.
- Sous-estimer l’impact du projet sur les utilisateurs : il est important de tenir compte de l’impact du projet sur les utilisateurs et de s’assurer qu’ils sont bien formés et préparés à utiliser le nouveau système. Si l’impact du projet sur les utilisateurs est sous-estimé, il y a un risque de résistance au changement et de baisse de productivité.
- Ne pas impliquer suffisamment les utilisateurs et les responsables de l’entreprise : il est important d’impliquer les utilisateurs et les responsables de l’entreprise dans le projet et de les informer des avancées et des changements apportés par le nouveau système. Si l’implication des utilisateurs et des responsables de l’entreprise est insuffisante, il y a un risque de manque de soutien pour le projet et de difficultés à le mettre en œuvre.
- Choisir un fournisseur et un logiciel inadaptés : il est important de choisir un fournisseur et un logiciel qui répondent aux besoins de l’organisation et qui ont une bonne réputation en termes de qualité et de support. Si le fournisseur et le logiciel sont inadaptés, il y a un risque de problèmes techniques et de mauvaise qualité de service.
- Ne pas prévoir suffisamment de temps pour la formation et le support : il est important de prévoir suffisamment de temps pour former les utilisateurs au nouveau système et pour fournir un support technique de qualité. Si la formation et le support sont insuffisants, il y a un risque de difficultés pour les utilisateurs à utiliser le système et de problèmes techniques non résolus.
- Le développement de logiciels spécifiques peut sembler attrayant pour les entreprises, car cela leur permet de personnaliser le logiciel selon leurs besoins spécifiques. Cependant, le développement de logiciels spécifiques peut être coûteux et prendre beaucoup de temps. De plus, ces logiciels sont souvent plus difficiles à maintenir et à mettre à jour que les logiciels existants. Un autre inconvénient du développement de logiciels spécifiques est qu’il peut limiter l’interopérabilité avec d’autres systèmes. Ils peuvent être difficiles à intégrer avec d’autres systèmes, ce qui peut entraîner des coûts supplémentaires et des retards dans les projets.
En résumé, pour éviter les pièges d’un projet ERP, il est important de prévoir suffisamment de temps et de ressources, de tenir compte de l’impact du projet sur les utilisateurs, d’impliquer les utilisateurs et les responsables de l’entreprise, de choisir un fournisseur et un logiciel adaptés et de prévoir suffisamment de temps pour la formation et le support. Mais surtout de maitriser le nombre de spécifiques.
Soyons précis lorsque nous parlons de programmes spécifiques dans les processus de l’entreprise. Les interfaces ou les éditions sont des sujets à part entière dans le projet, mais ce ne sont pas des spécifiques, ce sont plutôt des adaptations que l’on retrouve dans tous les projets. Les développements spécifiques sont tous les programmes que l’on souhaite voir apparaître pour répondre à un besoin de l’entreprise, d’un utilisateur, d’une partie prenante de l’entreprise ou du projet.
Ce travail demande un effort particulier de tous, et il est très important de n’avoir recours au développement spécifique que lorsqu’il est indispensable. Je pense, par exemple, à des contraintes réglementaires ou légales qui n’existeraient pas en standard. Pour le reste, soyons honnêtes, pour les domaines des achats, des ventes, des stocks et de la production, les solutions sont robustes et bien développées. Ce qui l’est moins, et c’est pour cela qu’il faut être vigilant dans le choix de l’outil, ce sont les domaines et modules du service après-vente, de la gestion des temps et activités, des modules techniques et certainement d’autres. C’est pourquoi le point 4 des erreurs à ne pas commettre est important.
Comme promis, nous ferons un point sur la démarche de communication et du pourquoi de simon sinek dans une prochain épisode. La question de la productivité me semble plus intéressante.
Pourquoi faire développer du spécifique peut être contre-productif
Introduction
Lorsqu’une entreprise décide de mettre en place un système informatique pour améliorer ses processus métiers, elle doit choisir entre deux options : faire l’intégration d’un outil d’un éditeur (SAP, IFS, ORACLE, Microsoft, SAGE, CEGID…..) en restant dans le standard ou adapter un logiciel existant je ne souhaite pas rentrer dans le détail du développement complet, du développement partiel ou autres. Nous allons voir les difficultés que peuvent engendrer cette seconde solution et pourquoi faire développer du spécifique peut être contre-productif.
Adapter les processus métiers
L’adaptation d’un logiciel existant à ses processus métiers est une option courante pour les entreprises. En restant dans le standard on facilite l’intégration par l’intégrateur, par les utilisateurs, pour les futurs nouveaux embaucher et pour la continuité de service. Ceci sans parler de la robustesse de solutions standard éprouvées. Vraiment, ce qu’il faut garder à l’esprit c’est la continuité de service dans le temps, les évolutions et montée de version seront plus aisées. En effet, les logiciels existants sont souvent conçus pour répondre aux meilleures pratiques du secteur et peuvent offrir des fonctionnalités avancées pour améliorer les processus métiers.
Les inconvénients du développement de spécifique
Le développement de spécifique peut sembler attrayant pour les entreprises, car cela leur permet de personnaliser le logiciel selon leurs besoins spécifiques. Cependant, le développement de spécifique peut être coûteux et prendre beaucoup de temps, dans un premier temps. Dans un second temps les développements spécifiques sont souvent plus difficiles à maintenir et à mettre à jour que les logiciels existants.
Les développements spécifiques ont une résilience très faible face aux montées de version. Un exemple concret serait un de mes clients qui avait créé de nombreux spécifiques dans son système d’information à partir d’un ERP du marché. Tous les trois ans, le client devait reprendre l’ensemble des spécifiques, ce qui représentait plus de 200 programmes à reprendre. Pour cela, il fallait prévoir un projet d’environ un an avec une équipe de cinq personnes, incluant l’éditeur et l’intégrateur pour un soutien optimal. La question du ratio gain versus coût récurrent doit être posée dans ce cas. En outre, les nouvelles recrues ne pouvaient pas simplement intégrer les équipes, car elles devaient suivre un parcours d’intégration spécifique et coûteux.
Limiter le nombre de spécifique
Il est important de limiter le nombre de logiciels spécifiques dans une entreprise. En effet, plus il y a de spécifique, plus il est difficile de les maintenir et de les mettre à jour. De plus, chaque logiciel spécifique ajoute de la complexité au système informatique de l’entreprise, ce qui peut entraîner des problèmes des coûts supplémentaires.
La meilleure approche consiste à utiliser des logiciels existants et à les adapter aux processus métiers de l’entreprise. Si l’entreprise a besoin de fonctionnalités spécifiques qui ne sont pas disponibles dans les logiciels existants, elle devrait envisager de développer des modules complémentaires plutôt que de développer un logiciel spécifique.
Sans une gestion rigoureuse du nombre de spécifique et sans une analyse précise à l’aide d’une méthodologie adaptée, on se retrouve a devoir multiplé les ressources pour développer les ressources et les maintenir. Comme illustré ici sans cette méthodologie (ci-dessous) il faudrait donc inviter shiva dans les projets ERP.
Pour éviter tout débordement du nombre de spécifique, je propose cette méthodologie simple :
1 – Le demandeur doit spécifier clairement le besoin
2 – La demande doit être justifiée et argumenté dans l’esprit : “6 pager de Jeff Bezos” (voici un exemple : https://bit.ly/3Z3ar7G)
3 – Une estimation du cout doit être faite par l’éditeur / intégrateur
4 – Une commission incluant le sponsor du projet doit décider en gardant à l’esprit que ce processus de choix est “lean management”, et donc qu’il faut conserver que le stricte nécessaire.
5 – S’assurer dans le cadre du développement de la “maintenabilité” du spécifique en respectant les règles de développement et en documentant le spécifique
Ainsi, le nombre de spécifique sera limité et les spécifiques conservés seront vraiment utiles aux processus de l’entreprise.
Lean Management
Le Lean Management est une méthode de gestion qui vise à améliorer l’efficacité de l’entreprise en éliminant les gaspillages et en optimisant les processus. Cette méthode est souvent utilisée dans les entreprises manufacturières, mais elle peut également être appliquée dans d’autres secteurs.
Le Lean Management repose sur cinq principes fondamentaux :
- La valeur : la valeur est définie comme tout ce qui est important pour le client. Il est donc essentiel de comprendre les besoins des clients et de fournir des produits et services qui répondent à ces besoins.
- Le flux de valeur : le flux de valeur est le processus qui permet de créer de la valeur pour le client. Il est important d’identifier les étapes du processus et d’éliminer les gaspillages.
- La production tirée : la production tirée signifie que la production ne doit pas dépasser la demande du client. Il est donc essentiel d’adapter la production en fonction de la demande réelle.
- La perfection : la perfection est l’objectif ultime du Lean Management. Il s’agit d’atteindre un niveau d’efficacité optimal en éliminant tous les gaspillages et en améliorant en permanence les processus.
- Le respect des personnes : le respect des personnes est un élément essentiel du Lean Management. Il s’agit de reconnaître la valeur des employés et de les impliquer dans le processus d’amélioration continue.
Conclusion
En conclusion, le développement de spécifique peut sembler attrayant pour les entreprises, mais cela peut être contre-productif. Les logiciels existants offrent souvent des solutions éprouvées et une expertise des fournisseurs de logiciels, tandis que les logiciels spécifiques peuvent être coûteux et difficiles à maintenir. Il est important de limiter le nombre de spécifique dans une entreprise pour éviter les problèmes de compatibilité et les coûts supplémentaires. La meilleure approche consiste à utiliser des logiciels existants et à les adapter aux processus métiers de l’entreprise, en développant des modules complémentaires si nécessaire, en conservant la maitrise de ces adaptations tels que les coûts et la pérennité.
