Gestión de procesos empresariales en la banca: qué es y por qué importa

Si ha asistido a una revisión de operaciones en la que alguien dijo «necesitamos una mejor gestión de procesos empresariales (BPM)» y toda la sala asintió sin que nadie acordara qué significaba exactamente, está en el lugar adecuado.

Los equipos de operaciones bancarias se enfrentan a esto constantemente. La BPM acaba en la agenda como respuesta a cualquier problema actual —incorporación lenta de clientes, brechas de cumplimiento, acumulación de aprobaciones de préstamos— y entonces comienza la evaluación. ¿Qué herramienta? ¿Qué proveedor? ¿Cuánto tiempo llevará implementarla? Son preguntas reales, pero producirán respuestas equivocadas si el equipo no ha resuelto antes algo más básico: qué es realmente la gestión de procesos empresariales, en contraste con las herramientas de automatización, el software de seguimiento de proyectos y las plantillas de flujo que se confunden continuamente con ella.

Dónde suelen bloquearse los equipos antes de empezar

• La BPM es una disciplina de gestión para procesos repetibles, no una categoría de software; comprar una herramienta antes de modelar el proceso no resuelve el problema subyacente.
• Los flujos bancarios que más se deterioran —KYC, aprobaciones de préstamos, verificaciones de cumplimiento— son precisamente aquellos en los que la BPM genera valor operativo real.
• La idea errónea más costosa: tratar la BPM como equivalente a la gestión de tareas o la automatización, y luego preguntarse por qué la implementación se estanca a los tres meses.

Qué significa realmente la gestión de procesos empresariales en un contexto bancario

IBM y Gartner definen la gestión de procesos empresariales como una disciplina que descubre, modela, analiza, mide, mejora y optimiza procesos repetibles. Esa es la versión académica. La versión operativa para cualquier persona que trabaje en operaciones bancarias es más sencilla: la BPM es la forma de tomar un proceso que se ejecuta miles de veces, hacerlo visible y hacerlo gobernable.

La palabra importante aquí es «disciplina». No software. No automatización. Una disciplina: algo que se aplica a los procesos antes y después de implementar cualquier tecnología sobre ellos.

Lo que hace relevante esta definición específicamente en banca es aquello que coordina la BPM: personas, sistemas, información y materiales a lo largo de un flujo integral para producir un resultado empresarial definido. La debida diligencia de clientes, por ejemplo, no es solo una lista de verificación de documentos. Es un proceso que involucra al personal de atención al cliente, los equipos de cumplimiento, los datos bancarios centrales, los sistemas de gestión documental y los registros regulatorios. La BPM es lo que proporciona a toda esa cadena una estructura definida, etapas medibles y un registro de auditoría.

La dirección de la banca y los servicios financieros está sometida a una presión real actualmente para hacer precisamente esto. La propuesta normativa de FinCEN de abril de 2026 —que reorientaría el cumplimiento de AML/CFT hacia la efectividad basada en riesgos en lugar de la integridad procedimental— es una señal directa de que las expectativas regulatorias se están desplazando hacia procesos empresariales diseñados y medibles, en vez de procesos guiados por listas de comprobación. Eso es lo que la BPM, en su forma práctica, debe ofrecer.

A diferencia de una herramienta de flujo o un sistema de seguimiento de proyectos, la BPM en banca gestiona las operaciones empresariales a nivel de proceso, no a nivel de tarea ni de proyecto. Esa distinción es la que realmente cambia lo que evalúa y lo que construye.

Las expectativas de los clientes también han cambiado lo suficiente como para que los plazos bancarios tradicionales —días para abrir una cuenta, semanas para procesar un préstamo— generen ahora una pérdida de clientes visible. La gestión de procesos ya no es solo un instrumento de cumplimiento. También se está convirtiendo en uno de retención de clientes. La BPM existe en la intersección de ambos, y el sector bancario es una de las industrias donde ignorar esa intersección resulta más costoso.

Por qué la BPM en el sector bancario no es lo mismo que la gestión de tareas o la gestión de proyectos

