logo

Build, buy o integrate: la decisión que casi nadie plantea bien

18 agosto 2026

La decisión entre construir software a medida, comprar una solución estándar o integrar lo que ya tienes no se resuelve comparando funcionalidades ni precios: se resuelve identificando qué parte de tu operación es realmente distinta de la de tus competidores. Lo que te diferencia se construye. Lo que no te diferencia se compra. Y lo que ya funciona se integra en lugar de sustituirse.

El error más caro no es elegir mal entre las tres opciones. Es no darse cuenta de que existe la tercera.

¿Por qué la mayoría de estas decisiones se plantean mal?

Porque llegan al comité formuladas como una elección entre dos productos, cuando en realidad son una pregunta sobre el modelo operativo de la empresa.

Cuando un director de operaciones dice «necesitamos un CRM», ya ha tomado implícitamente tres decisiones: que el problema es de herramienta, que la herramienta debe ser nueva y que la categoría correcta es CRM. Las tres pueden ser falsas. El problema puede ser que la información del cliente vive en cuatro sitios; la herramienta puede existir ya y estar infrautilizada; y la categoría puede ser en realidad un problema de integración entre el ERP y el sistema de facturación.

Hay un dato de mercado que sostiene esto. Reuters analizó en agosto de 2026 por qué compañías europeas establecidas —SAP, Capgemini, Sopra Steria, OVHcloud— han emergido como ganadoras inesperadas del ciclo de la IA: el reto de las empresas ya no es elegir el mejor modelo, sino hacer que funcione con el software, los datos y los procesos que ya tienen. El valor se ha desplazado de la adquisición a la integración.

El marco de decisión: tres preguntas antes de cualquier demo

Pregunta

Si la respuesta es sí

Si la respuesta es no

¿Este proceso es una ventaja competitiva o solo un requisito para operar?

Construir a medida

Comprar estándar

¿Existe una solución estándar que cubra el 80% sin forzar tu proceso?

Comprar e integrar

Construir o integrar lo existente

¿Los sistemas que ya tienes cubren la función pero no se hablan entre sí?

Integrar

Evaluar build o buy

La primera pregunta es la que más se salta. Una gestoría no necesita un software de contabilidad a medida: la contabilidad es un requisito regulado e idéntico para todos. Pero una naviera sí puede necesitar un CRM a medida, porque la operativa de shipping —rutas, documentación aduanera, escalas, incidencias— no existe en ningún CRM del mercado. Esa es exactamente la razón por la que construimos NaviCRM en lugar de configurar un producto estándar, y por la que el resultado fue una reducción del 60% del tiempo de gestión: no había versión configurable de ese proceso.

La segunda pregunta tiene una trampa habitual. El «80% cubierto» se mide en funcionalidades durante la demo, pero se paga en el 20% restante durante los tres años siguientes. Ese 20% es donde vive tu diferencia, y es justamente lo que la herramienta estándar te obligará a abandonar o a resolver con desarrollos paralelos, integraciones frágiles y hojas de cálculo. Antes de aceptar un 80%, conviene identificar qué hay exactamente en el 20%.

La tercera pregunta es la que ahorra más dinero y la que menos se hace. En muchas empresas la funcionalidad ya existe repartida entre sistemas que no comparten información. El proyecto correcto no es comprar un sistema más: es construir la capa de integración que hace que los existentes funcionen como uno. Cuesta una fracción, no requiere migración de datos masiva y no obliga a reentrenar a nadie.

Las señales de que "comprar" es la respuesta correcta

Comprar estándar es la decisión acertada más veces de lo que a una empresa de desarrollo le conviene admitir. Estas son las señales claras:

  • El proceso está regulado o estandarizado por normativa o por práctica sectorial (contabilidad, nóminas, facturación electrónica).
  • La función es necesaria pero no diferencial: nadie ha ganado un cliente por tener mejor gestión de vacaciones.
  • El coste de mantener esa capacidad al día —cambios normativos incluidos— es alto y recurrente.
  • Existe un mercado maduro con varios proveedores solventes, lo que limita el riesgo de dependencia.

Si se cumplen las cuatro, construir a medida es casi siempre destruir valor.

Las señales de que "construir" es la respuesta correcta

  • El proceso es la razón por la que tus clientes te eligen, o el motivo por el que operas con mejor margen que la competencia.
  • Ninguna solución del mercado lo contempla sin obligarte a cambiar tu forma de trabajar en lo que precisamente te hace competitivo.
  • Estás pagando licencias por usuario por un sistema del que usas una fracción, y ese coste crece con tu plantilla.
  • Necesitas propiedad del dato y del código por razones de soberanía, compliance o valoración de la compañía.
  • El proceso va a cambiar varias veces en los próximos años y necesitas poder cambiarlo sin depender del roadmap de un tercero.

Este último punto es el más subestimado. Comprar software es delegar el ritmo de evolución de una parte de tu negocio en las prioridades comerciales de otra empresa.

Las señales de que "integrar" es la respuesta correcta

  • Los datos que necesitas ya existen dentro de la organización, pero en sistemas distintos.
  • Los equipos hacen trabajo de copiar y pegar entre herramientas. Cada copia manual es una integración que falta.
  • Las herramientas actuales funcionan bien por separado y nadie se queja de ellas individualmente.
  • El problema se describe como «no tenemos visibilidad» más que como «nos falta una funcionalidad».

