La mayoría de los equipos descubren la gestión dinámica de casos de la misma manera: crean un flujo, este gestiona correctamente el 80 % de los casos y, de pronto, el otro 20 % empieza a causar problemas. Las excepciones se acumulan. Las soluciones alternativas se multiplican. Alguien crea una hoja de cálculo para hacer seguimiento de los casos límite que la automatización no puede gestionar, y ahora mantiene dos sistemas en lugar de uno.
No es un problema del flujo. Es una señal de que el trabajo en sí es realmente no estructurado y de que la herramienta utilizada no fue diseñada para ello.
La gestión dinámica de casos existe precisamente para ese 20 %. Esta guía explica qué es realmente, en qué se diferencia de las herramientas que probablemente ya utiliza y cómo saber si la necesita o si un flujo más sencillo haría bien el trabajo.
No es un ticket más inteligente: es un modelo completamente diferente
- La DCM está diseñada para trabajos en los que el recorrido y el resultado no pueden definirse de antemano; no es una versión mejorada de la automatización de flujos.
- El modelo híbrido de personas y automatización es estructural: los gestores de casos dan forma al proceso en tiempo real; la tecnología se adapta en torno a sus decisiones.
- Los servicios financieros, la salud, el sector público y las funciones legales son quienes más la utilizan: cualquier ámbito donde las excepciones sean la norma, no el caso límite.
Qué es realmente la gestión dinámica de casos
La gestión dinámica de casos (DCM) es un modelo de coordinación para trabajos que no pueden guionizarse por completo de antemano. La definición formal, alineada con cómo Gartner y Mendix entienden este concepto, describe la DCM como un sistema que coordina trabajo no estructurado e impulsado por excepciones entre personas, sistemas y agentes en tiempo real, con el objetivo de alcanzar un resultado específico en lugar de ejecutar una secuencia predefinida de pasos.
El enfoque de Forrester es más contundente: denomina a esta categoría «procesos indomables». Trabajo demasiado variable, que exige demasiado criterio y depende demasiado de datos contextuales como para poder capturarse en un diagrama de flujo fijo. La palabra «dinámica» en el nombre se refiere específicamente a la modificación del proceso durante su ejecución: la capacidad de cambiar lo que sucede después en un caso mientras el caso sigue abierto, según nueva información o cambios en las circunstancias. No se trata solo de configurar el proceso antes de empezar. Se trata de cambiarlo mientras está en marcha.
La DCM también se denomina gestión adaptativa de casos (ACM) en la literatura de analistas y proveedores. Los términos son intercambiables. Describen el mismo enfoque para trabajo intensivo en conocimiento, en el que el resultado no puede definirse durante la admisión.
Los trabajadores del conocimiento son los usuarios principales. Son personas que no ejecutan una lista de verificación: toman decisiones basadas en información incompleta, coordinan entre equipos y ajustan su enfoque a medida que evoluciona la situación. Un perito de seguros que investiga una denuncia de fraude. Un coordinador asistencial que gestiona a un paciente con múltiples diagnósticos. Un responsable de cumplimiento que revisa una solicitud de permiso que afecta a tres marcos regulatorios.
El enfoque dinámico sitúa a esos trabajadores en el centro del proceso y articula la tecnología en torno a su criterio, en lugar de intentar sustituirlo por reglas.
Gestión dinámica de casos frente a BPM y automatización de flujos estándar
Esta es la pregunta que veo con más frecuencia en soporte y en conversaciones de la comunidad: «Ya tenemos una herramienta de flujos. ¿Es solo otro nombre para lo que ya tenemos?». Por lo general, la respuesta es no. Esta es la diferencia real.
| Dimensión | BPM / flujo estándar | Gestión dinámica de casos |
|---|---|---|
| Estructura del proceso | Definida de antemano; los pasos son fijos en el momento del diseño | Emergente; los pasos se añaden, eliminan o reordenan durante la ejecución según el contexto |
| Quién controla el recorrido | El diseñador del proceso; los gestores de casos siguen la ruta | El gestor de casos, guiado por el sistema; la ruta se adapta a sus decisiones |
| Gestión de excepciones | Las excepciones requieren escalación o una anulación manual fuera del sistema | Las excepciones son el estado esperado; el sistema está construido en torno a ellas |
| Intensidad de conocimiento | Baja a media; diseñado para trabajo repetible y de baja variabilidad | Alta; adecuado para trabajos en los que el criterio humano y los datos contextuales determinan el resultado |
| Cuándo basta la automatización | Cuando los pasos y las reglas de decisión son estables en la mayoría de los casos | Cuando los resultados varían tanto que las reglas no pueden cubrir el espacio de decisión |
Conviene detenerse en el enfoque de Forrester: «indomable» frente a «repetible». Un sistema estándar de gestión de procesos de negocio, o BPM, se basa en el supuesto de que puede describir el proceso por completo antes de que se ejecute. Es un buen supuesto para muchos tipos de trabajo: aprobaciones de facturas, listas de incorporación de empleados, cumplimiento de pedidos. Un sistema de gestión dinámica de casos parte del supuesto contrario. El proceso cambiará. Construya el sistema de gestión en torno a esa realidad.
OpenText plantea un punto similar sobre la modificación durante la ejecución: una solución DCM real permite a los gestores de casos cambiar la secuencia de tareas, asignar nuevos participantes o incorporar datos adicionales sin detener el caso ni reconstruir el flujo desde cero. No es una función que tengan la mayoría de las herramientas de flujos para entornos empresariales. Es una diferencia estructural en la forma en que funcionan ambos modelos.
En términos prácticos, esto significa que si su equipo pregunta «¿cómo gestionamos mejor las excepciones?» y las excepciones representan entre el 30 % y el 40 % de su volumen, probablemente no se enfrenta a un problema de excepciones. Se enfrenta a un tipo de trabajo que necesita un sistema de gestión diseñado para procesos complejos, no uno optimizado para el recorrido habitual.
Cómo funciona la gestión dinámica de casos: flujos adaptativos y soporte de decisiones en tiempo real
El mecanismo central es más sencillo de lo que sugiere la jerga. Se crea un caso, ya sea mediante el envío de un formulario, una llamada de admisión, una transacción marcada o cualquier otro desencadenante. Ese caso se convierte en el objeto central: todos los datos, documentos, participantes, tareas y decisiones asociados a él viven en un solo lugar y permanecen conectados durante toda la vida del caso.
Lo que hace que la DCM sea diferente de un registro de caso estándar es lo que ocurre después. El sistema no ejecuta una secuencia fija. Presenta al gestor de casos información contextual, sugiere posibles acciones siguientes basadas en reglas de negocio y datos, y le permite modificar el recorrido —añadiendo tareas, reasignando responsabilidades o incorporando partes interesadas adicionales— en tiempo real, sin detener ni reiniciar el proceso.
La asignación de rutas se basa en datos en lugar de secuencias. Si llega una nueva prueba durante una investigación de reclamación, el sistema puede mostrar automáticamente esos datos, señalar una regla relevante y sugerir una acción actualizada, pero el gestor del caso decide cómo proceder. Es el diseño con intervención humana que describen tanto Flowable como Kissflow: la tecnología amplía el criterio, no lo reemplaza.
La capa de orquestación subyacente gestiona la coordinación: mantiene informadas a todas las partes, conserva el registro de auditoría, hace seguimiento del estado de los SLA y muestra la información adecuada a la persona adecuada en el momento adecuado. Esa es la parte de «tiempo real»: no solo un panel en directo, sino una adaptación activa de lo que presenta el sistema a medida que cambian las circunstancias.
Por qué la gestión adaptativa de casos pone a los gestores de casos al control del recorrido del proceso
La gestión adaptativa de casos significa que las personas que realizan el trabajo dan forma al flujo mientras se ejecuta, no antes de que comience. Esta es la diferencia estructural frente a la automatización basada en reglas.
En un sistema basado en reglas, los trabajadores del conocimiento llegan a una bifurcación de la lógica y siguen la instrucción del sistema o escalan fuera de él. En un modelo de gestión adaptativa de casos, el gestor del caso opera con contexto: ve el panorama completo del caso, evalúa qué debe ocurrir después y dirige el proceso en consecuencia. El sistema sigue su criterio. Proporciona límites —requisitos de auditoría, visibilidad de SLA, puntos de control de cumplimiento—, pero no bloquea la secuencia.
La definición de Flowable sobre la gestión adaptativa de casos refleja bien esta idea: resultados que no pueden definirse por completo de antemano, impulsados por información cambiante en lugar de un recorrido guionizado. La palabra «ágil» aquí no es lenguaje de marketing. Significa que el gestor del caso puede realizar acciones ad hoc —añadir una tarea, solicitar un documento o incorporar a un especialista— sin romper la integridad del caso ni perder trazabilidad. Esa flexibilidad es el objetivo.
Cómo la resolución integral de casos se mantiene encaminada cuando cambian las circunstancias
«Integral» en DCM significa que el ciclo de vida del caso se sigue de forma continua desde la admisión hasta la resolución, incluso cuando las tareas, los participantes y las secuencias cambian durante la ejecución. El caso es el objeto persistente. Todo lo demás —las personas que trabajan en él, los pasos que se realizan, los datos que se recopilan— puede cambiar. El registro del caso no.
Así es como la gestión de casos a escala mantiene la coherencia. El sistema conserva la trazabilidad de cada acción, decisión y modificación. Quién cambió qué, cuándo y basándose en qué información. Ese registro de auditoría es lo que diferencia a la DCM de simplemente realizar trabajo ad hoc sin gestionar: la adaptabilidad existe dentro de una capa de coordinación que mantiene todo visible y sujeto a responsabilidad.
Los SLA se supervisan respecto al caso en su conjunto, no respecto a pasos individuales. Los datos relacionados con el caso de cada participante y sistema se agregan en una vista compartida. El objetivo no es imponer un recorrido específico, sino garantizar que el caso se resuelva y que la resolución esté documentada lo suficientemente bien como para superar una revisión. Eso es lo que «resolver casos» significa realmente en la práctica: resultado logrado, registro íntegro y proceso defendible.
🤔 Espere.
Si los gestores de casos pueden cambiar el proceso siempre que lo necesiten, ¿qué impide que la DCM sea indistinguible de personas haciendo simplemente lo que quieren? La respuesta de la investigación es específica: la DCM proporciona los límites —registro de auditoría, capa de coordinación, datos contextuales y visibilidad de SLA— sin bloquear la secuencia. La adaptabilidad está acotada, no es ilimitada. La diferencia entre flexibilidad estructurada y caos es la integridad del registro del caso.
Casos de uso de gestión dinámica de casos en distintos sectores
La forma más clara de entender dónde encaja la gestión dinámica de casos es analizar los tipos de trabajo en los que la automatización de flujos estándar produce excepciones de forma consistente. Son los sectores donde los «procesos indomables» no son casos límite, sino la norma.
Servicios financieros: investigaciones de fraude y reclamaciones de seguros
En una investigación de reclamaciones de seguros, no hay dos casos que sigan el mismo recorrido. El perito puede necesitar solicitar documentación adicional, involucrar a un tasador especialista, contrastar reclamaciones anteriores o escalar al área legal, en cualquier secuencia, según pruebas que llegan de forma impredecible. Los flujos estándar de procesamiento de reclamaciones gestionan bien las renovaciones rutinarias. Un sistema DCM gestiona los casos impredecibles en los que el perito —no el sistema— debe determinar qué ocurre después. El modo de fallo de la automatización estándar en este contexto está bien documentado: el flujo cubre las situaciones habituales y falla en cada caso complejo, generando excepciones manuales que se acumulan fuera del sistema.
Salud: coordinación asistencial con múltiples partes interesadas
Un paciente ingresado con múltiples comorbilidades crea un episodio asistencial que abarca equipos de urgencias, cirugía, rehabilitación y trabajo social, a menudo de forma simultánea. Coordinarlo requiere un objeto de caso que persista entre todos los departamentos, se adapte a medida que cambia el cuadro clínico y mantenga a todos los participantes trabajando con los mismos datos contextuales. El trabajo de Harmony Healthcare sobre coordinación asistencial lo describe directamente: el sistema muestra información relevante a cada profesional clínico en el momento adecuado y permite a los coordinadores asistenciales adaptar el plan cuando cambian las condiciones. Un flujo rígido no puede adaptarse a la variabilidad de la atención real al paciente. La sobrecarga de coordinación que esto genera —APQC descubrió que los trabajadores del conocimiento dedican aproximadamente el 25 % de su tiempo a buscar información y gestionar comunicaciones internas— es precisamente lo que la DCM está diseñada para reducir.
Sector público: permisos, prestaciones y revisiones de cumplimiento
Las agencias públicas que gestionan solicitudes de prestaciones, aprobaciones de permisos o revisiones de cumplimiento se enfrentan a documentación incompleta, asignación entre múltiples departamentos y variaciones regulatorias que hacen que cada caso sea estructuralmente diferente del anterior. Los flujos gubernamentales asistidos por IA descritos en el análisis de Public Sector Network siguen un patrón DCM reconocible: la admisión activa la agregación de documentos y datos, la IA extrae y señala información faltante, los trabajadores añaden tareas ad hoc a medida que llegan nuevas pruebas y el registro del caso conserva una pista de auditoría completa para el cumplimiento. La automatización gestiona la admisión y la asignación. El gestor del caso aplica el criterio. Ninguno puede hacer el trabajo del otro.
RR. HH. corporativos y legal: gestión de excepciones entre funciones
Las reclamaciones de empleados, revisiones disciplinarias, disputas contractuales e investigaciones de cumplimiento comparten la misma estructura: recorridos impredecibles, colaboración entre múltiples partes y resultados que dependen en gran medida del contexto acumulado durante el caso. La gestión de tickets estándar de RR. HH. maneja bien las solicitudes de servicio rutinarias, como restablecimientos de contraseñas o solicitudes de permisos. Falla en los casos complejos porque el modelo de tickets supone un recorrido de resolución definido. La DCM los gestiona porque no lo supone. El patrón de gestión de incidentes en legal y RR. HH. también está impulsado por la coordinación de partes interesadas: legal, RR. HH., finanzas y dirección suelen necesitar incorporarse en distintos momentos según lo que revele el caso.
Para concretar el lado de la orquestación: en Latenode, un desencadenante de admisión desde un portal existente —una solicitud de prestaciones, una transacción marcada o una etiqueta de escalación— puede iniciar un flujo que agregue documentos de múltiples sistemas (utilizando su biblioteca de más de 5.500 integraciones con OAuth automático), los envíe a un modelo de IA para extraer datos y detectar carencias, y asigne el caso a la cola adecuada según lo que encuentre la IA. Cuando surge algo inusual a mitad del caso, el flujo se adapta: un gestor de casos añade una tarea, el sistema la registra, el reloj del SLA sigue corriendo y el registro del caso se mantiene completo. Es una orquestación al estilo DCM construida sobre una plataforma low-code, sin una base de datos vectorial independiente ni un servidor nuevo para cada paso lógico. El modelo de precios por ejecución también importa aquí: un flujo de caso de seis pasos cuenta como una ejecución, lo que mantiene los costes previsibles a medida que crece el volumen de casos. Para implementar este patrón, conectaría su fuente de admisión, configuraría el paso de extracción con IA y definiría la lógica de asignación: aproximadamente entre 60 y 90 minutos de configuración si las credenciales OAuth están listas.
Cuándo usar gestión dinámica de casos y cuándo basta un flujo más sencillo
Calcularía que la mitad de las conversaciones que he tenido sobre herramientas DCM terminan con el equipo dándose cuenta de que en realidad no necesita una. No es un fracaso: es un buen trabajo de diagnóstico. La DCM resuelve un problema específico. Si ese problema no es el suyo, la sobrecarga no merece la pena.
Use DCM cuando:
Los resultados no pueden definirse durante la admisión
Si no puede escribir un diagrama de flujo completo para un tipo de caso antes de que se abra —porque lo que sucede después depende de pruebas que llegan durante el caso—, está en terreno de DCM. Esta es la señal de los «procesos indomables» de Forrester. El recorrido no se oculta al sistema; realmente todavía no existe.
Los casos requieren criterio humano y datos contextuales
Cuando una decisión no puede tomarse solo con reglas, los datos relevantes están repartidos entre múltiples sistemas y una persona debe sintetizar ambos elementos, se trata de trabajo intensivo en conocimiento. La DCM está diseñada para esto. Una herramienta de flujos no.
El volumen de excepciones es lo suficientemente alto como para convertirse en la norma
Si las excepciones representan más del 20 % al 30 % de su volumen de casos, no tiene un problema de excepciones. Tiene trabajo estructuralmente variable. Intentar gestionarlo mediante las rutas de escalación de un flujo lineal crea un sistema manual paralelo que se vuelve más difícil de mantener con el tiempo.
Un flujo más sencillo basta cuando:
El proceso es repetible y de baja variabilidad
Un BPM estándar, un sistema de tickets bien configurado o una automatización de flujos básica gestionan esto mejor, y con menor coste y complejidad. Las solicitudes al service desk de TI con SLA definidos, las secuencias de cumplimiento de pedidos, los informes programados y las listas de incorporación de empleados son buenos ejemplos. Los procesos de gestión implicados son previsibles. Un sistema DCM en este caso supone sobrecarga técnica sin beneficio.
La lógica de decisión puede codificarse en reglas
Si puede escribir el árbol de decisiones por completo, incluso uno complejo, BPM o un motor de reglas es una mejor opción. La atención al cliente de un producto SaaS suele encajar aquí: la mayoría de las solicitudes de servicio siguen patrones reconocibles con respuestas guionizadas. Usar DCM para atención al cliente rutinaria es excesivo.
📊 En la práctica:
Una renovación rutinaria de póliza de seguro sigue una secuencia fija: verificación de datos, ejecución del pago, generación de documentos y confirmación. La automatización de flujos estándar la gestiona bien. Una investigación de fraude sobre esa misma póliza no: el perito puede necesitar obtener el historial de transacciones, solicitar documentación a tres partes, consultar a un especialista y modificar su enfoque a medida que llega cada prueba. Mismo sector, misma empresa, tipo de trabajo diferente. Uno necesita un flujo. El otro necesita DCM.
Qué debe gestionar realmente una solución de gestión dinámica de casos
Los proveedores añaden «caso» a los productos igual que añaden «IA»: a veces de forma significativa, a veces como una etiqueta sobre algo que ya existía. Si un equipo está evaluando una solución de gestión dinámica de casos, estos son los requisitos funcionales que distinguen a un sistema DCM auténtico de una herramienta de flujos con una interfaz renombrada.
Modificación del proceso sobre la marcha. El sistema debe permitir a los gestores de casos añadir tareas, cambiar secuencias, reasignar responsabilidades e incorporar nuevos participantes mientras el caso está activo, sin detenerlo ni reconstruir el flujo. Esta es la definición estructural de DCM. Si un sistema no puede hacerlo, no es DCM, independientemente de lo que diga la página del producto.
Coordinación de datos contextuales. Todos los datos relacionados con el caso —documentos, comunicaciones, historial de decisiones y notas de participantes— deberían ser accesibles desde el registro del caso, actualizarse en tiempo real y ser visibles para todas las partes interesadas relevantes. Un sistema de gestión de casos que obliga a los trabajadores a alternar entre cinco herramientas distintas para reunir el contexto no está coordinando casos. Está añadiendo una capa sobre el mismo problema.
Soporte de decisiones con intervención humana. El sistema debe mostrar información relevante, sugerir las mejores acciones siguientes y señalar anomalías sin eliminar la capacidad del trabajador de anular o redirigir. Las sugerencias impulsadas por IA son útiles. La automatización impulsada por IA que elimina el criterio humano de decisiones intensivas en conocimiento es otra cosa y, a menudo, el diseño equivocado para el trabajo DCM.
Auditabilidad. Cada acción, modificación, decisión y cambio de datos debe registrarse con marca de tiempo, responsable y motivo. Esto no es solo para el cumplimiento: es lo que hace que la gestión adaptativa de casos sea trazable en lugar de caótica. El estándar CMMN (Case Management Model and Notation) proporciona un marco formal para ello. Un sistema basado en casos sin registro de auditoría es trabajo ad hoc con pasos adicionales.
Visibilidad de estado en tiempo real. Las partes interesadas necesitan ver el estado del caso, la cuenta atrás del SLA, el responsable actual y la siguiente acción pendiente sin solicitar una actualización de estado. Un sistema de gestión que exige que una persona elabore un informe de estado no proporciona la visibilidad que requiere la DCM.
Profundidad de integración. La DCM implica datos de múltiples sistemas: CRM, gestión documental, gestión de contenido, repositorios de gestión del conocimiento, herramientas de comunicación y bases de datos externas. La solución debe integrarse con la pila tecnológica existente, no reemplazarla. Aquí es donde evaluar plataformas avanzadas de gestión de casos se vuelve caro rápidamente: si el sistema solo puede gestionar los datos que posee, su valor en un entorno multisistema es limitado.
Una comprobación práctica antes de comprometerse con cualquier plataforma: pregunte al proveedor cómo añadiría un gestor de casos una tarea ad hoc a un caso abierto que no estaba en el flujo original. Repase los pasos exactos. Si la respuesta requiere un administrador del sistema, un desarrollador o crear un nuevo flujo, ese sistema es BPM con una pegatina de DCM.
