BI industrial com Qlik Sense: do dado bruto à decisão operacional

Numa fábrica de malhas de Vizela, o mapa de produção do dia anterior sai numa folha de cálculo às 9h30 — depois de o encarregado da noite ter escrito à mão os números da última hora, porque o sistema "não fechou o turno a tempo". Às 11h, quando a direção olha para esse mapa, os operadores já estão a produzir a próxima encomenda. O relatório descreve um mundo que já não existe. Isto não é falta de dados. É excesso de dados mortos.

A tese deste artigo é simples e desconfortável: a maior parte dos projectos de BI industrial em Portugal falha não por causa da ferramenta, mas porque as empresas compram dashboards antes de resolverem a latência e a fiabilidade da recolha de dados no chão de fábrica. Qlik Sense — ou qualquer motor de BI — só vale o que valem os dados que o alimentam, e a que velocidade chegam. Este texto trata do caminho inteiro: do sensor à decisão, com o contexto industrial português que os manuais internacionais ignoram.

1. O problema operacional real

Comecemos pelo sítio errado onde quase toda a gente começa: o ecrã bonito. Um diretor industrial vê uma demonstração de Qlik Sense numa conferência, fica encantado com os gráficos interativos, e volta para a fábrica convencido de que o problema dele é visualização. Não é. O problema dele é que ninguém sabe, às 14h de uma terça-feira, quantas peças conformes saíram da secção de acabamento naquela manhã sem ligar a três pessoas e abrir dois ficheiros Excel.

O dado nasce atrasado, incompleto e disperso

Numa PME industrial portuguesa típica, os dados operacionais vivem em silos que não se falam. O ERP tem as encomendas e a facturação. Uma folha de cálculo tem o mapa de produção. O encarregado tem na cabeça (ou num caderno) as paragens de máquina. O armazém tem um sistema próprio — quando tem. E a qualidade regista as não-conformidades num impresso que alguém digita ao fim da semana, se der tempo.

Quando finalmente se junta tudo, o dado tem dois, três, sete dias. Serve para prestar contas. Não serve para decidir. E decidir com informação de ontem, numa fábrica que muda de artigo três vezes por dia, é conduzir a olhar pelo retrovisor.

Há uma subtileza que raramente aparece nas conversas de digitalização: o dado disperso não é apenas lento — é contraditório. A folha de cálculo do encarregado conta peças produzidas; o ERP conta peças facturadas; a qualidade conta peças conformes. As três referem-se, teoricamente, ao mesmo lote. Quase nunca batem certo. E quando não batem, o tempo da direção gasta-se a reconciliar números em vez de a decidir sobre eles. Numa reunião de segunda-feira de manhã, é comum ver quarenta minutos consumidos a discutir qual dos números está certo antes de sequer se chegar à decisão que a reunião existia para tomar.

A latência tem um custo que ninguém contabiliza

Ninguém abre uma rubrica na contabilidade chamada "custo de decidir tarde". Mas ele existe. Uma linha que ficou parada quarenta minutos por falta de material — porque o aviso de rutura só apareceu no mapa do dia seguinte — custa capacidade produtiva que não volta. Uma encomenda urgente aceite sem se saber que a linha crítica já estava sobrecarregada gera uma entrega atrasada, uma penalização contratual, e uma casa-mãe irritada. Estes custos não aparecem numa folha de cálculo porque estão diluídos em mil pequenas decisões tomadas com informação velha.

A regra empírica que aplicamos: quanto mais curto o ciclo de produção de um artigo, mais tóxica é a latência de informação. Uma tinturaria que vira um lote em horas não pode tomar decisões com dados diários. Uma serralharia que trabalha peças de série longa tem mais margem. A urgência de BI não se mede pela dimensão da empresa — mede-se pela velocidade a que a operação muda de estado.

O caso da confeção que subcontrata para Inditex

Uma casa de confeção do eixo Famalicão–Guimarães que trabalha para grandes cadeias vive uma pressão específica: a casa-mãe exige indicadores de cumprimento de prazo, taxa de defeito e rastreabilidade de lote — muitas vezes num portal próprio, com deadlines apertados. Se a fábrica não consegue extrair estes números com fiabilidade e rapidez, gasta pessoas caras a compilar relatórios à mão, e mesmo assim entrega números que não bate certo com a realidade da linha.

A pressão agravou-se com a Estratégia da UE para Têxteis Sustentáveis e Circulares. As grandes marcas empurram para os subcontratados a exigência de rastreabilidade de origem de matéria-prima, consumo de água por lote na tinturaria, e composição de fibra ao nível do artigo. Isto não é um relatório anual de sustentabilidade — é um dado que a casa-mãe pede lote a lote, e que a fábrica só consegue fornecer se o capturar na origem. Uma confeção que aponta produção a papel simplesmente não tem como responder. E a marca não espera: escolhe o fornecedor que responde.

O BI industrial não serve para fazer relatórios mais bonitos. Serve para encurtar a distância entre o que aconteceu na máquina e o momento em que alguém com autoridade age sobre isso.

