DW, duas letrinhas poderosas cuja combinação

faz muita diferença no mundo dos dados.

Aliás, é justamente esse armazém de dados

que empoderam as organizações
no seu processo de tomada de decisão.

Muitas empresas primeiro 
tomam as suas decisões

para depois olhar para os dados
buscando ratificá-las.

Mas para ser data-driven de fato,
primeiro você olha para os dados,

e então depois você faz uma tomada
de decisão muito mais assertiva.

Eu sou a Tassiana, sou gestora 
na área de dados e analytics

em uma startup de Inteligência 
Artificial, a Tribo IA,

sou também professora
e coordenadora de MBA aqui na FIAP.

E é justamente para falar sobre 
tomada de decisão que eu estou aqui

com o meu querido Bruno Passos,

que já tem uma vasta 
experiência nesse mercado.

E eu queria que você se apresentasse
para o nosso aluno

e contasse quando que a tomada de decisão 
analítica entrou aí na sua carreira.

Eu trabalho com dados há mais de dez anos,

e é um grande prazer estar aqui 
com a professora Tassiana.

Já foi minha professora.

Eu acho que eu entrei como
a maioria das pessoas

acabaram entrando no mundo de dados,

que é como um projeto de DW na empresa.

Grudei ali com os especialistas.

Fazia parte de um time de negócio 
fazendo upstream, o entendimento,

uma parte também muito interessante 
de levantamento de requisitos,

e fui entrando numa parte mais técnica.

Hoje eu trabalho como squad líder
no Bradesco em inovação e Dados,

e estamos rompendo a barreira dos dados,
e vamos falar um pouco de DW.

Bacana, Bruno.

Essa combinação inovação e dados
é muito poderosa, né?

Como nós podemos...

Pensando aqui em criar um trilho

de entendimento para o nosso aluno,

como podemos definir 
esses dados analíticos?

Dados analíticos são dados 
que estão disponíveis

para serem explorados, analisados.

Eles vão responder questões de negócio,
questões estratégicas da empresa,

se bem explorados.

Tem toda uma arquitetura 
e um contexto por trás disso tudo,

mas o final dele é responder
questões da organização.

Bacana, bacana.

Em termos práticos, Bruno,
para o nosso aluno entender

que isso vai fazer a diferença
lá no contexto corporativo mesmo,

hoje, você ali na sua liderança, 
gestão, na sua atuação com dados,

em que momento você precisa ir lá
e acionar a sua ferramenta,

a sua plataforma de análise de dados?

Hoje nós utilizamos o dado

para facilitar a vida 
do nosso time comercial.

Então nós utilizamos esse dado analítico

de uma maneira bem granular 
para fazer predições

e realmente melhorar a vida do comercial,

fazendo com que ele 
visite uma loja correta,

que ele tenha um índice
de assertividade no dia a dia dele.

Então nós fazemos predições,
modelos estatísticos,

para poder melhorar a vida do comercial.

Bruno, nós temos hoje uma série 
de tecnologias, ferramentas, enfim,

mas me parece que o DW
é o coração de tudo isso, né?

Como ele funciona?

Vamos começar a mostrar ali 
para o nosso aluno

quais seriam os caminhos.

Vou construir um Data Warehousing,

preciso ter uma equipe 
técnica por trás disso?

Como eu me organizo 
num projeto desse tipo?

O DW, é importante sempre explorar.

Antes de você sair fazendo 
a construção, para que ele vai servir,

que respostas você precisa 
obter através dos dados,

quais são as especificidades de cada
departamento, e como você vai utilizar.

Claro que você precisa 
de uma equipe de negócio

para auxiliar em toda essa 
estrutura do Data Warehouse.

Para você conseguir transformar 
os dados, colocar regras de negócio,

você precisa de pessoas 
com um viés um pouco mais técnico

para fazer a ingestão dessas informações.

E sempre tem aquelas pessoas 
que têm mais habilidade do UX,

de prototipar, de montar 
relatórios, dashboards.

Então é um caminho de construção
em relação ao profissional

que tem oportunidade para todos

Legal falarmos para o nosso 
aluno então, né, Bruno,

que o DW é um conceito
que apoia a tomada de decisão.

