MIT: Por que é que tantos projectos de ciência de dados fracassam

Cada vez mais empresas vêem a ciência de dados como uma função e uma capacidade. Contudo, muitas delas não têm conseguido retirar valor comercial de forma consistente dos seus investimentos em big data, inteligência artificial e aprendizagem automática. Além disso, as provas sugerem que está a aumentar o fosso entre as organizações que obtêm valor da ciência de dados e as que têm dificuldade em fazê-lo.

Para compreender melhor os erros que as empresas cometem ao implementar projectos lucrativos de ciência de dados, e descobrir como evitá-los, realizámos estudos aprofundados a actividades de ciência de dados em três dos 10 maiores bancos do sector privado da Índia, com departamentos analíticos bem estabelecidos. Identificámos cinco erros comuns, como exemplificado pelos seguintes casos que encontrámos, e abaixo sugerimos soluções para os resolver.

ERRO 1 – O martelo à procura de um prego

Hiren, um cientista de dados recentemente contratado num dos bancos que estudámos, é o tipo de mago analítico que as organizações cobiçam. Sente-se particularmente impressionado com o algoritmo “k-vizinhos mais próximos”, útil para identificar e classificar conjuntos de dados. «Apliquei o k-vizinhos mais próximos a vários conjuntos de dados simulados durante os meus estudos», disse-nos ele, «e mal posso esperar para o aplicar em dados reais em breve.»

Hiren fez isso alguns meses mais tarde, quando usou o algoritmo k-vizinhos mais próximos para identificar segmentos do sector particularmente rentáveis dentro da carteira de contas correntes de negócios do banco. A sua recomendação à equipa de contas correntes empresariais: visar dois dos 33 segmentos do sector do portefólio.

Esta conclusão desiludiu os membros da equipa de negócios. Eles já conheciam estes segmentos e conseguiam determinar a rentabilidade do segmento com simples cálculos retrospectivos. Utilizar o algoritmo k-vizinhos mais próximos para esta tarefa foi como usar um míssil guiado quando uma pressão de ar teria sido suficiente.

Neste caso, e noutros que examinámos nos três bancos, o fracasso em atingir o valor comercial resultou de uma paixão pelas soluções da ciência de dados. Este fracasso pode ter várias formas. No caso de Hiren, o problema não exigiu uma solução tão elaborada. Noutras situações, vimos a utilização bem-sucedida de uma solução de ciência de dados num contexto tornar-se justificação para a sua utilização noutro contexto em que não era tão apropriada ou eficaz. Em suma, este erro não decorre da execução técnica da técnica analítica; decorre da sua má aplicação.

Depois de Hiren ter desenvolvido uma noção mais profunda do negócio, voltou à equipa com uma nova recomendação: mais uma vez, propôs a utilização do algoritmo k-vizinhos mais próximos, mas desta vez ao nível do cliente, em vez de ao nível do sector. Isto provou ser muito mais adequado, e deu origem a novos conhecimentos que permitiram à equipa visar segmentos de clientes por explorar. O mesmo algoritmo, num contexto mais apropriado, ofereceu um potencial muito maior de valor comercial.

Não é exactamente extraordinário observar que as soluções analíticas são susceptíveis de funcionar melhor quando desenvolvidas e aplicadas de uma forma sensível ao contexto empresarial. Mas descobrimos que a ciência de dados parece mesmo ser extraordinária para muitos gestores. Deslumbrados com a aura de alta tecnologia da analítica, podem perder de vista o contexto. Isto era mais provável, descobrimos, quando os gestores viam uma solução funcionar bem noutro lugar, ou quando a solução era acompanhada por um rótulo intrigante, como “IA” ou “aprendizagem automática”. Os cientistas de dados, que estavam focados nos métodos analíticos, muitas vezes não conseguiam ou não ofereciam uma perspectiva mais holística.

Para combater este problema, os gestores de topo dos bancos do nosso estudo recorreram frequentemente à formação. Num banco, os recém-chegados da ciência de dados eram obrigados a frequentar cursos de formação de produtos ensinados por peritos na área, juntamente com estagiários de gestão de relações de produto. Este banco também ofereceu formação em ciências de dados adaptada para gestores de empresas de todos os níveis e administrada pelo líder da unidade de ciências de dados. O currículo incluía conceitos analíticos básicos, com ênfase em questões a colocar sobre técnicas de solução específicas e onde as técnicas devem ou não ser utilizadas. Em geral, as intervenções de formação concebidas para abordar este problema tinham como objectivo facilitar a fertilização transversal de conhecimentos entre cientistas de dados, gestores de empresas e peritos de áreas e ajudá-los a desenvolver uma melhor noção dos trabalhos uns dos outros.

