OCEL 2.0 explicado para gente de procesos, sin una línea de código
OCEL 2.0 SUENA A ESPECIFICACIÓN TÉCNICA. ES, EN EL FONDO, UN ACUERDO SOBRE CÓMO SE ESCRIBE LO QUE PASÓ.
Y si trabajas en procesos, entenderlo te sirve aunque nunca vayas a escribir una línea de código. Porque define qué información tienes que exigirle a un sistema para que el proceso sea analizable.
La pregunta que se hace es qué herramienta compramos.
La correcta es qué tiene que registrar el sistema para que cualquier herramienta sirva.
El formato, sin jerga:
Un evento es algo que pasó, con su momento.
Se aprobó la orden, a tal hora. Nada más. Si no tiene marca de tiempo, no es un evento: es un estado.
Cada evento se relaciona con uno o varios objetos.
Aquí está la diferencia con el formato anterior. Un evento puede tocar la orden y el envío a la vez, sin que haya que elegir uno.
Los objetos tienen tipo y atributos propios.
La orden tiene monto y cliente; el envío tiene transportista y destino. Cada uno con su ficha.
Los atributos cambian en el tiempo, y eso se registra.
Si el monto de la orden se modificó, queda cuándo. Es lo que permite reconstruir por qué una decisión se tomó con la información de ese momento.
Y hay relaciones entre objetos.
Esta factura corresponde a estas dos órdenes. Ese vínculo es un dato, no una inferencia.
Con esas cinco cosas escritas, cualquier herramienta de análisis puede leer tu proceso sin desarrollo a medida. Sin ellas, cada proyecto empieza reconstruyendo el mismo rompecabezas.
Lo interesante para alguien de procesos es que esta lista es una especificación de requisitos. Sirve para pedírsela al área de sistemas antes de que exista el proyecto.
¿Tu sistema registra cuándo cambió cada atributo, o solo el valor actual?
- OCEL
- ProcessMining
- GestiónDeProcesos
- Datos
- BPM
El carrusel completo
7 láminas. Toca cualquiera para verla en grande.
