KORA Productivity no chão de fábrica: do papel ao OEE validado

O problema não é medir o OEE. É acreditar no número que sai. Numa confecção do Vale do Ave onde o encarregado anota paragens numa folha quadriculada e a administrativa lança tudo no ERP na sexta à tarde, o OEE de segunda-feira é uma ficção retrospetiva: números redondos, causas de paragem inventadas de memória, micro-paragens que ninguém registou porque durar menos de cinco minutos "não vale a pena". O controlo do chão de fábrica em tempo real resolveu o conceito. Neste artigo resolve-se o detalhe técnico: como é que a captura em KORA Productivity produz um OEE que sobrevive a uma auditoria de melhoria contínua.

A tese: a maior parte dos projetos de OEE em Portugal falha não na tecnologia mas na definição do denominador. Quem cronometra o tempo planeado errado — inclui ou exclui mudanças de série, paragens sindicais, refeições — produz um OEE que sobe e desce por artefacto de configuração, não por desempenho real. O terminal industrial é a parte fácil. A parte difícil é decidir, com o plant manager e o controller na mesma sala, o que conta como tempo produtivo. Faça isso mal e terá um dashboard bonito que ninguém usa para decidir nada.

Passámos por dezenas destas salas. A conversa arranca sempre com entusiasmo — todos concordam que "precisamos de medir a eficiência" — e descarrila na primeira pergunta concreta: a hora de almoço conta? A partir daí, o projecto vive ou morre conforme a organização for capaz de decidir e escrever o que decidiu. Este texto é o mapa dessa decisão, camada a camada, com os números que sustentam cada escolha e as armadilhas que já vimos partir implementações em produção.

1. Arquitetura recomendada

KORA Productivity assenta em três camadas que não devem ser confundidas: captura, agregação e validação. A tentação de ir do terminal direto ao dashboard é o erro que produz OEE não-auditável. Quando o número que aparece no ecrã do plant manager é o mesmo bruto que saiu do terminal, sem passar por validação, basta um operador distraído ou um corte de rede para contaminar a semana inteira.

O modelo de referência para esta separação de camadas não é invenção nossa: a norma ISA-95 (IEC 62264) define desde há duas décadas os níveis de integração entre o chão de fábrica e os sistemas de gestão. O que a norma chama "nível 3" — o MES, a camada de execução — é exatamente onde vive a agregação e a validação. Confundir nível 1 (o sinal do posto) com nível 4 (o ERP) é o pecado original de metade dos projectos que herdámos para arranjar.

Camada de captura — o terminal e o operador

No posto, um terminal industrial (Android endurecido ou PC touch IP65 conforme o ambiente) regista três eventos elementares: início/fim de operação, quantidade produzida e quantidade rejeitada, e código de paragem. Nada mais. O operador não calcula OEE, não interpreta nada — pica um código de barras da ordem de fabrico, confirma o artigo, e a partir daí o relógio corre.

A escolha do hardware não é detalhe cosmético. Numa nave de acabamentos têxteis, a humidade e os vapores de fixação matam eletrónica de consumo em meses; o IP65 não é luxo, é sobrevivência. Numa linha de costura, o problema é outro — o operador tem as mãos ocupadas com tecido e o terminal tem de estar ao alcance de um toque, com botões grandes, sem menus profundos. Já vimos terminais tecnicamente perfeitos serem ignorados porque estavam a dois metros do posto. O operador não anda dois metros a cada paragem. Simplesmente não pica.

Regra dura: a paragem é imputada por defeito ao estado anterior até o operador a classificar. Se a máquina para e ninguém toca no terminal, o tempo acumula como "paragem não classificada". Esse balde é o indicador de saúde do próprio sistema — se cresce acima de 8-10% do tempo de calendário, a captura não está a ser adotada e o OEE ainda não é confiável.

Um OEE de 82% com 15% de paragens não classificadas não é um OEE de 82%. É um palpite com casas decimais.

A ergonomia da picagem — porque é que a UI decide o projecto

Em confeção e calçado, onde raramente há PLC para contar automaticamente, tudo depende do operador tocar no ecrã no momento certo. Isto muda a hierarquia de prioridades: numa fábrica com sinal máquina, a UI é secundária; numa nave de costura, a UI é o projecto.

