Como Analisar Seu Processo: Guia Prático para Insights de Process Mining
Transforme seus dashboards de process mining em insights acionáveis. Guia passo a passo para entender dados, explorar padrões e descobrir oportunidades de melho…
O Que Você Vai Aprender
Neste guia, você aprenderá como criar um log de eventos para Process Mining do zero. Abordaremos as três colunas essenciais que todo log de eventos precisa, analisaremos um exemplo prático e mostraremos como construir seu primeiro log de eventos usando Excel e SQL.
Relacionado: Saiba mais sobre melhoria de processos e encontre templates de dados para seu sistema. Leia também por que evitamos conectores “out-of-the-box” em favor de templates de dados simples.
Um event log de process mining é simplesmente uma tabela de dados que registra o que aconteceu no seu processo de negócio. Pense nele como um diário que rastreia cada etapa de cada caso que flui através do seu sistema. O software de process mining lê este diário e cria diagramas visuais mostrando como o seu processo realmente funciona.
Cada event log precisa de três informações essenciais para cada linha:
| Coluna | Significado | Exemplo |
|---|---|---|
| Case ID | Um identificador único que agrupa eventos relacionados | Pedido #12345 |
| Timestamp | Quando o evento ocorreu | 2025-01-15 09:30:00 |
| Atividade | O que aconteceu | ”Pedido Realizado” |
É isso. Com apenas estas três colunas, você pode começar a fazer process mining. Tudo o mais, como nomes de clientes, valores de pedidos ou IDs de funcionários, são extras opcionais chamados de “atributos” que enriquecem sua análise.
Antes de nos aprofundarmos, vamos esclarecer um ponto comum de confusão.
Uma atividade é um tipo de ação, como “Pedido Enviado” ou “Pagamento Recebido”. Pense nela como uma categoria ou rótulo.
Um evento é uma ocorrência específica dessa atividade. Quando o Pedido #12345 é enviado em 15 de janeiro às 14:30, isso é um evento.
Seu registro de eventos contém eventos, mas cada evento tem um nome de atividade. Na prática, as pessoas frequentemente usam esses termos de forma intercambiável, e tudo bem. Apenas lembre-se: atividades são o “o quê” e eventos são “quando aconteceu com quem”.
Para tornar este guia prático, vamos trabalhar com um sistema fictício. Imagine que você gerencia o Pizza Palace, uma pizzaria local com um sistema de pedidos online. Os clientes fazem pedidos pelo site, a equipe prepara as pizzas e os entregadores as entregam.
O sistema do Pizza Palace possui várias tabelas de banco de dados que rastreiam diferentes partes do processo de pedido:
Seu objetivo: criar um event log que mostre a jornada completa de cada pedido, desde o momento da realização até a entrega.
Ao construir um event log, você encontrará dois tipos de eventos:
Eventos diretos são registrados explicitamente em seu sistema. Alguém clicou em um botão ou o sistema registrou uma ação, e há um timestamp ali mesmo no banco de dados.
Exemplos da Pizza Palace:
orders)payments)delivery_assignments)Eventos inferidos não possuem um timestamp próprio, mas você pode descobrir quando ocorreram com base em outros dados.
Exemplos do Pizza Palace:
delivery_assignments possui um campo created_at que indica quando a atribuição foi feitaA principal diferença: eventos diretos são registrados explicitamente, enquanto eventos inferidos exigem que você interprete outros campos de dados. Ambos são válidos e úteis para o Process Mining.
Antes de extrair os dados, planeje quais eventos deseja capturar. Para a Pizza Palace, vamos acompanhar as seguintes atividades:
Para cada evento, identifique:
Veja o mapeamento:
| Atividade | Tabela de origem | Campo de timestamp | Campo de Case ID |
|---|---|---|---|
| Pedido realizado | orders | created_at | id |
| Pagamento recebido | payments | payment_time | order_id |
| Pedido enviado para a cozinha | kitchen_queue | queue_entry_time | order_id |
| Pedido pronto | kitchen_queue | completed_time | order_id |
| Motorista designado | delivery_assignments | assigned_at | order_id |
| Entrega concluída | delivery_assignments | delivered_at | order_id |
Embora o Case ID, Timestamp e Activity sejam obrigatórios, os atributos tornam sua análise muito mais poderosa. Atributos são colunas adicionais que fornecem contexto.
Atributos de case descrevem o case (pedido) inteiro e são os mesmos para todos os eventos nesse case:
Atributos de evento são específicos para cada evento:
Dica pro: É perfeitamente aceitável incluir todos os atributos em cada linha, mesmo que alguns não se apliquem a certos eventos. Por exemplo, sua linha de “Pedido Realizado” pode ter uma coluna “Nome do Entregador” vazia. Isso mantém seu log de eventos em um formato de tabela simples e plano que as ferramentas de process mining adoram.
Seu event log final deve ser uma tabela onde cada linha representa um evento. Veja como será o nosso event log do Pizza Palace:
| Case ID | Timestamp | Activity | Cliente | Valor do Pedido | Entregador | Método de Pagamento |
|---|---|---|---|---|---|---|
| 1001 | 2025-01-15 18:30:00 | Pedido Realizado | John Smith | 45.99 | ||
| 1001 | 2025-01-15 18:30:15 | Pagamento Recebido | John Smith | 45.99 | Cartão de Crédito | |
| 1001 | 2025-01-15 18:31:00 | Pedido Enviado para a Cozinha | John Smith | 45.99 | ||
| 1001 | 2025-01-15 18:45:00 | Pedido Pronto | John Smith | 45.99 | ||
| 1001 | 2025-01-15 18:46:00 | Atribuído ao Entregador | John Smith | 45.99 | Maria Garcia | |
| 1001 | 2025-01-15 19:05:00 | Entrega Concluída | John Smith | 45.99 | Maria Garcia | |
| 1002 | 2025-01-15 18:35:00 | Pedido Realizado | Jane Doe | 28.50 | ||
| 1002 | 2025-01-15 18:35:20 | Pagamento Recebido | Jane Doe | 28.50 | PayPal | |
| … | … | … | … | … | … | … |
Observe como os atributos de caso (Cliente, Valor do Pedido) se repetem para cada evento do mesmo caso. Essa duplicação é intencional e facilita o trabalho com os dados.
Se você consegue exportar seus dados para planilhas, pode construir um event log manualmente. Este método funciona muito bem para pequenos conjuntos de dados ou quando você está aprendendo.
Crie uma planilha para cada tipo de atividade:
Planilha 1: Pedido Realizado
| ID do Caso | Timestamp | Atividade | Cliente | Valor do Pedido |
|---|---|---|---|---|
| 1001 | 2025-01-15 18:30:00 | Pedido Realizado | John Smith | 45.99 |
| 1002 | 2025-01-15 18:35:00 | Pedido Realizado | Jane Doe | 28.50 |
Planilha 2: Pagamento Recebido
| ID do Caso | Timestamp | Atividade | Cliente | Valor do Pedido | Método de Pagamento |
|---|---|---|---|---|---|
| 1001 | 2025-01-15 18:30:15 | Pagamento Recebido | John Smith | 45.99 | Cartão de Crédito |
| 1002 | 2025-01-15 18:35:20 | Pagamento Recebido | Jane Doe | 28.50 | PayPal |
Certifique-se de que todas as planilhas tenham as mesmas colunas na mesma ordem. Adicione colunas vazias onde necessário:
Planilha 1: Pedido Realizado (atualizada)
| ID do Caso | Timestamp | Atividade | Cliente | Valor do Pedido | Entregador | Método de Pagamento |
|---|---|---|---|---|---|---|
| 1001 | 2025-01-15 18:30:00 | Pedido Realizado | John Smith | 45.99 |
Crie uma nova planilha de “Registro de Eventos”. Copie e cole todas as linhas de cada planilha de atividade nesta planilha combinada, uma após a outra.
Selecione todos os seus dados e classifique por:
Isso organiza os eventos em ordem cronológica dentro de cada caso, facilitando o acompanhamento da jornada de cada pedido.
Salve sua planilha combinada como um arquivo CSV. Este formato funciona com praticamente todas as ferramentas de Process Mining.
Dicas de Excel:
Para conjuntos de dados maiores ou extrações regulares, o SQL é mais eficiente e repetível. A técnica principal é usar UNION ALL para combinar múltiplas queries em um único conjunto de resultados.
O UNION ALL empilha os resultados de múltiplas instruções SELECT uma em cima da outra. Cada SELECT se torna um conjunto de linhas no seu resultado final. Todas as instruções SELECT devem ter o mesmo número de colunas com tipos de dados compatíveis.
Aqui está uma query SQL que cria um log de eventos para a Pizza Palace:
-- 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;
Para adicionar mais eventos ao seu log:
Por exemplo, para adicionar um evento “Tentativa de Entrega”:
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'
Comece com as três colunas obrigatórias e apenas algumas atividades chave. Uma vez que você tenha criado com sucesso um event log básico e o carregado em uma ferramenta de Process Mining, você pode retornar e adicionar mais eventos e atributos.
Antes de mergulhar na análise, verifique seu log de eventos em busca de problemas comuns:
Mantenha anotações sobre:
Essa documentação é inestimável quando você precisar atualizar ou solucionar problemas em seu log de eventos futuramente.
Mantenha os nomes das atividades consistentes entre as extrações:
Se seus dados vêm de múltiplos sistemas ou regiões, certifique-se de que todos os timestamps estejam no mesmo fuso horário. UTC é frequentemente a escolha mais segura para consistência.
Às vezes, o mesmo evento é registrado em múltiplas tabelas. Por exemplo, tanto seu sistema de pedidos quanto seu ERP podem registrar quando um pedido é enviado.
Solução: Escolha uma fonte como a “fonte da verdade” e utilize apenas essa. Documente sua escolha.

