Ejemplos de gestión de procesos empresariales por departamento (con flujos reales)

La mayoría de las personas que buscan ejemplos de gestión de procesos empresariales no buscan una definición. Ya saben qué significa BPM. Lo que quieren es una respuesta concreta a una pregunta práctica: ¿cómo se ve esto realmente en un departamento real, un martes cualquiera, con una persona real responsable de ello?

Para eso sirve este artículo. Y esta es la afirmación que merece hacerse claramente: los ejemplos de BPM que realmente funcionan comparten una estructura común: un desencadenante definido, un flujo mapeado y un resultado medible. La mayoría de los equipos fracasan con BPM no porque hayan elegido la herramienta equivocada, sino porque omiten por completo esa estructura y empiezan a construir antes de responder las tres preguntas básicas.

Dónde fracasan silenciosamente la mayoría de las iniciativas de BPM

• BPM requiere un desencadenante, lógica de enrutamiento y un resultado medible; la mayoría de los equipos solo documentan la parte central.
• Los ejemplos más claros a nivel departamental provienen de RR. HH., finanzas, operaciones y atención al cliente.
• La mayoría de las iniciativas de BPM se estancan después del lanzamiento porque la etapa de optimización se considera opcional.
• La selección de herramientas viene después de la claridad del proceso, no al revés.

Qué significa realmente la gestión de procesos empresariales en la práctica

BPM es la disciplina de identificar, evaluar y mejorar continuamente procesos empresariales repetibles. Esa es la definición que utilizan IBM y Pipefy, y es precisa. Pero la parte que se omite en la práctica es la palabra «continuamente».

La mayoría de los equipos tratan BPM como un ejercicio de documentación. Mapean el proceso, lo escriben, quizá lo colocan en una wiki y lo dan por terminado. Eso no es gestión de procesos empresariales. Es un diagrama de flujo con aspiraciones.

Una gestión eficaz de procesos empresariales significa que el proceso tiene un responsable, un desencadenante, pasos definidos con lógica de enrutamiento y al menos una métrica que indica si funciona. Cuando falta cualquiera de esos cuatro elementos, no tiene un proceso gestionado; tiene un hábito con documentación.

Las operaciones empresariales funcionan mediante patrones repetibles: se incorpora un nuevo empleado, llega una factura, un cliente presenta una reclamación. BPM es lo que convierte esas situaciones recurrentes en sistemas predecibles y mejorables, en lugar de decisiones individuales que varían según quién esté trabajando ese día.

La razón por la que fracasan la mayoría de las iniciativas de BPM no es la selección de herramientas, el presupuesto ni la voluntad organizativa. Es que los equipos omiten la mejora de procesos como disciplina y van directamente a la automatización. Automatizar un proceso sin examinar solo hace que lo que está roto funcione más rápido.

Ahí es donde suele empezar el problema.

Los principales tipos de gestión de procesos empresariales

No todos los procesos empresariales tienen la misma forma, y el tipo de BPM adecuado depende de qué se mueve realmente a través del proceso: datos entre sistemas, decisiones entre personas o documentos por distintas etapas.

Hay tres tipos principales que conviene comprender antes de analizar ejemplos, porque el tipo determina qué herramientas se aplican, dónde suelen formarse los cuellos de botella y qué significa siquiera la «mejora».

BPM centrado en integraciones

El BPM centrado en integraciones gestiona procesos empresariales que se mueven principalmente entre sistemas, con una intervención humana mínima en cada paso. El flujo está basado en datos: se activa un desencadenante en un sistema, la información pasa por lógica de transformación o validación y un resultado llega a otro lugar.

Aquí es donde surgen de forma más directa las cuestiones sobre software de automatización y gestión de procesos. Cuando un pedido realizado en una plataforma de comercio electrónico crea automáticamente un registro de preparación en un sistema de almacén y activa una factura en contabilidad, eso es BPM centrado en integraciones. Los cuellos de botella suelen ser incompatibilidades de formato de datos, fallos de autenticación o mapeos de campos incompletos. Las personas aparecen en los extremos (para configurar las cosas y gestionar excepciones), pero no en el centro.

BPM centrado en las personas

El BPM centrado en las personas es el tipo en el que las aprobaciones, decisiones y transferencias entre personas definen el flujo del proceso. Un contrato que necesita revisión legal antes de la firma. Un informe de gastos que requiere la aprobación de un responsable antes del reembolso. Una oferta de empleo que debe ser aprobada por tres partes interesadas antes de que RR. HH. la envíe.

