analytics – Analítico

Consertando o People Analytics

Não ouvir todos os clientes e falta de transparência pode ser fatal para o People Analytics

Navegando pelo LinkedIn, quase diariamente observo críticas aos serviços de People Analytics focados em recrutamento, principalmente Gupy e Kenoby. As reclamações são de candidatos frustrados com processos seletivos longos, cheios de testes e sem feedback algum sobre o resultado.

Nas últimas semanas, em face ao aumento dessas reclamações, vejo que as plataformas estão ficando mais ativas em responder às reclamações nas redes sociais, porém na maioria das vezes apontando os clientes como os responsáveis pelas informações, feedbacks e configurações da plataforma.

Em um estudo recente de Harvard + Accenture (leia aqui), vê-se que isso é um problema que afeta trabalhadores em diversos mercados, deixando muitas pessoas em um limbo que não existiria quando os processos seletivos não eram gerenciados por algoritmos e sim por pessoas.

Mas a tecnologia veio para ficar e ajudar recrutadores a processar centenas de aplicações da maneira mais eficiente, selecionando os melhores candidatos para as vagas. Porém acredito que exista uma maneira de realizar essa façanha e ainda dar aos candidatos e candidatas uma experiência muito melhor.

Não existe apenas um cliente

Acreditar que apenas o cliente que paga a sua fatura é o que importa talvez seja o principal erro. Em um projeto de produto ou serviço deve-se envolver todos os tipos de clientes, conhecer suas histórias, seus desafios e a partir daí construir soluções. Vejamos um exemplo:

“Como candidata, gostaria de saber quais os pontos fortes – ou fracos – que me ajudariam a conseguir a vaga” .

Um time de desenvolvimento traduziria isso em um indicador ou insights para a candidata ter ideia de suas chances. Inovador? Nem tanto! O próprio LinkedIn já fornece esse tipo de informação para assinantes premium, do tipo “Você está entre os 25% melhores”.

Transparência

Há regras nas contratações – traduzidas para os algoritmos – que não são explícitas, seja por intenção (design) ou não.

O contratante pode ter uma vaga na cidade do Rio de Janeiro e receber aplicações de pessoas de todo o Brasil. Ele pode não dizer explicitamente que não aceita candidaturas de outras regiões, porém o sistema pode dar preferência aos candidatos geograficamente mais próximos e deixar alguém disposto a se realocar ao Rio de Janeiro no final da fila. Um exemplo que mostra que a máquina simplesmente reflete o que aconteceria numa análise manual.

Algo menos explícito seria preterir uma candidata por ter ficado 2 anos fora do mercado. O sistema não perguntará o motivo para isso – uma gravidez? problemas de saúde? período de estudo ou sabático? – ele simplesmente empurrará para o final da fila.

Essas regras não são transparentes para os candidatos mas são para os desenvolvedores de algoritmos e para os clientes. E qual o problema em dar transparência às regras?

O exemplo da SerasaExperian

Um exemplo interessante é o score de crédito da SerasaExperian. Além de mostrar qual seu score numa escala de 0-1000, ele mostra exatamente o que está levando seus números para cima ou para baixo. Insights do tipo “Você pagou 90% do seu último empréstimo e isso é bom para seu score” mostram o que você está fazendo certo ou não e que podem não ser óbvias para o usuário comum.

Para beneficiar as empresas de crédito (que são os principais clientes da SerasaExperian) eles investiram na experiência do cliente final, dando informação e transparência nas regras.

Quem sabe no futuro uma plataforma de People Analytics pode mostrar para o candidato do tipo: “Você ficou menos de 6 meses em seus últimos 2 empregos e isso é negativo para sua candidatura”.

Entendendo o fracasso dos projetos de Data Analytics

Projetos morrem constantemente pois usuários simplesmente deixam de usá-los. Mas como aumentar o valor evitar que caiam no esquecimento?

O sucesso ou fracasso de um projeto de Analytics – aliás, de quase todos os projetos de tecnologia de produtos ou serviços – baseia-se na adoção do novo produto/serviços pelos clientes.

Sucesso é medido não apenas nas características do produto, e quando se fala da área de Analytics, há cemitérios cheios de dashboards com lindos gráficos interativos e serviços de insights automáticos que não são importantes para ninguém além dos seus criadores.

