1

Conferencia Internacional sobre Informacin, Procesos y Gestin del Conocimiento

Diagnosticos de Procesos:
un Metodo Basado en Process Mining
Melike Bozkaya, Joost Gabriels, Jan Martijn van der Werf
LaQuSo, Laboratory for Quality Software,
an activity of Technische Universiteit Eindhoven and Radboud Universiteit Nijmegen,
P.O. Box 513, 5600 MB Eindhoven, The Netherlands
Email: {m.bozkaya, j.gabriels, j.m.v.d.werf}@laquso.com
Resumen - Como las organizaciones cambian, los sistemas de
informacin pueden evolucionar de sistemas simples a sistemas
complejos, que son difciles de entender, y por lo tanto, difcil de
mantener o extender. Process Mining o la Minera de Procesos puede
ayudar a las organizaciones en tratar de entender los sistemas de
informacin mediante el anlisis de sistemas.
En este artculo se propone una metodologa para llevar a cabo el
diagnstico de procesos, basados en process minning. Dado un event
log (registro de eventos) de un sistema de informacin de una
organizacin, el diagnstico de procesos ofrece una visin general
de(los) proceso(s) de la organizacin en un corto perodo de tiempo.
En la metodologa de diagnstico de procesos, se destacan varias
perspectivas del proceso. El resultado incluye la perspectiva de flujo
de control, la perspectiva del rendimiento y la perspectiva de la
organizacin. Utilizamos la metodologa en un estudio de caso para
una organizacin gubernamental Holandesa.
Palabras claves - Gestin de procesos, anlisis de procesos, minera
de procesos o process mining, diseo de sistemas de informacin.

I. INTRODUCCIN

Hoy en da, los sistemas de informacin son indispensables
dentro de las organizaciones. A medida que las organizaciones
cambian, estos sistemas evolucionan de simples sistemas, que
fueron fciles de entender, a sistemas complejos que son difciles
de entender, y por lo tanto, difciles de mantener. Esto plantea la
pregunta de si el sistema est funcionando de la forma en que la
organizacin cree que funciona. Esta pregunta suele ocurrir cuando
el sistema de informacin tiene algunos defectos como problemas
de rendimiento. Ms importante an, para que las organizaciones
estn en control, deben asegurarse de que el sistema est
funcionando de acuerdo a sus especificaciones.
Los sistemas de informacin de apoyo a los procesos de
negocio suelen registrar todos los eventos en un registro. Tal
registro, denominado registro de eventos (event log) o seguimiento
de auditora (audit trail), contiene informacin sobre los eventos:
para qu actividad e instancia del proceso, conocido como caso, se
ejecuta, por quin y en qu momento. Una actividad puede tener
mltiples eventos. Todos los eventos para un caso forman una
secuencia, llamada rastro (trail) o ejecucin (run) de ese caso, y
muestra qu eventos ocurrieron, en qu orden y en qu momento.
Process mining permite analizar estos event logs. Process mining
mira dentro de los procesos para responder preguntas como:
Cmo es el proceso actual?, Los logs ejecutados se ajustan a
las especificaciones, es decir, todos los casos siguen el modelo de
proceso especificado?, Existe algn cuello de botella en el
proceso?, Quin ejecuta qu tareas?, Quines suelen trabajar
juntos?, etc. El campo del process mining cubre muchas reas,
tales como las caractersticas de rendimiento (por ejemplo, tiempos
de produccin) [1], descubrimiento de procesos (descubrimiento
del flujo de control) [2], [3], [4], conformidad de proceso
(cumplimiento de especificaciones del event log) [5], [6], y las
redes sociales (por ejemplo, cooperacin o subcontratacin)[7],
[8]. Responder estas preguntas puede servir como un identificador
para las organizaciones para responder dos de las principales
preguntas: Estamos en control?, y La informacin del sistema
realmente refleja la situacin del proceso de negocio?.
Unas de las herramientas de apoyo de process mining es el
ProM [9]. Est basado en complementos (plugins) para apoyar
nuevas reas y tcnicas. En la ltima dcada, el process mining
evolucion desde el descubrimiento del flujo de control a un
amplio campo de investigacin para obtener todo tipo de
informacin de un registro (log), lo que resulta en ms de 250
complementos diferentes dentro de ProM. Esto muestra que
existen muchas tcnicas diferentes para aplicar process mining.
Puesto que hay muchas, no est claro ya cuando usar cada
complemento. A pesar de que muchos casos de estudio se han
llevado a cabo (vase [10], [11]), el principal problema con estos
estudios de caso es que todos fueron hechos caso por caso desde la
perspectiva y conocimiento del investigador que realiz el estudio
de caso. Hasta ahora, no existe una metodologa para abordar un
nuevo estudio de caso, es decir, es difcil hacer process mining un
servicio repetible.
En este artculo se propone una metodologa para hacer un
diagnstico de un proceso basado en process mining. La
metodologa es diseada para ofrecer en un corto periodo de
tiempo una amplia visin general de(los) proceso(s) dentro del
sistema de informacin. La clave en esta metodologa es la
ausencia de dominio y conocimiento especfico previo. La nica
informacin disponible es el event log. Esto tambin implica que
el diagnostico solo presenta hechos sobre los procesos. Depende de
la organizacin interpretar los resultados del diagnstico.
Ilustramos la metodologa con un estudio de caso realizado para
una organizacin gubernamental holandesa.
Este artculo est organizado de la siguiente manera: primero
se explica la metodologa en la Seccin II. En la Seccin III, se
presenta un estudio de caso en el cual se aplica la metodologa. Se
concluye este artculo en la Seccin IV.

