En casi todos los proyectos de tercerización que se caen, el motivo que se registra en la minuta es otro, pero el motivo real es el mismo: nadie resolvió a tiempo cómo iba a ser la integración del BPO a los sistemas de la empresa. El acuerdo comercial estaba, el alcance estaba, el equipo del proveedor estaba. Lo que faltaba era la respuesta a una pregunta muy concreta: ¿desde dónde van a trabajar, con qué permisos, y cómo vuelve lo que producen al sistema donde vive la verdad del negocio?
En el mercado financiero argentino esa pregunta tiene nombres propios. Newcon en planes de ahorro, SAP en la administración, Salesforce o un CRM propio en lo comercial, y casi siempre un core prestado o desarrollado a medida que nadie quiere tocar. Ninguno de esos sistemas fue pensado para que un tercero opere adentro. Pero todos admiten alguna forma de trabajo conjunto —el punto es elegir la correcta, y elegirla antes de que el proveedor arranque, no después.
Por qué la integración se subestima (y qué pasa cuando se subestima)
La integración se subestima porque parece un tema técnico y se trata como un trámite de IT: "les damos un usuario y listo". El problema es que la forma de conectarse define el modelo operativo entero. Define quién carga, quién controla, dónde queda el registro de lo que se hizo, qué se puede auditar y qué no. Un accesorio técnico mal elegido termina produciendo lo que más se quería evitar: doble carga, planillas paralelas y una operación que existe en dos lugares a la vez sin que ninguno sea confiable.
El síntoma clásico es el Excel intermedio. El proveedor no puede escribir en el sistema, entonces devuelve un archivo; alguien del equipo interno lo carga. En el papel se tercerizó el proceso; en los hechos se movió el cuello de botella un casillero más adelante y se sumó un punto de error. La operación no mejora, el costo baja menos de lo prometido y a los tres meses la conclusión es que "el proveedor no rinde". Rendía. El diseño de la conexión no.
Los cuatro modelos de integración BPO a sistemas
En la práctica hay cuatro formas de conectar un equipo tercerizado a los sistemas del cliente, y conviene conocerlas todas antes de elegir, porque casi ninguna operación usa una sola.
1. Acceso directo con usuarios nominados. El equipo del proveedor trabaja dentro del sistema del cliente, con usuarios propios, perfiles acotados y trazabilidad nativa. Es el modelo más simple y, cuando el sistema lo permite, el mejor: no hay duplicación de datos ni sincronización que pueda fallar, y cada acción queda registrada con nombre y hora en el log del sistema. La condición es que el sistema tenga perfiles granulares —si el único perfil disponible da acceso a todo, este camino no sirve.
2. Integración por API. El proveedor opera en su propia plataforma y los datos se sincronizan con el sistema del cliente vía interfaz programática. Es lo que mejor escala y lo que permite automatizar de verdad —validaciones, controles, alertas—, pero requiere que el sistema exponga endpoints y que haya alguien del lado del cliente que los conozca. En Salesforce es casi trivial; en un core desarrollado hace quince años puede ser un proyecto en sí mismo.
3. Intercambio de archivos estructurados. Lotes de datos que van y vienen en formato fijo, por SFTP o carpeta compartida, con una frecuencia acordada. Es el modelo más viejo y el más subestimado: bien hecho —con esquema definido, validación automática al ingresar y acuse de recepción— resuelve el 80% de los casos de alto volumen sin tocar el sistema. Mal hecho es exactamente el Excel intermedio del que hablábamos, con otro nombre.
4. Automatización sobre la interfaz existente. Cuando el sistema no tiene API ni admite usuarios externos, se automatiza la carga sobre la propia pantalla. Es frágil —cualquier cambio de la interfaz lo rompe— y no debería ser nunca la arquitectura definitiva, pero funciona muy bien como puente mientras se construye algo mejor, y evita quedar rehén de un sistema legacy.
Newcon, SAP y Salesforce: qué cambia en cada uno
Las diferencias entre plataformas no son de detalle, cambian el diseño. En Newcon, muy presente en terminales y administradoras de planes de ahorro, lo habitual es el acceso directo con perfiles acotados: el equipo tercerizado carga y valida adherentes dentro del sistema, y el control se hace sobre reportes del propio Newcon. La discusión suele ser de perfiles, no de arquitectura —cómo dar acceso a la carga de legajos sin habilitar de paso la administración de contratos.
En SAP la restricción típica es de licencias y de segregación de funciones: sumar usuarios cuesta caro y el esquema de autorizaciones es estricto por diseño. Ahí suele convenir un modelo mixto: el proveedor procesa y valida en su plataforma, y la contabilización final la ejecuta un usuario interno con la información ya depurada. Cambia el reparto de tareas, no el beneficio.
En Salesforce —o cualquier CRM moderno— el problema no es técnico sino de gobierno del dato: la API está, pero hay que decidir qué campos escribe el proveedor, cuáles son de solo lectura y qué pasa si el mismo registro se toca de los dos lados. Definir un dueño por campo antes de conectar nada evita el 90% de los conflictos posteriores.
Un dato tiene un solo dueño y un solo lugar donde vive. Si después de la integración el mismo número existe en dos sistemas y los dos lo pueden editar, la integración está mal diseñada, no importa qué tan bien funcione el primer mes.
Los tres riesgos que aparecen tarde
El primero es de permisos. Dar más acceso del necesario "para que no se traben" es la decisión más común y la peor. El criterio correcto es el inverso: el mínimo perfil que permita completar la tarea, revisado cada tres meses y revocado el mismo día que alguien deja el equipo. Un proveedor serio pide menos accesos de los que le ofrecen y documenta por qué necesita cada uno.
El segundo es de trazabilidad. Si el proveedor trabaja en su plataforma y devuelve resultados, tiene que poder mostrar el camino completo de cada caso: qué documento entró, contra qué regla se validó, quién resolvió la excepción y cuándo. Ante un requerimiento de UIF o CNV, "está en el sistema del proveedor" no alcanza si ese sistema no exporta evidencia en un formato que el auditor acepte. Vale la pena ver cómo está construida la plataforma tecnológica del proveedor antes de firmar, no después del primer pedido de auditoría.
El tercero es la dependencia de la conexión. Toda integración se cae alguna vez: cae la VPN, cambia una versión, expira un certificado. La pregunta no es si va a pasar, sino qué hace la operación ese día. Un plan de contingencia escrito —modo alternativo de carga, cuántas horas se tolera, quién avisa a quién— es parte del diseño, igual que en cualquier esquema de continuidad operativa frente a interrupciones.
Cómo secuenciar la integración sin frenar la operación
La secuencia que funciona tiene cuatro etapas y ninguna se saltea. Primero, un mapa del dato: qué información toca el proceso, en qué sistema vive cada campo, quién lo escribe hoy y quién debería escribirlo después. Es un ejercicio de dos reuniones que ahorra meses.
Segundo, un piloto de conexión con volumen chico: un solo proceso, un lote acotado, corriendo en paralelo con el circuito actual. No se busca eficiencia todavía, se busca detectar los desvíos —el campo que llega con otro formato, la excepción que nadie había mencionado, el caso que el sistema rechaza.
Tercero, controles automáticos antes de escalar: validaciones al ingreso, conciliación de totales entre ambos lados y una alerta cuando algo no cuadra. Escalar volumen sin controles es multiplicar errores a velocidad industrial.
Cuarto, ampliación por olas, con la línea de base medida desde el principio —tiempo de ciclo, tasa de rechazo, costo por unidad procesada— para poder afirmar que mejoró y no solamente sentirlo. El orden de esas olas se decide con la misma lógica que se usa para elegir qué procesos tercerizar primero: volumen, reglas claras y distancia al diferencial del negocio.
Antes de conectar nada: las preguntas que ordenan
Siete preguntas para diseñar la integración
- ¿Qué sistema es la fuente de verdad de cada dato del proceso, y quién es el dueño de cada campo?
- ¿El sistema admite perfiles acotados, o el único acceso posible es "todo o nada"?
- ¿Hay API disponible y documentada? ¿Alguien del lado del cliente la conoce y la puede sostener?
- ¿Cómo se registra quién hizo cada cosa, y ese registro se puede exportar para una auditoría?
- ¿Qué pasa el día que la conexión se cae? ¿Cuántas horas tolera la operación sin ella?
- ¿Qué datos personales cruzan el límite entre organizaciones y bajo qué acuerdo de tratamiento?
- ¿El proveedor puede mostrar esta misma integración funcionando en otra operación comparable?
Si alguna respuesta es "lo vemos después", conviene verlo antes. Las integraciones no fallan por complejidad técnica: fallan por decisiones que se postergaron hasta que ya había volumen corriendo.
En éxodo bpo la integración se define en el diseño de la operación, no en la implementación: mapeamos el dato, elegimos el modelo de conexión que el sistema del cliente admite y recién ahí armamos el equipo, tanto en operaciones a medida como en análisis de riesgo crediticio. Trabajamos con acceso directo, con API y con archivos estructurados según lo que haya del otro lado —y cuando no hay nada de eso, lo construimos. Porque el objetivo de tercerizar nunca fue cambiar de sistema. Fue que el sistema deje de ser el cuello de botella.