Cuando hablamos de reingeniería de procesos nos referimos tradicionalmente a aplicar metodologías que parten de la teórica situación actual de los procesos, para identificar ineficiencias en los mismos, y diseñar finalmente un proceso objetivo en el que todos esos problemas estén corregidos.
Si se lees el párrafo anterior de nuevo, posiblemente caigas en la cuenta de que me estoy refiriendo al punto de partida como “teórica” situación actual de los procesos, y no como situación actual de los procesos sin más. El motivo de que lo considere así, tiene que ver con cómo modelamos esa situación inicial. Se trata de procedimientos que implican completado de cuestionarios por los responsables de los procesos, entrevistas con los mismos para entender su funcionamiento, trabajo de campo, y documentación final de una representación de los procesos en cuestión. Hablamos, por tanto, de la observación y entendimiento de una situación, lo que implica una doble subjetividad: La referida a las personas que nos están contando el funcionamiento, y la propia de la persona que lo documenta.
Y si estamos de acuerdo en que ese modelado inicial tiene que ver con “lo que creo que está pasando”, más que con “lo que realmente está pasando”, estaremos también de acuerdo en que nuestro punto de partida no parece ser el mejor posible.
¿Y no hay otra forma de proceder para abordar una reingeniería? La buena noticia es que sí, la solución se llama Process Mining, y utilizándola estaremos seguros de que las representaciones analizadas se corresponden al 100% con los procesos reales que están ocurriendo.
Filosofía tras del minado de procesos
Existen en el mercado varios vendors que ofrecen herramientas de Process Mining, pero en esencia todas se basan en la información contenida en los tradicionales repositorios de datos de los sistemas (típicamente tablas entidad-relación, ficheros estructurados, logs de programas…) para obtener con ella representaciones gráficas de los procesos que soportan el core de negocio. Puesto que son los datos la única fuente utilizada para realizar este modelado, podemos estar seguros de que la representación es totalmente fidedigna. Y no sólo eso: cada representación de un proceso contiene la cadena de valor más común, pero también las cadenas de valor alternativas que, si bien ocurren un número menor de veces, son igualmente válidas cuando tratamos de identificar problemas. Y, es más, es precisamente en esos “caminos B”, en los que suelen encontrarse la mayoría de ineficiencias y fallos.
Como complemento, prácticamente todas estas herramientas suelen ofrecer motores de acciones para, una vez identificadas las ineficiencias, sugerir y automatizar el procedimiento para corregirlas. De esta forma, la reingeniería de procesos se hermana de forma natural con la inteligencia artificial, el RPA y la monitorización predictiva.
El proyecto
Es importante entender que la minería de procesos es un fin para obtener una ganancia de eficiencia y que debe aplicarse sobre un proceso (o set de procesos) concreto. Pero no deberíamos pensar en Process Mining como una herramienta de arquitectura que “está ahí”, y que podemos usar recurrentemente para eficientar lo que sea, cuando sea y cómo sea.
En este sentido, un proyecto no consiste en implantar la herramienta, sino en identificar ineficiencias sobre un proceso concreto. Finalizado el proyecto, podríamos decidir comenzar uno nuevo para minar sobre un proceso distinto, o podríamos abordar la corrección de las ineficiencias que surgirían tras ese primer proyecto. De esta forma, hablaríamos de “Bloques de Process Mining” (Un proyecto = Un Bloque = Minado sobre un proceso concreto).
El plazo para ejecutar un proyecto definido de esta forma (un bloque) es de 3 meses, si bien podría plantearse como proyecto inicial en un cliente una prueba de concepto de 6 semanas.
Sea de una u otra forma, los resultados que obtendremos serán sorprendentes para nosotros y, lo que es más importante, mucho más sorprendentes para nuestro cliente.