II. METODO DEL DIAGNOSTICO DE PROCESO

Se presenta una metodologa para un rpido diagnstico de
procesos. La metodologa tiene como objetivo ofrecer una amplia
visin general del proceso en el sistema de informacin dentro de
un corto periodo de tiempo. Se compone de cinco fases: (1) log
preparation (preparacin del registro), en la que se extrae el event
log del sistema de informacin, (2) log inspection (inspeccin del
registro), para obtener un primer vistazo del proceso, (3) control
flow analysis (anlisis de flujo de control), (4) performance
analysis (anlisis de rendimiento) y (5) role analisys (anlisis de


2

rol), es decir, las personas y los recursos que ejecutan actividades
en el proceso. Finalmente, los resultados se informan al cliente. La
Figura 1 muestra la metodologa como un proceso. Las primeras
dos etapas son entradas para el anlisis de flujo de control y
anlisis de rol, el anlisis de rendimiento tambin necesita los
input del anlisis de flujo de control.

A. Preparacin del Log

En un event log, cada evento hace referencia a un caso y a una
actividad, y tiene una marca de tiempo que indica cuando ocurri.
Normalmente, el sistema de informacin en cuestin tiene un
formato de registro interno, que contiene toda la informacin, pero
que necesita ser extrada, o incluso transformada, con el fin de
poder ser utilizado para process mining. El formato interno de logs
del sistema de informacin puede ser cualquier cosa, desde simples
archivos de textos hasta bases de datos internas, como en un
sistema SAP. Por lo tanto, es necesario un procesamiento previo
del log. El preprocesamiento ya plantea muchas preguntas. El
primer paso es seleccionar la mejor idea de un caso, ya que a
menudo hay varios candidatos. El siguiente paso es la
identificacin de las actividades y sus eventos. Si el log tiene
mltiples marcas de tiempo, la semntica de las marcas de tiempo
necesitar ser claras, por ejemplo, una marca de tiempo del
comienzo del evento, o del caso. Estos tipos de problemas
necesitan abordarse para tener un event log apropiado para
proceder a la siguiente fase.

B. Inspeccin del Log

La siguiente fase consiste en familiarizarse con el event log, y
para tener un primer vistazo del proceso representado por el event
log. En esta fase, se recopilan estadsticas sobre el log. Estas
incluyen informacin sobre el nmero de casos y roles, el nmero
total de eventos, los diferentes eventos actuales, el nmero
mnimo, mximo y promedio de eventos por cada caso, los eventos
de inicio y finales y sus ocurrencias, etc. Estas estadsticas dan a
conocer el tamao del proceso y del event log y ayudan a afinar los
algoritmos de minera y a evaluar los resultados obtenidos en las
siguientes fases. En base a estas estadsticas, el event log es
filtrado para remover los casos incompletos, es decir, se eliminan
los casos que se iniciaron antes del inicio del event log, y casos
que an se estaban ejecutando al final del event log. Este event log
filtrado es el input para las siguientes fases.

C. Anlisis de Flujo de Control

