Qlik Sense em produção industrial: da recolha ao dashboard operacional

Numa fábrica de malhas em Vizela, o diretor de produção tem um ecrã de 55 polegadas na parede do escritório. Mostra um dashboard Qlik Sense com OEE por máquina, atualizado a cada 15 minutos. Bonito. Só que ninguém no chão-de-fábrica o vê — está virado para o corredor da administração. E os dados que alimenta vêm de um ficheiro Excel que a Dona Fernanda preenche às 17h30, com os números que os encarregados lhe passam de cabeça. O dashboard existe. A gestão baseada em dados, não.

Este artigo defende uma tese incómoda: na produção industrial portuguesa, o Qlik Sense quase nunca falha por causa do Qlik Sense. Falha porque a recolha a montante é fantasia, porque ninguém definiu o que "unidade produzida" significa, e porque o dashboard foi desenhado para impressionar visitas em vez de mudar uma decisão às 10h da manhã. O software de BI é a parte fácil. A parte difícil é tudo o que acontece antes de o dado chegar ao motor associativo.

Vamos dizê-lo de outra forma, para não haver dúvida. Comprar Qlik Sense sem arrumar a recolha é comprar um microscópio potentíssimo para observar uma lâmina em branco. A resolução é magnífica. Não há nada para ver. E este erro repete-se em fábricas com 20 pessoas e em grupos com 400 — muda a escala, não muda a natureza.

1. O problema operacional real

Comecemos pelo que se vê nas fábricas quando lá entramos. Não pela teoria.

O relatório que chega tarde de mais para servir

Numa confecção perto de Famalicão, o fecho de mês demora três dias. Não porque as contas sejam complexas — porque a produção real de cada linha vive em cadernos, em memórias de encarregados e num Excel partilhado que três pessoas editam ao mesmo tempo e ninguém sabe qual é a versão boa. Quando o número consolidado chega ao CEO, já é dia 4 do mês seguinte. A decisão que ele podia ter tomado — parar uma encomenda que estava a dar prejuízo à peça — passou o prazo.

O problema não é a falta de relatório. É que o relatório descreve um passado morto. Um dashboard operacional que não conseguir responder a "o que está a acontecer agora" é decoração.

Repare-se na assimetria. A decisão que dá dinheiro é quase sempre uma decisão de correção rápida: parar uma linha que está a produzir refugo, reafectar um operador de uma máquina parada por falta de fio para outra que está a atrasar a encomenda da Inditex, antecipar que um lote de malha vai chegar tarde ao acabamento. Estas decisões têm janela de minutos ou horas. Um relatório mensal, por mais bonito que seja, chega sempre depois de a janela ter fechado. Está a informar o funeral, não a evitar a doença.

O caso da encomenda que sangrou em silêncio

Um padrão que vemos vezes de mais numa confecção subcontratada: uma encomenda de 4 000 peças para uma casa-mãe internacional, com preço fechado por peça, negociado com uma cadência-alvo de produção. Se a cadência real ficar 18% abaixo do previsto — porque o tecido é mais difícil de coser, porque a costureira experiente foi de baixa, porque o setup da máquina demorou o dobro — a margem evapora. E numa confecção sem captura em tempo real, isto só se descobre no fecho. A encomenda já saiu. O prejuízo já está lançado. Ninguém decidiu conscientemente perder dinheiro; simplesmente ninguém viu a tempo.

Numa confecção com margem de subcontratação, não é a encomenda perdida que mata — é a encomenda ganha e produzida a prejuízo, que ninguém viu a sangrar até ao fecho.

Os três sítios onde o dado se perde

Em três décadas a implementar sistemas em indústria portuguesa, vemos sempre os mesmos pontos de fuga:

• A recolha manual no posto — o operador que aponta a quantidade num papel e transcreve no fim do turno, com os erros de transcrição que isso implica e a tentação de "arredondar" para o número que o encarregado quer ouvir.
• A definição ambígua de métrica — "produção do dia" inclui a peça reprocessada? Conta o refugo? Conta o tempo de setup como paragem ou como produção? Cada encarregado responde de forma diferente, e o dashboard soma maçãs com laranjas.
• O silo entre ERP e chão-de-fábrica — o ERP MULTI sabe o que foi encomendado e faturado; o chão-de-fábrica sabe o que foi realmente feito. Se os dois não falam, o BI escolhe um lado e mente sobre o outro.

Um dashboard alimentado por recolha manual não é business intelligence — é a mesma folha de cálculo, agora com cores.

A economia do erro de transcrição

Há quem despreze o erro de transcrição como um detalhe. Não é. Considere uma fábrica com 60 postos, três turnos, cada operador a registar cerca de oito lançamentos por turno. São mais de 1 400 registos manuais por dia. Se apenas 2% tiverem erro — uma taxa optimista para escrita à mão transcrita no fim do turno — são quase 30 dados errados a entrar no sistema todos os dias. Ao fim do mês, o erro acumulado no OEE, no custo por unidade e no consumo de matéria não é ruído aleatório: tende a ter viés, porque o operador arredonda sempre no mesmo sentido, o do encarregado contente. O dashboard não mostra incerteza. Mostra um número exato e falso.

