Business Process Management

Software de gestión de procesos y herramientas BPM: qué hacen y qué dan por sentado que ya sabes

Qué hacen realmente el software de gestión de procesos y el BPM, en qué se diferencian y qué herramientas de documentación de procesos requieren
No se requiere tarjeta de crédito
Elegido como la mejor relación calidad-precio en Análisis de personal
por
y
Busy? Get a TLDR of this Page:
Summarize With AI

Temas de la guía

Hable con el departamento de ventas

Nuestro equipo dedicado está aquí para responde a todas sus necesidades personalizadas.

Puntos clave

  • El software de gestión de procesos y las herramientas de BPM modelan, ejecutan, dirigen y controlan un proceso de negocio definido a gran escala, una vez que dicho proceso ha sido identificado y documentado.
  • En la práctica, ambos términos son prácticamente intercambiables; BPM es la denominación más formal y orientada a grandes empresas que se utiliza en adquisiciones y análisis de mercado, mientras que "software de gestión de procesos" es un término más amplio empleado en el marketing de productos.
  • La herramienta no es lo difícil. Lo complicado es saber qué introducir en ella: un proceso actual documentado y preciso, algo que la mayoría de los compradores no tiene al empezar.
  • Evaluar una plataforma implica cuestionar cómo se integra realmente un proceso, qué sucede con el trabajo que se realiza fuera de ella y qué es lo que la gobernanza aplica en la práctica frente a lo que parece aplicar sobre el papel.

Software de gestión de procesos y herramientas BPM: qué hacen y qué dan por sentado

El software de gestión de procesos ejecuta el proceso que se le asigna. El software BPM hace lo mismo, bajo un nombre más formal y orientado a la empresa. Ambos están diseñados para ejecutar un flujo de trabajo definido de forma fiable y a escala, una vez que dicho flujo ha sido establecido.

Esa es la parte que la mayoría de las evaluaciones pasan por alto. Una plataforma puede modelar, dirigir y controlar un proceso que se le ha indicado. Sin embargo, no tiene forma de decirle al comprador si el proceso que está a punto de modelar es el que su equipo realmente sigue, o una versión que dejó de ser precisa hace meses.

¿Qué es el software de gestión de procesos?

El software de gestión de procesos es una plataforma que modela un proceso de negocio, lo ejecuta entre las personas y sistemas involucrados, y aplica las reglas que rigen su funcionamiento. Sustituye la coordinación improvisada por un flujo de trabajo definido y repetible que el software puede dirigir, versionar y analizar con el paso del tiempo.

Tanto el software de gestión de procesos de negocio como las herramientas BPM describen esta misma categoría, que suele adquirirse cuando un proceso se ha vuelto demasiado complejo o crítico como para coordinarlo únicamente mediante correos electrónicos, hojas de cálculo y la memoria institucional.

Las capacidades principales se agrupan en torno a unas pocas funciones. Las herramientas de modelado permiten diseñar un proceso mediante una notación definida, generalmente un diagrama de flujo, antes de que se ejecute. Los motores de ejecución toman ese modelo y dirigen el trabajo: una tarea pasa de una persona o sistema al siguiente siguiendo las reglas integradas en el proceso.

Las funciones de gobernanza controlan qué cambios se permiten una vez que el proceso está activo y quién puede aprobarlos. Las herramientas de informes muestran el rendimiento del proceso una vez ejecutado: tiempo de ciclo, volumen y puntos donde se acumuló el trabajo.

Ninguna de estas capacidades requiere que el proceso sea sencillo, solo que se conozca con suficiente detalle como para poder dibujarlo, dirigirlo y aplicarlo de forma coherente. Ese requisito subyace en todas las listas de funciones que publica un proveedor, y rara vez es lo primero que un comprador piensa en verificar.

Software de gestión de procesos y software BPM: ¿son lo mismo?

Sí, en la práctica. La diferencia es de enfoque más que de función. BPM, siglas de gestión de procesos de negocio, es el término más antiguo y formal, que aparece con mayor frecuencia en conversaciones de compras corporativas, solicitudes de propuestas (RFP) y análisis de mercado.

El software de gestión de procesos es la etiqueta más reciente y amplia, utilizada principalmente en el marketing de productos y en las búsquedas en línea. Ambos términos se refieren a la misma capacidad subyacente: modelar un proceso, ejecutarlo y controlar cómo evoluciona con el tiempo.

Algunos proveedores intentan trazar una línea más clara, posicionando un término como más estratégico y el otro como más táctico, o reservando "BPM" para suites con mayor gobernanza y "gestión de procesos" para herramientas departamentales más ligeras. Esa distinción no es consistente en todo el mercado y no se sostiene al comparar las listas de funciones reales.