Em termos práticos, quando pensamos 
um Data Warehouse, o que temos ali dentro

são KPIs de dimensões, não mais que isso.

E isso vai ser sempre superimportante
dentro das empresas.

Mas aí tem toda a questão 
do ferramental, do trilho de construção,

do perfil profissional e tudo mais, 
para materializar isso.

Mas não é uma ferramenta, né?

Não dá para dizer que é 
simplesmente uma ferramenta, né?

E aí tem uma questão aqui de definição,
só para não deixar o nosso aluno confuso

quando ele se deparar com as buzzwords,
e os termos e tudo mais.

Se eu coloco lá o "ing" no termo, 
muda alguma coisa?

Apesar do nome ser praticamente 
igual às definições,

e se você ler literalmente 
é igual, mas é diferente.

O Data Warehousing tem uma amplitude maior

porque é a concepção lá desde o início,

trazer os dados lá do transacional,

daqueles sistemas de origem, 
do sistema financeiro,

se for um supermercado,
o sistema que passa lá do caixa,

e engloba até o processo da confecção
de um dashboard, de um relatório.

Então vamos dizer que o Data 
Warehouse sem o ing no final

é um subconjunto dentro desse processo.

Ele é um ambiente dentro 
de um banco de dados

onde armazena essas 
informações de negócio.

Então é um subconjunto
de todo esse processo.

Bacana.

E com o ing, aí é a esteira inteira, né?

A esteira inteira.

Perfeito.

Se não prestarmos atenção,
nós confundimos, né,

e de repente acha 
que um é sinônimo do outro.

Se não falar o ing no final, 
no ouvido do brasileiro passa batido.

Boa!

Se você fosse hoje, Bruno, montar 
uma squad para compor um DW...

Muitas organizações já tem 
o seu Data Warehouse.

Temos feito o BI...

Nasceu há boas décadas atrás.

Então, quando você pega, por exemplo,
o Bradesco, uma grande financeira,

necessariamente eles já têm 
uma estrutura de tomada de decisão.

De repente, se estivermos 
falando ali de uma startup,

aí sim é uma empresa que está começando
a fazer os seus registros transacionais

e a compor a sua base analítica.

Então vamos pensar num cenário mais novo.

Se você estivesse ali na liderança
de uma squad, quem você traria?

Qual é o perfil profissional
para atuar, na criação mesmo,

de uma solução de Data Warehouse?

Para mim, sempre existe a necessidade

de antes de você realmente conceber
e prototipar toda a arquitetura,

entender com os responsáveis,
com a gestão mais executiva,

o que a empresa busca através dos dados,

para definirmos então que tipo de arquitetura.

Se vamos partir para um DW,

ou se a empresa vai fazer 
um investimento numa cloud,

se vamos para um lake, se está 
interessado em minerar dados.

Agora, se for realmente um Data Warehouse,

com certeza muitas pessoas de negócio,

um profissional de ingestão de dados,

um profissional de negócio 
para fazer todo o upstream,

o levantamento de requisitos, né?

E é importante ter um profissional
para fazer toda essa parte

de montar a ingestão dessa informação,

aquelas três letrinhas lá, de extração,
transformação, e a carga de tudo isso.

Então eu traria esses três tipos de perfis:
uma pessoa relacionada ao negócio,

uma pessoa que trabalha
com ingestão de dados,

para fazer toda essa parte 
de arquitetura, das três letrinhas,

que poderemos passar depois por elas,

e alguém que tem habilidades de fazer
a confecção de um dashboard,

de construir relatórios, fazer estudos.

Bacana.

Então, no warehousing, nós 
temos levantamento de requisitos

para responder as dores de negócio.

Na modelagem, falando techniquêz, 
nós chamamos de levantar os fatos,

o que se quer saber, não é isso?

E aí tem uma conexão muito 
grande com o negócio.

Em paralelo a isso, 
de repente um arquiteto...

Hoje nós temos uma série de arquiteturas,

Lambda, Kappa, tudo para tomada de decisão,

malhas de dados, data mesh, 
data product, enfim.

Ai talvez seja um papo
para um outro vídeo.

Mas sem dúvida, 
um arquiteto ali para para olhar.

