Planejamento e programação avançados: o que uma programação precisa satisfazer

Ela pressupõe que você conhece o seu processo e nunca comprou um software de programação.

Restrições de programação da produção que uma linha real precisa satisfazer

Comece pelas restrições, porque o software só interessa na medida em que consegue representá-las. Uma máquina roda um trabalho por vez, e o tempo para passar do trabalho que está rodando para o próximo normalmente depende de quais são esses dois trabalhos. Cor clara para escura é uma limpeza rápida; escura para clara é uma purga e uma lavagem completa. Isso é o setup dependente de sequência: o tempo de setup não é propriedade de uma operação, e sim de um par de operações num recurso específico, já que a mesma troca de cor custa uma coisa numa prensa grande e outra numa pequena, e em algumas linhas depende também do estado da máquina. É a restrição que mais falta no sistema de registro, e é por isso que um plano saído do ERP tantas vezes parece uma lista ordenada em vez de uma sequência.

Depois vêm as restrições que não estão presas a uma única máquina, e que em muitas linhas apertam mais do que a matriz de setup. Um estampo, um molde ou uma bancada de teste só pode estar num lugar por vez, então duas células que poderiam rodar o pedido não podem rodá-lo ao mesmo tempo. Um operador qualificado é o mesmo tipo de recurso escasso: três pessoas no turno e uma certificada para a classe de solda significa que aquela classe tem capacidade um. Ar comprimido, um forno ou uma ponte rolante restringem uma área inteira, então dois trabalhos que cabem individualmente podem não caber juntos.

A disponibilidade de material é uma pré-condição rígida e, ao mesmo tempo, uma entrada frouxa. O pedido não pode começar antes de o componente chegar, mas a data de chegada é a promessa de um fornecedor com a sua própria confiabilidade. A programação deveria portanto mostrar quais pedidos dependem de uma entrega que ainda não aterrissou, para que a exposição fique visível no plano em vez de diluída dentro de um lead time e descoberta na manhã em que o material não chega.

Os calendários carregam mais do que se imagina. Os padrões de turno diferem por área, não por planta: o tratamento térmico roda a noite inteira e a montagem não, e uma troca de setup na sexta-feira que não termina antes do fim do turno vai ser feita duas vezes. Janelas de manutenção, feriados e a parada anual são períodos em que o recurso existe na lista de ativos e não está disponível para a produção.

E há regras de processo que nada têm a ver com capacidade. Cura, secagem, resfriamento e quarentena impõem esperas mínimas entre operações, e muitas vezes máximas também: curar por pelo menos quatro horas, pintar dentro de vinte e quatro, usar o adesivo misturado dentro do seu pot life, lavar a peça antes que apareça oxidação superficial. Um programador que entende esperas mínimas mas não as máximas vai produzir, em silêncio, planos que refugam material. Alguns pares de operações precisam ser consecutivos porque a peça não pode ficar semiacabada; alguns lotes precisam ser formados pelo volume do tanque, e não pela quantidade demandada.

Por que a rodada de MRP produz datas que ninguém consegue cumprir

O MRP faz algo genuinamente útil, e esse algo não é programar. Ele explode a demanda pelas listas de materiais, compensa contra estoque e ordens em aberto, desloca no tempo por um lead time fixo por item, e diz o que fabricar ou comprar e mais ou menos quando começar. Para fazer isso em milhares de itens, ele assume que há capacidade disponível sempre que a aritmética pedir.

Essa premissa falha em silêncio. Duas ordens querem a prensa às dez horas e o MRP coloca as duas ali. O deslocamento por lead time é um número definido uma vez, uma média de fila, processamento e movimentação sob condições que já não valem, e as trocas de setup ou estão ausentes ou estão escondidas dentro dele como uma folga fixa que não depende da sequência. O resultado é aritmeticamente consistente e fisicamente inexequível, o que é pior do que estar errado, porque parece correto dentro do sistema.

