BI com Qlik Sense: dashboards operacionais para indústria portuguesa

Numa fábrica de malhas perto de Barcelos, o diretor de produção tinha um ritual às sextas-feiras. Fechava a porta do gabinete, abria seis folhas de Excel — produção, refugo, encomendas em atraso, absentismo, consumos de fio, margens — e passava três horas a colar valores de uma para a outra até conseguir um número em que confiava o suficiente para o levar à reunião de segunda. Esse número já estava velho quando o dizia em voz alta. E era o único que a administração via.

Esta é a tese: a maioria das PMEs industriais portuguesas não tem um problema de dados — tem um problema de latência e de confiança nos dados. Os dados existem, dispersos pelo ERP, pelos terminais de chão-de-fábrica e por trinta ficheiros Excel. O que falta é transformá-los num painel que o gerente de armazém consulta antes do café e o CFO consulta antes do fecho. É isso que um projeto de BI com Qlik Sense resolve — ou estraga, quando mal feito.

O diretor de Barcelos não é uma caricatura. É a norma. E o mais desconfortável é que ele é competente: conhece o negócio de cor, sabe onde estão os erros, adivinha a margem com dois euros de margem de erro. O problema é que esse conhecimento vive na cabeça dele e num ecrã de Excel que só ele entende. No dia em que sair — reforma, doença, uma proposta melhor — a empresa fica cega. E fica cega devagar, sem dar por isso, porque durante meses ninguém repara que os números deixaram de bater certo.

1. O problema operacional real

Segundo o INE, em 2025 apenas 45% das empresas em Portugal faziam análise de dados (big data/analytics), uma subida de 6,4 pontos face a 2023. Ou seja: mais de metade do tecido empresarial português ainda decide sem analítica estruturada. E dentro dos 45% que "fazem análise", uma parte substancial faz o que o diretor de Barcelos fazia — Excel manual, tardio, frágil.

O problema não é abstrato. Tem cheiro, ruído e prazos. Vejamos onde dói, setor a setor.

Têxtil e vestuário: o número que chega tarde de mais

No têxtil do Vale do Ave — Famalicão, Guimarães, Vizela — o ciclo de subcontratação para as casas-mãe (Inditex, Decathlon, Tom Tailor) vive de duas coisas: cumprir data e defender margem. O problema é que a margem real de uma ordem de confeção só se conhece depois de fechada, quando alguém soma os tempos de máquina, o refugo de tecido, as horas extra e o custo do fio efetivamente consumido. Nessa altura, a próxima ordem já está em curso com o mesmo erro de orçamentação.

Um dashboard operacional inverte a ordem: mostra a margem projetada enquanto a ordem está em produção, cruzando o consumo real de fio com o standard. Quando o desvio passa de 4%, o responsável de planeamento vê-o na segunda-feira, não no fecho do mês.

Há uma camada adicional que se tornou obrigatória e não intuição. A Estratégia da UE para os Têxteis Sustentáveis e Circulares, e o quadro do passaporte digital de produto que a acompanha, empurram as casas-mãe a exigir rastreabilidade de lote aos subcontratados portugueses. Uma marca alemã que vende na Alemanha quer saber de que tinturaria saiu o lote, com que composição, com que consumo de água e energia. No vestuário, a confeção que não conseguir devolver esse dado depressa perde a encomenda para quem consegue. E esse dado — número de lote, ficha técnica, consumo — é exatamente o tipo de informação que um BI bem alimentado cruza sem drama, desde que nasça fiável no ERP.

A rastreabilidade de lote deixou de ser um capricho de auditor. É o passe de entrada para continuar a produzir para as marcas europeias.

Há aqui uma nuance por dimensão. A confeção de 40 pessoas que trabalha exclusivamente para uma casa-mãe tem um problema diferente da fiação de 120 pessoas que serve vinte clientes. A primeira precisa de defender margem numa relação de dependência — o BI serve para não perder dinheiro em ordens que o comprador impõe. A segunda precisa de decidir que clientes vale a pena manter — o BI serve para descobrir que dois dos vinte clientes consomem metade da capacidade e deixam a menor margem. São perguntas diferentes que exigem dashboards diferentes, e é por isso que copiar o painel do vizinho quase nunca funciona.

Calçado: 800-1200 SKUs que nenhuma folha de cálculo aguenta

Uma coleção de amostras em Felgueiras tem entre 800 e 1200 SKUs, cruzados em três eixos — cor, tamanho e forma (fitting). Os compradores internacionais visitam duas vezes por ano (homem em agosto, mulher em fevereiro) e decidem em dias. A pergunta operacional é brutalmente simples e brutalmente difícil de responder num Excel: quais das 900 referências desta coleção têm margem positiva depois de subtrair o custo de amostragem, e quais estão a matar-nos?