Você falou do...

Só recapitulando para o nosso aluno, né?

Você falou do ETL, que é 
uma parte dolorida, né, Bruno?

Porque tem...

É...

Limpeza, tratamento dos dados...

Não é isso?

É, é o trabalho sujo, né?

Eu estou brincando, 
não é o trabalho sujo.

Na verdade é uma profissão bem legal,

um engenheiro de dados ali, que vai 
fazer toda essa parte de ingestão.

Ele vai capturar as informações
dos sistemas transacionais.

E aí, com a ajuda dessas 
pessoas de negócio,

ele vai aplicar todas as regras
que foram definidas

e vai fazer o carregamento dessas informações
para dentro desse Data Warehouse.

Então ele move o engenho desse processo.

E aí tem uma dor de qualidade de dados.

Tem uma estatística
que diz que menos de 10%

das bases de dados são, de fato,
consideradas qualificadas hoje.

Então nós temos essa esteira
com tantos profissionais...

É um superprojeto, e às vezes entra
sujeira, e sai sujeira colorida.

Eu brinco com os alunos do outro lado,

porque o dado não entra, 
de fato, muito bem qualificado,

e nessa fase do ETL, nós temos muita dificuldade

de fazer o quality, o cleansing dos dados, né

Qualidade de dados hoje já 
não é mais uma dor técnica.

É uma dor de negócio.

Porque se eu não consigo resolver, eu não
respondo às minhas perguntas de negócio.

Você brincou ali no começo, que é 
trabalho sujo porque é trabalhoso,

mas é estratégico,

essa fase de combinar, 
agregar, calcular os dados

e conseguir levá-los 
para um nível que eles, de fato,

respondam as perguntas
com assertividade.

Você, como gestor, sabe, né, Bruno?

Se o meu DW não for bem preparado,
o gestor começa a burlar o sistema,

e aí ele baixa aquilo no Excel,

dá uma ajustada, vai no feeling,

como eu brinquei
aqui no início do nosso papo.

As empresas não são data-driven, né?

Elas tomam as decisões
e depois até enviesam os dados

que é para dizer que tomou a decisão 
certa, quando deveria ser o contrário.

Eu faço aquilo que o dado 
me direciona a fazer.

Mas que tudo isso está
nessa fase do ETL,

que parece tão técnico, mas 
que tem essa questão de qualidade

que precisa ser pensada ali,
inclusive pela gestão do projeto, né?

Total.

Eu não vou falar que o quality é o principal.

Eu acho que é o principal ofensor 
sim, é o principal ofensor.

Porque é igual o que você comentou.

A informação vem com um nível 
de tratamento mínimo

e você pode organizar essas 
informações e tratar um campo nulo,

de repente transformar ali
as cinco variáveis de São Paulo,

São Paulo com "S", São Paulo só com o "SP",
e tratar essas informações.

Mas, por muitas vezes,
você não consegue identificar

se existe um padrão errado
de informação lá dentro.

Por exemplo, eu posso 
dizer que numa coluna

deve vir uma descrição de 20 caracteres.

E ali é uma é uma coluna para ver
o modelo de um veículo,

mas de repente vem o nome de uma cidade.

É muito difícil o quality identificar 
algumas coisas que vêm da origem.

Você até consegue identificar, né?

Então é um trabalho que realmente, 
na concepção do upstream ,

toda a parte ali 
da montagem da arquitetura,

tem que se pensar
nessas questões de quality

para começar realmente a transformar 
isso num dado de qualidade.

É muito difícil 100% 
das informações estarem...

Estamos usando um exemplo de banco,

que tem mais de 90 sistemas 
transacionais, e nem tudo se conversa...

Igual eu comentei aqui,

um sistema coloca a cidade

de um jeito e um outro sistema de outro.

Você consegue fazer essas correções.

Mas se existe um problema 
na articulação dos dados,

um campo texto aonde alguém 
pode errar alguma coisa,

é bastante sensível,
é bem complicado.

Eu acho que esse é o maior 
ofensor dentro de um DW.

Bom ponto, é um super desafio, né?

E aí você falou que depois da camada
de consumo tem ali um analista de BI,

talvez seja esse o melhor nome,
para construir DataViz.

