Numa fábrica de malhas perto de Vizela, o diretor industrial abre o portátil às 8h05 e faz o mesmo ritual de há sete anos: exporta três ficheiros do ERP, cola-os num Excel com quarenta separadores, corre uma macro que ninguém sabe já quem escreveu, e às 9h30 tem finalmente o mapa de produção de ontem. Ontem. O turno da noite fechou às 6h. A máquina 4 esteve parada três horas por rebentamento de fio e ele só vai descobrir isto quando o Excel abrir — quando já não há nada a fazer sobre o turno de ontem.
A tese deste artigo é simples e desconfortável: o problema do BI industrial em Portugal não é a falta de dados nem a falta de ferramenta — é que a maioria dos dashboards é construída para impressionar a administração, não para o encarregado usar às 3h da manhã. Qlik Sense resolve o problema técnico. Só resolve o problema real quando o desenhas a partir do chão-de-fábrica para cima, e não do slide do CEO para baixo.
Ao longo de 35 anos a implementar software vertical em fábricas do Norte, vimos o mesmo padrão repetir-se em têxtil, calçado, metal e distribuição: empresas que compram tecnologia de topo e continuam a decidir por intuição. Não por falta de vontade — por falta de sequência. Este artigo é sobre a sequência certa.
1. O problema operacional real
Comecemos pelo que não se diz nas demonstrações. Em 2025, 45% das empresas em Portugal faziam análise de dados — mais 6,4 pontos que em 2023, segundo o INE. Parece progresso. É. Mas o número esconde uma verdade cruel: a "análise de dados" da maioria destas empresas é um analista financeiro a fazer tabelas dinâmicas em Excel no dia 4 de cada mês sobre o que aconteceu no mês anterior.
Isso não é business intelligence industrial. É contabilidade retrospetiva com gráficos.
O fecho de mês que ninguém acredita
Numa confeção típica do Vale do Ave, o "fim de mês" tem um som próprio: o barulho da impressora a cuspir listagens, a chamada ao IT às 18h40 porque "o mapa de eficiência não bate com o da produção", e a reunião de segunda em que três pessoas discutem qual dos três Excel está certo. Nenhum está. Cada um foi construído a partir de uma exportação diferente, num momento diferente, com regras de arredondamento diferentes.
O sintoma clássico: a administração tem dados, mas não confia neles. E se não confia, decide por intuição — que é exatamente o que o BI devia ter eliminado.
Há uma economia escondida neste ritual. Se uma pessoa gasta dois dias por mês a reconciliar folhas de cálculo, são cerca de 24 dias por ano — mais de um mês de trabalho anual dedicado a produzir números em que ninguém confia plenamente. Multiplique isto pelas três ou quatro pessoas que, em muitas empresas, mantêm cada uma o seu Excel paralelo, e o custo do não-BI torna-se maior do que o custo do BI. Só que o primeiro está escondido em horas de trabalho dispersas, e o segundo aparece numa fatura.
O desfasamento temporal como imposto invisível
O denominador comum de todos os sintomas é o desfasamento temporal. Entre o evento e o número passa demasiado tempo, e num negócio industrial de margem apertada o tempo entre o problema e a sua deteção é dinheiro que já saiu pela porta. A margem operacional de uma confeção que subcontrata para casa-mãe raramente é confortável — muitas trabalham com margens de um dígito. Nessas condições, três horas de máquina parada num turno que só se descobre no dia seguinte não são um contratempo: são a diferença entre uma ordem lucrativa e uma ordem no vermelho.
O desfasamento tem três origens distintas, e é útil separá-las porque cada uma se corrige de forma diferente:
- Latência de captura — o evento acontece no chão-de-fábrica mas só é registado no fim do turno, em papel, e lançado no sistema horas ou dias depois.
- Latência de reconciliação — os dados existem em vários sítios e alguém tem de os juntar manualmente antes de fazerem sentido.
- Latência de confiança — o número existe e está disponível, mas ninguém acredita nele o suficiente para agir, por isso pede-se uma segunda validação que atrasa tudo.
Os três buracos por setor
Cada vertical tem o seu buraco de informação particular, e é importante nomeá-los com precisão:
- Têxtil e acabamentos — o custo real por lote não se sabe até ao fecho, porque o consumo de corante, energia e água por partida não é capturado em tempo real. Quando a marca pede prova de conformidade com a Estratégia da UE para os Têxteis Sustentáveis e Circulares, a fábrica não tem os dados de rastreabilidade de lote estruturados.
- Calçado — uma coleção de amostras em Felgueiras tem 800 a 1200 SKUs com três eixos (cor, tamanho, forma). O ERP genérico modela isto mal, e o resultado é que ninguém consegue dizer, a meio da época, que modelos estão a puxar encomenda e quais estão a queimar amostras sem retorno.
- Distribuição alimentar — o chefe de armazém sabe de cor onde estão as coisas, mas quando ele está de férias o desempenho do picking cai e ninguém tem um número para o provar nem para agir.
Um dashboard que chega no dia 4 sobre o mês anterior não é informação de gestão — é uma autópsia.
O buraco do têxtil visto de perto
Entre numa tinturaria de Vale do Ave numa tarde de agosto. O cheiro do banho de tingimento fica na roupa durante horas. Há uma partida de malha a tingir num jet e o mestre-tintureiro sabe, pela experiência, quanto corante e quanta água leva aquela receita. Mas "saber pela experiência" não é o mesmo que ter o consumo registado por partida, associado à ordem de fabrico, ao cliente e ao lote. Quando a marca cliente — uma casa que já assinou compromissos de sustentabilidade — pede a pegada de água e a rastreabilidade química do artigo que comprou, a fábrica tem duas semanas de trabalho manual pela frente a reconstruir dados que deviam ter sido capturados no momento.
A Estratégia da UE para os Têxteis Sustentáveis e Circulares e o futuro Passaporte Digital de Produto vão tornar isto obrigatório, não facultativo. A fábrica que hoje captura consumo por partida está a construir um ativo comercial; a que continua a fazê-lo de memória está a acumular uma dívida técnica que se paga em encomendas perdidas.
O buraco do calçado e a tirania dos SKUs
Felgueiras e S. João da Madeira vivem em ciclos de duas épocas — a coleção de homem que os compradores internacionais vêm ver em agosto, a de mulher em fevereiro. Uma coleção de amostras com mil SKUs, cruzando cor, tamanho e forma, gera uma explosão combinatória que os ERPs generalistas tratam como se cada variante fosse um produto independente. Não é. É o mesmo modelo com eixos. Quando o sistema não modela isto corretamente, a análise a meio da época — que modelos confirmam encomenda depois da feira, quais ficam encalhados — torna-se impossível de fazer a tempo de reagir.
No calçado, o BI que interessa é o que responde, a meio de setembro, a uma pergunta simples: dos 900 modelos que mostrámos em agosto, quais estão a puxar encomenda firme e devemos empurrar para produção, e quais custaram protótipo e couro sem retorno? Sem os três eixos bem estruturados no ERP, essa pergunta só tem resposta no fecho da época — tarde demais.
2. O que é exatamente Qlik Sense dashboards produção industrial
Qlik Sense é uma plataforma de Self-Service BI — análise de dados que combina um motor associativo próprio com visualização interativa. A diferença técnica face às ferramentas de query tradicionais está no motor: em vez de percorrer caminhos de junção pré-definidos (SQL query por query), o Qlik carrega os dados em memória e mantém todas as associações vivas ao mesmo tempo.
O que o "motor associativo" significa no chão-de-fábrica
Traduzindo para linguagem de encarregado: quando clicas numa máquina, o dashboard mostra-te instantaneamente que ordens de fabrico passaram por ela, que operadores, que turnos, que defeitos — e também, e isto é o ponto, o que não está associado (fica a cinzento). Vês simultaneamente o que se relaciona e o que está excluído. Numa análise de causas de paragem, ver o que não aconteceu é frequentemente mais revelador do que ver o que aconteceu.
Dou um exemplo real de raciocínio. Um diretor de produção seleciona no dashboard todas as ordens que fecharam com atraso no último trimestre. O motor associativo, ao filtrar, deixa acesos os operadores, as máquinas e os turnos envolvidos — e apaga tudo o resto. De repente vê-se que, das doze máquinas da secção, apenas três aparecem acesas nos atrasos, e um turno específico está sobre-representado. Isto não é um relatório que alguém pediu; é uma descoberta que emergiu de clicar e ver o que ficou a cinzento. Nenhuma tabela dinâmica de Excel faz isto sem que já se saiba de antemão o que procurar.
Um dashboard de produção industrial em Qlik Sense combina tipicamente:
- Dados de captura de chão-de-fábrica (terminais, sensores, apontamentos de operador) — quantidades produzidas, tempos, paragens, defeitos, medidos idealmente ao nível do OEE.
- Dados do ERP — ordens de fabrico, gamas operatórias, custos-padrão, consumos de material, planeamento.
- Dados comerciais e logísticos — carteira de encomendas, prazos, prioridades, situação de SCM.
Uma breve nota histórica que importa
O Qlik nasceu na Suécia nos anos 90 com o QlikView, e o salto para o Qlik Sense (a partir de 2014) foi precisamente a passagem do dashboard construído por um programador para o dashboard que o utilizador de negócio compõe sozinho. Essa distinção — quem constrói a análise — é o que separa uma cultura data-driven de uma cultura de dependência do IT. Vale a pena ler como se dá o primeiro passo para uma organização data-driven antes de escolher ferramenta nenhuma.
OEE, MES, MRP — arrumar os acrónimos
Há confusão recorrente entre estas três coisas, e ela mata projetos. O OEE (Overall Equipment Effectiveness) é uma métrica: disponibilidade × desempenho × qualidade. O MES é o sistema que captura o que se passa na máquina. O MRP é o motor de planeamento de necessidades no ERP. Qlik Sense não é nenhum destes três — é a camada de leitura que junta os dados dos três e os transforma em decisão. Se não tens captura de chão-de-fábrica a alimentar o Qlik, estás a fazer dashboards bonitos sobre dados que continuam a chegar no dia 4.
| Sigla | O que é | Onde vive | O que o Qlik faz com isto |
|---|---|---|---|
| OEE | Métrica: disponibilidade × desempenho × qualidade | Calculado a partir de dados de máquina e ordens | Visualiza tendência, decompõe as três parcelas, compara linhas |
| MES | Sistema de captura e execução de produção | Chão-de-fábrica: terminais, sensores | Lê os eventos capturados e transforma-os em séries analisáveis |
| MRP | Motor de planeamento de necessidades | Núcleo do ERP | Cruza o plano com o realizado para mostrar desvios |
| BI (Qlik) | Camada de leitura e decisão | Por cima de todos os anteriores | É o próprio Qlik: junta, associa, revela |
Porque o OEE decompõe mais do que resume
O valor do OEE não está no número final — está na decomposição. Um OEE de 65% pode ter causas radicalmente diferentes: pode ser disponibilidade baixa (máquina para muito), desempenho baixo (anda abaixo da cadência nominal) ou qualidade baixa (produz mas rejeita). Cada uma exige uma ação de gestão distinta. Um dashboard que mostra apenas "OEE: 65%" é quase inútil; um que mostra "65% = 82% disponibilidade × 88% desempenho × 90% qualidade" diz ao encarregado onde atacar primeiro. É esta a diferença entre um indicador e uma ferramenta de decisão.
3. O panorama em Portugal hoje
Os números do INE de 2025 desenham o cenário real, e ele é menos avançado do que os fornecedores gostam de sugerir:
| Indicador (empresas em Portugal, 2025) | Valor | Leitura |
|---|---|---|
| Fazem análise de dados (big data/analytics) | 45% | +6,4 pp face a 2023; ainda não é maioria robusta |
| Usam ERP | 53,7% | Quase metade não tem núcleo integrado para o BI ler |
| Adquirem serviços de cloud | 38,7% | A infraestrutura para BI moderno ainda é minoritária |
O cruzamento destes três números é o insight que a maioria ignora: não se pode fazer BI industrial sério sem ERP integrado, e quase metade das empresas portuguesas ainda não o tem. Vender Qlik Sense a quem não tem os dados arrumados no ERP é vender um microscópio a quem ainda não recolheu a amostra.
A distância entre a média e a fábrica típica
Há uma nuance importante nestas médias nacionais: elas incluem grandes empresas de serviços, banca e telecomunicações, que puxam os números para cima. A fábrica de confeção com 60 pessoas ou a metalúrgica familiar com 40 estão, quase sempre, abaixo da média. O tecido industrial do Norte, onde vive grande parte da produção têxtil e de calçado, é feito de empresas pequenas e médias, de propriedade familiar, com uma maturidade digital mais baixa do que a estatística agregada sugere. Quando lê "45% fazem análise de dados", leia "provavelmente muito menos de 45% das fábricas de confeção o fazem de forma que mereça o nome".
O peso industrial que justifica o investimento
Ao mesmo tempo, o tecido industrial que beneficia disto é enorme. Só o setor metalúrgico e metalomecânico português tem mais de 23 mil empresas e cerca de 250 mil pessoas empregadas, segundo dados da AIMMAP/Metal Portugal. Junte-se o têxtil, o vestuário, o calçado e a distribuição, e temos centenas de milhares de postos de trabalho numa economia que compete por margem e por prazo — as duas grandezas que um bom dashboard de produção ataca diretamente.
Reshoring, pressão asiática e a corrida ao prazo
O contexto competitivo muda o cálculo. A pressão da concorrência asiática nunca desapareceu, mas o reshoring — marcas europeias a reaproximar produção para encurtar cadeias — deu ao têxtil e ao calçado portugueses uma vantagem que se joga em duas variáveis: prazo curto e flexibilidade de pequenas séries. Uma marca que reencaminha produção para Portugal fá-lo porque quer entregas rápidas e capacidade de resposta a coleções cápsula. Ora, prazo e flexibilidade são precisamente aquilo que só se gere com visibilidade em tempo real. A fábrica que não sabe hoje se vai cumprir a data de embarque de sexta não pode competir por esta vantagem — pode apenas rezar.
O comércio como contexto de fundo
O volume de negócios do comércio em Portugal atingiu 201,8 mil M€ em 2024, com o retalho a crescer 4,7% (INE). Para quem produz para marca ou para retalho, isto significa procura, mas também exigência crescente de prazo, de rastreabilidade e de resposta a picos — precisamente onde a visibilidade em tempo real deixa de ser luxo.
Quase metade das empresas portuguesas ainda não tem ERP. Antes de comprar dashboards, arrume a casa que os alimenta.
O financiamento existe — mas o relatório técnico decide
Há dinheiro disponível para digitalização industrial através do PT2030, do PRR, do COMPETE 2030 e do Norte 2030. Vemos empresas a candidatar-se e a receber apoio para exatamente este tipo de projetos — ERP, captura de chão-de-fábrica, BI. Mas há uma lição prática que convém dizer sem rodeios: o que aprova ou trava uma candidatura não é a ideia, é o relatório técnico. Um projeto de BI industrial bem articulado — com métricas de partida, objetivos quantificados de eficiência e uma sequência de implementação credível — passa. Um projeto formulado como "queremos dashboards para modernizar" fica preso na avaliação. A disciplina de definir KPIs de partida, que defendemos por razões operacionais, é também a que desbloqueia o financiamento.
4. Os modelos de implementação
Há quatro abordagens práticas para implementar dashboards de produção com Qlik Sense, e a diferença entre elas não é técnica — é organizacional. Escolher a errada para a maturidade da empresa é a principal causa de projetos que morrem no piloto.
| Modelo | Como funciona | Bom para | Risco principal |
|---|---|---|---|
| Dashboard financeiro-primeiro | Começa pelos KPIs de gestão (margem, tesouraria, vendas) | CFO que quer prova de valor rápida | O chão-de-fábrica nunca chega a usar |
| OEE-primeiro (chão-de-fábrica) | Captura de produção alimenta dashboards operacionais em tempo real | Fábricas com paragens não explicadas | Exige captura fiável antes do BI |
| Híbrido faseado | OEE operacional + camada de gestão por cima, em fases | A maioria das PMEs industriais | Requer disciplina de roadmap |
| Self-service alargado | Utilizadores de negócio constroem as próprias análises | Empresas com cultura de dados madura | Caos de "verdades" se não houver governance |
O erro de sequência mais caro
Vemos isto repetidamente: empresas que compram Qlik Sense e começam pelos dashboards financeiros porque é o que impressiona a administração. Seis meses depois, a administração tem uns gráficos bonitos e o chão-de-fábrica continua no Excel. O BI ganhou visibilidade política e perdeu utilidade operacional. É o modelo que gera o famoso "temos Qlik mas ninguém usa".
A razão de fundo é psicológica. O dashboard financeiro dá satisfação imediata a quem decide o orçamento, mas não altera nenhuma decisão que se tome no dia. O CFO já sabia, mais ou menos, como estava a margem; agora vê-a mais bonita. Ninguém no chão-de-fábrica muda o que faz por causa dele. E como o valor operacional nunca aparece, o projeto fica órfão de quem o defenda quando chega a altura de renovar ou expandir.
Porque o híbrido faseado ganha quase sempre
Para a PME industrial portuguesa típica — 50 a 250 colaboradores, um ERP vertical, um diretor industrial pragmático — o modelo híbrido faseado é o vencedor. Começa-se pela camada onde o valor é imediato e mensurável (parar de perder três horas de turno sem se saber porquê), e a camada de gestão vem depois, alimentada pelos mesmos dados fiáveis. Este é o padrão que descrevemos em detalhe nos dashboards operacionais para indústria portuguesa.
O dashboard financeiro impressiona quem assina o cheque. O dashboard operacional muda o que se faz no turno. Só um dos dois sobrevive a dois anos.
Quando o self-service alargado é armadilha
O self-service alargado — dar a toda a gente a capacidade de construir as suas próprias análises — soa a democratização e a maturidade. Em empresas com cultura de dados sólida, é. Mas numa organização que ainda discute qual dos três Excel está certo, dar a cada departamento a liberdade de criar as suas métricas é multiplicar o caos, não resolvê-lo. Passa-se do problema dos três Excel para o problema das trinta apps de Qlik, cada uma com a sua definição de OEE. A liberdade de análise sem uma camada de dados governada e definições únicas produz mais discórdia, mais elegante. Governance primeiro, liberdade depois.
Tempo real não é o mesmo que rápido
Distinção que poupa desilusões: BI em tempo real exige uma cadeia de dados a montante que muitas fábricas não têm. Se os operadores apontam a produção em papel e alguém lança no ERP ao fim do turno, o teu "tempo real" é, no melhor dos casos, tempo-do-fim-do-turno. Sensores e terminais industriais, muitas vezes com protocolos como MQTT a transportar leituras de máquina, são o que torna o tempo real literal. Sem eles, sê honesto sobre a latência.
5. Como avaliar se a sua empresa precisa
Antes de qualquer projeto, faz-se um diagnóstico de prontidão. Não é sobre querer dashboards — toda a gente quer. É sobre ter as condições para que eles sejam usados.
Sinais de que precisa mesmo
- O fecho de produção demora mais de dois dias e ninguém confia plenamente no número final.
- Existem três ou mais Excel "oficiais" que dizem coisas diferentes sobre a mesma realidade.
- Quando uma máquina para, ninguém consegue dizer no dia seguinte durante quanto tempo e porquê.
- As decisões de prioridade de ordens de fabrico são tomadas pela pessoa que grita mais alto, não por dados de carteira e capacidade.
- Uma marca cliente já vos pediu dados de rastreabilidade ou de sustentabilidade que demoraram semanas a compilar.
Sinais de que ainda não é o momento
Há também sinais honestos de que o BI é prematuro, e um bom fornecedor di-lo em vez de vender à mesma:
- Não há ERP integrado — os dados de vendas, compras e produção vivem em sistemas ou folhas separados que não se falam.
- Ninguém na organização consegue ser dono dos dados de um domínio; toda a informação depende da memória de uma ou duas pessoas.
- A empresa nunca acordou uma definição única de sequer um KPI — cada pessoa calcula a eficiência à sua maneira.
- Não há vontade de mudar a rotina do chão-de-fábrica; a expectativa é que o BI resolva sem que ninguém apure a captura.
Passo a passo do diagnóstico de prontidão
- Inventarie as fontes de dados. Liste onde vivem hoje os números de produção, custo e vendas — ERP, terminais, folhas de Excel, cadernos do encarregado. Se mais de metade está fora do ERP, o problema é de captura, não de BI.
- Meça a latência real. Cronometre quanto tempo passa entre um evento no chão-de-fábrica (uma paragem, uma quantidade produzida) e o momento em que esse dado fica disponível num sistema. Este número define o tecto do que o BI pode fazer.
- Identifique os três KPIs que mudam decisões. Não os vinte que ficam bem no ecrã — os três que, se os visse a tempo, mudariam uma ação. Para muitas fábricas é OEE, cumprimento de prazo e custo real por ordem.
- Nomeie os utilizadores reais. Quem vai olhar para cada dashboard, quando, e em que dispositivo? Se a resposta para o dashboard operacional não for "o encarregado, várias vezes por turno, num terminal no chão", esse dashboard vai morrer.
- Valide a fonte de verdade. Confirme que existe um sistema — idealmente o ERP MULTI ou equivalente — que é a referência única. BI sobre múltiplas verdades multiplica a confusão, não a resolve.
O melhor teste de um dashboard não é a administração gostar. É o encarregado abri-lo sem que ninguém lho peça.
Dois quick wins antes do projeto grande
Duas coisas que uma empresa implementa em uma a duas semanas, mesmo antes de qualquer projeto formal: primeiro, consolidar as três folhas de Excel conflituantes numa única com regras acordadas — só o exercício de acordar as regras já revela metade dos problemas. Segundo, cronometrar manualmente as paragens de uma máquina crítica durante uma semana, com o operador a anotar causa. O choque de ver o número real costuma ser o argumento que desbloqueia o orçamento.
O trio de decisão português e como cada um lê o diagnóstico
Nas empresas familiares que servimos, a decisão cristaliza-se quase sempre num trio: o CEO, o CFO e a pessoa de IT — frequentemente um herói autodidata com quinze anos de conhecimento do negócio e nenhum diploma formal, que conhece o sistema melhor do que quem o vendeu. Cada um lê o diagnóstico de prontidão por uma lente diferente, e o projeto só arranca quando os três veem valor:
| Decisor | O que o preocupa | Como o diagnóstico o convence |
|---|---|---|
| CEO | Competitividade, prazo, relação com marcas clientes | O sinal de que uma marca pediu dados que demoraram semanas a compilar |
| CFO | Retorno, custo escondido, margem real por ordem | O cálculo das horas perdidas em reconciliação de Excel |
| IT / herói autodidata | Não herdar mais um sistema que ninguém usa | A prova de que a captura e a fonte de verdade estão arrumadas antes do BI |
6. O que escolher e porquê (decisão por dimensão de empresa)
A recomendação muda consoante a dimensão e a maturidade. Não há resposta única, e desconfie de quem lhe der uma.
| Perfil | Prioridade | Abordagem recomendada |
|---|---|---|
| <50 colaboradores, sem ERP integrado | Arrumar a fonte de dados primeiro | ERP vertical antes de BI; dashboards financeiros simples como início |
| 50–150, ERP integrado, produção manual | Captura de chão-de-fábrica | Terminais de captura + OEE, depois Qlik Sense sobre esses dados |
| 150–250, ERP + captura existente | Modelo híbrido faseado | Qlik Sense operacional + gestão, com governance de dados |
| >250 ou multi-filial | Complexidade e integração | ERP de maior complexidade + BI corporativo + integração entre filiais |
Para a empresa pequena sem ERP integrado
É a maior tentação e o maior erro: querer saltar diretamente para os dashboards porque parecem o passo mais visível. Numa empresa com menos de 50 pessoas e sem ERP integrado, o BI não tem de onde ler. A prioridade é montar o núcleo — um ERP vertical que modele o setor — e só depois pensar em visualização. Nesta fase, um punhado de dashboards financeiros simples, ligados ao ERP acabado de instalar, é suficiente para criar o hábito de olhar para números fiáveis. Correr para o Qlik antes disto é construir o telhado antes das fundações.
Para a empresa sem captura de chão-de-fábrica
Este é o caso mais comum e o mais mal servido. A tentação é comprar o BI e "depois logo se vê a captura". Errado. Sem dados de máquina fiáveis, o Qlik Sense vai mostrar com precisão gráfica os dados errados dos apontamentos manuais. A ordem correta é: primeiro a captura em tempo real com KORA Productivity, depois a visualização com Qlik Sense. O OEE calculado a partir de apontamentos manuais é ficção com casas decimais.
Há aqui um ganho colateral frequentemente subestimado. Quando se instala captura de produção, o primeiro benefício não é o dashboard — é o número honesto. Uma fábrica que julgava ter uma disponibilidade de máquina de 85% descobre, com dados reais, que anda mais perto de 65%, porque as micro-paragens que ninguém contava somam horas. Este choque, doloroso no início, é o que torna toda a discussão de melhoria finalmente concreta. Não se melhora o que não se mede com honestidade.
Para a empresa multi-filial
Quando há mais do que uma unidade — algo comum no calçado e no têxtil, com produção distribuída e subcontratação — o desafio é a consolidação. Os dados têm de convergir com definições idênticas antes de chegarem ao dashboard. A integração entre unidades, com ferramentas como Multi Connect, tem de estar resolvida a montante, ou vai passar a vida a explicar porque é que o OEE da fábrica A e da fábrica B não são comparáveis.
O problema mais insidioso aqui não é técnico — é semântico. A fábrica A conta como "paragem" tudo o que ultrapassa cinco minutos; a fábrica B só conta acima de quinze. A fábrica A mede quantidade produzida à saída da máquina; a fábrica B mede depois do controlo de qualidade. Junte-se os dois no mesmo dashboard e obtém-se uma comparação sem sentido, que gera desconfiança em vez de decisão. A consolidação multi-filial começa por uma reunião aborrecida onde se acorda o significado exato de cada palavra. Sem essa reunião, nenhuma ferramenta salva o projeto.
Para a empresa de grande complexidade
Nas organizações acima dos 250 colaboradores, com múltiplas unidades, processos muito específicos ou requisitos de integração pesados, o próprio ERP pode precisar de ser de outra classe. É o contexto para um ERP de grande complexidade e low-code como o QAD Adaptive ERP, capaz de acomodar processos que fogem ao standard sem que cada alteração exija reescrever código. O BI corporativo por cima destes sistemas ganha uma dimensão de governança — quem vê o quê, com que perfil, em que unidade — que numa PME é acessória mas aqui é central.
O terminal que o encarregado esconde
Uma verdade operacional que 35 anos em fábricas ensinam: o tablet ou terminal de captura que fica no chão-de-fábrica vai ser maltratado. Vai apanhar pó de fio, vai ser colado com fita-cola a uma coluna, vai desaparecer misteriosamente antes de uma auditoria. Se o dashboard operacional depende de um dispositivo frágil ou de um login complicado, morre. O ecrã de captura tem de ser tão simples que um operador o use com luvas e sem pensar. Este detalhe, aparentemente menor, decide mais projetos do que qualquer funcionalidade avançada do BI.
O ecrã de captura tem de funcionar com luvas, com pó de fio e sem manual. Se exige um curso, já perdeu.
A resistência do chefe de armazém e como não a ignorar
No corredor Lousada–Paços de Ferreira, num centro de distribuição, o chefe de armazém é rei. Conhece de cor onde está cada palete e move a operação a partir de um rádio na mão. Qualquer rollout que o tire do rádio mais de duas horas vai ter um inimigo determinado — e ele vai ganhar, porque a operação não pode parar e a administração sabe-o. A lição para quem implementa gestão de armazém e o BI que a lê: envolva-o desde o primeiro dia, faça-o dono de uma métrica que o valorize (a produtividade de picking que ele intui mas nunca provou), e nunca, nunca desenhe o processo numa sala longe do armazém. O melhor dashboard de logística é o que dá razão ao chefe de armazém com números — não o que tenta substituí-lo.
7. Quadro regulatório e conformidade aplicável
Dashboards de produção parecem neutros do ponto de vista regulatório. Não são. Assim que ligas dados de ERP, de RH e de faturação numa plataforma acessível por rede, entras num conjunto de obrigações que convém conhecer antes, não depois da auditoria.
Dados que alimentam o BI e a certificação AT
Os dados de faturação que entram nos dashboards comerciais vêm de um sistema que tem de estar certificado pela Autoridade Tributária, ao abrigo do DL 28/2019, com ATCUD e comunicação SAF-T mensal (Portaria 195/2020). O BI lê estes dados, não os substitui — mas se a fonte não for conforme, os números comerciais do dashboard herdam o problema.
RGPD quando o dashboard toca em pessoas
Um dashboard de produtividade que mostra desempenho por operador processa dados pessoais. O RGPD e a Lei 58/2019 aplicam-se: minimização, finalidade, e cuidado especial com métricas individuais que podem derivar para monitorização abusiva. A regra prática é agregar por equipa ou linha sempre que a decisão de gestão não exija o indivíduo. Um dashboard de Employee Engagement mal desenhado é um risco de conformidade e de clima social ao mesmo tempo.
Há uma tensão real aqui que não se resolve com tecnologia. O diretor industrial quer saber quem produz mais e quem menos; a lei e o bom senso de clima social pedem contenção no uso de métricas individuais. A saída equilibrada é distinguir o propósito: para gerir o processo (onde estão os estrangulamentos, que linha precisa de apoio), agregue por equipa; para gerir a pessoa (formação, reconhecimento, correção), use o dado individual dentro do quadro legal de gestão de pessoas, com transparência para o trabalhador. Uma plataforma como o pplPortal trata estes dados no contexto próprio de gestão de pessoas, separando-os da vitrina operacional que todos veem no chão-de-fábrica.
Cibersegurança: NIS2 e o acesso ao BI
A Diretiva NIS2 (UE 2022/2555), transposta em Portugal pelo DL 65/2025, alarga as obrigações de cibersegurança a mais setores, incluindo indústria transformadora relevante. Um servidor de BI com dados operacionais e financeiros de toda a empresa é um alvo. Acesso com MFA, gestão de perfis e uma postura de segurança séria deixam de ser opcionais. Quem trata dados críticos deve conhecer os riscos silenciosos da cibersegurança na empresa e o papel de uma proteção perimetral com SOC. Certificações como a ISO 27001 estruturam esta disciplina.
O servidor de BI concentra os dados mais valiosos da empresa num só sítio. Isso torna-o a jóia da coroa — e o alvo preferido.
A IA preditiva e o AI Act
Quando o dashboard evolui de descrever o passado para prever o futuro — antecipar rutura de material, sinalizar risco de atraso de uma encomenda a partir de padrões históricos — entra-se no território do Regulamento (UE) 2024/1689, o AI Act, que classifica sistemas de IA por nível de risco. A maioria das aplicações preditivas de produção é de baixo risco, mas há uma zona sensível: qualquer uso de IA que toque na avaliação ou gestão de pessoas cai em categorias de risco mais exigentes. Antes de deixar a inteligência preditiva aproximar-se de dados de trabalhadores, classifique o risco e documente-o. É trabalho aborrecido que evita problemas sérios.
Um mapa de conformidade para não esquecer nada
| Camada do BI | Regulação aplicável | Cuidado prático |
|---|---|---|
| Dados de faturação e vendas | DL 28/2019, Portaria 195/2020 | Fonte tem de ser software certificado AT (ATCUD, SAF-T) |
| Dados de pessoas / produtividade | RGPD, Lei 58/2019 | Agregar por equipa; individual só com finalidade e transparência |
| Acesso e infraestrutura do servidor BI | NIS2 (DL 65/2025), ISO 27001 | MFA, perfis, monitorização; tratar como ativo crítico |
| Módulos preditivos / IA | AI Act (UE 2024/1689) | Classificar risco; cautela redobrada com dados de trabalhadores |
8. Como a INFOS aborda isto
A nossa posição, construída ao longo de 35 anos a implementar software vertical para indústria portuguesa, é que o BI não é um produto isolado — é a camada de leitura de um sistema que já tem de estar bem alimentado. Por isso raramente propomos Qlik Sense em vácuo. Propomo-lo em cima de um ERP MULTI que já modela corretamente a complexidade do setor — os três eixos de SKU do calçado, a rastreabilidade de lote do têxtil, o custo real por ordem de fabrico — e de uma captura de chão-de-fábrica com KORA Productivity que garante que o OEE no dashboard é medido, não estimado.
Trabalhamos o modelo híbrido faseado porque é o que sobrevive ao teste do encarregado às 3h da manhã. Começamos pela camada operacional, onde o valor é imediato e visível, e construímos a camada de gestão por cima, sobre os mesmos dados. Isto evita o cenário mais frequente e mais frustrante: a empresa que "tem Qlik" mas em que só o departamento financeiro o abre.
Porque a verticalização não é um slogan
A diferença entre um BI genérico e um BI que serve uma fábrica de calçado está no modelo de dados por baixo. Se o ERP trata cada variante cor-tamanho-forma como um produto solto, o dashboard herda essa fragmentação e nunca conseguirá agrupar por modelo de forma útil. Se o ERP modela os três eixos como aquilo que são — dimensões do mesmo artigo — o BI ganha, de graça, a capacidade de analisar por qualquer combinação. A verticalização paga-se aqui: não em funcionalidades listadas numa brochura, mas na estrutura invisível que torna certas perguntas respondíveis. Um ERP generalista pode chegar lá com customização pesada; um ERP que já nasceu para o setor chega lá por defeito.
Onde entra a captura, a integração e a análise
Na prática, um projeto completo costuma articular várias camadas nossas conforme a necessidade: a captura operacional com KORA Productivity, a gestão de armazém com KORA Inventory Suite quando a logística pesa, a integração entre unidades e parceiros com Multi Connect, e a leitura final com Qlik Sense. Nenhuma destas peças é vendida como fim em si — cada uma existe para que o número certo chegue à pessoa certa a tempo de mudar uma decisão.
A IA entra por último, e com método
Quando o projeto envolve IA preditiva — antecipar rotura de material, prever atrasos de encomenda a partir de padrões históricos — encaixamos essa camada de forma controlada, com atenção à classificação de risco do AI Act. O caminho de transformar dados em decisão automatizada está descrito em detalhe em IA aplicada à indústria, mas o princípio é sempre o mesmo: primeiro os dados fiáveis, depois a inteligência. Um modelo preditivo alimentado por apontamentos manuais atrasados não prevê nada — repete o erro dos dados com uma confiança estatística que não merece.
9. Roadmap 30/60/90 dias
Um plano realista para uma PME industrial que parte de ERP integrado mas sem BI operacional. Marcos verificáveis, não intenções.
Dias 1–30: fundação e verdade única
- Concluir o diagnóstico de prontidão dos cinco passos e documentar a latência real de cada fonte de dados.
- Definir os três KPIs que mudam decisões e acordar, por escrito, a fórmula de cada um — especialmente o OEE, onde 90% das discórdias nascem de definições diferentes de disponibilidade.
- Consolidar as folhas de Excel conflituantes numa fonte de verdade única, ligada ao ERP.
- Nomear o dono de dados de cada domínio (produção, comercial, financeiro). Sem dono, não há governance.
Dias 31–60: primeiro dashboard operacional
- Construir o primeiro dashboard de produção em Qlik Sense, focado numa linha ou secção crítica, não na fábrica inteira.
- Validar com o encarregado dessa linha em ambiente real — não numa sala de reuniões, mas no terminal onde ele vai usá-lo.
- Se a captura de chão-de-fábrica ainda for manual, arrancar a implementação de terminais na linha piloto.
- Medir a adoção: quantas vezes por turno o dashboard é aberto por quem o devia usar. Este é o único KPI do projeto que interessa nesta fase.
Dias 61–90: escala e camada de gestão
- Estender o dashboard operacional às restantes linhas, com definições idênticas para permitir comparação.
- Construir a camada de gestão (margem, cumprimento de prazo, custo por ordem) sobre os mesmos dados já validados.
- Rever os acessos e aplicar MFA e perfis, alinhando com as obrigações de NIS2 e RGPD antes de alargar a base de utilizadores.
- Fazer a primeira reunião de gestão inteiramente sobre o dashboard, sem nenhum Excel na sala. Se alguém ainda trouxer um Excel paralelo, o projeto ainda não terminou.
O que fazer depois dos 90 dias
Os primeiros 90 dias criam a fundação; o que os sucede determina se o BI vira cultura ou fica moda passageira. A partir daqui, o trabalho é de manutenção da confiança: rever definições quando o negócio muda, retirar dashboards que ninguém abre — sim, retirar, porque um portal cheio de análises mortas dilui a atenção das vivas — e resistir à tentação de multiplicar métricas. A regra que damos aos clientes é contraintuitiva: se em seis meses o número de dashboards ativos duplicou mas a média de aberturas por dashboard caiu, o projeto está a piorar, não a melhorar. Menos análises, mais usadas, valem mais do que muitas ignoradas.
É também o momento de considerar a camada preditiva, se e só se os dados descritivos já forem fiáveis e usados. Prever a rutura de um material específico ou o risco de atraso de uma encomenda só faz sentido quando o
Perguntas frequentes
O Qlik Sense é obrigatório para implementar BI industrial ou existem alternativas?
Qlik Sense é uma ferramenta potente, mas não é obrigatória. Existem alternativas como Power BI, Tableau ou Looker. A escolha depende da complexidade dos dados, orçamento e capacidade técnica interna. O importante é que a ferramenta seja usada operacionalmente no chão-de-fábrica, não apenas para relatórios mensais.
Quanto tempo demora a implementação de um dashboard industrial em Qlik Sense?
Varia entre 4 a 12 semanas, dependendo da qualidade dos dados existentes e da complexidade dos processos. Se os dados estão dispersos em múltiplos sistemas ou em Excel, o tempo aumenta. A maior parte do tempo é gasto em limpeza e integração de dados, não na construção do dashboard.
Qual é o custo real de implementar BI numa fábrica pequena?
O custo direto (software + implementação) varia entre 15 mil e 50 mil euros. Mas o retorno surge rapidamente: redução de tempo em reconciliações, deteção mais rápida de problemas operacionais e decisões baseadas em dados reais. Muitas fábricas recuperam o investimento em 6 a 9 meses.
Como evitar que o dashboard fique apenas para a administração?
Desenhe o dashboard a partir do chão-de-fábrica para cima, não do CEO para baixo. Envolver encarregados, mestres de produção e operadores no desenho garante que o dashboard responde a perguntas reais. Um dashboard útil às 3h da manhã para o encarregado é útil para toda a empresa.
O que fazer se os dados da fábrica estão dispersos em vários sistemas?
É comum e não é bloqueante. Qlik Sense consegue integrar dados de múltiplas fontes (ERP, máquinas, Excel, bases de dados). A dificuldade maior é garantir que as definições são consistentes entre sistemas. Isto requer um trabalho prévio de mapeamento e limpeza de dados.
Como garantir que os dados do BI são confiáveis?
A confiança constrói-se em três passos: primeiro, validar que os dados capturados correspondem à realidade operacional; segundo, reconciliar dados de múltiplas fontes com regras claras; terceiro, envolver os utilizadores finais na validação antes de usar em decisões críticas. Sem confiança, o BI não funciona.
Qual é o impacto real de um dashboard operacional na margem de uma fábrica?
Direto: redução de tempo de paragem não detetado, menos desperdício por falta de informação, e decisões mais rápidas. Indireto: menos tempo em reconciliações manuais e mais tempo em ações corretivas. Numa fábrica com margens apertadas, a diferença entre detetar um problema em tempo real ou no dia seguinte pode ser a diferença entre lucro e prejuízo.
Fontes
- Instituto Nacional de Estatística (INE) — Inquérito à Utilização de Tecnologias da Informação e da Comunicação nas Empresas (ITICE), dados sobre análise de dados em empresas portuguesas, 2023-2025
- Estratégia da UE para os Têxteis Sustentáveis e Circulares — Comunicação da Comissão Europeia sobre economia circular no setor têxtil e requisitos de rastreabilidade
- Regulamento (UE) 2024/1781 — Passaporte Digital de Produto (Digital Product Passport) e obrigações de rastreabilidade para produtos têxteis
- Associação Têxtil e Vestuário de Portugal (ATP) — Dados setoriais sobre conformidade ambiental e rastreabilidade em empresas têxteis portuguesas