Una búsqueda de herramientas de gestión de procesos de negocio y una búsqueda de software de gestión de procesos suelen arrojar la misma lista de proveedores, descritos con el lenguaje que coincida con la búsqueda.

La conclusión práctica es más sencilla de lo que sugiere la terminología: evalúe la plataforma por lo que hace, no por cuál de las dos etiquetas utiliza para describirse.

Para obtener una visión más completa de la gestión de procesos de negocio como disciplina, y no solo como categoría de software, consulte nuestra sección dedicada.

Lo que estas plataformas hacen realmente

Estas plataformas están diseñadas en torno a un conjunto coherente de capacidades, independientemente del proveedor o la etiqueta que se les asigne.

Modelado y notación de procesos. Un proceso se diseña mediante una notación visual definida, comúnmente BPMN, antes de ser ejecutado. BPMN es una especificación del Object Management Group, actualmente en su versión 2.0.2 y publicada también como ISO/IEC 19510, razón por la cual un modelo creado en una plataforma suele ser compatible con otra.

Ejecución de flujos de trabajo. Una vez modelado, el proceso se ejecuta en tiempo real: el trabajo avanza paso a paso, siguiendo la secuencia y las condiciones establecidas en el modelo, sin necesidad de que alguien decida manualmente qué sucede a continuación en cada ocasión.

Enrutamiento de tareas y aprobaciones. Las tareas individuales se asignan automáticamente a la persona o equipo adecuado, y las aprobaciones siguen la cadena de mando correcta según las reglas establecidas durante el modelado.

Motores de reglas. La lógica condicional determina cómo se ramifica un proceso, evaluando los detalles de cada caso y dirigiéndolo por la ruta correcta sin que esa lógica esté codificada de forma rígida en el propio modelo.

Gobernanza y control de versiones. Los cambios en un proceso activo siguen su propio procedimiento controlado: quién puede proponer un cambio, quién lo aprueba y cómo se conserva la versión anterior en caso de que sea necesario revertirlo.

Repositorios de procesos. Cada proceso modelado reside en una biblioteca central, lo que permite que un proceso creado por un equipo sea visible y reutilizable, en lugar de quedar limitado únicamente a los archivos de ese equipo.

Análisis e informes. Una vez que se ejecuta un proceso, la plataforma informa sobre su rendimiento: tiempo de ciclo, volumen, dónde se estancaron los casos y con qué consistencia se siguió la ruta modelada.

Cada una de estas capacidades depende del mismo insumo: un modelo preciso del proceso desde el principio. Una plataforma puede ejecutar, dirigir y gobernar a la perfección, y aun así estar ejecutando la versión incorrecta del proceso si ese insumo era erróneo desde el inicio.

La documentación que estas herramientas dan por sentada

Cada una de las capacidades anteriores depende de un modelo, y cada modelo depende de que alguien ya sepa cuál es el proceso en realidad. Esa suposición está integrada en la decisión de compra y rara vez se examina de cerca antes de firmar el contrato.

El modelado requiere un estado actual documentado: la secuencia real de pasos, decisiones y transferencias por las que pasa un proceso hoy en día, no la versión escrita cuando se diseñó por primera vez. La mayoría de las organizaciones tienen algo parecido a esto, pero no exactamente.

Existe un mapa de procesos en algún lugar, pero tiene un par de reorganizaciones de antigüedad. Una variante más reciente maneja un caso excepcional que el diagrama original nunca contempló. Alguien creó una solución alternativa hace dieciocho meses que ahora todos consideran estándar, sin que nunca se haya incluido en la documentación.

Nada de esto es inusual, ni es un fallo por parte del comprador. Es simplemente lo que le sucede a la documentación con el paso del tiempo en cualquier organización donde las personas que ejecutan un proceso siguen adaptándolo más rápido de lo que alguien actualiza el diagrama.

El problema es lo que esto le hace a la fase de modelado. Un proyecto definido como "implementar la plataforma" se convierte silenciosamente en "averiguar primero cuál es nuestro proceso real", y ese segundo proyecto nunca fue presupuestado, dotado de personal ni programado en el plan original. Se programan talleres. Se entrevista a las partes interesadas. Pasan semanas antes de que se modele un solo proceso, porque el modelado no puede comenzar hasta que alguien reconstruya lo que se supone que debe representar.

Incluso cuando ocurre esa reconstrucción, generalmente produce el proceso previsto en lugar del real, ya que los talleres y las entrevistas describen cómo cree la gente que se ejecuta el proceso, filtrado a través de la memoria y una cierta cantidad de ilusiones sobre la consistencia con la que se sigue.

Ese modelo se convierte entonces en la base para la gobernanza y la verificación de conformidad en el futuro. La plataforma informará fielmente si la actividad en vivo coincide con el modelo. Lo que no puede decirle a nadie es si el modelo mismo coincidió alguna vez con lo que realmente estaba sucediendo el día en que se construyó.