A adoção do produto de Analytics envolve vários fatores, tanto intrínsecos ao produto quanto extrínsecos. Vejamos alguns:

O produto só informa o óbvio: Ter um relatório que apenas mostra quais seus produtos mais vendidos, por exemplo, não será uma novidade para a maioria das pessoas. Seu José da expedição pode facilmente dar essa informação. Um produto de inteligência deve oferecer informações que estão muito além da superfície.
Os dados estão errados: Encontrar informações erradas, principalmente nas primeiras interações dos usuários finais com o produto, é o equivalente à um suicídio. Rapidamente cairá em descrédito e a primeira impressão de todos é que o produto não funciona. Analistas devem gastar tempo suficiente em analisar os resultados do modelo e criticá-los. Ter os “advogados do diabo” nessa fase é essencial.
Atualizações não são constantes: Assim como erro de dados, usuários que interagem com seu produto ou serviço de dados e enxergam sempre o mesmo resultado em breve vão simplesmente ignorá-lo. Será como um quadro ruim numa parede: depois de um tempo você nem lembra que está lá. Atualizar frequentemente as informações e o próprio modelo estatístico é essencial para que usuários percebam a dinâmica dos negócios.
As pessoas não entendem o conteúdo: Entender algoritmos, modelos estatísticos e gráficos complexos são assuntos para os Analistas e Engenheiros do produto. Usuários querem informações simples e mastigadas para que possam interpretar e tomar ações rapidamente. Se é necessário explicar muito ao usuário, então algo está sendo feito errado.
O serviço/produto não é importante para o cliente: Projetos já nascem mortos dessa maneira. Não levar em conta as reais necessidades do cliente e o que é valorizado pelos usuários invalida todo o trabalho. Há necessidades explícitas e implícitas das pessoas em um produto ou serviço. Entendê-las e transformá-las em algo útil deve ser a prioridade principal e indiscutível do projeto.

Há formas e metodologias práticas para evitar esses erros no desenvolvimento de produtos e serviços de Analytics. Utilizar as ferramentas de Design Thinking é uma ótima forma de traduzir o que as pessoas querem em algo realmente útil.

Metodologias de Gestão de Mudança também são importantes durante todo o ciclo de um projeto para ter certeza de que as pessoas conhecem, entendem e utilizam o projeto.

E, finalmente, é essencial colher o feedback dos usuários de forma constante e utilizar conceitos de Agilidade e Melhoria Contínua para fazer aperfeiçoamentos constantes no produto, utilizando o erro como uma forma de aprender e ficar mais forte, e não mais próximo da morte.

People Analytics: faça você mesmo

Realizar análises sofisticadas sobre sua equipe não requer investimentos significativos em aplicações. Veja como dar os primeiros passos em People Analytics.

Identificar as pessoas com maior desempenho na companhia, buscar o perfil mais adequado à uma vaga entre milhares de candidatos e prever se alguém irá sair da empresa são algumas das informações que sistemas de People Analytics pretendem responder após analisar seus dados de Recursos Humanos.

Como o próprio nome diz, People Analytics refere-se às informações, insights, previsões e análises que são realizadas com dados de pessoas, ou que podem ser desdobrados em um nível individual. O resultado é utilizado tanto para tomada de ações específicas à um indivíduo quanto de equipes ou na definição de políticas internas.

Contratar Pedro, enviar a equipe de Contabilidade para um treinamento, promover Vanessa, mudar Carlos de equipe, alterar o valor do ticket-refeição são alguns exemplos do que um People Analytics pode sugerir para você.

Aplicações como Gupy, Kenoby, Qualtrics – para citar poucas – estão entre as mais conhecidas nesta arena. Mas o propósito desde post é explicar como iniciar com uma análise de People Analytics sem a necessidade de investir muito capital.

Como começar

Um projeto de Analytics inicia com dados. (Se quiser saber mais sobre o ciclo de um projeto veja esse outro post), portanto melhor arregaçar as mangas:

A quantidade e a variedade de dados faz uma diferença significativa, e isso não significa usar apenas dados muito recentes. Na tabela abaixo há exemplos do que pode ser obtido em diferentes áreas.