Porque é que a folha de cálculo sobrevive tanto tempo

Segundo o INE, em 2025 apenas 45% das empresas em Portugal faziam análise de dados (big data/analytics), mais 6,4 pontos que em 2023. A maioria continua a gerir de olho e de instinto. E a folha de cálculo sobrevive porque funciona o suficiente — até ao dia em que a Inditex pede rastreabilidade de lote por lote, ou o cliente alemão exige um relatório de qualidade que o Excel simplesmente não consegue produzir sem duas noites de trabalho. Falamos mais sobre esta transição em Qlik Sense em indústria portuguesa: da folha de cálculo à decisão.

Há ainda um motivo cultural que raramente se admite em voz alta. A folha de cálculo é propriedade de alguém. A Dona Fernanda que a preenche detém, na prática, um monopólio sobre a verdade da produção. Digitalizar a recolha tira-lhe esse poder — e é natural que resista, consciente ou inconscientemente. Quem já viu uma implementação encalhar no "o Excel dá para tudo, para quê complicar" sabe que raramente é uma objecção técnica. É territorial. Ignorar esta dimensão humana é a forma mais rápida de um bom projecto de BI morrer na primeira semana.

O efeito da pressão da cadeia de fornecimento

O que empurra, no fim, é o cliente. A Estratégia da UE para os Têxteis Sustentáveis e Circulares e o futuro Passaporte Digital do Produto vão exigir rastreabilidade que um caderno não fornece. Quando uma marca pede a composição, a origem do fio, o consumo de água e energia por lote e a cadeia de subcontratação, a fábrica que gere em Excel descobre, de um dia para o outro, que a sua verdade não é auditável. E não há relatório de última hora que resolva a ausência de captura estruturada durante o ano inteiro. A pressão regulatória e de marca está a transformar o BI de luxo em condição de acesso ao mercado.

2. O que é exatamente Qlik Sense em produção industrial

Definição rigorosa

O Qlik Sense é uma plataforma de business intelligence e visualização de dados baseada num motor associativo em memória. Traduzindo do folheto para a fábrica: carrega dados de várias fontes (ERP, recolha de chão-de-fábrica, ficheiros, bases de dados), mantém-nos em memória e permite explorar as relações entre eles sem ter de construir antecipadamente cada consulta. Clica em "máquina 4" e todo o dashboard reage — produção, paragens, refugo, operador — mostrando o que está associado e, criticamente, o que não está.

Aquele "o que não está" é a parte que distingue o modelo associativo dos relatórios tradicionais. Num relatório clássico, filtra por máquina 4 e vê os dados da máquina 4. No modelo associativo, ao selecionar a máquina 4, o resto do dashboard mostra-lhe também, a cinzento, os operadores que nunca trabalharam nessa máquina, os turnos em que ela esteve parada, os motivos de paragem que não ocorreram. A ausência é informação. Numa análise de qualidade, saber que um determinado defeito nunca apareceu num certo turno pode ser tão revelador como saber onde ele apareceu.

Em produção industrial, isto materializa-se em três famílias de indicadores: eficiência (TPM, OEE, disponibilidade, cadência), qualidade (taxa de refugo, reprocessos, não-conformidades por lote) e custo (custo real por unidade, desvio ao standard, consumo de matéria por ordem de fabrico).

OEE — o número que todos citam e poucos calculam bem

O OEE (Overall Equipment Effectiveness) multiplica três fatores: disponibilidade × desempenho × qualidade. Um OEE de 60% não é "60% de bom" — é o produto de, por exemplo, 85% de disponibilidade, 80% de desempenho e 88% de qualidade. O erro clássico é uma fábrica reportar OEE de 90% porque só está a medir a disponibilidade e chamar-lhe OEE. O Qlik Sense não resolve isto — a definição correta tem de estar na origem, na recolha.

Vale a pena decompor cada fator, porque é onde a discussão honesta começa:

• Disponibilidade — tempo em que a máquina esteve efetivamente a produzir, sobre o tempo planeado. Aqui mora a grande armadilha: o que conta como "tempo planeado"? Inclui a hora de almoço? O setup? A pausa de limpeza? Duas fábricas com a mesma máquina e o mesmo output reportam disponibilidades diferentes só por causa desta definição.
• Desempenho — cadência real sobre cadência teórica da máquina. Se a máquina foi concebida para 100 peças/hora e fez 78, o desempenho é 78%. O erro comum é usar uma cadência teórica optimista de catálogo, que a máquina nunca atingiu na vida real.
• Qualidade — peças boas sobre peças totais produzidas. Simples de definir, difícil de medir com honestidade, porque exige registar o refugo — e ninguém gosta de registar o próprio erro.