La gestión de proyectos se ocupa de trabajo puntual con un final definido. La gestión de tareas realiza el seguimiento de acciones individuales. La BPM no gestiona ninguna de estas dos cosas. Gestiona procesos que se ejecutan repetidamente, a escala, bajo restricciones de cumplimiento y que deben producir el mismo resultado defendible cada vez.

Ese es el límite definitorio. Y la razón por la que se cruza continuamente es que la mayor parte del software que las personas utilizan a diario —Jira, Asana, Trello e incluso Notion— fue creado para el trabajo de tareas y proyectos. Cuando intenta gobernar procesos bancarios centrales con estas herramientas, obtiene algo que parece gestionado, pero no lo está. Los pasos se realizan, pero las excepciones se manejan de manera informal, el registro de auditoría vive en hilos de Slack y la capacidad de defender el cumplimiento desaparece en cuanto alguien se desvía de la secuencia prevista.

Un proceso empresarial bancario no se ejecuta una sola vez. La originación de préstamos se realiza a diario. La incorporación de clientes se ejecuta continuamente. La detección AML funciona casi en tiempo real. Estos son los procesos empresariales para los que la BPM está diseñada: repetibles, sensibles al cumplimiento, propensos a excepciones y con consecuencias graves cuando fallan silenciosamente.

El enfoque de IBM es directo al respecto: la BPM se centra específicamente en procesos integrales repetibles. Esa especificidad importa más en el sector bancario y de servicios financieros que en sectores donde un paso omitido en un proceso le cuesta una venta. En banca, puede costarle una observación regulatoria.

El software de gestión de procesos empresariales está diseñado para modelar, ejecutar, supervisar y mejorar este tipo de procesos a escala. Eso es fundamentalmente diferente del software que realiza el seguimiento de quién es responsable de una tarea. La distinción no es académica. Los equipos que los confunden descubren la brecha cuando sus procesos bancarios centrales se enfrentan a un caso de excepción y nadie sabe qué hacer después, porque el proceso nunca se modeló: solo estaba documentado en la mente de alguien.

Lo que agiliza las operaciones bancarias a este nivel es disponer de un modelo formal del proceso antes de seleccionar la herramienta. Ese modelo es el trabajo de la BPM. El software viene después.

Los tres tipos de BPM que aparecen con mayor frecuencia en las operaciones bancarias

La BPM no sigue un único patrón de implementación. Existen tres tipos que surgen habitualmente en la banca, y los modos de fallo de cada uno son lo suficientemente específicos como para que merezca la pena identificarlos antes de empezar a evaluar soluciones.

• BPM centrada en la integración

  Gestiona flujos de sistema a sistema con una implicación humana mínima. En banca, aparece en el procesamiento de pagos, el enrutamiento de transacciones en tiempo real y la sincronización de sistemas bancarios centrales. El modo de fallo: los equipos seleccionan una BPM centrada en la integración para procesos que en realidad requieren criterio humano en pasos clave, como las aprobaciones de excepciones. El flujo se ejecuta, pero las excepciones se acumulan silenciosamente porque no existe un punto estructurado de decisión humana, solo una cola que se llena.

• BPM centrada en las personas

  Diseñada para flujos de aprobación en los que las decisiones requieren intervención humana en etapas definidas. Las aprobaciones de préstamos, las cadenas de escalamiento y las revisiones de riesgo de clientes encajan aquí. En los flujos bancarios, este tipo se aplica incorrectamente cuando se mantienen los pasos de aprobación, pero se elimina la lógica de asignación de roles. Se obtiene un flujo en el que cualquiera puede aprobar cualquier cosa, lo que desde una perspectiva de auditoría es peor que no tener ningún flujo. La responsabilidad desaparece mientras se mantiene la apariencia de un proceso.

• BPM centrada en documentos

  Gestiona flujos en los que los documentos son el principal artefacto que se crea, revisa, aprueba o archiva. Los paquetes KYC, contratos de préstamos, presentaciones regulatorias y archivos de auditoría pertenecen a esta categoría. Los sistemas bancarios que aplican mal una BPM centrada en documentos suelen hacerlo tratando la recopilación documental como el punto final del proceso, en lugar de como un paso dentro de un flujo de cumplimiento más amplio. Los traspasos entre la captura, revisión y conservación de documentos ocurren por correo electrónico, creando brechas que aparecen durante las auditorías en vez de durante la incorporación.

