Software a medida o de catálogo: cómo decidir

«¿Lo hacemos a la medida o compramos algo ya hecho?» se discute casi siempre con opiniones. Es mejor discutirla con criterios, porque los dos errores cuestan: pagar durante años por un paquete que no encaja, o construir desde cero algo que ya existía.

No hay una respuesta universal. Sí hay cinco preguntas que ordenan la decisión, y una forma de contestarlas en una semana sin comprometer presupuesto.

1. ¿Es lo que te diferencia?

Hay procesos que todas las empresas hacen más o menos igual: contabilidad, nómina, facturación, correo. Ahí un paquete maduro casi siempre gana, porque millones de usuarios ya encontraron los errores que tú todavía no has visto.

Y hay procesos que son la manera en que tu empresa compite: cómo cotizas, cómo programas la producción, cómo atiendes a un cliente difícil. Si ese proceso es parte de tu ventaja, forzarlo a caber en un producto genérico significa parecerte a tu competencia.

Prueba rápida: si un competidor pudiera comprar el mismo software mañana, ¿perderías algo? Si la respuesta es no, compra. Si la respuesta es «sí, perdería justo lo que nos distingue», empieza a considerar construir.

2. Cuánto vas a configurar y cuánto a parchar

Configurar es usar lo que el paquete ya permite: campos, reglas, reportes. Parchar es pedirle al proveedor, o a un tercero, que cambie el producto para que haga algo que no hace. La primera es barata y se actualiza sola; la segunda se paga dos veces: al construirla y cada vez que el paquete se actualiza y el parche se rompe.

Cómo medirlo: lista los requisitos imprescindibles y marca cuáles el paquete cubre tal cual, cuáles cubre configurando y cuáles exigen modificarlo. Si más de un puñado cae en la tercera categoría, el paquete ya no es «de catálogo»: es un desarrollo a medida disfrazado.

3. El costo total a cinco años

Comparar el precio de hoy es la trampa más común. Un paquete suele cobrar por usuario o por módulo, y esa cifra crece con la empresa. Un desarrollo a medida cuesta más al inicio, pero no cobra por usuario, y es tuyo.

Para compararlos con justicia, suma en ambos casos, a cinco años:

• Licencias o suscripciones, con el crecimiento de usuarios que esperas.
• Implementación, migración de datos y capacitación.
• Integraciones con los sistemas que ya tienes.
• Mantenimiento, soporte y actualizaciones (en el caso de lo construido, también).
• El costo de cambiar de proveedor si hace falta.

Ninguna de esas cifras será exacta. Pero pasar de «este cuesta menos» a «este cuesta entre tanto y tanto en cinco años, por estas razones» ya mejora la conversación.

4. Las integraciones

Un sistema que no habla con los demás crea trabajo manual: alguien exporta, pega y concilia. Antes de decidir, pregunta cómo se conectaría cada opción con tu ERP, tu facturación, tus bancos y tus hojas de cálculo.

Los paquetes grandes suelen traer conectores para lo más común; para lo demás, la integración se vuelve un proyecto aparte. Un desarrollo a medida puede nacer integrado, pero esa integración también hay que construirla y mantenerla. En ambos casos, conviene presupuestarla desde el principio.

5. El riesgo y la dependencia

Todo camino te hace depender de alguien. Con un paquete dependes de que el fabricante siga existiendo, mantenga el producto y no cambie las condiciones. Con un desarrollo a medida dependes de quien lo construyó, salvo que el contrato proteja lo esencial.

Lo que debería quedar por escrito en un desarrollo a medida:

• Que el código y los derechos patrimoniales son tuyos.
• Que el repositorio vive en una cuenta de tu organización desde el primer día.
• Que existe documentación suficiente para que otro equipo pueda continuar.
• Qué pasa si la relación termina: entrega de accesos, documentación y conocimiento.

El camino intermedio

La decisión rara vez es todo o nada. Con frecuencia lo más sensato es comprar el paquete para lo genérico y construir solo lo que lo diferencia, conectado al paquete mediante integraciones. Así se conserva el valor de lo maduro y se invierte únicamente donde importa.

También sirve empezar pequeño: construir primero el módulo que más duele, con un alcance acotado y una forma de medir si funcionó, antes de comprometerse con un sistema completo.

Cómo decidirlo en una semana

1. Día 1: lista los requisitos y sepáralos en imprescindibles y deseables. Pide a quienes operan el proceso que los revisen.
2. Días 2 y 3: prueba dos o tres paquetes con casos reales de tu operación, no con los ejemplos de la demostración.
3. Día 4: marca qué cubre cada uno tal cual, configurando o modificando.
4. Día 5: estima el costo a cinco años de la mejor opción de paquete y de construir solo lo imprescindible.

Con esas cifras, la decisión deja de ser una discusión de opiniones. Y si ninguna opción convence, ya sabes qué preguntarle a quien te proponga una solución.

Cuándo no construir

• El proceso es genérico y un paquete maduro lo cubre sin parches.
• No hay nadie en tu empresa que pueda decidir con autoridad cómo debe funcionar el sistema.
• Necesitas algo funcionando en semanas y no hay margen para descubrir requisitos.
• No tienes cómo mantenerlo: un sistema sin mantenimiento se vuelve un problema en dos años.