Sem BI, essa pergunta responde-se por intuição do dono. Com BI, responde-se por referência, por cliente e por forma, com os dados do ERP MULTI a alimentarem o painel.

O calçado português tem uma característica que o distingue do têxtil: a exportação é a esmagadora maioria do negócio, e os mercados-alvo — Alemanha, França, Países Baixos — são exigentes em prazo e em consistência de qualidade. Isto muda o que o BI tem de mostrar. Não basta margem por referência. É preciso cumprimento de prazo por cliente, porque um atraso de duas semanas numa encomenda para um retalhista alemão custa a encomenda seguinte inteira. É preciso saber, por forma, quanto tempo a produção real desvia do standard — porque uma forma nova mal estudada come margem em silêncio durante toda a coleção.

A gestão da coleção como problema de dados

A verdadeira dor do calçado não é produzir. É decidir o que produzir. Uma coleção de amostras é uma aposta: a fábrica investe centenas de horas de modelação e amostragem sem garantia de que o comprador compra. O BI transforma essa aposta de instinto em probabilidade informada. Cruzando as coleções passadas — que formas, que cores, que gamas de preço venderam a que clientes — o painel mostra padrões que a memória do dono já não segura: o cliente francês que compra sempre a forma clássica em couro escuro, o cliente holandês que só reage a novidade, o cliente que pede muitas amostras e converte poucas.

Distribuição e retalho: o chefe de armazém que odeia relatórios

No corredor Lousada/Paços de Ferreira, o chefe de armazém de um centro de distribuição alimentar não quer relatórios. Quer o rádio na mão e o picking a andar. Qualquer coisa que o tire do Gemba mais de duas horas é sabotada — e ele tem razão. O erro clássico das PMEs é construir dashboards para a administração e esquecer que o dado nasce no chão. Se o operador não vê benefício, o dado que ele introduz degrada-se, e o painel bonito da administração fica a mentir com confiança.

Um dashboard que só a administração usa está condenado. O BI que sobrevive é o que devolve valor a quem alimenta o dado.

No retalho, o volume de negócios do comércio a retalho cresceu 4,7% em 2024 (INE). Mas crescimento de vendas sem visibilidade de margem por loja, por categoria e por hora do dia é combustível para decisões erradas — abrir SKUs que não rodam, promover o que já vende sozinho.

A distribuição alimentar portuguesa vive de margens finas e volumes altos. Um centro de distribuição com 15 000 m² e 4 000 referências ativas gere ruturas, sobrestocagem e prazos de validade em simultâneo — e cada um desses três problemas custa dinheiro de forma diferente. A rutura perde venda. A sobrestocagem imobiliza capital e enche corredores. A validade a expirar é perda pura. Um dashboard operacional que cruze rotação, cobertura de stock e dias até validade dá ao gestor de armazém a informação para agir antes de o problema se materializar — não a autópsia no fim do mês.

O dado de armazém, quando nasce de terminais de rádio-frequência ligados ao KORA Inventory Suite, chega ao BI limpo e datado à operação real. É a diferença entre saber que uma referência está em rutura agora e descobri-lo três dias depois num inventário. Para o retalho com loja física, o dado de venda ao segundo vem do POS — e um MAXIRETAIL sincronizado alimenta o painel de margem por loja e por categoria sem exportações manuais.

Retalho: a margem por hora do dia que ninguém olha

Há um indicador que quase nenhuma cadeia regional analisa e que muda a gestão de pessoal e de promoções: a margem por hora do dia e por dia da semana. Uma loja de conveniência alimentar não vende igual às 8h e às 19h, nem à segunda e ao sábado. O staffing costuma ser plano; a venda não é. Um dashboard que revele os picos e os vales reais permite ajustar horários e concentrar promoções onde há tráfego, em vez de queimar margem em horas mortas. É o tipo de insight que o motor associativo do Qlik entrega quase por acidente — porque deixa o utilizador cruzar hora, categoria e loja sem construir uma consulta nova de cada vez.

Indústria metal/plástico: a peça única contra a série

No corredor Aveiro–Marinha Grande, a indústria de moldes e injeção plástica tem um problema de custeio que envergonha muitos ERPs generalistas. A peça única — um molde — é um projeto com centenas de horas de fresagem, erosão e bancada, e o custo real só se conhece no fim. A série — injeção de milhares de peças — vive de cadência de máquina e de refugo. São dois mundos de custeio a conviver na mesma fábrica. Sem MES a capturar o tempo real por operação e por centro de custo, o BI de custeio de molde é ficção. Com captura em tempo real via KORA Productivity, o dashboard mostra o desvio de horas ao orçamento do molde enquanto o molde está a ser feito — a tempo de renegociar ou de aprender para a próxima proposta.

