El 'swivel chair' que RPA vino a matar

Existe un nombre técnico para esa persona que pasa el día copiando datos de una pantalla a otra. Se llama swivel chair —la silla giratoria— porque literalmente gira de un monitor a otro: lee en el sistema A, gira, escribe en el sistema B. Y es probablemente la tarea más cara e invisible de tu empresa.

El nombre nació en los call centers y backoffices, donde un operador tenía dos o tres sistemas que no se hablaban entre sí. Su trabajo no era decidir nada: era ser el cable humano entre aplicaciones que nunca se integraron. Mirar un número acá, tipearlo allá. Todo el día.

Por qué el swivel chair es el peor de los trabajos

Es la combinación perfecta de lo que no querés que haga una persona:

• No agrega criterio. Es transcripción pura. El humano no aporta juicio, solo dedos.
• Es propenso al error. Un dígito mal tipeado en una transferencia, un campo pegado en la fila equivocada. El cansancio garantiza errores.
• Es desmoralizante. Nadie estudió ni se entrenó para ser un puente de datos manual.
• Es invisible al management. No figura en ningún organigrama como "copiar datos". Está disuelto dentro de roles que en teoría hacen otra cosa.

Justamente porque está disuelto, casi nunca aparece en los procesos que la empresa cree tener. Es parte del abismo entre el proceso que dibujaste y el que de verdad ocurre, y suele esconderse detrás del happy path que tapa el 80% del trabajo real.

El caso de uso perfecto para RPA

El swivel chair es, casi por definición, el primer candidato ideal de un proyecto de RPA. ¿Por qué? Porque cumple todas las condiciones de oro:

1. Es 100% basado en reglas. "Leé este campo, escribilo en aquel otro." Sin ambigüedad, sin criterio. Exactamente lo que un bot —que no es IA ni la necesita— hace mejor que nadie.
2. Es repetitivo y de alto volumen. El ROI salta a la vista: si una persona pasa cuatro horas diarias en esto, un bot las recupera enteras.
3. No hay API que lo resuelva fácil —si la hubiera, el swivel chair no existiría—. Es el territorio donde RPA entra por la ventana porque la puerta nunca se construyó.

El bot toma la silla giratoria, gira más rápido, no se cansa, no se distrae y no comete errores de tipeo. Y la persona que antes era el cable humano queda libre para tareas que sí requieren cabeza.

La trampa: automatizar el síntoma, no la enfermedad

Acá va el matiz que distingue al consultor del vendedor de bots. El swivel chair es un síntoma: existe porque dos sistemas no están integrados. RPA cura el síntoma rápido y barato, y eso está perfecto como primer paso.

Pero el bot no arregla la enfermedad. Sigue habiendo dos sistemas desconectados, ahora unidos por una integración frágil que se rompe con cualquier cambio de pantalla. Lo ideal:

• Corto plazo: poné el bot, recuperá las horas, frená la sangría de errores.
• Mediano plazo: preguntá por qué esos sistemas no se integran de verdad y evaluá la API.

Matar el swivel chair con RPA es una de las victorias más rápidas y satisfactorias de la automatización. Solo recordá que estás tapando un agujero, no rediseñando la casa. El día que puedas conectar los sistemas de verdad, el bot —y la silla giratoria— deberían desaparecer juntos.