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

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 négociations concernant les logiciels de sécurité prennent-elles 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'approbation du budget, lorsque le service des achats sollicite plusieurs devis concurrentiels. Sur le papier, cela ressemble à une diligence raisonnable. Dans la pratique, cela allonge souvent le processus de 60 à 90 jours.

Cela s'explique par le fait que les fournisseurs s'accordent rarement clairement sur le périmètre, les fonctionnalités ou les modèles de mise en œuvre. Les équipes internes doivent alors harmoniser des comparaisons qui relient des éléments disparates. Chaque nouveau devis fait intervenir de nouvelles parties prenantes et soulève de nouvelles objections.

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

Les parties prenantes cachées qui font en réalité capoter les transactions

Ce sont rarement les responsables de la sécurité qui bloquent un achat. Les transactions sont bloquées parce que d’autres services évaluent la décision sous un angle très différent.

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 services informatiques s'inquiètent de la complexité de l'intégration, des frais généraux opérationnels et de la charge de support.
Les équipes juridiques examinent minutieusement la propriété des données, la responsabilité, les accords de niveau de service (SLA) et les clauses de résiliation.
Les équipes 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 préliminaire : 4 à 6 semaines

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

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

• Négociations relatives aux marchés publics : 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 formulées en fin de processus n'ont rien à voir avec le prix, même si elles semblent en avoir.

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 commencer par citer des chiffres, fondez votre argumentation sur le coût du statu quo. Cela inclut le coût récurrent des processus manuels, des heures supplémentaires, des interventions en cas d'incident, des consultants externes, ainsi que le manque à gagner lié à la perte de clients ou à la perte de confiance. Les risques réglementaires et les conséquences d'une violation de données doivent également être pris en compte dans cette réflexion.

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 inclut les services de mise en œuvre et d'accompagnement à la prise en main, que les fournisseurs ont souvent tendance à minimiser, les coûts liés à la formation et à la gestion du changement, les frais d'intégration d'outils prétendument moins chers, les frais de mise à niveau, les limitations fonctionnelles, ainsi que les différences réelles en matière de qualité de l'assistance et de délais 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 trouve son origine dans la crainte d'être tenu pour responsable d'un déploiement raté. La solution consiste à rendre les mesures d'atténuation des risques explicites et visibles.

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 pertes d'efficacité mensuelles, l'aggravation des risques de sécurité, le désavantage concurrentiel 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 parrain exécutifse préoccupe de l'avantage stratégique et des risques d'entreprise. Son recrutement s'appuie sur l'analyse concurrentielle et les témoignages illustrant l'impact sur les clients.

• Un partenaire financier accorde de l'importance à la prévisibilité des coûts et à des hypothèses prudentes en matière de retour sur investissement. Il est sélectionné sur la base de modèles financiers clairs qui évitent les prévisions trop optimistes.

• Un collaborateur du service informatique se préoccupe de la facilité d'intégration, de l'impact opérationnel et de la charge de travail liée à l'assistance. Il doit être associé dès le début au processus d'évaluation technique.

• Un utilisateur avancé, dans le cadre de son activité quotidienne, cherche à savoir si l'outil permet réellement de résoudre ses problèmes quotidiens. Il devrait participer aux démonstrations et aux périodes d'essai.

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

Suivre une feuille de route pour la pré-approbation

Les validations rapides sont planifiées des mois à l'avance, et non pas effectuées à la hâte en fin de processus.

• 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 que possible

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

• Deux mois pour finaliser l'achat : gérer la procédure d'appel d'offres 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 toutes les économies réalisées à 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

Parmi les points clés à aborder lors des négociations, citons : les délais de mise en œuvre, la formation et l'accompagnement, l'assistance à l'intégration, les modalités de paiement, les accords de niveau de service (SLA) et les paramètres du projet pilote.

Parmi les points sur lesquels il est risqué de trop négocier, on peut citer : la valeur fondamentale de la licence, la qualité du support, les fonctionnalités de sécurité et de conformité, ainsi que les intégrations essentielles.

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 le meilleur rapport qualité-prix à long terme ?

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

• Des baisses de prix spectaculaires sans modification de la portée

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

• Urgence artificielle,

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

• Des délais de mise en œuvre flous sont souvent le signe d'un risque latent.

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 à préserver et que vous élaborez votre argumentaire en tenant compte de cette réalité, vous cessez de vous opposer au processus d’appel d’offres et commencez à le mener à bien.