2. O que é exatamente Qlik Sense e o BI para indústria em Portugal

Qlik Sense é uma plataforma de business intelligence e visualização de dados que permite construir dashboards interativos sobre múltiplas fontes — ERP, MES, folhas de vencimento, ficheiros Excel, bases de dados. A diferença técnica que interessa a quem decide não é o gráfico bonito. É o motor associativo.

O motor associativo — porque é que isto não é mais um gráfico

A maioria das ferramentas de BI baseadas em SQL obriga a definir de antemão as perguntas: constrói-se uma consulta, filtra-se por um caminho. O motor associativo do Qlik funciona ao contrário — carrega os dados em memória e deixa o utilizador navegar em qualquer direção, vendo instantaneamente o que está relacionado e, tão importante, o que não está relacionado com a seleção atual.

Exemplo concreto de calçado: seleciona um cliente alemão e o painel mostra logo as formas que ele compra, os meses em que compra, as margens dessas ordens — e, a cinzento, as referências que ele nunca comprou apesar de estarem na coleção. Esse "cinzento" é ouro comercial que um relatório de SQL clássico esconde.

Por que é que isto importa numa PME e não é só jargão de fornecedor? Porque a pergunta de negócio nunca vem sozinha. O comercial pergunta a margem por cliente, e a resposta gera três perguntas novas — por gama, por mês, por forma. Numa ferramenta baseada em consultas rígidas, cada pergunta nova é um pedido ao IT e uma espera de dias. No modelo associativo, a pessoa de negócio segue o fio sem sair do painel. É a diferença entre uma investigação de duas horas e uma de dois minutos, e é isso que decide se o dashboard é usado ou abandonado.

Termos que vais ouvir na sala de reunião

• Dashboard operacional — painel de indicadores atualizados de forma frequente (diária ou intra-diária), orientado à ação no terreno, não à análise histórica trimestral.
• KPI — indicador-chave de desempenho; num contexto industrial, coisas como OEE, refugo %, cumprimento de prazos, rotação de stock.
• ETL / data load — o processo de extrair, transformar e carregar dados das fontes para o modelo Qlik. É aqui que 70% do esforço de um projeto vive, e onde as consultoras genéricas subestimam sempre.
• Self-service BI — a capacidade de o utilizador de negócio criar as suas próprias análises sem depender do IT para cada pergunta nova.
• Camada semântica — a definição comum do que cada indicador significa, para que "margem" queira dizer o mesmo no painel do comercial e no do CFO.
• Section access — mecanismo de segurança do Qlik que limita, ao nível da linha de dados, o que cada perfil de utilizador vê.

Para o percurso completo do problema à decisão, aprofundamos noutro artigo como funciona Qlik Sense em indústria portuguesa: da folha de cálculo à decisão, e o mecanismo de atualização contínua em Business Intelligence em tempo real com o Qlik Sense.

Breve história — de QlikView a Qlik Sense

A Qlik nasceu na Suécia em 1993. O produto original, QlikView, popularizou o motor associativo nos anos 2000 e ganhou tração em Portugal sobretudo em indústria e distribuição. O Qlik Sense, lançado em 2014, reconstruiu a experiência para self-service e responsividade, com governação centralizada. Quem ainda corre QlikView em produção não está errado — mas a estrada de desenvolvimento e as capacidades de IA aumentada estão hoje no Sense.

Esta distinção tem consequência prática para quem herdou um projeto antigo. Muitas fábricas portuguesas têm aplicações QlikView de dez ou doze anos, construídas por um consultor que já não trabalha lá, que ninguém sabe manter mas que ninguém se atreve a desligar porque o CFO ainda as abre. A migração para Sense não é urgente — mas adiar indefinidamente cria uma dívida técnica que um dia rebenta, tipicamente quando o servidor antigo morre e o backup não restaura. O momento de planear a migração é antes de haver crise, não durante.

On-premise, cloud ou híbrido — a decisão de alojamento

Uma pergunta que surge cedo: onde corre o BI? O Qlik Sense funciona bem em datacenter próprio (on-premise), em cloud, ou em modelo híbrido. Para a PME industrial portuguesa que ainda não moveu o ERP para a cloud — e são a maioria — o on-premise em servidor gerido é a opção natural, porque mantém o BI ao lado da fonte de dados e evita a latência de puxar volumes grandes pela ligação de internet. Quem tem várias filiais e quer acesso uniforme costuma inclinar-se para modelos com componente cloud. Não há resposta universal; há a resposta certa para a arquitetura de dados que já existe.