O calçado e a maldição dos 1000 SKUs

Em Felgueiras, uma coleção de amostras tem facilmente 800 a 1200 SKUs, cruzando modelo, cor, tamanho e forma. Os compradores internacionais visitam duas vezes por ano — o calçado de homem sobretudo em agosto, o de mulher em fevereiro. Quando o comprador pergunta "quanto me consegue produzir deste modelo em pele castanha, tamanhos 39 a 44, para entrega em oito semanas?", a resposta depende de dados de capacidade, de stock de matéria-prima e de carga das linhas que nenhuma folha de cálculo consegue cruzar em tempo útil. Perde-se a encomenda a decidir devagar.

O problema do calçado é estrutural e mal servido por ferramentas genéricas: os três eixos de variante (cor, tamanho, forma) multiplicam-se de forma explosiva. Um ERP generalista trata cada combinação como um artigo independente — e a gestão desmorona-se sob dezenas de milhares de linhas. Um sistema desenhado para o setor modela a variante como uma matriz, e o BI que assenta sobre ele consegue responder à pergunta do comprador em minutos, não em dias. A diferença entre ganhar e perder a encomenda está, muitas vezes, exatamente aqui: na capacidade de dar um número fiável enquanto o comprador ainda está sentado na sala.

O armazém e o chefe que não larga o rádio

Há um personagem que decide o destino de metade dos projectos e que raramente aparece na sala onde se assina o contrato: o chefe de armazém de um centro de distribuição no corredor Lousada–Paços. Este homem coordena picking, cross-docking e expedição por rádio, e conhece o layout melhor do que qualquer planta. Qualquer sistema que o obrigue a sair do rádio por mais de duas horas para "dar formação" vai encontrar resistência feroz — e com razão. A operação não pára porque o BI chegou.

A lição operacional: a recolha de dados no armazém tem de acontecer dentro do fluxo de trabalho existente, não à margem dele. Um terminal de gestão de armazém que confirma picking com um scan é aceite; um ecrã adicional onde alguém tem de "registar o que fez" é sabotado no primeiro dia. O BI de distribuição só é fiável se o dado nascer do gesto que o operador já faz de qualquer maneira.

2. O que é exatamente BI industrial Qlik Sense Portugal

Business Intelligence industrial é a disciplina de recolher, integrar, modelar e apresentar dados operacionais e financeiros de forma a suportar decisões — de preferência antes de o problema custar dinheiro. Qlik Sense é uma plataforma de BI e análise de dados que executa esse ciclo com uma característica técnica que a distingue: o motor associativo em memória.

O motor associativo — porque é que isto importa

A maioria das ferramentas de BI funciona por consultas hierárquicas: escolhe uma dimensão, desce, filtra. O motor associativo de Qlik carrega os dados em memória e mantém todas as relações entre todos os campos simultaneamente. Na prática, quando um diretor clica numa máquina específica, todos os outros gráficos — turnos, artigos, defeitos, operadores — reagem instantaneamente, mostrando o que está associado e, mais importante, o que não está. Esse "cinzento" (o que fica excluído da seleção) é frequentemente onde vive a resposta.

Um exemplo concreto de fábrica: seleciona-se um determinado tipo de defeito de acabamento. Os gráficos mostram que máquinas, que turnos e que operadores estão associados a esse defeito. Mas o valor real aparece ao inverso — a lista de operadores que fica a cinzento (ou seja, que nunca produziu esse defeito) diz-lhe onde está a boa prática que devia ser replicada. Ferramentas hierárquicas escondem esta ausência; o motor associativo torna-a visível. Numa investigação de causa de não-conformidade, esta capacidade de ver o que não está lá poupa horas de cruzamento manual.

Os termos que vai ouvir e o que significam mesmo

• ETL / carga de dados — o processo de extrair, transformar e carregar os dados das fontes para o modelo. É aqui que a esmagadora maioria do trabalho real de um projecto de BI acontece, e é a parte que ninguém mostra nas demonstrações.
• Modelo de dados — a estrutura que liga tabelas de factos (produção, vendas, paragens) a dimensões (tempo, artigo, cliente, máquina). Um modelo mal desenhado dá números errados com confiança total.
• KPI — indicador que mede algo que importa a uma decisão. Se ninguém age sobre ele, é decoração.
• OEE — Overall Equipment Effectiveness, o indicador que combina disponibilidade, desempenho e qualidade de um equipamento. É o número-rei do BI de produção — e o mais falsificado quando calculado à mão.
• MES — sistema de execução de manufactura, a camada que captura o que acontece na máquina em tempo real. Sem esta camada, o BI de produção fica cego ao presente.
• MRP — planeamento de necessidades de material, o motor que traduz encomendas em necessidades de compra e produção. Alimenta o BI de compras e de planeamento.
• Data Lake — repositório onde se armazenam dados brutos de múltiplas fontes antes de os modelar. Útil em cenários complexos; excessivo para a maioria das PMEs.

Vale distinguir BI de dashboards operacionais de tempo real. O painel operacional que a produção usa ao minuto e o relatório analítico que a direção lê ao fim do mês são coisas diferentes, com requisitos de latência diferentes. Confundi-los é a origem de metade das frustrações.

