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.