Qlik Sense em indústria portuguesa: da folha de cálculo à decisão

Numa fábrica de malhas em Vizela, o mapa de produção do mês vive num ficheiro Excel de 14 separadores que só o Sr. Armando sabe abrir sem partir as fórmulas. Quando o Armando vai de férias, a empresa fica cega. Este cenário — o analista humano insubstituível, encarnado numa folha de cálculo que ninguém mais compreende — repete-se em metade da indústria portuguesa que conheço.

A tese deste artigo é incómoda: o problema do BI industrial em Portugal não é técnico, é de posse. Empresas compram Qlik Sense a pensar em dashboards bonitos e descobrem que o obstáculo real é largar a folha de cálculo — porque a folha dá poder a quem a controla. Vou mostrar-lhe como o Qlik Sense muda esse jogo, o que é defensável em números, e onde os projectos descarrilam.

1. O problema operacional real: a folha de cálculo como sistema operativo oculto

A maioria das PMEs industriais portuguesas não sofre de falta de dados. Sofre de dados presos. O ERP tem os números, o chão-de-fábrica tem os apontamentos, o comercial tem o seu próprio Excel de margens, e o CFO tem um terceiro ficheiro que concilia os três à mão, ao domingo à noite.

Chamo a isto o sistema operativo oculto porque, de facto, é o que gere a empresa. O ERP factura, cumpre a lei, guarda os movimentos — mas a decisão sai da folha de cálculo. Quando um diretor industrial decide subcontratar mais uma casa em Barcelos, ou quando o CFO decide cortar uma referência de coleção, o número que sustenta essa decisão saiu quase sempre de um separador manual. E esse separador não tem controlo de versões, não tem trilho de auditoria, não sobrevive à saída de quem o mantém.

O ritual do fim de mês

Fim de mês numa confeção perto de Famalicão soa assim: o ERP a exportar CSVs, a impressora a cuspir mapas, e alguém a copiar valores de um separador para outro porque "a fórmula da coluna J deixou de bater com o novo IVA". O fecho que devia demorar duas horas demora dois dias. E quando a casa-mãe — Inditex, Decathlon, Tom Tailor — pede um relatório de cumprimento de prazos por encomenda, ninguém sabe responder sem reabrir o mesmo ficheiro monstruoso.

O sintoma clássico: três pessoas na reunião de gestão trazem três valores diferentes de "vendas do mês". Não porque mintam — porque cada folha foi construída com regras diferentes de corte, de devoluções, de câmbio. A discussão de negócio transforma-se numa auditoria de fórmulas.

Este ritual tem um custo que raramente se contabiliza porque está diluído em horas de gente competente. Um controller que dedica dois dias por mês a consolidar folhas gasta cerca de 24 dias por ano — mais de um mês de trabalho qualificado — a fazer o que uma carga automatizada faz de madrugada, sem erro e sem café. E esse controller é, quase sempre, a pessoa que a empresa mais precisa de ter a pensar, não a copiar e colar.

Quando a reunião de gestão discute qual dos três Excel está certo, já perdeu a reunião de gestão.

Porque é que isto persiste (e não é preguiça)

A folha de cálculo sobrevive porque é flexível, gratuita à primeira vista, e — o ponto crítico — porque dá autonomia a quem a domina. O Sr. Armando não esconde o ficheiro por maldade. Esconde-o porque esse ficheiro é a prova de que ele é indispensável. Retirar a folha sem devolver protagonismo a quem a mantinha é o erro número um dos projectos de BI que falham em Portugal.

Há ainda uma segunda razão, mais estrutural. Nas empresas familiares portuguesas, a decisão de investir corre pelo trio CEO + CFO + IT, e o responsável de IT é muitas vezes um autodidacta com 15 anos de conhecimento do negócio e nenhum diploma formal. Esse profissional construiu a folha de cálculo ao longo de uma década, incorporou nela regras de negócio que não estão escritas em lado nenhum, e desconfia — com razão — de qualquer consultor que chegue a prometer substituí-la num powerpoint. Ganhar este aliado é metade do projecto. Ignorá-lo é garantir a sabotagem passiva que mata rollouts.

Os custos silenciosos desta arquitetura acumulam-se:

• Decisões tomadas sobre dados de ontem — ou da semana passada — porque a consolidação é manual e lenta.
• Erros de fórmula que ninguém deteta até o cliente reclamar de uma fatura errada.
• Conhecimento de negócio fechado na cabeça de uma pessoa e num ficheiro que não sobrevive à saída dela.
• Impossibilidade de cruzar produção com margem, ou stock com sazonalidade, porque os dados vivem em ilhas.
• Zero rastreabilidade de quem alterou o quê e quando — um problema quando a auditoria de uma casa-mãe pergunta como se chegou a determinado número.

