¿Comprar un sistema o desarrollarlo a medida? El marco para decidir

«¿Compramos un sistema o lo mandamos a hacer?» es una de las decisiones tecnológicas que más dinero mueve y que más se toma por intuición. Este artículo propone un marco para resolverla con criterios, y dice también cuándo desarrollar a medida es la peor opción — que ocurre más de lo que a un proveedor de desarrollo le conviene admitir.

La pregunta que hay que hacerse primero

No es «¿cuánto cuesta cada opción?». Es ¿esto que quiero automatizar es lo que me diferencia de mi competencia?

Si la respuesta es no —y para la mayoría de los procesos lo es— probablemente exista un producto que ya lo resuelve, con años de correcciones encima y un precio que ningún desarrollo a medida va a igualar.

Si la respuesta es sí, la conversación cambia: ahí el software no es un gasto administrativo, es la forma en que su empresa hace lo que sabe hacer.

Los cinco criterios

1. Diferenciación

Contabilidad, remuneraciones, facturación electrónica: son obligaciones legales idénticas para todos. Comprar. Su proceso particular de cotización, la lógica con que asigna recursos a obra, la forma en que calcula un margen: eso es suyo. Ahí el producto estándar le obliga a trabajar como trabajan los demás.

2. Ajuste real, no de demo

Un producto que cubre el 80 % suele ser mejor negocio que un desarrollo que cubre el 100 %. Pero el 20 % restante importa: si es papeleo menor, se absorbe; si es el núcleo de la operación, ese 80 % no sirve.

La forma de saberlo no es la demostración comercial. Es coger los tres casos más complicados del mes pasado y pedir que los resuelvan delante de usted, con sus datos.

3. Volumen y ciclo de vida

Una licencia por usuario que sale barata con diez personas puede ser cara con ochenta. Y un desarrollo a medida tiene un costo inicial alto y uno de mantención que no desaparece nunca. Compare a cinco años, no a uno.

4. Integraciones

Es donde se rompen más proyectos. Si el sistema debe hablar con su ERP, su facturación y su banco, pregunte por la vía de integración antes de decidir. Un producto que no expone una API obliga a integraciones frágiles que se caen con cada actualización suya.

5. Quién lo va a sostener

Un producto lo mantiene su fabricante. Un desarrollo a medida lo mantiene quien usted decida — y si no decide, no lo mantiene nadie. Este criterio elimina más proyectos a medida que los otros cuatro juntos.

Cuándo NO desarrollar a medida

Cuatro escenarios donde la respuesta correcta es comprar, aunque duela:

• Procesos regulados que cambian por ley. Facturación, libros contables, previsional. Cada cambio normativo obligaría a pagar una modificación; el fabricante del producto lo reparte entre miles de clientes.
• Cuando nadie puede dedicarle tiempo a definirlo. Un desarrollo a medida necesita alguien del negocio disponible para decidir. Sin eso, se construye lo que el proveedor imagina.
• Cuando se quiere «lo mismo que X pero más barato». Replicar un producto maduro sale más caro que comprarlo, siempre.
• Cuando la urgencia es de semanas. Un producto se configura; un desarrollo se construye.

Cuándo sí conviene

• El proceso es su ventaja competitiva y ningún producto lo refleja sin forzarlo.
• Ya paga licencias caras por usar el 15 % de una suite grande.
• Tiene varios sistemas que no se hablan y el trabajo real es la integración.
• El producto disponible le obliga a cambiar cómo opera, y ese cómo es el que funciona.

La tercera opción que casi nadie plantea

La decisión rara vez es binaria. La combinación que mejor rinde en empresas medianas:

Comprar la base, desarrollar la diferencia. Un ERP estándar para lo que es igual en todas las empresas, y desarrollo a medida para las dos o tres piezas donde su operación es distinta — conectadas por integración.

Cuesta menos que un desarrollo completo, evita pagar por módulos que nadie usará, y deja el esfuerzo donde produce ventaja. La condición es que el producto base permita integrarse de verdad, lo que devuelve al criterio 4.

Antes de pedir cotizaciones

Tenga escritas tres cosas. Sin ellas, cualquier presupuesto que reciba es una estimación sobre un malentendido:

1. Qué problema resuelve, en lenguaje de negocio y no de sistemas. «Reducir el tiempo de cotización de dos días a dos horas», no «un módulo de cotizaciones».
2. Los tres casos más difíciles que debe manejar. Los casos fáciles los resuelve cualquiera.
3. Con qué debe integrarse y quién controla esos sistemas.

Si un proveedor le entrega precio sin preguntar por los tres, desconfíe: está cotizando lo que suele hacer, no lo que usted necesita.

Y la pregunta del código

Si termina desarrollando, fije desde el contrato de quién es el resultado. Por defecto, y salvo pacto expreso, el código y la documentación pueden no ser suyos — y eso se descubre el día que quiere cambiar de proveedor.

Es una cláusula de una línea que se negocia antes, nunca después. Está entre las que recomendamos revisar en la guía de outsourcing informático.

En GLTS partimos por el diagnóstico: si lo que necesita ya existe en el mercado, se lo decimos. Puede ver cómo trabajamos el desarrollo de software a medida —el código y la documentación quedan en su empresa— o pedir una asesoría informática para resolver primero esta decisión.