Cualquier financiera, SGR o terminal de planes de ahorro que crece llega al mismo cuello de botella: necesita un sistema que acompañe cómo trabaja. No un Excel gigante ni un módulo prestado, sino una herramienta que entienda su proceso —cómo se carga una suscripción, cómo se arma un legajo, qué se verifica antes de aprobar—. Y ahí aparece la pregunta cara: ¿lo desarrollo o lo compro?
Las dos respuestas clásicas tienen problemas conocidos. Desarrollar a medida da exactamente lo que necesitás, pero cuesta meses, plata y un equipo de IT que sostener. Comprar un enlatado es rápido y barato al principio, pero obliga a operar como el software quiere. Hace tiempo que el mundo del BPO viene puliendo una tercera opción que esquiva las dos trampas: el software a medida incluido en el servicio. Vale la pena entender cómo funciona antes de firmar cualquier desarrollo.
Desarrollar o comprar: por qué ninguna opción cierra del todo
Desarrollar tu propio sistema suena ideal hasta que aparece la factura completa. No es solo el costo inicial: es el equipo que hay que contratar o tercerizar, el mantenimiento que no termina nunca, las correcciones, y el detalle más caro de todos —que el día que el desarrollo está listo, el proceso ya cambió—. El software propio envejece, y mantenerlo vivo es un costo fijo permanente que casi nunca entra en el presupuesto original.
Comprar un enlatado evita el desarrollo, pero traslada el problema a la operación de todos los días. El software estándar está pensado para un promedio que no sos vos: falta un campo clave, sobran tres pantallas y no contempla la excepción que el negocio tiene cada semana. Se termina adaptando la operatoria al software en lugar de al revés, y cada parche cuesta tiempo y errores. Es la misma trampa de mirar el costo visible y no el real que aparece en costos fijos vs. variables en el back-office: lo barato de entrada puede salir carísimo a fin de mes.
El costo invisible de operar con una herramienta que no encaja
Hay un costo que ninguna cotización muestra: el que se paga, mes a mes, cuando el sistema no acompaña el proceso. Son los datos que se cargan dos veces, el export a Excel para tapar lo que el software no hace, las pantallas que nadie usa y los pasos manuales inventados para sortear un límite del programa. Sumados, esos minutos se vuelven horas, y esas horas, gente entera dedicada a pelear con la herramienta en lugar de operar.
Cuando ese costo se mide —cosa que casi nunca se hace— suele ser más grande que la licencia o que la cuota del desarrollo. Es el argumento más fuerte a favor de tener un sistema que se amolde al proceso: no por capricho técnico, sino porque la fricción diaria se paga aunque no figure en ninguna planilla.
La tercera vía: software a medida incluido en el servicio
El modelo es distinto de raíz. En lugar de comprar un sistema o mandarlo a desarrollar, la herramienta la aporta y la construye quien va a operar el proceso —el proveedor de BPO— y su costo va dentro del servicio. No hay una línea de "desarrollo" en el presupuesto ni un área de IT que montar: se paga por el resultado operativo, y el software viene incluido.
El cambio importante no es contable, es de fondo: el que desarrolla es el mismo que opera. La herramienta nace pegada a la realidad del proceso, no a un documento de requerimientos que alguien interpretó de memoria en una reunión. Quien la provee tiene un incentivo directo en que sea buena, porque con ese mismo sistema produce todos los días. Y como el software sirve a varias operaciones parecidas, el costo de construirlo y mantenerlo se reparte en vez de caer entero sobre un solo cliente.
Por qué rinde más que un enlatado
Un sistema hecho a la medida del proceso elimina los pasos que un software genérico obliga a inventar. Desaparecen las recargas dobles, los exports para tapar agujeros y las pantallas muertas. El equipo deja de pelear con la herramienta y se concentra en lo que aporta criterio. El efecto es concreto: menos errores, tiempos de respuesta más cortos y más volumen procesado con la misma gente. En operaciones que viven de procesar legajos o solicitudes, eso es ganar capacidad sin sumar headcount.
Las operaciones que más rinden no son las que compraron el mejor software del mercado: son las que tienen el software hecho a su proceso. La diferencia no está en la tecnología, está en el encaje. Un sistema correcto que calza perfecto le gana siempre a uno brillante que obliga a torcer la operación.
Un sistema que no envejece: mejora continua e IA
Un desarrollo a medida tradicional tiene un problema silencioso: nace y envejece. El día que se entrega es el mejor que va a estar, y cada mejora posterior es un proyecto nuevo que hay que aprobar y pagar. Con el software incluido en el servicio pasa lo contrario: la plataforma se mantiene viva. Las mejoras —funciones nuevas, ajustes de usabilidad, automatizaciones— llegan a la operación como parte del servicio, sin un proyecto separado cada vez.
Ahí es donde la inteligencia artificial entra de forma sana: como habilitador, no como bandera. La lectura automática de documentos con OCR, las validaciones asistidas o un asistente que responde y escala tienen sentido cuando el proceso los necesita —no para poder decir que "se usa IA"—. En un esquema de mejora continua, esas incorporaciones entran a una operación que ya está andando, sin frenarla. El sistema del año que viene es mejor que el de hoy, y no costó un proyecto aparte.
¿Y el control? Datos, trazabilidad y lock-in
La objeción es directa y correcta: si el software es del proveedor, ¿no se queda uno atado? La respuesta depende de cómo esté armado el acuerdo. En un esquema serio, los datos son del cliente y se exportan cuando se piden; cada operación queda registrada y es auditable; y el proceso se ve en tiempo real, no es una caja negra. Delegar la herramienta no es lo mismo que perder el gobierno sobre la información —un punto que se trabaja en tercerizar no es perder el control—. La clave es dejar por escrito de quién es cada cosa antes de empezar.
Cuándo conviene este modelo (y cuándo no)
Sin humo: no es para todos. Conviene cuando hay un proceso operativo con volumen, se necesita una herramienta hecha a medida y no tiene sentido montar y sostener un área de IT para algo que no es el negocio principal. Conviene también cuando se prefiere un costo variable que acompañe la operación antes que una inversión fija para amortizar.
No conviene si el software es el producto que se vende —ahí se lo quiere adentro, es el diferencial— o si ya existe un equipo de desarrollo robusto con capacidad ociosa. Para el resto —que es la mayoría de las financieras, SGRs y terminales de planes de ahorro— pagar el desarrollo por separado suele ser gastar de más para tener menos. Es la misma lógica de tercerizar operaciones vs. contratar más personal: la pregunta no es qué tener adentro, sino cómo conseguir el resultado.
Qué mirar antes de elegir
Si el modelo cierra, conviene evaluarlo con preguntas concretas en lugar de promesas. Estas son las que más ordenan la decisión:
Preguntas para evaluar un esquema de software incluido en el servicio
- ¿De quién son los datos y cómo se exportan si algún día querés cambiar de proveedor?
- ¿La herramienta se adapta a tu proceso, o tu proceso se tiene que adaptar a ella?
- ¿Cómo y cada cuánto se incorporan mejoras? ¿Entran sin costo adicional?
- ¿Qué nivel de servicio —tiempos, disponibilidad, soporte— queda comprometido por escrito?
- ¿Cada operación queda registrada y es auditable ante un pedido del regulador?
- ¿El costo es variable y acompaña tu volumen, o hay un fijo encubierto?
- ¿Se integra con los sistemas que ya usás, o te obliga a reemplazarlos?
Si esas respuestas son claras y quedan en el contrato, el modelo deja de ser un acto de fe y pasa a ser una decisión operativa como cualquier otra.
Así es, en la práctica, como trabajamos en éxodo bpo: la herramienta que el proceso necesita va incluida en el servicio —desde las operaciones a medida hasta plataformas propias como éxodo cloud para terminales de planes de ahorro y SGRs— y la tecnología se actualiza con la operación andando, sin que el cliente cargue con el desarrollo. Pero más allá de quién lo provea, el punto sirve para cualquiera que esté por decidir: antes de firmar un desarrollo o resignarse a un enlatado, conviene preguntarse si el software no debería venir, simplemente, con el servicio.