La distinción tiene nombre. El Grupo de Trabajo del IEEE sobre Minería de Procesos distingue entre modelos de jure, que describen cómo debería realizarse el trabajo, y modelos de facto, que describen cómo se realiza realmente. Un taller genera los primeros y los denomina como los segundos.

Cómo evaluar el software de gestión de procesos

La mayoría de las evaluaciones se centran en las funcionalidades. Las siguientes preguntas se enfocan en lo que sucede una vez que el software está ejecutando un proceso real.

  1. ¿Qué notación utiliza y quién de su equipo puede leerla realmente?
  2. ¿Cómo se introduce un proceso en la herramienta en primer lugar?
  3. ¿Qué sucede con el trabajo que se realiza fuera de ella?
  4. ¿Qué registra sobre cuánto tiempo tomó cada paso?
  5. ¿Cómo se gestionan las excepciones?
  6. ¿Qué coste supone modificar un proceso modelado después de su puesta en marcha?
  7. ¿Qué es lo que la gobernanza aplica realmente, frente a lo que parece aplicar?

Notación y legibilidad. La mayoría de las plataformas utilizan BPMN o una variante propia. Si solo el equipo de implementación puede leer la notación, cualquier cambio futuro deberá pasar por ellos, lo que convierte a la herramienta de modelado en una dependencia.

Cómo introducir un proceso en la herramienta. Algunas plataformas importan datos desde herramientas de diagramación, mientras que otras requieren modelar desde cero dentro de la propia plataforma. En cualquier caso, la precisión de lo que se modele dependerá siempre de la descripción del proceso que se proporcione.

Trabajo fuera de la herramienta. Casi todos los procesos reales tienen una ruta de excepción que nunca se llega a modelar: un correo electrónico, una hoja de cálculo o una llamada telefónica. Pregunte qué sucede con ese trabajo, ya que la plataforma no tiene visibilidad sobre él de forma predeterminada.

Cronometraje a nivel de paso. Algunas plataformas registran marcas de tiempo detalladas en cada paso. Otras solo informan si un caso está abierto o cerrado, lo que oculta dónde se está perdiendo tiempo realmente.

Gestión de excepciones. Un proceso modelado suele tener una ruta ideal y una lista de excepciones previstas. Pregunte qué ocurre cuando algo queda fuera de ambas.

Coste de los cambios tras la puesta en marcha. Un proceso que parecía estable durante la demostración de ventas cambiará. Averigüe cuánto cuesta, tanto en tiempo como en personal necesario, modificarlo una vez que esté en funcionamiento.

Gobernanza en la práctica. Las funciones de gobernanza parecen idénticas en una lista de características. Lo que marca la diferencia es si realmente se aplican en el día a día o si las excepciones se normalizan silenciosamente sin que nadie actualice el modelo.

Software de BPM frente a categorías adyacentes

El software de BPM se sitúa en un grupo de categorías relacionadas pero distintas, y los límites entre ellas determinan cuál es la que mejor se ajusta al problema.

Category What it does Best fit
BPM / process management software Models, executes, and governs a process end to end Automating a known, repeatable process
Workflow management software Automates task sequences and approvals, lighter than full BPM Task routing without full modeling or governance
Process mining software Reconstructs how a process ran from system event logs Seeing the real process before modeling it
Process mapping tools Diagrams a process, without executing or governing it Documentation and planning

La distinción más importante es la que existe entre modelar y descubrir. Tanto la gestión de procesos de negocio (BPM) como las herramientas de mapeo de procesos trabajan a partir de una descripción del proceso, independientemente de cómo se haya creado dicha descripción. La minería de procesos funciona en la dirección opuesta: reconstruye el proceso a partir de datos sobre cómo se ejecutó realmente, lo que supone un punto de partida y un tipo de evidencia totalmente distintos. La gestión de flujos de trabajo se asemeja más al BPM en cuanto a su función, pero con un alcance más limitado.

Ninguna de estas categorías reemplaza a las demás. Una herramienta de minería de procesos puede servir de base para lo que se modela en una plataforma BPM. Una herramienta de mapeo de procesos puede documentar lo que un sistema de gestión de flujos de trabajo automatizará más adelante. Evaluar cualquiera de ellas de forma aislada es la razón por la que muchas empresas terminan con herramientas que no resuelven el problema para el que fueron adquiridas.

Obtener primero el estado actual real

El modelado, la ejecución, la gobernanza y la evaluación se basan en la misma premisa: que el proceso que se está modelando es el que realmente se está ejecutando. Esa suposición suele basarse en talleres y en la memoria, lo cual es un punto de partida razonable, pero también es la razón por la que los modelos se alejan de la realidad incluso antes de que la plataforma entre en funcionamiento.

