Dados para modelos de simulação: de onde vêm e quão bons precisam ser

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

Os dados para um modelo de simulação vêm de sistemas, medições e especialistas. Veja as fontes, as lacunas de qualidade mais comuns e o nível de qualidade que os dados de entrada da simulação precisam ter.

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

Os dados para construir o modelo de simulação vêm de três lugares: sistemas do negócio e do chão de fábrica, medição direta e as pessoas que conhecem a linha. O quão bons eles precisam ser depende da pergunta, e não de um padrão geral. Este guia é para gestores de melhoria contínua que são solicitados a fornecer os dados para uma simulação de fábrica. Você vai aprender do que o modelo precisa, de onde vem cada item, o que costuma dar errado, um exemplo resolvido com números e um plano de seis passos para obter dados suficientemente bons.

Principais conclusões

• Um modelo de simulação precisa de produtos e roteiros, tempos de processo, recursos, paradas, pedidos e regras de dimensionamento de equipe; cada item vem de um sistema, de uma medição ou de um especialista.
• Os dados vêm de fontes primárias, como estudos de cronometragem e observação, e de fontes secundárias, como sistemas ERP, MES e CAD, além de previsões.
• As lacunas típicas são tempos pré-configurados no ERP que diferem dos tempos reais, registros duplicados, dados defasados em relação à realidade e variação ausente.
• As entradas precisam ser boas o suficiente para a pergunta: verifique quais entradas mais alteram o resultado e concentre o esforço nelas.
• Use distribuições e registros reais, e não apenas médias, porque a variação gera o tempo de espera que você quer testar.

Dados para construção de modelos de simulação: do que o modelo precisa

Um modelo de fluxo de uma linha precisa de seis tipos de entrada. Esta lista é um resumo nosso das práticas comuns, e não um padrão.

• Produtos e roteiros. Qual produto passa por qual estação e em que ordem.
• Tempos. Tempo de processo por produto e estação, tempos de troca de ferramental e a variação de ambos.
• Recursos. Máquinas, ferramentas e pessoas, sua capacidade e disponibilidade, incluindo falhas e paradas planejadas.
• Pedidos e demanda. Tamanhos dos lotes de pedido, mix e padrão de chegada, a partir da carteira de pedidos ou de uma previsão.
• Regras. Modelo de turnos, tempos de pausa, regras de sequenciamento e de formação de lotes, e como os operadores se movem entre as estações.
• Qualidade. Taxas de sucata e retrabalho, e onde os defeitos são encontrados.

O modelo não precisa de todos os números da fábrica. Ele precisa dos números de que a pergunta depende, e precisa da variação, porque é a variação que gera a espera que você quer simular e testar. Um modelo só consegue prever aquilo que os seus dados permitem.

De onde vêm os dados de entrada da simulação: coleta de dados na prática

Um artigo de Maja Bärring e colegas na Winter Simulation Conference de 2018 descreve as fontes em dois grupos, seguindo trabalhos anteriores de Anders Skoogh e colegas.

• Dados primários são coletados para o estudo: medições, estudos de cronometragem e observação na linha.
• Dados secundários já existem. Incluem referências externas, como normas industriais e especialistas da área, sistemas corporativos de negócio como ERP, MES, PDM e CAD, e dados específicos do projeto, como previsões de volume de produção.

Na prática, para um gestor de melhoria contínua, a coleta de dados se parece com isto. O sistema de execução de manufatura armazena os tempos de ciclo reais, os eventos de parada e as quantidades por estação. O ERP guarda pedidos, roteiros e tempos planejados. O sistema CAD ou PDM guarda a estrutura do produto. Os planos de turno ficam com o planejamento ou com RH. Os tempos de troca de ferramentas e a forma como os operadores realmente trabalham muitas vezes só são descobertos por observação e perguntando aos líderes de turno.

Por que os dados muitas vezes não são bons o suficiente

Bärring e colegas estudaram duas empresas, com cinco entrevistados, portanto os resultados são indicativos, não gerais. No caso em que os dados eram coletados manualmente do ERP e de planilhas, eles relatam problemas que muitas fábricas vão reconhecer:

• Valores predefinidos do ERP foram usados no lugar de tempos reais, então não ficava claro quais tempos deveriam ser usados.
• O mesmo item estava armazenado tanto no sistema ERP quanto em planilhas.
• Os rótulos eram inconsistentes, e os departamentos eram diferentes entre si.
• A realidade mudou, mas o sistema não.

Os autores também observam que os sistemas ERP dão mais ênfase a valores determinísticos do que a valores estocásticos, de modo que a variação de que uma simulação precisa muitas vezes está ausente. No segundo caso, a aquisição automática evitou cinco dos oito desafios que eles listam. O artigo recomenda, entre outras coisas, atribuir a responsabilidade pelos dados a funções dentro da empresa. Uma pesquisa de Skoogh, Perera e Johansson publicada em Simulation Modelling Practice and Theory constatou que cerca de 80% dos usuários de simulação ainda dependem de procedimentos altamente manuais para os dados de entrada.

Roteiro e lista de materiais em uma simulação

Dois tipos de dados mestres costumam causar problemas. O roteiro indica quais operações um produto precisa, em que ordem, em qual recurso e com qual tempo. A lista de materiais indica quais peças entram no produto. Para um modelo de fluxo, o roteiro costuma ser a espinha dorsal, e a lista de materiais importa quando peças podem faltar ou quando uma estação espera por uma montagem.