Uma breve história — de onde vem isto

Qlik nasceu na Suécia nos anos 90 com o QlikView, um produto que popularizou a análise associativa em memória numa altura em que o BI era território de relatórios estáticos pesados. Qlik Sense, lançado em 2014, reconstruiu essa filosofia numa arquitetura moderna, orientada a self-service, responsiva e com governança centralizada. Para a indústria, a mudança relevante foi permitir que um encarregado explore os seus próprios dados sem esperar por um relatório do departamento de informática.

Esta transição — de relatório estático pedido ao departamento de informática para exploração autónoma pelo utilizador de negócio — é o ponto de viragem que muda a economia do BI. No modelo antigo, cada pergunta nova gerava um pedido, uma fila de espera de dias, um relatório que já não respondia à pergunta original quando chegava. No modelo associativo, o encarregado clica, filtra, descobre, e age no mesmo dia. Para uma PME industrial que não tem uma equipa de analistas de dados, esta autonomia não é um luxo — é a única forma de o BI sobreviver ao entusiasmo inicial.

3. O panorama em Portugal hoje

Convém ancorar a conversa em números reais, não em entusiasmo de feira tecnológica. 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 adoção está a crescer, mas a gestão baseada em dados está longe de ser universal. A maioria continua a decidir por intuição e experiência, o que numa fábrica com margens apertadas é um luxo cada vez mais caro.

Mais revelador ainda: apenas 53,7% das empresas em Portugal usavam ERP em 2025 (INE). Isto tem uma consequência direta para o BI — quase metade das empresas não tem um núcleo integrado de onde extrair dados coerentes. Fazer BI sobre dados dispersos por folhas de cálculo e sistemas isolados é possível, mas é como cozinhar com ingredientes de qualidade desconhecida: o resultado é imprevisível.

Sem um ERP a funcionar como fonte única de verdade, o BI não elimina a confusão — amplifica-a, dando-lhe a aparência de rigor.

A cloud ainda é minoria

Em 2025, apenas 38,7% das empresas em Portugal adquiriam serviços de cloud (INE). Isto importa para o BI porque as arquiteturas modernas de análise — Qlik Cloud incluído — assumem cada vez mais um modelo de nuvem. Muitas PMEs industriais portuguesas ainda preferem manter os dados em casa, por razões de controlo, de custo previsível e de desconfiança legítima. É uma decisão de arquitetura que condiciona o projecto todo.

Esta desconfiança tem raízes concretas, não é irracional. Uma fábrica que passou trinta anos a controlar os seus servidores desconfia — com alguma razão — de um modelo em que os dados de produção, os custos e as margens vivem na infraestrutura de terceiros. A resposta não é convencê-la à força de que a cloud é sempre melhor. É desenhar a arquitetura que faz sentido para o seu perfil de risco: on-premises para os dados mais sensíveis, cloud para o que ganha com escala e acesso remoto, ou um modelo híbrido. A decisão de onde vivem os dados deve preceder a decisão de que ferramenta de BI comprar — e não o contrário.

A lacuna de competências digitais

Há um obstáculo que os números de adoção não capturam: a escassez de gente capaz de manter um sistema de análise de dados a funcionar. Na PME industrial portuguesa típica, o "responsável de informática" é frequentemente um profissional autodidata com quinze anos de conhecimento profundo do negócio e nenhuma formação formal em ciência de dados. É uma figura valiosíssima — conhece cada exceção do processo, cada cliente difícil, cada máquina que precisa de mimo. Mas pedir-lhe que desenhe do zero um modelo de dados multidimensional é pedir demasiado.

Este perfil condiciona a escolha de arquitetura de forma decisiva. Uma plataforma de BI que exige uma equipa de analistas dedicada vai falhar numa empresa onde essa equipa não existe e não vai existir. A ferramenta certa para esta realidade é aquela cujo modelo de dados chega pré-desenhado pelo fornecedor que conhece o setor, deixando à figura interna o que ela faz bem: validar que os números fazem sentido face à realidade que só ela conhece.

Onde há dinheiro e onde há movimento

O setor metalúrgico e metalomecânico português tem mais de 23 mil empresas e cerca de 250 mil pessoas empregadas (AIMMAP / Metal Portugal). É um universo enorme, com maturidade digital muito desigual: das fundições de Marinha Grande com Indústria 4.0 avançada às serralharias familiares que ainda fecham o mês num caderno. No comércio, o volume de negócios atingiu 201,8 mil M€ em 2024, com o retalho a crescer 4,7% (INE) — pressão que empurra as cadeias a analisar melhor margem, rotação de stock e desempenho por loja.

No têxtil e calçado, o movimento é diferente e vem de fora: o reshoring. À medida que as marcas europeias reponderam a dependência da produção asiática — puxadas pela volatilidade dos custos de transporte, por prazos de entrega mais curtos e pela pressão regulatória de sustentabilidade — Portugal recupera encomendas. Mas essas encomendas vêm com exigências de rastreabilidade e de resposta rápida que a fábrica só cumpre com dados fiáveis. O reshoring não premeia quem produz barato; premeia quem produz com informação. É aqui que o BI industrial deixa de ser um investimento discricionário e passa a ser uma condição de acesso a mercado.

