Y sommes-nous ?
Cet article fait partie de notre collection « From the Ttrenches ». Il décrit comment les implémentations de système d’entreprise doivent être en mesure de s’adapter et d’évoluer pour réussir.
Pour télécharger la version Word de cet article, consultez Y a-t-il encore ?.
Pour plus d’articles, consultez les livres blancs « From the Trenches ».
Y sommes-nous ?
Au fil des ans, l’un des plus grands pièges que j’ai vus dans la sélection et le déploiement de logiciels d’entreprise est la pensée de l’implémentation comme répondant à un objectif statique. Il est possible que ce soit juste un signe de notre temps que nous essayons de sonner tout dans notre monde. « Il gère nos projets » « C’est notre feuille de temps » ou « C’est notre système ERP » ou « Nous avons un système EPM » réduit notre besoin de penser en permanence à tous les aspects de notre entreprise qui peuvent être touchés par notre système d’entreprise. Pourtant, les organisations que j’ai rencontrées qui ont le plus réussi à déployer un projet d’entreprise ou un système de feuilles de temps d’entreprise les considèrent inévitablement comme un « système vivant » ; un système qui évolue continuellement par conception.
Pourquoi le considérer comme un système statique ?
S’il est vrai qu’il existe une meilleure chance de succès dans un système d’entreprise considéré comme un environnement dynamique, pourquoi tant d’organisations considèrent-elles leur système d’entreprise comme un logiciel fixe ?
Il y a de nombreuses raisons possibles.
Peut-être que l’acceptation du système d’entreprise reviendrait à présenter une analyse de rentabilité dans un environnement budgétaire complexe où il y aurait une chance et une chance d’obtenir un budget approuvé pour le système. Revenir chaque année ou chaque cycle budgétaire pour demander une autre phase, puis une autre, c’est politiquement impossible.
Ou, peut-être que vous avez hérité du système et que certaines promesses ont été faites sur ce qu’il devait fournir ou peut-être qu’il y a eu un certain temps et que tout le monde dans l’organisation pense que le système ne fournit qu’une liste définie de fonctionnalités métier.
Ou, peut-être qu’à l’intérieur de la politique sont à l’œuvre et qu’il y a des gens ailleurs dans l’organisation qui auraient peur d’un système sans frontières.
Qu’est-ce qui ne va pas dans cette pensée ?
Il est étrange que nous considérions même un système logiciel comme statique. Nous ne pensons généralement pas que le problème qu’il est de résoudre est statique. Les énoncés de problème que nous associons à l’implémentation d’un système d’entreprise évoluent presque toujours. Ils dépendent de l’évolution des conditions économiques, des conditions commerciales changeantes, des changements dans les activités des concurrents, des changements au niveau du personnel ou de l’architecture technologique. Une organisation qui pense que les conditions commerciales ne changeront jamais est peu susceptible de rester en activité longtemps. Si nous pensons aux logiciels d’entreprise, pensez à la vitesse à laquelle l’aspect technologique de la solution change. Dans notre activité de feuilles de temps TimeControl, nous avons subi 6 changements architecturaux majeurs en 20 ans. Nous avons commencé en 1994 avec une version DOS, puis en 1995 avec une version Windows, puis une version client/serveur en 1997, puis une version basée sur un navigateur en 1999, puis une version hébergée dans le cloud et une version mobile en 2010. C’est juste une architecture technologique. Une évolution supplémentaire s’est produite grâce à l’évolution des conditions économiques, des concurrents et simplement de l’expérience. Pour ceux d’entre nous dans le projet d’entreprise ou l’édition de logiciels de feuille de temps d’entreprise, nous acceptons que le changement est une constante.
Il ne s’agit pas d’une autre conception du déploiement d’un système d’entreprise. Dans le temps nécessaire à l’implémentation d’un système d’entreprise comme Project Server, l’organisation qui l’implémente est vouée à changer. Il y aura de nouveaux clients, de nouveaux membres du personnel et du personnel qui partiront. Dans le temps nécessaire au choix et au déploiement du système EPM, d’autres produits concurrents émergeront. Nous avons vu des organisations paralysées par ce phénomène. Par crainte qu’ils ne sélectionnent pas le produit parfait, la publication d’un autre produit par un autre fournisseur a pour résultat que le groupe de sélection suspend son travail pour prendre en compte le nouveau produit. Ou, la publication d’une nouvelle version de l’un des produits considérés a tout le monde craignant que leur évaluation ne prendra pas en compte toutes les alternatives. Ces groupes recommencent encore et encore. Une décision finale n’est jamais prise, car les exigences de l’organisation et les options de solution ne cessent de changer.
Le problème pour ces organisations est que le défi commercial qui les avait obligés à rechercher une solution en premier lieu ne disparaît pas, et en l’absence de décision, ils ne sont pas résolus.
Donc, si ce n’est pas statique, alors quoi ?
Les déploiements de systèmes d’entreprise auront de meilleures chances de succès s’ils sont des environnements vivants. Ils doivent croître, évoluer et s’adapter aux conditions changeantes qui les entourent. Et, oui, peut-être qu’à un moment donné, quand ils seront vieux, ils devront être mis à la retraite. Le changement le plus critique de cette façon de penser est que la solution parfaite n’est pas le point de départ. Les priorités deviennent le choix d’une solution qui répond aux besoins les plus critiques, mais qui a la capacité de s’adapter à des besoins plus complexes à l’avenir, même si ceux-ci n’ont pas encore été parfaitement articulés. L’un des critères de sélection les plus importants est la flexibilité plutôt que l’étendue des fonctionnalités.
Comment éviter l’accrocage statique ?
Il existe un certain nombre de choses que nous pouvons faire pour éviter d’être bloqué dans un paradigme de déploiement statique.
Effectuez des phases dans votre plan d’implémentation et n’expirez jamais de phases.
Si nous adoptons une approche progressive de l’implémentation de l’entreprise, nous pouvons nous concentrer sur une première phase beaucoup plus modeste. Notre personnel de conseil apprend à identifier non pas le plus que nous pourrions faire, mais le moins possible. Nous leur disons de « rechercher le déploiement le plus minimal, dont le déploiement produira un retour sur investissement positif continu ». La bonne nouvelle à ce sujet, c’est que la valeur du système commencera beaucoup, beaucoup plus rapidement et dans l’utilisation du système, même à un niveau plus minimal, les exigences pour une utilisation future deviendront plus claires.
Créez un budget qui permet l’évolution.
L’un des défis que nous avons rencontrés dans de nombreux déploiements est la « visite unique au puits » où une demande pour un système d’entreprise ne peut être faite qu’une seule fois. Faire un budget par phases à la place avec l’espoir que les deux premiers budgets de phase sont assez détaillés, mais les phases futures le sont moins, est inévitablement plus réussi.
Choisissez des solutions hautement flexibles.
Notre personnel a adopté la devise « Semper Gumby » (d’après le toy flexible M. Gumby). C’est un jeu de mots inventé pour la première fois dans l’armée américaine, mais il correspond parfaitement à notre pensée. Tout comme M. Gumby, nous ne savons jamais dans quelle forme nous serons tordus par la suite, donc nous pensons en termes de flexibilité. Quelle que soit la solution d’entreprise que vous choisissez, la flexibilité est un critère de réussite.
N’abandonnez pas toute votre équipe d’implémentation lorsque vous devenez opérationnel.
Conservez les ressources clés à l’avenir. Il s’agit d’un défi extrêmement courant. Souvent, dans un déploiement d’entreprise, l’organisation est attirée par l’affectation de ses ressources les plus expérimentées et les plus qualifiées, ce qui contribue certainement à la sélection et à l’implémentation du système. Toutefois, ces ressources sont celles qui seront nécessaires pour le prochain projet critique et elles sont susceptibles d’être extraites de celui-ci au moment où le système entre en service et est à son stade le plus critique. La planification à l’avance pour que certaines ressources clés restent avec l’implémentation pendant une période plus longue peut faire une énorme différence.
Faire une équipe permanente d’amélioration du système, peut-être petite, mais qualifiée.
L’équipe qui rassemble les exigences du système d’entreprise examine les processus métier, les fonctionnalités du système, l’intégration avec d’autres systèmes d’entreprise clés, etc. Le fait que ces personnes abandonnent le système une fois qu’il est installé rend l’évolution future très difficile. Placez ce système d’entreprise et peut-être d’autres systèmes connexes dans des soins évolutifs à long terme où les besoins de l’organisation et les capacités du système sont évalués régulièrement.
Apprendre de l’utilisation réelle
Mettre votre système en production tôt.
C’est tellement plus facile dans le monde d’aujourd’hui qu’il y a 5 ans. Vous pouvez tirer parti des installations cloud et des services accessibles à distance pour que votre système fonctionne rapidement. La plupart des systèmes d’entreprise qui ont à la fois des offres cloud et locales ont des méthodes d’évolution de l’un à l’autre. C’est certainement vrai avec Project Server. C’est vrai aussi pour nos systèmes.
Vérifiez qu’il existe une boucle de commentaires qui entraîne l’amélioration du système.
Il est bon de voir des choses qui peuvent être améliorées, pas mal. Certaines équipes d’implémentation découragent les suggestions d’amélioration, craignant qu’elles empêchent les utilisateurs d’utiliser le système qu’ils ont déjà déployé. Notre expérience est que ceux qui font des suggestions d’amélioration sont généralement les plus grands alliés du système d’entreprise. Même si une idée ne peut pas être implémentée immédiatement, elle doit être bienvenue. La création d’un système d’identification et d’encouragement de nouvelles idées pour le système d’entreprise permet à tout le monde d’investir et peut apporter d’énormes avantages.
N’abandonnez pas l’espoir trop vite.
Certaines entreprises diront « Le problème est dans le logiciel » et sauter le navire avant qu’il y ait une chance de succès.
Y sommes-nous ?
Quand y arriverons-nous ?
J’espère que jamais.
Cela ne veut pas dire que les stations de chemin le long du chemin ne seront pas de bons endroits pour s’arrêter. Votre première cible pour une nouvelle implémentation de logiciels d’entreprise, comme un projet d’entreprise ou un système de feuilles de temps d’entreprise, doit être un environnement de production offrant un retour sur investissement positif. Recherchez un système qui peut se déployer en couches ou en phases et avec suffisamment de flexibilité pour pouvoir croître, s’adapter et changer, et vous êtes susceptible de trouver plus de productivité en cours de route que vous pourriez trouver en attendant de choisir la destination idéale.
À propos de l’auteur
Chris Vandersluis est le président et fondateur de HMS Software, basé à Montréal, au Canada, un partenaire certifié Microsoft. Il a un diplôme en économie de l’Université McGill et plus de 30 ans d’expérience dans l’automatisation des systèmes de contrôle de projet. Il est un membre de longue date du Project Management Institute (PMI) et a participé à la création des sections de Montréal, Toronto et Québec du Microsoft Project Users Group (MPUG). Les publications pour lesquelles Chris a écrit incluent Fortune, Heavy Construction News, le magazine Computing Canada et PMNetwork de PMI, et il est un chroniqueur régulier pour Project Times. Il enseigne la gestion avancée de projets à l’Université McGill et intervient souvent à des fonctions d’association de gestion de projets dans Amérique du Nord et partout dans le monde. HMS Software est l’éditeur du système de gestion du temps timecontrol orienté projet et est partenaire de solution Microsoft Project depuis 1995.
Chris Vandersluis peut être contacté par e-mail à l’adresse : chris.vandersluis@hms.ca
Si vous souhaitez lire d’autres articles relatifs à L’EPM de Chris Vandersluis, consultez le site d’aide sur l’EPM de HMS (https://www.epmguidance.com/?page_id=39).