¿Qué es un BPMS? Gestión de procesos de negocio

Un BPMS (sistema de gestión de procesos de negocio) es un software que modela y ejecuta procesos definidos, y supervisa el trabajo que estos gestionan. Su fortaleza está en la ejecución: hace cumplir una secuencia, asigna tareas y registra lo ocurrido. Sin embargo, ofrece una visión limitada del conjunto, ya que solo puede ejecutar e informar sobre la parte del trabajo que se le ha definido.

Esta guía explica qué hace un BPMS, cuáles son los cinco componentes que realmente se adquieren y dónde están sus límites. Después compara el software de ejecución con la inteligencia de procesos, que deja deliberadamente la ejecución en manos de los numerosos sistemas que ya la realizan bien y, en cambio, conecta sus datos en un lugar común para que puedan usarlos las personas y la IA.

¿Qué significa BPMS?

BPMS significa Business Process Management System. Algunos proveedores usan en su lugar Business Process Management Suite. En ambos casos, esta categoría incluye software para definir un proceso, dirigir el trabajo a través de él y supervisar su ejecución.

BPM, o gestión de procesos de negocio, es la disciplina que permite comprender, diseñar, medir y mejorar cómo se realiza el trabajo. Un BPMS es un tipo de software que puede respaldar esa disciplina. Es posible aplicar BPM sin comprar un BPMS, y comprarlo no garantiza que se estén gestionando bien los procesos.

La categoría ha evolucionado con el tiempo. Empezó con motores de flujo de trabajo, se amplió con suites que incorporaron modelado, formularios y supervisión, y ahora incluye plataformas low-code con las que los equipos crean aplicaciones de procesos completas. Esta variedad explica por qué dos proveedores pueden describir un BPMS de forma distinta. Al evaluar software de gestión de procesos de negocio, no se fije en la etiqueta y hágase cuatro preguntas importantes: ¿permite modelar el proceso, ejecutarlo, conectarlo con los demás sistemas implicados y mostrar cómo funcionan sus instancias?

¿Cuáles son los cinco componentes de un BPMS?

Los productos agrupan estas funciones de distintas maneras, pero un sistema de gestión de procesos de negocio suele incluir cinco componentes:

1. Un modelador. Permite definir el proceso, a menudo en BPMN 2.0. Un modelo puede describir el flujo y, en un sistema ejecutable, servir de base para ejecutarlo. Consulte el modelador BPMN para obtener más información sobre el diseño de modelos de procesos.
2. Un motor de ejecución. El motor crea instancias de procesos, evalúa condiciones, asigna tareas, inicia temporizadores y escala el trabajo atrasado.
3. Formularios, reglas y roles. Estos determinan qué información proporcionan las personas, qué tareas ven y qué reglas rigen el siguiente paso.
4. Integración. El sistema intercambia datos con aplicaciones como sistemas ERP y CRM, almacenes de datos y gateways de API. El trabajo de integración puede representar una parte importante de la implementación.
5. Supervisión y repositorio. Los Dashboards muestran el estado de las instancias en ejecución. Un repositorio ayuda a gestionar las versiones de los procesos y controlar los cambios.

Un motor de flujo de trabajo es solo una parte del conjunto. Un BPMS combina el motor con las herramientas y los controles necesarios para definir, respaldar y supervisar un proceso más amplio.

¿Qué puede hacer un BPMS que no puede hacer un documento de procesos?

Un documento de procesos describe cómo debería realizarse el trabajo. Un BPMS puede dirigirlo y hacerle seguimiento según las reglas configuradas. Por ejemplo, puede:

• Escalar una tarea que lleva esperando un tiempo determinado.
• Enviar una instancia a aprobación cuando alcanza un umbral configurado.
• Registrar la ruta que sigue cada instancia.
• Permitirle actualizar un flujo mediante la configuración, sin modificar varias aplicaciones relacionadas.

Estas funciones son útiles cuando necesita dirigir el trabajo de forma coherente, asignar responsabilidades claras y ver las instancias que ejecuta el sistema. No garantizan que todas las partes del proceso real se realicen dentro del BPMS. Si su principal necesidad es documentar un proceso o entender cómo funciona actualmente, quizá el software de ejecución no sea el primer paso adecuado.

¿En qué se diferencian un BPMS, los motores de flujo de trabajo, RPA, Process Mining y la inteligencia de procesos?