O retalho e a pressão da certificação

No retalho, sobretudo o alimentar regional e o especializado, a digitalização não é opcional — é imposta pela conformidade. O software de POS tem de estar certificado pela AT, o e-Fatura tem de comunicar, o ATCUD tem de estar em cada documento. Uma cadeia regional com vinte e duas lojas que ainda vive de mapas de vendas em Excel por loja está a deixar dinheiro na mesa em rotação de stock, em rutura evitável e em desempenho comparado entre lojas. O BI de retalho responde a perguntas que o gerente de loja não consegue responder sozinho: que artigos rodam melhor nesta loja e pior naquela, e porquê.

4. Os modelos de implementação de BI industrial

Não há uma forma certa de implementar BI. Há a forma certa para a sua empresa, dado o tamanho, a maturidade dos dados e a urgência. Estas são as quatro abordagens que vemos na prática, com os seus custos reais — não os prometidos.

Modelo 1 — o ponto de partida honesto

Começar por extrações do ERP não é derrota, é prudência. Uma fábrica que nunca teve BI ganha imenso simplesmente por ter, num ecrã único, a facturação, a margem por cliente e a rotação de stock — mesmo que os dados sejam de ontem. É rápido, barato e ensina a organização a confiar em dados. O erro é ficar aqui para sempre.

Este modelo tem uma virtude pedagógica subestimada: cria o hábito de olhar para dados. Numa organização que sempre decidiu por intuição, a mudança cultural é o obstáculo maior — não a técnica. Um painel de margem por cliente, atualizado diariamente, que a direção comercial começa a abrir todas as manhãs, muda a conversa da empresa. Passa-se de "acho que este cliente é dos bons" para "este cliente tem margem de 8% e ocupa 20% da capacidade — porquê?". Quando esse hábito se instala, a organização começa ela própria a pedir dados mais frescos. E é aí que a evolução para os modelos seguintes deixa de ser uma venda e passa a ser uma exigência interna.

Modelo 2 — a ligação direta ao ERP

Quando o hábito está instalado, a latência diária começa a incomodar. A direção comercial quer saber a carteira de encomendas agora, não como estava ontem à noite. A ligação direta à base de dados do ERP — em vez de exportações periódicas — resolve isto para as áreas de vendas, compras e stock. É um salto de complexidade moderado: exige cuidado para não sobrecarregar a base de dados de produção do ERP com consultas pesadas, mas é território bem conhecido. Para uma PME comercial ou de distribuição, este é frequentemente o modelo que entrega o melhor rácio de valor por esforço.

Modelo 3 — onde o BI industrial se torna industrial

A diferença entre BI genérico e BI industrial está aqui: ligar o BI à captura de produção em tempo real. É preciso uma camada MES — no nosso caso, o KORA Productivity captura produção, paragens e eficiência diretamente nos terminais de chão de fábrica. Só com este fluxo é que o OEE deixa de ser um número calculado à mão no fim do mês e passa a ser um sinal ao vivo. É também o modelo mais exigente, porque envolve o chão de fábrica, os operadores e a resistência natural à mudança.

O OEE calculado à mão no fim do mês é, quase sempre, uma ficção reconfortante. As paragens curtas — cinco minutos aqui, dez minutos ali para trocar de artigo ou desencravar — não são registadas porque ninguém tem tempo para as apontar. O resultado é um OEE inflado que esconde precisamente o problema que devia revelar. É comum uma fábrica descobrir, ao capturar paragens em tempo real pela primeira vez, que o OEE real de uma linha era substancialmente inferior ao que sempre reportou — não porque a linha piorou, mas porque finalmente se está a medir a verdade. Este momento é desconfortável e essencial: sem ele, todas as decisões de investimento em capacidade assentam num número falso.

O gerente de produção que esconde o tablet KORA debaixo de uma caixa com fita-cola não está a sabotar o projecto — está a dizer-lhe que o processo de recolha lhe estraga o ritmo de trabalho. Ouça-o antes de comprar mais tablets.

A resistência do chão de fábrica merece respeito, não desprezo. Um operador que produz há vinte anos sabe que qualquer segundo gasto a interagir com um ecrã é um segundo que não está a produzir — e, se for pago à peça, é um segundo que lhe custa dinheiro. A captura de produção só funciona quando o registo é quase invisível: um botão físico no posto, um scan de código, uma confirmação de um toque. Quanto mais o sistema pede ao operador, mais o operador contorna o sistema. O sucesso do Modelo 3 mede-se menos na sofisticação do software e mais na simplicidade brutal da interação no posto de trabalho.

Modelo 4 — o Data Lake, e quando NÃO precisa dele

