- Notas de versão
- Antes de começar
- Introdução
- Gerenciamento de acesso
- Como trabalhar com aplicativos de processo
- Criação de apps de processo
- Carregamento de dados
- Carregamento de dados
- Retrieving the SQL Server database parameters
- Configuração de uma conta do SQL Server para upload de dados usando um extrator
- Loading data using Theobald Xtract Universal
- Requisitos do Sistema
- Configuração do DataBridgeAgent
- Configuring CData Sync
- Adição de um conector personalizado ao DataBridgeAgent
- Uso do DataBridgeAgent com o Conector SAP para o Acelerador de Descoberta Purchase-to-Pay
- Uso do DataBridgeAgent com o Conector SAP para o Acelerador de Descoberta Order-to-Cash
- Personalização de aplicativos de processo
- Transformações de dados
- ModeloUm modelo de aplicativo
- Modelo de aplicativo Purchase-to-Pay
- Modelo de aplicativo Order to Cash
- Basic troubleshooting guide
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”.