Qué es BPM en la era de la IA: guía desde los fundamentos

¿Qué es realmente BPM? Cuando pensamos en BPM, o Business Process Management (en español, gestión de procesos de negocio), solemos pensar en cosas como «es caro», «es para empresas grandes», «consume demasiado tiempo de la gerencia» o «todavía no estamos preparados para eso». ¿Es eso lo que hay realmente detrás de BPM?

Hace diez años ya sosteníamos que todas esas percepciones eran equivocadas. Hoy, con la inteligencia artificial metida en cada etapa de la disciplina, directamente no se sostienen. En este artículo explicaremos BPM desde los fundamentos, en un lenguaje simple y orientado a quien tiene que decidir sobre esto sin ser técnico —el CEO, el gerente general, el director—, y luego iremos etapa por etapa mostrando qué cambia con la IA. Adelantamos la postura: las etapas son las mismas de siempre; lo que cambia es cuánto cuestan, cuánto tardan y quién puede hacerlas.

Todo lo que sigue aplica a BPM en general, como disciplina. Ahora bien, cuando bajemos a ejemplos, estaremos pensando sobre todo en las plataformas BPM no-code (o low-code), que son hoy las más adoptadas por las organizaciones de todo el mundo, sean grandes o chicas. Se configuran desde el navegador, no requieren programadores, y permiten pasar del dibujo del proceso a su ejecución en el mismo día.

Esto no quiere decir que las BPM Suites tradicionales hayan desaparecido. Siguen existiendo y siguen siendo la opción correcta para casos especializados: procesos con volúmenes de transacciones enormes, integraciones profundas con sistemas legados, requisitos regulatorios muy particulares. Son más complejas de implementar y más caras, pero también más potentes. Conviene tener presente la distinción, porque cuando un proveedor dice «BPM» puede estar hablando de dos cosas bastante distintas en costo, en plazo y en el equipo que hace falta para operarlas.

Un proceso de negocio es una secuencia de actividades que ocurren en su empresa para lograr alguno de sus objetivos. Normalmente involucra a varias personas, cada una contribuyendo con una tarea en particular. Pensemos en el siguiente ejemplo: su empresa recibe consultas y pedidos de productos por correo electrónico, por teléfono, por el sitio web, por el call center o directamente a través de los vendedores. En cualquier caso, luego de recibido el pedido, se le asigna a un vendedor, quien se comunica con el cliente para entender mejor su necesidad y armarle una propuesta. Hay propuestas estándar, que van directamente al cliente por correo. Y hay propuestas complejas, que requieren la aprobación adicional del gerente comercial antes de llegar al cliente. Digamos que el cliente sólo puede hacer tres cosas: comprar, rechazar la propuesta o pedir modificaciones. Si compra, el proceso continúa a través del vendedor, que coordina la entrega.

¿Parece complicado? No tanto. Ese párrafo ya describe un proceso completo, con sus tareas, sus responsables, sus decisiones y sus bifurcaciones. Lo que hace BPM es formalizarlo, para poder ejecutarlo, medirlo y cambiarlo sin depender de que cada persona se acuerde bien de cómo era.

Y acá vale la pena volver sobre las percepciones del inicio. Los procesos manuales no son escalables. Dicho de otra manera, la empresa que tenga que procesar el doble de trabajo por unidad de tiempo no podrá hacerlo a mano sin que los costos se disparen, perdiendo competitividad. Una plataforma no-code cuesta hoy lo que una licencia de software de oficina, y el primer proceso se automatiza en días. Ninguna organización, sea del tamaño que sea, debería dejar este tema para más adelante.

BPM se organiza como un ciclo de mejora continua, con cuatro etapas: modelar el proceso, automatizarlo (ponerlo a ejecutar en una plataforma), medirlo mediante indicadores (KPIs) y mejorarlo a partir de lo que esos indicadores muestran. Terminada la cuarta etapa, se vuelve a la primera con una versión nueva del proceso, y el ciclo se repite una y otra vez. Esa es la disciplina, y es la parte que no ha cambiado en veinte años.

Lo que sí cambió, y mucho, es lo que pasa dentro de cada etapa. Vamos a recorrerlas una por una, primero con el enfoque tradicional y luego con lo que la IA agrega hoy. En cada caso daremos algunos ejemplos ilustrativos, que no pretenden ser una lista completa; los usos de la IA en procesos se multiplican cada mes y seguramente cuando usted lea esto ya haya varios más.

