As Sombras São Perigosas?

Pronto, lá vamos nós de novo! A bola da vez é Shadow IT, que é a organização de TI fora da TI.


Gartner: Shadow IT refere-se a equipamentos, softwares e serviços informatizados fora da propriedade e controle do departamento de TI de uma organização.

Wikipedia: Shadow IT é um termo usado com frequência para descrever sistemas de tecnologia da informação construídos e usados dentro de uma organização sem aprovação explícita. Assim como o termo Stealth IT, Shadow IT é usado para descrever soluções especificadas e entregues por outros departamentos que não o de TI.


Soa familiar? Deveria! Olhe esta notícia, de 2 de Fevereiro de 2016:


Gartner estima que as vendas mundiais de software de BI vai atingir US$16.9Bi, conforme as compras mudam do departamento de TI para as mãos de indivíduos adeptos ao auto-serviço. Gartner says $16.9bn BI market in last stage shift from IT to business


Este artigo discorre sobre a tendência de a operação das ferramentas para BI sair da TI e migrar para dentro dos departamentos que usam essas ferramentas. Como estamos em 2016 e a onda de Data Discovery já está passando, o repórter coloca as coisas em uma perspectiva suave comparado ao que foi 2015: “TI ainda tem um papel na captura e preparo dos dados para consumo pelos usuários de negócio”.

Cuma??? Li isso mesmo? “TI ainda tem um papel…”.

Nossa. :-O

Um ano atrás todas as propagandas de Data Discovery e outros quejandos berravam “livre-se da TI, acesse seus dados diretamente, sem precisar de ninguém!” Era praticamente a reedição da Reforma Protestante, agora para Inteligência de Negócios

Nada como um dia após o outro.

Eu até procurei um pouco de todo esse marketing anti-TI, mas não consegui encontrar. Começo a pensar se não vi coisas, ou se não entendi tudo errado.

À Sombra da TI

De volta à vaca fria, o ponto que eu queria enfatizar é que sempre existiu alguma independência entre os departamentos de TI e o restante da empresa. Nas pequenas empresas familiares, um departamento (ou até mesmo dois!) ficam concentrados em uma só pessoa, e o funcionamento da empresa depende das aptidões e talentos multidisciplinares de todos os empregados. Meu primeiro emprego, por exemplo, foi como assistente de vendas na ACATEC (nossa, ela sumiu…) e o trabalho usava uma mistura bagunçada de Word, Access, fax e e-mails. Aos poucos eu aprendi a usar o Access e evoluí o processo de trabalho, até ficar totalmente centrada no Access e eliminar 100% de papel (isso está no meu CV, hehe – e era 1998!!!) Nesse Access registrávamos o contato do cliente, abriámos propostas, mandávamos mala-direta etc. Eu era a TI, o BI, o Marketing E assistente de vendas. :-)

Depois eu fui trabalhar no SAS (graçasadeusaindaestálá!), uma empresa muito, muito, muito maior. Havia um departamento de TI, um cara para cuidar da infra e tudo mais…

… MAS TODO MUNDO ANOTAVA TUDO EM PAPEL!!

O escritório do SAS na maior cidade do maior país da América do Sul tinha uma rotina de trabalho mais manual que da pobre ACATEC. E o que eu fiz? Reconstruí o banco de dados em Access e automatizei o meu trabalho, claro. Mostrei para meus colegas e eles disseram que alguém já tinha tentado fazer a mesma coisa, e até resgataram o que foi feito, mas que não deu em nada.


Foi a primeira vez que eu me dei conta de que não podemos forçar uma boa ferramenta em qualquer uso. O que eu consegui fazer em um dia com Access eles passaram meses tentando, usando o próprio SAS, e não conseguiram. O fato é que o SAS não era voltado para aquela função. Daria para fazer – tanto que eles conseguiram alguma coisa – mas não teria dado tão certo como meu Access nem com todo conhecimento do mundo. E isso faz quinze anos!!


No final veio um mega-sistema da sede, nos EUA, via web, mas ainda não fazia tudo que o meu fazia – estava planejado, mas na primeira etapa era só um apoio para elaboração de propostas. Enfim, saí de lá para uma empresa que vendia software de automação industrial (SCADAs), que era parte de um grupo maior, que incluía uma software house para automação comercial. Era uma empresa nacional, chamada Aquarius, com alcance internacional. Um meio-termo, portanto, entre o SAS e a ACATEC.


Eu, de peixes, trabalhando na Aquarius. Piada pronta… :-P


De novo, operavam na base do papel, e-mail, Word, agendas particulares (de papel! Eu era um dos dois únicos caras com um Palm.) O que eu fiz? Adivinhou: saquei o Access do pacote MS Office, que todo mundo tinha, e reconstruí meu gerenciador de contatos/vendas. Desta vez meu trabalho era todo de campo, e por isso eu precisava visitar muitos clientes. Não tive dúvidas! Criei uma função de planejamento de roteiro. Assim eu poderia passar uma semana no escritório contatando os clientes e fechando agenda para, vai, o sul de Minas Gerais, e registrar tudo. No final eu imprimia um relatório e passava a semana na estrada, ticando empresa após empresa.

De novo, mostrei o que tinha feito em uma reunião da diretoria da empresa. De novo… está ficando cansativo, mas vamos lá…

De novo eles falaram “nossa, igual ao que estamos fazendo!” e me mostraram o que estavam desenvolvendo a coisa de ano ou pouco mais. Claro que eles estavam fazendo um produto para vender e não se comparava com o meu nem em funcionalidades nem em qualidade e aparência. O meu era um Access, manuseado metade por formuláros, metade por tabelas, enquanto que o deles era um aplicativo especial, com instalador, cliente-servidor, todo cheio de ícones bonitos e telas funcionais.

Mas mesmo assim eu os bati – cheguei antes no fim. Na verdade, acho que eu tinha acabado de recriar a idéia do ágil e não sabia. (Eu fazia pedaço por pedaço, para atender uma necessidade imediata.)

Excel-ente!

E esta semana, lendo por aí eu me deparei com o tal do Shadow IT. Ora bolas, eu sempre fui uma sombra de TI! Não quero nem nunca quis sabotar nada, sem contar que algumas vezes eu era a própria TI. Eu sempre tentava obter e adotar a solução oficial. Quando essa não vinha, ou não resolvia um mínimo dos meus problemas, eu partia para resolver eu mesmo.

A maior ferramenta de BI de todos os tempos.
A maior ferramenta de BI de todos os tempos.

Quando os projetos de DW e BI começaram a demorar muito, a frustrar os usuários finais, o que foi que aconteceu?

