A maioria das empresas industriais portuguesas não falha por falta de dados. Falha porque tem dados a mais, espalhados por ficheiros Excel, o ERP, o sistema de faturação e a cabeça do diretor comercial — e ninguém sabe qual é a versão verdadeira. Este guia defende uma posição clara: tornar-se data-driven é, antes de tudo, um problema de autoridade política, não de tecnologia. E dá-lhe um método concreto para o resolver — auditar o que tem, decidir o que importa e criar uma base que aguente o peso das decisões do dia a dia.

A tese que ninguém quer ouvir

Tornar-se data-driven não começa com tecnologia. Começa com uma decisão política: quem tem autoridade para declarar que um número está errado?

Segundo o INE, em 2025 apenas 53,7% das empresas em Portugal usavam ERP. Sem um núcleo transacional integrado, qualquer iniciativa de BI trabalha sobre dados dispersos — e os dashboards que resultam são, na melhor das hipóteses, uma média de versões incompatíveis da realidade. Crescimento real em analytics, portanto, mas construído sobre areia em muitas PME industriais. O diretor de produção continua a confiar mais no caderno do encarregado do que no ecrã do Qlik Sense — não porque seja retrógrado, mas porque o caderno nunca lhe mentiu com dados mal imputados.

O problema não é o software. É a ausência de uma fonte de verdade acordada. Enquanto o CFO calcula a margem com uma fórmula e o COO usa outra, a organização não é data-driven — é data-confusa. Os KPIs industriais que o CFO e o COO discordam são o sintoma mais visível deste problema, e o mais caro.

Uma organização data-driven não é aquela que tem mais dados. É aquela onde toda a gente usa os mesmos dados para discutir — e onde discordar do número obriga a provar, não a opinar.

O que precisa antes de começar

Não avance para ferramentas sem verificar estes pré-requisitos. Cada um em falta é uma razão concreta para o projeto parar a meio — e na nossa experiência com fábricas do Norte, é quase sempre o primeiro ou o último que falta, não os do meio.

Precisa de um patrocinador executivo com autoridade real para resolver conflitos de dados entre departamentos — não alguém que "apoia a iniciativa", mas alguém que pode dizer ao diretor comercial que o número do ERP prevalece sobre o Excel dele. Precisa de pelo menos uma fonte de dados transacional centralizada — ERP, sistema de faturação, WMS — que cubra mais de 80% do volume de negócio. Precisa de identificar os três a cinco processos onda decisão errada custa mais dinheiro: produção, compras, crédito a clientes, stock, margem por linha de produto. E precisa de um responsável de dados nomeado com tempo alocado — não voluntariado. Pode ser o controller financeiro ou o IT interno; não tem de ser um data scientist. O que não pode ser é "toda a gente quando tiver tempo".

Antes de avançar, defina também o que é confidencial: quem vê margens por cliente, quem vê custos de produção, quem vê salários. E prepare a equipa para aceitar que alguns relatórios históricos vão mostrar números diferentes dos que conhece. Isso é informação, não erro.

Passo 1 — Audite as suas fontes de dados em 90 minutos

Reúna o IT, o controller e um responsável operacional. Abra uma folha em branco. Para cada sistema que a empresa usa, preencha a tabela seguinte. Não precisa de ser exaustivo — precisa de ser honesto.

Sistema O que regista Atualização Quem confia nele Problema conhecido
ERP / faturação Vendas, compras, stock, financeiro Tempo real / diária CFO, comercial Artigos sem custo padrão atualizado
Excel de produção Ordens, tempos, refugo Semanal (manual) Diretor de produção Versões diferentes por turno
Sistema de RH / ponto Assiduidade, horas extra Mensal RH, payroll Não integrado com produção
Folhas de rota / papel Tempos de operação Por ordem Encarregado Não digitalizadas, perdem-se
CRM / email Pipeline, visitas, reclamações Ad hoc Comercial (parcialmente) Incompleto, não obrigatório

No fim da sessão terá o mapa real do seu território de dados — não o que devia existir, o que existe. Guarde-o. É o documento de trabalho para tudo o que se segue. Um detalhe que os manuais raramente referem: a coluna "Problema conhecido" é a mais importante da tabela. Se ninguém escreve nada nela, a sessão não foi honesta — recomece.

Passo 2 — Escolha uma pergunta de negócio, não um projeto de dados

O erro mais frequente que vemos em empresas industriais portuguesas: começam pela infraestrutura. Compram um data warehouse, instalam uma ferramenta de BI, e depois perguntam "que relatórios queremos?". O resultado são dashboards que medem tudo e respondem a nada — e que em seis meses ninguém abre.

Faça o inverso. Escolha uma pergunta de negócio com três características: tem um decisor identificado, tem impacto financeiro mensurável, e a resposta muda um comportamento concreto. "Qual é a margem real por referência de produto, depois de imputar o refugo e o retrabalho?" é uma boa pergunta. "Quais os clientes que compram menos de X€ por trimestre mas consomem mais de Y horas de suporte?" também. "Em que ordens de produção o desvio de tempo real vs. planeado supera 20%?" resolve um problema que o diretor de produção tem todas as semanas. "Qual o prazo médio de recebimento por segmento de cliente — e quanto custa em capital de trabalho?" é a pergunta que o CFO devia estar a fazer há dois anos.