O princípio é implacável: cada toque adicional que se pede ao operador reduz a taxa de classificação. Um ecrã que exige três confirmações para registar uma avaria vai ser contornado — o operador pica "produzir" e resolve a avaria em silêncio, porque parar para navegar custa-lhe produção pessoal. O desenho tem de assumir que o operador está apressado, com as mãos ocupadas e sem paciência para hierarquias de menu. Códigos de paragem visíveis num ecrã, um toque, seguir. Se a árvore de códigos tem quarenta entradas, ninguém a usa; oito a doze códigos bem escolhidos cobrem 90% das paragens reais.

Camada de agregação — do evento ao turno

Os eventos crus vão para uma base transacional. A agregação por operação, ordem de fabrico, posto e turno faz-se em processo separado, tipicamente de minuto a minuto para o painel de linha e consolidado ao fecho de turno para o histórico. Manter a captura desacoplada da agregação permite recalcular o passado quando se corrige uma definição — e vai corrigir, várias vezes, no primeiro trimestre.

Este ponto merece ênfase porque é onde os fornecedores generalistas cortam custos. Um sistema que agrega no momento da captura — que "cola" o evento cru ao número final — não permite reprocessar. Quando, ao fim de seis semanas, descobre que classificou mudanças de série como paragem não-planeada em vez de setup, num sistema acoplado tem de viver com o erro histórico. Num sistema desacoplado, corrige a regra e recalcula três meses de dados numa noite. A diferença entre os dois modelos não se vê na demo. Vê-se no terceiro mês.

Camada de validação — o encarregado antes do ERP

Esta camada é a que separa um projeto sério de um brinquedo. Antes de o turno consolidar para o ERP MULTI, o encarregado revê num ecrã as paragens não classificadas e as quantidades anómalas. Não altera o cru; anota a causa. O dado validado alimenta o histórico e o Qlik Sense para BI. O dado cru fica intacto para auditoria. Esta separação é o que torna o número defensável perante um cliente que exige demonstração de melhoria contínua ou perante um financiamento PT2030 que pede relatório técnico com indicadores.

O ponto de fricção aqui é humano: o encarregado tem de dedicar quinze a vinte minutos por turno a esta validação. Nas primeiras semanas resiste — "não tenho tempo para isto". Tem. O que não tinha antes era a informação a chegar num ecrã em vez de numa folha ilegível. A validação bem desenhada mostra só as anomalias, não o turno inteiro: as três paragens por classificar, as duas quantidades fora do esperado. Se o encarregado tiver de rever tudo, o projecto morre de exaustão. Se rever só o que está errado, a tarefa cabe no fecho de turno sem drama.

O dado cru nunca se altera. Corrige-se a interpretação, nunca o facto. É essa disciplina que faz a diferença entre um indicador e uma narrativa conveniente.

2. Parâmetros, métricas e thresholds

OEE = Disponibilidade × Desempenho × Qualidade. Trivial na fórmula, traiçoeiro nos limites. Os valores abaixo são referências operacionais defensáveis para captura industrial em confeção e calçado; ajuste ao seu processo.

Sobre o alvo: perseguir 85% no primeiro ano é receita para desmotivar a linha. A produtividade por hora trabalhada em Portugal rondava dois terços da média da UE em anos recentes, segundo dados do Eurostat — o problema estrutural não se resolve com uma meta de PowerPoint. Ganhe primeiro a fiabilidade do número, depois discuta o alvo com dados na mão. Ligar OEE a práticas de TPM e Kaizen só funciona quando o número é confiável.

Porque é que 85% é uma armadilha

O número "world-class 85%" circula em toda a literatura de manufacturing e é tecnicamente correto — decompõe-se em cerca de 90% de disponibilidade, 95% de desempenho e 99% de qualidade. O problema é o contexto de aplicação. Esses valores derivam de linhas automatizadas de produção em série contínua, com PLC a contar cada peça e paragens medidas ao segundo. Uma nave de confeção com trinta operadores a coser em ritmo humano não é comparável.

Numa confeção do Vale do Ave que arranca a captura, é comum o OEE real medido nas primeiras semanas situar-se abaixo dos 50% — não porque a fábrica seja má, mas porque pela primeira vez está a contar honestamente as micro-paragens, as esperas de material e os arranques de série que antes desapareciam na folha de papel. Anunciar à administração que a fábrica "só" faz 48% quando toda a gente achava que fazia 80% é uma conversa difícil. Prepare-a. O 48% honesto vale infinitamente mais do que o 80% imaginado, mas essa verdade tem custo político. Assuma-o antes do arranque.

