Adquisición vs. Propiedad Operativa: Quién Decide sobre SaaS y Cuándo

El equipo de operaciones había estado evaluando herramientas de gestión de proyectos durante seis semanas. Habían hecho Demos, ejecutado un Pilot, puntuado a los proveedores e identificado un ganador claro. El contrato estaba listo para firmar.

Legal lo marcó. Adquisición estaba evaluando simultáneamente a tres de los mismos proveedores para un despliegue a toda la empresa. El equipo de operaciones no lo sabía. Adquisición no sabía que el equipo de operaciones estaba ejecutando un proceso paralelo. Y el proveedor que el equipo de operaciones había elegido era en realidad el que adquisición había clasificado en tercer lugar.

El COO ahora tenía que tomar una decisión que era políticamente difícil independientemente de cómo resultara: anular las seis semanas de trabajo del equipo de operaciones, o anular la evaluación en curso de adquisición. Cualquier opción consumía buena voluntad y sentaba un precedente.

La causa raíz no fue una mala decisión de ninguno de los dos equipos. Fue una estructura de autoridad indefinida. Nadie había respondido la pregunta: ¿cuándo decide operaciones, cuándo lidera adquisición y cómo se hace el handoff cuando el tamaño o el alcance supera un umbral?

Esa es la pregunta que responde esta guía.

Datos clave: Adquisición vs. Propiedad Operativa en SaaS

• El 65-75% de las compras de SaaS en empresas de mediana empresa evitan completamente a adquisición, con compradores de línea de negocio (operaciones, ventas, marketing, RRHH) tomando decisiones de compra directas (investigación de gasto en SaaS de Gartner, 2024).
• La empresa promedio de mediana empresa ejecuta un 40-60% más de apps de SaaS de lo que IT conoce, el shadow IT infla la cartera real bien por encima del inventario sancionado (Productiv State of SaaS Sprawl, 2024).
• El gasto duplicado en SaaS promedia el 10-30% del presupuesto total de SaaS en empresas de mediana empresa sin un registro central: dos equipos comprando herramientas superpuestas es la mayor fuente de desperdicio prevenible.
• El tiempo promedio del ciclo de aprobación de adquisición para herramientas por encima de $25K es de 6-10 semanas en empresas con adquisición formal, vs. 2-5 días para las decisiones lideradas por operaciones por debajo del umbral (Deloitte CPO Survey).
• Las empresas que formalizan la propiedad de SaaS entre los 150-500 empleados gastan aproximadamente un 40% menos por empleado en SaaS en el hito de los 500 empleados que aquellas que posponen la gobernanza hasta que una crisis las obliga (investigación de madurez de gobernanza tecnológica de Forrester).

El Modelo de División de Propietario de Decisión

El Modelo de División de Propietario de Decisión asigna la autoridad de compra de SaaS basándose en dos ejes: valor del contrato y especificidad funcional. Adquisición lidera cuando el valor del contrato supera un umbral material (típicamente $50K+) o cuando la herramienta es infraestructura transversal donde la consolidación de la cartera importa más que el ajuste específico del usuario. Operaciones lidera cuando la herramienta es específica del departamento, está por debajo del umbral y el conocimiento del caso de uso domina la decisión. La propiedad conjunta se aplica en la banda intermedia ($10K-$50K), donde operaciones define los requisitos y ejecuta la evaluación mientras adquisición gestiona el proceso del RFP, los términos del contrato y la diligencia del proveedor, con reglas explícitas de desempate (operaciones gana en capacidad, adquisición gana en precio/términos, seguridad gana en riesgo).

Por Qué la Autoridad de SaaS No Está Definida en la Mayoría de las Empresas de Mediana Empresa

Las empresas de mediana empresa típicamente no construyen funciones formales de adquisición hasta que están experimentando problemas de adquisición. Para entonces, la cultura informal de compra está establecida y es difícil de cambiar. La Encuesta Global de Directores de Adquisición de Deloitte encuentra consistentemente que las empresas sin autoridad de adquisición formalizada en la etapa de mediana empresa gastan un 20-35% más en categorías de tecnología que empresas de tamaño comparable con estructuras de propiedad definidas.

