📅 · 4 min de leitura · Equipa Meta Smart Factory
A maioria das fábricas que fracassou na digitalização não fracassou na tecnologia. O gateway funcionou e a plataforma fez tudo o que a demonstração mostrava. O que falhou foi a ordem: análise comprada antes de o dado existir, um otimizador instalado acima de um registro de execução que ninguém tinha construído, uma plataforma escolhida antes de alguém escrever a pergunta.
Sequenciar é a parte difícil, e é a parte que o material de fornecedor pula, porque a versão honesta significa dizer ao cliente para comprar menos neste ano. Esta página é essa ordem.
Quatro causas respondem pela maioria deles. As quatro são falhas de programa, e não de produto, o que é justamente o ponto: são as que a fábrica controla. Software também falha nos termos dele, e essa lista pertence ao processo de compra: desenho de transação, desempenho em escala, um fornecedor cujo envolvimento termina no go-live.
A primeira é um patrocinador sem um dono abaixo dele. Patrocinador aprova orçamento e comparece a uma reunião mensal; dono tem tempo de chão de fábrica, autoridade para mudar um processo e um resultado pessoal amarrado a rodar a fábrica de outro jeito daqui a um ano. A segunda é um business case que assume um dado que não existe, e aí um plano de analisar paradas encontra um campo de texto livre numa folha de turno. A terceira é um piloto que nunca foi construído para escalar. A quarta é comprar uma plataforma antes de saber a pergunta, e a fábrica passa a ter um sistema capaz sem um primeiro uso.
O primeiro projeto deve sair da restrição da fábrica, não da lista de módulos. Na maioria das fábricas a perda é sem glamour: trocas de setup mais longas que o padrão, material que não se acha, paradas de dois minutos que ninguém registra.
Três perguntas filtram os candidatos depressa. A perda já aparece na contabilidade da própria fábrica, como refugo, hora extra, frete expresso ou multa por atraso na entrega? Alguém agiria diferente dentro do mesmo turno se tivesse a resposta? Dá para saber dentro de um ciclo de produção se funcionou? Ciclo, e não trimestre: três meses é um teste justo em produção repetitiva de alto mix e não quer dizer nada em aeronáutica ou numa campanha farmacêutica, onde a unidade é uma campanha ou uma ordem.
Às vezes software é a resposta errada: se a restrição é física, nenhum dado vai deixar a máquina mais rápida. O que a medição faz é mostrar para onde a capacidade vai, e isso normalmente redireciona o pedido de investimento em vez de confirmá-lo. O tempo rodando da máquina candidata parece pior do que qualquer um imaginava, depois que as paradas curtas são contadas, e ainda assim a maior parte das horas que ela perdeu não era dela: ficou sem material a montante, bloqueada a jusante, em troca de setup, ou esperando um operador que cobria dois postos. A máquina nunca foi a restrição, e o dinheiro deve ir para outro lugar.
A armadilha é de definição. Antes do go-live, a disponibilidade sai de uma folha de turno em que paradas curtas não são anotadas; depois, as paradas são detectadas automaticamente, então o OEE medido cai, porque perdas que sempre estiveram ali finalmente passam a ser contadas. Se ninguém registrou a definição antiga e o número antigo, o terceiro mês parece um retrocesso, e o programa gasta a credibilidade dele se defendendo.
Então escreva o número atual e a definição dele por inteiro: a base de tempo que o percentual usa, de onde vem o tempo de ciclo ideal, como a parada é classificada, se a manutenção programada é excluída e como o retrabalho é tratado. Os dois primeiros decidem a maior parte: tempo calendário, tempo programado e tempo com mão de obra alocada dão à mesma fábrica três números diferentes a partir de dados idênticos, e o tempo de ciclo ideal é o nominal de placa, o melhor já demonstrado, ou um número de roteiro definido uma vez e nunca mais revisto.
Depois capture os fatos mais difíceis de redefinir e que conciliam com o financeiro: unidades expedidas, horas pagas contra horas apontadas, linhas de pedido entregues em atraso, notas de crédito e hora extra. Mais difícil não é impossível, então congele a definição e o sistema de origem de cada um junto com a definição de OEE. Entrega no prazo precisa da própria decisão por escrito, porque a base de data é a definição mais rediscutida de qualquer fábrica: data original confirmada ou última data revisada, pedido ou linha, expedição ou recebimento.
Conectividade e cadastro mestre ficam embaixo de tudo, a análise fica em cima e vale o que essas camadas valem, e o cadastro mestre é a dependência sistematicamente subestimada. Um sistema de execução não distribui uma operação que não está no roteiro, e um programador de produção não sequencia sem tempos-padrão que alguém tenha medido nesta década. Então, antes de assumir uma data, conte as peças sem roteiro, os tempos-padrão em números redondos, os locais que existem na prática e em nenhum sistema, e as BOMs duplicadas.
A outra costura a dimensionar no começo, e não no fim, é a integração com o ERP, onde a dificuldade é acordo, não código: o que um apontamento significa de cada lado e se o chão de fábrica o lança ou um backflush o faz, como quantidades parciais e divisões de ordem se acomodam, o que acontece com um estorno depois que o material já se moveu, onde o refugo é lançado contra o custo-padrão. Cada resposta é uma decisão entre departamentos que nunca precisaram concordar.
Duas dependências de prazo longo raramente aparecem num roadmap técnico. Um registro de execução que atribui produção, paradas e refugo a um operador nomeado é, na Alemanha e em boa parte da Europa, um sistema capaz de monitorar desempenho individual, então exige um acordo de empresa negociado com o conselho de trabalhadores antes do go-live. A aprovação leva meses, então comece no ano um, junto com o cadastro mestre. A substância é curta: se a identidade do operador é armazenada, quem a vê, por quanto tempo, e se o relatório é agregado por desenho.
A segunda vale para produção regulada. Em farmacêutica, dispositivos médicos e boa parte de alimentos, um sistema que registra ou impõe uma decisão de qualidade é escopo validado: plano de validação, qualificação, trilha de auditoria, obrigações de assinatura, controle de mudanças mais lento depois. Relatório, captura de parada e programação ficam fora dessa linha; bloqueio de lote, liberação e a versão de modelo que um sistema de inspeção usa ficam dentro. Dimensione isso antes de comprar o módulo, porque a validação costuma ser o item isolado mais longo do programa.
Dê ao planejamento avançado a premissa de ontem sobre onde o trabalho está, e a sequência é rearranjada na mão antes de o turno começar, o planejador volta para a planilha em algumas semanas, e o veredito é que o software de programação era ruim. Ele não era ruim, era cego.
Dados em tempo real tornam uma programação viável, não executável, e é nessa lacuna que mora a maior parte da decepção com APS. Uma programação sobre dado perfeito continua sendo ignorada se otimiza o objetivo errado, minimizando setup enquanto a fábrica é cobrada por data de entrega; se faltam restrições secundárias, já que sequência de verdade é decidida por ferramental, matriz de competências e mão de obra compartilhada; ou se nada é congelado, já que um otimizador que resolve continuamente entrega ao supervisor um plano novo toda vez que ele olha. Acorde um período congelado e deixe a otimização se agitar fora dele.
Previsão de qualidade tem o mesmo formato: um modelo que prevê refugo precisa de refugo registrado na operação em que aconteceu, com causa e contexto de processo, de máquina e ferramenta até o lote de material.
A manutenção tem uma distinção que o discurso de venda costuma passar por cima. Detecção de anomalia em assinatura de vibração ou de corrente roda sem histórico de falha, o que não é a mesma coisa que rodar sem dado: precisa de semanas de dado de estado saudável cobrindo toda a faixa de operação, ou alarma em toda troca de setup em vez de alarmar em dano, e de sensores montados e amostrados para os modos de falha que interessam. Mesmo assim ela só diz que algo está fora do comum, e saber quais anomalias importaram exige histórico de ordens de manutenção com modo de falha.
Uma câmera mostrando aprovado ou reprovado numa tela também não mudou a fábrica: o veredito tem que se prender a uma ordem de produção, a um lote e a uma versão de modelo dentro do registro de execução e de qualidade, o que faz da inspeção uma capacidade tardia, e não uma porta de entrada. Guias separados cobrem programação de capacidade finita, o que uma programação de APS tem que satisfazer, e onde um CMMS termina e a manutenção preditiva começa.
A TI é parceira, não dona: quando a TI é dona do programa, ela otimiza para integração e segurança, faz as duas bem, e então empaca na adoção, porque ninguém naquela linha responde por o operador usar ou não a tela. Abaixo do dono ficam os usuários-chave, um por área, nomeados, com horas alocadas: são eles que decidem o que uma tela pede e em que ordem, e o chão de fábrica dá ouvidos a eles.
O obstáculo declarado à adoção é quase sempre gente; o obstáculo real costuma ser o desenho da transação. Observe um apontamento durante uma troca de setup, de luva, com a próxima ordem esperando. Se lançar um motivo de parada não muda nada visível, o lançamento vira imposto sobre o turno, pago o mais tarde possível e normalmente como um bloco de ficção no fim. Se ele aciona a manutenção, atualiza o quadro do turno ou ressequencia a próxima ordem, vira parte do trabalho.
Bom desenho de apontamento é específico: terminal na máquina, operação com uma mão e de luva, valores padrão puxados da ordem, e uma lista curta de motivos por tipo de máquina em vez de uma taxonomia em que só meia dúzia de códigos é usada. Quando a transação cabe no trabalho, o treinamento é curto o bastante para ser feito na máquina durante um turno. Quando não cabe, nenhuma quantidade de sala de aula resolve, e um pedido de mais treinamento é muitas vezes um problema de desenho diagnosticado como problema de gente.
Duas coisas passam batido na maioria dos planos de treinamento. A primeira é a correção: apontar uma quantidade boa é fácil de ensinar, enquanto estornar uma errada ou desfazer um apontamento lançado contra a ordem errada é onde um usuário sem treino faz estrago de verdade. A segunda é que treinamento não é um evento, porque supervisor precisa de mais que operador, e novatos, temporários e um chão de fábrica multilíngue chegam continuamente.
Pilotos não escalam por razões desenhadas dentro deles: a melhor linha, as máquinas velhas evitadas, o fornecedor no local todo dia, cadastro mestre curado na mão. Um piloto construído para escalar roda numa linha representativa, inclui pelo menos um ativo difícil de instrumentar, e registra horas por linha, porque esse custo unitário é a única entrada honesta para o plano de rollout.
Critério de saída e data de decisão do rollout são acordados antes de o piloto começar, e o trecho final roda sem o fornecedor. O que importa nesse trecho é a cobertura dele, e não a duração, porque piloto raramente falha em operação normal. Ele falha no primeiro fechamento de período, quando os números têm que conciliar com o ERP e alguém descobre refugo lançado duas vezes, e na primeira religada depois de uma parada, quando os gateways voltam e as contagens em buffer não. Então especifique cobertura: um fechamento de período com a conciliação dele, o mix completo de produtos que aquela linha roda, e uma parada programada com religamento. Na maioria das fábricas isso é um mês ou um ciclo inteiro, não quinze dias.
A licença é a linha negociada com mais afinco, e as linhas que decidem o resultado estão em outro lugar: integração com o ERP e com as máquinas; hardware, de gateways e painéis a sensores de retrofit; limpeza de cadastro mestre; treinamento e o tempo de produção que ele consome; e esforço interno. Esforço interno é a linha mais frequentemente omitida: usuários-chave, o dono, a TI, técnicos instalando gateway, produção perdida no cutover. Se ninguém custeou essas horas, o orçamento está errado por melhor que a licença tenha sido negociada.
O trabalho físico se divide em duas categorias que se programam de formas diferentes. Lançamento de cabo, porta de switch e segmentação entre a rede de automação e a rede corporativa são engenharia comum com prazo longo de fornecimento, e podem andar junto com a produção. Qualquer coisa dentro do painel da máquina não pode: isso é trabalho isolado, que exige bloqueio e etiquetagem e uma parada programada, e na maioria das fábricas uma proibição permanente de abrir painel energizado. Então a restrição real do cronograma de conectividade é quantas janelas de parada ainda restam neste ano e quanto de cada uma a manutenção já reservou. Conectividade se planeja contra o calendário da manutenção, não contra o plano do software.
Depois o custo recorrente, que nenhum orçamento de projeto contém e que o diretor financeiro pergunta primeiro: o custo do ano quatro. Assinatura ou suporte anual continua, e painel industrial e gateway se desgastam mais rápido que hardware de escritório. Acima de tudo, alguém de dentro roda o sistema depois que o fornecedor sai: manutenção do cadastro mestre, mudanças de código de motivo e de roteiro, administração de usuários, absorver cada nova versão. Reserve orçamento à parte para mudança nos doze meses seguintes ao go-live, porque os pedidos que valem a pena financiar só chegam quando o chão de fábrica acredita no que o sistema diz.
Um calendário acrescenta o que a ordem de dependência não consegue: quem decide em cada fronteira, e como dinheiro e horas se distribuem. O ano um resolve as decisões caras de revisitar, e o dono as resolve com o financeiro, a TI e o conselho de trabalhadores, e não com o time de projeto: definições de KPI, estrutura do cadastro mestre, a costura com o ERP, identidade do operador e, numa fábrica regulada, o escopo de validação. O esforço interno tem o pico aqui em relação ao gasto com licença, então um orçamento com formato de projeto de TI convencional já está errado. Há um item que pertence ao ano um e que as fábricas adiam: medir as maiores cargas elétricas para estabelecer uma linha de base, o que é instrumentação e não modelagem, e muitas vezes não é opcional sob uma norma de energia ou uma auditoria.
A fronteira para o ano dois é um julgamento, não uma data, e é cruzada quando o chão de fábrica discute com o número do sistema em vez de ignorá-lo. Fechar uma malha significa que um supervisor ou um gerente da qualidade entrega uma decisão a uma regra, então esse escopo é negociado com as pessoas cuja autoridade se move, e o gasto desloca de horas internas para licença e integração. O ano três ganha a camada baseada em modelo sobre dois anos de registro, e a condição de fronteira dele é ter um dono definido: cada capacidade precisa de uma pessoa nomeada dona do limiar e do calendário de retreinamento. Energia atribuída por peça entra aqui, porque a atribuição precisa do registro de execução que os dois primeiros anos construíram.
Duas condições de parada pertencem à aprovação. Se o chão de fábrica não confia no dado do ano um, o ano dois não começa. E antecipar o ano três porque a diretoria pediu uma iniciativa de IA produz o projeto travado descrito no começo desta página.
Cada etapa precisa de um gate com evidência que você mostraria a um cético. Depois da conectividade, a produção capturada bate com uma contagem manual ao longo de um turno inteiro, dentro de uma tolerância acordada antes do teste. Depois do primeiro número reportado, a planilha antiga continua sendo mantida em paralelo; quando ela discretamente para de ser atualizada, o número foi aceito.
Um gate pertence ao primeiro go-live de execução e é quase sempre pulado: o que a linha faz quando o sistema não está lá. Uma vez que o operador aponta na máquina e a qualidade bloqueia lote por regra, um switch ou uma interface que falhe interrompe a produção: a fábrica trocou uma prancheta por um ponto único de falha. Então defina e teste o modo degradado primeiro: o que o terminal armazena localmente e por quanto tempo, qual é o retorno ao papel, quem pode autorizar rodar sem o sistema, e como o acúmulo é redigitado sem contagem duplicada. Teste puxando a conexão durante um turno rodando, porque failover não testado é a razão comum de um go-live virar incidente de produção.
Depois do registro de execução, dá para reconstituir uma ordem, incluindo paradas, refugo e quem a rodou, no nível de identificação acordado, sem perguntar a uma pessoa. Antes do planejamento, o estoque em processo está correto no início do turno. Uma tendência importa mais que qualquer gate isolado: se cada linha nova custa o que a anterior custou, o programa construiu instalações sob medida em vez de um método.
A Meta Smart Factory cobre as camadas acima como módulos separados, de MES, MRP e APS a qualidade, manutenção, armazém e visão, até a integração com o ERP. A modularidade torna esse sequenciamento comprável por partes, mas a primeira compra não é só um módulo. É um módulo contra uma restrição nomeada em uma área, mais a fundação embaixo dele: conectividade, limpeza de cadastro mestre, a costura com o ERP e as definições acordadas. Essa fundação é a maior parte do esforço do primeiro ano e não aparece em lista de preço, então ela pertence à aprovação como linha própria, e não presumida dentro de uma licença.
As partes difíceis sobrevivem a qualquer escolha de plataforma. Combinar o que os números significam, limpar o cadastro mestre, desenhar transações que o operador conclua sem ser cobrado, e escolher o que parar de fazer são trabalho conjunto. Se é aí que você está, uma conversa sobre sequenciamento para a sua restrição vale mais que uma demonstração de produto.
Fale com os nossos especialistas