O assunto Big Data tem tomado pelo menos 80% do meu tempo e embora sua prática ainda seja incipiente aqui no Brasil, aqui e ali já observo um certo amadurecimento do conceito. Tecnologia ainda domina corações e mentes de muita gente que está interessada no tema. Tem explicação. Tecnologia por si tem seu charme e existe uma pressão muito grande dos fornecedores de soluções tecnológicas, que têm que cumprir suas quotas de vendas de produtos. Assim, existe uma pressão natural para que os clientes comprem suas soluções. O problema para o qual a solução foi comprada, vê-se depois… Big Data não é apenas tecnologia e centrar discussões neste tópico é um caminho quase certo para o fracasso de suas iniciativas.
Mas algumas questões fundamentais, que envolvem pessoas e processos ainda passam ao largo. Por exemplo, quem deve liderar as iniciativas de Big Data na empresa? Big Data exige governança? Como criar uma equipe para projetos deste tipo? O Data Scientist existe mesmo ou é um unicórnio? É necessário ter um CDO (Chief Data Officer) e se sim, a quem ele deve se reportar? Ao CEO, ao CIO, ao CFO ou alguma outra área como marketing?
Um aspecto que quase ninguém aborda é o fator cultural. Como qualquer conjunto de novas tecnologias, sua adoção passa por mudanças no mindset e cultura da organização. Podemos recordar aqui algumas mudanças tecnológicas que encontraram muita resistência no início, chegaram a ser combatidas, mas que provocaram mudanças de paradigmas. Cito a transformação do modelo centralizado em mainframes para o distribuído, baseado na arquitetura cliente-servidor, a criação e expansão do comércio eletrônico e, mais recentemente, a cloud computing e a adoção da mobilidade.
O mesmo está acontecendo com Big Data. Há os que dizem que já fazem há muito tempo, que Big Data nada mais é que o velho Data Warehouse de sempre e que não apresenta realmente nada de novo. Por outro lado há o grupo que diz que é tudo novo, e que existe uma demanda para um profissional chamado Data Scientist (Cientista de Dados), uma figura quase mítica. Mas pouco se comenta dos aspectos culturais e organizacionais. Por exemplo, uma empresa recruta alguns cientistas de dados, uns caros desenvolvedores em Hadoop, cria a função de CDO e assim por diante. Mas como inserir este grupo na organização? Que projetos desenvolver e como avaliar se estes projetos estão realmente trazendo valor para a empresa?
OK, ainda não existem metodologias comprovadas e muito menos certificações de maturidade para o processo de desenvolvimento de projetos Big Data, a não ser um apanhado de experiências ad hoc, aqui e ali, algumas que deram certo e outras não. Mas, algumas primeiras lições começam a ser aprendidas.
Por exemplo, é fundamental ter um sponsor de alto nível na organização. Um projeto de Big Data feito dentro da TI, com pouca visibilidade externa,simplesmente não vai decolar. Big Data demanda principalmente variedade de dados, geralmente oriundos de diversas fontes espalhadas por diversos sistemas e áreas da organização. Sem a colaboração dos setores envolvidos, não se vai longe. E olhem que nem abordei acesso a dados externos à empresa…
Também é importante criar projetos que sejam gerenciáveis (impossível abraçar o mundo) e envolver os usuários em todas as etapas. Uma boa alternativa é gerar entregáveis com certa periodicidade, de modo que a cada etapa os resultados consigam ser tangibilizados claramente, mantendo sempre aceso o entusiasmo e o comprometimento dos usuários.
Outro item essencial: definir claramente os objetivos de negócio, quais problemas as iniciativas de Big Data irão resolver. Um projeto de Big Data deve ser “use case-centric”. Identifique claramente um problema e então desenvolva o projeto. Nunca o contrário. Montar uma plataforma tecnológica, adquirir caras soluções tecnológicas, recrutar equipe e ficar aguardando os pedidos dos executivos da empresa é jogar dinheiro fora. É criar a solução e depois esperar que os problemas apareçam. Sem objetivos definidos, não aparecerão pedidos de projetos…
Uma terceira recomendação. Fala-se muito nos insights que podem ser gerados pelo Big Data, mas o essencial é como traduzir estes insights em resultados tangíveis, em valor real para o negócio. Projetos de Big data devem ser vistos como projetos geradores de novas receitas ou de redução significativa de custos. Uma boa estratégia é primeiro identificar as “dores” do negócio e só então propor uma solução que envolva Big Data para resolvê-las. Neste sentido, vamos ver que a tecnologia vai surgir naturalmente no fim do caminho e não no seu início.
Um aspecto que passa batido é que muitas vezes um projeto de Big Data vai demandar mudanças nos processos da organização. Por exemplo, vejamos uma rede varejista. Com informações fácil e rapidamente disponíveis para um gerente de loja tomar decisões em tempo real, como promoções, mudar preços e assim por diante, a diretoria deixará de ser a única responsável por estas decisões. A empresa está cultural e psicologicamente preparada para dar este salto?
Temos também a questão da equipe. Dificilmente conseguiremos pessoas que atendam a equação hackers + profundos conhecimento estatísticos e matemáticos + bons conhecimento de negócio. Uma sugestão é montar uma equipe multidisciplinar e operacionalizar os processos que envolvam os projetos Big Data. Claro que a equipe deve ter um bom gestor, que consiga entender as diversas linguagens faladas por profissionais tão diferentes entre si e que seja apaixonado pelo conceito dos projetos. Um gerente burocrata não vai conseguir desfiar os inevitáveis problemas de comunicação inter e intra equipe. E montar uma equipe apenas com hackers, por exemplo, pode gerar um algoritmo preditivo sensacional, mas de pouco valor para a empresa. Afinal, o objetivo não é gerar modelos analíticos fantásticos, mas sim resolver problemas do negócio.
E, onde colocar a equipe de Big Data? Não existe resposta única. Pode ser ligada ao CEO, se a empresa estiver em um grau de maturidade adequado para reconhecer a importância do Big Data para seu negócio e entender e buscar mudanças de ruptura que poderão ser provocadas por estes projetos. Pode ser ligada ao CIO, mas tomando-se as devidas cautelas para não ficar preso aos modelos e práticas típicas de muitas áreas de TI, com longos e burocráticos processos de aprovação de projetos. Corre o risco também de se envolver de forma muito tática e pouco estratégica. Pode ficar com o CFO, mas pelas próprias características desta função, inevitavelmente, vai se concentrar em inovações incrementais e não disruptivas. Pode ficar com CMO, mas correndo o risco de focar especificamente em atender as demandas de marketing. Enfim, cada caso é um caso e nada também é eterno. Pode-se começar com a equipe ligada a um executivo e ao longo do tempo ser transferida para outro.
Finalmente governança. Big Data exige governança. Pelas características de volumes muito grandes e variados, com dados não estruturados (antítese do modelo estruturado e relacional que estamos acostumados) tende-se a não documentar e nem criar processos de governança. Com isso, corremos o risco de reinventar a roda constantemente. Big Data é diferente do modelo tradicional, desenhado para responder a uma série de perguntas previamente definidas. Big Data permite que perguntas não previstas possam ser respondidas e portanto não pode ser limitada por estruturas rígidas como no modelo relacional. Mas, flexibilidade não significa que não seja importante criar processos de governança.
Big Data não é tecnologia. Não é Hadoop. É uma mudança de mindset. Envolve novas e antigas tecnologias, mas a grande transformação é a revolução nos negócios que pode potencialmente provocar na organização. Sem esta percepção claramente reconhecida, Big Data será mais um conjunto de tecnologias inseridas no portfólio tecnológico da empresa. De pouco valor.
*Cezar Taurion é CEO da Litteris Consulting, autor de seis livros sobre Open Source, Inovação, Cloud Computing e Big Data