3. O panorama em Portugal hoje

Três números do INE (2025) desenham o terreno com honestidade desconfortável:

• Apenas 53,7% das empresas em Portugal usavam ERP em 2025. Sem núcleo integrado, o BI trabalha sobre dados dispersos — e um dashboard sobre dados sujos é uma mentira mais rápida.
• Apenas 38,7% adquiriam serviços de cloud, o que condiciona arquiteturas modernas de BI (embora o Qlik funcione perfeitamente on-premise em datacenter próprio).
• Os tais 45% que fazem análise de dados — número que sobe, mas devagar. A gestão baseada em dados ainda não é o normal em Portugal; é uma vantagem competitiva disponível para quem a agarra primeiro.

Lido em conjunto: a barreira de entrada ao BI útil em Portugal continua a ser o ERP e a higiene de dados, não a ferramenta de visualização. Quem já tem um ERP vertical bem implementado está a meio caminho. Quem não tem, gasta o orçamento de BI a corrigir dados de origem — e depois queixa-se de que "o BI não funcionou".

O BI não falha por causa do gráfico. Falha porque ninguém quis arrumar a casa dos dados primeiro.

A diferença entre grandes e pequenas — o fosso da digitalização

As médias estatísticas escondem um fosso enorme. As grandes empresas portuguesas adotam analítica a taxas que se aproximam da média europeia; as micro e pequenas ficam muito atrás. Este desnível é o dado mais relevante para a PME industrial, porque significa duas coisas em simultâneo. Primeira: a maioria dos concorrentes diretos ainda decide no escuro, logo há vantagem em ver primeiro. Segunda: os clientes grandes — as casas-mãe do têxtil, os retalhistas do calçado, as centrais de compra da distribuição — já são digitalizados e vão exigir que os fornecedores acompanhem. A pressão vem de cima na cadeia de valor, não só da concorrência lateral.

O financiamento — PT2030, PRR e a realidade dos relatórios técnicos

Um projeto de BI e digitalização de dados é elegível para vários instrumentos — PT2030, COMPETE 2030, Norte 2030, e componentes de digitalização do PRR. Na prática, o que aprovámos ver aprovar são projetos com âmbito claro, entregáveis mensuráveis e ligação a produtividade demonstrável. O que fica atolado são as candidaturas vagas — "transformação digital" sem métrica — que morrem na fase de relatório técnico porque ninguém consegue provar o que mudou. A lição para a PME é a mesma que serve o projeto em si: âmbito estreito, indicador concreto, valor demonstrável. Um dashboard que reduz o tempo de fecho de mês de cinco dias para um é uma história de candidatura defensável. "Vamos ser data-driven" não é.

O erro-padrão português: comprar a ferramenta antes de ter a pergunta

Em 36 anos a acompanhar fábricas portuguesas, o padrão repete-se: a empresa compra licenças de BI empolgada com uma demo, constrói vinte dashboards no primeiro trimestre, e no segundo ninguém os abre. A razão é sempre a mesma — construíram-se painéis a partir do que os dados permitiam mostrar, não a partir das decisões que a gestão precisava de tomar. Dashboard sem decisão associada é decoração cara. Explorámos este arranque em como construir uma organização data-driven: o primeiro passo.

O trio de decisão e o herói de IT sem canudo

Nas empresas familiares portuguesas, o BI decide-se num trio — CEO, CFO e a pessoa de IT. E a pessoa de IT é, muitas vezes, um autodidata com quinze anos de conhecimento do negócio e sem grau formal. É ele que sabe onde estão os dados, que macro faz o quê, porque é que aquele campo do ERP nunca se pode confiar. Ignorá-lo num projeto de BI é garantir o fracasso; ouvi-lo é ganhar o mapa do território sem escavar. O que ele precisa é de uma ferramenta que o liberte de ser o gargalo humano de todos os relatórios — não de uma que o substitua e o humilhe. O self-service BI, bem introduzido, transforma-o de fábrica de Excel em curador do modelo de dados. É uma promoção, e vale a pena vendê-la assim.

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

Há cinco abordagens práticas para pôr BI a funcionar numa PME industrial portuguesa. Não são igualmente boas — cada uma tem um custo, um risco e um tipo de empresa a que serve.

O trade-off que ninguém te conta

Saltar direto para o BI corporativo governado numa PME sem maturidade de dados é o erro mais caro. O modelo departamental self-service, começado numa área com dor aguda (tipicamente produção ou tesouraria), gera confiança e financia o resto. A regra prática: prove valor numa área em 8-10 semanas antes de prometer o dashboard universal. Sobre transformar isto em resultado financeiro, ver transforme dados em lucro com o Qlik Sense.

