¿Qué es el modelo de gestión de casos y la notación (CMMN)?

Las organizaciones siempre buscan mejoras en la forma en que trabajan para aumentar la eficiencia y reducir los errores. Esto requiere el análisis y la mejora continua de sus métodos de trabajo, que pueden incluir flujos de trabajo muy estructurados en  situaciones predecibles , así como protocolos para responder a  situaciones dinámicas  donde es  imposible prescribir un proceso fijo .

CMMN  es una notación gráfica utilizada para capturar métodos de trabajo que se basan en el manejo de casos que requieren diversas actividades que pueden realizarse en  un orden impredecible en respuesta a situaciones en evolución . Usando un enfoque centrado en eventos y el concepto de un archivo de caso, CMMN amplía los límites de lo que se puede modelar con  BPMN , incluidos los esfuerzos de trabajo menos estructurados y aquellos impulsados ​​por trabajadores del conocimiento. El uso de una combinación de BPMN y CMMN permite a los usuarios cubrir un espectro mucho más amplio de métodos de trabajo.

Aquí hay algunas razones por las que necesitamos CMMN además de BPMN:

  • Tradicionalmente, la investigación y la práctica de los sistemas de información empresarial se centran en procesos empresariales bien estructurados. Sin embargo, muchos procesos comerciales son difíciles de modelar.
  • Esto es especialmente cierto para las tareas que requieren muchos conocimientos, como la gestión de incidentes, la consultoría o las ventas. De hecho, muchas actividades se inician y llevan a cabo de manera ad hoc en lugar de planificarse con anticipación.
  • Este es especialmente el caso de las actividades intensivas en conocimientos o basadas en proyectos, que a menudo representan las competencias básicas de una organización.

Proceso ad-hoc

Los procesos ad-hoc son conjuntos de actividades comerciales y los artefactos correspondientes (p. ej., información, decisiones y productos) que solo se pueden estandarizar a un alto nivel de agregación. Los tipos reales de actividades y su orden son diferentes de un caso a otro.

Estas son las características del Proceso Ad-hoc:

  • Si bien se pueden predecir ciertas actividades, gran parte del proceso no se puede especificar completamente al principio, ya que requiere información que solo está disponible de alguna manera en el proyecto.
  • Si asumimos que en el contexto de los procesos ad-hoc nunca se determina el siguiente paso, su ejecución no puede ser controlada por los sistemas de información clásicos basados ​​en procesos, en la mayoría de los casos, los trabajadores del conocimiento tienen el control del proceso.
  • Parece imposible pensar en todas las posibilidades para un proceso ad-hoc en el momento del diseño, tal modelo de proceso se volvería complejo y difícil de administrar.

BPMN frente a CMMN

En las últimas décadas, ha habido un enfoque en el modelado y la automatización de procesos rutinarios y bien estructurados. BPMN se utiliza mejor para trabajos bien estructurados y altamente predecibles donde los trabajadores del conocimiento ejecutan principalmente tareas, mientras que CMMN cubre la sección de procesos menos predecibles con la participación activa de trabajadores del conocimiento que toman decisiones y planifican durante el tiempo de ejecución.

La gestión de casos (CM) fue presentada como una herramienta para los trabajadores del conocimiento por van der Aalst en 2005. En mayo de 2014, OMG publicó un  estándar para la gestión de casos denominado Modelo y notación de gestión de casos (CMMN) . Su enfoque es apoyar procesos impredecibles, intensivos en conocimiento y débilmente estructurados. La gestión de casos es un tipo de tecnología de procesos empresariales que no utiliza el flujo de control para describir el proceso.

La gestión de casos se trata de empoderar a los trabajadores del conocimiento brindándoles acceso a toda la información relacionada con el caso y dándoles discreción y control sobre cómo evoluciona un caso. La gestión de casos no se trata del proceso, se trata de los trabajadores. A diferencia de los procesos clásicos, un objetivo determinado y la provisión de posibilidades para elegir es más importante que la forma de lograr el objetivo en sí.

Aquí se enumeran las diferencias entre BPMN y CMMN:

La notación declarativa  no intenta modelar el flujo de un problema; establecen los resultados deseados, es decir, especifican lo que quieren que suceda pero no cómo debe suceder. SQL es un ejemplo de programación declarativa porque no intenta controlar el flujo de un programa; simplemente indica lo que le gustaría que apareciera, pero no cómo se hace.

