Como criar um Event Log para Process Mining

Para começar no Process Mining, você precisa de uma tabela com as atividades, cada uma com data e hora, agrupadas por ID do caso. Neste guia, você vai montar essa tabela com dados do sistema, usando como exemplo um processo fictício de pedidos de restaurante. Veja duas formas de fazer isso: com algumas linhas no Excel ou com uma consulta SQL que reúne as atividades com UNION ALL. Compare seu resultado com o Event Log de exemplo pronto ao longo do caminho.

Event Log para Process Mining: as três colunas necessárias

Um Event Log é um registro estruturado do que aconteceu em um processo. Cada linha representa um evento, como um pedido feito ou um pagamento recebido. O ID do caso conecta os eventos relacionados, o registro de data e hora indica quando cada evento ocorreu e, juntos, esses dados permitem que uma ferramenta reconstrua como os casos percorrem o processo.

Atividade é um tipo; evento é uma ocorrência. Uma atividade é um tipo de ação, como “Pedido enviado”. Um evento é uma ocorrência específica dessa ação: o pedido 12345 foi enviado às 14h30 do dia 15 de janeiro. Seu Event Log registra eventos, e cada evento tem um nome de atividade. As pessoas costumam usar os dois termos como sinônimos, mas essa diferença importa na preparação dos dados: a atividade indica o que aconteceu, enquanto o evento registra que isso aconteceu com determinado caso, em determinado momento.

Um Event Log básico para Process Mining precisa de três colunas:

Antes de avançar, confira estes três campos:

Esses três campos são a base. Se algum estiver ausente ou inconsistente, a visualização do processo vai representar a sequência de trabalho de forma incorreta. Todo o resto é opcional: um Event Log que as ferramentas de Process Mining conseguem ler sempre consiste em uma tabela de casos e eventos, e as três colunas necessárias para usar um Event Log em Process Mining não mudam. Para conhecer os formatos aceitos e as etapas de preparação, consulte a documentação de dados para Process Mining.

Exemplo prático: o sistema de pedidos da Pizza Palace

Para deixar as etapas mais concretas, vamos usar um restaurante fictício chamado Pizza Palace. Os clientes fazem pedidos online, a equipe prepara a comida e os entregadores fazem as entregas. O exemplo não contém dados de clientes.

Imagine que o sistema armazene informações nestas tabelas:

• orders: ID do pedido, cliente e horário do pedido
• order_items: pizzas, acompanhamentos e bebidas de cada pedido
• kitchen_queue: quando um pedido entra e sai da cozinha
• delivery_assignments: atribuições de entregadores e acompanhamento das entregas
• payments: registros de processamento de pagamentos

O objetivo é criar um Event Log que acompanhe cada pedido, desde o envio até a entrega. O ID do pedido será o ID do caso. Cada ação e registro de data e hora relevante vai gerar uma linha. Baixe o Event Log de exemplo da Pizza Palace e compare as colunas com as da sua extração.

Defina quais atividades incluir antes de extrair os dados. Na Pizza Palace, o pedido passa por seis etapas:

1. Pedido feito: o cliente envia o pedido.
2. Pagamento recebido: o pagamento é processado com sucesso.
3. Pedido enviado à cozinha: o pedido entra na fila de preparo.
4. Pedido pronto: a cozinha marca o pedido como concluído.
5. Entregador atribuído: um entregador é designado.
6. Entrega concluída: o pedido é entregue.

Para cada atividade, identifique a tabela de origem, o campo de registro de data e hora e o campo do ID do caso. Confirme se o ID do caso vincula o evento ao pedido certo.

Separe os eventos diretos dos inferidos. Um evento direto tem um registro explícito e um registro de data e hora no sistema de origem: Pedido feito vem do horário registrado na orders, Pagamento recebido vem de payments e Entrega concluída vem de delivery_assignments. Em geral, é simples extrair esses eventos, desde que o registro de data e hora represente o evento que você quer analisar.

Um evento inferido não tem um registro próprio, então você deduz o horário a partir de outro campo. Entregador atribuído pode existir apenas como horário de criação da atribuição de entrega, e Pedido pronto pode corresponder apenas ao momento em que o status da fila da cozinha mudou para “concluído”. Eventos inferidos podem ser úteis, mas documente como você chegou a eles: uma mudança de status ou o horário de criação de um registro pode não significar exatamente o que o nome da atividade sugere. Antes de tratar esse valor como registro de data e hora do evento, confirme o significado do campo com quem conhece o sistema de origem.

