data warehouse - como modelar

Data Warehouse – Passo a Passo para Modelar um Data Warehouse

Quer saber o segredo para, ao invés de demorar 6 meses na entrega de um Data Warehouse, levar 1 mês só?

O Agile Data Warehouse Design é uma metodologia de desenvolvimento ágil para criação de Data Warehouse.

A ideia é diminuir as horas e horas de reuniões improdutivas e focar no que realmente precisamos levantar para desenhar o Data Warehouse.

Mas vamos por partes.

Hoje em dia mais ninguém tem tempo para esperar. E se para nós é assim, imagina para o cliente que precisa tomar uma decisão e não tem os benditos dados que precisa?

Isso nos deixa com 2 problemas:

  1. O cara não está disposto a esperar 1 ano até o Data Warehouse estar pronto
  2. Ele não vai ter tempo para fazer todas as milhares de reuniões que você precisa

 

E como eu resolvo isso?

Vou apresentar aqui o 5W3H. Se você teve algum contato com a área de administração, já deve ter ouvido falar no 5W2H. A ideia é parecida, mas fiz uma adaptação nela para metodologias ágeis de desenvolvimento de Data Warehouse.

Para isso eu monto um mapa mental. Obviamente, você pode utilizar outro tipo de ferramenta. Eu utilizo o mapa mental porque fica organizado e fácil de visualizar, o que é bom tanto pra você como para o cliente.

Fica assim:

Agile Data Warehouse Design

A aparência é amigável e com perguntas que os Key Users estão acostumados a ver no dia a dia.

Lembra sempre que a obrigação da tomada de decisão correta é sua. Embora o cliente deva saber o que ele quer, você, como consultor, tem que saber extrair as melhores respostas.

Por mais que a criação de um Data Warehouse pareça simples ou cotidiana para você, para o cliente não é, então ele nem sempre vai saber te dar as melhores respostas.

 

Tá, mas como eu uso isso?

Eu sempre compartilho o próprio mapa mental online com o cliente, assim não precisa estar todo mundo junto naquelas benditas reuniões que é sempre difícil de colocar todo mundo no mesmo lugar no mesmo horário.

A sacada é que as pessoas recebam esse mapa primeiro, antes da reunião, para começar a entender o que você precisa. Assim, elas mesmas já podem começar a preencher algumas informações direto no mapa mental.

Vai tentar pegar o tempo do VP, diretor financeiro ou gerentes, os caras estão sempre correndo. Aí você compartilha uma ferramenta assim, bem simples. Já peguei vários clientes que entre uma reunião e outra abriam o aplicativo, davam uma olhada, comentavam alguma coisa e viam o que o resto do time já tinha colocado.

Então todo mundo estava olhando a mesma coisa e sem nenhuma reunião até agora.

Quando você finalmente for fazer a reunião, pode abrir esse mesmo mapa mental que já está com as respostas do pessoal e começar a bater as perguntas. E mesmo que não dê tempo de todos preencherem tudo, pelo menos já vão saber do que se trata, não vão estar tão confusos na reunião. A gente trabalha com pessoas, precisamos entender isso. Aí na reunião você começa a passar as perguntas uma a uma.

Eu coloquei as perguntas na ordem que eu prefiro fazer, porque foi a ordem que identifiquei ser a melhor nos projetos que usei essa estratégia. Mas é claro, você pode trocar para como fizer mais sentido no seu projeto.

Algumas perguntas não fazem sentido para determinados tipos de negócio e vai ter outras que o cliente realmente não quer porque não interessa para ele, então tem coisas que você pode pular sem problema nenhum.

 

Agora, o passo a passo

A primeira pergunta que você deve fazer é a do centro.

Qual fato aconteceu?Agile Data Warehouse Design

Vou usar um exemplo aqui de venda.

Qual é o fato que aconteceu? Uma venda

E aí isso já é a tabela fato? Pois é, a tabela fato se chama fato porque aconteceu um fato.

Depois, você vai seguindo de acordo com os números.

 

#1 – What – o quê / do quê?

Aqui você pode usar um template para completar e deixar mais fácil de entender a frase:

Template: Aconteceu _________. Do quê?

Vai ficar como?

Aconteceu uma venda. Do quê? De Coca-cola

Agile Data Warehouse Design

Aí já respondemos a primeira pergunta.

É só isso? É só isso.

Depois é só ir aplicando o mesmo estilo de template para todas as perguntas.

 

#2 When – quando?

Template: Aconteceu _________. Quando?

Aconteceu uma venda. Quando? 31/02/2017

Agile Data Warehouse Design

 

#3 Where – onde?

Template: Aconteceu _________. Onde?

Aconteceu uma venda. Onde? Na loja de São Paulo

Agile Data Warehouse Design

 

#4 Who – quem?

Nesse podemos ter várias interpretações. Você precisa entender o conceito e então ir colocando de acordo com o negócio em questão. “Quem” é a pessoa envolvida, e ela pode estar envolvida com o fato em papéis diferentes.
Alguns exemplos:

