Hemos acabado recientemente la primera fase de un proyecto de Process Mining que nos ha llevado casi un año. En el proyecto se planificó analizar 10 procesos, que fueron 11 realmente, y finalmente en 9 se llegó a análisis completos.
El proyecto no sólo iba de analizar procesos, también se trataba de introducir el concepto, «evangelizar» a las personas clave de la dirección y definir e implantar una metodología que hiciese más fácil integrar la orientación a la mejora de procesos en las prácticas de la organización.

Consideramos que es una buena idea realizar una «retrospectiva» cuando acabamos un proyecto (en este caso una fase) y repasar cómo ha ido, qué se debería haber hecho de manera diferente, qué decisiones deberían haber sido otras, etc. Todo, claro está, con el propósito de ganar en conocimiento y que el próximo proyecto salga mejor.
Pues toca ahora hacer la retrospectiva del proyecto citado y me ha parecido interesante compartirla aquí (no todo se puede contar pero al menos una buena parte sí).

Ahí vamos:

Logros:

1. Difusión y Evangelización.
   Un objetivo importante del proyecto era demostrar el valor que podía aportar la aplicación de Process Mining en las iniciativas de mejora de los procesos de la organización. Y para ello era importante explicar el concepto y convencer a los elementos decisores e influyentes dentro de la organización. Lo abordamos en dos fases. Una inicial con workshops para explicar el concepto, aplicación y beneficios del Process Mining, y una segunda donde para cada proceso se enseñaba cómo se podían aprovechar los resultados obtenidos para mejorar el proceso. No conseguimos convencer a todos pero sí a una gran mayoría.
2. Implantación de metodología y práctica
   Partiendo de la metodología propia que aportábamos conseguimos adaptarla a la casuística específica y detalle requerido por nuestro cliente. Puede parecer extraño pero podemos decir con orgullo que el cliente podrá seguir solo aunque no estemos nosotros, si dedica los recursos necesarios claro.
3. Imagen del sponsor del proyecto como proveedor de valor para negocio.
   No era un resultado buscado pero logramos que la imagen de nuestro sponsor en la organización se viese reforzada como generador de innovación y aportador de soluciones de valor al negocio. Era muy gratificante ser testigos de cómo las áreas de negocio felicitaban a nuestro sponsor cuando acabábamos los workshops de puesta en común de resultados y diseño de plan de acción.
4. Resultados «accionables» en la mayoría de procesos analizados.
   De manera desigual pero en casi todos los procesos se llegó a conclusiones que permitieron levantar un plan de acciones concretas de mejora. E importante: la mayoría de esas acciones salieron de las propias áreas de negocio.
5. Identificación de carencias en cómo se registraban las transacciones en los sistemas. Otro resultado no buscado pero se llegó a identificar algún caso donde no se estaba trazando correctamente la información del proceso. Algo que resultó muy relevante por temas regulatorios de trazabilidad.

Lecciones aprendidas

1. Involucrar más y mejor al equipo técnico que extrae los logs de los sistemas utilizados por los procesos.
   Hay que dedicarles más tiempo, darles más contexto, no sólo el formato del archivo y cuatro ideas. Hay que explicar el propósito e incluso compartir con ellos los problemas, no sólo técnicos, que te encuentras cuando estás preparando el log para que sea viable. Te ahorrarás tiempo y conseguirás un log de mayor calidad. Lo aprendimos algo tarde y eso nos supuso un desgaste que se podría haber reducido.
2. Añadir a las métricas del proceso las dimensiones analíticas de negocio.
   Desde el primer momento ya tienes que estar pensando en cómo vas a medir el proceso desde una perspectiva de negocio. Las consabidas métricas que valen para cualquier proceso (tiempos, colas, rework, automatización, etc.), las has de intentar encuadrar en el modelo analítico que se utiliza por los protagonistas del proceso. Por ejemplo si haces un análisis de tiempos de un proceso de atención al cliente es necesario que puedas segmentar ese tiempo por el tipo de petición, el tipo de cliente, el importe asociado a la petición, etc. Esto tiene impacto directo en como enriqueces y procesas el log. Este punto es importante para poder hacer comparativas de rendimiento y cumplimiento entre segmentaciones.
