La conversación previa a tercerizar gira casi siempre alrededor de dos cosas: el precio y el alcance. Son las dos que menos explican por qué un proyecto termina bien o mal. Lo que decide el resultado es la implementación del BPO: las semanas que van desde la firma hasta el día en que la operación corre sola y el cliente deja de mirarla todos los días. Ese tramo tiene una duración razonablemente estable —unos 90 días para un proceso de volumen medio— y una secuencia que conviene respetar.
La razón por la que vale la pena mirarlo con detalle es incómoda: buena parte del trabajo de una implementación no la hace el proveedor, la hace el cliente. Definir reglas que hoy viven en la cabeza de alguien, conseguir accesos, decidir excepciones que nunca se escribieron. Cuando ese esfuerzo no está previsto, la implementación se estira, el equipo interno se frustra y a los tres meses la conclusión es que "tercerizar no funcionó". Casi nunca es eso. Es que se implementó como si fuera una contratación y no un traspaso de proceso.
Por qué la implementación decide más que la elección del proveedor
Entre dos proveedores serios, la diferencia de capacidad técnica es menor de lo que parece en la presentación comercial. La diferencia real aparece en cómo cada uno maneja los primeros 90 días: si arranca produciendo desde el día uno para mostrar velocidad, o si invierte las primeras semanas en entender el proceso antes de tocarlo.
Arrancar produciendo rápido es tentador y casi siempre sale caro. El equipo tercerizado procesa con reglas incompletas, el cliente detecta errores, se generan retrabajos y la relación empieza con desconfianza justo en el momento en que más se necesita crédito. La secuencia inversa —dos o tres semanas sin producir nada— se siente lenta al principio y termina antes.
Días 1 a 15: relevar, no producir
La primera quincena es de levantamiento. El objetivo no es procesar casos, es escribir el proceso tal como existe hoy, no como figura en el manual. Eso incluye tres cosas que rara vez están documentadas: las reglas de decisión reales, las excepciones y quién las resuelve, y los criterios que la gente aplica por costumbre sin poder explicar de dónde salieron.
La forma práctica de hacerlo es observar. Alguien del proveedor mira trabajar al equipo interno, toma casos concretos —incluidos los raros— y los convierte en reglas escritas que después el cliente valida. En paralelo se define el mapa del dato: qué información toca el proceso, dónde vive cada campo y quién lo escribe. Ese mapa es el insumo para decidir el modelo de conexión, que es una discusión propia: cómo se hace la integración del BPO a los sistemas de la empresa sin duplicar carga ni perder trazabilidad.
El entregable de esta etapa es concreto: un documento de proceso con reglas, excepciones y criterios de aceptación, firmado por el dueño del proceso del lado del cliente. Si al día 15 ese documento no existe o nadie lo quiere firmar, el problema no es de plazos: es que el proceso no está lo bastante definido para tercerizarse todavía.
Días 16 a 45: el piloto corre en paralelo
El piloto es la etapa donde se descubre lo que el relevamiento no vio. Se toma un subconjunto acotado —un tipo de caso, un canal, una cartera— y se procesa en paralelo con el circuito actual. En paralelo significa exactamente eso: el equipo interno sigue haciendo su trabajo y el equipo tercerizado hace el mismo trabajo por su lado, para poder comparar resultados caso por caso.
Es un mes de doble esfuerzo y por eso muchos lo quieren saltear. No conviene. El paralelo es el único momento en que se puede detectar una diferencia de criterio sin que tenga consecuencias: el caso que el equipo interno aprueba y el tercerizado rechaza, la excepción que nadie mencionó, el documento que llega en un formato que no estaba previsto. Cada una de esas diferencias es una regla que faltaba, y encontrarlas con volumen chico cuesta una conversación; encontrarlas con volumen pleno cuesta un mes de retrabajo.
Durante el piloto se mide, pero no para evaluar productividad. La productividad de un equipo nuevo en su primer mes no dice nada. Lo que se mide es la tasa de coincidencia entre ambos circuitos y el tipo de desvío cuando no coinciden. Un piloto sano termina con coincidencia alta y con una lista de reglas nuevas que se incorporan al documento.
No se escala volumen hasta que los desvíos del piloto dejan de ser sorpresas. Mientras cada semana aparezca un tipo de caso que nadie había previsto, el proceso todavía no está descripto: está siendo descubierto.
Días 46 a 75: escalar por olas, con controles antes
Con el proceso estabilizado se amplía volumen, y la forma de ampliarlo importa. Por olas: se suma un tipo de caso o un tramo de volumen, se sostiene dos semanas, se mide, y recién ahí se suma el siguiente. Duplicar de golpe es la manera más eficiente de multiplicar un error que todavía no se detectó.
Antes de cada ola tienen que estar los controles automáticos: validaciones al ingreso, conciliación de totales entre ambos lados y una alerta cuando algo no cuadra. Un equipo que crece sin controles produce más rápido, pero produce a ciegas. Es también el momento de definir el esquema de muestreo y las métricas mensuales del control de calidad sobre el proceso tercerizado, que a partir de acá deja de ser una actividad de implementación y pasa a ser rutina.
En esta etapa aparece el otro tema que se posterga: la cobertura. Un equipo tercerizado también tiene vacaciones, licencias y bajas. Si la operación depende de dos personas que aprendieron el proceso en el piloto, el proyecto es frágil. La formación de un tercer perfil de respaldo se hace acá, mientras hay margen, no cuando falta alguien.
Días 76 a 90: gobierno, línea de base y cierre
El último tramo no agrega volumen: ordena. Se define el gobierno del día a día —quién es la contraparte de cada lado, con qué frecuencia se habla, qué se escala y a quién— y se cierra la línea de base de indicadores. Esa línea de base es lo que va a permitir, seis meses después, afirmar que la operación mejoró en lugar de sentirlo.
Los cuatro indicadores mínimos son casi siempre los mismos: tiempo de ciclo por caso, tasa de rechazo o retrabajo, volumen procesado por período y costo por unidad procesada. Conviene además dejar registrada la medición equivalente del circuito anterior, aunque sea aproximada, porque a los seis meses nadie se acuerda de cómo estábamos antes y la discusión sobre el impacto se vuelve una cuestión de percepciones.
El cierre formal de la implementación es un momento útil: una reunión donde se revisa qué quedó documentado, qué reglas cambiaron respecto del relevamiento inicial y qué temas quedan abiertos con responsable y fecha. Después de eso, la relación pasa a ritmo de operación.
Qué tiene que poner el cliente (y casi nunca está presupuestado)
Esta es la parte que conviene mirar antes de firmar, porque es la que suele desbordar. Una implementación de 90 días necesita, del lado del cliente, un dueño del proceso con autoridad para decidir reglas y excepciones, disponible varias horas por semana durante los primeros 45 días. No un referente que "conoce el tema": alguien que pueda decir "esto se hace así" y que esa definición valga.
Necesita además a IT para accesos, perfiles y conexión, con tiempos reales de la organización —si el alta de un usuario tarda tres semanas, eso es parte del cronograma— y a alguien de compliance o legales para el acuerdo de tratamiento de datos y los criterios de auditoría. Cuando estos tres roles no están asignados con nombre y horas, el proyecto avanza al ritmo de la disponibilidad de quien tenga un rato libre, que es el ritmo más lento posible.
Señales de que la implementación se está torciendo
Hay cuatro que aparecen temprano y conviene tomar en serio. La primera: al día 20 todavía no hay un documento de proceso que alguien haya firmado. La segunda: el piloto se saltea "porque no hay tiempo" —siempre hay menos tiempo después. La tercera: aparece un archivo intermedio que alguien del equipo interno carga a mano, y se naturaliza; ahí el proceso no se tercerizó, se movió el cuello de botella. La cuarta: se empieza a discutir productividad antes de que las reglas estén cerradas, lo que garantiza que se va a producir rápido y mal.
Ocho preguntas antes de arrancar la implementación
- ¿Quién es el dueño del proceso del lado del cliente y cuántas horas semanales puede dedicar?
- ¿Las reglas de decisión están escritas o viven en la cabeza de alguien?
- ¿Qué pasa con las excepciones: quién las resuelve hoy y quién las va a resolver después?
- ¿Cuánto tarda realmente la organización en dar de alta un usuario y un perfil?
- ¿Hay un período de paralelo previsto en el cronograma, o se produce desde el día uno?
- ¿Cómo estamos midiendo hoy este proceso? ¿Existe una línea de base o hay que construirla?
- ¿Qué datos personales cruzan el límite entre organizaciones y bajo qué acuerdo?
- ¿Quién forma al perfil de respaldo, y en qué semana del plan?
Si varias respuestas son "lo vemos en el arranque", conviene verlo antes. La implementación no es la parte administrativa de tercerizar: es donde se define si el proceso queda mejor o simplemente cambia de manos. El orden en que se encara depende de qué se traspasa primero, y ahí sirve la misma lógica que para elegir qué procesos conviene tercerizar primero: volumen, reglas claras y distancia al diferencial del negocio.
En éxodo bpo la implementación es una etapa con entregables propios, no un trámite previo a facturar: relevamiento documentado, piloto en paralelo, escalamiento por olas y línea de base medida antes del cierre. Es como armamos tanto las operaciones a medida como los equipos de gestión de personal, y es la razón por la que preferimos arrancar despacio. Los primeros 90 días no se recuperan: o se usan para dejar el proceso ordenado, o se pagan después.