Fonte dos dados	Categoria	Dados
Operações	Resultados do indivíduo	Produtividade, Qualidade, Erros, satisfação de cliente
RH	Folha de pagamento e Ponto	Salário, Grupo Salarial, faltas e ausências
	Desempenho	avaliações da chefia, medidas disciplinares, auto-avaliações, avaliação 360°, desligamentos, resultado de entrevista de desligamento
	Comportamental	Perfil psicológico e comportamental, testes de aptidão, lógicos, etc.
	Demográficos	Idade, educação, estado civil, localização geográfica.

O segundo passo é fazer um ‘saneamento’ nos dados e organizá-los para a análise. Isso pode significar eliminar dados não-significativos ou extremos (outliers) e preencher dados faltantes baseado em premissas. Nessa etapa é essencial o envolvimento de alguém com conhecimento da área, para evitar tomar direções erradas.

Organizando para a análise

É nessa etapa que acontece o famoso ‘cruzamento de dados’: juntamos informações de origens diferentes em uma única tabela. Mas para isso acontecer os dados devem estar organizados de maneira individualizada, em uma escala de tempo similar – se aplicável – e as diferentes bases de dados devem possuir uma “chave” para cruzarmos umas com as outras. Esta chave, por exemplo, pode ser a matrícula ou CPF, que são dados únicos por indivíduo.

O resultado é uma grande tabela com todos esses dados juntos, agrupados por indivíduo e por período, que pode parecer com isso.

Esta tabela terá tantas colunas quanto as diferentes variáveis que estiverem disponíveis e o número de linhas será grande: no mínimo o número de pessoas X o número de períodos analisados. Ex.: Uma operação de 50 pessoas analisada durante um ano em períodos mensais terá 50 x 12 = 600 linhas.

Primeiro explorar os dados

Com dados devidamente organizados, pode-se iniciar uma análise exploratória da base. A Análise Exploratória procura mostrar o comportamento das variáveis que coletamos tanto de maneira isolada quanto associada à outras. Informações e insights desta análise são importantes para conhecimento do comportamento dos dados – e também das pessoas e processos – e também para o refinamento da base de dados. Pode-se desconsiderar, por exemplo, uma das variáveis pois ela tem um comportamento errático e não está influenciando nenhuma outra.

Para especialistas: Para um modelamento estatístico, é necessário muitas vezes recorrer à transformações de variáveis para que o algoritmo utilizado tenha melhor desempenho, e a Análise Exploratória é útil para identificar que tipo de transformações são necessárias

Agora o modelamento

O modelo estatístico é, simplificadamente, uma fórmula que foi construída baseada nos dados históricos que construímos. Há diferentes tipos de algoritmos para diferentes aplicações, mas em qualquer uma delas o resultado será tão bom quanto a qualidade dos dados que utilizados.

Há basicamente três tipos de algoritmos que podem ser aplicados à base de dados, e que baseiam-se no tipo de resultado pretendido:

Agrupamento ou Clustering: são algoritmos que irão separar seus dados em ‘famílias’, conforme similaridade entre os dados. Pode-se identificar, por exemplo, o que difere os grupos de pessoas de alto desempenho das demais.

Classificação: Quando é necessário separar ou prever o resultado de uma maneira categórica, geralmente obtendo uma resposta sim/não. Uma aplicação comum é prever se alguém irá deixar/permanecer na companhia.

Algoritmos de Regressão são usados para prever resultados numéricos. Prever qual será a produtividade de um indivíduo no próximo mês pode ser uma das aplicações.

Na tabela abaixo organizo alguns exemplo da aplicação dos algoritmos, conforme a necessidade:

O que descobrir	Tipo de decisão	Algoritmos
– Alguém vai sair ou não da empresa – Pessoa deve ou não ser promovida – Contratar ou não contratar	Classificação (Sim/Não)	Regressão logística, Árvores de decisão, Bayes, K-neareast nighbors
– Produtividade no próximo mês – Quantas ausências terei na equipe	Regressão (resultado é um número)	Regressão linear
– Comportamento de grupos por similaridade (alta performance, experientes, novatos, etc)	Agrupamento (Famílias)	k-means

Como seguir em frente

Posso fazer isso sem comprar uma solução? Sim, é possível. Contruir um protótipo utilizando uma base de dados de pequeno porte e Excel é uma opção viável. O Excel possui alguns poucos algoritmos de regressão/classificação que podem ser usados para começar.

