Fundamentos para desarrollar Process Driven Application (PDA)

Imagine un sistema informático completo hecho a la medida, dónde tenga todo lo que necesita pantallas, base de datos, archivos, envío de correos, etc, todo lo que Ud. o su proceso necesite, Just in Time y Jidoka a la vez, eso es un PDA, y no es la definición "de vida" de Calderón de la Barca.

“Principios antes que métodos”, decía R.W.Emerson

Antes de desarrollar un PDA considero importante tomar en cuenta estos principios:

“Hacer cosas correctas (generar valor) manualmente antes que hacer cosas erradas o triviales automáticamente”, parafraseando a B.Gates cuando habla aplicación de la tecnología.

“El ying yang de los procesos y personas”, en un primer momento el proceso “dirige” al hombre mediante actividades definidas con procedimientos de forma que ahorre tiempo y no cometa errores, luego el hombre “analiza” el proceso, revisa los datos obtenidos y “mejora” el proceso (hansei), en un ciclo interminable de mejora continua.

A medida que el proceso mejora y se automatiza se libera a la persona para que analice y mejore el proceso, se automatiza porque se respeta la capacidad del hombre en lograr mejoras que una máquina no puede hacer.

T. Ohno decía (Toyota Motor Corp., 2018) “Mokeru Industrial Engineering (MIE)”, en la traducción al español, Ingeniería Industrial para obtener ganancias, no se automatiza sólo para reducir costos, se automatiza principalmente para lograr más ingresos sostenibles en el tiempo, sólo tiene que mirar la línea de la producción para (Kimura, 2019) mejorar calidad, costo y entrega sin perder de vista el “camino correcto” osea bueno para el cliente, colaborador y sociedad.

Sugerencia 1, antes de desarrollar un  PDA, revisen este check list (jamás excluyente):

1. verificar que el proceso hace las cosas correctas.

2. buscar el “ying yang proceso persona”, unir lo que parece excluyente para crecer.

3. respetar a las personas para lograr Mokeru BPM (Gestión por Procesos para obtener ganancias) siguiendo el “camino correcto”.

 ¿Cómo hacer PDA? No descubramos la rueda, mejoremos la que existe

Antes una definición, Business Process Management System (BPMS) es un software que genera aplicaciones basada en modelos normalmente gráficos, se puede decir que es una evolución de los generadores de flujo de trabajo o workflows (WfMC) de los noventas.

En el artículo Scheid, K (2021) propone adicionar a los 3 artefactos genéricos (ver figura 1) de un PDA 1) los modelos de procesos interpretables por el motor de procesos en Business Process Model & Notation (BPMN) (OMG, 2013), Decision Model Notation (DMN) (OMG, 2024) incluiría Case Management Model & Notation (CMMN) también, 2) código fuente, cómo las integraciones con otro software usando tareas de servicios o la ejecución de script dentro del mismo BPMS, y 3) las vistas de formularios, compuestas por archivos en HTML.

Figura 1 Artefactos y Componentes de ejecución de PDA

En el mismo artículo se propone un análisis (ver figura 2) acerca del modelo de datos que complemente y ayude a prevenir anomalías en la ejecución de las aplicaciones.

 Figura 2 BPMN ejemplo Recepción Facturas y DFA

Los BPMS, toman los 3 artefactos como insumos, casi un código fuente y generan aplicaciones dónde se enlazan las actividades del modelo BPMN, con el modelo de datos a través de formularios y dónde el comportamiento es dirigido mediante las reglas de negocio definidas, por eso la importancia de separar reglas del modelo, que comentaremos en otro artículo.

