Agendar una reunión de evaluación
Adopción

La gestión del cambio en proyectos de automatización: el riesgo que rara vez es técnico

3 node Solutions 5 min de lectura
Figura humana en postura de meditación formada por líneas de nodos, representando el cambio organizacional

Una automatización puede estar técnicamente bien construida y aun así fracasar en la operación. Roles, responsabilidades, hábitos, controles y decisiones cambian cuando cambia un proceso. La gestión del cambio no consiste únicamente en capacitar usuarios antes del go-live: consiste en preparar a la organización para operar de una manera diferente.

Una automatización puede superar todas las pruebas técnicas y aun así no generar el resultado esperado.

El robot funciona.

La integración funciona.

Los datos son correctos.

El deployment fue exitoso.

Pero los usuarios continúan utilizando el proceso anterior.

Aparecen planillas paralelas.

Se crean controles manuales adicionales.

Las excepciones no se administran correctamente.

Nadie sabe quién debe actuar cuando existe un problema.

El proyecto técnicamente funciona.

La operación no cambió.

Ese es uno de los riesgos más subestimados de la automatización empresarial.

Automatizar significa cambiar cómo trabaja una organización

Un proceso no está compuesto solamente por sistemas.

También está compuesto por personas.

Una automatización puede modificar:

  • Tareas.
  • Responsabilidades.
  • Aprobaciones.
  • Controles.
  • Tiempos.
  • Información disponible.
  • Decisiones.
  • Indicadores.

Por eso el impacto organizacional debe analizarse desde el comienzo.

El error de considerar Change Management como capacitación

En muchos proyectos la gestión del cambio aparece casi al final.

Se desarrolla la solución.

Se realiza testing.

Poco antes del go-live se agenda una sesión para explicar cómo funciona.

Eso no es suficiente.

Capacitación es una parte del Change Management.

Pero la pregunta más amplia es:

¿Qué necesita cambiar dentro de la operación para que este nuevo proceso funcione?

Los usuarios necesitan comprender el propósito

Cuando una automatización se presenta solamente como una iniciativa tecnológica pueden surgir percepciones incorrectas.

"Nos están reemplazando."

"El sistema nos va a controlar."

"Ahora tendremos más trabajo."

"Esto funcionaba bien antes."

La resistencia no siempre aparece porque las personas sean contrarias a la tecnología.

Muchas veces aparece porque no comprenden por qué se está modificando el proceso, qué problema se intenta resolver, qué cambiará, qué permanecerá igual y qué se espera de ellos.

Comunicar el propósito reduce incertidumbre.

Involucrar usuarios durante Process Discovery

Los usuarios que ejecutan diariamente un proceso poseen conocimiento que rara vez aparece completamente en un procedimiento.

Conocen:

  • Excepciones.
  • Atajos.
  • Dependencias.
  • Problemas recurrentes.
  • Situaciones especiales.

Involucrarlos durante Discovery mejora el diseño y, al mismo tiempo, genera participación.

Existe una diferencia importante entre recibir una solución terminada y participar en la definición de cómo debería funcionar.

Debe quedar claro quién hace qué

Cuando parte de un proceso se automatiza, las responsabilidades cambian.

Antes, una persona procesaba todas las transacciones.

Después, la automatización procesa 85% y la persona administra excepciones.

Eso significa que el nuevo trabajo de esa persona ya no consiste principalmente en ejecución.

Consiste en excepción, control y supervisión.

Este cambio debe quedar explícitamente definido.

Las excepciones necesitan propietarios

Una automatización puede identificar correctamente un problema y enviarlo a una cola.

Pero si nadie es responsable de esa cola, el proceso sigue fallando.

Cada tipo de excepción debería tener:

  • Propietario.
  • Prioridad.
  • Tiempo esperado de respuesta.
  • Mecanismo de resolución.
  • Escalamiento.

