Há coisas que são um completo mistério para mim. Por exemplo, porque algum professor acredita que um trabalho em grupo pode produzir conhecimento para os alunos.
Quero dizer, todo mundo sabe: um cara faz e o outros olham. Eu sempre fui assim, fazia tudo e mandava os outros ficarem calados e quietinhos – eu não queria nenhum mané estragando minhas notas, ou pior: ter que explicar tudo para eles! :-P
Mesmo assim, trabalhos em grupo viraram um componente básico de tudo quanto é curso. Eu estou fazendo um segunda graduação e todo santo semestre eu preciso entregar um trabalho em grupo, o famigerado Projeto Integrador.
A idéia – como todas as idéias – tem lá o seu sentido: dar aos alunos um espaço para aplicar o que aprenderam ao longo do semestre. Mas, como todas as idéias, há uma grande diferença entre a imaginação iridiscente dos docentes e a dura realidade discente.
O problema mais frequente é justamente um só aluno assumir o trabalho pelo grupo, quando os alunos simplesmente não saem no tapa por causa do projeto. (Sim, brigas que não chegam às vias de fato porque o curso é 100% EAD.)
Parte da nota da matéria é uma auto-avaliação, cujos critérios são dados pelo instrutor e cada membro atribui a si mesmo quanto acredita que merece. Neste semestre, porém, veio uma novidade: nós, membros do grupo, deveríamos escolher três critérios de auto-avaliação e realizar a avaliação de cada membro por estes critérios.
Caramba!
É fácil se atribuir nota máxima para um critério vago como “Dedicação ao resultado” ou “Participou ativamente” – afinal, são muito subjetivos. Mas quando te dão a responsabilidade de criar o critério, você enfrenta um problema muito pior:
Se você criar um critério fácil, o instrutor vai notar que você está tentando se safar e conseguir uma nota alta – ou seja, está sendo imoral;
Se você criar um critério difícil, vai prejudicar a si e aos seus colegas, fora o papel de bobo de ter se dado uma meta que você sabe que não atingiu.
E agora, José?
Como físico e um cara de BI, eu tratei o problema como um assunto de negócios. Primeiro, eu me coloquei no lugar do professor e me perguntei o quê, em um trabalho em grupo, eu gostaria que acontecesse. Achei isso:
Que o volume de trabalho fosse dividido de maneira equilibrada entre os membros;
Que a dedicação de um membro (ou falta desta) impactasse o grupo como um todo;
Que os membros levassem suas tarefas à sério e não desemcumbissem-se meramente para cumprir tabela.
Pensei em alguns outros parâmetros, mas acabei ficando com esses por entender que são mais fundamentais.
Como sabemos de Lean, uma forma de provocar um comportamento é medi-lo. Logo, eu precisava criar métricas objetivas que levassem os alunos a se auto-organizar e se policiarem mutuamente.
Depois de alguns momentos de rilhar de dentes, cheguei nestas métricas:
Colaboração
A qualidade do resultado final é diretamente dependente do entrosamento e do trabalho em time. Um cara que nunca aparece nas reuniões e nunca participa das discussões é a raiz de um problema: se ele não entendeu como as tarefas foram definidas e divididas, ele provavelmente vai dar mais trabalho e gerar menos resultado.
Por isso eu defini a nota de Colaboração como uma nota individual, representando um percentual de participação em reuniões, indo de zero porcento (nunca deu as caras) à 100% (esteve em todas!)
Entrega
Além de trabalhar em time, colaborando com os colegas, o integrante precisa ser responsável e realizar as tarefas distribuídas para ele e precisa fazê-lo dentro de um prazo, com qualidade.
Putz, qualidade? Isso não é subjetivo? Sim, mas eu achei uma forma: cada membro tem sua tarefa revisada por pelo menos dois outros (somos em seis no meu grupo.) Assim cada um tem que prestar contas aos colegas, que por sua vez não vão aceitar um resultado que vão prejudicá-los adiante. Em outras palavras, eu dei um jeito de enfiar a coação social do Scrum no trabalho de escola. U-lá-lá!! :-D
Resta a questão de dar um número para isso. Eu chamei essa métrica de Entrega, indivual, como uma média aritmética de dois outros parâmetros: “Dentro do Prazo” e “Qualidade”.
“Dentro do Prazo” é calculado como a distância entre a data na qual o aluno entregou a sua parte e o deadline para aquela parte. Se ele entregar antes ou no dia, recebe 10 em Entrega, com penalidade de dois pontos a cada dia atrasado, até ter zero se atrasar cinco ou mais dias.
“Qualidade” eu defini quase do mesmo jeito: uma nota começando em 10 e caindo 1 ponto a cada erro encontrado por outro membro da equipe. Assim, dez erros daria zero e nenhum erro, nota máxima.
Finalmente, nota Entrega = (Dentro do Prazo + Qualidade ) / 2.
Ah, os números. Eles realmente são mágicos!! Agora eu já tinha duas notas para nos avaliar! Que alegria! :-)
Só que o curso exige três notas de auto-avaliação. E eu ainda não tinha amarrado a divisão de tarefas. Resolvi criando a última métrica, que pressionasse o aluno a participar do trabalho e se comprometer com o grupo como um todo – algo na mesma linha da primeira métrica, de Colaboração, mas que afetasse todos a partir de um.
Carga
Essa é uma nota única para o grupo inteiro: se um membro fizer corpo mole (ou se um decidir ser fominha, como eu era), o grupo inteiro sai prejudicado.
O truque foi usar uma medida estatística: desvio-padrão.
Como? Fácil: a cada reunião tínhamos uma série de tarefas para fazer, distribuídas entre os alunos. Daí bastou calcular o desvio-padrão usando N como tamanho do grupo, a quantidade de tarefas como cada amostra, e a média de tarefas por membro. Voi-lá!
Como eu quero notas de zero a dez, eu defini: Carga = 10 – 2*sigma.
Se todo mundo pegasse exatamente a mesma quantidade de tarefas, fosse um ou dez, sigma (o desvio-padrão) daria zero e a nota seria 10. Se um só cara fizesse tudo, sigma chegava perto de 5 com apenas 12 tarefas – como se um só acumulasse duas tarefas de todo mundo – e isso nos daria zero.
E porque isso é legal? Ora, por uma simples questão de produtividade! A vantagem do trabalho em grupo sobre o individual é poder produzir mais em menos tempo e com menos esforço. Quando todas as tarefas estão em um único membro, o trabalho atinge a produtividade individual e o valor do grupo vai a zero – que é o que normalmente acontece.
Por outro lado, quanto mais dividida as tarefas são, maior é a produtividade do grupo como um todo – e maior o benefício desse tipo de exercício. Usando sigma eu consegui que mesmo um folgado ou um fominha já ferrasse o grupo inteiro, dando rédeas aos instintos de cada membro.
Eu sou o máximo!!!
Conclusão
Estamos em 2021, já com centenas de anos nas costas usando o mesmo modelo de educação. Esse formato já era, não serve mais e é fácil notar: estamos no meio de um enorme apagão de mão-de-obra. Graças à peste chinesa, está ainda pior porque nossos cérebros estão sendo contratados no exterior, com a mesma facilidade que seriam contratados aqui. Se existe tanta demanda por mão-de-obra, como então não estamos vendo um crescimento explosivo em cursos de formação profissional? Deveria ser o mercado mais aquecido! E não é!
Eu realmente queria deixar aqui as referências – talvez um dia eu volte a este post e conserte esse problema. Agora passa da meia-noite e ainda não entreguei o trabalho da facul e amanhã preciso pular cedo da cama, então vai como está. Sorry. :-(
Porém, um pouco de visão de negócio, uma relada de Lean e uma pitada de Scrum corrigiram – para mim – um problema que me aporrinha desde que eu era um moleque besta na quinta série.
This is Business Intelligenceeeee!!!
OUVIU ISSO, FÊSSOR? É ASSIM QUE SE FAZ!!! PRO INFERNO COM SEU DIÁRIO DE CLASSE!!!
Colocando de outra maneira, e se fosse possível saber hoje, agora, o que vai acontecer dentro de um ano? Que diferença isso faria na sua vida? E na vida de sua empresa ou organização?
Toda Ciência que busca criar um modelo abstrato a partir da realidade tem potencial para prever o futuro. Por exemplo, se você jogar uma pedra para o alto, a Física diz quanto tempo ela vai tomar para cair na sua cabeça, com um erro bem pequeno até. Economia, que anda tão em moda, oferece modelos de resposta ao que acontece quando se atua em certas variáveis e assim por diante – Química, Biologia, Medicina, Farmácia e por aí vai.
Essa é justamente a função central de BI, na minha opinião: estudar o presente para poder estimar o futuro com alguma precisão. Essa previsão pode, então, alimentar as ações do presente, de maneira até mesmo automática, como eu mostrei na série As Soluções Clássicas.
Eu sempre falo de Data Mining, mas nunca mostro. É complicado falar em poucas linhas de um tema tão complexo, tão vasto. Por isso eu decidi fazer um post com uma visão geral de como funciona um projeto de Data Mining. Assim, hoje vamos percorrer esse caminho, do início ao fim. Quem nunca mexeu ou viu o assunto de perto, e só ouviu falar, vai poder fazer uma idéia de como funciona um projeto desses na vida real.
Quanto mais experiente e mais safo é o profissional de Data Mining, o tal do – afff – Data Scientist, mais embolado fica o processo. Com experiência vem a velocidade e a economia de movimentos, o que torna as coisas mais rápidas e fases inteiras podem sumir na cabeça dele. Por isso não se impressione se vir alguém executando apenas uma ou outra etapa, ou mudando a ordem delas, pois provavelmente ele já tem conhecimento suficiente para isso. Ele atingiu o Shuhari.
Vou explicar em poucas palavras o meu cenário, só para não ficar tudo muito etéreo. Daí vamos entrar em Data Mining, com o SEMMA e botar esse lance na rua, usando-o para justificar o nosso (meu ;-) ) salário.
Esse post nasceu com 15 linhas. De tanto eu rever e mudar, acabou como uma verdadeira Introdução Rápida a Data Mining. Na boa, se quiser pular fique à vontade. Semana que vem eu devo trazer a segunda parte do BI Morreu!, que deve ser beeeeem mais curta e muito mais divertida. (Mentira, este aqui está mais. Por outro lado, vai ter Chaves. Putz, páreo duro…)
Você foi avisado. ;-)
Senta que lá vem história!
Zabbix & Data Vault
Estou apoiando a construção de um Data Vault para arquivar os dados de vários [Zabbix][zabbix_bitly]es e, de quebra, facilitar análises sobre eles.
Anteontem eu consegui completar uma transformação PDI que faz a carga de um satélite mais complicado, que captura um histórico que existe no sistema de origem. Ainda não sei se está mesmo certo, e só ontem eu consegui identificar esse tipo de satélite no padrão DV 2.0 e por isso não vou entrar nos seus detalhes.
Aos que, como eu, morrem de véspera: acho que é um tipo status. Assim que eu tiver certeza eu posto aqui uma explicação sobre ele.
E como funciona esse sistema? Bom, o Zabbix monitora um monte de medidas, de um monte de itens. Por exemplo, ele pode acompanhar a quantidade de memória RAM disponível em um servidor. Traduzindo em zabixxês, ele registra uma métrica (quantidade) de um item (RAM) de um host (servidor.) E ele faz isso dentro de um período pré-definido, como uma vez por minuto ou uma vez por segundo.
E o Zabbix faz isso com uma enormidade de tipos de hosts (computadores, roteadores, switchs, sensores etc. etc. etc.), medindo uma infinidade de itens (porta, memória, uso de CPU, disco, tensões, fluxos blá blá blá.)
Cada medida que chega é arquivada em uma tabela chamada history, que guarda a medida atômica. Em uma instalação de maior porte, como a na qual eu estou trabalhando, uma tabela dessas chega a acumular vários milhões de linhas por mês, com até centenas de milhares (ou mais) de novas linhas adicionadas diariamente. E são essas linhas que precisam ser arquivadas no Data Vault. Aliás, usando o jargão DV, é preciso arquivar esse histórico em um satélite.
O primeiro passo para conseguir isso foi descobrir, junto ao cliente, se ele precisa desse dado atômico, ou se contenta-se com uma agregação. Por exemplo, podemos agregar tudo, que às vezes está em segundos ou minutos, para horas. Daí cada item teria no máximo 24 pontos por dia, reduzindo em muito o volume de dados tratados.
E ele podia! Melhor ainda: o Zabbix possui uma tabela auxiliar chamada trends que acumula essa agregação, fazendo o grosso do trabalho com muito mais eficiência. A única coisa que sobreou, então, foi ler a tabela trends e levá-la para o satélite (que seria ligado a um item, que por sua vez tem um relacionamento com um host – ambos hubs):
Diagrama do modelo para Zabbix, hosts, itens e medidas.
Assim, o satélite Item 001 ficou os dados de cada item, o Item 003 com os nomes e o Item 002 com as coletas temporais de cada métrica. Meu trabalho foi justamente resolver o ETL desse satélite – mas esse é assunto para outro dia.
E isso é tudo que você precisa saber sobre o cenário.
Acabou!
… Só que não! Assim que eu versionei e botei o processo no ar, veio a pergunta:
Conversation with XXX on Ter 07 Mar 2017 16:19:37 BRT:
(16:19:37) XXX: Tem pespectiva de crescimento?
Duhn… Me pegou de surpresa. Não, eu não tenho a menor idéia! Mas faz assim: deixa rodar uma semana e extrapola! Que coisa…
Claro que eu não respondi isso. Até admito que isso me passou pela cabeça, mas um segundo depois eu lembrei que a tabela guarda, justamente, histórico! Ou seja, a carga inicial do satélite Item 002 já vem com um histórico! Neste caso, desde 2016. Como possui dados agregados na hora, temos aí pelo menos uns 300 dias de crescimento, carregados de uma talagada só.
Era tentador demais para eu deixar quieto, hehe.
Extrapolando
Ao contrário do que o nome sugere, extrapolar não é dar um pulo a mais, não é extra pular.
Nem tem nada a ver com um super frio, um frio extra-Polar.
Tá-dá-dum-tssssss!!
Fingindo que nada aconteceu, vamos de novo: todo nós fazemos extrapolações, corriqueiras e diárias. Por exemplo, sempre voltamos ao mesmo restaurante porque se ele estava lá ontem, deve continuar lá hoje – extrapolamos a continuidade temporal de uma empresa para o dia seguinte a partir do fato que ela esteve lá nos últimos X dias.
Eu só tinha que fazer a mesma coisa aqui: contar o número de linhas por dia, pegar algumas diferenças entre dois dias e tirar uma média de crescimento diário. Fácil… e extremamente sem-graça.
Para que simplificar, se podemos complicar, não? ;-)
O Problema & Sua Solução
Meu cliente tem um disco rígido com 600 GB reservados para o banco de dados. Comprar disco novo é – apesar de tudo – complicado, já que é um disco especial e coisa e tal. Logo, se o disco não for o bastante para o serviço, ele precisa saber antecipadamente quando vai lotar, para poder agir a tempo de substitui-lo sem interromper o processo de ETL. É um problema clássico da área de TI chamada Capacity Planning.
Quanto tempo de coletas diárias esse HD comporta?
Com que velocidade ele está enchendo?
Quando ele vai estar a 75% da capacidade?
Quando é que eu terei mais 6 meses até ele lotar completamente?
Note que essas perguntas têm uma resposta válida apenas se as condições atuais se mantiverem inalteradas. Por exemplo, a velocidade de ocupação do HD depende que o sistema de origem continue se comportando como vem fazendo até hoje, e que o cliente não inclua mais nada no Data Vault. Mesmo assim, ainda é uma medida com alguma imprecisão – é só pensar em arquivos temporários e auto-gestão do banco de dados (um Postgres, aliás), sistema operacional etc. etc. etc.
Como esse problema é resolvido?
De maneira simples, basta medir a variação de espaço ocupado de um dia para outro, ao longo de algum tempo, e tirar uma média. Por exemplo, suponha que esta tabela mostre a evolução do espaço ocupado dia-a-dia:
Dia
Bytes Gastos
1
1000
2
1100
3
1220
4
1310
5
1460
…
…
Podemos “plotar”[^1] isso. Apelando para o bom e velho LibreOffice Calc/MS Office Excel:
Gráfico de consumo de bytes por dia no HD.
Isso quer dizer que do dia 1 para o dia 2 o HD teve 100 bytes gastos. Podemos fazer uma tabela:
Dia
Delta Bytes
1-2
100
2-3
120
3-4
90
4-5
150
…
…
Somando tudo e dividindo por quatro, temos que cerca de 115 bytes são acrescidos a cada dia – em média. Essa é a velocidade média da ocupação do disco: 115 bytes/dia. Usando isto podemos responder as perguntas:
Quanto tempo de coletas diárias esse HD comporta? R.: 600 GB / (115 bytes/dia) = 5.6e9 dias ~ 15.3 milhões de anos;
Com que velocidade ele está enchendo? R.: 115 bytes/dia.
Quando ele vai estar a 75% da capacidade? R.: 75% de 600 GB = 450 GB. 450×(1024^3)÷115 = daqui a 4.2 milhões de dias, ou 11.3 milhões de anos;
Quando é que eu terei mais 6 meses até ele lotar completamente? R.: Esqueça, isso não vai acontecer nem durante a vida do seu tataraneto. :-)
Pegou a idéia?
Agora vamos tratar os dados que eu peguei do sistema, dentro do processo SEMMA.
SEMMA na Veia
O mundo é um lugar livre, e podemos seguir o caminho que quisermos. Se formos inteligentes, faremos o que outros já fizeram antes de nós e resultou em sucesso. Uma dessas coisas é o processo de garimpagem de dados. Existem dois mais famosos:
O primeiro é mais abrangente e engloba a parte que já fizemos, de entender o negócio e o problema. Ele foi desenvolvido por um consórcio de fornecedores e especialistas, e é bem legal.
O segundo possui essencialmente as mesmas partes, exceto as etapas de entender o problema, e foi criado pelo [SAS][sas_bitly] para suportar o Enterprise Miner, a ferramenta de DM deles. Ele é bem didático e direto e por isso vou usá-lo aqui.
Como sempre, melhor ou pior é algo flexível em BI. Métodos e ferramentas existem aos borbotões por aí e o truque é escolher aqueles que fazem o trabalho que você precisa, sem te aborrecer demais.
SEMMA significa:
Sample
Explore
Modify
Model
Assess
Funciona assim:
Ao invés de pegar o dataset inteiro, escolha uma amostra. Isso é importante porque precisamos reservar uma parte dos dados que estão sendo analisados para testar o resultado, ou seja, para descobrir o quanto a nossa previsão, o nosso modelo, está dentro da realidade. O post A Nuvem Negra discorre um pouco sobre a importância dessa etapa. Os dados usados na modelagem são chamados de dados de treinamento, e o conjunto restante de dados de teste;
De vez em quando temos uma idéia clara do que aqueles dados devem representar, outras vezes não. Por via das dúvidas, explore esses dados de algumas maneiras para tentar apreender o que está acontecendo ali, ou se a sua intuição está bem calibrada. Por exemplo, plote-os ou calcule uma estatística básica (média, mediana, dispersão etc.) sobre eles;
O mundo real é sujo, e dados do mundo real são sujos da mesma forma. Como se isso não bastasse, ainda existem aquelas situações nas quais os dados precisam ser re-alinhados, digamos assim, ou traduzidos. Basta pensar num clássico dos clássicos: uma lista de perfis de compradores, em que o gênero não vem como M ou F, mas como 0 ou 1. Mesmo que possamos usar números, é muito mais prático (e para alguns modelos, imprescindível) traduzi-los para letras. Sempre precisamos olhar os nossos dados e verificar se é preciso modificá-los de alguma forma, e como;
Só então é que podemos partir para os finalmentes: construir um modelo. É a parte mais divertida da bagaça: passar aquela renca de linhas numa regressão polinomial e ver se o Chi-Quadrado está baixo o bastante, é rodar uma clusterização e descobrir se existem grupos óbvios ou talvez nem tanto, e assim por diante. No exemplo de hoje eu vou tentar ajustar os dados a um modelo linear, ou seja, a uma descrição dos dados que se posicionam em uma organização retilínea;
Pronto, certo? Não! É muita inocência acreditar que só porque o modelo mostrou um alto coeficiente R e uma baixa dispersão ele está correto, menos ainda pronto. Há muita coisa que pode (e boa parte vai) dar errado na sua modelagem. Só para começar, você pode sofrer de overfitting, uma situação em que seu modelo explica bem demais os pontos que você estudou, mas muito bem mesmo!, mas falha completamente em qualquer ponto fora da amostra. Por isso precisamos avaliar a adequação do modelo à realidade. É justamente para isso que serve separar o conjunto total de dados em pelo menos duas partes, o que é feito lá na primeira etapa: se os dados são uniformes, e as partições de dados equilibradas, o modelo ajustado em na amostra vai apresentar a mesma precisão na partição restante
Se o modelo ou o particionamento não forem bons o bastante, o ajuste do modelo ao dados de teste vai ser pior que aos dados de treinamento. Se isso acontecer – se o modelo não se mostrar tão bom quanto parecia – mas ainda assim for um resultado bom o bastante para seu uso, o trabalho acabou. Se, por outro lado, o ajuste do modelo aos dados de teste ficar muito ruim, precisamos recomeçar o processo do início: rever amostragem, explorar, modificar a amostra, modelar e testar de novo. Deu certo? Fim! Ainda está ruim? Repita de novo, e de novo até chegar no resultado que você quer, ou provar que não pode ir além daquilo.
Ao trabalho!
Sample
Temos uma tabela que aumenta a cada hora. Ela tem este layout:
Coluna
Tipo
h_item_bk
Bigint
s_item_002_ldts
timestamp
s_item_002_rsrc
Varchar
s_item_002_ledts
timestamp
clock
Bigint
num
Integer
value_avg
Number (16,4)
value_max
Number (16,4)
value_min
Number (16,4)
Dela nos interessa apenas a contagem de linhas por dia. Podemos usar a coluna s_item_002_ldts ou clock para fazer essa contagem, já que são as que guardam o tempo de cada medida. Como a coluna LDTS é do padrão do Data Vault, vamos deixá-la de lado e ficar com clock, que tem mais a ver com o assunto em si.
Só para constar, tanto faz a coluna que escolhermos já que ambas, s_item_002_ldts e clock, são iguais. A primeira é um timestamp no formato AAAA-MM-DD hh:mm:ss.mmm, enquanto que a segunda é a mesma data/hora representado em formato Unix Epoch (a quantidade de segundos desde 1 de janeiro de 1970.)
Quantas linhas são capturadas por hora? A consulta SQL abaixo nos dá essa lista:
SELECT clock,
SUM(1) AS qtd
FROM dv.s_item_002
GROUP BY clock
ORDER BY 1
O resultado é:
Clock
Qtd
1456801200
65
1456804800
68
1456808400
57
1456812000
57
1456815600
63
1456819200
53
1456822800
62
1456826400
56
1456830000
56
1456833600
50
1456837200
60
…
…
Vamos converter clock para data/hora só por curiosidade:
Data/Hora
Qtd
2016-03-01 00:00:00.0
65
2016-03-01 01:00:00.0
68
2016-03-01 02:00:00.0
57
2016-03-01 03:00:00.0
57
2016-03-01 04:00:00.0
63
2016-03-01 05:00:00.0
53
2016-03-01 06:00:00.0
62
2016-03-01 07:00:00.0
56
2016-03-01 08:00:00.0
56
2016-03-01 09:00:00.0
50
2016-03-01 10:00:00.0
60
…
…
Ou seja, existe 65 linhas correspondentes a itens coletados entre a meia-noite e a uma da manhã de primeiro de março de 2016. Daí há 68 linhas na hora seguinte, e 57 logo depois e assim por diante.
O conjunto total que eu tinha para analisar possuía (neste exato instante já é maior) 8.774 linhas. É um conjunto pequeno, então eu poderia analisá-lo inteiramente, mas isso seria conceitualmente errado, e por isso eu vou escolher uma amostra.
Apenas “conceitualmente errado” porque um ajuste de reta tem muito pouco a ganhar separando o volume inteiro em datasets de treino e teste. No final das contas, para uma regressão linear, que é o modelo que eu estou buscando, o resultado acaba ficando até mais próximo da realidade incluindo todo mundo.
Percentual: sorteia-se um X % de linhas do dataset original;
Periódico: pega-se uma linha a cada X linhas;
Particionado: quebra-se o dataset em faixas e pega-se uma quantidade de cada faixa.
Como a intenção é apenas passar pela etapa e cumprir a tabela, vou apelar para uma amostragem simples: [Reservoir Sampling][reservoir_bitly]. A vantagem dessa técnica – para mim, hehe – é que o PDI possui um passo que faz isso. Assim, eu escrevi uma transformação bem simples que lê o dataset original, faz o “sampling” e devolve um dataset de amostra.
Amostragem “reservoir” no PDI.
Pronto, etapa concluída.
Explore
Hora de explorar esse dataset para ver se achamos algum comportamento ou algo que sugira uma abordagem em detrimento de outra.
Como o próprio nome sugere, essa etapa do SEMMA é voltada a examinar o conjunto de dados de várias formas, em busca de alguma pista sobre o quê informação eles guardam. Para isso vale de tudo:
Montar uma tabela com estatísticas básicas: média, mediana, dispersão, máximo, mínimo, esperança etc.
Plotar um gráfico simples, bi- ou tri-dimensional;
Contagens diversas ou construções de clusters.
Qualquer coisa vale, para ser sincero. Se você já está com um palpite, pode testá-lo. Se você acha que uma determinada variável é inútil, pode buscar evidências disso. O importante é que você ganhe um “sentimento de conhecer” o dataset em questão.
E quando você não souber o que usar, use tudo que souber. Cedo ou tarde você vai passar por um momento ah-ha! e a coisa via começar a ficar mais intuitiva.
Já passei algumas vezes por situações em que, de qualquer forma que eu olhasse os dados, nada aparecia. Não tem grilo: ausência de padrão não é um erro, mas um fato. Apenas certifique-se que fez o bastante e, neste caso, mire seu processo em provar que os dados não tem correlação útil. Esse resultado vai te levar a buscar mais dados, ou a abandonar de vez o problema.
Uma vez vi um amigo comentar que trabalhou por meses com uma grande companhia de Internet para tentar analisar os dados de navegação dos usuários. No final eles concluíram que não havia nada para concluir. :-D
Qualquer ferramenta serve, mas eu vou optar pelo [Weka][weka_bitly] porque é a ferramenta de Data Mining tradicionalmente associada ao Pentaho. Existem outras que, na minha opinião, são mais adequadas ao uso em produção (como RapidMiner) ou poderosas (como o R) e oferecem mais possibilidades, mas no momento o Weka basta – poderoso e fácil de usar.
Sem transformar este post em um tutorial, vale a pena dizer só que o Weka facilita o trabalho de explorar: rode-o, selecione o módulo Explorer, clique em Open File e depois em Visualize.
Plot de todas as variáveis contra todas as variáveis no Weka.
Hmm… Lembram-se que nossa intenção original era achar uma “velocidade” para o crescimento do volume de dados? Essa amostra oferece uma séria ameaça a esta idéia. Notou o quadrante superior esquerdo? Ele até acomoda uma reta, mas parece mais uma corcova. Não acredito que ali exista uma exponencial… muito menos uma assíntota.
Hora de pegar outro conjunto de dados: vamos usar tudo, de uma vez – podemo, afinal, já que é pequeno.
De novo, agora com o *dataset* completo.
Ô, diacho! Mesma coisa?!?
Isso quer dizer que 1) a amostra é muito boa, pois é praticamente a mesma coisa que o conjunto original e 2) o sistema exibe um comportamento de tendência a estabilidade. Lembrando que esses dados são a quantidade de dados por hora, vemos que no começo havia muita variação, e aos poucos vai se fortalecendo uma regularidade maior, com uma variabilidade menor.
Opa, descobrimos algo importante! E era isso que eu estava procurando. Agora podemos ver que o sistema está entrando em equilíbrio, e os dados do início são menos relevantes que os dados do final, que são muito mais regulares.
A consequência disso é que, se levarmos em conta TUDO, vamos acabar diluindo o comportamento atual do sistema com uma tendência que não existe mais! Logo, a nossa ação mais imediata é limar o dataset original para, vai, logo depois daquele degrau, quando o sistema ficou mais estável:
O X vermelho marca o início do comportamento atual.
Depois de procurar um pouco descobri que esse X vermelho está, mais ou menos, perto do ponto clock = 1474963200. Vou reaplicar a amostragem e remover tudo que vier antes dele. Também vou dividir o dataset (tirar uma amostra) em duas partes iguais. Eis o novo gráfico:
Plot da segunda amostra (50% de tudo que veio depois de 1474963200.)
Beleza! Agora sim, temos um conjunto de dados bacana.
Modify
A etapa de modificação do SEMMA contempla todo tipo de tratamento dos dados para torná-los adequados ao estudo. Ou seja, remover outliers indesejados (sim, existem outrliers desejáveis!), agregar, quebrar, normalizar, traduzir, classificar e categorizar as inúmeras variáveis, tratar nulos, brancos, erros etc. etc. etc.
O nosso caso até que é bem comportado: duas colunas, X e Y, com números inteiros.
Por outro lado, olhe de novo: é uma lista de clocks! Quero dizer, de Unix Time!
Unix Time, também chamado de POSIX time ou epoch, é um sistema para descrever instantes no tempo, definido como o número de segundos passados desde a meia-noite de 1/1/1970 (uma quinta-feira, diga-se de passagem.)
Muito prático para medir e guardar tempo, mas inadequado para estimar variação de bytes por dia. Então aqui está a nossa modificação: trocar clock por dia!
Felizmente o PDI pode nos ajudar nisso de novo: basta converter clock para data e hora, e depois somar todos os pontos de um mesmo dia, isto é, agregar por dia. Atualizei a transformação e agora a amostra sai assim:
dia
qtd
25/02/2017
657
26/02/2017
1168
27/02/2017
730
28/02/2017
876
01/03/2017
1241
02/03/2017
730
03/03/2017
730
04/03/2017
949
05/03/2017
803
06/03/2017
730
…
…
Que plotando dá:
Mesmo gráfico, agora agregado por dia.
Notou algo incomun?
Você, que aprendeu operações básicas na quarta série e funções na sétima, me diga: que operação algébrica leva uma data em um número? Ou então, se olharmos apenas para a primeira linha, que número, dividido por 657 é igual à 25/2/2017? Nenhum, não é? Claro! O tipo DATE não serve para operações matemáticas. Então, se quisermos achar uma equação que expressa a quantidade de linhas capturadas em função do dia, precisamos converter as datas em alguma outra coisa como, por exemplo, um número de dias.
Daí eu fiz a seguinte alteração: a primeira data é 0 e daí em diante cada data é alterada para o número do dia correspondente. A tabela acima fica, então, assim:
dia
qtd
0
657
1
1168
2
730
3
876
4
1241
5
730
6
730
7
949
8
803
9
730
…
…
Agora sim, podemos achar um função que leve x = {N} (x pertencente ao conjunto dos número Naturais) em y = {N}.
Atenção que a coisa agora ficou mais complicada.
Depois de todas essas alterações, o conjunto de dados está diferente do conjunto inicial. A lista que temos para trabalhar, agora, não reflete mais o comportamento do sistema. Antes, tínhamos uma amostra de linhas por hora. Escolhida aleatoriamente, uma linha qualquer representava o sistema naquele momento em que ela foi capturada.
Após converter a escala de horas para dias, precisamos fazer essa conversão sobre os dados originais. Não podemos fazer essa troca sobre a amostra!
Porquê? Por que o total de linhas capturadas num certo dia da amostra é menor que o mesmo total, naquele mesmo dia, sobre o volume inteiro!
Estando conscientes desta mudança, voltamos um passo atrás, geramos um dataset original de novo – agora convertido em dias – e só então é que poderíamos pegar uma amostra! Caso contrário, estaríamos olhando um sistema potencialmente diferente dos dados reais!
Só que o dataset, que começou com mais de oito mil pontos, caiu a 163 linhas. Se já era pequeno, agora está muito menor (uma ordem de grandeza menor, para ser mais preciso.)
Escolher uma amostra de um conjunto tão pequeno é mais que desnecessário, é perigoso, pois pode nos levar a um resultado enviesado. Só nos resta decidir entre acumular mais dados, e atrasar a análise, ou usar o dataset inteiro, e aceitar que nosso modelo estará sob risco de overfitting, entre outros.
Como este post é só uma visão geral, vamos aceitar os riscos inerentes a um dataset pequeno e seguir adiante.
Acabamos de modificar completamente nosso dataset. Podemos passar para a etapa seguinte? A rigor, não: precisaríamos retornar com esse novo conjunto de dados para a etapa de exploração e ver se algo mudou significativamente. O nosso caso é muito simples, então podemos seguir adiante sem preocupação, mas nunca tome essa decisão automaticamente, ok?
Model
YEAH!! Chegamos lá! :-D Agora é que a parte legal acontece, quando vamos realmente aplicar nossos cérebros em estudar os dados. Nosso objetivo, lembre-se, é tirar dali um modelo matemático, algo que explique o que está acontecendo e como está acontecendo. Com sorte tiramos até porque está acontecendo.
Mas vamos um passo de cada vez.
Antes de mais nada, entenda que aqui existe um pouco de chute. O exemplo de hoje é muito simples, diria até que não dá para ficar mais simples, mas raramente isso acontece. O mais comum é ter algum problema já tratado, uma combinações de problemas conhecidos, ou algo tão inédito que você talvez tenha que inventar algo novo.
Esse amigo meu, doutor em Física Nuclear, topou com um destes, numa entrevista de emprego Kobayashi Maur. O entrevistador passou um problema, com uma semana para resolver. Imagine: entrevista de emprego, prova, com prazo de uma semana para entregar. Daí você tem um grau do que é o topo da cadeia alimentar em Data Mining.[^2]
Existem classes de modelos mais ou menos aptos a cada tipo de problema. Assim, descobrir perfis de cliente sugere uso de clusters e árvores de decisão, enquanto que tendências sugerem algum tipo de regressão. Para quem está começando essa parte é o Inferno na Terra – de onde começar, raios? Como saber ao menos o que pode ser chutado como modelo??
Por isso que é imprescindível que o profissional aspirante a – arfff – Cientista de Dados (coça, coça) faça um curso de Estatística básica e, preferencialmente, um curso de Data Mining mesmo. O curso de Estatística serve para dar traquejo matemático, mas o que vai agregar valor é o curso de Data Mining, que é onde se aprende quais modelos existem, e como eles podem ser usados, em que situação etc.
Certos tipos de profissionais, como físicos e engenheiros, tem uma aptidão natural para Data Mining, já que muito do que se estuda nessas faculdades é criar e resolver modelos. Entretanto, nada libera ninguém de um tempo de trabalho na área até “pegar o jeito”, claro. Experiência conta muito!
Ok, agora vamos ao nosso caso. Sabemos – da etapa de exploração dos dados – que o sistema de origem dos dados está “em regime”, ou seja, está com um comportamento regular. Houve uma zona de ajustes, no início, quando a quantidade de linhas capturadas por hora variou bastante. Hoje isso não acontece mais e o volume de dados entrantes é praticamente constante.
Isso já é um modelo! O volume de dados novos amanhã será igual ao de hoje. Ou seja, velocidade constante de crescimento. Que velocidade? Podemos pegar o último ponto e repetir, por exemplo, ou pegar uma média de todos para dar um chute mais “educado”.
Quem estudou Cálculo I e Cálculo Numérico (ou fez alguma matéria de laboratório de Física I), conhece uma forma simples de avaliar comportamentos regulares: plotar os pontos em um gŕafico log ou log-log. Se nosso sistema tiver um comportamento linear próximo à constante, uma escala muito grande (10x) ou um gráfico semi-log vai mostrar os pontos alinhados muito perto de uma linha horizontal. Vejamos:
Plot semi-log dos dados da amostra limpa. Praticamente constante!
Primeiro: nossa hipótese foi comprovada, o sistema possui um comportamento próximo à constante ou, no mínimo, linear. Isso é mais que suficiente para consolidar o modelo. Só por via das dúvidas, vamos fazer a coisa com um pouco mais de Matemática, mas antes, cabe outra observação: notou os dois outliers? São o primeiro e último pontos do dataset. Devemos fazer algo?
Outliers, em quantidade ou deslocamento suficientes podem afetar intensamente o resultado do modelo, logo devemos tentar removê-los sempre que tivermos uma certeza boa de representarem um estado incorreto do sistema, ou de frequência desprezível (i.é., raro, improvável.) O importante é saber se removê-los vai melhorar o modelo ou piorá-lo, sempre.
Pensemos um pouco: porque estão ali? Porque são justamente o primeiro e o segudo ponto?
Uma hipótese razoável é que não representam o dia inteiro e por isso não correspondem ao comportamento regular do sistema. Se isso for verdade, podemos removê-los.
Ela se sustenta?
O último ponto representa o estado do sistema quando o ETL rodou pela primeira vez, durante o dia. Logo, sim, para o último ponto sustenta-se, sim. Podemos removê-lo;
O primeiro ponto representa um corte no dataset, bem no clock igual a 1474963200. Isso corresponde à data/hora 2016-09-27 05:00:00. Em outras palavras, o dataset começa no dia 27/9/2016, mas com dados apenas a partir das cinco horas da manhã! Tudo entre a meia-noite e as cinco foi descartado! Então não é um dia completo, e a hipótese, de novo, mostra-se correta. Por isso eliminamos também este ponto.
Note que, se tivéssemos retornado à etapa de exploração no final da etapa de modificação, já teríamos feito todas essas observações.
Beleza, então já sabemos que o sistema apresenta um comportamento de uma reta ao longo do tempo. Em Estatística existe uma técnica chamada Regressão Linear, que descobre modelos de retas a partir de observações. É uma idéia simples: traçar uma reta (= calcular o coeficiente de inclinação a e a intersecção com o eixo X, b) entre os pontos medidos, de tal forma que ela (a reta) fique à menor distância possível de todos os pontos, simultaneamente.
Dito ao contrário, uma regressão linear descobre o valor de a e b da equação f(x) = a.x + b que minimiza a soma de todas as distâncias de f(x) a cada ponto medido.
A distância entre a reta f(x) e o ponto y correspondente.
Traduzindo, e olhando a figura anterior: queremos achar a e b tais que a soma de todos os ds seja a menor possível. Pronto, acabou a teoria de regressão linear. Se quiser saber mais vá atrás deste link.
O LibreOffice e o Excel (e o Weka, e o RapidMiner e o R e o…) fazem isso. Para mostrar como, eu vou usar momentaneamente um conjunto de dados artificial, diferente do nosso problema, ok? Só para deixar mais claro como tudo funciona.
Primeiro, clique com o botão direito do mouse sobre um dos pontos do gráfico e escolha a opção Trend Line, conforme mostra a figura:
Como pedir uma regressão linear no LibreOffice.
Entre alguns parâmetros, como o nome da função e quais resultados você quer ver. Na imagem abaixo você vê que eu coloquei f(t) como nome da função e pedi para ser exibido a função em si e o coeficiente de relacionamento (R^2):
Parâmetros da regressão linear no LibreOffice.
Quando você dá Ok no diálogo acima, o Calc sumperimpõe a reta encontrada sobre seus pontos. Eu mexi um pouco mais e fiz com que ele mostrasse não apenas a reta sobre os pontos já medidos, mas também coloquei os pontos de cinco dias seguintes, extrapolando o crescimento do volume de dados:
Ajuste plotado sobre dados, extrapolando o futuro.
Ficou claro? É assim, aliás, que vamos usar o modelo.
Aplicando essa técnica ao dataset sem os outliers, temos:
![ Modelo de progressão do volume de linhas coletadas dia-a-dia. ][Figura 14]
Show! :-) A regressão linear deu o seguinte:
Reta: f(x) = 0,4334.x + 1700
Coeficiente de correlação ao quadrado: R^2 = 0,39
A interpretação desse modelo é o seguinte:
A cada dia, o sistema incorpora um número de linhas igual a 0,4334 x dias, mais 1700;
Esse relacionamento entre o dia e o volume de dados não é dos melhores, já que R^2 está distante de 1.
O R^2 é um indicador de “qualidade” do ajuste. Quanto mais perto de 1, mais ajustada é a reta que encontramos, e quanto mais perto de zero, pior é o ajuste. Como o R^2 do nosso caso está mais perto de zero do que de um, somos levados a concluir que o ajuste da reta não ficou tão bom quanto possível. Isso não significa que o Calc errou, ou mesmo que podemos melhorar nosso ajuste, mas antes implica que há uma dispersão entre os dados que torna questionável o resultado da nossa análise.
Assess
A última parte do SEMMA diz respeito a testar o modelo em relação à realidade. Como usamos o dataset completo para construir o modelo, temos duas opções para fazer essa avaliação de qualidade:
Deixamos o sistema acumular pontos por mais algum tempo, como uma semana ou um mês, e usamos esses novos valores para testar o modelo;
Voltamos atrás, dividimos o nosso (já exíguo) dataset em amostra de treinamento e amostra de teste e refazemos a regressão linear.
Em qualquer um dos dois casos, a medida de sucesso é o quanto o modelo acerto em relação à realidade. Há várias maneiras de fazer isso, que depende inclusive do modelo usado. Este caso, por exemplo, mostra como avaliar a qualidade do modelo em uma regressão múltipla (coeficientes lineares, várias variáveis.)
O nosso caso é muito simples, insisto, mas não quero deixar essa seção sem nada. Então vamos dividir o dataset em dois, regredir o primeiro e ver como a extrapolação casa com o segundo.
Primeiro, separei aquelas 161 (163 – 2 outliers) linhas de dados em dois conjuntos, um com 80% (128 linhas) para treinamento, e outro com 20%, ou 33 linhas, para teste.
Primeiro, eis o resultado da regressão:
Regressão sobre os primeiros 80% do dataset.
Interessantemente o bastante, o R^2 é maior neste conjunto que no conjunto total, o que torna este modelo melhor neste dataset que o primeiro, para todos os pontos. Isso, e o valor de a quase o dobro do primeiro modelo, sugerem que talvez exista algum outro comportamento embutido aqui, sutil o bastante para não aparecer em um simples plot. Se bobear, eu acertei um ponto de inflexão sem querer. Vixe.
Usando essa equação eu montei um segundo gráfico, no qual aparecem os 20% de pontos restantes, juntos com duas novas séries de pontos: em vermelho/diamante os pontos calculados a partir do modelo, e em nabla (triângulo invertido, uma letra grega) verde, a diferença entre o valor sugerido pelo modelo, para aquele dia, e o valor efetivamente medido. Veja:
Teste da regressão sobre os últimos 20% de dados.
E aí está: o erro, nabla verde, segue crescendo lentamente, mas sem dúvida nenhuma crescendo.
Erro do modelo em relação à realidade.
Respostas, Afinal!
Então nosso estudo, nossa garimpagem, produziu o seguinte resultado: (vou usar o primeiro modelo, só por gosto)
O banco de dados cresce a uma taxa de f(x) = 0,4334.x + 1700 linhas por dia.
Mas quanto representa isso em bytes? Afinal, o espaço em disco é medido em GB, não em linhas – ao menos não diretamente.
Eu rodei algumas consultas no Postgres e descobri que, a tabela inteira carregada só com esses dados, dava uma média de 120 bytes por linha. O que faz sentido, se lembrarmos do layout desta tabela:
Coluna
Tipo
Tamanho
h_item_bk
Bigint
8
s_item_002_ldts
timestamp
8
s_item_002_rsrc
Varchar
64
s_item_002_ledts
timestamp
8
clock
Bigint
8
num
Integer
4
value_avg
Number (16,4)
20
value_max
Number (16,4)
20
value_min
Number (16,4)
20
O total dá 160, mas dos 64 bytes possíveis para o VARCHAR apenas 8, “ZABBIX000”, são usados. Somando um para o fim da string, o total cai para 105 bytes. Um pouco de overhead explica a média em 120 bytes, o que não é de todo inaceitável. Logo, multiplicamos a equação inteira por 120 e temos um modelo em bytes. Ah, e mais um detalhe que eu não havia contado: estamos coletando dados de 10 Zabbixes, logo o modelo final precisa ser multiplicado por dez, também.
Portanto nosso modelo deve ser:
O espaço em disco ocupado pela tabela cresce a uma taxa de f(x) = 520.x + 2040000 bytes por dia.
Não se esqueça que x = 0 é 27/9/2016 e tudo é medido a partir daí.
Pronto! Podemos FINALMENTE responder as perguntas com algum critério:
Quanto tempo de coletas diárias esse HD comporta?
Se ele tem 600GB de espaço, e mais nada acontecer ou for acrescentado:
600 GB = 520.x + 2040000
600 . 1024^3 = 520x + 2040000
520x = 644245094400 - 2040000
x = 1.238.928.951 dias, aprox.
= 3.394.325 de anos, aprox.
Bom, da primeira vez eu estava de brincadeira, mas agora estamos bem mais embasados: qualquer que seja o erro do nosso cálculo, ainda tem muuuuuuuuito tempo até encher isso tudo. Para mim, passou de 10 anos é infinito.
Eu fui dividindo por 1024, no caso de você estar se perguntando.
Quando ele vai estar a 75% da capacidade?
Em 0,75 * 3,3 milhões de anos, ou 2,4 milhões de anos, aproximadamente. :-P
Quando é que eu terei mais 6 meses até ele lotar completamente?
Irrelevante, concordam?
Conclusão
Este post começou como o relato de um exercício que eu fiz, em cinco minutos, para tranquilizar os donos dos servidores de Data Vault, dizendo que não estávamos capturando tanta coisa assim, afinal. Era quarta-feira, eu ia escrever o post da semana e pensei, porque não? Eu estava postando muita coisa ousada ultimamente, e seria um post divertido de escrever (ainda que não tanto de ler.)
Mas, meus amigos e amigas, caramba!… Estou escrevendo há três dias!
Francamente, acho que valeu a pena. Até porque, que coisa doida, ontem apareceu este comentário no post do A Nuvem Negra, feito pelo Rafael:
(…)
Já que, como você diz, BI não existe (risos), por mais que a gente estude e trabalhe com, ficamos na dúvida sobre o que é ou não é BI. Olhar Business Intelligence como ciência pura me fez pensar o seguinte: BI e Ciência de Dados seriam a mesma coisa? Fico com a impressão de que Ciência de Dados está sendo vendida no Brasil mais como um chavão e relacionado especificamente com Big Data.
E sobre testar o que foi aprendido com o passado, isso se daria em ambiente de teste ou de produção?
(…)
Passem lá para olhá-lo, foi muito inteligente e acho que agrega muito lê-lo.
Bom, o que eu posso dizer? Eu acabei respondendo as perguntas dele, ainda que meio indiretamente. Se não, vejamos:
Ciência de Dados e BI são a mesma coisa? Resposta: não, Rafael. Se há alguma equivalência entre Ciência de Dados, um termo do qual eu não gosto, e alguma coisa, eu diria que Data Mining é essa alguma coisa. Juro para você, meu caro, quando você postou, eu já tinha escrito isso (está lá no começo, procure):
“Por isso que é imprescindível que o profissional aspirante a – arfff – Cientista de Dados (coça, coça) faça um curso de Estatística básica(…)”
Ou seja, para mim Data Science é o jargão da vez para Data Mining, assim como Data Discovery foi para OLAP.
E como testar o que aprendemos com o passado? Concorda comigo que foi exatamente essa pergunta que eu acabei respondendo hoje? O tal “aprender” pode ser entendido como “construir um modelo”. Levamos esse modelo “para produção” de diversas formas. Hoje eu mostrei como planejar a capacidade do seu ambiente usando Data Mining. No exemplo de hoje, levar o modelo para produção equivale a saber que tamanho de disco precisamos para aguentar até a próxima troca de hardware. Em outros casos, levar para produção pode ser programar o caixa eletrônico para mostrar uma oferta de crédito sempre que o cliente A ou B se registrar. Pode ser planejar uma plantação de eucaliptos para produção de papel, que só vai acontecer daqui a uma década. Pode ser construir um algoritmo de controle da injeção eletrônica em função de inúmeros fatores. Pode ser um monte de coisas!
Esse, aliás, é um bom tema para um post. Estou vendo outra série surgindo – explicando Data Mining ou, afff, Data Science. :-D
O nome original deste post era Prevendo o Futuro. Eu não tive como não alterá-lo para Introdução à Data Mining depois de tudo, e ainda mais depois do comentário do Rafael.
Aliás, Rafael, muito obrigado pelo comentário. Prometo que vou postar mais coisas daquele naipe. Aguarde o Bola Quadrada, hehe!
Então é isso.
Acabou? Sério? ALELUIA!
A-LE-LU-IA!!!!!
:-)
Parabéns por chegarem até aqui, e obrigado pela companhia.
Algumas das soluções tradicionais de BI elencadas então foram:
CRM;
Crédito;
Seguros;
Supply Chain;
Fraude;
Risco.
Destas, além da introdução ao assunto, eu queria mostrar três: CRM, CS e Seguros. No meio do caminho a vida foi acontecendo e o assunto foi ficando de lado, mas hoje vou fechar a “primeira temporada” e mostrar a solução de BI para Seguradoras (e outros negócios.)
O Problema
Você conhece aquela piada de estatística sobre o consumo médio de frango assado?
Dizem que cada brasileiro come em média um frango assado por mês. Bom, então deve ter alguém comendo dois, porque com este preço eu não estou comendo nenhum!
Acho que nem estatísticos riem dessa porcaria, mas enfim, o ponto era chamar o assunto. :-)
A idéia toda baseia-se nos conceitos estatísticos embutidos na piada: se conhecemos a taxa de repetição de um evento, ou seja, se sabemos que em média, algum um certo tanto de eventos vai acontecer dentro de um certo período, podemos calcular a chance de esse evento acontecer de novo dentro de um certo tempo. E conforme conseguimos mais informação sobre esses eventos, podemos refinar o cálculo e obter indicações mais precisas sobre provável próxima ocorrência.
Por exemplo, dados coletados juntos ao Ministério da Saúde e ao Instituto do DPVAT indicam que mais ou menos 200.000 pessoas foram hospitalizadas devido a colisões de veículos em 2014. Dividindo por 12 meses temos que, em média, cerca de 16.700 pessoas se machucaram por mês em 2014.
Para simplificar o raciocínio, vamos extrapolar esse número para todos os anos seguintes e assumir que, em 2016, essa média se manteve.
Arredondando a população brasileira para 200 milhões de pessoas, podemos dizer que ao longo de um ano, ao menos uma pessoa a cada 1000 com certeza vai parar no hospital por motivo de colisão veícular.
E se soubermos mais sobre quem se acidentou, no passado, podemos melhorar a estimativa. Por exemplo, se sabemos que mais homens se acidentam que mulheres, podemos ter uma certeza razoável de que ser homem aumenta o risco, e ser mulher o diminui. E assim sucessivamente: faixa etária, localização geográfica, hora do dia em que sai de casa, estação do ano…
Sabendo que a cada mil pessoas, uma vai parar no hospital a cada ano, por colisão de veículo, qual é a chance que eu tenho de ser uma destas pessoas?
As chances mudam conforme a vida que eu levo:
Se eu NUNCA saio de casa, esse risco tende a zero;
Se eu dirijo o dia inteiro, esse risco tende ao máximo;
Se eu uso principalmente metrô para me deslocar na cidade, meu risco é mínimo, mas maior que se eu ficasse em casa o tempo todo;
Se eu sou homem, a minha imprudência natural tende a aumentar meu risco de acidentes, e se eu sou mulher, tende a diminuir.
E assim por diante. Esse é um tipo de análise Bayesiana, aliás! Cada nova informação que eu trago realoca as chances de cada evento. ;-)
Sempre que há algum risco envolvido em alguma ação, o ser humano busca minimizar esse risco ou proteger-se contra as consequências de sua realização. Assim levamos em viagem mais roupa de baixo que usaremos, compramos o dobro de cartuchos de tinta para imprimir o TCC e saímos de casa meia-hora mais cedo “para o caso de algo dar errado”.
Para que é que serve essa análise de risco? Ora, para um monte de coisas! Suponha que você vai construir uma estrada: que eventos podem comprometer esse projeto? Que risco cada um destes eventos apresenta? Se um destes dados riscos for muito grande, a prudência recomenda reter o projeto. E a mesma idéia se aplica a seguros e empreendimentos variados.
O Negócio
Em algum momento alguém sacou que essa necessidade representava uma oportunidade de negócios. É como um jogo de azar: aposto um tanto de dinheiro que nada de errado vai acontecer contigo. Se eu ganhar a aposta, eu mantenho o dinheiro. Se eu perder, eu banco o seus prezuíjo até um certo tanto.
Se eu for um bom apostador, isto é, se eu escolher bem as minhas apostas, eu ganho mais que perco, acumulando o dinheiro das apostas.
Se eu for um pusta pé-frio, perdendo mais apostas do que eu consigo bancar, vou à falência rapidinho e páro logo com isso.
Consta na Wikipedia que as primeiras compras de garantias datam do Século IV, e cobriam o transporte marítmo de bens.
O assunto é deveras fascinante e merece um bom estudo, pois ajuda a entender como chegamos até aqui. Aliás, se você tiver curiosidade, vale a pena estudar também a origem dos bancos. A idéia sempre foi a mesma: ser um ponto em que os recursos de vários pequenos investidores eram somados para alavancar negócios que, individualmente, nenhum deles conseguiriam. Os exemplos mais bacanas são as caravanas de comércio e a agricultura. Ou seja, sem bancos não temos crescimento econômico…
Divago, perdão.
Uma vez que chegamos neste ponto, tudo se torna uma questão matemática: acumular dados e fazer contas até chegar em valores que balanceiem o risco com o custo. Existe um profissional que estuda as técnicas para estimar esses riscos:
Atuário (…) é o (…) especialista em avaliar e administrar riscos.
(…) Este profissional é capaz de criar modelos matemáticos para planos de investimento e amortização, para seguro social e privado; efetuar cálculos de probabilidades de eventos, avaliar riscos, fixar valores de prêmios de seguro ou de indemnizações e, ainda, trabalhar em outras áreas coligadas ao tema de risco.1
Inteligência de Negócios Aplicado à Seguros
Quem já leu algum dos meus posts sobre Data Mining, como este aqui ou até mesmo o post que abre a série, já detectou nesta definição as palavrinhas mágicas “modelo matemático”.
E o que é que eu sempre digo sobre BI? Que, no fundo, Inteligência de Negócios é a aplicação do Método Científico para entender como a organização funciona e como extrapolar seu futuro a partir do seu passado. Isso é feito por meio de – tchan! tchan! tchan! tchaaaaan! – modelos matemáticos. Conclusão? Cálculos atuariais, que estimam riscos, são uma parte de BI. Mesmo que oficialmente ninguém afirme isso, não dá para escapar à essa conclusão: se A=B e B=C, então A=C, ponto.
Essa relação nos leva a uma outra conclusão: o analista de Data Mining que constrói modelos atuariais é um atuário. Como Analista de Data Mining hoje em dia é chamado de Cientista de Dados (pfff…) então um atuário é um tipo de Cientista de Dados!
Você pode querer argumentar que um Cientista de Dados pode ser um atuário, mas um atuário não é, necessariamente, um Cientista de Dados porque não traz todo rol de habilidades com dados habitualmente associado a Cientistas de Dados (=Analistas de Data Mining.) É, eu concordo com isso. Talvez a coisa que melhor separe as duas categorias, Analistas de Data Mining e Atuários, é que o segundo só faz cálculos atuariais, enquanto que o primeiro faz muito mais coisas – só que nada impede que ambos cresçam até englobar um o conhecimento do outro. ;-) Filosofia de mais, de volta à vaca fria!!
Ou seja, Atuária e BI são, essencialmente, uma categoria única. BI engloba muitas outras coisas, assim como Atuária, mas na hora de se aplicar uma ou outra, o rol de ferramentas é praticamente o mesmo.
Para uma visão mais geral, consulte esta página da Wikipedia. Ali você tem uma lista de várias das aplicações da Atuária. Eis uma pequena amostra:
Health insurance
Life insurance
Net premium valuation
Stochastic modelling
Asset liability modelling
Property insurance
Casualty insurance
Vehicle insurance
Ruin theory
Reinsurance
Investments & Asset Management
Dividend yield
PE ratio
Bond valuation
Yield to maturity
Cost of capital
Derivatives
Pensions
Stochastic modelling
Enterprise risk management
(Desculpem não traduzir – muito trabalho para bater o Google…)
A Solução
E que ferramentas são essas?
Ora, BI tem duas ferramentas, só:
Data Mining;
Data Warehouses.
Uma boa ferramenta de Data Mining, como SAS Enterprise Miner, e um bom projeto de DW bastam para aplicar todas as técnicas. Eventualmente, uma empresa desse ramo pode precisar comprar dados externos para poder desenvolver certos modelos matemáticos.
O próprio SAS possui pacotes prontos para esse tipo de problema – vem daí, aliás, o tema da série: soluções clássicas, soluções que de tanto serem aplicadas, acabaram empacotadas como produto.
Clicando aqui você pode conhecer a solução SAS para seguros. Já este link dá um panorama mais geral sobre as soluções baseadas em Atuária.
Note que qualquer ferramenta que faça as contas já serve. Excel, por exemplo, bem usado, pode fornecer resultados comparáveis ao próprio Enterprise Manager. O que acaba mudando, de uma ferramenta para outra, é a facilidade e praticidade da coisa.
Conclusão
Atuária é a ciência de estimar riscos. Seguros e Gerenciamento de Riscos são dois ramos de negócios assentados nessa tecnologia.
Por sua vez, BI engloba toda habilidade de acumular e analisar dados de uma organização para melhorar o negócio. Logo, Atuária e BI se interpõem, e ambos acabam formando parte do outro.
Nada mais natural, portanto, que exista um conjunto de ferramentas em BI desenhadas especialmente para lidar com problemas de Atuária. Esse conjunto de ferramentas é a tal da Solução de Inteligência de Negócios para Seguros e para Gerenciamento de Riscos. No miolo dessas soluções está sempre uma ferramenta de Data Mining, e os profissionais habilitados a usá-la. Ainda que não seja absolutamente imprescindível, o uso de um DW ajuda muito neste tipo de projeto.
Se você acredita que sua empresa pode se beneficiar desse tipo de solução, não tente fazer sozinho. Busque uma consultoria, um profissional do ramo, nem que seja só para se aconselhar. Arriscando-se sozinho você assume uma chance alta de obter conclusões erradas, e comprometer a sobrevivência de sua empresa. Melhor não economizar nisso, não é?
Estamos chegando ao final do ano, e este post conclui a primeira temporada da série Soluções Clássicas de BI. Gostaram? Acharam interessante? Ou um total despercício mútuo de tempo?
Considerando-se a piada da média de frangos, tenho medo de não ter valido nem pelas risadas… :-O
Essas são as mais fáceis de se mostrar e mais simples de se entender o uso, mas existem inúmeras outras soluções. Se eu conseguir aprender o bastante sobre alguma delas, eu voltarei ao tema. Duas que eu acho superlegais, mas que são relativamente complexas, é [SCM][scm_bitly], ou Supply Chain Management, e IT Capacity Planning. Quem sabe não são as primeiras da temporada dois?
Até a próxima! ;-)
Extraído do verbete Atuário, da Wikipedia, em 12/12/16. ↩
Trabalho na indústria de BI há 16 anos. Hoje em dia dá-se muito destaque a um tipo de dados considerados especiais, até meio místicos, como se guardassem a chave para as respostas de todas as perguntas não-formuladas. São os tais dos chamados dados não-estruturados.
Não vou debater semântica, ou nomenclatura, mas o fato é que esse tipo de dado existe desde sempre. Tanto é assim que há um campo inteiro dedicado a produzir conhecimento a partir de fontes hoje ditas “não-estruturadas”. Esse campo chama-se Text Mining, uma extensão do conceito de Data Mining. São as técnicas aplicadas em, por exemplo, soluções de análise de sentimento.
Assim como eu tenho algumas ressalvas com todo o hype em volta de BigData, também tenho minhas reservas quanto ao endeusamento desse tipo de dado. A minha bronca é que essa atitude não raro decorre de modismos, em geral carentes de significado mais concreto, cunhados a fim de encher a cabeça do cliente e ocasionalmente levá-lo a comprar alguma coisa.
Compra quem quer, deixa-se levar por modismos quem quer. Longe de mim atrapalhar a liberdade que cada um tem de se deixar convencer! Entretanto, eu não posso deixar de tocar no assunto. Encare este post como mais um argumento em um longo debate em busca da verdade. ;-)
A maior parte dos dados úteis para análises são justamente os que refletem algum processo, e por isso são capturados em sistemas transacionais ordinários. São dados que vivem em tabelas ou, no máximo, arquivos com algum layout padronizado. Já os tais dos dados não-estruturados não possuem “nenhuma” regularidade. Então tá, se sairmos desse domínio – se deixarmos os sistemas transacionais e suas tabelas padronizadas para trás – o que temos?
Vou ver um exemplo para ficar mais claro.
O Governo Federal tem a missão de gastar o dinheiro da melhor forma possível. Suponha que decidiu-se estabelecer a relação entre o atendimento do Bolsa-Família (BF) e a melhoria da educação. Isso é importante para permitir que a geração seguinte à suportada pelo BF possa almejar empregos de qualidade e melhorar de vida.
Como correlacionar esses dados? Uma opção é avaliar a relação entre demografia e os índices de escolaridade e frequência, e a cobertura geográfica do BF.
De onde virão esses dados? Dos sistemas de gestão escolar, por certo. Logo, esses dados são 100% estruturados. Estamos falando de capturar as listas de chamada, as notas, o resultado do ENEM, da Provinha Brasil, da concessão de BFs, de mapas… São todos dados estruturados. Mesmo que não venham de um único sistema, quiçá de uma única entidade, todos esses dados “vivem” em estruturas regulares. Com esses dados obtemos o conhecimento mais valioso que existe nos processos de gestão escolar.
Permitam-me colocar de outra forma: obtemos uma informação valiosa sem precisarmos de nenhum dado não-estruturado. E isso vale para a maioria do que está por aí, aguardando ser descoberto.
O dado não-estruturado serve para situações muito específicas, em condições muito particulares. É um nicho naturalmente pequeno – basta pensar quantas empresas/organizações grandes o bastante existem para puxar alguma inteligência dessas fontes, e o tamanho que essas fontes precisam ter para atribuir alguma confiança, estatisticamente falando, aos resultados.
Analiso Ergo Estruturo
Por outro lado, quais fontes de dados não-estruturadas existem por aí?
Textos (web e e-mail;)
Textos (posts em mídias sociais;)
Textos (documentos;)
Vértices de grafos (URLs – textos.)
Um punhado de dados não-estruturados.
Eu com certeza ignoro algumas outras categorias de dados não-estruturados, mas quais? Repassei a lista mas tudo que eu pensava tinha alguma estrutura mais ou menos óbvia, fixa:
Objetos XML: têm estrutura;
Transações entre empresas, como SWIFT: além de privados, têm estrutura;
Mapas: têm estrutura;
Etc…
Ora, o que é uma análise? Pode ser desde uma contagem ou uma média (quantas palavras o post possui, quantas palavras existe, em média, nos posts de cada autor?) a uma coisa mais sofisticada (qual é a chance, para cada assunto, de o autor possuir relação íntima com o dado assunto de seus textos?) Responder a essas perguntas envolve analisar frequências, distribuições, distâncias – números, números, números! Sempre precisamos quantificar em números e qualificar com uma descrição tudo aquilo que desejamos analisar.
Bom, mesmo o exemplo dado na figura 1 (e em geral naqueles elencados no início da sessão) possui alguma estrutura. Por exemplo:
Data e hora de publicação;
Ocasionalmente data e hora de criação e edição;
Versão (1, 2, 3… quando alguém edita o conteúdo e republica o item – doc, post etc.;)
Autor, e todos seus dados;
Tamanho;
Tipo de conteúdos (só texto, só imagem, mistura;)
Relacionamentos;
E, finalmente, o conteúdo em si.
O mesmo punhado de dados, estruturados.
Veja que, ignorando o conteúdo, podemos puxar muita coisa só olhando o restante! Dá para montar grafos diversos, por exemplo, acompanhando o timestamp e relacionamentos entre publicações em blogs e redes sociais. Dá para analisar o sentimento de um conjunto em relação a um assunto.
Análise impõe estrutura: para conduzir uma análise, os dados precisam ser estruturados de alguma forma. Se os dados não possuem estrutura, então não podem ser organizados e, imperiosamente, não permitem análise.
Logo, se os dados podem ser analisados, então eles possuem alguma estrutura. Isso gera confusão com o jargão de TI, que costuma chamar de “estrutura” um container ou padrão de armazenamento digital (isto é, que guarda os dados de uma forma mais ou menos organizada, como uma tabela, uma planilha ou um arquivo texto, representados por sequências de bytes em alguma mídia.)
Conclusão
O meu ponto é chamar a atenção para o hype em volta de dados não-estruturados. Afinal, para podermos conduzir qualquer análise é preciso poder representá-los matematicamente. Quero dizer, é preciso que eles possuam alguma estrutura, por mais incomum ou exótica que seja essa estrutura, ou por mais “escondida” que ela esteja.
Essa tabela mostra o exemplo da estrutura de dados do post em emu Facebook que aparece nas figuras anteriores:
Mesmo dados arquivados sob formatos exóticos (textos, e-mails, páginas web) possuem um mínimo de estrutura matemática apta a análises. Vem daí a afirmação que dá título a este post:
Todo dado (que seja útil para análise) é estruturado, de uma forma ou de outra.
Isso implica em dizer que não existem dados não-estruturados? Pode ser, tanto que esse era o título original deste post. Mas ainda não consigo afirmar isso com certeza.
Inteligência de Negócios é a disciplina que busca a compreensão do funcionamento de uma organização (o conhecimento do negócio) mediante a aplicação do Método Científico. Além de insumo para aplicação do Método Científico, os dados de uma empresa prestam-se a um sem-número de funções, que podem ser realizadas por uma gama de ferramentas.
Algumas das formas de uso são notadas com maior frequência em uma organização ordinária. Vamos descrever algumas destas formas de uso de dados e ferramentas, os chamados Casos de Uso.
Caso de Uso
Um caso de uso (ou CDU para simplificar) é um modo de aplicação ou o propósito – o uso – de algo, como uma ferramentas ou uma técnica.
Como exemplo tome o caso de uso de uma panela de pressão: cozinhar alimentos a temperaturas superiores ao ponto de ebulição da água. Sempre que um alimento precisar de maior temperatura para ser adequadamente cozido, podemos usar uma panela de pressão.
Conversamente, sempre que um alimento pode ser cozido no ponto de ebulição da água, o uso de uma panela de pressão é desnecessário e pode até mesmo comprometer a qualidade do resultado.
A toda ferramenta corresponde um ou mais casos de usos com graus variados de adequação. Aplicar uma ferramenta a situações para as quais ela não possui uma adequabilidade mínima pode comprometer o resultado almejado, ou pior, pode entregar um resultado plausível enquanto oculta alguma falha intrínseca. Basta pensar no velho ditado “para martelo, tudo é prego” e imaginar que uma boa martelada pode engastar um parafuso na madeira: a qualidade da fixação será insuficiente e, mesmo aparentando estar “pregado” bem o bastante, o parafuso pode soltar-se e causar uma falha catastrófica.
Casos de Uso de Dados
Os dados produzidos nos sistemas informatizados de uma organização podem ser consumidos de várias formas e usados para várias finalidades.
Monitoração
Parte do trabalho de qualquer profissional, nos dias de hoje, é acompanhar eventos diários e responder a eles.
Entrou um novo ticket pedindo serviço? Surgiu um defeito? Um sistema sofreu pane?
Manter-se informado dos acontecimentos é parte da tarefa de monitorar o ambiente. Outra parte é examinar a situação, ou seja, os dados correntes, em busca de sinais que prenunciem o surgimento de uma situação específica. O exemplo mais banal é observar o dia no calendário: a aproximação de certas datas, que avizinham vencimentos de prazos, é uma forma de monitoração.
Algumas situações só podem ser monitoradas a partir de um conhecimento prévio, que precisa ser adquirido de antemão. Sabemos que a chance de chover aumenta quando o céu cobre-se de nuvens escuras porque tivemos a oportunidade de testemunhar a correlação entre chuva e céu nublado – com frequência o primeiro segue-se ao último – várias vezes.
Evidência
Situações surgem em que ocorrências passadas são questionadas. A forma mais prática de confirmar fatos é apresentar os dados que evidenciam o que aconteceu.
Por vezes essa evidência é direta, como um relatório de gastos ou uma lista de peças de um lote. Em outras situações a evidência é indireta. Se nenhum sistema registra a entrada do empregado em certo dia, por exemplo, e nenhum arquivo de sua estação de trabalho possui timestamp de acesso naquele dia, então é razoável supor que naquele dia ele não esteve em seu posto.
Análise
Pense no indivíduo que nunca testemunhou uma chuva na vida. Na primeira ocasião em que observar o céu escurecido – resultado da monitoração – ele não presumirá o risco maior de precipitação. Apenas depois de algumas ocorrências céu escuro/chuva é que ele poderá ser levado à concluir que a associação existe.
Essa é uma situação recorrente no funcionamento diário em qualquer organização: se não entendemos a relação entre causa e efeito, monitorar o quê? Se não temos um argumento a ser testado, provar o quê? Esse é o miolo da disciplina de Inteligência de Negócios, a que realmente agrega valor à organização ao produzir conhecimento explicitando a relação (e os parâmetros) entre causa e efeito. Essa é a mesma justificativa para erigirmos um DW, aliás.
Dados, além de servir para monitorar e para demonstrar fatos, ainda podem ser explorados e estudados em busca do conhecimento de negócio. Na minha opinião, essa classificação do uso dos dados em uma empresa explicita a separação entre os usos analíticos e operacionais.
Casos de Uso de Ferramentas de Dados
O termo genérico “ferramentas de dados” significa toda ferramenta que manuseia e/ou apresenta os dados dos sistemas informatizados de alguma maneira. Por exemplo, o próprio sistema informatizado, que produz os dados, é uma ferramenta de dados. Levado ao paroxismo, todo software é uma ferramenta de dados, já que todo software comanda uma CPU para tratar algum dado de alguma maneira. Para o propósito deste documento vamos restringir essa definição aos softwares que lidam com dados de negócio em sua forma operacional. Por exemplo, softwares que tabulam dados ou traçam gráficos.
Relatório
Uma das ferramentas mais simples para o manuseio dos dados é a exibição de listas. Esse CDU é conhecido pelo termo de relatório, pois relata, descreve, apresenta os dados. Um relatório é, por definição, uma lista de dados com rótulos nas colunas, que pode vir acompanhado de outros recursos.
Uma ferramenta de relatório pode incorporar uma quantidade de opções de apresentação, como títulos, cabeçalhos, números de páginas, gráficos ou sub-relatórios (relatórios dentro de relatórios.) Ferramentas de relatórios podem possuir alguma resposta dinâmica, como escolher o formato de saída (HTML, PDF e CSV entre outros), ou a aplicação de algum filtro em tempo de execução e até mesmo embutir URLs (links web) nos campos, tal que clicar sobre eles abrem páginas em navegadores web. Consta como tradicional a possibilidade de imprimir tais listas.
O acesso aos relatórios pode ser por meio do software instalado localmente ou via portal web e algumas soluções combinam a possibilidade de remeter um relatório renderizado diretamente para o e-mail de um usuário.
Painel de Dados
Um passo adiante do simples relatório, painéis são meios eminentemente gráficos, usados para apresentar diversas visões sobre dados em uma única área, em geral com alguma correlação entre si. Tradicionalmente associa-se à esta tecnologia a capacidade de algum tipo de interação. Por exemplo, um painel de vendas pode mudar para exibir os números por UF ao se clicar em um mapa do país.
A promessa dessa tecnologia é comunicar um volume maior de informações por meio de uma diagramação mais inteligente dos dados. Em outras palavras, um painel é a proverbial imagem que vale por mil palavras para a gestão da organização.
Análise Multidimensional
Uma ferramenta de análise multidimensional tem a capacidade de cruzar atributos em linhas e colunas, com os valores nas células resultantes desse cruzamento. Em comparação com uma ferramenta de relatório, uma ferramenta de análise multidimensional possui duas diferenças principais:
Exibir cabeçalhos tanto em linhas quanto em colunas, já mencionado;
Reorganizar a visão interativamente, com um tempo de espera mínimo.
Enquanto que ferramentas de relatórios estão limitadas a listas, que são renderizadas a partir de consultas, uma ferramenta de análise multidimensional pode criar planilhas, e respondem em segundos. Esse tipo de exploração de dados apóia processos de investigação de causa-raiz (ir de uma visão macro a uma visão micro, até achar a causa de um evento) e de entendimento de correlações entre os dados.
Se relatórios e painéis de dados sobressaem-se na apresentação dos dados, ferramentas de análises multidimensionais ajudam a descobrir o quê é interessante apresentar.
A sigla tradicional para análise multidimensional é OLAP, abreviação em inglês de Processamento Analítico On-Line.
Além da organização dos dados e da interatividade, ferramentas OLAP ainda oferecem controle sobre os níveis e o tipo de agregação. Por exemplo, podemos criar uma visão multidimensional mostrando, nas colunas, as UFs, e nas linhas os produtos. Cada célula dessa planilha indica, portanto, o total de venda de um certo produto numa certa UF. Podemos trocar UF por região, e a quantidade de colunas passará de 27 a 5. Mas também podemos manter a UF e fazer uma quebra por região, exibindo simultaneamente o UF e região para cada valor. Uma linha de células no topo (ou no fundo da planilha) pode, então, mostrar as agregações por região.
Data Mining
Esse pode ser considerado uma família de casos de uso mais do que um único CDU, cujo propósito genérico é apoiar o desenvolvimento de algum modelo matemático que “explique” os dados.
Ferramentas desta categoria costumam oferecer, entre outros recursos:
Estatísticas avançadas: distribuições, ajustes de curvas, testes de regressão e hipóteses, por exemplo;
Análises sofisticadas, como Análise Baeysiana, clusterização, grafos, previsores como ARIMA e HoldWinters.
Ao contrário das outras ferramentas, as que implementam estes CDUs são voltadas para um público específico, dotado de habilidades específicas no tratamento de dados e construção de modelos empíricos. O nome corrente do profissional apto a aplicar este tipo de ferramenta é “cientista de dados”, mas já foi tratado por analista de data mining ou simplesmente “o estatístico”.
Os resultados de projetos para este caso de uso costumam se apresentar como algoritmos ou equações que, devidamente implementadas nos sistemas transacionais, podem operar decisões autônomas, sem supervisão humana. Um exemplo clássico dessa situação são as ofertas de crédito pré-aprovado exibidas por ATMs.
E o Pentaho?
A suite Pentaho implementa casos de uso de dados através de alguns casos de usos de ferramentas de dados.
O Pentaho oferece a possibilidade Monitorar, Reportar e Analisar dados.
Entre as ferramentas disponíveis na suite temos as capacidades de relatório (Report Designer), Painéis (BA Server) Análises Multidimensionais (Mondrian) e Data Mining (Weka.)
Cada CDU de ferramenta é implementada por um software específico. Cada CDU de dados é resultado da combinação de uma ou mais ferramentas, em geral com o BA Server no centro.
Conclusão
Os casos de uso de dados explicitam uma separação que eu fiz no primeiro post de 2016: o uso dos dados pode ser estratégico ou operacional. O CDU de Dados Análise é o único que realmente se encaixa em BI. Os outros dois podem consumir dados tanto de um DW quanto de bases transacionais, vivas. O CDU de Análise, não. A única forma de determinar a relação de causa e efeito é usando um DW e o Método Científico.
Olhando as demandas por dados que toda empresa experimenta através do ponto de vista de CDUs, podemos notar que a Suite Pentaho é uma solução completa, pois permite implementar todos os CDUs de dados através de todos os CDUs de ferramentas.
Mesmo que pareça o contrário, a intenção do post de hoje não era tecer loas ao Pentaho. Nunca escondi que sou fã da plataforma e se um dia eu decidir rasgar ceda para o Pentaho, eu o farei escancaradamente, sem pudores. Este post nasceu de um relatório que eu terminei hoje, que examinou a adequação de outra ferramenta, o [Spotfire][spotfire_bitly], à comunidade de usos e necessidades de certa empresa real. É justamente o fato de ser baseado em um relatório autêntico, de uma empresa real, que deu esse tom mais austero, mais academicista ao post. Espero que isso não espante vocês. Semana que vem volto ao modo galhofa de sempre. ;-)
Lamentavelmente para essa companhia, o Spotfire não possui uma adequabilidade tão grande às necessidades dela quanto outras ferramentas – como SAS e Pentaho – ainda mais em um patamar de custo benefício significativamente desvantajoso para o Spotfire.
Credit Scoring é o processo de atribuir uma pontuação – score – ao solicitante de alguma operação de crédito, como um empréstimo ou um parcelamento, e assim oferecer um número, um fato concreto, sobre essa solicitação para apoiar a decisão de concedê-la ou recusá-la. (Note que Credit Scoring é o processo, e Credit Score é o resultado.)
Uma solução de CS é resultado de um projeto de Data Mining, conforme eu expliquei no post inicial desta série, As Soluções Clássicas.
A idéia é simples, mas o processo em si é cheio de nuances, a começar por “score sobre o quê”, indo até o “score sobre quem”, combinando-os em “score para quem fazer o quê?”. Como a proposta é dar a vocês o sentimento de BI aplicado, uma visão geral sobre a solução de negócio, mais que de tecnologia ou Matemática, vou falar em termos genéricos e leigos. E assim como o post CRM, tudo aqui foi tirado em grande proporção de uma Solução SAS para CS e do livro Data Mining Techniques.
Introdução
Vamos do início, e no caso canônico: bancos emprestam dinheiro a clientes, que pagam de volta (ou não.) O processo em si não é muito complicado:
Ciclo de vida de um novo pedido de empréstimo.
Um cliente (um prospecto na verdade, pois cliente ele será se o pedido for aceito) entra com o pedido de crédito, o banco avalia e decide se concede ou não.
Se o banco recusar o empréstimo a coisa acaba ali mesmo. Se conceder, o prospecto vira cliente, recebe o dinheiro e começa a pagar as parcelas. Daí ele entra em outro ciclo de vida:
Ciclo de vida de um empréstimo em andamento.
Se durate a vigência do empréstimo (o contrato) ele deixar de pagar uma parcela, ele entra em recuperação. Pode ser apenas um pagamento atrasado alguns dias, um pagamento que ele “esqueceu” (deixou de pagar uma parcela, mas continua pagando as outras), ou passou a pagar com atraso, e assim por diante. Na situação limite, quando o cliente acumula sucessivos atrasos e a recuperação empaca, o cliente é encerrado, e a recuperação passa para a esfera jurídica, na qual o banco vai tentar reaver qualquer dinheiro possível e minimizar as perdas.
Se o processo de recuperação dá certo o cliente volta a efetuar os pagamentos e o andamento do processo retorna ao normal, seguindo até seu encerramento. Depois disso o ciclo pode recomeçar, com o agora ex-cliente pedindo um novo empréstimo.
Trabalho de Formiguinha
Imagine-se na posição do gerente do banco que recebe um pedido de crédito. Via de regra, até certo valor, todo gerente possui uma autonomia para decidir sobre a concessão desse pedido. Acima desse ponto o processo “sobe” para outras instâncias do banco, melhor capacitadas a avaliar os riscos do pedido.
E como um gerente, um profissional técnico do ramo, decide sobre esse pedido? Ele precisa descobrir se esse prospecto tem algum histórico de bom pagador ou caloteiro, por exemplo. E mesmo não tendo um bom histórico, ou apesar de tê-lo, o pedido faz sentido? O destino prometido ao dinheiro é um negócio saudável? Ou parece algum “esquema”, alguma coisa suspeita ou boa demais para ser verdade?
Não é uma tarefa simples. Meu pai foi gerente de banco antes, durante e depois da explosão da informatização bancária, e eu testemunhei em primeira mão (ou quase, hehe) as mudanças causadas nessa transição. Ele sempre foi muito reservado sobre o trabalho dele, mas alguma coisa sempre escapava. Como eu sou muito curioso e enxerido, acabei entendendo como ele fazia essas avaliações: ele visitava o cliente, aprendia sobre o negócio dele, sobre o destino do empréstimo e depois fazia a lição de casa, que consistia em levantar o histórico do cliente no banco, se existisse, depois no SERASA (ou coisa que o valhesse durante as décadas 70 a 90) e finalmente conversava com as “fontes” dele, profissionais que ele conhecia neste ou naquele segmento e que poderiam saber de algo a mais, saber como o mercado estava reagindo etc. Isso tudo além de ler Veja, Isto É, Exame, Manchete, Estadão e Gazeta Mercantil (ele já estava aposentado quando saiu o Valor.)
Só que, no final, não raras vezes ele tinha que apostar na própria intuição. Em certos casos ele dizia que “tinha uma sensação estranha” ou que “algo estava incomodando-o”, que “tudo estava certo, e isso era estranho” e assim por diante. Eu me lembro claramente de um dia ele chegar em casa e falar com minha mãe: “sabe o sujeito que pediu empréstimo e eu recusei? Eu não disse que era estranho? Acabaram de descobrir que ele deu estouro na praça”. Estouro na praça é o jargão bancário para estelionato: o cara tinha apresentado um lindo projeto de abatedouro e levantou crédito em vários bancos, crédito que ele embolsou e sumiu. Meu pai negara, baseado no “faro”, ele dizia, e foi o que salvou o pescoço dele.
Como vocês podem imaginar, não era um trabalho rápido. Uma parte dos casos eram novas linhas de créditos para clientes estabelecidos, e esses saiam rapidamente, mas os novos negócios demoravam algum tempo.
Com o advento de computadores e armazenamento cada vez mais poderosos e baratos, e as novas possibilidades abertas pelo acúmulo cada vez maior de dados (soa familiar? era década de 70, indo para 80, e ainda hoje temos a mesma conversa!!), aos poucos a importância do trabalho de analista feito por profissionais como meu pai, chamados eufemisticamente de linha de frente, foi diminuindo. O banco foi se tornando capaz de emitir análises cada vez mais rápidas e mais precisas sobre cada pedido, e paulatinamente a autonomia dele, o tamanho do empréstimo que ele podia decidir sem recorrer à central do banco, dimiuia. Cada vez mais pedidos, de valores cada vez menores, eram remetidos eletronicamente para a central de processamento de dados do banco, e uma análise mandada de volta em cada vez menos tempo.
Eu não me lembro exatamente de qual sistema era, mas dos meus quinze anos eu me lembro de ele usando uma coisa parecida com o sistema 3790 da IBM:
Sistema IBM 3790 de computação distribuída: pioneirismo vintage!
Me lembro do meu espanto ao ver meu pai, um “velho” de mais de cinquenta anos, entusiasta da computação, pressionando pela a informatização da agência inteira. Mas velhos não resistem à tecnologia??
Essa tendência seguiu firme e forte, até o momento em que todo caixa eletrônico (ATM) passou a oferecer crédito na hora.
Na Passarela, o Modelo!
Mas como, afinal, a informatização conseguiu substituir o pé na rua, a investigação em pessoa e a intuição?
Resposta: não conseguiu. O processo de tomada de decisão manual, por assim dizer, depende de se obter certas informações. O processo de decisão automatizado, que é uma aplicação de Data Mining, não pode contar com o mesmo tipo de conhecimento consumido no processo manual e por isso precisa apelar para outros recursos, outros caminhos.
Assim, ao invés de avaliar um prospecto pelo que sabemos sobre ele, o processo automatizado atribui uma nota – um score – ao prospecto a partir do que se sabe sobre os clientes que se parecem com ele.
Funciona assim: um especialista no assunto analisa uma massa de dados de clientes, isto é, de quem já contratou crédito. Essa massa possui algumas característias como, por exemplo, ser apenas uma parcela da base de dados, ao invés de ser a base inteira. Por outro lado, ela contém uma certa proporção dos vários tipos de clientes e situações, refletindo a distribuição da base inteira. E são dados limpos, que foram tratados para remover as incertezas e dubiedades. E por aí vai.
Essa amostra de dados é então dividida em algumas partes, como a base de treinamento e de avaliação. Sobre uma destas partes o especialista, que é um Analista de Data Mining, vai rodar alguns testes, e depois de um pouco de trabalho vai chegar a algumas expressões matemáticas que dizem qual é a chance de um determinado cliente pagar ou não pagar o empréstimo. Essas expressões são o que se chama modelo matemático, e leva esse nome por que ele mostra como a realidade se comporta, tal qual uma maquete representa um prédio.
E como confiar que este modelo de fato representa a realidade? Aplicando-se este modelo contra as outras partes da amostra inicial e medindo o quanto ele está certo ou errado.
Gráfico de avaliação e comparação de modelos. Quem “ajusta” melhor?
Os termos técnicos não são “certo” e “errado”, mas sim coisas como sensibilidade, discriminação, lift, ganho etc. Eu estou simplificando esse jargão em prol da comunicação.
O processo volta ao início e é repetido algumas vezes, até que o modelo ganhe um grau de certeza que atenda a demanda da empresa, isto é, até que ele entegue as respostas buscadas, dentro de uma faixa de certezas. Neste momento o modelo (matemático, lembre-se! Não é modelo de bancos de dados!) está pronto e pode ser usado para estimar o risco de conceder crédito a um prospecto.
Eis um fluxo de Data Mining: note o particionamento dos dados e a avaliação dos modelos.
Só Isso?
Até agora falamos como um modelo matemático pode ser usado para estimar o risco de um novo negócio. Vimos no início, porém, que o ciclo de vida do cliente vai além da venda do crédito: ele passa por todo o período em que o empréstimo é quitado. Nesse período muita coisa pode acontecer, como perdermos algum dinheiro com caloteiros contumazes, mas recuperar outro tanto de clientes que passaram por dificuldades financeiras.
Grosso modo, a solução de Credit Scoring cria modelos de riscos que dão respostas às seguintes perguntas:
Contratação de crédito: qual é o risco de um determinado solicitante se mostrar um mau (ou bom) pagador?
Falha de pagamentos: que cliente possui o maior risco de deixar de pagar o empréstimo, em parte ou totalmente?
Recuperação: quanto de recuperação de valores em atraso podemos esperar da base de clientes?
Ou seja, podemos ter modelos que tratam o cliente desde antes de ele receber o crédito, até depois de ele quitá-lo (avaliando quando sugerir um novo empréstimo), passando por avaliações de risco de atrasos, perdas e recuperações destas perdas!
Se você acompanhou o raciocínio até aqui deve estar achando Credit Scoring uma solução muito específica, voltada para um segmento relativamente pequeno – empréstimos por bancos. Na verdade, essa solução aplica-se em um sem-número de situações e indústrias. Quer ver?
Crediário
Toda loja que vende a crédito pode usar essa solução. As Casas Bahia são um exemplo para lá de manjado, tanto que dizem que o negócio deles é crédito pessoal, que por acaso é feito dentro de uma loja onde podemos gastar esse empréstimo.
Limites
Já se perguntou como é que sua operadora de cartão de crédito estipula seus limites? Ou porque é que seu limite aumentou de repente? E cheque especial? De onde o banco tira coragem para te deixar gastar a descoberto??
Todos esses exemplos, caso você não tenha notado, são empréstimos temporários. A solução de Credit Scoring dá uma forma de calcular que valores podem ser deixados à disposição do cliente, pré-aprovado, para uso rápido – para fluxo de caixa.
Hipotecas
Essa é ótima: pedimos um empréstimo, e em contra-partida oferecemos um imóvel como lastro para o empréstimo. Esse tipo de operação, chamada de hipoteca ou hipotecagem, tende a oferecer juros menores porque representam um risco menor. Mas quão menores ainda serão vantagem ou seguro para a instituição que oferece o crédito?
Seguros & Prêmios
Não. Talvez você até atenha se perguntado se CS não seria uma boa opção para estipular prêmios de seguros ou custos destes mesmos seguros. Bom, apesar de esses números poderem ser calculados com uma solução de Data Mining, não é a solução de Credit Scoring que faz isso, mas sim a de Cálculo Atuarial – assunto do próximo post da série!
Conclusão
Voltando um pouco à história do meu pai e do banco, ao contrário do que o senso comum pode nos levar a pensar, meu pai não se revoltou com essa “perda de poder”. Longe disso! Ele abraçou essa idéia com fervor. Pudera, a lógica dele ela cristalina: esse trabalho de formiguinha roubava tempo que ele poderia usar para ir atrás de quem precisava de dinheiro, mas não ainda não tinha ido até o banco. Mais do que isso: se ele trouxesse um novo negócio, ele mesmo precisaria avaliar o cliente, precisando ficar sentado mais um tempo até processar os novos prospectos, e só então poderia sair para buscar outros… e a vida virava um arrastar sem fim, um sai-cria-negócio-pára-recomeça. Com a automação do processo de decisão de concessão de crédito, ele ficaria livre para se dedicar continuamente a abrir novas frentes de negócios, sendo pró-ativo, deixando o maçante trabalho de autorizar ou não para um time mais eficiente e mais preparado que ele. Ele gostava era de por o pé na rua para vender! :-)
De novo, isso te soa familiar? “Automatizar processos repetitivos e liberar os trabalhadores para funções mais nobres.” Essa é a eterna promessa da automatização, feita por TI!
A concessão de crédito é um processo que pode ser resolvido tanto analisando-se caso a caso, quanto em lote. A solução de Credit Scoring é uma automação do processo de decisão, em que usamos o que sabemos sobre o pretendente, seu histórico de comportamento e o contexto, para qualificá-lo desta ou daquela maneira e assim tornar a análise um processo objetivo, automatizável até. E tanto isso é possível que temos aí os caixas-automáticos oferencendo crédito em qualquer esquina do país, vinte e quatro horas por dia, 365 dias por ano.
All hail Business Intelligence! All power to the knowledge!E o pessoal se matando para comprar ferramentas de dashboards… :-)
No próximo post teremos a última solução integrante da SAStíssima trindade de BI, outro assunto que também é praticamente sinônimo de BI e Data Mining: a Solução Atuarial, vulgarmente conhecida como “Seguros”.
Semana passada começamos a nova série no GeekBI: As Soluções Clássicas. Clique aqui para acessar aquele post.
Hoje veremos a primeira destas soluções: Gerenciamento do Relacionamento com o Cliente, ou em inglês Customer Relationship Management. Sim, você leu corretamente: CRM. O bom e velho, famigerado CRM.
Boa parte do que eu vou trazer aqui pode ser visto no livro Data Mining Techniques, seminal sobre CRM e Data Mining em geral. Se você quer estudar o assunto, esse é o livro.
Relacionamento com o Cliente
Direto ao ponto: antigamente todo mundo comprava tudo – comida, roupa e outras coisas – ao vivo. Ia-se a uma loja, apontava-se o produto, dava-se o dinheiro e saia com ele pela porta. Simples assim. Olhávamos todos uns nas caras dos outros. Íamos a uma loja e não na vizinha porque gostávamos mais desta que da outra. Víamos o dono por ali, conhecíamos os atendentes, confiávamos na procedência dos produtos.
Essa convivência acabava por criar um relacionamento. Você sabe, aquela coisa que sua cara-metade discute ocasionalmente contigo, em uma sessão DR. ;-)
Aos poucos o fornecedor passava a conhecer os gostos do cliente, e este passava a confiar no fornecedor. Esse relacionamento trazia vantagens para ambos: o cliente recebia um atendimento melhor, personalizado, e o fornecedor fidelizava o cliente, tendo mais facilidade para planejar seu negócio e mais oportunidades de vendas. Resumindo, o cliente podia contar com o fornecedor para suprir suas vontades, e o fornecedor via seu faturamento e sua lucratividade aumentar graças à fidelidade do cliente.
Lembram-se como falava-se (ainda se fala?) em fidelizar o cliente? Em atendimento personalizado?
Aos poucos o mercado cresceu e sofisticou-se, e a distância entre o consumidor e o fornecedor foi aumentando. A quantidade de clientes ficou maior, a variedade dos gostos aumentou e a complexidade da linha de produtos acompanhou essa tendência.
Décadas atrás isso já era um problema: mesmo na década de 80, o mero volume de clientes e a efemeridade do seu contato eram tamanhos que ficou difícil saber quem era esse cliente, e como atendê-lo melhor. Pense um supermercado, uma padaria, um posto de gasolina etc. São negócios que envolvem um volume considerável de clientes, que recebem um atendimento rápido: pega-se o produto, enche-se o tanque, paga-se e vai-se embora. Não raro esses negócios – que são apenas um exemplo – têm mais de um caixa. É muito difícil para um gerente conhecer os seus clientes nesse ambiente. Não temos mais tempo para jogar conversa fora, ou demorar muito escolhendo os produtos. É vapt-vupt.
Agora pense em redes de supermercados, padarias e postos de combustíveis. Jogue nisso tudo a Internet e a explosão do comércio eletrônico. Se antes o contato com cliente era fugaz, ao menos era físico. Com o e-commerce (precedido pelas onda das vendas por catálogos), o cliente nem mesmo aparecia mais na loja. Nem sequer temos mais uma “loja” no sentido de coisa de tijolos e cimentos!
Como construir um relacionamento com um ser quase mítico, que para todos os efeitos é invisível e que se move à velocidade da luz?
Customer Relationship
Com Data Mining.
Antes de continuar vamos abrir um parênteses sobre a terminologia.
A idéia de “gerenciar” o relacionamento é usar o conhecimento sobre a clientela para tornar cada contato uma nova oportunidade de aumentar a proximidade/fidelidade do cliente, de fazê-lo consumir de você e não do seu concorrente, ao menos na maior parte das vezes.
O conceito de “gerenciamento de relacionamento” não é trivial. Pense no gerenciamento de recursos humanos: atribuir tarefas a pessoas, deslocar e direcionar times para as atividades da empresa e tudo mais. Troque “recursos humanos” por “relacionamento com o cliente” e estamos falando de reforçar um tipo de contato (por e-mail, chat, telefone) ou enfraquecer outro, de injetar dinheiro para propaganda neste e naquele segmento sobre este e aquele produto, ao invés de abrir um comercial na TV. De usar uma oportunidade de contato para incrementar as vendas ou a satisfação do cliente conosco.
Ou forma de pensar que ajuda a entender o termo é “alavancar”: através do gerenciamento dos relacionamentos com os clientes podemos alavancar (ajudar, empurrar) o crescimento da empresa. Usamos as interações para criar ações que movem a organização para mais próximo dos seus objetivos, da sua visão.
Depois de um tempo a frase parece fazer sentido, mas só com um pouco de familiariedade com uma grande operação voltada ao consumidor é que podemos abarcar completamente o conceito.
Continue pensando, uma hora sai! ;-)
Se você entendeu a idéia na seção anterior, que era aprender sobre o cliente para atendê-lo melhor, e com isso maximizar suas vendas, basta transpor isso para o mundo do cliente sem rosto, mas que interage com a empresa. Cada interação é uma oportunidade de conhecer melhor quem está do outro lado do balcão.
CRM = Data Mining
Vejamos: temos muitos clientes, muitos produtos e, mesmo que não individualmente falando, muitos contatos de clientes. O que são esses contatos?
Uma compra;
Uma re-compra (o cliente voltou para mais;)
Uma reclamação;
Um pedido de serviço;
Etc.
Cada vez que um cliente interage com a empresa, ele deixa um pouco dos seus dados – identificação, localização, interesses, valores, etc. São esses dados que, agregados e acumulados, dá uma montanha de dados que esconde um ouro. Ouro esse que pode ser desencavado com Data Mining. (Mais cliché impossível.)
E Aí?
Que resultados nos traz uma solução de CRM? O que ela consome?
Insumos
Uma solução de CRM analisa dados de todos os sistemas da empresa que tenham alguma interação com o cliente – e mesmo alguns que não têm. Os mais valiosos são aqueles que dão informação direta sobre o cliente: caixas (por isso é importante pedir o CPF, já que permite saber quem é o cliente), reclamações, trocas. Canais de atendimento, como call centers, também são valiosos (por isso que a maioria pede alguma identificação de quem liga.)
Os dados não precisam ser coletados em um DW – surpresa! – mas ajuda muito fazê-lo. Coletar dados históricos, integrá-los e limpá-los são os primeiros passos de qualquer projeto de Data Mining, e por isso mesmo são os primeiros passos do projeto de CRM. Se a empresa decide por uma iniciativa de coleta de dados isolada, estanque, descartando um DW, desperdiça boas oportunidades e gera alguns problemas:
DW é uma tecnologia estável, e projetos profissionais de DW consomem menos recursos, com melhores resultados. Nem preciso dizer que projetos amadores, de qualquer coisa, sempre dão dor-de-cabeça, né?
Gera retrabalho/duplicação de esforços: se apenas o projeto de CRM coleta e organiza os dados dos clientes, qualquer um que queira usar esses mesmos dados na empresa precisa atrapalhar o projeto de CRM, ou duplicar o trabalho em outro lugar;
Seria mais caro: a idéia de evitar o DW é – imagino – poupar o gasto com profissionais “do ramo” e ambientes especiais. Trocar um projeto profissional por outro amador tende a causar atrasos e dificuldades;
CRM é uma boa âncora para DWs corporativos. Como DWs podem ser usados pela empresa inteira, ter um bom argumento a favor de um DW – como o CRM – é um bom argumento para vender a idéia do DW;
CRMs tendem a dar bons resultados e ajudam a melhorar a imagem de todas as tecnologias de BI na empresa, facilitando a mudança de cultura necessária (um dia aborarei isso.)
E isso é parte do ponto de vista da tecnologia. A outra parte deste lado seriam as máquinas, que podem ser muito grandes em função dos volumes de dados envolvidos, e os softwares, que podem ser Software Livre ou proprietário, mas definitivamente são escolhas secundárias.
Olhando para o lado dos recursos humanos, um projeto de CRM requer um Analista de Data Mining com experiência em CRM. Como esse profissional é um bocado caro para ter na folha de pagamentos (primeiro pela especialização, segundo pelo uso relativamente limitado de suas maiores habilidades), o mais comum é recorrer a uma boutique de Data Mining para trazer esse especialista para o projeto, temporariamente. O time do projeto é completado, via de regra, por gente da casa, com membros da TI para ajudar na parte de coleta e tratamento dos dados, e gente do negócio para ajudar na priorização e construção dos modelos.
Entregáveis
Eu adoro dizer que o entregável de um projeto de Data Mining é dinheiro, muito dinheiro!!, mas isso costuma não colar. Pena. :-) A próxima melhor definição dos resultados entregues por uma solução de CRM é “incrementar o valor do cliente”, que é feito através de ações planejadas com o auxílio da inteligência obtida da análise dos dados. Mas com o que se parece, o que é essa “inteligência”? Qual é, concretamente, o entregável do projeto, qual é o produto?
Como eu já coloquei em outro post, o entregável de um projeto de Data Mining são modelos matemáticos. Cada um destes modelos automatiza o processo de decisão em relação à próxima interação com o cliente. Há tantos modelos possíveis que eles são agrupados em várias categorias: Sales Promotion, Survival Analysis, Churn Prevention etc. etc. etc. Vamos ver alguns dos modelos mais famosos.
Para começar, um dos modelos mais interessantes é o Lifetime Value do cliente, que é uma estimativa do valor do cliente por todo seu relacionamento ao longo do tempo, ou dentro de um horizonte, como alguns meses ou anos. De posse dessa estimativa podemos avaliar com mais clareza se vale a pena ou não manter um determinado freguês. Suponha que certo cliente peça um desconto. Vale a pena dar esse desconto para ele? Se fôssemos o dono da loja, sabendo tudo de tudo, seria fácil decidir:
Cliente novo?
Sim. Parece do tipo que dá lucro?
Sim: dê o desconto;
Não: recuse o pedido;
Não. Cliente valioso?
Sim: dê o desconto;
Não: ofereça um desconto menor.
Agora, como ajudar a moça do call center da Americanas.com a decidir? Montando o mesmo script baseado no Lifetime Value!
A saída dessa ação pode ser encaixada com os resultados dados por outros modelos, como os que atuam no incremento das vendas. Imagine se ao invés de recusar o desconto, ou simplesmente concedê-lo, a tal atendente ainda tenha no script ramificações para:
Up-selling: vender algo mais caro ou mais valioso (com maior lucratividade;)
Cross-selling: fazer o cliente comprar alguma outra coisa, não aparentemente relacionada;
Recomendações: recomendar algo mais do mesmo tipo, para aproveitar o desconto.
Cada uma destas ideias é um modelo que o CRM pode gerar.
E que estratégia a organização deve perseguir? Adquirir clientes, ou se esforçar para aumentar a lealdade dos já existentes? (Pegadinha: clientes novos custam muito mais caro que os já adquiridos, por isso é sempre importante investir na manutenção da sua clientela.) Um projeto de CRM ajuda a desenhar estratégias oferecendo modelos para:
Campanhas de retenção, para evitar perder o cliente para a concorrência;
Estímulo de uso, para fazer o cliente se lembrar que possui um serviço, ou se lembrar de voltar a nos procurar;
Programas de fidelidade, que estimulam o cliente a decidir por nós ao invés de pela concorrência;
Redução de atrito: já é difícil segurar o freguês, então pelo menos vamos tentar não empurrá-lo para longe, que é o objetivo deste modelo, de Churn Reduction.
E mesmo quando temos alguns desertores, há modelos que apoiam iniciativas reparadoras. Uma dessas chama-se Customer Reactivation que, como o nome mesmo diz, tenta motivar um freguês que não nos procura a voltar a entrar em contato. Um modelo mostra que cliente é mais propenso a ser recuperado por esta ou aquela ação.
Falando em problemas como clientes, outro conjunto de modelos lidam com o risco que um cliente representa e como manter baixo esse risco. Coisas que o departamento financeiro sempre quer saber como quem tem tantos porcento de falhar no pagamento? Dos clientes que estão atrasando ou deixando de pagar, quais têm maior propensão a pagar alguma coisa, e quanto?
Sempre que eu menciono um destes exemplos você pode tentar imaginar o que estaria acontecendo na proverbial lojinha. A reativação, por exemplo, pode ser uma visita ao cliente, só para bater papo, ou para levar algo que ele gosta. Um pouco de tato pode evitar vender fiado para quem sabemos que vai dar trabalho, e a redução de atrito pode ser um pedido de desculpas por uma burrada. E o estímulo ao uso? Que tal um brinde, que ele aproveitaria melhor se comprasse algo? Não estou brincando: o programa Cliente Mais do Pão-de-Açúcar me deu, uma vez, uma tigela para comer cereal. Fofo, não? (Deu certo, só para constar – por algum tempo eu passei a comprar cereais com mais regularidade.)
Não é Para o Meu Bico
Uma espécie de regra geral para projetos de Data Mining é “precisa de grandes volumes de dados”. Ainda que grande seja uma coisa relativa, hoje em dia nunca é menos de milhões de linhas – milhões de linhas de vendas, de interações com clientes, de produtos, de acessos etc. Isso é uma coisa natural, por que a maioria desses métodos são de inferência: fazem estimativas a partir de um comportamento observado. É como o caso da moeda: não dá para saber se ela é viciada com apenas um arremesso. Precisamos de uma quantidade que mostre a tendência para sair mais cara ou mais coroa, ou então termos uma certeza razoável de que é uma moeda “normal”. Quanto mais dados, menor ou mais delimitado é o erro em relação a uma estimativa. Inversamente, quanto menos dados, maior a incerteza da estimativa.
Essa necessidade de um certo volume de dados não é motivo para barrar análises com menos dados. O erro será maior, mas alguma informação sempre é melhor que nenhuma. Projetos de Data Mining, em geral, e de CRM em particular, podem ser encetados por sua organização mesmo que você não disponha de montanhas e montanhas de dados. Apenas seja mais precavido em relação às iniciativas que vão usar os resultados para alavancar o crescimento da empresa.
Para demonstrar isso, eu deixo vocês com um caso real. Há vários anos, numa das minhas turmas da 4Linux, tive um aluno dono de um supermercado, de São Carlos. Ele queria dispor de relatórios e análises sobre seus dados (principalmente dos caixas) e, como era muito caro contratar um projeto, decidiu fazer tudo ele mesmo. Eu fiquei impressionado, afinal ele era o dono do supermercado (acho que tinha algum sócio, não me lembro), que não era uma loja pequena. Assumir um projeto técnico com uma empresa inteira para tocar, não importa quão pequena, é um desafio e tanto. Bom, ele terminou o curso, e voltou para São Carlos.
No começo de 2015, estimulada pelo Caio Moreno, o Prof. Coruja, a comunidade de Pentaho de São Paulo se juntou para um Meetup. Qual não foi minha surpresa ao reencontrar esse empresário lá?! Já fiquei impressionado de vê-lo se deslocar para um encontro num final de dia, começo de noite, de uma quarta-feira em São Paulo, mas eu fiquei de queixo caído quando ele falou o que estava fazendo: não apenas implantou BI no supermercado, como agora estava atrás de Data Mining para fazer CRM!!! :-O A meta dele era simples, modesta até, mas mesmo assim seria capaz de melhorar a rentabilidade do negócio: se eu não me engano, ele queria reduzir perdas por vendas a prazo. O simples fato de passar da administração do risco de manual para automática já teria impacto positivo no negócio dele.
Nunca mais falei com ele, infelizmente, mas não tenho a menor dúvida que conseguiu, e que hoje deve estar fazendo mais alguma coisa surpreendente e inteligente.
Customer Intelligence
CRM é um termo que ficou meio desgastado – sabe, como OLAP, metadados e o próprio BI. Como o conceito de “gerenciamento do relacionamento” não é algo transparente, imediatamente apreensível, muitas empresas se apoderaram dele para usar em qualquer coisa e surfar a onda do mercado (de novo.) Daí hoje em dia temos CRM que maneja envio de e-mails (mala-direta), CRM que recebe/dispara teleatendimentos (call center), CRM que monitora redes sociais (social-thingamajig) blá blá blá. Nenhum destes casos responde pela “coisa”. Para se livrar desses mal-entendidos, a empresa líder de BI, o SAS, renomeou o campo como Customer Intelligence (“excelente” abreviação: SAS CI – entenderam? Sasci, Saci. Kkkk…)
Bom, o SAS já renomeou quase tudo de BI (incluindo BI, que virou BA), por isso não há nenhuma novidade aqui. Para mim, porém, o termo Customer Intelligence é tão opaco quanto Customer Relationship Management, o que sempre me conduz à mesma conclusão: a ideia não é ajudar, é ser dono exclusivo de buzzwords. SAS, SAS, tsc, tsc… Adiante.
A solução SAS é completa, com planejamento, estratégia, gerenciamento de campanhas, medida de eficiências etc. Não vou entrar nela porque o post é sobre CRM e não sobre o SAS e seus produtos, mas vale a pena conhecê-la. Se quiser ver um pouco mais da cara do resultado de um projeto de Data Mining, que fica por trás de um projeto de CRM, pode ler um pouco sobre o SAS/Enterprise Miner.
Conclusão
Uma forma de entender a disciplina BI é como uma ferramenta de apoio à decisão, ou de automação da decisão. Neste sentido, projetos de Data Mining produzem recursos empregados na automação das decisões de uma empresa, melhorando a precisão dessas decisões e aumentando a velocidade com que são tomadas. Em uma empresa moderna, que dependa de computadores no seu métier diário, minguém consegue manter tudo dentro da cabeça para conseguir entender o que precisa ser feito, e como. Só BI consegue isso, através de Data Mining, em geral, e CRM, em especial, no aspecto da clientela.
Gerenciamento do Relacionamento com Clientes, ou CRM, é um projeto que busca entender o Cliente para melhor atendê-lo.
Um projeto de CRM entrega modelos matemáticos que alimentam desde o planejamento estratégico até a implementação de iniciativas e ações na empresa, sempre com o objetivo de maximizar o valor do cliente, enquanto ajuda a organização a prestar um serviço de maior qualidade. Em outras palavras:
Um projeto de CRM dá ao cliente um atendimento melhor, personalizado, e ao fornecedor a maximização do valor de cada cliente.
Projetos de CRM são ganha-ganha.
Porque tão poucas empresas investem em Data Mining, para mim, é um mistério. Que quase nenhuma tenha um projeto de CRM, então, é um mistério envolto em um enigna.
No próximo post (que não será semana que vem): Credit Scoring. Até lá! ;-)
No primeiro post da série eu apresentei uma analogia direta entre Mineração real e Mineração de Dados. Minha esperança era ter encontrado uma forma simples de responder a pergunta “O que é o produto?”.
No post de hoje eu vou explorar essa analogia e apontar algumas das etapas em um projeto de mineração tradicional e construir uma explicação simples de como projetar e conduzir projetos de Data Mining.
Ilusões Esmeraldas
Você se lembra de expedições chamadas bandeiras, sobre as quais aprendemos na escola? Bandeiras desbravavam nossos sertões e cumpriam várias funções: conseguir mão-de-obra (escravos), expandir recursos (criar plantações e vilarejos), conhecer o território e buscar minérios e pedras preciosas. Uma das mais famosas foi a Bandeira de 1674, que tinha como uma das metas encontrar certa lendária montanha, cheia de prata e esmeraldas. Do verbete da Wikipedia:
A 8 de agosto de 1672, Fernão Dias Pais Leme se apresentou à câmara de São Paulo a chamado de seus oficiais e declarou que, em cumprimento da carta régia, partiria em março seguinte para o sertão de Sabaraboçu a fim de descobrir prata e esmeraldas. Itaverava-uçu ou Sabarabuçu era a “serra que resplandece”, inventada por Filipe Guilhem: sertanista castelhano, a procurar nas “gerais” sem tamanho a misteriosa montanha de prata ou esmeralda, visão do paraíso…
O destaque é meu. Quer dizer, ninguém tinha a menor idéia se existia ou não um veio explorável de qualquer coisa, em algum lugar! Fernão Dias aventurar-se-ia pela mata selvagem em busca de um “visão do paraíso” descrita por outro explorador, sem a mais remota comprovação!
Hoje em Dia…
… mineração é uma ciência elaborada e muito sofisticada. Envolve desde análise de imagens de satélites, amostras de solo, Geologia e Sismologia, Física, Química e até Biologia, em busca de certeza da existência de depósitos, e depois, para o projeto, Engenharia Mecânica e Elétrica de alto gabarito, sem falar em todas as habilidades de gestão, planejamento, finanças etc. etc. etc. Abrir uma mina, hoje em dia, é um brincadeira de menino grande, com várias etapas:
Etapas de um projeto de mineração.
Note que existem três etapas só de pesquisa, para apenas na quarta etapa desenvolver a mina e só então começar a produzir! Muito antes de o minério começar a sair da mina, todas as justificativas financeiras, riscos e promessas estão muito claras. O que não é tão exótico assim: para que gastar dinheiro “estragando” uma paisagem se não for valer à pena?
Projetos de Data Mining precisam ser guiados por esse mesmo raciocínio por um único motivo: é um projeto tão complexo que se não houver um objetivo bem claro, ele vai dar em nada com certeza. Data Mining não é uma ferramenta, que acaba sendo aproveitada em usos paralelos se o uso principal falhar. Nem tão pouco é uma produto essencial, como um ERP ou BPMS, que toda empresa deve ter e por isso é melhor instalar e começar a usar o quanto antes, mesmo sem ter muito claros os detalhes. Toda essa zoeira em torno de BigData e Data Science ajuda a piorar o cenário, pois acabam funcionando como uma cortina de fumaça em volta do assunto.
Data Mining é difícil, é a coisa mais difícil de BI, que é uma disciplina difícil por natureza. Sem um plano bem claro e justificado, Data Mining dá em nada. Pior: dá em desperdício de tempo e dinheiro.
Projeto de Data Mining
Vamos olhar as etapas da figura anterior e compará-las a uma iniciativa de Data Mining numa empresa. Antes de começar, vamos reforçar o que aprendemos no post anterior:
O produto de Data Mining é um Modelo Matemático, da mesma forma que o produto de Mineração é o minério: ambos servem de insumo para produção de algo. Minérios são refinados em produtos, e Modelos Matemáticos são refinados em decisões automáticas.Nosso projeto de Data Mining quer desencavar um modelo. Em que dados? De que maneira? Que valor?
Vamos adiante com a analogia.
Geociência
A primeira etapa de um projeto de mineração fornece dados que encoragem a exploração, que sugiram que ali pode haver uma boa oportunidade. É a etapa que responde a perguntas “o quê estamos procurando?” e “porque aqui e não ali?” Em nossa analogia, Geociências é transformada em Conhecimento de Negócio, puro e simples. É o conhecimento de negócio e da operação da organização que diz onde pode haver uma oportunidade de ganhos.
Quem “faz” Geociência é um profissional especializado, experiente, que já fez isso outras vezes. É um cara tão importante que aparece em relatórios oficiais de minerações. Para o caso do Data Mining estamos falando de uma pessoa com habilidades de Matemática e Estatística de nível de Ensino Superior, com visão estratégica e conhecimento de negócio. Não bastasse isso, é alguém que precisa ter alguma experiência na atividade de avaliar organizações, seus processos de negócio, seus dados e vislumbrar oportunidades de negócio nos dados.
Cientistas de Dados, que é o título de Analistas de Data Mining por esses dias, não se qualificam. Podem ser uma alternativa, na falta do referido profissional, mas não é o ideal porque, em geral, está muito focado nas técnicas e ferramentas, e menos na visão de negócio.
Exploração & Descoberta
A exploração é levada adiante por mineiros e prospectos técnicos, e tem a função de encontrar o depósito mineral propriedamente dito. Depois de o geocientista levantar a forte suspeita da existência de um aluvião qualquer, é essa etapa que vai tirar a prova dos nove e dizer que ali tem mesmo alguma coisa.
Em Data Mining é a tal da Prova de Conceito, ou PoC. Conduzidos pelo “Geocientista Empresarial” (Cientista de Negócios??? Aff…), um time com um Analista de Data Mining e outros SMEs (Subject Matter Experts, tais como DBAs, Financistas, Marketeiros etc.) faz a primeira avaliação da oportunidade levantada. Dá para fazer? Existem dados suficientes? Vai chegar a um resultado ou calcular por anos a fio? E que resultado vai trazer? Qual serã seu ROI?
Eu não gosto do termo, mas entendo que esta etapa pode ser caracterizada por uma buzzword que não colou: Business Discovery. A expressão, agora dentro do conceito de mineração, traz um significado claro: é o resultado da exploração dos dados crús da empresa e aponta para um “veio virtual de dados valiosos”. Eu suspeito que esse era o conceito imaginado por empresas que vivem da buzzword Data Discovery – tanto que BD foi tentado antes, não colou e “morfou” em Data Discovery.
Agora, uma vez que a oportunidade de negócio identificada na primeira etapa, Geociência, foi avalizado por esta etapa anterior, Descoberta, nos resta decidir se vamos adiante, construir o modelo.
Desenvolvimento
É neste ponto que a mina ganha corpo, que figurativamente sai do subterrâneo. É o momento de comprar equipamentos, contratar pessoas e treinar mineiros e, enquanto isso acontece, licenças de operação foram (ou estão sendo) negociadas e adquiridas, uma rede de logística é desenhada, e assim por diante, com muitas coisas acontecendo interdependentemente.
Em Data Mining, nesta etapa, a equipe provisória é formalizada, com os eventuais ajustes, os ambientes e recursos são amealhados, e o projeto de Data Mining ocorre.
Note que em Data Mining estamos uma fase adiantados em relação ao projeto de uma mineração real: o produto da mina – o minério – só vai começar a sair na próxima etapa, mas o produto do projeto de Data Mining – O Modelo – ficará pronto na etapa atual. Até entendo que podemos discutir isso, e eventualmente jogar a produção do modelo para etapa seguinte e declarar esta aqui como uma etapa de planejamento, de venda interna etc. Mas, IHMO, a venda precisa ter sido feita lá atrás, antes da PoC. E depois, montar um projeto de DM é incomparavelmente mais simples e rápido que montar um projeto de uma mina.
Esta etapa possui subdivisões próprias, tal como um projeto de mineração. O Analista de Data Mining constrói, testa e valida o modelo. Esse analista precisa ter uma formação operacional sólida, tem que dominar suas ferramentas e ser do ramo. Não dá para aprender a construir modelos por tentativa e erro, experimentando ora isso, ora aquilo. É preciso saber o que se está fazendo, sob o risco de encontrar um modelo errado.
Ao final desta etapa teremos o Modelo, que é equivalente ao minério extraído pela mina.
Produção
Para a mineração, é aqui que o produto aparece. Ele vem na forma de lingotes, pelotas, fios ou barras, puros ou combinados em ligas, e caem no mercado para venda. Graças à peculiariedades das cadeias de suprimento de nosso mundo moderno, essa produção sempre tem um destino praticamente certo, quando não pago em adiantado.
No projeto de Data Mining, por outro lado, é quando o modelo é posto para trabalhar e gera decisões automáticas. O que acontece nesta etapa depende de como a etapa anterior, modelagem, foi tratada.
Se o Desenvolvimento restringiu-se à criação do modelo, então esta etapa implica em um novo projeto, ou um sub-projeto independente, que é a integração do modelo aos sistemas da empresa. Por exemplo, se o modelo faz a seleção de produtos em uma mala-direta, então ele precisa ser integrado ao gerenciador de campanha e isso requer, via de regra, um mini-projeto. A equipe conta com o Analista de Data Mining, mas fora isso quase sempre é diferente da anterior. Os ambientes são outros e a infra-estrutura envolvida agora é a operacional. Findado esse mini-projeto de integração, o projeto de Data Mining entre em modo de monitoramento, avaliação e ajuste do modelo – operação contínua.
O contra-exemplo é um modelo de pontuação de crédito (Credit Scoring), no qual vários parâmetros são passados e uma pontuação é retornada. Esse tipo de integração pode ser feito por meio de um webservice, um webservice que pode ser construído na etapa anterior, ao longo de um projeto paralelo para integrar o novo método de scoring ao sistema transacional. Neste caso, a presente etapa assume apenas o modo de operação contínua.
Conclusão
Do post anterior tiramos o conceito de produto em um projeto de Data Mining: um modelo matemático, que pode ser usado para gerar decisões automáticas no sistema transacional.
Hoje chegamos a uma nova analogia: as etapas de um projeto de Data Mining:
Geociência: usar o conhecimento de um especialista em Data Mining e negócios para identificar oportunidades nos dados;
Exploração & Descoberta: Prova de Conceito liderada por um Analista de Negócio em conjunto com um Analista de Data Mining para determinar a viabilidade e o ROI da oportunidade;s
Desenvolvimento: desenvolvimento do modelo, usando o método SEMMA por exemplo;
Produção: integração do modelo nos sistemas da organização.
Alguém pode argumentar que essas quatro etapas já existem dentro do CRISP-DM e que estou apenas explicando-o com minhas próprias palavras. Concordo. Minha intenção não é inventar um método, mas ajudar o não-Data Miner a entender o assunto. Nesse sentido, sim, é uma repetição do CRISP-DM. Só que as três primeiras fases do CRISP-DM, tal como estão colocadas, me dão a sensação de que primeiro decidimos por um projeto de Data Mining e só depois envolvemos o negócio, quando na realidade isso não funciona – acredite-me, já vi mais que minha cota disto nestes últimos 15 anos.
Para obter sucesso é o Negócio que deve impulsionar o projeto de Data Mining, não o contrário. Justamente para ajudar o executivo que precisa tomar pé no assunto eu reescreveria o CRISP-DM com outros termos, como por exemplo:
Etapas de um projeto de Data Mining.
Eu ainda não senti aquela epifania que me acomete quando eu tenho certeza que bati em cima. Sinto que está faltando alguma coisa, que dá para melhorar. E até que eu consiga uma abordagem melhor, o que você achou desta? Ajudou? ;-)
O ápice da disciplina de Business Intelligence é criar valor com Data Mining. Mas como isso acontece? Qual é o entregável de um projeto de Data Mining? Como explicar isso a pessoas de outras áreas, leigas em Business Intelligence?
Acho que eu descobri como. Preparado para mais um longo post? Café na mão? Tempo de sobra? (há-há…)
Mineral, Mineração, Mina
Você já viu uma mina surgir?
Primeiro, não há nada: floresta, mata, rios, colinas, montanhas. Nada na acepção humana da coisa, claro.
Vários especialistas chegam e analisam o solo – composição química, camadas, história geológica, ultrassonogragia, sismogramas.
Em certo ponto concluí-se que ali há um potencial de exploração mineral, e uma mineradora assume o negócio: contrata equipe (gestores de todo tipo, operadores de máquinas e sistemas), quota e compra o material necessário para o início das operações.
Aí o vespeiro começa a zumbir: operações de deslocamento e assentamento são montadas, materiais são movidos até lá, pessoas são transportadas e alojadas. Já não é mais o nada da Natureza, a paisagem começou a se modificar e as primeiras marcas da mudança ficam visíveis. Até então, figurativamente, ocorria tudo no subterrâneo, e apenas os patrocinadores e diretores da operação saberiam que estava em curso um negócio. Até agora, ainda, só investimento e pouca coisa concreta.
Conforme o tempo passa, as equipes progridem, abrindo valas, cavando e escorando túneis. Rotas de escoamento futuro são definidas e seguradas, seja por meio de compra de terreno ou manutenções em estradas, ramais rodoviários e hidrovias. As primeiras máquinas de processamento de minério começam a funcionar, e os primeiros carregamentos são extraídos da mina. Talvez anos tenham se passado, e só agora começam a sair os primeiros resultados e sabe-se lá quantos e quais contratempos ou “novidades” foram enfrentados pelo empreendimento. Pode ter havido “revolta” da Natureza, instabilidade de Governo, reviravoltas na economia, problemas trabalhistas, acidentes, limitações financeiras e tecnológicas… Murphy teria orgulho da lista de coisas que podem dar errado em uma aventura destas!
Do ‘nada’ à mineração.
Muito tempo depois de os peritos dizerem que ali, naquele ponto, era possível extrair minério deste ou daquele tipo, a esta ou aquela taxa, provendo um certo faturamento, a promessa se realiza. O negócio está a pleno vapor, produzindo com eficiência e gerando os dividendos almejados.
Hora de descansar.
Será?
Há! Nem de longe!
É preciso manter tudo funcionando – trocar peças, repor consumíveis, atualizar equipamentos e pessoas, expandir ou contrair em função do mercado. Renegociar dívidas, replanejar investimentos, desembaraçar-se de problemas legais – não tem fim! É uma empresa humana a pleno funcionamento! Só haverá descanso quando o último empregado apagar as luzes, fechar a porta e virar as costas, deixando para a Mãe Natureza cuidar da baderna feita pelos “filhos”. Hehe. Deve ser por isso que chamamos Mãe Natureza e não Cunhado Natureza. Kkkkk….
Outra forma de coletar recursos minerais é por meio de um garimpo. Não vou digredir sobre a diferença entre os dois, mas eu vejo garimpo como uma operação muito mais manual, e de menor escala, do que uma mina, em que se conta com mais automação e se produz volumes maiores. Mas eu não sou versado no assunto e essa aqui é só a minha opinião. ;-)
Garimpagem de Dados
Eu estava pensando (de novo ou ainda, a obsessão não me deixa largar o osso) no problema que me foi colocado no trabalho:
Qual é o produto?Puxa, como assim? O produto é a porcaria do modelo, do algoritmo, oras! >:-/
Estou indo rápido demais, sorry. Vamos do início.
A empresa na qual trabalho precisa criar novos produtos, abrir novos mercados e incrementar o faturamento. Não precisa ter passado 15 anos no mercado de BI para saber que, se você cuida das operações mais importantes de um grande ecossistema, você está sentado em uma montanha de negócios em potencial. Todos aqueles dados, interpretados, contam histórias fantásticas, que valem dinheiro não apenas pelo que informam, mas pelo que ajudam a poupar e melhorar a qualidade das operações.
Vários projetos de Data Mining foram iniciados com vistas a extrair esse valor todo, melhorar a segurança econômica da empresa e ajudar os clientes (ou “O” cliente, como queira) a operar melhor, gastando menos, melhor e entregando mais, com mais qualidade.
Mas eis que batemos num iceberg e a idéia de usar Data Mining começou a fazer água: o que é o produto? O que eu instalo? Que tela o cliente vai ver no final? A imensa maioria dos profissionais de TI e executivos estão acostumados com bancos de dados, telas, relatórios. Quando se fala em BI com esses profissionais, se entrou no ramo nos últimos dez anos, vai pensar em dashboards e Data Discovery; se for da antigas, pode pensar em OLAP e dados consolidados. Raramente se ligam no que, de fato, é BI: Ciência a serviço dos negócios.
É aqui que a história da mineração do começo se liga – e é onde eu tenho falhado na comunicação.
O produto é claro: o resultado de um projeto de Data Mining é um modelo matemático, que vira um algoritmo e é, literalmente, programado nos sistemas. A partir daí o sistema, sozinho, começa a tomar as decisões. Lembram daquela história toda de DSS e BI? Pois é: uma solução de Data Mining faz exatamente isso, toma decisões sozinha. Decide se o cliente merece crédito, se esse ou aquele produto deve ser oferecido, se essa ou aquela declaração deve ser auditada etc. etc. etc.
Na Passarela, O Modelo!
Veja:
‘Modelo’ matemático da atração gravitacional.
Se você jogar uma pedra para cima, ou um foguete, ou uma vaca, todos eles vão voltar à terra sofrendo uma força F calculada por essa fórmula.
Se você for um piloto de moto, pode calcular que aceleração a é preciso imprimir a seu bólido para fazer o percurso S da pista no tempo t que ele desejado:
‘Modelo’ matemático da posição de uma moto em uma pista de corrida reta.
Se a pista tiver 1 Km e o piloto quiser fazer isso em 10 segundos:
Resolva para encontrar a aceleração que a moto deve ter para fazer 1 Km em 10 segundos.
Para os preguiçosos: a = 20 m/s2.
Para você ter uma idéia de quanto isso é, a gravidade (a aceleração que te força a ficar no chão) é de ~ 9,8 m/s^2 (ou Pi ao quadrado, como dizia meu eterno orientador, Prof. Carlos Lenz Cesar.)
E, é claro, você pode fazer o contrário: pode usar o modelo para descobrir a aceleração, conhecendo o tamanho da pista e medindo o tempo do início ao fim. Ou medir o tamanho da pista se souber o tempo e a aceleração. Essa é a graça de um modelo matemático: ele correlaciona variáveis e permite que analisemos o que acontece com uma em função da variação de uma outra qualquer. Ah, aproveitando o gancho, vale lembrar que é por isso que precisamos de Data Mining: um ser humano não consegue “enxergar” essas correlações “à olho nu”, só plotando uma coisa em função da outra. Primeiro porque qualquer coisa mais complicada que uma reta já é muito complexa. Veja a curva da moto acelerando:
Gráfico da posição da moto. Consegue usar isso para prever a posição se a aceleração mudar?
Segundo porque se com duas variáveis (t e S) já não é fácil, imagine com 20 ou 200?
Qual é o Produto?
O produto é claro um ovo! É claro para mim, que vivo, como e respiro BI, e sou um cientista desde criancinha (literalmente, hehe.) Nem de longe é claro para outrem!
O produto de um projeto de Data Mining é como o produto de uma operação de mineração: ele não existe antes, é subterrâneo por um tempão e, definitivamente, acima de tudo, não é uma geladeira, que ligamos na tomada e começa a produzir. E para piorar, o resultado de uma operação de mineração é – adivinhe!! – minério! E daí? Puxa, você já comprou pirita para birita, ou viu alguém pilotando um balde de bauxita?? Não? Sabe por quê? Porque minério, assim como o “produto” de um projeto de Data Mining, é um insumo para outra coisa! Ferro para carros, tinta de ouro para terminais elétricos, lítio para baterias, nitrogênio para refrigeração, carbono para uma infinidade de coisas! É como petróleo: extrair é o começo, pois muito precisa ser feito para tornar disponível o poder daqueles hidrocarbonetos complexos até que um carro possa sair andando, sozinho por aí, usando gasolina. Foi preciso inventar algo (em 1886) que se aproveitasse a [gasolina][gas_bitly] (1870) para ela ter o valor que tem, aliás.
Sei lá, entende?! Padaqui, padali. Padicá, palilá.
Grande Orival! Até hoje eu uso seu famoso “sei lá, entende?”, rio só de lembrar…
Bom, o tal do Patropi, personagem do Orival, era um estudante de comunicação que, no fundo, comunicava porcaria nenhuma. Era todo enrolado e vivia confundindo tudo.
Sempre que eu preciso falar de Data Mining eu me sinto meio Patropi: sei lá, entende? Afirmar “o produto é o modelo”, por mais sintético e completo que possa ser, é pouco para explicar o mundo que existe por trás. Mas quando eu começo a desfiar – tem o sistema de origem, daí a necessidade de negócio, e o problema, e então a análise, a modelagem blá blá blá – eu perco a platéia!
E acho que eu finalmente entendi como comunicar isso.
Contando a história da mineradora.
Veja:
A mina não existe até ser criada, como o projeto de Data Mining: não é como um aparelho, um produto, que se compra e usa. Data Mining não é uma melhoria em algo que existia antes, é um novo projeto!
Um projeto de Data Mining está para um sistema transacional da mesma forma que uma mineradora está para uma fábrica de qualquer coisa: são empreendimentos bem separadas um do outro, com vidas independentes;
Assim como um projeto de Data Mining, uma mineradora não gera um artefato pronto para consumo, mas sim um insumo para outra parte da supply chain, a cadeia de fornecimento: o modelo. Mas não um modelo de tabela ou de banco de dados, e sim um modelo matemático, como o que idealiza a realidade e ajuda a entendê-la;
A mina é o produto do projeto da mineradora; o produto do projeto de Data Mining é o modelo. A exploração da mina produz minério, a exploração do modelo produz decisões;
Clientes da mina pagam pelo minério, e vendem produtos acabados; clientes de Data Mining pagam pelo modelo e geram valor (“vendem”) a partir de decisões automáticas.
Agora Vai! O Produto é…
Como eu já coloquei, o produto de um projeto de Data Mining é um modelo matemático. Esse modelo vai ser usado para gerar valor tomando decisões de negócio automaticamente. Como isso vai ser feito depende muito de qual problema está sendo resolvido.
Talvez esse seja um ponto de debate: o produto é o modelo, ou a aplicação dele? No meu entendimento, aplicar o modelo para gerar valor é o resultado (o produto, portanto) de outro projeto, ou do trecho final do projeto de Data Mining. As técnicas de Garimpagem de Dados foram aplicadas até chegarmos no modelo. O uso dele em produção pode, sim, gerar dados que realimentados no projeto de Data Mining refinam o modelo, mas a integração com o sistema transacional é feita por meio de outras artes. A competência dos profissionais de Mineração de Dados acabou bem antes!
Acho que, a esta altura, você já notou que o falado Data Scientist é ninguém menos que o Analista de Data Mining.
E como um modelo pode ser integrado a um sistema on-line, transacional? De diversas forma, como por exemplo:
Vendas: a clássica solução de CRM. Neste caso o modelo é programado em uma solução de campanha de Marketing, e passa a gerar as sugestões de produtos ou ações para cada prospecto ou cliente. Você vê esse sistema em ação sempre que visita uma loja eletrônica e recebe sugestões baseadas no seu perfil;
Crédito: um banco opera em cima de diversos sistemas, como cadastro de correntistas, gestão de conta-corrente, gestão de carteiras de produtos e assim por diante. A equipe de Data Mining trabalha com a equipe de sistemas para criar um módulo que aplica o modelo (chamado de credit scoring, pontuação de crédito) aos clientes. Esse módulo pode então ser usado em vários sistemas, como ATM (onde você pode receber um valor de crédito instantâneo), gestão de empréstimos (para avalizar o negar a operação solicitada pelo cliente), vendas, no qual o modelo do CRM usa o resultado do modelo de credit scoring para selecionar clientes a que oferecer empréstimo e assim por diante;
Seguro: a equipe atuarial (que constrói o modelo) trabalha com a equipe de marketing para calcular os riscos de cada público para cada produto, e com isso derivar a lista de preços. Neste caso o modelo não vira um programa on-line.
Nos casos acima os modelos gerados pelos projetos de Data Mining foram usados para realimentar os sistemas transacionais da empresa com o conhecimento apreendido dos dados. Exatamente da mesma forma que o minério extraído pela mineração vai ser refinado em um produto final.
Eu tento fazer com que todo texto seja fleugmático: interessante, mas controlado, sem deixar a empolgação subir à cabeça. Mas esse aqui vai ser difícil. Quando eu assisti o vídeo eu só conseguia pensar OMGWTFOMGWTF…
Funciona assim.
Data Mining é uma coisa manual. Não é possível fazer uma garimpagem de dados automática, por poucas e boas razões:
Um modelo que represente um negócio (sazonalidade de vendas, por exemplo) é necessariamente muito complexo, e possui, necessariamente, muitas variáveis;
A busca da equação mais adequada é um problema de combinatória: combinar N famílias de equações, parametrizadas por M variáveis;
Dado o número de variáveis e as famílias de equações que podem servir como modelo, o número de combinações explode e a busca, mesmo com supercomputadores (que não estão disponíveis para qualquer um, diga-se de passagem), seria demorada demais para ser útil.
Tradicionalmente o analista de Data Mining faz uma avaliação dos dados, seleciona uma amostra e vira-a de tudo quanto é lado, tentando enxergar alguma possível relação entre as variáveis. A partir daí ele propõe alguns modelos e, paulitanemente, vai limando os menos adequados e melhorando as propostas iniciais. Isso repete-se até que o erro diminua para um patamar definido pelo negócio, e então testa-se o modelo contra o restante dos dados. Se passar, vai para produção, onde ele identificará possíveis clientes, prováveis fraudadores, relacionamentos em atrito etc. etc. etc.
Não dá para automatizar isso e obter um resultado dentro dos próximos milhões de anos, mesmo para pequenos conjuntos de dados, mesmo com problemas simples. Não dá, é uma impossibilidade combinatória. Sempre será necessário algum tipo de guia humano para ajudar a máquina a sair do outro lado.
Um bom programador pode olhar para isso e retrucar que “dá para fazer um programa pré-carregado com os modelos mais comuns e conhecidos”. Isso reduziria a busca no espaço de soluções a um volume muito menor que o espaço inteiro (que pode muito bem ser infinito) e assim semi-automatizar Data Mining. Ok, mas pouco prático, já que cada caso é um caso, e isso reflete-se em cada modelo é um modelo.
Qualquer um que estudou Computação Natural pode olhar para essa situação e intuir a existência de uma solução com Algoritmos Genéticos ou Computação Evolutiva. Eu mesmo, que fui aluno de algumas dessas matérias, cheguei a pensar se não seria possível um motor de Data Mining automático. Nunca levei a idéia a sério, até porque eu sou fraquinho com Matemática.
Mas não é que algém levou? E é isso que o Eureqa, da empresa Nutonian, faz: ele gera uma série de possíveis modelos, aleatoriamente, e evolue-os até um certo erro pré-definido. Nada mais óbvio, nada mais simples. Mas eles fizeram!!!!
Assistam os vídeos deste link para ter uma idéia de como funciona. O exemplo dado no primeiro vídeo (Through the Wormhole with Morgan Freeman) é o mais claro. Eu ainda acho que ele usou um caso muito simples, muito banal (um pêndulo duplo), mas mesmo assim é impressionante!
Pode parecer pouca coisa, ou besteirol científico, mas o simples fato de já existir um produto que faz isso torna a possibilidade de Data Mining automático muito mais próxima da realidade!
Geek BI 