El estándar CMMN y la gestión de casos (Case Management Model and Notation), surgieron como una representación gráfica para procesos basados en «casos», desestructurados e imprevisibles en su ejecución. A pesar de una gran expectativa y revuelo por su aplicabilidad y posibilidades que ofrecían, no lograron tracción en el mercado. Básicamente, la comunidad internacional de gestión de procesos le dio la espalda. Actualmente vigente, el estándar agoniza. Veremos en este artículos las principales causas.
El ascenso del estándar CMMN y la gestión de casos
El estándar de modelado de procesos de negocios BPMN (¿Qué es BPMN?) tuvo gran éxito, siendo adoptado por buena parte de la comunidad de practicantes de gestión de procesos de negocios – BPM (¿Qué es BPM?). Pero BPMN es un estándar orientado a procesos estructurados, repetitivos y mayoritariamente predecibles en su ejecución.
Inspirados por ese éxito de BPMN, y la existencia de carencias para modelar procesos desestructurados, surge CMMN: Case Management Model and Notation. CMMN es una representación gráfica para expresar gráficamente un proceso asociado a un Caso.
«Un Caso es un procedimiento que involucra acciones tomadas con respecto a un sujeto en una situación particular para lograr un resultado deseado» y se deriva del concepto de gestión de Casos utilizado, por ejemplo, en el mundo legal y médico.
Wikipedia
Para bajar el concepto a tierra, veamos un ejemplo concreto. Pensemos en un proceso de atención a una demanda judicial. Cuando se recibe la demanda, primero se estudia, y luego, según sus características, se derivará a una u otra área dentro de la organización. Pero a priori no sabemos a cuál área se enviará, puede ser cualquiera. Esa área analiza el caso, y decide los siguientes pasos a seguir. Desde ignorarlo y archivarlo, hasta derivarlo al Directorio para que tome conocimiento, o cualquier otra alternativa en el medio. Y cuando llega a esa nueva etapa, se repite el análisis y decisión.
En cada etapa del caso se analiza y define cuál es la siguiente etapa. Y esto se decide en tiempo de ejecución, no de diseño del proceso.
Los proceso ad-hoc vistos como casos
En el mundo de los procesos, siempre existió el concepto de «ad-hoc»: aquellos procesos que no se pueden definir en tiempo de diseño, sino que cada ejecución puede ser diferente, sin seguir rutas o flujos predefinidos.
La gestión de casos, justamente, es una implementación de procesos ad-hoc, donde cada caso puede tener una resolución, tareas, y participantes diferentes.
CMMN estándar OMG
El punto clave para el ascenso del estándar CMMN y la gestión de casos fue cuando se convirtió en un estándar promulgado por la OMG. La versión 1.0 de CMMN se publicó en mayo de 2014 y fue modificada por la versión 1.1 en diciembre de 2016.
A partir de allí, una gran cantidad de practicantes de BPM comienzan a utilizarlo, como complemento a BPMN, para los procesos menos estructurados. De la misma forma, las Suite de BPM, comienzan a soportarlo también, incluso algunas de ellas, desarrollando motores de ejecución específicos para procesos modelados con el estándar CMMN.
La caída del estándar CMMN y la gestión de casos
En 2019, pasados tres años desde la publicación de la versión 1.1 del estándar CMMN, se percibía que no estaba generando la tracción esperada en el mercado. Si bien varias herramientas lo soportaban, en los congresos se hablaba de ellas, y la comunidad experta en procesos conocía bien CMMN, la adopción real del mercado era muy poca. De hecho, algunos jugadores importantes del ecosistema, anunciaban que no continuarían incorporando nuevas funcionalidades relacionadas con CMMN (ejemplo, Camunda en 2019).
Otro cadáver en el armario
El caso de CMMN no es nuevo en el mundo de los procesos. Como toda disciplina relativamente joven, que se está «descubriendo a sí misma», algunas iniciativas prosperan (como BPMN), mientras que otras no.
El mercado finalmente es quien decide, si las nuevas propuestas se adaptan a las necesidades y capacidades existentes, en cuyo son adoptadas, o no.
El caso de BPML – Business Process Modeling Language deprecado en 2008 es un ejemplo similar. Era una notación con gran potencial, pero que no fue adoptada por el mercado y finalmente terminó desapareciendo.
Otro caso similar es BPEL – Business Process Execution Language, que si bien no fue deprecado y aún es usado por algunas herramientas, su última versión fue publicada en 2007 por OASIS.
En Flokzu, detectamos tempranamente algunos de los principales problemas de CMMN, motivo por el cual nunca lo soportamos. Uno de los principales, fue su poca facilidad de uso. Siendo Flokzu una herramienta no-code, orientada completamente a usuarios de negocios, no tenía sentido obligarlos a aprender otra notación. Sobre todo, cuando la mayoría de los escenarios podían ser cubiertos directamente por BPMN, manteniendo una única notación para nuestros usuarios.
Principales debilidades de CMMN
Identificamos tres debilidades principales del estándar CMMN y la gestión de casos, que probablemente sean las causas principales para que el mercado no las adoptara:
- Complejidad. El estándar reviste complejidad para ser aprendido y utilizado correctamente. No es una notación demasiado intuitiva, ni derivada de los clásicos flujogramas que ya conocemos. Incluye elementos que requieren explicación y entrenamiento. Un usuario de negocios tendrá dificultades para aprender CMMN, sea para crear nuevos modelos o entender los existentes, lo que naturalmente dificulta la adopción. Claramente, esto no es compatible con el espíritu de Flokzu, de facilitar y dar autonomía para que usuarios de negocios creen y administren sus procesos con autonomía.
- Sobreposición. Si bien CMMN es específico para el modelado de procesos ad-hoc no estructurados, la realidad es que la mayoría de las situaciones de negocios también podrían ser modeladas con BPMN. Tal vez con un poco más de dificultad, es cierto, pero podría hacerse. Entonces, ¿por qué aprender CMMN para solo algunos casos, si puedo aprender BPMN y que me sirva para todos? Es una pregunta válida. En Flokzu hemos visto decenas de procesos ad-hoc, que fueron modelados con BPMN, utilizando tareas genéricas y asignación dinámica de participantes, una configuración perfectamente correcta.
- Incompletitud. Este tal vez sea el problema más grave. Descubrimos que la mayoría de los procesos tienen una parte formal, fija y preestablecida. Y luego, otra parte que puede ser ad-hoc, no estructurada. BPMN puede soportar ambas, pero CMMN no (solo puede soportar la parte ad-hoc, no estructurada). Entonces, ¿necesitaremos ambas notaciones para el mismo proceso? Naturalmente, se preferirá usar una sola notación, y dado que BPMN cubre la mayoría de la casuística, pierde sentido utilizar CMMN.
Conclusiones
El estándar CMMN y la gestión de casos recibieron mucho foco durante la segunda mitad de la década pasada. Sin embargo, el mercado no los adoptó como se pensaba. Lentamente fueron perdiendo tracción. Actualmente, el estándar está vigente y publicado, pero su adopción es cada vez menor.
Esta situación no es nueva en un área del conocimiento que está madurando y evolucionando. Y está muy bien que suceda, porque el mercado adopta aquellas notaciones y tecnologías que realmente le son útiles. En Flokzu siempre hemos priorizado a nuestros usuarios, la facilidad y agilidad de uso, por lo que entendemos que la complejidad de aprender CMMN y convivir con dos notaciones, no justifica los beneficios. Además, está el hecho muy relevante, de que prácticamente todos los procesos, aún sus partes ad-hoc poco estructuradas, pueden ser modelados y automatizados con el estándar mundialmente aceptado, BPMN.
En Flokzu, siempre estamos dispuestos a ayudar a modelar sus procesos. Agenda aquí una llamada con un experto, y juntos encontraremos la solución para tu caso desestructurado o proceso bien definido!