Num trabalho no terreno relacionado, vimos também correcções baseadas em processos para evitar o erro de passar demasiado depressa para uma solução favorecida. Uma grande empresa aeroespacial americana usa uma abordagem a que chama os Sete Caminhos, que exige que as equipas identifiquem e comparem pelo menos sete soluções possíveis e depois justifiquem explicitamente a sua selecção final.

ERRO 2 – Fontes de tendenciosidade que não são reconhecidas

Pranav, um cientista de dados com experiência em modelação estatística, estava a desenvolver um algoritmo para criar recomendações dirigidas aos responsáveis pela aprovação de empréstimos garantidos a pequenas e médias empresas. Utilizando os memorandos de aprovação de crédito (CAM) para todos os pedidos de empréstimo processados nos 10 anos anteriores, comparou a saúde financeira dos devedores na altura do seu pedido com a sua situação financeira actual. No espaço de alguns meses, Pranav tinha uma ferramenta de software desenvolvida em torno de um modelo altamente preciso, que a equipa de responsáveis implementou.

Infelizmente, após seis meses, tornou-se claro que as taxas de delinquência sobre os empréstimos tornaram-se mais elevadas após a implementação da ferramenta. Perplexos, os gestores de topo indicaram um responsável experiente para trabalhar com Pranav e descobrirem o que tinha corrido mal.

A epifania surgiu quando o responsável descobriu que os dados de entrada provinham de CAMs. O que o responsável sabia, mas Pranav não, era que os CAM eram preparados apenas para empréstimos que já tinham sido pré-seleccionados por gestores experientes e que tinham muitas probabilidades de serem aprovados. Os dados dos pedidos de empréstimo rejeitados na fase de pré-selecção não foram utilizados no desenvolvimento do modelo, o que criou uma enorme tendenciosidade na selecção. Este enviesamento fez com que Pranav falhasse a importação de um parâmetro crítico de decisão: os cheques devolvidos. Como seria de esperar, houve muito poucos casos de cheques devolvidos entre os devedores que os gestores tinham pré-seleccionado.

A correcção técnica neste caso foi fácil: Pranav adicionou os dados sobre pedidos de empréstimo rejeitados na pré-selecção, e o parâmetro “cheques devolvidos” tornou-se um elemento importante no seu modelo. A ferramenta começou a funcionar como deveria.

O maior problema para as empresas que procuram obter valor comercial a partir da ciência de dados é como discernir antecipadamente tais fontes de enviesamento e garantir que não se infiltram nos modelos em primeiro lugar. Isto é um desafio porque os leigos – e por vezes os próprios especialistas em analítica – não conseguem perceber facilmente como a “caixa negra” da análise gera resultados. E os peritos em analítica que compreendem a caixa negra muitas vezes não reconhecem as tendenciosidades incorporadas nos dados em bruto que utilizam.

Os bancos no nosso estudo evitam enviesamentos não reconhecidos, exigindo que os cientistas de dados se familiarizem com as fontes dos dados que utilizam nos seus modelos. Por exemplo, vimos um cientista de dados passar um mês numa filial a acompanhar um gestor de relações de modo a identificar os dados necessários para assegurar que um modelo produzia resultados precisos.

Vimos também uma equipa de projecto composta por cientistas de dados e profissionais de negócios usar um processo formal de prevenção de enviesamentos, no qual identificaram potenciais variáveis de previsão e as suas fontes de dados e depois escrutinaram cada uma delas em busca de potenciais tendenciosidades. O objectivo deste processo era questionar pressupostos e de outra forma “purificar” os dados – evitando assim problemas que possam surgir das circunstâncias em que os dados foram criados ou recolhidos.

ERRO 3 – Solução certa, altura errada

