- Notas de versão
- Antes de começar
- Introdução
- Integrações
- Como trabalhar com aplicativos de processo
- Como trabalhar com painéis e gráficos
- Como trabalhar com gráficos de processo
- Trabalhando com Descubra modelos de processo e Importar modelos BPMN
- Showing or hiding the menu
- Informações de contexto
- Exportar
- Filtros
- Envio de ideias de automação ao UiPath® Automation Hub
- Tags
- Datas de conclusão
- Comparar
- Verificação de conformidade
- Análise de causa raiz
- Simulação de Potencial de Automação
- Triggering an automation from a process app
- Exibição de dados do processo
- Criação de aplicativos
- Carregamento de dados
- Personalização de aplicativos de processo
- Introdução aos painéis
- Como trabalhar com o editor de painel
- Criação de painéis
- Painéis
- Gerenciador de automação
- Definição de novas tabelas de entrada
- Adicionando campos
- Adição de tabelas
- Requisitos do modelo de dados
- Exibição e edição do modelo de dados
- Exportando e importando transformações
- Visualizando o log de transformações
- Edição e teste de transformações de dados
- Structure of transformations
- Tips for writing SQL
- Mesclando logs de evento
- Gerenciador de processos
- Modelos de apps
- Recursos adicionais
- Tags prontas para uso e datas de vencimento
- Edição de transformações de dados em um ambiente local
- Setting up a local test environment
- Designing an event log
- Estendendo a ferramenta de extração SAP Ariba
- Recursos de desempenho

Process Mining
Designing an event log
Ao configurar as transformações para o Process Mining, é importante ter uma boa compreensão do processo. A primeira etapa é definir os eventos que ocorrem e os objetos nos quais esses eventos ocorrem.
Comece definindo as atividades de alto valor. Priorize a adição de atividades com base na frequência com que ocorrem e no quão significativas são para o usuário final. A definição das atividades deve ser um processo iterativo.
A ilustração a seguir mostra um exemplo de um log de evento para o processo Faturas.
O número ideal de atividades para descrever um processo é entre 10 e 20. Embora mais atividades levem a mais possibilidades de análise, também levam a mais variações de processo e maior complexidade.
Número de atividades |
Resultado |
---|---|
<10 |
Baixa complexidade de análise, baixo número de melhorias potenciais. |
10-20 |
Equilíbrio ideal da complexidade de análise e potenciais melhorias |
20 |
Alta complexidade de análise, alto número de pequenas melhorias. |
Convenções de Nomes
Para nomes de atividades, a prática recomendada é usar o formato Nome do verbo, como Criar documento. A tabela a seguir contém algumas recomendações sobre a nomenclatura das atividades.
Nome da Atividade |
Conselho |
Melhores práticas |
---|---|---|
Ordem Ordem |
Evite nomes de atividade ambíguos. |
Pedir material |
Tíquete |
Evite nomes simples para atividades - declare o que aconteceu com o quê. |
Criar tíquete |
Documento cancelado |
Evite a voz passiva. |
Cancelar documento |
Aprovar verificação de controle de crédito na ordem de venda |
Evite nomes de atividade muito longos |
Aprovar verificação de crédito de ordem de venda |
Os eventos ocorrem em um ou mais objetos no processo. Use o conjunto de eventos desejados para determinar quais objetos são necessários para um processo de negócios. A tabela a seguir mostra um exemplo de um conjunto de eventos e seus objetos correspondentes.
Evento |
Object |
Criar ordem de compra |
Ordem de compra |
Aprovar ordem de compra |
Ordem de compra |
Criar fatura |
Fatura |
Alterar condições de pagamento |
Fatura |
purchase_order_type
, e um objeto de fatura pode ter um payment_due_date
.
O número de objetos que são de interesse em um processo varia dependendo da complexidade do processo. Em alguns processos, apenas um objeto pode ser necessário, como o ticket em um processo de Gerenciamento de Incidentes.
Em processos mais complexos, vários objetos podem ser de interesse. Por exemplo, um processo Purchase-to-Pay, que começa com a compra de um produto até o pagamento de uma fatura, abrange um conjunto de eventos relacionados a vários objetos. Para criar um log de evento para esses processos, as relações entre os objetos devem ser definidas. A ilustração a seguir mostra um exemplo de objetos Purchase-to-Pay de diagrama de relacionamento.
O log de evento descreve o processo fim a fim abrangendo os eventos de todos os objetos combinados. Apenas um objeto no processo pode funcionar como o objeto principal que será rastreado durante todo o processo. Esse objeto principal é nomeado como “Caso” no processo, identificado por seu “ID do caso”.