Défis associés à une sélection de logiciels d’entreprise : livre blanc

Ce livre blanc fait partie de notre collection « Depuis les tranchées ». Décrit comment des implémentations de système d’entreprise doivent pouvoir s’adapter et évoluer pour réussir.

Pour télécharger la version Word de ce livre blanc, voir Défis associés à une sélection de logiciels d’entreprise.

Pour consulter d’autres livres blancs, voir les livres blancs « Depuis les tranchées ».

Défis associés à une sélection de logiciels d’entreprise

Cela se produit ici tout le temps. Un client envoie un appel d’offres au bureau, avec des instructions pour la préparation d’une réponse à renvoyer dans quelques jours ou semaines afin de lui permettre d’envisager l’achat de notre système d’entreprise. Tous les appels d’offres se ressemblent. Ils comprennent généralement un bref aperçu, des instructions sur ce qu’il faut faire pour que la réponse soit prise en considération, y compris concernant la mise en forme, la date de renvoi, etc. Vient ensuite une longue grille de fonctionnalités requises et un certain nombre de questions à développement auxquelles il faut répondre.

Le problème avec les appels d’offres est qu’ils ne sont pas parfaitement adaptés pour la sélection de logiciels d’entreprise, de sorte que le respect de la procédure d’appel d’offres ne garantit nullement que l’organisation prendra la meilleure décision. Les appels d’offres sont conçus par l’entité acheteuse afin d’obtenir le meilleur produit au meilleur prix, et ils y parviennent toujours avec brio. 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 (par exemple, les dates de livraison) à prendre en compte. Lorsque les solutions possibles s’inscrivent dans la même catégorie générale mais ne sont pas du tout comparables (comme c’est le cas des logiciels d’entreprise), le nombre de variables que les acheteurs doivent prendre en considération est énorme, et le processus d’appel d’offres n’ajoute pas de valeur à la sélection. Comment la plupart des sociétés sélectionnent un logiciel d’entreprise Commençons par examiner le processus qui a systématiquement lieu chez un vendeur ou un fournisseur de solutions de logiciels d’entreprise. J’évoquerai des logiciels de gestion de projet ou de feuille de temps pour entreprise, car il s’agit de produits que ma société fournit. Toutefois, le paradigme est identique pour pratiquement toute sélection de système d’entreprise.

Comment la plupart des sociétés sélectionnent un logiciel d’entreprise

Commençons par examiner le processus qui a systématiquement lieu chez un vendeur ou un fournisseur de solutions de logiciels d’entreprise. J’évoquerai des logiciels de gestion de projet ou de feuille de temps pour entreprise, car il s’agit de produits que ma société fournit. Toutefois, le paradigme est identique pour pratiquement toute sélection de système d’entreprise.

Dans la plupart des organisations, la décision de rechercher un logiciel d’entreprise est déclenchée par la nécessité de résoudre un problème donné. Le problème peut être signalé par le personnel de terrain. Ou il peut être identifié par un cadre supérieur. Quoi qu’il en soit, l’initiative doit bénéficier du soutien d’un membre de l’encadrement supérieur. Une sélection collective d’un système affectant toute l’entreprise relève de la plus haute fantaisie, même dans les organisations les plus progressistes. C’est donc un cadre supérieur qui décide du type de système d’entreprise nécessaire.

Le processus classique de sélection d’un logiciel d’entreprise se déroule comme suit :

  1. Annonce par la direction de la nécessité d’acquérir un nouveau système d’entreprise

  2. Sélection d’un responsable de projet

  3. Sollicitation de tous les départements concernés pour qu’ils formulent leurs demandes

  4. Fusion de toutes les demandes dans une grande feuille de calcul

  5. Envoi de la grille d’exigences à de nombreux fournisseurs

  6. Réception de nombreuses réponses

  7. Liste restreinte des candidats possibles

  8. Visionnage de démonstrations

  9. Négociation

  10. Obtention de l’acceptation de la direction

  11. Demande à la direction de décider éventuellement d’autre chose