La integración es la opción menos vistosa de las tres y la que más retorno produce por euro invertido, precisamente porque no requiere sustituir nada que ya funcione. Lo hemos desarrollado con más detalle en nuestro análisis sobre ERP, CRM e IA como nueva arquitectura empresarial

¿Y dónde encaja la IA en esta decisión?

En ninguna de las tres columnas, y esa es la respuesta que conviene interiorizar. La IA no es una cuarta opción: es una capacidad que puede añadirse a cualquiera de las tres.

Gartner publicó en junio de 2025 una previsión que conviene tener presente en cualquier proceso de compra: más del 40% de los proyectos de IA agéntica serán cancelados antes de finales de 2027, por costes crecientes, valor de negocio poco claro o controles de riesgo inadecuados. En el mismo análisis, Gartner estimaba que de los miles de proveedores que se presentan como especialistas en agentes, solo alrededor de 130 lo son realmente. Al fenómeno lo llamaron *agent washing*.

La implicación práctica para un comité de compras es directa: cuando una propuesta se presenta como «solución de IA», hay que devolverla a la pregunta original. ¿Qué proceso resuelve? ¿Es un proceso diferencial o estándar? ¿Los datos que necesita existen y son fiables? ¿Quién responde cuando se equivoque?

Si esas cuatro preguntas no tienen respuesta, no estás evaluando una solución. Estás evaluando una demo.

Cómo estructurar la decisión sin quedar atrapado en el proceso comercial

El problema estructural de estas decisiones es que la información la aportan los propios candidatos. Cada proveedor define el problema de la forma en que su producto es la solución.

Un proceso limpio tiene cuatro pasos:

  1. Definir el proceso antes de mirar herramientas. Qué decisiones se toman, con qué datos, quién responde, qué excepciones existen. Este documento es el que hace comparables las propuestas.
  2. Escribir los criterios de evaluación antes de ver la primera demo. Y ponderarlos. Si los criterios se escriben después, se escriben para justificar la preferencia ya formada.
  3. Evaluar el 20% no cubierto, no el 80% cubierto. Todas las herramientas maduras cubren el núcleo. La diferencia está en los bordes.
  4. Incluir el coste de salida en la comparación. Qué pasa dentro de cuatro años si esta decisión resulta equivocada.

Cuando participamos en estos procesos lo hacemos como parte independiente: redactamos el RFP, evaluamos las ofertas y negociamos el contrato con criterio técnico, sin presentarnos como candidatos a la licitación que estamos evaluando. Es la única forma en que el consejo puede tratar la recomendación como un criterio y no como una propuesta comercial disfrazada.

La pregunta que resume las tres opciones

Antes de la próxima decisión de compra de software, conviene responder una sola cosa: ¿esta capacidad es una razón por la que un cliente nos elige, o simplemente algo que necesitamos para operar?

Lo primero se construye y se posee. Lo segundo se compra y se integra. Confundir las dos categorías es el origen de la mayoría de los proyectos de software que cuestan el doble y sirven la mitad.

Preguntas frecuentes

¿Cuándo conviene desarrollar software a medida en lugar de comprar uno estándar?

Cuando el proceso es una ventaja competitiva real, cuando ninguna solución del mercado lo cubre sin obligarte a cambiar la forma de trabajar que te hace competitivo, cuando el coste de licencias por usuario crece con la plantilla, o cuando necesitas propiedad del código y del dato por compliance o valoración.

Consiste en conectar los sistemas que ya tienes en lugar de sustituirlos. Se olvida porque no la propone ningún vendedor de software: no hay licencia que vender. Suele ser la opción con mayor retorno por euro invertido cuando los datos ya existen dentro de la organización pero están repartidos.

Evaluando el 20% que no cubre, no el 80% que sí. Todas las herramientas maduras cubren el núcleo funcional; la diferencia está en los bordes, y esos bordes suelen coincidir con lo que diferencia a tu empresa. Ese 20% se paga durante los años siguientes en desarrollos paralelos y hojas de cálculo.

El estándar tiene menor coste inicial y coste recurrente por usuario que crece con la plantilla; el desarrollo a medida tiene mayor coste inicial y sin licencias por usuario. El punto de equilibrio depende del número de usuarios, de la vida útil prevista y de cuánto desarrollo paralelo exigiría la solución estándar.

Definiendo el proceso y los criterios de evaluación ponderados antes de ver la primera demo, e incorporando una parte técnica independiente que no compita en la licitación. Si los criterios se escriben después de las demos, se escriben para justificar una preferencia ya formada.

En ninguna de las tres: la IA es una capacidad que se añade a cualquiera de las opciones, no una cuarta alternativa. Ante una propuesta presentada como «solución de IA», conviene devolverla a las preguntas de origen: qué proceso resuelve, si ese proceso es diferencial, si los datos existen y quién responde de los errores.

 

¿Tienes una decisión de compra de software encima de la mesa? Podemos redactar el RFP, evaluar las ofertas y negociar el contrato con criterio técnico independiente — sin presentarnos como candidatos. Dos horas de análisis de tu caso, sin compromiso. Hablemos →

Profesional TI evaluando opciones Build, Buy o Integrate para una empresa