Esse mapeamento é um plano, não uma confirmação de que todos os campos são adequados. Confira se os registros de data e hora estão preenchidos e se cada tabela pode ser vinculada ao ID do pedido sem gerar linhas duplicadas.

Atributos de caso e de evento

Os atributos dão contexto à análise. São as colunas além de ID do caso, registro de data e hora e atividade. Só vale a pena incluí-los quando têm um significado claro e podem ser vinculados ao caso ou evento correto.

Os atributos do caso descrevem o caso inteiro e, em geral, permanecem iguais em todos os eventos: nome do cliente, valor total do pedido, endereço de entrega e quantidade de itens pedidos. Em um Event Log plano, o valor se repete em cada linha daquele caso. Isso permite filtrar ou comparar eventos usando informações do caso mais tarde.

Os atributos do evento descrevem um único evento: o entregador em um evento de entrega, o método de pagamento em um evento de pagamento e a estação da cozinha em um evento da cozinha. Como uma coluna desse tipo não se aplica a todas as linhas, deixe em branco onde não se aplicar e mantenha a coluna na tabela para que todas as linhas tenham a mesma estrutura.

O Event Log final deve ser uma única tabela plana, com um evento por linha. Veja o Event Log da Pizza Palace:

O cliente e o valor do pedido se repetem em cada evento do mesmo caso. Isso é intencional: mantém o Event Log em uma tabela simples, que as ferramentas de Process Mining conseguem ler.

Método 1: crie o Event Log no Excel

O Excel funciona bem para uma extração pequena ou um primeiro exercício. Exporte cada tipo de evento, padronize as colunas e reúna as linhas em uma única planilha. As cinco etapas abaixo levam cerca de uma hora com os dados da Pizza Palace.

Etapa 1: exporte cada tipo de evento para uma planilha separada. Crie uma planilha para cada tipo de atividade. Por exemplo:

Planilha 1: Pedido feito

Planilha 2: Pagamento recebido

Crie outras planilhas para os eventos da cozinha e da entrega, seguindo o mesmo método.

Etapa 2: padronize as colunas. Use os mesmos nomes e a mesma ordem de colunas em todas as planilhas. Quando um atributo não se aplicar, inclua uma coluna em branco. Por exemplo, a planilha Pedido feito pode incluir todas as colunas:

Confira se os valores usam formatos compatíveis. Em especial, verifique se os registros de data e hora estão armazenados como datas e horários, e não como texto que apenas parece um registro de data e hora.

Etapa 3: combine as planilhas. Crie uma nova planilha chamada Event Log e copie para ela as linhas de eventos de cada planilha de atividades. Mantenha uma única linha de cabeçalho e um evento por linha.

Etapa 4: ordene por caso e registro de data e hora. Ordene os dados combinados primeiro pelo ID do caso, em ordem crescente, e depois pelo registro de data e hora, também em ordem crescente. Isso facilita a revisão da sequência de cada caso. A ordenação não corrige registros de data e hora incorretos. Antes de confiar na ordem, confira eventos com horários iguais ou inesperados.

Etapa 5: exporte para CSV. Salve a planilha combinada como um Event Log CSV para Process Mining que sua ferramenta consiga ler. Abra o arquivo exportado para conferir se os cabeçalhos, delimitadores, formatos de data e valores em branco estão como esperado.

Dicas para Excel:

• Use VLOOKUP ou XLOOKUP para incluir atributos do caso, como o nome do cliente, a partir da planilha de pedidos.
• Use um formato único para data e hora, como YYYY-MM-DD HH:MM:SS.
• Confira se há linhas duplicadas antes de exportar.
• Guarde uma cópia sem alterações das extrações originais para rastrear eventuais correções.

Método 2: crie o Event Log com SQL

Vale a pena usar SQL quando os dados estão em um banco de dados, a extração é grande ou você precisa repetir o processo no mês seguinte. Em geral, a estrutura consiste em um SELECT por atividade, reunidos com UNION ALL.

Como funciona UNION ALL. Ele reúne as linhas retornadas por várias instruções SELECT. Cada instrução deve retornar o mesmo número de colunas, na mesma ordem e com tipos de dados compatíveis. Use também um conjunto consistente de aliases para dar nomes claros às colunas finais.

A consulta. O exemplo abaixo usa as tabelas fictícias da Pizza Palace. Antes de adaptá-lo, confira os nomes das tabelas e dos campos, o significado dos registros de data e hora e o dialeto SQL do seu sistema.

-- Event Log Extraction for Pizza Palace
-- This query combines multiple event types into a single event log
-- Each SELECT block represents one activity type

