Caso de negocio de minería de procesos: cuatro cifras para Finanzas

Un caso de negocio de Process Mining ofrece a Finanzas cuatro cifras para evaluar: la magnitud del problema, el coste de resolverlo, el coste del piloto y el tiempo hasta obtener las primeras pruebas. Tres de ellas pueden calcularse a partir de una sola exportación de los datos de sus procesos. Si alguna cifra es todavía una estimación, indíquelo y señale cuándo la medirá.

Es difícil evaluar una solicitud para «incorporar Process Mining» porque no especifica un problema, una decisión ni una fecha para obtener pruebas. La mayoría de los casos que fracasan se basan en lo que alguien espera que produzca la herramienta, en lugar de en lo que realmente ocurre en el proceso. Por eso, esta página centra el caso en un solo proceso: qué se medirá, cuánto costará el cambio y cuándo se conocerán los resultados.

¿Qué cuatro cifras necesita un caso de negocio de Process Mining?

Indique las cuatro antes de defender cualquiera de ellas y explique en qué se basa cada una.

1. Magnitud del problema: cuánto le cuesta ahora el proceso, en una unidad que su empresa ya mida, como días de tiempo de ciclo, recargos por demora, días pendientes de cobro u horas de personal equivalente a tiempo completo (FTE). Utilice sus propios volúmenes y tiempos.
2. Coste de la solución: cuánto cuesta cambiar el proceso, no analizarlo. Cambiar una política y realizar una sesión de formación supone un trabajo distinto al de modificar un sistema; la estimación corresponde a quien sea responsable del cambio.
3. Coste del piloto: la licencia, el trabajo con los datos y el tiempo del personal interno necesario para establecer los hechos.
4. Tiempo hasta obtener las primeras pruebas: la fecha prevista para revisar un resultado y la métrica con la que lo evaluará.

Por lo general, tres de las cuatro cifras proceden del mismo lugar. Una exportación de datos del proceso permite conocer la magnitud del problema, el esfuerzo necesario para preparar los datos y el tiempo que lleva el análisis. El coste de la solución es la única cifra que depende de una decisión aún pendiente. Por eso, necesita una persona responsable y una fecha, no un número inventado.

Indique si cada cifra del caso es una medición o una estimación. Finanzas preguntará cuál es cuál, y será más difícil descartar un caso que responda a esa pregunta que uno con cuatro cifras contundentes sin una base visible.

¿Por qué pierden respaldo los casos de negocio de Process Mining?

Los casos rara vez fracasan porque una cifra sea incorrecta. Un caso de negocio de Process Mining fracasa cuando no hay nada que comprobar.

Solicitan una capacidad en lugar de plantear una decisión. «Obtendremos visibilidad de todo el proceso de pedidos a cobros» no indica a Finanzas qué está financiando ni cómo se evaluará el resultado. «Averiguaremos si el segundo paso de aprobación añade una semana a un tercio de los pedidos y presentaremos los resultados antes del 15 de noviembre» sí lo hace.

Se basan en porcentajes de referencia. Afirmar que Process Mining suele reducir el tiempo de ciclo en cierto porcentaje no dice nada sobre su proceso. Su propia referencia inicial resulta más útil, aunque sea menos llamativa.

No incluyen el trabajo con los datos. Extraer datos, identificar casos, ordenar las marcas de tiempo y configurar las actualizaciones lleva tiempo. Si el caso solo incluye la licencia, el coste del piloto queda infravalorado. Consulte primero el desglose de costes para conocer mejor cada partida.

Utilizan un promedio que oculta el problema. Un tiempo medio de gestión reparte una espera de cinco días entre todos los casos, por lo que la cifra parece pequeña y cualquier mejora también parece menor. Indique dónde se concentra el tiempo: en qué paso, en cuántos casos y durante cuánto tiempo. «Unos 12.000 pedidos por trimestre; aproximadamente un tercio no llega en la fecha prometida y se desconoce la causa» ofrece a quien revisa el caso algo que comprobar. «Ineficiencia significativa en la gestión de pedidos» no.

¿Qué resultados suelen ofrecer los proyectos de Process Mining?

Conocer qué pruebas se obtienen facilita la redacción del caso. El primer análisis de un proceso a partir de sus datos de eventos suele responder a preguntas como estas:

