Témoignage client - Processus précis d'évaluation et de sélection d'un outil ESM par le JPL de la NASA

[0:05] Lynn : Frank est un professionnel des technologies de l'information au Laboratoire de propulsion à réaction (JPL) de la NASA, où il s'occupe de la conception de processus métier, de la programmation web, de la conception et du développement de bases de données, de la programmation SQL, de l'ingénierie des systèmes, de la collecte des besoins et de projets informatiques. Sa carrière a débuté il y a environ trente ans en tant qu'opérateur de gros ordinateurs ; il a ensuite évolué vers le poste de chef de projet technique, où il a mis en place des bases de données de prêt entre bibliothèques. Quelques années plus tard, il a rejoint le JPL en tant que responsable des technologies de l'information. Avant de m'éloigner du sujet, je vais donc passer la parole à Frank. À vous.

[0:51] Frank : Eh bien, merci beaucoup et bienvenue à tous ceux qui sont ici pour ce webinaire. Je suis vraiment ravi de vous présenter ces informations. J’espère que vous les trouverez aussi intéressantes que moi. Allons-y et commençons tout de suite, d’accord ? Ma présentation consistera donc en un récapitulatif informel du processus que nous avons suivi pour rechercher, trouver et évaluer des produits d’utilisation. Je vais vous présenter les choses telles qu’elles se sont déroulées lorsque nous avons mené cette étude nous-mêmes. Jevais vous montrer comment j’ai mené l’étude d’évaluation, dans l’ordre où je l’ai fait, et je vais vous présenter certains des documents que j’ai créés dans le cadre de la rédaction du rapport final. Je tiens donc à vous signaler que le JPL a pour politique de ne pas recommander de produits spécifiques ; par conséquent, lorsque je présenterai des informations sur les fournisseurs que nous avons évalués, je n’utiliserai pas leurs noms. Passons doncparlons du programme du webinaire d’aujourd’hui. Je vais vous présenter les objectifs que nous avions lorsque nous avons lancé l’étude pour trouver un produit adapté à nos besoins ; je vais vous parler des fournisseurs que nous avons sélectionnés et vous faire part de ce que nous avons appris à leur sujet au cours de l’étude ; je vais vous expliquer comment nous avons procédé à la notation, c’est-à-dire comment nous avons évalué concrètement les fournisseurs sélectionnés ; jevais vous montrer comment nous avons présenté les résultats de nos notations, qui incluront les performances de chacun des fournisseurs. Je vais vous parler des résultats de l’étude, y compris de l’état d’avancement actuel du processus dans son ensemble, puis, à la fin, nous aurons un peu de temps pour répondre à quelques questions. Je tiens à vous signaler que les procédures de diffusion des informations du JPL sont strictes et que jedevrai limiter les questions à celles liées au webinaire que nous organisons en ce moment même. Ainsi, lorsque je parle des produits et des fournisseurs dans le cadre de cette étude que nous avons menée, lorsque je parle d’un fournisseur, je fais référence aux entreprises qui fournissent des solutions d’utilisation, et lorsque je parle d’un produit, je fais référence aux logiciels que nous gérons, entretenons et fournissons à nos clients, c’est-à-dire les produits que vous gérez, entretenez et fournissez à vos clients enen interne, nous utilisons ces termes de manière interchangeable ; je vais donc faire de mon mieux, tout au long de ce webinaire, de m’en tenir à ces termes précis, et si je fais une erreur, je me corrigerai.

[3:58] Bon, commençons par le cœur de la présentation : parlons des objectifs de l’étude. Notre premier objectif était d’augmenter la qualité… pardon, la quantité de nos données d’utilisation. En effet, nous avions constaté que, dans l’outil interne que nous avions créé pour gérer notre utilisation, bon nombre de nos produits généraient des données de journalisation. Nous utilisions ces données pour collecter les informations d’utilisation, les gérer, puis les présenter dans notrepour générer nos graphiques. Or, nous avons constaté que cette utilisation des données de journalisation posait de réels problèmes : les journaux présentaient parfois des anomalies lorsque les fournisseurs ne transféraient pas les données de leur mémoire tampon vers le journal. Nous devions alors revenir en arrière pour retraiter ces données, ce qui entraînait des problèmes dans nos rapports d’utilisation que nous devions corriger régulièrement. De ce fait, nos parties prenantes internes ont commencé à perdre confiance dans les données, car lorsque nousdevions revenir en arrière pour les retraiter, ils estimaient que la stabilité de notre système de collecte de données n’était pas aussi solide qu’elle aurait pu l’être. C’est donc également l’une des raisons pour lesquelles nous avons mené cette étude : déterminer comment améliorer cette qualité et renforcer cette confiance. Nous avons constaté que les données n’étaient pas aussi mauvaises que les parties prenantes le percevaient, mais cette perception était sans aucun doute un élément que nous devions également gérer.

