Por qué se estancan las contrataciones de software de seguridad en la fase de adquisición (y cómo evitarlo)  

Si alguna vez te has preguntado por qué la adquisición de un software de seguridad, que parece algo obvio, se alarga durante meses o acaba quedando en el olvido en el departamento de compras, no eres el único. 

En los entornos empresariales, las herramientas de seguridad rara vez fallan por ser ineficaces. Fallan porque el proceso de adquisición está diseñado para ralentizar las decisiones, distribuir el riesgo y proteger a la organización de resultados negativos. Esa realidad choca con la forma en que la mayoría de los equipos de seguridad elaboran sus análisis de viabilidad. 

El resultado es de lo más habitual. Se mantienen conversaciones sobre el presupuesto. Las demostraciones salen bien. Los directivos asienten con la cabeza. Y luego el acuerdo se pierde en el proceso de contratación pública durante un periodo de entre seis y nueve meses. 

Este artículo analiza en qué puntos se estancan realmente las negociaciones sobre software de seguridad, las objeciones que surgen en las últimas fases del proceso y cómo elaborar un caso de negocio que supere el escrutinio del departamento de compras en lugar de fracasar en él. 

¿Por qué tardan tanto en cerrarse los acuerdos sobre software de seguridad? 

La mayoría de los responsables de la adquisición de soluciones de seguridad subestiman el número de personas con poder de decisión que intervienen entre el interés inicial y la aprobación final. El proceso de adquisición no es un simple paso. Se trata de un recorrido lleno de obstáculos diseñado para reducir el riesgo de la organización, no para acelerar la innovación. 

El agujero negro de la contratación pública 

Uno de los primeros retrasos se produce justo después de la aprobación del presupuesto, cuando el departamento de compras solicita varios presupuestos competitivos. Sobre el papel, esto parece una medida de diligencia debida. En la práctica, a menudo alarga el proceso entre 60 y 90 días. 

Esto ocurre porque los proveedores rara vez se ponen de acuerdo con claridad sobre el alcance, las funcionalidades o los modelos de implementación. Los equipos internos se ven entonces obligados a normalizar comparaciones entre cosas que no son comparables. Cada presupuesto adicional trae consigo nuevas partes interesadas y nuevas objeciones. 

Mientras esto ocurre, el impulso se va desvaneciendo y las prioridades cambian. 

Las partes interesadas ocultas que, en realidad, echan por tierra los acuerdos 

Los directores de seguridad rara vez son quienes frenan una compra. Las operaciones se estancan porque otros departamentos evalúan la decisión desde perspectivas muy diferentes. 

Los equipos de finanzas y de dirección financiera se centran en el retorno de la inversión, la previsibilidad y la contención de costes a largo plazo.
El departamento de TI se preocupa por la complejidad de la integración, los gastos generales operativos y la carga que supone el soporte técnico.
Los equipos jurídicos analizan minuciosamente la titularidad de los datos, la responsabilidad civil, los acuerdos de nivel de servicio (SLA) y las cláusulas de rescisión.
Los equipos de compras gestionan el riesgo de los proveedores, la estructura de los contratos y los riesgos de incumplimiento normativo. 

Si tu propuesta de negocio solo se centra en mejorar los resultados en materia de seguridad, no saldrá indemne de este grupo. 

Una visión realista del ciclo de compra empresarial 

Las autorizaciones de software de seguridad suelen desarrollarse de la siguiente manera: 

• Investigación inicial: de 4 a 6 semanas 

• Consecución de un consenso interno: de 6 a 8 semanas 

• Evaluación formal y demostraciones: de 4 a 6 semanas 

• Negociaciones de contratación pública: de 8 a 12 semanas 

• Revisión jurídica: de 2 a 4 semanas 

• Planificación de la implementación: de 2 a 3 semanas 

Cuando los compradores intentan acortar este plazo sin informar con antelación a las partes interesadas, el proceso de contratación se convierte en el cuello de botella que absorbe todas las dificultades. 

¿Qué objeciones en materia de contratación pública frustran los acuerdos de software de seguridad en las fases finales? 

La mayoría de las objeciones que surgen en las últimas fases del proceso no tienen nada que ver con el precio, aunque parezca lo contrario. 

Se trata del miedo. Miedo a que se vea afectada la reputación. Miedo a que la puesta en marcha fracase. Miedo al escrutinio de la dirección. 

Objeción 1: «Necesitamos ver el precio exacto por escrito antes de presentar esto». 

Lo que realmente significa es que a alguien le preocupa que el precio le dé un susto o parecer poco preparado ante los superiores. 

La forma de contrarrestar esta objeción es centrar la conversación no en los gastos, sino en la reducción de costes y la mitigación de riesgos. 

En lugar de empezar con cifras, basa tu argumento en el coste que supone mantener la situación actual. Esto incluye el coste continuo de los procesos manuales, las horas extras, las horas dedicadas a la respuesta ante incidentes, los consultores externos y los ingresos en riesgo debido a la pérdida de clientes o a la pérdida de confianza. El riesgo normativo y las consecuencias de las infracciones también deben tenerse en cuenta en este debate. 

Cuando la inversión se plantea como una forma de evitar pérdidas continuas, el precio pasa a ser algo contextual en lugar de resultar alarmante. 

Objeción 2: «Vuestra solución es más cara que la del competidor X» 

Lo que esto suele significar es que el departamento de compras realizó una comparación superficial. 

La solución consiste en implantar un marco de «coste total de propiedad» que vaya más allá del primer año. 

