- 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
- 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
Designing an event log
Ao configurar as transformações para Process Mining, é importante ter um bom entendimento do processo. O primeiro passo é definir os eventos que ocorrem e as entidades nas 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.
Abaixo está um exemplo de log de eventos para o processo de 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 melhor prática é usar o formato Verb Noun, como Create document. Consulte a tabela abaixo para obter alguns conselhos sobre a nomenclatura de 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 uma ou mais entidades no processo. Use o conjunto de eventos desejados para determinar quais entidades são necessárias para um processo de negócios. Abaixo está um exemplo de um conjunto de eventos e suas entidades correspondentes.
purchase_order_type
e uma entidade de fatura pode ter um payment_due_date
.
O número de entidades que são de interesse em um processo varia de acordo com a complexidade do processo. Em alguns processos pode ser necessária apenas uma entidade, como o ticket em um processo de Gerenciamento de Incidentes.
Em processos mais complexos, várias entidades 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árias entidades. Para criar um log de eventos para tais processos, as relações entre as entidades devem ser definidas. Consulte a ilustração abaixo para obter um exemplo de diagrama de relacionamento Entidades de compra para pagamento.
O log de eventos descreve o processo de ponta a ponta cobrindo os eventos de todas as entidades combinadas. Apenas uma entidade no processo pode funcionar como a entidade principal que será rastreada ao longo do processo. Esta entidade principal é chamada de “Case” no processo, identificada por seu “Case ID”.