Segundo o INE, em 2025 apenas 53,7% das empresas em Portugal usavam ERP. Ou seja: quase metade nem sequer tem um núcleo integrado sobre o qual construir análise. Nessas casas, o BI trabalharia sobre dados dispersos — e é por isso que a ordem certa importa, um tema que desenvolvo em Como construir uma organização data-driven: o primeiro passo.

O risco de continuidade: quando a folha é uma pessoa

Vale distinguir dois tipos de risco que a folha de cálculo cria. O primeiro é operacional — o número está errado e ninguém percebe. O segundo é de continuidade — o conhecimento vive numa pessoa. O segundo é o mais grave e o menos discutido nas reuniões de gestão, porque é desconfortável admitir que a empresa depende de um indivíduo.

Numa fábrica de acabamentos têxteis no Vale do Ave, presenciei uma situação em que o único responsável pela folha de custeio de banhos de tinturaria saiu para a concorrência. Durante quatro meses, a empresa não conseguiu calcular a margem real de nenhuma encomenda de tingimento com fiabilidade, porque as regras de rateio de químicos e de energia estavam num ficheiro que ninguém sabia interpretar. O custo dessa cegueira, em decisões de preço mal informadas, ultrapassou largamente o que teria custado documentar o modelo de dados atempadamente.

2. O que é exatamente Qlik Sense na indústria portuguesa

Qlik Sense é uma plataforma de business intelligence e visualização de dados. Reduzido ao essencial: pega em dados de várias fontes — ERP, folha de vencimentos, terminais de chão-de-fábrica, e-commerce, folhas de cálculo — carrega-os para um motor próprio, e permite explorá-los visualmente através de dashboards interactivos onde cada clique recalcula todo o contexto.

O motor associativo: a diferença que os concorrentes copiaram mas não igualaram

O que distingue tecnicamente o Qlik é o motor associativo em memória. Num relatório tradicional, quando filtra por "cliente = Decathlon", o sistema mostra-lhe os dados desse cliente. No modelo associativo, o Qlik mostra-lhe também, activamente, o que não está associado a essa seleção — que artigos nunca foram encomendados pela Decathlon, que meses tiveram zero atividade. Essa capacidade de ver o vazio, o negativo, é onde nascem as perguntas de negócio que ninguém pensou em fazer.

Este comportamento não é cosmético. Numa coleção de calçado de Felgueiras com 800 a 1200 SKUs em três eixos — cor, tamanho, forma — a diferença entre "mostra-me o que vendeu" e "mostra-me o que ficou parado e porquê" é a diferença entre gerir a coleção e sofrê-la.

A maioria das ferramentas de BI construídas sobre modelos de consulta tradicionais — baseados em SQL por trás de cada filtro — força o analista a saber a pergunta antes de a fazer. É preciso construir o relatório para descobrir o padrão. O motor associativo inverte isto: navega-se pelos dados livremente, e o padrão emerge da própria exploração. Para quem trabalha coleções sazonais com centenas de referências, esta liberdade de exploração não é conveniência — é a única forma prática de detetar a referência que se comporta de maneira anómala num universo demasiado grande para inspeção manual.

Breve história — porque é que a arquitetura importa

A Qlik nasceu na Suécia nos anos 90. O QlikView, a primeira geração, era poderoso mas rígido — cada aplicação era um monólito construído por especialistas. O Qlik Sense, lançado a partir de 2014, inverteu a lógica: dashboards que o próprio utilizador de negócio compõe, self-service, com governação central. Essa mudança é a que importa para uma PME portuguesa, onde raramente há uma equipa dedicada de analistas e o diretor industrial tem de conseguir mexer sozinho.

A distinção entre self-service com governação central e self-service sem governação é fundamental e frequentemente mal compreendida. Sem governação, cada utilizador constrói a sua própria versão da verdade — e volta-se ao problema das três folhas de cálculo, agora com gráficos mais bonitos. Com governação central, existe uma camada de dados única e validada sobre a qual cada um explora livremente, mas a definição de "vendas líquidas" ou "margem de contribuição" é a mesma para todos. É esta arquitetura que permite descentralizar a análise sem fragmentar a verdade.

Termos que vai encontrar e o que significam

• Aplicação (app) — o conjunto de dashboards sobre um domínio, por exemplo "Produção" ou "Comercial".
• Modelo de dados associativo — a estrutura que liga tabelas de origens diferentes por chaves comuns.
• Load script — o código que extrai e transforma os dados antes de os apresentar; é aqui que se resolvem as regras de negócio (devoluções, câmbios, cortes).
• Set analysis — a sintaxe para calcular métricas condicionais (vendas do mesmo período no ano anterior, por exemplo).
• QVD — o ficheiro nativo do Qlik para armazenar dados intermédios já transformados, que acelera cargas subsequentes.
• Section access — o mecanismo de segurança que restringe que dados cada perfil de utilizador consegue ver.

Para uma explicação prática do que muda no dia-a-dia, vale a leitura de Business Intelligence em tempo real com o Qlik Sense.