Estos son los procesos en los que viven la mayoría de los cuellos de botella operativos. El flujo solo es tan rápido como la persona más lenta de la cadena, y si no existe un proceso de aprobación o lógica de enrutamiento definidos, las solicitudes acaban en la bandeja de entrada de alguien hasta que se le insiste. Las herramientas de gestión de flujos suelen rendir por debajo de lo esperado aquí precisamente cuando el proceso en sí no se ha modelado primero: automatiza la notificación, pero la lógica de decisión sigue siendo ambigua.

BPM centrado en documentos

El BPM centrado en documentos organiza los procesos en torno a la revisión, aprobación y enrutamiento de documentos a través de etapas definidas. Contratos, documentos de políticas, propuestas, presentaciones regulatorias, órdenes de compra: cualquier proceso en el que un documento sea el elemento sobre el que se trabaja.

Este tipo se confunde habitualmente con la gestión de proyectos. Pipefy establece claramente la diferencia: el BPM centrado en documentos se rige por reglas empresariales sobre lo que necesita el documento antes de pasar a la siguiente etapa. La gestión de proyectos realiza el seguimiento de la finalización de tareas y plazos hacia un punto final fijo. Un proceso de revisión de contratos es BPM. Planificar el lanzamiento de un producto es gestión de proyectos. Si el proceso se repite con la misma lógica cada vez que entra un nuevo documento, está en territorio de BPM centrado en documentos.

Ejemplos de gestión de procesos empresariales por departamento

A continuación, cinco ejemplos concretos de gestión de procesos empresariales en distintos sectores y departamentos. Cada uno indica el desencadenante, los pasos del flujo y el aspecto de un resultado medible. No son teóricos: son los procesos que aparecen sistemáticamente en colas operativas e historiales de soporte reales.

La incorporación de empleados como ejemplo de BPM

Desencadenante: carta de oferta aceptada y firmada.

Sin BPM, la incorporación de empleados es una cascada de decisiones individuales. En algún momento, TI recibe un correo electrónico. Alguien configura el portátil. RR. HH. envía un paquete de bienvenida, quizá. El responsable define el calendario de formación. Dos semanas después, la nueva incorporación todavía no tiene acceso a tres sistemas y nadie tiene una visión clara de lo que falta.

Con BPM aplicado, el mismo proceso se ve completamente diferente. El flujo se ejecuta por etapas: el aprovisionamiento de TI comienza en el momento en que se activa el desencadenante, la recopilación de documentos (I-9, formularios fiscales, depósito directo) se envía a la nueva incorporación a través de un canal definido, el calendario de formación se genera a partir de una plantilla y se programa una reunión de seguimiento con el responsable para el día 7 y el día 30. Cada paso tiene un responsable. Cada paso tiene una señal de finalización. Puede ver de un vistazo qué está hecho y qué está bloqueado.

Este es uno de los ejemplos de BPM más citados por Claromentis, Appian y ClickUp porque es universalmente reconocible y el contraste entre lo gestionado y lo no gestionado es inmediato. También es un ejemplo claro de BPM centrado en las personas, ya que las transferencias entre TI, RR. HH. y el responsable de contratación son su mecánica principal.

El resultado medible: tiempo hasta la productividad de las nuevas incorporaciones, número de tickets de aprovisionamiento de accesos generados durante las dos primeras semanas y puntuaciones de satisfacción de los responsables en el día 30 sobre la fluidez del proceso.

Pasos del proceso de un vistazo:

Gestión de contratos y flujos de aprobación

Desencadenante: solicitud de borrador de contrato por parte de un miembro del equipo de ventas o compras.

El modo de fallo que BPM resuelve aquí es específico: contratos que permanecen en la bandeja de entrada de alguien porque no existe una lógica de enrutamiento definida. Un representante de ventas envía un borrador al equipo legal. El equipo legal no responde durante cuatro días porque no conocía el nivel de prioridad. El representante hace seguimiento. El equipo legal solicita el contexto empresarial que debería haberse incluido en la solicitud original. Pasan otros dos días. La operación se retrasa.

Esa secuencia no es inusual. Es lo que sucede cuando no se ha mapeado un proceso integral.

