Desarrollar o comprar software empresarial: un marco de decisión

La pregunta equivocada, planteada cada año

Toda organización acaba celebrando esa reunión: ¿construimos este sistema o lo compramos? El debate suele plantearse como una comparación de costes — la oferta de un proveedor frente a una estimación interna — y suele decidirse con las pruebas equivocadas. El precio de compra y el coste inicial de desarrollo son las dos cifras más pequeñas de la ecuación. La decisión que importa es la de la propiedad: quién controla el ritmo de cambio de una capacidad de la que depende su negocio, y cuánto cuesta ese control a lo largo de una década.

Este artículo expone cómo llevamos a cabo ese análisis con los CTO: un coste total de propiedad calculado con honestidad, la deuda de integración valorada antes de la firma y un test de diferenciación que muestra dónde compensa realmente la ingeniería a medida.

El coste total de propiedad, calculado con honestidad

Ambos bandos maquillan sus propias cifras. Los equipos internos estiman el desarrollo y omiten los años de mantenimiento; los proveedores citan la licencia del primer año y omiten todo lo que viene después. Un modelo de TCO honesto valora el ciclo de vida completo en ambos lados:

• Desarrollar: la entrega inicial más un 15–20 % del coste de desarrollo al año en mantenimiento, actualización de dependencias y trabajo de seguridad — durante toda la vida del sistema
• Desarrollar: el equipo. Un sistema construido por un equipo de proyecto y luego dejado huérfano se degrada más rápido que cualquier solución comprada
• Comprar: precios por usuario que escalan con su plantilla, no con su valor — recalcule el contrato con el triple de las licencias actuales
• Comprar: los costes de personalización y consultoría, que en las grandes plataformas superan con regularidad a la propia licencia
• En ambos casos: el coste de salida. Migrar fuera de cualquier sistema en el quinto año es un proyecto que nadie presupuesta en el primero

Ejecute el modelo a siete o diez años, no a tres. La mayoría de los sistemas comprados parecen baratos a tres años y caros a diez; en los sistemas desarrollados ocurre lo contrario. El horizonte que elija es la decisión.

La deuda de integración: la partida oculta

Ningún sistema empresarial funciona solo. Cada compra añade un nodo a su grafo de integraciones, y es en las aristas donde mueren los presupuestos: identidad, datos maestros, canalizaciones de informes y las sincronizaciones punto a punto que se acumulan alrededor de cualquier producto comprado. Las plataformas compradas se integran en los términos del proveedor — sus límites de API, su cadencia de actualizaciones, su modelo de datos. Cada personalización que usted añade le acerca a lo peor de ambos mundos: costes de mantenimiento propios del desarrollo con el control propio de la compra.

Valore el trabajo de integración de forma explícita antes de la decisión, no después. Si conectar una plataforma comprada a su panorama de sistemas cuesta más de la mitad de construir la capacidad desde cero, la opción de compra nunca fue realmente una compra.

El test de diferenciación

El filtro más potente no es financiero. Pregúntese si la capacidad le diferencia en su mercado. Las capacidades commodity — nóminas, ticketing, correo electrónico, gastos de empleado — deben comprarse sin ceremonias; nadie elige a un proveedor por su herramienta de gastos. Las capacidades que aparecen en su discurso comercial, en sus márgenes o en su experiencia de cliente merecen ingeniería a medida, porque ser dueño de su ritmo de cambio es precisamente la cuestión.

• Compre donde baste la paridad — nóminas, RR. HH., ticketing, gestión documental
• Desarrolle donde vive la ventaja — motores de precios, flujos orientados al cliente, el proceso que solo usted ejecuta
• Cuestione la zona gris: si está escribiendo personalizaciones pesadas sobre un producto comprado, el mercado le está diciendo que esa capacidad es núcleo de su negocio

Estrategias híbridas que se sostienen

En la práctica, la respuesta madura rara vez es pura. Los patrones híbridos que vemos triunfar comparten una propiedad: una costura limpia entre lo que se posee y lo que se alquila.

• Compre el motor, desarrolle la experiencia — un sistema de registro comprado detrás de una interfaz a medida que sus equipos y clientes usan de verdad
• Desarrolle el núcleo, compre los bordes — lógica de dominio a medida rodeada de servicios estándar para identidad, mensajería y analítica
• Envuelva antes de sustituir — una capa de API propia sobre un sistema heredado o de proveedor, para poder reemplazarlo más adelante sin tocar a sus consumidores

El patrón que fracasa es el fork personalizado: modificar una plataforma de proveedor tan a fondo que cada actualización se convierte en una migración. Combina el perfil de costes del desarrollo con las restricciones de la compra.

Un marco que cabe en una sola reunión

Antes de la próxima discusión sobre desarrollar o comprar, ponga cinco preguntas sobre la mesa:

• ¿Nos diferencia esta capacidad, o solo necesitamos paridad con los demás?
• ¿Cambiarán nuestros requisitos más rápido que la hoja de ruta de cualquier proveedor?
• ¿Cómo es el TCO honesto a diez años — mantenimiento, licencias, personalización, integración, salida?
• ¿Podemos dotar y retener un equipo durante la vida del sistema, no solo durante la construcción?
• ¿Cuánto cuesta marcharse — en el mes 36, en cualquiera de los dos caminos?

Respuestas que hablan de diferenciación, cambio rápido y equipo sostenible apuntan a desarrollar. Paridad, estabilidad e integración ligera apuntan a comprar. Todo lo que queda en medio apunta a un híbrido con la costura trazada deliberadamente. Los sistemas empresariales son una parte del trabajo de ingeniería que hacemos en Vendenis — y cuando el análisis dice desarrollar, o dice comprar e integrar, ayudamos a las organizaciones a materializar la respuesta en ambos casos.