¿Tu proceso SAP funciona como fue diseñado? Process mining para detectar desviaciones y cuellos de botella

Un proceso puede estar correctamente diseñado en un diagrama y ejecutarse de una manera completamente diferente en la operación diaria. Usuarios que agregan pasos manuales. Aprobaciones que toman rutas distintas. Órdenes que necesitan correcciones. Actividades que se ejecutan fuera de SAP. Excepciones que con el tiempo terminan convirtiéndose en la forma habitual de trabajar.

La pregunta entonces no es solamente:

¿cómo debería funcionar nuestro proceso?

También necesitamos saber:

¿cómo está funcionando realmente?

El process mining busca responder esa segunda pregunta utilizando los datos que los sistemas empresariales generan durante la ejecución de los procesos.

¿Qué es process mining?

Process mining, o minería de procesos, es una disciplina que utiliza registros generados por los sistemas de información para reconstruir y analizar cómo se ejecutan realmente los procesos.

En un ERP como SAP, las operaciones dejan información asociada a transacciones, documentos, usuarios, fechas, cambios y otros elementos del proceso. A partir de estos datos es posible reconstruir secuencias de actividades y analizar qué rutas siguen realmente los casos.

Ingvaldsen y Gulla (2008) señalan que puede existir una diferencia entre la manera en que un sistema SAP fue diseñado para soportar un proceso y la forma en que los usuarios realmente realizan las actividades. Esa diferencia es precisamente uno de los espacios donde el process mining puede aportar información.

El proceso diseñado no siempre es el proceso ejecutado

Una empresa puede tener documentado un flujo como:

solicitud → aprobación → orden → recepción → factura → pago

Pero los datos pueden mostrar algo diferente:

solicitud → modificación → aprobación → modificación → orden → bloqueo → corrección → recepción → factura → nueva corrección → pago. El primer flujo representa cómo se espera que funcione el proceso. El segundo puede representar cómo está funcionando realmente.

Esto no significa automáticamente que las variantes sean incorrectas. Algunas pueden responder a necesidades legítimas del negocio. Otras pueden revelar retrabajos, excepciones frecuentes, controles insuficientes o pasos que ya no aportan valor.

El objetivo del análisis es entender por qué aparecen esas diferencias.

¿Qué información puede revelar el process mining?

Dependiendo del proceso y de la calidad de los datos disponibles, el análisis puede ayudar a observar:

• secuencias reales de actividades;
• variantes del proceso;
• actividades que se repiten;
• tiempos entre etapas;
• excepciones frecuentes;
• recorridos poco habituales;
• usuarios o roles que intervienen;
• cambios realizados sobre documentos;
• posibles puntos de espera;
• diferencias entre el modelo esperado y la ejecución real.

Štolfa et al. (2014), por ejemplo, aplicaron técnicas de process mining sobre un proceso de facturas en SAP y analizaron distintas secuencias de ejecución considerando no solo actividades, sino también tiempo y usuarios.

La finalidad no era simplemente crear un gráfico del proceso. Era identificar patrones y diferencias que no resultaban evidentes observando únicamente el modelo formal.

1. Primero hay que definir qué queremos investigar

Process mining no debería empezar extrayendo todas las tablas posibles de SAP. El primer paso es definir el problema. Roest (2012) propone comenzar delimitando el alcance del análisis y estableciendo objetivos y preguntas concretas.

Por ejemplo:

• ¿Por qué determinadas órdenes tardan más que otras?
• ¿Dónde aparecen más modificaciones?
• ¿Qué etapas generan mayor tiempo de espera?
• ¿Cuántas variantes diferentes existen?
• ¿Dónde se está ejecutando el proceso de una forma distinta a la esperada?

Esta definición es importante porque determina qué información necesitaremos extraer después.

2. Convertir los datos SAP en un event log

Process mining necesita organizar la información como eventos.

De forma simplificada, un event log necesita permitir identificar:

• qué caso estamos siguiendo;
• qué actividad ocurrió;
• cuándo ocurrió;
• y, cuando resulte relevante, quién ejecutó la actividad.

El reto es que SAP no guarda necesariamente todo el proceso como una única secuencia lista para analizar. La información puede encontrarse distribuida entre documentos, posiciones, tablas maestras, registros de cambios y otras estructuras.

Ingvaldsen y Gulla (2008) muestran esta complejidad utilizando como ejemplo procesos relacionados con solicitudes de compra, órdenes de compra y facturas. Por eso, extraer datos no es todavía hacer process mining.Primero hay que construir correctamente el conjunto de eventos que representa el proceso que queremos estudiar.

3. Limpiar los datos antes de interpretar

Los datos también necesitan preparación. Roest (2012) incluye una etapa específica de preprocesamiento y limpieza antes de ejecutar el análisis.

Puede ser necesario tratar situaciones como:

• actividades duplicadas;
• casos incompletos;
• registros inconsistentes;
• identificadores incorrectos;
• eventos que no pertenecen al alcance;
• datos que no permiten reconstruir correctamente el proceso.

Esta etapa es especialmente importante porque un problema en la preparación puede terminar produciendo una representación incorrecta del proceso.