Um OEE de classe mundial ronda os 85%. A maioria das fábricas de série que visitamos, quando mede pela primeira vez com honestidade, descobre-se na casa dos 45% a 60%. E esta descoberta é frequentemente traumática: a administração estava convencida de que "andava nos 80". A distância entre a percepção e o número real é, muitas vezes, a maior descoberta do primeiro mês de um projecto de BI.

O primeiro OEE honesto de uma fábrica é quase sempre um choque. Não porque a fábrica seja má — porque toda a gente vivia com um número inflacionado que ninguém tinha coragem de auditar.

Onde acaba o ERP e começa o BI

Muita confusão nasce aqui. O ERP regista transacções: encomendas, ordens de fabrico, movimentos de stock, faturação. O sistema de recolha de chão-de-fábrica — um MES como o KORA Productivity — captura eventos de produção em tempo real: início de ordem, contagem de peças, paragem e o seu motivo. O BI, o Qlik Sense, lê ambos e cruza-os para produzir o indicador. Três camadas, três funções. Quem tenta usar o ERP como ferramenta de BI acaba com relatórios rígidos que demoram uma semana a alterar sempre que o negócio muda.

O ERP diz o que devia ter acontecido. A recolha diz o que aconteceu. O BI mostra a diferença entre os dois — e é nessa diferença que mora o dinheiro.

MRP, planeamento e o papel do BI no ciclo

Há uma quarta peça que raramente entra na conversa e devia: o MRP e o planeamento de produção. O MRP calcula o que comprar e quando produzir com base nas encomendas e no stock. Mas o MRP trabalha com capacidades teóricas — assume que a linha produz à cadência nominal. Se o BI revela que a cadência real é 20% inferior à teórica, o planeamento está sistematicamente a prometer prazos que a fábrica não cumpre. Aqui o BI deixa de ser só um espelho do passado e passa a alimentar de volta o planeamento: os parâmetros de cadência do MRP devem ser calibrados com os dados reais que o Qlik Sense expõe. Este ciclo de retorno — medir, calibrar o plano, voltar a medir — é o que separa uma fábrica que aprende de uma que apenas reporta.

3. O panorama em Portugal hoje

Os números que definem o ponto de partida

A conversa sobre BI em Portugal tem de começar por reconhecer onde está a base instalada. Três dados do INE, referentes a 2025, desenham o quadro:

• Apenas 53,7% das empresas usavam ERP. Quase metade não tem sequer um núcleo transaccional integrado — e sem núcleo, o BI trabalha sobre dados dispersos por ilhas.
• Apenas 38,7% adquiriam serviços de cloud. A infraestrutura para análise de dados moderna ainda não é maioritária.
• 45% faziam análise de dados — a subir, mas longe de universal. E "fazer análise" inclui quem abre um dashboard uma vez por mês.

Lido em conjunto, isto diz uma coisa: a maioria das PMEs industriais portuguesas está a saltar etapas. Compra um Qlik Sense antes de ter o ERP e a recolha em ordem, e depois estranha que o dashboard não bata certo com a realidade do armazém.

A fractura entre grandes e pequenas empresas

A média nacional esconde uma fractura profunda. As grandes empresas portuguesas adoptam ERP, cloud e analítica a taxas que se aproximam das congéneres europeias. É nas micro e pequenas empresas — que constituem a esmagadora maioria do tecido industrial do Norte — que o atraso se concentra. Uma confecção familiar de 18 pessoas em Barcelos e um grupo têxtil de 400 em Guimarães vivem em mundos digitais diferentes, ainda que a 30 quilómetros de distância. Qualquer estratégia de BI que ignore esta assimetria vende a mesma receita a doentes com patologias opostas.

Segundo dados publicados pela Comissão Europeia no âmbito do índice de digitalização, Portugal fica próximo da média da UE na conectividade e nos serviços públicos digitais, mas abaixo na integração de tecnologia digital nas empresas — precisamente a dimensão onde o BI industrial vive. Ou seja: temos boa rede, temos e-Fatura obrigatória, mas a maturidade analítica interna das empresas industriais está atrasada face à infraestrutura disponível. A ferramenta chegou antes da cultura de a usar.

O peso industrial que justifica o investimento

Não é por falta de indústria. O setor metalúrgico e metalomecânico português tem, segundo a AIMMAP, mais de 23 mil empresas e cerca de 250 mil pessoas empregadas. O têxtil e vestuário do cluster do Vale do Ave e o calçado de Felgueiras e Guimarães exportam para as maiores marcas do mundo. São operações com margem apertada, onde um ponto percentual de OEE ou meio ponto de refugo definem se a encomenda deu lucro. É precisamente aqui que o BI operacional paga o investimento — e precisamente aqui que a recolha continua, muitas vezes, num caderno.

O calendário como fonte de dados: o caso do calçado