Um OEE que desce quando começa a medir a sério não é um problema do sistema. É o sistema a funcionar. O 80% de antes é que era mentira.

O detalhe do tempo planeado

A decisão mais consequente: o denominador da disponibilidade. Recomendação firme — use tempo planeado de produção (calendário menos paragens planeadas: refeições, manutenção agendada, ausência de encomenda) e não o tempo de calendário. E torne essa definição visível no dashboard. O erro clássico é o controller calcular sobre calendário e o plant manager sobre tempo planeado; ao fim de dois meses estão a discutir números que diferem 15 pontos e ninguém percebe porquê.

Vale a pena descer ao concreto de cada caso limítrofe, porque é aqui que as reuniões descarrilam:

• Refeições: excluir do tempo planeado. A máquina não estava agendada para produzir durante o almoço. Incluí-las penaliza a disponibilidade por algo que ninguém controla.
• Mudança de série (setup): incluir no tempo planeado mas classificar como paragem planeada. O setup é tempo produtivo perdido que se pode reduzir — se o excluir do denominador, esconde uma das maiores alavancas de melhoria em calçado, onde as mudanças de modelo são constantes.
• Ausência de encomenda: excluir. Não faz sentido penalizar a linha por não haver trabalho — isso é um problema comercial, não de eficiência de produção.
• Manutenção preventiva agendada: excluir do tempo planeado. Foi decidida e agendada; é boa gestão, não perda.
• Avaria não-planeada: incluir no tempo planeado como perda de disponibilidade. É exatamente o que o OEE existe para capturar.

Escreva estas seis linhas numa tabela, faça o controller e o plant manager assinarem, e cole-a na parede da sala de reuniões. Parece burocracia. É a diferença entre um indicador estável e uma renegociação semanal do denominador.

Disponibilidade, desempenho e qualidade — o que cada fator esconde

A grande vantagem do OEE sobre uma métrica única de "eficiência" é a decomposição. Um OEE de 60% pode esconder três patologias completamente diferentes, cada uma com remédio distinto:

• Disponibilidade baixa (ex.: 70%): a máquina para muito. Avarias, esperas de material, mudanças de série demoradas. O remédio é manutenção e logística interna, não pressão sobre o operador.
• Desempenho baixo (ex.: 80%): a máquina anda mais devagar do que o tempo de ciclo padrão. Micro-paragens, arranques lentos, ou — muito comum — tempo de ciclo padrão desactualizado que faz a realidade parecer má.
• Qualidade baixa (ex.: 90%): produz-se mas rejeita-se. Problema de matéria-prima, de afinação, ou de método. Aqui o Pareto de defeitos por causa é indispensável.

Quem só olha para o 60% agregado não sabe onde atuar. Quem vê 70% × 80% × 90% sabe que o problema é disponibilidade e vai investigar as paragens. É por isto que o dashboard tem de mostrar sempre os três fatores, nunca só o produto. O Qlik Sense permite descer do OEE agregado ao Pareto de causas de paragem por linha e turno em dois cliques — e é aí que a melhoria contínua acontece, não no número de topo.

3. Configuração prática

Snippets ilustrativos. A parametrização real faz-se na consola de administração, mas o modelo mental é este.

Definição da árvore de estados e códigos de paragem — a base de tudo:

# Estados do posto (mutuamente exclusivos)
estado: PRODUZIR      -> conta em tempo_produtivo
estado: SETUP         -> paragem planeada (mudanca de serie)
estado: MANUTENCAO    -> paragem planeada se agendada, nao-planeada se avaria
estado: PARADO        -> paragem nao-planeada
estado: SEM_ENCOMENDA -> exclui do tempo planeado

Codigos de paragem (o operador escolhe apenas destes)
P01  avaria_mecanica      -> disponibilidade
P02  falta_material       -> disponibilidade
P03  mudanca_serie        -> setup (planeada)
P04  ajuste_qualidade     -> disponibilidade
P05  micro_paragem        -> auto, se 30s <= t < 300s
P99  nao_classificada     -> BALDE (alvo: minimizar)