En esta fase, se analizan los aspectos del flujo de control del
proceso. Da respuestas a la pregunta Cmo es el proceso
actual?. En primer lugar, si la organizacin tiene un modelo del
proceso, es ejecutado un chequeo de conformidad para comprobar
si el proceso mencionado cumple las especificaciones, es decir,
que cada caso en el event log se puede reproducir en el modelo del
proceso. Si este no es el caso, o un modelo del proceso no existe,
el flujo del control necesita ser descubierto. Hay muchos
algoritmos disponibles para descubrir procesos, vase [2], [12],
[13], [4]. Simplemente ejecutar diferentes algoritmos de
descubrimiento a menudo nos da algunos modelos de proceso,
pero por lo general, esto resulta en un modelo de procesos
enredado, ya que el comportamiento poco frecuente, como las
excepciones, tambin son tomados en cuenta. Los
comportamientos poco frecuentes significan que hay casos cuya
secuencia no ocurre muy a menudo. Por lo tanto, para descubrir un
modelo de proceso que describa la ejecucin de la fbrica, es
necesario descartar las secuencias infrecuentes en primer lugar, y
solo considerar secuencias con una alta frecuencia. Siguiendo el
principio de Pareto, el log necesita ser filtrado de tal manera que
cubra al menos el 80% del log, pero que solo contenga casos con
alta frecuencia de ocurrencia. Luego este event log se puede
utilizar para descubrir el flujo de control. Una buena verificacin
para el modelo del proceso es ejecutar un chequeo de conformidad
sobre l. Sobre este resultado, un comportamiento infrecuente se
puede notar.

D. Anlisis de Rendimiento

Despus de descubrir el flujo de control, estos modelos de
proceso se pueden utilizar para analizar el rendimiento del proceso.
Esta fase responde preguntas como Existe algn cuello de
botella en el proceso?. En primer lugar, un anlisis grfico de
puntos [14] se utiliza para comparar casos y sus tiempos de
ejecucin. El eje vertical de un grfico de puntos representa los
casos en el event log, el eje vertical representa el tiempo. Esto nos
da un conocimiento til sobre rendimiento del sistema.
A continuacin, mediante la reproduccin del log sobre el
modelo de proceso, los cuellos de botella y los tiempos de
ejecucin de actividades individuales y del proceso en s son
calculados [1]. A pesar que el modelo del proceso describe la
ejecucin de la fbrica, este anlisis no es suficiente. Por lo tanto,
despus de la reproduccin, las diferentes secuencias necesitan ser
inspeccionadas por separado, dando una valiosa informacin
acerca de los tiempos de ejecucin en casos con excepciones u
otros comportamientos poco frecuentes.

E. Anlisis de Rol

Si el event log es lo suficientemente rico, es decir, si contiene
informacin sobre quien ejecuta un evento, entonces los roles en el
proceso pueden ser analizados. Un rol es una persona u otro tipo
de recurso que est involucrado en el proceso, mediante la
ejecucin de actividades de ese proceso. Esta fase da respuestas a
preguntas como Quin ejecuta qu actividad? y Quines
estn trabajando juntos?. En primer lugar, se crea una matriz rol-
actividad. En esta matriz, las filas representas los roles, las
columnas representan cada evento del event log. Cada celda
contiene el nmero de veces que el rol ejecuta ese evento. A
continuacin, para cada rol se crea un perfil desde esta matriz. Si
los roles tienen perfiles similares, forman un grupo. De esta forma,
los roles en el event log se pueden dividir en grupos. Para la
organizacin, ahora es posible chequear estos grupos descubiertos
frente al modelo organizacional utilizado. Esto le da a la
organizacin informacin importante sobre la divisin del trabajo
dentro de los departamentos de la organizacin, si las personas de
diferentes departamentos ejecutan actividades similares, y como
est la comunicacin entre los diferentes departamentos [8].


3

