Extracção e Avaliação de Fluxo de Processos. Engenharia de Informática e Computadores

Transcrição

1 Extracção e Avaliação de Fluxo de Processos Pedro Miguel dos Santos Martins Dissertação para obtenção do Grau de Mestre em Engenharia de Informática e Computadores Presidente: Orientador: Vogal: Prof. José Tribolet Prof. Diogo R. Ferreira Prof. Andreas Wichert Setembro de 2009

2 Agradecimentos Um obrigado especial ao Professor Diogo R. Ferreira pelo acompanhamento e apoio que me deu ao longo deste ano, durante o qual este trabalho foi realizado. A sua participação mostrou-se essencial pelo conhecimento e experiência disponibilizados, sem as quais teria sido impossível a realização desta Tese de Mestrado. Gostaria também de agradecer ao Professor Pedro M. Reis dos Santos pela contribuição e disponibilidade demonstrada na realização de um dos casos de estudo apresentado neste trabalho. Aos meus colegas Gabriel Veiga e Gil Aires pela troca de ideias e de sugestões. Julgo que, juntamente com o professor Diogo R. Ferreira, construímos um núcleo de trabalho na área de Process Mining interessante, e cujo as interacções daí resultantes foram bastante positivas. Não podia também deixar de agradecer ao meu colega, e amigo, Ivo Anastácio pelo apoio e motivação que sempre me deu, essenciais numa etapa feita de altos e baixos. Por último, referir todos aqueles que, directa ou indirectamente, contribuíram na minha formação, quer académica como pessoal. Aos meus pais, professores, amigos e colegas os meus sinceros agradecimentos. 1

3 Resumo Cada vez mais as organizações procuram novas formas de monitorizar o comportamento dos seus processos de negócio, em tempo real. Através de técnicas de process mining torna-se possível a extracção de modelos de processos, a partir de logs de eventos registados a partir de Sistemas de Informação Orientados a Processos. No entanto, cada técnica de process mining possui as suas vantagens, e podem originar diferentes tipos de modelos. Torna-se, por isso, fundamental a utilização de ferramentas que permitam a avaliação destas técnicas. No entanto, as metodologias de avaliação existentes possuem algumas limitações, não conseguindo abranger eficazmente todo o tipo de técnicas existentes. Com base no estudo da conformidade de processos, neste trabalho é proposto uma metodologia de avaliação, baseada na simulação de processos e na aplicação de métricas de análise de comparação de logs. Esta metodologia permitirá a avaliação de algoritmos de process mining e das suas capacidades para extraírem o comportamento registado nos logs de eventos. Com base na mesma abordagem comparativa, é ainda proposta uma metodologia de avaliação de conformidade de processos. O trabalho realizado fornece, assim, uma ferramenta genérica capaz de suportar diferentes técnicas, garantindo mais meios para a análise de técnicas de process mining e de conformidade de processos. Palavras-chave: Process Mining, Conformidade de Processos, Metodologia de Avaliação, Métricas de Avaliação 2

4 Abstract Organizations are seeking out new ways to monitor the run-time behavior of their business processes. With process mining techniques it becomes possible to extract process models from event logs and compare them to the expected behavior. However, each process mining technique has its own merits and different techniques produce different kinds of models. The use of an evaluation tool becames fundamental. Based on process conformance, this work presents a new evaluation framework, using process simulation and a set of metrics to compare the event logs produced by different models. This framework provides an assessment of the capabilities of the available process mining techniques. Based on the same evaluation method it is also proposed an framework to evaluate process conformance between an event log and a model. With that, a generic framework evaluation for process mining and process conformance is proposed, increasing the analysis methods for both techniques. Keywords: Process Mining, Conformance Checking, Evaluation Framework, Evaluation Metrics. 3

5 Lista de Conteúdos Lista de Figuras 6 Lista de Tabelas 8 Lista de Acrónimos 8 1 Introdução Contexto Objectivos Estruturação da Dissertação Trabalho Relacionado Introdução a Process Mining Ferramentas de Process Mining ProM Framework Suite Pallas Athenas BPM Protos Microsoft SQL Server Algoritmos de Process Mining Algoritmo α Algoritmo α Algoritmo Heurístico Algoritmo DWS Algoritmo Genético Conformidade de Processos Conformidade segundo Governatori et al Conformidade segundo Rozinat et al Framework para Avaliação de Conformidade de Processos Simulação de Modelos em Conformidade de Processos Conclusão Metodologia de Avaliação Apresentação da Metodologia Genérica de Avaliação Metodologia Geral de Avaliação: Passo a Passo

6 3.1.2 Aspectos gerais de implementação Implementação das Interfaces de Mining Simulação de Modelos Métricas de Avaliação Métrica de Avaliação Naive Métrica de Avaliação Aproximada Metodologia de Avaliação de Conformidade de Processos Conclusão Experiências e Resultados Padrões estudados Resultados Obtidos Conclusão Casos de Estudo Simulação de um Modelo de Rede Processo de Suporte Técnico Aplicação da Metodologia de Avaliação Aplicação da métrica aproximada Conclusão Conclusão Principais contribuições Trabalho futuro

7 Lista de Figuras 2.1 Exemplo de como um log de evento pode ser transformado num modelo, no formato de rede Petri, através de técnicas de process mining Perspectiva geral da arquitectura da ferramenta ProM [1] Imagem da aplicação que implementa o algoritmo heurístico na ferramenta ProM Exemplo de um modelo de processo que aceita demasiado comportamento, i.e., pouco preciso Mapeamento das relações entre o termo de Conformidade e dos espaços identificados nesta abordagem Legal e de Negócio Ilustração das diferentes componentes da framework de Conformidade, e como interagem entre si [2] Passos principais da metodologia de avaliação de process mining, apresentada neste trabalho Exemplo do formato de um log de eventos de entrada. Na primeira parte é feito mapeamento entre os nomes das actividades e respectiva letra. Na segunda parte encontram-se, por cada linha, as sequências de actividades com respectivos números de ocorrência Exemplo de um log de eventos, ilustrando um processo de obtenção de licença de condução, no formato MXML [1] Estrutura segundo a qual se encontra organizada a metodologia de avaliação, desenvolvida no âmbito deste trabalho Exemplo de um padrão AND no formato de rede Heurística Matriz Causal correspondente à rede Heurística representada Estrutura interna definida para as Redes de Petri, que permite executar a sua simulação Estrutura interna definida para as redes hheurísticas, que permite executar a sua simulação Exemplo do formato dos logs de eventos, utilizados no módulo de avaliação (4 o passo). Cada letra corresponde a uma actividade específica e cada linha a uma instância de execução do processo a ser analisado Exemplo de uma matriz contendo as distâncias de Levenshtein existentes entre as sequências dos logs da Tabela 3.3. Nas linhas encontram-se as sequências do log original, enquanto nas colunas se encontram as do log simulado a Iteração

8 a Iteração a Iteração a Iteração Exemplo de processo de emparelhamento de uma matriz de distâncias Ilustração da Metodologia de Avaliação de Conformidade de Modelos de Processos Exemplo de um padrão cíclico simples, de comprimento Um exemplo de como é definido as probabilidades, em caso de disjunção, quando estas não são previamente definidos Modelo resultante da aplicação do algoritmo α ++ ao padrão two-loop Modelo que representa o resultado esperado da extracção do padrão two-loop Exemplo de padrão And Split/Join representado numa rede Heurística Exemplo de padrão And Split/Join representado numa rede de Petri Lista de padrões utilizados para a realização do estudo comparativo, apresentado neste capítulo Modelo descrito do sistema de encaminhado de Mensagens: c = capacidade da fila; s = número de servidores; t = tempo de processamento; l = tempo entre chegadas de mensagens; p = probabilidade de seguir determinado caminho [3] Imagem do modelo utilizado na ferramenta AweSim, no processo simulação, com os respectivos pontos de controlo Rede de Petri resultante da aplicação do algoritmo α ao problema em questão Descrição do Processo pré-definido de tratamento de Incidentes [4] Descrição do fluxo de Incidentes desde que é criado/actualizado até à avaliação de Conformance com o Modelo Pré-definido Modelo que contém os comportamentos (status) detectados, após execução do Issue Manager Lista das 10 principais sequências de actividades mais frequentes, com maior número de ocorrência (total de sequências igual a 6766) [4]

9 Lista de Tabelas 2.1 Um exemplo de uma Matriz Causal, obtida a partir do modelo representado na Figura Intervalo de resultados possíveis, de serem produzidos pela metodologia de avaliação, e respectivo significado Exemplo de dois Logs de Eventos, com as respectivas sequências, antes de serem agregadas Exemplo de sequências que, apesar de serem diferentes, podem representar o mesmo comportamento Sequências possíveis, geradas a partir de um modelo cíclico, de comprimento 1, e respectivas probabilidades Resultados obtidos após a aplicação da metodologia de avaliação a algoritmos de mining determinísticos recorrendo à métrica naive Resultados obtidos após a aplicação da metodologia de avaliação a algoritmos de mining probabilísticos recorrendo à métrica naive Resultados obtidos após a aplicação da metodologia de avaliação a algoritmos de mining determinísticos recorrendo à métrica de avaliação aproximada (G ) Resultados obtidos após a aplicação da metodologia de avaliação a algoritmos de mining probabilísticos recorrendo à métrica de avaliação aproximada (G ) Resultados dos cinco algoritmos, na extracção dos padrões apresentados, segundo a metodologia genérica de avaliação Resultados obtidos após a aplicação da metodologia de avaliação recorrendo à métrica naive Lista de actividades terminais, e respectivas probabilidades de ocorrências, retiradas do log uma das 6 experiências realizadas Lista de sequências de actividades, e respectiva ocorrência, tendo em conta o cenário hipotético apresentado (total de seqências igual a 4594) Matriz de emparelhamento, contendo as distâncias de Levenshtein entre as sequências do modelo (linhas) e as sequências do log de eventos (colunas)