📊 En la práctica:
La incorporación KYC es un problema de BPM centrada en documentos. El paquete incluye documentos de identidad, resultados de evaluaciones de riesgo, declaraciones de titularidad real y activadores de supervisión continua, todo ello vinculado a plazos de cumplimiento. Los traspasos manuales entre estos pasos son donde realmente se forman las brechas de cumplimiento. Según el boletín de abril de 2026 de la OCC sobre los requisitos de programas AML/CFT, los requisitos de debida diligencia de clientes se están reforzando explícitamente en la propuesta normativa. Un proceso KYC sin un modelo formal centrado en documentos es un pasivo regulatorio que se agrava con cada nueva cuenta.

Dónde genera la BPM en banca valor operativo real

La BPM aparece en todas las operaciones bancarias donde un proceso es recurrente, sensible al cumplimiento y tiene consecuencias cuando falla. Eso abarca gran parte de la carga de trabajo diaria. Cinco casos de uso concentran la mayor parte de la presión operativa.

Incorporación de clientes, KYC y los procesos que fallan sin un modelo claro

La incorporación de clientes es uno de los procesos bancarios que se modelan con más frecuencia por una razón sencilla: omitir un paso tiene consecuencias regulatorias. El proceso integral de incorporación abarca la verificación de identidad, la evaluación de riesgos, la recopilación documental, la revisión de titularidad real y la configuración de supervisión continua. Cada paso depende, desde el punto de vista del cumplimiento, de los anteriores.

Cuando este proceso se ejecuta mediante procesos manuales —cadenas de correo electrónico, carpetas compartidas, listas de comprobación informales— las brechas no aparecen durante la apertura normal de cuentas. Aparecen durante una revisión regulatoria, cuando un inspector solicita el registro de auditoría de una cuenta concreta y la respuesta es un PDF en la bandeja de entrada de alguien.

La BPM aplicada a este proceso bancario hace algo concreto: explicita cada paso, dirige el trabajo al rol correcto cuando se requiere revisión humana y crea un registro documentado de qué sucedió y cuándo. La propuesta normativa de la OCC exigiría una debida diligencia de clientes vinculada a un proceso formal de evaluación de riesgos. No es un requisito tecnológico, sino un requisito de diseño de procesos que la tecnología respalda posteriormente.

Veo que esto surge continuamente con los equipos de cumplimiento: llevan años realizando KYC, pero cuando se les pide mostrar el proceso, presentan una serie de tareas desconectadas en lugar de un flujo modelado. Esa es la diferencia que la BPM debe aportar.

Procesamiento y aprobaciones de préstamos: donde la BPM centrada en las personas demuestra su valor

El procesamiento de préstamos es el argumento más claro a favor de la BPM centrada en las personas en banca. La cadena de aprobación —desde la recepción de la solicitud hasta la revisión crediticia, la suscripción, las verificaciones de cumplimiento y la aprobación final— implica inherentemente múltiples roles, es propensa a excepciones y sensible al tiempo. Cuando esos pasos son informales, normalmente fallan dos aspectos: el manejo de excepciones y la responsabilidad.

El manejo de excepciones sin un modelo BPM significa que, cuando una solicitud de préstamo queda fuera de los criterios estándar, se escala según lo que el revisor considere apropiado ese día. A veces a la persona correcta. A veces al superior de su superior. A veces a una bandeja de entrada compartida que nadie revisa los viernes.

La BPM centrada en las personas resuelve esto codificando las reglas empresariales para cada punto de decisión. Quién aprueba qué, bajo qué condiciones y en qué plazo. Cuando ocurre una excepción, el flujo la dirige al rol adecuado según el modelo de proceso, no según quién esté disponible cerca. Los plazos de procesamiento de préstamos se vuelven predecibles. Los registros de auditoría se vuelven defendibles. Y la cadena de aprobación deja de depender de una memoria institucional que sale por la puerta cuando alguien se marcha.