A continuacin, los roles son analizados para descubrir
especialistas, es decir, los roles que solo ejecutan algunas
actividades pero con mucha frecuencia; y generalistas, es decir,
los roles que ejecutan muchas actividades diferentes en el proceso.
Una forma de descubrir estos tipos de roles es generar una
jerarqua de roles, una jerarqua basada en las distintas actividades
que los roles ejecutan. Una flecha dirigida entre dos roles indica
que el rol en la base de la flecha puede hacer al menos las
actividades del rol en la punta de la flecha.
En tercer lugar, se realiza un anlisis de la red social. Una red
social es un grfico que representa la relacin entre los roles,
basado en una caracterstica descubierta en el event log. Esta
caracterstica puede ser la transferencia de trabajo, es decir, un rol
pasa un simple caso a otro y este a otro; y la subcontratacin, es
decir, un rol pasa un solo caso a otro rol, y este rol devuelve el
trabajo de vuelta al primer rol despus de terminar su actividad.
Los indicadores importantes dentro del anlisis de redes sociales
son la centralidad de intermediacin, es decir, el nmero de roles
que un rol puede alcanzar solo por atravesar flechas dirigidas, el
grado de flechas entrantes y el grado de flechas salientes [7].

F. Transferencia de los Resultados

El objetivo de esta metodologa es obtener conocimientos en
los procesos de la organizacin y su apoyo mediante los sistemas
de informacin. Los resultados del diagnstico muestran todo el
comportamiento visto en el sistema. Este comportamiento a
menudo se desva del proceso previsto, debido a la conducta no
deseada, como secuencias o perfiles de usuario que no estn
permitidos, por ejemplo, la legislacin, pero tambin a causa de
atajos inteligentes tomados por los usuarios del sistema para hacer
su trabajo ms fcil. El ejecutor de los diagnsticos no es capaz de
hacer la distincin entre el comportamiento deseado y no deseados.
Por lo tanto, es importante discutir los resultados de los
diagnsticos con el cliente, de manera que el cliente entienda el
resultado y consiga un mejor entendimiento del sistema de
informacin. Con este conocimiento, y con el apoyo del ejecutor
del diagnstico, el cliente puede refactorizar su sistema de
informacin para que sea ms eficiente o para acelerarlo, por
ejemplo, decidir no permitir ciertas secuencias a perfiles de
usuario, o apoyar ciertos atajos tomados por sus usuarios.

III. ESTUDIO DE CASO

Para una organizacin gubernamental holandesa, se realiz un
estudio de caso para dar una visin general del proceso dentro de
su sistema de informacin, implementado en Oracle 9i. La
organizacin se encarga de un proceso de emitir un documento.
Mientras ms y ms personas y organizaciones necesiten este
documento, el proceso necesita ser altamente optimizado. Para ser
capaz de entregar conocimiento de cmo funciona actualmente el
sistema de informacin y dar recomendaciones para mejorar el
sistema para acelerar el proceso, se realiza el mtodo de
diagnstico de proceso para dar una visin general de su sistema.

A. Preparacin del Log

El log recibido fue un archivo de texto con registros que
contienen 23 campos. Cada registro contiene informacin sobre el
identificador del caso, la actividad realizada, el recurso de
ejecucin, llamado el originador, y varias marcas de tiempo
indicando la hora de inicio del caso, el momento en que ocurri el
evento y la marca de tiempo que indica el trmino previsto y real
del caso. Desafortunadamente, no fue posible encontrar una marca
de tiempo indicando el fin de una actividad, lo que significa que
solo se conoce cuando ocurre una actividad, pero no el tiempo que
se emplea en ella.

B. Inspeccin del Log

En nuestro caso de estudio, el event log consta de 60 diferentes
actividades y 83.611 casos con un total de 276.333 eventos. Haba
60 originadores involucrados en el proceso. En el log se encontr
alrededor de 25 eventos de inicio, de los cuales la actividad 1 y
495 son los eventos de inicio en el 90% de los casos. El log consta
de 30 finales de eventos, de los cuales la actividad 56 es en el 87%
de todos los casos, el evento final.
Para obtener un primer vistazo, el Fuzzy Miner [3], un plugin
en la herramienta ProM, se utiliza en el registro, con un comienzo
artificial y un final de evento aadido a cada caso. El Fuzzy Miner
agrupa las actividades coherentes con log significativos pero con
alta correlacin. La Figura 2 muestra el modelo del proceso
resultante.
El grosor de un arco indica la frecuencia. Por lo tanto, parece
que la secuencia 1 61 56 es una ruta frecuente. Este modelo
muestra que tanto la actividad 1 y 495 son los eventos de inicio
ms frecuentes, y que el proceso termina la mayora de las veces
con la actividad 56. Este resultado concuerda con las estadsticas
encontradas en la fase previa. Por lo tanto, es una buena idea filtrar
el log para obtener solo los casos que comienzan con la actividad 1
o 495 y que terminan con la actividad 56. Esto resulta en un event
log filtrado con 67.411 casos, lo cual es el 81% del event log
original.