10 Capítulo 1 Introdução 1.1 Contexto Nos últimos anos tem-se assistido a um aumento do interesse, por parte das organizações, na monitorização dos seus processos de negócio. Esta situação deve-se a vários factores, quer pelo surgimento de novas imposições legais ou, simplesmente, de forma a garantir maior eficiência nos seus processos, perante forças da concorrência. Simultaneamente, cada vez mais, informação sobre os processos de negócio, de uma dada organização, é gerada e guardada em registos, conhecidos como logs de eventos. Isto graças a um conjunto de Sistemas de Informação Orientados a Processos (PAIS de Process-Aware Information Systems) que registam constantemente informação sobre os eventos executados por uma organização [5]. Exemplos disso são sistemas como os ERP (Enterprise Resource Planning), CRM (Customer Relationship Management) ou SCM (Supply Chain Management) para referir apenas alguns [6]. Não obstante, perante a necessidade de monitorização de processos, esta informação não é, na maioria dos casos, utilizada da forma mais conveniente. Normalmente, parte-se do princípio de que os processos de negócio estão bem definidos, utilizando a informação registada apenas para cálculos de performance(e.g. tempo que determinada tarefa demora em média). A verdade é que, em muitas situações, os processos de negócio têm tendência a evoluir, à medida que as pessoas os executam, verificando-se uma discordância entre o que é suposto acontecer e o que realmente acontece. É neste cenário de discordância que as técnicas de Process Mining poderão ser bastante úteis. Através de algoritmos de extracção de fluxos de processos é possível construir o modelo respectivo, contendo as dependências entre as actividades desse processo [7][8][9]. Essa extracção é feita precisamente a partir de logs de eventos, registados por PAIS, que contêm os conjuntos de sequências executados ao longo do tempo. Com base nestes logs é possível gerar modelos de processos que reflictam o comportamento observado, garantindo informações importantes sobre o funcionamento da organização. Paralelamente às abordagens de extracção de fluxos de processos de negócio, inserem-se as técnicas 9

11 de Conformidade de Processos. O objectivo destas técnicas passa por avaliar o alinhamento entre o comportamento definido, normalmente especificado sob a forma de modelos, e o comportamento real, registado em logs de eventos [10][11][12]. Desta forma, a análise de conformidade de processos é realizada entre modelo e log de eventos. Assume, por isso, a existência de modelos definidos, caracterizando como os processos de negócio devem ser executados, e de logs de eventos, de forma a calcular o alinhamento entre ambos. Isto em contraponto às técnicas de process mining que assumem apenas a existência de logs de eventos, com o objectivo de obter os respectivos modelos [10]. No entanto, apesar de serem duas áreas distintas, em [13] é sugerida a análise de conformidade de processos como uma ferramenta de avaliação das técnicas de process mining. Assim, após analisar um determinado log de evento e de ser extraído o respectivo modelo, é possível aferir a conformidade entre estes. Pretende-se, com isto, averiguar se o modelo extraído representa correctamente o comportamento do log, ou seja, se a técnica de process mining foi eficiente. Em [14] é também apresentado um método de comparação de processos baseado na utilização iterativa de técnicas de process mining e na simulação de modelos. Deste processo deverão ser gerados dois modelos, que poderão ser comparados entre eles, permitindo avaliar as técnicas de mining utilizadas. Apesar de já existirem alguns métodos de avaliação de técnicas de process mining, estas apresentam alguns problemas. Por exemplo, o primeiro método de avaliação referido ([13]) assenta a sua análise na utilização de redes Petri. Isto tem consequências uma vez que, ao limitar-se o tipo de modelo utilizado, está-se também a limitar o tipo de técnicas de mining àquelas que produzam esse tipo de modelo. Apesar da existência de métodos de conversão entre diferentes tipos modelos, que permitam contornar parcialmente este problema, a verdade é que esta operação implicará sempre a perda de alguns detalhes fundamentais do modelo original. Já no segundo método de avaliação ([14]), o problema está no facto da análise comparativa ser realizada ao nível dos modelos. Como é referido em [15], este tipo de comparação acaba por ser ineficaz, dado que, por vezes, modelos semelhantes podem originar comportamentos completamente distintos. Continua a existir a necessidade de uma abordagem que seja verdadeiramente independente do modelo extraído e, consequentemente, que seja capaz de abranger o maior número de técnicas de mining possível. Esta necessidade ainda ganha maior relevo em áreas tão recentes como as do process mining. Daqui nasce o motivo deste trabalho, sendo o seu objectivo principal a definição e desenvolvimento de uma metodologia genérica de avaliação de técnicas de process mining, independentemente do tipo de modelo que estas geram. Ao contrário do que sucede na abordagem apresentada em [14], cuja comparação é realizada directamente entre modelos, a metodologia aqui apresentada visa a comparação entre logs de eventos. Assim, a partir de um log de eventos, registado a partir de um PAIS, é possível extrair um modelo aplicando técnicas de process mining. De seguida, através da sua simulação, é gerado um novo log de eventos contendo os comportamentos representados no modelo minado. Por fim, através da comparação desses dois logs, é possível obter o seu grau de similaridade e daí inferir o grau de precisão da técnica de mining aplicada. Para esse efeito, foram definidas duas métricas probabilísticas, baseadas na comparação de sequências 10

12 existentes em ambos logs e na frequência com que estas ocorrem. É também apresentada uma metodologia de conformidade de processos, com base na mesma abordagem de comparação de logs de eventos. 1.2 Objectivos A finalidade desta dissertação, face aos problemas identificados, foca-se no desenvolvimento de uma metodologia que consiga suportar uma avaliação baseada na comparação de logs de eventos. A metodologia desenvolvida destinar-se-á, numa primeira fase, à avaliação de técnicas de process mining, pelo que foram traçados os seguintes objectivos: Definir métricas para cálculo do grau de similaridade comportamental, entre sequências de actividades registadas em logs de eventos. Desenvolver metodologia genérica de avaliação, capaz de avaliar diferentes tipos de algoritmos de mining. A metodologia deverá: conseguir suportar diferentes tipos de modelos (e.g. redes de Petri e Heurística); ser facilmente expandida com novos algoritmos de mining; ser facilmente expandida com novas métricas de avaliação; Realizar um estudo comparativo entre um conjunto de algoritmos de mining, aplicando-os a um conjunto de de padrões comuns, de forma a aferir a validade dos resultados e, consequentemente, da metodologia aplicada; Aplicar a metodologia de avaliação ao contexto de Conformidade de Processos; Experimentar a metodologia em cenários reais. 1.3 Estruturação da Dissertação Esta Dissertação encontra-se organizado da seguinte forma: Capítulo 1 - Introdução: Introduz as motivações deste trabalho e alguns conceitos importantes para a sua percepção. Apresentação do problema que se pretende resolver assim como os seus objectivos. Capítulo 2 - Trabalho Relacionado: Introduz as áreas de process mining e de conformidade de processos, sendo apresentadas as principais técnicas de ambas áreas. Capítulo 3 - Metodologia de Avaliação Probabilística: Indicação dos detalhes de definição e implementação da metodologia de avaliação, vocacionado na análise de algoritmos de mining. Apresentação, passo a passo, da metodologia, com principal destaque nas métricas de avaliação 11

13 probabilísticas, utilizadas, na comparação entre logs. Apresentação de uma variante da metodologia de avaliação aplicada à avaliação de conformidade de processos. Capítulo 4 - Experimentação e Resultados: Apresentação das primeiras experiências efectuadas com a metodologia de avaliação de process mining, onde são aplicados os algoritmos introduzidos no Capítulo 2 a um conjunto de padrões comuns. Capítulo 5 - Casos de Estudo: Descrição de dois casos de estudo distintos, onde foram, respectivamente, testadas as duas vertentes da metodologia de avaliação realizada: Análise de Process Mining e de Conformidade de Processos. Capítulo 6 - Conclusões e Trabalho Futuro: Conclusão do trabalho realizado, destacando as principais características e alguns pontos que podem ser melhorados, como trabalho futuro. 12

14 Capítulo 2 Trabalho Relacionado Como já foi referido, anteriormente, o objectivo do Process Mining passa pela extracção de informação de logs de eventos, registados através de Sistemas de Informação Orientados a Processos. Procura, no fundo, resolver o problema que muitas organizações atravessam, ao possuírem pouca informação sobre o que realmente acontece internamente. Pretende-se, com isto, preencher uma lacuna, que tende a existir, entre o que está definido e o que realmente acontece. Desta forma, na Secção 2.1 será introduzido a área process mining. Serão também, respectivamente, apresentadas nas Secções 2.2 e 2.3 algumas das principais ferramentas e algoritmos existentes nesta área de investigação. Na Secção 2.4 serão introduzidas técnicas de conformidade de processos, sendo na Secção 2.5 apresentados os métodos de avaliação de process mining, com base em abordagens de conformidade. Por último, na Secção 2.6, serão feitas algumas considerações acerca deste capítulo. 2.1 Introdução a Process Mining Tipicamente, as técnicas de process mining assumem que é possível registar, num log, informação, contendo sequências de eventos que podem ser directamente mapeadas em actividades, de um determinado processo de negócio. É também assumido que o log de eventos é completo, na medida em que nele deverão estar registados todos os comportamentos passíveis de ocorrer, no processo de negócio que se pretende estudar. Outro factor a ter em consideração, aquando da análise de um log de eventos, é a possibilidade de existência de ruído. Por ruído entenda-se um conjunto de comportamentos errados que, normalmente, surgem em pequenas percentagens num log de eventos. As origens deste tipo de comportamento podem ser provocadas por erros humanos, a executar determinadas tarefas, ou por erros de sistema (e.g. excepções), que podem originar transições entre actividades que não estão inicialmente previstas. Para além dos tipos de eventos registados, as técnicas de mining poderão considerar outros tipos informação tal como a pessoa que executou determinado evento, a data e hora em que este terá ocorrido, entre outros, dependendo do tipo de técnicas que se pretenda utilizar. 13