O chão de fábrica absorve a diferença. Alguém ressequencia à mão, normalmente bem, usando um conhecimento que mora em uma ou duas cabeças, e o plano vira uma sugestão. Tudo o que deriva dele herda o erro: datas de entrega prometidas, timing de compras, dimensionamento de pessoal, o número de capacidade informado para vendas. Quando o planejador responde inflando os lead times, a proteção é real e o custo também, porque lead time inflado é trabalho liberado cedo, que vira material em processo parado entre postos.

A planilha que substitui aquelas datas é uma melhoria genuína com um teto. Ela funciona porque o planejador carrega a matriz de trocas e os conflitos de ferramental na cabeça, e falha na escala, nas férias dele, e na pergunta sobre o que quebra se este pedido for aceito.

O que a programação com capacidade finita muda

A programação com capacidade finita inverte a pergunta. Em vez de perguntar quando uma operação deveria começar se nada estivesse no caminho, ela posiciona operações sobre recursos que já têm trabalho em cima, respeitando setups, calendários, ferramental e precedência, e reporta as datas que saem daí. As datas passam a ser saída, e não entrada.

As consequências são práticas. A sequência em cada recurso fica explícita, então a matriz de setup pode ser explorada: onde o setup consome uma parcela relevante da capacidade disponível, agrupar produtos compatíveis recupera horas de troca sem investimento. Se esse é o seu caso é um número que você pode medir nesta semana, e vale medir primeiro, porque numa linha com trocas de cinco minutos e um problema de material o sequenciamento recupera quase nada. Os gargalos passam a ser visíveis como carga, em vez de como opinião. Como o plano é restrito, incluir um pedido mostra o que ele desloca, e é isso que torna possível uma promessa de entrega crível.

Isso também muda a liberação. Um plano de capacidade infinita libera trabalho tão cedo quanto os deslocamentos permitem; um plano finito libera quando a restrição consegue receber, o que puxa o material em processo para baixo e encurta a distância entre gerar um defeito e encontrá-lo. Nada disso é de graça: o modelo precisa ser mantido, e é tão honesto quanto os tempos que estão dentro dele.

Planejar, programar e despachar são três trabalhos diferentes

Confundir os três é a razão mais comum de um projeto de programação produzir algo que ninguém usa. O planejamento trabalha em semanas e meses. Ele responde se a demanda é viável no agregado, se é preciso um segundo turno em março, o que comprometer com os fornecedores. A unidade é uma família e uma semana; mais precisão seria falsa, porque a demanda também não é precisa.

A programação trabalha em horas e dias. Ela responde qual é a sequência em cada recurso nos próximos turnos, com os setups que essa sequência implica, e é o que APS significa mais especificamente.

O despacho trabalha em minutos. Ele responde o que o operador desta célula começa em seguida, dada a parada, a primeira peça reprovada, o material que não chegou. Ele pertence ao que o operador de fato olha — um terminal de MES, uma lista de despacho, uma sequência colada na máquina — e o que importa é que fique perto do trabalho e tenha permissão para divergir da programação, porque a realidade também tem voto.

O modo de falha é usar uma ferramenta na altitude errada: programar ao minuto com três semanas de antecedência, ou planejar capacidade a partir de uma lista de despacho. O outro é proibir o desvio na camada de despacho, o que transforma o sistema num obstáculo e garante que ele seja contornado.

Que dados um APS exige: roteiros, tempos de ciclo, trocas de setup

Um motor de programação é um cálculo sobre os seus dados mestres. Se o dado é decorativo, a saída é decorativa e confiante.

Os roteiros precisam refletir como a peça é realmente feita, inclusive as alternativas. Se um trabalho pode rodar em três máquinas mas o roteiro nomeia uma, o programador enfileira trabalho ali e reporta um gargalo que você não tem. Se um roteiro omite uma operação que sempre acontece — uma rebarbação, uma inspeção, uma espera de resfriamento — toda data fica curta naquele tanto.

Os tempos de ciclo precisam ser medidos, não herdados. Os tempos padrão na maioria dos ERPs foram digitados no go-live e refletem uma ferramenta e um operador que talvez já não existam. Você não precisa de tempos perfeitos, só de tempos cujo erro seja pequeno e sem viés: um roteiro em que toda operação é otimista pela mesma margem se acumula numa programação errada por um turno inteiro no fim da semana.