Esto incluye los servicios de implementación y puesta en marcha que los proveedores suelen restar importancia, los costes de formación y gestión del cambio, los gastos de integración de herramientas supuestamente más baratas, las cuotas de actualización, las limitaciones de las funciones y las diferencias reales en la calidad de la asistencia técnica y los tiempos de respuesta. 

Cuando los compradores presentan a la dirección el coste total del ciclo de vida, las herramientas de menor precio suelen perder la ventaja que se les atribuye. 

Objeción 3: «No estamos seguros de que esto vaya a funcionar en nuestro caso concreto». 

Esta objeción se debe al temor a ser responsable de un lanzamiento fallido. La solución consiste en hacer que la mitigación de riesgos sea explícita y visible. 

Las propuestas internas sólidas suelen incluir implementaciones por fases, programas piloto bien definidos con indicadores de éxito, puntos de control claros para la toma de decisiones y cláusulas de salida transparentes. Hablar abiertamente sobre los posibles escenarios de fracaso no debilita el argumento. Al contrario, refuerza la confianza. 

Objeción 4: «No es el momento adecuado. Tenemos que esperar». 

Esto suele indicar fatiga a la hora de tomar decisiones o prioridades contrapuestas. 

Para contrarrestarlo, los compradores deben cuantificar el coste de la espera. Esto implica calcular las ineficiencias mensuales, el riesgo de seguridad acumulado, la desventaja competitiva y el tiempo de aprendizaje perdido. 

Ofrecer alternativas ayuda. Empezar poco a poco ahora suele ser mucho menos arriesgado que una implantación a gran escala y disruptiva más adelante. 

Cómo elaborar un estudio de viabilidad que garantice la aprobación de un software de seguridad para empresas 

El departamento de compras no aprueba herramientas. Aprueba decisiones que se consideran justificables. 

Tu objetivo no es convencer a todo el mundo de que el software es impresionante. Tu objetivo es ayudar a cada parte interesada a explicar por qué aprobarlo no les supondrá ningún perjuicio. 

Crea tu coalición interna desde el principio 

Los defensores de la seguridad que tienen éxito buscan aliados antes de que comience el proceso de aprobación formal. 

• Un patrocinador ejecutivose preocupa por la ventaja estratégica y el riesgo empresarial. Se les capta mediante la inteligencia competitiva y los relatos sobre el impacto en los clientes. 

• Un aliado financierose preocupa por la previsibilidad de los costes y por unas hipótesis conservadoras en cuanto al retorno de la inversión. Se selecciona a estas personas mediante modelos financieros claros que evitan las previsiones optimistas. 

• Un colaborador del área de TIse preocupa por la facilidad de integración, el impacto operativo y la carga de asistencia técnica. Es necesario que participe desde el principio en la evaluación técnica. 

• A un usuario avanzado de operaciones le interesasaber si la herramienta resuelve realmente los problemas cotidianos. Debería participar en demostraciones y pruebas. 

Cuando estas opiniones coinciden, la contratación pública pasa a ser un proceso procedimental en lugar de un proceso conflictivo. 

Sigue una guía para la preaprobación 

Las aprobaciones rápidas se planifican con meses de antelación, no se hacen a toda prisa a última hora. 

• Entre seis y cuatro meses antes de la compra: crear conciencia y alcanzar un consenso informal 

• Entre cuatro y tres meses antes de la compra:realiza evaluaciones y aborda las objeciones desde el principio 

• Entre tres y dos meses antes de la compra: elaborarel análisis de viabilidad y validar las hipótesis 

• Dos meses para realizar la compra: gestionarel proceso formal de contratación y la revisión jurídica 

La mayoría de los acuerdos que se estancan pasan directamente a la fase final. 

Estrategias de negociación que no resultan contraproducentes 

Las negociaciones mal gestionadas suelen generar problemas posteriores que anulan cualquier ahorro a corto plazo. 

El objetivo es preservar el valor y, al mismo tiempo, gestionar la percepción de los costes. 

Qué negociar y qué evitar 

Entre los aspectos clave que conviene negociar se incluyen:los plazos de implementación, la formación y la capacitación, el apoyo a la integración, la estructura de pagos, los acuerdos de nivel de servicio (SLA) y los parámetros de la fase piloto. 

Entre los aspectos que resulta peligroso negociar en exceso se incluyen:el valor fundamentalde la licencia, la calidad del soporte técnico, las funciones de seguridad y cumplimiento normativo, y las integraciones críticas. 

En lugar de pedir descuentos, plantea preguntas relacionadas con la ingeniería de valor, como por ejemplo: 

• ¿Podemos llevar a cabo la implementación por fases para distribuir la inversión? 

• ¿Qué funciones podríamos posponer hasta el segundo año? 

• ¿Qué tareas de implementación podríamos llevar a cabo internamente? 

• ¿Qué duración de contrato ofrece la mejor relación calidad-precio a largo plazo? 

Señales de alerta sobre los vendedores que los compradores deben tener en cuenta 

• Descensos drásticos de los precios sin cambios en el alcance 

• Respuestas vagas sobre los costes futuros,  

• Urgencia fingida,  

• La reticencia a facilitar referencias,  

• Los plazos de ejecución poco claros suelen indicar la existencia de riesgos ocultos. 

Reflexión final 

Las operaciones de adquisición de software de seguridad no se estancan porque el proceso de adquisición no funcione. Se estancan porque la mayoría de los análisis de viabilidad se elaboran pensando en los equipos de seguridad, en lugar de en las personas encargadas de aprobar los riesgos en nombre de la empresa. 

Cuando comprendes qué es lo que cada parte interesada está protegiendo y diseñas tu argumento en función de esa realidad, dejas de enfrentarte al proceso de contratación y empiezas a avanzar en él.