12/04/2022
No DaaP, sigla da expressão em inglês Data as a Product, o objetivo é fornecer os dados de que a companhia precisa, seja para tomar decisões, seja para construir produtos personalizados ou qualquer outro propósito
Admar Concon-Neto, Claudio Luis Muller e Fabiano Tomita*
Existem dois conceitos na área de dados que aparecem muito no dia a dia, o DaaP (Dados como um Produto, do inglês Data as a Product) e o DaaS (Dados como um Serviço, do inglês Data as a Service). Hoje vamos falar sobre o DaaP e, muito em breve, sobre o DaaS.
Essencialmente, o conceito de Dados como um Produto, como o próprio nome diz, é entregar os dados como um produto. Mas como assim? Neste artigo, Justin Gage, líder de dados de uma startup chamada Retool, usa uma definição bacana do conceito. Originalmente em inglês, podemos traduzi-la da seguinte forma: “DaaP é o modelo mais simples de entender: o trabalho do time de dados é fornecer os dados de que a companhia precisa, para qualquer propósito, seja para tomar decisões, seja para construir produtos personalizados ou para detectar fraude”.
O diagrama abaixo serve para ilustrar o fluxo no modelo DaaP. Note que os dados da companhia (à esquerda) são trabalhados pelo time de dados, geralmente composto por engenheiros, analistas e cientistas de dados, que fornecem para a empresa o dado como um produto. Então, a empresa irá interpretar esses dados para obter os insights que a ajudarão na tomada de decisão.
Um exemplo concreto pode ajudar a entender melhor o conceito. Imagine que na sua empresa existem várias bases de dados: a base dos clientes, a dos produtos, a dos fornecedores etc. Seu time comercial pretende fazer uma ação com um determinado produto e, para isso, precisa de algumas informações sobre um item específico. Em geral, os profissionais do setor comercial não são programadores, então eles pedem para o time de dados todas as informações de que precisam desse item: o preço de custo, o volume de vendas dos últimos 30 dias, os dispositivos que os clientes usam para comprar esse produto etc. A pessoa do comercial faz uma lista do que ela precisa e passa para o time de dados.
Quando o pedido chega ao time de dados, as coisas não são tão automáticas como muitos pensam. Existe o Data Lake (que seria o grande repositório de dados da empresa), que contém todos os dados, mas nem sempre as informações estão bem estruturadas. Às vezes, é necessário um tratamento, que pode ser feito por meio de ETLs (do inglês Extract, Transform, and Load, os processos de Extração, Transformação e Carregamento dos dados). Esse trabalho pode ser feito por engenheiros, analistas e cientistas de dados.
Depois dos ETLs, é preciso validar os dados, para ver se eles fazem sentido. E então colocá-los, ou melhor, empacotá-los de uma forma adequada para poder entregar ao time comercial. Pronto, uma vez entregue ao time comercial, os dados foram entregues como um produto. No final, pode ser um arquivo .csv, uma planilha na web do Google (gsheets) uma planilha do Microsoft Excel. Enfim, a forma como vai ser entregue depende do acordo do time de dados com o time comercial, neste exemplo fictício. Também é comum o time de dados entregar o produto em uma base de dados na nuvem, como na AWS (via Redshift), e o time comercial consumir esses dados por meio de um dashboard do Microsoft Power BI. Dependendo da infraestrutura da empresa, várias outras possibilidades podem ser consideradas (Google Cloud Platform – GCP, Azure, Tableau etc.).
Nesse modelo do DaaP, quando o time comercial recebe o produto, ele não vai perguntar ao time de dados como ele deve fazer a ação comercial. Se deve dar um desconto maior para os clientes que compram pelo celular, ou se devem dar um brinde para compras acima de X reais. Essas decisões são do time comercial. A interpretação dos dados, os insights obtidos a partir dos dados também cabem ao time comercial. Ele é que vai olhar e dizer: “Considerando os últimos 3 meses, vendemos melhor nos finais de semana. Então, vamos fazer uma ação de marketing na quinta, para alavancar as vendas do próximo final de semana.” O time de dados nem vai saber, tampouco participar dessas conversas do time comercial. O trabalho do time de dados acaba quando entrega o produto. Da mesma forma, o time comercial não vai perguntar nem vai querer saber se o time de dados usou ferramentas como SQL, DBeaver, Pentaho etc. Como diz aquele velho ditado, “cada macaco no seu galho”.
No exemplo usado, o cliente era um setor da própria empresa (time comercial). Mas o raciocínio pode ser estendido para o cliente externo. Sua empresa entregaria o produto ao cliente, e a partir daí todas as análises e decisões estariam nas mãos do seu consumidor.
Se você optar por adotar o conceito de “Dados como um Produto”, algumas orientações devem ser seguidas. As equipes de dados devem adotar uma abordagem multifuncional do ciclo de vida do Dado como um Produto. O ciclo de vida da entrega deve seguir princípios ágeis, para entregar um valor incremental e rápido aos consumidores dos dados. Um exemplo de metodologia ágil muito utilizado hoje em dia é o Scrum. Podemos citar também o Lean e o Kanban, entre outras ferramentas.
Definir os requisitos dos dados é essencial, respeitando o contexto e os objetivos de seu negócio. Além disso, não podemos esquecer o arcabouço regulatório, principalmente depois que a Lei Geral de Proteção de Dados entrou em vigor. A questão da privacidade e governança dos dados não pode ser relegada a segundo plano, sob pena de sua empresa precisar desembolsar um bom dinheiro em indenizações.
Eventualmente, será necessário criar APIs de serviços da web para permitir o consumo de aplicativos com as credenciais corretas para acessar o produto de dados e desenvolver todas as etapas do processo (pipelines) para publicar os dados com segurança para seus assinantes.
Há também a questão da qualidade, e duas siglas novas aparecem: o SLA (do inglês Service Level Agreement), que seria um acordo de nível de serviço, e o QA (Quality Assurance), ou seja, a Garantia de Qualidade. Antes de iniciar as atividades, é importante definir com o seu cliente o nível de serviço esperado, o que é o mínimo pretendido, e isso vem especificado no SLA. O controle de qualidade vem com os testes e a validação dos dados, para garantir que estejam completos, em conformidade, e que possam ser consumidos com segurança.
Após entregar o produto ao seu cliente, há a famosa pós-venda, que é tão importante quanto a pré-venda, embora muitas vezes as empresas deixem um pouco de lado. É preciso planejar o suporte e a manutenção, deixando claro para o cliente, desde o início, como ele deve proceder quando eventuais problemas ocorrerem. Quando seu carro ou sua casa (exemplos de ativos tangíveis) precisa de alguma manutenção, você já sabe o que fazer e resolve rápido, para evitar que a dor de cabeça fique maior. Com ativos intangíveis, como software e dados, os cuidados com a manutenção e o suporte são igualmente importantes. Para fidelizar seu cliente e facilitar sua prospecção, a assistência bem-feita é uma ótima estratégia de marketing.
Esperamos que tenham gostado do DaaP. Bons negócios e até breve!
Admar Concon-Neto é fundador da Northern, cofundador do Wabafood, mentor de startups no Founder Institute, mentor na disciplina Resolução Eficaz de Problemas no Insper e professor de desenvolvimento web e data science no Le Wagon.
Claudio Luis Muller é engenheiro químico e mestre em processamento de polímeros pela Universidade Federal do Rio Grande do Sul (UFRGS), tem mais de 20 de experiência em sistemas de coleta de manipulação de dados industriais, IoT com ênfase em O&G e é membro da comunidade Alumni Insper, instituição onde concluiu o MBA executivo.
Fabiano Tomita é engenheiro de produção formado pela Universidade Federal de São Carlos (UFSCar) e pós-graduado pelo Insper (CBA – 2006) e pela Unesp em inovação tecnológica. Atua no Instituto Eldorado, centro de pesquisa, desenvolvimento e inovação, nas áreas de planejamento estratégico, com foco em estratégia de mercado.