Grupos com três, quatro fábricas, cada uma com o seu sistema, e uma direção que quer consolidar tudo, têm um argumento legítimo para um Data Lake. Uma PME de 80 pessoas com um ERP e uma folha de cálculo não tem. Vender um Data Lake a essa empresa é vender-lhe um camião para ir às compras. A regra prática: se o número de fontes de dados relevantes é inferior a cinco, não precisa de Data Lake — precisa de um bom modelo de dados.

O Data Lake é frequentemente vendido como solução para o problema errado. A dificuldade de consolidar dados de várias fábricas raramente é de armazenamento — é de semântica. A fábrica A chama "OEE" a uma coisa; a fábrica B chama "OEE" a outra ligeiramente diferente; a fábrica C nem sequer o calcula. Deitar todos esses dados num repositório central não resolve isto — apenas concentra a confusão num sítio maior. O trabalho verdadeiro, antes de qualquer Data Lake, é acordar definições comuns de indicadores entre entidades. Feito esse trabalho de governança, o repositório físico torna-se um detalhe técnico. Saltado esse trabalho, o Data Lake mais caro do mundo produz números que ninguém confia.

5. Como avaliar se a sua empresa precisa

Antes de olhar para ferramentas, olhe para dentro. A maioria das empresas descobre, ao fazer este diagnóstico honesto, que o problema não é a falta de BI — é a falta de dados fiáveis para alimentar o BI. Trate primeiro a fonte.

Sinais de que está pronto (ou de que não está)

• Alguém na sua empresa passa mais de meio dia por semana a compilar relatórios manuais em Excel — sinal forte de que há retorno imediato.
• Duas pessoas apresentam o mesmo indicador com valores diferentes na mesma reunião — sinal de que falta uma fonte única de verdade antes do BI.
• As decisões importantes esperam sempre pelo fecho do mês — sinal de latência excessiva na informação.
• O seu ERP está estável e a maioria dos processos passa por ele — pré-requisito verde para avançar.
• Os dados de produção ainda são apontados à mão em papel — trate desta recolha primeiro, ou o BI de fábrica não terá o que mostrar.

O trio que decide — e como falar com cada um

Nas empresas familiares portuguesas, a decisão de investir em BI passa quase sempre por três pessoas: o CEO (frequentemente o dono ou um filho da segunda geração), o CFO e o responsável de informática. Cada um tem uma linguagem e um medo diferentes, e um projecto que ignore qualquer um deles descarrila.

A conversa que funciona é a que dá a cada um a sua vitória: ao CEO, uma decisão que passou a ser mais rápida; ao CFO, um número que reconcilia com o balancete; ao responsável de informática, a garantia de que o modelo de dados chega mantido e não fica dependente exclusivamente dele. Vender só ao CEO — que é quem se entusiasma na feira — e ignorar os outros dois é a receita para um projecto aprovado que nunca arranca.

Passo a passo

1. Inventarie as fontes de dados. Liste onde vivem os dados que importam: ERP, folhas de cálculo, sistemas de armazém, registos de qualidade, apontamentos de chão de fábrica. Para cada um, anote quem o mantém e com que frequência é atualizado.
2. Identifique as 3 a 5 decisões que mais dinheiro custam ao atrasar. Não tente medir tudo. Escolha as decisões concretas — aceitar uma encomenda, parar uma linha, comprar matéria-prima — onde a informação atrasada dói mais.
3. Avalie a fiabilidade da recolha na fonte. Para cada decisão, verifique se o dado necessário existe, é fiável e chega a tempo. Onde falhar, o problema é de recolha, não de BI — resolva-o primeiro.
4. Defina os indicadores mínimos viáveis. Para cada decisão, defina o indicador exato, a fórmula, a granularidade (por linha? por turno? por cliente?) e a latência aceitável.
5. Faça uma prova de conceito com um caso real. Escolha uma decisão, ligue os dados reais e construa um painel funcional em duas a quatro semanas. Meça se a decisão passou a ser tomada mais depressa e melhor. Só depois generalize.

Este exercício, feito com honestidade, poupa a maior parte do orçamento que se desperdiça em dashboards que ninguém abre. Vale a pena ler também sobre quais os KPIs que fazem sentido do chão de fábrica à direção antes de fixar os indicadores.

6. O que escolher e porquê (decisão por dimensão de empresa)

A pergunta "qual a melhor abordagem de BI" não tem resposta universal. Tem resposta por perfil. A matriz abaixo condensa o que recomendamos consoante a dimensão e a maturidade.

A PME abaixo de 50 pessoas — comece pequeno, comece já

A tentação da empresa pequena é adiar: "somos poucos, ainda não precisamos disto". É um erro. Precisamente porque é pequena, cada decisão errada pesa mais no resultado, e cada hora que uma pessoa-chave gasta a compilar Excel é uma hora que não gasta a vender ou a produzir. O ponto de partida para este perfil é modesto e eficaz: BI sobre o ERP, três indicadores, um mês de arranque. O que este perfil não deve fazer é deixar-se convencer a comprar arquitetura de grupo — é o erro mais caro que uma empresa pequena pode cometer com dados.

A empresa de 150 a 300 pessoas — o ponto de maturidade do OEE

