Español

El árbol de decisión para comprar SaaS: ¿Cuándo comprar, construir o integrar?

Datos clave: decisiones de compra de SaaS en empresas de mercado medio

  • Duración promedio de evaluación de SaaS: 84 días desde el primer Demo hasta la firma del contrato en acuerdos superiores a $25.000/año (Gartner, benchmarks de compra B2B 2025).
  • Proveedores en lista corta de proveedores por acuerdo: 3 a 5 en acuerdos típicos de mercado medio; los acuerdos enterprise promedian 6 a 8 (Forrester SaaS buying pulse).
  • Tomadores de decisión por acuerdo: 6,8 en promedio en una compra de software B2B de mercado medio, frente a 5,4 en 2020 (Gartner B2B Buying Journey).
  • Tasa de éxito de decisiones estructuradas vs. ad-hoc: los equipos que usan un marco de decisión documentado reportan tasas de adopción de herramientas 2,3 veces mayores un año después de la compra, en comparación con los equipos que omiten los pasos del marco (McKinsey software buying study).
  • Superposición de herramientas en empresas de mercado medio: el 30-40% de las herramientas SaaS tienen superposición de funciones con al menos otra herramienta del stack (Productiv State of SaaS).

El COO tenía un problema: en realidad, tres problemas. En un solo trimestre, tres equipos distintos habían solicitado a la dirección recursos con la justificación de "necesitamos algo rápido". Los tres fueron aprobados. Los tres compraron. Y cuando el líder de IT mapeó el stack cuatro meses después, dos de las herramientas tenían una superposición sustancial de funciones entre sí, y una duplicaba funcionalidades que la empresa ya tenía en una plataforma que había licenciado dieciocho meses antes.

Nadie había hecho nada incorrecto, en rigor. Cada equipo tenía una necesidad real y encontró una solución real. Pero nadie había hecho la pregunta previa: ¿deberíamos estar comprando algo en absoluto?

Esa pregunta, comprar, construir o integrar, parece obvia. No lo es. La mayoría de las empresas la omiten por completo porque requiere trabajo antes de que comiencen las conversaciones con los proveedores, y esas conversaciones son más fáciles. El Demo ya está programado. El Trial ya está en curso. La decisión de compra ocurre antes de que el marco de decisión se aplique.

Esta guía le ofrece ese marco. Está diseñada para empresas de entre 50 y 500 personas que toman decisiones de SaaS con suficiente frecuencia como para que un proceso formal de adquisición parezca excesivo, pero con la suficiente lentitud como para que la proliferación de herramientas tenga consecuencias reales en presupuesto y productividad.

Por qué la respuesta por defecto siempre es "comprar"

El mercado de SaaS ha diseñado el camino de menor resistencia para apuntar directamente hacia una compra. Los Trials gratuitos eliminan la fricción. El Product-Led Growth hace que las herramientas se propaguen dentro de las organizaciones antes de que adquisición se entere. Según la investigación de Gartner sobre comportamiento de compra de software, los usuarios finales ahora inician más del 60% de las compras de software, a menudo sin pasar por IT ni adquisición. Los discursos de vendors de IA en 2025 y 2026 han añadido una nueva complejidad: cada capacidad parece una plataforma, y cada plataforma promete reemplazar tres herramientas que ya posee. Antes de evaluar cualquier vendor, es útil entender cómo ejecutar un RFP de SaaS que no desperdicie seis semanas, porque el proceso de RFP asume que usted ya decidió comprar.

La respuesta por defecto es "comprar" porque es la más fácil de defender. Se puede mostrar un Demo. Se puede señalar un caso de estudio. Se puede tener un equipo productivo en dos semanas. Construir lleva meses, e integrar requiere que alguien conozca la herramienta existente lo suficientemente bien como para saber qué puede hacer realmente.