Excel não é o inimigo — é o sintoma

Convém ser justo com o Excel. Não é uma ferramenta má; é uma ferramenta mal usada quando vira base de dados de gestão de uma empresa de oitenta pessoas. O Excel é ótimo para uma análise ad-hoc, para um cálculo pontual, para o rascunho de uma ideia. O problema começa quando o ficheiro do José de sexta-feira vira a fonte oficial da verdade da empresa. O sinal de que se passou o limite é simples: quando dois departamentos abrem o "mesmo" relatório e discutem qual está certo, o Excel deixou de ser ferramenta e passou a ser risco operacional. A migração para BI não é abolir o Excel — é tirar-lhe o peso que ele não devia carregar.

O Excel não mata a empresa. O que mata é o Excel promovido a fonte da verdade sem ninguém ter decidido promovê-lo.

O silo de dashboards — o fracasso silencioso do self-service

O modelo departamental tem um risco que só aparece ao fim de dois anos: cada área constrói os seus painéis, com as suas definições, e quando a administração cruza produção com vendas descobre que "unidade produzida" quer dizer coisas diferentes em cada dashboard. É o silo de dashboards. A prevenção não é técnica — é de governação. Basta uma pessoa responsável por manter as definições dos indicadores centrais coerentes, mesmo enquanto cada departamento constrói o resto à sua maneira. Governação leve, não burocracia. O erro é o extremo oposto: bloquear todo o self-service atrás de um comité que aprova cada gráfico, matando a agilidade que era o ponto do BI departamental.

5. Como avaliar se a sua empresa precisa

Nem toda a empresa precisa de BI já. Precisa quem sofre de pelo menos três destes sintomas:

• O fecho de mês depende de uma pessoa que "sabe onde estão os números" — e essa pessoa vai de férias.
• A reunião de gestão discute que número é o correto, em vez de discutir a decisão.
• A margem real de uma ordem/loja/produto só se conhece semanas depois de fechada.
• Há dados no ERP, nos terminais de chão-de-fábrica e em Excel, e ninguém os cruza sem trabalho manual.
• Decisões de compra, produção ou preço tomam-se por intuição porque o dado chega tarde.

Passo a passo do diagnóstico

1. Liste as cinco decisões recorrentes mais caras da empresa. Não indicadores — decisões. "Aceitar ou recusar esta ordem", "repor ou não este SKU", "manter ou fechar esta rota de vendas". O BI serve decisões, não gráficos.
2. Para cada decisão, aponte que dado a fundamenta hoje e quanto tempo demora a obtê-lo. Se a resposta for "o José exporta do ERP e cruza no Excel em duas horas", encontrou o seu primeiro caso de uso.
3. Avalie a fonte de origem. Esse dado nasce fiável no ERP, ou é preenchido à mão em folhas soltas? Se a origem é suja, o BI não a limpa — só a mostra mais depressa. Corrija a origem primeiro.
4. Identifique o dono da decisão e confirme que ele quer o painel. Um dashboard imposto a um chefe de armazém que não o pediu morre em três semanas. Um que ele ajudou a desenhar, esse vive.
5. Estime o valor de decidir 24-48 horas mais cedo e com o número certo. Se poupa uma ordem mal orçamentada por trimestre no têxtil, o projeto paga-se sozinho. Calcule o TCO contra esse valor, não contra o preço da licença.

Se não consegue nomear a decisão que o dashboard vai melhorar, não está pronto para o construir — está pronto para o desperdiçar.

O teste da higiene de dados antes de qualquer licença

Antes de comprar seja o que for, faça um teste barato e revelador: peça a três pessoas diferentes o volume de vendas do mês passado. Se os três números não baterem certo, o problema não é BI — é a fonte. Repita com margem por cliente, com stock de uma referência qualquer, com horas de produção de uma ordem. Cada discrepância é um sinal de onde o dado nasce sujo. Um projeto de BI honesto começa por este inventário de sujidade, e às vezes a conclusão é adiar o BI e arrumar primeiro o ERP. É uma conclusão desagradável de vender, mas é a que poupa o dinheiro.

Quem não precisa de BI ainda

Ao contrário do discurso de fornecedor, há empresas que não devem avançar. A micro-empresa de doze pessoas que ainda não tem ERP integrado deve pôr o ERP a funcionar primeiro; construir BI sobre exportações manuais é construir sobre areia. A empresa cujo negócio inteiro cabe na cabeça do dono e não vai crescer não precisa de painel para descobrir o que já sabe. E a empresa em crise aguda de tesouraria tem prioridades mais urgentes do que dashboards — embora, ironicamente, um bom painel de tesouraria seja exatamente o que evitaria a próxima crise. O critério é honesto: se não há decisão recorrente cara e mal informada, não há caso de BI.

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