Os roteiros no ERP são frequentemente valores de planejamento, definidos uma vez e raramente atualizados, que é o problema descrito por Bärring e colegas. Antes de carregar um roteiro em um modelo, compare os tempos dele com os tempos reais do MES para o mesmo produto e estação. Verifique se a sequência de operações ainda corresponde ao chão de fábrica e se a lista de materiais mostra as variantes que você realmente fabrica. Não preencha uma lacuna com dados simulados, também chamados de dados sintéticos, e esqueça de identificá-los.

Qual deve ser a qualidade dos dados de simulação?

A resposta é: boa o suficiente para a decisão. Averill Law, em seu artigo sobre armadilhas na modelagem de simulação, pede registros das distribuições dos dados de entrada e validação, e recomenda coletar dados de todas as fontes possíveis de aleatoriedade do sistema, sempre que for possível. Ele alerta para dois erros: substituir uma entrada aleatória pela sua média, o que, no exemplo dele, elimina a fila por completo, e escolher uma distribuição normal por hábito, o que, em um dos seus exemplos, gerou um erro de saída de 39%.

Uma forma prática de decidir quanto esforço investir é ordenar as entradas pelo seu efeito e pela incerteza de cada parâmetro. Law também recomenda a análise de sensibilidade para ver quais fatores afetam mais as medidas de desempenho. Esta classificação é uma ferramenta de planejamento nossa, não um padrão:

1. Nota A: medido e verificado. Use para as entradas que mais alteram o resultado, como o tempo de ciclo no gargalo e o padrão de paradas antes dele.
2. Nota B: obtido de um sistema e verificado em uma amostra. Use para entradas com efeito médio.
3. Nota C: julgamento de especialista. Use para entradas com pouco efeito, e registre a premissa.

Por fim, verifique o conjunto inteiro por meio da validação: o modelo reproduz a produção da linha real? Se não reproduz, examine primeiro as entradas de nota A.

Exemplo: tempo do roteiro versus tempo real

Este é um exemplo ilustrativo com números presumidos, não um caso medido. Uma linha produz um único produto. O roteiro do ERP indica 42 segundos por peça na estação gargalo. O MES mostra um tempo de ciclo real mediano de 47 segundos ao longo de quatro semanas.

• Produção por hora com o tempo do roteiro: 3.600 ÷ 42 = 85,7 peças.
• Produção por hora com o tempo real: 3.600 ÷ 47 = 76,6 peças.
• A roteirização superestima a taxa em 85,7 ÷ 76,6 = cerca de 12 por cento. Em um turno de 8 horas, isso representa cerca de 686 contra 613 peças, uma diferença de 73 peças.

Um modelo alimentado com a roteirização faria uma previsão que a linha nunca alcançou, e qualquer melhoria medida em relação a ele pareceria pior do que realmente é.

A mesma lógica vale para as paradas. Suponha que o MES registre sete paradas com durações de 2, 3, 3, 4, 5, 6 e 40 minutos. A soma é de 63 minutos, portanto a média é de 9 minutos, enquanto a mediana é de 4 minutos. Um modelo com uma parada constante de 9 minutos nunca mostra a parada de 40 minutos que esvazia o buffer, e exibe mais paradas de duração média do que a linha realmente tem. Plote as durações registradas, calcule a dispersão delas e use-as diretamente ou uma distribuição estatística ajustada a elas. Estime os parâmetros a partir dos registros.

Usar bem os dados: um plano em seis etapas

1. Liste as perguntas. A pergunta define quais entradas você precisa.
2. Liste os itens dos seis grupos acima e marque aqueles dos quais a pergunta mais depende.
3. Defina fonte e responsável para cada um, por exemplo o MES para as paradas, o ERP para os pedidos, um observador para as trocas de setup.
4. Compare as fontes. Confira os tempos da roteirização com o MES e verifique se os identificadores e as unidades coincidem entre os sistemas.
5. Meça as lacunas com o método de grau A para as entradas que importam e registre as premissas para as demais.
6. Valide e mantenha os dados. Compare o modelo com a linha real, armazene o conjunto com uma data e designe um responsável por atualizá-lo.

Erros comuns

• Carregar a roteirização do ERP sem verificação. Valores planejados não são valores reais.
• Usar apenas médias. Cada entrada é uma variável com dispersão, não um número único. A variação cria o tempo de espera, e a média a elimina.
• Coletar tudo. Esforço sem uma pergunta desperdiça tempo que o projeto não tem, e o volume excessivo esconde o que importa.
• Misturar definições. Uma parada, uma troca de setup ou um ciclo podem significar coisas diferentes em sistemas diferentes.
• Não ter responsável. Dados que ninguém mantém ficam desatualizados na próxima mudança.
• Pular a validação. Sem uma comparação com a linha real, você não sabe se as entradas são boas o suficiente.

Como o software pode ajudar

Um grafo de conhecimento que relaciona produtos, etapas do processo e recursos pode reduzir dados duplicados e conflitantes, porque cada fato é armazenado uma única vez. O Polaris Designer da iFAKT é um módulo do iFAKT Polaris que constrói um grafo de conhecimento produto-processo-recurso (PPR) como fonte única da verdade para produtos, etapas do processo e recursos. Ele não substitui a verificação com os tempos reais, os responsáveis nem a validação do modelo. Qualquer que seja a ferramenta, pergunte como ela importa dados do seu ERP e do MES e como as mudanças são rastreadas.

Próximo passo

Escolha a estação gargalo de uma linha e compare o tempo de roteirização no ERP com o tempo de ciclo real no MES nas últimas quatro semanas. Se eles diferirem, você encontrou a primeira lacuna nos dados para a construção do modelo de simulação e sabe por onde começar.