Data Driven
Ser uma empresa orientada a dados é o que todas as organizações precisam e estão perseguindo cada vez mais.
Ser uma empresa orientada a dados é o que todas as organizações precisam e estão perseguindo cada vez mais.
Os executivos dos níveis estratégicos, táticos e operacionais e os analistas de informação e profissionais em geral querem:
Poder fazer qualquer pergunta sobre os dados do negócio que já aconteceram (análise descritiva);
Obter previsões do que deve acontecer com o negócio (análise preditiva), e
Obter explicações sobre o peso dos fatores que justificam as previsões para terem insights sobre o que precisa ser feito (análise prescritiva).
Todo esse esforço para gerar insights que orientem a descoberta de importantes forças, fraquezas, oportunidades e ameaças é para a rápida elaboração de planos de ação para poder aproveitar a situação ou se defender dela.
Não é possível dizer que uma organização, privada ou pública, é completamente “não data driven” ou totalmente “data driven”. Nem tampouco se pode ir de um estágio “não data driven” para “data driven” de um salto só.
Na verdade, esse é um processo contínuo e iterativo como num ciclo PDCA onde a cada giro executado com sucesso se pode dizer que estamos caminhando para uma posição mais data driven do que antes.
A realidade dos dados nas organizações atualmente apresenta algumas barreiras para que o movimento data driven possa ocorrer com suavidade. Vamos ver:
Esta fase normalmente é composta por um esforço misto entre área de TI, analistas das áreas finalistas (de custo, de orçamento, de marketing, financeiro, fiscal, de materiais, de produção, etc) e usuários finais de negócio.
Isso é um problema porque as transformações aplicadas sobre os dados para fazer limpeza, cálculos de indicadores, adaptações estruturais e criações de novas informações, acabam ficando espalhadas em vários lugares. A área de TI desenvolve scripts em SQL e gera bancos de dados, o que deveria ser o padrão.
Contudo, muitas planilhas eletrônicas ainda são geradas nas extrações de dados, ao invés de bancos de dados. Quando é assim, os usuários acabam criando novas colunas e aplicando novas regras de transformação nas planilhas por meio de fórmulas e macros.
Quando as planilhas são então usadas como fontes de dados nas ferramentas de visualização como Qlik, PowerBI ou Tableau, é comum a criação de novas transformações sobre os dados ou pela área de TI ou pelos próprios usuários de negócio.
A consequência desta forma de trabalhar é a dificuldade em se obter uma única versão da verdade. Torna-se muto comum que uma pergunta simples como “qual o faturamento do mês passado?” produza respostas com números diferentes trazidos por setores diferentes.
Outro ponto crucial que dificulta o caminho data driven de uma organização é o vocabulário limitado dos usuários quanto ao conhecimento de gráficos e o que eles estão comunicando. Desde a graduação, passando por cursos de especialização e MBA, normalmente trabalhamos com o famoso trio de gráficos Barra, Pizza e Linha. Fora disso, só a já tradicional Tabela ou Tabela Dinâmica.
Conhecendo apenas esses tipos de gráfico, perdemos uma gama bastante vasta de possibilidades de ler informação e relacionar coisas que estão presentes em um monte de outros tipos de gráfico, tais como Dispersão, Radar, Árvore, Cascata, Caixa, Treliça, Mekko, Nuvem de Palavras, Mapas Multicamadas, Acordes, Combinados, entre outros muitos que podem ser customizados.
O primeiro desafio aqui é o usuário conseguir ler o gráfico e entender que informações ele está comunicando. O segundo desafio é o próprio usuário montar aquele novo tipo de gráfico para expor suas descobertas. O desafio final é o usuário argumentar em favor de suas ideias usando o gráfico de forma dinâmica durante uma reunião. É bem similar ao aprendizado de uma língua estrangeira, onde é comum passar pelos níveis de leitura, escrita, fala básica e chegar na fala fluente. Sabemos que estamos fluentes naquela língua quando conseguimos participar de uma argumentação com várias pessoas.
A inspiração dos usuários de negócio é a planilha eletrônica. Ela foi a grande responsável pela introdução do microcomputador nas empresas e está presente há muitas décadas nas organizações. O modelo mental da planilha é o de primeiro conseguir todos os dados que eu preciso e carregar na planilha.
Feito isso, posso começar a filtrar, ordenar, transformar, calcular e ver dados de diversas formas, inclusive em gráficos diversos. Na hora de mostrar as análises e descobertas, montam-se slides para serem apresentados nas reuniões executivas. Este é o modelo utilizado há muito tempo.
Quando os usuários então conhecem uma ferramenta de Analytics moderna, como Qlik, PowerBI ou Tableau, a tendência é replicarem essa forma de trabalhar com a qual já estão acostumados. Isso significa que sempre partem de um conjunto de dados limitado que é extraído para se estudar um cenário específico.
Sobre esses dados limitados, são construídos então painéis de análise nas ferramentas de Analytics que imitam os slides antes utilizados. São painéis estáticos, com poucas possibilidades de filtros e que apresentam gráficos com os eixos X e Y pré-definidos e sem a possibilidade de troca (e.g. gráfico de barras mostrando as Vendas por Linha de Produto).
Quando os painéis estão sendo mostrados nas reuniões de gestão, sempre aparece aquela pergunta imprevista que fica sem resposta. A resposta é “Ops, esse dado nós não pensamos em trazer para esse cenário!”. A resposta fica então para a próxima reunião quando, muitas vezes, ninguém se lembra mais do que se tratava.
Fazer qualquer pergunta imprevista e obter respostas instantâneas é um dos principais indutores do data driven numa organização.
Por isso, a dinâmica utilizada atualmente não atende a este requisito.
Os usuários de negócio estão acostumados a correr atrás dos dados navegando pelos painéis de análise em busca de informações. São poucos que também conseguem receber algum feedback automático do ambiente de Analytics.
O ideal seria que o usuário pudesse, por exemplo, espalhar sensores pelos dados e receber alertas pelo celular todas as vezes que um dado sofresse uma modificação importante (e.g. avise-me sempre que a margem bruta da linha de produtos naturais na região Sul baixar de 10%).
Além dos sensores sobre os dados, também seria bom receber relatórios regulares via e-mail (e.g. envie-me o relatório de metas de vendas toda segunda, quarta e sexta às 9h da manhã). Imagine então se fosse possível receber predições sobre o comportamento futuro dos dados e explicações sobre essas predições também de forma automática (e.g. envie-me toda segunda-feira às 10h da manhã a lista de clientes que tem probabilidade de deixar a empresa e a lista dos principais fatores que contribuem para saírem).
Qual a solução da Toccato para mudar essa realidade?
Criamos um framework completo para levar a organização em direção a ser cada vez mais data driven em ciclos iterativos.
Primeiro, estabelecemos o nosso Manifesto Data Driven com os princípios base que devem nortear todos os esforços data driven na organização.
Única versão da verdade: centralização e padronização das transformações nos dados e reutilização dos resultados destas transformações em vários temas de análise diferentes para produzir uma única versão da verdade;
Acesso self-service: é fundamental que o próprio usuário de negócio tenha autonomia para acessar os dados e fazer suas análises, inclusive responder a qualquer pergunta, sem a necessidade de ter o apoio do time de TI;
Simplicidade de uso: para ser self-service precisa ser simples e intuitivo fazer as perguntas necessárias para obter os insights. Tem que ser algo que seja aprendido de forma básica em poucos minutos pela naturalidade da interface com o usuário;
Qualquer pergunta: aqui temos o ponto central para a produção de insights que sejam operados por seres humanos. A curiosidade humana, temperada com a experiência e a vivência, levam usuários de negócio a navegarem nos dados por meio de perguntas sucessivas até descobrirem o que estão procurando. Essa sucessão de perguntas precisa ser garantida sem interrupções.
Entrega contínua: o projeto promovido pelo ciclo data driven é estruturado e a sua rodada iterativa aproxima cada vez mais a organização de uma situação mais data driven. Por isso, a cada nova rodada do ciclo, que pode durar de 2 a 4 semanas, um Pilar de Dados é entregue pronto para ser explorado por qualquer pergunta feita pelos usuários de negócio. Isso evita aqueles projetos muito longos do passado onde investiam-se meses em modelagem e estruturação para se ter algo para navegar.
Governança de dados: todos já imaginam que governança de dados significa o controle de quem pode ver o que, assim como a proteção a dados sensíveis que não podem ser divulgados como são e, por isso, precisam de uma desidentificação. A inovação aqui está numa curadoria de dados que preocupa-se com a reputação e credibilidade dos dados. Por isso, também acrescentamos aqui o controle rígido da Não-Conformidades identificadas nos dados, juntamente com suas explicações e planos de ação para solução. Também controlamos o ROI (retorno do investimento) que foi gerado pelos dados.
Alfabetização em dados: os usuários de negócio são o alvo de todos os esforços data driven e, assim, precisam estar completamente capacitados a falar a linguagem dos dados. Isso significa que precisam ser avaliados em suas competências quanto a isso e receberem o conhecimento necessário para o preenchimento de lacunas eventualmente existentes.
Como dissemos anteriormente, o processo para uma organização ser cada vez mais data driven é contínuo e iterativo, como num ciclo no estilo PDCA. Apresentamos então o nosso ciclo Data Driven:
A primeira etapa do ciclo é o Aprenda. Aqui fazemos o assessment (avaliação por meio de prova eletrônica pela internet) dos conhecimentos de todos os usuários de negócio da organização em relação aos seguintes itens:
Entendendo Gráficos: sabemos que o vocabulário dos usuários de negócio normalmente está limitado ao conhecimento dos gráficos de barra, pizza, linha e a famosa tabela com linhas e colunas. Conhecendo apenas esses tipos de gráfico, os usuários perdem uma gama bastante vasta de possibilidades de ler informação e relacionar coisas que estão presentes em um monte de outros tipos de gráfico, tais como Dispersão, Radar, Árvore, Cascata, Caixa, Treliça, Mekko, Nuvem de Palavras, Mapas Multicamadas, Acordes, Combinados, entre outros muitos que podem ser customizados. Então aqui vamos avaliar qual a amplitude deste conhecimento e, conforme for a pontuação do usuário, recomendaremos que adquira essa competência fazendo o nosso treinamento de Alfabetização em Dados – Módulo Entendendo Gráficos.
Fazendo Qualquer Pergunta: também sabemos que os usuários de negócio estão mais acostumados com painéis de análise onde os gráficos e indicadores mostrados estão pré-formatados para responder à perguntas limitadas a um determinado cenário. Chamamos isso de análise guiada. Contudo, o que queremos proporcionar com o nosso framework é que o usuário tenha uma experiência completamente ad-hoc, ou seja, que possa fazer perguntas imprevistas sobre os dados e obter respostas instantâneas. A questão é: será que os usuários sabem fazer isso? Parece estranha esta pergunta, mas temos observado que, por não terem esse hábito, diante de um painel do tipo “Qualquer Pergunta”, os usuários acabam ficando sem saber o que fazer com tanta liberdade de navegar e explorar os dados. Isso limita sua capacidade de produzir insights apesar de terem à sua disposição esse poder. Uma vez identificada esta lacuna por meio da avaliação, recomendamos a realização do nosso treinamento Alfabetização em Dados – Módulo Qualquer Pergunta.
Construindo Painéis: aqui vamos avaliar a habilidade do usuário de negócio em ter diante de si uma tela branca e ali construir seu próprio painel de análise conforme sua necessidade de exploração de dados. Não se trata de ter conhecimento de uma ferramenta de visualização específica, mas sim de saber quais gráficos, tabelas e mostradores combinam melhor juntos para a produção de insights. Sabemos que o processo de exploração e descoberta de dados é algo que funciona muito melhor quando combinamos várias visões de dados na mesma tela e conseguimos observar como todas as outras visões reagem no momento em que aplicamos algum filtro a uma determinada visão. Caso o conhecimento do usuário não seja suficiente neste assunto, recomendamos então a realização do nosso treinamento Alfabetização em Dados – Módulo Construindo Painéis.
Entendendo Estatística: o objetivo desta avaliação não é encontrar estatísticos avançados entre os usuários de negócio, mas sim avaliar o nível de conhecimento básico que possuem nos conceitos de estatística mais utilizados em análises de negócio e que podem ser facilmente entendidos e utilizados na prática por pessoas comuns que não precisam necessariamente ser cientistas de dados. Caso sejam identificadas lacunas nesta área, recomendamos a realização do nosso curso Alfabetização em Dados – Módulo Entendendo Estatística.
Entendendo Pilares de Dados: nesta avaliação vamos identificar o que os usuários conhecem sobre o elemento básico de estrutura de dados que vai sustentar todo o nosso processo data driven: o Pilar de Dados. Mais adiante vamos explicar em detalhes, na fase Modele do nosso ciclo data driven, o que é um Pilar de Dados. Por enquanto, vamos imaginar que é uma estrutura concentradora de dados que funciona como um pilar de um edifício, sustentando todo o resto do prédio. Ao identificar que não há esse conhecimento entre os usuários de negócio, recomendamos então a realização do nosso treinamento Alfabetização em Dados – Módulo Entendendo Pilares de Dados.
A segunda fase é o Modele. Aqui vamos identificar e construir os Pilares de Dados da organização e descobrir como eles relacionam-se entre si. Mas afinal, o que é um Pilar de Dados.
Assim como os pilares de um prédio sustentam toda a construção que pode ter dezenas de andares para cima, os Pilares de Dados são estruturas de dados, facilmente identificáveis na área de negócio, e que sustentam todos os esforços de data driven de uma organização.
Na construção civil, um pilar é construindo pela mistura de cimento, areia e brita montados num esqueleto de aço.
Já no universo de dados de uma organização, um Pilar de Dados é composto pela identificação de um Documento que existe no mundo real na vida daquela organização. São exemplos de documentos Pilares de Dados:
Pedido Venda
Nota Fiscal Venda
Título a Receber
Recebimento de Título
Inventário Estoque
Ordem de Produção
Apontamento Produção
Conhecimento de Transporte
Lead
Conta
Oportunidade
Proposta
Contrato
Contra-Cheque ou Hilerite, …150+
Sempre que algo de importante acontece em uma organização, existe um Documento (digital ou em papel) para registrar esse fato. A vantagem do Pilar de Dados ser um documento é que tanto a área de negócio como a de TI conseguem conversar sobre algo que ambos entendem, tornando assim o mapeamento dos Pilares de Dados muito mais fácil.
A composição de um Pilar de Dados não é a mistura de cimento, areia e brita num esqueleto de aço. O Pilar de Dados é constituído pela espinha dorsal de qualquer documento que são o seu Cabeçalho (com as informações gerais de Quando, Onde, Quem, Porque e Como) e os seus Itens (com as informações gerais de O que e Quanto). Similar ao que encontramos em uma Nota Fiscal.
Veja que sem os dados estarem organizados em um Pilar de Dados, o que temos são campos como datas, descrições, nomes, tipos, valores, quantidades, percentuais e etc. desorganizados e espalhados. Fica difícil extrair informações dessa confusão.
A composição de um Pilar de Dados não é a mistura de cimento, areia e brita num esqueleto de aço. O Pilar de Dados é constituído pela espinha dorsal de qualquer documento que são o seu Cabeçalho (com as informações gerais de Quando, Onde, Quem, Porque e Como) e os seus Itens (com as informações gerais de O que e Quanto). Similar ao que encontramos em uma Nota Fiscal.
Mas quando pegamos esses mesmos dados e os organizamos em Pilares de Dados, reconhecendo que eles são agrupados naturalmente em documentos que existem no mundo real, então temos uma visão muito melhor das coisas.
Rodamos um Ciclo Data Driven completo para cada um dos Pilares de Dados identificados. Essa rodada ou sprint (ciclo de esforço) pode ter a duração de 2 a 4 semanas a depender da complexidade estrutural do Pilar de Dados que está sendo mapeado e tendo seus dados extraídos, limpos, transformados e carregados. Outro fator importante que influencia nesta duração é o nível de conhecimento que a organização tem sobre as tabelas de banco de dados que compõem o Pilar de Dados e seus relacionamentos nos sistemas de gestão ou ERPs da empresa.
Outro ponto importante ao observar os Pilares de Dados é ver como eles se relacionam por meio de dados que possuem em comum. Se considerarmos, por exemplo, o dado Cliente. Temos Cliente no documento Pedido Venda, mas também na Nota Fiscal e ainda no Título a Receber. Então, por Cliente, podemos cruzar as Medidas (valores, quantidades, percentuais) existentes nestes três documentos e responder a perguntas como:
Mostre-me o Valor Pedido, Valor Nota e o Valor a Receber por Cliente?
Mostre-me o % Atendido do Pedido (Valor Pedido / Valor Nota) e o % A Receber da Nota (Valor a Receber / Valor Nota) por Cliente?
Veja que cada uma destas Medidas (destacadas na cor verde) está em um Documento diferente. Contudo, podemos vê-las juntas combinando-as pela Dimensão (destacada na cor azul) Cliente. Veja que podemos até criar novos Indicadores (destacados na cor vermelha) a partir das Dimensões e Medidas cruzadas de Documentos diferentes.
O mesmo podemos fazer olhando o dado Produto que aparece nos documentos Pedido Venda, Nota Fiscal e Inventário de Estoque. Também aplicamos o mesmo raciocínio com o dado Cidade que está nos documentos Pedido Venda, Nota Fiscal, Título a Receber e Inventário de Estoque.
Este cruzamento ilimitado de Dimensões e Medidas, mesmo estando em Documentos diferentes, nos dá o poder que precisamos para fazer qualquer pergunta imprevista e obtermos respostas instantâneas.
À medida que vamos mapeando e construindo os Pilares de Dados da organização, eles acabam virando, à cada Ciclo Data Driven rodado, a Estrutura Corporativa de Dados que vai sustentar todos os esforços de Analytics e Machine Learning para a geração de muitos Insights por toda a empresa que é o que desejamos.
Nesta terceira fase do Ciclo Data Driven, vamos mapear e definir que esforços serão necessários para a Captura de Dados e Automação do Processo de Transformação e Carga de Dados.
Neste momento entram questões importantes como a frequência de extração de dados, a depender do caso de uso que precisamos atender. Há necessidades analíticas e de produção de insights que se acomodam muito bem com extrações de dados apenas diárias durante a madrugada (algumas vezes até mensais).
Contudo, dependendo da criticidade das análises envolvidas, muitas vezes pode ser preciso extrair os dados próximo do tempo-real para que já sejam analisados poucos minutos após sua ocorrência e planos de ação sejam executados para correções, adaptações e microestratégias que precisam ser implementadas muito rapidamente. A execução destas estratégias muitas vezes implica no ganho ou perda de milhões de reais em apenas um dia.
Se esse é o caso, será necessário então empreender esforços de Change Data Capture (Captura da Mudança de Dados) por meio de ferramentas de Replicação de Dados que leem as mudanças feitas pelos sistemas gerenciadores de bancos de dados e registradas nos Logs de Transação e replicam essas alterações para outros bancos de dados que serão usados para Analytics e Machine Learning.
Para completar, todo o processo de Transformação de Dados precisa de uma infraestrutura de Automação que possa não só coordenar a execução de cada uma das rotinas necessárias, como também interagir com diversos aplicativos (e.g. Teams, Salesforce, e-mail, etc) para fazer uma comunicação também automatizada e até a geração de dados e aplicações nas plataformas necessárias.
Essa automação é realizada por meio de ferramentas que permitem a construção de Fluxos de Automação gráficos que coordenam diversas tarefas e ferramentas envolvidas no processo.
Na fase Governe, nossa atenção está voltada para dois fatores importantíssimos para uma organização tornar-se cada vez mais Data Driven:
Depois de décadas de experiência na construção de projetos de Data Warehouse, Business Intelligence, Data Discovery e Analytics, observamos que um dos maiores inimigos para o uso em massa desse tipo de tecnologia entre os usuários de negócio é a credibilidade dos dados.
Isso ocorre sempre que os usuários encontram algum dado nos painéis de análise cujo valor não bate com o que ele encontra nos sistemas de gestão de onde aquele dado foi extraído. Isso pode ocorrer por três motivos:
Erro de Transformação: são erros podem ocorrer nos processos de transformação e limpeza dos dados desenvolvidos pela equipe de TI, que alteram inadvertidamente o valor do dado;
Descasamento de Período de Observação: ocorre quando o usuário está comparando um dado que está no banco de dados de Analytics numa outra escala de tempo em relação a um dado que está no sistema de gestão de forma on-line. Um exemplo disso seria o usuário ver no ambiente de Analytics qual o valor total de vendas do mês corrente (sendo que o banco de dados para Analytics foi atualizado na madrugada de ontem para hoje) e comparar com o mesmo valor consultado no sistema de gestão que é on-line e tem seus dados atualizados milhares de vezes durante o dia pelas transações que ocorrem. Quando isso ocorre, uma explicação para o usuário do processo de Extração, Transformação e Carga dos Dados é necessária.
Falta de Entendimento das Fórmulas de Cálculo de Valores: ocorre quando o usuário vê valores nomeados da mesma forma, mas que não batem entre o sistema de gestão e o ambiente de Analytics e não há um erro de cálculo. Imagine um usuário querendo saber o total de vendas do mês passado e recebendo números diferentes de setores diferentes da empresa. Quando se vai um pouco mais a fundo na identificação das razões da diferença, é verificado que um setor trouxe o valor bruto de vendas e o outro apresentou o valor líquido de vendas. Nesse caso, não há um erro, mas sim uma falta de harmonização de entendimento do conceito de total de vendas do mês entre os setores.
Seja qual for o motivo, sempre que há um não batimento de dados entre os bancos de dados dos sistemas de gestão e do ambiente de Analytics, é de suma importância a abertura de um processo de Registro de Não-Conformidade.
Da mesma forma que acontece com a gestão da qualidade nas indústrias mais avançadas, esse processo de registro de não-conformidade precisa:
Registrar a ocorrência do não batimento dos dados com todas as informações pertinentes, inclusive de quem encontrou essa diferença;
Investigar as causas do não batimento dos dados entre as três possibilidades que já apresentamos anteriormente;
Corrigir o erro nos dados se o motivo do não batimento for um erro;
Explicar o motivo do não batimento de dados se a ocasião for um descasamento de período de observação ou uma falta de entendimento de fórmulas;
Fechar o processo de registro e tratamento de não-conformidade e dar publicidade.
Somente assim conseguiremos preservar a qualidade dos dados e a confiança dos usuários de negócio, mesmo quando ocorrem erros nos tratamentos de dados.
Isso porque, quando o usuário percebe um não batimento de dados, é natural que passe a considerar todo o restante do ambiente de Analytics como suspeito. Imagine que você consulte seu extrato bancário num dia e observe que há um erro mostrando um saldo menor do que deveria. Se for comprovado que há um erro no extrato, você vai passar a desconfiar de todos os extratos daí para frente.
Se não houver uma explicação do que aconteceu que lhe convença, certamente você vai mudar de banco. É exatamente o que acontece com os usuários de negócio que, depois de observar alguns erros que não tratados ou explicados, acabam abandonando o uso do ambiente de analytics.
O outro lado desta moeda está na importância do registro de todos os retornos de investimento obtidos pelo uso do ambiente de analytics.
Depois de décadas desenvolvendo projetos para organizações de todos os segmentos econômicos e portes, já comemoramos com os clientes conquistas como:
Descoberta de um erro de fabricação em uma linha de produtos que, ao ser tratado, economizou dezenas de milhares de reais por mês;
Descoberta de equipes de vendas que não estavam conseguindo oferecer todo o mix de produtos da empresa aos clientes e que assim estavam deixando centenas de milhares de reais na mesa que poderiam ser revertidos em faturamento;
Descoberta de contas hospitalares que estavam engavetadas ou eram recusadas pelos planos de saúde por conta de falhas documentais, redundando em centenas de milhares de reais de faturamento aumentado por mês;
Descoberta de fraudes em empresas públicas e privadas pelo cruzamento de dados comportamentais, resultando em milhões de reais recuperados;
Descoberta de oportunidades de vendas de linhas de produtos específicas em novos mercados, aumentando o faturamento dos clientes em muitos milhões de reais, entre muitas outras conquistas.
O importante aqui é registrar todas essas conquistas de forma sistemática, inclusive com os respectivos valores em reais de cada um desses retornos de investimento. O que vemos é que essas vitórias são comemoradas, mas não ficam registradas em lugar nenhum e logo se perdem na memória ou viram lenda.
Então nesta fase, tratamos de providenciar um local estruturado para registrar não só esses grandes retornos, mas também os mais simples e de valor menor. Essa acaba sendo a base de impulsionamento para o patrocínio dos futuros projetos de analytics.
Uma vez que os dados estão carregados, é fundamental entender o perfil de cada um de seus componentes. Para isso, temos dois esforços importantes a serem considerados:
É cada vez mais comum nas organizações a existência de diversos esforços, equipes e ferramentas em paralelo aplicadas no sentido extrair, transformar e disponibilizar dados para as áreas de negócio da própria empresa, mas também de seus fornecedores, clientes e parceiros.
Essa realidade acaba gerando um grande retrabalho na produção de informações e a falta de uma padronização, de metadados e de um depósito central onde um usuário possa acessar com confiança e credibilidade os dados da organização.
É nesse contexto que surge a necessidade de um Catálogo Central de Dados, onde possam ser armazenados conjuntos de dados interrelacionados e bem definidos com metadados completos. Esses conjuntos de dados também precisam ser pesquisáveis para que os usuários de negócio e também de TI possam descobri-los e publica-los na ferramenta de Analytics ou Data Science de sua preferência, como por exemplo Qlik, PowerBI ou Tableau.
Com o advento da LGPD (Lei Geral de Proteção de Dados) e de seus pares em outros países, a preocupação com o sigilo, governança e circulação do dado é um elemento cada vez mais presente.
Por isso, é preciso identificar se essas necessidades estão presente nos dados que circulam pela organização para garantir que essa circulação cause apenas o efeito benéfico esperado, sem comprometer a segurança e a privacidade das pessoas.
Aqui temos o momento alto de todo o Ciclo Data Driven. Tudo que fizemos até o momento servirá como fator estruturante para que o processo de Exploração dos Dados possa ocorrer de forma:
Tem que ser simples ou quase intuitivo para que seja manuseado pelo usuário de negócio de forma natural. Tem que ser flexível para permitir que qualquer pergunta seja feita de forma imprevista e a resposta seja obtida de forma instantânea. Tem que ser poderosa pois a resposta precisa vir quase que instantaneamente, não importando o volume de dados que está sendo consultado.
Essa é uma das principais estratégias para proporcionar ao usuário final poder de análise, simplicidade de acesso e flexibilidade para perguntar. Fazer qualquer pergunta significa manter uma sequência de perguntas de análise sem a necessidade de parar porque aquele dado não está disponível e se precisa pedir ao pessoal de TI que faça sua extração.
Isso é implementado por meio do Painel de Qualquer pergunta que permite ao usuário final de negócio saber tudo que precisa sem sair de uma única tela:
Esse é o painel onde o usuário conseguirá responder à qualquer pergunta por meio de gráficos combinados que permitem milhões de combinações diferentes sem sair de uma mesma tela.
Veja a seguir as áreas do painel e suas funções. Inicialmente o painel está dividido em três grandes áreas:
Nesta área temos a possibilidade de escolher que Dimensões queremos comparar e por quais Medidas vamos fazer essa comparação.
Veja que é possível trocar tanto a Dimensão como a Medida do gráfico por qualquer outra que faça parte do 5W2H deste Documento.
Nesta área temos a possibilidade de escolher que Dimensões e Medidas queremos ter a evolução temporal observada.
Veja que é possível trocar tanto a Dimensão (no gráfico Contínuo Dimensão) como a Medida do gráfico por qualquer outra que faça parte do 5W2H deste Documento.
Sabemos que muitos usuários de negócio preferem ver os dados em Tabelas ao invés de gráficos. Principalmente as pessoas mais acostumadas a fazer análises em Planilhas Eletrônicas.
Por isso, temos também um painel de Qualquer Pergunta feito em forma de Tabela para deixar esses usuários de negócio mais confortáveis, onde podem escolher as Dimensões e as Medidas a serem utilizadas:
Vamos ver as áreas deste tipo de painel e a função de cada uma delas:
A fase de Ative busca identificar as oportunidades de que o ambiente de Analytics possa oferecer algo ao usuário de negócio de forma automática ao invés do tradicional que é o usuário buscar o que precisa navegando nos painéis.
Quer saber mais sobre como esta plataforma
pode transformar sua organização?