Pourquoi les contrats de logiciels de sécurité sont bloqués au niveau des achats (et comment éviter cela)  

Si vous vous êtes déjà demandé pourquoi l'achat d'un logiciel de sécurité qui semble évident traîne pendant des mois ou échoue discrètement au stade de l'approvisionnement, vous n'êtes pas le seul. 

Dans les environnements d'entreprise, les outils de sécurité échouent rarement parce qu'ils sont inefficaces. Ils échouent parce que le processus d'achat est conçu pour ralentir les décisions, répartir les risques et protéger l'organisation contre les mauvais résultats. Cette réalité entre en conflit avec la manière dont la plupart des équipes de sécurité élaborent leurs analyses de rentabilité. 

Le résultat est familier. Des discussions budgétaires ont lieu. Les démonstrations se passent bien. Les dirigeants approuvent. Puis l'accord disparaît dans les méandres des achats pendant six à neuf mois. 

Cet article analyse les raisons pour lesquelles les contrats de logiciels de sécurité échouent, les objections qui surgissent tardivement dans le processus et la manière d'élaborer un dossier commercial qui résiste à l'examen minutieux des services d'achat au lieu d'y périr. 

Pourquoi les contrats de logiciels de sécurité prennent-ils autant de temps ? 

La plupart des acheteurs de solutions de sécurité sous-estiment le nombre de décideurs qui interviennent entre le moment où l'intérêt est manifesté et celui où l'approbation est donnée. L'approvisionnement n'est pas une étape unique. Il s'agit d'un parcours semé d'embûches destiné à réduire les risques organisationnels, et non à accélérer l'innovation. 

Le trou noir des achats 

L'un des premiers retards survient juste après l'alignement budgétaire, lorsque le service des achats demande plusieurs devis concurrentiels. Sur le papier, cela ressemble à une diligence raisonnable. Dans la pratique, cela ajoute souvent 60 à 90 jours au processus. 

Cela s'explique par le fait que les fournisseurs s'accordent rarement clairement sur la portée, les fonctionnalités ou les modèles de mise en œuvre. Les équipes internes doivent alors normaliser des comparaisons entre des éléments disparates. Chaque devis supplémentaire introduit de nouvelles parties prenantes et de nouvelles objections. 

Pendant ce temps, l'élan s'essouffle et les priorités changent. 

Les parties prenantes cachées qui font échouer les transactions 

Les directeurs de la sécurité sont rarement ceux qui bloquent un achat. Les transactions sont bloquées parce que d'autres services évaluent la décision sous des angles très différents. 

Les équipes financières et les directeurs financiers se concentrent sur le retour sur investissement, la prévisibilité et la maîtrise des coûts à long terme.
Les équipes informatiques s'inquiètent de la complexité de l'intégration, des frais généraux opérationnels et de la charge que représente l'assistance.
Les équipes juridiques examinent minutieusement la propriété des données, la responsabilité, les accords de niveau de service et les clauses de résiliation.
Les équipes chargées des achats gèrent les risques liés aux fournisseurs, la structure des contrats et les risques de non-conformité. 

Si votre analyse de rentabilité ne met en avant que de meilleurs résultats en matière de sécurité, elle ne survivra pas intacte à cet examen. 

Une analyse réaliste du cycle d'achat des entreprises 

Les homologations des logiciels de sécurité se déroulent généralement comme suit : 

• Recherche initiale : 4 à 6 semaines 

• Recherche d'un consensus interne : 6 à 8 semaines 

• Évaluation formelle et démonstrations : 4 à 6 semaines 

• Négociations relatives à l'approvisionnement : 8 à 12 semaines 

• Examen juridique : 2 à 4 semaines 

• Planification de la mise en œuvre : 2 à 3 semaines 

Lorsque les acheteurs tentent de raccourcir ce délai sans préparer les parties prenantes à l'avance, l'approvisionnement devient le goulot d'étranglement qui absorbe toutes les frictions. 

Quelles objections en matière d'approvisionnement font échouer les contrats de logiciels de sécurité dans les dernières étapes ? 

La plupart des objections tardives n'ont rien à voir avec le prix, même si elles semblent l'être. 

Ils concernent la peur. La peur de nuire à la réputation. La peur d'un échec dans la mise en œuvre. La peur du contrôle des dirigeants. 

Objection 1 : « Nous devons connaître le prix exact par écrit avant de présenter cela. » 

Ce que cela signifie réellement, c'est que quelqu'un craint d'avoir un choc en voyant le prix ou de paraître mal préparé devant ses supérieurs. 

Pour neutraliser cette objection, il faut orienter la conversation vers la réduction des coûts et l'atténuation des risques plutôt que vers les dépenses. 

Au lieu de vous appuyer sur des chiffres, fondez votre argumentation sur le coût du statu quo. Cela inclut le coût continu des processus manuels, les heures supplémentaires, les heures consacrées à la réponse aux incidents, les consultants externes et les revenus menacés en raison du départ des clients ou de la perte de confiance. Les risques réglementaires et les conséquences des violations font également partie de cette discussion. 

Lorsque l'investissement est présenté comme un moyen d'éviter des pertes continues, son prix devient contextuel plutôt qu'alarmant. 

Objection 2 : « Votre solution est plus chère que celle du concurrent X. » 

Cela signifie généralement que le service des achats a effectué une comparaison superficielle. 

La solution consiste à mettre en place un cadre de coût total de possession qui va au-delà de la première année. 

