Esta es la confusión que sigo viendo en los tickets de soporte y las llamadas de incorporación: alguien dice que quiere implementar BPM, y lo que quiere decir es que quiere comprar una herramienta. O acaba de terminar un proyecto de documentación de procesos y cree que con eso ya ha hecho BPM. O ha automatizado algunos flujos y ahora lo llama BPM porque suena más estratégico.
Ninguna de esas cosas está exactamente mal. Pero ninguna de ellas es BPM por sí sola.
BPM es una disciplina. Tiene un ciclo de vida. Funciona de manera continua. La herramienta es una parte de una etapa. La documentación es un artefacto. La automatización es un método de ejecución. Ninguno de ellos, por sí solo, es la disciplina.
Esta distinción importa mucho en la práctica. Los equipos que confunden BPM con un proyecto de software suelen acabar con un sistema que nadie mantiene, paneles en los que nadie confía y un proceso que se ha "mejorado" dos veces, pero que sigue fallando de la misma forma cada trimestre. Los equipos que lo tratan como una disciplina obtienen beneficios acumulativos: cada ciclo hace que el siguiente sea más barato y rápido.
Este artículo explica qué es realmente BPM, cómo es el ciclo de vida en la práctica, dónde encaja y dónde no, y cómo saber si una implementación se va a sostener.
La parte que los equipos suelen aprender seis meses demasiado tarde
- BPM es una disciplina, no una herramienta ni un proyecto puntual
- Se dirige a procesos repetibles de extremo a extremo, no a todas las tareas
- El ciclo de vida es circular: la optimización vuelve al diseño
- La automatización es un método de ejecución dentro de BPM, no un sinónimo
- Sin responsables y KPI definidos, nada mejora de forma medible
Qué significa realmente la gestión de procesos de negocio (BPM)
BPM es una metodología de gestión para descubrir, modelar, analizar, medir, mejorar y optimizar procesos de negocio. No un único proceso. No una revisión puntual. Es la disciplina continua de gestionar cómo fluye el trabajo a través de una organización, de extremo a extremo, con gobernanza y medición asociadas.
El BPM Institute lo presenta como una disciplina que abarca personas, procesos y tecnología, y que requiere no solo herramientas, sino también cultura, estructuras de responsabilidad y métricas definidas. El enfoque al estilo Gartner (según la síntesis de Generis) lo describe de manera similar: un enfoque sistemático para mejorar los flujos de trabajo de una organización de modo que pueda adaptarse a las condiciones cambiantes del mercado.
Hay dos aspectos de estas definiciones que conviene recordar. Primero, es sistemático, no ad hoc. Segundo, trata sobre adaptación, lo que implica un ciclo continuo, no un estado finalizado.
La gestión efectiva de procesos de negocio se aplica específicamente a actividades operativas repetitivas, continuas y predecibles. No todas las tareas empresariales cumplen los requisitos. Un proyecto puntual no se beneficia de un ciclo de BPM. En cambio, un proceso recurrente de órdenes de compra, un flujo de incorporación de empleados o una ruta de escalado de soporte al cliente sí. La repetición es lo que hace valiosa esta disciplina: puede medir el mismo proceso a lo largo del tiempo, comparar ciclos y saber realmente si ha mejorado.
BPM no es una metodología de proyectos. No termina con el lanzamiento. La disciplina incluye lo que ocurre después de que el proceso entra en funcionamiento: supervisar el rendimiento, detectar desviaciones, identificar cuellos de botella y volver al rediseño.
Esta última parte es donde la mayoría de las implementaciones de BPM fracasan silenciosamente. Se produce el lanzamiento. Se configura el panel. El equipo pasa a otra cosa. Y el proceso que "mejoraron" comienza a degradarse en unos pocos meses, sin que nadie sea responsable de detectarlo.
Los 3 tipos de gestión de procesos de negocio
No todos los procesos fallan de la misma forma, lo que significa que no todos los enfoques de BPM son iguales. Los tres tipos reconocidos se corresponden con lo que realmente impulsa el proceso: sistemas, personas o documentos. Saber con qué tipo está tratando cambia cómo lo modela, qué lo puede romper y qué le indica realmente la supervisión.
La mayoría de los procesos reales combinan elementos de los tres. Sin embargo, el tipo predominante determina dónde se encuentran los modos de fallo.
BPM centrado en integraciones
El BPM centrado en integraciones gestiona procesos que funcionan principalmente mediante transferencias de un sistema a otro, con una participación humana mínima durante la ejecución. Las reglas de negocio gobiernan el enrutamiento: si un registro cumple la condición A, pasa al sistema B. Las personas que lo diseñaron no están en la ruta crítica una vez que está activo.
Este tipo es rápido y consistente cuando funciona. Los modos de fallo son técnicos: tokens de autenticación caducados, cambios de esquema en uno de los sistemas conectados, límites de frecuencia que nadie tuvo en cuenta a gran escala. Cuando fallan, a menudo lo hacen en silencio. El panel muestra que las ejecuciones siguen funcionando. Al sistema posterior le faltan registros. Y el equipo se entera dos semanas después, cuando alguien pregunta dónde fueron a parar los datos.
BPM centrado en personas
El BPM centrado en personas cubre procesos en los que la aprobación, el criterio o la coordinación mantienen a las personas en la ruta crítica. Un flujo de aprobación de gastos, un ciclo de revisión de contenido o una secuencia de firma de contratos dependen de que las personas tomen decisiones en etapas específicas. Los usuarios de negocio son el mecanismo, no solo los destinatarios finales.
Este tipo falla de manera diferente. Rara vez es un fallo técnico. Puede ser una persona de permiso, un paso de aprobación que se omitió "solo esta vez" y luego se convirtió en práctica habitual, o una transferencia que existe en el modelo pero no en el calendario de nadie. El BPM centrado en personas necesita responsabilidades claras y SLA en cada paso. Sin ellos, el modelo de proceso documenta lo que debería suceder mientras el trabajo real lo evita.
BPM centrado en documentos
El BPM centrado en documentos organiza el trabajo en torno a un documento que pasa por etapas de revisión, aprobación y cumplimiento. Es habitual en los sectores jurídico, financiero, de fabricación regulada y sanitario, es decir, en cualquier lugar donde el propio documento sea la unidad de trabajo y su estado (borrador, aprobado, publicado, archivado) tenga significado legal u operativo.
La gestión de riesgos es el motor principal en este caso. El proceso existe para crear evidencia auditable de que las personas adecuadas revisaron la versión correcta en el momento correcto. Cuando este tipo de BPM se implementa mal, los documentos avanzan, pero el registro está incompleto. La aprobación se realizó en el correo electrónico de alguien. La versión que llegó a producción no era la versión revisada. Las organizaciones con altas exigencias de cumplimiento aprenden esto durante las auditorías, que no es el momento ideal para aprenderlo.
El ciclo de vida de BPM: de qué es responsable realmente cada etapa
El ciclo de vida de BPM es el mecanismo que convierte BPM en una disciplina en lugar de un proyecto. Cinco etapas. Se ejecutan en secuencia. Después se ejecutan de nuevo. La optimización del final retroalimenta el diseño del principio, y el ciclo se repite mientras exista el proceso.
Esta circularidad es la afirmación mecánica central de BPM. También es la parte en la que más implementaciones se equivocan. Los equipos tratan el ciclo de vida como una secuencia única: diseñarlo, modelarlo, desplegarlo y darlo por terminado. La etapa de supervisión se omite o se delega a un panel que nadie revisa. La optimización nunca ocurre porque no hay un bucle formal que vuelva al diseño. Lo que obtienen es un proceso documentado que se aleja lentamente de la realidad mientras todos asumen que sigue funcionando según lo previsto.
Diseño y descubrimiento de procesos
Antes de modelar nada, alguien debe averiguar qué procesos existen realmente. El diseño y descubrimiento de procesos es la etapa en la que identifica qué flujos están funcionando, quién es responsable de ellos, qué se supone que deben hacer y qué están haciendo en realidad. El mapeo de procesos en esta etapa suele revelar que la versión oficial y la versión real son documentos distintos.
Omitir esta etapa es donde se estancan la mayoría de las implementaciones de BPM. Los equipos pasan directamente a modelar su versión preferida del proceso, lo que significa que están optimizando una ficción. El análisis de procesos durante el descubrimiento revela los cuellos de botella, las brechas en las transferencias y las soluciones alternativas no documentadas que el diagrama oficial del proceso nunca mencionó. No puede mejorar un proceso que no ha descrito con precisión.
Modelado de procesos
El modelado es donde se definen estructuralmente el estado actual y el estado objetivo, normalmente de forma visual. Un buen modelo de proceso muestra no solo el flujo, sino también los puntos de decisión, los participantes en cada paso, las excepciones y los indicadores clave de rendimiento que utilizará para medir si la versión mejorada es realmente mejor.
El BPM Institute deja claro que el modelado incluye definir métricas y KPI junto con la estructura del proceso. No es un paso separado. Si modela el flujo sin definir qué significa "mejor", tiene un diagrama, no un modelo de proceso de negocio. El modelado de procesos de negocio sin criterios de medición es documentación. Con criterios de medición, se convierte en la base de un ciclo de mejora real.
Ejecución e implementación
La ejecución es donde se despliega el proceso modelado: mediante software, políticas, herramientas de flujos o alguna combinación de estos elementos. Esta es la etapa que tiende a absorber más atención, presupuesto y tiempo. También es la etapa en la que los equipos confunden con mayor frecuencia la implementación de BPM con el final de BPM.
No lo es. La ejecución es la tercera de cinco etapas de un ciclo circular. Las herramientas de BPM elegidas aquí deberían respaldar las etapas posteriores de supervisión y optimización, no solo el despliegue en sí. Un proceso que se ejecuta pero nunca se supervisa es un proyecto puntual con una etiqueta de BPM. El proceso de implementación importa. Lo que viene después también.
Aquí es también donde Latenode suele aparecer en el trabajo que veo. Los equipos lo usan para conectar el proceso modelado con los sistemas que lo ejecutan, convirtiendo rediseños de flujos en automatizaciones ejecutables sin necesitar una capa de integración separada para cada transferencia. El RAG integrado, el nodo JavaScript y más de 5.500 integraciones permiten que incluso la documentación de procesos con entradas no estructuradas (PDF, notas dispersas, archivos SOP heredados) se enrute a flujos utilizables. La condición previa sigue siendo la misma: la cadena de aprobación y la responsabilidad del proceso deben definirse antes de crear el flujo. La herramienta no tomará esas decisiones por usted.
Supervisión y medición
La supervisión es lo que convierte BPM de un evento de lanzamiento en una disciplina continua. Una vez que un proceso está en ejecución, necesita visibilidad continua sobre su rendimiento: tiempo de ciclo, tasa de error, tasa de finalización de pasos, retrasos en las transferencias y frecuencia de excepciones. Estas son las señales que indican si el proceso se comporta como fue diseñado.
La inteligencia de procesos en esta etapa no es opcional. El Estudio BPM 2025 de BOC Group descubrió que el 21 % de las organizaciones recopila solo datos sin procesar, el 14 % depende de analítica descriptiva y solo el 11 % utiliza enfoques de diagnóstico como la minería de procesos. Esto significa que aproximadamente el 85 % de las organizaciones opera con inteligencia de procesos limitada o inexistente. Saben que algo es lento. No están seguros de dónde. No tienen un método estructurado para averiguarlo.
El tiempo de ciclo es la medición inicial. Indica cuánto tarda realmente un recorrido completo de extremo a extremo por el proceso. Todo lo demás —dónde se ralentiza, dónde falla, dónde se reenvía— se construye sobre esa referencia.
Optimización de procesos
La optimización es la etapa que cierra el ciclo. Los datos de supervisión revelan qué está rindiendo por debajo de lo esperado. La optimización de procesos utiliza esos datos para identificar mejoras específicas: rediseñar un paso, reasignar responsabilidades, cambiar un umbral o añadir un nodo de automatización. Después, el ciclo se reinicia con un diseño revisado.
No es una fase de limpieza. Es mejorar procesos de negocio basándose en evidencia en lugar de suposiciones. Los equipos que he visto obtener más valor acumulativo de BPM son los que tratan el bucle de optimización a diseño como trabajo trimestral habitual, no como una iniciativa especial. El ciclo se vuelve más rápido porque cada iteración se basa en datos de ejecución reales y no en condiciones estimadas. Ese es el mecanismo. Eso es lo que hace que valga la pena mantener la disciplina.
Dónde encaja BPM en una organización real y dónde no
BPM se orienta a toda la red de flujos, no a correcciones departamentales aisladas. Ese alcance es intencional. Un proceso que abarca ventas, legal y finanzas no puede mejorarse optimizando solo la parte de ventas. Las transferencias son donde se detiene el trabajo, y son invisibles cuando solo observa su propio paso.
En la práctica, BPM es más útil para cuatro tipos de equipos que trabajan en cuatro tipos de problemas:
Equipos de operaciones que reducen retrasos y errores. Si un proceso recurrente se retrasa de forma constante, produce retrabajo o genera volumen de soporte, BPM le proporciona un ciclo de mejora estructurado con criterios de medición. Este es el punto de entrada más habitual.
Equipos de mejora y estandarización de procesos. Las organizaciones que escalan a varias oficinas, regiones o líneas de productos necesitan estandarización de procesos antes de que la variación se vuelva inmanejable. BPM proporciona la estructura de modelado y gobernanza para lograrlo.
Equipos de TI y automatización que conectan el rediseño con los sistemas. Un rediseño de procesos que nunca llega a las herramientas es solo un ejercicio de pizarra. Los equipos de TI y los analistas de negocio que aplican BPM proporcionan el puente entre cómo debería fluir el trabajo y cómo los sistemas lo ejecutan realmente. Latenode aparece aquí como la capa de ejecución: por ejemplo, un equipo de operaciones de una empresa mediana puede tomar un proceso rediseñado de incorporación de proveedores y convertirlo en un flujo que enruta aprobaciones, verifica campos obligatorios, notifica a las partes interesadas y registra cada paso, sin un recurso de ingeniería dedicado al proyecto. Mejora de procesos de negocio aplicada mediante herramientas, no mediante documentación.
Organizaciones con altas exigencias de cumplimiento que mejoran la trazabilidad. El cumplimiento sigue siendo un importante impulsor de valor para la documentación de procesos, citado por el 57 % de las organizaciones en el Estudio BPM 2025 de BOC Group. Cuando un proceso necesita un registro auditable, la estructura de gobernanza de BPM es el mecanismo práctico para crearlo.
Pero BPM tiene límites importantes. Se aplica a actividades repetitivas, continuas y predecibles. Un proceso específico que se ejecuta en un ciclo definido, con entradas y salidas consistentes, es candidato para BPM. Un proyecto puntual, un proceso de trabajo creativo o una tarea situacional que cambia de forma cada vez no lo es. Aplicar la sobrecarga de BPM a procesos que no se repiten genera trabajo de documentación y gobernanza sin ningún beneficio acumulativo. Los resultados empresariales que genera BPM solo se materializan cuando el proceso se ejecuta con suficiente frecuencia como para medir la mejora entre ciclos.
BPM tampoco se adapta automáticamente a todos los objetivos de negocio. Empezar con el proceso equivocado —algo demasiado complejo desde el punto de vista político, demasiado variable o demasiado vinculado a un cambio organizativo pendiente— es una de las formas más seguras de paralizar una iniciativa antes de que produzca algo medible.
Beneficios de la gestión de procesos de negocio que merece la pena medir
Las afirmaciones genéricas sobre que BPM mejora la eficiencia no son incorrectas. Simplemente son inútiles sin las condiciones operativas que las hacen reales. Cada beneficio siguiente requiere algo específico. Cuando falta esa condición, el beneficio no se materializa o no puede verificarse.
Reducción de retrasos y errores de procesamiento
BPM reduce los retrasos cuando el descubrimiento ha mapeado con precisión dónde se ralentiza realmente el proceso, no dónde dice el modelo que debería hacerlo. Si el rediseño se basa en el flujo oficial del proceso en lugar de en datos de ejecución observados, los retrasos se desplazan en lugar de desaparecer.
Trabajo estandarizado entre equipos y ubicaciones
Un BPM eficaz crea consistencia en cómo se realiza el trabajo entre distintas personas y contextos. Este beneficio es real cuando el proceso estandarizado se sigue realmente, lo que requiere documentación accesible y responsabilidades claras. Si el estándar existe solo en una herramienta de modelado que los trabajadores de primera línea nunca abren, tiene un documento estandarizado, no un proceso estandarizado.
Rendimiento medible frente a KPI definidos
BPM crea la infraestructura para saber si un proceso funciona bien. Esto solo funciona cuando los KPI se definen en la etapa de modelado, antes de que comience la ejecución. Los programas exitosos de procesos de negocio que definen métricas después del despliegue tienden a medir lo que es fácil de contar en lugar de lo que realmente importa.
Mejor trazabilidad y responsabilidad
Cada paso tiene un responsable, cada decisión tiene un registro y cada excepción tiene un historial. En contextos con altas exigencias de cumplimiento, este es el valor principal. La condición: los responsables de los procesos deben asignarse y poder auditarse en la etapa de diseño. La trazabilidad construida retrospectivamente cubre algunas brechas, pero no las que aparecen en las auditorías.
Menor coste por ciclo de proceso a lo largo del tiempo
Aquí es donde el éxito de BPM se acumula. Cada ciclo de optimización reduce la fricción, lo que reduce el coste por ejecución. La condición es el ciclo de vida circular: sin el bucle que va de la supervisión a la optimización y de vuelta al diseño, los costes se estabilizan después de la mejora inicial en lugar de seguir disminuyendo.
Mayor agilidad empresarial cuando cambian los procesos
Un proceso modelado, documentado y supervisado se rediseña más rápido que uno no documentado. La organización sabe qué existe, quién es responsable y cuál es la referencia de rendimiento actual. Cuando cambian las condiciones, el rediseño parte de un mapa real en lugar de la memoria institucional. Este beneficio requiere que el modelo de proceso se mantenga actualizado. Los modelos que reflejan el estado de hace 18 meses proporcionan ciclos de rediseño más lentos, no más rápidos.
🤔 Espere.
Ninguno de estos beneficios se materializa si los responsables de los procesos y los criterios de medición no están definidos cuando comienza la ejecución. BPM sin gobernanza es documentación. El Estudio BPM 2025 descubrió que solo alrededor del 15 % de las organizaciones ha alcanzado una madurez avanzada de BPM, y la diferencia entre la documentación básica y el BPM operativo suele depender de si las responsabilidades y los KPI se definieron antes del despliegue, no después.
BPM frente a automatización de procesos de negocio: por qué la confusión sigue apareciendo en soporte
La automatización de procesos de negocio se trata como sinónimo de BPM con tanta frecuencia que he dejado de sorprenderme cuando alguien usa ambos términos en la misma frase con el mismo significado. No significan lo mismo.
BPM es la disciplina. La automatización de procesos de negocio es un método de ejecución dentro de esa disciplina. Puede implementar BPM sin ninguna automatización, utilizando documentación de políticas, formación y estructuras de responsabilidad de procesos. Puede ejecutar automatizaciones sin BPM, y muchos equipos lo hacen, que es de donde proceden la mayoría de las historias de "automatizamos lo equivocado". Cuando la automatización funciona sin la capa de gobernanza que proporciona BPM, escala procesos defectuosos, no procesos buenos.
La automatización robótica de procesos (RPA) genera más confusión en este ámbito. RPA automatiza secuencias de tareas específicas, a menudo en la capa de interfaz de usuario, sin rediseñar el proceso subyacente. Es una categoría de herramientas. BPM es la disciplina de gestión que le indicaría si automatizar esa secuencia de tareas realmente resuelve el problema correcto.
La gestión de proyectos es otro punto de confusión. La gestión de proyectos trata trabajo único y limitado en el tiempo, con estados definidos de inicio y fin: crear un producto, ejecutar una campaña o migrar un sistema. BPM gestiona procesos operativos repetibles que existen indefinidamente. Un despliegue de software es un proyecto. La canalización de despliegue que gestiona todos los despliegues futuros mediante un proceso consistente es candidata para BPM.
Las herramientas de minería de procesos completan el panorama, pero no sustituyen la disciplina. Revelan datos de ejecución y muestran cómo se están ejecutando realmente los procesos en comparación con cómo están modelados. Es una información valiosa para las etapas de supervisión y optimización del ciclo de vida de BPM. Pero las herramientas de minería de procesos no gobiernan el proceso, no son responsables de los pasos ni definen las métricas. La disciplina hace eso. La herramienta informa sobre ello.
Salesforce presenta BPM como algo que abarca toda la red de flujos: no automatizaciones individuales ni herramientas departamentales aisladas, sino el sistema conectado de procesos que mueve el trabajo a través de una organización. Ese alcance es el motivo por el que importa la definición. Un equipo que cree que BPM significa "hemos automatizado algunas cosas" lo aplicará de manera limitada y no detectará los problemas sistémicos que solo aparecen al observar la red completa.
Qué debe hacer realmente un sistema BPM antes de que confíe en él
La idea equivocada con la que me encuentro más a menudo es esta: los equipos eligen software BPM antes de haber definido qué debe admitir ese software. Evalúan la herramienta de forma aislada, compran basándose en la demostración y descubren seis meses después que han medido la adopción del software en lugar del rendimiento del proceso. El sistema BPM no es la disciplina. Respalda la disciplina.
Antes de elegir una solución BPM, aplique esta lista de verificación a cualquier plataforma que esté evaluando:
Soporte para descubrimiento y documentación de procesos
La plataforma BPM debe capturar los procesos tal como existen realmente, no solo como están documentados oficialmente. Si solo gestiona entradas estructuradas y flujos de procesos limpios, no revelará las soluciones alternativas informales que le están costando tiempo.
Modelado visual con definición de KPI
Las herramientas de modelado son comunes. Las herramientas de modelado que exigen definir métricas de rendimiento junto con la estructura del proceso lo son menos. Elija un sistema BPM que no le permita terminar un modelo sin nombrar qué significa "mejor".
Capa de ejecución conectada a flujos reales
El modelo debe conectarse con el trabajo real. Esto puede significar automatización de flujos, enrutamiento de documentos, asignación de tareas o cadenas de aprobación. Una herramienta que modela de forma excelente pero no puede intervenir en la ejecución diaria produce diagramas precisos que nadie sigue.
Paneles de supervisión con señales accionables
Los paneles deberían mostrar tiempo de ciclo, recuentos de errores, tasas de finalización de pasos y excepciones, no solo "el flujo se ejecutó correctamente". La distinción entre el estado de ejecución y la calidad del resultado es la que la mayoría de los paneles ignora silenciosamente. Una ejecución en verde que produjo un resultado incorrecto no es una ejecución de proceso exitosa.
Colaboración y asignación de responsabilidades
Cuando varios departamentos intervienen en un proceso, las plataformas BPM deben hacer visible la responsabilidad. Quién es responsable de cada paso, quién revisa las excepciones y quién es responsable del ciclo de mejora. Sin esto, obtiene modelos de procesos que todos consultan y nadie mantiene.
Cuando elige una solución BPM según estos criterios, no está evaluando un producto de software. Está comprobando si la herramienta puede respaldar la disciplina. Las decisiones de gobernanza, las definiciones de KPI y las asignaciones de responsabilidades: nada de eso procede de la herramienta. Usted aporta esos elementos. La herramienta simplemente hace que sean más fáciles o más difíciles de mantener.
💡 La parte contraintuitiva:
Las organizaciones que implementan software BPM antes de definir las responsabilidades de los procesos y los KPI suelen acabar midiendo la adopción de la herramienta, no el rendimiento del proceso. Pueden indicarle cuántos usuarios iniciaron sesión en la plataforma. No pueden decirle si el proceso mejoró. La disciplina debe preceder al software, no seguirlo.
Qué hace que una implementación de BPM tenga éxito o se venga abajo
Conviene decir algo desde el principio: BPM no requiere recursos a escala empresarial. La idea equivocada de que implementar la gestión de procesos de negocio solo es viable para grandes organizaciones con equipos de procesos dedicados ha llevado a muchas empresas pequeñas y medianas a recurrir a soluciones ad hoc cuando un enfoque disciplinado les habría servido mejor. El ciclo de vida escala. El alcance debe ser realista, pero la disciplina en sí no requiere un equipo de diez personas.
Lo que requiere es un pequeño conjunto de condiciones. Cuando esas condiciones están presentes en el lanzamiento, las implementaciones de BPM tienden a sostenerse. Cuando están ausentes, incluso las iniciativas de BPM bien financiadas y con buenas herramientas producen documentación y poco más.
Delimitar primero los procesos adecuados
El motivo más común por el que los proyectos de BPM se estancan antes de producir algo medible es la selección del proceso. Los equipos comienzan con el proceso más visible, con mayor tensión política o más complejo de la organización. Es comprensible: ese proceso es el que más frustra a todos. Pero también es el que implica a más partes interesadas, más excepciones y más desacuerdo sobre lo que siquiera significa "funcionar".
BPM funciona con actividades repetitivas, continuas y predecibles. El proyecto BPM que produce un resultado en el primer ciclo es el que comienza con un proceso que se ejecuta al menos semanalmente, tiene un inicio y un final definibles, y no cambia de forma cada vez que se ejecuta. Ese es el proceso que debe instrumentar primero. Desarrolle la capacidad y la credibilidad con un proceso que sea realmente abordable antes de asumir el más difícil. El plan de procesos no tiene que empezar por el primer puesto de la lista de prioridades. Debe empezar donde el éxito sea lo bastante alcanzable como para demostrar que el ciclo funciona.
Un proceso nuevo recién definido a veces es más fácil de delimitar que uno consolidado, precisamente porque todavía no ha acumulado soluciones alternativas. Si está creando un nuevo flujo de incorporación, puede diseñar la estructura de BPM desde el principio. De hecho, es más sencillo que incorporar gobernanza a un proceso que ha funcionado informalmente durante tres años.
Gobernanza, responsabilidad y medición antes del lanzamiento
BPM sin responsabilidades definidas produce documentación. Se modela el proceso, se configura la herramienta y luego no mejora nada porque nadie observa si está mejorando. El elemento que falta casi siempre es la gobernanza: quién es responsable del proceso, quién revisa los datos de supervisión y quién tiene la responsabilidad de convocar el siguiente ciclo de optimización.
La mejora de procesos requiere una persona responsable de la diferencia entre el rendimiento actual y el rendimiento objetivo. No un comité. No "el equipo". Una persona identificada, con un criterio de medición, que revise los datos en un calendario definido. Sin eso, el ciclo de vida se detiene en la ejecución y nunca llega a la optimización.
La gestión eficaz del cambio también importa aquí, y no en sentido abstracto. Las personas que ejecutan el proceso necesitan comprender por qué cambió y cómo difiere su trabajo. La gestión eficaz del cambio en el lanzamiento de BPM tiene menos que ver con campañas de comunicación y más con hacer que el nuevo proceso sea más fácil de seguir que la solución alternativa anterior. Si el nuevo proceso requiere más esfuerzo que la versión informal a la que sustituyó, las personas lo evitarán. No es resistencia. Es sentido común.
La mejora continua como estado final real
La señal de que BPM funciona no es un lanzamiento exitoso. Es el segundo ciclo de optimización.
Una iniciativa BPM exitosa produce un cambio medible en el primer ciclo y luego usa ese cambio como referencia para el siguiente. El bucle de optimización a diseño del ciclo de vida significa que la disciplina se vuelve más barata y precisa con el tiempo: cada iteración se informa mediante datos de ejecución reales, no mediante estimaciones iniciales. Los equipos que implementan BPM como una iniciativa puntual, declaran el éxito después del primer despliegue y siguen adelante nunca llegan a esta parte. El valor permanece teórico.
Si está evaluando si una iniciativa de BPM funciona realmente, la pregunta que debe plantear es: ¿qué han cambiado los datos de supervisión en el siguiente ciclo de diseño? Si la respuesta es "nada todavía", el ciclo de vida no está funcionando. Tiene un proceso ejecutado, no uno gestionado. El futuro de los programas de BPM que conservan su valor consiste en que la respuesta a esa pregunta se vuelva más rica con cada ciclo, no que siga siendo la misma.
Ahí es donde aparece realmente el progreso más útil de una iniciativa BPM.