C. Anlisis de Flujo de Control

Para encontrar las rutas ms frecuentes en el event log, se ha
utilizado el plugin Performance Sequence Analysis de ProM, que


4





muestra los diferentes patrones (patterns), junto con algunos
parmetros de rendimiento para cada patrn, como el tiempo
medio de produccin. Los resultados de este anlisis muestran que
la observacin de nuestra ruta frecuente es correcta. La secuencia 1
61 56 se ejecuta 41.422 veces, es decir, el 49,5% de los casos.
En total hay 210 secuencias diferentes que un caso puede seguir.
La Tabla 1 muestra los 15 primeros patrones ms frecuentes del
proceso. Esta tabla muestra solo 8 actividades de un total de 60, y
que 15 secuencias describen 66.582 de los 67.411 casos, es decir,
la mayora de las secuencias del proceso siguen un modelo de
proceso muy simple, mientras que solo un pequeo porcentaje
seguir una ruta ms difcil. Filtramos el log de tal manera que
solo contenga los casos que siguen uno de estas 15 secuencias. En
este event log, hemos descubierto el modelo de proceso que se
muestra en la Figura 3. El chequeo de conformidad en este modelo
muestra una correcta terminacin del 99.4%, es decir, el 99,4% de
los casos que comienzan con la actividad 1 o 495 y terminan con la
actividad 56 siguen exactamente este modelo.

D. Anlisis de Rendimiento

En el event log obtenido, hemos realizado un anlisis de
grafico de puntos, de los cuales el resultado se muestra en la
Figura 4. A partir de este diagrama, podemos concluir que entre las
primeras dos actividades, la actividad 1 y 61, el tiempo de espera
se desva mucho. Como no tenemos ninguna informacin sobre la
duracin de las actividades, solo podemos concluir que, o bien la
actividad 1 tiene una alta desviacin, o la actividad 61 es una
actividad que es ejecutada irregularmente. El Anlisis de
Rendimiento tambin muestra que hay dos cuellos de botella en el
proceso estndar, es decir, los lugares entre la actividad 1 y 44, y el
lugar entre la actividad 44 y 61. A partir de esto, podemos concluir
que la actividad 1 tiene una duracin irregular. La Tabla 1 tambin
indica que los casos que comienzan con la actividad 495 tienen un
bajo tiempo de produccin promedio, mientras que un caso que
comienza con la actividad 1 muestra un alto tiempo de produccin
promedio.

E. Analisis de Rol

El event log es suficientemente rico como para realizar un
anlisis de roles. El complemento Organizational Miner de ProM
se utiliza para calcular el perfil de cada uno de los roles presentes
en el event log. Hemos descubierto 4 grupos diferentes. En el
primer grupo residen 14 roles, en el segundo grupo 37. Es
interesante que los dos ltimos grupos consten de un solo rol. Los
primeros dos grupos ejecutaron 15 y 23 actividades diferentes
respectivamente. Los ltimos dos grupos ejecutaron 2 y 4
actividades respectivamente. La inspeccin de la matriz rol-
actividad revela que las actividades realizadas por los dos ltimos
grupos se producen muy poco frecuentes, mientras que las
actividades realizadas por los otros roles son muy frecuentes. Es
muy probable, que los dos ltimos grupos son dos administradores
que ejecutan actividades si el proceso se queda atascado. A
continuacin se examinan los especialistas y generalistas. Una
jerarqua de roles es generada como se muestra en la Figura 6.
Desde el rbol generado, podemos concluir que hay 24
especialistas, cada uno ejecutando como mximo 3 actividades, y 5
generalistas reales que ejecutan cada uno 13 o ms actividades
diferentes. La mayora de los usuarios ejecutan entre 4 y 9
actividades diferentes. Es interesante que el servicio web es uno de
los especialistas, que solo ejecuta dos actividades diferentes. Es
destacable que el rol de administrador solo ejecuta 9 actividades,
lo cual es, en este proceso, demasiado poco para ser un generalista.


5

Esto indica que hay solo uno pocos casos en donde el
administrador tuvo una intervencin importante.