Kartik, um cientista de dados com experiência em aprendizagem automática, passou um mês a desenvolver um modelo sofisticado para analisar atritos nas contas poupança, e depois passou mais três meses a aperfeiçoá-la para melhorar a sua precisão. Quando partilhou o produto final com a equipa de produtos das contas poupança, ficaram impressionados, mas não puderam apoiar a sua implementação porque o seu orçamento anual já tinha sido gasto. Para evitar o mesmo resultado no ano seguinte, Kartik apresentou o seu modelo à equipa de produto antes do início do ciclo de orçamentação. Mas, o objectivo da equipa de direcção tinha passado da retenção para a aquisição de contas. A equipa não apoiou o projecto baseado no modelo de Kartik.

No seu terceiro ano de tentativa, Kartik conseguiu finalmente a aprovação do projecto, mas tinha poucos motivos para celebrar. «Agora querem implementá-lo», disse-nos ele, com evidente consternação, «mas o modelo deteriorou-se e precisarei de o desenvolver novamente!»

O erro que impede os bancos de obterem valor em casos como este é a falta de sincronização entre a ciência de dados e as prioridades e processos do negócio. Para o evitar, são necessárias melhores ligações entre a ciência de dados e as estratégias e sistemas do negócio.

Os executivos de topo podem assegurar o alinhamento das actividades de ciência de dados com as estratégias e sistemas organizacionais através de uma integração mais rigorosa das práticas de ciência de dados e cientistas de dados com o negócio em termos físicos, estruturais e de processos. Por exemplo, um banco incorporou cientistas de dados nas equipas empresariais com base num projecto. Desta forma, os cientistas de dados acompanharam a equipa empresarial no dia-a-dia, tornando-se mais conscientes das prioridades e prazos – e, em alguns casos, antecipando necessidades empresariais não articuladas. Vimos também equipas de cientistas de dados em contacto com equipas empresariais, bem como a utilização de mandatos de processo, tais como a exigência de que as actividades do projecto sejam realizadas no local da equipa empresarial ou que os cientistas de dados sejam incluídos nas reuniões e actividades da equipa empresarial.

Em geral, os cientistas de dados deveriam concentrar os seus esforços nos problemas considerados mais importantes pelos líderes empresariais. Mas há uma advertência: por vezes, a ciência de dados produz percepções inesperadas que devem ser levadas à atenção dos líderes seniores, independentemente de se alinharem com as prioridades actuais. Portanto, há aqui uma linha a ser percorrida. Se surgir um discernimento que não se enquadra nas prioridades e sistemas actuais, mas que, não obstante, pode trazer um valor significativo à empresa, cabe aos cientistas de dados comunicá-lo à direcção.

ERRO 4 – Ferramenta certa, utilizador errado

Sophia, uma analista de negócios, trabalhou com a sua equipa para desenvolver um motor de recomendação capaz de oferecer novos produtos e serviços orientados com precisão para os clientes do banco. Com a assistência da equipa de marketing, o motor de recomendação foi adicionado à aplicação da carteira móvel do banco, ao site de internet banking e aos emails. Mas o novo negócio previsto nunca se concretizou: a aceitação por parte dos clientes das sugestões de produtos foi muito menor do que o previsto.

Para descobrir porquê, os telemarketers do banco inquiriram uma amostra de clientes que não adquiriram os novos produtos. O mistério foi rapidamente resolvido: muitos clientes duvidavam da credibilidade das recomendações oferecidas através de aplicações, websites e emails.

Ainda à procura de respostas, Sophia visitou várias agências do banco, onde ficou surpreendida ao descobrir o elevado grau de confiança que os clientes pareciam depositar nos conselhos dos gestores de relações (RM). Algumas experiências informais convenceram-na de que os clientes teriam muito mais probabilidades de aceitar as sugestões do motor de recomendações quando apresentadas na agência por um RM. Percebendo que o problema não era o modelo do motor de recomendação, mas sim o modo de entrega das recomendações, Sophia reuniu-se com os líderes seniores e propôs o relançamento do motor como uma ferramenta de apoio à venda de produtos através dos RM. A iniciativa reformulada foi um enorme sucesso.