Optimización del flujo de trabajo mide el estado actual de un proceso tal y como se ejecuta realmente. Esto proporciona a la fase de modelado un punto de partida real en lugar de uno basado en talleres y memoria, y ofrece a la gobernanza pruebas de si el proceso modelado es el que la gente sigue realmente.

La medición proviene de una aplicación de escritorio que registra la actividad, las aplicaciones y los archivos que el usuario tiene delante, junto con la interacción, es decir, los clics y los campos que muestran lo que se hizo. Ambos elementos reconstruyen un flujo de trabajo: el proceso tal y como se ejecutó, en lugar de como alguien lo recordaba.

Esto no reemplaza a una plataforma de BPM o de gestión de procesos. Se sitúa por debajo de ella, proporcionando la información de la que depende el modelado. Una vez que un modelo está activo, la misma medición puede mostrar si el proceso modelado y el proceso ejecutado se mantienen alineados o si empiezan a divergir, tal como ocurría con la documentación original. La secuencia tiene una forma clara: descubrir cuál es el proceso realmente, mejorarlo y, finalmente, automatizarlo.

El software de BPM que carece de esta capa pasa directamente al paso de automatización, y todo lo que viene después hereda los aciertos o errores del punto de partida.

No base sus modelos en suposiciones

La herramienta no es lo difícil. Lo difícil es saber qué introducir en ella, y ese conocimiento suele provenir de una documentación que en algún momento fue precisa, pero que ya no lo es. Ninguna de las capacidades aquí descritas resuelve esa brecha por sí sola. Todas asumen que ya se ha cerrado antes de comenzar la implementación.

Todas asumen que ya se ha cerrado antes de comenzar la implementación. Cerrarla es una labor de medición: observar cómo se realiza el trabajo realmente, para que el proceso que automatice sea el que reduce los costes operativos y no el que aparece en el diagrama.

La optimización de flujos de trabajo se encuentra actualmente en fase beta. Solicitar acceso a la versión beta para conocer el estado actual de sus procesos antes de modelarlos.

Preguntas frecuentes

¿Qué es el software de gestión de procesos?

El software de gestión de procesos modela un proceso de negocio, lo ejecuta entre las personas y los sistemas involucrados, y aplica las reglas que rigen su funcionamiento. Sustituye la coordinación improvisada por un flujo de trabajo definido y repetible que el software puede dirigir, versionar y sobre el que puede generar informes. La mayoría de las plataformas también incluyen funciones de gobernanza que controlan cómo puede cambiar un proceso activo con el paso del tiempo.

¿Qué es el software BPM?

El software BPM pertenece a la misma categoría de plataforma que el software de gestión de procesos, solo que bajo un nombre más formal y orientado a grandes empresas. BPM, siglas de gestión de procesos de negocio, suele aparecer en compras corporativas, solicitudes de propuestas (RFP) y análisis de mercado, mientras que "software de gestión de procesos" es más común en el marketing de productos. Funcionalmente, ambos describen la misma capacidad.

¿Cuál es la diferencia entre el software BPM y el software de gestión de flujos de trabajo?

El software BPM modela, ejecuta y gobierna un proceso de negocio completo de principio a fin, incluyendo reglas, aprobaciones y control de versiones. El software de gestión de flujos de trabajo suele ser más limitado, ya que automatiza secuencias de tareas individuales y aprobaciones sin la capa completa de modelado o gobernanza. La gestión de flujos de trabajo puede ser un componente de una plataforma BPM o una alternativa más ligera e independiente.

¿Qué características debe tener un software de BPM?

El software de BPM debe incluir modelado de procesos con una notación estándar, un motor de ejecución de flujos de trabajo, enrutamiento de tareas y aprobaciones, un motor de reglas para lógica condicional, control de versiones y gobernanza, un repositorio central de procesos y análisis sobre el rendimiento de cada proceso.

¿Es necesaria la documentación de procesos antes de implementar un software de BPM?

Sí. Sin una descripción precisa del estado actual de los procesos, la fase de modelado se convierte en un proyecto de descubrimiento sin presupuesto ni alcance definido. La mayoría de las organizaciones cuentan con documentación parcial o desactualizada, y los talleres diseñados para cubrir esa brecha suelen producir el proceso ideal en lugar del que realmente se ejecuta, lo que genera una base inexacta para todos los controles de gobernanza posteriores.

¿Cuánto cuesta un software de BPM?

El costo varía según la cantidad de procesos modelados, el número de usuarios, si la plataforma requiere servicios profesionales para su implementación y el nivel de integración personalizada necesario. Los presupuestos difieren significativamente entre proveedores e incluso entre implementaciones de la misma plataforma, ya que el alcance y la complejidad de la implementación influyen más en el costo que la licencia en sí.


El software mejor valorado a nivel mundial. Amado por los clientes.

Logre una productividad sostenible
con Insightful

No se requiere tarjeta de crédito