Os tempos de troca de setup são o dado que mais falta por completo, e o mais valioso. Uma matriz completa de todos os pares de produtos raramente se sustenta. O que funciona é agrupar produtos em famílias pelo que de fato determina o setup — cor, material, ferramenta, temperatura, largura — e definir tempos entre famílias, com exceções só onde elas importam. Espere manter essa matriz de família para família por grupo de recursos, e não uma única para a planta inteira, porque a mesma transição raramente custa o mesmo em duas máquinas diferentes.

O material em processo atual é a parte que as pessoas esquecem. Uma programação para amanhã parte do estado do chão de fábrica hoje à noite: o que está semiacabado, onde está, o que está montado em cada máquina. Se esse estado é digitado no fim do turno a partir de uma folha de papel, o programador está otimizando uma fábrica que existiu horas atrás.

O dado ruim se anuncia. Um recurso está sempre saturado e todo o resto ocioso, o que em geral significa que os roteiros afunilam para ele artificialmente. Os planejadores sobrescrevem os mesmos pedidos todo dia, o que significa que falta uma restrição no modelo. Os trabalhos são apontados em lote no mesmo minuto, o que significa que os apontamentos são redigitados depois e que os horários de início são ficção. O instinto é calibrar o motor; a causa é quase sempre o dado mestre.

Como julgar uma programação

A entrega no prazo é o resultado que importa, medida contra a data dada ao cliente e não contra a última data interna revisada, senão o número melhora enquanto a experiência do cliente não.

O total de horas de troca de setup por semana é a medida mais limpa de se o sequenciamento está fazendo algum trabalho, e é diretamente conversível em capacidade.

O material em processo e o tempo de atravessamento dizem se o plano está liberando com bom senso. Uma programação que melhora a entrega no prazo inundando o chão de fábrica com liberações antecipadas apenas mudou o problema para os corredores.

A aderência à programação — quanto do que foi planejado para um turno foi de fato rodado, na sequência planejada — é a medida honesta de se o plano é crível. Uma programação com métricas teóricas excelentes que o chão de fábrica parou de seguir antes do almoço é um documento.

A utilização é a armadilha. Manter toda máquina ocupada num recurso que não é restrição produz estoque, não throughput, e uma linha carregada perto do teto em todo lugar não tem nada sobrando para absorver variabilidade, então as filas crescem de forma não linear e os lead times pioram à medida que o número de utilização melhora. Acompanhe-a na restrição e ignore-a em grande parte no resto.

Política de reprogramação e nervosismo da programação

Um motor capaz de replanejar em segundos convida ao replanejamento constante. Resista. Se a sequência muda toda vez que qualquer coisa se mexe, o chão de fábrica aprende que o plano das oito não é o plano das dez, e volta a rodar o que parecer sensato. Essa instabilidade se chama nervosismo, e ela destrói a confiança mais rápido do que uma programação medíocre.

O padrão utilizável é um horizonte congelado e uma política. Dentro da janela a sequência não muda, exceto por bloqueios genuínos, de modo que setups já iniciados não são desperdiçados; fora dela, a reotimização é permitida. A regra prática é replanejar não mais do que a janela congelada é longa, e definir essa janela a partir de duas coisas observáveis na área: quanto tempo leva um setup, e com que frequência aparece um bloqueio genuíno. Uma oficina de usinagem com trabalhos de uma hora e conflito de ferramental quase todo dia vai congelar algumas horas e replanejar a cada turno; uma planta de processo rodando campanhas de uma semana vai congelar dias. De um jeito ou de outro, as rodadas programadas são complementadas por rodadas disparadas por evento, para uma quebra de máquina, uma entrega faltante ou um pedido urgente.

Duas coisas fazem a política funcionar. A lista de exceções precisa ser explícita: o que conta como motivo para romper o congelamento, e quem pode autorizar. E, quando a programação muda mesmo, o supervisor precisa conseguir ver por quê, porque uma mudança sem explicação é lida como software não confiável.

Onde o APS fica em relação ao ERP e ao MES, e quem decide o quê