Porém o Excel fica muito limitado para um desenvolvimento real, pois há limitações de velocidade, ferramentas e integração com outras aplicações.

Para um desenvolvimento completo, com uma base de dados extensa e flexibilidade para usar quaisquer algoritmos, pode-se usar uma construção em R ou Python, que são códigos abertos e possuem bibliotecas extensas para analisar, modelar e visualizar os resultados.

Na prática

Utilizar People Analytics na prática envolve alguns cuidados. Todo resultado proveniente de um modelo é baseado em um histórico passado e todo modelo tem uma margem de erro. Usar um resultado do modelo sem uma avaliação crítica é um risco muito grande.

Uma preocupação evidente é no aspecto ético. As variáveis utilizadas no modelo irão determinar o resultado, portanto selecionar as variáveis corretas passa por uma crítica ética. Para dar um exemplo prático: Mães com filhos pequenos e que moram longe do trabalho podem ter dificuldade em estar presente todos os dias do mês e sem atrasos. Utilizando o estado civil, distância do trabalho e número de filhos de uma funcionária e cruzando isso com outros dados de desempenho, o modelo pode classificá-la como um perfil de alto risco. Sem uma avaliação crítica o time de recrutamento rejeitará esses perfis sem nem se dar conta.

Selecionando a metodologia certa para o projeto

Comparando o ciclo de vida, segundo diferentes metodologias de projeto.

Diversas metodologias podem ser usadas no processo de melhoria, transformação, solução de problemas e inovação. Cada uma possui seu próprio ciclo de vida, mas teriam algo em comum? Ou haveria diferença significativa?

A seleção usualmente é baseada no objetivo do projeto, que pode ser resolver um problema trivial ou a criação de um produto inovador.

Para um mesmo objetivo, mais de uma ferramenta pode ser selecionada (por exemplo: PDCA x A3). Para outras situações, uma metodologia é evidentemente melhor e sem substituto.

Vale lembrar que nem todas são lineares. Muitas delas, como Design Thinking e Analytics envolvem um processo iterativo até chegar no objetivo final.

Compare no infográfico onde está cada uma delas em termos de início, meio e fim.

Como estruturar um programa de melhoria contínua em 2021

O que difere um programa de melhoria contínua de 2021 com aquele de 10 ou 20 anos atrás? Será que existe mudança na essência ou apenas na aparência?

Os saltos de tecnologia, especialmente ligados à exploração de big-data, redes sociais, inteligência artificial e comunicação em alta velocidade são as mais óbvias mudanças.

Mas existem outras na essência. Há mais demanda por velocidade e inovação hoje, o que deixou iniciativas como ISO 9000 e Six Sigma em segundo plano, enquanto Lean – também repaginado em metodologia ágil – e design thinking ganharam protagonismo. Na era da velocidade e da inovação é essencial errar logo, aprender e tentar novamente. Done is better than perfect.

A melhoria contínua saiu da responsabilidade de um time de Gestão da Qualidade, para todos os outros setores: Operações, Logística, Produção, Financeiro, Atendimento ao cliente, Vendas, e assim por diante. E hoje as iniciativas de melhoria ou transformação de processos tem uma estrutura descentralizada na execução, mas como um escritório central – chamado de PMO, VMO, Escritório de Processos, Centro de Excelência – que orienta as práticas e gerencia o portfólio de projetos.

Outros aspectos continuam na essência da filosofia: foco na satisfação do cliente, redução de desperdícios e do custo da má-qualidade, olho em indicadores, prevenção acima de correção, combinar melhorias incrementais com saltos de inovação.

Enxergo nesse contexto 6 componentes essenciais nessa estrutura de melhoria contínua de 2021. Podemos chamar também de pilares, mas creio que é outro termo saindo de moda!

A Organização que busca a melhoria contínua possui poucos objetivos, não porque não almeja grandes coisas, mas porque possui um foco centralizado em clientes, acionistas, empregados e na comunidade. Ela é capaz de investir e sacrificar o curto prazo para retornos consistentes no longo prazo. Ela incentiva a inovação e todas as falhas relacionadas ao processo de criação, porém demanda que isso aconteça em ciclos rápidos e a implementação mais rápida ainda. A melhoria contínua é parte dos seus valores. Não tolera falta de ética e atalhos que não sejam compliants.