Uma pergunta. Um decisor. Um prazo para ter a resposta. Só depois define os dados necessários para responder. Leia mais sobre como estruturar este processo em Planeamento estratégico com BI: quando os dados substituem a intuição.

Antes de avançar para o passo seguinte, confirme: a pergunta tem um decisor com nome e cargo? A resposta muda uma decisão operacional ou financeira concreta? Os dados necessários existem — mesmo que dispersos? Definiu uma data para ter a primeira resposta?

Passo 3 — Defina a sua fonte de verdade por domínio

Numa fábrica de confeção do Vale do Ave com 120 colaboradores, é comum existirem três números diferentes para "stock de malha": o do ERP, o do armazém em Excel e o que o encarregado tem na cabeça. Os três estão tecnicamente "certos" — cada um mede uma coisa ligeiramente diferente, com um timing diferente. O problema não é técnico. É a ausência de uma declaração explícita: para efeitos de decisão, o número oficial é este, atualizado desta forma, por esta pessoa.

Para cada domínio de dados crítico, documente numa página simples a fonte oficial — qual o sistema ou ficheiro que prevalece em caso de conflito —, o responsável que valida e corrige, a frequência de atualização, e a regra de conflito: se dois sistemas divergem mais de X%, quem é notificado e em quanto tempo. Chame-lhe "contrato de dados" ou como quiser. Este documento é mais valioso do que qualquer dashboard nos primeiros seis meses. Sem ele, o Self-Service BI torna-se uma fábrica de versões alternativas da realidade — e cada departamento produz a sua.

Um erro específico que encontramos repetidamente: as empresas definem a fonte oficial para stock e faturação, mas esquecem-se da margem. Resultado: o comercial apresenta margens brutas, o CFO apresenta margens líquidas com imputação de custos indiretos, e a reunião de gestão passa meia hora a perceber por que os números não batem. Declare a fonte da margem antes de construir qualquer relatório financeiro.

Passo 4 — Meça a qualidade antes de construir relatórios

Antes de ligar qualquer ferramenta de visualização, passe uma semana a medir a qualidade dos dados da sua fonte oficial. Não é glamoroso. É o que separa os projetos que funcionam dos que morrem em seis meses.

Quatro métricas simples para começar:

  1. Completude: que percentagem dos registos tem todos os campos obrigatórios preenchidos? Artigos sem custo padrão, clientes sem segmento, ordens sem centro de custo — cada campo vazio é uma decisão que vai ser tomada com base em zero.
  2. Consistência: o mesmo conceito é codificado da mesma forma em todos os registos? "Portugal", "PT", "PRT" no campo país parecem um pormenor até ao dia em que o relatório de vendas por mercado agrupa errado e o diretor comercial apresenta números incorretos ao conselho.
  3. Atualidade: qual o atraso médio entre o evento real e o registo no sistema? Uma receção de mercadoria registada dois dias depois invalida qualquer análise de stock em tempo real.
  4. Unicidade: existem duplicados — clientes com dois códigos, artigos com referências duplicadas? Num ERP com dez anos de vida e três migrações, a resposta é quase sempre sim.

Não precisa de uma ferramenta de data quality para começar. Um SQL básico ou um Power Query resolve. O que precisa é de registar os resultados e partilhá-los com o patrocinador executivo. Problemas de qualidade de dados não se resolvem no IT — resolvem-se com processos operacionais e com quem os executa. O IT mede e reporta; o responsável de compras é quem tem de obrigar ao preenchimento do custo padrão antes de gravar o artigo.

Passo 5 — Construa o primeiro dashboard para uma decisão, não para um relatório

Um dashboard data-driven responde a uma pergunta e sugere uma ação. Um relatório lista o que aconteceu. A diferença não está na ferramenta — está no design. E na maioria das empresas que visitámos, o primeiro dashboard construído é um relatório disfarçado de dashboard: 14 gráficos, três tabelas, dois filtros de data e nenhuma indicação do que fazer a seguir.

Aplique esta regra ao primeiro dashboard: se o utilizador não consegue dizer, em menos de 30 segundos, o que deve fazer a seguir, o dashboard falhou. Um indicador principal no topo — o número que define se o dia ou a semana está bem ou mal. Dois a três indicadores de contexto que explicam por que o número principal está onde está. Uma lista de exceções — os casos que precisam de ação imediata: clientes em atraso, ordens com desvio, stock abaixo do mínimo. Nenhum gráfico decorativo. Se não muda uma decisão, não está no ecrã.

Antes de apresentar à gestão, teste o dashboard com dados reais e com o utilizador principal presente. Pergunte-lhe: "O que faria agora?" Se a resposta for "não sei" ou "teria de ir ver outra coisa", o design precisa de ser revisto. Veja como este princípio se aplica na prática em KPIs empresariais: o guia operacional para diretores industriais portugueses e em Como a cultura data-driven muda a tomada de decisão.

