Se olharmos para algumas das falhas mais dispendiosas de projetos corporativos, onde se gastaram anos e dinheiro na construção de data warehouses ou data lakes, Na Amazon Web Services vemos que estas provavelmente ocupam o segundo lugar nas grandes implementações de ERP. Embora a nuvem tenha reduzido significativamente o time-to-market e o custo de armazenamento, processamento e análise de dados em escala, é importante que os recursos de dados comecem com os resultados do negócio, em vez de com as fontes de dados.
Para construir recursos de dados, comece por fazer uma lista com perguntas feitas pela empresa. Veja com que frequência se essas perguntas estão a ser feitas; classifique as perguntas mais comuns por ordem do impacto no negócio. Isto permite que consiga priorizar e ordenar os dados que precisa. Mais importante, permite que agregue valor de forma gradual a partir dos dados, sem precisar de gastar tempo ao verificar “todos os dados”.
Uma das ferramentas que uso é um gráfico visual que mostra os principais elementos de dados num eixo e as funções core do negócio que dependem desses dados. Vamos considerar uma pergunta simples: Qual é o P&L (Profit & Loss) do produto X?
Agora, acrescente as áreas que querem saber dos mesmos elementos de dados.
À medida que repete este processo com a lista das perguntas prioritárias, a imagem vai exibir os elementos que agregam valor a várias funções. Também mostra que elementos de dados já dispõe, que podem permitir fazer melhores ou diferentes perguntas das iniciais e o que falta ainda preencher. Esta pode ser uma poderosa ferramenta visual para ajudar gradualmente a criar e priorizar a plataforma de dados, sem perder a big picture.
Adicione os dados “Black Holes”
É essencial focar-se também na captura de dados corretos e não apenas no seu consumo. Muitas transações importantes dentro de uma empresa acontecem nas folhas de cálculo ou nos workflows que estão fora de qualquer sistema. Existem muitos dados valiosos provenientes desses workflows que não são explorados porque não há uma aplicação estratégica vinculada aos mesmos.
Tenha uma Estratégia para limpeza, qualidade e reconciliação de dados
À medida que a empresa muda para uma cultura orientada a dados, é natural ter alguma resistência. O medo mais comum é a “falta de confiança” nos dados. É crucial superá-la, trabalhando com os proprietários dos dados das unidades de negócio para definir antecipadamente um processo de reconciliação.
Os problemas de qualidade dos dados podem surgir muito mais tarde e inviabilizar uma iniciativa. Para evitá-lo, faça verificações, identifique casos extremos e faça uma limpeza antes de trabalhar em alguma coisa. Às vezes, problemas de qualidade de dados também são reveladores de problemas maiores dentro da organização ou nos processos de negócios. No início de minha carreira, trabalhei numa iniciativa de dados de vendas para uma grande empresa de media e descobrimos que havia mais de 200 variações de um único registo de cliente! A solução foi trabalhar, não na limpeza de dados, mas incidir nos silos de dados dentro das funções de vendas.
Vi também que frequentemente o que é considerado “verdade”, está errado. Não tenha medo de revalidar, recuar e questionar a precisão de qualquer fonte à qual a nova plataforma de dados está a ser comparada. Um dos projetos que trabalhei tinha um sistema de mainframe como fonte e a nossa reconciliação foi reduzida em alguns cêntimos numa medida muito importante – Custo por Mil (CPM). Mas quando multiplicado por milhões de impressões de audiência, os poucos cêntimos somam milhões de euros. Após várias noites, descobrimos que, devido a uma limitação no tamanho variável, o antigo sistema de mainframe estava a arredondar os números que a nossa nova plataforma de dados não precisava.
Padronizar é sobrevalorizado
Os dados são um espaço de rápida evolução, portanto esteja aberto a usar a ferramenta certa para o trabalho certo, em vez de forçar a padronização. Em vez de insistir em ferramentas de consolidação, forneça aos developers a flexibilidade de experimentar.
Mantenha os dados em movimento
Dados antigos não prestam! Pense no seu layer de integração como uma parte essencial do seu recurso de dados. Usamos algumas das mesmas APIs transacionais que conectam as nossas aplicações para preencher o nosso layer de dados de forma gradual. Isto eliminou mais um layer de lógica que tínhamos de manter e validar, mas mais importante, fornecia aos nossos clientes informações próximas em tempo real, sem ter que se esperar muito.
Um benefício adicional de ter um forte layer de API é a capacidade de criar uma abstração e uma flexibilidade entre a otimização ou layers analíticas e de dados.
“Reportar” cidades fantasma
Não deixe a sua plataforma de dados ser atacada ao automatizar, digitalizar ou receber relatórios que estão “em circulação”, mas que não estão em uso. As empresas têm centenas ou milhares de relatórios criados e distribuídos, mas quase nunca são usados. Quando substituímos o nosso sistema financeiro por uma plataforma global unificada, descobrimos que havia mais de 250 relatórios existentes que estavam programados. Trabalhamos diligentemente com os nossos parceiros de negócio e descobrimos que muitas eram simplesmente variantes diferentes, porque alguém queria adicionar mais algumas colunas ou gostava de uma formatação diferente. Crie um mecanismo para ver com que frequência algo é realmente executado e usado.
Torne-o o interface agradável
Às vezes, painéis e visualizações de dados são rotulados como “muito elementares” e não fazem parte de um recurso de dados “avançado”. Estes podem ser uma ferramenta muito poderosa para CIOs, CTOs ou CDOs. Use-os como um meio para quebrar os silos de dados, obtenha suporte e garanta o financiamento necessário para impulsionar recursos avançados de dados na empresa.
No passado, desenvolvemos uma skill em Alexa que permitia que uma interface de voz fizesse simples perguntas diárias à nossa plataforma de dados, como: “Como foi a estreia da noite passada?” ou “Quem foi o maior anunciante num <programa> desta temporada?” De seguida, colocámos o Amazon Echo em alguns dos nossos escritórios, algo que transformou a nossa plataforma de dados em algo com o qual se poderia “conversar”, tornando-a assim mais acessível.
Ishit Vachhrajani
Enterprise Strategy
Amazon Web Services