O estilo de Gestão escolhido pela empresa – não só para a área de melhoria contínua – preza pelo empoderamento das pessoas para resolver os problemas e inovar. As barreiras hierárquicas são quebradas para uma gestão mais ágil de projetos. Equipes (ou squads) multi-funcionais estão executando projetos de uma maneira que silos e estruturas departamentais são facilmente quebradas. Os processos e projetos são realizados com uma visão de ponta-a-ponta, e monitorados com indicadores (OKRs, KPIs, e outros) gerenciados, por sua vez, de maneira pro-ativa.

Pessoas que compõe o time de melhoria contínua são treinadas nas técnicas e habilidades em diferentes níveis. Elas são reconhecidas e incentivadas a melhorar processos e a si mesmas. À medida que crescem na empresa são capazes de resolver problemas mais complexos. Indicadores individuais de desempenho são medidos e informados claramente em todos os níveis.

Processos são estruturados, com início, meio e fim. Enxutos para entregar o máximo de valor com mínimo desperdício, adaptáveis às mudanças necessárias. Controlados por indicadores que estão atrelados ao sucesso do negócio. Propriamente documentados para treinamento, auditoria, segurança de informação e compliance. Atividades repetitivas são automatizadas. Pessoas focam o trabalho em análise, solução de problemas e maximização dos resultados da empresa. Priorizam o resultado do negócio, e não apenas pequenos sucessos isolados.

A organização também deve estar bem munida de Tecnologias para alavancar seu desempenho e competir. Primeiramente deve conhecer quais as ferramentas estão disponíveis e podem ser usadas. Benchmarking dentro e fora de seu campo de atuação deve ser usado para identificar pontos de melhoria. Um roadmap deve ser criado para implementar ou expandir as tecnologias, sem deixar de lado uma análise criteriosa de ROI/business case para os projetos. Fazer parcerias é chave, e isso se aplica até com os competidores. O vocabulário básico de tecnologia inclui Digitalização, ChatBot, Analytics, APIs, IoT, Aplicativos Móveis, OCR, Machine Learning, Visão Computacional, Nuvem.

Técnicas e habilidades são, em parte, dependentes do que foi escolhido entre os demais itens explicados acima. Mas em regra geral a organização, através das pessoas, deve ter a capacidade de analisar e resolver problemas. Ferramentas de conhecimento e aplicação geral como Agile, Lean, Six Sigma, Analytics, Design Thinking, BPM, Gerenciamento de projetos, Kanban e Estatística básica sempre devem estar presentes. E claro, o conhecimento da indústria ou domínio específico que se está inserido é um diferencial importante para extrair o máximo das ferramentas.

Acredito que o nível de maturidade em cada um desses componentes – e não apenas em Tecnologia – deve demonstrar se o programa de melhoria está na velocidade de 2021 ou ainda correndo atrás do futuro.

Transformando perguntas em respostas usando dados

Em um post anterior eu descrevi como é o início do processo de tomada de decisão com dados, e da necessidade de ter dados confiáveis. Se fosse organizar um livro, talvez o artigo abaixo devesse ser um capítulo anterior, pois minha ideia é explicar o fluxo macro do processo de análise de dados.

O propósito da análise de analisar dados é transformar perguntas em respostas. Uma pergunta pode ser desde uma provocação, uma curiosidade científica ou uma necessidade de negócio. A resposta, da mesma maneira, pode variar desde uma declaração curta (mas embasada) até um produto físico ou virtual que responde ao questionamento inicial.

Podemos enxergar o trabalho analítico e de ciência de dados como um ciclo de ações que após algumas iterações nos dará um resultado. A figura abaixo demonstra esse fluxo de trabalho

Começamos, primeiramente, com perguntas do tipo “Por que….?”, “E se….?”, “Como …. ?”, que podem vir tanto de nossa curiosidade como de nossa necessidade. E essas perguntas podem ser vagas ou muito abertas, mas isso não as torna menos importantes.

Como analistas – não no sentido de nome de cargo, mas como indivíduo que irá fazer uma análise – temos que buscar respostas para essas perguntas. E isso pode incluir o detalhamento, refinamento ou releitura completa da pergunta original.