Você mencionou UX, porque tem um pouco 
de como eu crio ali o meu storytelling,

como eu capto as questões 
mais cognitivas, né,

para onde as pessoas olham,

o que chama a atenção,
o uso de cores e tudo mais.

Isso é superimportante, é digno 
de uma disciplina inteira, né?

E de repente, Bruno, também
um pouco de analytics ali,

no sentido mais estatístico mesmo.

Cabe ali uma correlação estatística,

uma estatística mais 
descritiva, até preditiva, né?

Dá para começar a fazer
algumas combinações de KPIs, né?

Sim, e dá para explorar realmente.

Além da análise descritiva,

dependendo da granularidade de dados,

você realmente consegue 
fazer algum tipo de predição,

começar a trabalhar um dashboard 
com uma análise diagnóstica,

criar correlação, fazer algumas análises 
e estudos de churn, por exemplo.

Legal.

E em cima do UX, é muito importante, né?

Toda essa estrutura 
tem que sair lá na frente

em algo que faça sentido 
para quem vai ler.

Então o UX hoje, a parte de UI também,

estão presentes nos profissionais
que trabalham com DataViz

para achar a melhor maneira
de divulgar essa informação

para melhorar a leitura 
de quem vai consumir o dado.

E se você estivesse começando 
a sua carreira agora,

querendo entrar no clubinho dos dados...

Não sei se é um clube fechado ou não.

Aí é você que me diz, tá?

Por onde que você começaria?

Porque falamos de arquiteto, 
de engenheiro, de analista, de UX.

Muitos caminhos, né?

Mas eu imagino que tem aí
um caminho mais fácil de entrar.

Porque talvez a arquitetura não seja, né?

A arquitetura é uma visão mais holística,

Já tem que ter alguma bagagem de carreira.

Dê uma dica aí para o nosso aluno começar.

Eu vou dar uma dica prática,

que, na verdade, é 
a minha própria experiência,

que foi trabalhando com dados
voltado para negócio,

aquele cara que faz o upstream.

Então, quando você se senta 
ao lado de um engenheiro

para você passar todas aquelas regras 
e ajudá-lo a criar uma arquitetura,

porque ele não cria sozinho,

ele precisa da sua ajuda
para definir os melhores caminhos.

você começa a ter visão 
desses dois processos,

um processo mais técnico
e um processo de negócio,

que é o que realmente 
falta no mercado, né,

pessoas que não têm
só um viés técnico,

que é excelente quando uma pessoa 
executa a parte técnica,

mas se ela tem o feeling
de negócio, ela consegue

entrar em caminhos e tomar 
decisões bem interessantes.

Então eu começaria como eu
comecei, com a parte de negócio

na construção de um Data Warehouse.

Boa dica, né, é um bom começo.

Aliás, tivemos uma onda recente...

Não é muito a minha praia, mas eu vou 
arriscar falar aqui do "dev full stack"...

Que é aquele profissional
back-end, front-end...

Full, né?

E eu tenho percebido,
e não sei se você percebe,

esse mesmo movimento no contexto de dados.

Agora nós temos um analytics engineer,

que me parece que é essa fusão
desse profissional de análise de dados,

que entende de Python,
que entende também de SQL,

mas que se vira bem 
no desenvolvimento, se precisar,

para além da análise e da consulta
interativa dos dados.

Se precisar montar uma esteira, fazer 
efetivamente a engenharia, ele consegue.

Ele consegue estar nos dois momentos,
na engenharia e na análise dos dados.

Talvez seja uma uma tendência
para o nosso aluno olhar também.

E na camada executiva?

Estamos falando ali no técnico,
olhando para o negócio,

quais são as preocupações
na camada executiva?

Às vezes até quando vamos montar um dash,

temos que nos perguntar se é 
mais tático, se é mais executivo.

É importante porque o nível executivo 
tem algumas necessidades.

Diferente de dashboards voltados 
para o operacional, para o tático,

ele precisa de respostas 
num período curto

de tempo de execução
dessas informações,

e de indicadores estratégicos onde 
ele possa tomar uma decisão rápida

sem precisar fazer grandes leituras.

