Cinco erros comuns em projetos de simulação e como evitá-los

Disclosure: M365.FM host Mirko Peters works at iFAKT GmbH. This page describes the company factually; paid partnerships and links are labelled as advertising.

By Mirko Peters · 2026-11-11

Erros em projetos de simulação custam tempo e confiança. Conheça cinco dos mais comuns, de perguntas vagas a validações puladas, com um exemplo prático e uma lista de verificação.

Automatically translated with AI from the original post. Read the English original

Os erros em projetos de simulação são, em grande parte, evitáveis, e a maioria acontece antes de o primeiro modelo ser construído. Este guia é para gerentes de fábrica que patrocinam um projeto de simulação industrial e para os engenheiros que constroem o modelo, quando o objetivo é que o trabalho termine em uma decisão. Você vai conhecer cinco erros comuns, extraídos de dois artigos do especialista em simulação Averill Law e da prática, um exemplo com números que mostra por que uma única execução não basta, e uma lista de verificação para o seu próximo projeto de simulação de fábrica.

Pontos principais

• Cinco erros se repetem em projetos de simulação: falta de uma pergunta clara, nível de detalhe inadequado, dados fracos, ausência de validação e confiança em uma única execução.
• Um modelo sem uma pergunta clara e sem um tomador de decisão em contato regular resolve o problema errado, por melhor que seja.
• Comece simples e acrescente detalhes somente quando a pergunta exigir; detalhe desnecessário custa tempo e esconde os fatores que importam.
• Valide o modelo contra o sistema existente antes de usá-lo para previsões e mantenha as premissas escritas para revisão.
• Eventos aleatórios exigem muitas replicações: uma única execução pode classificar duas opções na ordem errada.

Erros em projetos de simulação: de onde vêm

Um projeto de simulação não é um exercício de programação. Averill Law, em seu artigo sobre como conduzir um estudo de simulação bem-sucedido, apresentado na Winter Simulation Conference de 2003, listou 17 armadilhas em quatro grupos: modelagem e validação, software, aleatoriedade e planejamento de experimentos. Em 2024, ele ampliou a lista para 23 armadilhas em um artigo para a mesma conferência. Ele observa que a programação representa apenas 25 a 50% do trabalho em um estudo bem conduzido.

Law trabalha em sua própria consultoria de simulação, a Averill M. Law & Associates, portanto suas listas refletem a visão de um especialista. Elas concordam com um artigo prático de J. Michael Knoll e Joseph Heim, da Genie Industries, sobre a adoção de simulação de eventos discretos em um ambiente industrial, que se baseia em um único fabricante de porte médio e não relata economias quantificadas.

A partir dessas fontes e da prática comum, escolhemos cinco erros que mais importam em uma fábrica. Esta seleção é nossa, não um ranking dos artigos.

Erro 1: Nenhuma pergunta clara e nenhum contato com o tomador de decisão

O primeiro erro é começar pela ferramenta, e não pela pergunta. Law inclui entre suas armadilhas objetivos mal definidos e pouco contato regular com o tomador de decisão. Ele cita um alerta de que o melhor modelo do mundo para o problema errado terá pouco valor para quem decide. Em um de seus exemplos, um analista trabalhou por meses sem consultar o general que havia feito o pedido. Ao final, em um briefing que durou apenas cinco minutos, o general saiu dizendo que aquele não era o problema que lhe interessava.

Knoll e Heim acrescentam uma regra prática: um modelo cujos resultados não serão usados não deveria ser construído.

Como evitar. Formule a pergunta como uma decisão. "Qual de dois layouts entrega 3.000 unidades por turno?" é uma pergunta. "Vamos simular a fábrica" não é. Faça uma reunião de início com todos os afetados, defina quem decide e até quando, e combine reuniões regulares de revisão durante o projeto.

Erro 2: O nível de detalhe errado

O segundo erro é modelar demais ou de menos. Law chama um nível de detalhe inadequado de um dos erros mais comuns, especialmente para analistas novos. A recomendação dele é incluir apenas o detalhe suficiente para responder às perguntas de interesse e começar simples, acrescentando detalhes conforme necessário. Knoll e Heim concordam: mantenha o escopo enxuto e não amplie um modelo só porque é possível.

Detalhe demais atrasa o projeto e esconde os fatores que importam em meio a uma multidão de parâmetros. Detalhe de menos deixa de fora um efeito que você queria testar, como uma troca de ferramenta (changeover) ou um buffer.

Como evitar. Pergunte, para cada elemento e cada parâmetro de entrada do modelo, se ele muda a resposta à pergunta. Se não mudar, deixe-o de fora ou use uma regra simples. Registre as premissas em um modelo conceitual curto, que Law chama de atividade absolutamente crítica e frequentemente pulada, e revise-o com as pessoas que conhecem a linha.

Erro 3: Coleta fraca de dados para a simulação

O terceiro erro diz respeito aos dados. Law inclui a coleta deficiente de dados do sistema entre as armadilhas e também alerta para dois erros típicos na modelagem de entradas. O primeiro é substituir uma entrada aleatória pela sua média. No exemplo de filas dele, usar tempos constantes iguais às médias elimina a fila por completo, então o modelo não mostra espera onde o sistema real a tem. O segundo é escolher uma distribuição, como a normal, por hábito. Em um dos exemplos dele, uma distribuição normal para tempos de atendimento produziu um erro de saída de 39% em comparação com uma distribuição que se ajustava melhor.

Os dados da fábrica também exigem cuidado. O motivo de parada no sistema de execução de manufatura coincide com o registro de manutenção? Se um gêmeo digital, uma representação digital mantida de um recurso físico e atualizada a partir de observações, estiver disponível, ele pode fornecer dados atuais. Se não estiver, reserve tempo para medição.

Como evitar. Liste os dados de que a pergunta precisa, identifique a fonte e o responsável por cada item, e colete a variação, não apenas a média. Use pelo menos dois especialistas para as partes importantes do processo, porque parte do que as pessoas dizem estará errada.

Erro 4: Pular a validação do modelo de simulação

O quarto erro é confiar em um modelo que nunca foi comparado com a realidade. Law chama a comparação dos resultados do modelo com o sistema existente da técnica de validação mais importante, e diz que ela também sustenta a credibilidade. Em seu artigo de 2024, ele apresenta um exemplo de polpa de papel em que a vazão do modelo e a do sistema diferiram em apenas 0,4% e 1,1%. Ele também recomenda uma revisão estruturada das premissas com todas as partes interessadas, porque erros e omissões do modelo serão encontrados.

Como evitar. Construa primeiro a linha de base e compare-a com a saída, as paradas e o lead time da linha real. Peça a especialistas que revisem os resultados da simulação quanto à razoabilidade e teste qual parâmetro de entrada mais altera os resultados. Só então use o modelo para avaliar opções. Se a linha ainda não existe, compare o modelo com uma linha semelhante ou com cálculos, e diga isso abertamente.

Erro 5: Tratar uma única execução como verdade

O quinto erro é estatístico. Uma simulação com eventos aleatórios produz um resultado diferente a cada execução. Law alerta contra tratar a saída de uma única execução como o desempenho verdadeiro do modelo. No exemplo de um escritório de veículos automotores, o atraso médio variou de 1,83 a 10,37 minutos entre as replicações. Ele também cita a omissão de um período de aquecimento (warm-up), quando o estado inicial está vazio e não é representativo, e a comparação de opções sem intervalos de confiança.

Como evitar. Execute muitas replicações independentes, descarte o período de aquecimento, planeje as análises antes das execuções e compare opções usando faixas ou intervalos de confiança, não números isolados.

Exemplo: uma execução contra cinco replicações

Este é um exemplo ilustrativo com números presumidos, não um caso medido. Uma fábrica compara dois projetos de buffer, A e B, em um modelo de uma linha de embalagem. A produção por turno de cada projeto no modelo é:

• Projeto A, cinco replicações: 412, 389, 401, 395 e 393 unidades. A média é 1.990 ÷ 5 = 398 unidades.
• Projeto B, cinco replicações: 405, 399, 408, 402 e 406 unidades. A média é 2.020 ÷ 5 = 404 unidades.

Se a equipe tivesse executado apenas a primeira replicação de cada um, o A teria marcado 412 e o B, 405, e o A pareceria 7 unidades melhor. Com cinco replicações, o B é, em média, 6 unidades melhor, e sua faixa, de 399 a 408, é mais estreita que a do A, que vai de 389 a 412. A primeira execução classificou os projetos na ordem errada.

Cinco replicações são um mínimo para uma ilustração. Um projeto real executaria mais e calcularia intervalos de confiança. A etapa de validação usa a mesma ideia: se o modelo de referência der uma média de 391 unidades e a linha real tiver produzido em média 380 unidades por turno ao longo de 20 turnos, o modelo fica 11 unidades, ou cerca de 3%, acima. A equipe decide se isso é suficientemente próximo para a questão e registra essa decisão.

Como evitar os cinco erros: uma lista de verificação

1. Escreva a pergunta como uma decisão, com o responsável pela decisão e a data.
2. Realize uma reunião de início com todas as partes interessadas e combine reuniões de revisão. Trate o trabalho como uma iteração com pontos de revisão, e não como um fluxo de trabalho unidirecional.
3. Comece simples. Escreva um modelo conceitual curto com as premissas e revise-o com especialistas antes de programar.
4. Planeje os dados. Identifique a fonte e o responsável por cada dado e colete a variação.
5. Valide o modelo de referência contra a linha real antes de testar as opções.
6. Replique. Execute replicações suficientes, descarte o período de aquecimento e reporte as faixas de variação.

Erros comuns

• Tratar o projeto como programação. Programar é apenas uma parte do trabalho, segundo a Lei.
• Deixar que a animação decida. Uma olhada rápida na animação não é um experimento.
• Escolher ferramentas de simulação apenas pelo preço. Adeque a ferramenta ao problema e às habilidades da sua equipe, e não use o software de simulação como caixa-preta.
• Falta de documentação. Um modelo sem premissas escritas não pode ser revisado nem reutilizado.
• Nenhum responsável após o projeto. Um modelo que ninguém atualiza fica desatualizado na primeira mudança.

Como o software pode ajudar

O iFAKT's Polaris Simulator é um módulo do iFAKT Polaris que testa virtualmente o sistema de produção, por exemplo cenários de capacidade, dimensionamento de equipe e buffers, e revela gargalos antes que as mudanças sejam feitas. Qualquer que seja a ferramenta escolhida, e antes de usar a simulação para uma decisão, verifique como ela trata replicações e período de aquecimento, como você importa dados reais e como pode documentar e revisar as premissas. O software não pode substituir a pergunta nem a validação.

Próximo passo

Pegue seu próximo projeto de simulação de manufatura, ou um que esteja em andamento, e verifique-o com a lista de verificação acima. Onde houver uma resposta faltando, você encontrou uma causa provável de erros em projetos de simulação, e pode corrigi-la antes de o modelo ser construído.