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.
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.
|
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.
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:
Si se cumplen las cuatro, construir a medida es casi siempre destruir valor.
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.
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
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.
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:
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.
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.
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 → |