Onde acaba o Qlik e começa o ERP

Uma confusão comum, sobretudo no trio decisor de empresas familiares, é achar que o BI substitui funções do ERP. Não substitui. O Qlik não factura, não emite guias, não comunica ao SAF-T, não faz a folha de vencimentos. Consome os dados que estes sistemas produzem. A fronteira é clara: sistemas transaccionais registam o que aconteceu e cumprem a lei; o BI interpreta o que aconteceu para informar o que fazer a seguir. Comprar Qlik esperando que resolva um problema de faturação certificada é comprar a ferramenta errada — para isso serve o software certificado pela AT, não a camada analítica.

3. O panorama em Portugal hoje

A gestão baseada em dados ainda não é universal em Portugal — está longe disso. Os números do INE desenham um retrato sóbrio.

O que estes números dizem realmente

Que 45% das empresas façam análise de dados soa razoável até se cruzar com os 53,7% que têm ERP. A conclusão desconfortável: há empresas a "fazer análise de dados" sem um núcleo integrado por baixo — ou seja, análise sobre folhas de cálculo. É o BI a fingir. O crescimento de 6,4 pontos em dois anos mostra apetite, mas o alicerce ainda falta em quase metade do tecido empresarial.

Há aqui uma nuance de dimensão que os números agregados escondem. A adoção de ferramentas analíticas e de ERP concentra-se fortemente nas empresas maiores. As micro e pequenas empresas — que constituem a esmagadora maioria do tecido industrial português, sobretudo na subcontratação têxtil e de calçado — estão significativamente abaixo destas médias. Quando se olha para uma confeção de 25 pessoas em Guimarães que trabalha em exclusivo para uma casa-mãe, a probabilidade de ter análise de dados estruturada cai a pique. É precisamente aí que o fosso digital se aprofunda e onde o reshoring europeu vai exigir capacidades que hoje não existem.

Análise de dados sem ERP integrado por baixo é uma folha de cálculo com aspirações. O motor de BI só brilha se o combustível estiver limpo.

O peso do setor industrial

O setor metalúrgico e metalomecânico português tem mais de 23 mil empresas e cerca de 250 mil pessoas empregadas, segundo a AIMMAP. É um universo enorme de moldes, injeção plástica e peça única no corredor Aveiro–Marinha Grande, onde cada série tem custos e margens que variam radicalmente entre encomendas. Sem análise, gere-se pela sensação. E a sensação, num molde de peça única, engana caro.

No têxtil e vestuário, a fileira portuguesa é uma das mais completas da Europa — da fiação ao produto acabado — e assenta em milhares de empresas concentradas no Norte, muitas delas de estrutura familiar e mão de obra envelhecida. A pressão simultânea do fast fashion, que exige tempos de resposta cada vez mais curtos, e da Estratégia da UE para Têxteis Sustentáveis e Circulares, que exige rastreabilidade de lote e passaporte digital de produto, transforma a análise de dados de luxo em pré-requisito de sobrevivência. Uma marca que pede prova de origem e de composição por lote não aceita "está algalgures no Excel" como resposta.

O comércio, por seu lado, movimentou 201,8 mil M€ de volume de negócios em 2024, com o retalho a crescer 4,7% (INE). Volume não é margem — e é exatamente essa distância entre faturar e ganhar que um bom dashboard de rentabilidade por artigo torna visível.

A financiamento e o gargalo dos relatórios técnicos

Projectos de digitalização e BI encaixam em instrumentos como o PT2030, o PRR, o COMPETE 2030 e o Norte 2030. A candidatura aprova-se com relativa frequência; onde os projectos encalham é no relatório técnico de execução — a demonstração de que o investimento produziu o resultado prometido. Um projecto de BI mal escopado é candidato natural a ficar preso nessa fase, porque "melhorámos a tomada de decisão" não é uma métrica auditável e "reduzimos o tempo de fecho de 2 dias para 3 horas" é.

A lição que retiramos de acompanhar candidaturas é operacional: desenhe o projecto a partir da métrica de execução, não a partir da tecnologia. Antes de escrever a candidatura, cronometre o tempo de fecho atual, conte os erros de faturação do último ano, meça o OEE de uma linha. Estes números-base são o que torna o relatório técnico defensável dezoito meses depois, quando o técnico do organismo intermédio pedir a prova do resultado. Sem baseline medido no dia zero, não há como demonstrar o ganho — e o financiamento fica em risco de devolução.

O selo PME Líder e a maturidade digital

O IAPMEI atribui os selos PME Líder e PME Excelência a empresas com desempenho e perfil de risco robustos. Cada vez mais, a maturidade digital entra na avaliação de risco que sustenta estas distinções, porque uma empresa que gere às cegas é, por definição, mais arriscada. Uma camada analítica governada não é só eficiência operacional — é sinal de qualidade de gestão que instituições financeiras e clientes internacionais leem cada vez com mais atenção nos processos de due diligence.