Un flujo de BPM para la gestión de contratos funciona así: se envía una solicitud de borrador con campos obligatorios (contraparte, valor de la operación, tipo de contrato, plazo); este es el desencadenante. La solicitud se enruta automáticamente al revisor legal correspondiente según el tipo de contrato. El equipo legal revisa y devuelve comentarios o escala el caso a asesoría jurídica sénior cuando supera un valor de operación definido. Los contratos aprobados se enrutan a la parte firmante. Se mantiene un historial de estado durante todo el proceso.

Los resultados medibles: plazo promedio de tramitación de contratos, número de contratos bloqueados en cada etapa durante más de 48 horas y capacidad de revisión legal utilizada al mes. Estos números no existen en organizaciones sin BPM. En organizaciones que lo utilizan, se convierten en la base de la planificación de capacidad.

Pasos de un proceso que pasó de no gestionado a gestionado: el contenido del trabajo no cambió. La lógica de enrutamiento y la propiedad sí.

Procesos de gestión financiera y de gastos

Desencadenante: un empleado envía un informe de gastos.

Un flujo de gastos sin gestionar se ve así: el empleado envía los recibos por correo electrónico a su responsable. El responsable los reenvía a finanzas. Finanzas pregunta cuál es el centro de coste. El empleado hace seguimiento. Finanzas introduce los datos manualmente. El reembolso tarda de dos a cuatro semanas. El rastro de auditoría consiste en hilos de correo electrónico.

No es una hipótesis. Es lo que escucho describirse habitualmente cuando los equipos empiezan a pensar en la mejora de procesos.

BPM añade tres elementos que cambian por completo el perfil de riesgo: reglas de enrutamiento (los envíos por encima de un determinado umbral se dirigen a un segundo aprobador), niveles de aprobación (los gastos de proyectos se enrutan de forma distinta a los de viajes, que a su vez se enrutan de forma distinta a los de equipamiento) y un rastro de auditoría que no es una pila de correos reenviados.

La implicación para la gestión de calidad es directa: BPM en finanzas reduce la exposición al incumplimiento al hacer que el proceso sea coherente y trazable. La inteligencia empresarial pasa a ser posible una vez que cuenta con datos estructurados: gasto por departamento, tiempo de aprobación por responsable, desgloses por categoría y trimestre.

Según la investigación de McKinsey sobre productividad organizativa, los procesos de gestión transversales típicos consumen entre el 40 y el 65 % del tiempo de gestión y gastos generales. La gestión de gastos es una pequeña parte de ello, pero es una parte que se acumula: cada interacción de aprobación en el reembolso de una comida de 45 dólares cuesta la misma atención de gestión que una factura de proveedor de 4.500 dólares cuando el proceso no está estructurado.

Métrica de rendimiento del proceso que debe seguir: tiempo promedio del ciclo de reembolso, desde el envío hasta el pago. En la mayoría de los entornos sin gestionar, es más largo de lo que cualquiera cree hasta que se mide.

Gestión de procesos de atención al cliente

Desencadenante: ticket de soporte recibido a través de cualquier canal (correo electrónico, chat, formulario web).

La ausencia de un proceso de gestión definido en atención al cliente crea tres modos de fallo específicos: gestión duplicada (dos agentes trabajan en el mismo ticket porque el enrutamiento no lo evitó), incumplimientos de SLA (un ticket de alta prioridad permanece en la cola general porque la lógica de clasificación no lo señaló) y ausencia de un ciclo de aprendizaje (el mismo problema se repite cada mes porque nada lo devuelve al equipo de producto o documentación).

BPM mapea el proceso desde la recepción hasta la clasificación, asignación, resolución y escalado. Un mapa de proceso para un ticket de soporte podría verse así: ticket recibido → clasificación automática por tipo y prioridad → enrutamiento a la cola adecuada → asignación dentro de una ventana de SLA definida → resolución o escalado según umbrales de tiempo y complejidad → resolución registrada con etiqueta de categoría para análisis de tendencias.

La conexión con la gestión de relaciones con clientes es directa: cuando la atención al cliente funciona con un flujo definido, obtiene datos. Volumen de tickets por categoría, tiempo hasta la primera respuesta por prioridad, tasa de escalado por área de producto. Sin la estructura del proceso, tiene una cola de elementos que se gestionaron, sin posibilidad de análisis de patrones.