Puede automatizar pasos específicos dentro de este proceso: extracción de documentos, consultas a agencias de crédito, verificaciones de indicadores de cumplimiento. Pero la automatización es posterior al modelo BPM. El modelo define qué hace la automatización y por qué.

Cumplimiento y gestión de riesgos como proceso continuo, no como revisión trimestral

El cumplimiento y la gestión de riesgos en banca no son un ejercicio de auditoría anual. Son una función operativa que se ejecuta cada día, en cada relación con clientes, cada transacción y cada evento de incorporación. La BPM permite ejecutarla a escala al transformar los puntos de control de cumplimiento de eventos reactivos en pasos de proceso diseñados.

La propuesta de FinCEN de abril de 2026 plantea explícitamente este cambio: los bancos deberían orientar los recursos hacia actividades de mayor riesgo y reducir la carga innecesaria en las de menor riesgo. Es un requisito de rediseño de procesos. No puede priorizar según el riesgo si sus procesos de cumplimiento tratan todas las cuentas de forma idéntica porque los activadores de revisión no están modelados, sino simplemente programados.

La BPM aplicada a la gestión de riesgos y cumplimiento hace que el proceso sea continuo y condicional. Activadores de revisión basados en cambios de puntuación de riesgo, anomalías en transacciones, ciclos periódicos o fechas de vencimiento regulatorias. Cada activador se dirige al paso de flujo adecuado con la parte interesada correcta y el requisito documental apropiado. Los datos financieros necesarios para la revisión forman parte de la definición del proceso, no algo que un analista deba reconstruir desde varios sistemas la mañana de la revisión.

La función de garantizar el cumplimiento dentro de un marco BPM es lo que crea el registro preparado para auditoría que los reguladores esperan cada vez más, no como un informe retrospectivo, sino como evidencia de una gobernanza continua del proceso.

Cómo funciona la BPM en la práctica: del descubrimiento del proceso a la optimización

El ciclo de vida de la BPM tiene seis etapas. Conviene tomar en serio el enfoque de IBM: un sistema BPM exitoso comienza definiendo las etapas de un flujo antes de hacer cualquier otra cosa. La cuestión de las herramientas viene después de la segunda etapa, no antes de la primera. Esa secuencia se invierte con más frecuencia de la que debería.

Cada etapa responde a una pregunta que un responsable de operaciones bancarias realmente formularía:

Descubrir: ¿Con qué proceso está tratando realmente? No el que aparece en el documento de políticas, sino el que se ejecuta hoy. Mapear lo que sucede actualmente, incluidos los pasos informales, las soluciones alternativas para excepciones y los roles que no figuran en el organigrama pero que en la práctica son fundamentales, es la parte más difícil. La mayoría de las implementaciones BPM que se estancan lo hacen porque esta etapa se apresuró.

Modelar: ¿Cómo debería ejecutarse el proceso? Defina cada paso, cada rol, cada punto de decisión y cada ruta de excepción. El modelo es el artefacto que hace posible todo lo demás. La automatización de procesos en banca sin un modelo solo automatiza la confusión actual, más rápido.

Analizar: ¿Dónde están los cuellos de botella, las brechas de cumplimiento y los pasos redundantes? Aquí es donde encuentra la cola de excepciones de los viernes por la tarde que lleva dos años acumulándose porque nadie modeló qué hacer cuando el documento no coincide con la dirección declarada por el solicitante.

Medir: ¿Cuáles son las métricas del proceso? Tiempo de ciclo, tasa de excepciones, cumplimiento de SLA, tasa de finalización de pasos. Estas métricas se incorporan a la capa de supervisión. Sin medición, no puede saber si una mejora funcionó.

Mejorar: Rediseñe según el análisis. Esto podría implicar eliminar un paso, dirigir las excepciones de otra manera, añadir un nodo de automatización o cambiar la lógica de asignación de roles. El objetivo de mejora debe ser específico: «reducir el tiempo de finalización de KYC eliminando el paso de reintroducción manual de documentos», no genérico.

Optimizar: Itere según los resultados medidos. La automatización de procesos en banca no es un proyecto puntual. El proceso cambia a medida que evolucionan las regulaciones, cambian los productos y crece el volumen. La etapa de optimización es donde la BPM se convierte en una capacidad continua en lugar de una instalación única.

Para los equipos que evalúan dónde encaja Latenode: resulta útil en la capa de automatización, conectando formularios de recepción, API de cumplimiento, procesamiento de documentos y lógica de enrutamiento en flujos ejecutables una vez que existe el modelo de proceso. Un ejemplo práctico: llega una solicitud de préstamo, un flujo de Latenode obtiene los datos del solicitante, los ejecuta mediante una verificación de cumplimiento a través de API, crea ramas según el nivel de riesgo y dirige el paquete a la cola de revisión adecuada. Así funciona la automatización de procesos en banca según lo previsto, pero solo porque alguien modeló primero el proceso.

Ahí es donde realmente reside la optimización de procesos. No en la selección de herramientas, sino en la mejora iterativa de un proceso modelado que las herramientas respaldan.

Beneficios de la BPM en banca: qué cambia y qué sigue siendo difícil

La versión honesta de los beneficios de la BPM incluye tanto las mejoras reales como las cosas que no mejoran automáticamente al implementar una capa de gestión de procesos.

Lo que realmente cambia:

Eficiencia operativa y productividad de los empleados. Se eliminan los pasos que eran informales o duplicados. Las decisiones de enrutamiento que requerían que alguien recordara cuáles eran las reglas se automatizan. Las personas que realizan el trabajo dedican menos tiempo a decidir qué hacer después y más a hacerlo. Los equipos de cumplimiento con los que he hablado describen esto principalmente como una reducción de la carga cognitiva de recordar rutas de excepción, no como una reducción de plantilla.

Velocidad de incorporación de clientes y experiencia del cliente. Un proceso de incorporación modelado con condiciones claramente definidas para el procesamiento directo frente a la revisión manual reduce la comunicación de ida y vuelta que hace que los clientes abandonen a mitad de la solicitud. Las expectativas de los clientes en banca han cambiado significativamente: una apertura de cuenta que tarda una semana cuando un competidor la completa en un día es un problema de retención disfrazado de problema de proceso.

Satisfacción del cliente y preparación para auditorías. Cuando el proceso se modela y supervisa, dispone de la documentación necesaria para mostrar a los reguladores, responder a las quejas de clientes e investigar discrepancias. El registro de auditoría es un subproducto de la gobernanza del proceso, no un proyecto independiente. Es una mejora significativa de la eficiencia operativa, aunque no aparezca en una métrica de panel.

Lo que sigue siendo difícil:

La BPM no corrige un mal diseño de procesos; simplemente hace que un mal diseño se ejecute de manera consistente a escala. Un flujo KYC mal modelado, una vez implementado en un sistema BPM, producirá brechas de cumplimiento de forma fiable y repetible. La etapa de modelado debe generar un proceso que merezca ser modelado. Eso exige que participen personas que comprendan tanto los requisitos de cumplimiento como la realidad operativa, y esas conversaciones rara vez son tan fluidas como la fase de implementación.

La adopción por parte de los empleados se subestima sistemáticamente. Una implementación BPM que no tenga en cuenta cómo trabajan actualmente las personas —las rutas de escalamiento informales, las soluciones alternativas que existen por razones reales— encontrará una resistencia que parece un fallo de gestión del cambio, pero que en realidad es un problema de diseño de procesos.

Para agilizar las operaciones, la BPM requiere una responsabilidad continua. No hay nada más costoso que una implementación BPM que se completó, documentó y luego se entregó a quien tenía menos trabajo ese trimestre.

🤔 Espere.
El error más común que veo cometer a los equipos no es elegir el software BPM equivocado. Es comprar software BPM antes de completar el descubrimiento del proceso. Una herramienta que modela y automatiza el proceso equivocado hará que ese proceso equivocado sea más rápido y más difícil de revertir. La recomendación de IBM es específica: defina primero las etapas del flujo. Cada hora dedicada al descubrimiento del proceso antes de la adquisición vale considerablemente más que esa misma hora destinada a evaluar demostraciones de proveedores.