Com uma pergunta na cabeça, vamos à coleta de dados. Coletar dados também pode variar desde o aperto de um botão até um projeto complexo em si. A demanda tão grande por Engenheiros de Dados atualmente é parte desse contexto onde é necessário extrair dados e deixá-los acessíveis para as análises.

Se dados são o novo petróleo, vamos imaginar que primeiramente precisamos extrair o petróleo e refiná-lo para depois vendermos gasolina. Coletar dados, seja com pesquisa de campo, medições, formulários ou extrações de um banco, é dos primeiros e fundamentais passos para uma boa análise.

Mas dados brutos raramente podem ser usando sem um refinamento ou transformação prévia. É necessário organizá-los, filtrá-los, cruzá-los com outros dados, transformá-los para enfim poder utilizá-los.

O resultado desse processo de refinamento é uma base de dados organizada e pronta para a análise. Os dados aqui estão prontos para o que o analista quiser fazer: visualizar, testar hipóteses, criar modelos estatísticos, previsões, etc.

Normalmente você não terá sorte de ter todas as respostas com a base de dados que você montou (ou montaram para você). Você precisará de mais dados – ou talvez menos, transformações diferentes, categorizações diferentes, formatos diferentes. Assim você trabalha para ter uma nova base organizada para reiniciar sua análise.

A interpretação dos resultados é essencial para concluir a análise, ou fazer novas perguntas que reiniciarão o ciclo, até que você esteja satisfeito com os resultados.

Com o resultado completo, é hora de comunicar. Essa etapa, como comentei, também pode variar significativamente de tamanho. Pode ser um relatório ou pode ser um projeto em si, tornando sua análise e seu modelo de machine learning um produto.

Essa estrutura básica é o que forma hoje um ciclo de um projeto de Ciência de Dados, e que permeia tanto a abordagem científica de descoberta e teste de hipóteses quanto a aplicação e comunicação e ação prática que a realidade necessita.

Identificando projetos de Analytics

Um Projeto de Analytics é uma iniciativa de melhoria de negócios baseada em uma profunda análise de dados e que entrega um produto final previamente acordado.

Assim como os demais projetos de melhoria e transformação de negócios, essas iniciativas precisam focar na resolução de um problema específico, mesmo que o escopo seja amplo.

O produto ou tipo de projeto de Analytics pode ser dividido nas seguintes categorias:

Análise descritiva

Como o próprio nome diz, nessa análise o objetivo é descrever o que está acontecendo. Dados são analisados dentro de um objetivo de negócio, como mostrar perfil dos clientes que visitam a um site de e-commerce, Análise de vendas por produto e por cliente, Desempenho de linhas de produção, etc.

O produto dessa análise, geralmente um relatório ou dashboards com os dados mais relevantes, dá mais visibilidade do que está acontecendo nos processos estudados.

Análise diagnóstica

É uma análise de dados históricos que é, em fato, uma análise de causa. Ela não só mostra o que está acontecendo mas também diz por quê. Ela pode inclusive responder à perguntas similares a testes de hipótese: Medicamento A é mais eficiente que Medicamento B?, Quem trabalha em home office tem maior produtividade que aqueles que trabalham em escritório?, Qual ação de marketing deu maior impacto nas vendas?

Análise preditiva

Na análise preditiva espera-se prever o futuro (com certa margem de erro, claro). Constrói-se um modelo estatístico utilizando dados históricos e aplica-se este modelo para dados novos/desconhecidos. Modelos aqui podem ser desde simples regressões lineares até redes de Deep Learning, mas que responderão – com certa margem de erro – qual a probabilidade de um cliente fazer uma compra do produto caso ele tenha acessado o site, qual a vida útil de um componente, qual a probabilidade de um político ganhar uma eleição.

Análise prescritiva

Nesta análise você confia ao modelo estatístico a prescrição ou sugestão de uma ação. A decisão em si nem sempre faz parte do pacote, mas os modelos, nesse caso, usarão a opção com maior probabilidade como sugestão de ação.

O exemplo comum é sugestão de produtos baseado em suas visitas ou compras anteriores. O sistema lhe sugere comprar pilhas junto com uma boneca que fala pois diversos clientes fizeram o mesmo no passado.

Também é dessa maneira que um sistema como Uber ou 99 usam para designar um motorista quando você solicita.