Un anlisis de redes sociales que representa el traspaso del
trabajo se muestra en la Figura 5. En esta figura, la amplitud de los
nodos representa el nmero de flechas salientes, mientras que la
altura de los nodos representa el nmero de flechas entrantes. El
grafico muestra que la mayora de los roles tienen un muy bajo
grado de flechas entrantes y salientes, mientras que solo un rol
tiene un muy alto grado de flechas salientes, indicando que este rol
delega actividades a muchos roles diferentes. Hay algunos
originadores que tienen un alto grado de flechas entrantes, lo que
significa que tienen una especia de posicin de recogida, puesto
que reciben trabajo delegado de muchos roles diferente, mientras
ellos no las pasan a muchos otros roles. Para medir a los
originadores centrales en el proceso, se calcula la mtrica de
centralidad de intermediacin. De esta mtrica podemos ver que
hay un rol que es ms central. La matriz rol-actividad revela que
este rol solo ejecuta las actividades 513 (37 veces), 56 (1.658
veces) y 24 (3.186 veces).

F. Transferencia de los Resultados

Al final de los diagnsticos del proceso, tuvimos una sesin
con el cliente en el que explicamos los resultados obtenidos.
Durante la discusin con el cliente, el cliente reconoce el modelo
del proceso, y de hecho, est de acuerdo que representa el flujo
central de sus procesos a pesar de que encontraron que los tiempos
de produccin de los casos es muy alta. En la discusin, se
constat que la actividad 45 solo se ejecuta si se ha ejecutado la
actividad 24. La actividad 45 es una actividad en la cual el caso es
analizado si es manejado correctamente, y solo debera ser
ejecutado una vez cada 100 casos. Sin embargo, resulto que esta
actividad fue ejecutada en casi la mitad de los casos, lo que
implica que este anlisis fue ejecutado con demasiada frecuencia.
La inspeccin del tiempo dentro de la organizacin, revel que
este era debido a un considerable atraso y el alto nmero de recin
llegados en ese momento. El alto tiempo de produccin tambin se
podra explicar por los mismos argumentos.
Al explicar los resultados del anlisis de rol, en particular el
modelo de la organizacin, el cliente poda nombrar los diferentes
grupos. El segundo grupo, el grupo 1, era un grupo especializado
de personas ejecutando las actividades ms elaboradas. El primer
grupo consista principalmente del departamento de
administracin, junto con algunas personas del segundo grupo,
quienes fueron transferidos en ese momento para ayudar al
departamento de administracin. El tercer grupo era una persona
que apoy a los diferentes departamentos. El ltimo grupo era el
administrador de sistemas. Tambin la alta centralidad del rol
role8 en la red social fue directamente reconocida por el cliente,
quien se sorprendi de alguna manera en que pudiramos
encontrar esto, ya que esta persona tena un rol central pues su
trabajo era principalmente delegar el trabajo a los diferentes
equipos en los departamentos.

IV. CONCLUSIONES

Para las organizaciones responder la pregunta principal:
Estamos en Control? pueden utilizar las tcnicas de process
mining. Sin embargo, la diversidad de la investigacin actual en
este campo hace que sea difcil ver cmo aplicar process mining
dentro de las organizaciones. En este artculo, se propone una
metodologa de diagnstico de procesos que da una visin general
del proceso apoyado por sistema de informacin. La metodologa
solo usa algunos de los mtodos de anlisis disponibles y se puede
realizar en un corto periodo de tiempo.
En la metodologa de diagnstico de procesos, se destacan
varios puntos de vista del proceso. El resultado incluye la
perspectiva del flujo de control, es decir como es el modelo del
proceso actual, la perspectiva del rendimiento, es decir, que tan
bien el sistema funciona y la perspectiva organizacional, es decir,
quin est involucrado en el sistema y cmo. El resultado de la
metodologa puede ser utilizada para su posterior anlisis en temas
especficos.
Se utiliz la metodologa en un estudio de caso para una
organizacin gubernamental holandesa. Este caso de estudio toma
alrededor de 50 horas hombre en total y se llev a cabo sin
conocimiento detallado del proceso de la compaa. Los resultados
de la aplicacin de la metodologa muestran que aproximadamente
el 80% de los casos se pueden describir como un modelo de
proceso simple que tiene un cuello de botella. El anlisis
organizacional tambin muestra que hay un rol dentro de la
organizacin que es muy central. Dicho punto central a menudo
indica un punto dbil dentro de la organizacin, pero tales
conclusiones solo se pueden extraer del cliente. En general, el
diagnostico de proceso solo presenta hechos. Para evitar malas
interpretaciones, el resultado nunca se debera entregar sin una
explicacin detallada del ejecutor del diagnstico. La discusin
entre el cliente y el ejecutor ayudan al cliente con la interpretacin
de los resultados.