-- Event 1: Order Placed
-- Source: orders table
-- This captures when customers submit their orders
SELECT 
    o.id AS case_id,                          -- The order ID is our case identifier
    o.created_at AS timestamp,                -- When the order was placed
    'Order Placed' AS activity,               -- The activity name (hardcoded)
    o.customer_name AS customer,              -- Case attribute: who ordered
    o.total_amount AS order_value,            -- Case attribute: order value
    NULL AS driver,                           -- Not applicable for this event
    NULL AS payment_method                    -- Not applicable for this event
FROM orders o
WHERE o.created_at >= '2025-01-01'            -- Filter to your desired date range

UNION ALL

-- Event 2: Payment Received
-- Source: payments table
-- This captures successful payment processing
SELECT 
    p.order_id AS case_id,
    p.payment_time AS timestamp,
    'Payment Received' AS activity,
    o.customer_name AS customer,              -- Join to get case attributes
    o.total_amount AS order_value,
    NULL AS driver,
    p.payment_method AS payment_method        -- Event-specific attribute
FROM payments p
JOIN orders o ON p.order_id = o.id            -- Join to get order details
WHERE p.payment_time >= '2025-01-01'
  AND p.status = 'successful'                 -- Only include successful payments

UNION ALL

-- Event 3: Order Sent to Kitchen
-- Source: kitchen_queue table
-- This captures when the kitchen starts working on the order
SELECT 
    k.order_id AS case_id,
    k.queue_entry_time AS timestamp,
    'Order Sent to Kitchen' AS activity,
    o.customer_name AS customer,
    o.total_amount AS order_value,
    NULL AS driver,
    NULL AS payment_method
FROM kitchen_queue k
JOIN orders o ON k.order_id = o.id
WHERE k.queue_entry_time >= '2025-01-01'

UNION ALL

-- Event 4: Order Ready
-- Source: kitchen_queue table (different timestamp field)
-- This is an inferred event based on when the kitchen marked it complete
SELECT 
    k.order_id AS case_id,
    k.completed_time AS timestamp,            -- Different timestamp than entry
    'Order Ready' AS activity,
    o.customer_name AS customer,
    o.total_amount AS order_value,
    NULL AS driver,
    NULL AS payment_method
FROM kitchen_queue k
JOIN orders o ON k.order_id = o.id
WHERE k.completed_time >= '2025-01-01'
  AND k.completed_time IS NOT NULL            -- Only include completed orders

UNION ALL

-- Event 5: Assigned to Driver
-- Source: delivery_assignments table
-- This captures when a driver is assigned to deliver the order
SELECT 
    d.order_id AS case_id,
    d.assigned_at AS timestamp,
    'Assigned to Driver' AS activity,
    o.customer_name AS customer,
    o.total_amount AS order_value,
    d.driver_name AS driver,                  -- Event-specific attribute
    NULL AS payment_method
FROM delivery_assignments d
JOIN orders o ON d.order_id = o.id
WHERE d.assigned_at >= '2025-01-01'

UNION ALL

-- Event 6: Delivery Completed
-- Source: delivery_assignments table (different timestamp field)
-- This captures when the order was delivered to the customer
SELECT 
    d.order_id AS case_id,
    d.delivered_at AS timestamp,
    'Delivery Completed' AS activity,
    o.customer_name AS customer,
    o.total_amount AS order_value,
    d.driver_name AS driver,
    NULL AS payment_method
FROM delivery_assignments d
JOIN orders o ON d.order_id = o.id
WHERE d.delivered_at >= '2025-01-01'
  AND d.delivered_at IS NOT NULL              -- Only include completed deliveries

-- Final ordering: by case, then by time
-- This makes the event log easy to read and follow
ORDER BY case_id, timestamp;

A consulta usa o ID do pedido como ID do caso e retorna as mesmas sete colunas para cada atividade. Os valores NULL mantêm a estrutura das colunas quando um atributo não se aplica. O filtro de data e a condição de pagamento aprovado são exemplos: escolha filtros adequados ao processo e ao período que você quer analisar.

Como ampliar a consulta. Para incluir outra atividade:

1. Copie um bloco SELECT para usar como ponto de partida.
2. Use a tabela de origem que registra o evento.
3. Selecione o campo que representa o registro de data e hora do evento.
4. Defina um nome de atividade consistente com as outras linhas.
5. Inclua o ID do caso e os atributos relevantes.
6. Adicione filtros adequados à sua análise.

Por exemplo, você pode incluir uma tentativa de entrega desta forma, se o sistema tiver a tabela e os campos necessários:

UNION ALL