Eles começaram a contornar à TI! Não é à toa que a funcionalidade mais requisitada em TODOS os projetos de exploração e visualização de dados (aff… “projetos de BI”) é EXPORTAR PARA EXCEL!!! Porque assim cai em uma coisa que o usuário pode fuçar sozinho, sem ser barrado ou frustrado pela TI e pelos “donos” do projeto de BI.

Na minha opinião, foi essa atividade parelala, tocada à sombra da TI formal, que os fornecedores de ferramenta de BI decidiram alimentar. Eu sempre impliquei com todo aquele papo de vendedor, como “se conecta a qualquer fonte de dados”, “self-service!”, porque quase todas as ferramentas de BI, se não todas mesmo, conectam-se a quase todas as fontes de dados, ou ao menos ao conjunto dos bancos mais famosos. Isso nunca foi uma revolução.

A revolução, mesmo, foi o vendedor desviar da porta do departamento de TI e ir bater no departamento de vendas. Na minha opinião, as modernas ferramentas de BI, mais leves e de menor porte, vieram na esteira dessa mudança no paradigma de vendas, e não o contrário.


Eu não levei mais que alguns meses no SAS para chegar a conclusão que BI se vende na diretoria, não na TI. Mais tarde eu percebi que, de maneira geral, essa abordagem é um traço da cultura de vendas do SAS e por isso veio a mim tão rápido (e eu me achando esperto…) Apenas frequentávamos a TI para ter certeza que não seríamos sabotados por um gerente magoado ou por uma prima-dona dodói. Mas nossa mira era sempre o C-Suite, nunca TI.


Conclusão

Meu ramo é BI, e tendo a olhar só BI. Porém, esse movimento “Self-Service” para informatização existe em muitos outros campos. Quantos gerentes não usam planilhas e smartphones para cuidar de suas agendas, deixando o sistema de agenda corporativa para um papel de comunicação/interface? Ou quantos departamentos inteiros não rodam em sistemas locais, completamente separados dos sistemas oficiais da empresa? E quando essa situação surge, adivinha o que acontece? Punem-se os responsáveis pelo sistema paralelo e força-se a adoção do oficial? Não, muito pelo contrário! Não raro a TI oficial assume que o sistema paralelo existe e funciona e deixa de competir por aquele “nicho” local, dedicando suas forças a coisas que ainda precisam da ação oficial.

O termo Shadow IT para faladores de português pode induzir à percepção de algo sombrio, fúnebre ou fora-da-lei. Mas em português, quando ficamos por perto, mas não à frente, ficamos à sombra de algo ou alguém. É esse o sentido, na minha interpretação, do termo Shadow IT. A tradução mais adequada talvez seja TI Paralela ou TI Alternativa.

Ao observar esses fatos – a TI paralela por necessidade, conveniência ou comodidade – e a explosão do mercado de ferramentas, eu passei a acreditar que não estamos vivendo a era do BI Self-Service, mas a do BI Paralelo, do Shadow BI.

O que me leva à uma forçosa conclusão:


Não existe Data Discovery. Não existe Data Lake. Não existe qualquer-coisa-BI-self-service, como eu venho argumentando há algum tempo, aliás.

O que existe é um mercado de softwares para a TI Paralela, e Self-Service Business Intelligence é um desses sub-mercados.


Quando eu me sentei para escrever esse artigo minha visão era colocar Shadow IT e o movimento de BI Self-Service lado-a-lado e, por meio de alguns paralelos, questionar se o que estava acontecendo não era a ascenção da Shadow IT, muito mais que o crescimento do auto-serviço. Só que eu não estava preparado para o que eu descobri: como sempre, eu recolho algumas referências para alimentar meus argumentos1, mas eu encontrei uma extrema dificuldade (leia-se: uma infrutífera hora googlando sem resultados) para encontrar propagandas, anúncios, posts esgoelando sobre “como a ferramenta X vai te dar independência da TI”.

Ao invés disso eu encontrei declarações contemporizadoras, suavizando o embate entre TI e usuário pelo acesso aos dados. Uma situação praticamente impensável a até um ano atrás, ou menos.

Eu não acredito em ferramentas de exploração de dados totalmente dominadas por usuários de negócio – self-service, data discovery – porque isso demanda um conhecimento e habilidade fora do alcance de 99% dessa comunidade. Acho mais fácil acreditar em um departamento de TI paralelo, translúcido, oculto nas dobras do continuum espaço-tempo, digo, corporação-tempo.

No fundo, você sempre precisa tratar os dados, sempre precisa de profissionais que só vão ser encontrados no departamento de TI. Me parece que a que mudou não foi o poder, da TI para o usuário, mas sim o que é a TI, que saiu do departamento e foi para mais perto do usuário final.2

Ufa!

Até a próxima! ;-)


  1. O que me deixa aberto ao viés de confirmação, acusação da qual eu me declaro totalmente culpado. ;-) 
  2. O título é um infame trocadilho. Não deu para aguentar, perdão. 

Nadando em Lagos de Dados

Para escrever meu primeiro post sobre Data Lake eu pesquisei sobre o assunto. Abri o Firefox e saí fuçando o mundo com o Google. Achei alguns artigos interessantes, até que um deles matou o assunto e fiz o post. Eu peguei o restante das pesquisas, dei uma passada d’olhos e, como não achasse nada muito divergente daquilo, descartei.

Limpando meus papéis eu achei um dos artigo que eu separara para ler com mais calma, chamado – que criativo! – DataLake, publicado pelo Martin Fowler em pessoa, em fevereiro de 2015.


Ele se autodefine como “author, speaker, and loud-mouth on the design of enterprise software”, ou em bom português, “autor, palestrante e tagarela sobre o design de software corporativo”.

Eu sou um fã de seu trabalho e já li muitos livros dele e da série Signature, a maioria através Addison-Wesley. Ele é muito bom, e é preciso que se destaque isso: em desenvolvimento de software. Ele nunca publicou ou palestrou sobre BI. O mais perto que ele chegou foi um livro sobre NoSQL escrito em parceria e, pelo visto, este artigo. Por mais que eu o respeite em seu campo, não posso ter o mesmo sentimento quando ele atua fora de sua área. Neste caso o que ele escreve está mais para uma visão multidisciplinar e informada que um comentário de especialista no assunto.


E não é que tem ali uma coisa que eu não tinha notado? Algo que parcialmente redime o conceito de Data Lake e confirma a importância de Data Vault. Vou pegar o assunto do começo, desenvolver o tema e, na conclusão, mostro o que me escapou antes. Acredito que isso vai ajudar a entender melhor tanto o conceito e a utilidade de um Data Lake, quanto a verdadeira natureza de ambos – Data Lake e Data Vault.