4. Os modelos de implementação: quatro abordagens e os seus trade-offs

Não há uma forma única de implementar Qlik Sense. Há quatro padrões que vejo repetidamente, cada um com um perfil de risco e de custo distinto.

O erro de saltar etapas

A tentação do CEO entusiasmado é começar pela plataforma governada. É o equivalente a comprar um torno CNC de cinco eixos para quem ainda não sabe afiar uma ferramenta manual. A sequência que funciona é ganhar credibilidade com um dashboard táctico que resolva uma dor real e visível — depois, com a confiança conquistada, escalar. A adoção mede-se em pessoas que largam o Excel, não em apps publicadas.

O padrão de fracasso mais comum que documentámos: empresa entusiasmada compra licenciamento para a plataforma completa, contrata a implementação de dez dashboards em simultâneo, e seis meses depois tem dez painéis que ninguém abre porque nenhum resolveu a dor que doía mais. A energia dispersou-se, a confiança evaporou-se, e o Excel continua a governar a empresa. O antídoto é a disciplina do foco: um dashboard, uma dor, um resultado medido, e só depois o próximo.

O caso do tempo real

O modelo com captura de chão-de-fábrica merece nota. Ligar o Qlik a uma solução de KORA Productivity — que captura produção em terminais industriais — transforma o TPM de um conceito de manual num painel onde o diretor de produção vê o OEE por máquina à hora. A protocolos como MQTT para telemetria de equipamento, o dado chega ao dashboard antes de o operador acabar o turno. Aqui, a integração faz-se muitas vezes com uma camada de iPaaS a orquestrar as fontes.

A diferença entre OEE ao mês e OEE à hora não é de grau, é de natureza. O OEE mensal serve para relatório e para autoflagelação a posteriori: descobre-se, no dia 5 do mês seguinte, que a linha de injeção esteve com disponibilidade abaixo do aceitável. Não há já nada a fazer. O OEE à hora, visível no painel enquanto o turno decorre, permite que o chefe de linha reaja antes de o problema se cristalizar em perda irrecuperável. É a diferença entre a autópsia e o diagnóstico atempado.

OEE calculado ao mês é história. OEE calculado à hora é gestão.

A escolha entre carga agendada e tempo quase-real

Uma decisão técnica com consequências operacionais reais: nem toda a análise precisa de tempo real. Um dashboard financeiro de rentabilidade por cliente funciona perfeitamente com carga nocturna — os dados de ontem são suficientes para decisões de margem e de crédito. Um dashboard de OEE de uma linha crítica precisa de refrescamento em minutos. Confundir os dois casos custa dinheiro em ambos os sentidos: infraestrutura de tempo real onde não faz falta é desperdício; carga nocturna onde se precisa de reação imediata é inutilidade. A regra prática: alinhe a frequência de refrescamento com a frequência da decisão que o dashboard suporta.

5. Como avaliar se a sua empresa precisa

Nem toda a empresa precisa de Qlik Sense amanhã. Há um teste honesto para saber se está madura — e outro para saber se está a fugir do problema errado.

Os sinais de que precisa (e já)

• A reunião de gestão gasta mais tempo a validar números do que a decidir sobre eles.
• O fecho de mês depende de uma pessoa e de um ficheiro que ninguém mais compreende.
• Não consegue responder em cinco minutos a "qual foi a margem real deste cliente no último trimestre?".
• A casa-mãe pede relatórios de cumprimento e a resposta demora dias.
• Tem ERP, mas exporta tudo para Excel para "poder trabalhar os dados".
• Descobre problemas de rentabilidade tarde demais para os corrigir — a encomenda já foi entregue com margem negativa.

Os sinais de que ainda não é a altura

Se não tem ERP, ou se o ERP está desactualizado e a origem dos dados é caótica, o BI vai amplificar o caos com gráficos coloridos. Primeiro arruma-se a casa. Um dashboard bonito sobre dados errados é mais perigoso do que Excel nenhum, porque parece confiável. A ordem é: ERP MULTI consolidado, dados limpos, e só depois a camada analítica.

Um segundo sinal de "ainda não": se a empresa não tem ninguém disposto a apropriar-se da ferramenta. O BI não é um sistema que corre sozinho num servidor — precisa de um dono humano que faça perguntas, que refine dashboards, que traga as descobertas à reunião de gestão. Se não há esse perfil, e não há intenção de o formar, comprar Qlik é comprar prateleira. A tecnologia sem apropriação humana é a forma mais cara de não mudar nada.

Passo a passo: diagnóstico de prontidão em cinco etapas