La evolución generalmente se ve así:

• 0-50 empleados: El fundador o COO aprueba todo. Informal pero funcional: el CEO conoce cada herramienta.
• 50-150 empleados: Aprobación informal a nivel gerencial, con finanzas haciendo verificaciones puntuales. La mayoría de las compras suceden por debajo del umbral de visibilidad.
• 150-500 empleados: IT, Finanzas y Operaciones están involucrados en diferentes compras sin un proceso consistente. Surgen conflictos. El shadow IT es significativo.

El rango de 150-500 es donde la autoridad de SaaS debe formalizarse. La organización es demasiado grande para la visibilidad a nivel de CEO en cada compra, pero aún no está suficientemente estructurada como para haber construido los rieles de gobernanza. Y el gasto en SaaS es lo suficientemente grande (típicamente $300K-$1M+ anuales) para justificar la estructura. La investigación de Forrester sobre la madurez de la gobernanza tecnológica identifica el rango de 150-500 empleados como la ventana de mayor riesgo para la gestión del gasto tecnológico. Las organizaciones que formalizan las estructuras de autoridad durante esta fase de crecimiento muestran un gasto en SaaS por empleado un 40% menor en el hito de los 500 empleados que aquellas que posponen la gobernanza hasta que una crisis las obliga.

Los Tres Modelos de Propiedad

Modelo 1: Autoridad Basada en Umbrales

El modelo más común y práctico para empresas de mediana empresa. La autoridad se asigna según el valor del contrato:

Ventajas: Simple de comunicar, fácil de aplicar, se mapea a la materialidad financiera.

Desventajas: Manipulación del umbral. Los equipos dividen las compras en múltiples contratos más pequeños para mantenerse por debajo del umbral. Requiere una regla de "retrospectiva": las compras del mismo proveedor, o herramientas que sirven la misma función, se agregan para los propósitos del umbral independientemente de cómo estén estructuradas. Así es también como se multiplica el sprawl de SaaS. Las compras pequeñas por debajo del umbral que individualmente parecen bien se acumulan en una cartera que nadie supervisa.

Modelo 2: Autoridad Basada en Categorías

La autoridad se asigna por categoría de herramienta en lugar de por valor:

Ventajas: La experiencia en la categoría impulsa la decisión. RRHH es dueño de las herramientas de RRHH, Revenue Operations es dueño de las herramientas de ventas. Mejores decisiones en dominios especializados.

Desventajas: Los límites de las categorías son difusos. Un CRM es una herramienta de ventas. Pero también es una herramienta de IT. Y una herramienta de datos de clientes. Las disputas de categorías requieren un árbitro de desempate.

Modelo 3: Modelo Híbrido (Operaciones Decide Por Debajo del Umbral, Adquisición Asesora)

Un término medio pragmático que funciona bien para empresas con una función de adquisición emergente:

• Por debajo de $10K: Operaciones decide con requisito de registro en IT. Adquisición está disponible como asesor pero no tiene autoridad de aprobación.
• $10K-$50K: Operaciones lidera la evaluación; adquisición asesora sobre el proceso del RFP, la revisión del contrato y la negociación. Decisión conjunta con escalación al COO si no se resuelve.
• Por encima de $50K: Adquisición lidera el proceso; operaciones es la parte interesada principal que define los requisitos y evalúa la capacidad. Decisión conjunta.

El principio clave: El valor añadido de adquisición es la experiencia en el proceso (gestión del RFP, negociación de contratos, diligencia del proveedor) y la supervisión de la cartera (prevención de duplicados, gestión del gasto agregado). El valor añadido de operaciones es el conocimiento del caso de uso (qué necesita hacer la herramienta y cómo encaja en los Workflows). El modelo falla cuando adquisición se convierte en un cuello de botella en lugar de un acelerador, o cuando operaciones evita adquisición para evitar la percepción de ralentización. Para las herramientas por encima del umbral, cómo ejecutar un RFP de SaaS es la plantilla del proceso de tres semanas que mantiene la evaluación liderada por adquisición lo suficientemente rápida para que los equipos no la eviten.

Elección del Modelo Correcto

La Plantilla de Matriz de Autoridad de SaaS