Estas cinco tecnologías abordan distintas partes de la gestión de procesos. La tabla muestra qué hace cada una y qué pregunta le ayuda a responder.

RPA y un BPMS abordan los cambios en los procesos de forma distinta. RPA automatiza tareas dentro del proceso existente. Un BPMS ejecuta un proceso que usted ha definido, lo que puede cambiar cómo se dirige el trabajo. Antes de automatizar una tarea, compruebe si rediseñar el proceso permitiría eliminarla. Obtenga más información sobre cómo encontrar oportunidades de automatización con Process Mining.

Process Mining y un BPMS también responden a preguntas distintas. Process Mining analiza datos de eventos para mostrar cómo fluye realmente el trabajo por sus sistemas. Un BPMS ejecuta un flujo diseñado e informa sobre las instancias que gestiona. Esta diferencia importa cuando necesita comprobar si el modelo coincide con el trabajo real.

La inteligencia de procesos ocupa la última fila y conecta las demás opciones. Deja la ejecución en manos del sistema que mejor la realiza, lee los registros de todos los sistemas y mantiene un modelo único del proceso con el que se comparan. Un BPMS informa sobre sus propias instancias; la inteligencia de procesos informa sobre el proceso completo, incluido el trabajo que ninguna plataforma ejecuta por sí sola.

¿Por qué un solo BPMS no puede ejecutar todos los procesos?

Un BPMS parece la respuesta para gestionar procesos hasta que se cuentan los sistemas que no controla. Un proceso real pasa por un ERP, un CRM, una herramienta de gestión de tickets, un portal de proveedores, una hoja de cálculo y varios buzones de correo. La plataforma ejecuta la parte que se modeló en ella, mientras el resto del trabajo continúa en otros lugares.

Esta brecha tiene tres consecuencias que conviene conocer antes de comprar.

Se crean flujos de trabajo personalizados en lugar de reutilizar estándares. Un BPMS es un conjunto de herramientas, así que cada proceso se convierte en un proyecto: se modela una variante propia, se asignan nombres a los pasos y se mantiene una versión propia de un flujo que también utilizan miles de organizaciones. Los modelos de referencia estándar del sector para los procesos de pedido a cobro, compra a pago o gestión de incidentes se reconstruyen en cada plataforma en vez de reutilizarse. Además, dos departamentos que usan el mismo sistema pueden acabar con versiones distintas de un mismo proceso.

Las plataformas centradas en la ejecución pierden de vista el panorama general. Un BPMS se evalúa por lo que ejecuta, así que la atención y el presupuesto se destinan a los flujos que gestiona. A menudo, nadie se responsabiliza de los procesos que no ejecuta, como los que pasan por distintos equipos, sistemas y países. Acelerar la ejecución no equivale a entender cómo funciona la organización.

Un BPMS siempre tendrá limitaciones y acabará acumulando excepciones propias. Todos los procesos tienen excepciones: un pedido urgente, un cliente VIP o un proveedor que solo acepta solicitudes por correo electrónico. En un BPMS, cada excepción se convierte en otra rama configurada, otro formulario, otra integración y otro flujo de trabajo que mantener. La plataforma que prometía estandarizar el trabajo se va llenando poco a poco de casos especiales que solo entiende el equipo que la gestiona.

Eso no convierte a un BPMS en una herramienta deficiente. Significa que no es una buena fuente de verdad única sobre sus procesos.

La brecha es aún mayor en la gestión de procesos de negocio de TI, donde un mismo trabajo abarca una cola de tickets, un calendario de cambios y varias aplicaciones, sin que ningún software de procesos de negocio pueda ver los tres elementos.

¿Conviene conservar un BPMS que apenas utiliza?

Muchas organizaciones compraron un BPMS por su motor de ejecución, pero nunca llegaron a utilizarlo. La implementación tardó más de lo previsto, un socio configuró los primeros flujos y el negocio siguió trabajando con los sistemas que ya tenía. Lo que queda es una licencia de modelado que unas pocas personas usan para dibujar diagramas y una factura de mantenimiento por un entorno de ejecución que nadie pone en marcha.

Ese es el momento de separar las dos funciones que la plataforma agrupaba. El motor de flujo de trabajo debía ejecutar el trabajo; el repositorio de modelos debía conservar el conocimiento de los procesos. Si solo se cumple la segunda función, está pagando por una plataforma de ejecución que se usa como herramienta de documentación: una forma compleja, técnica y costosa de documentar.

