Comprar software o construir a medida: la cuenta que casi nadie hace

Elegir entre comprar un software de mercado o construir una herramienta a medida no es una decisión técnica; es una decisión de inversión. Se decide con dos variables: el coste total de propiedad de cada opción a varios años y el grado en que ese proceso te diferencia de verdad. Todo lo demás —qué lenguaje, qué proveedor, qué integraciones— viene después y es secundario.

El problema es que casi nadie hace esa cuenta. Se compara el precio de la licencia con el presupuesto del desarrollo, se elige el número más bajo y se firma. Dos años después aparecen las partidas que no estaban en la hoja de cálculo: personalizaciones, integraciones, formación, un módulo que sube de precio, un proceso que sigue haciéndose en Excel porque la herramienta no lo contempla.

La pregunta suele estar mal planteada

"¿Compramos o desarrollamos?" es una pregunta que llega demasiado pronto. Antes de responderla hace falta saber qué proceso vas a soportar, cómo funciona hoy, qué variantes tiene y qué parte de esas variantes son necesidad real y cuáles son simple costumbre. Sin eso, cualquiera de las dos opciones hereda el desorden actual: la comprada te obligará a forzar el proceso hasta que quepa; la construida congelará en código un flujo que nunca fue diseñado.

La decisión correcta llega después del mapa de proceso, no antes. Es la diferencia entre elegir con criterio y elegir por catálogo.

El error de mercado: comparar precios que no son comparables

El error habitual es enfrentar dos cifras que miden cosas distintas. La licencia de un software de mercado es un precio recurrente y visible. El presupuesto de un desarrollo a medida es un precio de entrega, no de vida útil. Comparar el uno con el otro es como comparar un alquiler mensual con el precio de compra de un piso, ignorando la comunidad, el IBI y la derrama.

De ese error nacen tres decisiones malas muy frecuentes:

• Comprar una suite completa por un proceso que sólo necesitaba una integración entre dos sistemas que ya tienes.
• Desarrollar a medida algo que existe resuelto en el mercado, porque "lo nuestro es especial", cuando lo especial era una costumbre interna que nadie ha cuestionado.
• Comprar la herramienta correcta y no presupuestar la parte cara: la migración de datos, la limpieza previa, la formación y el mantenimiento del año dos en adelante.

En los tres casos el fallo no es tecnológico. Es que la cuenta estaba incompleta.

Las dos variables que deciden de verdad

Si tuvieras que tomar la decisión con dos ejes y nada más, serían estos: cuánto cuesta poseer cada opción durante su vida útil y cuánto te diferencia ese proceso frente a tu competencia. El primero acota lo que puedes gastar; el segundo decide si merece la pena gastarlo en algo propio.

Coste total de propiedad, no precio de entrada

El coste total de propiedad es lo que te cuesta la solución desde que la decides hasta que la jubilas. Conviene calcularlo a cinco años, porque es el horizonte en el que las dos opciones dejan de parecerse. Partidas que deben estar en la hoja de cálculo, en ambas columnas:

• Licencias o cuotas, con su escalado por usuarios, volumen o módulos adicionales.
• Implantación: configuración, parametrización, migración y limpieza de datos.
• Integraciones con lo que ya tienes, y su mantenimiento cuando alguna de las partes cambie de versión.
• Formación inicial y formación de las personas que entren después.
• Soporte, corrección de incidencias y evolución funcional.
• Horas internas: quién administra la herramienta, quién resuelve dudas, quién revisa que los datos entren bien.
• Coste de salida: qué pasa si dentro de tres años quieres cambiar, y en qué formato te llevas tus datos.
• Coste del desajuste: las tareas manuales que seguirás haciendo porque la herramienta no cubre ese caso.

Esa última partida es la más olvidada y a menudo la más cara. Un software que cubre el 80% de tu proceso deja un 20% que alguien sigue resolviendo a mano, y ese trabajo manual tiene un coste recurrente que nadie factura pero todos pagan.