Un responsable de projet pour l’effort de sélection se propose spontanément. Comme nous le faisons tous, il accède à Internet, ouvre un moteur de recherche, puis tape « logiciel EPM » (ou n’importe quel système d’entreprise souhaité). Il obtient instantanément un demi-million de résultats. Un responsable de projet diligent surfera peut-être sur la première dizaine de résultats pour en savoir plus sur les types de systèmes disponibles avant de continuer. Il est bien évident que personne n’a le temps de consulter un demi-million de résultats pour voir si le tout dernier ne serait pas éventuellement le système idéal pour l’organisation.

Intrépide, le responsable de projet constitue un comité de sélection composé de personnes qui seront concernées par l’implémentation de ce nouveau système d’entreprise. Certains membres du comité peuvent être issus du personnel de terrain à l’origine de l’identification du besoin au sein de l’organisation. D’autres non. Ce comité de sélection peut comprendre des personnes dont les intérêts divergent quant au type de système à sélectionner.

L’infortuné responsable de projet demande à présent à chaque membre du comité d’interroger son groupe représentatif sur ses besoins concernant le nouveau système d’entreprise. Comment les membres du comité procèdent-ils pour ce faire ? Bien sûr, ils ne consacrent pas tous les mêmes efforts à cette tâche. Toutefois, les plus consciencieux demandent à leur personnel de dresser une liste des fonctionnalités qui leur semblent importantes. Puis ils vont à leur tour visiter sur Internet quelques sites web de fournisseurs. Ils peuvent copier et coller des fonctionnalités qu’ils voient dans les brochures de ces sites, chacun de ces derniers proposant de nouvelles idées quant aux types de demandes qu’ils pourraient formuler concernant un nouveau système.

Le comité est à présent réuni, et les longues feuilles de calcul de ses membres sont fusionnées en une énorme feuille de calcul. La méga-feuille de calcul des exigences est organisée, mais il reste quelques défis. Tout d’abord, la diversité des besoins du comité est désormais plus apparente, car les fonctionnalités demandées sont inspirées par un vaste éventail de perspectives. Les membres du comité peuvent provenir de différents départements, mais aussi de différents pays, voire de différentes divisions. Une même liste contient presque toujours une demande en conflit avec une autre (par exemple, le système doit être très facile d’utilisation et n’afficher qu’un minimum d’invites, ET le système doit être très souple et offrir un grand nombre d’options pour chaque utilisateur).

Finalement, la feuille de calcul combinée qui sera remise aux vendeurs est achevée. Elle contient des centaines de demandes de fonctionnalités et, pour chacune d’elle, le vendeur est supposé répondre par « Oui », « Non » ou « Oui, mais avec un effort ». Un système de pondération peut également être associé, indiquant si telle ou telle fonctionnalité est « Indispensable », « Importante » ou « Intéressante ».

Extrait de code de la feuille de calcul de sélection de fonctionnalité

L’appel d’offres est presque prêt pour publication. Il contiendra quelques questions à développement, généralement sur l’architecture technique de la sélection et, selon le nombre de personnes interrogées sur leurs besoins, les demandes concernant l’architecture pourront également être conflictuelles (par exemple, toutes les données du système doivent être stockées de façon centralisée dans la base de données SQL Server, ET le système doit permettre un stockage local des données sur les ordinateurs des utilisateurs).

En réalité, jusque là, tout cela semble se présenter assez bien, n’est-ce pas ? Après tout, nous allons récupérer un grand nombre de réponses des vendeurs, qui nous permettront de voir qui peut fournir toutes les fonctionnalités dont nous avons besoin. En réalité, jusque là, tout cela semble se présenter assez bien, n’est-ce pas ? Après tout, nous allons récupérer un grand nombre de réponses des vendeurs, qui nous permettront de voir qui peut fournir toutes les fonctionnalités dont nous avons besoin.

Mais, en réalité, ce que j’ai décrit pose un problème crucial qui ne se produit pas lorsque nous utilisons le processus d’appel d’offres pour un produit plutôt que pour un système d’entreprise. Ce problème est le suivant : Un système d’entreprise est une solution à quelque chose. Mais nous n’avons encore rien dit du problème. Cette situation est si fréquente que le secteur des technologies a fini par la considérer comme normale et acceptable.

Pourquoi sélectionner un logiciel d’entreprise de cette manière ne fonctionne pas

Les acheteurs utilisent cette méthode depuis des décennies et personne ne la remet en question. Pourtant, les personnes qui travaillent dans le secteur des logiciels d’entreprise savent que le recours à la méthode d’appel d’offres classique pour sélectionner des logiciels d’entreprise pose un problème fondamental.

Tout d’abord, le fait de disposer d’une liste interminable de fonctionnalités ne signifie pas nécessairement que la résolution d’un problème d’entreprise soit proche. En fait, si vous n’avez pas même formulé les problèmes d’entreprise spécifiques que vous essayez de résoudre, il est probable que vous rendiez les choses plus complexes et, en définitive pires. Le processus d’appel d’offres a été conçu pour acheter des produits. Quand il s’agit de produits homogènes tels que des chaussures, des pommes ou du sucre, leur achat de cette manière peut aboutir à l’obtention de l’offre économiquement la plus avantageuse et au meilleur choix parmi les fournisseurs possibles. Les réponses à un appel d’offres pour un produit similaire facilitent considérablement la comparaison entre les fournisseurs possibles. Quand les variables relatives à chaque composant de l’ensemble sont en nombre infini (comme c’est le cas pour les logiciels d’entreprise), les réponses à l’appel d’offres comprennent également un nombre infini de variables, et le processus produit des résultats de peu de valeur.

Quand nous utilisons la méthode d’appel d’offres pour la sélection de systèmes d’entreprise, tous les appels d’offres se ressemblent. Cela résulte du fait que tous les appels d’offres sont créés en réponse au même stimulus. Le responsable de projet demande une liste des besoins que ce système d’entreprise doit satisfaire, et le seul vocabulaire dont disposent la majorité des cadres moyens pour répondre à cette demande est celui figurant dans une liste de fonctionnalités. Par conséquent, les réponses aux appels d’offres se ressemblent. Elles constituent une liste de contrôle de toutes les fonctionnalités qui seront disponibles dans le système, avec ou sans effort supplémentaire.

La situation la plus courante pour les équipes de sélection est qu’elles reçoivent un certain nombre de réponses à leurs appels d’offres, qu’elles dépouillent péniblement des centaines de pages et que, quand elles en ont terminé, elles n’ont pas le sentiment d’être plus près d’une solution que quand elles ont commencé. Cela est terriblement frustrant pour les acheteurs qui ont consenti d’énormes efforts pour créer ce qui devrait être un appel d’offres important et évaluer les réponses pour aboutir finalement à la conclusion que l’exercice était vain.

Le pire dans tout cela est que les commerciaux d’entreprise chevronnés, bien que sachant d’avance que le processus produira des résultats frustrants, se mettent au travail dès l’instant où ils apprennent qu’un appel d’offres va être lancé. Ils ne travaillent pas sur la réponse à l’appel d’offres. C’est inapproprié. Au lieu de cela, ils travaillent deux ou trois niveaux plus haut dans la structure de direction, en recherchant l’impulsion à l’origine du lancement de l’appel d’offres. Ils recherchent le cadre supérieur qui a évoqué certains problèmes d’entreprise et mis en mouvement l’engrenage pour que des acheteurs et d’autres effectifs de gestion de niveau moyen finissent par créer l’appel d’offres et l’envoyer à des vendeurs.

Lorsque les réponses à l’appel d’offres se terminent sans réponse claire aux problèmes d’entreprise qui n’ont pratiquement jamais été formulés dans le cadre du processus d’achat, le commercial d’entreprise est prêt à passer à l’action, en amenant un cadre supérieur à court-circuiter l’ensemble du processus, et à sélectionner un système basé sur sa relation personnelle avec le commercial supérieur.

Si vous trouvez cela cynique, vous avez tort. En fait, vous pouvez être plus performant en obtenant la sélection d’un logiciel par le biais de relations personnelles au niveau de l’encadrement supérieur, plutôt qu’un achat via le processus d’appel d’offres.

Mais qu’advient-il de la preuve de concept ou du projet pilote ?

Nous savons que le processus d’achat classique est faussé quand nous l’appliquons à l’acquisition d’un logiciel d’entreprise. Dans ce cas, comment choisir un logiciel d’entreprise tel qu’un système de gestion de projet d’entreprise ? Une solution populaire consiste à utiliser la méthode de la preuve de concept ou de la phase pilote.

Ces deux expressions étant souvent utilisées comme synonymes, commençons par expliquer ce que sont une preuve de concept ou un déploiement pilote.

Preuve de concept   . Dans le cadre d’une preuve de concept, l’organisation potentielle déploie le logiciel d’entreprise de façon limitée afin de prouver qu’il peut accomplir une opération technique donnée, s’il existe un doute quant à la capacité de la solution à l’exécuter. Il peut s’agir, par exemple, du volume de données. « Nous craignons que le produit ne puisse pas traiter la quantité de tâches que nous avons par projet. Nous aimerions que vous veniez avec le logiciel, preniez deux ou trois exemples de projet contenant quelque 500 tâches chacun, et nous montriez qu’il est possible de les charger dans le logiciel sans que cela altère l’exécution des fonctions de base de ce dernier. »

Phase pilote   . Dans le cadre d’une phase pilote, le logiciel d’entreprise est installé, mais son étendue est limitée. Par exemple, un déploiement pilote peut être effectué pour un sous-ensemble de 10 utilisateurs sur 1000, qui utiliseront pleinement le logiciel pendant une période de quatre semaines. Il peut également s’agir d’une sous-section des fonctionnalités ou d’un sous-ensemble du volume de données, par exemple, avec le chargement de 10 projets sur 500.

Utilisation de la preuve de concept et de la phase pilote    Un problème souvent rencontré est celui de déterminer comment appliquer la phase pilote ou la preuve de concept. Il est très rare qu’une organisation potentielle nous appelle pour nous demander une proposition de preuve de concept, et puisse en outre identifier le concept technique à prouver. Nous lui demandons alors ce qu’elle compte prouver et comment elle envisage d’évaluer la preuve que nous apporterions.

La situation la plus fréquente se produit quand un cadre intermédiaire identifie un élément du logiciel d’entreprise dont il espère qu’il pourrait lui faciliter la vie au sein de l’organisation. Les cadres supérieurs ne sont pas du tout impliqués, et les cadres intermédiaires n’ont même pas indiqué les difficultés d’entreprise qu’ils tentent de surmonter. Leur espoir est que, si la solution était disponible dans le bâtiment, la prochaine fois qu’un cadre supérieur passerait par là, il verrait « accidentellement » la solution fonctionner et donnerait instantanément sa bénédiction à un déploiement en entreprise. Pour paraphraser le thème du film Jusqu’au bout du rêve, cela reviendrait à dire : « Si nous le construisons, ils viendront ».

Sélection inefficace de phase du pilote

Cela marche rarement. Le problème avec les logiciels d’entreprise est que leur déploiement ne peut réussir sans l’implication de l’encadrement supérieur. C’est l’encadrement supérieur qui sera le « client » des rapports et analyses produits par ce système d’entreprise. C’est aussi l’encadrement supérieur qui devra investir pour octroyer à une partie du personnel le temps requis pour concevoir, configurer et apprendre le logiciel d’entreprise. C’est encore l’encadrement supérieur qui devra accepter, voire aider à reconcevoir les processus d’entreprise qui font partie de tout déploiement de système d’entreprise. Sans, non seulement la bénédiction, mais aussi le soutien implicite et l’assistance directe de l’encadrement supérieur, une preuve de concept n’aboutira à rien.

C’est également vrai d’une phase pilote. Si l’organisation ne s’est pas engagée, au plus haut niveau, dans la résolution de certains problèmes à l’aide d’un logiciel d’entreprise, l’introduction d’une phase pilote ne sera pas productive.

Sélection de phase pilote efficace

Cela ne veut pas dire qu’il n’y a pas de place pour une phase pilote dans un déploiement. Une phase pilote constitue un point critique dans un déploiement réussi. Elle doit intervenir juste après la décision d’achat et la fin de la conception du système d’entreprise. La phase pilote permet de tester la conception du système d’entreprise et de l’ajuster minutieusement avant son déploiement général.

Si une phase pilote est organisée dans l’espoir que la simple vue du logiciel en action incitera l’encadrement à sélectionner la solution, le projet pilote sera inefficace et ne mènera pas plus loin dans le processus de sélection.

Comment les organisations devraient-elles sélectionner un logiciel d’entreprise ?

Des organisations de taille moyenne à grande acquièrent quotidiennement des systèmes d’entreprise. Si la méthode de l’appel d’offres n’est probablement pas la plus efficace, il existe en revanche d’autres méthodes de sélection très efficaces. Voici quelques conseils pour créer votre propre processus de sélection d’entreprise efficace.

  • Formulez le problème   . Avant tout, formulez le problème. Cela signifie que l’encadrement supérieur doit être impliqué et qu’il est question d’un problème d’entreprise qui doit donc être formulé en termes d’entreprise. Une bonne question à poser est : « Quelle décision d’entreprise sommes-nous actuellement incapables de prendre ou ne pouvons-nous prendre qu’avec une grande difficulté, et que le déploiement de cette solution de système d’entreprise pourrait nous aider à prendre plus facilement? »

    Il peut y avoir toute une série de problèmes que vous souhaitez résoudre à l’aide de ce système d’entreprise.

  • Laissez aux vendeurs une certaine latitude pour créer la solution   . Une fois le ou les problème(s) d’entreprise formulé(s), contactez des vendeurs possibles et assurez-vous que l’accès à l’encadrement supérieur qui a contribué au processus est transparent. Les rencontres « secrètes » entre le vendeur et l’encadrement supérieur deviennent impossibles quand l’encadrement participe au processus dès le début. Laissez le vendeur comprendre le problème et y répondre en disposant d’une certaine latitude. Il se peut que vous en appreniez plus que vous ne le pensez sur votre organisation en expliquant comment ce problème d’entreprise vous affecte, et vous entreverrez certainement un éventail beaucoup plus large de solutions possibles au problème si vous ne tentez pas de décrire la solution au vendeur potentiel.

    Lorsque vous parlez à un fournisseur potentiel de solution, assurez-vous qu’il comprend la nécessité d’aborder le problème tant sur le plan de la technologie que du processus d’entreprise. Il n’existe pas de solution de système d’entreprise n’ayant aucune incidence sur le processus de l’organisation. Si le fournisseur ne peut pas dire en quoi la solution affectera le processus, cela signifie que vous n’envisagez qu’une partie de la solution.

  • Rencontrez quelques personnes   . Après avoir retenu quelques fournisseurs potentiels de solution, demandez à pouvoir vous entretenir avec certains de leurs clients. Mieux encore, voyez si le vendeur est disposé à vous laisser rendre visite à certains de ses clients. Les bons fournisseurs de solutions ont souvent des clients qui ont connu un déploiement réussi, et qui sont suffisamment généreux pour consacrer un peu de temps à des clients potentiels.

    Vous en apprendrez plus sur la solution possible en discutant pendant quelques heures avec un client expérimenté que vous n’auriez pu en apprendre en lisant des réponses à un appel d’offres ou en assistant à des démonstrations commerciales. Lorsque vous sollicitez d’un vendeur des références de clients ou des visites de sites, vous pourriez penser qu’une rencontre idéale serait celle d’une société rigoureusement identique à la vôtre. Ce n’est pas toujours le cas.