-- Event 7: Delivery Attempted
-- Add this to track failed delivery attempts
SELECT 
    d.order_id AS case_id,
    d.attempt_time AS timestamp,
    'Delivery Attempted' AS activity,
    o.customer_name AS customer,
    o.total_amount AS order_value,
    d.driver_name AS driver,
    NULL AS payment_method
FROM delivery_attempts d
JOIN orders o ON d.order_id = o.id
WHERE d.attempt_time >= '2025-01-01'

Verificações antes de analisar o Event Log

Faça estas verificações antes de analisar o Event Log. Juntas, elas cobrem os problemas mais comuns que distorcem os resultados do Process Mining: eventos duplicados, registros de data e hora ausentes, IDs de caso instáveis e campos de status confundidos com atividades.

1. Comece pelas colunas obrigatórias. Crie um Event Log pequeno com ID do caso, registro de data e hora e atividade antes de incluir mais eventos ou atributos.
2. Use IDs de caso estáveis. Todos os eventos do mesmo caso devem usar o mesmo identificador. Não use um valor que mude durante o processo.
3. Mantenha os nomes das atividades consistentes. Escolha um único nome, como “Pedido feito”, em vez de alterná-lo com “Pedido criado” e “Novo pedido”.
4. Confira os registros de data e hora. Confirme se representam o horário do evento, usam um fuso horário consistente e podem ser ordenados como datas e horários.
5. Verifique duplicidades e valores ausentes. Investigue eventos repetidos e linhas sem ID do caso, registro de data e hora ou atividade.
6. Documente a extração. Registre as tabelas de origem, os campos, os filtros, a data da extração e as suposições adotadas. Assim, fica mais fácil atualizar o Event Log e investigar problemas.
7. Inclua atributos com cuidado. Adicione campos que ajudem a responder a uma pergunta e confirme se as junções não multiplicam as linhas de eventos.

Sete problemas comuns com dados, de eventos duplicados a IDs de caso ausentes, têm respostas próprias na seção de perguntas frequentes no fim desta página. O conteúdo sobre ETL para Process Mining explica como aplicar o mesmo trabalho a extrações recorrentes.

O que fazer quando você não tem os dados

Você não precisa de um conector pronto para preparar um Event Log. Comece verificando o que o seu sistema consegue exportar e se os dados incluem os três campos obrigatórios.

1. Identifique o processo e o ID do caso que você quer acompanhar.
2. Confira se o sistema consegue exportar o histórico de eventos, os registros de auditoria ou as mudanças de status com registro de data e hora.
3. Use um Template de dados para mapear os campos disponíveis para ID do caso, registro de data e hora e atividade.
4. Se não for possível exportar uma tabela de eventos pronta, peça à equipe de dados uma extração do banco de dados ou um relatório com uma linha por evento.

Uma exportação do sistema pode conter várias tabelas ou usar nomes diferentes para o mesmo campo. Você pode combinar e renomear os dados no Excel ou em SQL, desde que preserve o significado de cada campo e consiga rastreá-lo até a origem. O conteúdo Onde encontrar dados para Process Mining mostra outros lugares onde podem estar os dados de origem que você consegue usar. Já os guias de melhoria de processos já cobrem as etapas de 1 a 3 para o seu sistema, com um Template de dados para cada processo.

Se quiser comparar formatos com outro exemplo de Event Log para Process Mining, a coleção de arquivos de exemplo e Templates de Event Log inclui uma planilha pronta, e a página sobre o Template de Event Log lista as colunas obrigatórias e opcionais. Para ver como carregar o primeiro conjunto de dados, consulte carregue seu primeiro conjunto de dados.

Carregue o Event Log que você criou

Quando o Event Log estiver pronto, carregue o arquivo e mapeie as três colunas obrigatórias. O ProcessMind lê diretamente arquivos do Excel, CSV e extrações de bancos de dados.

1. Carregue seu arquivo ou selecione a extração do banco de dados.
2. Mapeie as colunas ID do caso, registro de data e hora e atividade.
3. Revise os atributos adicionais.
4. Gere a visualização do processo e confira se os casos e a ordem dos eventos fazem sentido.

Veja o mapeamento das colunas do conjunto de dados para as funções de atividade, caso e atributo no ProcessMind

A visualização do processo ajuda você a identificar atividades ausentes, sequências inesperadas e pontos que merecem investigação. Ela não corrige os dados de origem nem altera a forma como o trabalho é feito. Se o primeiro resultado revelar um problema nos dados, atualize a extração e carregue-a novamente. Carregue seu primeiro conjunto de dados explica em detalhes como carregar os dados e fazer o mapeamento.

Carregue o Event Log que você acabou de criar