Diferenciación del proceso

La segunda variable es más incómoda: ¿ese proceso es una ventaja competitiva o es simplemente algo que hay que hacer? Contabilizar facturas, gestionar nóminas o firmar documentos no diferencian a nadie. La forma en que configuras un presupuesto complejo, planificas rutas con restricciones propias o gestionas una trazabilidad que tus clientes te exigen, puede ser exactamente lo que te hace ganar contratos.

Para decidirlo, responde con honestidad:

• ¿Un cliente ha elegido alguna vez trabajar contigo por cómo haces esto?
• Si mañana lo hicieras igual que tu competencia, ¿perderías algo medible?
• ¿La particularidad viene de una exigencia real (normativa, cliente, producto) o de una costumbre heredada?
• ¿Cuántas veces has descartado una herramienta de mercado por esa particularidad concreta?
• ¿Ese proceso va a seguir siendo así dentro de tres años, o está cambiando cada trimestre?

Se compra lo que te iguala al mercado. Se construye lo que te separa de él.

Los cuatro escenarios que salen al cruzar las dos variables

Cruza las dos variables y aparecen cuatro situaciones con recomendaciones distintas. No es una fórmula automática, pero ordena la conversación mucho mejor que "¿cuánto cuesta cada opción?".

Proceso estándar y coste de propiedad bajo: compra. Es el caso más común y el más claro. Contabilidad, nóminas, firma electrónica, gestión documental básica. El mercado lo ha resuelto mejor de lo que tú lo resolverías, mantiene el cumplimiento normativo por ti y el coste de cambiar de proveedor es asumible. Aquí construir a medida es casi siempre destruir dinero.

Proceso estándar y coste de propiedad alto: compra, pero renegocia el alcance. Cuando la herramienta estándar sale cara suele ser porque estás comprando una suite entera para usar dos módulos, o porque el precio escala con un volumen que crece. Antes de saltar al desarrollo, revisa si el problema real es de integración entre sistemas y no de funcionalidad. Muchas veces la alternativa barata no es construir: es conectar bien lo que ya pagas.

Proceso diferenciador y coste de propiedad alto: construye. Aquí el desarrollo a medida deja de ser un capricho. Si el proceso te da ventaja, si ninguna herramienta lo cubre sin acrobacias y si el desajuste te está costando horas todos los meses, construir es una inversión defendible. Con una condición: el proceso tiene que estar estabilizado antes de escribir la primera línea de código.

Proceso diferenciador y coste de propiedad bajo: espera y mide. Suena raro, pero pasa: el proceso te diferencia y aun así lo estás resolviendo bien con herramientas sencillas. Si una hoja de cálculo bien gobernada te está funcionando, no hay urgencia. Construye cuando el volumen, el número de personas implicadas o el riesgo de error hagan que esa solución deje de sostenerse.

Cómo hacer la cuenta, paso a paso

Esta es la secuencia que usamos cuando una empresa nos plantea la disyuntiva. No requiere conocimiento técnico: requiere disciplina para no saltarse el primer paso.

1. Documenta el proceso tal y como funciona hoy, con sus excepciones reales y quién interviene en cada paso.
2. Mide la situación de partida: cuántas horas consume, cuántos errores genera, cuánto tarda de principio a fin, cuántas personas son imprescindibles para que salga.
3. Separa lo necesario de lo heredado: qué particularidades responden a una exigencia real y cuáles se pueden eliminar rediseñando el flujo.
4. Comprueba si hace falta software nuevo. A veces el problema es de integración, de reglas o de orden, y se resuelve sin comprar ni construir nada.
5. Si hace falta, define los requisitos mínimos con los que el proceso funciona, no la lista de deseos de todo el mundo.
6. Pide presupuesto de las dos vías con el mismo alcance y el mismo horizonte temporal, incluyendo mantenimiento y evolución.
7. Rellena las dos columnas del coste total de propiedad a cinco años, con las partidas ocultas incluidas.
8. Estima el coste de salida de cada opción: cuánto te costaría cambiar de decisión dentro de tres años.
9. Define la métrica que demostrará que la decisión fue buena, y mídela antes de implantar. Sin punto de partida no hay retorno: hay intuición. El método está en cómo calcular el ROI de una automatización.
10. Decide, escribe por qué decidiste eso y revísalo dentro de un año.