Pero el costo de optar siempre por "comprar" se acumula. El número de herramientas crece. Los contratos se renuevan automáticamente. El seat count se descontrola. La investigación de McKinsey sobre gasto en software muestra que las organizaciones subestiman sistemáticamente el costo total del software entre un 30 y un 50% cuando solo consideran las tarifas de licencia. Y eventualmente el CFO se encuentra con una línea de SaaS que ha crecido un 40% año tras año sin una explicación clara de qué se obtuvo a cambio. Las consecuencias de omitir este paso son visibles en el problema de la proliferación de SaaS, un patrón que aparece en casi todas las empresas de mercado medio que han crecido rápidamente.

El marco de decisión cambia el punto de partida de "¿qué vendor?" a "¿deberíamos comprar algo en absoluto?"

El árbol de decisión de cuatro ramas

El árbol de decisión construir vs. comprar vs. adoptar

El árbol de decisión construir vs. comprar vs. adoptar es un marco de tres ramas que obliga a hacer una pregunta estructurada antes de cualquier conversación con proveedores: construir (desarrollar internamente cuando la función es central para la ventaja competitiva), comprar (licenciar una herramienta SaaS específica cuando la función no es central y el mercado de vendors es maduro), o adoptar (ampliar una capacidad ya disponible en el stack existente cuando la cobertura es del 70% o más). El árbol se recorre en orden: primero si es función central o no, luego el costo de construcción, luego la auditoría del stack existente, y finalmente la madurez del mercado de vendors, y se detiene en la primera rama que produce una respuesta defendible.

Aquí está el marco. Recorra cada rama en orden. La primera rama que le dé una respuesta clara es donde se detiene.

Rama 1: ¿Es esta una función central o no central?

Las funciones centrales son aquellas que diferencian su negocio o generan ingresos directamente. Las funciones no centrales son actividades de soporte: cosas que toda empresa necesita pero que no son fuentes de ventaja competitiva. El marco construir vs. comprar de Harvard Business Review plantea esta distinción en términos de control estratégico: externalice lo que es commodity, preserve lo que es propio.

Para la mayoría de las empresas de mercado medio, los ejemplos son los siguientes:

Central: cómo vende, cómo entrega, cómo retiene clientes, cómo funciona su producto.

No central: gestión de gastos, programación, almacenamiento de archivos, administración de RRHH, gestión de tickets de IT.

Si la necesidad es genuinamente central, la opción de construir merece consideración seria. No porque construir sea siempre mejor, sino porque externalizar lo que lo diferencia conlleva un riesgo estratégico que el precio de etiqueta no refleja.

Si la necesidad no es central, no la construya. Pase a la Rama 2.

Rama 2: ¿Cuál es el costo real de construir?

La mayoría de las empresas no elaboran una estimación de costos real antes de descartar la opción de construir. La estimación es "tendríamos que contratar ingenieros" y la conversación avanza. Esa es la respuesta correcta para la mayoría de las funciones no centrales, pero para las funciones centrales merece un número real.

Una hoja de trabajo básica de costos de construcción se ve así:

Categoría de costo Método de estimación
Desarrollo inicial Horas de ingeniería x tarifa por hora
Mantenimiento continuo 15-20% del costo de construcción inicial por año
Seguridad y cumplimiento Cumplimiento OWASP, pruebas de penetración, parches continuos
Hosting e infraestructura Estimación de costos en la nube a escala objetivo
Documentación y capacitación Generalmente el 20-30% del tiempo de desarrollo
Costo de oportunidad ¿Qué más podría estar construyendo este equipo?

La última línea es la que las empresas subestiman de manera consistente. Si sus ingenieros podrían estar desarrollando funciones del producto en lugar de una herramienta de Workflow interna, el costo real de construir incluye los ingresos que no generó.

Si el costo de construcción resulta significativamente mayor que las alternativas SaaS en un horizonte de 3 años (lo que suele ocurrir para funciones no centrales), pase a la Rama 3. El marco completo de modelado de TCO para SaaS cubre este modelo de costos en detalle, incluyendo implementación, integración y costos de salida que una comparación simple de licencias no contempla.

Rama 3: ¿Puede una herramienta existente hacer esto?