15 Figura 2.1: Exemplo de como um log de evento pode ser transformado num modelo, no formato de rede Petri, através de técnicas de process mining Existem assim, diferentes tipos de técnicas de process mining que se podem aplicar, dependendo da perspectiva de negócio que se pretende estudar: Perspectiva do Processo: o foco passa por extrair o fluxo de processos, i.e., a ordem pela qual as actividades foram registadas no log de eventos, expressas em modelos (e.g. redes de Petri). Pretende-se ilustrar como a organização funciona. Perspectiva da Organização: o foco está na organização, i.e., consistem em estudar a rede social da organização e perceber como as pessoas comunicam e trabalham, em conjunto. Permite também perceber qual a posição de cada pessoa na estrutura da organização, i.e., que pessoa realiza determinada(s) actividade(s). Neste trabalho, o foco estará na avaliação de técnicas de mining vocacionadas para a análise da Perspectiva do Processo. Desta forma, o estudo de processos através da aplicação de técnicas de process mining poderá não só contribuir na identificação de potenciais falhas, nos processos de uma organização, como, em determinados casos, originar os respectivos processos de reestruturação. Exemplo de aplicação de uma técnica de Process Mining Por norma, uma técnica de mining orientada à perspectiva do processo começa por analisar um log de eventos, ilustrado no exemplo da Figura 2.1. Através deste log é possível inferir qual ordem pela qual as actividades são executadas e, desta forma, gerar um modelo conforme o da Figura 2.1. Daí a importância do log ser completo, tendo impacto na precisão do modelo produzido. Deste modo, a partir do log de eventos da Figura 2.1, é possível inferir o seguinte: parte-se do princípio de que o processo começa pela actividade A, uma vez que esta surge sempre em primeiro lugar, em todos os registos; as actividades B,C e E ocorrem depois de A, i.e., seguem A; 14

16 B e C são actividades paralelas, uma vez que ocorrem sempre a seguir à mesma actividade (A), e porque se podem seguir uma à outra.; D é a última actividade do processo, surgindo a seguir às actividades B,C e E. Para este exemplo em particular, acaba por ser fácil construir um modelo que represente o processo de negócio registado no log de eventos. No entanto, em cenários reais, à medida que a complexidade do processo e do log aumenta, torna-se mais difícil executar este tipo de análises, pelo que as técnicas de process mining poderão ser muito valiosas. 2.2 Ferramentas de Process Mining ProM Framework ProM Framework é uma ferramenta open-source, desenvolvida pelo Grupo de Process Mining da Universidade de Eindhoven, que suporta um conjunto vasto de técnicas de process mining e de análise de logs de eventos [16], assim como um conjunto de funcionalidades de conversão e exportação de vários formatos de modelos. Está implementada em Java e tem-se expandido, sobretudo, graças ao contributo da comunidade de investigadores da área que tem contribuindo com novas extensões, nos últimos anos. Os logs de eventos suportados por esta ferramenta têm de estar no formato MXML 1, possuíndo uma aplicação própria para a conversão de logsde outros formatos para este específico chamado ProM Import [17]. Estas características encontram-se representadas na Figura 2.2, que dá uma perspectiva geral da arquitectura da ferramenta ProM Suite Pallas Athenas BPM Protos BPM Protos é uma aplicação proprietária, integrada na ferramenta Pallas Athenas Suite, que procura suportar o ciclo de vida de um processo modelação, simulação e mining. O pacote de process mining, disponível em todas as versões do BPM Protos, é baseado no algoritmo genérico (que será apresentado na Secção 2.3.5) e permite extrair a partir de logs de eventos o respectivo modelo do processo, permitindo a sua visualização e simulação. Os logs de eventos são suportados em dois formatos distintos: ftdb 2 e csv 3 [18][19] Microsoft SQL Server A ferrmenta Microsoft SQL Server é uma aplicação proprietária de gestão de bases de dados, integradas com módulos de business intelligence, com os quais é possível aplicar técnicas de data mining com base em informação alojada na base de dados. Não sendo uma ferramenta orientado à área de process mining, 1 O formato MXML é uma variante do formato XML, significando Mining Extensible Markup Language 2 O formato ftdb é um formato interno, utilizado para agregar diferentes tipos de informação acerca de um processo. 3 O formato csv é normalmente utilizado por ferramentas de folhas de cálculo e podem ser utilizados para simular um modelo de processo minado. 15

17 Figura 2.2: Perspectiva geral da arquitectura da ferramenta ProM [1]. 16