RPA y BPM en banca: cómo encaja la automatización robótica de procesos en el panorama

La RPA y la BPM se confunden regularmente en conversaciones sobre operaciones bancarias, normalmente cuando alguien vuelve de una demostración de proveedor y presenta la automatización robótica de procesos como la solución BPM. Están relacionadas, pero no son lo mismo, y tratarlas como intercambiables conduce a un modo de fallo específico y reconocible.

La BPM es la capa de diseño y gobernanza. Define qué es el proceso, cómo fluye, quién gestiona cada paso y qué ocurre en cada condición. La RPA es una capa de ejecución: robots de software que realizan tareas repetitivas específicas dentro de un paso de ese proceso. Un robot puede iniciar sesión en un sistema, extraer datos, pegarlos en otro campo y activar el siguiente paso del flujo. Eso es realmente útil dentro de un proceso bien diseñado.

Pero la RPA sin BPM es automatización en finanzas y banca aplicada a tareas individuales sin un modelo de proceso integral subyacente. Los robots realizan correctamente sus pasos. El proceso a su alrededor sigue siendo informal. Las excepciones siguen siendo gestionadas por quien detecta primero el problema. El registro de auditoría sigue viviendo en el correo electrónico.

La automatización que funciona en el sector bancario suele seguir el patrón BPM por encima y RPA por debajo: la capa BPM diseña y supervisa el proceso, y la capa RPA ejecuta los pasos de tareas repetitivas dentro de él. El planteamiento de SS&C Blue Prism es acertado: la RPA gestiona la ejecución de tareas estructuradas específicas; la BPM gobierna para qué sirven esas tareas y cómo se conectan con los resultados de cumplimiento.

La automatización de procesos empresariales a escala requiere que ambas capas trabajen juntas. La pregunta no es cuál elegir. Es cuál diseñar primero. La respuesta siempre es BPM. Y siempre en ese orden.

Qué evaluar al elegir herramientas BPM para flujos bancarios

La primera pregunta de selección que vale la pena formular es: ¿qué problema de flujo bancario está resolviendo? La respuesta debe surgir del trabajo de descubrimiento del proceso, no de una comparación de proveedores. Una vez que sabe qué está resolviendo, la evaluación de herramientas se vuelve considerablemente más manejable.

Utilizando los tres tipos de BPM como marco de selección:

Además de la adecuación por tipo, esta es la lista de comprobación práctica:

• ¿Puede modelar excepciones, no solo flujos directos?

  La mayoría de los procesos bancarios se comportan correctamente el 80 % del tiempo. El 20 % en el que no lo hacen es donde se concentra el riesgo regulatorio y de clientes. Una solución BPM que solo gestiona el camino limpio es un pasivo en los flujos bancarios.

• ¿Genera registros preparados para auditoría de forma predeterminada?

  No como un paso de exportación independiente, sino como resultado natural de la ejecución del proceso. Dado que las presiones de cumplimiento avanzan hacia una documentación basada en riesgos, el registro del flujo debe poder defenderse por sí mismo.

• ¿Cómo será el modelo de mantenimiento seis meses después de la puesta en marcha?

  Esta pregunta no aparece en las páginas de comparación de proveedores. Los procesos cambian, las regulaciones cambian y el personal cambia. Una solución BPM que requiere recursos especializados para actualizarse es una solución BPM que perderá alineación con el proceso real durante el año.

Las plataformas BPM y los proveedores de soluciones BPM presentarán sus herramientas como el punto de partida. En realidad, el punto de partida es un proceso modelado. Evalúe la herramienta frente a un diseño de proceso real, no frente a una plantilla genérica de flujo bancario. Las herramientas de banca digital parecen prácticamente equivalentes en las demostraciones. Las diferencias aparecen en el cuarto mes, cuando el proceso cambia y alguien debe actualizar el modelo.

La selección de software BPM, cuando se realiza correctamente, tiene menos que ver con comparar funcionalidades y más con la adecuación operativa: qué herramienta utilizará, actualizará y gestionará realmente su equipo con el tiempo.