[5:36] Dans le cadre de ce processus, nous avons compris que nous souhaitions améliorer la facilité d’utilisation de notre outil interne. Nous voulions en faire un outil reposant davantage sur une architecture orientée services, où les utilisateurs dépendraient moins de moi-même et de mes collègues développeurs pour programmer des rapports à partir des données d’utilisation issues du back-end, et où ils pourraient accéder à l’outil pour générer eux-mêmes davantage de ces rapports. Comme nous disposions déjà d’uninterne qui fonctionnait bien pour nous dans le cadre de cette étude, nous avons voulu nous assurer que c’était bien l’outil que nous souhaitions utiliser et conserver. Lorsque nous avions initialement développé notre outil interne, il n’existait pas sur le marché d’outil suffisant nous permettant d’obtenir les données d’utilisation souhaitées ; nous l’avons donc créé nous-mêmes. L’objectif principal de cette étude était alors de produire ce que nous appelons un rapport « développer ou acheter », c’est-à-dire une analyse visant à déterminer si notreet nos ressources internes constituaient une meilleure solution, ou si une solution préexistante et disponible sur le marché serait plus adaptée pour répondre aux besoins de notre étude et à nos besoins internes.

[7:15] Bon, nous allons donc vous présenter un bref aperçu de tout ce que nous avons fait pour mener cette étude. Nous avons donc commencé, dès le tout début, par évaluer nos besoins en matière de rapports d’utilisation. Nous avons ensuite défini et rassemblé nos exigences. Il est important de rappeler que nous n’avons pas défini ces exigences en nous basant sur notre outil interne actuel, car cela aurait simplement répondu à toutes ces exigences. Nous sommes plutôt partis de zéro, d’une page blanche, en nous demandant : « Si nous avions tout ce que nous voulions, à quoi cela ressemblerait-il ? Que recherchons-nous vraiment ? Quels sont les besoins non satisfaits par notre outil actuel et auxquels nous devons répondre pour nos besoins de reporting en interne ? » Je me suis alors mise à faire des recherches sur Internet et j’ai été surprise de constater qu’il existe aujourd’hui un nombre non négligeable de fournisseurs proposant des rapports d’utilisation. Nous avons donc identifié ces fournisseurs, consulté leurs sites web et lu l’ensemble de leur documentation en ligne, ce qui nous a permis de nous faire une bonne idée de ces entreprises rien qu’à partir de leur présence publique. À partir de là, nous en avons sélectionné quelques-uns qui nous semblaient être des candidats potentiels pour le type de rapports que nous souhaitions. Nous leur avons envoyé des demandes d’informations comprenant nos exigences. Ce qui était important à ce stade, c’est que lorsque nous avons enfin rencontré chacun des fournisseurs et discuté avec leurs équipes commerciales et techniques, nous leur avions déjà transmis nos exigences. Ces premières réunions se sont très bien déroulées, car nous étions vraiment concentrés sur nos questions spécifiques : nous avons pu aller droit au but en abordant des questions et des exigences précises. Ainsi, lors des présentations avec chaque fournisseur, nous leur avons demandé de répondre à l’ensemble des exigences et de nous expliquer comment chacun d’entre eux répondait – ou ne répondait pas – à ces .