La notación imperativa , por otro lado, intenta modelar el flujo de un problema; por ejemplo, lenguajes de programación imperativos como Java o C++, establecen comandos que le dirán al compilador cómo desea que se ejecute el código pero no explícitamente qué quiere que suceda.


Proceso Estructurado vs Caso vs Proceso Ad-Hoc

Tiempo de diseño frente a tiempo de ejecución

No existe un modelo de flujo de secuencia en CMMN. La ejecución de una tarea depende de eventos y condiciones llamados centinelas. Un centinela captura la ocurrencia de un determinado evento o el cumplimiento de una condición dentro de un caso. Los centinelas se utilizan como criterio de entrada y salida. Tenga en cuenta que los rombos blancos y negros representan los criterios.

Un caso tiene dos fases distintas que son el tiempo de diseño y el tiempo de ejecución, como se describe a continuación:

Tiempo de diseño

Durante la fase de tiempo de diseño, los analistas comerciales participan en el modelado, que incluye la definición de tareas (elementos del plan) que siempre forman parte de segmentos predefinidos en el modelo de caso y las tareas «discrecionales» que están disponibles para el asistente social que para ser aplicado opcionalmente en base a su discreción.

Tiempo de ejecución

En la fase de tiempo de ejecución, los asistentes sociales ejecutan el plan realizando tareas según lo planificado y, opcionalmente, agregando tareas discrecionales a la instancia del plan de caso en tiempo de ejecución.

Diagrama CMMN de un vistazo

Este ejemplo ilustra el proceso de escritura en papel modelado con CMMN. Supongamos que la escritura en papel es un trabajo de conocimiento intensivo y se puede manejar de diferentes maneras. Investiguemos este ejemplo un poco más de la siguiente manera:

  1. El proceso tiene dos hitos que deben alcanzarse:
  • Borrador completado
  • Documento completado
  1. Varias tareas (por ejemplo,  Crear TOC ) se dejan a discreción del autor.
  2. Las tareas Preparar borrador  con  Escribir texto  e  Integrar gráficos  son obligatorias.
  3. Esta etapa ha definido la regla de repetición que está simbolizada por el decorador de repetición (es decir,  hash ).
  4. Si bien  el tema de investigación  es una tarea obligatoria, la tarea de  organizar las referencias  debe decidirse en tiempo de ejecución. Es similar a  crear gráficos  y  generar una lista de figuras .
  5. El proceso finalizará cuando  se cree el documento  o  se alcance la fecha límite .

* Extraído de la especificación de notación y modelo de gestión de casos de OMG

Nota

  • Un modelo de plan de caso se representa utilizando una forma de «carpeta»
  • El nombre del caso se puede encerrar en el rectángulo superior izquierdo.
  • Los diversos elementos de un modelo de plan de caso se representan dentro de los límites de la forma del modelo de plan de caso.
  • El diagrama muestra un ejemplo de un modelo de plan de casos.

Conceptos básicos de CMMN

El modelo de comportamiento completo de un Caso se captura en un  Modelo de Plan de caso . Para un modelo de caso particular, un modelo de plan de caso se compone de todos los elementos que representan el plan inicial del caso y todos los elementos que respaldan la evolución posterior del plan a través de la planificación en tiempo de ejecución por parte de los asistentes sociales. Hay cuatro tipos de elementos del plan:

Tareas

Una tarea es una unidad de trabajo. Hay tres tipos de tareas:

Tareas (tarea discrecional)

Las tareas siempre forman parte de segmentos predefinidos en el modelo de caso. Además de las tareas, hay Tareas discrecionales que están disponibles para el asistente social, para que se apliquen opcionalmente según su criterio. Una tarea discrecional se representa mediante una forma de rectángulo con líneas discontinuas y esquinas redondeadas. Tenga en cuenta que cualquier tipo de tarea puede ser discrecional:

Oyentes de eventos

Un evento es algo que sucede durante el transcurso de un Caso. Por ejemplo, la habilitación, activación y terminación de Etapas y Tareas, o la consecución de Hitos.

Hito

Un hito representa un objetivo alcanzable, definido para permitir la evaluación del progreso del caso. Ningún trabajo está directamente asociado con un Hito, pero la finalización de un conjunto de Tareas o la disponibilidad de entregables clave (información en el Expediente del caso) generalmente conducen al logro de un Hito. Un hito puede tener cero o más criterios de entrada, que definen la condición cuando se alcanza un hito.

Por ejemplo, tenemos un acuerdo de nivel de servicio (SLA) en el proceso de cumplimiento que se puede modelar utilizando un detector de eventos de temporizador y un hito, de la siguiente manera.