Cela comprend les services de mise en œuvre et d'intégration que les fournisseurs ont tendance à minimiser, les coûts de formation et de gestion du changement, les frais d'intégration d'outils supposés moins chers, les frais de mise à niveau, les limitations des fonctionnalités et les différences réelles en termes de qualité du support et de temps de réponse. 

Lorsque les acheteurs présentent aux dirigeants le coût total du cycle de vie, les outils moins chers perdent souvent leur avantage perçu. 

Objection 3 : « Nous ne sommes pas sûrs que cela fonctionnera pour notre opération spécifique. » 

Cette objection est motivée par la crainte d'être responsable d'un lancement raté. La solution consiste à rendre la réduction des risques explicite et visible. 

Les propositions internes solides comprennent souvent des mises en œuvre par étapes, des programmes pilotes définis avec des indicateurs de réussite, des points de contrôle clairs et des clauses de sortie transparentes. Parler ouvertement des scénarios d'échec n'affaiblit pas le dossier. Cela renforce la confiance. 

Objection 4 : « Ce n'est pas le bon moment. Nous devons attendre. » 

Cela indique généralement une fatigue décisionnelle ou des priorités concurrentes. 

Pour y remédier, les acheteurs doivent quantifier le coût de l'attente. Cela implique de calculer les inefficacités mensuelles, les risques croissants en matière de sécurité, les désavantages concurrentiels et le temps d'apprentissage perdu. 

Proposer des alternatives aide. Commencer modestement dès maintenant est souvent beaucoup moins risqué qu'un déploiement à grande échelle perturbateur plus tard. 

Comment élaborer un dossier commercial convaincant pour justifier l'achat d'un logiciel de sécurité d'entreprise 

Le service des achats n'approuve pas les outils. Il approuve les décisions qui semblent justifiables. 

Votre objectif n'est pas de convaincre tout le monde que le logiciel est impressionnant. Votre objectif est d'aider chaque partie prenante à expliquer pourquoi l'approuver ne leur portera pas préjudice. 

Constituez votre coalition interne dès le début 

Les champions de la sécurité qui réussissent recrutent des alliés avant même que le processus d'approbation officiel ne commence. 

• Un sponsor exécutifse soucie de l'avantage stratégique et du risque d'entreprise. Il est recruté grâce à la veille concurrentielle et aux récits d'impact sur les clients. 

• Un allié financierse soucie des coûts prévisibles et des hypothèses de retour sur investissement prudentes. Il est recruté à l'aide de modèles financiers clairs qui évitent les projections optimistes. 

• Un collaborateur informatiquese soucie de la facilité d'intégration, de l'impact opérationnel et de la charge de support. Il doit être impliqué dès le début dans l'évaluation technique. 

• Un utilisateur expérimenté se souciede savoir si l'outil résout réellement les problèmes quotidiens. Il doit participer aux démonstrations et aux essais. 

Lorsque ces voix s'accordent, l'approvisionnement devient une procédure plutôt qu'un conflit. 

Suivre une feuille de route pré-approuvée 

Les approbations rapides sont planifiées des mois à l'avance, et non précipitées à la dernière minute. 

• Six à quatre mois avant l'achat: sensibiliser et établir un consensus informel 

• Quatre à trois mois avant l'achat :procédez à des évaluations et soulevez les objections dès le début. 

• Trois à deux mois avant l'achat : élaborerl'analyse de rentabilité et valider les hypothèses 

• Deux mois pour acheter : naviguer dansles procédures d'achat formelles et l'examen juridique 

La plupart des transactions bloquées passent directement à la phase finale. 

Stratégies de négociation qui ne se retournent pas contre vous 

Des négociations mal menées entraînent souvent des problèmes en aval qui annulent toute économie à court terme. 

L'objectif est de préserver la valeur tout en gérant la perception des coûts. 

Ce qu'il faut négocier et ce qu'il faut éviter 

Les domaines à négocier comprennent :les délais de mise en œuvre, la formation et la mise en place, l'assistance à l'intégration, la structure de paiement, les accords de niveau de service (SLA) et les paramètres pilotes. 

Les domaines dangereux à négocier à outrance comprennent :la valeur fondamentalede la licence, la qualité du support, les fonctionnalités de sécurité et de conformité, ainsi que les intégrations critiques. 

Au lieu de demander des remises, posez des questions d'ingénierie de la valeur telles que : 

• Pouvons-nous échelonner la mise en œuvre afin de répartir les investissements ? 

• Quelles fonctionnalités pourrions-nous reporter à la deuxième année ? 

• Quelles tâches de mise en œuvre pourrions-nous gérer en interne ? 

• Quelle durée de contrat offre la meilleure valeur à long terme ? 

Signaux d'alerte que les acheteurs doivent surveiller chez les fournisseurs 

• Baisse spectaculaire des prix sans modification du champ d'application 

• Réponses vagues concernant les coûts futurs,  

• Urgence artificielle,  

• Réticence à fournir des références,  

• Des délais de mise en œuvre imprécis sont souvent le signe d'un risque caché. 

Dernière réflexion 

Les contrats relatifs aux logiciels de sécurité ne sont pas bloqués parce que le processus d'achat est défaillant. Ils sont bloqués parce que la plupart des analyses de rentabilité sont conçues pour les équipes de sécurité plutôt que pour les personnes chargées d'approuver les risques au nom de l'entreprise. 

Lorsque vous comprenez ce que chaque partie prenante cherche à protéger et que vous concevez votre argumentation en fonction de cette réalité, vous cessez de lutter contre le processus d'approvisionnement et commencez à le franchir.