A dimensão da empresa e a maturidade de dados determinam a escolha. Esta matriz é a que usamos no terreno.

Porque é que o BI vertical bate o BI genérico

Uma ferramenta de BI genérica dá-lhe uma tela em branco. É poderoso e é uma armadilha: a empresa gasta meses a reinventar o que significa "OEE de linha de confeção" ou "margem de coleção de calçado por forma". O valor de um BI ancorado num ERP vertical industrial é que os conceitos já existem modelados — a ordem de produção, o consumo standard, a estrutura cor-tamanho-forma. O Qlik Sense ligado ao ERP MULTI ou ao QAD Adaptive ERP herda essa modelação em vez de a reconstruir do zero.

No chão-de-fábrica, os dados de eficiência que alimentam o dashboard vêm de captura em tempo real — é o papel do KORA Productivity. Sem essa camada, o OEE do dashboard é uma estimativa preenchida à mão no fim do turno, e vale o que vale uma estimativa. Para quem quer usar os dados no planeamento, ver planeamento estratégico com BI: quando os dados substituem a intuição.

A cadeia de dados que faz o dashboard honesto

Vale a pena traçar a cadeia completa, porque é aí que se percebe onde um BI vertical ganha tempo. O OEE nasce da captura de produção no terminal do MES. A margem nasce da ordem de produção no ERP cruzada com o custo real. O stock nasce do WMS. As vendas nascem do POS ou da força de vendas móvel. Quando todas estas fontes já estão ligadas por um ERP vertical que fala a mesma língua, o BI apenas as apresenta. Quando não estão — quando o OEE é uma folha, o custo outra, o stock uma terceira — o projeto de BI vira, na prática, um projeto de integração disfarçado, com o triplo do custo e do prazo. É esta a razão real pela qual o mesmo dashboard custa muito mais numa empresa e muito menos noutra.

Quando o dado é de pessoas — o painel de RH

Uma dimensão que as PMEs industriais descobrem tarde: o dado de pessoas vale ouro numa indústria com mão de obra envelhecida e difícil de repor. Saber a rotatividade por secção, o absentismo por turno, a curva etária de quem sabe operar uma máquina crítica — isto muda decisões de recrutamento e de formação. Quando a assiduidade e o payroll nascem do pplPortal, o BI de RH mostra padrões que a folha de vencimento esconde. E é aqui que a conformidade aperta mais, como veremos.

7. Quadro regulatório e conformidade aplicável

Um projeto de BI toca dados sensíveis — vendas, margens, folhas de vencimento, dados de colaboradores. A conformidade não é opcional.

RGPD e dados de pessoas nos dashboards

Assim que um dashboard de RH mostra absentismo, rotatividade ou desempenho por colaborador, entra no âmbito do RGPD e da Lei 58/2019. As regras operacionais: minimização (só os dados necessários à decisão), controlo de acessos por perfil (o encarregado de linha não vê os salários), e registo de quem acede a quê. O Qlik Sense permite section access — segurança ao nível da linha de dados — que faz exatamente isto quando bem configurado.

O erro mais comum é o dashboard de RH que mostra tudo a toda a gente com acesso. Um diretor de produção que consegue ver salários individuais da sua equipa através de um painel mal configurado é uma violação à espera de acontecer — e a Lei 58/2019 não distingue entre malícia e descuido. A regra é desenhar o acesso antes de desenhar o gráfico: quem pode ver que linha, agregado a que nível, com que granularidade. O absentismo por secção é legítimo para o gestor; o absentismo nominal de um colaborador específico exige base legal e restrição de acesso.

Faturação, SAF-T e a origem dos números

Os dados de faturação que alimentam os dashboards comerciais nascem de software certificado pela AT, no âmbito do DL 28/2019 (ATCUD, programas certificados) e da comunicação SAF-T mensal (Portaria 195/2020). O BI consome esses dados — não os substitui nem os altera. A coerência entre o que o dashboard mostra e o que foi comunicado à AT é uma verificação obrigatória no arranque.

Há uma armadilha subtil aqui. O dashboard comercial e a declaração fiscal devem contar a mesma história de faturação, mas medem períodos e critérios que podem divergir — venda por data de encomenda no painel, por data de documento na declaração. Se ninguém reconcilia os dois no arranque, mais tarde alguém repara na diferença e perde a confiança no BI inteiro. A reconciliação inicial contra a fonte oficial não é burocracia — é o que garante que o painel não é contestado na primeira reunião difícil.