• Dónde se va el tiempo: el tiempo de espera por actividad junto al tiempo de trabajo dedicado a ella, para que se vea la diferencia.
• Con qué frecuencia se repite el proceso: número de bucles y retrabajos, incluidos los pasos que no aparecen en un modelo documentado.
• Por cuántas personas pasa un caso: número de traspasos entre equipos y sistemas.
• Cuánto varía el proceso: cuántas rutas distintas existen y qué proporción de casos sigue la más habitual.
• Dónde se incumplen las reglas del proceso: diferencias de conformidad con respecto al proceso previsto.
• Qué pasos podrían automatizarse: pasos de gran volumen, basados en reglas y con poca variación, respaldados por una referencia inicial medida.
• Cuánto esfuerzo requiere cada paso: tiempo por paso y por caso, para poder calcular el coste de un cambio propuesto.

Los resultados dependen del proceso y de los datos. Un registro con un ID del caso, una actividad y una marca de tiempo permite responder a las cuatro primeras preguntas. Las demás requieren más detalles y, en algunos casos, un modelo de referencia. Descubra cómo Process Mining analiza los datos de sus procesos y, si los datos aún no se pueden utilizar, la ruta de inteligencia explica qué debe estar preparado primero.

Conviene decirlo claramente: la herramienta no le da la respuesta. Le aporta pruebas, que luego puede utilizar para elaborar un caso de negocio. Ninguno de esos resultados indica cuánto vale un cambio, si un paso debería existir o cuánta capacidad puede liberar realmente su equipo. Esas siguen siendo decisiones de negocio, y resulta más fácil tomarlas cuando ya se cuenta con mediciones. Los beneficios de Process Mining dependen del alcance de los cambios que respalden esas decisiones.

Si el registro solo abarca una parte del proceso o del periodo, indíquelo junto a las cifras. Una medición parcial sigue siendo una prueba, siempre que el lector sepa qué incluye y qué deja fuera.

¿Cómo calcular los beneficios a partir de sus propias mediciones?

El tamaño del problema solo se convierte en un beneficio cuando se explica qué cambiará. El valor del Process Mining depende de las decisiones que cambian a partir de los datos. Por eso, vincule el caso con una decisión que su organización deba tomar. Para justificar la inversión en Process Mining, dos modelos cubren la mayoría de los primeros casos:

Efectivo o capital de trabajo:

días reducidos × casos afectados × valor por día y caso × coste del capital

Capacidad:

horas reducidas por periodo × coste por hora, incluidos todos los conceptos

Tenga claras estas tres distinciones:

• Use una unidad que su empresa ya utilice. Exprese el beneficio en días de tiempo de ciclo, recargos por demora evitados, reducción del DSO u horas recuperadas. La «eficiencia» por sí sola no se puede verificar.
• Distinga el efectivo de la capacidad. Liberar capacidad no genera efectivo por sí solo. Indique si el valor proviene de atender más volumen con el mismo equipo o de una decisión sobre la plantilla, y quién toma esa decisión.
• Señale la suposición que menos confianza le inspira. Indique qué parte de la estimación es menos sólida y cómo la comprobará.

Una línea de base medida facilita defender el resto del cálculo. Si las horas se obtuvieron de los datos de eventos de su organización, la única suposición pendiente es el porcentaje de reducción, una cifra que cualquier persona revisora puede cuestionar. Un beneficio basado en una línea de base supuesta y una reducción también supuesta rara vez resiste el escrutinio. Si no puede defender un porcentaje de reducción, indique el intervalo que evaluó y qué valor del intervalo utilizó.

Puede introducir esos datos en la calculadora de ROI de ProcessMind: volumen anual de casos, tiempo medio de gestión, coste por hora con todos los conceptos incluidos, reducción prevista, incidencias y su coste medio, además de los datos del plan de licencia. La calculadora ofrece los beneficios anuales totales, el beneficio neto, el retorno de la inversión y el periodo de recuperación.

Es un modelo general, y ahí reside su valor: muestra cómo se combinan los datos de entrada. Solo se convierte en su caso cuando sustituye los valores predeterminados por sus propios volúmenes, tiempos y costes. Además, la calculadora no incluye en los costes el esfuerzo de implementación ni la preparación de los datos, así que debe añadirlos por separado. Un modelo que no puede adaptar a su situación aún no es un caso de negocio.

¿Cómo se presenta en la práctica un caso de negocio con cuatro cifras?

Las cifras siguientes son ilustrativas. Utilice el método, no los valores.

Situación: Un proceso gestiona 12.000 pedidos por trimestre. El tiempo de ciclo mediano es de 18 días y el P90, de 41 días. Cerca de un tercio de los pedidos espera más de cinco días en una etapa de aprobación que requiere unos cuatro minutos de trabajo efectivo.