É neste escalão que o OEE por linha e turno passa a fazer diferença real no resultado. Com múltiplas linhas a competir por capacidade, saber qual rende mais e porquê deixa de ser curiosidade e passa a ser gestão de ativos. Este perfil aguenta — e beneficia de — o Modelo 3 completo: BI ligado a MES, com um modelo de dados sólido por baixo. O erro típico deste escalão é o inverso do da empresa pequena: querer analítica preditiva (prever avarias, prever procura) antes de ter o básico da captura fiável a funcionar. Preveja o futuro depois de conseguir medir o presente.

A armadilha do "vamos medir tudo"

O erro mais caro que vemos não é escolher a ferramenta errada. É a ambição errada. Uma empresa decide que, já que vai fazer BI, vai medir cinquenta indicadores. Seis meses depois tem cinquenta gráficos e zero decisões diferentes. Comece por três indicadores que mudem comportamento. Quando os três estiverem a ser usados a sério, acrescente mais três.

Há uma razão psicológica para esta armadilha ser tão comum: um painel com cinquenta indicadores parece mais valioso do que um com três. Impressiona na demonstração, justifica o orçamento perante o conselho de administração. Mas o valor do BI não está no que mostra — está no comportamento que muda. Um único indicador que faz o diretor de produção parar uma linha uma hora mais cedo vale mais do que quarenta gráficos que toda a gente admira e ninguém age sobre. Meça o sucesso do seu BI em decisões alteradas, nunca em número de visualizações.

Self-service não significa sem governança

Qlik Sense brilha no self-service — deixar cada área explorar os seus dados. Mas self-service sem um modelo de dados governado é o caminho mais rápido para o caos dos "vários números para a mesma coisa". A regra: dados e definições de indicadores centralizados e certificados; liberdade de exploração por cima disso. Quem confunde as duas camadas volta ao problema que o BI devia resolver.

Self-service sem governança é dar a chave do arquivo a toda a gente e depois admirar-se de que cada um tenha uma versão diferente dos números.

7. Quadro regulatório e conformidade aplicável

BI mexe com dados. Em Portugal e na UE, mexer com dados tem regras — e ignorá-las é acumular risco silencioso que só aparece quando há uma inspeção ou um incidente.

RGPD e dados de pessoas

Se os seus painéis cruzam dados de operadores — produtividade por pessoa, absentismo, desempenho — está a tratar dados pessoais ao abrigo do RGPD e da Lei 58/2019. Isto exige base legal, minimização e cuidado especial com indicadores individuais. Medir eficiência por linha é uma coisa; expor um ranking nominal de operadores num ecrã público de fábrica é outra, com implicações legais e laborais reais. A ferramenta de gestão de pessoas deve tratar estes dados com o rigor devido.

A fronteira prática é útil de fixar: medir o processo é legítimo; vigiar a pessoa é território minado. Um painel que mostra a eficiência da linha 3 no turno da noite ajuda a gerir a operação. Um painel que expõe, por nome, quem produziu menos naquele turno cria um problema de proteção de dados e um problema laboral — os representantes dos trabalhadores têm aqui um interesse legítimo, e a Lei 58/2019 dá-lhes razão. Sempre que possível, agregue ao nível da linha, do turno ou da equipa. Só desça ao nível individual com base legal clara, finalidade documentada e informação prévia aos visados.

Segurança da informação — NIS2 e ISO 27001

A Diretiva NIS2 (UE 2022/2555), transposta para o direito nacional através do DL 65/2025, alarga significativamente o universo de entidades obrigadas a medidas de cibersegurança — muitas empresas industriais de média dimensão passam a estar abrangidas, sobretudo as que operam em cadeias de abastecimento críticas ou fornecem setores essenciais. Uma plataforma de BI concentra dados sensíveis de toda a operação: se for comprometida, expõe tudo de uma vez. Certificações como a ISO 27001 e controlos como EDR e proteção perimetral deixam de ser opcionais. Recomendamos a leitura sobre os riscos silenciosos da cibersegurança na empresa — o BI é precisamente um deles quando mal protegido.

Um painel de BI acessível na rede é um alvo concentrado: reúne, num único ponto, o retrato completo da sua operação. Proteja-o como protege o servidor do ERP.

Há uma dimensão de NIS2 que apanha as empresas industriais de surpresa: a responsabilidade sobre a cadeia de abastecimento. Uma empresa pode não ser, em si, uma entidade essencial — mas se fornece uma que é, passa a herdar exigências de segurança por contágio contratual. A casa-mãe que exige rastreabilidade de lote também começa a exigir garantias de segurança da informação dos seus fornecedores. O BI, sendo o ponto onde os dados se concentram, é o primeiro sítio que uma auditoria de segurança vai querer ver protegido.

SAF-T, DL 28/2019 e a coerência dos dados financeiros

Os indicadores financeiros do seu BI devem bater certo com o que comunica à Autoridade Tributária ao abrigo do DL 28/2019 e da comunicação SAF-T mensal (Portaria 195/2020). Ter um BI que mostra uma facturação e um SAF-T que mostra outra é criar duas versões da verdade perante o fisco — um problema que ninguém quer explicar numa inspeção. A fonte deve ser a mesma: o ERP certificado, com o seu ATCUD e a sua facturação eletrónica em conformidade.