Costumamos falar que tem que ter
um storytelling, todo um contexto.

Tem que ter também 
para a camada executiva,

mas uma coisa muito mais enxuta,

onde ele bata o olho
e consiga tomar uma ação.

Sim, sim.

Em contrapartida, de repente,
o período histórico deva ser maior,

mais resumido, mas um período histórico maior,

se estivermos falando
de um planejamento mais estratégico, né?

Eu percebo que, no tático, no operacional,

eu estou olhando muito para a minha 
esteira ali, para o meu dia a dia,

é pensar no amanhã, de repente é um...

- Eu não quero que tenha uma...
- Um monitoramento, né?

Isso. Eu não quero que tenha 
uma quebra de estoque,

então eu estou olhando para as minhas 
compras da semana que vem.

E é isso.

Agora, quando eu estou 
falando da camada executiva,

de repente é o meu planejamento anual,

ou eu estou norteando os próximos 
anos ali da minha organização,

e aí eu tenho que, de repente, olhar
para um período histórico um pouco maior.

Pode ser o caso também para diferenciarmos 
um pouco o estratégico do tático.

Gente, papo superbom.

Começamos aqui conceituando
o mundo de Business Intelligence.

O Bruno trouxe aspectos de negócio.

Aliás, a dica do Bruno 
foi começar por negócio

e depois abarcar ali a parte técnica.

E agora, como tudo 
o que é bom dura pouco,

para fecharmos aqui
a nossa conversa, dicas, dicas.

Tem alguma dica preciosa de estudo, 
de caminhos, para o nosso aluno

que está entrando nesse
mundo da tomada de decisão?

A minha percepção, não só para as pessoas 
que já já trabalham com isso,

mas que estão entrando na área,

é começar a olhar a tipos de arquiteturas
e de propostas diferentes

de como disponibilizar o dado, 
igual a professora Tassiama falou,

de Data Mesh, de várias outras ferramentas

voltadas para cloud, lakehouse, data lake,

para realmente saber 
que universo você quer ir,

se é um universo também
de mineração de dados.

Se você tem um viés mais 
matemático, estatístico,

e gosta de explorar, minerar
esse dado, também é um caminho.

É um caminho não tão recente, mas recente

em relação à toda essa 
estruturação de dados,

porque estamos falando de Data Warehouse.

E hoje, a concepção do Data Warehouse,
o que estamos falando aqui,

das profissões e dos métodos
de como criar toda arquitetura,

é importante para quem está 
querendo entrar na área

enxergar o cenário como um todo,
porque existem várias possibilidades,

além do Data Warehouse, né, 
outras estruturas,

mas estruturas que você acaba fazendo 
um formato híbrido com Data Warehouse.

E você pode entrar num outro viés,

matemático, estático,

que trabalha essas informações 
olhando para frente,

criando predições,
criando prescrições.

É um mundo muito vasto,
muito vasto mesmo.

Então, quando for estudar, olha 
no todo em relação ao dado

para você enxergar onde 
você se encaixa melhor.

Fantástico, Bruno.

Gente, só esses últimos 
termos que ele usou...

Ele falou de product, lake house,
arquiteturas híbridas...

Já dá horas aí,
para não dizer anos, de estudo.

Então dicas boas para vocês
se aprofundarem ainda mais aqui

no nosso conteúdo.

É importante dizer, pessoal,
que às vezes nós falamos DW,

e isso soa como algo antigo, porque,
de fato, nós fazemos isso há muito tempo.

Agora, é o seguinte: 
as tecnologias passam, né,

e às vezes eu até sinto 
a TI muito cíclica.

Descentraliza, centraliza, 
vai de um extremo a outro,

num contexto de agilidade.

Está tudo muito rápido.

Temos abarcado aí
muitas techs modernas.

Estão às vezes você estuda uma ferramenta,

ano que vem já é outra.

Mas quando falamos de conceitos,

de tomada de decisão, 
de planejamento,

isso é perene, é contemporâneo, não passa.

Então, estudar Data Warehouse 
no sentido de pensar no negócio

e como eu trabalho os meus KPIs 
para tomada de decisão,

é algo que te empodera para a carreira,

e vale super a pena você continuar 
investindo nesse assunto.