1. Inventarie as fontes de verdade. Liste todos os ficheiros e sistemas onde vivem números que a gestão usa para decidir. Se são mais de cinco e três são folhas de cálculo, tem um problema de dispersão.
2. Identifique o dono humano de cada folha crítica. Anote quem sabe abrir cada ficheiro sem o partir. Cada nome nesta lista é um risco de continuidade e um aliado potencial na mudança.
3. Meça o tempo real de fecho. Cronometre quantas horas por mês se gastam a consolidar dados manualmente. Este é o seu número de retorno defensável para uma candidatura PT2030.
4. Escolha uma dor única e mensurável. Rentabilidade por artigo, cumprimento de prazos, OEE de uma linha. Uma. A que dói mais e cujo resultado se pode medir antes e depois.
5. Valide a maturidade da origem. Confirme que os dados dessa dor existem no ERP de forma fiável. Se vivem só em Excel manual, o primeiro projecto é integrá-los, não visualizá-los.

Este exercício demora uma semana e evita o erro mais caro: comprar plataforma antes de saber o que se quer perguntar. A cultura conta tanto como a tecnologia — assunto de Como a cultura data-driven muda a tomada de decisão.

A tabela do custo silencioso

Para converter o diagnóstico em número, ajuda quantificar o que a arquitetura atual custa. Não em licenças — em horas e em erros.

O Excel não tem factura mensal. Tem uma factura anual disfarçada de horas de gente competente a fazer trabalho de máquina.

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

A recomendação certa depende de escala, maturidade de dados e complexidade do produto. Uma matriz honesta:

Para a micro e pequena: menos é mais

Uma confeção de 25 pessoas em subcontratação para uma casa-mãe não precisa de uma plataforma analítica governada — precisa de responder a duas ou três perguntas de sobrevivência. Estou a cumprir os prazos que me deram? Qual a minha eficiência real por operação? Estou a ganhar ou a perder em cada tipo de peça? Um único dashboard táctico sobre o ERP responde a isto, e o risco real não é técnico — é o tempo de quem tem de o manter. Numa estrutura pequena, quem faz o BI é a mesma pessoa que faz tudo o resto. O projecto tem de ser desenhado para consumir minutos, não horas, da atenção dessa pessoa.

Para a média industrial: o ponto doce

Uma fábrica têxtil típica do setor têxtil no Vale do Ave, com uns 80 colaboradores, encaixa quase sempre no segundo perfil. Tem ERP, tem apontamento de produção, e a dor divide-se entre "não sei a margem real por encomenda" e "não sei quanto tempo perco em setup entre lotes de cor". Aqui, o Qlik sobre o ERP resolve a primeira dor em semanas; a segunda exige integrar a captura de chão-de-fábrica e é a fase dois.

O erro típico neste perfil é querer resolver as duas dores de uma vez. A margem por encomenda depende de dados que já estão no ERP — vendas, custos de material, mão de obra imputada — e é atacável de imediato. O tempo de setup entre lotes de cor depende de captura fina no chão-de-fábrica, que muitas vezes ainda não existe ou existe em papel. Misturar as duas fases atrasa a primeira, que era a vitória rápida capaz de comprar credibilidade para a segunda.

Para o calçado: o problema dos eixos

No calçado de Felgueiras, a complexidade não está no volume de vendas mas na dimensionalidade. Analisar uma coleção implica cruzar cor × tamanho × forma × canal × campanha. ERPs generalistas achatam isto em relatórios planos. O modelo associativo do Qlik foi feito para navegar precisamente estes cubos — e para revelar o SKU que ninguém encomendou em todo o showroom de agosto. Sobre precificação inteligente nestes cenários, o Dynamic Pricing ganha outra base factual.

Há um ritmo sazonal que a análise de calçado tem de respeitar: os compradores internacionais visitam duas vezes por ano — calçado de homem em agosto, de senhora em fevereiro. A decisão sobre que referências manter, cortar ou reforçar na coleção seguinte toma-se numa janela apertada logo após cada visita. Um dashboard que responda em minutos a "que modelos tiveram interesse mas não converteram em encomenda" vale, nessa janela, mais do que semanas de análise fora do momento. A sazonalidade transforma a velocidade de resposta analítica numa vantagem competitiva direta.

Para a distribuição: o armazém não pode parar

Numa distribuidora no corredor Lousada–Paços, o chefe de armazém vai lutar contra qualquer rollout que o tire do rádio mais de duas horas. A lição operacional: o BI de armazém constrói-se sobre dados que já são capturados pela operação — de uma solução como KORA Inventory Suite — sem pedir trabalho novo a quem faz picking. O dashboard consome; não exige. Cruzar isto com práticas de Just-in-Time e 5S dá ao chefe de armazém números que ele próprio pode defender.

A resistência do chefe de armazém não é teimosia — é bom senso operacional. Quem faz gerir um armazém de 20 000 m² com picking e cross-docking sabe que qualquer paragem se propaga em cascata pela cadeia de entregas do dia. A abordagem que funciona é fazer o BI trabalhar a partir da telemetria que a operação já produz: leituras de código de barras, movimentos de stock, tempos de expedição. Nada de formulários novos, nada de pedir ao operador que introduza dados extra. O dashboard revela padrões de produtividade, gargalos de doca e desvios de stock a partir de dados que já existem. Quando o chefe de armazém percebe que o painel o defende em vez de o vigiar, torna-se aliado.