Cibersegurança: NIS2 e ISO 27001

Um servidor de BI concentra os dados mais sensíveis da empresa num só sítio — o que o torna um alvo. 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 e distribuição de dimensão relevante. Um projeto de BI sério trata do alojamento em datacenter com controlos de acesso, cifra e cópias de segurança, e da cibersegurança perimetral. Aprofundamos os riscos em os riscos silenciosos da cibersegurança na empresa e a proteção em segurança INFOS: proteção perimetral e SOC.

O ponto que escapa a muita PME: o BI amplia a superfície de risco precisamente porque agrega. Um atacante que compromete o ERP vê um módulo; um que compromete o servidor de BI vê a empresa inteira num painel — margens, clientes, salários, tudo cruzado e apresentado de forma legível. Por isso o servidor de BI merece o mesmo tratamento de segurança que o núcleo do ERP, não menos. As certificações ISO 27001, 27017 e 27018 dão o enquadramento de controlos; o essencial operacional é acesso mínimo por perfil, cifra em repouso e em trânsito, e cópias de segurança testadas — não presumidas.

Comprometer o ERP mostra um módulo. Comprometer o servidor de BI mostra a empresa inteira, já cruzada e legível. Trate-o como tal.

IA aumentada e o AI Act

Se avançar para BI com IA — previsão de rotatividade, deteção automática de anomalias — o Regulamento UE 2024/1689 (AI Act) classifica sistemas de IA por risco. A analítica preditiva de desempenho de pessoas exige atenção acrescida; a deteção de anomalias em produção, muito menos. Saber em que categoria cai cada caso de uso é parte do desenho, não uma reflexão posterior. Ver IA aplicada INFOS: transformar dados em decisões automatizadas.

A distinção prática é esta: usar IA para detetar que uma máquina desvia da cadência normal é baixo risco e alto valor — ninguém contesta um alerta de manutenção. Usar IA para prever que colaboradores vão sair, ou para pontuar desempenho de pessoas, cai numa zona sensível que exige transparência, base legal e cautela. O pplPortal tem componentes preditivos de rotatividade e absentismo precisamente porque o valor é real — mas o desenho tem de assumir desde o início que estes casos de uso vivem sob escrutínio regulatório, e não tratá-los como mais um gráfico.

8. Como a INFOS aborda isto

Trabalhamos exclusivamente com indústria e distribuição portuguesas há mais de três décadas. Isso significa que não chegamos a uma fábrica de calçado a perguntar o que é uma "forma" ou a uma confeção a perguntar como se calcula o consumo de tecido. Os conceitos verticais já estão no ERP MULTI, e o Qlik Sense herda-os — o que corta meses de modelação de raiz.

A nossa preferência é começar pequeno e provar valor: um caso de uso com dor aguda, dados que já nascem fiáveis no ERP e no KORA Productivity, e um dono de decisão que quer o painel. Depois expande-se. O onboarding dos utilizadores de negócio é tratado com o mesmo cuidado que a parte técnica — porque um dashboard que ninguém sabe usar não existe.

Sobre a INFOS não inventamos casos nem percentagens. O que afirmamos é genérico e verdadeiro da categoria: um BI vertical bem ancorado num ERP industrial encurta o tempo até ao primeiro dashboard útil e reduz o esforço de manutenção, porque não se reconstrói a semântica do negócio a cada projeto.

A prova de conceito antes do compromisso

A forma mais honesta de arrancar não é uma proposta de vinte páginas — é uma prova de conceito sobre dados reais da empresa. Pega-se num caso de uso, ligam-se as fontes verdadeiras, e constrói-se o primeiro painel com dados que o CFO reconhece. Se os números batem com o que ele sabe, ganhou-se a confiança. Se não batem, descobriu-se onde o dado nasce sujo — e isso, por si só, já vale o exercício. Uma PoC sobre dados reais mata as promessas vagas e substitui-as por evidência que a administração vê com os próprios olhos.

Manutenção — o custo que a demo esconde

A demo mostra sempre o dia da inauguração. O que separa um projeto vivo de um cemitério de dashboards é a manutenção: quando o ERP muda um campo, quando entra uma linha nova, quando o negócio passa a medir uma coisa que antes não media, alguém tem de atualizar o modelo. Num BI genérico construído por um consultor de passagem, essa manutenção fica órfã. Num BI ancorado num ERP vertical mantido pelo mesmo fornecedor, a mudança no ERP e a mudança no BI acontecem em conjunto. É uma vantagem que não aparece na demo mas que decide se o projeto está vivo daqui a três anos.