Esta coerência é um argumento a favor de fazer BI sobre o ERP e não à margem dele. Quando o painel financeiro lê diretamente da mesma base de dados que gera o SAF-T, a reconciliação é automática por construção. Quando o BI vive num sistema paralelo, alimentado por exportações manuais, abre-se a porta a divergências — e a divergência entre o que a empresa reporta ao fisco e o que a direção vê nos seus painéis é exatamente o tipo de coisa que transforma uma inspeção de rotina numa dor de cabeça prolongada.

AI Act — quando o BI começa a prever

Assim que o BI ultrapassa o descritivo e entra no preditivo — prever procura, antecipar avarias, estimar risco de rotatividade de pessoal — entra-se no âmbito do Regulamento UE 2024/1689, o AI Act. A maioria destas aplicações industriais cai em risco baixo ou limitado, mas há exceções relevantes: sistemas que avaliem desempenho ou risco de trabalhadores podem classificar-se em categorias de risco mais elevado, com obrigações acrescidas de transparência e supervisão humana. Antes de ativar um módulo preditivo sobre pessoas, verifique onde ele cai na classificação de risco. A ferramenta de gestão de pessoas que incorpora IA preditiva de rotatividade e absentismo tem de ser desenhada com esta classificação em mente.

Financiamento — PT2030 e PRR

Projectos de digitalização e análise de dados encaixam frequentemente em instrumentos como o PT2030, o COMPETE 2030 e o Norte 2030. A experiência diz-nos que o que trava as candidaturas raramente é a ideia — é o relatório técnico mal fundamentado e a incapacidade de demonstrar métricas de resultado. Um projecto de BI bem definido, com indicadores de partida e de chegada, é precisamente o tipo de investimento que estes programas gostam de aprovar.

O segredo, na nossa experiência com estas candidaturas, está na quantificação do antes e do depois. Um projecto que diz "vamos melhorar a eficiência" é rejeitado ou fica preso em pedidos de esclarecimento. Um projecto que diz "o OEE médio das três linhas é hoje de X%, e o investimento visa levá-lo a Y% em dezoito meses, medido pelo sistema de captura" tem uma história que o avaliador consegue defender. O BI é, ironicamente, a ferramenta que produz as métricas que justificam o próprio financiamento do BI — desde que se comece por medir o ponto de partida antes de investir.

8. Como a INFOS aborda isto

Trabalhamos indústria portuguesa há mais de três décadas, e a lição principal é esta: o BI não começa no BI. Começa em ter dados operacionais fiáveis. Por isso ligamos o Qlik Sense a fontes que já capturam a operação de forma estruturada — o ERP MULTI para o núcleo de gestão, o KORA Productivity para o chão de fábrica, o KORA Inventory Suite para o armazém. O dado nasce estruturado na origem, não é remendado no fim.

Essa é a vantagem de um fornecedor que conhece o setor: sabemos que uma coleção de calçado tem três eixos de variante, que uma tinturaria do Vale do Ave precisa de rastreabilidade de lote para compliance, que o chefe de armazém não larga o rádio por mais de duas horas. Modelamos o BI sobre essa realidade, não sobre um modelo genérico importado.

Este conhecimento setorial traduz-se em algo concreto: o modelo de dados chega em grande parte pré-desenhado. Um ERP generalista entregue a uma consultora genérica obriga a empresa a explicar, do zero, como funciona uma matriz de variante de calçado ou como se calcula o rendimento de um lote de fio. Nós já sabemos. Isso encurta o projecto e, mais importante, reduz a dependência do responsável de informática autodidata que, de outra forma, ficaria como único guardião de um modelo que ninguém mais entende.

Não vendemos ecrãs bonitos sobre dados maus. Quando os dados na origem não chegam, dizemo-lo — e tratamos da recolha primeiro.

É menos glamoroso do que uma demonstração de dashboards, mas é o que faz o projecto sobreviver ao segundo mês. Para casos de análise de dados com IA aplicada, explorar como transformar dados em decisões automatizadas é o passo seguinte natural — depois de o básico da recolha estar sólido, nunca antes.

Multi Connect e a consolidação entre filiais

Para os grupos que enfrentam o desafio do Modelo 4 — várias entidades, vários sistemas — a integração entre filiais e parceiros do ERP MULTI resolve o problema de raiz antes de este chegar ao BI. Quando as entidades partilham uma base de definições comuns, a consolidação deixa de ser um exercício de reconciliação penoso e passa a ser uma agregação natural. É o trabalho de semântica de que falámos: feito na camada de integração, o BI que assenta por cima herda dados já coerentes.

9. Roadmap 30/60/90 dias

Um projecto de BI industrial que não mostra valor nos primeiros 90 dias perde o apoio da direção e morre. Estruture-o para entregar cedo e crescer depois.

Dias 1-30 — fundações e um caso real