Note a regra dos estados mutuamente exclusivos. Um posto nunca está em dois estados ao mesmo tempo. Parece óbvio, mas os sistemas mal desenhados permitem sobreposições — máquina "a produzir" e "em setup" simultaneamente — que tornam o somatório de tempos superior ao tempo real de calendário. Quando isso acontece, a disponibilidade pode dar valores acima de 100% e todo o número perde credibilidade instantaneamente.

Regra de cálculo do OEE por turno, em pseudocódigo comentado:

# tempo_planeado = calendario - (refeicoes + manut_agendada + sem_encomenda)
disponibilidade = tempo_produtivo / tempo_planeado

desempenho usa tempo de ciclo padrao da operacao (ficha tecnica)
desempenho = (qtd_total * tempo_ciclo_padrao) / tempo_produtivo

qualidade sobre quantidade, nao sobre tempo
qualidade = (qtd_total - qtd_rejeitada) / qtd_total

oee = disponibilidade * desempenho * qualidade

GUARDA: se nao_classificada > 8% do calendario -> oee marcado "nao_fiavel"
if paragem_nao_classificada / calendario > 0.08:
    oee.flag = "NAO_FIAVEL"

Esse último guarda é a peça que os fornecedores generalistas não põem. Sem ele, um OEE ótimo pode esconder metade do turno por classificar. A flag "não fiável" não é um erro — é uma funcionalidade. Diz honestamente ao gestor: não decida com base neste número, primeiro resolva a captura. Um sistema que finge sempre saber é mais perigoso do que um que admite quando não sabe.

O caso do calçado — três eixos de complexidade

Em calçado, a configuração ganha uma camada que a confeção genérica não tem. Uma coleção de amostras em Felgueiras tem 800 a 1200 SKUs distribuídos por três eixos — cor, tamanho e forma/largura. O apontamento de produção não pode ser por "artigo" genérico; tem de descer ao nível cor-tamanho para que a quantidade produzida e a rejeição fiquem associadas ao SKU exato.

Isto tem consequência direta no OEE. O tempo de ciclo padrão varia por modelo — uma bota de senhora com costura decorativa não tem o mesmo ciclo de uma sapatilha simples. Se o sistema usar um tempo de ciclo médio para toda a coleção, o desempenho fica distorcido em ambos os sentidos: parece mau nos modelos complexos, ótimo nos simples, e a média não diz nada. A ficha técnica tem de ter tempo de ciclo por operação e por família de modelo, e a captura tem de saber qual está a correr. É esta granularidade que os ERPs generalistas não modelam e que obriga a um sistema vertical.

Retenção do dado e o RGPD do apontamento

O apontamento de produção liga quantidade a operador. Isso significa que, tecnicamente, o histórico permite reconstruir o desempenho individual de cada trabalhador — e aí entra o RGPD e a Lei 58/2019. Não é um detalhe menor. Medir produção por posto é legítimo; usar esse dado para avaliação individual disciplinar sem informação prévia e base legal é problema.

Recomendação: defina no arranque a finalidade do dado (melhoria de processo, não vigilância individual), documente-a, e configure a retenção do dado cru com granularidade individual dentro do prazo estritamente necessário. Para efeitos de OEE, o que interessa é o desempenho do posto e da linha — a identificação individual serve para corrigir apontamentos, não para construir rankings. Manter esta fronteira clara não é só conformidade legal; é o que impede a linha de começar a sabotar a captura no dia em que perceber que o número serve para punir.

4. Integrações e dependências

KORA Productivity não vive isolado. O que liga onde:

• ERP MULTI → KORA: ordens de fabrico, artigos, tempos de ciclo padrão da ficha técnica, estrutura de postos. A ficha técnica é a fonte da verdade do desempenho — se os tempos-padrão estão errados, o OEE também está.
• KORA → ERP MULTI: quantidades produzidas e rejeitadas confirmadas, consumo real, apontamento de mão de obra. Fecha o circuito do MRP.
• KORA → Qlik Sense: dataset validado para dashboards de OEE por linha, turno, artigo e causa de paragem (Pareto).
• KORA ↔ pplPortal: alinhamento de turnos e presenças, para o denominador do tempo não incluir horas de operador ausente. Ver assiduidade e turnos em fábrica.
• KORA ↔ rastreabilidade: o apontamento por ordem liga produção a lote, alimentando a rastreabilidade lote-a-lote exigida pela pressão de compliance da indústria têxtil.
• Multiplanta: consolidação entre unidades via Multi Connect quando há mais do que uma fábrica.