[9 h 36] Pour les fournisseurs avec lesquels nous avons décidé de mener des versions pilotes de ces logiciels, notre objectif était non seulement de voir les démonstrations que nous proposaient les équipes commerciales et techniques, mais aussi de découvrir à quoi ressemblaient ces produits avec nos propres données. Cela m’a également permis de générer des rapports spécifiques dans chacun des produits. Ainsi, dans le cadre de ce processus global, nous avons pu évaluer chaque fournisseur à l’aide de nos propres données et leur attribuer nous-mêmes une note en fonction de nos exigences Enfin, la dernière étape de l’étude a consisté à transmettre à nos parties prenantes l’ensemble de ces évaluations, ainsi que les résultats finaux de notre étude « développer ou acheter ».

[10:39] Dans ce cadre, j’ai également mené à bien mon processus d’ingénierie des systèmes, ce qui a notamment consisté à produire des documents communs relatifs aux exigences d’ingénierie des systèmes, tels que les cahiers des charges, le document de contexte et les résultats des études. J’ai ensuite rassemblé tous ces éléments et je les ai remis sous la forme d’un rapport global à ma hiérarchie. Je tiens à souligner qu’il nous a paru extrêmement utile, lorsque nousrecueillir nos exigences, de discuter avec tous les membres de l’équipe. Nous avons ainsi échangé avec notre direction, avec les responsables de la gestion des licences (ceux qui gèrent les modifications des fichiers de licence et la fourniture de ces services), avec nos chefs de produit (les personnes qui assurent spécifiquement le support des produits individuels que nous fournissons à notre clientèle), puis avec nos chefs de discipline. Pour nous, la « discipline » désigne notre groupe de parties prenantes, à savoir les équipes de direction chargées de nos outils mécaniques, les ingénieurs mécaniciens et nos outils électriques destinés aux ingénieurs électriciens, ainsi que nos outils de systèmes logiciels. Nous avons donc rassemblé toutes leurs informations et vousvous constaterez alors, comme nous l’avons fait, que chacun recherchait un type d’information légèrement différent. Par exemple, les responsables cherchaient davantage d’informations sur l’utilisation au fil du temps : comment nos licences étaient-elles utilisées ? Avons-nous suffisamment de licences ? Les responsables du support produit s’intéressaient davantage au nombre de refus enregistrés, aux personnes concernées et aux causes de ces refus. C’est ce qui a défini nos exigences au sein de l’outil lui-même. Je vous recommande donc de recueillir vos exigences auprès de toutes les personnes concernées par ce que les rapports d’utilisation leur révéleront.

[12:56] Ainsi, après avoir recensé nos besoins, nous avons commencé à mener des projets pilotes. L’étude a révélé que, pour le produit que nous avions choisi, nous devions nous assurer qu’il prenait en charge un nombre important de produits, ce qui nous ramène au problème que nous rencontrions : notreoutil interne ne prenait pas en charge le logiciel de gestion des licences à partir des journaux. Nous souhaitions donc que le produit choisi puisse remplacer notre solution existante si nous décidions de prendre en charge davantage de produits. Nous avons également appris que, quel que soit le fournisseur retenu, nous devions nous assurer qu’il puisse importer les données de produits non, et l’importance de ce point réside dans le fait que nous voulons nous assurer que, pour tous les produits que nous fournissons à notre clientèle, nous disposons d’un moyen d’intégrer les données d’utilisation dans l’outil du fournisseur ; nous ne pouvions pas affirmer que, pour un produit spécifique que nous fournissions, il n’existait aucun moyen d’intégrer les données d’utilisation dans le produit du fournisseur, à moins que le produit que nous fournissions ne génère pas de journaux.

[14:32] Nous avons compris que nous avions besoin d’un grand nombre de rapports personnalisés, ce qui s’explique par le fait que nous avons de nombreuses parties prenantes qui analysent les données de multiples façons différentes ; nous devions donc nous assurer que l’outil était suffisamment robuste pour répondre à tous leurs besoins. Nous avons également constaté que nos parties prenantesne souhaitaient pas devoir se connecter à l’outil à chaque fois pour générer un rapport ; ils voulaient que ces données leur parviennent d’elles-mêmes. Nous avons donc voulu qu’ils puissent, dès le matin, recevoir par e-mail le rapport programmé, qu’il s’agisse d’un rapport quotidien ou, pour certains, hebdomadaire. C’était l’un de nos besoins essentiels.

