Introdução: por que ainda se apaga incêndios todos os dias depois de “concluir a programação”
Em muitas oficinas de manufatura aditiva, a programação parece completa: cada equipamento tem ordens todos os dias, horários de início e prazos de entrega prometidos. Ainda assim, a operação continua apagando incêndios diariamente — pedidos urgentes são colocados no início da fila, uma máquina fica ociosa enquanto outra acumula seis ordens de produção, e os prazos prometidos são continuamente adiados. Normalmente, o problema não é a falta de empenho do programador, mas o fato de a programação estar baseada na premissa de “capacidade infinita”: ela responde apenas “qual ordem deve ser executada primeiro”, mas não responde se “esse equipamento, considerando trocas de configuração, pós-processamento, inspeção e retrabalho, realmente comporta mais uma ordem”.
A programação de capacidade finita (Finite Capacity Scheduling, FCS) é um método de engenharia que transforma a programação de uma “lista de sequência” em uma “tabela de carga”: ela considera simultaneamente o tempo real ocupado por cada operação, o calendário disponível dos equipamentos, a estrutura de turnos da equipe, as restrições de moldes e dispositivos, e a disponibilidade completa dos materiais, para gerar um plano executável e verificável.
I. Qual é a diferença entre capacidade infinita e capacidade finita
A programação de capacidade infinita distribui a cadeia de operações das ordens ao longo da linha do tempo, verificando apenas a precedência lógica entre operações anteriores e posteriores, sem verificar se um recurso está sendo ocupado mais de uma vez no mesmo instante. O prazo calculado costuma ser a “data teoricamente mais cedo de conclusão”, quase impossível de cumprir em uma oficina real.
Já a programação de capacidade finita vincula cada operação a recursos específicos — equipamentos, postos de trabalho, pessoas e dispositivos — e acumula a carga desse recurso em uma mesma janela de tempo. Quando o total excede a capacidade disponível, o mecanismo de programação precisa escolher: postergar, trocar de equipamento, terceirizar ou renegociar o prazo com a área comercial. Esse mecanismo de “ter que escolher” é precisamente o que falta à programação de capacidade infinita.
Para oficinas de impressão 3D, essa questão é ainda mais relevante. A ocupação de um equipamento metálico LPBF vai muito além da impressão: preparação do leito de pó e purga da atmosfera, processo de impressão, remoção de pó e retirada das peças, remoção de suportes, tratamento térmico, corte a fio, jateamento e inspeção. Cada etapa ocupa recursos diferentes e apresenta durações muito distintas. Programar apenas a impressão equivale a excluir mais de 70% da carga real do modelo.
II. Construção de um modelo de tempos por operação: da estimativa por experiência ao cálculo mensurável
A base da programação de capacidade finita são os tempos padrão por operação. Recomenda-se estabelecê-los conforme os seguintes critérios:
1. Tempo de impressão. Não utilize a estimativa grosseira de “quantidade de peças × tempo por peça”. O tempo real = preparação do leito de pó + tempo de varredura entre camadas + resfriamento da plataforma + retirada da peça e remoção do pó. O tempo de varredura pode ser estimado a partir da saída do software de fatiamento; os outros três itens devem usar valores médios obtidos em medições do equipamento. Em um equipamento metálico típico de quatro lasers, as atividades não relacionadas à impressão representam normalmente 25%–40% do tempo total de ocupação por lote.
2. Tempo de pós-processamento. O tratamento térmico deve ser calculado por carga de forno, e não por peça, pois várias peças podem ser processadas juntas, embora limitadas pelo volume de carga e pela curva do processo. Corte a fio, jateamento e inspeção devem ser calculados por peça. O ponto-chave é criar o parâmetro de “capacidade por carga de forno”; caso contrário, a programação tratará cada peça como se ocupasse um forno exclusivo.
3. Tempo de troca de configuração. Troca de material, troca de lâmina recoater, alteração de parâmetros de suporte e recalibração são todos processos de mudança de configuração. Na prática, uma troca de pó em equipamento metálico, incluindo peneiramento do pó, limpeza da máquina e purga da atmosfera, geralmente requer 2–4 horas; em equipamentos para polímeros, a troca de bobina de material normalmente leva 30–60 minutos. Sem modelar essas trocas, a programação subestimará sistematicamente a carga.
4. Tempo probabilístico de retrabalho e refugo. Com base no rendimento histórico, acrescente a cada operação um tempo esperado de retrabalho. Por exemplo, se o rendimento de conformação for de 95%, o tempo esperado de retrabalho = tempo por peça × 5%. Isso não é uma estimativa pessimista, mas a inclusão de fatos estatísticos conhecidos no plano.
III. Cálculo de carga de capacidade: antes de programar, determine se ainda há espaço
Com os tempos das operações definidos, é possível calcular a carga. As fórmulas centrais são simples:
Carga da operação (horas) = Σ (tempo padrão de cada ordem na operação + tempo de troca de configuração + tempo esperado de retrabalho)
Capacidade disponível do recurso (horas) = horas de calendário × disponibilidade operacional × fator de turnos
Taxa de carga = carga da operação ÷ capacidade disponível do recurso
Como critério prático de engenharia: uma taxa de carga superior a 100% exige postergação ou redistribuição; uma taxa mantida por longo período entre 85% e 95% indica que o equipamento é um gargalo e não possui margem, de modo que qualquer anomalia se transforma diretamente em atraso; abaixo de 60%, é necessário verificar se as regras de programação são excessivamente conservadoras ou se há desequilíbrio na estrutura dos pedidos.
A disponibilidade operacional não deve ser definida por intuição. Recomenda-se usar os dados reais dos últimos três meses: horas disponíveis ÷ horas de calendário, descontando manutenção planejada, paradas não planejadas, espera por material e espera por inspeção. Muitas oficinas acreditam ter disponibilidade de 90%, mas a medição revela apenas 72% — esse único parâmetro explica grande parte dos desvios de prazo.
IV. Gantt por operação e gestão de buffers
O resultado da programação de capacidade finita deve ser um gráfico de Gantt por operação: o eixo horizontal representa o tempo, cada linha representa um recurso — equipamento, posto ou pessoa — e cada bloco colorido representa uma operação. O comprimento do bloco deve corresponder ao tempo calculado, e não a uma “duração ideal”. Assim, o gargalo fica evidente: o recurso com blocos ininterruptos e para o qual as etapas seguintes estão sempre esperando é a restrição que deve ser priorizada.
É indispensável definir buffers sobre o Gantt. Recomenda-se uma estrutura de dois níveis: o buffer de prazo é colocado no final da ordem, absorvendo o impacto das variações operacionais sobre a data prometida; o buffer de gargalo é colocado antes da operação gargalo, assegurando que ela nunca fique sem trabalho disponível. A proporção de consumo do buffer é o indicador de alerta mais eficaz: quando mais de 50% do buffer de prazo foi consumido e o avanço físico é inferior a 40%, a ordem deve ser marcada como de risco e o cliente deve ser informado proativamente, em vez de o problema ser revelado apenas três dias antes da expedição.
V. Falta de materiais e pedidos urgentes: as duas fontes mais comuns de distorção da programação
Falta de materiais. A programação pressupõe que todos os materiais estão disponíveis, mas um lote de pó sem inspeção aprovada, uma placa de base ainda não recebida ou uma fila na terceirização do tratamento térmico podem impedir o início real de uma ordem aparentemente liberada. A solução é adicionar a cada ordem uma verificação prévia de “status de disponibilidade completa”: o lote de pó deve ter relatório de inspeção, a placa de base deve estar em estoque, os dispositivos devem estar disponíveis e a janela de terceirização deve estar confirmada. Somente quando os quatro requisitos forem atendidos a ordem poderá entrar na fila programável. A lista de faltas de material deve ser atualizada diariamente, e não descoberta no dia de início da produção.
Pedidos urgentes. Colocar um pedido urgente no início da fila é, em essência, uma otimização local que contorna as regras de programação. A abordagem correta não é proibir pedidos urgentes, mas atribuir-lhes um custo: é necessário avaliar explicitamente o impacto nos prazos das ordens já em produção — quantas ordens serão afetadas e quantos dias cada uma será adiada — e consumir explicitamente o buffer do gargalo. O mecanismo de programação deve poder apresentar uma “comparação antes e depois da inserção”, permitindo que os responsáveis decidam conhecendo o custo, em vez de a operação disputar equipamentos por intuição.
Também é necessário definir um período de congelamento do plano. Por exemplo, a sequência de ordens já iniciadas nas próximas 48 horas deve ser congelada, e mudanças durante esse período devem passar por aprovação. Sem um período de congelamento, a programação estará sempre no estado de “acabou de ser feita e já foi desorganizada”, tornando sem sentido o cálculo de carga.
VI. Fechamento do ciclo com indicadores: OTD, cumprimento do plano e desvio de programação
Concluir a programação não significa concluir a gestão. Recomenda-se acompanhar três indicadores e revisá-los semanalmente:
1. Entrega no prazo (OTD): calculada pela data prometida ao cliente, distinguindo causas atribuíveis ao cliente e causas internas; devem ser avaliados apenas os atrasos causados internamente.
2. Taxa de cumprimento do plano: número de operações efetivamente concluídas ÷ número de operações planejadas para conclusão, agrupado por recurso. Esse indicador reflete diretamente a precisão do modelo de tempos.
3. Desvio de programação: distribuição da diferença entre o tempo real e o tempo padrão. Se o desvio de determinada operação for continuamente positivo e superior a 20%, o tempo padrão deve ser revisado, em vez de continuar pressionando a operação.
Os três indicadores devem ser analisados em conjunto: OTD baixo com alta taxa de cumprimento do plano indica que o modelo de tempos é otimista demais ou que os prazos prometidos são excessivamente apertados; baixa taxa de cumprimento do plano com OTD ainda aceitável indica que a equipe está sustentando a situação com horas extras e pedidos urgentes, enquanto o risco se acumula.
Conclusão
A programação de capacidade finita não é um projeto que gera resultados apenas pela compra de um software. Em sua essência, ela exige que a oficina converta “experiência” em “parâmetros”: tempos por operação, disponibilidade operacional dos equipamentos, tempos de troca, capacidade por carga de forno, condições prévias de disponibilidade completa e estratégia de buffers. Esses parâmetros inevitavelmente serão imprecisos no início, mas, com o cumprimento do plano e os desvios de programação como feedback, podem convergir para uma precisão utilizável em três meses.
Para uma plataforma de gestão de ciclo de vida completo, como a lantu3D, que acompanha o processo desde o projeto até a entrega física, o valor da programação não está em preencher ao máximo a agenda, mas em poder ser verificada, responsabilizada e continuamente aprimorada. Ao transformar a programação de uma simples lista de sequência em um documento de engenharia com carga, buffers e feedback de desvios, o prazo deixa de ser apenas uma “promessa” e passa a ser um “resultado calculável”.
Submeta um modelo, desenho, imagem ou notas por escrito. Os engenheiros analisarão o material, processo, acabamento e entrega com base na utilização real.
