¿Cuáles son las limitaciones de la minería de procesos tradicional?
Aunque son extremadamente potentes, según el profesor van der Aalst, las técnicas tradicionales de minería de procesos tienen las siguientes limitaciones:
- La extracción y transformación de datos es tediosa y debe repetirse.
- Las interacciones entre objetos no se capturan.
- La realidad 3D se comprime en registros de eventos y modelos 2D.
Para comprender cada una de estas limitaciones, primero tienes que entender cómo funcionan los procesos modernos y cómo se almacenan los datos asociados a ellos.
Un modelo de proceso clásico asume una noción de caso único, la asunción de que un caso único (o instancia de proceso) ocurre de forma aislada. En los registros de eventos, como el anterior, esta noción de caso único se ilustra por el hecho de que existe un identificador de caso (ID de caso) por evento.
No es así como suceden los acontecimientos en el mundo real ni como suelen almacenarse los datos en los sistemas de información de los que se extraen los datos de registro de eventos. Por ejemplo, el departamento de ventas puede realizar un seguimiento de sus procesos a través de documentos digitales como las órdenes de venta. Cuando se aplican las herramientas tradicionales de minería de procesos al proceso de negocio de los pedidos de venta, se observaría un único objeto, el pedido de venta, y se examinaría cómo circula a través del departamento de ventas. Con esta información, podrías identificar áreas para continuar mejorando los procesos y aplicar cambios en los procesos para cerrar esas brechas de ejecución.
Sin embargo, el departamento de ventas no opera en el vacío. Los eventos que ocurren durante el proceso de ventas afectan a otros departamentos, como compras, producción, almacén, distribución, finanzas, etc. Además, los distintos departamentos emplean diversos objetos en sus procesos. Producción podría usar órdenes de producción, el departamento financiero podría usar facturas, el departamento de compras podría usar órdenes de compra, etc. Todos estos objetos están conectados porque los procesos están interconectados.
Pensemos en un cliente que hace un pedido de cuatro artículos al mismo tiempo. Un artículo está en stock y los otros tres deben fabricarse. Para los artículos que hay que fabricar, se crean tres órdenes de producción. El artículo en stock se embala y se envía solo, mientras que los demás artículos se embalan juntos y se envían más tarde, una vez fabricados. A continuación, se envía al cliente una única factura.
Los procesos suelen incluir varios objetos (por ejemplo, pedidos de cliente, artículos de pedidos de cliente, pedidos de producción, envíos y facturas) que están relacionados entre sí.
Este ejemplo ilustra cómo un solo evento, la creación de un pedido de ventas, puede implicar varios objetos (clientes, pedidos de ventas, posiciones de pedido de ventas, pedidos de producción, envíos y facturas) que están todos relacionados entre sí. Por ejemplo, un cliente puede tener varios pedidos de ventas (relación de uno a varios). Del mismo modo, un pedido de ventas puede contener varios artículos de pedido de ventas y un artículo de pedido de ventas se puede incluir en varios pedidos de ventas (relación de varios a varios). Para gestionar estas relaciones, los sistemas ERP, CRM, SCM y otros sistemas empresariales a menudo almacenan información en lo que se conoce como una base de datos relacional.
En un modelo relacional, los datos se organizan en tablas de filas y columnas. Las filas se denominan registros, las columnas se denominan atributos y las tablas son relaciones. Por ejemplo, en una tabla de clientes, cada fila podría corresponder al registro de un cliente y cada columna sería un atributo como el nombre, la dirección, el número de teléfono y similares. Volviendo a nuestro ejemplo de pedido de ventas anterior, una tabla de pedidos de ventas podría tener una fila/registro para cada pedido y columnas/atributos para información como el número de pedido, la fecha y la hora, el cliente, los artículos pedidos, el precio de cada artículo, la dirección de facturación, la dirección de envío, el método de envío, etc.
Cada fila dentro de una tabla de una base de datos relacional tiene un identificador único llamado clave. Por ejemplo, en una tabla de clientes, a cada uno se le asignaría un ID de cliente único que se usaría como clave primaria (PK) de la tabla. En la tabla de pedidos de venta, la clave primaria podría ser un ID de pedido de venta. Cada vez que se escribe un nuevo registro en una tabla, se genera un nuevo valor de clave primaria para ese registro.
Las claves primarias son la forma en que el sistema accede a la información de una tabla en particular y también se emplean para mostrar las relaciones entre tablas. Por ejemplo, las filas de la tabla de clientes pueden vincularse a filas de la tabla de pedidos de venta añadiendo una columna de ID de cliente a la tabla de pedidos de venta. Cada vez que un cliente hace una nueva compra, se añade un registro a la tabla de pedidos de venta y se añade el ID de cliente único del cliente como un atributo denominado clave externa (una clave única de una fila vinculada en otra tabla). Este modelo funciona bien para relaciones de uno a varios, donde muchas filas de una tabla tienen un valor de columna igual a la clave primaria o principal de otra tabla.
Para tener en cuenta las relaciones de varios a varios, las claves primarias o principales de las tablas relacionadas se suelen copiar en otra tabla para resolver la relación entre las dos tablas de entidades. Consideremos, por ejemplo, la relación de varios a varios entre los pedidos de venta y los artículos de pedidos de venta descrita anteriormente. Aquí podríamos tener una tabla de pedidos de venta, una tabla de artículos de pedidos de venta y una tercera tabla de resolución. La tabla de resolución contendría al menos una columna para cada una de las claves externas de las tablas de pedidos de venta y de artículos de pedidos de venta (claves principales en esas tablas), así como una nueva clave principal creada a partir de las dos claves externas.
En nuestro sencillo ejemplo de pedidos de ventas y artículos de pedidos de ventas, se necesitan al menos tres tablas para definir la relación. En el mundo real, se necesitan muchas más. Recordemos el proceso de pedidos de venta descrito anteriormente. Un único pedido de cliente está relacionado con cuatro artículos de pedido de cliente, tres órdenes de producción, dos envíos y una factura. Cada uno de estos objetos está relacionado con otros objetos, como clientes, proveedores, transportistas, etcétera. Por lo tanto, no es difícil comprender por qué los sistemas modernos de información empresarial, como un sistema ERP, utilizan bases de datos con cientos, miles e incluso cientos de miles de tablas.
Ahora podemos considerar las tres limitaciones de la minería de procesos tradicional mencionadas anteriormente:
- La extracción y transformación de datos es tediosa y debe repetirse. La minería de procesos clásica requiere extraer datos de las bases de datos relacionales de diversas tablas de los sistemas de información de origen en un registro de eventos plano (es decir, una tabla) en el que cada evento (es decir, una fila) se refiere a un caso, una actividad y una marca de tiempo. En nuestro ejemplo del pedido de venta, cada caso sería un pedido de venta concreto y podríamos hacer una pregunta del tipo «¿cuál es el motivo más habitual del bloqueo de un pedido ?». Sin embargo, si quisiéramos hacer una pregunta como «¿qué clientes pagan sus facturas a tiempo?», necesitaríamos un registro de eventos diferente con facturas, no pedidos de venta, como noción de caso. Así, tendríamos que volver a los datos y hacer una nueva extracción, una tarea laboriosa y compleja.
- Las interacciones entre los objetos no se capturan. Cuando se extraen datos de una base de datos relacional y se aplanan en un registro de eventos de minería de procesos en el que cada evento es un único caso, se pierden las interacciones entre los objetos definidos en los datos de origen. Del mismo modo, cualquier modelo de proceso que se genere a partir de los datos aplanados solo describe el ciclo de vida de un caso de forma aislada. Para que el proceso sea completamente transparente, es necesario comprender la relación entre todos los objetos y tipos de objetos que intervienen en el proceso.
- La realidad tridimensional se comprime en registros de eventos y modelos bidimensionales. En la minería de procesos tradicional, se crea un registro de eventos para cada tipo de objeto y se analiza por separado. Por ejemplo, creamos un registro de eventos para pedidos de ventas para examinar el proceso de pedidos de ventas, un registro de eventos para facturas de clientes para analizar el proceso de cuentas por cobrar, un registro para facturas de proveedores para analizar cuentas por pagar y un registro de eventos para pedidos de compra para el proceso de compras. Aunque estos registros de eventos planos estén vinculados mediante un modelo de datos de casos relacionados, seguimos comprimiendo datos y modelos tridimensionales centrados en objetos en registros de eventos y modelos de procesos bidimensionales y centrados en casos.
Este aplanamiento de datos conduce a problemas de convergencia y divergencia.
La convergencia se produce cuando un evento se replica en diferentes casos, lo que puede provocar una duplicación involuntaria. En el ejemplo del proceso de pedido de ventas descrito anteriormente, si seleccionamos un artículo de pedido de ventas como noción de caso, los eventos a nivel de pedido de ventas (por ejemplo, realizar pedido) se duplicarían para cada artículo de pedido de ventas relacionado con un pedido de ventas específico. Esta replicación de eventos puede causar diagnósticos engañosos.
La divergencia ocurre cuando puede haber varias instancias de la misma actividad en un mismo caso. Utilizando nuestro ejemplo anterior de proceso de pedido de ventas, si seleccionamos pedido de ventas como noción de caso, los eventos a nivel de artículo de pedido de ventas (por ejemplo, recoger artículo) pueden llegar a ser indistinguibles y parecer que están relacionados. Por ejemplo, los eventos recoger artículo y empaquetar artículo ocurren una sola vez por artículo y en una secuencia fija (por ejemplo, recoges el artículo y luego lo empaquetas), dentro de un registro de eventos de pedido de ventas plano, puede parecer que estos eventos ocurren muchas veces y en un orden aparentemente aleatorio para un caso en particular.