Para o retalho: volume não é margem

Uma cadeia regional de retalho alimentar com, digamos, 22 lojas, vive uma tensão específica: fatura muito, mas a margem esconde-se numa multiplicidade de artigos, promoções, quebras e roturas. O POS gera um dilúvio de transações que, sem análise, é ruído. Um dashboard de rentabilidade por artigo e por loja, cruzado com dados de MAXIRETAIL, revela onde a promoção destruiu margem sem gerar tráfego incremental, e onde a rotura silenciosa está a mandar clientes para a concorrência. A obrigação de certificação de software e comunicação à AT já produz os dados; o BI dá-lhes significado de gestão.

7. Quadro regulatório e conformidade aplicável

BI não vive num vácuo legal. Quando cruza dados de faturação, de colaboradores e de clientes num só sistema, herda obrigações que muitos esquecem até à primeira auditoria.

Dados de faturação e SAF-T

As fontes que alimentam o Qlik incluem dados de faturação sujeitos ao DL 28/2019 — faturação eletrónica, ATCUD, software certificado pela AT. O BI não substitui o sistema certificado; consome os seus dados. Mas se o dashboard de vendas apresentar valores que não reconciliam com o SAF-T comunicado mensalmente (Portaria 195/2020), tem um problema de credibilidade interna antes de ter um problema fiscal.

A reconciliação entre o dashboard e o SAF-T deve ser uma etapa formal do projecto, não uma verificação improvisada. Se o painel diz que as vendas de março foram X e o SAF-T comunicado à AT diz Y, alguém vai perguntar qual está certo — e a resposta "depende de como se contam as devoluções" mina a confiança em toda a plataforma. Definir as regras de negócio no load script de forma a que batam ao cêntimo com a contabilidade certificada é o que separa um dashboard credível de mais uma folha com aspirações.

RGPD e dados de pessoas

Um dashboard de RH que cruze absentismo, rotatividade e desempenho — do tipo que uma solução como pplPortal alimenta — mexe em dados pessoais sensíveis. O RGPD e a Lei 58/2019 exigem minimização e controlo de acesso por perfil. Ninguém no comercial deve ver a folha de vencimentos individual num painel. A governação de acesso do Qlik existe precisamente para isto; usá-la mal é uma coima à espera de acontecer. O Employee Engagement mede-se, mas mede-se com respeito pela privacidade.

O princípio da minimização tem uma tradução prática direta em BI: um dashboard de RH para a gestão de topo deve mostrar taxas agregadas — absentismo por departamento, rotatividade por unidade — e não o registo individual de cada colaborador. A tentação de "poder ir ao detalhe da pessoa" é precisamente o que a minimização proíbe quando não há base legal para esse nível de detalhe. O section access do Qlik permite construir a mesma app com vistas diferentes conforme o perfil: o diretor de RH vê o que tem de ver, o diretor industrial vê apenas o agregado da sua unidade.

Cibersegurança: NIS2 e ISO 27001

A Diretiva NIS2 (UE 2022/2555), transposta em Portugal, alarga as obrigações de cibersegurança a mais setores, incluindo indústria transformadora considerada crítica. Um servidor de BI concentra dados de toda a empresa num só ponto — é, por definição, um alvo de alto valor. Alojá-lo com controlos ISO 27001 e proteção perimetral não é luxo. É o tema de Segurança INFOS: proteção perimetral e SOC e dos riscos silenciosos da cibersegurança na empresa.

Vale medir a exposição com clareza: uma folha de cálculo comprometida expõe um domínio de dados; um servidor de BI comprometido expõe a empresa inteira, porque é ali que os domínios convergem. Esta concentração é a força do BI e o seu risco. O agravamento das obrigações NIS2, com as suas exigências de notificação de incidentes em prazos curtos e de responsabilização da gestão, torna a decisão de onde e como alojar a plataforma analítica numa decisão de conselho de administração, não de departamento de informática.

Um servidor de BI é a caixa-forte da empresa disfarçada de ferramenta bonita. Proteja-a como tal.

IA e o AI Act

Quando se adicionam modelos preditivos — previsão de procura, deteção de anomalias — entra o Regulamento UE 2024/1689 (AI Act), que classifica sistemas de IA por risco. A maioria dos casos de BI preditivo industrial cai em risco baixo ou limitado, mas convém documentar a classificação. Sobre onde a IA acrescenta previsibilidade real, vale IA aplicada INFOS: transformar dados em decisões automatizadas.

