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 o 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 Warehousing.

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 a 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 Warehousing, 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.

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

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 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 mash, 
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 essas informações
dos sistemas transacionais.

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

ele vai aplicar todas as regras ali
que foram definidas e vai fazer

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

Então ele faz, ele move a API,

o engenho desce desse processo

e aí tem uma dor de qualidade de dados.

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

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

Então a gente tem essa esteira

com tantos profissionais.

É um super projeto e às vezes entra
sujeira e sai sujeira colorida.

Eu brinco com os alunos do outro lado
porque o dado de fato não entra

muito bem qualificado
e a gente nessa fase do ETL

tem muita dificuldade de fazer
o quality cleansing dos dados.

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.

Então a brinco ali no começo
é trabalho sujo, porque

é trabalhoso, mas é estratégico.

Essa fase de combinar, agregar,
calcular os dados

é como seguir, levá los ali para um nível
que de fato

eles respondam as perguntas
com assertividade.

Você como gestor, sabe, né Bruno?

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

o sistema e aí ele baixa aquilo no Excel,

dá uma ajustada, vai no fim.

Como eu brinquei
aqui no início do nosso papo,

as empresas não são da hora do Ivan,

elas tomam as decisões
e depois elas até enviesa uns dados

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

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

Mas é tudo isso.

Eu estou aqui 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 de projeto total.

O Quality não vou falar que é o principal,

acho que é o principal principal
sensor é o principal sensor,

porque é igual você comentou

a informação, ela 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 e São Paulo com só 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.

Ele identificar algumas coisas
que vêm da origem.

Você até consegue identificar, né?

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

não ali dado Abstraindo 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
qual a gente está usando.

Exemplo de banco
que tem mais de 90 sistemas transacionais

e nem tudo se conversa igual
eu comentei aqui,

há um sistema, ele 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 é o maior ofensor
dentro de um DW.

Bom ponta, um super desafio, não?

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

talvez seja esse o melhor nome
para construir.

Davis Você mencionou

é o Hex, porque tem um pouco de
como é que eu crio ali o meu storytelling,

como é que eu capto
as questões mais cognitivas, para onde

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

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

E de repente também, Bruno

um pouco de analytics ali,
no sentido mais estatístico mesmo.

Cabe ali uma correlação estatística,
uma estatística

mais descritiva, até até preditiva.

Dá para começar a fazer
algumas combinações de equipe piás?

Sim, e dá para explorar realmente.

Além da análise descritiva,

você pode, dependendo ali

da granularidade de dados,
se você consegue realmente 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
toda essa estrutura.

Ela tem que sair lá na frente em algo
que faça sentido para quem vai ler.

Então hoje o UX, a parte de Why

também está presente

nos profissionais
que trabalham com detalhes

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.

É você que me diz

por onde que você começaria,

que a gente falou de arquiteto,
de engenheiro, de analista de web,

que são muitos caminhos,
mas eu imagino que tem aí

um caminho mais fácil de entrar,

porque talvez a arquitetura
não seja arquitetura.

É uma visão mais holística, já tem que ter
alguma bagagem de carreira, não.

A dica é 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 com com dados
voltado para negócio.

Então aquele cara que faz o upstream,
então,

quando você senta do lado de um engenheiro

para você passar
todas aquelas regras e de ajudar

ele a criar uma arquitetura,
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.

Pessoas que tem o que não tem,
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, é um bom começo.

Aliás, a gente teve uma onda recente,
não é muito minha praia,

mas vou arriscar
falar aqui do dez full stack,

que é aquele profissional
back end front end de forma.

E eu tenho percebido,

não sei se você percebe
esse mesmo movimento no contexto de dados.

Agora a gente tem um Analytics Engineer

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

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

mas que se vira bem no desenvolvimento
ali na 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.

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,
a gente está falando ali no técnico,

olhando para o negócio.

Quais são as preocupações
na camada executiva E até as vezes,

quando a gente vai montar um teste,
a gente tem que

se perguntar se é mais tático,
se é mais executivo.

É importante porque o nível executivo

ele precisa ter 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.

A gente costuma 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 ele consiga tomar uma ação. Sim.

Em contrapartida, de repente,

o período histórico deva ser maior,
mais resumido, mais um período histórico

maior que se a gente vai falando
de um planejamento mais estratégico,

eu percebo que no tático, no operacional,
eu estou olhando muito ali

para minha esteira, para o meu dia a dia
e pensar no amanhã de repente.

E eu não quero pensar muito isso,
não quero que tenha uma quebra de stock.

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, 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, pode ser o caso também
para a gente diferenciar

um pouco o estratégico do tático.

Gente, papo super bom.

A gente começou aqui conceituando
o mundo de Business Intelligence.

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 para como tudo o que é bom
dura pouco.

Agora, para a gente fechar 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?

Eu a minha percepção que hoje eu

não só as pessoas que já já trabalham
com isso, mas estão entrando na área,

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

de como disponibilizar
o dado igual para você.

Está cena falou de data,
mexe de e várias outras ferramentas

voltadas para cloud Like House.

Detalhei que para entender

realmente para que universo você

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 e minerar,
esse dado é um caminho também.

É um caminho
não tão recente, mais recente.

Em relação
a toda essa estruturação de dados.

A gente está falando de Data Warehouse
e hoje a concepção do Data Warehouse.

O que a gente está falando aqui

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

Então é importante
quem está querendo entrar na área

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

não só além do Data Warehouse
e outras estruturas, mas estrutura

que você acaba fazendo um formato híbrido
com data warehouse.

E você pode entrar nesse

não num outro viés matemático estático
que trabalha essas informações

olhando para frente, criando predições,
criando prescrições.

Então é um mundo muito vasto,
muito vasto mesmo.

Então, quando foi estudar e 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 lag, house,
arquiteturas híbridas

já daí horas
para não dizer anos de estudo.

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

no nosso conteúdo.

Portanto, dizer pessoal
que às vezes nós falamos.

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

Agora, o ponto é o seguinte
as tecnologias, elas elas passam, mas

e às vezes eu até sinto a
tem muito cíclica de centraliza,

centraliza, vai de um, de um extremo
a outro, num contexto de agilidade.

Está tudo muito rápido.

A gente tem abarcado aí
muitas techs modernas.

Estão às vezes a estudar uma ferramenta.

Ano que vem já é outra.

Mas quando a gente fala de conceitos,

de tomada, de decisão, de planejamento,
isso é perene.

É contemporâneo ou não, Não passa.

Então, estudar, daí ter house no sentido
de pensar no negócio

e como eu trabalho
os meus pés para tomada de decisão,

é algo que te empodera
pra carreira e vale super a pena.

Você continuar investindo nesse assunto e.