[15:24] Nous voulions également nous assurer que les rapports générés par l’outil du fournisseur incluent nos informations relatives aux ressources humaines. Ce qui était important à cet égard, c’est que nous avons constaté que les rapports que nous souhaitions générer devaient permettre d’analyser les données sous l’angle, par exemple, des groupes au sein de nos ressources humaines et de la structure de nos services, ainsi que de la manière dont ils utilisent spécifiquement les outils. Or, les données d’utilisation, telles qu’elles sont fournies à l’état brut,ne contiennent pas ces informations. Nous devons donc nous assurer que l’outil du fournisseur intègre ces données afin que nous puissions ensuite produire des requêtes et des rapports d’un point de vue institutionnel.

[16 h 13] Nous voulons nous assurer que nous disposons d’un très bon système de reporting des refus, et ce reporting doit être ciblé. En effet, comme vous le savez, lorsque l’on examine les refus, selon le produit, la manière dont les refus sont enregistrés varie : parfois, un produit peut enregistrer des refus avant même de passer à la délivrance d’une licence. Nous voulons donc nous assurer que le reporting des refus au sein du produit du fournisseur puisse prendre en charge les différents types de refus qui se produisent. L’une de nos parties prenantes tenait particulièrement à obtenir des informations en temps réelen temps réel, c’est-à-dire ce qui se passe actuellement sur le système, qui est connecté à l’instant, puis de croiser ces informations avec celles des RH pour savoir à quel groupe ou service ces personnes appartiennent.

[17:18] Bon, à ce stade de l’étude, nous avons recensé nos besoins, nous avons discuté avec les fournisseurs, nous avons sélectionné ceux qui participeront aux projets pilotes, nous avons intégré nos propres données dans le système etce qui nous a permis de dégager une première série d’informations sur ce dont nous aurons besoin dans un outil de suivi de l’utilisation. Je voudrais donc vous parler très rapidement de certaines des choses que nous avons apprises sur les fournisseurs qui menaient les projets pilotes. Le fournisseur A disposait d’une interface très épurée et moderne ; je ne vais pas passer en revue chacun de ces points, mais ce qui est important, c’est qu’ils avaient une interface épurée et moderne. Ce produit ne nous a pas permis de mener un projet pilote sur site, mais ils disposaient d’uneconçue, qui contenait de nombreuses données à partir desquelles nous pouvions générer des rapports. Ce que nous avons retenu d’important concernant le fournisseur A, c’est le dernier point : la présentation des données se faisait du point de vue du serveur. Or, pour nos systèmes en triade, il n’était pas possible de générer un rapport à partir des trois triades simultanément ; il y avait donc une limite de ce point de vue. Ce fournisseur présentait également un problème concernant la capacité à filtrer ses refus.

[18:58] Et c’était donc problématique. Voici ce que nous avons appris sur notre fournisseur B et ce qui était important à son sujet : le produit du fournisseur B: son produit était très épuré, très propre ; il ne contenait pas beaucoup de JavaScript, les images qu’il produisait étaient très simples, mais il offrait tout ce dont nous avions besoin, tout y était. Par rapport au fournisseur A, il offrait la possibilité de filtrer les refus, ce qui nous permettait de limiter le volume des rapports. Cependant, ce qui était intéressant avec le fournisseur B, c’est que, justement parce qu’il était épuré, cela nous a amenés à nous demander s’il serait capable de répondre à l’exigence de l’étude, à savoir augmenter le volume de nos rapports.