Despensa, Cozinha e Salão

Não deixe de ler o artigo, que é muito bem escrito e é do próprio Martin Fowler. Ele começa:

Data Lake é um termo que apareceu nesta década para descrever um importante componente do encanamento analítico no mundo do Big Data. A idéia é ter um único depósito para todos os dados crus que qualquer um na organização possa precisar para análise. Normalmente o povo usa Hadoop para trabalhar os dados no lago, mas o conceito é mais amplo que meramente Hadoop.

Eu saí pulando pelo artigo, da primeira vez, e do meio dele achei o que eu queria ouvir (ler!):

O Data Lake não deve ser acessado diretamente com frequência. Pelo fato de os dados serem crús, você precisa de um bocado de habilidade para tirar qualquer sentido deles. Você tem relativamente pouca gente que trabalha no Data Lake, e conforme eles descobrem visões úteis genericamente, eles podem criar Data Marts cada um do qual com um modelo específico para um único bounded context. Daí, um número grande de usuários podem tratar esta “loja a beira-rio” como uma fonte de dados fidedigna para aquele contexto.

No original: The data lake shouldn’t be accessed directly very much. Because the data is raw, you need a lot of skill to make any sense of it. You have relatively few people who work in the data lake, as they uncover generally useful views of data in the lake, they can create a number of data marts each of which has a specific model for a single bounded context. A larger number of downstream users can then treat these lakeshore marts as an authoritative source for that context.

Neste ponto eu parei de ler e fui escrever aquele post. Quando eu retornei e reli este artigo inteiro, eu notei a primeira relação desta visão de Data Lake com um Data Vault: assim como o proposto aqui por Fowler, um Data Vault não é uma estrutura para acesso direto. Os dados de um DV precisam ser refinados para uma área de apresentação, para aí então serem consumidos. Usando a metáfora de restaurante do Kimball, um Data Vault é a despensa, e tanto o DV quanto o Data Lake precisam passar por uma cozinha que deve preparar os dados para consumo pela clientela.

Aff… Medo de perder o contato com a realidade com tantas metáforas… Enfim, em frente.

Uma Rosa por Qualquer Outro Nome

Não bastasse essa semelhança, existe um outro conceito amarrado ao Data Vault que aparece no post do Fowler: o bounded context, que corresponderia a um conceito meio obscuro em DV, o Unit of Work.

Primeiro, o que é bounded context? A imagem abaixo dá um exemplo:

Ilustração do conceito de contexto limitado - bounded context.
Ilustração do conceito de contexto limitado – bounded context.

Agora a definição de bounded context:

Bounded Context is a central pattern in Domain-Driven Design. It is the focus of DDD‘s strategic design section which is all about dealing with large models and teams. DDD deals with large models by dividing them into different Bounded Contexts and being explicit about their interrelationships.

Ou, em tradução livre, “contexto limitado é um padrão central em Domain-Driven Design. É o foco da estratégia de design, que mostra como lidar com grandes modelos e equipes. DDD lida com modelos grandes dividindo-os em diferentes contextos limitados, sendo explícito em seus inter-relacionamentos”.

Em outras palavras, o tal do “contexto limitado” que o Fowler usa para dar sentido aos dados consumidos do Data Lake é similar ao conceito de orientação a assunto, subject oriented, do Inmon e [Kimball][dmmanifesto_bitly]:

“(…)what a data warehouse is – a subject oriented, nonvolatile, integrated, time variant collection of data in support of management’s decisions(…)”

Como o próprio Linstedt (o criador do Data Vault) insiste na necessidade de um área de apresentação de dados, tanto o conceito de “orientação por assunto” ou “limitação de contexto” se aplicam ao Data Vault! Mas há algo mais: existe um conceito pouco mencionado chamado Unit of Work (UoW), ou “Unidade de Trabalho”.

Conceito de UoW ilustrado: cada circunferência representa uma "unidade", que se integra a conceitos vizinhos.
Conceito de UoW ilustrado: cada circunferência representa uma “unidade”, que se integra a conceitos vizinhos.

Eu revi os livros e fiz uma busca pela Internet, mas não achei nada definitivo sobre o assunto. Este post foi feito por um dos alunos do Hans Hultgren, que parece ter sido o único a avaliar o conceito do ponto de vista de modelagem. Isso seria a definição de UoW:

  • A Unit of Work defines a correlated set of data;
  • A Unit of Work keep things together;
  • A Unit of Work establishes consistency between arriving data and data stored in the Datavault links;
  • UOW should be consistent with the (Enterprise wide) business keys.

Resumindo e traduzindo, traduzindo e resumindo, uma Unidade de Trabalho segundo Hans Hultgren é:


Um conjunto de dados correlacionados entre si, que faz sentido apenas quando estão juntos e representam aspectos do negócio.


Nest link e neste outro link esse conceito aparece de novo, mas sempre jogados, sem aprofundamento.

Então temos três conceitos:

  • O clássico subject oriented, da área de DW;
  • O bounded context herdado da área de desenvolvimento de sistemas;
  • O misterioso Unit of Work, visto em textos de Data Vault.

E todos eles querem dizer praticamente a mesma coisa: um conjunto de dados relacionados entre si, que representam a realidade da organização tal como foi capturada pelos sistemas informatizados.

Romeu & Julieta. Quê?! Shakespeare de novo, uai! Peguei gosto. :-)
Romeu & Julieta. Quê?! Shakespeare de novo, uai! Peguei gosto. :-)

Esta bela imagem foi retirada da Wikipedia.

Juliet:

‘Tis but thy name that is my enemy;
Thou art thyself, though not a Montague.
What’s Montague? It is nor hand, nor foot,
Nor arm, nor face, nor any other part
Belonging to a man. O, be some other name!
What’s in a name? that which we call a rose
By any other name would smell as sweet;
So Romeo would, were he not Romeo call’d,
Retain that dear perfection which he owes
Without that title. Romeo, doff thy name,
And for that name which is no part of thee
Take all myself.

W. Shakespeare, Romeu and Juliet

Portanto temos mais um tema em comum entre a visão de Data Lake de Martin Fowler e os conceitos de um Data Warehouse: o conjunto de dados correlacionados entre si.

Mesmo Assim…