Modelar es, en esencia, dibujar el proceso: qué tareas hay, quién las hace, en qué orden, qué decisiones se toman y qué pasa en cada rama. En la práctica, cuando uno modela un proceso para ejecutarlo tiene que definir tres cosas que van juntas. El flujo propiamente dicho (el diagrama). El formulario, es decir, qué datos viajan en cada instancia del proceso (el cliente, el monto, la fecha, los documentos adjuntos). Y las integraciones con otros sistemas, o sea, qué hay que consultar o actualizar en el CRM, en el ERP, en el correo, cuando el proceso pasa por determinado punto.

En el enfoque tradicional, el modelado era la etapa más lenta del ciclo. Reuniones con cada área, un analista que dibuja, revisiones, más reuniones. Semanas, en el mejor de los casos. Y con un problema de fondo que todos hemos visto: el diagrama envejecía rápido, porque el proceso real cambiaba y nadie actualizaba el dibujo.

Hoy el modelado es semiautomático. El punto de partida ya no es una hoja en blanco sino un prompt. Uno le describe el proceso en lenguaje natural —con un párrafo como el del ejemplo de arriba alcanza— y la plataforma genera un primer borrador. A manera de ejemplo, de la frase «las propuestas complejas requieren aprobación del gerente comercial», la IA propone la tarea de aprobación, la compuerta de decisión y las ramas de aprobado y rechazado. Del mismo texto infiere los campos del formulario (cliente, tipo de propuesta, monto, vendedor asignado, fecha límite) y propone tipos de dato y validaciones. Y si el prompt dice «buscar el cliente en el CRM», sugiere el conector correspondiente y el punto del flujo donde va.

El borrador rara vez queda perfecto, y no importa. Lo que cambia es que se parte de un proceso hecho en un 80% y se corrige, en lugar de partir de cero. Y algo más relevante todavía: la persona que conoce el proceso —el gerente comercial, no el analista de sistemas— puede modelarlo directamente y validarlo en la misma sesión. El modelo deja de ser un documento intermedio y pasa a ser el proceso mismo, listo para ejecutar.

Para que el dibujo sea ejecutable y lo entienda todo el mundo, hace falta una notación común. La más utilizada, por lejos, sigue siendo BPMN (Business Process Model and Notation), un estándar del Object Management Group (OMG) que además es norma ISO. La versión vigente, BPMN 2.0, tiene más de una década, y es la referencia tanto en las plataformas no-code como en las BPM Suites tradicionales. Hace años escribimos sobre por qué BPMN es tan importante para una corporación con miles de empleados como para una PyME, y los argumentos siguen vigentes.

Y la condición que consideramos clave: la herramienta elegida debe permitir pasar directamente del modelo BPMN a su ejecución. Tomada la decisión de automatizar un proceso, para que realmente sea un instrumento competitivo hay que poder pasar del dibujo a producción en horas, tal vez días, pero nunca semanas o meses. Si entre el dibujo y el proceso corriendo hay semanas de desarrollo, cada ajuste cuesta demasiado, no se hace, y la mejora continua no ocurre.

Acá conviene ser preciso, porque hay bastante ruido en el mercado. El estándar BPMN 2.0 no tiene un elemento nativo que se llame «tarea de IA» ni «agente». Lo que existe son distintas formas de resolverlo con lo que el estándar ya trae, y todas están en uso hoy. Veamos algunas.

La más común es usar los elementos existentes tal cual. Una llamada a un modelo de lenguaje se modela como una tarea de servicio, igual que cualquier otra integración con un sistema externo. Una decisión que toma la IA se modela como una tarea de regla de negocio, o como una compuerta cuya condición evalúa lo que devolvió el modelo. Y la revisión humana del resultado es una tarea de usuario, como siempre. Con esto se cubre la gran mayoría de los casos, y es lo que hacen las plataformas no-code.

Otra forma, más interesante, aprovecha el subproceso ad-hoc que BPMN 2.0 ya incluía desde el principio: un bloque donde las actividades no tienen un orden fijo. Los motores de procesos más avanzados lo reutilizan para modelar agentes de IA. Dentro del bloque se dibujan las herramientas que el agente tiene disponibles —consultar el CRM, enviar un correo, pedir una aprobación a una persona— y el agente decide en tiempo de ejecución cuáles usar y en qué orden. El proceso BPMN que rodea al bloque sigue controlando los límites: qué puede hacer el agente, cuándo interviene un humano, qué pasa si se agota el tiempo. Es una combinación de autonomía acotada y gobernanza que un directorio debería querer ver dibujada antes de aprobar nada.