No calçado, a estrutura de dados tem uma dimensão que os ERPs generalistas ignoram: o ritmo das coleções. Os compradores internacionais visitam duas vezes por ano — calçado de homem tipicamente em agosto, de senhora em fevereiro. Uma coleção de amostras traz 800 a 1 200 SKUs, com três eixos simultâneos de cor, tamanho e forma. Isto significa que o modelo de dados tem de suportar uma explosão combinatória: um único modelo em oito cores, dez tamanhos e três formas gera 240 SKUs. Um BI que não entenda esta estrutura vai produzir dashboards de vendas por "produto" que agregam o que não devia ser agregado — misturando a bota que vende e a que ficou em stock, porque as trata como o mesmo artigo. A verticalidade não é um argumento comercial; é uma condição para o número fazer sentido.

Distribuição e retalho: o mesmo problema, outra planta

O padrão não é exclusivo da produção. Num centro de distribuição no corredor Lousada/Paços, o chefe de armazém gere picking e cross-docking com um rádio na mão. A verdade do stock vive no movimento físico, não no ERP — e qualquer rollout que o tire do rádio por mais de duas horas encontra resistência feroz e legítima. No retalho alimentar regional, o BI cruza vendas por loja, margem por categoria e ruturas de linear, mas depende de um POS certificado a alimentar dados limpos. Em ambos os casos, a lição repete-se: o dashboard é tão bom quanto a captura no ponto onde a realidade acontece — a doca, o linear, o posto de costura.

Financiamento: a janela PT2030 e PRR

Boa parte destes projectos passa por candidaturas ao PT2030, PRR, COMPETE 2030 ou Norte 2030. O que aprova com facilidade é o investimento em digitalização com indicadores mensuráveis de produtividade. O que fica preso em relatórios técnicos é o projecto vago, sem baseline nem metas. Uma dica operacional: antes de submeter, tenha o OEE atual medido durante pelo menos um mês. Sem baseline, o técnico avaliador não tem como validar o ganho prometido — e a candidatura arrasta-se.

Há um segundo erro recorrente nas candidaturas: prometer ganhos de produtividade sem indicar como serão medidos depois. O avaliador do IAPMEI ou da CCDR-N quer ver o mecanismo de aferição. Se disser "vamos aumentar a produtividade em 15%", tem de dizer como mede a produtividade hoje e como a medirá no fim — e é aqui que ter o Qlik Sense sobre o MES já a produzir OEE fiável transforma a candidatura num caso fácil de aprovar, porque o próprio projecto fornece a instrumentação da sua avaliação. A digitalização da recolha e o BI não são só o objecto do investimento; são a prova do seu retorno.

Uma candidatura PT2030 sem baseline medido é uma promessa sem testemunha. O avaliador não recusa a ambição — recusa a impossibilidade de a verificar.

4. Os modelos de implementação

Há quatro abordagens típicas para pôr Qlik Sense a funcionar em produção industrial. Escolher mal custa meses.

Comparação das quatro abordagens

Trade-offs que ninguém explica no comercial

A tentação é começar pela primeira linha — "vamos só ligar o Qlik ao Excel para arrancar". Faça-o, mas com um prazo de morte: um piloto de Excel que dure mais de dois meses fossiliza-se e passa a ser o sistema definitivo, com todos os defeitos da recolha manual. A terceira linha, MES + ERP via KORA Productivity, é o ponto ótimo para a esmagadora maioria das fábricas portuguesas de confecção, calçado e metalomecânica de série. A quarta, com IoT e sensorização, só compensa em processos onde os dados de máquina são densos e contínuos — injeção plástica na Marinha Grande, por exemplo — e onde faz sentido caminhar para um Digital Twin do processo.

Quando o IoT compensa e quando é vaidade tecnológica

A quarta abordagem seduz porque soa a Indústria 4.0. Mas sensorizar tudo sem um caso de uso claro é a forma mais cara de recolher dados que ninguém lê. O IoT compensa quando o processo é contínuo e a variável física é a chave do problema: temperatura e pressão numa injectora de plástico, vibração num rolamento crítico, consumo eléctrico por ciclo. Nestes casos, a densidade de dados justifica a sensorização e abre a porta à manutenção preditiva. Não compensa numa linha de costura, onde o evento relevante — peça feita, paragem, refugo — é discreto e melhor capturado por um terminal de posto do que por um sensor. A pergunta certa não é "podemos sensorizar?" mas "que decisão de negócio muda com este dado a cada segundo em vez de a cada turno?". Se não houver resposta, o sensor é decoração cara.

A integração como calcanhar de Aquiles

A qualidade do BI é a qualidade da integração. Ligar MES, ERP e eventuais sensores exige uma camada de integração séria — o que hoje se chama iPaaS ou, no ecossistema MULTI, o Multi Connect. Subestimar esta camada é o erro que mais atrasa projectos. A regra prática: por cada semana que planeou para construir dashboards, planeie duas para garantir que os dados que os alimentam são consistentes, deduplicados e com definições únicas.

