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.

Siga nas redes sociais:

7 Passos Para Construir um Data Warehouse

Clique no botão abaixo e entenda Como Construir um Data Warehouse em 7 Passos

Autor:

Rafael Piton

Rafael Piton

Rafael é arquiteto de BI e Big Data. É criador do BI Academy e do BI Summit, autor do livro Data Warehouse Passo a Passo e fundador da Raizzer.

Leia mais:

Data Warehouse – Para Que Serve? Tá cansado de discutir com os planilheiros de plantão que nunca conseguem chegar em um acordo sobre quais relatórios que estão com os dados corretos? ...
Data Warehouse – Tipos de Métricas Tudo que a empresa for mensurar é uma métrica. Na maioria das vezes, a métrica vai ser o que o usuário quer medir. Pode ser também chamada de quantifi...
Data Warehouse – O Que É Star Schema? Star schema ou esquema estrela, idealizado por Ralph Kimball, é o modelo mais utilizado na modelagem dimensional para dar suporte à tomada de decisão ...
Compartilhe: