Acheter des solutions

Cet article fait partie de notre collection « From the Trenches ». Il décrit comment les acheteurs potentiels de logiciels peuvent rendre les interactions avec les éditeurs de logiciels plus efficaces en appliquant des méthodes d’analyse métier faciles à comprendre. Il décrit un exercice qui peut aider à créer des critères d’évaluation de logiciel en déterminant efficacement les problèmes qui doivent être résolus par la solution logicielle.

Pour plus d’articles, consultez les livres blancs « From the Trenches ».

Être un acheteur de solutions

Trop souvent, un achat de logiciel est basé sur une liste de fonctionnalités, une campagne publicitaire ou la recommandation d’un ami. Cet article décrit comment les acheteurs potentiels de logiciels peuvent rendre les interactions avec les fournisseurs de logiciels plus efficaces en appliquant des méthodes d’analyse métier faciles à comprendre.

C’est sûr que ce n’était pas comme avant. Le fait que les logiciels fonctionnent dans un environnement d’entreprise n’est même plus appelé installation. De nos jours, les termes implémentation ou déploiement décrivent mieux ce qui est nécessaire pour obtenir un nouveau package opérationnel.

De plus en plus d’éditeurs de logiciels parlent de ce qu’ils vendent en tant que solutions, et ce n’est pas étonnant. Lorsque nous envisageons de déployer un système d’entreprise comme Microsoft Project Server ou Microsoft CRM, nous devons d’abord réfléchir aux différentes couches de technologie qui seront impliquées et, avant même d’en arriver là, nous devons réfléchir à l’impact sur l’ensemble de notre activité.

Avec des solutions à vendre vient, bien sûr, des ventes de solutions. Si vous avez suivi cela, vous savez que presque toutes les organisations de haute technologie sur la planète qui ciblent des organisations de moyenne à grande taille travaillent à se recréer en tant que livreur de ventes de solutions. Microsoft fait certainement partie de ces organisations. Microsoft a beaucoup travaillé au cours des dernières années pour établir des solutions de vente en tant que principe directeur dans ses forces de vente et d’implémentation sur le terrain.

Qu’est-ce qu’un vendeur de solutions ? C’est vrai qu’ils sont toujours vendeurs. Toutefois, les vendeurs de solutions visent non seulement à déplacer une boîte de logiciels, mais aussi à créer quelque chose qui aide le client à améliorer sa situation.

Sonne très bien jusqu’à présent; un Nirvana de vendeurs qui cherchent tous à améliorer votre sort dans la vie. Mais cela s’accompagne d’un défi, et la résolution de ce défi est quelque chose à laquelle vous, le client potentiel, pouvez participer.

Se concentrer sur le problème

Le défi auquel la plupart des vendeurs de solutions sont confrontés lorsqu’ils arrivent sur le marché est notre préconception sur ce à quoi une solution doit ressembler. Nous sommes tellement habitués à nous concentrer sur les fonctions et les fonctionnalités des logiciels, quand nous parlons à un vendeur de logiciels, la conversation mène presque inévitablement directement à: « Votre logiciel peut-il faire cela? Votre logiciel peut-il le faire ? Les vendeurs de logiciels expérimentés , et ce sont les types qui sont déplacés vers des positions de vente de solutions, sont tellement habitués à vendre des fonctions et des fonctionnalités qu’ils oublient souvent de se poser la question la plus élémentaire de toutes : « Quel est le problème ? »

Maintenant, cela peut sembler idiot, mais si vous pensez à vos dernières conversations avec des vendeurs de logiciels, vous pourriez être surpris de voir à quel point cette question se pose rarement. Des fournisseurs comme Microsoft et ses partenaires reçoivent de nombreuses demandes de propositions chaque année. J’en ai vu des centaines au fil des ans, et une chose qui est presque toujours présente est une longue grille de fonctions que le fournisseur est censé remplir. Cette grande feuille de calcul est souvent au cœur de la réponse au client.

Ce qui est rarement présent, c’est une description des besoins métier qui seront traités par chacune de ces fonctions. Il est si facile d’être pris par une fonctionnalité que nous connaissons d’un produit précédent ou que nous avons vu promu quelque part qu’il faut une vraie discipline pour nous concentrer sur ce qui nous a intéressés à ce nouveau produit en premier lieu. Cela peut être particulièrement le cas dans un environnement d’entreprise où il y a beaucoup d’informations sur le type de solution recherché. Il est beaucoup plus facile d’envoyer une demande demandant aux utilisateurs de répertorier toutes les fonctions qu’ils souhaitent dans un nouveau système logiciel que de parler de leurs besoins professionnels particuliers.

Si vous commencez à penser que vous avez peut-être manqué quelque chose d’évident, vous n’êtes pas seul. Cette condition est tellement répandue dans l’industrie du logiciel à l’heure actuelle qu’une nouvelle catégorie de consultant appelé Analyste d’entreprise a vu le jour. Ces personnes sont formées pour établir la connexion entre les besoins de l’entreprise et les fonctionnalités logicielles. Prenons quelques minutes pour voir comment vous pouvez appliquer les concepts de base ( de la façon dont un analyste d’entreprise les appliquerait ) dans vos évaluations de logiciels au niveau de l’entreprise.

Identification des besoins de l’entreprise

La première chose à penser est ce que les besoins de l’entreprise vous ont amené à rechercher un nouveau système logiciel en premier lieu. Notre propre organisation consulte souvent les entreprises sur l’implémentation de logiciels de gestion de projets d’entreprise. Quand j’arrive dans une organisation en tant que consultant, bien avant de parler de l’achat de logiciels, je demande comment l’organisation fait de la gestion de projet en ce moment.

Quand ils terminent leur réponse, je pose toujours cette question de suivi : « Cette méthode fonctionne-t-elle pour vous ? » Étonnamment, le client répond souvent que c’est le cas. Pour moi, la conversation sur l’implémentation doit s’arrêter là. « S’il n’y a pas de problème, explique-t-je, il n’y a aucun moyen pour moi de trouver une solution ! » Souvent, cette réponse amène les gens à faire une pause. « Pourquoi avons-nous été appelés ? » Je vais demander. Les réponses peuvent varier considérablement, et il n’est pas rare que les gens regardent autour de la pièce se rendant compte qu’il y a plusieurs agendas en cours qui doivent être rapprochés – et notre conversation date de moins de cinq minutes!

Donc, demander « Quel est le besoin de notre entreprise ? » est un excellent point de départ. Il y a presque toujours un objectif global qui répond à cette question, un objectif qui a lancé l’initiative en premier lieu.

Réalisation d’un exercice de vision

Ensuite, vous devrez examiner un peu plus en détail ce que cela signifie en termes de fonctionnalités logicielles. Lorsque nous implémentons un logiciel de gestion de projet d’entreprise comme Microsoft Project Server dans une organisation, nous commençons toujours par un exercice de vision qui implique le personnel clé (ceux qui évaluent le logiciel) et la direction ( ceux qui parrainent l’exercice). Il ne suffit pas de faire cet exercice avec du personnel technique, car l’objectif de cet exercice est de connecter les objectifs métier aux fonctions techniques.

Voici un moyen efficace de le faire : placez le personnel clé dans une pièce avec un grand tableau blanc. Diviser le tableau blanc en 4 colonnes : commencez par un titre dans la colonne située à l’extrême droite uniquement. Appelez-le « Décision d’entreprise ».

Dans la colonne de droite, vous allez répertorier les décisions professionnelles que vous souhaitez prendre à l’aide du nouveau système que vous envisagez. Lorsque nous faisons cela avec un client, la première chose que les gens veulent faire est de répertorier un grand nombre de fonctionnalités. Vous devez donc insister pour que les réponses qui sont importantes soient les décisions de l’entreprise. Par exemple, un participant peut dire immédiatement : « J’ai besoin d’une liste de toutes les ressources et de leur charge de travail ». C’est peut-être vrai, bien sûr, mais ce que vous devez savoir, c’est quelle décision commerciale ils prendront avec cette liste.

Voici quelques exemples de décisions d’entreprise :

• Embauche ou licenciement dans un service particulier

• Prendre une décision d’aller ou de non-aller sur un projet

Une fois que vous avez une liste correcte de décisions commerciales, faites une pause. Le moment est venu de passer en revue la liste des décisions d’entreprise et d’identifier les décisions prioritaires. Vous voudrez peut-être vous poser cette question : Si vous ne pouviez obtenir des réponses que pour l’une de ces décisions d’entreprise, qui apporterait le plus de valeur à l’organisation? À ce stade du processus, il est toujours plus facile de choisir les trois principales décisions.

Si vous avez atteint ce niveau, vous avez déjà accompli plus que la plupart des organisations qui recherchent des logiciels de gestion de projet d’entreprise. Être en mesure de fournir une liste hiérarchisée des décisions commerciales les plus importantes aux fournisseurs de systèmes est un grand pas en avant pour l’ensemble du processus. Lorsque vous pouvez indiquer aux fournisseurs système les décisions métier que vous devez prendre, ils sont autorisés à aller au-delà de parler de fonctionnalités simples pour parler de la façon de rendre l’organisation plus efficace.

Ensuite, examinez chaque décision et demandez : « Pour prendre cette décision commerciale, quel rapport auriez-vous besoin ? » Pratiquement toutes les décisions sont prises après avoir examiné un ou plusieurs rapports. Étiquetez la 3e colonne « Rapport ». Pour chacune des trois premières décisions, répertoriez dans cette colonne les rapports requis pour la décision correspondante.

Par exemple, nous pourrions dire que pour déterminer s’il faut embaucher ou incendier du personnel pour un service particulier, nous avons besoin d’un rapport par ministère montrant les données de planification de la capacité des ressources. Cela inclut une prévision anticipée de la charge de travail attendue, de la disponibilité des ressources attendue et de la planification. Si vous êtes une entreprise de taille moyenne, le flux de trésorerie peut également être un problème. Vous pouvez, par exemple, avoir besoin de personnel supplémentaire, mais ne pas être en mesure de trouver l’argent pour les embaucher. Le rapport sur les flux de trésorerie inclurait les revenus estimés et les sorties d’argent avec un solde courant.

Si nous remplissons la colonne Rapport pour chacune des décisions que nous avons identifiées comme prioritaires, la forme de ce dont nous aurons besoin commence déjà à devenir claire. Une fois que vous avez terminé, vous avez une liste de sorties physiques dont vous avez besoin à partir de votre système potentiel.

Faites une pause ici pour savoir s’il existe déjà des rapports du type que vous avez identifié déjà en cours d’utilisation dans l’organisation. Il est probable que de tels rapports existent, mais dans de nombreux formats et éventuellement avec des données incomplètes ou avec un effort excessif requis pour les générer. Si vous trouvez des formats de rapports qui ont fonctionné dans l’organisation, vous pouvez les ajouter à votre liste de configuration système requise. Vous pouvez maintenant fournir encore plus d’informations aux fournisseurs du système.

Une fois les rapports clés identifiés, nous pouvons passer aux éléments d’un système requis pour générer ces rapports. Ajoutez le titre « Analyse » à la 2e colonne du graphique. Pour chaque rapport, identifiez les analyses ou algorithmes requis pour générer le rapport. Par exemple, pour un rapport de planification de la capacité des ressources, nous pouvons avoir besoin d’une planification de chemin critique à partir du système de gestion de projet et d’une analyse de nivellement des ressources.

Ces analyses sont souvent commercialisées par les fournisseurs sur la base de la myriade de fonctionnalités que chacune inclut. (Oui, la vente de caractéristiques par caractéristiques est toujours vivante et bien!) Ce que vous devez déterminer, c’est la fonctionnalité minimale qui fournira les rapports dont vous avez besoin, avec lesquelles vous pouvez ensuite prendre ou améliorer la décision métier que vous avez identifiée. Vous serez peut-être surpris de voir à quel point les fonctionnalités dont vous avez besoin sont basiques pour répondre à vos besoins métier réels. Pour certains rapports, aucune analyse ou calcul ne sera nécessaire; Les rapports ne doivent être que des agrégats simples qui peuvent être générés directement à partir des données du nouveau système.

Enfin, nous arrivons à la première colonne de notre graphique. Une fois que vous avez identifié les analyses requises, vous pouvez passer à la détermination des éléments de données requis pour alimenter les analyses.

Ajoutez le titre « Input » à la 1ère colonne de votre graphique.

Dans l’exemple que nous avons utilisé, nous pouvons avoir besoin d’une liste complète des tâches pour chaque projet impliqué dans le travail du service. Il peut s’agir de tous les projets de l’organisation. Nous avons également besoin d’un profil complet de la disponibilité de chaque ressource, ainsi que de la charge de travail définie sur chaque tâche, de sorte que lorsque la tâche se déplace dans l’analyse de planification, la charge de travail se déplace dans l’analyse de nivellement des ressources. Rappelez-vous aussi comment nous avons commencé avec la décision d’embaucher ou de licencier dans un service particulier? Nous devons également être en mesure d’identifier les ressources par service.

Nous pouvons passer ainsi des sorties à droite aux entrées de gauche jusqu’à ce que nous ayons identifié tout ce dont nous aurons besoin dans notre nouveau système d’entreprise.

Évaluation des risques