[20:01] Voici ce que nous avons appris au sujet du fournisseur C : il disposait d’une interface utilisateur très bien conçue. Ce qui était vraiment important pour nous chez ce fournisseur, c’était le stockage local des données LDAP. L’intérêt de cette fonctionnalité résidait dans le fait qu’elle libérait ainsi une partie des ressources allouées à notre système LDAP institutionnel ; le fournisseurn’avait pas besoin d’interroger constamment notre système LDAP pour collecter des informations. De plus, le fournisseur stockait ces informations RH ainsi que leurs modifications au fil du temps ; ainsi, si le nombre de personnes au sein d’un groupe, par exemple, changeait, ces informations étaient mises à jour en conséquence. C’est donc important pour pouvoir observer l’évolution des tendances issues des informations relatives au groupe. Le fournisseur C prenait également en charge un grand nombre de serveurs de licences par rapport aux autres fournisseurs : il prenait en charge 25 fournisseurs de licences différents. De plus, le fournisseur C disposait d’une fonctionnalité que nous avions également dans notre: la création de « pseudo-fournisseurs ». Pour ceux d’entre vous qui s’occupent de la gestion des licences, vous savez que certains fournisseurs de produits vous envoient un fichier de licence regroupant plusieurs de leurs produits dans un seul fichier. Il est alors nécessaire de pouvoir extraire ces données et de présenter cette utilisation sous forme de produits distincts que vous fournissez à votre clientèle. Le fournisseur C offrait cette fonctionnalité, ce que nous avons particulièrement apprécié.

[21:46] Nous avons donc évalué nos fournisseurs, qui collectaient nos données, et lorsque nous avons estimé être en mesure de comparer de manière pertinente les capacités des fournisseurs avec nos besoins et nos exigences, nous avons procédé à une notation. Voicivoici comment cela s’est déroulé : tout d’abord, pour chacune des exigences, nous leur avons attribué un coefficient de pondération sur une échelle de 1 à 10. J’ai choisi d’utiliser une échelle de 2 à 10 plutôt qu’une échelle de 1 à 5, et j’ai pris cette décision personnellement car je voulais m’assurer que les exigences de niveau 8 et 10, lorsqu’elles étaient satisfaites, aient un poids plus important dans la notation pour ces éléments clés, et que les exigences de faible importance, les « 2 » et les « fquatre, s’ils n’étaient pas satisfaits, cela ferait baisser la note. Je pense que c’était mon premier objectif. Mon deuxième objectif était d’obtenir ainsi une note finale plus significative à la fin pour ma direction et mes parties prenantes. Pour chacune de ces exigences pondérées, nous avons évalué les fournisseurs, puis nous leur avons attribué une note pour chacune d’entre elles. Nous avons ensuite multiplié cette note par la pondération, ce qui a donné la note finale de chaque fournisseur pour chacune de ces exigences.

[23:41] Voici donc un exemple : ce que nous examinons ici est l’un des documents que j’ai produits dans le cadre de mon rapport global. Il s’agit de l’exigence n° 36. « TUR » signifie « Tool Utilization Reporting » (rapports d’utilisation des outils) et, dans cette exigence, nous parlons de la capacité du produit de ce fournisseur à générer un rapport personnalisé. Notre outil interne répondait à cette exigence, car, ayant conçu le système de A à-end et les tables de base de données, je savais comment écrire mes propres requêtes SQL pour mon système ; j’ai donc satisfait à cette exigence. Le fournisseur A a déclaré ne pas satisfaire à cette exigence, mais je lui ai en réalité attribué une note plus élevée, car lors de l’évaluation, j’ai constaté qu’il disposait d’une interface graphique web permettant de générer des requêtes SQL qui pouvaient ensuite être injectées dans le système ; je lui ai donc attribué une note plus élevée. J’ai procédé de la même manière pour le fournisseur B, en lui attribuant une note indiquant qu’il satisfaisait partiellement à l’exigence, car j’ai pu accéder à saet d’examiner le schéma de sa base de données. Je l’ai trouvé peu compliqué et j’ai estimé que nous serions capables de nous familiariser avec ces tables de base de données pour ensuite écrire nos propres requêtes SQL directement sur les données brutes. Le fournisseur C répondait également à cette exigence et disposait d’un système robuste de rapports pré-intégrés. Avec le recul, j’aurais probablement dû attribuer au fournisseur C une note indiquant qu’il dépassait cette exigence, mais il a finalement obtenu la note de 12. Ce n’est pas grave.

[25:44] Voici donc un exemple d’un autre rapport que j’ai généré ; il s’agit de ma représentation visuelle de la notation. Je l’ai fait afin que vous puissiez avoir un aperçu rapide et facile de la note attribuée à chacun des fournisseurs. Vous remarquerez que les notes sont exprimées en dixièmes ; notez également que je ne montre que le résumé et non l’exigence réelle – on n’écrirait pas une exigence dans ce genre de langage –, mais vous voyez que les fournisseurs A et B n’ont pas satisfait à certaines de ces exigences, et même si elles font partie de nos exigences « incontournables », les parties prenantes vont tout de même examiner cela et se demander s’il s’agit d’exigences dont elles pourront se passer si nous choisissons cet outil.