O ERP é dono do mundo comercial e de materiais e é a fonte do que precisa ser feito e até quando. O APS é dono da sequência, tomando demanda e material do ERP, restrições do seu próprio modelo e o estado do chão de fábrica da execução. O MES é dono da execução e do registro dela, e é também o sensor do APS, sem o qual o programador fica cego para o presente.

O ciclo só fecha se correr nos dois sentidos: do APS para o MES vai a programação, do MES para o APS vem o que realmente aconteceu. Um arquivo diário de apontamentos basta para planejar o dia seguinte e não basta para replanejar nesta tarde.

A titularidade precisa estar escrita antes do go-live, porque as discussões são previsíveis. Quem pode alterar uma data de entrega. Quem mantém a matriz de trocas de setup e os tempos de ciclo, e em que ciclo de revisão. Quem pode sobrescrever a sequência na célula, e se a sobrescrita fica registrada. Qual sistema prevalece quando o ERP e o programador discordam sobre o que há em estoque. Deixar isso implícito é o motivo habitual de uma implantação tecnicamente sólida empacar.

Conduzir uma avaliação que diz alguma coisa

Uma demonstração do fornecedor com dados do fornecedor prova apenas que o software roda. Julgue-o na sua planta; o exercício é barato se você delimitar o escopo.

Escolha uma área com restrições reais — setups relevantes, ferramental compartilhado, pedidos concorrentes — em vez da planta inteira, e pegue um período passado de quatro a oito semanas do qual você sabe o que foi rodado e o que atrasou. Entregue ao candidato os dados mestres que você tem hoje, não uma versão limpa para o teste, porque o estado dos seus dados é uma das coisas que você está medindo.

Depois peça que ele reproduza uma programação para aquele período e compare. O modelo representa as suas restrições, ou precisa que as incômodas sejam simplificadas e deixadas de fora? Ele trata esperas máximas tão bem quanto as mínimas, se o seu processo tem um prazo de validade ou um pot life dentro dele? Quanto tempo de troca de setup a sequência dele consome contra o que você de fato gastou, e o que ele diz sobre os pedidos que você entregou atrasados? Depois rode os cenários que importam: o gargalo parado por dois dias, um pedido urgente no meio da semana, uma entrega uma semana atrasada.

Depois sente um planejador na frente dele por uma tarde. A pergunta não é se o motor é inteligente, e sim se um humano consegue ver por que ele tomou uma decisão e ajustá-la sem brigar com a ferramenta; um programador com quem ninguém consegue discutir é um programador que ninguém vai usar. Pergunte quanto custa manter o modelo quando um produto, uma máquina ou um tempo de setup muda, e em quantos lugares. A maioria das programações se degrada não porque o motor estava errado, mas porque ninguém ficou dono do modelo depois que o projeto terminou.

Onde o Meta Smart Factory se encaixa

Os módulos de APS e MRP do Meta Smart Factory fazem a parte de capacidade finita disso, contra um modelo de restrições que cobre setups dependentes de sequência, ferramental compartilhado, qualificação de operador e calendários de turno por área, com rodadas de cenário para as perturbações acima. Como eles ficam na mesma plataforma que o módulo de MES, não há repasse noturno de arquivo entre a execução e o programador, então o estado do chão de fábrica é tão atual quanto os seus pontos de apontamento e a disciplina de registro dos seus operadores permitirem. Isso é uma condição, não um detalhe: se metade dos apontamentos é lançada no intervalo e a etapa de montagem manual não tem ponto de leitura, a arquitetura não te salva. Decidir onde esses pontos ficam é trabalho de implantação, não um subproduto dela. A costura com o ERP para pedidos, listas de materiais e apontamentos faz parte do mesmo trabalho.

As partes que decidem se algo disso funciona não são nossas para fornecer: tempos de ciclo medidos, uma matriz de trocas de setup com um dono, roteiros que correspondem a como a peça é realmente feita, e uma política de reprogramação escrita. Se você está no começo disso, o primeiro passo útil não é uma demo, e sim a comparação histórica descrita acima, numa área restrita, com os seus dados como eles estão.