Cuando el número de operaciones crece más rápido que los ingresos, cada nuevo volumen exige otra persona. Vemos qué parte del trabajo asumen los procesos, los robots y el asistente, y cuál no asumirán nunca.
capas de automatización del back office
procesos y robots en marcha
líneas de código para lanzar un proceso
El volumen crece de forma lineal; el trabajo del back office, más rápido: cada operación arrastra una cola de excepciones.
Un pago por encima del límite, una devolución en una operación disputada, dar de alta a un comercio: cada uno exige una cadena de aprobaciones, y la cadena vive en el correo.
Exportar del portal del proveedor, dejarlo en una carpeta, cargarlo en la contabilidad. Trabajo en el que la persona hace de cable de conexión.
Dónde está el dinero de esta operación, por qué se rechazó, cómo emitir una devolución. La respuesta está en el sistema, pero encontrarla rara vez es más rápido que preguntar a un compañero.
Tareas distintas, herramientas distintas. Confundirlas sale caro: un robot no sustituye a un proceso ni un asistente a un robot.
Aprobaciones, escalados y plazos se describen como un esquema: quién aprueba, qué ocurre por encima del límite, adónde va la tarea si nadie responde en un día. El esquema lo ejecuta el sistema, no la memoria de alguien.
Donde la contraparte no tiene API, el robot hace lo que hacía la persona: entra al portal, toma la exportación, deja el fichero en su sitio. Por calendario y sin olvidarse.
Responde preguntas sobre los datos de su organización: estado de la operación, motivo del rechazo, historial de cambios. No ahorra la operación sino los minutos de búsqueda, que al día suman una hora.
La automatización del back office suele venderse como una sola herramienta, y ahí está su principal debilidad. Un robot lanzado contra un proceso de aprobación se vuelve una construcción frágil: cambia el orden de las firmas y el robot se rompe. Un proceso con el que se pretende sustituir el trasiego de ficheros choca con que la contraparte no tiene API. El reparto correcto es sencillo: el proceso describe decisiones, el robot ejecuta acciones, el asistente responde preguntas.
La segunda diferencia está en quién es el autor. Una implantación clásica exige un proveedor y un proyecto de varios meses, tras el cual cualquier cambio vuelve a requerir al proveedor. Aquí el proceso lo monta en el panel del operador la misma persona que trabaja dentro de él: la que mejor sabe dónde se pierde el tiempo. El coste de un cambio baja a media hora y la automatización deja de quedarse obsoleta.
Y un límite honesto. La automatización no asumirá el análisis de una operación disputada, ni la negociación de comisiones con el proveedor, ni la decisión de entregar dinero a un destinatario dudoso. Eso es, en esencia, el trabajo del back office. El sentido de las tres capas es que el equipo se dedique a eso y no a trasladar líneas entre ventanas.
Tres asistentes de configuración. El operador los recorre por su cuenta, sin desarrollo.
Pasos, roles, condiciones de transición, plazos y escalados. El proceso arranca con un evento de la operación o a mano.
Guion, calendario, credenciales y comportamiento ante fallo: reintentar, aplazar o pasar a una persona.
El ámbito de datos al que accede, los roles de usuario y los límites: sobre qué responde y qué deriva.
Conviene empezar por el proceso y no por el robot: mientras el orden de aprobaciones no esté descrito, el robot automatizará el desorden y costará más que hacerlo a mano.
Regístrese y monte usted mismo el primer proceso: el esquema funciona sin desarrollo. Los robots y el asistente llegan en los pasos siguientes.
Empezar