Nouvel ERP, implantation d’une nouvelle version de WMS, montée de version d’un TMS… nombreux peuvent être aujourd’hui les projets IT au sein de nos chaînes logistiques. Et très régulièrement (même trop régulièrement), nous choisissons de faire des développements spécifiques…
Quel est le problème pourriez-vous me dire en tant que néophyte ? Eh bien, ils sont justement nombreux ! Avec cette publication je vous propose de balayer ensemble cette thématique.
Implantation d’un nouveau SI, comment ça marche ?
Ça y est, Paul revient tout content dans l’open space de la réunion qu’il vient d’avoir avec la DSI. Il croise ses équipes et leur annonce que les budgets ont enfin été accordés au projet de changement de WMS. Les ateliers de design avec l’éditeur retenu lors de l’appel d’offre vont enfin pouvoir débuter !
Pour chaque projet que vous allez mener ateliers vont avoir lieu avec l’éditeur. Appelés en général ateliers de « design » ils vont servir aux équipes de l’éditeur à identifier correctement les besoins que vous avez et, quelles briques de la solution utiliser pour répondre à ce besoin.
Il en résulte donc un certain nombre d’heures d’échanges durant lesquelles l’éditeur va venir vous challenger afin de coller au maximum à la solution. Cette étape est également le meilleur moment pour apporter des améliorations aux processus existants. De manière générale il est n’est pas bon de venir calquer ce que vous faisiez avant pour le faire rentrer dans votre nouvel outil…
Mais malheureusement, il y a des moments où le client (vous et moi) demandons à l’outil des choses que celui-ci ne sait pas faire nativement. C’est là que les choses se compliquent et que les fameux développements spécifiques arrivent…
Développements spécifiques.. c’est là que je projet dérape
Prenons un exemple pour illustrer de cas de demandes spécifiques qui in fine vont entraîner un développement spécifique.
Paul notre responsable supply chain travaille avec une veille version d’un WMS qui était plutôt malléable. Un certain nombre de fonctionnalités avaient été intégrées au fil des années. Au fil des ateliers de design, les équipes de Paul on fait remarquer que si elles se conformaient au fonctionnement standard du nouvel outil, beaucoup de reporting et d’habitudes allaient se trouver chamboulées.
Face à cet ensemble de remarques pertinentes, Paul choisit d’aller dans le sens de ses équipes et demanda que plusieurs fonctionnements soient développés et intégrés à la solution…
Quels sont les impacts d’un développement spécifique ?
Pour comprendre le danger des développements spécifiques il faut prendre le problème du point de vue plus large que le simple fait de payer pour développer des solutions / fonctionnements qui n’existent pas en standard.
Toute solution IT développée par un éditeur est connue, testée et maintenue au fil du temps par les équipes de celui-ci. Elles connaissent les fonctionnements, les rouages…
En premier lieu, des développements spécifiques vont vous coûter du temps et de l’argent. La durée de votre projet va s’en trouver rallongée et par conséquent, les frais de pilotage inhérent à celui-ci seront plus importants. Le coût de déploiement de la solution s’en trouvera aussi comme je le disais augmenté.
Ensuite, lorsque vous rajoutés des éléments supplémentaires qui ne sont pas dans le standard vous aller dans un premier temps changer la manière de fonctionner de l’outil. Ce changement va induire plus de temps à tester les mises à jour régulières poussées par l’éditeur afin de s’assurer qu’il n’y a pas de dysfonctionnements . C’est donc un coût supplémentaire de MCO (maintien en condition opérationnel) auquel vous vous exposez. Il vous sera peut-être même nécessaire d’avoir des équipes support en interne plus nombreuses et de leur faire suivre une formation plus longue auprès de l’éditeur.
Enfin, en cas d’incidents vous vous exposez à des temps de résolution plus longs si jamais vous êtes sur un incident sérieux. Pourquoi ? Et bien tout simplement par ce que le fonctionnement « normal » de la solution ne sera pas respecté dans votre cas. Les équipes de l’éditeur devront donc surement passer plus de temps à tester pour identifier la cause de votre dysfonctionnement.
En synthèse… privilégiez le standard… ne vous aventurez pas trop sur les terres du spécifique !
Bonsoir,
Article très intéressant. Demander des dévs spécifiques lors de l’installation d’un nouvel ERP pour coller à notre solution actuelle engendre en effet des coûts supplémentaires comme énoncé. D’un autre côté, vouloir perdre ses fonctionnalités pour se conformer à un standard peut engendrer une quantité astronomique de chose à revoir à tous les niveaux dans notre manière de faire, et ce n’est pas non plus gratuit…
Tout est question de dosage et/ou compromis. Il n’y a pas de solution miracle et unique. Certes, un nouvel ERP est l’occasion rêvée de revoir certains processus, mais il ne faut pas tomber dans l’accès de standardisation : les bonnes choses on peut aussi les garder!