18 é possível utilizá-la para resolver alguns dos problemas que esta pretende resolver uma vez que o process mining recorre a técnicas de data mining de forma a inferir modelos de processo. Apesar de ser uma ferramenta proprietária, é possível expandi-la através de módulos, já tendo sido inclusivamente utilizada em [20] e [21] no contexto de process mining. 2.3 Algoritmos de Process Mining Sendo um dos objectivos deste trabalho proceder ao desenvolvimento de uma metologia genérica de avaliação de algoritmos de process mining, foi necessário estudar algumas das técnicas de mining existentes. Pretende-se que a metodologia desenvolvida possa ser aplicável a qualquer técnica de mining, independentemente do tipo de modelo que esta produza. Para tal, foi seleccionado um conjunto de cinco algoritmos, distintos entre si, que contribuíssem na elaboração da metodologia e na comparação de resultados, numa fase de validação e experimentação. Serão assim introduzidos algoritmos de mining baseados em abordagens determinísticas (Secções e 2.3.2) em comparação com abordagens probabilísticas (Secção 2.3.3). Será também apresentado um algoritmo de mining que se distingue pelo facto de recorrer a técnicas de clustering de forma a conseguir discernir, correctamente, os diferentes comportamentos registados num log de eventos Secção Por último, será apresentada, na Secção 2.3.5, uma aplicação de algoritmos genéticos à área de process mining Algoritmo α O algoritmo α baseia-se na procura local, a um log de eventos, com o objectivo de inferir relações, entre actividades, com base na sua ocorrência ao longo log, i.e., trata-se de um algoritmo determinístico. Este facto pode representar uma limitação considerável, na performance deste algoritmo, dado não considerar a frequência com que cada tipo de comportamento ocorre ao longo log - condicionando assim a análise de logs que contenham ruído [1]. Deste modo, é essencial, para o correcto funcionamento do algoritmo α, que o log seja completo e possua apenas comportamento correcto. Como já foi referido, o algoritmo α vai analisar o log de eventos na procura de um conjunto de relações. Estas podem ser: Seguidas (a > b): quando uma actividade (b) segue outra actividade (a); Causais (a b): quando uma actividade (a) é seguida pela segunda (b), mas o inverso não acontece; Não relacionadas (a#b): quando duas actividades não possuem qualquer tipo de relacionamento entre elas, i.e., não se seguem; Paralelas (a b): quando ambas as actividades podem ser seguidas, entre elas. 17

19 Assim sendo, o algoritmo α pode ser definido da seguinte forma. Definição do Algoritmo O algoritmo α começa por extrair todas as transacções de actividades, existentes no log de eventos, processando-as, de modo a perceber que actividades possuem relações causais. Desta análise é possível obter o número exacto de places que a rede de Petri, a descobrir, terá [1]. Por último, a rede de Petri é criada, sendo os places obtidos ligados às respectivas transições, de entrada e saída. No caso do algoritmo α o resultado final será na forma de uma redes SWF 4. Limitações do Algoritmo α Como já foi referido, tratando-se de um algoritmo determinístico não faz qualquer distinção entre comportamentos mais frequentes, que se assumem como sendo correctos, a comportamentos menos frequentes, normalmente conotado como comportamento errado (ruído). Isto significa que este algoritmo apenas consegue uma performance positiva no tratamento de logs de eventos que contenham apenas comportamento correcto. Para além dessa limitação, o algoritmo α produz ainda resultados erróneos no tratamento de um conjunto de padrões de fluxo, dado não os conseguir distinguir aquando da análise ao log original. Isto acontece porque, por vezes, padrões diferentes podem originar redes SWF iguais. Esses padrões são os seguintes: Ciclos Curtos: Dado tratar-se de um algoritmo de procura local, não consegue distinguir ciclos curtos de outras transacções simples; Tarefas invisíveis: Este tipo de tarefas não são geradas uma vez que o algoritmo α apenas considerará tarefas que estejam presentes no log; Tarefas duplicadas, Tarefas implícitas e Pontos de Escolha Condicionados (Non-Free Choices) uma vez que as redes SWF não conseguem representar estes tipos de padrões. Foi para ultrapassar algumas destas limitações que surgiram novos algoritmos e abordagens, alguns dos quais serão introduzidos nas sub-secções seguintes Algoritmo α++ O algoritmo α++ surge como uma extensão do algoritmo α, na medida em que procura ultrapassar a incapacidade deste em tratar padrões cíclicos curtos. Assim sendo, o algoritmo funciona da seguinte forma. 4 Redes SWF (Structured wofklow net) são uma variante de redes de Petri, normalmente usadas na representação de fluxos de actividades, sem recorrer a places implícitos. 18

20 Figura 2.3: Imagem da aplicação que implementa o algoritmo heurístico na ferramenta ProM. Definição do Algoritmo No primeiro passo, o algoritmo irá analisar o log de eventos, na procura da ocorrência de padrões cíclicos, identificando, caso estes existam, a que places estão ligados. De seguida, os ciclos identificados serão removidos do log original. O segundo passo irá então consistir na aplicação do algoritmo α ao log, sem os ciclos identificados no primeiro passo. Deste passo irá resultar uma rede SWF [22]. Por último, o terceiro passo consistirá em acrescentar à rede, descoberta no segundo passo, os padrões cíclicos, anteriormente removidos, nas respectivas posições [22] Algoritmo Heurístico Anteriormente foram apresentados dois algoritmos baseados numa abordagem determinística o que representa uma séria limitação, na medida em que não consegue identificar, no log de eventos, a existência de ruído. Assim, surgem algoritmos que, com base numa abordagem probabilística, irão analisar o log de eventos na procura de dependências entre actividades e, com base na sua frequência, concluir se se trata de um comportamento correcto ou não [23]. Nesta família de algoritmos insere-se o heurístico que, para além de ser baseado em probabilidade, é um algoritmo de procura local. Por exemplo, seguindo o modelo da Figura 2.1 é possível inferir que se B ocorre sempre após a actividade A então é provável que exista uma relação entre estas duas 19

21 actividades, i.e., A ser seguida por B. Assim sendo o algoritmo heurístico vai considerar os seguintes tipo de relações, entre actividades: 1. Seguidas (a > b): quando uma actividade (b) segue outra actividade (a); 2. Causais (a b): quando uma actividade (a) é seguida pela segunda (b), mas o inverso não acontece; 3. Não relacionadas (a#b): quando duas actividades não possuem qualquer tipo de relacionamento entre elas, i.e., não se seguem; 4. Paralelas (a b): quando ambas as actividades podem ser seguidas entre elas; 5. Relação Cíclica (a >> b): quando duas actividades se encontram numa relação cíclica curta (esta relação permite a correcta detecção deste tipo de padrões); 6. Relação de Precedência (a >>> b): quando a primeira actividade ocorre sempre antes da segunda actividade, ao longo do log de eventos. Assim sendo o algoritmo Heurístico é separado em três passos distintos e pode ser definido da seguinte forma. Definição do Algoritmo O primeiro passo Descoberta do Grafo de dependências começa por construir o grafo de dependências entre as actividades. Neste caso é utilizado um método probabilístico para inferir as dependências, i.e., para concluir se duas actividades estão ou não relacionadas. Assim sendo, vai calcular as relações causais, entre actividades, considerando todas as relações entre estas, i.e., em ambas as direcções (ver Equação em 2.1 [23]). Quanto maior for esse valor, maior a probabilidade de existir relação entre essas duas actividades. a b = ( a > b b > a ) ( a > b + b > a + 1) (2.1) Neste passo, levanta-se a questão sobre quão alto deve a probabilidade ser, para que uma relação seja considerada relevante. Nem sempre as relações com probabilidade de ocorrência reduzidos devem ser consideradas ruído, podendo-se tratar simplesmente de comportamento correcto com baixa frequência. Para tal, foram definidos três thresholds, de modo a ultrapassar esta situação. São eles: Dependency threshold, Positive observations threshold e Relative to best threshold. No segundo Passo Tratamento das relações AND/XOR o algoritmo irá procurar por relações AND/XOR entre actividades. É considerado que duas actividades (B e C por exemplo) se encontram numa relação AND se o padrão BC ou CB puder ocorrer no log de eventos. Por outro lado, se duas actividades estão numa relação XOR estas não se podem seguir, ao long longo do log (i.e. elas não se relacionam). 20

22 Assim sendo, vai ser calculada a probabilidade de duas actividades, que sigam a mesma actividade, estarem, ou não, numa relação paralela (i.e. AND). Valores elevados significam que estas se encontram numa relação AND e valores reduzidos implicam que estas estão numa relação XOR. Para ilustrar este passo, considere-se as actividades B e C, do log representado na Figura 2.1. Ambas surgem após a actividade A e podem aparecer juntas, i.e., seguidas em ambas as ordens, o que pode implicar que provavelmente se encontrem numa relação AND. Por outro lado, se considerarmos as relações B e E, do mesmo log, ambas seguem a actividade A mas nunca surgem juntas, i.e., estão numa relação XOR. O terceiro e último passo Tratamento de distâncias longas vai considerar situações onde não é possível inferir as relações, existentes ente actividades, baseando apenas a análise nas suas posições adjacentes. (e.g. relações cíclicas). Este passo vai implicar uma análise ao modelo como um todo. Esta situação é problemática para a maioria dos algoritmos de mining, que se baseiam numa procura local poucos algoritmos como o Genético, conseguem tratar esta situação. Para tal, o algoritmo Heurístico consegue, através da relação de precedência (a >>> b), contornar esta situação. Ao longo destes três passos, através do algoritmo heurístico, o resultado final vai sendo construído de forma gradual, tratando as diferentes situações possíveis, de forma separada. Assim, consegue obter melhores resultados do que os algoritmos α e α++, principalmente por considerar o factor probabilístico na sua análise. Uma definição formal destes três passos pode ser encontrado em [23] Algoritmo DWS O DWS (Disjunctive Workflow Schema) é um algoritmo de mining baseado numa abordagem de clustering hierárquico. Assim sendo, o log, que se pretende estudar, é dividido recursivamente em clusters homogéneos,do ponto de vista comportamental. Para cada recursão, será aplicado o algoritmo heurístico ao cluster descoberto [24]. Desta forma, o algoritmo vai começar por examinar o log, gerando o modelo correspondente, através do algoritmo heurístico a este modelo denomina-se modelo raiz, dado concentrar todo o comportamento registado no log. Caso se detecte que se atingiu uma solução óptima ou se atinja o número máximo de clusters definidos, o algoritmo termina. Caso contrário, o modelo é dividido em clusters, através do algoritmo K-Means. No final de cada iteração, é verificado se a solução óptima foi atingida e se não existe nenhum cluster que agregue demasiado comportamento, de forma a determinar quando é que o algoritmo deve parar [24]. No final, serão devolvidos n + 1 modelos, correspondente aos n clusters detectados mais o modelo raiz, na forma de redes Heurísticas Algoritmo Genético As técnicas, até aqui introduzidas, tinham em comum o facto de serem algoritmos de procura local, i.e., quando analisam as relações de uma determinada actividade apenas são observadas as actividades que 21

23 Actividade Act. Entrada Act. Saída A B, C, E B A D C A D D A D E B, C, E Tabela 2.1: Um exemplo de uma Matriz Causal, obtida a partir do modelo representado na Figura 2.1 lhe estão adjacentes (que lhe sucedam ou precedam directamente no log de eventos). Isto representa uma limitação na descoberta de determinados padrões que impliquem dependências longas, dado exigir uma análise mais abrangente. Foi para ultrapassar estas limitações que [1] introduziu os algoritmos Genéticos à área de investigação de process mining, de forma a beneficiar das suas propriedades de procura global. Os algoritmos Genéticos consistem assim em métodos de procura que tentam recriar o processo da evolução, estando normalmente ligado às áreas de Biologia e Bio-tecnologia [25]. Assim sendo, o problema visado pelos algoritmos Genéticos pode ser definido como a procura num espaço de hipóteses candidatas também denominada por população com o intuito de identificar as melhores. A melhor hípotese é definida como aquela que maximiza uma medida numérica para o problema em questão, a qual é denominada por fitness [26]. Contextualizando no cenário de process mining, uma hipótese pode ser vista como um modelo de processo e a função de fitness como uma medida que permite avaliar se o modelo reproduz o comportamento registado no log. Desta forma, o algoritmo irá gerar vários modelos (o espaço de hipótese) e, avaliando cada uma através da função de fitness, escolher aquele que melhor representar o log. Este tipo de algoritmos actua de forma iterativa, actualizando a cada passo a população. A cada iteração, os elementos da população são avaliados pela função de fitness, originando uma nova população, gerada a partir dos elementos, da actual população, com melhor fitness. Enquanto alguns elementos (com melhor classificação) avançam directamente para a nova população, sem sofrerem alterações, outros são submetidos a um conjunto de alterações, obtidos através da aplicação de operadores genéticos: elitismo, cruzamento, mutação. Assim sendo, tendo em conta a estrutura básica dos algoritmos Genéticos, é importante definir três pontos base: Representação Interna que define o espaço de procura do algoritmo. Para a área de process mining o principal requisito é que seja possível representar as dependências entre actividades, resgistadas no log, i.e., expressar correctamente as transições entre actividades [27]. Para esse efeito [1] introduz como forma de representação a matriz causal (ver Tabela 2.1) [1]. Função de Fitness, como já foi mencionado, define o critério de classificação dos elementos da população. Este critério é utilizado na escolha dos elementos que serão incluídos na geração seguinte [26]. Em process mining isto pode ser utilizado para medir de que forma os modelos representam o comportamento registado no log. Para tal, são introduzidos duas dimensões, 22

24 que pretendem quantificar o quão preciso e completo o modelo é. Um processo diz-se completo quando consegue tratar todas as sequências de actividades registados no log de eventos. Por sua vez, diz-se preciso quando não gera comportamento que não fora registado, evitando assim a geração de comportamento extra (ver exemplo da Figura 2.4 como sendo um modelo genérico daquele representado na Figura 2.1). Idealmente, estes dois requisitos deveriam ser igualmente cumpridos. No entanto, por norma, as funções de fitness tendem a dar prioridade ao facto do modelo ser completo, uma vez que, acima de tudo, é importante que o modelo minado consiga reproduzir todo o comportamento registado. Operadores Genéticos permitem potenciar a procura, por parte do algoritmo, no espaço de hipoteses definido na representação interna. Assim sendo, foram definidos três operadores: Elitista, Cruzamento e Mutação. Elitista é utilizado para filtrar os melhores elementos da população. Cruzamento permite gerar dois novos elementos, com base em outros dois elementos, através do seu cruzamento, i.e., copiando partes específicas, de cada elemento pai, utilizando uma máscara de crossover 5. No contexto de process mining um operador de crossover poderá produzir novos modelos (elementos) acrescentando/removendo actividades ou mudando as relações entre estas. Mutação é utilizado para produzir pequenas mudanças aleatórias, na população. Isto poderá significar mudanças nas relações da população, acrescentando/removendo aleatoriamente actividades. Figura 2.4: Exemplo de um modelo de processo que aceita demasiado comportamento, i.e., pouco preciso. Definição do Algoritmo O algoritmo Genético começa por construir, de forma aleatória, a população inicial com todos os seus indivíduos, com base nas actividades lidas a partir do log de eventos que se pretende estudar. Assim, para cada indivíduo é calculado o fitness e verificado se o critério de paragem do algoritmo é 5 A máscara de crossover indica que parte de cada elemento pai deve ser mudado 23

25 atingido 6. Se o critério de paragem for atingido, é devolvido, como resultado, a população actual 7. Caso contrário, se o algoritmo não parar, é construída uma nova geração, utilizando o operador Elitista para escolher os melhores elementos que serão submetidos aos operadores de cruzamento e mutação. A função de fitness é então aplicada à nova geração e o processo é novamente repetido, até o critério de paragem se verificar. 2.4 Conformidade de Processos Na Secção anterior foram apresentadas cinco técnicas distintas de extracção de processos de negócio, a partir de informação registada em logs de eventos por Sistemas de Informação - denominado por técnicas process mining. Paralelamente à área de process mining surge a de Conformidade de Processos, com o objectivo de comparar o comportamento esperado 8, de um processo de negócio, com o comportamento que realmente acontece e que é registado pelos PAIS [5]. Este tipo de análise poderá trazer grandes mais valias para uma organização na medida em que um problema de conformidade, entre modelo e log, pode ser visto das seguintes formas: Assumindo o modelo de negócio definido como sendo o comportamento correcto, a existência de um problema poderá significar que na prática a organização está a funcionar mal e, como tal, serão necessárias alterações para corrigir essas discrepâncias; Assumindo o log de evento como sendo o correcto, uma vez que se trata da forma como a organização funciona realmente, poderá significar que o modelo de negócio está desactualizado e que já não faz sentido com a lógica de negócio actual; Mesmo em caso de total alinhamento entre modelo de negócio e log de evento, esta avaliação poderá ser extremamente valiosa, ao garantir confiança no modelo actual. O conceito de conformidade de processos pode ser exercido a vários níveis. Nas Secções e são introduzidas duas abordagens de conformidade ao nível da monitorização de processos de negócio, onde o principal objectivo é aferir o alinhamento entre as regras de negócio definidas e a forma como estas são executadas. Já as Secções 2.5 e ilustram o recurso às abordagens de conformidade como forma de avaliar resultados produzidos por algoritmos de process mining. 6 O algoritmo pára quando tiver computado o máximo de gerações permitido ou quando o indivíduo com melhor fitness não apresentar mudanças durante n/2 gerações. 7 As transições que nunca foram utilizadas são removidas da população final podem ser vistas como actividades invisíveis, que nunca foram disparadas. 8 Por comportamento esperado entenda-se aquele que é definido à partida, normalmente sob forma de modelos de negócio, e que tentam ilustrar a forma como determinada organização deve funcionar. 24

26 2.4.1 Conformidade segundo Governatori et al. O conceito introduzido em [28] denominado como Business Compliance surge como uma técnica que permite avaliar a forma como os processos de negócio estão implementados, em comparação com as varáveis, definidas nos contratos de negócio. Esta abordagem pode ser vista como uma forma de perceber o alinhamento entre o espaço Legal mais focado na negociação dos contratos e em garantir a validade legal destes e o espaço de Negócio focado em identificar os requisitos de negócio e na definição/modelação dos processos de negócio (Ver Figura 2.5). Assim sendo, a Conformidade surge como um elo de ligação entre estes dois espaços. Para avaliar essa ligação, [28] apresenta duas abordagens distintas. Figura 2.5: Mapeamento das relações entre o termo de Conformidade e dos espaços identificados nesta abordagem Legal e de Negócio. A primeira abordagem define um conjunto de orientações para obter, de forma progressiva, as regras necessárias para a execução dos processos de negócio, tendo como ponto de partida as varáveis de negócio contratualizadas. Esta abordagem permite assim cobrir toda a organização, na medida em que define uma metodologia que permite derivar os processos de negócio a partir dos contratos de negócio definidos, garantindo assim o alinhamento entre estes. A sua utilização adequa-se a situações em que novos sistemas necessitam de ser desenhados e implementados, permitindo não só inferir os processos a partir dos contratos de negócio mas também uma integração mais eficaz de novos processos, dado serem definidos com base nas mesmas especificações. Por outro lado, a segunda abordagem proposta, sugere a comparação das regras dos processos de negócio com as regras presentes nos contratos de negócio, na procura por inconsistências. A sua utilização adequa-se a situações em que se pretenda avaliar o grau de integração, de um sistema já existente. Poderá ser útil também para perceber se um processo de negócio já definido poderá suportar, sem conflitos, novos requisitos de negócio, evitando assim o surgimento de incompatibilidades. Ambas as abordagens baseiam-se num formalismo lógico, para expressar os comportamentos existentes nos contratos e nos processos de negócio. A partir deste formalismo será possível determinar quais as soluções ideais, parcialmente ideais e não ideais, quando comparados os caminhos possíveis dos processos de negócio com as condições contratualizadas Conformidade segundo Rozinat et al. O conceito de Conformidade introduzido por Rozinat et al ([29] [10] [12]) pretende estudar o alinhamento de negócio de uma organização, através do estudo comparativo entre os processos definidos 25

27 (usados para configurar os sistemas de informação) e os processos reais (resultantes da execução dos sistemas de informação em forma de log de eventos). Esta abordagem diverge assim das abordagens de mining apresentadas na secção 2.1, na medida em que enquanto os algoritmos de mining pretendem extrair o modelo que represente o comportamento registado num log, a análise de Conformidade vai fazer um estudo comparativo entre um modelo e o respectivo log, e avaliar o grau de similaridade entre eles. Esta avaliação será realizada segundo duas dimensões: Abrangência do log: avalia o quão bem o log cobre o comportamento representado no modelo, classificando entre 0 (quando não existe qualquer tipo de ligação) e 1 (quando todas as transições do modelo se encontram registadas no log). Abrangência do modelo: avalia o quão bem o modelo cobre o comportamento registado no log, classificando entre 0 (quando não existe qualquer tipo de ligação) e 1 (quando todas as entradas do log estão representadas no modelo). De forma a cobrir as dimensões enunciadas, foi definido um conjunto de métricas que permitem aferir o alinhamento entre o modelo e o respectivo log, segundo as dimensões referidas. São elas: Fitness: esta métrica mede o nível de encaixe entre log e modelo de processo, i.e., se é posssível replicar no modelo o comportamento registado no log, através da simulação do modelo, em formato de redes de Petri. Assim sendo, tentar-se-á replicar cada entrada do log na rede de Petri, aferindo no final as inconsistências com base nos tokens que não forem consumidos, i.e., que não tiverem atingido o place final 9 ([1], [29]). Relação Comportamental: A métrica anteriormente apresentada, media a capacidade do modelo em representar todo o comportamento patente no log de eventos. No entanto, pode suceder que o modelo, apesar de conseguir retratar o comportamento registado, seja demasiado genérico, permitindo a ocorrência de transições que nunca tenham ocorrido, representando também um sinal de desalinhamento. Esta métrica pretende, assim, avaliar a quantidade de comportamentos extra, permitidos pelo modelo, que nunca foram registados no log de eventos. Para tal serão comparados os comportamentos permitidos pelo modelo com os registados no log, aferindo em cada caso que actividades seguem ou precedem outras actividades - i.e., duas actividades poderão seguir-se/preceder-se sempre, algumas vezes ou nunca. Relação Estrutural: Esta métrica está mais relacionada com a sintaxe do modelo de processo, i.e., existem diversas formas de representar, graficamente, o mesmo comportamento, sendo que algumas são mais correctas do que outras. Consiste assim na análise de padrões, recorrentes, no log de forma a perceber se o modelo está compacto e perceptível, penalizando a ocorrência de padrões como actividades duplicadas, actividades invisíveis ou places implícitos, que contribuem para um aumento da complexidade do modelo. Apesar de, idealmente, ser importante maximizar os resultados de todas as métricas, na prática esta abordagem define o fitness como métrica prioritária, na medida em que em caso de conflito se deve 9 Numa rede de Petri, correctamente executada, todos os tokens devem ser consumidos 26

28 beneficiar modelos que consigam representar o comportamento registado. Daí que se deva executar esta métrica antes das restantes. Uma descrição formal das métricas referidas pode ser encontrado em [29]. Esta abordagem resultou num conjunto de extensões para ferramenta ProM e, apesar de se basear em dimensões genéricas que possam ser aplicadas para avaliar qualquer tipo de modelo, foi implementada de forma a efectuar a comparação sobre redes de Petri, estando limitada a esse formato de modelos. Apesar da ferramenta ProM permitir a conversão de outros formatos (e.g. redes Heurísticas) para redes de Petri, esta operação implica a perda de algumas prioridades inerentes a alguns modelos, que não são representáveis em redes de Petri (e.g. probabilidades associadas a transições). 2.5 Framework para Avaliação de Conformidade de Processos Nas secções anteriores foram introduzidas duas abordagens distintas de conformidade de processos de negócios. Partindo da abordagem de conformidade apresentada na Secção 2.4.2, em [13] é apresentada um protótipo de uma framework de avaliação de algoritmos de process mining. Esta surgiu como resposta à necessidade de criação de normas de avaliação, que facultassem formas de medir a performance de algoritmos de process mining. Pretendia-se assim definir um ambiente genérico de desenvolvimento e de testes que permitisse uma fácil integração a investigadores da área de process mining, sem necessitarem de definir ambientes próprios de forma ad hoc. Esta framework deveria garantir ainda a avaliação da similaridade entre modelos, extraídos a partir de técnicas de process mining, e os respectivos logs de eventos definido antes como Conformidade de Processos. A framework, ilustrada na Figura 2.6, é então composta pelos seguintes módulos: Repositório Central contendo diversos exemplares de logs de eventos e modelos de Processos, que podem ser comparados segundo diferentes abordagens de avaliação. Este repositório deve poder ser estendido, com novos exemplares, através da criação de novos logs (por simulação de modelos); criação de novos modelos (aplicando algoritmos de mining a logs existentes); modificando exemplares já existentes (e.g. adicionar ruído, novos padrões); Gerador de Logs permite gerar novos logs de eventos, através da simulação de modelos ou através da modificação de logs existentes no Repositório Central, de forma a adicionar comportamentos específicos ou ruído. Este módulo contribuirá assim para um enriquecimento do Repositório Central; Verificador é utilizado para garantir a validade dos exemplares armazenados no Repositório Central, assegurando se os logs de eventos e os modelos de processo estão correctos e que determinadas propriedades, necessárias para a correcta aplicação das técnicas de mining, são asseguradas; Módulo de Process Mining tal como o nome sugere, permite aplicar técnicas de mining, a logs de eventos armazenados no Repositório Central, gerando novos modelos que podem vir a 27

29 Figura 2.6: Ilustração das diferentes componentes da framework de Conformidade, e como interagem entre si [2]. ser avaliados; Módulo de Avaliação e Conformidade é o responsável por aplicar, ao Repositório Central, determinadas técnicas de avaliação e conformidade. Pode, por isso, ser visto como um repositório de diferentes métricas de avaliação, podendo ser estendido com novas técnicas de conformidade. Para este módulo, [13] sugeriu duas abordagens possíveis, (i) utilizando métricas de conformidade (semelhantes à apresentada na secção 2.4.2) e (ii) baseada em técnicas de machine learning Simulação de Modelos em Conformidade de Processos Na framework de avaliação apresentada, a simulação de modelos surgia como forma de geração de logs (módulo de Geração de Logs). No entanto, existem outras aplicações possíveis, onde a simulação surge com um papel mais fulcral no processo de conformidade de processos, com particular destaque para a avaliação de algoritmos de process mining. O trabalho apresentado em [14] centra-se na simulação de modelos com o objectivo de realizar uma análise de aferição ao impacto que possíveis mudanças ou decisões poderão ter no modelo definido, sendo a simulação uma forma de testar essas mudanças. Desta forma, a abordagem apresentada é definida em dois passos. No primeiro passo são aplicadas 28

30 técnicas de process mining aos logs de eventos, gerados a partir dos PAIS, que se pretende estudar. Neste caso, o objectivo passa por estudar as diferentes perspectivas da organização (e.g. fluxo de actividades, rede social), em simultâneo, sendo, para isso, utilizadas mais do que uma técnica de mining. Assim, serão extraídas diferentes perspectivas do negócio e integradas num único modelo, na forma de redes de Petri coloridas [30], o qual é possível simular. O segundo passo começa pela simulação do modelo resultante do primeiro passo, gerando um log de eventos que será submetido aos mesmos procedimentos, i.e., às mesmas técnicas de mining. Deste passo resultará um novo modelo. Finalmente, é efectuada a comparação entre os modelos, obtidos no primeiro e segundo passos, sendo possível obter daí o grau de similaridade entre os dois modelos. A utilização de simulação, do modelo obtido no primeiro passo permitirá testar possíveis alterações nas variáveis do modelo e perceber que impacto terão, ao observar o resultado no segundo modelo. É também possível, através deste método, comparar técnicas de mining, utilizadas no primeiro e segundo passo e perceber se produzem, ou não, o mesmo resultado. 2.6 Conclusão O capítulo de trabalho relacionado, apresentado neste documento, centra-se em torno de duas áreas distintas Process Mining e Conformidade de Modelos mas que, como foi referido, intersectam-se. Estando a área de Process Mining relacionada com a extracção de Modelos de Negócio, a partir de logs de eventos, e a área Conformidade de Processos relacionada com a avaliação comportamental de uma organização (comportamento real vs comportamento definido), a verdade é que, como foi possível ver nas Secção 2.5, as duas áreas encontram-se fortemente ligadas. É precisamente nesse ponto de intersecção que as contribuições produzidas neste trabalho se inserem. Desta forma, no Capítulo 3 será apresentada uma metodologia de avaliação, que pode ser aplicada à avaliação de process mining (Secção 3.1) e à avaliação de Conformidade de Processos (Secção 3.3). 29

31 Capítulo 3 Metodologia de Avaliação No capítulo anterior foram apresentadas algumas técnicas de process mining e de conformidade de processos. Foram ainda abordadas abordagens onde se recorre a técnicas de conformidade, de forma a avaliar técnicas de process mining. No entanto, estas abordagens apresentam algumas limitações. A verdade é que, como havia sido proposto em [13], continua a existir a necessidade de uma metodologia genérica de avaliação, independente do tipo de modelos ou de técnicas que se pretenda avaliar. Esta necessidade assume maior importância numa área tão recente, como a de process mining, de modo a identificar que técnicas se adequam a determinadas situações, garantindo também maior confiança nos resultados produzidos. O objectivo deste trabalho consistirá, então, no desenvolvimento de uma metodologia genérica de avaliação, baseada na comparação directa entre logs, que permita abranger as duas áreas apresentadas - process mining e conformidade. Pretende-se, assim, uniformizar a forma como a avaliação é realizada. Para tal, foram desenvolvidos um conjunto de módulos que permitam suportar um conjunto de métricas probabilísticas de avaliação. A metodologia desenvolvida deverá garantir não só a análise de qualquer algoritmo de process mining, com base na simulação de modelos minado, assim como a avaliação de conformidade entre um log (comportamento real) e um modelo (comportamento definido). Desta forma, na Secção 3.1 será apresentada a metodologia geral de avaliação, com todos os módulos realizados, vocacionada para a avaliação de process mining. Serão também introduzidas, na Secção 3.2, as métricas implementadas para esse efeito. Na Secção 3.3, será apresentada uma metodologia focada na realização de conformidade de processos que, no fundo, resulta de uma especialização da metodologia geral. Por último, na Secção 3.4, serão apresentadas algumas conclusões acerca da implementação da metodologia genérica de avaliação. 30

32 3.1 Apresentação da Metodologia Genérica de Avaliação Para desenvolver uma metodologia de avaliação de algoritmos de process mining é importante ter os seguintes pontos em consideração: existem vários algoritmos de mining disponíveis, estando sempre a surgir novas abordagens; cada técnica pode produzir tipos de modelos diferentes.(e.g. redes de Petri, redes Heurísticas); como garantir a realização da avaliação entre logs de eventos. Em relação ao primeiro ponto, é importante garantir que a metodologia a desenvolver consiga abranger o máximo de algoritmos possíveis, assegurando também que esta consiga ser facilmente estendida com novos algoritmos de mining. No fundo, pretende-se que cada técnica seja encarada como uma interface, que apenas recebe um log, em formato MXML, e produz o modelo descoberto. Daqui surge a segunda questão: como suportar os vários tipos de modelos? Para garantir o suporte de vários tipos de modelos, a técnica apresentada na Secção recorre ao uso de uma operação de conversão, implementada na ferramenta ProM, que permite a conversão de outros modelos para redes de Petri. No entanto, esta abordagem apresenta os seguintes problemas: está dependente da existência desta funcionalidade de conversão para todos os tipos de modelos; a conversão entre modelos, pode significar a perda de informação extremamente importante (e.g. as redes heurísticas possuem probabilidade associada às suas transacções, algo que as redes de Petri não suportam). É, por isso, importante garantir que a metodologia desenvolvida suporte o maior número de tipos de modelos existentes, maximizando, assim, a avaliação das especificidades de cada algoritmo. Por último, é importante garantir o ponto central da metodologia, i.e., a forma como a avaliação será realizada. Para tal, uma vez que se pretende realizar uma avaliação baseada na comparação directa entre logs, a simulação de modelos é utilizada como forma de extracção de um novo log, que contenha o comportamento presente no modelo minado. Só assim será possível efectuar a comparação entre o log simulado e o log original - transformando a avaliação num problema de comparação de strings. Todos estes aspectos foram considerados na definição da metodologia representada na Figura 3.1, ao longo de quatro passos distintos e que serão introduzidos na Secção Metodologia Geral de Avaliação: Passo a Passo 1 o Passo - Normalização da Entrada O 1 o passo da metodologia consiste na normalização do log de entrada para um formato MXML que possa ser analisado pela ferramenta ProM. Este log representa aquilo que já denominámos como o comportamento real e resulta da execução diária do processo, que se pretende estudar. Este poderá 1 baseia a sua avaliação na simulação de redes de Petri 31

33 Figura 3.1: Passos principais da metodologia de avaliação de process mining, apresentada neste trabalho. assumir os mais variados formatos, dependendo do sistema de informação que o produz, sendo, por isso, fundamental a sua normalização. No contexto deste trabalho, optou-se pela utilização de um formato simples (em TXT ), contendo apenas as sequências de actividades, de forma a facilitar a criação e adaptação de logs de eventos. Daí que o conversor implementado apenas suporta este tipo de ficheiros de entrada. No entanto, este passo poderia ser complementado com a ferramenta ProM Import, que permite a normalização de logs de formatos mais utilizados (e.g. logs do sistema SAP) para MXML [17]. O ficheiro de entrada irá, então, ser constituído por duas partes distintas. Na primeira parte é feito 32

34 Figura 3.2: Exemplo do formato de um log de eventos de entrada. Na primeira parte é feito mapeamento entre os nomes das actividades e respectiva letra. Na segunda parte encontram-se, por cada linha, as sequências de actividades com respectivos números de ocorrência. o mapeamento entre actividades e as respectivas letras. A segunda parte contém, em cada linha, sequências de letras e a respectiva frequência, com que esta ocorre. A razão para a utilização de sequências de letras, em vez de utilizar directamente os nomes das respectivas actividades, é a de facilitar a realização da avaliação (4 o passo), que se baseia na comparação de strings - a legendagem vai apenas permitir que os modelos sejam gerados com os nomes correctos (2 o passo), permitindo assim uma melhor interpretação. Como alternativa à utilização do formato apresentado, pode ser inserido como entrada directamente um log MXML, situação em que este primeiro passo não é realizado. 2 o Passo - Aplicação de Mining Após normalizar-se o log de entrada, para MXML, dá-se inicio ao 2 o passo. É nesta fase que as técnicas de mining serão aplicadas, de forma a descobrir-se o modelo que melhor represente o log. Como já foi referido, um dos requisitos fundamentais da metodologia de avaliação é que esta consiga suportar o maior número de técnicas de mining. Como tal, este módulo foi realizado de forma a suportar facilmente a inclusão daquilo a que se chamou Interface de mining. Assim, para cada algoritmo deverá ser implementado uma interface que, recebendo um MXML, aplique a técnica respectiva e produza como saída um modelo. Este modelo deverá possuir um formato que seja suportado pelo passo seguinte, de forma a poder ser simulado. Pretende-se assim que a complexidade da normalização, dos modelos descobertos, seja feita dentro de cada interface, mantendo assim a metodologia genérica. Neste trabalho optou-se por testar cinco algoritmos de mining, introduzidos na Secção 2.1, implementando uma interface para cada. Na Secção serão introduzidos alguns detalhes de implementação de cada uma das cinco interfaces. 33

35 Figura 3.3: Exemplo de um log de eventos, ilustrando um processo de obtenção de licença de condução, no formato MXML [1]. 34

36 3 o Passo - Simulação de Modelos Como já foi mencionado, é essencial para uma metodologia de avaliação, baseada em simulação, suportar os tipos de modelos utilizados pelos algoritmos que se pretende estudar. Para tal, o módulo de simulação foi desenvolvido de modo a ser estendido com sub-módulos - um por cada tipo de modelo que se pretende simular. Assim, de acordo com o algoritmo que se pretende avaliar, o respectivo sub-módulo de simulação será seleccionado em detrimento dos restantes (e.g. se o algoritmo escolhido for o heurístico então será utilizado o sub-módulo de simulação de redes heurísticas). Uma vez que, neste trabalho, se decidiu suportar cinco algoritmos de minging, foram desenvolvidos dois sub-módulos correspondentes aos tipos de modelos em que estes assentam: redes de Petri e redes heurísticas. Na Secção serão introduzidos alguns detalhes sobre a implementação destes dois sub-módulos. 4 o Passo - Avaliação Probabilística Uma das principais motivações deste trabalho consistia em provar que era viável efectuar a conformidade de modelos, através da comparação directa de logs de evento (o original e o gerado através do 3 o passo de simulação). Daí que o módulo de avaliação tenha sido idealizado de forma a suportar, especificamente, esse tipo de avaliação. O módulo deverá então receber dois logs contendo apenas as respectivas sequências de actividades, produzindo, a partir daí, o valor probabilístico correspondente ao grau de semelhança entre estes. O resultado é obtido através da aplicação de métricas de avaliação, que implementam diferentes abordagens de comparação. O objectivo, uma vez mais, é que a metodologia de avaliação possa ser estendida com novas métricas de comparação de logs. No contexto deste trabalho, foram desenvolvidas duas métricas que serão introduzidas na Secção 3.2. Sendo o resultado obtido por métodos de natureza probabilística, é importante ter em consideração a existência de uma margem de erro. Desta forma, definiu-se um intervalo de resultados, que permita mapear os resultados possíveis, em termos de graus de semelhança (ver Tabela 3.1). É importante ter em consideração que, apesar da classificação definida se adequar a grande parte das situações, é possível que, nalgumas situações, tal não aconteça. Daí a importância de verificar sempre os resultados, encarando esta medida como um auxílio importante à avaliação de process mining e não como um resultado absoluto Aspectos gerais de implementação Antes de entrar em detalhes, sobre o processo de desenvolvimento da metodologia de avaliação, importa introduzir alguns aspectos básicos, a começar pela escolha do ambiente de desenvolvimento ferramenta ProM [16]. Como já foi introduzido, o ProM é uma aplicação que resulta de um projecto académico, open-source, desenvolvido em linguagem Java. Este tem sido expandido com várias técnicas 35

37 Significado Resultado 0% - 20% É provável que não exista relação entre logs de eventos 21% - 40% É provável que os logs de eventos sejam bastante diferentes 41% - 60% É provável que os logs de eventos contenham algumas semelhanças 61% - 80% É provável que os logs de eventos sejam semelhantes 81% - 100% É provável que os logs de eventos sejam iguais Tabela 3.1: Intervalo de resultados possíveis, de serem produzidos pela metodologia de avaliação, e respectivo significado. Figura 3.4: Estrutura segundo a qual se encontra organizada a metodologia de avaliação, desenvolvida no âmbito deste trabalho. de mining e clustering, sendo neste momento a ferramenta mais completa na área de process mining. Foi sobretudo esse o motivo que condicionou a escolha de enquadrar o desenvolvimento da metodologia de avaliação na ferramenta ProM, dado suportar as técnicas de mining que nos propusemos estudar. Esta ferramenta garante ainda algumas funcionalidades auxiliares importantes, como por exemplo, exportação e importação de modelos. Desta forma, a Metodologia de Avaliação foi desenvolvida como uma extensão ao ProM, no mesmo pacote onde se inserem todas as extensões, quer de mining como de análise, tendo a estrutura apresentada na Figura 3.4. Na raiz (evaluation) encontram-se as duas metodologias - uma de avaliação de algoritmos de mining e outra para análise de conformidade de processos. A directoria metrics destina-se às diferentes métricas apresentadas neste trabalho. Por último, a directoria util destina-se a todas as funcionalidades que se podem considerar acessórias, i.e., conversores de MXML e PNML, simuladores de modelos e as diferentes interfaces de mining (este conceito será introduzido na Secção 3.1.3). Apesar da ferramenta ProM ser baseada em interface gráfica, o trabalho realizado pretendeu sobretudo estudar a viabilidade de análise de algoritmos de mining, através da comparação de logs de eventos (originais e simulados). Daí que se tenha optado por não desenvolver interface gráfica, sendo toda a interacção, com a metodologia, realizada através de linha de comandos. Assim sendo, ao executar a metodologia é necessário introduzir um ficheiro de parâmetros, que permitirão a configuração de aspectos gerais, tais como: 36

38 logfiletxtpath: a localização raiz, a partir da qual a metodologia deverá procurar os modelos ou padrões que se pretende avaliar; pattern: o nome do modelo/padrão que se pretende avaliar; numsimulation: o número de vezes que deve ser realizada a simulação do modelo, i.e., o número de sequências de eventos que se pretendem gerar, através da simulação do modelo; simulationthreshold: o valor limite, em que cada simulação deve parar, para impedir casos em que esta possa entrar em ciclos infinitos; metric: o número da métrica a avaliar (1 - Métrica Naive; 2 - Métrica de Avaliação Aproximada; algorithm: qual o número correspondente ao algoritmo a avaliar (1 - Algoritmo α; 2 - Algoritmo α ++ ; 3 - Algoritmo Heurístico; 4 - DWS; 5 - Algoritmo Genético); LevTreshold: em caso de se utilizar métricas de avaliação aproximada, é necessário definir um limite que indique para que valores dos algoritmos de distâncias, duas sequências devem, ou não, ser consideradas similares Implementação das Interfaces de Mining De seguida, serão apresentadas os principais detalhes de implementação inerentes ao desenvolvimento de cada uma das cinco Interfaces de mining. Implementação das Interfaces para os algoritmos α e α ++ Tanto o algoritmo α como α ++ assentam em redes de Petri, pelo que a sua implementação acabou por ser bastante similar, na medida em que recebem exactamente o mesmo tipo de entrada e produzem o mesmo tipo de saída. Deste modo, após o carregamento do log MXML para o ProM, é feita a invocação do respectivo algoritmo. Como saída, de ambas as interfaces, será produzido um ficheiro no formato PNML 3 [31] - este ficheiro é obtido através de um exportador de redes de Petri em formato PNML. Implementação da Interface para o algoritmo Heurístico O algoritmo heurístico assenta em redes heurísticas e, tal como os restantes algoritmos, recebe como entrada um log MXML. Assim, após o carregamento do log para o ProM, será feita invocação da classe responsável por executar o algoritmo em heurístico. Foi na definição da saída desta interface, onde esteve o maior problema (como aliás aconteceu com o algoritmo DWS e Genético que também assentam em redes heurísticas). Apesar de também existir um exportador de redes heurísticas implementado no ProM, este apenas permite exportar parcialmente o modelo, perdendo-se, assim, alguma informação fundamental. Ou seja, obtém-se a respectiva matriz causal, que permite fazer o mapeamento de 2 Para valores inferiores ou iguais ao limite estabelecido, as sequências são consideradas similares. 3 PNML significa Petri Net Markup Language e é uma variante de XML, aplicada ao contexto de redes de Petri. 37

39 transições entre actividades sem, no entanto, referir o peso probabilístico associado a cada transição, perdendo-se uma mais valia deste tipo de modelos. Foi, por isso, necessário estudar as estruturas das classes que implementam o algoritmo heurístico, de forma a detectar como eram armazenados as probabilidades associadas a cada transição. Esses valores são armazenados numa matriz (ver Figura 3.6) de dimensões n n, sendo n o número de actividades. Em cada posição da matriz causal, encontra-se a probabilidade de existir uma transição entre as actividades correspondentes à posição da matriz. Com base nesta informação é possível construir a estrutura de dados, própria para redes heurísticas, que permitirá a sua simulação (esta estrutura será introduzida na Secção dedicada à simulação de redes heurísticas). Na Figura 3.5 é apresentado um exemplo de uma rede Heurística, representando um padrão AND, estando a respectiva matriz de transições na Figura 3.6. A B C D A 0 0,65 0,35 0 B 0 0 0,65 0,35 C 0 0,35 0 0,65 D Figura 3.5: Exemplo de um padrão AND no formato de rede Heurística. Figura 3.6: Matriz Causal correspondente à rede Heurística representada. Implementação da Interface para o algoritmo DWS Sendo o DWS baseado no algoritmo heurístico (como foi referido na Secção 2.3.4) e produzindo também, como saída, uma rede heurística, a implementação da sua interface apenas se diferenciou num pormenor. Uma vez que este algoritmo recorre a técnicas de clustering, de modo a separar diferentes padrões comportamentais, irá produzir como saída n+1 modelos, sendo n o número de clusters que o algoritmo conseguir descobrir. É ainda devolvido o modelo global, onde são representados os comportamentos de todos os clusters descobertos - corresponde ao comportamento global. Neste caso, embora fosse possível escolher todos os modelos, correspondentes a cada cluster e simulá-los separadamente, isso iria aumentar significativamente a complexidade do 3 o passo. Daí que se tenha optado por se basear a análise ao algoritmo DWS apenas no seu modelo raiz. Desta forma, apenas será extraída a matriz de transições correspondente ao modelo global, sendo convertida na estrutura de dados que permitirá a sua simulação, no passo seguinte. Implementação da Interface para o algoritmo Genético Também o algoritmo genético assenta em redes heurísticas, pelo que a sua interface não variará muito, quando comparado com os algoritmos heurístico e DWS. A diferença está, uma vez mais, na escolha 38

40 do modelo a devolver. Sendo o algoritmo genético baseado na criação e filtragem de gerações, importa, no final, escolher a melhor geração, i.e., aquela que possui maior valor de fitness (ver Secção 2.3.5). A geração com melhor fitness terá, consequentemente, a melhor representação do modelo resultante da aplicação do algoritmo Simulação de Modelos Nesta secção serão relatados os principais detalhes de implementação, inerentes ao desenvolvimento dos módulos de simulação de redes de Petri e de redes heurísticas, nas secções e 3.1.4, respectivamente. Simulação de Redes de Petri O desenvolvimento do módulo de simulação de redes de Petri foi feito de acordo com as suas especificações. Uma rede de Petri é uma estrutura dinâmica que consiste num conjunto de transições, representados por quadrados, que correspondem a actividades da rede que podem ser executados, num conjunto de places, representados por círculos que podem conter tokens (pontos negros) e um conjunto de arcos direccionados que ligam as transições e os places, entre si. As transições são activas quando todos os seus places de entrada (i.e. os que lhe antecedem directamente) contêm, pelo menos, um token. Quando uma transição é activa, diz-se que esta é disparada, sendo-lhe retirado um token de cada um dos places de entrada e colocados nos seus places de saída. Desta forma, cada vez que uma transição é disparada, o estado da rede será alterado, representando a evolução de um determinado processo. Desta forma, como entrada deste sub-módulo, é recebido um ficheiro em formato PNML, produzido pelas interfaces de mining. O formato PNML contém informação sobre as actividades, places e transições existentes na respectiva rede de Petri, assim como a informação gráfica (e.g. posições de cada objecto) que permita a um interpretador desenhá-la. É com base nesta informação que o simulador de redes de Petri irá carregar os dados necessários para executar a simulação do modelo. Figura 3.7: Estrutura interna definida para as Redes de Petri, que permite executar a sua simulação. 39

41 Tendo como base o ficheiro PNML, será filtrada apenas a informação relevante (actividades, places e transições) e armazenada numa estrutura interna que permita executar a simulação, representada na Figura 3.7. Existe a classe central (PetriNet) que conhece a estrutura toda da rede, i.e., contém a lista de todos os Places e Transitions, incluindo qual o place de entrada e de saída, que lhe permita saber onde começar a simulação da rede e quando acabar. É também esta classe que contém os métodos de simulação da rede. Cada Place apenas conhece as transacções que as antecedem e que as seguem e o número de tokens que possui, a determinado momento. Neste trabalho apenas se considerou redes de Petri com um único place de entrada e outro de saída Por último, cada Transition conhece os places que os antecedem e que os seguem, tendo associado ainda uma etiqueta, que permite gerar a cadeia de actividades, aquando da simulação da rede. Inicialmente planeou-se também a utilização das redes de Petri na simulação de modelos resultantes de algoritmos que assentam em redes heurísticas, uma vez que a ferramenta ProM permite a conversão entre estes dois formatos. No entanto, após realizar algumas experiências, constatou-se que os resultados da avaliação dos algoritmos que utilizam redes heurísticas eram penalizados pelo facto das redes de Petri não considerarem o factor probabilístico, entre transições. Daí que se tenha optado por desenvolver um simulador próprio para as redes heurísticas, introduzido na secção seguinte. Simulação de Redes Heurísticas As redes heurísticas são constituídas por um conjunto de actividades, interligadas por transições. Cada transição contém um valor probabilístico associado, que representa a frequência com que esta ocorre, e uma actividade destino. Por seu lado, cada actividade contém uma etiqueta que a descreve e uma lista de transições possíveis (no total a soma das probabilidades associadas às transições de uma tarefa tem que dar 100%). Importa referir que, ao contrário do que sucedia nas redes de Petri em que as transições correspondiam aos quadrados (equivalente às actividades), nas redes heurísticas, estas representam os arcos de ligação. Para suportar a lógica das redes heurísticas, definiu-se a estrutura ilustrada na Figura 3.8 e que contém uma classe central (HeuristicNet). É esta classe que conhece o contexto global da rede, i.e., todas as tarefas e transições que a constituem, assim como quais as tarefas onde a rede começa e termina, que lhe permite simular a rede. Apesar das redes heurísticas não serem tão estruturadas, quando comparadas com as redes de Petri, dado não representarem de forma tão rigorosa alguns padrões comuns (e.g. AND e Or), como são um modelo de natureza probabilístico deverão produzir, tendencialmente, comportamento correcto, para um número considerável de execuções. 40

42 Figura 3.8: Estrutura interna definida para as redes hheurísticas, que permite executar a sua simulação. 3.2 Métricas de Avaliação Como foi enunciado na Secção 1.2, um dos objectivos deste trabalho consistia no desenvolvimento de métricas de avaliação baseada na comparação entre dois logs, contendo apenas as respectivas sequências de actividades. Esta abordagem já havia sido proposta em [15], onde foi provada a maior eficiência deste tipo de análise (entre logs), quando comparada com uma análise realizada entre modelos. Entre os problemas apontados destacam-se o facto de não ser possível detectar pontos de escolha (AND/XOR) e o de dois modelos muito semelhantes poderem produzir comportamentos completamente diferentes. Por norma um log de evento encontra-se em MXML, um formato standard definido especificamente para área process mining, que pode ser utilizado na ferramenta ProM. Este formato pode conter informação tão relevante como quais as actividades executadas e quem as executou, entre outro tipo de dados. Dado estarmos interessados em analisar o log, segundo uma perspectiva processual, apenas será relevante analisar quais as actividades executadas, e por que ordem sucederam. Para tal, recorre-se a um formato simplificado que contenha apenas sequências de letras, onde cada letra corresponde a uma actividade específica e cada linha a uma instância de execução do processo analisado 4. Figura 3.9: Exemplo do formato dos logs de eventos, utilizados no módulo de avaliação (4 o passo). Cada letra corresponde a uma actividade específica e cada linha a uma instância de execução do processo a ser analisado. 4 Quando no 3 o passo, é gerado um log resultante da simulação do modelo minado estará neste formato. 41