Los resultados empresariales de los procesos de soporte gestionados incluyen tasas medibles de cumplimiento de SLA y un circuito cerrado entre los patrones de soporte y los cambios en el producto o la documentación. El patrón que veo con frecuencia en soporte: los equipos que implementan BPM para el enrutamiento de tickets ven reducirse el tiempo de primera respuesta en cuestión de semanas. El volumen de trabajo no cambia. El enrutamiento y la visibilidad sí.

Flujos de compras y adquisiciones

Desencadenante: se envía una solicitud de compra para un nuevo proveedor, producto o servicio.

Un flujo de compras, sin procesos empresariales definidos, se convierte en un ejercicio político. Alguien necesita una nueva suscripción de software. Se lo pide a su responsable. El responsable pregunta a finanzas. Finanzas consulta con el equipo legal. El equipo legal pregunta sobre el tratamiento de datos del proveedor. El solicitante original está copiado en una cadena de correos que dejó de leer al tercer día.

BPM estructura esto como un flujo de aprobación por etapas: solicitud de compra enviada con detalles del proveedor, coste estimado y justificación empresarial → enrutamiento automático según el nivel de gasto (las compras pequeñas se aprueban a nivel de responsable, las más grandes requieren aprobación de finanzas y los contratos empresariales se envían al equipo legal) → se activan los pasos de incorporación del proveedor una vez concedida la aprobación → la compra se registra y etiqueta para el seguimiento del presupuesto.

Las actividades empresariales clave aquí —validación del proveedor, aprobación del presupuesto, comprobación de cumplimiento y registro de la compra— se realizan en secuencia y con un responsable en cada etapa. La gestión de inventario se conecta posteriormente: las compras aprobadas activan actualizaciones de los inventarios de activos o suscripciones, de modo que los registros de la organización se mantienen actualizados.

El aspecto de cumplimiento: las compras son el punto en que BPM reduce directamente la exposición a auditorías. Cada decisión de compra deja un rastro. Cada aprobación tiene una marca de tiempo y un responsable.

📊 En la práctica:
Los ejemplos de BPM que funcionan en todos los departamentos de esta lista comparten una estructura de tres partes: un desencadenante definido que inicia el proceso, una lógica de enrutamiento que determina qué sucede después y un resultado medible que indica si el proceso se ejecutó correctamente. La mayoría de los equipos solo crean la lógica de enrutamiento. Omiten la definición del desencadenante (lo que significa que el proceso comienza de manera inconsistente) y omiten la medición del resultado (lo que significa que nunca podrán mejorarlo). Eso es caos documentado, no un proceso gestionado.

El ciclo de vida de BPM: etapas que todo proceso debe superar

BPM no es una tarea de configuración. Es un ciclo. El ciclo de vida de la gestión de procesos empresariales pasa por cinco etapas, y la mayoría de los equipos tratan las dos primeras como si fueran todo el proyecto. Ahí es donde muere el proceso.

Las cinco etapas: diseño, modelado, ejecución, supervisión y optimización. Cada etapa del ciclo de vida de BPM tiene un modo de fallo característico. Comprender esos modos de fallo es más útil que comprender las etapas en sí.

Diseño y modelado: donde la mayoría de los proyectos de BPM fallan primero

La etapa de diseño es donde se define el proceso: quién lo activa, quién es responsable de cada paso, cuáles son los puntos de decisión y qué aspecto tiene el resultado cuando funciona.

La etapa de modelado es donde esa definición se convierte en un modelo de proceso que puede ejecutarse y probarse. Esto no es lo mismo que la documentación. Un modelo de proceso incluye lógica de decisión (¿qué sucede cuando una factura excede el umbral de aprobación?) y gestión de excepciones (¿qué sucede cuando el aprobador está de baja?). La mayoría de los primeros proyectos de BPM omiten ambas cosas. Un analista empresarial puede mapear el camino ideal con meticuloso cuidado. Los casos límite reciben una nota que dice «gestionar manualmente».

Cuando utiliza BPM para documentar sin modelar la gestión de excepciones ni la lógica de decisión, produce un diagrama que es preciso para el 80 % de los casos e inútil para el 20 % que realmente necesita orientación. El proyecto de BPM falla en ese 20 % de casos y el equipo concluye que BPM no funciona para su situación. Sí funcionó. Para el camino sencillo. La parte que necesitaba más atención no se modeló.

Una lista de verificación útil para el diseño:

