AS-IS vs. TO-BE: cómo pasar de documentar procesos a realmente mejorarlos

Uno de los errores más frecuentes en los proyectos de procesos es considerar que el trabajo termina cuando se elaboran los flujogramas.

En realidad, ese debería ser apenas el punto de partida.

Si una organización documenta exactamente cómo trabaja actualmente y posteriormente convierte esos diagramas en procedimientos, puede terminar formalizando sus propias ineficiencias.

El valor del levantamiento de procesos aparece cuando la información obtenida permite cuestionar la operación:

¿Esta actividad realmente agrega valor?

¿Esta aprobación es necesaria?

¿Por qué esta información se registra más de una vez?

¿Por qué intervienen tantas personas?

¿Qué provoca los tiempos de espera?

¿Qué actividades podrían automatizarse?

¿Qué información debería generar el proceso para poder medirlo?

Estas preguntas permiten pasar de documentar procesos a mejorarlos.

El TO-BE representa cómo debería funcionar el proceso después de incorporar las mejoras identificadas.

No se trata simplemente de hacer un flujograma más ordenado. El objetivo es diseñar una operación que permita alcanzar mejores resultados con una utilización más eficiente de los recursos.

Dependiendo del proceso, el diseño TO-BE puede considerar:

• eliminación de actividades que no agregan valor;
• reducción de aprobaciones;
• eliminación de duplicidad de información;
• redefinición de responsabilidades;
• simplificación de controles;
• integración entre áreas;
• estandarización de actividades;
• digitalización de registros;
• automatización de tareas;
• utilización de inteligencia artificial;
• establecimiento de indicadores de desempeño.

De esta manera, el TO-BE se convierte en una propuesta concreta de transformación del proceso.

La diferencia entre ambos modelos puede resumirse de manera sencilla:

AS-IS = entender cómo trabajamos hoy.

TO-BE = diseñar cómo deberíamos trabajar mañana.

Pero entre ambos existe una etapa fundamental: el análisis del proceso.

Una metodología práctica puede desarrollarse en cinco etapas.

El primer paso consiste en comprender cómo se ejecuta realmente el proceso y representarlo de manera estructurada.

El objetivo no es juzgar todavía si está bien o mal, sino obtener una visión común y validada de la operación.

Con el proceso visible es posible analizar dónde se encuentran las principales ineficiencias.

Algunas señales frecuentes son:

• demasiadas aprobaciones;
• actividades duplicadas;
• información registrada en varios sistemas;
• dependencia excesiva de correos electrónicos;
• controles manuales;
• tareas repetitivas;
• falta de responsables claros;
• tiempos prolongados entre actividades;
• reprocesos;
• ausencia de indicadores.

Eliminar una actividad sin entender por qué existe puede generar nuevos problemas.

Por ello, antes de rediseñar el proceso es necesario identificar las causas que originan los retrasos, errores o reprocesos.

Esto permite diferenciar entre el problema visible y su verdadera causa.

Una vez identificadas las oportunidades, se diseña la nueva forma de trabajo.

En esta etapa deben evaluarse conjuntamente personas, actividades, controles, tecnología e información.

El objetivo no es solamente tener menos pasos, sino construir un proceso más simple, controlado, medible y sostenible.

Un proceso no puede considerarse mejor únicamente porque su nuevo flujograma tenga menos actividades.

La mejora debería poder demostrarse mediante resultados.

Por ejemplo:

• reducción del tiempo de ciclo;
• disminución de errores;
• reducción de reprocesos;
• cumplimiento de tiempos de respuesta;
• disminución de actividades manuales;
• incremento de productividad;
• reducción de costos;
• mejora en la experiencia del cliente.

Por ello, los indicadores deben formar parte del diseño TO-BE.

Actualmente, el análisis AS-IS y TO-BE tiene una oportunidad adicional: identificar actividades que pueden ser digitalizadas, automatizadas o apoyadas mediante inteligencia artificial.

Sin embargo, existe una regla importante:

automatizar un proceso ineficiente no necesariamente lo convierte en un buen proceso.

Si una organización automatiza actividades duplicadas, controles innecesarios o circuitos excesivos de aprobación, simplemente conseguirá ejecutar más rápido un proceso que sigue estando mal diseñado.

Por eso, antes de implementar tecnología conviene analizar el proceso.

Primero se simplifica.

Después se estandariza.

Luego se determina qué tiene sentido automatizar.

En algunos procesos, las oportunidades pueden encontrarse en tareas como clasificación de información, generación de documentos, extracción de datos, elaboración de reportes, seguimiento de solicitudes, validaciones, alertas o análisis de grandes volúmenes de información.

La tecnología debería responder al proceso y no al revés.

Imaginemos un proceso de aprobación de compras.

En el AS-IS se identifica que una solicitud:

1. se genera mediante correo electrónico;
2. se registra posteriormente en Excel;
3. pasa por tres aprobaciones;
4. vuelve al solicitante cuando falta información;
5. se envía nuevamente por correo;
6. finalmente se registra en otro sistema.

El proceso funciona, pero genera tiempos de espera, duplicidad de información y poca trazabilidad.

En el TO-BE podría diseñarse un único punto de ingreso de la solicitud, establecer campos obligatorios, definir aprobaciones según monto, generar alertas automáticas y mantener la trazabilidad del estado de cada requerimiento.

El resultado no es solamente un flujograma diferente.

Es una nueva forma de operar.

Esta es probablemente la diferencia más importante.

Una organización orientada a documentación pregunta:

"¿Tenemos el procedimiento?"

Una organización orientada a procesos pregunta:

"¿Este proceso está generando el resultado esperado y cómo podemos hacerlo mejor?"

Los procedimientos, flujogramas y fichas de procesos son herramientas importantes, pero no deberían convertirse en el objetivo final.

El verdadero valor aparece cuando permiten entender la operación, tomar decisiones, medir resultados y mejorar continuamente.