También hay propuestas académicas de extender la notación con carriles de agente (con un nivel de confianza y un rol), tareas «agénticas» con estrategias de revisión, y compuertas donde varios agentes colaboran. Son interesantes para seguir de cerca, pero no son estándar, y al momento de escribir esto no hay una iniciativa formal del OMG hacia un «BPMN 3.0».

Automatizar es poner el modelo a correr. Cada instancia del proceso —cada pedido, cada solicitud, cada reclamo— avanza por el flujo, y la plataforma se encarga de asignar cada tarea a la persona que corresponde, avisarle, controlar los plazos, guardar los datos del formulario y ejecutar las integraciones. Se terminan el correo interno, la planilla compartida y la pregunta de «¿en qué quedó esto?».

En el enfoque tradicional, las reglas de la ejecución eran fijas. La asignación seguía una tabla de roles, los textos de las notificaciones eran plantillas, y toda consulta a un sistema externo había que programarla. Esta es la etapa donde la IA se integra en más puntos del proceso, así que vale la pena dar varios ejemplos, siempre entendiendo que son ilustrativos y que hay muchos más.

Un punto que conviene fijar desde el directorio: en todos estos casos el flujo BPMN define en qué tareas interviene la IA, con qué límites y en qué puntos una persona valida. Esa es la diferencia entre automatizar con IA y dejar que un chatbot «resuelva» sin trazabilidad alguna. Es, además, una de las preguntas que un directorio debería estar haciendo sobre la IA antes de aprobar una inversión.

Modelar un proceso implica también definir cómo se lo va a medir. Es parte de la disciplina, y es lo que da objetividad a la discusión sobre cómo está funcionando la organización. Los KPIs clásicos de BPM son pocos y potentes: tiempo de ciclo (cuánto tarda una instancia de punta a punta), tiempo por tarea, volumen procesado por período, tasa de rechazo o retrabajo, cumplimiento de plazos, costo por transacción.

Como la plataforma registra cada paso de cada instancia, los datos siempre estuvieron. El trabajo era armar los reportes, mirarlos y sacar conclusiones. Y ese trabajo, seamos honestos, en la mayoría de las organizaciones se hacía poco y tarde, porque siempre había algo más urgente. Con IA, la medición pasa a ser continua y de bajo costo.

Y además del dato, se obtiene una explicación probable: «el aumento del tiempo de ciclo coincide con la incorporación del paso de verificación de crédito en la versión 3 del proceso». Con esa explicación en la mano, la etapa siguiente arranca con medio camino hecho.

Con los KPIs a la vista, hay que sacar conclusiones, y esas conclusiones suelen implicar modificar el proceso: eliminar un paso, cambiar una condición, agregar una aprobación, mover un plazo. Nuevamente, aquí es fundamental tener el proceso modelado en BPMN sobre una herramienta que lo ejecuta directamente, para que sea simple y rápido introducir la mejora. Dicho de otra forma: si cambiar una etapa o una condición del flujo lleva semanas o meses, no se hará. Y por ende no se mejorará.

La IA baja todavía más el costo de cada iteración, y lo hace a lo largo de toda la etapa.

Con eso volvemos a la etapa 1, con una versión mejor del proceso, y con un ciclo que ahora tarda días en lugar de trimestres.

La IA no decide qué proceso automatizar. Ese sigue siendo un criterio de negocio: el proceso que más duele, el que más se repite, el que más cruza áreas o el que más impacta al cliente. Nuestro consejo sigue siendo el mismo de hace diez años: empezar por uno, uno solo, y aprender con él. Es, en el fondo, el mismo ejercicio de levantar la cabeza y elegir el rumbo antes de nadar más rápido.

La IA no reemplaza la gobernanza del proceso; más bien la exige. Cada punto donde un modelo decide o genera contenido es un punto donde hay que definir quién revisa, qué se registra y qué pasa cuando se equivoca. BPM es justamente el marco para hacerlo, porque el proceso dibujado dice dónde interviene la IA y dónde no. Un directorio que aprueba «automatizar con IA» sin ver ese dibujo está aprobando algo que no entiende del todo.

Y la IA reduce el costo de cada etapa, no la necesidad de hacerlas. Un proceso mal modelado que se ejecuta más rápido sigue siendo un proceso mal modelado. La disciplina es la misma; lo que pasa es que el ciclo da muchas más vueltas por año.