• Desencadenante definido con condiciones específicas (no «cuando sea necesario») - Cada punto de decisión tiene lógica de enrutamiento explícita para cada posible respuesta - Rutas de excepción nombradas y asignadas a un responsable - Medición del resultado definida antes de que comience la ejecución - Un responsable de proceso designado y responsable de todo el ciclo de vida

Ejecutar, supervisar y optimizar: cómo es el ciclo después del lanzamiento

La etapa de ejecución es donde el proceso modelado se aplica a datos reales con personas reales. Aquí es cuando comienzan a aparecer casos límite que no se modelaron. Es normal. Se supone que la etapa de ejecución debe revelar brechas.

La etapa de supervisión es donde se recopilan y revisan los datos de rendimiento del proceso. Esta es la etapa que los equipos omiten con mayor frecuencia, según el patrón que identificó McKinsey al examinar organizaciones en las que los procesos transversales consumen entre el 40 y el 65 % del tiempo de gestión: los equipos lanzan, declaran el éxito y siguen adelante. Nadie vuelve para revisar las cifras.

La etapa de optimización cierra el ciclo: los datos de la supervisión identifican dónde el proceso es lento, inconsistente o genera resultados inesperados, y esos conocimientos vuelven a alimentar el diseño y el modelado. Esto es lo que implica la reingeniería de procesos empresariales en su nivel más básico: utilizar lo aprendido al ejecutar el proceso para rediseñarlo mejor.

Las herramientas de minería de procesos pueden revelar patrones de ejecución a partir de registros cuando el volumen es suficientemente alto como para mostrar ineficiencias sistémicas. Para la mayoría de los equipos, una señal más sencilla funciona primero: elija tres métricas en la etapa de diseño, revíselas mensualmente y pregunte si la dirección de la tendencia es la correcta.

El modo de fallo que separa un proceso gestionado de uno simplemente implementado: tratar el lanzamiento como la línea de meta. La mejora de procesos es lo que sucede cuando supera esa línea y sigue avanzando.

Para los equipos que comienzan a cerrar este ciclo, una plataforma de automatización low-code puede ayudar a conectar la ejecución y la supervisión sin requerir infraestructura empresarial. Así funciona en la práctica: conecta las herramientas SaaS relevantes (su CRM, sistema de tickets y herramienta de proyectos) mediante integraciones integradas, configura un flujo que recopila métricas de proceso según una programación y utiliza un nodo de JavaScript para calcular KPI derivados antes de enviar el resultado a un panel compartido. Latenode ejecuta este tipo de flujo de informes como una única ejecución, independientemente de cuántos pasos estén involucrados, lo cual importa cuando construye algo que se ejecuta cada día y necesita que el coste operativo siga siendo predecible. El objetivo no es una configuración sofisticada de BI, sino una señal coherente que le indique si el proceso mejora o se estanca.

Prácticas recomendadas de gestión de procesos que realmente sobreviven al contacto con las operaciones

Todas las listas de prácticas recomendadas para BPM dicen lo mismo: documente sus procesos, involucre a las partes interesadas, mida los resultados. Todo eso es cierto y casi nada de ello le dice cómo evitar los errores específicos que hacen que las iniciativas de BPM fracasen en la práctica. Esta es la versión directa.

• Empiece por el proceso que falla de forma más visible

El modo de fallo que esto evita: pasar semanas modelando un proceso de bajo riesgo mientras el proceso roto que genera tickets cada semana continúa sin mapearse. La comprobación: ¿puede nombrar ahora mismo el proceso que genera más trabajo reactivo para su equipo? Inicie ahí la iniciativa de BPM, no con el proceso más fácil de diagramar.

• Defina el desencadenante antes de mapear el flujo

Los fallos de los modelos de proceso suelen tener su origen en un desencadenante ambiguo: «cuando un cliente se queja» en lugar de «cuando se envía un ticket a través del portal de soporte con el nivel de prioridad establecido como Alto». Un desencadenante vago significa que el proceso comienza de manera inconsistente, y la inconsistencia es el primer enemigo de la medición. La comprobación: ¿puede alguien que no conoce ya el proceso decidir si el desencadenante se ha activado?

• Asigne un responsable por proceso, no un comité