En la línea de Shcheid, que menciona un 4to artefacto para controlar las anomalías que pueden aparecer en los PDA, presentamos una propuesta que usamos en las consultorías de automatización de procesos, un poco más simple que sirve como documento de requerimiento y checklist de verificación, que denominamos “Modelo de Datos”, donde mostramos una matriz modelo de datos versus actividades de usuario del modelo BPMN para determinar los criterios de visibilidad de los campos en cada actividad (Figura 3), pero adicionalmente sugerimos un 5to artefacto que consiste en la configuración de los permisos de ejecución de los procesos y de sus actividades por roles, aplicando este concepto luego podemos asociar roles con cargos funcionales y tendremos Manuales de Organizaciones y Procesos (MOP) similar a los Manuales de Organización y Funciones (MOF), con la gran diferencia que todas las actividades o funciones de un rol pertenecerán a un proceso, que de acuerdo a la arquitectura de procesos debe estar alineado a un mapa de procesos y este a su vez a la estrategia de la empresa, si lo que haces no es parte de un proceso de la organización, lo más probable es que lo que haces no genera valor, a pesar que te cueste mucho esfuerzo.

Figura 3 Ficha Modelo de Datos

Sugerencia 2, utilizar  5 criterios para el desarrollo de los PDA

1) modelos BPMN y reglas de negocio, 2) Código, actividad de servicio y script, 3) formularios HTML, 4) Modelo de Datos, con reglas de negocios con el comportamiento de los campos dependiendo de la actividad a la que está asociada y 5) Configuración de los permisos de ejecución del proceso y sus actividades.

Ventaja de los PDA sobre el desarrollo convencional, en el estudio de Jon Iden, (Iden, 2012) acerca del impacto de los Sistemas de Calidad en la gestión por procesos, en su cuarta conclusión comenta que muchos sistemas de información existentes no tiene una visión de procesos - porque no fueron pensados para eso, se quedaron con Taylor -, así de sencillo. Los entrevistados en el estudio mencionaron que tenían que recopilar información sobre procesos en forma manual, pero que a menudo se registran en bases de datos no integradas, lo que dificulta su gestión y combinación. Esto impide una adecuada gestión por procesos, porque no existe una gestión de procesos y aunque esta responsabilidad se le encarga a TI, debería ser encargada al área de procesos siempre y cuando sepan conozcan el concepto de PDA.

 Sugerencia 3, para implementar gestión por procesos en una organización en forma exitosa, necesitamos hacer gestión de procesos, los PDA aseguran la gestión de procesos con beneficios como generar datos útiles, asegurar el cumplimiento del proceso definido, etc., y un PDA bueno se basa en principios, ser correctos, mejorados constantemente con el ying yang, orientados a Mokeru (obtener ganancias) y seguir el "camino correcto".

 Figura 4 Camino más corto tomado por las hormigas

Consejo, cuando tengan dudas copien a la naturaleza, no pide derechos de autor y siempre está dispuesta a enseñar, cuando queremos aprender nos enseñan hasta las hormigas (Figura 4), a medida que un camino -el más corto- es utilizado ellas van dejando más rastros de feromonas que otras seguirán generando el comportamiento inteligente a partir de la autoorganización y la comunicación, si la naturaleza toma siempre el camino más corto (Martín, s.f.), entonces elaboremos procesos usando PDA dónde el “camino correcto” sea el más corto y muchas cosas cambiarán, hasta eso que llaman cultura, que a veces parece la definición "de vida" de Calderón de la Barca.

 Bibliografía

Iden, J. (2012). Investigating process management in firms with quality systems: a multi-case study. Business Process Management Journal.

Imai, M. (2014). Kaizen la clave de la ventaja competitiva japonesa. México: Grupo Editorial Patria, SA de CV.

Kimura, K. (2019). TPM Volume-9 Mantenimiento Preventivo Total.

Martín, S. C. (s.f.). LA SABIDURÍA DE LA NATURALEZA. Obtenido de Ciencia Cognitiva: https://www.cienciacognitiva.org/?p=45

OMG. (2013). Business Process Model and Notation (BPMN). Obtenido de http://www.omg.org/spec/BPMN

OMG. (18 de 01 de 2024). DECISION MODEL AND NOTATION™ (DMN™). Obtenido de https://www.omg.org/dmn/

Schneid, K., Di Bernardo, S., Kuchen, H., & Thöne, S. (2021). Data-Flow Analysis of BPMN-based Process-Driven Applications: Detecting anomalies across model and code.

Toyota Motor Corp. (OMCD - División de Consultoría de Gestión de Operaciones). (2018). Manual Toyota 1973.