Agendar una reunión de evaluación
Process Improvement

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

3 node Solutions 5 min de lectura
Icono de engranaje dentro de una red de nodos, representando la mejora de un proceso antes de automatizarlo

Automatizar no debería significar convertir cada paso manual existente en una tarea automática. Antes del desarrollo es necesario identificar actividades innecesarias, reglas redundantes, excepciones evitables y puntos de falla. Process Improvement puede generar valor incluso antes de construir la automatización.

Automatizar un proceso no lo convierte automáticamente en un buen proceso.

Puede hacerlo más rápido.

Y ese es precisamente el problema.

Si una operación contiene pasos innecesarios, datos duplicados, aprobaciones sin valor, reglas contradictorias o excepciones generadas por un mal diseño, una automatización puede terminar ejecutando esas ineficiencias miles de veces con extraordinaria velocidad.

Por eso existe una diferencia importante entre automatizar tareas y mejorar procesos.

El riesgo de copiar el proceso actual

Una aproximación frecuente consiste en documentar lo que una persona hace actualmente y pedir que un robot reproduzca exactamente esos mismos pasos.

El usuario abre una aplicación.

Descarga un archivo.

Copia información.

Abre Excel.

Modifica columnas.

Envía el archivo.

Entonces se espera que el robot haga exactamente lo mismo.

Parece lógico, pero no siempre lo es.

Antes de desarrollar debería plantearse otra pregunta: ¿por qué existe cada uno de esos pasos?

Quizás el archivo podría generarse directamente con el formato requerido.

Quizás Excel existe únicamente como una capa intermedia porque dos sistemas nunca fueron integrados.

Quizás una validación manual podría transformarse en una regla.

Quizás tres aprobaciones podrían convertirse en una.

Quizás la información ya existe en otro sistema.

Automatizar sin realizar estas preguntas puede significar institucionalizar una ineficiencia.

Process Discovery: entender antes de modificar

El primer trabajo consiste en conocer el proceso real, no solamente el proceso que aparece en un procedimiento.

Eso implica entender:

  • Quién participa.
  • Qué aplicaciones utiliza.
  • Qué información recibe.
  • Qué información genera.
  • Qué reglas debe aplicar.
  • Qué excepciones aparecen.
  • Qué actividades consumen mayor tiempo.
  • Qué actividades generan errores.
  • Qué dependencias existen.
  • Dónde aparecen cuellos de botella.

También es importante distinguir entre el flujo normal y las excepciones.

Un proceso puede parecer sencillo cuando se explica su camino ideal y extremadamente complejo cuando empiezan a aparecer todas las situaciones reales de la operación.

Eliminar antes de automatizar

Uno de los principios más importantes de Process Improvement consiste en preguntar si una actividad debería existir.

Imaginemos un proceso compuesto por 22 pasos.

La primera reacción podría ser automatizar los 22.

Una evaluación más profunda podría determinar que cinco pasos pueden eliminarse, tres pueden consolidarse, dos validaciones pueden realizarse automáticamente en origen, una aprobación no es necesaria y cuatro actividades pueden resolverse mediante integración.

El nuevo proceso podría contener considerablemente menos actividades.

Ahora la automatización será más simple.

Y una automatización más simple normalmente significa:

  • Menor desarrollo.
  • Menos puntos de falla.
  • Menor mantenimiento.
  • Mayor velocidad.
  • Mayor estabilidad.

Simplificar reglas también genera retorno

Otro problema frecuente está en las reglas de negocio.

Con el tiempo, las organizaciones acumulan reglas. Algunas se crearon por circunstancias que ya no existen. Otras se superponen. Otras solamente aplican a una proporción mínima de transacciones.

Antes de codificarlas conviene revisar: ¿esta regla sigue siendo necesaria?

Cada regla adicional puede convertirse en lógica adicional, testing adicional y mantenimiento adicional.

La simplificación del proceso tiene un efecto directo sobre la complejidad tecnológica posterior.

Estandarizar antes de escalar

El mismo proceso puede ejecutarse de forma diferente según el país, unidad de negocio, equipo, sucursal, usuario o sistema.

Automatizar inmediatamente puede significar construir múltiples versiones de una misma solución.

En algunos casos es preferible identificar primero qué parte del proceso puede estandarizarse.

Esto es especialmente importante en organizaciones regionales que operan en varios mercados.

Un diseño común permite administrar las diferencias realmente necesarias como configuraciones o variantes controladas, en lugar de crear una automatización distinta para cada operación.

Las excepciones revelan problemas del proceso

Las excepciones no deberían analizarse únicamente como obstáculos para la automatización.

También proporcionan información.

Si una proporción significativa de transacciones necesita intervención manual, debe entenderse por qué.

Puede existir mala calidad de datos, información incompleta, reglas ambiguas, fallas de integración, inconsistencias entre sistemas o actividades realizadas fuera del proceso definido.

Resolver la causa puede ser más valioso que construir lógica adicional para administrar eternamente la excepción.

¿Qué debería salir de Process Improvement?

Antes de comenzar el desarrollo debería existir una definición clara del proceso objetivo.

Ese proceso debería establecer:

  • Qué actividades desaparecen.
  • Cuáles se simplifican.
  • Cuáles se estandarizan.
  • Cuáles se automatizan.
  • Cuáles requieren intervención humana.
  • Qué excepciones permanecerán.
  • Qué sistemas participarán.
  • Qué controles son necesarios.

Ese será el proceso To-Be.

Y ese es el proceso que debería automatizarse.

El beneficio puede comenzar antes de la automatización

Eliminar una aprobación innecesaria genera valor.

Reducir duplicación de información genera valor.

Estandarizar una actividad genera valor.

Eliminar una planilla intermedia genera valor.

Simplificar una regla genera valor.

La automatización posteriormente multiplica esos beneficios.

La automatización debe amplificar un buen proceso

La pregunta no debería ser: ¿cómo automatizamos lo que hacemos hoy?

Debería ser: si pudiéramos diseñar este proceso nuevamente, ¿cómo debería funcionar?

Después podemos determinar qué combinación de RPA, integraciones, workflows, low-code e Inteligencia Artificial permite ejecutarlo de manera eficiente.

Automatizar más rápido no es necesariamente avanzar más rápido.

Cuando el proceso está mal diseñado, detenerse primero a mejorarlo puede ser la decisión que más acelera el resultado final.

process improvement rediseño de procesos lean
← 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

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

Documento con un gráfico de barras ascendente, representando el retorno de una automatización
Business Case

El ROI real de la automatización: más allá de las horas ahorradas

Conversemos sobre el proceso que necesita mejorar.

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

Agendar una reunión de evaluación