Há uma armadilha específica na integração que raramente se antecipa: a reconciliação temporal. O ERP fecha uma ordem de fabrico num momento; o MES contou as peças ao longo do turno; o sistema de qualidade registou o refugo horas depois, quando a inspecção foi feita. Se o BI cruzar estes três sem alinhar os relógios e as janelas temporais, produz números que não fecham — a soma das peças boas mais refugo não bate com a produção total, e o diretor perde a confiança no primeiro olhar. Integrar não é só ligar tabelas; é reconciliar o tempo em que cada sistema regista a sua verdade.

Ninguém confia num dashboard duas vezes. Se na primeira semana os números não baterem com a realidade do chão-de-fábrica, perdeu o diretor de produção para sempre.

5. Como avaliar se a sua empresa precisa

Nem toda a fábrica está pronta para BI operacional. Algumas precisam primeiro de arrumar a casa a montante. Este diagnóstico separa os dois casos.

Sinais de que está pronto

• Tem um ERP integrado a registar ordens de fabrico e movimentos — não faturação isolada num programa e produção num caderno.
• Consegue identificar, hoje, quem é responsável por definir o que conta como "unidade produzida", "refugo" e "paragem".
• A administração já pede indicadores que o sistema atual não consegue dar em menos de um dia.
• Há pelo menos uma pessoa interna — muitas vezes o IT self-made com 15 anos de casa — que domina o negócio e vai ser o dono funcional do projecto.

Sinais de que precisa de arrumar antes

• A produção real vive em papéis e memórias. Não há captura digital no posto.
• Cada encarregado calcula os seus indicadores à sua maneira.
• Ninguém consegue dizer, sem hesitar, qual é o OEE médio da fábrica no último mês.

O dono funcional: o IT self-made como peça central

Nas empresas familiares portuguesas, a decisão passa quase sempre pelo trio CEO, CFO e a pessoa de IT. E essa pessoa de IT é, muitas vezes, um herói autodidacta com 15 anos de conhecimento do negócio e sem grau formal — o homem que sabe onde estão enterrados todos os campos personalizados do ERP e porque é que a ordem 2019/0043 tem de ser tratada à parte. Ignorar esta figura é o erro mais caro de um projecto de BI. Não é um obstáculo; é o ativo. Ele conhece as exceções que nenhuma documentação regista e que fazem qualquer dashboard ganhar ou perder credibilidade. O papel de dono funcional cabe-lhe naturalmente, desde que a administração lhe dê tempo protegido — e não lhe empilhe o projecto por cima do trabalho corrente já a 110%.

Passo a passo do diagnóstico

1. Meça a latência da decisão. Pergunte: quanto tempo passa entre um problema acontecer no chão-de-fábrica e alguém com poder de decisão saber? Se a resposta for "no fecho de mês", tem um problema de recolha, não de BI.
2. Audite a definição das três métricas-base. Reúna os encarregados numa sala e peça a cada um que defina "unidade produzida", "refugo" e "paragem". Se as respostas divergirem, resolva isto antes de comprar qualquer software.
3. Trace o mapa das fontes de dados. Liste todos os sítios onde vive informação de produção: ERP, folhas, cadernos, cabeças. Cada fonte manual é um ponto de falha futuro do seu dashboard.
4. Identifique as três decisões que quer suportar. Não "quero ver tudo". Quer decidir o quê? Parar uma ordem deficitária? Reafectar operadores? Antecipar uma rutura de safety stock? Três decisões concretas definem os três dashboards que valem a pena.
5. Nomeie o dono funcional. Sem uma pessoa interna responsável pelos indicadores, o projecto morre no primeiro relatório que não bate certo.

O teste do café: uma heurística rápida

Antes de qualquer projecto formal, há um teste de dois minutos que vale mais do que muitas reuniões. Pergunte ao diretor de produção, à hora do café, três coisas: qual foi o OEE de ontem, qual a encomenda que mais margem está a perder esta semana, e qual a máquina que mais parou este mês e porquê. Se ele responder com números sem ir consultar nada, a fábrica já tem uma cultura de dados e o BI vai apenas acelerá-la. Se ele hesitar, olhar para o lado, ou responder "tenho de ver com o encarregado", tem o diagnóstico feito: o problema não é falta de dashboard, é falta de dados vivos. Nenhum software resolve uma cultura que ainda gere de instinto — só a torna visível.

Este exercício de arrumar a casa antes de digitalizar está no coração de como construir uma organização data-driven: o primeiro passo.

6. O que escolher e porquê, por dimensão de empresa

A matriz de decisão

Porquê esta lógica e não outra

A dimensão determina a ordem, não a ambição. Uma fábrica de 25 pessoas que gasta o orçamento em Qlik Sense antes de digitalizar a recolha compra um espelho caro do seu próprio caos. Primeiro a captura, depois a análise. Acima dos 30 colaboradores, com várias linhas e turnos, o custo de não ter OEE fiável ultrapassa o custo do projecto — e aí a combinação ERP + MES + BI justifica-se plenamente. Nos grupos com várias unidades, o desafio muda de natureza: passa a ser governança de dados, garantir que a "unidade produzida" significa o mesmo em Barcelos e em Felgueiras. Aqui o QAD Adaptive ERP e um Qlik Sense governado fazem sentido.