El paso nueve es el que casi todo el mundo se salta y el que más caro sale. Sin una métrica definida antes, la evaluación posterior se convierte en una discusión de percepciones.

Cuándo sí y cuándo no

Compra cuando

• El proceso es estándar y está sujeto a normativa que cambia: que el proveedor cargue con esa actualización.
• Necesitas estar operativo pronto y puedes adaptar tu forma de trabajar a la de la herramienta.
• Hay varios proveedores solventes, lo que te da capacidad de negociación y una salida razonable.
• El equipo interno no puede asumir el mantenimiento de un desarrollo propio.
• El volumen actual no justifica un proyecto de construcción.

Construye cuando

• El proceso te diferencia y ninguna herramienta lo cubre sin trabajo manual permanente alrededor.
• El coste de las licencias escala con un volumen que va a crecer, y ese escalado es insostenible a tres o cinco años.
• Ya has rediseñado y estabilizado el proceso: sabes qué entra, quién decide, qué sale y en qué formato.
• Tienes claro quién va a mantener y evolucionar lo construido, con presupuesto asignado para ello.
• La integración con tus sistemas actuales es tan específica que cualquier producto de mercado requeriría un desarrollo similar por encima.

No hagas ninguna de las dos cuando

• El proceso cambia cada pocos meses porque todavía no está definido: congélalo en código y pagarás dos veces.
• Los datos que alimentarían la herramienta están duplicados, incompletos o sin dueño.
• Nadie es responsable del proceso de punta a punta, así que nadie podrá adoptar ni defender la solución.
• El dolor real es de coordinación entre áreas, no de falta de software.

Los errores que destruyen el retorno de cualquiera de las dos opciones

Da igual lo que elijas: hay cuatro formas seguras de que la inversión no rinda.

• Automatizar o comprar sin haber eliminado antes los pasos que sobran. Mecanizar un flujo malo sólo produce desperdicio más rápido.
• Presupuestar la implantación y no el mantenimiento. El proyecto no termina en la puesta en marcha: es donde empieza a costar.
• Personalizar tanto un producto de mercado que pierdes la ventaja de comprarlo, porque cada actualización del proveedor te rompe algo.
• Construir a medida sin documentación y sin más de una persona que entienda el sistema. Lo que sólo sabe uno, no escala.

La vía intermedia que casi nunca se plantea

La decisión rara vez es binaria para toda la empresa. Lo razonable en la mayoría de las pymes es comprar la base y construir el borde: un producto estándar para lo que te iguala al mercado (contabilidad, gestión documental, CRM comercial) y desarrollo propio sólo en la capa donde tu forma de trabajar aporta valor, conectada con lo anterior. Así el coste de propiedad se reparte y no dependes de un único proveedor para todo.

Esa es también la conversación honesta cuando alguien nos pide directamente un desarrollo a medida: la primera pregunta no es qué construimos, sino qué parte no hace falta construir. Y la segunda es quién lo va a mantener cuando la novedad pase.

El precio de entrada te dice lo que pagas hoy. El coste de propiedad te dice si vas a poder sostenerlo.

Si estás en esa disyuntiva ahora mismo y no puedes rellenar las dos columnas de coste a cinco años, todavía no estás en fase de decidir: estás en fase de medir. Y esa medición, hecha bien, suele costar menos que la decisión equivocada. Es la misma diferencia que separa digitalizar por moda de digitalizar con retorno.