… Fowler comete alguns equívocos:

  • Ele afirma que modelar o dado na entrada é um beco sem saída. De fato, usando modelo dimensional ou a terceira forma normal, não há solução possível. Cedo ou tarde esses modelos abrem o bico e quebram. Eu já discuti isso aqui e a conclusão foi justamente que um Data Vault supera essa limitação;
  • Ele diz que qualidade de dados é um problema, primeiro porque pode ser difícil equalizar a qualidade entre fontes diversas, e depois porque Data Mining (ele não usa esse termo, mas é disso que ele fala) precisa dos dados sujos. Ele tem razão e está errado nos dois casos, pois um modelo dimensional, que é feito para apresentação, guarda dados limpinhos e cheirosos, mas não um Data Vault. Um DV guarda 100% dos dados tal como vêm dos sistemas de origem, tanto que uma das premissas é que possamos reconstruir o estado do sistema de origem usando o DV e ter 100% de auditabilidade;
  • Aceita que o sistema de origem pode e deve mudar, afirma que o Data Lake deve guardar tudo e nunca apagar nada, mas deixa em aberto como gerenciar a associação entre as diversas capturas ao longo do tempo e a variação de esquema no sistema de origem. Quer dizer, até entende essa necessidade – uma coisa básica em todo DW – mas não tem idéia de como deve ser feito. Apesar de um modelo dimensional e um na 3NF poderem assimilar essas mudanças, um Data Vault é a única modelagem que aguenta.

E, vamos reconhecer, ele diz uma coisa muito muito bacana: You should use a data lake for analytic purposes, not for collaboration between operational systems. Ele afirma que trocas de dados transacionais entre sistemas devem ser feitas usando tecnologias como chamadas HTTP RESTFul e não via DW/DL/WH(atever). Finalmente! Acredite se quiser, tem gente que vê essas tecnologias de BI/DW como respostas para toda e qualquer necessidade. Absurdo! Mais um ponto para o Sr. Fowler.

Conclusão

É isso que conseguimos quando pegamos profissionais inteligentes, altamente gabaritados e humildes1 como Martin Fowler. Ele conseguiu enxergar na definição do James Dixon, da Pentaho, um componente do cenário de análises de dados de uma organização. Até então, eu via no conceito Data Lake apenas um departamento de marketing forçando a barra para vender software.

Mas o resultado final do post do Fowler é muito maior que seu conteúdo:

Data Lake Data Vault
Dados crús Dados crús
Precisa destilar para consumir Precisa destilar para consumir
Context bounded Subject oriented

PQP DE RODINHA!!!

O que o artigo dele coloca é de uma obviedade cristalina, e por isso mesmo nós, gente comum, deixamos passar:


DATA LAKE = DATA VAULT


Só o gênio dele para trazer essa relação à tona.

Então, da próxima vez que aventarem um Data Lake do seu lado, responda: “show! me dê o curso do Linstedt, o Wherescape e vamos começar!”

;-)


  1. Para mim é inconcebível um cara da área dele falar sobre outro assunto com tanta propriedade sem ter estudado e se consultado com um monte de livros e pessoas e ter ouvido essas pessoas. A lista de agradecimentos dele, ao final de seu artigo, reforça minha certeza. 

Eleições Inteligentes

Agora que estamos na época, diga-me: como você escolhe seu candidato às eleições?

Essa é uma escolha pessoal (mas de arrependimento coletivo :-) ) e não tem uma fórmula. Cada um vota de acordo com sua consciência e opinião.

Não deixa de ser curioso, portanto, os argumentos que cada político apõe à sua campanha. Um dos candidatos a vereador em São Paulo, por exemplo, promete acompanhar de perto os gastos públicos. Para dar um exemplo do que está falando, ele soltou uma lista das emendas aprovados na câmara dos vereadores, que geraram despesas.


Hmmm… Dados tabulados… Planilha…


É claro que eu não pude resistir e, morando em São Paulo, eu tinha que fazer um exame mais visual desses dados.

Assim Não Vai Rolar…

Eu poderia usar o Calc (=Excel do LibreOffice) ou qualquer outra ferramenta. Optei pelo [BA Server 5.4][ba54] que me permite importar um arquivo CSV e montar um cubo. Assim eu poderia examinar os dados e montar um post para o blog. Eu estava farejando um caso neste assunto.

Eu me propus a uma tarefa muito simples:


Examinar os gastos das emendas de vereadores, no período 2013-2015, contra as principais dimensões: Vereador, Destino da Verba e Tempo.


Não queria achar nenhum padrão oculto nem nada, apenas exercitar um pouco de ETL/OLAP com o Pentaho e aproveitar para ver como o dinheiro está sendo gasto.

Expertei a planilha para CSV e importei no BA Server usando o wizard de nova fonte de dados. Isso me deixou com um cubo OLAP, “pronto” para explorar.

Primeira Visão: Por Vereador

Coloquei entre aspas porque estava pronto coisíssima nenhuma. Vejam:

Valor de emenda aprovada, quebrado por vereador.
Valor de emenda aprovada, quebrado por vereador.

O nome do verador pode aparecer de mais de uma forma, resultando em linhas que não são agregadas. Assim parece que temos dois vereadores “tipo Netinho”, cada qual com um total de gastos, quando na verdade é um só político:

Vereador Gasto
Netinho de Paula 180.000,00
Netinho De Paula 660.000,00
Netinho de Paula”_” 560.000,00

O “_” é para indicar que o nome possui um espaço extra ao final, dando três “nomes” diferentes para a mesma pessoa.

E apesar de o objetivo ser examinar os valores por vereador, se eu quisesse ver por partido, quantidade de votos etc. não daria, pois essa informação não consta na planilha.

Segunda Visão: Por Objeto

Vamos lá:

Valor de emenda aprovada, quebrado por objeto, i.e. destino da verba.
Valor de emenda aprovada, quebrado por objeto, i.e. destino da verba.

Nossa, pior ainda! Até há um padrão de nomes, mas não é consistente (nomes duplicados de formas diferentes, como no caso dos vereadores) nem prático (não dá para analisar um gráfico com um item “Reforma do CDC Moinho Velho, no bairro do Ipiranga, incluindo troca do piso do salão de festas, do salão sede, do vestiário e sanitários, troca do telhado, instalação de forro de gesso no salão de festas, reforma da parte elétrica/luminárias, além de pintura geral – Rua Elba 980 – Ipiranga”!!)

E também não dá para separar por categorias, como Saúde, Esporte, Reforma, Compra etc. Até temos que orgão recebeu o dinheiro, mas não vai além disso. Não dá para, por exemplo, comparar os gastos de subprefeituras com secretarias municipais.

Terceira Visão: Por Ano

Até temos um padrão melhor, graças ao fato de termos uma coluna só para ano:

Valor de emenda aprovada, quebrado por ano.
Valor de emenda aprovada, quebrado por ano.

… mas não dá para quebrar por mês, por exemplo, ou para saber qual dia da semana tem mais aprovações.