Une fois cet exercice terminé, il est utile de revenir à chacune des entrées et de déterminer la disponibilité de ces éléments de données. Vous constaterez peut-être, comme nous le faisons souvent, que certains de ces éléments n’existent même pas. Par exemple, certaines organisations ne tiennent pas à jour une liste complète de la disponibilité des ressources. Vous pouvez également constater que tous les projets n’ont pas une planification chargée des ressources indiquant la charge de ressources générée par ce projet. Dans de nombreuses organisations, certains types de projets ne sont placés dans aucun système. Les travaux d’urgence, de support technique ou de maintenance régulière sont quelques exemples courants.

Si vous n’avez pas accès aux données fondamentales dont vous aurez besoin pour fournir la valeur métier, vous devez considérer cet élément du système comme présentant un risque élevé. Par exemple, si nous constatons que nous pouvons identifier les planifications chargées en ressources pour 80 % des projets de l’organisation, pouvons-nous raisonnablement nous attendre à améliorer notre décision commerciale d’augmenter ou de réduire le personnel ? La réponse est probablement « Non ». Pourquoi? Parce que les 20 p. 100 des projets qui ne sont pas dans le système pourraient représenter 80 p. 100 de la charge de travail d’un ministère en particulier. Si vous n’avez pas toutes les données, vous ne saurez jamais si le rapport final est exact.

Il existe des moyens de contourner ce genre de problèmes, bien sûr. Une méthode consiste à isoler tous les processus métier des aspects de l’organisation pour lesquels vous ne pouvez pas accéder aux éléments de données. Les ressources d’une division dont les projets ne se trouveraient peut-être pas dans le système n’auraient pas non plus été répertoriées. Cela ne peut pas être fait simplement dans tous les cas; vous devrez examiner élément par élément pour déterminer le risque que ces processus métier et décisions métier représentent pour votre implémentation. Il n’est pas rare à ce stade du processus de re-hiérarchiser les décisions métier finales que vous souhaitez améliorer. Vous pouvez avoir une décision qui est très souhaitable, mais qui s’avère très risquée et qui ne vaut donc pas la peine de poursuivre dans les premières phases de votre déploiement.

Documentation de ce que vous avez fait

Lorsque vous organisez ce type de réunion, affectez un scribe, c’est-à-dire une personne dont la tâche consistera à enregistrer des notes et des commentaires tout au long du processus. Les raisons pour lesquelles une décision d’entreprise particulière a été classée comme une priorité élevée ou faible ou pourquoi quelque chose était considéré comme à risque élevé seront rapidement oubliées si vous n’avez pas de bonnes notes à renvoyer.

Il est très important d’enregistrer :

• Ce que vous avez écrit sur le tableau blanc

• Qui a participé au processus

• Qui est propriétaire de chaque décision d’entreprise finale

Si vous vous sentez submergé à ce stade, ne craignez pas. L’ensemble de cet exercice peut être réalisé très rapidement, même dans les plus grandes organisations. Il n’est pas rare de pouvoir terminer l’ensemble du processus en un jour ou peut-être deux. La clé de la réussite est d’obtenir le bon niveau de gestion dans la salle. De plus, ce type de réunion est mieux facilité par une personne de l’extérieur de l’organisation qui n’est pas prédisposée à faire les choses comme elles l’ont toujours été.

La connaissance, c’est la puissance

Si vous envisagez des systèmes de gestion de projet d’entreprise( en fait, des systèmes d’entreprise de tout type), la réalisation de cet exercice vous donne une énorme quantité de puissance lorsque vous interagissez avec les fournisseurs de systèmes logiciels. Vous pouvez immédiatement faire la distinction entre les éléments d’un système qui sont importants pour vous et ceux qui ne le sont pas. Les fournisseurs de logiciels peuvent obtenir la liste des rapports et des décisions que vous souhaitez prendre.

Vous serez peut-être surpris par certaines des réponses qui vous sont envoyées par les fournisseurs. Libérés pour répondre d’une manière autre que sur une base de fonctionnalité par caractéristique , c’est-à-dire en essayant d’adapter une fonction carrée à une exigence ronde, les meilleurs fournisseurs seront en mesure de vous montrer comment vous pouvez répondre à vos défis métier en utilisant leurs systèmes au meilleur de leur avantage.

Voici le plus grand avantage de cet exercice : vous avez créé des critères d’évaluation prêts à l’action. Maintenant, pendant la phase de preuve de concept, vous pouvez vous concentrer immédiatement sur la question de savoir si le système fournit les informations dont vous avez besoin pour améliorer les décisions commerciales que vous devez prendre.

À 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).