AS-IS vs. TO-BE: de documentar procesos a mejorarlos

El AS-IS representa cómo funciona realmente un proceso en la actualidad.

No describe cómo debería funcionar según un procedimiento, ni cómo piensa la gerencia que funciona. Busca identificar lo que verdaderamente sucede durante la operación.

Para construirlo es necesario conversar con las personas que ejecutan el proceso, observar la secuencia de actividades, identificar responsables, entradas, salidas, decisiones, controles, sistemas utilizados y puntos de interacción con otras áreas.

Un buen levantamiento AS-IS permite detectar situaciones como:

• actividades duplicadas;
• aprobaciones innecesarias;
• reprocesos;
• tareas manuales que podrían automatizarse;
• responsabilidades poco claras;
• controles insuficientes o excesivos;
• información registrada varias veces;
• actividades que dependen excesivamente de una persona;
• cuellos de botella;
• riesgos operativos;
• uso de herramientas desconectadas entre sí.

Por eso, documentar el AS-IS no debería ser el objetivo final del proyecto. Es el punto de partida para comprender la operación.

Uno de los errores más frecuentes en los proyectos de procesos es entrevistar al personal, dibujar el flujo actual, aprobarlo y convertirlo inmediatamente en un procedimiento.

El problema es evidente: si el proceso actual contiene ineficiencias, al documentarlo sin cuestionarlo podemos terminar formalizando los mismos problemas que queríamos resolver.

Una actividad no agrega valor simplemente porque "siempre se ha hecho así".

Antes de estandarizar un proceso debemos preguntarnos:

¿Esta actividad es realmente necesaria?

¿Quién debería ejecutarla?

¿Podemos eliminarla, simplificarla o automatizarla?

¿Existen controles duplicados?

¿La información podría generarse una sola vez y reutilizarse?

¿Dónde se producen esperas o reprocesos?

¿Qué riesgos existen y cómo deberían controlarse?

Estas preguntas convierten un ejercicio de documentación en un ejercicio de mejora.

El TO-BE representa cómo debería funcionar el proceso después de analizar y mejorar la situación actual.

No consiste simplemente en dibujar un flujograma más ordenado.

Implica tomar decisiones sobre la manera en que debería operar la organización para conseguir mejores resultados.

El TO-BE puede incorporar, entre otros aspectos:

• eliminación de actividades que no agregan valor;
• reducción de tiempos y pasos;
• redefinición de responsabilidades;
• incorporación o mejora de controles;
• automatización de actividades;
• integración entre sistemas;
• reducción de registros manuales;
• estandarización de criterios;
• definición de indicadores;
• tratamiento de riesgos;
• mejoras en la interacción entre áreas.

Por eso podemos resumir la diferencia de esta manera:

AS-IS = entender cómo trabajamos hoy.

TO-BE = diseñar cómo queremos trabajar mañana.

El verdadero valor de un proyecto de procesos se encuentra en el espacio entre ambos modelos.

Supongamos, por ejemplo, que un proceso requiere que una persona reciba información por correo electrónico, la registre en una hoja de cálculo, solicite una aprobación, vuelva a ingresar los mismos datos en otro sistema y posteriormente genere manualmente un reporte.

El AS-IS debe reflejar esa realidad.

Pero el TO-BE debería preguntarse si toda esa secuencia continúa siendo necesaria.

Quizás la información pueda capturarse una sola vez, activar automáticamente un flujo de aprobación, actualizar los registros correspondientes y alimentar un tablero de indicadores.

El objetivo no es únicamente producir un flujograma diferente.

El objetivo es lograr un proceso más simple, controlado, medible y eficiente.

Existe una tendencia a comenzar los proyectos de transformación preguntando:

"¿Dónde podemos utilizar Inteligencia Artificial?"

Pero existe una pregunta que debería realizarse primero:

"¿Tenemos claro cómo funciona nuestro proceso y cómo debería funcionar?"

Automatizar un proceso ineficiente puede simplemente conseguir que una ineficiencia ocurra más rápido.

Por eso, antes de incorporar automatización, RPA, Inteligencia Artificial, CRM, ERP u otras herramientas, es recomendable analizar el proceso.

Una secuencia lógica sería:

1. Identificar el proceso.
Determinar alcance, objetivo, participantes, entradas y resultados esperados.

2. Levantar el AS-IS.
Comprender cómo se ejecuta realmente.

3. Analizar riesgos, controles e ineficiencias.
Identificar problemas, reprocesos, actividades sin valor y oportunidades.

4. Diseñar el TO-BE.
Definir una operación más eficiente y controlada.

5. Evaluar automatización e IA.
Determinar qué actividades pueden apoyarse o transformarse mediante tecnología.

6. Definir indicadores.
Medir si el nuevo proceso realmente genera mejores resultados.

De esta manera, la tecnología se convierte en un habilitador de la mejora y no en el objetivo del proyecto.

No basta con observar la secuencia de actividades. También es necesario entender quién hace qué, qué riesgos existen, qué controles se requieren, qué información circula y cómo se medirá el desempeño.

Herramientas como SIPOC permiten delimitar el proceso y entender proveedores, entradas, actividades, salidas y clientes.

El modelamiento mediante BPMN permite visualizar la secuencia de actividades y decisiones.

Una matriz RACI ayuda a clarificar responsabilidades.

El análisis de riesgos y controles permite evaluar dónde puede fallar el proceso y qué mecanismos deberían existir.

Los indicadores permiten comprobar posteriormente si las mejoras implementadas producen los resultados esperados.

Cuando estas herramientas se utilizan de manera integrada, el levantamiento deja de ser únicamente documental y comienza a convertirse en una herramienta de gestión.

Una organización madura no debería tener procedimientos simplemente porque una norma, una auditoría o un sistema de gestión los solicita.

Los procesos deberían servir para gestionar mejor la organización.

Eso significa que deben ayudar a responder preguntas como:

¿Dónde estamos perdiendo tiempo?

¿Qué actividades generan reprocesos?

¿Dónde existen riesgos importantes?

¿Qué responsabilidades no están claras?

¿Qué podemos automatizar?

¿Qué debemos medir?

¿Qué información necesita la gerencia para tomar decisiones?

Cuando un proyecto de procesos logra responder estas preguntas, el resultado deja de ser un conjunto de documentos y se convierte en una herramienta para mejorar la operación.

El AS-IS y el TO-BE no deberían verse como dos flujogramas que forman parte de un entregable.

Son dos momentos de una misma conversación empresarial.

El primero obliga a la organización a reconocer cómo trabaja realmente.

El segundo la obliga a decidir cómo quiere trabajar en el futuro.

Entre ambos aparecen las oportunidades de simplificación, estandarización, control, automatización, Inteligencia Artificial y mejora continua.

Por eso, antes de invertir en nuevas herramientas o comenzar a automatizar actividades, vale la pena hacerse una pregunta:

¿Estamos automatizando el proceso que tenemos o diseñando primero el proceso que necesitamos?