Também não dá para quebrar por região da cidade ou qualquer outro parâmetro, como quantidade de eleitores, por exemplo. Imagine saber quais são os projetos que atendem mais pessoas? Será que tem algum padrão bairrista, onde somas vultosas são gastas com projetos populistas, mas de baixa serventia pública? Isto é, que é bonito pra chuchu, mas atende pouca gente?

Data Quality To The Rescue!

Eu sempre quis fazer um post com exemplos de Data Quality, e estava apostando que esta planilha seria um bom caso.

Há uma renca infinita de operações e técnicas de limpeza de dados, mas na maior parte dos projetos sempre usamos as mesmas técnicas. Duas destas técnicas mais frequentes são muito úteis, e se aplicam diretamente ao ETL: normatização e classificação dos dados.

Por exemplo, o “multi-vereador” que vimos acima passaria a ter um único nome, e as agregações passariam a funcionar. Isso é normatização: damos uma norma aos membros de um conjunto, que obtemos montando – manual ou automaticamente – um dicionário para traduzir todas as formas de cada elemento em uma forma só.

Já a classificação é uma técnica que automatica extrai atributos de um certo elemento. Por exemplo, podemos usar a data, que existe na planilha, para conseguir as informações de mês e dia da aprovação do gasto.

Em outro exemplo, podemos fazer buscas por textos específicos em cada linha tratada, e assim gerar uma classificação automática para os dados. Vou usar essa técnica para tratar os objetos de cada emenda, e descobrir se pertencem à área da Saúde, Esporte ou Cultura, se são Melhorias ou Compras e assim por diante.

Vamos lá.

Normatização com Dicionários

Com relação ao nome dos vereadores, precisamos montar um dicionário que “traduz” cada variação de nome para um padrão. E já que estamos nesta, podemos fazer um pouco mais: podemos enriquecer essa planilha com outros dados do vereador, como partido, quantidade de votos conquistados etc.

Na verdade podemos fazer a mesma coisa com tudo nesta planilha:

  • Orgão: tipo (Secretaria, Subprefeitura, Autarquia etc.);
  • Região da cidade atendida: Centro, Sul, Leste, Oeste, Norte;
  • Objeto: usufrutuário, prazos etc.

Imagino que a Câmara dos Vereadores registre esses e muitos outros atributos em seus sistemas, mas o que temos é só essa planilha e por isso não dá para extrapolar demais.


O nome do vereador na planilha original vem com maiúsculas e minúsculas. A primeira coisa mais fácil a fazer é mudar todos para caixa baixa ou alta – prefiro alta.

Daí podemos pegar o partido, votação etc. do vereador em algum site. Eu achei uma página do UOL sobre as eleições de 2012 que trazia tudo: nome do vereador, partido e quantidade de votos. Com isso tudo em mãos eu construí uma planilha Excel com o seguinte layout:

Coluna Função
VEREADOR_ORIGINAL Nome do vereador na planilha original
VEREADOR_CORRIGIDO Nome corrigido
PARTIDO Partido pelo qual ganhou a eleição
VOTOS Quantidade de votos recebidos pelo vereador
VOTOS PARTIDO Quantidade de votos recebidos pela legenda

A tabela abaixo mostra como essa tabela foi preenchida:

VEREADOR_ORIGINAL VEREADOR_CORRIGIDO PARTIDO VOTOS
Abou Anni ABOU ANNI PV 
Adilson Amadeu ADILSON AMADEU  PTB  40100
Adolfo Quintas ADOLFO QUINTAS PSDB 
Alessandro Guedes ALESSANDRO GUEDES PT 
Alfredinho Alfredo Alves Cavalcante (ALFREDINHO) PT  36634
Andrea Matarazzo ANDREA MATARAZZO  PSDB  117617

Porque há casos de nenhum voto? Não sei. Provavelmente é um vereador suplente, que não constava na lista que eu usei. Dá para corrigir, mas o propósito deste post é exemplificar algumas técnicas de Data Quality e por isso não me preocupa se sobrar algumas lacunas.


Depois eu fiz mais duas colunas: faixa_votos_1 e faixa_votos_2. A primeira qualifica o vereador em faixas de 10.000 em 10.000 votos. A segunda faz uma divisão em três categorias: menos de 50.000 votos, entre 50.000 e 100.000 votos, e uma última de mais de 100.000 votos.

Depois eu apliquei a mesma idéia para o orgão e criei este dicionário:

Coluna Função

| ORGAO_EXECUTOR_ORIGINAL | Orgão na planilha original |
| ORGAO_EXECUTOR_CORRIGIDO | Nome do orgão corrigido |
| TIPO_ORGAO | Tipo: secretaria, autarquia etc. |
| REGIAO_CIDADE | Região que atende, ou Geral quando não tem |

Que, preenchido à mão, ficou assim:

ORGAO_EXECUTOR_ORIGINAL ORGAO_EXECUTOR_CORRIGIDO TIPO_ORGAO REGIAO_CIDADE
Autarquia Hospitalar Municipal AUTARQUIA HOSPITALAR MUNICIPAL AUTARQUIA GERAL
Fundo de Preservação do Patrimônio Histórico e Cultural FUNDO DE PRESERVAÇÃO DO PATRIMÔNIO HISTÓRICO E CULTURAL FUNDO GERAL
Fundo Municipal de Assistência Social FUNDO MUNICIPAL DE ASSISTÊNCIA SOCIAL FUNDO GERAL
Secretaria Municipal de Coordenação das Subprefeituras SECRETARIA MUNICIPAL DE COORDENAÇÃO DAS SUBPREFEITURAS SECRETARIA MUNICIPAL GERAL
Secretaria Municipal do Verde e do Meio Ambiente SECRETARIA MUNICIPAL DO VERDE E DO MEIO AMBIENTE SECRETARIA MUNICIPAL GERAL
Serviço Funerário do Município de São Paulo SERVIÇO FUNERÁRIO DO MUNICÍPIO DE SÃO PAULO AUTARQUIA GERAL
Subprefeitura Pinheiros SUBPREFEITURA PINHEIROS SUBPREFEITURA OESTE
Subprefeitura Sé SUBPREFEITURA SÉ SUBPREFEITURA CENTRO
Subprefeitura Vila Mariana SUBPREFEITURA VILA MARIANA SUBPREFEITURA SUL
Subprefeitura Vila Maria/Vila Guilherme SUBPREFEITURA VILA MARIA/VILA GUILHERME SUBPREFEITURA NORTE
Subprefeitura Vila Prudente/Sapopemba SUBPREFEITURA VILA PRUDENTE SUBPREFEITURA LESTE