3. Incorporar visión económica al análisis.
   Un análisis se valora de manera distinta entre negocio (euros) y analistas (tiempos, cantidades) por lo que se ha de intentar añadir contexto económico a cualquier métrica. Por ejemplo si encuentras que en el 2% de los pagos no se respeta la segregación de funciones has de aportar también el valor en Euros de ese 2% de pagos. Esto vuelve a tener impacto directo en como enriqueces y procesas el log.
4. La presentación del análisis de un proceso es diferente según el destinatario. El reporting «ejecutivo» del proyecto se presenta de manera diferente a como se presenta el «operativo». Los resultados del análisis del proceso de order To Cash se muestran al CFO de una manera diferente a como se muestra al business analyst del proceso o al individuo que está haciendo las remesas de cobro.

Próximos retos:

Para la segunda fase nos hemos propuesto las siguientes acciones de mejora:

1. Conseguir mejores logs:
   • Añadir al log más info de dimensiones analíticas para así conseguir luego mejores métricas y la posibilidad de efectuar benchmarks o comparativas.
   • Cuantificar (valor y/o coste) en cada caso. No en todos los procesos será directo.
   • Añadir eventos que se produzcan en sistemas complementarios al principal.
2. Extender la práctica a más sistemas. En primera fase trabajamos con tres sistemas (una aplicación en un BPM más o menos estándar y dos aplicaciones desarrolladas a medida). En segunda fase queremos añadir más sistemas, lo que requerirá una readaptación de la metodología.
3. Estandarizar y automatizar, al menos en parte, los informes de presentación de análisis. En primera fase fue una parte muy manual y que creemos que se puede mejorar bastante.
4. Buscar una manera más efectiva y completa de traducir a acciones de mejora el resultado del análisis. Lo veníamos haciendo de manera un tanto espontánea en los workshops de presentación de resultados. Hay que buscar la forma de hacerlo con una dinámica de workshop que genere más y mejores ideas.
5. Incorporar la posibilidad de comparar el mismo proceso en dos momentos diferentes del tiempo. Esto será muy importante para evaluar el resultado de las acciones implementadas en primera fase.

Hasta la próxima. Espero que haya resultado de interés.

Cuando empezamos un nuevo proyecto de Process Mining, o de mejora de procesos en general, de las primeras cuestiones que surgen destaca la de ¿Con qué proceso empiezo?.

La respuesta a esta pregunta es importante, tanto que puede condicionar el éxito del proyecto. En esta entrada queremos compartir algunas reflexiones que nos ayudarán a fijar criterios y pistas para escoger acertadamente esos procesos y empezar ya con buen pie el proyecto.

(1) Que el log tenga los datos imprescindibles

Es evidente de que si queremos analizar un proceso debemos disponer de los datos necesarios para ello, por tanto deberemos asegurar que el log de nuestro proceso candidato es válido y que tiene al menos estas columnas:

• ID de instancia: Identificador único de cada caso. Por ejemplo, en un proceso de solicitud de un préstamo sería el nº de solicitud. En otros procesos será el nº de pedido, el nº de expediente, etc.
• ID de evento: la acción o actividad realizada sobre el caso. Siguiendo el ejemplo anterior, la recepción de la solicitud. La creación de un pedido, el alta de un expediente, etc.
• Timestamp: Cuándo se produce el evento. Permite ordenar la secuencia de eventos y por tanto reconstruir el flujo temporal del proceso. Idealmente nos gustaría tener dos timestamps,  fecha-hora de inicio y fecha-hora de fin del evento, para poder saber los tiempos de inactividad entre dos eventos consecutivos. Si sólo disponemos de una, lo habitual es interpretarla como el momento en el que se inicia el evento.

Este es un criterio excluyente más que de priorización. Si no se cumple, el proceso no se puede analizar.

(2) El proceso es estable

El proceso candidato debe haber estado funcionando de manera estable durante al menos 2-3 ciclos medios de ejecución de una instancia. Es decir si un proceso dura de media un mes, necesitamos que el proceso y el sistema de información utilizado no haya cambiado de manera sustancial en 2-3 meses.