Si la mayoría de estas afirmaciones se cumplen, se está pidiendo a la plataforma de ejecución que gestione conocimiento, aunque nunca se diseñó para ello. La solución no es añadir más capacidad de ejecución. Consiste en trasladar ese conocimiento a una herramienta cuya función principal sea servir de centro: un lugar para todos los procesos, conectado con los datos de cada sistema y accesible para las personas y los asistentes de IA que lo necesitan, sin tener que operar un entorno de ejecución.

Conserve el BPMS para los procesos que realmente ejecuta. Traslade el conocimiento de los procesos a un lugar donde pueda evolucionar sin depender de un ciclo de versiones.

¿En qué se diferencia la inteligencia de procesos de un BPMS?

La diferencia es deliberada, no una función que falte. La inteligencia de procesos no se ocupa de la ejecución porque existen muchas herramientas para ello, y la mejor opción rara vez es la plataforma que ya tiene. RPA, los agentes de IA, un sistema de gestión de flujos de trabajo, los propios flujos de trabajo del ERP y los equipos que realizan el trabajo destacan en ámbitos distintos. La herramienta que ejecuta el trabajo debe elegirse exclusivamente para esa función.

Lo que no conviene dejar en manos de cinco sistemas es el conocimiento. Si cada herramienta de ejecución mantiene su propio mapa del proceso, nadie puede decir en qué consiste el proceso, qué variante recibió realmente un cliente o qué paso conviene automatizar después. Centralizar el conocimiento de los procesos, tanto para quienes realizan el trabajo como para los asistentes de IA que empiezan a utilizarlo, es más importante que ejecutar el trabajo.

Ahí es donde está la ventaja de los datos. Un BPMS informa sobre sus propias instancias; una plataforma de inteligencia de procesos conecta los datos de eventos de todos los sistemas, por lo que ofrece una visión que también incluye el trabajo que el BPMS no llegó a registrar. Así, puede mantener un único modelo de referencia para el BPMS, el ERP y las herramientas de automatización.

¿Por qué hace falta Process Mining para que el modelo refleje la realidad?

Un BPMS puede informar sobre las instancias que se ejecutan en él. Eso no significa que registre todas las rutas que siguen las personas para completar el proceso. Pueden surgir tres brechas habituales:

• El trabajo se realiza fuera del motor. Alguien gestiona una excepción por correo electrónico y actualiza el sistema más tarde. La instancia puede parecer conforme, aunque el trabajo haya tardado más de lo que indica el modelo.
• Se llega al mismo resultado mediante otros sistemas. Los equipos pueden utilizar un ERP, una hoja de cálculo o un portal de proveedores. Si ese trabajo nunca se registra en el BPMS, sus Dashboards no muestran el proceso completo.
• El modelo se queda atrás. Un proceso puede ser preciso cuando se publica y, después, desviarse a medida que los equipos adoptan variantes locales. Si actualizar el modelo lleva tiempo, esas variantes pueden perdurar.

El resultado es un modelo bien gestionado que ya no refleja cómo trabaja la gente. Process Mining permite volver a ajustarlo a la realidad: lee los datos de eventos que ya registran sus sistemas y reconstruye las rutas que se siguieron, incluidas las que nadie había modelado.

La comprobación de conformidad compara un modelo de proceso con los datos de eventos para mostrar dónde divergen la ejecución y el diseño, mientras que Process Mining revela las variantes, las demoras y el retrabajo que aparecen en sus propios registros. Por qué el modelado de procesos y Process Mining deben ir de la mano explica por qué nunca conviene separar las dos partes: lo que se pretende hacer y lo que ocurrió.

¿Por qué decidimos no crear un motor de ejecución?

Es una pregunta razonable para una plataforma de procesos: si permite modelar un proceso y ver cómo funciona, ¿por qué no ejecutarlo también? Los BPMS existen porque la respuesta evidente es afirmativa. Nosotros elegimos otro camino, y fue una decisión, no una omisión.