Do lado da captura de sinal máquina: onde houver PLC ou contador, integre por sinal digital para eliminar o fator humano na contagem. Onde não houver — e em confeção raramente há — a picagem do operador é o que existe, e o desenho da UI passa a ser crítico. Um evento a mais no ecrã e a linha ignora o terminal. A ligação a este mundo de máquinas conectadas é o que a Indústria 4.0 promete e raramente entrega sem trabalho de integração sério.

A ficha técnica como fonte da verdade

Vale insistir neste ponto porque é o que mais projectos subestima. O desempenho no OEE é calculado contra o tempo de ciclo padrão que vem da ficha técnica no ERP MULTI. Se esse tempo estiver errado, nenhuma sofisticação da captura salva o número.

O problema é que a ficha técnica raramente é mantida. Muitas fábricas têm tempos-padrão definidos no arranque do sistema, há anos, e nunca revistos. Entretanto o método mudou, a máquina foi afinada, o operador ganhou destreza — e o tempo real afastou-se do padrão. Quando finalmente se liga o OEE, o desempenho aparece cronicamente distorcido e a linha conclui, corretamente do seu ponto de vista, que "o sistema está sempre a dizer mal". A auditoria dos tempos-padrão contra medição real no primeiro mês não é opcional. É a fundação sobre a qual todo o resto assenta.

O circuito fechado com o MRP e o planeamento

Quando o KORA devolve ao ERP MULTI as quantidades reais produzidas e o consumo real, fecha-se um circuito que muda a qualidade do planeamento. O MRP deixa de trabalhar com quantidades teóricas — "deviam ter-se produzido 500 peças" — e passa a trabalhar com o real. Isto tem impacto direto na promessa de prazo à casa-mãe.

Para uma confeção que subcontrata para grandes marcas — Inditex, Decathlon, Tom Tailor, Lacoste — a capacidade de dizer com precisão quanto se produziu ontem e quanto se produzirá amanhã, com base em OEE real e não em optimismo, é uma vantagem comercial concreta. A casa-mãe não quer promessas; quer previsibilidade. Um OEE fiável alimenta um planeamento fiável, que alimenta uma promessa de entrega que se cumpre. É esta cadeia que transforma um indicador de chão de fábrica numa alavanca de negócio.

5. Armadilhas operacionais

O que vimos partir projetos em produção — e o que fazer.

• Tempos de ciclo padrão desatualizados. A ficha técnica diz 45 s/peça, a linha faz 62 s há dois anos. O desempenho aparece cronicamente abaixo de 75% e a linha conclui que o sistema "está sempre a dizer mal". Solução: audite os tempos-padrão no primeiro mês, contra medição real, antes de mostrar OEE a alguém.
• Rede fabril que cai. Dye houses e naves metálicas comem Wi-Fi. Sem modo offline no terminal, cada micro-corte gera buracos de captura que viram "não classificado". Exija buffer local no terminal com sincronização diferida. Se a cobertura é má, resolva a rede antes do OEE — não depois.
• O balde do "não classificado" que ninguém olha. Configure o guarda dos 8% e ponha-o no dashboard do encarregado, não escondido num relatório mensal. O que não se vê ao fim do turno não se corrige.
• Micro-paragens que desaparecem. Sem threshold de 30 s, arranques e pequenos encravamentos entram no desempenho e escondem o verdadeiro problema de disponibilidade. Configure a captura automática de micro-paragem — não conte com o operador para picar uma paragem de 40 segundos.
• Denominador em guerra civil. Já descrito: controller sobre calendário, plant manager sobre tempo planeado. Feche a definição numa ata assinada por ambos antes do arranque. Sim, uma ata. É a única forma de o número parar de ser negociado todas as semanas.
• Rollout que tira o chefe de linha do posto. Formar operadores num terminal simples leva minutos. Reconfigurar mentalidades leva meses. Não faça big-bang em todas as linhas — arranque numa linha piloto, valide o número contra a folha antiga durante duas semanas em paralelo, e só depois alargue.
• Rejeições registadas no fim, em bloco. Se a qualidade só se lança ao fecho, perde-se a associação da rejeição à operação e à causa. Force o registo de rejeição no momento e no posto. O Pareto de defeitos só vale se tiver granularidade.
• OEE usado como vara para bater no operador. No dia em que a linha perceber que o número serve para punir, começa a jogar contra a captura — pica produção que não fez, esconde paragens. Posicione OEE como ferramenta de melhoria, não de disciplina. Isto não é boa vontade; é engenharia de fiabilidade do dado.