Antes de comprar cualquier herramienta nueva, audite lo que ya posee. Este es el paso que la mayoría de las empresas omite porque requiere que alguien inicie sesión en las herramientas existentes y comprenda qué pueden hacer.

Las preguntas que debe hacerse:

  • ¿Alguna plataforma actual tiene esta función de forma nativa o mediante configuración?
  • ¿Alguna plataforma actual tiene esta función en su Roadmap (dentro de 90 días)?
  • ¿Existe una integración o automatización entre dos herramientas existentes que aproxime esta necesidad?
  • ¿Hay licencias sin uso en una herramienta actual que tenga esta capacidad?

Esta auditoría debería tomar a una persona uno o dos días, no seis semanas. Usted busca una capacidad existente que sea suficientemente cercana, no una coincidencia perfecta.

La siguiente tarjeta de puntuación ponderada de complejidad de integración le ayuda a evaluar si integrar sobre una herramienta existente es genuinamente más sencillo o simplemente intercambia un tipo de trabajo por otro:

Factor Baja complejidad Complejidad media Alta complejidad
Alineación del modelo de datos Mismos objetos, mismos campos Objetos distintos, mapeo limpio Objetos distintos, mapeo personalizado requerido
Disponibilidad de API Integración nativa existente REST API disponible, sin integración nativa Solo webhook o sin API
Carga de mantenimiento Configurar y olvidar Revisión mensual necesaria Ingeniería continua requerida
Cambio en el Workflow del usuario Mismo Workflow, nuevo botón Punto de entrada distinto, mismo resultado Nuevo Workflow requerido

Si dos o más categorías puntúan "Alta", la integración probablemente sea más costosa en la práctica que comprar una herramienta específica.

Si su stack existente tiene una capacidad genuinamente cercana, amplíela. Si no, pase a la Rama 4.

Rama 4: ¿Es maduro el mercado de vendors?

La madurez del mercado de vendors importa porque determina su riesgo a largo plazo. El análisis del mercado SaaS de Forrester distingue entre líderes de categoría con más de 5 años de trayectoria y competidores emergentes que aún están en ciclos de product-market fit, una distinción que afecta directamente cómo debe dimensionar su compromiso contractual. Comprar en un mercado maduro significa que usted tiene:

  • Múltiples vendors establecidos con más de 5 años de trayectoria
  • Diferenciación clara de funciones (no solo diferenciación de marketing)
  • Clientes de referencia en su industria y tamaño
  • Términos contractuales estándar con puntos de negociación conocidos

Comprar en un mercado inmaduro, especialmente en la actual ola de SaaS de IA, significa:

  • Los vendors tienen 12-18 meses de antigüedad con financiamiento inicial o de Serie A
  • Los Roadmaps de funciones son amplios; la capacidad en producción es limitada
  • Los precios son experimentales y cambiarán
  • Los clientes de referencia son early adopters seleccionados a mano

Esto no significa que no deba comprar a vendors emergentes. Significa que debe dimensionar su compromiso según la madurez del mercado. Un Pilot de $500/año es un riesgo distinto al de un contrato anual de $50.000 con auto-renewal a 2 años.

Regla de decisión: si el mercado es maduro, compre con la diligencia estándar. Si es inmaduro, compre con compromiso limitado (anual, no plurianual; alcance de Pilot, no despliegue completo) e incorpore un disparador de reevaluación en el contrato. Para herramientas con IA nativa, evaluar SaaS con IA integrada ayuda a separar la capacidad genuina de las promesas de marketing antes de asumir un compromiso plurianual.

Errores comunes en cada rama

Soluciones puntuales que duplican licencias existentes

El error más común y costoso. Un equipo compra una herramienta de gestión de proyectos porque no les gusta cómo está configurada la herramienta de gestión de proyectos existente de la empresa. La solución no es una nueva herramienta. Es una conversación de mejor configuración o capacitación sobre la herramienta existente.

Antes de aprobar cualquier compra nueva, solicite al solicitante que documente si una herramienta existente ya cubre el 70% o más de la necesidad.