[26:36] Voici donc une échelle présentant les résultats pour l’ensemble de nos critères de pondération 10 ; ce sont nos critères incontournables, nous en avions 15, et j’ai le sentiment que parmi ces critères de pondération 10, il y en avait un certain nombre que tous les fournisseurs du secteur devraient être en mesure de satisfaire. Par exemple, l’un des critères stipulait la capacité à produire un rapport sur l’utilisation des heures supplémentaires, et du point de vue de la collecte des besoins,c’est une exigence importante à avoir ; mais cela signifie que tous les fournisseurs vont obtenir un score un peu élevé pour vos critères de pondération 10. Or, vous remarquez que le fournisseur A n’a pas obtenu un score aussi élevé que je l’aurais attendu pour ces critères de pondération 10. En y repensant, je pense que cela s’explique par le fait qu’il a présenté ses données du point de vue du serveur, ce qui ne nous a pasn’avons pas pu obtenir tous les autres rapports pour l’ensemble de nos systèmes Triad. À titre d’exemple, nous avons attribué un score très élevé à notre outil interne, et ce parce que nous l’avons développé nous-mêmes ; nous répondions donc évidemment à tous nos besoins importants, car nos exigences pondérées à 8 – celles qui revêtaient une grande importance, au nombre de 14 –il est intéressant de noter qu’à ce stade, le fournisseur A a pris un retard significatif dans sa capacité à répondre à ces exigences ; celles-ci allaient au-delà des fonctionnalités de base ; ce sont les exigences où nous commençons vraiment à améliorer la convivialité et à répondre aux besoins de notre établissement au-delà du strict minimum ; ce sont les exigences pour lesquelles nous commençons à voir dans quelle mesure elles répondent à nos besoins métier ; vous pouvez constater que, même dans ces domaines, notrene répondait pas à toutes ces exigences. Ce que cela représente figure précisément dans notre rapport « développer ou acheter » et, pour cette partie de l’étude, cela correspond au domaine dans lequel nous allons devoir investir dans notre propre outil afin de répondre à ces exigences. Ici, vous pouvez voir que le fournisseur C a obtenu d’excellents résultats et a même obtenu un score supérieur à celui de notre outil interne.

[29:15] Voici les résultats concernant les exigences de pondération 6 : dans ce domaine, le fournisseur B est également resté assez loin derrière, et notre outil interne n’a pas non plus obtenu de très bons résultats. Il y a ici un vaste domaine où nous devrions mettre en place une solution développée en interne, ce qui représentera une part importante de notre investissement interne. En ce qui concerne nos exigences de pondération 4, le fournisseur B est à nouveau à la traîne ; le fournisseur C a obtenu de meilleurs résultats que notre outil interne. Il y en a sept : ces exigences de pondération 4 sont des exigences assez importantes, et il n’y avait que deux exigences classées en pondération 2 ; je n’ai donc pas inclus ce graphique. Mais voici le score final : vous pouvez voir que le fournisseur C a obtenu ici un score supérieur à celui de notreoutil interne. Vous pouvez constater ici qu’aucun des fournisseurs ni notre outil interne n’a satisfait à l’ensemble de nos exigences ; il y a donc un domaine dans lequel nos parties prenantes devront évaluer quelles sont les exigences manquantes et déterminer l’impact de ces dernières sur nos processus internes. Ce que ce graphique des scores finaux vous montre, c’est qu’il va réellement falloir choisir entre notre outil interne et le fournisseur C.