A distinção prática que interessa: um dashboard que mostra o passado e o presente não é um sistema de IA no sentido do regulamento. Torna-se sistema de IA quando incorpora modelos que fazem inferências — prever a procura da próxima coleção, sinalizar uma encomenda com risco elevado de atraso, detetar um padrão de fraude. Nesse momento, mesmo em risco baixo, convém ter documentada a lógica do modelo, os dados que o treinam e as limitações conhecidas. Não por burocracia, mas porque um modelo que decide sobre pessoas ou sobre crédito sem lógica auditável é um passivo à espera de acontecer.

8. Como a INFOS aborda isto

Trabalhamos Qlik Sense como camada analítica sobre o núcleo que já implementámos em fábricas portuguesas há mais de três décadas. Isto muda a conversa: não chegamos com um dashboard genérico, chegamos a conhecer o modelo de dados do têxtil, do calçado, da distribuição — porque o construímos no ERP MULTI ao longo de milhares de projectos no setor industrial.

A consequência prática é a velocidade de arranque. Quando os dados vivem num ERP que conhecemos, o load script não começa do zero — as regras de negócio de devoluções, câmbios e cortes por coleção já estão mapeadas. Para grupos com múltiplas filiais, a consolidação apoia-se em Multi Connect, e a captura de chão-de-fábrica em terminais que já falam com o BI.

Este ponto merece ênfase porque é onde a maioria dos projectos de BI genérico se atola. Metade do custo e do prazo de um projecto de BI está na modelação dos dados — em perceber como é que "vendas" se define nesta empresa, como se tratam as devoluções, como se rateiam os custos indirectos por encomenda, como se contam os artigos de uma coleção que muda de referência entre estações. Quem chega com uma ferramenta e sem conhecimento do modelo de dados do setor gasta meses a redescobrir o que já está resolvido no ERP vertical. Nós partimos com esse mapa desenhado.

Não vendemos plataforma como fim. Vendemos a passagem da folha de cálculo para a decisão — e, honestamente, a parte difícil raramente é técnica. É convencer o Sr. Armando de que largar o ficheiro o torna mais valioso, não dispensável. Os projectos que ignoram esta dimensão humana são os que escrevemos, anos depois, como aprendizagem.

O dashboard é a parte fácil. A parte difícil é a política interna de quem perde e quem ganha poder quando a verdade passa a ser partilhada.

O que aprendemos com os projectos que correram mal

A honestidade obriga a referir os fracassos. Vimos projectos descarrilar por três razões recorrentes. A primeira: escopo demasiado ambicioso à partida, dez dashboards em vez de um, energia dispersa e nenhuma vitória clara. A segunda: dados de origem que se assumiram limpos e não estavam — o projecto de BI transformou-se, a meio, num projecto de saneamento de dados não orçamentado, com todo o atrito que isso gera. A terceira, a mais insidiosa: falta de um dono humano com mandato e tempo para se apropriar da ferramenta, deixando o dashboard a ganhar pó enquanto o Excel continuava a comandar.

Destas aprendizagens saiu a nossa disciplina: começar pequeno, validar a qualidade da origem antes de prometer prazos, e identificar o dono humano antes de a primeira app ser construída. Nenhuma destas lições é técnica. Todas são de gestão de mudança — e é por isso que a parte mais valiosa de um projecto de BI acontece nas conversas, não no código.

9. Roadmap 30/60/90 dias

Um plano accionável com marcos verificáveis — nada de "melhorar a tomada de decisão", tudo em números que uma candidatura PT2030 ou uma reunião de gestão consegue auditar.

Dias 1–30: fundação e prova

• Concluir o diagnóstico de prontidão de cinco etapas da secção 5, com o tempo de fecho cronometrado como número-base.
• Escolher uma dor única e mensurável e mapear as suas fontes no ERP.
• Construir o primeiro dashboard táctico sobre essa dor, com dados reais — não maqueta.
• Marco verificável: a gestão consegue responder à pergunta-alvo em menos de cinco minutos, sem abrir Excel.

Dias 31–60: integração e confiança

• Automatizar o refrescamento dos dados a partir do ERP — fim das cargas manuais.
• Reconciliar os valores do dashboard com o SAF-T e com o fecho contabilístico, ao cêntimo.
• Formar o dono humano da antiga folha crítica como primeiro utilizador avançado — devolver-lhe protagonismo.
• Marco verificável: o tempo de consolidação mensal cai para uma fração do valor-base medido no dia 1.

Dias 61–90: escala e governação

• Publicar a segunda app sobre a próxima dor — tipicamente produção ou rentabilidade por cliente.
• Definir perfis de acesso: quem vê margens, quem vê RH, quem vê o quê — conformidade RGPD por desenho.
• Configurar alertas automáticos sobre desvios críticos (OEE abaixo do limiar, margem negativa por encomenda).
• Marco verificável: pelo menos duas decisões de gestão do trimestre foram tomadas a partir do dashboard, documentadas para o relatório técnico de financiamento.

Os anti-marcos: o que não deve acontecer