Construir lo que se puede comprar por $200/mes

El tiempo de ingeniería es costoso. Un ingeniero senior cuesta $150-200/hora. Si existe una herramienta SaaS por $200/mes, la opción de construir necesita entregar al menos $7.200 en valor anual por encima de lo que ofrece la herramienta SaaS solo para equilibrar las primeras 30 horas de desarrollo. Rara vez lo hace.

La excepción: cuando la solución SaaS existente genera un problema de privacidad de datos, cumplimiento o seguridad que las herramientas internas evitan. Ese cálculo es diferente.

Lógica de integración que crea silos de datos

Ampliar una herramienta existente parece de baja fricción hasta que se descubre que la integración crea un flujo de datos que vive en tres sistemas y que solo entiende una persona. Cuando esa persona se va, la integración se rompe y nadie sabe por qué.

Antes de aprobar una integración, documente el flujo de datos, asigne un propietario y confirme que la integración puede reconstruirse solo con la documentación.

Hacer que la decisión sea duradera

El marco de decisión solo funciona si se aplica antes de que el calendario de Demos se llene. La forma práctica de aplicarlo:

  1. Exija un resumen de una página antes de que comience cualquier evaluación de proveedores. El resumen responde: ¿qué problema estamos resolviendo, qué rama del árbol de decisión recorrimos y por qué llegamos a "comprar"?

  2. Incluya al líder de IT o a un responsable de SaaS designado en la Rama 3 en cada ocasión. Ellos conocen el stack. El solicitante no siempre.

  3. Establezca un disparador de revisión para cualquier compra superior a $10.000/año. Al cabo de un año, alguien verifica si la herramienta se está usando, si duplica algo más y si la necesidad original sigue existiendo.

  4. Rastree las herramientas dadas de baja como métrica de éxito. Si solo mide la adquisición de nuevas herramientas, está midiendo solo la mitad del problema.

Cómo medir si el marco está funcionando

Sabrá que el marco de decisión está funcionando cuando:

  • La superposición de herramientas disminuya en la auditoría anual del stack
  • El tiempo de decisión para compras de software se reduzca (porque el marco elimina la deliberación circular)
  • El presupuesto recuperado de herramientas dadas de baja o consolidadas aparezca como una línea en la revisión anual
  • Los tickets de IT relacionados con confusión de herramientas o fricción por herramientas duplicadas disminuyan

El objetivo no es ralentizar las decisiones de software. Es dedicar veinte minutos de reflexión estructurada por adelantado para evitar cuatro meses de limpieza.

Cómo Rework apoya el árbol de decisión en la práctica

El marco solo funciona si el resumen de una página, la auditoría del stack de la Rama 3 y la aprobación del líder de IT ocurren antes del Demo del vendor, y ahí es donde la mayoría de los equipos de mercado medio tienen dificultades. Rework Work Ops (desde $6/usuario/mes) ofrece al responsable de SaaS un único lugar para documentar cada ejecución del árbol de decisión: el enunciado del problema, qué rama produjo la respuesta, los resultados de la auditoría de herramientas existentes y el aprobador, y enrutar todo ello a través de las partes interesadas correctas sin perseguir a nadie por Slack.

Las plantillas de Work Ops permiten estandarizar el resumen de una página para que cada solicitud de nueva herramienta siga la misma estructura, y el enrutamiento del Workflow envía las revisiones de la Rama 3 directamente al líder de IT o al responsable de SaaS designado con una parada obligatoria hasta que den su aprobación. Como Work Ops está junto a Rework CRM/Sales Ops (desde $12/usuario/mes), las decisiones comerciales de herramientas que involucran a los equipos de ingresos reciben la misma revisión estructurada que las herramientas de operaciones, sin Workflow separado, sin herramienta separada. El disparador de revisión a los 12 meses para compras superiores a $10.000/año puede programarse como una tarea recurrente vinculada al registro de decisión original, de modo que nada se renueve automáticamente sin que un ser humano verifique si todavía se está usando.

Más información