A falta de confiança das pessoas afetará o caminho para se tornar uma empresa orientada por dados, a menos que haja uma estratégia baseada no raio de explosão dos incidentes de qualidade de dados.
Um dos grandes inimigos das empresas que buscam se tornar data-driven é a má qualidade dos dados disponíveis para embasar tomadas de decisões. Segundo a Gartner, em média US$ 15 milhões ao ano são gastos em decisões erradas nas companhias e, conforme a Experian, 90% das empresas são afetadas por esse problema.
Um dos pontos que causa maior impacto é a perda de confiança da organização sobre os dados e sobre sua plataforma de processamento e armazenamento. Se algum erro ou decisão ruim foi tomada com base nos dados, a desconfiança pode percorrer os corredores e se instaurar na empresa como um todo.
Um estudo da IBM revela que 1/3 dos executivos de negócios não confia em seus dados e eles acreditam que, em média, 32% de seus dados estão errados. Outro estudo, da Forrester, mostra que 1/3 dos analistas de dados gasta mais de 40% do tempo revisando os dados manualmente, campo a campo, em busca de problemas de qualidade. Justamente devido à falta de confiança.
Trust Blast Radius – Raio de Explosão de Confiança
Ryan Gross, engenheiro de computação e vice-presidente da norte-americana Pariveda Solutions, do ramo de TI, utiliza o termo Trust Blast Radius para explicar o problema da falta de confiança nos dados e propor formas de neutralizá-la.
O impacto de uma bomba é proporcional ao seu raio de explosão, que é a distância da fonte que será afetada quando ocorrer uma explosão.
Ilustração do raio de explosão de uma bomba atômica. Fonte: Wikimedia
O termo ganhou força no espaço da arquitetura de TI, com equipes trabalhando para minimizar o número de sistemas adicionais que são colocados offline por uma falha em um único sistema.
Quanto à qualidade dos dados, Trust Blast Radius é a quantidade de confiança adicional que é destruída por um único problema de qualidade de dados. É uma medida da lacuna entre a quantidade de dados ruins em uma organização e a quantidade de desconfiança nos dados em toda a organização. Depois que uma pessoa passa por um evento que abala sua confiança, é natural que o medo, a incerteza e a dúvida se espalhem rapidamente no ambiente.
Se considerarmos uma equação para o conceito de Trust Blast Radius, ela seria:
Número de problemas de qualidade de dados
x
número de conversas sobre os problemas sem contexto
x
número de experiências negativas anteriores com qualidade de dados
O fato a aceitar é que problemas de qualidade de dados sempre surgirão, apesar dos melhores esforços para evitá-los. Se mudarmos de uma atitude apenas de prevenção para uma atitude de prevenção e também minimização do raio de explosão, teremos muito mais sucesso em promover uma cultura baseada em dados em uma organização.
Como minimizar o raio de explosão de confiança
Para combater os efeitos do Trust Blast Radius, podemos nos inspirar em uma técnica militar norte-americana da década de 50. A Análise de Modos e Efeitos de Falha (FMEA, em inglês) foi desenvolvida para uso em programas de armas nucleares e, amplamente adotado por outras organizações responsáveis por sistemas complexos, como a NASA e empresas de fabricação de aeronaves e automóveis, semicondutores, da área da saúde, etc. O FMEA detalha os componentes e subcomponentes de um sistema (ou etapas de processos) e lista as maneiras como cada um deles pode falhar. Então, examina os efeitos posteriores dessas possíveis falhas e recomenda um mecanismo de controle para prevenir ou minimizar o impacto delas.
Embora essas técnicas tenham sido projetadas para máquinas onde os efeitos são bem mais evidentes, elas fornecem um guia útil para analisar o sistema complexo que é uma organização passando por uma transformação para se tornar orientada por dados.
Para começar a enumerar as possíveis falhas, é importante sublinhar a função principal da organização de dados e análises em uma companhia: permitir que a empresa obtenha o máximo de valor de seus ativos de dados, normalmente ajudando na tomada de decisão baseada em dados.
-
Um dado inválido é incluído em um produto de dados que faz com que uma decisão inválida seja tomada. Por exemplo, uma métrica de satisfação do cliente foi calculada incorretamente para uma pequena seção de clientes, fazendo parecer que os clientes insatisfeitos estavam muito satisfeitos. Isso leva a empresa a enviar publicidade adicional de venda cruzada em vez de atuar sobre a insatisfação desse grupo.
-
O consumidor de um produto de dados detecta que um dos pontos de dados relatados é inválido (ou seja, o mesmo cenário de antes, mas alguém no marketing percebe o problema antes de enviar os anúncios).
-
Vários produtos de dados representam a mesma coisa conceitual de maneira diferente, e o consumidor não sabe qual é o correto. Por exemplo, um relatório de operações define o cliente ativo como aquele que usou o sistema na última semana, enquanto um relatório de faturamento o define como um cliente que está pagando uma assinatura.
A chave é que, em cada um desses cenários, o impacto no ponto de falha inicial não é muito grande. No entanto, se não forem verificados, eles podem iniciar uma cascata de problemas e falta de confiança. E isso sim pode causar um grande impacto.
Como lidar com data quality
Para manter um bom padrão de qualidade nos processos de dados da sua organização, há 4 ações fundamentais: captura, catálogo, correção e cura. Elas moldam a explosão de problemas de qualidade de dados para torná-la mais produtiva, minimizando o raio de explosão.
Capturar – Refere-se à captura do problema. O ideal é que esses problemas sejam detectados pelo monitoramento em sua plataforma de dados antes que qualquer consumidor de dados tome conhecimento deles. Porém, é impossível detectar todos os problemas e alguns deles podem levar a uma expansão muito grande do raio de explosão. Por isso é fundamental dar voz aos consumidores de dados e que eles confiem que, por que usam sua voz para levantar um problema, isso será resolvido. Para começar, certifique-se de que cada consumidor de dados na organização tenha acesso a um único local para levantar problemas de dados. Tão importante quanto, eles também devem saber como usar essa ferramenta e devem verificar se o problema está sendo tratado, o que leva ao restante das etapas.
Catalogar – Assim que um problema for encontrado, é muito importante avisar aqueles que serão afetados. É importante que a documentação dos problemas de dados fique visível para as pessoas em seu fluxo de trabalho diário. Isso é mais fácil se houver um local consistente para encontrar notas de qualidade de dados em um determinado produto de dados. Por exemplo, fazer com que seus consumidores de dados acessem seus relatórios de BI por meio de um diretório único faz com que possa haver avisos de problemas de qualidade antes mesmo de alguém abrir um relatório. Caso não haja essa estrutura, é preciso criar alertas diretamente nos relatórios (de preferência em um local com boa visibilidade) para chamar a atenção para as possíveis inconsistências. Obviamente, essa técnica só funciona se os pipelines de dados forem integrados e minimamente confiáveis.
Catalogar o que deve ser confiável é tão importante quanto documentar o que não deve ser confiável por enquanto. É como um carro que acende a luz de verificação do motor no painel. Pode ser que a tampa do tanque não esteja bem apertada ou que seu motor esteja prestes a se destruir nos próximos 10 minutos. Como você não sabe, sua reação deve ser conduzida a partir do pior cenário possível. Se, em vez disso, você pudesse abrir um aplicativo e ver quais verificações de mecanismo estavam passando e quais estavam causando avisos, você seria capaz de tomar uma decisão melhor informada sobre o que fazer. No mundo de DataOps, isso envolve colocar a lista de testes de dados que foram executados para provar um determinado pipeline antes de ser implantado em produção, bem como aqueles que são executados continuamente para garantir que os dados atendam às principais expectativas.
Corrigir – Catalogar o estado atual dos dados, tanto bons quanto ruins, ajuda a mudar a mentalidade padrão dos consumidores de dados e aumentar sua confiança. A última parte da documentação necessária é a documentação de que ações já estão sendo tomadas para melhorar as coisas. Dessa forma, ter um sistema de tickets de trabalho para rastrear os problemas de dados funciona melhor do que simplesmente capturar o problema diretamente como uma nota no catálogo. Depois de mostrar aos consumidores de dados de que você é transparente e está agindo, é muito menos provável que eles criem um raio de explosão.
Ilustração do ciclo para mostrar ações e atualizações na resolução de problemas de dados
Uma questão chave nesse quesito é ir além de simplesmente corrigir o problema para aumentar a confiança de que ele foi corrigido.
Consideramos o seguinte cenário de raio de explosão de confiança, também abordado por Ryan Gross: um analista de marketing encontra um problema com endereços de clientes e pergunta a cinco pessoas a quem deve reportar isso. Em seguida, envia um e-mail para o engenheiro de dados responsável pelo pipeline de endereços do cliente. O engenheiro percebe que sua última alteração causou um problema de formatação, corrige o problema e envia um e-mail ao analista de marketing informando que foi corrigido. Agora, embora o analista acredite que os endereços estão corretos, as outras quatro pessoas com quem ela conversou não sabem sobre a solução (ou mesmo os detalhes do problema) e provavelmente confiarão menos nos dados de endereços.
Se a plataforma de dados está de acordo com os primeiros 2 C’s e a equipe de dados pratica um desenvolvimento orientado a testes, então essas 4 pessoas seriam capazes de ver que o novo teste adicionado quando o engenheiro corrigiu o problema. Pode ver também que não há tickets abertos para os dados de endereço, restaurando sua confiança sem nem a necessidade de uma conversa direta com o engenheiro de dados.
Cura – a etapa final é impedir que os problemas voltem, curando as questões sistêmicas que os levaram a acontecer inicialmente. Este é definitivamente o empreendimento mais complexo, mas também o mais recompensador.
A ideia é realizar análises de tendências e de causa raiz nos tickets, para descobrir problemas sistêmicos. Vinculando tickets de problemas a tickets de “correção sistêmica”, é possível criar novos recursos na plataforma de dados, além de melhorias de processo que podem passar a identificar potenciais problemas logo no início do ciclo de desenvolvimento.
Problemas com qualidade dos dados provocam desconfiança nos funcionários de uma organização. Isso coloca a perder toda a inteligência que os dados poderiam gerar, gerando desperdício de recursos e, até mesmo, más decisões – baseadas em critérios que não são objetivos.
Iniciativas baseadas em dados fracassam quando há baixo engajamento de usuários importantes. E data quality deve ser um processo minucioso que lembra a todos na empresa que eles podem confiar nas evidências oferecidas para sua tomada de decisão.