Tão importante como os marcos é vigiar os sinais de descarrilamento. Se ao fim de 30 dias ainda não há um dashboard com dados reais e continua tudo em fase de "levantamento de requisitos", o projecto entrou no pântano da análise infinita. Se ao fim de 60 dias os valores não reconciliam com a contabilidade e a resposta é "depois afinamos", a credibilidade já está a sangrar. Se ao fim de 90 dias o dono humano da folha antiga continua a manter a folha em paralelo "por segurança", a mudança não pegou. Cada um destes anti-marcos é um sinal para parar e corrigir, não para acelerar.

Fixe metas com OKR para cada fase — não porque soa moderno, mas porque um relatório de execução PT2030 sobrevive melhor com objetivos-chave medidos do que com adjectivos. E se, ao fim dos 90 dias, o Sr. Armando abrir o dashboard antes do Excel por sua iniciativa, ganhou. Esse é o verdadeiro indicador de que a folha de cálculo deixou de ser o sistema operativo oculto da sua empresa. Sobre transformar esses dados em resultado de fundo, aprofundo em Transforme dados em lucro com o Qlik Sense e no planeamento estratégico com BI.

A folha de cálculo não morre por decreto. Morre quando quem a mantinha descobre que o dashboard lhe devolve o tempo que o ficheiro lhe roubava — e quando a reunião de gestão, pela primeira vez, discute o negócio em vez de discutir qual dos três números está certo. Esse é o dia em que o BI deixou de ser um projecto de informática e passou a ser a forma como a empresa pensa.

Fontes

• INE — Inquérito à Utilização de Tecnologias da Informação e da Comunicação nas Empresas, 2025 (análise de dados, ERP, cloud).
• INE — Estatísticas do Comércio, 2024 (volume de negócios do comércio e do retalho).
• AIMMAP / Metal Portugal

Perguntas frequentes

O que é exatamente o Qlik Sense e como funciona na indústria?

Qlik Sense é uma plataforma de business intelligence que integra dados de várias fontes (ERP, folhas de cálculo, bases de dados) numa única camada de análise. Permite criar dashboards interativos onde os utilizadores exploram dados em tempo real, sem depender de relatórios estáticos. Na indústria portuguesa, resolve o problema das folhas de cálculo dispersas centralizando a informação.

Qual é a diferença entre usar Excel e implementar Qlik Sense?

Excel é flexível mas frágil: dados em silos, sem controlo de versões, dependência de pessoas. Qlik Sense centraliza tudo numa base única, com auditoria completa de quem alterou o quê e quando. Um controller deixa de gastar 24 dias por ano a consolidar folhas e passa a usar esse tempo em análise estratégica. Os dados estão sempre actualizados e acessíveis a quem precisa.

Quanto custa implementar Qlik Sense numa PME industrial?

O custo varia com a complexidade dos dados e o número de utilizadores. Licenças começam em torno de 3.000-5.000 euros anuais por utilizador nomeado. A implementação (integração de dados, desenho de dashboards, formação) custa tipicamente 15.000-40.000 euros. O retorno aparece em 6-12 meses através da redução de horas manuais e decisões mais rápidas.

Porque é que os projectos de BI falham em Portugal?

A razão principal não é técnica: é política. Quem controla a folha de cálculo perde poder quando essa folha desaparece. Se o projecto não reconverter esse protagonismo para análise real, há sabotagem passiva. O segundo erro é ignorar o IT interno que construiu a folha — esse profissional é aliado crítico, não obstáculo. Terceiro: implementar sem documentar as regras de negócio que vivem na folha.

Como é que o Qlik Sense resolve o problema da pessoa indispensável?

Documentando e automatizando o conhecimento que vive numa folha de cálculo. As regras de rateio, as fórmulas de margem, os cortes de devoluções — tudo fica registado no modelo de dados do Qlik. Quando essa pessoa sai, o conhecimento fica. Além disso, múltiplos utilizadores podem aceder aos mesmos dados com confiança, eliminando a dependência de um "Sr. Armando".

Qlik Sense funciona se a empresa não tem ERP?

Sim, mas com limitações. Qlik pode integrar dados de várias fontes (Excel, bases de dados, APIs, ficheiros CSV). Sem ERP, os dados continuam dispersos e a qualidade depende da origem. O ideal é ter um núcleo integrado (ERP ou data warehouse) para construir análise fiável. Se não existe, Qlik ajuda a organizar o caos, mas não substitui uma arquitetura de dados adequada.

Quanto tempo demora a ver resultados com Qlik Sense?

Os primeiros dashboards operacionais saem em 4-8 semanas. Decisões mais rápidas começam a aparecer imediatamente — um diretor industrial deixa de esperar por consolidações de fim de mês. O ROI completo (redução de horas manuais, melhor qualidade de decisão) materializa-se entre 6 e 12 meses, dependendo da complexidade inicial e da adoção pelos utilizadores.