1. Tamaño del problema: La espera afecta a unos 4.000 pedidos por trimestre. Si la espera media en esa etapa es de seis días, equivale a 24.000 días de tiempo de ciclo por trimestre. El trabajo efectivo que requiere esa etapa suma unas 270 horas en el mismo periodo. Cuál de estas dos cifras conviene incluir depende de si la demora afecta a los costes, al nivel de servicio o a ambos. Antes de utilizar cualquiera de ellas, compruébela con sus propios datos. Tenga en cuenta también la unidad: los días de pedido no equivalen a euros. Si el caso debe expresarse en dinero, esa conversión es otra suposición que deberá indicar y comprobar.

2. Coste de la solución: Una opción sería elevar el umbral para que la etapa de aprobación se aplique al 8 % de los pedidos, en lugar del 33 %, y asignar a una persona delegada cuando no esté quien aprueba. Antes de considerar que es una solución de bajo coste, confirme con las personas responsables los costes de las políticas, los controles y la implementación.

3. Coste del piloto: Limite el piloto a un proceso y a un periodo definido. Incluya la licencia, el tiempo de análisis dedicado a preparar los datos y el tiempo de la persona responsable del proceso. Si aún no ha confirmado el esfuerzo necesario para preparar los datos, indíquelo como una estimación. Un caso de negocio de Process Mining que solo incluya la licencia subestimará el trabajo necesario.

4. Tiempo hasta obtener los primeros datos: Fije una fecha para revisar el tiempo de ciclo del segmento afectado. Si la espera no cambia, al menos tendrá una línea de base para orientar la siguiente decisión.

¿Qué podría cambiar la conclusión? Si la etapa de aprobación existe para detectar fallos de control, cambiar el umbral podría debilitar ese control. Incluya ese riesgo en el caso y consulte a la persona responsable del control antes de recomendar un cambio.

Resuma en una página las cuatro cifras y las preguntas financieras:

Cada fila de esa tabla debe basarse en algo que haya medido o en una estimación de una persona responsable identificada. Lo mismo se aplica al cálculo del ROI de Process Mining: no presente una estimación como ahorro hasta que sus propios datos y el cambio propuesto la respalden.

Para identificar primero las etapas que podría valer la pena cambiar, lea cómo encontrar oportunidades de automatización con Process Mining.

¿Por qué conviene que el primer caso de negocio sea un piloto?

El primer caso de negocio debe centrarse en un piloto, no en una plataforma. Las cuatro cifras están pensadas para eso: un proceso, una decisión y un periodo lo bastante corto para revisar el resultado antes de comprometerse con algo más amplio. Considérelo una prueba de valor de Process Mining: un ejercicio de medición, no una implementación a pequeña escala.

Empiece con un piloto pequeño y mantenga expectativas realistas: el caso de negocio debería justificarse por sí solo. Si no es así, quizá esté pensando a una escala demasiado grande. Deje que los datos hablen primero y amplíe el alcance donde sea necesario. Un piloto que cuesta unas pocas licencias y unas semanas de análisis exige mucho menos que un programa de plataforma y aporta algo que este no puede ofrecer: su propia línea de base.

Empezar con poco también es una decisión sobre el software. Si una herramienta solo resulta adecuada para una implementación empresarial, el caso debe ser grande desde el principio. ProcessMind tiene un precio por licencia, ofrece un nivel gratuito después de la prueba y una prueba gratuita de 14 días sin tarjeta de crédito. Así, el primer análisis no requiere un acuerdo empresarial. Consulte el coste de cada plan.

Antes de iniciar un piloto de Process Mining, defina estos cuatro aspectos:

• Un proceso: lo bastante acotado para que una sola pregunta defina el alcance.
• Una decisión: la decisión que deberán orientar los resultados.
• Criterios para cerrar el piloto: acuerde de antemano qué resultados justificarían continuar y cuáles, detenerse.
• Una fecha de revisión: el día en que evaluará los datos y decidirá qué hacer después.

Si el piloto justifica continuar, utilice sus resultados para fundamentar el siguiente proceso. Si no, al menos tendrá una línea de base y motivos más claros para cambiar de rumbo. En cualquier caso, antes de empezar, contemple en el caso los tres resultados posibles: los datos respaldan este cambio, respaldan otro cambio o justifican detenerse. Un caso que solo puede terminar de una manera no es un ejercicio de medición.

¿Qué ocurre si aún no tiene las cifras?

En ese caso, quizá todavía no se justifique la inversión. Reconocerlo es un hallazgo, no un fracaso. Suele deberse a uno de estos tres motivos: el volumen del proceso es demasiado bajo para que el trabajo tenga un impacto relevante, los datos no están disponibles en un formato útil o nadie está esperando una decisión.

Si los datos existen y el proceso es pequeño, mida una línea de base manualmente. Si los datos no son utilizables, defina el trabajo necesario para prepararlos en lugar de solicitar una licencia e indique qué tendría que cambiar para volver a evaluar el caso.