Template:
Aconteceu _________. Para quem?
Aconteceu _________. Quem fez?
Aconteceu _________. Quem entregou?

Para quem foi a venda? Pro Piton
Quem fez a venda? Vendedora Joana
Quem entregou? TNT Transportadora Mercúrio

Agile Data Warehouse Design

 

#5 How – como?

Template: Aconteceu _________. Como?

Aconteceu uma venda. Como? Através do site

Agile Data Warehouse Design

 

#6 Why – por quê?

Template: Aconteceu _________. Por quê?

Aconteceu uma venda. Por quê? Por causa de uma promoção de natal

Agile Data Warehouse Design

 

#7 How often – com que frequência?

Template: Aconteceu _________. Com que frequência?

Aconteceu uma venda. Com que frequência? 2x por mês

Agile Data Warehouse Design

Aqui a frequência é diferente da data, porque a data é quando cada uma das vendas aconteceu, e a frequência mostra o espaço de tempo entre elas.

Com a frequência, a gente consegue saber qual a periodicidade da carga, com que frequência vai precisar carregar os dados.

 

#8 How many – quanto / quantas vezes?

Aqui é onde você vai identificar as métricas.

Template: Aconteceu _________. Quantas Vezes?

Aconteceu uma venda. Quantas Vezes? 200 (vendas)

Agile Data Warehouse Design

Só com essas perguntas você já tem uns 80% do seu modelo dimensional pronto.

 

E os outros 20%?

Agora você precisa definir as dimensões e seus atributos.

Mas é muito simples fazer isso já tendo o mapa preenchido dessa forma. É diferente de quando você começa um projeto e vai pensando em dimensão por dimensão e perdendo um baita tempo em entrevistas.

Agora imagina que você já tem todas essas informações e os envolvidos do fato que aconteceu presentes.

Quando aconteceu uma venda, quem são os envolvidos na venda? O time de marketing, time de vendas, talvez o time financeiro também faça alguma parte.

Agora, sua missão é: depois que toda essa galera estiver reunida e entender o conceito desse mapa mental, cada um pode colocar o que entende disso para então chegar em um consenso.

 

Mas na prática como é?

Aqui você começa a fazer as perguntas para saber o que os Key User esperam de uma dimensão, por exemplo, de produtos (que você identificou lá na pergunta #1).

Você nem precisa falar em dimensão para não complicar a conversa.

Pergunta assim: Nessa primeira pergunta você respondeu “Coca-cola”, que é um produto. O que você gostaria de analisar do produto?

Você vai pegar informações como:

  • Coca-cola é o nome do produto
  • Você vai precisar também do código daquele produto para fazer algum relatório
  • Aí vem o cara lá do marketing e diz que eles precisam saber a marca desse produto
  • O cara da logística vai dizer que precisa saber qual o peso do produto para planejar o caminhão, para saber se tem espaço em armazenagem, e inclusive precisa ter a unidade de medida daquele produto
  • Depois vem o financeiro, que quer saber qual o preço unitário do produto

Agile Data Warehouse Design

Fazendo as perguntas certas fica fácil de entender o que o negócio precisa. É claro que você sabe que essa dimensão depois vai ter uma Surrogate Key e uma Natural Key, mas não é o momento de pensar nisso, por enquanto você está falando com o Key User, que é o cara de negócio, e essa é a abordagem mais simples e rápida possível.

 

Alertas: 2 coisas que podem estragar seu projeto

  1. Às vezes algum diretor ou gerente não vai poder estar na reunião ou participar do levantamento de requisitos e vai mandar alguém para representar ele. Esse diretor ou gerente que não foi é um Key User, e é muito importante que a pessoa que estiver no lugar dele tenha conhecimento o suficiente do negócio para responder essas perguntas. Se não, você vai acabar com informações capengas.
  2. Projeto de Data Warehouse não é projeto de TI. Projeto de Data Warehouse é projeto de negócio. Já to careca de ver projeto de Data Warehouse/BI em que a equipe fica socada junto com a TI dentro de um porão achando que é só pegar dados e jogar em um banco de dados. Cagada total.

Esse planejamento é extremamente importante. Empresas grandes e mais maduras já entendem o poder disso. Várias das empresas grandes pelas quais eu passei têm essa ideia de business first, então é sempre o negócio que está em foco, e não a TI. O importante agora não é saber se o cara já tem o dado coletado, se o banco aceita select ou se é MDX, isso é para outra hora.

Eu usei o mapa mental como exemplo porque é como eu gosto de usar, mas você precisa entender mesmo é a ideia para poder aplicar da forma que for melhor para você e o cliente.

Se entender a estratégia, vai poder aplicar ela da forma que for, porque é muito simples, basta seguir esse passo a passo e você vai conseguir entregar um Data Warehouse muito mais rápido e menos suscetível a falhas do que está acostumado.

 

Ah, e se quiser que eu te avise dos novos posts conforme eles forem saindo, é só deixar seu e-mail abaixo!

 

Deixe um comentário 🙂

Leia também:

mautic is open source marketing automation