Construya esta matriz para su empresa. Complete cada celda antes de publicar la política.

La Asignación de Propiedad Post-Compra

Una pregunta casi tan importante como "quién decide": ¿quién es dueño de la relación con el proveedor después de que se firma el contrato?

Aquí es donde la mayoría de los marcos de gobernanza se detienen. Definen el proceso de aprobación y dejan la propiedad sin definir. Luego el campeón original se va, la renovación se acerca, nadie conoce los términos, y el contrato se renueva automáticamente por defecto.

Plantilla de asignación de propiedad post-compra:

Para las compras por debajo de $10K, una persona puede desempeñar los tres roles. Para las compras por encima de $50K, deben ser personas separadas.

Esta asignación debe documentarse cuando se firma el contrato, almacenarse en el registro de SaaS y revisarse anualmente.

El Árbol de Decisión de Escalación

Cuando operaciones y adquisición están en desacuerdo sobre una decisión de compra de SaaS, el camino de escalación debe definirse antes de que ocurra el conflicto.

Árbol de escalación estándar:

¿Es esto una compra nueva o una renovación?
├── Compra nueva
│   ├── ¿Por debajo del umbral? → Operaciones decide según la matriz de autoridad
│   └── ¿Por encima del umbral?
│       ├── ¿Ops y adquisición están de acuerdo? → Recomendación conjunta al ejecutivo
│       └── ¿Ops y adquisición están en desacuerdo?
│           ├── ¿Es el desacuerdo sobre la capacidad? → Operaciones gana (define los requisitos)
│           ├── ¿Es el desacuerdo sobre el precio/términos? → Adquisición gana (su dominio)
│           ├── ¿Es el desacuerdo sobre el riesgo del proveedor? → IT/Seguridad gana (el riesgo es su dominio)
│           └── ¿Es el desacuerdo sobre la estrategia? → COO decide en 48 horas
└── Renovación
    ├── ¿Menos de $10K? → El dueño del negocio decide; el dueño comercial negocia
    └── ¿Más de $10K? → Decisión conjunta del dueño del negocio + dueño comercial; COO si hay desacuerdo

La regla "el COO decide en 48 horas" es crítica. Las escalaciones abiertas matan el impulso. Incorpore un límite de tiempo en el proceso.

Modos de Fallo Comunes

Adquisición como guardián, no como habilitador. Cuando cada compra por encima de un umbral requiere la aprobación de adquisición y adquisición ejecuta un ciclo de seis semanas, los equipos evitan el proceso. La solución son los estándares de nivel de servicio para adquisición: una compra de $20K debería tener un tiempo de respuesta de adquisición de cinco días hábiles, no tres semanas.

Política de autoridad sin proceso. Definir quién puede aprobar qué no ayuda si no hay un sistema para rastrear las aprobaciones, no hay un registro de SaaS para registrar nuevas herramientas y no hay un calendario de renovaciones para gestionar los vencimientos próximos.

Política que operaciones ignora. Una política que no se aplica es peor que ninguna política. Crea la apariencia de gobernanza sin la realidad. Construya la política en torno a un Workflow que los equipos realmente sigan: un formulario de aprobación, un canal de Slack, un registro de SaaS. La política debe requerir pasos adicionales mínimos, no un desvío burocrático.

Propiedad indefinida al momento de la firma del contrato. En el momento en que se firma un contrato, el dueño del negocio, el dueño técnico y el dueño comercial deben ser asignados y registrados. Si esto no se hace al momento de la firma, se vuelve más difícil de hacer retroactivamente. Esto es especialmente importante para los contratos con términos de renovación complejos. La guía de señales de alerta en contratos SaaS cubre las cláusulas de auto-renewal y ventana de aviso que solo importan si alguien realmente es dueño del calendario de renovaciones.

Cómo Hacer que la Política Sea Efectiva

La razón más común por la que fracasan las políticas de gobernanza es que están diseñadas como documentos en lugar de Workflows. Un documento puede ignorarse. Un Workflow es parte de cómo se hace el trabajo. La investigación de McKinsey sobre el cambio organizacional en las funciones de adquisición encontró que las políticas de adquisición incorporadas en los Workflows de aprobación existentes logran tasas de cumplimiento 3-4 veces más altas que los documentos de política independientes, independientemente del contenido de la política.