Automatizar el camino normal sin diseñar la operación de excepciones deja el proceso incompleto.

El temor a perder control produce procesos paralelos

Un fenómeno frecuente después de automatizar es la creación de verificaciones manuales adicionales.

Los usuarios no confían completamente en la solución.

Por eso mantienen una planilla.

Revisan nuevamente resultados.

Crean un reporte adicional.

Durante un periodo inicial, determinados controles pueden ser razonables.

Pero si permanecen indefinidamente, el supuesto ahorro puede desaparecer.

La confianza debe construirse mediante evidencia, métricas, trazabilidad, resultados consistentes y tratamiento claro de errores.

Los managers también necesitan cambiar

Change Management no afecta solamente al usuario operativo.

Los responsables del proceso ahora pueden necesitar nuevas métricas.

Antes medían transacciones por persona y horas de procesamiento.

Después podrían necesitar medir tasa de automatización, excepciones, tasa de éxito, tiempo de recuperación, backlog y capacidad.

Administrar una operación automatizada requiere indicadores diferentes.

Hypercare cumple una función organizacional

Los primeros días después del go-live son particularmente importantes.

El objetivo de Hypercare no es solamente resolver bugs.

También permite observar cómo utilizan realmente la solución los usuarios, dónde aparecen dudas, qué excepciones no fueron previstas, qué actividades siguen ejecutándose manualmente y qué elementos necesitan ajustes.

Es un periodo de transición entre proyecto y operación.

Medir adopción, no solamente disponibilidad

Una solución puede estar disponible 99,9% del tiempo y tener una adopción deficiente.

Por eso conviene observar indicadores como:

  • Porcentaje de transacciones procesadas por el nuevo flujo.
  • Número de actividades manuales paralelas.
  • Excepciones.
  • Frecuencia de intervención.
  • Feedback de usuarios.
  • Uso de funcionalidades.

Esto ayuda a diferenciar un problema tecnológico de un problema de adopción.

Los cambios deben continuar después del go-live

Los procesos evolucionan.

Los equipos descubren nuevas necesidades.

Las políticas cambian.

Por eso una automatización no debería congelarse después de producción.

Los usuarios deben contar con un mecanismo claro para reportar incidentes, proponer mejoras, solicitar cambios, incorporar nuevas excepciones y revisar resultados.

La mejora continua también es gestión del cambio.

Una pregunta útil antes de implementar

Antes del go-live conviene reunir a responsables de negocio y responder:

Mañana, cuando esta automatización esté funcionando, ¿qué hará diferente cada persona involucrada en el proceso?

Si la respuesta no está clara, probablemente el cambio organizacional todavía no esté completamente diseñado.

Tecnología y operación deben cambiar juntas

La automatización empresarial funciona cuando tres elementos están alineados:

Proceso + tecnología + personas.

Puede existir una excelente arquitectura tecnológica.

Pero si el proceso continúa funcionando de la misma manera alrededor de ella, el valor será limitado.

Change Management no es una actividad secundaria.

Es el mecanismo que convierte una solución técnica en una nueva forma de operar.

gestión del cambio adopción comunicación interna
← Volver a Insights

Otros insights

Nodo conectado dentro de un ciclo de flechas, representando la elección entre tecnologías de automatización
Automatización

RPA, APIs, IA o agentes: cómo decidir qué tecnología necesita realmente un proceso empresarial

Icono de engranaje dentro de una red de nodos, representando la mejora de un proceso antes de automatizarlo
Process Improvement

Automatizar un proceso deficiente más rápido sigue dejando un proceso deficiente

Escudo con una marca de verificación sobre una red de nodos, representando una automatización lista para producción
Inteligencia Artificial

Del piloto de IA a producción: qué cambia cuando una automatización debe operar el negocio

Conversemos sobre el proceso que necesita mejorar.

Una evaluación de 30 minutos para entender su caso.

Agendar una reunión de evaluación