Classificação Automática

Resolvidas essas dimensões, restou apenas o objeto de cada emenda. O que contém a lista de objetos de emendas? Coisas assim:

  • Contenção Margem com Gabiões – Rua Magdeburgo – Processo nº 2013-0.102.577-8;
  • Readequação área de lazer Rua Constantino Cavafi – Processo nº 2013-0.102.541-7;
  • 26º Campeonato de Moto Aquática – Jet Ski – Associação Brasileira de Jet Ski Profissional e Não Profissional;
  • E172 – Realização de Duas Etapas da Copa São Paulo de Jet Ski na Represa do Guarapiranga;
  • Execução de Obras de microdrenagem nas Ruas Rodrigues dos Santos, joão Teodoro e Ruas limitrofes no Bairro do Brás;
  • Associação Beneficente Nossa Senhora do Pari – Melhorias e Ampliação de Atendimento para adequação, ampliação e reforma do mobiliário e equipamentos hospitalares referente ao setor de Nutrição e Dietética;

E assim por diante. A única forma de fazer uma classificação precisa, bem-feita, é manualmente. São quase 1.800 projetos aprovados. Se eu levar um minuto para qualificar cada um, são 1.800 minutos ou 30 horas trabalhando sem parar.

No $%#%!@% way.

Logo, ou achamos o sistema de origem e vemos o que mais dá para puxar, ou montamos uma aproximação. Por exemplo, podemos montar uma tabela com uma coluna para cada atributo, como “É uma compra de material/produto?”, “É um pagamento de serviço?”, “É um gasto com saúde?” e por aí vamos. Daí, para cada objeto que entrar nesta tabela na primeira coluna, respondemos as perguntas em outras colunas. No final teríamos algo assim:

Objeto Compra? Cultura? Saúde? Esportes?
E2538 – Fundação Antonio Prudente(…) Não Não Sim Não
Implantação de equipamento de Ginástica (…) Sim Não Não Sim
Realização de obras e pavimentação de vias, visando a melhoria (…) Não Não Não Não
Incentivo à pratica de esportes Não Não Não Sim

Isso permitiria uma classificação rudimentar, inicial, que desse ao menos uma visão geral. Com ela podemos responder perguntas como “quanto do gasto é compra de material novo, e quanto é manutenção?” Ou “quanto estamos alocando de dinheiro para Saúde, Educação e Lazer?”

Uma forma de se fazer seria colocar essas linhas em uma planilha Calc e uma coluna para cada pergunta. Daí, usando fórmulas como IF() e FIND(), buscamos as ocorrências de termos-chaves. Sempre que encontrarmos um, marcamos com “SIM”. Se não encontramos nada, com “NÃO”.

E, de fato, foi a primeira coisa que eu fiz:

Primeira tentativa de qualificar os objetos.
Primeira tentativa de qualificar os objetos.

Era uma solução muito tosca, mas me ajudou a entender a mecânica da coisa. Com isso eu pude subir para o nível seguinte: usar RegEx, isto é, Expressões Regulares para fazer essa detecção. Usando expressões regulares eu poderia montar um processo de detecção automático e mais robusto que uma planilha Excel.

Assim, aproveitei o que eu aprendi com o livro RegEx Com Python e, com o auxílio do passo Regex Evaluation consegui extrair essa informações do nome do objeto de cada emenda parlamentar.


Eu parei de criar atributos e de refinar minhas RegExes quando comecei a ter um resultado aproveitável, mas poderia ter ido mais longe e conseguido bem mais coisa – até mesmo reconstruir a descrição da emenda aprovada. Mas, de novo, não era essa a meta e por isso não avancei.


Transformação Eleições 2016

A figura abaixo dá a visão geral da transformação que lê a planilha e gera um CSV pronto para importação no BA Server:

Transformação que incrementa a qualidade dos dados da planilha.
Transformação que incrementa a qualidade dos dados da planilha.

Essa transformação, e todos os dicionários, resultados e um pouco mais, estão disponíveis para download aqui, como um zip. Descompacte em um diretório qualquer e abra os arquivos .KTR com o Spoon do PDI 5.4. Falarei mais sobre a outra transformação na Conclusão.

Agora Sim!

Muito bem, com um novo e melhorado conjunto de dados, recarreguei o CSV no BA Server e gastei um tempinho refinando o mapeamento. Vejamos o que podemos fazer agora.

Por Vereador: bem melhor! Agora dá para ver todo mundo, numa só posição.

Valores aprovados por vereadores em São Paulo, no termo 2012-2016.
Valores aprovados por vereadores em São Paulo, no termo 2012-2016.

Veja que existe apenas um vereador que aprovou menos de um milhão de Reais em emendas. Até dá para dizer que existe duas faixas:

  • Uma turma que libera muito, com totais sempre maiores que R$ 5.000.000,00;
  • E outra que é mais modesta, que fica entre os R$2M e R$4M.

Mesmo assim não temos nenhum “calombo”, que seriam vereadores que liberam (ui!) muito mais que a média (ai!). Eu diri até que eles se espalham em uma graduação mais ou menos suave.

Por Objeto: Agora sim! Mesmo sendo uma classificação incipiente, consegui ver que os dez maiores valores em gastos concentram-se em coisas que não é nem para Saúde, nem para Esportes ou para Cultura.

Valores aprovados por qualificação de objetos.
Valores aprovados por qualificação de objetos.

Os dois picos são muito curiosos… Daí eu fui olhar por orgão:

Valores aprovados por orgão.
Valores aprovados por orgão.

Uia. Quem mais recebe dinheiro de emenda parlamentar… é a Secretaria de Esportes e Lazer, mas os picos do gráfico anterior mostram que o grosso do dinheiro não vai para isso… Confuso! Com certeza culpa da classificação porca e apressada que minhas expressões regulares toscas.


Eu explorei essas visões um pouco mais do que eu vou mostrar aqui. A menos que eu tenha cometido um erro grosseiro, parece que há mesmo uma concentração de emendas para Secretaria de Esportes. Eu fiquei pensando sobre o quê explicaria isso, e bolei uma hipótese: eventos e ações voltadas para Esportes causam um impacto mais marcante, e não constumam ser caras. Assim, se um político precisa prometer algo que tenha condições de cumprir, prometer fazer um evento esportivo parece uma opção de boa relação custo-benefício.

Mas é só uma hipótese, sem nenhum embasamento sério nos fatos. Tipo assim, um chutão. ;-)


E eu continuei a cutucar os dados, até que me deparei com uma visão interessante:

Eleitores representados por gastos.
Eleitores representados por gastos.