Una visualización convincente basada en datos mal construidos sigue siendo una conclusión poco confiable.

4. Identificar variantes del proceso

Una vez construido el event log, podemos empezar a observar las rutas que realmente siguen los casos. Puede existir una variante dominante y varias excepciones. O puede ocurrir lo contrario: decenas o cientos de formas distintas de ejecutar aparentemente el mismo proceso.

La cantidad de variantes por sí sola no permite decir que el proceso sea malo. Pero sí abre preguntas relevantes.

• ¿Por qué esta actividad aparece solo en determinados casos?
• ¿Por qué algunas órdenes regresan a una etapa anterior?
• ¿Por qué ciertos flujos necesitan más aprobaciones?
• ¿Existe una diferencia por área, centro, proveedor o tipo de operación?

El valor aparece cuando la variante deja de ser simplemente una anomalía visual y empieza a tener una explicación de negocio.

5. Detectar dónde se concentra el tiempo

Process mining también puede incorporar la dimensión temporal. Esto permite estudiar cuánto tiempo transcurre entre actividades o comparar recorridos con duraciones diferentes.

Un proceso puede tener pocas etapas y aun así ser lento. Otro puede tener más actividades, pero ejecutarse sin grandes esperas. Por eso, contar pasos no basta.

Conviene identificar dónde se concentra realmente el tiempo. Eso puede ayudar a separar un problema tecnológico de situaciones como:

• espera por aprobación;
• dependencia de información externa;
• retrabajo;
• falta de recursos;
• actividades manuales;
• excepciones del proceso.

6. Una desviación no es automáticamente un error

Este punto es especialmente importante. Si un proceso real no coincide con el modelo esperado, no debemos asumir inmediatamente que los usuarios están trabajando mal.

Una desviación puede existir porque el proceso documentado está desactualizado. También puede representar una necesidad legítima que nunca fue incorporada al modelo. O puede tratarse de una excepción necesaria para determinados clientes, productos o situaciones. Por eso el análisis necesita combinar datos + conocimiento del proceso.

Roest (2012) destaca precisamente que la interpretación funciona mejor cuando el especialista en process mining trabaja junto con los responsables que conocen el contexto operativo.

7. El análisis no termina cuando aparece el gráfico

Una visualización puede mostrar que existe un cuello de botella. Pero todavía queda por responder:

¿por qué ocurre?

El dato observado puede decirnos que una etapa tarda más.

La causa podría encontrarse en:

• SAP;
• una aprobación de negocio;
• información incompleta;
• un procedimiento manual;
• una integración;
• un tercero;
• una regla interna;
• falta de capacitación;
• diseño del proceso.

Process mining ayuda a localizar dónde investigar. No sustituye el análisis del negocio.

Qué conviene revisar antes de modificar SAP

Hallazgo	Pregunta que deberíamos hacer
Muchas variantes	¿Son necesarias o aparecieron por falta de estandarización?
Actividad repetida	¿Existe retrabajo o corrección frecuente?
Tiempo alto entre etapas	¿El problema está en SAP o en una espera operativa?
Diferencia entre áreas	¿Existe una necesidad legítima o procesos inconsistentes?
Muchas modificaciones	¿Los datos iniciales son incompletos?
Pasos fuera del flujo esperado	¿Existe una excepción no documentada?
Proceso diferente al diseño	¿Debe corregirse la ejecución o actualizarse el diseño?

Esta revisión ayuda a evitar un error frecuente:

modificar SAP antes de entender qué está originando realmente el problema.

De opiniones sobre el proceso a evidencia de ejecución

Cuando una empresa pregunta cómo funciona determinado proceso, distintas personas pueden describirlo de maneras diferentes. Cada área conoce la parte que ejecuta. Los registros del sistema aportan otra perspectiva: qué actividades quedaron registradas y en qué secuencia ocurrieron.

Eso no reemplaza las entrevistas, los talleres ni la experiencia de los usuarios. Las complementa.

El resultado puede ser una visión más completa:

lo que debería pasar + lo que las personas dicen que pasa + lo que los datos muestran que pasó.

A partir de esa comparación pueden tomarse decisiones con mayor evidencia.

¿Tus procesos SAP funcionan como crees que funcionan?

Antes de desarrollar una nueva funcionalidad o modificar un proceso existente, conviene entender qué está ocurriendo realmente en la operación. En Altamira Technology realizamos Assessment TI para revisar procesos, aplicaciones, integraciones y brechas antes de definir cambios tecnológicos.

Referencias

Ingvaldsen, J. E., & Gulla, J. A. (2008). Preprocessing support for large scale process mining of SAP transactions. En A. ter Hofstede, B. Benatallah, & H.-Y. Paik (Eds.), Business Process Management Workshops (Lecture Notes in Computer Science, Vol. 4928, pp. 30–41). Springer.

Roest, A. (2012). A practitioner’s guide for process mining on ERP systems: The case of SAP order to cash [Master’s thesis, Eindhoven University of Technology].

Štolfa, J., Štolfa, S., Slaninová, K., & Martinovič, J. (2014). An application of process mining by sequence alignment methods to the SAP invoice process example. DATESO 2014, 81–90.