[31:11] Voici donc une carte thermique de toutes les exigences ; elle vous offre un aperçu très rapide et facile à lire des performances de chacun des fournisseurs ainsi que de notre outil interne. Une chose que j’ai trouvée intéressante, c’est que j’avais créé la catégorie « dépasse les exigences » et que je n’n’en ai pas eu autant que prévu. Je m’attendais à ce qu’il y ait davantage de cas de « dépasse les exigences ». Bien sûr, le vert signifie « répond aux exigences », le jaune « répond en partie aux exigences » et le rouge « ne répond pas aux exigences ». Je pense que ce qui est important dans ce graphique, c’est aussi que vous pouvez constater qu’au niveau 4 des exigences, il y a ce grand bloc rouge tant chez le fournisseur B et le fournisseur C que dans notreinterne, où nous n’avons pas satisfait aux exigences requises. Le fournisseur A du secteur y a répondu en partie, mais c’est un domaine où nous devons revenir en arrière, examiner ces exigences et nous demander si ce sont vraiment des questions que nous devrions poser, car nous constatons que les outils du secteur n’y apportent pas de réponse.

[32:39] Bon, nous avons donc évalué les produits, nous leur avons attribué une note, et il est maintenant temps de passer à la dernière étape de l’étude « faire soi-même ou acheter » : comparer les résultats de cette notation au coût d’investissement. Voici le résultat : la courbe représentant l’achat est relative à elle-même ; jeje ne veux pas que vous puissiez déduire un coût quelconque à partir des notes ; le coût est donc masqué et exprimé en termes relatifs par rapport à l’échelle, mais il est représenté avec précision. En regardant ce graphique, vous pouvez vous faire une idée concrète de l’investissement que chaque outil allait nécessiter, et le coût de notrereprésente le coût de ce que nous prévoyions d’investir en interne pour répondre à leurs exigences. Je tiens également à vous préciser que ce coût n’inclut pas les frais de main-d’œuvre de maintenance, car nous considérions qu’il s’agissait d’un coût fixe et que celui-ci serait identique pour chacun des outils.

[34:13] Bon, pour résumer les conclusions de l’étude : nous avons déterminé que le fournisseur C, comme vous pouvez le voir sur le graphique précédent, offrait davantage de fonctionnalités par dollar investi dans ce domaine. En effet, nous avons constaté que le fournisseur C allait nous offrir un meilleur retour sur investissement que notre propre. Nous avons découvert que le fournisseur C disposait de capacités qui ne figuraient même pas dans notre cahier des charges initial. En fin de compte, nous n'avons pas pu justifier la différence de coût entre investir dans la refonte de notre outil interne et ce que nous obtiendrions en procédant à l'achat. Le choix entre « développer » et « acheter » s'est donc porté sur l'achat, et nous avons donc acquis le produit du fournisseur C.

[35:17] Alors, où en sommes-nous actuellement ? Nous venons de terminer la première phase de mise en œuvre du fournisseur, qui comprenait l’installation de toutes les licences prises en charge, c’est-à-dire les outils nativement pris en charge par le produit du fournisseur — ce qui, à notre grande surprise, représentait une part importante des outils que nous fournissons à notre clientèle. Actuellement, pendant que nous collectons nos données, nous utilisons en parallèle notre outil interne et celui du fournisseur C ; à terme, nous allons progressivement abandonner notreoutil interne tout en poursuivant la formation de nos collaborateurs internes à l’utilisation de l’outil, ainsi qu’à la recherche et à la compréhension des rapports. Nous sommes également en train de générer les rapports personnalisés dont nos collaborateurs auront besoin.

[36:29] Le processus que nous avons suivi ici n’est pas une invention de mon cru ; il s’agit d’une pratique standard en ingénierie des systèmes logiciels. Vous trouverez des références sur ce processus dans cet ouvrage ; il estest abordé en détail au chapitre 22. Je vous recommande donc de vous pencher sur le processus d’évaluation des fournisseurs en lien avec les exigences logicielles. Il m’a été extrêmement utile de m’appuyer sur une norme du secteur pour mener cette évaluation ; cela m’a donné davantage d’assurance dans la réalisation de cette tâche et m’a permis de savoir que le rapport que je rédigeais à l’intention de ma direction s’inscrivait dans le cadre des meilleures pratiques du secteur. Je tiens à remercier tout le monde d’être venu aujourd’hui et de m’avoir écouté. J’espère que vous avez trouvé cela intéressant et que cela vous a donné envie d’essayer ce type de processus vous-mêmes.