A finales de septiembre, la comunidad de gestión de procesos se reúne en Stuttgart para All about Process Management. Dos días de keynotes, masterclasses y mesas redondas y, a juzgar por la agenda, un tema atravesará la mayoría de ellas: los agentes de IA y lo que hace falta para dejarlos actuar dentro de un proceso de negocio. Estaremos allí como expositores, y este es el argumento que pensamos defender.
Todo empieza con algo que no tiene nada que ver con el software. En la mayoría de las empresas, descubrir qué está realmente fallando en un proceso exige que alguien lo sospeche primero.
Pensemos en cómo suelen salir a la luz estas cosas. Un proveedor se queja de un pago retrasado. Un responsable nota que las aprobaciones tardan más que antes. Un equipo siente que está haciendo el mismo trabajo dos veces. Alguien plantea la pregunta, y solo entonces empieza el trabajo real: extraer los datos, construir el análisis, presentar los resultados, acordar una medida. Semanas después llega una respuesta, y suele ser buena.
Pero fíjate en lo que tuvo que ocurrir antes de todo eso. Alguien tuvo que tener una corazonada. Y una corazonada solo se forma cuando alguien está lo bastante cerca del trabajo como para sentir que algo no cuadra. Todo lo que da la casualidad de que nadie siente permanece invisible: el departamento que nunca se queja, el paso del proceso del que nadie es responsable, la excepción que silenciosamente se ha convertido en norma. No porque falten los datos, sino porque a nadie se le ocurrió preguntar.
La respuesta estándar es un dashboard. Poner las cifras en una pantalla, actualizarlas con regularidad y dejar que la gente mire.
Ayuda, pero no resuelve el problema de fondo. Un dashboard sigue a la espera de ser interrogado. Recompensa a quien ya sabe qué gráfico abrir, qué filtro aplicar y qué cifra es inusual para esta época del año. Ofrece una forma de comprobar una sospecha más rápido, pero no da la sospecha en sí. Así que los mismos puntos ciegos sobreviven, ahora detrás de una interfaz más bonita.
Esto se ve en cómo se usan realmente los dashboards. Un puñado de especialistas los consulta constantemente. Casi todos los demás los abren cuando se les pide, echan un vistazo a la línea superior y los vuelven a cerrar. No por desinterés, sino porque examinar una vista de proceso en busca de anomalías es un trabajo realmente arduo, y la mayoría de las personas ya tienen otro trabajo que hacer.
Hay un paso que casi todo el mundo se salta, porque se siente administrativo más que inteligente. Si se quiere que un sistema avise cuando algo ha ido mal, primero hay que decirle cómo se ve lo correcto.
La mayoría de las organizaciones tienen este conocimiento, pero vive en los lugares equivocados: en un manual de calidad que nadie lee, en un documento de política interna, en la cabeza de la persona que lleva once años haciendo ese trabajo. Existe como intención. No existe en una forma que se pueda comprobar.
Puesto por escrito correctamente, resulta ser sorprendentemente simple y sorprendentemente concreto. Una factura no debería pagarse antes de haber sido aprobada. Un pedido no debería modificarse tres veces después de confirmado. La persona que solicita algo no debería ser la misma que lo autoriza. Una solicitud de cliente no debería quedar sin atender más de cinco días. Nada de esto es sofisticado. Es lo que las personas del proceso ya creen, simplemente hecho explícito.
En Process.Science Intelligence, eso es exactamente lo que son los Process Norms: las propias expectativas sobre un proceso, escritas como reglas y luego contrastadas con lo que realmente ha ocurrido en los sistemas, en cada caso y no en una muestra. Cuando los datos no permiten un veredicto claro, así se indica, en lugar de contarlo silenciosamente como correcto.
Esa es toda la condición previa. Una vez establecida, el sentido del trabajo puede invertirse.
El camino convencional va del dashboard al insight. Una persona abre una vista, busca algo que parece incorrecto, formula una hipótesis, filtra, profundiza y finalmente llega a una causa raíz. Ese camino depende por completo de que alguien decida mirar, sepa dónde mirar y mire con la frecuencia suficiente. Escala con el número de especialistas disponibles, es decir, prácticamente no escala.
Process.Science Intelligence cuenta con una función llamada Alerts que recorre el camino en la otra dirección. En lugar de esperar a ser interrogado, el sistema contrasta el proceso con tus normas y señala los lugares donde la realidad se ha desviado: aquí, en esta parte del negocio, contra esta regla, tantas veces, así de a menudo últimamente. Desde esa alerta se pasa directamente al análisis relevante, y de ahí a la causa raíz: qué casos están afectados, qué tienen en común, cuánto tiempo está costando. Ya no hay que reconstruir el camino, porque ya está trazado.
No del dashboard al insight, sino del insight directamente al lugar correcto del dashboard, con la causa raíz ya a la vista. Y cuando el análisis muestra que las desviaciones se concentran en torno a un proveedor, una sede o un tipo de documento, eso es exactamente lo que indica. Una fuerte indicación de dónde mirar a continuación vale mucho, y no es lo mismo que una prueba, así que no la presentamos como tal.
La consecuencia es un cambio en para quién se hace el trabajo de procesos. El camino antiguo servía a especialistas que conocían la herramienta, los datos y el proceso lo bastante bien como para moverse por los tres a la vez. El nuevo sirve a quienes son dueños del proceso: jefes de equipo, controllers, responsables de departamento y gestores de centros de servicios compartidos. No necesitan saber construir un análisis. Necesitan que se les indique dónde mirar y luego poder seguir la pista por sí mismos.
Durante años esto fue una cuestión de eficiencia. Menos puntos ciegos, respuestas más rápidas, menos dependencia de unos pocos analistas saturados. Merecía la pena, pero no era urgente.
La automatización cambia eso. Un software que aprueba, pide, registra y responde por sí solo no tiene corazonadas. No nota que un proveedor es inusual, que se sorteó una cadena de aprobación o que se saltó un paso porque alguien estaba de vacaciones. Las personas absorben ese tipo de ambigüedad de forma constante y silenciosa. Una máquina no absorbe nada de eso. Así que en el momento en que se deja que el software actúe dentro de un proceso, las reglas no escritas tienen que convertirse en reglas escritas, no por el bien del análisis, sino para definir el límite: ¿dónde puede decidir la máquina y dónde tiene que devolver el control? Una organización que nunca ha establecido cómo se ve lo correcto no tiene forma de responder a eso, ni de saber si su respuesta seguirá siendo válida dentro de seis meses.
El valor se manifiesta en tres lugares. Los problemas se detectan mientras aún son baratos, porque una desviación se hace visible en la semana en que ocurre, y no en el trimestre en que alguien finalmente pregunta por ella. Las personas dueñas del proceso pueden actuar por sí mismas, lo que significa que la mejora deja de esperar en cola a que un analista esté disponible y empieza a ocurrir donde está el trabajo. Y la organización termina con algo que antes no tenía: un estándar escrito y probado de cómo deben funcionar sus procesos. Ese estándar es lo que hace defendible el siguiente paso, ya sea un acuerdo de objetivos, una auditoría o entregar parte del proceso a una máquina.
Nada de esto depende de un gran programa. Depende de estar dispuesto a escribir lo que ya se cree sobre el propio proceso, y luego dejar que los datos te contradigan.
Preferimos discutir esto antes que afirmarlo, porque lo interesante siempre es el proceso concreto: qué reglas tiene una empresa la confianza suficiente para poner por escrito, y cuáles resultan ser más negociables de lo que nadie esperaba.
Estaremos en All about Process Management los días 30 de septiembre y 1 de octubre de 2026 en el ICS de Stuttgart, y mostraremos con gusto Alerts en vivo, desde una sola desviación hasta la causa raíz. Pásate por nuestro stand para esa conversación.
¿Prefieres hablar antes? Usa Habla con un experto para concertar una demo, y la haremos sobre uno de tus propios procesos. Nos hace ilusión esas conversaciones.