La gestión del cambio se deteriora cuando la responsabilidad es colectiva. Si tres personas son responsables del proceso, en la práctica significa que no se puede preguntar a una sola persona por qué algo salió mal. La comprobación: ¿puede escribir un solo nombre junto a «responsable del proceso» y lograr que esa persona confirme que acepta la responsabilidad?

• Automatice después de ejecutar el proceso manualmente al menos una vez

Esto parece obvio, pero se omite habitualmente. Los equipos pasan de un proceso nuevo a un proceso automatizado sin una ejecución de validación manual que revele el 20 % de los casos límite que el modelo no detectó. El modo de fallo: una solución de BPM que automatiza un proceso sin validar y escala los errores. La comprobación: ¿tiene el equipo notas de al menos un ciclo completo de ejecución antes de activar la primera automatización?

• Integre la medición en el modelo, no la añada a posteriori

La estrategia de gestión de procesos empresariales fracasa cuando la mejora se basa en sensaciones en lugar de datos. Si la métrica no se define antes de que comience la ejecución, la etapa de optimización no tiene nada en qué apoyarse. Observe las funciones empresariales que han operado sin KPI durante años: equipos financieros que realizan conciliaciones manuales al final de mes, equipos de RR. HH. que no pueden decir cuánto tarda la incorporación para distintos puestos. La comprobación: ¿qué cifra específica cambiará si este proceso mejora y dónde se registrará?

• Incluya a las personas que realizan el trabajo al modelar el proceso

Los usuarios empresariales son quienes saben dónde están las soluciones alternativas no oficiales. Un modelo de proceso creado por un analista empresarial de forma aislada describirá con precisión el proceso aprobado y omitirá las tres cosas que la gente realmente hace para que funcione. La comprobación: ¿revisó el modelo al menos una persona que ejecuta este proceso habitualmente antes de que pasara a la ejecución?

• Establezca una cadencia de revisión antes del lanzamiento, no después del primer incidente

La mayoría de las iniciativas de BPM se estancan en la etapa de supervisión porque no hay tiempo programado para revisar los datos. «Lo revisaremos cuando algo salga mal» no es una estrategia de BPM; es mantenimiento reactivo con documentación adicional. Elija una frecuencia (mensual para procesos nuevos, trimestral para los estables), inclúyala en el calendario y asigne a alguien la tarea de presentar las cifras.

• No automatice soluciones alternativas

Esta es la que pondría en una fuente más grande si pudiera. Cuando encuentra una solución alternativa en un proceso que lleva años en funcionamiento, la pregunta correcta es si el paso subyacente del proceso que compensa es realmente necesario. Automatizar una solución alternativa la convierte en permanente. La comprobación: ¿este paso resuelve un problema del proceso real o compensa un defecto de diseño que debería eliminarse?

Cómo utilizar herramientas de gestión de procesos empresariales sin sobredimensionar la solución

La discusión sobre herramientas viene después. Siempre. Un equipo que selecciona una herramienta BPM antes de modelar el proceso dedicará los primeros tres meses a personalizar la herramienta para ajustarla a un flujo sin examinar. La herramienta no falla. Falló la claridad del proceso.

Dicho esto, la categoría de herramienta importa. La clase de herramienta adecuada depende del tipo de proceso que esté gestionando, de cuánta interacción humana implica y de quién lo mantendrá.

Una nota práctica sobre la categoría de automatización de flujos: si está creando BPM centrado en integraciones y necesita conectar sistemas que tienen API junto con sistemas que solo cuentan con una interfaz web, una plataforma low-code con capacidad de navegador headless elimina la necesidad de un servicio independiente de automatización de navegador. Latenode tiene uno integrado; lo menciono porque la alternativa es añadir una segunda herramienta a su pila y una segunda obligación de mantenimiento para quien sea responsable del flujo dentro de seis meses.

El modelo de precios por ejecución también importa aquí de una forma que es fácil pasar por alto: un flujo de informes o aprobaciones de 6 pasos cuenta como una ejecución, no como seis tareas independientes. A escala, no es una diferencia menor.

🤔 Espere.
La mayoría de los equipos seleccionan una herramienta BPM antes de tener un modelo de proceso. Eso invierte el orden correcto y casi garantiza que la herramienta se abandone o se personalice en exceso para corregir una brecha de modelado que debería haberse resuelto antes de que entrara en escena cualquier software. Una herramienta que se adapta a un proceso sin modelar es simplemente confusión bien financiada ejecutándose a la velocidad de la automatización.