Alguns eventos podem não ter seu próprio timestamp. Por exemplo, um “Pedido Aprovado” pode ser apenas um flag booleano.
Solução: Procure por timestamps relacionados. Talvez exista um campo “approved_at”, ou você pode usar o timestamp “modified_at” quando o flag app%roved foi alterado.
Se você tem milhões de eventos, suas queries podem ficar lentas ou travar durante a extração.
Solução:
Depois de criar seu event log como um arquivo CSV ou exportação de banco de dados, você estará pronto para carregá-lo em uma ferramenta de Process Mining. A maioria das ferramentas segue um processo similar:
Ferramentas modernas de Process Mining como ProcessMind tornam este processo simples e direto. Basta fazer o upload do seu event log, e a ferramenta visualiza automaticamente seu processo, revelando gargalos, variações e oportunidades de melhoria.
Criar um log de eventos para Process Mining não exige ferramentas especializadas ou conhecimento técnico aprofundado. Em sua essência, você está simplesmente organizando seus dados em uma tabela com três colunas essenciais: Case ID, Timestamp e Activity.
Independentemente de você usar Excel para conjuntos de dados menores ou SQL para extrações maiores e mais complexas, os princípios permanecem os mesmos:
A parte mais difícil não é a extração técnica, mas sim entender seu processo bem o suficiente para saber quais eventos importam. Comece com os eventos óbvios (pedido realizado, pedido concluído) e adicione gradualmente mais detalhes à medida que descobre quais insights sua ferramenta de Process Mining revela.
Pronto para aprofundar? Explore nossas páginas de melhoria contínua de processos onde você encontrará informações detalhadas sobre atividades e requisitos de dados para processos populares como Compra ao Pagamento, Pedido ao Recebimento e Contas a Pagar. Esses recursos incluem templates de dados para sistemas conhecidos como SAP, Oracle e Microsoft Dynamics, dando a você uma vantagem inicial em sua jornada de criação de log de eventos.
Comece Hoje Mesmo
Não espere pelo log de eventos perfeito. Comece com o que você tem, aprenda com os mapas de processo que você cria e itere. Mesmo um log de eventos simples com atividades básicas pode revelar insights surpreendentes sobre como seus processos realmente funcionam.
Transforme seus dashboards de process mining em insights acionáveis. Guia passo a passo para entender dados, explorar padrões e descobrir oportunidades de melho…
Conectores prontos para process mining prometem facilidade, mas trazem complexidade, atrasos e vendor lock-in. Descubra nossa abordagem com templates de dados.
Guia prático para usar data na melhoria de processos e transformação dos negócios.
Compare Celonis e ProcessMind em 2025. Veja qual process mining serve seu negócio, orçamento e meta.
Acesso imediato, sem cartão de crédito e sem espera. Veja como mapping, mining e simulation funcionam juntos para decisões mais inteligentes e rápidas.
Explore todos os recursos, descubra insights valiosos e otimize suas operações desde o primeiro dia.
Comece seu teste grátis e aproveite todo o poder da Process Intelligence, com melhorias em menos de 30 dias!