Diagnstico de procesos: un mtodo basado en Procesos de MineraResumen-medida que las organizaciones cambian, sus sistemas de informacin pueden evolucionar de sistemas simples a sistemas complejos, que son difciles de entender, y por lo tanto difcil de mantener o ampliar. La minera de procesos puede ayudar a las organizaciones para tratar de entender los sistemas de informacin mediante el anlisis del sistema. En este trabajo se propone una metodologa para llevar a cabo el diagnstico de procesos, basado en la minera proceso. Teniendo en cuenta un registro de eventos de un sistema de informacin dentro de una organizacin, el diagnstico de procesos ofrece una amplia visin de proceso (s) de la organizacin dentro de un corto perodo de tiempo. En la metodologa de diagnstico del proceso, se destacan varias perspectivas del proceso. El resultado cubre la perspectiva del fl ujo de control, la perspectiva de rendimiento y el punto de vista organizativo. Se utiliz la metodologa en un caso de estudio para una organizacin no gubernamental holandesa. ndice Trminos proceso de gestin, anlisis de procesos, la minera de procesos, diseo de sistemas de informacinINTRODUCCIN Hoy en da, los sistemas de informacin son indispensables dentro de las organizaciones. Como organizaciones cambian, estos sistemas evolucionan a partir de los sistemas simples que eran fciles de entender a los sistemas complejos que son difciles de entender, y di fi cultad, por tanto, de mantener. Esto plantea la cuestin de si el sistema est funcionando como la organizacin piensa que funciona. Esta pregunta se produce normalmente en el caso del sistema de informacin tiene algunas aws fl, como problemas de rendimiento. Ms importante, para que las organizaciones estn en control, que necesitan para asegurar que el sistema est funcionando de acuerdo a su especificacin. Los sistemas de informacin de apoyo a los procesos de negocio suelen registrar todos los eventos en un registro. Dicho registro, llama un registro de eventos o pista de auditora, contiene informacin sobre los eventos: para los que la actividad y la instancia de 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, que se llama el camino o la carrera de ese caso, y muestra lo que sucedi eventos en qu orden y en qu momento. La minera de procesos permite que estos registros de sucesos para ser analizados. Minera Proceso ve "dentro del proceso" para responder a preguntas como: "cmo hace el proceso real se parece", "son los registros realizados se ajustan especi fi cacin, es decir, seguir todos los casos el modelo de proceso especificado fi?", "Hay cuellos de botella en el proceso? "," quin realiza qu tareas? "," que por lo general trabajan juntos? ", etc. El campo de la minera proceso cubre muchas reas, como las caractersticas de rendimiento (por ejemplo, los tiempos de produccin, descubrimiento de proceso (descubrimiento del control de flujo) la conformidad proceso (se ingrese el evento conformar especificacin) [5], [6], y las redes sociales (por ejemplo, de cooperacin o de subcontratacin) Respuestas sobre estas preguntas pueden servir como un mango para las organizaciones para responder a dos de las principales preguntas:. "estamos en control ? ", y" no el sistema de informacin muy re fl ejan la situacin del proceso de negocio? ". Una de las herramientas de apoyo a la minera proceso es el ProM marco minera proceso. Es para apoyar nuevas reas y tcnicas basada en complementos. En la ltima dcada, la minera proceso se desarroll de control de flujo descubrimiento de una amplia rea de investigacin para obtener todo tipo de informacin de un registro, que se tradujo en ms de 250 plugins diferentes dentro ProM. Esto demuestra que existen muchas tcnicas diferentes para aplicar la minera proceso. Puesto que hay tantos, no est claro cundo utilizar ms que plugin. Aunque muchos estudios de casos, vase, por ejemplo se han realizado, el principal problema con estos estudios de caso es que todos fueron de caso por caso sobre las ideas y el conocimiento del investigador de realizar el estudio de caso hecho. Hasta, ahora, no existe una metodologa para hacer frente a un nuevo caso de estudio, es decir, es difcil hacer que la minera proceso de un servicio repetible. En este trabajo se propone una metodologa para hacer un diagnstico de un proceso basado en la minera proceso. La metodologa est diseada para ofrecer en un corto perodo de tiempo una amplia visin del proceso (s) dentro del sistema de informacin. Clave en esta metodologa es la ausencia de conocimientos previos y de dominio especfico. La nica informacin disponible es el registro de eventos. Esto tambin implica que el diagnstico slo se presentan datos sobre el proceso. Corresponde a la organizacin de interpretar los resultados de los diagnsticos. Ilustramos la metodologa con un caso de estudio realizado por una organizacin gubernamental holandesa. Este trabajo est organizado de la siguiente manera: en primer lugar se explica la metodologa en la Seccin II. En la seccin III, se presenta un estudio de caso en el que se aplic la metodologa. Concluimos este trabajo en la Seccin IV.II. EL MTODO DE DIAGNSTICO PROCESO Se presenta una metodologa para el diagnstico de procesos rpidos. La metodologa tiene como objetivo dar una visin general del proceso en el sistema de informacin en un corto perodo de tiempo. Se compone de cinco fases: (1) ingrese preparacin, en la que se extrae el registro de eventos del sistema de informacin, (2) inspeccin de registros, para conseguir una mirada primera del proceso, (3) flujo de anlisis, (4) el rendimiento de control anlisis y (5) Anlisis de papel, es decir, elpersonas y 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 fases son de entrada tanto para el control de flujo de anlisis y el papel de anlisis, anlisis de rendimiento tambin necesita la entrada de control de flujo de anlisis. A. Preparacin Entrar un registro de eventos, cada evento se refiere a un caso y para una actividad, y tiene una marca de tiempo que indica cundo ocurri. Tpicamente, el sistema de informacin en cuestin tiene un formato de registro interno, que contiene toda la informacin, pero esto necesita ser extrado, o incluso transformado, con el fin de ser capaz de utilizarlo para la minera proceso. Formato interno del sistema de informacin de los registros puede nada de texto sin formato archivos de bases de datos internas, como en un sistema SAP. Por lo tanto, se necesita preprocesamiento del registro. Preprocesamiento ya plantea muchas preguntas. El primer paso es seleccionar la mejor idea de un caso, ya menudo hay varios candidatos. El siguiente paso es la identificacin de las actividades y sus eventos. Si el registro tiene varias marcas de tiempo, la semntica de las marcas de tiempo tiene que ser claro, por ejemplo, se trata de una marca de tiempo del comienzo del evento o del caso. Este tipo de problemas deben ser abordados con el fin de obtener un registro de eventos adecuado para pasar a la siguiente fase. B. Inspeccin Iniciar La siguiente fase consiste en familiarizarse con el registro de eventos, y para conseguir una mirada primera del proceso representado por el registro de eventos. En esta fase, se recogen estadsticas sobre el registro. Esto incluye informacin sobre el nmero de casos y los roles, el nmero total de eventos, los diferentes acontecimientos actuales, el nmero mnimo, mximo y promedio de eventos por caso, los eventos y de inicio y fin se encuentran sus ocurrencias, etc. Estas estadsticas dan ideas en el tamao del proceso y registro de eventos, y ayuda a los algoritmos de minera de ajustar y evaluar los resultados obtenidos en prximas fases. En base a estas estadsticas, el registro de eventos se filtra para eliminar los casos incompletos, es decir, se eliminan los casos que se iniciaron antes del inicio del registro de eventos y los casos que an se estaban ejecutando en el final del registro de eventos. Esta filtra registro de eventos es de entrada para las prximas fases. C. Control Anlisis de Flujo En esta fase, el control de fl ujo se analiza los aspectos del proceso. Da respuestas a la pregunta "qu hace el proceso real parece?". En primer lugar, si la organizacin tiene una descripcin del proceso, una comprobacin de cumplimiento se ejecuta para comprobarsi el proceso es conformar especi fi cacin, es decir, que cada caso en el registro de eventos se puede reproducir en la definicin proceso de fi [5]. Si bien este no es el caso, o una descripcin del proceso no existe, el control de fl ujo necesita ser descubierto. Hay muchos algoritmos disponibles para descubrir procesos, cf. [2], [12], [13], [4]. Slo ejecutar diferentes algoritmos de descubrimiento a menudo da una modelo de proceso, pero por lo general, esto se traduce en un modelo de proceso spaghettilike, ya que el comportamiento poco frecuentes, como excepciones, tambin se tienen en cuenta. Comportamiento infrecuente significa que hay un caso cuya secuencia no se produce con demasiada frecuencia. Por lo tanto, para descubrir un modelo de proceso que describe el funcionamiento de la planta, es necesario descartar secuencias infrecuentes fi primero, y considerar las secuencias con slo de alta frecuencia. Siguiendo el principio de Pareto, el registro tiene que ser filtr tal que al menos 80% de la de registro est cubierto, pero que slo contiene los casos con alta frecuencia de ocurrencia. Este registro de eventos se puede utilizar para descubrir el flujo de control. Un buen cheque por el modelo de proceso es ejecutar una comprobacin de cumplimiento en l. En este resultado, el comportamiento poco frecuente puede ser marcado.Anlisis de rendimiento D. Despus del descubrimiento del control de flujo, estos modelos de proceso se puede utilizar para analizar el rendimiento del proceso. Esta fase responde a preguntas como "existen cuellos de botella en el proceso?". En primer lugar, un anlisis grfico de puntos [14] se utiliza para comparar los casos y sus tiempos de ejecucin. El eje vertical de un grfico de puntos representa los casos en el registro de sucesos, el eje horizontal representa el tiempo. Esto ya da ideas tiles en el rendimiento del sistema. A continuacin, mediante la reproduccin del registro en el modelo de proceso, los cuellos de botella de rendimiento y tiempos de actividades individuales y el proceso en s se calculan [1]. Como el modelo de proceso slo se describe el funcionamiento del molino, este anlisis no es suficiente. Por lo tanto, despus de la de repeticin, las diferentes secuencias deben ser inspeccionados por separado, dando informacin valiosa acerca de los tiempos de produccin en los casos de excepciones u otros comportamientos poco frecuentes.Anlisis Papel E. Si el registro de eventos es lo suficientemente rico, o ms especficamente, si contiene informacin acerca de los cuales se ejecuta un evento, los roles en el proceso se pueden analizar. Un rol es una persona u otro recurso que est implicado en el proceso, mediante la ejecucin de actividades de ese proceso. Esta fase da respuestas a preguntas como "quin realiza qu actividades?" Y "que estn trabajando juntos?". En primer lugar, se crea una matriz de papel-actividad. En esta matriz, las filas representan los roles, las columnas representan cada evento del registro de eventos. Cada clula contiene el nmero de veces que el papel ejecutado ese evento. A continuacin, para cada funcin de un pro fi le est hecho de esta matriz. Si tienen funciones similares per fi les, que forman un grupo. De esta manera, los papeles en el registro de eventos se pueden dividir en grupos. Para la organizacin, ahora es posible comprobar estos grupos descubiertos en contra del modelo de organizacin utilizado. Esto le da a la organizacin informacin til acerca de la divisin del trabajo dentro de los departamentos de la organizacin, si las personas en todos los departamentos ejecutan actividades similares, y cmo la comunicacin es entre los diferentes departamentos [8]. A continuacin, los papeles se analizan para descubrir los especialistas, es decir, los roles que slo ejecutan algunas actividades, pero con mucha frecuencia, y generalistas, es decir, los roles que se ejecutan muchas actividades diferentes en el proceso. Una manera de descubrir este tipo de papeles es generar una jerarqua de roles, una jerarqua basada en las diferentes actividades de los roles ejecutan. Una flecha dirigida entre dos papeles indican que el papel en la base de la flecha puede hacer por lo menos las actividades de la funcin en la punta de la flecha. En tercer lugar, se realiza un anlisis de redes sociales. Una red social es una (dirigida) grfico que representa las relaciones entre las funciones, basado en una propiedad descubierta en el registro de eventos. Esta propiedad puede ser la entrega de la obra, es decir, los roles que pasan obra de un solo caso a uno y otro, y la subcontratacin, es decir, un papel pasa obra de un solo caso a otro papel, y este papel devuelve el trabajo de nuevo a la funcin primera despus fi nalizar su actividad. Mtricas importantes en el anlisis de redes sociales son la centralidad de intermediacin, es decir, el nmero de papeles un papel puede alcanzar slo atravesar bordes dirigidos, el grado de bordes entrantes, y el grado de bordes salientes [7]. F. Transferencia de los Resultados El objetivo de esta metodologa es para obtener informacin en los procesos de la organizacin y su apoyo por los sistemas de informacin. El resultado de los diagnsticos muestra todo el comportamiento observado en el sistema. Este comportamiento a menudo se desva del proceso previsto, debido a la conducta no deseada, como secuencias o usuario per fi les que no estn permitidos debido a, por ejemplo la legislacin, sino tambin por los atajos inteligentes tomadas por los usuarios deel sistema para hacer su trabajo ms fcil. El intrprete de los diagnsticos no es capaz de hacer la distincin entre el comportamiento deseado y no deseado. Por lo tanto, es importante discutir los resultados de los diagnsticos con el cliente, de modo que el cliente entienda el resultado, y obtiene una mejor comprensin del sistema de informacin. Con este conocimiento, y con el apoyo de la intrprete de los diagnsticos, el cliente puede refactorizar su sistema de informacin para que sea ms e fi ciente o para acelerarlo, por ejemplo, con la decisin de no permitir ciertas secuencias o usuario per fi les, o para apoyar a ciertos atajos tomados por sus usuarios.III. ESTUDIO DE CASO Para una organizacin no 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 para expedir un documento. A medida que ms y ms personas y organizaciones necesitan este documento, el proceso tiene que ser altamente optimizado. Para poder dar ideas de cmo funciona actualmente el sistema de informacin, y para dar recomendaciones para mejorar el sistema con el fin de acelerar el proceso, se realiz el mtodo diagnstico de procesos para dar una visin general de su sistema.A. Madero Preparacin El registro fue recibido un texto fi l con registros que contienen 23 campos. Cada registro contiene informacin sobre el caso identi fi cador, la actividad realizada, el recurso de la ejecucin, llamado el iniciador y varias marcas de tiempo, lo que indica la hora de inicio del caso, el momento en que ocurri el evento, y marcas de tiempo que indica el final previsto y efectivo el tiempo del caso. Desafortunadamente, no era posible encontrar un sello de tiempo que indica el final de una actividad, lo que significa que slo se conoce cuando se produjo una actividad, pero no el tiempo gastado en l.B. Inspeccin Entrar nuestro estudio de caso, el registro de eventos consta de 60 actividades diferentes y 83.611 casos con un total de 276.333 eventos. Haba 60 originadores involucrados en el proceso. En el registro se encontr cerca de 25 eventos de inicio, de las cuales las actividades 1 y 495 son los eventos de inicio en el 90% de todos los casos. El registro consta de 30 eventos finales, de los cuales la actividad 56 se encuentra en el 87% de todos los casos el evento final. Para obtener una vista en primer lugar, el Fuzzy Miner [3], un plugin en el ProM herramienta, se utiliza en el registro, con un arti fi cial iniciar y evento final aadi a cada caso. Los racimos Miner Fuzzy actividades coherentes con signi registro signi fi pero alta correlacin. La Figura 2 muestra el modelo de proceso resultante. El espesor de un arco indica la frecuencia. Por lo tanto, parece que la secuencia de 1-61-56 es un camino frecuente. Este modelo muestra que ambas actividades 1 y 495 son los eventos de arranque ms frecuentes, y que el proceso termina principalmente con la actividad 56. Este resultado est de acuerdo con las estadsticas que se encuentran en la fase anterior. Por lo tanto, es una buena idea para fi ltro el registro para obtener slo los casos que se inician con la actividad 1 o 495 y terminar con la actividad 56. Este resultados en un evento filtra fi conectarse con 67.411 casos, lo cual es el 81% del registro de eventos originales.C. Control Anlisis de flujo para hallar los caminos ms frecuentes en el registro de eventos, hemos utilizado el anlisis de la secuencia de rendimiento lector de ProM, que muestra los diferentes patrones, junto con algunos parmetros de rendimiento de cada patrn, como el tiempo promedio de procesamiento. Los resultados de este anlisis muestran que la observacin de nuestro camino frecuente es correcta. La secuencia 1 - 61 a 56 se ejecuta 41.422 veces, es decir, 49,5% de todos los casos. En total hay 210 secuencias diferentes de un caso puede seguir. La Tabla I muestra los 15 primeros de la mayora de los patrones de procesos frecuentes. Esta tabla muestra que slo 8 actividades de un total de 60 actividades y 15 secuencias describen 66.582 de los 67.411 casos, es decir, la mayora de las secuencias de procesos siguen un modelo de proceso muy simple, mientras que slo un porcentaje muy pequeo seguir un camino ms difcil. Nos filtra el registro de tal manera que slo contiene los casos que siguen una de estas 15 secuencias. En este registro de eventos, hemos descubierto el modelo de proceso que se muestra en la Figura 3. La comprobacin de la conformidad en este modelo muestra una correcta terminacin de 99,4%, es decir, el 99,4% de todos los casos que se inician con la actividad 1 o 495 y terminan con la actividad 56 siguen exactamente este modelo.Anlisis de rendimiento D. En el registro de eventos obtenido, hemos realizado un anlisis grfico de puntos, de los cuales el resultado se muestra en la Figura 4. En este diagrama, se puede concluir que entre las dos primeras actividades, actividad 1 y 61, el tiempo de espera se desva mucho. Como lo hacemosno tiene ninguna informacin sobre la duracin de las actividades, slo podemos concluir que, o bien la actividad 1 tiene una alta desviacin, o actividad 61 es una actividad que se ejecuta de manera irregular. Anlisis de rendimiento ha demostrado que hay dos cuellos de botella en el proceso estndar, es decir, los lugares entre la actividad 1 y 44 y el lugar entre las actividades 44 y 61. A partir de esto, podemos concluir que la actividad 1 tiene una duracin irregular. Tabla I tambin indica que los casos comienzan con la actividad 495 tienen un tiempo de rendimiento promedio bajo, mientras que a partir de un caso con la actividad 1 da un alto promedio de tiempo de procesamiento.E. Anlisis Papel El registro de eventos es lo suficientemente rico como para realizar un anlisis de funcin. El ProM Plugin Organizacional Miner [8] se utiliza para calcular el per fi l de cada una de las funciones presentes en el registro de eventos. Hemos descubierto 4 grupos diferentes. En el primer grupo, 14 papeles de residencia, en el segundo grupo 37. Interesante es que los dos ltimos grupos, tanto consiste en un solo papel. Los primeros dos grupos ejecutaron respectivamente 15 y 23 actividades diferentes. Los dos ltimos grupos ejecutaron respectivamente 2 y 4 actividades. 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 papeles son muy frecuentes. Lo ms probable, los dos ltimos grupos son dos administradores ejecutoras actividades si el proceso qued atascado. A continuacin, especialistas y generalistas son inspeccionados. Una jerarqua de papel como se muestra en la Figura 6 se descubre. En el rbol generado, podemos concluir que hay 24 especialistas, cada uno ejecutando a lo sumo 3 actividades, y 5 generalistas reales que se ejecutan cada25Uso bajo licencia autorizado limitado a: Universidad Pontificia Catlica de Chile. Descargado el 31 de marzo de 2009 a las 15:32 de IEEE Xplore. Aplican restricciones.Fig. 4. punteada Anlisis Grfico13 o ms actividades diferentes. La mayora de los usuarios ejecutan entre los 4 y 9 actividades diferentes. Interesante es que el servicio web es uno de los especialistas, solamente la ejecucin de dos actividades diferentes. Notable es que el rol de administrador slo se ejecut 9 actividades, que es en este proceso muy pocos para ser un generalista. Esto indica que slo hay unos pocos casos en los que el administrador tuvo una intervencin importante. Un anlisis de redes sociales que representa la entrega de trabajo se muestra en la Figura 5. En esta figura, la amplitud de nodos representa el nmero de arcos salientes, mientras que la altura del nodo representa el nmero de arcos entrantes. El grfico muestra que la mayora de los papeles tienen un grado muy bajo de arcos entrantes y salientes, mientras que slo una funcin tiene un grado muy grande de arcos salientes, lo que indica que este papel traspasos actividades a muchos papeles diferentes. Hay algunos creadores que tienen un alto grado de arcos entrantes, lo que significa que tienen una especie de posicin de recogida, puesto que consiguen trabajo entregado desde muchos papeles diferentes, mientras que no pasan a muchas otras funciones. Para medir los originadores centrales en el proceso, se calcula la mtrica centralidad de intermediacin. De esta mtrica podemos ver que hay un papel que es ms central. La matriz roleactivity revela que este papel slo ejecuta actividades 513 (37 veces), 56 (1658 veces) y 24 (3186 veces).F. Transferencia de los Resultados Al final de los diagnsticos de 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 de proceso y de acuerdo en que este hecho representa el ncleo flujo de sus procesos, a pesar de que encontraron el tiempo de procesamiento de los casos muy altas. En la discusin, parece que la actividad 45 de hecho solamente se ejecuta si se ha ejecutado la actividad 24. Actividad 45 es una actividad en la que se comprueba el caso si se maneja correctamente, y slo debe ejecutarse una vez cada 100 casos. Sin embargo, result que esta actividad fue ejecutado en casi la mitad de todas las huellas, lo que implica que esta verificacin se ejecut con demasiada frecuencia. Inspeccionar el perodo dentro de la organizacin revel que esto era debido a un considerable atraso y el elevado nmero de recin llegados en ese momento. El tiempo de alto rendimiento tambin podra explicarse por el mismoargumentos. Explicando los resultados del anlisis de conducta, en particular, el modelo de organizacin, el cliente podra nombrar los diferentes grupos. El segundo grupo, el grupo 1, era un grupo especializado de personas ejecucin de las actividades ms elaborados. El primer grupo consisti principalmente en el departamento de administracin, junto con algunas personas del segundo grupo, que fueron trasladados en ese momento para ayudar al departamento de administracin. El tercer grupo era una persona que apoy a los diferentes departamentos. El ltimo grupo fue el administrador del sistema. Tambin la alta centralidad del rol "role8" en la red social est directamente reconocido por el cliente, que era de alguna manera sorprendido de que pudiramos hallar esto, como esta persona de hecho tuvo un papel central ya que su trabajo era principalmente a delegar el trabajo a diferentes equipos en los departamentos.IV. CONCLUSIONES Para las organizaciones para responder a la pregunta principal: "estamos en control?" Tcnicas de minera de proceso pueden ser utilizados. Sin embargo, la diversidad de la investigacin actual en este campo hace que sea difcil ver cmo aplicar la minera proceso dentro de las organizaciones. En este trabajo, se propone una metodologa de diagnstico del proceso, que da una visin general del proceso apoyado por el sistema de informacin. La metodologa slo usa algunos de los mtodos de anlisis disponibles, y se puede realizar en un corto perodo de tiempo. En la metodologa de diagnstico del proceso, se destacan varias perspectivas del proceso. El resultado abarca el control de flujo de perspectiva, es decir, "cmo el modelo de proceso en realidad se parece", la perspectiva de rendimiento, es decir, "qu tan bien realizar el sistema" y el punto de vista organizativo, es decir, "que est involucrado en el proceso y cmo". El resultado de la metodologa se puede utilizar para un anlisis ms detallado sobre temas especficos. Se utiliz la metodologa en un caso de estudio para una organizacin no gubernamental holandesa. Este estudio de caso tom cerca de 50 horas de trabajo en total y se llev a cabo sin el conocimiento detallado de los procesos de la compaa. Los resultados de la aplicacin de la espectculo metodologa que aproximadamente el 80% de los casos se puede describir con un modelo de proceso simple que tiene un cuello de botella. Asimismo, el anlisis de la organizacin muestra que hay un rol dentro de la organizacin que es muy central. Tal punto central a menudo indica un punto dbil dentro de la organizacin, pero tales conclusiones slo puede ser dibujado por el cliente. En general, el diagnstico de procesos slo se presenta hechos. Para evitar malas interpretaciones, el resultado nunca se debe dar sin explicacin detallada de la intrprete de diagnstico. Discusin entre el cliente y los artistas ayuda al cliente con la interpretacin de los resultados. El estudio de caso demuestra que la metodologa de diagnstico del proceso de hecho se puede aplicar dentro de un corto perodo de tiempo, dando una visin general del proceso dentro de los sistemas de informacin utilizados. Se necesitan ms estudios de casos para definir afinar la metodologa. La mayor parte de las tcnicas de anlisis de las herramientas de uso de la metodologa. Puede ser de valor para automatizar partes de las actividades mineras proceso para simplificar el uso de diagnstico de proceso, y por lo tanto para que sea ms fcil. La presentacin de los resultados en un documento escrito, es por lo general no su fi ciente, ya que slo muestra los resultados en un nivel fijo de la abstraccin y el tiempo. Los resultados son a menudo mejores interpretable si la organizacin es capaz de interactuar con los modelos que se encuentran, ver excepciones en el proceso, y, en general, obtener una mejor sensacin del proceso. Al dar una instantnea, de alguna manera, ya limitamos la informacin. Con el fin de capturar todos los aspectos del proceso, tenemos que hallar mejores formas de presentar y visualizar los resultados.