A empresa pequena: resistir à sedução do dashboard

Para a fábrica com menos de 30 pessoas, o conselho mais valioso é frequentemente "ainda não". Não porque não mereça dados — mas porque o dinheiro rende mais em digitalizar a recolha e integrar o ERP do que em comprar visualização de dados que não existem em estado utilizável. Um terminal simples no posto, uma definição única das três métricas e o ERP a registar ordens de fabrico valem, nesta escala, mais do que qualquer dashboard. O BI vem no ano seguinte, quando houver dados dignos de serem vistos. Ordenar o investimento ao contrário é o desperdício mais comum que vemos neste segmento.

A empresa média: o ponto de retorno mais claro

Na faixa dos 30 aos 250 colaboradores, com várias linhas e turnos, está o retorno mais nítido de todos. A escala já gera complexidade suficiente para que o instinto do encarregado deixe de chegar, e ainda é pequena o bastante para que uma implementação de KORA Productivity com Qlik Sense por cima cubra a fábrica inteira num projecto único e gerível. É aqui que o meio ponto de refugo evitado ou o ponto de OEE recuperado se traduzem, ao fim do ano, num valor que paga o projecto várias vezes. E é aqui que a maioria das candidaturas de financiamento com bom retorno se concentra.

Os grupos: governança antes de ferramenta

Acima dos 250, com várias unidades produtivas, o problema técnico é o menor. O difícil é organizacional: fazer com que "peça produzida", "refugo" e "hora de paragem" signifiquem exatamente o mesmo em todas as fábricas, para que o dashboard consolidado do grupo não some maçãs de Barcelos com laranjas de Felgueiras. Isto exige um dicionário de métricas central, um dono de dados por domínio e um Qlik Sense governado, com controlo de quem vê o quê e uma única definição autoritária de cada indicador. A ferramenta é a mesma; a disciplina de governança é o que muda — e é o que costuma faltar.

O erro de comprar dashboards em vez de decisões

O pior briefing que recebemos é "queremos ver tudo num ecrã". Ver tudo é não ver nada. Um bom dashboard operacional cabe numa TV do chão-de-fábrica e responde a uma pergunta numa olhada de dois segundos: estamos ou não a cumprir o plano deste turno? Os dashboards de exploração profunda, com filtros associativos, são para o gabinete — não para a parede da linha. Confundir os dois produz ecrãs bonitos que ninguém usa. Detalhamos esta distinção em dashboards que a produção industrial realmente usa.

7. Quadro regulatório e conformidade aplicável

O que o BI toca em matéria de conformidade

Um projecto de BI industrial parece neutro do ponto de vista regulatório. Não é. Assim que cruza dados de produção com dados de operadores — quem produziu o quê, com que cadência — entra no âmbito do RGPD e da Lei 58/2019. Indicadores de desempenho individual têm de respeitar a finalidade declarada e a minimização de dados. Não pode transformar um dashboard de OEE por máquina, sorrateiramente, num sistema de vigilância de produtividade individual sem base legal e informação aos trabalhadores.

A linha ténue entre gerir e vigiar

Esta fronteira merece cuidado, porque é fácil atravessá-la sem intenção. Um dashboard que mede o OEE de uma máquina é gestão de equipamento. O mesmo dashboard, filtrado por operador e usado para comparar pessoas num ranking exposto na parede, é tratamento de dados de desempenho individual — e isso tem consequências legais e, sobretudo, humanas. Numa fábrica com mão de obra envelhecida, como é comum na confecção do Norte, expor um ranking de produtividade individual destrói a moral mais depressa do que qualquer ganho de eficiência que traga. A regra que seguimos: medir o processo, não a pessoa. E, quando o dado individual for necessário, tratá-lo com finalidade declarada, minimização e transparência total com os trabalhadores e os seus representantes.

Segurança e infraestrutura

• ISO 27001 — se os dados de produção residem em infraestrutura gerida, exija do fornecedor um sistema de gestão de segurança da informação certificado.
• NIS2 (Diretiva UE 2022/2555, transposta pelo DL 65/2025) — alarga as obrigações de cibersegurança a mais entidades. Fábricas em cadeias de fornecimento de setores essenciais podem ser abrangidas indirectamente, por exigência dos seus clientes.
• DL 28/2019 e SAF-T — quando o BI cruza dados comerciais e de faturação, os dados de origem têm de vir de software certificado pela AT. O dashboard herda a fiabilidade da origem.

NIS2: a conformidade que chega pela cadeia de fornecimento