9. Roadmap 30/60/90 dias

Um arranque de BI departamental numa PME industrial portuguesa cabe em 90 dias — se houver disciplina de âmbito. O erro é querer tudo no primeiro trimestre.

Dias 1-30: âmbito e dados

• Escolher um caso de uso com dono e dor aguda — não três.
• Mapear as fontes de dados desse caso e verificar a fiabilidade na origem.
• Definir os 5-8 KPIs que servna decisão-alvo — e recusar os "seria bom ter".
• Confirmar alojamento, acessos e conformidade RGPD para os dados envolvidos.

Dias 31-60: construir e validar

• Montar o data load do ERP e das fontes para o modelo Qlik.
• Construir o primeiro dashboard operacional com o dono da decisão a validar semana a semana.
• Testar a segurança ao nível da linha (section access) para os perfis certos.
• Verificar a coerência dos números do dashboard contra a fonte oficial (ERP, SAF-T).

Dias 61-90: adotar e medir

• Formar os utilizadores de negócio na leitura e no self-service básico.
• Medir a adoção real — quem abre o painel e com que frequência. Se ninguém abre, o problema é o desenho, não a formação.
• Documentar o valor gerado na decisão-alvo (tempo poupado, erro evitado).
• Só então planear a segunda área — com o crédito de confiança já ganho.

Noventa dias chegam para um dashboard que muda uma decisão. Não chegam para o dashboard universal — e ainda bem, porque esse ninguém usa.

O que medir para saber se funcionou

A adoção é o único juiz honesto. Contam-se três coisas ao fim dos 90 dias: quantas pessoas abrem o painel numa semana normal, quantas vezes cada uma, e se a decisão-alvo

Perguntas frequentes

O Qlik Sense é adequado para PMEs industriais portuguesas?

Sim. O Qlik Sense foi desenhado para empresas que têm dados dispersos em ERPs e ficheiros Excel, mas carecem de visibilidade operacional. Adapta-se bem a fábricas com 40 a 500 colaboradores que precisam de dashboards em tempo real sem investimento massivo em infraestrutura IT.

Quanto tempo leva a implementar um dashboard operacional?

Entre 6 a 12 semanas, dependendo da complexidade. Uma PME têxtil com ERP consolidado consegue um painel de margens por ordem em 8 semanas. O tempo crítico é a limpeza de dados no ERP e o alinhamento sobre que métricas importam realmente.

É necessário ter um departamento IT interno?

Não obrigatoriamente. Um implementador externo (consultor de BI) constrói o painel e treina dois utilizadores internos para manutenção básica. A maioria das PMEs industriais consegue gerir dashboards Qlik com um técnico de IT a meia jornada após implementação.

Como o BI ajuda na rastreabilidade de lote exigida pela UE?

O Qlik cruza dados de lote do ERP — tinturaria, composição, consumo de água/energia — e apresenta-os num painel que responde em minutos. Sem BI, essa informação fica dispersa em documentos. Com BI, o comprador alemão recebe o passaporte digital do produto em tempo real.

Qual é o custo típico de um projeto Qlik Sense numa fábrica de 100 pessoas?

Entre 15 mil e 35 mil euros (implementação + licenças primeiro ano). Varia com o número de dashboards, complexidade do ERP e necessidade de limpeza de dados. O ROI aparece quando elimina 3-4 horas semanais de trabalho manual em Excel.

O Qlik consegue mostrar a margem real de uma ordem enquanto está em produção?

Sim. Se o ERP alimenta o painel com consumos reais de fio, tempos de máquina e refugo em tempo real, o Qlik cruza esses dados com o orçamento original e mostra desvios de margem diariamente. Isto é crítico no têxtil, onde a margem só era conhecida no fecho.

Que diferença há entre um dashboard para têxtil e outro para calçado?

O painel têxtil foca margem por ordem e rastreabilidade de lote. O painel calçado foca margem por SKU, cumprimento de prazo por cliente e desvio de tempo por forma. São perguntas de negócio diferentes que exigem estruturas de dados distintas no Qlik.

Fontes

• Instituto Nacional de Estatística (INE) — Inquérito à Utilização de Tecnologias da Informação e da Comunicação nas Empresas (IUTIC), dados 2023-2025
• Comissão Europeia — Estratégia da UE para os Têxteis Sustentáveis e Circulares e Regulamento (UE) 2024/1781 (Passaporte Digital de Produto)
• Associação Têxtil e Vestuário de Portugal (ATP) — Relatórios Setoriais de Competitividade
• Associação Portuguesa de Empresas de Calçado (APEC) — Estatísticas de Exportação e Competitividade