Il est souvent extrêmement précieux de rencontrer des sociétés actives dans d’autres secteurs apparentés ou similaires au vôtre. Vous pourriez également tirer de nombreux enseignements d’organisations d’une taille différente de la vôtre. Mettez davantage l’accent sur l’ampleur de l’expérience que l’organisation a acquise avec la solution, plutôt que sur sa taille, son secteur d’activité ou la version de la solution utilisée.

Si vous avez la chance de pouvoir rendre visite à un client existant, n’oubliez pas qu’il n’est pas le vendeur. Montrez-vous respectueux, courtois et reconnaissant. Un petit cadeau, tel du matériel promotionnel avec le logo de votre société, est souvent très apprécié. Lorsque vous rendez visite à une organisation ou discutez au téléphone avec un client de référence, voici quelques questions que vous pourriez poser :

  1. Quel processus avez-vous utilisé pour sélectionner cette solution plutôt que d’autres ?

  2. Quelle incidence cette solution a-t-elle eu sur vos processus d’entreprise ?

  3. Quel a été l’aspect le plus difficile du déploiement ?

  4. Quel a été le retour sur investissement le plus précieux à ce jour ?

  5. Comment voyez-vous la solution évoluer à l’avenir ?

Ne vous attendez pas à recevoir uniquement des réponses positives.

Un vendeur totalement incapable de fournir des références est relativement suspect par rapport à un vendeur disposant d’un certain nombre de clients satisfaits.

Enfin, une fois la sélection faite, procédez au déploiement de façon progressive. Vous trouverez dans cette rubrique d’autres articles sur la manière de procéder à un déploiement progressif plutôt qu’en une seule fois. Cela permet d’atténuer les risques liés à tout déploiement de système d’entreprise et de régler minutieusement 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. Il ne s’agit pas d’une décision ponctuelle produisant des résultats heureux, mois après mois, indéfiniment. La plupart des déploiements d’entreprise réussis commencent par une sélection impliquant le personnel clé qui participera au processus de déploiement, du cadre du plus haut niveau à l’agent de terrain le plus stratégique, et se poursuivent au travers de l’évolution du système de phase en phase.

La sélection d’un système d’entreprise efficace ne constitue que la première phase du processus.

À propos de l’auteur

Chris Vandersluis est le président et le fondateur de HMS Software. Basée à Montréal (Canada), l’entreprise est un partenaire Microsoft Certified Partner. Diplômé en sciences économiques de l’université McGill, Chris a plus de 30 ans d’expérience dans l’automatisation des systèmes de gestion de projets. Il est membre du Project Management Institute (PMI) depuis de nombreuses années et a participé à la création des chapitres du Microsoft Project Users Group (MPUG) pour Montréal, Toronto et Québec. Il a publié des articles dans Fortune, Heavy Construction News, Computing Canada et PMNetwork. Il tient également une chronique régulière pour Project Times. Il enseigne la gestion de projets avancée à l’université McGill et intervient souvent lors d’événements organisés par des associations de gestion de projets en Amérique du Nord et dans le monde entier. HMS Software est l’éditeur du système d’horloge pour les projets TimeControl et est un partenaire Microsoft Project Solution Partner depuis 1995.

Vous pouvez contacter Chris Vandersluis à cette adresse : chris.vandersluis@hms.ca.

Pour consulter d’autres articles en lien avec la gestion des projets d’entreprise rédigés par Chris Vandersluis, rendez-vous sur le site EPM Guidance de HMS Software (http://www.epmguidance.com/?page_id=39).

Développez vos compétences
Découvrez des formations
Accédez aux nouvelles fonctionnalités en avant-première
Rejoignez le programme Office Insider

Ces informations vous ont-elles été utiles ?

Nous vous remercions pour vos commentaires.

Merci pour vos commentaires. Il serait vraisemblablement utile pour vous de contacter l’un de nos agents du support Office.

×