Os seus dados de ERP, CRM e financeiros num só lugar, com histórico e uma definição acordada para cada KPI.
Com a confiança de organizações de referência
Um data warehouse é uma base de dados central onde reúne dados de ERP, CRM, loja online e planeamento, os limpa e organiza para criar relatórios fiáveis, incluindo sobre dados históricos. Mandar construir um data warehouse compensa quando a elaboração de relatórios exige demasiado trabalho manual ou os departamentos apresentam números diferentes. A Data Science Lab constrói-o, desde a primeira integração até à gestão.
No primeiro dia útil de cada mês, o controller exporta o volume de negócios do ERP, coloca-o no Excel ao lado de uma exportação do CRM e corrige manualmente os números de cliente que diferem entre os dois sistemas. Entretanto, a equipa comercial produz os seus relatórios diretamente a partir do CRM. Na reunião da equipa de direção, há dois valores de volume de negócios em cima da mesa, e ninguém sabe qual é a regra de cálculo correta nem quem decide sobre ela.
Há ainda a questão do histórico. Quando um cliente muda para outra região, o CRM substitui o valor anterior. Se depois consultar o volume de negócios por região do ano passado, o relatório faz os cálculos como se esse cliente sempre tivesse estado na nova região.
Um data warehouse recolhe automaticamente os dados das fontes, estabelece uma única vez a correspondência entre os números de cliente e regista as alterações em vez de as substituir. O valor no dashboard passa então a vir de um único modelo, com uma única regra de cálculo e um responsável.
Uma abordagem comprovada é a modelação dimensional segundo Ralph Kimball: tabelas de factos com eventos como encomendas e faturas, e dimensões como cliente, produto e data. Primeiro, definimos a granularidade: o nível de detalhe de cada linha. Assim, os relatórios continuam rápidos e fáceis de compreender.
Primeiro, carregamos os dados de origem sem alterações e depois transformamo-los na própria plataforma, muitas vezes com dbt. Assim, cada regra de cálculo fica registada em código com controlo de versões, com testes, por exemplo, a chaves únicas, campos vazios e valores válidos.
Com slowly changing dimensions, dimensões que acompanham as alterações ao longo do tempo, é possível preservar o estado de um cliente ou produto em qualquer momento. No tipo 2, uma alteração cria uma nova versão com um período de validade, para que a receita do ano passado continue associada à região anterior.
Definimos uma única vez o que conta como receita, cliente ativo ou entrega atempada, num modelo semântico partilhado, como um modelo Power BI ou metric views no Databricks. Depois, todos os dashboards Power BI usam a mesma fórmula.
Cada fonte e cada KPI tem um responsável que sabe o que significam os campos e quem resolve os erros. As verificações na pipeline de carregamento detetam valores vazios ou anómalos antes de chegarem a um relatório. Estes acordos fazem parte da data governance.
Ligamos sistemas ERP, CRM, de comércio eletrónico, de RH e de planeamento através de APIs, ligações a bases de dados ou exportações automatizadas. Definimos centralmente a correspondência entre números de cliente e códigos de artigo de diferentes sistemas, em vez de a refazer em cada relatório.
Diga-nos que fontes tem. Ajudamos a definir o primeiro tema para o seu data warehouse.
Começamos pelos relatórios e pelas decisões que o data warehouse deve apoiar e definimos, para cada KPI, o que significa e quem é responsável por ele.
Analisamos que sistemas fornecem os dados, como aceder-lhes, com que frequência devem ser atualizados e onde há falhas de qualidade.
Data warehouse ou lakehouse, cloud ou servidor próprio: escolhemos o que melhor se adequa aos seus dados, à sua equipa e ao seu ambiente de TI existente.
Desenvolvemos uma área bem delimitada, como vendas ou stocks, desde a fonte até ao dashboard. Os utilizadores comparam os números com o que conhecem da prática.
Depois, avançamos para o processo seguinte. Reutilizamos dimensões como cliente, produto e data, para que as novas áreas se integrem no que já existe.
Monitorizamos os processos de carregamento de dados e ajustamos o modelo quando as fontes ou as definições mudam. Também podemos continuar a tratar dessa gestão por si.
A DSL ajudou-nos a criar o nosso primeiro data warehouse. Acompanhou-nos passo a passo e ajudou-nos a identificar a informação de que precisamos para tomar melhores decisões. Isto deu-nos informações muito importantes e aumentou os nossos lucros. Para nós, é uma parceira fantástica, que recomendamos a outras PME.
Um data warehouse armazena dados estruturados e controlados em tabelas preparadas para relatórios. Um data lake armazena dados de qualquer tipo em bruto: é económico e flexível, mas os dados não são validados, pelo que é menos adequado para apoiar decisões de gestão. Um lakehouse combina ambos num único formato de armazenamento aberto, com camadas que vão dos dados em bruto (bronze) aos dados limpos (prata) e prontos para uso empresarial (ouro). A Databricks e a Microsoft Fabric chamam-lhe arquitetura medallion; o modelo dimensional do seu data warehouse pode constituir a camada ouro.
Se trabalha sobretudo com dados estruturados de sistemas ERP e CRM e a sua equipa escreve SQL, um data warehouse é muitas vezes suficiente. Se também precisa de lidar com dados de sensores, documentos ou machine learning, um lakehouse poderá ser mais adequado. Para a Vivara, criámos uma plataforma de dados em Azure Databricks que recolhe diariamente dados de fontes como SAP, Magento e SharePoint.
Também não tem de estar necessariamente na cloud: para a Zuiver, criámos um data warehouse num servidor próprio, que reúne as diferentes fontes. Para saber como um data warehouse se integra num ambiente de dados mais amplo, leia sobre a fundação de dados.
Qualquer organização pode iniciar um projeto-piloto de IA. O desafio está no passo seguinte: integrar a IA na organização. É aí que a Data Science Lab faz a diferença.
Saiba mais sobre nós
10+
8,7
200+
Um data warehouse é uma base de dados concebida para análise e produção de relatórios, separada dos sistemas onde decorre o trabalho. Reúne dados de ERP, CRM e outras fontes, limpa-os e conserva o histórico, para que possa comparar dados entre departamentos e ao longo dos anos com as mesmas definições.
Em princípio, qualquer sistema do qual seja possível extrair dados: sistemas ERP como o SAP, CRM, lojas online, sistemas de RH e planeamento, ficheiros Excel e SharePoint. Para o Koninklijk Concertgebouworkest, ligamos e normalizamos informação de diferentes sistemas e arquivos numa única plataforma de dados. A parte mais difícil raramente é a ligação em si, mas chegar a acordo sobre qual é a fonte de referência.
O dbt (data build tool) é uma ferramenta para escrever, testar e documentar transformações em SQL. Assim, cada passo desde os dados de origem até ao KPI fica registado como código sob controlo de versões, e é possível rastrear alterações às regras de cálculo. Na Fokker Services Group, usamos dbt e Databricks para modelar dados de diferentes fontes segundo a arquitetura medallion, com verificações de qualidade dos dados integradas.
Com slowly changing dimensions. No tipo 1, substitui-se um valor, como um endereço de email corrigido. No tipo 2, cria-se uma nova versão com datas de início e fim, por exemplo, quando um cliente muda de região. No dbt, faz-se isso com snapshots. Muitos sistemas de origem não guardam as alterações, por isso registe-as desde o início: os dados que a fonte já substituiu muitas vezes não podem ser recuperados.
Ambos. Enquanto Databricks Partner e Microsoft Partner, desenvolvemos plataformas de dados e IA com Databricks e Microsoft Fabric. O Fabric é um serviço SaaS; o Databricks funciona num fornecedor de cloud como o Azure. Em ambos os casos, os dados são armazenados no formato aberto Delta, pelo que não fica dependente de um único fornecedor. O que mais importa é onde os dados têm de estar, quem os vai gerir e que conhecimentos existem internamente.
Normalmente, sim, embora as regras de cálculo passem para o modelo central. Começamos por fazer um levantamento do que existe: que tabelas existem, que regras de cálculo estão nos relatórios e quais são efetivamente utilizadas. As regras atualmente dispersas por relatórios separados passam para o modelo central. Depois, migramos os relatórios existentes um a um, para que os utilizadores não tenham de mudar todos de uma vez.
Se produz relatórios a partir de um único sistema com boas funcionalidades próprias de reporting, ou se precisa apenas de alguns relatórios que raramente mudam. Nesses casos, um modelo Power BI ligado diretamente à fonte costuma ser suficiente. Um data warehouse também não resolve problemas de qualidade na fonte: nesse caso, é preciso começar por limpar os dados e definir regras para a sua introdução. Se uma solução mais simples for suficiente, dizemo-lo com franqueza.
E-mail info@datasciencelab.nl
Telefone +31 (0)20 3636 724
Diga-nos que fontes de dados tem e que números estão a suscitar debate neste momento. Pensamos consigo no primeiro tema a abordar e na arquitetura adequada.
Mensagem enviada
Obrigado pela sua mensagem. Entraremos em contacto consigo o mais rapidamente possível.