Erros comuns e como evitar

Começar pelo software. Comprar a ferramenta de BI antes de ter a fonte de verdade definida garante um projeto de seis meses que termina em dashboards que ninguém usa. A sequência correta é: pergunta de negócio → fonte de dados → contrato de dados → qualidade → ferramenta. Inverter qualquer passo desta ordem custa tempo e credibilidade interna.

Tratar qualidade de dados como problema de IT. O IT pode medir e reportar. Mas a causa de um campo vazio num artigo do ERP é um processo de compras que não obriga ao preenchimento. A correção é operacional, não técnica. Envolva os responsáveis de processo desde o início — e formalize a obrigação no procedimento, não num email de pedido.

Querer medir tudo de uma vez. Uma empresa que tenta construir 40 KPIs em simultâneo não constrói nenhum bem. Escolha três. Faça-os funcionar durante 90 dias. Só depois expanda. A pressão para "aproveitar o projeto" e acrescentar indicadores é real — e é a razão mais comum pela qual os projetos de BI perdem foco e credibilidade antes de produzirem valor.

Ignorar a camada de acesso. Definir quem vê o quê não é burocracia — é a condição para que os utilizadores confiem no sistema. Um dashboard de margens por cliente acessível a toda a força de vendas cria problemas comerciais e de RGPD em simultâneo. Defina perfis de acesso antes de publicar o primeiro relatório, não depois de alguém se queixar.

A transição para uma organização data-driven não se faz num trimestre nem com um único projeto. Faz-se com decisões pequenas e repetidas: declarar a fonte oficial de um número, resolver um conflito de versões, construir um dashboard que uma pessoa usa todas as segundas-feiras. A escala vem depois — quando a confiança nos dados já está instalada na cultura da empresa, não antes.

Perguntas frequentes

O que significa uma organização ser "data-driven"?

Uma organização data-driven é aquela onde todas as pessoas usam os mesmos dados para discutir e decidir. Não é quem tem mais dados, mas quem usa dados consistentes e acordados. Quando há discordância sobre um número, obriga-se a provar com dados, não a opinar. É o oposto de "data-confusa", onde cada departamento tem a sua versão da verdade.

Por que falham as iniciativas de dados nas empresas industriais portuguesas?

Falham porque começam pela tecnologia, não pela política. A maioria tem dados dispersos em Excel, ERP e sistemas isolados — ninguém sabe qual é a versão verdadeira. Sem uma fonte de verdade acordada e um responsável com autoridade para resolver conflitos, os dashboards medem tudo e respondem a nada. O problema não é falta de dados, é falta de autoridade política.

Qual é o primeiro passo para tornar-se data-driven?

Auditar o que tem em 90 minutos. Reúna IT, controller e um responsável operacional. Mapeie cada sistema (ERP, Excel, CRM, etc.), o que regista, com que frequência atualiza, quem confia nele e que problemas conhece. Este mapa real — não o ideal — é o documento de trabalho para tudo o que se segue.

Preciso de um data scientist para começar?

Não. Precisa de um responsável de dados nomeado com tempo alocado — pode ser o controller financeiro ou IT interno. O que não pode ser é "toda a gente quando tiver tempo". Não precisa de ser especialista em tecnologia, mas tem de ter autoridade para garantir que os dados são consistentes e usados corretamente.

Qual é o erro mais comum ao começar um projeto de dados?

Começar pela infraestrutura: comprar um data warehouse, instalar BI, e depois perguntar "que relatórios queremos?". O resultado são dashboards que medem tudo e respondem a nada. Faça o inverso: escolha uma pergunta de negócio com decisor identificado, impacto financeiro e que mude um comportamento concreto. Depois defina os dados necessários.

Que pré-requisitos preciso antes de avançar para ferramentas?

Precisa de: um patrocinador executivo com autoridade real para resolver conflitos entre departamentos; pelo menos uma fonte transacional centralizada (ERP, faturação, WMS) que cubra mais de 80% do volume; três a cinco processos onde decisão errada custa dinheiro; e um responsável nomeado com tempo alocado. Sem estes, o projeto para a meio.

Como escolho a primeira pergunta de negócio para responder?

Escolha uma pergunta que tenha: um decisor identificado com nome e cargo; impacto financeiro mensurável; e que mude um comportamento operacional ou financeiro concreto. Exemplos: "Qual a margem real por produto após refugo?" ou "Qual o prazo de recebimento por cliente e o custo em capital de trabalho?". Uma pergunta, um decisor, um prazo.

Fontes

  • Instituto Nacional de Estatística (INE) — Estatísticas sobre adoção de ERP em empresas portuguesas (2025)
  • Norma ISO/IEC 27001:2022 — Gestão da segurança da informação e governança de dados em organizações
  • Regulamento (UE) 2016/679 (RGPD) — Proteção de dados pessoais e conformidade em sistemas de informação
  • ENISA (European Union Agency for Cybersecurity) — Diretrizes sobre governança de dados e qualidade de informação em infraestruturas críticas
  • Banco de Portugal — Recomendações sobre gestão de risco operacional e controlo interno em processos de dados financeiros