Ángulo

Una exigencia técnica de gran cuenta —la base de datos en su propia suscripción cloud, su pasarela de correo, su proveedor de modelo de lenguaje— se negocia sobre su motivo, nunca sobre su viabilidad. El motivo dice lo que basta con conceder; responder a la petición tal como está formulada equivale a conceder el máximo sin saber por qué, y ese máximo se paga después en divergencia del producto, en partidas que ningún cuadro de costes muestra.

Síntesis

Un gran grupo evalúa tu software de nóminas. El asunto avanza. Y entonces cae una frase: "la base de datos debe estar en nuestra suscripción de Azure".

La discusión que sigue se sitúa casi siempre en el mismo sitio: ¿es viable? Sí, técnicamente. ¿Cuánto tiempo? Dos meses. Se cifra, uno se compromete y se pasa a lo siguiente.

Esa discusión se ha saltado la única pregunta que da el control: por qué esa petición. Una auditoría ISO que hay que pasar, una política de seguridad que prohíbe los datos fuera de su tenant, un equipo de ciberseguridad que quiere sus registros en su propia herramienta de supervisión. No son juicios sobre tu competencia —nadie cree que el cliente vaya a alojar mejor que tú—. Es control: poder responder de sus datos ante su auditor.

El motivo importa porque fija la dosis. Si la necesidad es demostrar que los datos no salen de la Unión Europea, una región de alojamiento y un compromiso escrito la cubren. Si es conservar la clave de cifrado, una clave gestionada por el cliente la cubre. Ninguna de esas dos necesidades exige la base en su suscripción. Responder a la petición tal como está formulada es conceder el máximo por un motivo que no se ha identificado.

Porque lo que se concede tiene un precio, y se paga en partidas que nadie lleva. La base vive en casa del cliente: cada puesta en producción que toca la estructura de datos se convierte en un procedimiento que enviar, una validación que esperar, una ventana de mantenimiento que reservar. El primer cliente la pasa el martes, el tercero la aplaza al mes siguiente, y tres meses después tus correctivos se prueban contra cuatro estados de base distintos. Lo que se pierde ahí es exactamente lo que daba interés al modelo: un producto único que se hace avanzar para todos a la vez. La partida de infraestructura, en cambio, ha bajado — y es esa la que ve el comercial cuando propone un descuento.

Hay un caso en que el cálculo cambia de sentido: un bloque que no diferencia nada puede impedir por sí solo la venta. El SSO no distingue a ningún software de nóminas de sus competidores, y su ausencia basta para eliminarte. Se construye, por tanto, no por lo que aporta, sino por lo que cuesta su ausencia. La pregunta nunca es "¿esto crea valor?" — es "¿qué abre esto, y en qué partida se paga?".

De ahí la conclusión, que no es técnica. Estas exigencias no son casos particulares que tratar uno a uno: son la cultura de gobernanza de un segmento de mercado. Decidir vender ahí es aceptar esa restricción como un dato del mercado, cifrarla de una vez por todas y negociar cada petición sobre su motivo en lugar de sobre su viabilidad.

Tensiones / contradicciones

Dos notas no dicen lo mismo sobre lo que se puede ceder. Una plantea que sustituir a un proveedor sin cambiar el valor vuelve sustituible el servicio —y por tanto que hay que resistir—; la otra, que la sustitución sigue siendo costosa en cuanto el bloque sostiene el estado duradero —y por tanto que el riesgo es menor de lo que parece—. La frontera entre ambas no está trazada.

Tensión no resuelta también: la tesis pide negociar sobre el motivo, pero nada garantiza que el interlocutor lo conozca. Una exigencia transmitida por un comprador puede haber perdido su razón por el camino.

Preguntas

• ¿Cómo hacer emerger el motivo cuando el interlocutor solo transmite una regla interna?
• ¿Hasta cuántos estados de base distintos aguanta un equipo antes de que la calificación se vuelva impracticable?