• Inventarie as fontes de dados e valide a fiabilidade da recolha na fonte — este é o trabalho invisível que determina tudo o resto.
• Escolha uma única decisão de negócio de alto valor (ex.: margem por cliente, ou OEE de uma linha crítica) e defina o indicador com precisão.
• Construa uma prova de conceito com dados reais dessa decisão. Marco verificável: um painel funcional que uma pessoa da direção usa numa reunião real.

Dias 31-60 — modelo de dados e primeira área a sério

• Consolide um modelo de dados governado, com definições de indicadores certificadas e uma fonte única de verdade.
• Coloque uma área inteira em produção — tipicamente vendas/margem ou produção de uma linha. Marco: os relatórios manuais dessa área deixam de ser feitos em Excel.
• Se o caso envolve chão de fábrica, comece a captura de produção em piloto numa linha, com os operadores envolvidos desde o primeiro dia.

Dias 61-90 — escala controlada e governança

• Alargue a mais duas ou três decisões, sempre validando uso real antes de acrescentar indicadores.
• Formalize a governança: quem pode criar painéis, quem certifica indicadores, como se protege o acesso (alinhado com RGPD e política de segurança).
• Defina o próximo horizonte — captura em tempo real alargada, consolidação multi-fábrica ou analítica preditiva — com base no que os primeiros 90 dias ensinaram. Marco: um plano de

Perguntas frequentes

Qual é a diferença entre ter muitos dados e ter dados úteis para decisão?

Dados úteis chegam a tempo, são fiáveis e respondem a perguntas operacionais reais. Muitos dados chegam atrasados, dispersos em sistemas diferentes e contraditórios. Uma folha de cálculo com números de ontem não serve para decidir hoje numa fábrica que muda de artigo três vezes por dia. O valor está na velocidade e coerência, não no volume.

Por que é que o Qlik Sense sozinho não resolve os problemas de BI industrial?

Porque nenhuma ferramenta de visualização consegue corrigir dados que nascem atrasados, incompletos ou dispersos. O Qlik Sense é excelente para mostrar padrões, mas só funciona bem se os dados que o alimentam forem fiáveis e chegarem em tempo real. Comprar um dashboard bonito sem resolver a recolha de dados no chão de fábrica é gastar dinheiro em cosmética.

Como é que a latência de informação afeta a rentabilidade de uma fábrica?

A latência custa em capacidade perdida, decisões erradas e penalizações contratuais. Uma linha parada porque o aviso de rutura só apareceu no mapa do dia seguinte, ou uma encomenda aceite sem saber que a linha crítica estava sobrecarregada, geram custos que não aparecem numa rubrica contabilística mas diluem-se em mil pequenas ineficiências diárias.

Qual é a diferença entre uma tinturaria e uma serralharia em termos de urgência de BI?

A urgência de BI não depende do tamanho da empresa, mas da velocidade a que a operação muda de estado. Uma tinturaria que vira um lote em horas não pode tomar decisões com dados diários — a latência é tóxica. Uma serralharia que trabalha peças de série longa tem mais margem para esperar. Quanto mais curto o ciclo, mais crítica é a informação em tempo real.

Como é que as grandes marcas estão a forçar as fábricas portuguesas a melhorar o BI?

As marcas internacionais exigem rastreabilidade de lote, indicadores de cumprimento de prazo e dados de sustentabilidade em tempo real. Uma confeção que aponta produção a papel não consegue responder. A pressão vem de portais próprios das marcas com deadlines apertados, e quem não consegue fornecer dados fiáveis perde encomendas para concorrentes melhor equipados digitalmente.

Por que é que os números do ERP, da folha de cálculo e da qualidade nunca batem certo?

Porque cada sistema mede coisas diferentes com definições diferentes. O ERP conta peças facturadas, o encarregado conta peças produzidas, a qualidade conta peças conformes. Referem-se ao mesmo lote mas raramente coincidem. Quando não batem, a direção gasta tempo a reconciliar números em vez de a decidir sobre eles, atrasando reuniões e decisões operacionais.

Como é que o calçado de Felgueiras consegue responder rapidamente a pedidos de encomenda com 1000 SKUs?

Precisa de BI que modele a variante como uma matriz (cor, tamanho, forma) em vez de tratar cada combinação como artigo independente. Um ERP generalista desmorona-se sob dezenas de milhares de linhas. Um sistema desenhado para o setor, alimentado por dados em tempo real de capacidade e stock, permite responder em minutos a perguntas de viabilidade que hoje levam horas ou dias.

Fontes

• Estratégia da UE para Têxteis Sustentáveis e Circulares — Comissão Europeia, Direção-Geral do Ambiente (2022)
• Norma ISO/IEC 27001:2022 — Sistemas de Gestão da Segurança da Informação (aplicável a dados operacionais em ambiente industrial)
• Regulamento (UE) 2016/679 (RGPD) — Proteção de dados pessoais em sistemas de rastreabilidade de produção
• IAPMEI — Programa de Modernização e Transformação Digital da Indústria Portuguesa (orientações para BI e automação em PME)