As dificuldades que Sophia encontrou realçam a necessidade de prestar atenção à forma como os resultados de ferramentas analíticas são comunicados e utilizados. Para gerar valor total para os clientes e para o negócio, a análise à experiência do utilizador deve ser incluída no processo de concepção da ciência de dados. No mínimo, os testes de utilizador devem ser uma parte explícita do ciclo de vida do projecto de ciência de dados. Melhor ainda, uma prática de ciência de dados deve ser posicionada dentro de uma estrutura de concepção centrada no ser humano. Para além dos testes com utilizadores, essa estrutura poderia obrigar à investigação do utilizador no front-end do processo de ciência de dados.

ERRO 5 – Os difíceis últimos metros

A iniciativa “win-back” do banco, criada para recuperar clientes perdidos, não fez progressos durante meses. E a reunião desse dia entre os cientistas de dados e os gestores de produto, que deveria colocar a iniciativa no bom caminho, também não estava a correr bem.

Os cientistas de dados Dhara e Viral estavam concentrados em identificar quais os clientes perdidos com maior probabilidade de voltarem ao banco, mas os gestores de produto Anish e Jalpa queriam discutir os pormenores da campanha seguinte e pressionavam os cientistas de dados a assumirem imediatamente a responsabilidade da sua implementação. Após o adiamento da reunião, sem qualquer avanço, Viral desabafou com Dhara: «Se os cientistas e analistas de dados fazem tudo, para que é que o banco precisa de gestores de produto? A nossa tarefa é desenvolver uma solução analítica; a tarefa deles é executá-la.»

Na reunião seguinte, porém, Viral parecia ter mudado de ideias. Fez um esforço para compreender porque é que os gestores de produto insistiam sempre para que os cientistas de dados assumissem a responsabilidade da implementação. Descobriu que, em várias ocasiões no passado, o departamento de sistemas de informação dera aos gestores de produto listas de clientes a serem alvo de uma recuperação que não fora bem-sucedida. Na verdade, a utilização das listas tinha sido um enorme desafio, em parte devido à incapacidade de monitorizar os contactos com os clientes – por isso, os gestores de produto sentiram que receber outra lista de clientes alvo iria simplesmente conduzi-los a outro fracasso.

Com esta nova noção do problema do ponto de vista dos gestores de produto, Viral e Dhara adicionaram ao seu plano de projecto o desenvolvimento de uma aplicação de software de front-end para os operadores de telemarketing do banco, equipas de gestão de email, pessoal das sucursais e equipas de activos. Isto proporcionou-lhes uma ferramenta onde podiam colocar informações sobre as suas interacções com os clientes e fazer melhor uso das listas fornecidas pela equipa de ciência de dados. Por fim, o projecto avançou.

As acções de Viral e de Dhara exigiram um grau invulgar de empatia e iniciativa. Eles saíram das suas funções como cientistas de dados e agiram mais como líderes do projecto. Mas as empresas provavelmente não deveriam depender dos cientistas de dados para tal, e podem não o querer – afinal de contas, os conhecimentos técnicos dos cientistas de dados são um recurso escasso e caro.

Em vez disso, as empresas podem envolver os cientistas de dados na implementação de soluções. Um banco no nosso estudo conseguiu isto, acrescentando estimativas do valor comercial fornecido pelas soluções dos cientistas de dados às suas avaliações de desempenho. Isto motivou os cientistas de dados a assegurar a implementação bem-sucedida das suas soluções. Os executivos do banco reconheceram que isto por vezes fazia com que os cientistas de dados operassem demasiado fora das suas responsabilidades atribuídas. Contudo, acreditavam que assegurar a entrega de valor justificava o desvio de recursos da ciência de dados, e que este poderia ser corrigido caso a caso, se o impacto negativo das responsabilidades centrais dos cientistas de dados se tornasse excessivo.

Os erros que identificámos ocorreram invariavelmente nas interfaces entre a função de ciência de dados e o negócio em geral. Isto sugere que os líderes deveriam adoptar e promover uma concepção mais ampla do papel da ciência de dados dentro das suas empresas – uma concepção que inclua um maior grau de coordenação entre os cientistas de dados e os colaboradores responsáveis pelo diagnóstico de problemas, administração de processos e implementação de soluções. Esta ligação mais estreita pode ser conseguida por vários meios, incluindo formação, observação, colocação e oferta de incentivos formais. O resultado será menos falhas nas soluções, tempos de ciclo de projecto mais curtos e, em última análise, a obtenção de um maior valor comercial.

Artigo publicado na Revista Executive Digest n.º 181 de Abril de 2021