Artigo 07 de 16
Uma estrutura de 5 etapas para transformar dados dispersos num ativo estratégico
O termo “estratégia de dados” é muito utilizado – muitas vezes como abreviatura de “devemos fazer algo com os nossos dados”. Uma estratégia de dados real é algo muito mais específico: uma estrutura clara de como a sua organização recolhe, armazena, governa e utiliza os dados para atingir os objetivos de negócio. Sem ele, as empresas acabam por ter armazéns de dados dispendiosos, cheios de números pouco fiáveis, equipas de análise a gastar 80% do seu tempo a limpar dados e a liderança ainda a tomar decisões com base na intuição. As estratégias que realmente funcionam partilham algumas características: partem de questões empresariais e não de escolhas tecnológicas, estabelecem prioridades impiedosamente, tratam a governação como uma preocupação de primeira classe e não como uma reflexão tardia, e fornecem algo utilizável já no primeiro trimestre. As estratégias que falham tendem a fazer o contrário: começam com uma selecção de fornecedores, adiam a governação para a “fase dois” e produzem um documento de 60 páginas que ninguém lê. Esta publicação aborda uma estrutura de cinco etapas que funcionou em projetos marítimos, de logística, de energia e de fabrico.
O erro mais comum na estratégia de dados é começar pela tecnologia. As empresas compram um data warehouse, contratam analistas e depois perguntam “o que devemos fazer com ele?” Em vez disso, comece com as suas questões comerciais mais importantes não respondidas. Para uma empresa de logística, estas podem ser: "Porque é que a nossa taxa de entrega dentro do prazo está a diminuir?" ou "Quais as rotas que são rentáveis e quais estão a destruir margens?" Para um operador marítimo: "O que está a impulsionar o aumento do consumo de combustível nas nossas rotas no Mar do Norte?" Para um fabricante: “Quais os SKU que estão a subsidiar discretamente o restante portfólio de produtos?” Todo o investimento em dados deve remontar a uma questão específica que, se respondida, alteraria uma decisão. Se não consegue articular a decisão que os dados pretendem informar, ainda não tem um caso de utilização – tem uma curiosidade. A curiosidade é boa, mas não é o que justifica um investimento multitrimestral na plataforma.
Identifique as 5 a 10 principais decisões que a sua equipa de liderança toma repetidamente e toma atualmente sem bons dados
Priorizar por impacto: que decisão, se melhor tomada, afetaria mais diretamente a receita, o custo ou o risco?
Defina como seriam os “dados bons” para cada decisão – que métricas, com que granularidade, com que frequência?
Antes de criar qualquer coisa nova, mapeie quais os dados que já existem na sua organização. De acordo com a nossa experiência, a maioria das empresas detém 70 a 80% dos dados de que necessitam – estão apenas dispersos, inconsistentes e inacessíveis. Uma auditoria de dados identifica: que sistemas contêm dados relevantes (ERP, CRM, telemática, folhas de cálculo), quão fiáveis são realmente estes dados, quem é o seu proprietário e onde estão as lacunas críticas. Esta auditoria demora normalmente 2 a 4 semanas e revela quase sempre insights surpreendentes – como o facto de duas unidades de negócio monitorizarem a mesma métrica de forma diferente há três anos, ou de todo um fluxo de receitas ser registado numa folha de cálculo que está no portátil de um gestor financeiro. A saída é um inventário de dados: um catálogo estruturado de fontes, proprietários, cadências de atualização e problemas de qualidade conhecidos. Esse documento torna-se a base para tudo o que se segue.
Não ignore a auditoria. Isto evita que passe seis meses a construir um pipeline de dados para dados que não existem ou que não são fiáveis para utilização. A auditoria é também onde se descobre quais as integrações que serão dolorosas – e trazer à tona essa dor antecipadamente permite-lhe planear isso em vez de ser apanhado de surpresa no quarto mês.
Uma arquitetura de dados é o modelo de como os dados fluem dos sistemas de origem para as pessoas que deles necessitam. Não existe uma arquitetura única certa, mas a maioria das pilhas de dados modernas segue um padrão semelhante: ingestão de dados (pipelines ETL/ELT), um data warehouse ou lakehouse centralizado, uma camada de transformação (como dbt) e uma camada de apresentação BI. As principais decisões aqui são: fornecedor de cloud (AWS, Azure, GCP), tecnologia de armazém (Snowflake, BigQuery, Redshift, Databricks), ferramenta de orquestração (Airflow, Prefect) e ferramenta de dashboard (Power BI, Tableau, Looker). Estas escolhas devem ser orientadas pelo seu ambiente existente, pelas competências da sua equipa e pelos seus requisitos de volume e latência — e não pelo marketing do fornecedor.
Comece de forma simples: uma pilha de duas camadas bem concebida (armazém + ferramenta BI) supera uma pilha complexa de cinco camadas que ninguém compreende
Escolha serviços de cloud geridos em vez de auto-hospedados sempre que possível – a sobrecarga de manutenção mata as pequenas equipas de análise
Garanta que a arquitetura consegue lidar com o seu pico de volume de dados com espaço de sobra
A governação de dados é o conjunto de regras, processos e estruturas de responsabilidade que garantem que os seus dados se mantêm fiáveis ao longo do tempo. É a parte menos glamorosa de uma estratégia de dados – e a parte que a maioria das empresas ignora até que algo se rompe catastroficamente, normalmente sob a forma de um pedido do regulador, uma disputa de dados ao nível do conselho ou um incidente de segurança. A governação abrange: a propriedade dos dados (quem é responsável por cada conjunto de dados), definições de dados (o que significa realmente "receita" na sua organização?), monitorização da qualidade dos dados (alertas automatizados quando os valores saem dos intervalos esperados), controlos de acesso (quem pode ver o quê) e gestão de alterações (o que acontece quando um sistema de origem altera o seu esquema). Construir a governação retrospetivamente é doloroso – cada métrica precisa de ser novamente contestada, cada política de acesso reaplicada, cada proprietário reidentificado. Construí-lo desde o início é uma semana de trabalho que compensa pela vida útil da plataforma.
Uma estratégia de dados não é um projeto único. É um sistema vivo que deve ser revisto trimestralmente em relação às questões empresariais a que foi concebido para responder. Acompanhe a adoção (as pessoas estão realmente a utilizar os painéis?), as pontuações de qualidade dos dados (que percentagem de registos passam na validação?) e a velocidade de decisão (as decisões estão a ser tomadas mais rapidamente?). As empresas que obtêm o maior valor dos dados não são aquelas que possuem a tecnologia mais sofisticada. São eles que reveem consistentemente o que está a funcionar, eliminam o que não está e continuam a fechar a lacuna entre os dados e a decisão.
A maioria das estratégias de dados bem-sucedidas começa pequena: uma questão comercial crítica, uma fonte de dados fiável, um painel utilizado diariamente por uma equipa. Depois expandem-se a partir daí. As empresas que tentam ferver o oceano raramente entregam alguma coisa; as empresas que entregam uma primeira fatia estreita constroem quase sempre algo substancial.
Na prática, uma estratégia de dados nunca é independente do setor. A estrutura de cinco etapas é válida, mas os domínios de dados e as métricas que geram valor variam acentuadamente por setor. O erro é tratar a estratégia como um exercício genérico e perder os poucos ativos de dados de alta alavancagem que realmente diferenciam a sua operação.
Marítimo: a rentabilidade da viagem por navio, o consumo de combustível ajustado ao clima, o tempo de resposta no porto e a exposição ao fretamento são os primitivos de alto valor. AIS, relatórios do meio-dia e faturas de bunker são as fontes de elevado atrito.
Logística: a margem ao nível da rota, o tempo de ciclo de cais a cais, a utilização de veículos e a taxa de sinistros por pista geram a maior parte dos insights acionáveis. TMS, telemática e feeds EDI de clientes são os desafios da integração.
Energia: as curvas de declínio da produção, o tempo de atividade dos ativos, o equilíbrio da exposição ao mercado e a intensidade de carbono por MWh são as cargas de trabalho analíticas dominantes. Os historiadores SCADA e os feeds de dados de mercado dominam a agenda de integração.
Fabrico: OEE, taxa de refugo, manutenção preditiva e margem ao nível da SKU são questões recorrentes. Os dados de MES, ERP e PLC de chão de fábrica são as fontes de integração típicas, sendo a qualidade muitas vezes o maior obstáculo.
Nomear estas especificidades no seu documento estratégico obriga a equipa da plataforma a fazer escolhas arquitetónicas concretas, em vez de construir um armazém genérico e esperar que se encaixe.
O resultado final
Uma estratégia de dados que funcione começa com questões de negócio, não com tecnologia. Audite o que tem, escolha uma arquitetura adequada ao seu ambiente, crie governação desde o primeiro dia e meça incansavelmente. As estratégias que falham são quase sempre as que invertem isto – começando pela selecção de um fornecedor, adiando a governação e produzindo um documento em vez de um painel funcional. Se isto parece muito trabalhoso - é. Delta BI já o fez dezenas de vezes nas áreas marítima, logística, energia e manufatura. Podemos acelerar cada etapa, desde a auditoria inicial, passando pela escolha da arquitetura, até à estrutura de governação e ao primeiro painel de produção.
Comece pela decisão
Conte-nos o seu desafio. Responderemos para agendar uma avaliação e definir um caminho prático.
Pedir uma avaliação de dados