Todas estas armadilhas têm uma raiz comum: tratar o OEE como um problema de software quando é um problema de organização com uma componente de software.

A armadilha da mão-de-obra envelhecida

Há uma dimensão que raramente aparece nos manuais e que é central no Norte de Portugal: a idade média da mão-de-obra na confeção. Uma parte significativa dos operadores tem décadas de ofício e pouca familiaridade com ecrãs táteis. Introduzir um terminal a alguém que coseu quarenta anos sem tocar num computador não é trivial e não se resolve com um folheto de formação.

O que funciona: reduzir a picagem ao mínimo absoluto — idealmente um toque para confirmar a ordem, e depois o sistema assume produção até haver uma paragem —, usar ícones grandes e reconhecíveis em vez de texto, e emparelhar cada operador experiente com o encarregado nas primeiras semanas. O que não funciona: assumir que a resistência é preguiça. Não é. É a experiência de quem já viu iniciativas da administração aparecerem e desaparecerem. A adoção conquista-se mostrando que o terminal lhes tira trabalho — não lhes acrescenta —, e isso só se prova com o tempo.

A armadilha do financiamento que espera pelo indicador

Uma candidatura a PT2030, PRR ou Norte 2030 para digitalização industrial exige, no relatório técnico, indicadores de resultado — tipicamente ganhos de produtividade ou de eficiência mensuráveis. Muitas empresas montam a candidatura, adquirem o sistema, e só depois descobrem que não têm baseline: não sabem qual era o OEE antes, porque nunca o mediram de forma fiável.

Sem baseline, o relatório técnico fica exposto — como demonstrar melhoria de um número que nunca existiu? A recomendação é dura mas necessária: se pretende financiar a digitalização com fundos, meça o baseline durante as semanas de captura em paralelo antes de fechar a candidatura, ou estabeleça claramente que o primeiro período de operação serve para construir a linha de base. Um avaliador técnico distingue perfeitamente uma melhoria demonstrada de um número inventado a posteriori.

6. Decisão técnica final

Sem hedging. Por dimensão e setor:

A sequência de arranque que recomendamos

Independentemente do perfil, a ordem das operações importa mais do que a escolha de tecnologia. A sequência que vimos funcionar:

1. Semana 0: auditoria da rede fabril e dos tempos-padrão da ficha técnica. Se qualquer um dos dois estiver mau, pare aqui e resolva.
2. Semana 0-1: reunião de definição do denominador com plant manager e controller. Ata assinada. Árvore de estados e códigos de paragem fechada.
3. Semana 1-2: instalação de terminais na linha piloto. Formação dos operadores. Captura em paralelo com a folha de papel.
4. Semana 2-4: validação diária pelo encarregado. Vigilância do balde de não-classificadas. Comparação do número KORA com o registo antigo.
5. Mês 2: quando o não-classificado desce abaixo dos 8% na linha piloto, o número torna-se oficial. Só então alargar às restantes linhas.
6. Mês 3+: ligar ao Qlik Sense, construir os Pareto, começar a melhoria contínua com dados fiáveis.

Uma nota de honestidade: em fábricas onde a captura ainda é em papel, o primeiro ganho real não é o OEE — é deixar de perder duas horas de administrativa por semana a transcrever folhas ilegíveis. O OEE fiável vem no segundo ou terceiro mês, quando o balde de não-classificadas desce abaixo dos 8%. Prometer o dashboard perfeito na semana um é como prometer que o chefe de armazém larga o rádio durante o rollout: não acontece.

7. Como a INFOS implementa

Implementamos KORA Productivity acoplado ao ERP MULTI com arranque em linha piloto e duas semanas de captura em paralelo com o método antigo, para validar o número antes de o tornar oficial. Configuramos a árvore de estados, o threshold de micro-paragem, o guarda de não-classificadas e a definição de tempo planeado em conjunto com plant manager e controller — porque essa definição é do cliente, não nossa. O dado validado alimenta Qlik Sense para os Pareto de paragem e defeito. O mesmo modelo de mobilidade que resolve o chão de fábrica resolve o armazém e as rotas de venda — o papel sai do processo inteiro, não só de uma nave.