Recuerdo que en un proyecto empezamos el análisis de un proceso y nos encontramos un flujo mucho más complicado y sucio que el que nos esperábamos atendiendo al conocimiento previo que teníamos. Al final descubrimos que había habido cambios en la aplicación BPM utilizada por el proceso y que teníamos mezclados en el log trazas del proceso antiguo con trazas del nuevo.

(3) Disponemos de suficientes ciclos

Debemos asegurar que tenemos información que nos permita analizar ciclos completos de un proceso, por ello deberemos buscar procesos de los que podamos disponer logs con rangos temporales que abarquen al menos 2-3 ciclos medios de ejecución de una instancia.

Es posible analizar (con limitaciones) ciclos incompletos (con instancias ya empezadas o que no han acabado) pero, al menos para empezar, es mejor hacerlo asegurando que tenemos ciclos completos.

(4) Acceso a conocedores del proceso

Cuanto mejor se conozca el proceso funcionalmente más rápido y mejor se podrá enfocar e interpretar el análisis. Por lo tanto se deberán priorizar los procesos de los que dispongamos un mejor acceso a este conocimiento funcional, ya sea porque está bien documentado o, mejor, porque tenemos acceso a un process champion.

Hay quien es partidario de empezar los análisis a ciegas, es decir analizando a ver qué se descubre. Es un enfoque tentador porque, si sale bien, le permite a uno lucirse mostrando como por arte de magia cómo es un proceso. La trampa oculta en este enfoque es que sin un conocimiento previo, aunque sea general, del proceso, hay riesgo de hacer una interpretación o llegar a conclusiones que luego el conocedor funcional del proceso te desmonte. Algo que puede ser demoledor para la credibilidad del equipo de proyecto.

(5) Procesos con impacto

Hay que priorizar procesos de los que ya se sepa que con su mejora se producirán los mayores beneficios. De esta manera el proyecto gana puntos dentro de la organización ya desde el principio.

Por ejemplo, en un proyecto reciente escogimos para empezar un proceso de negocio sobre un proceso de gestión interna. Con el primero era más fácil mostrar los beneficios que con el segundo (lo que no quiere decir que fueran necesariamente mayores).

Dentro de este bloque, otro criterio que se puede utilizar es escoger procesos que ya estén en proceso de mejora y donde las técnicas de Process Mining puedan ser un acelerador de esas mejoras.

Por ejemplo, en un cliente escogimos un proceso administrativo, intensivo en procesado documental y tareas humanas repetitivas, que se había decidido automatizar mediante robots de software (RPA/RDA). Con Process Mining se podían identificar los puntos calientes del proceso donde la eficiencia se pudiera notar más, y por otro lado, poder comparar el proceso de antes con el de después de aplicar las mejoras.

Nota mental: el maridaje de Process Mining y RPA/RDA es un tema sobre el que hay que profundizar.

(6) Disponibilidad de atributos de segmentación

Se deben priorizar procesos con disponibilidad de mayor número de atributos o características relacionadas con el negocio.

En una visión clásica de Process Mining, aparte de analizar el proceso en sí mismo (flujo, cuellos de botella, reworks, etc.), es interesante poder segmentar el análisis por atributos del proceso. Por ejemplo, en un contact center disponer del dato de por dónde se originó el contacto (e.mail, teléfono, whatsapp, …) lo que permite un análisis diferenciado y más fino por subprocesos.

En una visión más avanzada, esos atributos, o en este punto quizá sea mejor llamarles características (features), se pueden utilizar para construir un modelo predictivo del proceso, por ejemplo para poder anticipar dónde va a acabar un proceso con un valor determinado de una característica.

O yendo más allá, utilizar el modelo de procesos para encontrar características (feature engineering) que puedan ser utilizados en técnicas de Machine Learning para definir modelos de comportamiento del proceso. Pero este es un punto que daría para otra entrada. Aquí lo dejo.

En conclusión, a la hora de empezar un proyecto de Process Mining, asegúrate de que empiezas con el proceso más adecuado. Aquí hemos dado algunas pistas que utilizamos en nuestros proyectos.