Para que la política sea efectiva:

1. Construya el registro. Cada herramienta aprobada va a una herramienta central (una hoja de cálculo está bien para empezar; una plataforma de gestión de SaaS adecuada a medida que escale) con propietario, costo, fecha de renovación y estado.

2. Automatice las alertas de renovación. Noventa días antes de cada renovación por encima de $5K, el dueño comercial recibe un recordatorio automatizado. Este único cambio elimina la mayoría de las sorpresas de renovación.

3. Haga del cumplimiento el camino fácil. El Workflow de aprobación debe tomar diez minutos para una herramienta de $3K, no treinta. Si el proceso es doloroso, los equipos lo evitan.

4. Revise las excepciones públicamente. Cuando un equipo compra una herramienta fuera del proceso, abórdelo en un foro donde otros líderes de equipo lo vean. El shadow IT persiste cuando no tiene consecuencias.

5. Informe sobre la cartera trimestralmente. Una breve revisión de la cartera (gasto total, herramientas añadidas, herramientas eliminadas, renovaciones próximas) mantiene la visibilidad del liderazgo actualizada sin requerir una auditoría profunda cada vez.

Medición de si la Gobernanza Está Funcionando

La puntuación de satisfacción de operaciones vale la pena rastrearla explícitamente. Si operaciones califica consistentemente el proceso de adquisición de manera desfavorable, la política está creando fricciones que generarán soluciones alternativas. Esa fricción vale la pena diagnosticarla y eliminarla.

Cómo Rework Work Ops Apoya la Coordinación entre Adquisición y Operaciones

La gobernanza se rompe cuando adquisición y operaciones trabajan desde sistemas separados: adquisición vive en hojas de cálculo y colas de tickets, operaciones vive en herramientas de proyectos y bandejas de entrada compartidas. El handoff entre ellos es donde se originan las evaluaciones duplicadas, el shadow IT y las sorpresas de renovación.

Rework Work Ops le da a ambas funciones una superficie compartida. El registro de proveedores vive como una base de datos estructurada que puede ver cada departamento: cada herramienta, propietario, fecha de renovación, nivel de gasto y estado de aprobación en un solo lugar. Adquisición puede filtrar por "contratos que vencen en 90 días por encima de $10K" mientras operaciones puede filtrar por "herramientas en mi categoría actualmente en evaluación". Las evaluaciones duplicadas surgen antes de que el segundo equipo desperdicie seis semanas en un RFP paralelo.

La plantilla del Workflow de aprobación se mapea directamente al Modelo de División de Propietario de Decisión descrito anteriormente. Una solicitud de $3K se enruta al jefe de departamento con una lista de verificación ligera. Una solicitud de $25K adjunta automáticamente a adquisición como asesor y activa la plantilla de RFP. Una solicitud de $60K escala a adquisición liderado con operaciones como parte interesada, todo sin persecución por Slack ni propiedad ambigua. Comenzando en $6 por usuario por mes, Work Ops tiene un precio justificable después de prevenir una compra duplicada.

Preguntas Frecuentes

Aprenda Más

• El Árbol de Decisión de Compra de SaaS: Cuándo Comprar, Construir o Complementar: el marco de decisión que opera dentro de la estructura de gobernanza
• Cómo Ejecutar un RFP de SaaS Sin Desperdiciar 6 Semanas: cómo se ve el proceso liderado por adquisición para las compras por encima del umbral
• El Problema del Sprawl de SaaS: Señales de que Lo Tiene y Cómo Solucionarlo: qué sucede cuando la gobernanza está ausente durante demasiado tiempo
• Consolidación de SaaS: Cuándo Eliminar una Herramienta vs. Mantenerla: el ejercicio de limpieza que una buena gobernanza evita que sea necesario
• Medición del ROI de SaaS a los 90 días de la compra: cómo vincular la responsabilidad del dueño del negocio a resultados medibles a los 90 días
• Política de gobernanza de IA para departamentos: cómo extender el marco de autoridad para gobernar específicamente las compras de AI SaaS