En la práctica, esto significa que ProcessMind nunca le pide las llaves del flujo de trabajo. Los sistemas que ya utiliza siguen ejecutando el trabajo, mientras el conocimiento sobre lo que hacen se centraliza y se mantiene actualizado. Si más adelante sustituye una herramienta de ejecución, ya sea un bot de RPA por un agente de IA o un flujo de trabajo antiguo por uno nuevo, el modelo, el historial y las mediciones permanecen donde están. Por qué creamos ProcessMind explica el resto de los motivos.

¿Cómo se integra ProcessMind con un BPMS?

ProcessMind no es un BPMS ni ejecuta el trabajo. Su BPMS, ERP o plataforma de automatización sigue siendo responsable de ejecutar los procesos, y ese es precisamente el objetivo: conservar la mejor herramienta de ejecución para cada proceso y reunir en un solo lugar el conocimiento sobre todos ellos.

Esto es lo que hace en la práctica la inteligencia de procesos:

• Antes de desarrollar: Analice los datos de eventos de los sistemas implicados para descubrir las rutas, variantes y excepciones reales. Modele el proceso objetivo en BPMN 2.0 y utilice la simulación de procesos para probar un cambio antes de que alguien configure un flujo de trabajo.
• Después de desarrollar: Siga analizando los datos para comprobar si la ejecución aún coincide con el diseño y detectar cuándo una solución local se ha convertido discretamente en el proceso que sigue todo el mundo.

El BPMS ejecuta el trabajo. La inteligencia de procesos ayuda a decidir qué vale la pena ejecutar y comprueba si el resultado coincide con el proceso que las personas siguen realmente.

¿Cuándo conviene elegir un BPMS, RPA o inteligencia de procesos?

El mejor punto de partida depende de lo que ya sabe y del problema que quiere resolver.

Comience por la inteligencia de procesos cuando:

• Las personas no se ponen de acuerdo sobre cómo funciona el proceso actualmente.
• El proceso abarca varios sistemas y parte del trabajo puede realizarse fuera del flujo de trabajo principal.
• Sabe que el proceso es lento, pero desconoce el motivo.
• Tiene un BPMS cuyo motor de flujo de trabajo está inactivo y quiere conservar el conocimiento del proceso en un lugar útil.

Considere un BPMS cuando:

• El proceso se comprende y es lo bastante estable como para estandarizarlo.
• El trabajo pasa de un equipo a otro y hace falta definir mejor las asignaciones o las responsabilidades.
• Necesita aplicar reglas y gestionar cambios sin tener que modificar varias aplicaciones a la vez.

Considere RPA cuando:

• El proceso es estable y repetitivo.
• La tarea se realiza con suficiente frecuencia como para justificar su automatización.
• No se pueden modificar las aplicaciones y es posible automatizar el paso mediante sus interfaces.

Dos hábitos ayudan a elegir en el orden adecuado: mida el proceso antes de comprar software de ejecución y compruebe si un rediseño eliminaría la tarea antes de automatizarla.

¿Cómo evaluar un BPMS antes de comprarlo?

Empiece por un proceso con un nombre claro y una persona responsable: del pedido al cobro, de la compra al pago, incorporación de personal o gestión de incidentes. Evite evaluar un área amplia, como “operaciones”, sin especificar a qué proceso se refiere. Después, siga estos cuatro pasos.

1. Encuentre los datos de eventos

   Compruebe qué sistemas registran el proceso y si sus registros incluyen un identificador de caso, una actividad y una marca de tiempo. Las herramientas de gestión de procesos de negocio describen el flujo previsto; el registro de eventos demuestra lo que ocurrió.

2. Compare el diseño con lo que se ejecutó

   Busque las rutas, demoras y excepciones que el modelo no muestra. Probar el BPMS candidato más adecuado con sus propios datos resulta más útil que consultar una tabla de funciones, porque permite ver qué partes del proceso gestionaría realmente.

3. Determine qué indican los datos

   La solución puede ser un BPMS, un rediseño del proceso, un cambio en un paso o ninguna intervención. Deje que los resultados determinen la herramienta, no al revés.

4. Siga midiendo después de implementar

   La plataforma puede informar sobre las tareas que ejecuta. Los datos de eventos de todos sus sistemas permiten comprobar si el proceso sigue reflejando el trabajo una vez que el flujo de trabajo está en funcionamiento.

Si el proceso abarca sistemas con los que el BPMS no se conecta, las primeras mediciones lo dejarán claro. Esa es la comparación que conviene hacer antes de invertir en una herramienta de ejecución.