Retrospectiva de un proyecto

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.

Vender más, más rápido y con más margen. It’s the process, s*!

El título de este texto, en cualquiera de sus variantes, resume los objetivos de cualquier organización comercial. Y para alcanzar esos objetivos nos vamos a encontrar multitud de enfoques, estrategias, técnicas, conjuros, recetas,… Unos funcionan, otros menos pero, siempre en todos hay un denominador común: has de mejorar tu proceso de ventas.

Porque para poder gestionar más oportunidades, tener mejores ratios de conversión, acortar tu ciclo de ventas, bajar tus costes de transacción, … tienes que tener en marcha un proceso que funcione, es decir que sea medible, predecible, eficiente, de calidad y que cumpla las normativas vigentes, internas y externas.

Para mejorar un proceso se tiene que empezar conociéndolo y ver dónde duele y una manera, la tradicional, es sentarte con todo el que participe y analizarlo. Buena suerte con eso, es como se ha hecho siempre y ya sabemos lo que pasa: horas de reuniones, produces un visio y/o un powerpoint y a lo mejor levantas un proyecto de reingeniería de procesos pero que ya empieza con mal pie porque el análisis del que parte es estático, parcial y subjetivo. Y, peor aún, a la velocidad que va todo hoy en día, para cuando empieces el proyecto de mejora, el proceso ya es otro, te habrá cambiado. Se te ha movido la foto que hiciste.

La buena noticia es que hay otra manera de abordar la mejora de un proceso: En lugar de creerte lo que te cuentan obsérvalo por ti mismo con Process Mining.

Process Mining es una práctica novedosa que utiliza tecnologías de analítica de datos e inteligencia artificial para interpretar las trazas que los procesos dejan en los sistemas de informacion que les dan soporte – es decir, la realidad de lo que pasa, no lo que te cuentan que pasa.

Utilizar Process Mining para mejorar los procesos comerciales te permitirá conocer tus métricas comerciales dinámicamente y en relación al proceso, en contraposición a la manera tradicional de obtener las métricas por estados del embudo comercial. ¡Es como pasar de ver fotos a verlo en video!

Por ejemplo, así se ve en un caso donde se utiliza Salesforce para la gestión de oportunidades:

Parece interesante, ¿no?

Por cierto, en Nodotic llevamos más de tres años en proyectos de Process Mining y unos cuantos más en proyectos de mejora y reingeniería de procesos. Te podemos contar cosas interesantes.

Process Mining ¿Con qué proceso empiezo?

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 timestampsfecha-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.

El Process Mining NO es utilizar BI para analizar procesos.

Process Mining NO es BI para procesos

Una pregunta recurrente cuando explicamos qué es Process Mining a nuestros clientes es: ¿Pero eso que me estás explicando no es un BI o un Data Mining para procesos?

Y hay que reconocer que, depende cómo lo expliques, se puede confundir. Pues para deshacer esa confusión vamos a intentar explicar algunas diferencias entre usar Process Mining y BI/Data Mining para analizar procesos:

  • El análisis de procesos con una herramienta BI parte de fotos estáticas, sin la historia del proceso. El análisis con Process Mining se realiza con la historia (traza) de cada instancia del proceso. Lo que hace más fácil determinar los casos problemáticos y el origen del problema (root analysis).
  • Data Mining busca y analiza patrones de datos, Process Mining patrones de procesos.
  • Process Mining es cómodo para analizar excepciones, Data Mining requiere identificar, y en su caso excluir, los outliers porque distorsionan su análisis.
  • Una herramienta BI requiere definir y preconfigurar un modelo de datos (dimensiones, ejes, segmentos, etc.). La herramienta de Process Mining trabaja con el log, con una estructura base mínima (id de instancia, id de evento y time stamp) sin prejuzgar el modelo de datos.
  • Y por último, una diferencia muy importante a la hora de decidirse a empezar un proyecto: el despliegue de una herramienta de Process Mining en general es más rápido porque requiere infraestructuras y capacidades técnicas más ligeras, además de un análisis preliminar de los datos menos exigente para empezar a obtener resultados.

¿Qué opináis? ¿Me dejo o estáis en desacuerdo con algo?

Si te interesa la práctica de Process Mining puedes encontrar más info en Process Mining Profesional.

Beneficios del Process Mining

La práctica del Process Mining tiene relevantes ventajas sobre los enfoques tradicionales de Entrevistas+modelado As Is en los proyectos de mejora y reingeniería de procesos:

  • Menor impacto en el día a día de la organización, requiere menos recursos personales, no hay que entrevistar a todas las personas que participan en el proceso analizado.
  • No se depende de que haya un gran conocimiento previo sobre el proceso porque se trabaja sobre la realidad del mismo.
  • La información obtenida, sin filtros ni interpretaciones de entrevistas,  hace que el punto de partida sobre el que se hace el análisis sea más fiable.
  • Es aplicable a procesos muy complejos, donde sea suficiente identificar puntos de mejora localizados, que no dependan de un conocimiento completo del modelo del proceso.
  • Coste contenido: El trabajo de campo es reducido, se pueden utilizar herramientas sin coste y el equipo de proyecto es de menor tamaño que con un enfoque tradicional de Entrevistas+modelado AsIs.
  • Puede acelerar iniciativas de RPA (Robotic Process Automation) ya que permite localizar rápidamente los puntos donde estas iniciativas son más beneficiosas (cuellos de botella, disconformidades, segregación de responsabilidades, etc.)
  • Por todo lo anterior es posible conseguir que los proyectos de mejora de procesos se acorten y se obtengan mejores resultados.

 

