Plus court, plus vite
Trente ans après la création de l’univers ERP, on peut se poser les bonnes questions sur son expansion dans l’entreprise. Aujourd’hui, la poursuite ou la création du déploiement reste un vrai défi. Et à tout le moins, la question du "comment" se pose avec acuité. Doit-on tout changer d’un coup, pour tout le monde, ou faut-il opérer par vague, étape par étape ?
L’ERP est arrivé au moment où les entreprises organisées en silos et de façon très hiérarchique ont eu accès aux télécommunications.
Dans le même temps, on s’apercevait que les limites des structures étaient atteintes. L’ERP s’est imposé comme le plus puissant des outils pour créer de la transversalité et faire communiquer les services entre eux. Pour autant, au premier abord, la situation relève du paradoxe : opter pour des outils dans l’optique de faire communiquer les services
entre eux alors qu’au quotidien, on leur demande de travailler d’abord pour eux et de défendre leurs intérêts. Dans les faits, chacun a la responsabilité de ses processus et veille sur son département.
A tel point d’ailleurs qu’il ne le quittera qu’à l’âge de trente-trois ans. Son père lui explique
que pour être tranquille dans la vie, il faut être sérieux. Il l’est. Mais à l’orée de la seconde,
la motivation décline. Un conseiller le remotive en lui parlant d’un BEP de comptabilité.
Obtenu brillamment, il rattrape sa route vers un bac G2 où la compta est reine.
Les résultats sont bons. On conseille à Michel de s’orienter vers de longues études.
Mais lui préfère un parcours plus court pour entrer plus vite dans la vie active.
Sa décision est prise, ce sera un BTS. Il enchaîne ensuite sur une maîtrise de gestion.
Comptable en uniforme
Et puis il a aussi des contraintes, notamment celles du service militaire "Pendant dix mois, à Montauban puis Vincennes" reprend Michel. Là, il endosse l’uniforme du comptable pour
s’occuper de la solde du contingent. "J’étais chanceux avec ce poste tranquille après des classes plus rugueuses", précise-t-il. Juste après l’armée, la chance l’attend encore dans une agence d’intérim. On lui propose de remplacer au poste de comptable une collaboratrice qui s’est cassée la jambe. "En fait, le PMU me met le pied à l’étrier", s’amuse Michel. Il y restera trois ans. Puis d’autres horizons s’ouvrent à lui. Notamment publicitaires chez Publicis Conseil.
Des sociétés de services l’accueillent. Jusqu’à Kaba. Ce spécialiste des portes coulissantes lui ouvre les siennes. "Souhaitant renouveler leur système d’information, ils avaient besoin de mon expérience pour être accompagnés dans ce changement". Les solutions du marché ne plaisent pas à Michel. C’est alors que des consultants de Navision viennent le voir. Leur offre plait au Directeur comptable de Michel et l’implémentation est mise place avec succès. Michel ayant découvert le métier de consultant est tenté par l’activité. Intéressé par la compétence comptable de Michel, Navision lui propose de le former au consulting.
Puis Michel entre chez Colombus, intégrateur AX. Les projets s’enchaînent, spécialement
chez Saint-Gobain Glass. Ensuite, il entre chez Avanade et quelques années plus tard
il intègre l’ESN Viseo.
De façon assez binaire, quand on étudie le déploiement d’un ERP, deux options de changement se présentent : l’une globale, en une fois, l’autre par vagues. Dans le cadre d’un Big Bang radical, tout le monde changera d’outil du jour au lendemain, avec à la clé de nouvelles méthodes. Cette approche a l’avantage de mettre toutes les équipes sur le pont, focalisées sur un objectif fédérateur, commun et clair.
Tout un chacun devient acteur du changement et se sent mobilisé dans une dynamique nouvelle de développement. Néanmoins, au-delà des réticences incompressibles et des freins face à la nouveauté, un inconvénient récurrent apparaît. Le fameux "effet tunnel". L’intégration d’un nouvel outil exige un alignement entre les processus métiers et la solution. À chaque écart, il faut trouver des réponses. Dès lors, c’est au métier ou à l’IT de s’adapter. Il n’y a pas de religion, les problèmes se règlent au cas par cas, avec de longues discussions. On cherche ainsi le modèle parfait, car dans cette approche, peu de changements sont prévus après le démarrage du nouvel ERP. Pour autant, des ratés peuvent créer de fortes incohérences, y compris sur le long terme.
_1.jpg?v=1htnite "Big Bang avec effet tunnel contre changement par étapes vers un ERP unique")
Premiers contacts
Deux ans après, Flexmind le contacte avec un argument décisif : "Ici tu n’auras pas une kyrielle de projets mais un seul, important et captivant". C’est ainsi que Michel démarre en 2012 sur le projet Geodis et fait la connaissance de nombre de ses collègues d’aujourd’hui. En 2017, il quitte le salariat pour le statut d’indépendant et opère pour le groupe Saur. "Pendant ce temps, Geodis s’était séparé de Flexmind pour rejoindre FiveForty°. Jonathan m’appelle pour me proposer de reprendre en sous-traitant sur Geodis en conservant mon nouveau statut", résume le consultant finance Dynamics.
"De toute façon, quand Jonathan a voulu monter sa structure, je n’ai pas hésité une seule seconde". Celui que la chance n’a jamais lâché précise : "Ici, on ne sent pas le poids de la structure, l’aspect famille est palpable. Ce lien social ajouté à la diversité des clients, c’est ce qui donne envie de bosser avec eux".°
L’autre option repose sur un déploiement par vagues ou par lots. Il s’agit de chercher par tous les moyens comment découper son projet en sections indépendantes et déployer chaque segment au fur et à mesure. Quand l’ERP Microsoft Dynamics For Finance & Supply Chain Management est déployé, une trentaine de modules sont à considérer. Il est tout à fait envisageable de n’en déployer que certains. Prenons la finance par exemple. Les outils opérationnels en marche sont conservés avec des interfaces et on choisit de déployer au fil de l’eau. Le principe : atteindre après un certain laps de temps l’objectif d’un ERP unique. Toutefois, à l’échelle d’un groupe international, il est presque impossible d’atteindre ce but. À force d’acquisitions, de fusions et autres adaptations de l’entreprise à son marché, on hérite en permanence d’outils nouveaux qui alimentent les projets des services métiers et IT.
En découpant le projet ainsi, par module, mais aussi par pays, ou par division métier, il est possible d’éviter "l'effet tunnel" et permettre aux métiers d’avancer pas à pas. On cherche ainsi à implémenter, non pas la solution parfaite, mais une solution flexible, adaptable qui peut changer dans le temps. Nous l’avons vu récemment avec la crise sanitaire, les processus ont besoin de s’adapter, rapidement. Les équipes doivent savoir qu’on ne met pas en place un flux pour une quinzaine d’années quand dans les trois ans il pourrait être complétement revu sur demande et ce, dans un délai raisonnable. Grâce à une approche recherchant plus de pragmatisme, il devient possible de donner plus d’indépendance aux équipes dans la logique du modèle "DevOps". Les équipes qui, du besoin à la mise en production d’une solution, sont autonomes et peuvent dans des délais très courts surprendre par leur réactivité. Certes, dans ce cas on dépend beaucoup plus des hommes. En effet, l’organisation n’étant pas au-dessus d’eux pour garantir la qualité des processus, il faut accepter la délégation de responsabilités. En revanche, avec une communication plus simple, plus directe, les effets néfastes de la bureaucratie des organisations s’éloignent et le lien social se renforce apportant moins de turn over et un partage des connaissances important. Avec à la clé, une gestion facilitée des départs dans les équipes. On en vient à dire ici que la qualité d’un projet serait assurée, non pas par des piles de gestion de projet en mode PMO mais par davantage d’indépendance. Nous aurons l’occasion d’en parler dans un prochain sujet.
Finalement, si le Big Bang permet de tout faire en une fois, "l’effet tunnel" reste un risque fort. Dans le cadre d’une option de changement par vague, on peut compter sur un flux plus continu avec un meilleur contrôle assorti d’une capacité d’adaptation plus forte. En tout état de cause, c’est en fonction de la structure de votre entreprise, de vos projets et de la maturité de vos équipes que vous pourrez étudier ces différentes solutions de déploiement. Et pour encore mieux cerner tous les contours et les obstacles d’un projet aussi déterminant, n’hésitez pas à solliciter les retours d’expériences d’experts de l’ERP.°
Par J.Lascaux, Fondateur de FiveForty°
*Big Bang avec effet tunnel contre changement par étapes vers un ERP unique
Partager cet article :
Trente ans après la création de l’univers ERP,
on peut se poser les bonnes questions sur son
expansion dans l’entreprise. Aujourd’hui, la
poursuite ou la création du déploiement reste
un vrai défi. Et à tout le moins, la question du
"comment" se pose avec acuité. Doit-on tout
changer d’un coup, pour tout le monde, ou
faut-il opérer par vague, étape par étape ?
L’ERP est arrivé au moment où les entreprises organisées en silos et de façon très hiérarchique ont eu accès aux télécommunications.
Dans le même temps, on s’apercevait que les limites des structures étaient atteintes. L’ERP s’est imposé comme le plus puissant des outils pour créer de la transversalité et faire communiquer les services entre eux. Pour autant, au premier abord, la situation relève du paradoxe : opter pour des outils dans l’optique de faire communiquer les services entre eux alors qu’au quotidien, on leur demande de travailler d’abord pour eux et de défendre leurs intérêts. Dans les faits, chacun a la responsabilité de ses processus et veille sur son département.
De façon assez binaire, quand on étudie le déploiement d’un ERP,
deux options de changement se présentent : l’une globale, en une fois, l’autre par vagues. Dans le cadre d’un Big Bang radical, tout le monde changera d’outil du jour au lendemain, avec à la clé de nouvelles méthodes. Cette approche a l’avantage de mettre toutes les équipes sur le pont, focalisées sur un objectif fédérateur, commun et clair.
Tout un chacun devient acteur du changement et se sent mobilisé dans une dynamique nouvelle de développement. Néanmoins, au-delà des réticences incompressibles et des freins face à la nouveauté, un inconvénient récurrent apparaît. Le fameux "effet tunnel". L’intégration d’un nouvel outil exige un alignement entre les processus métiers et la solution. À chaque écart, il faut trouver des réponses. Dès lors, c’est au métier ou à l’IT de s’adapter. Il n’y a pas de religion, les problèmes se règlent au cas par cas, avec de longues discussions. On cherche ainsi le modèle parfait, car dans cette approche, peu de changements sont prévus après le démarrage du nouvel ERP. Pour autant, des ratés peuvent créer de fortes incohérences, y compris sur le long terme.
L’autre option repose sur un déploiement par vagues ou par lots.
Il s’agit de chercher par tous les moyens comment découper son
projet en sections indépendantes et déployer chaque segment au fur et à mesure. Quand l’ERP Microsoft Dynamics For Finance & Supply Chain Management est déployé, une trentaine de modules sont à considérer. Il est tout à fait envisageable de n’en déployer que certains. Prenons la finance par exemple. Les outils opérationnels en marche sont conservés avec des interfaces et on choisit de déployer au fil de l’eau. Le principe : atteindre après un certain laps de temps l’objectif d’un ERP unique. Toutefois, à l’échelle d’un groupe international, il est presque impossible d’atteindre ce but. À force d’acquisitions, de fusions et autres adaptations de l’entreprise à son marché, on hérite en permanence d’outils nouveaux qui alimentent les projets des services métiers et IT.
En découpant le projet ainsi, par module, mais aussi par pays, ou par division métier, il est possible d’éviter "l'effet tunnel" et permettre aux métiers d’avancer pas à pas. On cherche ainsi à implémenter, non pas la solution parfaite, mais une solution flexible, adaptable qui peut changer dans le temps. Nous l’avons vu récemment avec la crise sanitaire, les processus ont besoin de s’adapter, rapidement. Les équipes doivent savoir qu’on ne met pas en place un flux pour une quinzaine d’années quand dans les trois ans il pourrait être complétement revu sur demande et ce, dans un délai raisonnable. Grâce à une approche recherchant plus de pragmatisme, il devient possible de donner plus d’indépendance aux équipes dans la logique du modèle "DevOps". Les équipes qui, du besoin à la mise en production d’une solution, sont autonomes et peuvent dans des délais très courts surprendre par leur réactivité. Certes, dans ce cas on dépend beaucoup plus des hommes. En effet, l’organisation n’étant pas au-dessus d’eux pour garantir la qualité des processus, il faut accepter la délégation de responsabilités. En revanche, avec une communication plus simple, plus directe, les effets néfastes de la bureaucratie des organisations s’éloignent et le lien social se renforce apportant moins de turn over et un partage des connaissances important. Avec à la clé, une gestion facilitée des départs dans les équipes. On en vient à dire ici que la qualité d’un projet serait assurée, non pas par des piles de gestion de projet en mode PMO mais par davantage d’indépendance. Nous aurons l’occasion d’en parler dans un prochain sujet.
Finalement, si le Big Bang permet de tout faire en une fois, "l’effet
tunnel" reste un risque fort. Dans le cadre d’une option de
changement par vague, on peut compter sur un flux plus continu
avec un meilleur contrôle assorti d’une capacité d’adaptation plus
forte. En tout état de cause, c’est en fonction de la structure de
votre entreprise, de vos projets et de la maturité de vos équipes
que vous pourrez étudier ces différentes solutions de déploiement.
Et pour encore mieux cerner tous les contours et les obstacles d’un
projet aussi déterminant, n’hésitez pas à solliciter les retours
d’expériences d’experts de l’ERP.°
Par J.Lascaux, Fondateur de FiveForty°
*Big Bang avec effet tunnel contre changement par étapes vers un ERP unique
.jpg?v=1htnite "Big Bang avec effet tunnel contre changement par étapes vers un ERP unique")
Partager cet article :
Paris - FRANCE / New York - USA
©2021 FiveForty°. Tous Droits Réservés.
Conception et réalisation :
