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á trabalham com isso,
mas que estão entrando na área,
é começar a olhar tipos de arquiteturas e de propostas diferentes
de como disponibilizar o dado, igual a professora Tassiana falou,
de data mesh, de várias outras ferramentas
voltadas para cloud, lakehouse, data lake,
para realmente saber qual 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 data 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 stacks 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.