Los procesos de negocios formalmente definidos, estructurados y predecibles son hermosos. Pero la realidad es más compleja, desestructurada e imprevisible en muchos casos. Es así que surjen los procesos ad-hoc, como una subcategoría más flexible, desestructurada y orientada a la colaboración entre personas. Y más adelante, surje el concepto de caso, y la gestión de casos asociada, para contemplar y automatizar procesos cuyo flujo de ejecución no se puede prever en tiempo de diseño. En este artículo cubriremos los elementos más importante de la gestión de casos y como realizarla con Flokzu.
Procesos ad-hoc.
Los procesos ad-hoc son aquellos en que la ruta se define en tiempo de ejecución y no en tiempo de diseño. Es decir, cada persona que recibe la instancia de proceso, la estudia, y decide cuál es el siguiente paso, o la siguiente persona que debe trabajar sobre esa instancia de proceso. No está predefinido (en tiempo de diseño) quien será la siguiente persona.
Veamos un ejemplo concreto. Imaginemos un proceso de un Ministerio de Salud, en el que se revisan y autorizan modificaciones a las Farmacias habilitadas. Una modificación puede ir desde aspectos legales (estatutos, responsables, propietarios), edilicios (ampliaciones, cambios en la distribución y circulación), médicos (medicamentos que maneja, responsable técnico), etc. Entonces, dado una nueva solicitud de cambio, requerirá ser revisada por diferentes áreas, y probablemente más de una, intercambiar información, “ir y volver” varias veces, hasta que se toma una resolución definitiva. Una posible forma de modelarlo en un proceso que contemple toda la casuística en tiempo de diseño sería:
La complejidad del modelo radica en que desde cada tarea de “Revisión”, se puede enviar la instancia de proceso a cualquier otra tarea de “Revisión”, o a la aprobación final. El atento lector notará que agregar una nueva tarea de “Revisión”, agrega una complejidad exponencial al modelo. Detectar errores o hacer cambios en un modelo de esta complejidad, es muy, pero muy difícil.
Es un error modelar un proceso ad-hoc intentando cubrir toda la casuística posible. La complejidad del modelo generado lo hará impráctico e inmantenible en el futuro.
Modelado de procesos ad-hoc
En los proceso ad-hoc, y en la gestión de casos en general, lo ideal es no modelar la casuística completa (como en el ejemplo anterior), sino modelar el comportamiento desde el punto de vista del caso.
Continuando con el ejemplo anterior, una forma más adecuada de modelar el proceso sería incluir en el formulario las opciones de Revisión. Por ejemplo, se podría tener un campo de tipo Combo que permita al usuario elegir el siguiente revisor:
Con este cambio, podríamos modelar un proceso más genérico, indicando sólamente que hay una tarea de “Revisión de área” específica. ¿Qué área será la que revise? La que el usuario haya elegido en la tarea anterior en el combo de “Siguiente Revisión”. El proceso en notación BPMN se vería así:
El único punto que restaría definir es cómo asignar los usuarios responsables de la tarea “Revisión de área”. Eso se realiza con la asignación dinámica de tareas a usuarios. Es decir, la asignación será realizada en tiempo de ejecución, dependiendo del valor del campo “Siguiente Revisión”. Dependiendo del valor de ese campo, por ejemplo se podría traer desde una base de datos de Flokzu, la lista de usuarios de cada área. O también se podría asignar la tarea mediante un WebService, que reciba como parámetro el valor del campo “Siguiente Revisión” y devuelva la lista de usuarios asignados.
Esta solución es mucho más práctica. El modelo es mucho más claro de entender, mantener y sobre todo evolucionar en el futuro. Por ejemplo, es mucho más fácil agregar un área de revisión más.
Gestión de casos y CMMN
Todo lo explicado anteriormente para los procesos ad-hoc, es la base de la gestión de casos (conocido como Case Management en inglés). La disciplina de Gestión de Casos surge como respuesta formal para el manejo de procesos ad-hoc como los anteriores. De hecho, la OMG desarrolló un estándar de notación para los procesos de negocios basados en casos. Se llama CMMN – Case Managemente Modeling Notation.
CMMN ha sido un buen agregado a la notación BPMN para este tipo de procesos que requieren un alto grado de flexibilidad. Una característica importante de CMMN es que se puede serializar en un archivo XML y ser ejecutada por un motor de procesos de negocios compatible con la notación. En este sentido, se comporta de forma idéntica a BPMN, permitiendo no sólo la representación gráfica del proceso, sino también su ejecución en una Suite BPM.
Siguiendo con el ejemplo de la modificación de farmacia, la representación de la actividad clave de Revisión de cada área se podría modelar así:
Conocimiento asociado a los casos.
En la mayoría de las situaciones, la gestión de casos se relaciona íntimamente con la gestión del conocimiento organizacional. En los casos trabajan personas, que colaboran con otras, compartiendo conocimiento, trabajando sobre archivos adjuntos, realizando comentarios, estudiando la historia de cada caso, comparándolo con otros similares, etc.
En este sentido, es muy relevante que la suite BPM utilizada para automatizar el proceso, tenga un adecuado soporte a los activos de conocimiento de la organización. En el caso de Flokzu, para cada caso (instancia de proceso), además de los datos relevantes del formulario, se permiten adjuntar archivos de cualquier tipo y realizar comentarios arrobando a otras personas para potenciar la colaboración. Además, cuenta con un potente motor de búsquedas para encontrar rápidamente casos similares que faciliten aprovechar el conocimiento embebido en la resolución de los mismos.
Conclusiones
Un caso es un conjunto de elementos (información, archivos adjuntos, actividades), que debe ser analizado por seres humanos, y cuya lógica para completarlo no está predefinida. Esto implica que el flujo que tendrá el caso entre las personas, no se puede conocer en tiempo de diseño. Dependerá de cada caso y de las decisiones de las personas que trabajen sobre él.
Es posible modelar procesos basados en casos utilizando BPMN, pero se recomienda no hacerlo taxativamente, sino utilizar rutas ad-hoc. En este artículo se presentó un artículo y ejemplo concreto para hacer de forma correcta y que sea mantenible en el tiempo.
También es posible modelar procesos basados en casos utilizando la notación específica CMMN, estándar de la OMG para la gestión de casos.
Si en tu organización crees que estas tecnologías podrían ayudarte, contáctanos inmediatamente.
Agenda aquí y te ayudaremos a instrumentar los procesos reales de tu organización.
Pero espera! Quieres leer más articulos relacionados? Esto es lo que podemos ofrecerte:
– Low-Code vs. No-Code – La guía definitiva
– Capacidad del control de procesos para ahorrar costos y eliminar errores
– Estándar CMMN y la gestión de casos: ascenso y caída
– Ciudadanos desarrolladores y la digitalización de procesos sin programar
