Défis associés à la sélection des logiciels d’entreprise
Cet article fait partie de notre collection « From the Trenches ». 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 Les défis de la sélection des logiciels d’entreprise.
Pour plus d’articles, consultez les livres blancs « From the Trenches ».
Les défis de la sélection des logiciels d’entreprise
Ça se passe tout le temps ici. Un client envoie une « demande de proposition » (RFP) au bureau avec des instructions pour compléter une réponse dans quelques jours ou une semaine et la renvoyer pour que notre système d’entreprise soit considéré comme étant en cours d’achat. Les appels d’offres se ressemblent à peu près tous. Il y a généralement une brève vue d’ensemble, des instructions sur ce que vous devez faire pour que votre réponse soit prise en compte, y compris la façon dont elle doit être mise en forme et quand la renvoyer, etc. Ensuite, il y a une longue grille de fonctionnalités qui sont requises et un certain nombre de questions supplémentaires pour écrire des réponses.
Le défi avec les demandes de propositions est qu’elles n’étaient pas idéales pour sélectionner des logiciels d’entreprise, et ce qui s’ensuit lorsqu’un processus d’appel d’offres est suivi ne garantit pas les meilleures décisions pour le organization. Les appels d’offres ont été conçus par la communauté d’achat comme un moyen d’obtenir le meilleur produit au meilleur prix et ils font encore un excellent travail de cela. Lorsque les offres sont comparables, le processus de décision peut se concentrer sur le meilleur prix avec seulement une ou deux variables supplémentaires (telles que les dates d’expédition) à gérer. Lorsque les solutions possibles sont dans la même catégorie générale, mais pas du tout comparables (comme c’est le cas avec les logiciels d’entreprise), le nombre de variables qui doivent être prises en compte par les acheteurs est énorme et le processus d’appel d’offres n’ajoute pas de valeur à la sélection. Comment la plupart des entreprises sélectionnent les logiciels d’entreprise Commençons par examiner le processus qui se produit en permanence dans n’importe quel fournisseur ou fournisseur de solutions de logiciels d’entreprise. Je vais parler des logiciels de gestion de projet d’entreprise ou des logiciels de feuille de temps d’entreprise, car c’est ce que mon entreprise fournit, mais le paradigme est le même pour pratiquement n’importe quelle sélection de système d’entreprise.
Comment la plupart des entreprises sélectionnent les logiciels d’entreprise
Commençons par examiner le processus qui se produit en permanence dans n’importe quel fournisseur ou fournisseur de solutions de logiciels d’entreprise. Je vais parler des logiciels de gestion de projet d’entreprise ou des logiciels de feuille de temps d’entreprise, car c’est ce que mon entreprise fournit, mais le paradigme est le même pour pratiquement n’importe quelle sélection de système d’entreprise.
Dans la plupart des organisations, l’impulsion à la recherche de logiciels d’entreprise vient d’un problème. Le personnel de terrain a peut-être mis en évidence le problème. Le problème est peut-être identifié par un membre de la haute direction. Quoi qu’il en soit, l’initiative doit obtenir l’appui d’un membre de la haute direction. La sélection locale d’un système qui affectera l’ensemble de l’entreprise est un fantasme, même dans les organisations les plus progressistes. C’est pourquoi un cadre supérieur décide : « Nous avons besoin de ce type de système d’entreprise ».
Le processus de sélection classique des logiciels d’entreprise se présente comme suit :
La direction dit que nous avons besoin d’un nouveau système d’entreprise
Le gestionnaire de projet est sélectionné
Solliciter des demandes de tous les services concernés
Fusionner toutes les demandes dans une grande feuille de calcul
Envoyer la grille des exigences à de nombreux fournisseurs
Obtenir un grand nombre de réponses
Liste courte
Regarder les démonstrations
Négocier
Obtenir l’acceptation de la gestion
Faire en sorte que la direction décide d’autre chose
Un responsable de projet pour l’effort de sélection est volontaire. Il ou elle fait ce que nous faisons tous : accéder à Internet, charger un moteur de recherche et taper « Logiciel EPM » (ou n’importe quel système d’entreprise souhaité). Immédiatement un demi-million d’accès sont retournés. Peut-être que le gestionnaire de projet diligente surfe sur la première douzaine ou plus pour découvrir le genre de systèmes disponibles avant de passer à autre chose. Il est clair que personne n’a le temps de surfer à travers un demi-million ou plus de hits pour voir si peut-être le tout dernier est le système idéal pour le organization.
Le chef de projet réunit désormais un comité de sélection parmi ceux qui seront concernés par la mise en œuvre de ce nouveau système d’entreprise. Certains membres du comité peuvent faire partie du personnel sur le terrain qui a d’abord identifié le besoin dans le organization. D’autres ne le peuvent pas. Il peut y avoir une combinaison de membres de ce comité de sélection qui ont des intérêts divers dans le type de système qui sera choisi.
Le chef de projet indécis sollicite désormais chaque membre du comité pour interroger son groupe représentatif pour connaître ce dont il a besoin dans le nouveau système d’entreprise. Comment chaque représentant du comité procède-t-il? Tout d’abord, tout le monde ne fait pas le même effort, mais pour ceux qui font leurs devoirs, ils demandent à leur personnel de soumettre une liste de caractéristiques qu’ils trouveraient importantes. Ensuite, ils, aussi, ont atteint l’Internet et surfent sur certains sites Web de fournisseurs. Ils peuvent copier et coller à partir des fonctionnalités qu’ils voient dans les brochures de ces sites, car chaque site leur donne de nouvelles idées sur les types de demandes qu’ils pourraient être en mesure de faire d’un nouveau système.
À présent, le comité est remonté et la longue feuille de calcul de chaque membre du comité est fusionnée avec les autres dans une feuille de calcul massive. La méga-feuille de calcul des exigences est catégorisée, mais il existe des défis. Tout d’abord, les divers besoins du comité deviennent de plus en plus évidents à mesure que les caractéristiques sont demandées sous un large éventail de perspectives. Il peut y avoir des membres du comité dans différents départements, mais aussi dans différents pays/régions ou même dans différentes divisions. Il y a presque toujours une requête qui est en conflit avec une autre requête dans la même liste (par exemple, le système doit être très facile et ne pas avoir beaucoup d’invites et le système doit être très flexible avec un grand nombre d’options pour chaque utilisateur).
Enfin, la feuille de calcul combinée que les fournisseurs verront est terminée. Il a des centaines de demandes de fonctionnalités et pour chacune d’elles, le fournisseur est censé dire « Oui », « Non » ou « Oui avec un certain effort ». Un système de pondération peut également être attaché pour indiquer si cette fonctionnalité est un « Must-have », un « Important-to-have » ou un « Nice-to-have ».
La demande de propositions est presque prête. Il y aura quelques questions de rédaction, généralement sur l’architecture technique de la sélection et, selon le nombre de personnes interrogées sur ces exigences, les demandes d’architecture peuvent être également conflictuelles (par exemple, le système doit avoir toutes les données stockées de manière centralisée dans la base de données SQL Server et le système doit autoriser le stockage local des données sur l’ordinateur de l’utilisateur).
En fait, ça sonne assez bien jusqu’à présent, n’est-ce pas ? Après tout, nous allons récupérer un ensemble de réponses des fournisseurs qui indiquent qui peut fournir toutes les fonctionnalités dont nous aurons besoin. En fait, ça sonne assez bien jusqu’à présent, n’est-ce pas ? Après tout, nous allons récupérer un ensemble de réponses des fournisseurs qui indiquent qui peut fournir toutes les fonctionnalités dont nous aurons besoin.
Mais il y a en fait un problème fondamental avec ce que j’ai décrit jusqu’à présent : un problème qui ne se produit pas lorsque nous utilisons le processus d’appel d’offres pour un produit plutôt qu’un système d’entreprise. C’est ceci : un système d’entreprise est une solution à quelque chose. Mais nous n’avons rien dit jusqu’à présent sur le problème. Il s’agit d’une situation tellement courante que l’industrie de la technologie en est venue à l’accepter comme normale et acceptable.
Pourquoi la sélection d’un logiciel d’entreprise de cette façon ne fonctionne pas
Les acheteurs utilisent cette méthode depuis des décennies et personne ne la remet en question, mais les gens dans le secteur des logiciels d’entreprise savent qu’il existe un problème fondamental avec la méthode classique de demande de propositions de sélection des logiciels d’entreprise.
Tout d’abord, simplement parce que vous avez une liste extrêmement longue de fonctionnalités, cela ne signifie pas nécessairement que vous êtes plus proche de la résolution d’un problème métier. En fait, si vous n’avez même pas articulé les problèmes d’entreprise spécifiques que vous essayez de résoudre, alors vous êtes susceptible de rendre les choses plus complexes et finalement pires, pas mieux. Le processus d’appel d’offres a été conçu pour acheter des produits de base. Lorsque nous avons des produits homogènes comme des chaussures, des pommes de terre ou du sucre, l’achat de ces articles de cette façon peut entraîner le prix le plus bas et la meilleure sélection parmi les fournisseurs possibles. Les réponses à une demande de propositions pour un produit similaire facilitent la comparaison des fournisseurs possibles. Lorsque les variables de chaque produit de la combinaison sont infinies (comme avec les logiciels d’entreprise), les réponses à l’appel d’offres ont également un nombre infini de variables et le processus produit des résultats qui ont peu de valeur.
Lorsque nous utilisons la méthode RFP pour sélectionner des systèmes d’entreprise, les demandes de propositions se ressemblent généralement toutes. Cela est dû au fait qu’ils sont tous créés en réponse au même stimulus. Le responsable de projet demande une liste de « ce dont vous aurez besoin dans ce système d’entreprise » et le seul vocabulaire que la plupart des responsables intermédiaires ont pour répondre à cette demande est une liste de fonctionnalités. Par conséquent, les réponses aux appels d’offres se ressemblent toutes. Il s’agit d’une liste de contrôle de toutes les fonctionnalités disponibles dans le cadre du système ou dans le cadre du système avec un certain effort.
Ce qui est le plus courant pour les équipes de sélection, c’est qu’elles recevront un certain nombre de réponses à leurs demandes de propositions, qu’elles parcourront les centaines de pages et, une fois qu’elles auront terminé, elles ne se sentiront pas plus proches d’une solution qu’au début. C’est terriblement frustrant pour les acheteurs qui ont fait d’énormes efforts pour créer ce qui devrait être une demande de proposition équitable et pour évaluer les réponses seulement pour constater que l’exercice était pour rien.
Pire que tout cela, les vendeurs expérimentés savent que le processus donnera des résultats frustrants et qu’ils sont au travail dès qu’ils entendent qu’une demande de propositions sera créée. Ils ne travaillent pas sur la réponse à la demande de propositions. Ce n’est pas pertinent. Au lieu de cela, ils travaillent à deux ou trois niveaux plus élevés dans la structure de gestion, à la recherche de l’impulsion initiale qui a lancé la demande de propositions. Ils cherchent le cadre supérieur qui a formulé un certain défi commercial et qui a mis les roues en marche afin que les acheteurs et les autres cadres intermédiaires créent la demande de propositions et l’envoient aux fournisseurs.
Lorsque les réponses à la demande de propositions se terminent sans réponse claire aux problèmes de l’entreprise qui ne sont presque jamais articulés dans le processus d’achat, le vendeur de l’entreprise est prêt à passer à l’action, en faisant en charge un cadre supérieur de contourner le processus et de sélectionner un système basé sur sa propre relation personnelle avec le vendeur principal de l’entreprise.
Si vous pensez que cela semble blasé, vous avez tort. En fait, vous pouvez faire un meilleur cas pour avoir un logiciel sélectionné par le biais de relations personnelles au niveau de la direction que pour l’achat par le biais du processus d’appel d’offres.
Mais qu’en est-il d’une preuve de concept ou d’un pilote ?
Ainsi, nous savons que le processus d’achat classique est défectueux lorsque nous l’appliquons à l’achat de logiciels d’entreprise. Si c’est le cas, comment choisir un logiciel d’entreprise tel qu’un système de gestion de projet d’entreprise ? Une méthode populaire consiste à utiliser la méthode preuve de concept ou phase pilote.
Ces deux termes étant souvent utilisés comme synonymes, commençons par parler de ce qu’est une preuve de concept ou un déploiement pilote.
Preuve de concept. Dans une preuve de concept, le organization potentiel déploie le logiciel d’entreprise de manière limitée afin de prouver qu’il peut accomplir un défi technique lorsqu’il y a une certaine question quant à la capacité de la solution à surmonter ce défi. Il peut s’agir, par exemple, du volume de données. « Nous craignons que le produit ne soit pas en mesure de gérer autant de tâches que nous avons par projet. Nous aimerions que vous veniez avec le logiciel, prendre deux ou trois exemples de projets avec 500 tâches chacun et nous montrer comment celles-ci peuvent être chargées dans le logiciel et que le logiciel peut toujours effectuer ses fonctions de base avec ce volume dans celui-ci.
Phase pilote. Une phase pilote est une installation du logiciel d’entreprise, mais avec une portée limitée. Un déploiement pilote peut être destiné à un sous-ensemble d’utilisateurs ; par exemple, seulement 10 personnes sur 1000 utiliseront le logiciel entièrement pendant une période de quatre semaines. Ou bien, il peut s’agir d’une sous-section de la fonctionnalité ou d’un sous-ensemble du volume de données ; par exemple, seuls 10 projets sur 500 seront chargés.
Comment la preuve de concept ou la phase pilote sont-elles utilisées ? Le problème que l’on rencontre souvent est la façon dont la phase pilote ou la preuve de concept est appliquée. Il est assez rare qu’un organization potentiel nous appelle et nous demande une proposition de preuve de concept et peut également identifier le concept technique à prouver. « Qu’espérez-vous prouver et comment serons-nous en mesure de mesurer que nous l’avons prouvé ? » nous demandons.
Ce qui est le plus courant, c’est qu’un membre de l’encadrement intermédiaire a identifié un logiciel d’entreprise qu’ils espèrent leur faciliter la vie dans leur organization. La haute direction n’est pas du tout impliquée, et le personnel de gestion intermédiaire n’a même pas expliqué les défis métier qu’ils essaient de surmonter. Ils espèrent que si la solution était juste dans le bâtiment, que la prochaine fois qu’une personne de la direction se promenerait dans le couloir, elle verrait « accidentellement » la solution en cours d’exploitation et donnerait instantanément sa bénédiction à un déploiement d’entreprise. Pour emprunter une phrase du film Field of Dreams, « Si nous le construisons, ils viendront. »
Il est rarement réussi. Le problème avec les logiciels d’entreprise est que nous avons besoin de la participation de la haute direction pour que le déploiement soit un succès. Ce sont les cadres supérieurs qui seront les « clients » des rapports et des analyses de ce système d’entreprise. Ce sont les cadres supérieurs qui devront investir personnellement pour permettre à un large éventail de membres du personnel de concevoir, de configurer et d’être formés au logiciel d’entreprise. Ce sont les cadres supérieurs qui devront accepter ou même aider à reconcevoir les processus métier qui font partie de tout déploiement de système d’entreprise. Sans la haute direction non seulement leur bénédiction, mais aussi leur soutien implicite et leur aide directe, aucune preuve de concept ne sera utile.
Cela vaut également pour une phase pilote. Si l’entreprise ne s’est pas engagée, à partir du plus haut niveau, à résoudre un problème commercial par l’utilisation de logiciels d’entreprise, l’introduction d’une phase pilote n’est pas productive.
Cela ne veut pas dire que les phases pilotes d’un déploiement n’ont pas de place. Ils comportent un emplacement critique dans un déploiement réussi. Ce lieu est immédiatement après la décision d’achat terminée et la conception du système d’entreprise a été conclue. Maintenant, une phase pilote constitue un excellent endroit pour tester la conception de notre système d’entreprise et l’affiner pour un déploiement général.
Lorsqu’une phase pilote est effectuée dans l’espoir que le logiciel en action aboutira à la sélection par la direction, nous disposons d’un projet pilote inefficace et nous n’aurons plus d’avance dans le processus de sélection.
Comment les organisations doivent-elles sélectionner les logiciels d’entreprise ?
Les systèmes d’entreprise sont achetés chaque jour par des organisations de taille moyenne à grande et, bien que la méthode RFP ne soit peut-être pas la plus efficace, il existe plusieurs méthodes de sélection de logiciels d’entreprise qui sont très efficaces. Voici quelques conseils pour créer votre propre processus de sélection d’entreprise efficace.
Articulez le problème. D’abord et avant tout, articuler le problème. Cela signifie que la haute direction doit être impliquée et que le problème à articuler est un problème métier. Une bonne question à se poser est la suivante : « Quelle décision d’entreprise ne pouvons-nous pas prendre maintenant ou ne pouvons-nous prendre qu’avec de grandes difficultés, dont la création pourrait être facilitée avec le déploiement de cette solution de système d’entreprise ? »
Il peut y avoir une série de défis métier que vous souhaitez résoudre avec l’utilisation de ce système d’entreprise.
Donnez aux fournisseurs une certaine latitude pour créer la solution. Une fois que le problème ou les problèmes ont été articulés, contactez les fournisseurs possibles et assurez-vous que l’accès à la haute direction qui a aidé au processus est transparent. Les réunions de fournisseurs « secrètes » avec la haute direction deviennent impossibles lorsque la gestion fait partie du processus dès le début. Laissez les fournisseurs comprendre le problème et donnez-leur une certaine latitude pour y répondre. Vous pouvez en savoir plus sur votre organization en expliquant comment ces défis métier vous affectent, et vous verrez certainement une gamme beaucoup plus large de solutions possibles à votre problème si vous n’essayez pas de décrire la solution aux fournisseurs potentiels.
Lorsque vous parlez à d’éventuels fournisseurs de solutions, assurez-vous qu’ils comprennent qu’ils doivent s’adresser à la fois à la technologie et au défi du processus métier. Il n’y a jamais eu de solution système d’entreprise qui n’a pas eu d’impact sur le processus de l’organization. Si le fournisseur de solutions ne peut pas vous aider sur la façon dont le processus sera affecté, vous n’examinez qu’une partie de la solution.
Allez rencontrer des gens. Lorsque vous obtenez un certain nombre de fournisseurs de solutions possibles, demandez à parler à certains de leurs clients existants. Mieux encore, vérifiez si le fournisseur vous permettra de visiter certains de ses clients existants. Les bons fournisseurs de solutions ont souvent des clients qui ont réussi dans leurs propres déploiements et qui sont assez généreux pour prendre le temps de rencontrer des clients potentiels.
Vous en apprendrez davantage en quelques heures avec un client expérimenté de la solution possible que vous n’auriez jamais appris en lisant les réponses à l’appel d’offres ou en examinant des démonstrations de ventes de fournisseurs. Lorsque vous demandez au fournisseur des références client et des visites de sites possibles, vous pensez peut-être que l’entreprise idéale à rencontrer serait exactement comme la vôtre. Ce n’est pas toujours le cas.
Il est souvent extrêmement précieux de rencontrer des entreprises dans d’autres secteurs qui sont liés ou quelque peu similaires aux vôtres. Vous pouvez également apprendre beaucoup d’organisations qui sont plus grandes ou plus petites que vous. Mettez davantage l’accent sur la quantité d’expérience que l’organization a eu avec la solution plutôt que sur la version qu’ils utilisent ou s’ils sont de la taille exacte ou dans le secteur exact dans lequel vous vous trouvez.
Si vous avez la chance de visiter un client existant, n’oubliez pas qu’il ne s’agit pas du fournisseur. Soyez respectueux, courtois et reconnaissant. Apporter un petit cadeau, peut-être du matériel promotionnel logo de l’entreprise est souvent bien apprécié. Pendant que vous êtes avec le organization ou lorsque vous parlez à des références sur le téléphone, voici quelques questions possibles :
Quel processus avez-vous utilisé pour sélectionner cette solution plutôt que d’autres ?
Quel impact cette solution a-t-elle eu sur vos processus métier ?
Quel était l’aspect le plus difficile du déploiement ?
Quel était le retour sur investissement le plus précieux jusqu’à présent?
Comment voyez-vous la solution évoluer à partir d’ici ?
Ne vous attendez pas seulement à des réponses heureuses.
Un fournisseur qui est complètement incapable de fournir des références doit être un peu plus suspect qu’un fournisseur qui a un certain nombre de clients satisfaits.
Enfin, lorsque vous avez effectué votre sélection, déployez en plusieurs phases. Vous trouverez d’autres articles dans cette colonne sur la façon de déployer en mode progressif ou big-bang. Cela permet d’atténuer les risques impliqués dans tout déploiement de système d’entreprise et d’affiner le processus de déploiement à mesure que le système évolue.
N’oubliez pas que tout déploiement de système d’entreprise est un processus dynamique. Ce n’est pas une décision unique avec des résultats heureux arrivant mois après mois pour toujours. Les déploiements d’entreprise les plus réussis commencent par une sélection qui implique le personnel clé qui fera partie du processus de déploiement de la direction la plus haute à la plus tactique sur le terrain et se poursuit tout au long de l’évolution du système, étape après étape.
Une sélection efficace du système d’entreprise n’est que la première phase du processus.
À 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 Informatique 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 dans 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).