Lemos esse gráfico assim: “O maior valor foi liberado para emendas criadas por parlamentares com representação menor que 50.000 votos”. Legal, não é? Como a maior quantidade de vereadores tem menos que 50.000 votos, ter a grana concentrada nessa parcela de políticos significa que o dinheiro está sendo empregado em projetos da maioria dos vereadores, e que são projetos de baixa representatividade, ou seja, tocados por políticos que representam poucos eleitores.


Eu sou partidário do voto distrital, e não da forma atual. Esse gráfico reforça meu viés pelo voto distrital, mas evitaria tomá-lo como uma prova inconteste da vantagem dessa opção.


Essa é uma visão difícil de ler, mas é bem curiosa:

Valores em ementas espalhados na área proporcional a cada orgão.
Valores em ementas espalhados na área proporcional a cada orgão.

Imagino que era para ser um gráfico de árvore, mas ficou meio estranho…

Ele representa o valor gasto por orgão, dentro de cada tipo (Fundo, Subprefeitura etc.) De novo, observe como parece haver alguma desproporção entre os valores alocados à Secretaria Municipal de Esporte e Lazer e, por exemplo, a de Saúde. Até a de Cultura é maior que a de saúde!

E o gasto ao longo do tempo? Não parece nada de mais, um comportamento quase aleatório:

Distribuição de valores nos meses de aprovação.
Distribuição de valores nos meses de aprovação.

Eu poderia prosseguir aqui até a próxima eleição… de 2018. Mas não é preciso tanto. ;-)

Conclusão

Diz o ditado: Lixo Entra, Lixo Sai. Análises de dados dependem de dados Limpos, bem tratados etc. Existem muitas formas de se cuidar dos dados para que eles possam nos contar a verdade por trás de si. O ramo que responde por essas técnicas chama-se Data Quality e costuma ser uma disciplina complexa.

Vimos que, mesmo sendo trabalhoso, qualquer melhoria pode render ganhos significativos. Por isso considere sempre fazer ao menos uma avaliação da qualidade dos seus dados que o cliente vai examinar.

Coceira…

Com os dados ali, prontinhos, e os assuntos separados em tópicos, eu fiquei com a mão coçando para andar mais um pouco e transformar aquilo em uma estrela dimensional. Como a melhor maneira de se livrar da tentação é ceder, eu cedi.

Peguei a transformação anterior e coloquei alguns passos que alimentam junk dimensions. Isso deu origem a dimensões instantâneas de Vereador e Orgão.

Modelo dimensional miojo: basta adicionar Junk Dimensions!
Modelo dimensional miojo: basta adicionar Junk Dimensions!

Depois eu juntei todos os atributos em uma dimensão junk de verdade, e mais adiante adicionei outra para os objetos das emendas. Eu poderia degenerá-lo mas, francamente, a idéia daquele texto todo na fato, uuhhh calafrios, não me agradou.

Por fim criei uma dimensão data completa, usando um passo Database Lookup. Pronto! Um Table Output no final, sair clicando em todos os botões SQL para criar tabelas, rodar e…. PIMBA! Tudo no ar!

Eu peguei o Power*Architect e fiz uma engenharia reversa no banco. Ajustei alguns detalhes (como os relacionamentos) e voilà! Modelo dimensional de valores de ementas!

Diagrama de tabelas da estrela Emendas Vereadores 2013-2015.
Diagrama de tabelas da estrela Emendas Vereadores 2013-2015.

Esse diagrama e a transformação que o alimenta estão no mesmo pacote deste post. Fique à vontade para brincar, explorar e descobrir. Apenas mantenha em mente o seguinte:


Eu, Fábio, não sou responsável pelo conteúdo de dados deste pacote, nem por qualquer interpretação que alguém tirar dele.

Me incluam fora dessa! ;-)


Até a próxima!

Full Metal BI Itch

Outro dia assisti um filme de SciFi que eu adorei, No Limite do Amanhã, ou Edge of Tomorrow no original em inglês. (Clique aqui para ver o trailer.)1

Nele o herói “ganha” o poder de resetar o dia, ativado pela morte. Assim, cada vez que ele morre ele volta para o início de um certo dia – sempre o mesmo, sempre na mesma hora. Como o dia recomeçou, as coisas se repetem, sempre as mesmas, desde que ele tome as mesmas decisões. Logo ele percebe isso: os eventos futuros mudam em função das ações dele.

Por exemplo, na primeira “vida” ele é emboscado pelo inimigo logo que chega na praia. Na segunda, ainda sob o choque de ter morrido pela primeira vez, ele morre no mesmo lugar. Na terceira vida, quando ele chega na praia ele já sabe onde o inimigo vai estar, e acerta um tiro em cheio… e sobrevive! Apenas para morrer segundos depois, de novo, e reiniciar o dia pela quarta vez.

E assim ele vai: a cada vida que ele “revive” ele já sabe onde falhou da última, e avança mais um pouco.


Agora que eu parei para pensar um pouco, exatamente como em um video-game!


Amei aquele filme. Adoraria pode esquecê-lo só para poder vê-lo de novo e sentir a mesma emoção que eu senti da primeira vez.

E o que ele tem a ver com BI?

Guenta as pontas aí, já vou amarrá-las. Antes, um pouco sobre…

Técnicas de Garimpagem de Dados

Se você ainda não leu, leia. Esse deve ser o livro de BI mais de BI que existe:

O livro de BI mais de BI que existe. Leia!
O livro de BI mais de BI que existe. Leia!

Em sua introdução ele explica uma coisa chamada “ciclo virtuoso do Data Mining”, na minha tradução livre:


A promessa do data mining é encontrar padrões interessantes dormentes em todos esses bilhões e trilhões de bits jazendo em memórias computacionais. Meramente encontrar esses padrões não é o suficiente. Você deve responder aos padrões e agir sobre eles, em última instância transformando dados em informações, informações em ações e ações em valor. Esse é o ciclo virtuoso do data mining, resumidamente.


Capítulo 1, páginas 9 e 10 da terceira edição física, ou locação 676 para quem tem o livro no Kindle.

Acho que não preciso interpretar o que ele disse, não? É muito óbvio, certo?

Se é tão óbvio, seu projeto de BI deve estar fazendo, não?

Ah, não estão fazendo porque seu projeto é de Inteligência de Negócios, não de Data Mining? Entendi. ;-) Vamos ver o início do capítulo 3, então?

O que é que pode dar errado, não é mesmo?
O que é que pode dar errado, não é mesmo?

Este capítulo do livro vai esmiuçar um problema de Data Mining em suas partes e aspectos gerais e comuns entre várias técnicas. Não vou traduzir tudo que está escrito aqui, exceto por este trecho:


Data Mining is a way of learning from the past in order to make better decisions in the future.


Traduzindo mais ou menos ao pé-da-letra:


Garimpagem de Dados é uma forma de aprender com o passado a fim de tomar melhores decisões no futuro.


The Ultimate Past is The Future!

Vamos voltar ao filme: a cada vez que o herói morre, ele volta para o início do fatídico dia. Naquele momento, o futuro ainda não aconteceu mas, na cabeça dele, já. Ou seja, para ele, o passado é uma história que já aconteceu, e está para se repetir. Ele pode, portanto, usar o que aprendeu na sua “vida anterior” para tomar melhores decisões… no futuro!


Loucura, não? Filmes de Ficção Científica com viagem no tempo são mesmo de dar nós nas nossas cabeças. Enfim, adiante.


A esta altura acho que é impossível você não notar a ligação entre Data Mining/BI e o filme. Falam da mesma coisa!!

Isso não acontece na vida real, claro, mas… E se pudesse acontecer? E se você pudesse voltar um ano? O que faria? Mandaria alguém embora? Cancelaria uma venda ou faria mais pedidos de matéria-prima? Ou faria tudo igual, de novo?

Você há de concordar comigo que, se pudesse mesmo voltar um ano, muito provavelmente faria alguma coisa diferente. Duvido que você não tenha um único arrependimento sequer. Não? Mesmo? E o dólar?

A-há! Agora percebeu, né? Se pudesse voltar um ano, saberia quando comprar e vender moeda estrangeira e faria uma grana fácil!

Curiosamente, esse poder de “prever o futuro” existe hoje, mas raros usam-no. Quem dá a uma empresa o poder de prever o futuro é justamente Data Mining, em particular, e Inteligência de Negócios, em geral!

Claro que não é possível prever, com exatidão, o valor que o dólar vai ter amanhã, ou semana que vem, ou… Não se trata disso. Se trata de, sabendo como um negócio funciona, bolar uma equação matemática – um modelo matemático – que ajude a calcular as chances de determinadas situações acontecerem.

Daí, baseados nesse modelo, que é a informação tirada dos dados, podemos tomar decisões com chances melhors de sucesso. Evidentemente não é uma decisão garantida, mas entre optar por um caminho ao invés de outro por pura intuição, ou fazer uma escolha embasado no que já aconteceu, obviamente preferimos apostar no que já vimos acontecer.

O arriscamos no cara-ou-coroa, ou apostamos em algo mais sensato.

Odd Squad

Um bom exemplo de como Data Mining age sobre nossas decisões pode ser vista no seriado infantil Esquadrão Bizarro, episódio “Undercover Olive”.

Sem entrar nos detalhes desse seriado, que é divertido pra chuchu, a história é simples: os vilões roubaram o mapa para o quartel-general dos mocinhos – o tal Esquadrão Bizarro – e vão presenteá-lo a quem vencer o torneio de jan-ken-po do mal. Para impedir que esse mapa caia nas mãos de qualquer vilão, o Esquadrão Bizarro decide mandar uma agente, disfarcada (undercover) para participar do torneio e ganhar o mapa. Eles contam com uma vantagem: Oscar, cientista do grupo, analisou torneios anteriores e fez a contagem de cada movimento (pedra, papel ou tesoura) de cada vilão. Assim, quando a agente Olívia disputa um jogo, o Oscar “sopra” por rádio qual opção ela deve fazer para ter a maior chance de vitória.

O Esquadrão Bizarro: Oscar, Srta. O, Otto e Olívia.
O Esquadrão Bizarro: Oscar, Srta. O, Otto e Olívia.

No começo é fácil: a maioria dos vilões tem algum padrão, e eles usam esses padrões para ganhar. Mas quase no fim aparece um vilão que é aleatório! Ele sempre usa quantidades praticamente iguais de cada movimento, aleatoriamente. Não existe escolha mais provável, e a equipe fica em uma sinuca de bico: chutar qualquer coisa, e arriscar, ou se agarrar ao método que usaram até ali e fazer um chute calibrado?

É como Data Mining: pode ajudar muitas vezes, mas existe sempre o risco de errar pois não é uma previsão exata.


O Esquadrão Bizarro é um programa para crianças, que usa aquele fino humor britânico. É praticamente um Dr. Who para crianças, e usa uma pancada de clichès. Oscar, o cientista do Esquadrão, é obviamente inspirado no Q, o cientista do MI:6, das histórias do James Bond. O sistema de tubos é uma interpretação infantil dos teleportes de Star Trek, e assim por diante. E tem as galinhas-laser, uma birutice que não remete a nada, só piração mesmo. ;-) Meu filho de sete anos (e eu) adora(mos), mas o de dez acha uma chatice.


Ciclo Virtuoso do Conhecimento

Apesar de o livro tratar de Data Mining e por isso usar a expressão Ciclo Virtuoso do Data Mining, na minha opinião o correto seria falar Ciclo Virtuoso do Conhecimento ou Ciclo Virtuoso da Inteligência de Negócios, já que não é a garimpagem de dados que eleva a rentabilidade da empresa, mas sim o conhecimento gerado por meio de um processo de Data Mining que provê as melhorias.

Do início do terceiro capítulo, eis o ciclo:

  1. Identificar o problema;
  2. Transformar dado em informação;
  3. Tomar uma ação;
  4. Avaliar o resultado.

Auto-explicativo, não?

Conclusão

Comprar ferramentas, montar DWs, entregar dúzias de dashboards, etc. etc. etc. são ações tidas como “de BI”. São todas vazias, inúteis e até um desperdício de dinheiro se elas não forem construídas dentro do Ciclo Virtuoso do Conhecimento, no qual todos esses projetos e ferramentas são aplicados na construção de conhecimento, que depois é usado para tomar uma ação. Sem aplicar o conhecimento obtido em uma ação concreta, todo esse esforço terá sido desperdiçado, terá sido em vão.

Volto a frisar:


Se sua empresa não tem um problema para resolver, então não precisa de BI.


E se tem um problema, não começe comprando uma ferramenta bacana, ou subindo um projeto de “Data Lake”, ou coisa que o valha. Não.

Comece pelo começo: identifique o problema.

E sempre tome uma ação. Ou você vai viver todas as suas vidas repetindo os mesmos erros e morrendo no mesmo lugar.

Está sentindo essa coceira por BI?

Aquilo não é uma espada, é uma hélice de helicóptero!
Aquilo não é uma espada, é uma hélice de helicóptero!

Até a próxima! ;-)


  1. Há uma ligação entre o título do post e o filme. Assista-o e descubra. ;-)