Etapa y Etapa Discrecional

  • La etapa se puede considerar como una «fase» en un caso y, por lo general, agrupa varias tareas.
  • Es un contenedor de elementos a partir de los cuales se construye el plan de la caja y puede evolucionar más.
  • Las etapas pueden considerarse «episodios» de un caso. Se pueden considerar como subcasos (similares a los subprocesos en BPMN) y también se ejecutan en paralelo.
  • El escenario está representado por una forma de rectángulo con esquinas en ángulo y un marcador en forma de un signo «-» en un pequeño cuadro en su centro inferior («-» designa etapas expandidas).
  • La etapa discrecional se puede agregar ‘opcionalmente’, ‘ad-hoc’, al plan a discreción del usuario.

La siguiente figura muestra una etapa ampliada con una subetapa y tres tareas.

Criterios

Los criterios nos permiten describir cuándo una tarea, etapa o hito debe estar disponible para su ejecución (criterios de entrada), o cuándo un caso (plan de caso), etapa o tarea debe terminar de manera anormal (criterios de salida). Los criterios tienen las siguientes dos partes opcionales:

  • Uno o más eventos desencadenantes (llamados onParts). Estos son eventos que satisfarán la evaluación de los criterios de entrada o criterios de salida.

Podemos pensar en los criterios que forman una oración de la siguiente manera,

([ on < Event 1 >[, on < Event 2 >[, . . .]] ]) AND ([ if < Boolean condition > ])

Tenga en cuenta que:

  • Donde los corchetes ([ ]) indican partes opcionales de la oración, y los corchetes angulares (< >) son marcadores de posición que deben reemplazarse.
  • tanto onPart como ifPart son opcionales  en la oración, pero para que tenga sentido al menos uno de ellos debe estar presente.

Criterio para entrar

Un criterio de entrada describe la condición que debe cumplirse para que la etapa, la tarea o el hito estén disponibles para su ejecución. La etapa, la tarea o los hitos sin criterios de entrada estarán disponibles para su ejecución tan pronto como se creen. Los criterios de entrada se pueden colocar en cualquier lugar del borde de la etapa, tarea o hito.

Ejemplo

En el ejemplo a continuación, ambas etapas, quejas de productos y quejas de servicios, necesitan un criterio de entrada, porque solo se pueden ejecutar si la queja es de su tipo. En la mayoría de los casos, solo se ejecutará una de las dos etapas, aunque en algunas situaciones las quejas pueden involucrar ambas etapas.

criterio de salida

Un criterio de salida es similar a un criterio de entrada, pero se utiliza para dejar de trabajar en la etapa, tarea o caso (plan de caso) cuando se cumple. En el proceso de denuncias agregaremos un criterio de salida del caso. En la situación, el cliente llama y cancela la queja, por lo que debemos dejar de trabajar en el caso. Modelamos este escenario al tener un elemento de archivo de caso de cancelación, que podría ser una grabación de voz de una llamada de un cliente o una carta del cliente.

Expediente

En CMMN, cada instancia de caso contiene un solo  archivo de caso  (también llamado  carpeta de caso , o simplemente el  caso ), y los asistentes sociales tienen acceso a todos los datos en ese archivo de caso. Los asistentes sociales pueden agregar, eliminar y modificar datos en el archivo del caso incluso si no están ejecutando ninguna tarea en el caso, siempre que tengan suficientes privilegios. Los datos en el expediente del caso se denominan elementos del expediente del caso.

Todos los datos y estructuras de datos se denominan  elementos de archivo de caso . Todos los elementos del expediente del caso se almacenan en el expediente del caso. Los elementos del archivo de casos se utilizan para representar todo tipo de datos, incluido un valor de datos en una base de datos, una fila en una base de datos, un documento, una hoja de cálculo, una imagen, un video, una grabación de voz, etc. Además de los datos básicos, Los elementos del expediente del caso también pueden representar contenedores, incluidos un directorio, una carpeta, un conjunto, una pila, una lista, etc.

Ejemplo

Mesa de planificación

Una Etapa o una Tarea Humana puede tener una Tabla de Planificación que indique si los elementos discrecionales se visualizan (-) o no (+). Cuando un usuario ‘expande’ una tabla de planificación, los elementos discrecionales que contiene se vuelven visibles dentro del escenario o fuera de la tarea humana. Para elementos discrecionales asociados con una tarea humana, la planificación solo está disponible en el estado activo de la tarea.


Dejar una contestacion

Tu dirección de correo electrónico no será publicada.