¿Cuándo conviene software a la medida y cuándo uno de paquete?
La regla corta: de paquete cuando tu proceso es igual al de todos, a la medida cuando tu proceso es la razón por la que ganas dinero. Facturar, timbrar nómina o llevar contabilidad es igual en todas partes y desarrollarlo es tirar dinero. En cambio, la forma en que cotizas, surtes o atiendes a tus clientes suele ser lo que te distingue, y forzarla dentro de un producto genérico te obliga a operar como tu competencia. Antes de decidir conviene agotar dos opciones intermedias que casi nadie considera: configurar a fondo un producto estándar, y conectar entre sí los que ya tienes.
¿Cuál sale más barato a largo plazo?
Depende de cuánto dure el sistema y de cuánto cuesten las excepciones. El de paquete tiene un costo bajo y constante: la suscripción por usuario, año tras año, que crece cuando crece el equipo. El desarrollo a la medida tiene un costo alto al principio y luego uno de mantenimiento que suele rondar entre el 15 % y el 20 % anual de lo invertido. Con equipos pequeños el de paquete casi siempre gana. A partir de cierto número de usuarios, o cuando el trabajo manual que impone el producto estándar equivale a varios sueldos, la cuenta se invierte. El error es comparar solo el precio de licencia contra el precio del proyecto, olvidando las horas que la empresa gasta hoy en tapar los huecos.
¿Qué costos se olvidan al comparar las dos opciones?
Tres, y siempre los mismos. Primero, el trabajo manual que impone un producto que no encaja: si tres personas dedican cinco horas semanales a mover datos entre sistemas, eso son sesenta horas al mes que nadie contabiliza como costo del software. Segundo, el mantenimiento del desarrollo a la medida, que no es opcional: un sistema sin quien lo actualice acumula deuda técnica hasta volverse imposible de tocar. Tercero, el costo de salida: migrar años de configuración o de datos propios cuesta mucho más de lo que cualquiera presupuesta.
¿Se puede empezar con un producto de paquete y migrar después?
Sí, y suele ser lo más sensato. Empezar con un producto estándar deja aprender cómo funciona el proceso de verdad antes de congelarlo en código, que es el error más caro del desarrollo a la medida: construir el proceso que alguien describió en una junta en vez del que realmente ocurre. La condición es cuidar los datos desde el principio. Si el producto permite exportarlos completos y en un formato razonable, la migración es trabajo; si no, es un rescate.
¿Qué pasa si el desarrollador desaparece?
Es el riesgo real del desarrollo a la medida, y se cubre con tres cosas que hay que exigir por contrato desde el primer día: que el código y su repositorio sean tuyos, que exista documentación suficiente para que otro equipo lo retome, y que el sistema corra en infraestructura a tu nombre y no a nombre del proveedor. Sin eso no contrataste un sistema, rentaste una dependencia. Con eso, cambiar de proveedor es incómodo pero no catastrófico.
¿Cómo se decide sin corazonadas?
Escribiendo el proceso completo antes de mirar opciones, incluidas las excepciones. Después, contando: cuántas veces ocurre cada excepción, cuánto tiempo cuesta resolverla y qué pasa cuando alguien se equivoca. Casi siempre, esa cuenta decide sola. Si las excepciones son raras y baratas, gana el producto de paquete. Si son frecuentes y caras, o si son justamente lo que te distingue de la competencia, gana construir. El ejercicio incómodo es hacer esa lista antes de haber elegido, no después de haberse enamorado de una opción.