El caso de estudio muestra que la metodologa de diagnstico
de procesos puede ser aplicada dentro de un corto periodo de
tiempo, entregando una visin general del proceso dentro de los


6



sistemas de informacin utilizados. Se necesitan ms casos de
estudio para afinar la metodologa.
La mayora de las tcnicas de anlisis en la metodologa
utilizan herramientas que pueden ser de valor para automatizar
partes de las actividades de proces mining , esto para simplificar el
uso de los diagnsticos de proceso, y por lo tanto, sea ms fcil.
La presentacin de los resultados en un documento escrito, por
lo general no es suficiente, ya que solo muestra los resultados en
un nivel fijo de abstraccin y tiempo. Los resultados son a menudo
mejor interpretados si la organizacin est dispuesta a interactuar
con los modelos encontrados, mirar las excepciones en el proceso,
y, en general, tener una mejor sensacin del proceso. Al dar una
instantnea, de alguna manera, limitamos la informacin. Para
capturar todos los aspectos del proceso, necesitamos encontrar
mejores maneras de presentar y visualizar los resultados.

REFERENCES

[1] P. Hornix, Performance analysis of business processes through process
mining, Masters thesis, Technische Universiteit Eindhoven, 2007.
[2] W. van der Aalst, A. Medeiros, and A. Weijters, Genetic process mining, in
ICATPN 2005, ser. LNCS, vol. 3536, 2005, pp. 48 69.
[3] C. Gunther and W. van der Aalst, Fuzzy mining: Adaptive process
simplification based on multi-perspective metrics, in BPM 2007, ser. LNCS,
vol. 4714, 2007, pp. 328 343.
[4] J. M. van der Werf, B. van Dongen, C. Hurkens, and A. Serebrenik, Process
discovery using integer linear programming, in ATPN, ser. LNCS, vol. 5062,
2008, pp. 368 387.
[5] Rozinat and W. van der Aalst, Conformance testing: Measuring the fit and
appropriateness of event logs and process models, in BPM 2005 Workshops,
ser. LNCS, vol. 3812, 2005, pp. 163 176.
[6] Rozinat and W. van der Aalst, Conformance testing: Measuring the fit and
appropriateness of event logs and process models, in BPM 2005 Workshops,
ser. LNCS, vol. 3812, 2005, pp. 163 176.
[7] W. van der Aalst, H. Reijers, and M. Song, Discovering social networks from
event logs, Computer Supported Cooperative Work, vol. 14, no. 6, pp. 549
593, 2005.
[8] M. Song and W. van der Aalst, Towards comprehensive support for
organizational mining, Technische Universiteit Eindhoven, Tech. Rep., 2007.
[9] W. van der Aalst, B. van Dongen, C. Gunther et al., Prom 4.0:
Comprehensive support for real process analysis, in ICATPN, ser. LNCS,
vol. 4546, 2007, pp. 484494.
[10] W. van der Aalst, H. Reijers, A. Weijters, B. van Dongen, A. Alves de
Medeiros, M. Song, and H. Verbeek, Business process mining: an industrial
application, Information Systems, vol. 32, no. 1, pp. 713 732, 2007.
[11] Rozinat, I. de Jong, C. Gunther, and W. van der Aalst, Process mining of test
processes: a case study, Technische Universiteit Eindhoven, Tech. Rep. WP
220, 2007.
[12] W. van der Aalst, A. Weijters, and L. Maruster, Workflow mining:
Discovering process models from event logs, IEEE Transactions on
Knowledge and Data Engineering, vol. 16, no. 9, pp. 1128 1142, September
2004.
[13] Weijters, W. van der Aalst, and A. Alves de Medeiros, Process mining with
the HeuristicsMiner algorithm, Technische Universiteit Eindhoven, Tech.
Rep. WP 166, 2006.
[14] M. Song and W. van der Aalst, Supporting process mining by showing events
at a glance, in WITS 2007, 2007.