Muitas fábricas industriais portuguesas acreditam que a NIS2 não lhes diz respeito, por não serem infraestrutura crítica. É uma leitura arriscada. A diretiva estende obrigações de segurança às cadeias de fornecimento de entidades essenciais e importantes — e uma fábrica que fornece componentes ou têxteis técnicos a um cliente abrangido pode ver-se obrigada, contratualmente, a demonstrar maturidade de cibersegurança que não tem. A ENISA tem vindo a sublinhar precisamente o risco da cadeia de fornecimento como vector de ataque dominante. Quando os dados de produção passam a residir na nuvem e a alimentar dashboards acessíveis remotamente, a superfície de ataque cresce — e o cliente que exige o relatório de OEE pode passar a exigir também o certificado de segurança de quem o produz.

Um dashboard de produtividade por operador sem base legal RGPD não é um risco técnico — é um processo à espera de acontecer.

IA sobre os dados de produção

Quem avança para modelos preditivos sobre os dados de produção — prever refugo, antecipar paragens — entra no âmbito do AI Act (Regulamento UE 2024/1689), com a classificação de risco correspondente. Sistemas de IA aplicados a trabalhadores têm exigências acrescidas. A cibersegurança destes fluxos, com um SOC e proteção perimetral adequados, deixa de ser opcional a partir do momento em que dados de fábrica saem para a nuvem.

Há uma distinção prática que o AI Act obriga a fazer e que muda a exposição regulatória. Um modelo que prevê a falha de um rolamento a partir de dados de vibração é IA de risco limitado — atua sobre a máquina. Um modelo que classifica ou pontua trabalhadores a partir do seu desempenho pode cair na categoria de alto risco, com obrigações de documentação, supervisão humana e transparência muito mais pesadas. A fronteira volta a ser a mesma da secção do RGPD: modelar o processo é seguro; modelar a pessoa levanta o nível de exigência para outro patamar. Antes de deixar entusiasmar-se com IA preditiva sobre o chão-de-fábrica, classifique o caso de uso — porque a classificação errada é uma não-conformidade cara.

8. Como a INFOS aborda isto

A nossa convicção, depois de mais de três décadas em fábricas portuguesas, é simples: o BI é o último andar, não o primeiro. Por isso não vendemos Qlik Sense isolado como quem vende uma licença e vai embora. Olhamos primeiro para a recolha — o KORA Productivity a capturar produção real no posto, com terminais que o operador consegue usar sem tirar as luvas — e para o núcleo transaccional, o ERP MULTI vertical para o seu setor. Só depois o Qlik Sense cruza tudo e produz o indicador em que o diretor confia.

Essa verticalidade importa. Um ERP generalista não modela uma coleção de calçado com 800 a 1200 SKUs e três eixos de cor-tamanho-forma. Se o modelo de dados na origem está errado, nenhum dashboard o corrige. Trabalhamos a partir do conhecimento do têxtil, do vestuário e do calçado porque é aí que a INFOS tem 36 anos de estrada.

O terminal que o operador usa sem tirar as luvas

Um detalhe que parece menor e decide projectos: a ergonomia da captura no posto. Numa tinturaria do Vale do Ave, o operador tem as mãos molhadas e por vezes com luvas; numa linha de costura, os dedos estão ocupados com a peça; num armazém de distribuição, o gesto tem de ser feito de pé, com o rádio na outra mão. Se a captura exigir escrever num teclado pequeno ou navegar em menus complexos, o operador não regista — ou regista mal, no fim do turno, de cabeça, e voltamos ao Excel da Dona Fernanda. Um terminal industrial pensado para o gesto real, com leitura de código, botões grandes e o mínimo de passos, é a diferença entre dados que existem e dados que se inventam. O melhor BI do mundo não sobrevive a uma captura que o chão-de-fábrica odeia usar.

A honestidade sobre o que corre mal

E somos honestos sobre o que corre mal: os projectos de BI que falham na INFOS falham quase sempre por causa da recolha a montante e da ausência de um dono funcional interno. É por isso que insistimos no diagnóstico da secção 5 antes de escrever a primeira linha de carga de dados. Aprendemos isto da forma dura, em projectos onde o cliente queria começar pelo dashboard e nós cedemos — e ao fim de dois meses tínhamos ecrãs lindos que ninguém acreditava, porque a produção real continuava a viver num caderno que o sistema não via. Hoje recusamos começar pelo fim. Não por teimosia; por experiência acumulada de saber onde o projecto descarrila.

Sobre o caminho da IA aplicada a decisões, o princípio mantém-se: sem dados limpos na base, a IA amplifica o lixo mais depressa. Um modelo preditivo treinado sobre uma recolha manual enviesada não prevê o futuro — projecta o viés do passado com uma confiança estatística que engana. A ordem correta nunca muda: primeiro a captura fiável, depois o indicador honesto, só então a predição.

9. Roadmap 30/60/90 dias

Dias 1–30: fundação e baseline

• Complete o diagnóstico da secção 5 e nomeie o dono funcional interno.
• Feche a definição única de "unidade produzida", "refugo" e "paragem" — documentada e assinada pelos encarregados.
• Estabeleça a baseline: meça o OEE atual durante pelo menos quatro semanas, mesmo que a recolha ainda seja imperfeita. É o número contra o qual tudo será comparado — e o que a candidatura PT2030 vai exigir.