O que aprendemos em três décadas de indústria no Norte é que a tecnologia é a parte fácil. O terminal instala-se numa tarde. A árvore de estados configura-se em horas. O que leva tempo — e o que separa um projecto que vive de um que fica na gaveta — é a organização decidir o que quer medir e comprometer-se com a disciplina da validação diária. Onde essa disciplina existe, o OEE torna-se a espinha dorsal da melhoria contínua. Onde não existe, é mais um dashboard bonito.

O OEE fiável não é o fim. É a condição de entrada para tudo o resto: melhoria contínua, negociação de prazos com a casa-mãe, relatório técnico de financiamento que passa à primeira. Enquanto o número for uma ficção da sexta à tarde, cada decisão em cima dele é um palpite caro.

Fontes

• Eurostat — Labour productivity per hour worked (Portugal vs. UE).
• INE — Sociedade da Informação e do Conhecimento, inquérito à utilização de TIC nas empresas.
• ATP — Associação Têxtil e Vestuário de Portugal, dados do setor ITV.
• APICCAPS — Associação Portuguesa dos Industriais de Calçado, Componentes e Artigos de Pele.
• IEC 62264 / ISA-95 — Enterprise-control system integration (modelo de referência de níveis de produção).
• Regulamento (UE) 2016/679 (RGPD) e Lei 58/2019 — proteção de dados pessoais.

Perguntas frequentes

O que é o OEE e por que razão é difícil confiar no número que sai?

O OEE mede a eficiência operacional, mas o maior problema não é medi-lo — é acreditar no resultado. Quando a captura é manual e retrospetiva (anotações em papel, lançamento no ERP dias depois), os números tornam-se ficção: paragens inventadas de memória, micro-paragens ignoradas, valores redondos sem base real. A solução é captura em tempo real no chão de fábrica.

Qual é a principal razão pela qual os projetos de OEE falham em Portugal?

A maioria falha não na tecnologia, mas na definição do denominador — o tempo planeado. Quando se define mal o que conta como tempo produtivo (incluindo ou excluindo mudanças de série, paragens sindicais, refeições), o OEE sobe e desce por artefacto de configuração, não por desempenho real. Sem decisão clara e documentada, o dashboard fica bonito mas inútil.

O que é a arquitetura de três camadas do KORA Productivity?

KORA Productivity separa captura (terminal regista eventos), agregação (processa dados por turno) e validação (encarregado revê antes de consolidar). Confundir estas camadas — por exemplo, ir direto do terminal ao dashboard — produz um OEE não-auditável. Um operador distraído ou corte de rede contamina os dados. A separação permite recalcular o passado quando se corrigem definições.

O que deve registar o terminal no posto de trabalho?

O terminal regista apenas três eventos: início/fim de operação, quantidade produzida e quantidade rejeitada, e código de paragem. Nada mais. O operador não calcula OEE nem interpreta dados — pica um código de barras da ordem, confirma o artigo e o relógio corre. A simplicidade garante adoção e fiabilidade.

Como se escolhe o hardware do terminal industrial?

A escolha não é cosmética. Numa confecção têxtil com humidade e vapores, IP65 é obrigatório; numa linha de costura, o terminal deve estar a um toque do operador com botões grandes e sem menus profundos. Se estiver a dois metros, o operador não vai andar lá para registar paragens. A ergonomia decide o sucesso do projeto.

O que significa uma taxa alta de paragens não classificadas?

Paragens não classificadas acumulam quando o operador não toca no terminal. Se ultrapassam 8-10% do tempo de calendário, significa que a captura não está a ser adotada e o OEE ainda não é confiável. Um OEE de 82% com 15% de paragens não classificadas não é um número real — é um palpite com casas decimais.

Quantos códigos de paragem devem estar disponíveis no ecrã?

Oito a doze códigos bem escolhidos cobrem 90% das paragens reais. Se a árvore tem quarenta entradas, ninguém a usa. Cada toque adicional que se pede ao operador reduz a taxa de classificação. O desenho deve assumir que o operador está apressado, com as mãos ocupadas e sem paciência para navegar menus profundos.