¿Te ha resultado interesante? ¿Crees que podrías aprovechar el Process Mining en la mejora de tus procesos? Nos gustaría oir tu opinión en los comentarios. Y si necesitas una orientación más detallada no dudes en contactarnos directamente, nos encantará intercambiar opiniones y experiencias contigo.

Aplicaciones del Process Mining

El Process Mining, utilizando herramientas tecnológicas que aplican algoritmos avanzados de descubrimiento de procesos y análisis masivo de datos, permite encontrar patrones de comportamiento y estadísticas de los procesos analizados.

De esta manera es posible identificar los puntos problemáticos de un proceso (cuellos de botella, redundancias, reglas de decisión, incompatibilidades, tareas no autorizadas, correlaciones, …) para poder diseñar las mejoras necesarias en el proceso.

Esquemáticamente:

 

 

Pero no en todos los entornos es aplicable esta práctica. Donde mejor encaja sería en:

  • Entornos con procesos intensivos: call centers, servicios financieros, seguros…
  • Entornos con procesos muy poco estructurados y complejos: hospitales por ejemplo
  • Entornos con problemática de control y compliance: procesos de compra descentralizada, servicios financieros, seguros, …
  • Entornos donde es crítico el control de eficiencias y cumplimiento de planificaciones: cadenas de producción por ejemplo

 

¿Te reconoces en alguna de estas problemática? ¿Te ha resultado interesante? ¿Crees que podrías aprovechar el Process Mining en la mejora de tus procesos? Nos gustaría oír tu opinión en los comentarios. Y si necesitas una orientación más detallada, no dudes en contactarnos directamente, nos encantará intercambiar opiniones y experiencias.

 

Process Mining. Seguimos

 

Ya empezamos a obtener resultados en nuestros proyectos de Process Mining. Los cuellos de botella, puntos calientes del proceso, recursos sobrecargados, … empiezan a aflorar de manera que podría parecer magia. Pero de magia nada, detrás ha habido un trabajo importante de aprendizaje de la metodología, evangelización a los decisores, obtención de la información, depuración de logs, interpretación de resultados, …

Y podemos confirmar lo que te explican en los cursos y artículos: lo difícil es obtener un log de calidad, y si lo consigues ya tienes medio proyecto hecho. En este caso nos las prometíamos felices porque el log salía de una herramienta BPM pero a la hora de la verdad hemos tenido que depurarlo mucho.

Para que os hagáis una idea, hemos tenido que trabajar con logs de 3Gb y más de un millón de filas, que inocentemente intentabas abrir con Excel y se te cuajaba el ordenador. Suerte que conocíamos PowerQuery de otros proyectos y eso nos ha salvado.

Como herramientas de Mining estamos utilizando ProM y Fluxicon DISCO (la animación que encabeza esta entrada está hecha con DISCO).

Nos queda bastante por hacer porque el proceso que estamos analizando es complejo (lo que se ve en la animación es un modelo simplificado), pero es gratificante ver que el esfuerzo de tantos meses está obteniendo sus frutos. Seguiremos contando.

Si quieres saber más sobre el tema, en Processmining.pro tienes una introducción.

Process Mining. Empezamos

Iniciamos con esta entrada una serie de posts sobre Process Mining. Una práctica que hemos empezado a desarrollar en Nodotic y en la que, en el momento de escribir estas líneas, ya estamos envueltos en dos proyectos, uno empezando y otro en fase piloto o prueba de concepto.

Pero empecemos por definir qué es Process Mining:

Process Mining es una práctica orientada a la mejora y optimización de procesos que combina metodologías y tecnologías de disciplinas como el BPM (Business Process Management) y el Data Mining.

La base de la práctica del Process Mining es la explotación de la información contenida en las trazas que los procesos dejan en los sistemas de información que son utilizados en dichos procesos.

El conjunto de esas trazas de un proceso se le conoce como el log de ese proceso. Por ejemplo, en el log de un proceso consistente en una secuencia de tareas estaría trazado, cada vez que se realiza una tarea, qué tarea sucede, quién la realiza y cuándo se produce dicha tarea, entre otros elementos de información.

El Process Mining aprovecha la información contenida en el log del proceso para descubrir, de forma experimental, las características reales del proceso, lo que está pasando en realidad.

En Nodotic creemos que nuestro consolidado offering de consultoría de mejora y reingeniería de procesos se va a ver enormemente enriquecido con esta práctica y en próximas entradas compartiremos nuestro punto de vista sobre los beneficios que nuestros clientes van a poder obtener mediante el Process Mining en la mejora de sus procesos. Permanezcan atentos 🙂

Mientras tanto nos puedes seguir en nuestro grupo de LinkedIn, en nuestra Web específica sobre el tema Process Mining PRO o en un vistazo puedes hacerte una idea con este gráfico:

 

¿Te ha resultado interesante? ¿Crees que podrías aprovechar el Process Mining en la mejora de tus procesos? Nos gustaría oir tu opinión en los comentarios. Y si necesitas una orientación más detallada no dudes en contactarnos directamente, nos encantará intercambiar opiniones y experiencias.

Uso de cookies

Este sitio web y subdominios asociados utilizan cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pinche el enlace para mayor información.plugin cookies

ACEPTAR
Aviso de cookies