Dias 31–60: recolha e integração

• Ponha a captura digital a funcionar em uma ou duas linhas-piloto — não na fábrica inteira. Um poka-yoke no terminal evita que o operador registe o impossível.
• Construa a camada de integração entre MES e ERP e valide, linha a linha, que os números batem com a contagem física.
• Corra o primeiro dashboard operacional em paralelo com o método antigo. Só ganha confiança quando os dois concordam durante duas semanas seguidas.

Dias 61–90: dashboard e adoção

• Publique os três dashboards que respondem às três decisões definidas — um para a parede da linha, dois para o gabinete.
• Ponha o ecrã da linha virado para os operadores, não para as visitas. O envolvimento da equipa nasce de verem o seu próprio desempenho em tempo real, não de serem vigiados de cima.
• Alargue a recolha às restantes linhas só depois de a piloto ser confiável. Escalar o caos é mais rápido do que escalar a ordem, mas custa muito mais.

Depois dos 90 dias: o que sustenta o ganho

O erro final, mais comum do que se admite, é declarar vitória aos 90 dias e retirar a atenção. Um projecto de BI operacional não termina na publicação do dashboard; começa aí. As definições de métrica derivam com o tempo — entra uma máquina nova, muda um turno, altera-se um processo — e sem manutenção o dashboard afasta-se lentamente da realidade até voltar a não bater certo. É por isso que o dono funcional tem de continuar a existir depois do arranque, com uma revisão trimestral do dicionário de métricas e uma verificação regular de que os números do Qlik Sense ainda concordam com a contagem física. A confiança conquista-se em 90 dias; perde-se numa semana de negligência.

No fim destes 90 dias, o teste é único e brutal: quando o diretor de produção

Perguntas frequentes

O Qlik Sense sozinho resolve os problemas de dados na produção?

Não. O Qlik Sense é apenas a ferramenta final de visualização. Se os dados que alimentam o dashboard vêm de recolha manual ou ficheiros Excel desorganizados, o software não consegue criar inteligência a partir de lixo. A qualidade do resultado depende 80% da recolha a montante e apenas 20% da ferramenta de BI.

Qual é a diferença entre um dashboard bonito e um dashboard operacional?

Um dashboard bonito impressiona em apresentações, mas chega tarde. Um dashboard operacional responde a "o que está a acontecer agora" e permite decisões de correção em minutos ou horas. Na produção, a janela de decisão é curta — um relatório mensal nunca consegue evitar perdas que ocorrem diariamente.

Porque é que a recolha manual de dados é tão problemática?

A recolha manual introduz três tipos de erro: transcrição (operador escreve mal), arredondamento (ajusta números para agradar ao encarregado) e atraso (dados chegam tarde demais para agir). Numa fábrica com 1 400 registos diários, 2% de erro significa 30 dados falsos por dia — suficiente para distorcer completamente o OEE e custos.

Como é que uma encomenda "sangra" sem ninguém dar por isso?

Quando a produção real fica abaixo da cadência prevista — por tecido difícil, ausência de operador ou setup longo — a margem evapora gradualmente. Sem captura em tempo real, isto só se descobre no fecho do mês. A encomenda já saiu e o prejuízo está lançado. A decisão de parar ou reafectar recursos nunca foi tomada.

Qual é o impacto de definições ambíguas de métricas?

Se "produção do dia" significa coisas diferentes para cada encarregado — alguns contam refugo, outros não; alguns incluem setup, outros não — o dashboard soma dados incomparáveis. Isto cria a ilusão de precisão enquanto o sistema está a mentir sistematicamente sobre o desempenho real.

Porque é que o ERP e o chão-de-fábrica não falam entre si?

O ERP regista encomendas e facturas; o chão-de-fábrica regista o que foi realmente produzido. Se não estão integrados, o BI escolhe um lado e ignora o outro. O resultado é dois "dados verdadeiros" contraditórios — um para a administração, outro para a produção.

Porque é que as empresas continuam a usar Excel em vez de sistemas automáticos?

Excel funciona o suficiente até o cliente exigir rastreabilidade ou relatórios complexos que o Excel não consegue produzir. Há também uma razão cultural: quem preenche o Excel detém poder sobre a "verdade" dos dados. Digitalizar a recolha tira esse monopólio, gerando resistência natural.

Fontes

• Instituto Nacional de Estatística (INE) — Inquérito à Utilização de Tecnologias da Informação e da Comunicação nas Empresas (IUTICE), dados 2023-2025 sobre análise de dados e big data em empresas portuguesas
• Norma ISO/IEC 27001:2022 — Sistemas de gestão da segurança da informação, aplicável a recolha e tratamento de dados operacionais em ambiente industrial
• Norma ISO 22400:2018 — Automation systems and integration — Key performance indicators (KPIs) for manufacturing operations management, referência para definição de métricas como OEE
• Banco de Portugal — Relatórios sobre transformação digital e adoção de tecnologias em PME industriais portuguesas