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.

Cambio en el modelo del integrador de ERP

Hoy en una conversación con un preventa de un partner de Microsoft me comentaba que la apuesta sin complejos que está haciendo Microsoft por los modelos SaaS de despliegue de sus sistemas de gestión (ERPs, CRMs, etc.) está provocando que sus partners de integración deban cambiar de modelo de negocio.

De vender largos proyectos de configuración y adaptación de los productos implantados (que provocaban clientes cautivos) a actuar más como consultores de cómo aprovechar las funcionalidades estándar de esos productos y meterse en la definición de procesos y mejoras en los mismos.

Tiene sentido, se me ocurren algunas razones:

  • Los clientes buscan implantaciones rápidas. La velocidad creciente a la que van sus negocios no les permite proyectos largos.
  • En los modelos SaaS de despliegue la personalización de producto está generalmente penalizada.
  • Los clientes cada vez saben más sobre implantaciones ERP. No se repiten errores.

¿Qué opináis? ¿Algo que matizar?

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 extraño caso del PM por minutos

Gantt comprimido

El amigo de un amigo me ha explicado un divertido caso (o no, según se mire) y que comparto a continuación.

Resulta que un proyecto de implantación de un ERP que tiene que arrancar, sí o sí, a principios del año que viene, ve retrasado su inicio por causas diversas, por lo que una planificación que inicialmente eran unos razonables ocho meses se tiene que comprimir a menos de cinco.

Para ello se ha realizado ajustes: a la baja en el alcance (menos países, algún proceso se deja para más adelante, etc.) y al alza en la intensidad del proyecto (más dedicación del equipo en menos tiempo). Bueno, no de todo el equipo, porque resulta que el cliente quiere recortar proporcionalmente la dedicación del Project Manager, con lo que que ésta queda en un día por semana.

Y es un error, un grave error, por varios motivos:

  • Con una dedicación de menos de un día por semana, mientras llegas y te explican lo que ha pasado durante la semana, sólo te queda tiempo para despedirte hasta la semana que viene, por lo que al final el PM se convierte en un lastre. Pierde totalmente su sentido.
  • En un proyecto con tanta intensidad, la velocidad tan alta a la que pasan las cosas (y cosas en estos proyectos pasan, creedme) requiere respuestas muy rápidas, sin capas intermedias, entre lo que pasa y el PM.
  • El PM pasa gradualmente a intervenir reactivamente, más como apagafuegos, que gestionando el proyecto. El proyecto siempre irá por delante.
  • Desde el punto de vista del PM es también muy ineficiente porque acaba fragmentando su dedicación durante la semana – por goteo y si está en más proyectos acaba en una multitarea excesiva.

Por eso le he dicho a mi amigo que a su vez le transmita a su amigo de que debe convencer a su cliente de que, en realidad, cuando aumenta la intensidad de un proyecto, aunque se acorte su calendario, lo que se requiere es aún más dedicación del PM.

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.

Netsuite. Crónica desde el SuiteWorld 2017.

Ben Kepes, reconocido analista de tecnología, hace una excelente crónica de las novedades anunciadas por Netsuite en la SuiteWorld 2017, su reunión anual para usuarios.

Muy resumidamente:

  • La adquisición por Oracle ha proporcionado un gran impulso a la expansión de Netsuite: se doblan los data centers, se pasa de presencia con oficina en 10 países a 23 y se aprovechan de la red mundial de centros de desarrollo de Oracle.
  • Se anuncia SuiteSuccess, verticalizaciones del producto con las mejores prácticas sectoriales, por ahora para Advertising, media, publishing,  Financial technology, Manufacturing, Nonprofit, Retail, Service-based businesses, Software/internet y Wholesale distribution.
  • Se lanza SuitePeople, solución de gestión de RRHH (con nómina sólo para EEUU).
  • No se va a competir con las soluciones de Oracle. Tienen targets diferentes.

En Nodotic llevamos siguiendo a Netsuite desde el 2009 y ahora que hemos empezando a participar en dos implantaciones  ya avanzo que tenemos buenas sensaciones.

Teoría de las restricciones. La manera de gestionar sistemas complejos.

Este video de Vector Consulting Group me ha parecido muy interesante por la manera tan didáctica de mostrar que un sistema con un mínimo de complejidad no puede gestionarse con el enfoque lineal y simplista de la cuenta de resultados.

Hay más videos, tan interesantes o más, en su página de YouTube.

Por cierto, la traducción de constraint por restricción no me acaba de gustar. ¿Conocéis alguna mejor?

¿Hemos de hacerle caso a Gartner y similares?

Gartner MQ for Dummies

Acabo de leer en LinkedIn este artículo de Kevin Hunt, Senior Account Executive de  MicroStrategy, sobre el último MQ de Gartner de plataformas BI y que ya comentamos en su día en este blog.

El señor Hunt es muy duro en su artículo y subraya, entre otras cosas, el conflicto de intereses que supone que el evaluador cobre de los evaluados. No se queda ahí, sino que se pregunta sobre el verdadero valor que aportan los informes de Gartner y otros (Forrester, BARC, …) y las consecuencias de no salir en el cuadrante.

También se pregunta el porqué se les hace caso y afirma que el verdadero poder de Gartner es lo que se llama el «social proof», el mecanismo psicológico por el cual, subconscientemente, los individuos nos sentimos mejor opinando como los demás.

Lo llega a comparar, y esto me hace particularmente gracia, con las risas enlatadas que hay en algunos programas de televisión.

El artículo se puede leer directamente el LinkedIn o en una copia que podéis encontrar aquí.

 

Esta es una polémica recurrente. Cada vez que Gartner saca un MQ alguien se queja o le quita importancia. En nuestro caso siempre lo usamos con mucha precaución y normalmente porque el cliente lo menciona en algún momento.

Reconozco que puede ser útil para tener una primera impresión sobre who-is-who en un determinado mercado pero con muchas limitaciones, sobre todo si lo intentas utilizar en entornos de mediana empresa o locales – se puede dar el caso de que un producto que es líder indiscutible en su país no salga en el MQ, por eso, por local – ¿Lo vas a descartar entonces?.

Otra queja frecuente es su dificultad de interpretación directa. No se pueden sacar conclusiones automáticas por el cuadrante donte hayan metido a un producto y creo que es más útil y significativo ver cómo se ha evolucionado un producto, él mismo por los cuadrantes y en relacion a sus competidores. En nuestra entrada sobre el MQ de plataformas BI ya pusimos un gráfico que ilustra muy bien esto que digo:

 

Y para acabar, si os interesa seguir profundizando en el tema os recomiendo este artículo donde explican como leerlo y este, del propio Gartner, donde dan pistas para no equivocarse al interpretarlo.

***

Si este contenido te ha parecido interesante y no quieres perderte otros similares o mejores, te invito a suscribirte a nuestra lista de correos en el icono de la derecha o directamente desde aquí

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