Se você comprou a versão pré-lançamento, que estava online até hoje cedo, já pode baixar a versão final da primeira edição: visite a página Atualize a versão do seu eBook Kindle e siga as instruções.
Se você não se lembra do que estou falando, tudo bem. Faz só quatro anos que eu publiquei a versão de pré-lançamento do livro: eu queria aproveitar meu aniversário de 20 anos em BI, e prometi a versão final para dali a dois meses.
Ha! Dois meses. Como eu estava otimista.
Para o livro chegar ao ponto em que eu queria, que é servir como livro-texto para um curso de Inteligência de Negócios, eu entendia que precisava oferecer três coisas:
Definição: o que é Inteligência de Negócios?
Justificativa: porque sua empresa deve usar BI?
Contexto: ferramentas, tecnologias, processos e história.
O primeiro item e parte do último formavam a versão preliminar. Porém, a justificativa não era tão firme quanto eu gostaria. Além disso, não existem processos típicos de BI. No máximo existem processos de gestão de projetos de BI, mas não de funcionamento de uma área de dados em si.
Após o pré-lançamento eu me dediquei a criar esse o processo e a refinar essa justificativa. Porém, como em uma reforma em que o verdadeiro esforço só é conhecido quando você começa a quebrar tudo, e aí já é tarde, eu só descobri o mato sem cachorro no qual me meti quando continuei o trabalho para completar o livro.
Foi tentando fundamentar a motivação para usar BI que eu notei que não existe motivo que te obrigue a usar Inteligência de Negócios.
Sim, isso mesmo: não existe motivo. Pode espernear e xingar, eu espero. Eu fiz o mesmo.
É óbvio que analisar dados é uma atividade crítica para o sucesso de uma empresa. Isso não se questiona. O que sempre me atormentou, porém, é o fato de que inúmeras empresas (a maioria, na minha observação) vivem sem se preocupar com dados. É fácil de perceber que, depois de tanto tempo existindo sem fundamentar a gestão em informações derivadas dos dados, uma empresa simplesmente vive. Ela pode não ir à falência, pode não dominar o mercado, mas deixar de usar BI não mata ninguém!
Ou seja, se é possível viver sem BI e não afundar, então existe um motivo para praticar Inteligência de Negócios?
Se não faz (tanta) diferença, porque usar?
Eu estava convencido que uma empresa deve usar BI, claro, mas não conseguia exprimir essa convicção sem que ela parecesse mero achismo da minha parte.
Eu levei um tempo até encontrar uma forma expressar esse argumento de tal maneira que ele pudesse ser criticado, que pudesse ser contestado e debatido. Sem isso, todo meu argumento não passaria de achismo e opinião, que é justamente o que eu me propus a evitar quando decidi escrever esse livro. Minha visão para o livro é que ele trouxesse argumentos que fizessem sentido, que tivessem lógica e pudessem ser debatidos e contestados porque se sobreviverem a esse escrutínio, então eles estariam corretos. Se não, então eu teria a chance de aprender e melhorar e tentar de novo. Mas não poderia nunca ser algo dogmático, tirado do ar e sem fundamentos.
Afinal, esse é o nome do livro, né? ;-)
Quando finalmente encontrei essa linha de raciocínio eu fechei o conteúdo. Daí eu trabalhei mais um ano e qualquer coisa até finalizar todos os detalhes relevantes, como a História da Inteligência de Negócios, os casos de livro-texto, ortografia, bibliografia e mais alguns detalhes até me dar por satisfeito e me sentir tranquilo em dizer que o livro está pronto e acabado.
E uma definição certa, precisa e usável de Ciência de Dados, com que eu finalmente fiz as pazes graças ao Scott Ambler.
FIN, 1a. Edição PublicadA
Agora completo, o livro ganhou uma nova descrição:
Definições são importantes.
Médicos não iniciam seu estudo em um hospital, mas em uma sala de aula, aprendendo os conceitos e definições mais básicos. Engenheiros, biólogos, matemáticos, advogados, todos começam aprendendo as definições das próprias áreas. Afinal, como podemos estudar e aplicar algo se não sabemos o que é aquele algo? Apenas depois de tal estudo é que o podemos aprender sobre os instrumentos e procedimentos de cada profissão.
O que é Inteligência de Negócios?
Essa pergunta é respondida há décadas, se não séculos, e mesmo assim ainda não existe uma definição única, aceita por todos. Há quase tantas definições de Inteligência de Negócios quanto há livros, artigos e vídeos sobre o assunto. A maioria das definições baseiam-se em situações concretas – é a coleção de ferramentas, é o ato de analisar dados, é usar dados para lucrar mais e assim por diante. Uma porção menor de definições segue um molde mais acadêmico, abstrato, tentando colocar BI na intersecção de várias outras disciplinas, como Engenharia de Computação, Estatística e Admininstração.
Todas essas definições derivam da observação de projetos de BI, que é uma abordagem inadequada. Afinal, se Física fosse conceituada da mesma forma, por exemplo, ela seria definida como “a aplicação de instrumentos de laboratório para estudar a Natureza”, o que não diz nada. A definição de Física atualmente aceita é ao mesmo tempo simples e completa: o estudo do comportamento da matéria no espaço e tempo, e suas relações de força e energia. Esta definição não amarra Física à existência de experimentos, ou de ferramentas ou processos.
Definições equivocadas, incompletas ou confusas não apenas atrapalham como também podem levar a erros. Por isso é muito importante usar definições fundamentadas em argumentos claros, que possam ser contestados e debatidos. Possuir uma boa definição permite um melhor aprendizado e um trabalho mais fácil e produtivo.
Com Inteligência de Negócios não pode ser diferente. Existe uma definição para Business Intelligence que também possa ser útil, abrangente, fundamental?
Ao invés de se definir BI sobre o que se vê, que são as ferramentas e os processos, este livro constrói uma definição de Inteligência de Negócios através da observação do funcionamento de uma empresa e sua relação com a Informação e os dados. Com essa definição ganhamos liberdade e capacidade de resolver problemas em suas raízes, ao invés de simplesmente tentar mudar processos ou ferramentas.
Como este livro está organizado
O livro é composto por duas partes e fechado por dois apêndices.
A primeira parte inicia-se definindo BI, seguindo-se pela inferência e definição de uma disciplina complementar, a Inteligência Operacional. Em seguida mostramos a aplicação prática dos conceitos vistos e finalmente formalizamos tal aplicação em um processo, que pode ser aplicado em qualquer empresa. O final da primeira parte discute a relação entre BI e a administração de uma empresa.
A segunda parte aborda os temas tradicionalmente associados à Inteligência de Negócios: as ferramentas, processos e tecnologias.
Os dois apêndices adicionam contexto ao leitor: o primeiro elenca os eventos históricos que desaguaram na Inteligência de Negócios, desde o Egito Antigo aos dias atuais, e o segundo reúne casos clássicos de Data Mining.
Em TI vivemos imersos em estrangeirismos, que é como se chama o uso de uma palavra de outra língua no nosso idioma natal.
Em si, isso não é ruim. Por exemplo, quando a palavra nativa é desajeitada ou esquisita, um termo de outra língua ajuda bastante: quebra-luz ou sustentador, as palavras em português para abajur (abat-jour) e sutiã (soutièn).
Mas em outras ocasiões isso é um problema sério. Meu exemplo favorito é leader. Traduzido como líder, a palavra não evoca nada. Ou melhor, evoca aquela pessoa destemida, à beira de um promontório, com o peito aberto para o espaço e um olhar confiante e distante.
Só que essa imagem que a palavra cria na sua cabeça está errada. Quer ver? O que é um guia?
Você deve ter pensado “é o cara que conhece o caminho, os desvios, atalhos, riscos e armadilhas”. Correto. É a pessoa que já passou por ali e vai te ajudar na travessia. É um profissional que vai tomar as decisões e vai se responsabilizar por elas, que vai delegar e cobrar o resultado, que amalgar várias pessoas, todas únicas e diferentes entre si, em uma coisa coesa, com direção firme.
E adivinhe? Leader, traduzido, significa guia.
Entendeu? Só de mudar a palavra estrangeira para seu equivalente nativo você já ganhou uma idéia melhor do que significa ser um líder. Agora você pode até avaliar se é uma pessoa para essa posição ou não, pode avaliar quem te lidera, pode escolher quem vai querer para ser seu guia. E em várias dimensões: profissional, pessoal, social…
Hub, Link and Satellite
Um Data Vault é um repositório de dados usado para construção de Data Warehouses.
Vamos mudar a frase anterior: “um cofre de dados é um repositório de dados usado para construir armazéns de dados”. Notou? Só de trocar Data Vault por cofre de dados e Data Warehouse para armazém de dados as imagens na sua cabeça estão diferentes.
Traduzir Data Vault por cofre de dados não é uma boa idéia, porque um Data Vault não tem nada a ver com segurança ou inviolabilidade. Mudar DW para Armazém de Dados, porém, já ajuda.
O mesmo ocorre com as estruturas básicas de um Data Vault: hub, link e satellite. Desta forma, em inglês, elas não dizem muito. Quando estudamos cada uma dessas estruturas aprendemos que se referem a layout de tabela muito específico.
Agora, veja como a coisa muda se traduzirmos:
Hub: Pivô;
Link: Elo;
Satellite: Satélite.
Pivô
Pivô, do francês pivot, é aquele elemento sobre o qual se faz uma rotação (pivotear) ou aquilo que fica no centro, no eixo, no qual se ligam outras partes.
A função de um hub é justamente essa: estar no centro do armazém de dados, como um conceito de negócio, no qual outras estruturas (links e satellites) vão se ligar.
Cubo, caixa, eixo, âncora – muitas outras traduções existem para hub, mas eu gostei mais de pivô. Cubo já existe em BI, eixo é esquisito. Caixa e âncora não têm significado claro neste contexto.
Elo
Em um Data Vault, link é uma tabela que liga dois ou mais pivôs (hubs). Essa é uma palavra muito usada, comum até fora da Informática: todo mundo compartilha links para todo tipo de coisa – páginas web, perfis em redes sociais, arquivos e formulários etc. etc. etc.
Não seria um problema deixar link como link (como hub também não era). Mas…
Mas existe uma palavra em português que serve muito bem para essa função e transmite a imagem mais adequada: elo. Ao invés de um caminho para alguma coisa, como nos habituamos a pensar para link web (que no mais das vezes é uma URL e não um link), a palavra elo transmite a idéia de coisas ligando-se entre si e formando algo maior. E essa é exatamente a função de um tabela elo (link): conectar, ligar dois ou mais pivôs e assim conectar todos os conceitos de negócios entre si.
Link poderia ser traduzido, também, por conexão, ligação, contato, junção, ligadura, ligamento etc. Nenhuma dessas palavras, porém, cria uma imagem tão ilustrativa do conceito de link como elo.
Satélite
Um satellite em Data Vault é a tabela que guarda contexto. É lá que ficam os atributos que podem ser atualizados e descrevem os conceitos de negócio (pivôs) e contextualiza as relações entre esses conceitos (elos).
A palavra é tão próxima do português satélite que quem usa Data Vault sempre fala “hubs, link e satélite”, misturando português e inglês como se fosse uma feijoada de frango.
E é uma palavra muito apta à sua função: ela se liga aos outros elementos e sempre apenas a um, como um corpo preso por atração gravitacional a um outro corpo (eu sou físico e satélite para mim tem uma imagem muito clara). Se eu tivesse criado o conceito de Data Vault, talvez chamasse de “context” ou “attributes” ou qualquer coisa mais óbvia (não sou um cara criativo, mind you), mas Daniel Linstedt escolheu satellite e caiu muito bem.
Assim, completando a tradução dos conceitos de Data Vault, eu vou continuar com satélite, como todo mundo.
Pivô, elo e satélite
Meio como Doc Brown, de “De Volta para o Futuro”, um dia eu tive uma epifania sobre como a língua interfere na interpretação do texto. Tudo começou com Data Mining, que depois de dez anos traduzindo como mineração de dados eu mudei para Garimpagem de Dados (e hoje eu diria Garimpagem em Dados).
Desde então eu venho testando traduzir alguns termos para verificar se em português eles mais ajudam ou mais atrapalham. E hoje eu decidi acabar de vez com hub, link e satélite. Não apenas por causa da feijoada de frango que é misturar português e inglês tão intimamente, mas porque eu quero poder ampliar a audiência do Data Vault, agora que (FINALMENTE!!!) o mundo (e o Brasil junto) o descobriu.
Então, a partir de hoje eu vou falar “pivô, elo e satélite” ao invés de “feijão, paio e frango”, digo, “hub, link e satéite”.
Essa mudança não causou um aumento na velocidade de entrega de novas funcionalidades. Ou melhor, não causou um aumento na quantidade de novas entregas – afinal, eles não falaram que aumentaram o time e sem mais recurso você não pode fazer mais.
Ao ir de um deploy por mês para dez por dia, eles reduziram o tempo entre uma idéia entrar em desenvolvimento e chegar ao mercado. Daí, ao invés de fazer um grande release por mês eles passaram a fazer dez pequenos releases por dia.
Tudo bem, vocês dirão, e daí?! Afinal, se cada release tem um custo, eles acabaram foi multiplicando esse custo (overhead) por 200 – 20 dias úteis no mês, vezes 10 deploys.
E que raios tem isso a ver com BI?!
Vamos chegar lá. Eu vou fazer o seguinte:
Ilustrar o processo de como empresas criam diferencial competitivo;
Extrair o fundamento desse processo na forma de um conceito;
Extrapolar esse conceito no contexto de uma empresa contemporânea;
Generalizar – aqui eu chego aos dez deploys por mês;
Relacionar dados e o conceito acima;
Relacionar os dez deploys a BI.
Pegue um café, vai ser um filme!
Um Dia na Vida
Imagine duas lojas, lado a lado, na mesma rua. Ambas vendem a mesma coisa, têm o mesmo tamanho e, portanto, atendem o mesmo público.
A Loja A é gerenciada por um experiente empresário, que cresceu naquele ramo e conhece tanto os produtos quanto a clientela. Ele sabe o que todos precisam e o que vender melhor, o que dá mais lucro e como acompanhar a sazonalidade do mercado. Ele está lá há dez anos, é apreciado por todos do bairro e reconhecido como um bom comerciante. As pessoas frequentam sua loja e sentem-se bem lá.
A Loja B está no bairro a menos tempo. Como a Loja A, seu dono e gerente é um profissional experiente, competente e boa praça. Apesar de seus preços serem um pouco menores que seu concorrente, e ele ter um relacionamento bom com o bairro, seu comércio raramente tem mais público que seu vizinho.
No fundo, a única diferença entre as lojas são as coisas periféricas – arrumação dos itens, empregados, decoração etc.
Um dia, o Gerente B está parado na porta e conversando com seu vizinho e concorrente, o Gerente A:
Gerente B: Você já recebeu o novo sorvete da Kifrio?
Gerente A: Sim, recebi hoje cedo. E você, não comprou?
GB: Sim, comprei também, mas chega só amanhã. Mas, se você já comprou, porque ainda não está na vitrine?
GA: Ora, porque estamos na terça-feira. Ninguém compra coisas novas na terça-feira. Vou te dar uma dica: todo mundo quer novidade às sextas-feiras. É quando as pessoas voltam de casa se preparando para o fim-de-semana e já aparecem aqui perguntando por alguma coisa diferente. Se eu botar o sorvete agora, não terei nada novo na sexta-feira, o sorvete já não será mais novidade.
GB: Puxa, obrigado. Você não tem medo que eu te copie?
GA: Ora, temos quase tudo igual e mesmo assim eu ainda tenho mais gente aqui. Além disso, tem espaço para todos.
Isso deixou nosso herói, o Sr. Gerente B, pensativo. “É verdade”, ele concluiu, “eu posso fazer qualquer coisa e o Sr. A ainda vai vender mais que eu.”
Liberdade, Liberdade
Como o Sr. B estava em uma situação confortável, com a loja gerando um lucro satisfatório, ele ponderou que não tinha nada a perder se experimentasse algumas idéias. Afinal, depois de anos copiando o vizinho e tentando fazer tudo que ele fazia, melhor – menores preços, melhor decoração (na opinião do Sr. B, claro), mais limpa, mais iluminada etc. – ele ainda era o segundo do bairro, a alternativa quando a loja do Sr. A estava muito cheia ou estava sem um determinado produto.
Ele percebeu que estava livre para inovar.
Sua primeira ação foi colocar o sorvete na vitrine assim que o recebeu. Claro, o Sr. A torceu o nariz e até ficou meio chateado. Puxa, ele deu uma dica daquelas e o Sr. B a ignorou! Era quase uma ofensa!!
Enfim, lá foi o Sr. B vender antes os sorvetes. Na sexta-feira, dito e feito, o Sr. A começou a vender o novo sorvete e, claro, sua loja encheu como sempre.
Porém, o Sr. B notou algo: ele recebeu mais clientes atrás de sorvete do que o normal. Não mais do que o vizinho, mas mais que ele mesmo recebia.
Pega-Pega
Na semana seguinte, o Sr. B mudou sua decoração.
Na outra, alterou a posição das gôndolas.
Em seguida, comprou outras marcas de diversos produtos e passou a oferecer uma opção a mais, e para isso ele precisou reduzir o estoque de seus produtos tradicionais.
No final do mês ele mudou a decoração de novo.
O Sr. A acompanhou tudo achanda uma graça o espernear do vizinho. Afinal, esse monte de mudanças só podia significar uma coisa para o Sr. A: a Loja B devia estar com dificuldades financeiras. Talvez o Sr. B estivesse gastando muito em casa, ou esteja passando por alguma doença na família – vai saber, se consolou o Sr. A.
Do ponto de vista do Sr. B, porém, o mundo estava diferente:
Ao mudar sua decoração pela primeira vez, ele notou que apareceram mais crianças que o normal;
Quando ele mudou as gôndolas, a clientela ficou mais tempo dentro da loja;
As novas marcas não fizeram sucesso. Algumas pessoas voltaram por elas, mas a maioria ignorou-as;
Na segunda mudança de decoração, as crianças pararam de aparecer.
A cada mudança, o mercado respondia. Nem sempre a resposta era boa – na verdade, nenhuma ainda não tinha valido a pena. Ele não chegou no final de semana com mais dinheiro do que na semana anterior. Porém, ele persistiu.
Um belo dia, algum tempo depois, o Sr. A tomou um susto ao notar que a Loja B tinha, aparentemente, quase tanta gente quanto a dele. No começo ele ignorou isso como uma impressão errada ou uma observação distraída. Porém, a cada semana que passava a Loja B parecia diferente e com um pouco mais de movimento. Em alguns meses a Loja B estava completamente diferente e com outros produtos. Apesar de seu movimento não ter mudado, parecia ao Sr. A que o vizinho agora tinha mais clientes, e clientes que ele não conhecia.
Consternado, mais aborrecido por perder seu posto de líder do que perder vendas, ele puxou conversa com o Sr. B, que contou que seus novos clientes eram amigos dos clientes antigos, que vinham ali por causa da propaganda boca-a-boca atrás de produtos específicos.
O Sr. A pensou e pensou e concluiu que não seria um problema se arriscar. Afinal, ele ainda era a loja do bairro. Começou a experimentar e passou pelo mesmo que o Sr. B: as mudanças alteravam as coisas (público variava, ocupação da loja variava), mas não os resultados (as vendas não mudavam).
Em pouco tempo o Sr. A desistiu de tentar fazer a mesma coisa que o Sr. B e voltou aos seus métodos tradicionais.
Eu não vou finalizar essa história, mas apenas dizer que o antigo equilíbrio estático entre as lojas acabou – a cada dia as coisas eram diferentes e nunca se repetiam. Os Senhores A e B continuam amigos até hoje, e o bairro continua com duas lojas de boa qualidade. (E foi essa paz até o dia em que o Sr. C abriu sua loja do outro lado da rua, mas essa fica para outro dia. ;-) )
O Nome do Jogo É Acumulação
Essa pequena história, totalmente fictícia e completamente baseada no filme Concorrenza Sleale, ilustra pontos importantes nos negócios:
Quem decide qual é a melhor empresa é o consumidor, não o empresário;
Ninguém nunca sabe o resultado de algo até tentar. Você pode suspeitar, mas só vai saber quando fizer;
Imitação não cria vantagem.
No início, o Sr. B não conseguia fazer crescer seu negócio. Ele seguiu todas as boas práticas de mercado, alinhou-se com a empresa de maior NPS do segmento e mantinha um portfólio testado e aprovado pelos consumidores. Apesar de fazer tudo certo, a Loja B não conseguiu superar seu marketshare tradicional.
O Sr. B abandonou sua estratégia tradicional e decidiu adotar inovação como um meio de gerar novos fluxos de receita. A tática inicial era “uma novidade toda semana”. Depois de algum tempo ele descobriu quais novidades geravam maiores retornos e aprendeu como rotineiramente criar esss novidades e assim sustentar um nível maior de faturamento.
Seu segredo era fazer pequenas mudanças, que alteravam a loja de um dia para outro. Enquanto ele descobria como fazer isso, a Loja A seguia repetindo suas estratégias de inovação, como lançar produtos às sextas-feiras e decorar a loja em cada data comemorativa como Natal e Páscoa.
Como resultado, enquanto que a Loja A permaneceu estável no seu segmento, a Loja B atingiu novos públicos, descobriu outros produtos e combinou o processo de inovação com o ambiente local para agradar a um número maior de consumidores, enquanto alterava seu mix de produtos para ficar mais rentável.
O gerente da Loja B assimilou uma realidade: ele não sabe o que vai na cabeça do mercado, mas sabe que testar novas idéias é o mesmo que passear com a loja pelo bairro. Testar novas idéias permite descobrir oportunidades que, bem aproveitadas, tendem a melhorar sua lucratividade.
Já o Sr. A colocou a sua loja em risco, mesmo sem saber disso: as pequenas mudanças em seu entorno distanciam a empresa do mercado. Daí, num belo dia ele vai perceber que não fatura mais tanto quanto antes. Quando ele começar a se mexer já terá perdido o passo e terá que trabalhar dobrado para alcançar o Sr. B (que está na disputa com o Sr. C).
Pequenas mudanças permitem a uma empresa explorar o espaço de oportunidades. Cada pequena vitória, cada pequena melhoria soma-se ao longo do tempo, causando um acúmulo de mudanças que dão o diferencial competitivo.
Claro, existe o lado oposto: um acúmulo de pequenas mudanças erradas vão levar a empresa pouco a pouco para o buraco. Por isso o ciclo PDCA (planeje, execute, verifique e ajuste) é tão importante: ele é um instrumento que permite determinar a qualidade e a direção dessas modificações.
Velocidade é Agilidade
Vamos voltar ao tema da 10+ Deploys Per Day. Eles dizem:
O negócio requer mudanças (slide 13);
Mudanças causam a maior parte das quebras (slide 14);
Diminuindo o risco de mudanças através da mudança de cultura (slide 16).
O argumento deles é que ao invés de fazer grandes mudanças a cada grande intervalo de tempo, mudanças menores a intervalos menores oferecem melhor controle sobre os resultados. Até então, o mais frequente era um grande atrito entre desenvolvimento e operação, com a operação resistindo a mudanças vinda dos desenvolvedores.
Ora, mas que danados esses desenvolvedores! Queriam mudar tudo o tempo todo!
Bom, os desenvolvedores não queriam mudar porque eram tipos irriquietos e bagunceiros, mas porque o negócio precisava mudar, ou poderia ir à falência.
Ao resistir à mudança, a operação não estava protegendo a estabilidade do serviço, mas sim barrando a inovação e impedindo a empresa de mudar e melhorar. Ao acharem como coordenar desenvolvimento e operação, criando o cerne da cultura DevOps, eles resolveram não um problema técnico, e sim um problema de negócio muito sério!
Habilitar uma grande velocidade na mudança teve um efeito intencional, aumentar a estabilidade do serviço sem barrar a mudança, e um efeito não-intencional, que foi diminuir o tempo entre a idéia e a execução. Se antes toda idéia nova levava mês ou meses até ser colocada em produção e ainda representava um risco de perda de faturamento, com DevOps a todo vapor isso caiu para o mínimo possível, deslocando o gargalo de criação de mudanças da operação para o desenvolvimento e o negócio.
Não importava quão rápido negócio e desenvolvimento conseguiam inventar moda, a operação dava conta. Pensou? Programou, implantou, mudou! (E se desse pau, era mais simples e fácil voltar atrás e consertar a situação.)
Já que agilidade é definida como “a capacidade de mudar rapidamente a posição do corpo”, então agilidade tem a ver com velocidade de mudança. DevOps é, portanto, um habilitador de agilidade de negócio pois DevOps permite ao negócio mudar a empresa rapidamente.
Não confunda “capacidade de mudar rapidamente” (agilidade operacional = agilidade de negócio) com Business Agility.
Em resumo, uma empresa atual precisa ter agilidade de negócio (operacional) para poder mudar constantemente, tanto para responder às variações do mercado, quanto para explorar novas idéias. Essa agilidade é, em grande parte, garantida por coisas como DevOps.
Vamos deixar essa questão pendurada e voltar nosso olhar para outro aspecto da vida de uma empresa.
A Empresa Invisível
Uma loja de bairro é uma empresa concreta, tangível: tudo está à vista e pode ser tocado com a mão, desde o estoque no quarto dos fundos, aos consumidores entrando pela porta da frente e a operação dos empregados. Mesmo os fornecedores são visíveis, ainda que esporadicamente. Eventualmente há um computador no balcão, que processa a contabilidade, mas isso é o tudo.
Empresas um pouco maiores, porém, tendem a ser mais informatizadas: os clientes interagem por telefone ou internet, estão registrados em um sistema, que também registra o estoque e os empregados, que não necessariamente estão no mesmo local. A empresa pode oferecer algum tipo de suporte, que é controlado por outro sistema informatizado, que pode acionar remotamente os times técnicos, e assim por diante. Computadores são o que unem e fazem a empresa rodar todo dia, o dia todo.
Isso significa que muitas das novidades não serão lançadas (apenas) como produtos ou serviços mas (também) como mudanças em processos e aplicações. Em 2023, e já há algum tempo, o departamento de informática tem para a empresa contemporânea o mesmo valor que o departamento de engenharia tinha para uma fábrica de 100 anos atrás. Sâo eles que constroem os novos produtos, que implementam a gestão dos processos, as novas linhas de produção e que aumentam as eficiências. Depende-se muito da Informática para realizar as melhorias que causam crescimento e que geram vantagens de negócio.
Caso o Sr. B fosse o dono de uma empresa um pouco maior que sua loja de bairro, ele faria mais experimentações com sistemas e processos do que com decorações e linha de produtos.
Se você desligar os computadores de uma empresa dessas, e de qualquer outra maior, ela simplesmente some. Quem estiver na empresa continuará a ver o que (ainda) existe de material, como estoque, mesas, armários e o próprio prédio. Porém, tudo que a empresa faz – seu funcionamento, relacionamentos com clientes e fornecedores etc. etc. etc. – sumirá, porque estão nos sistemas informatizados. Mesmo com os computadores ligados, se você olhar para longe da da sua tela, o que você verá é uma fração do que a empresa realmente é e faz.
Uma empresas informatizada é invisível e quanto mais informatizada, quanto mais digital for, menos tangível e mais invisível será a empresa.
Os dados que são criados, alterados e movidos de um lado para outro são como feixes de luz que mostram o que está acontecendo na empresa. Por isso eu sempre digo que, ao contrário da analogia feita por Clive Humby em 2006, dados não são o novo petróleo, mas sim luz: são os dados que permitem a alguém ver o que está acontecendo na empresa, a qualquer momento.
Dados não são petróleo, mas luz. Ignorar os dados é o mesmo que fechar os olhos.
Dados e Exploração
Estamos chegando lá! Aguente só mais um pouco!
Pense comigo: se a empresa existe mais como dados que como coisas, então saber o que está acontecendo na e com a empresa depende de consultar os dados. Logo, criar mudanças e até mesmo inovar depende de analisar os dados.
Além disso, para inovar você precisa testar coisas. Para saber que coisas testar e se deram certo, você precisa examinar a empresa, que é o mesmo que examinar os dados.
Portanto, da mesma forma que uma equipe de desenvolvimento e operação é algo imprescindível para uma empresa muito informatizada, uma equipe de dados é imprescindível para entender a empresa, mudar, inovar, experimentar e avaliar os resultado de tudo isso.
Quando alguém vem com uma nova idéia, junto já traz a métrica e o indicador que será necessário para avaliar os resultados dessa idéia. Por exemplo, suponha que o Marketing decide oferecer um e-book em troca dos e-mails dos visitantes, e divulgam esse e-book em uma rede social. A métrica de sucesso é quantidade de novos e-mails capturados com a página/e-book e o indicador pode ser quantidade de novos e-mails capturados por dia.
Antes mesmo de a campanha ser posta na rua o indicador já terá sido definido e já estará sendo acompanhado – afinal, faz parte da inovação. Esse é um caso onde o dado a ser usado no ciclo PDCA já será coletado e analisado de saída ao invés de entrar pela esteira típica de projetos de BI, em que as coisas são construídas durante um tempo relativamente longo (mês ou meses).
Agora, e quando nasce uma pergunta de negócios do nada? Não há escapatória: é preciso ir até a equipe de dados, abrir uma demanda e esperar que ela aconteça.
Até esses dados serem obtidos e analisados, a empresa estará parada, aguardando.
Enquanto isso, quantas entregas de dados seu time está fazendo?
Uma por dia?
Uma Entrega por Dia
Se você está em uma empresa normal, dificilmente você faz uma entrega por dia. Talvez entregue um produto de dados por semana, por time, se tanto. Daí, se você tiver cinco times, talvez entregue em média um por dia a cada semana.
Por que é que em 2023 ainda não temos a tecnologia e gestão e cultura necessária para entregar um produto de dados por dia?
Se você quiser tornar a sua empresa verdadeiramente ágil, capaz de descobrir e explorar oportunidades enquanto elas existem, você precisa tornar o seu projeto de dados tão rápido (=ágil) quanto um projeto DevOps.
Você precisa receber uma demanda de dados de manhã e entregá-la à tarde.
Pergunte-me como. :-)
Conclusão
A Humanidade conhece a alvenaria há milênios e mesmo assim ainda dá trabalho construir uma casa. Temos Engenharia Civil, Arquitetura, Eletricidade, Hidráulica e um monte de outros conhecimentos envolvidos na construção que seja de um simples puxadinho no fundo do terreno. Depois de pronta, uma construção de alvenaria precisa receber manutenção periódica, sem contar a limpeza e eventuais tratamentos químicos (como descupinização).
Construir um prédio em alvenaria não é o mesmo que fazer um bolo de caixinha: requer conhecimento especializado, profissionais capazes e experientes, um bom plano, tempo e dinheiro. E, insisto, temos essa tecnologia há milênios. Milhares de anos. Centenas de milhares de dias.
A Informática com computadores eletrônicos nasceu há coisa de 70 anos e nesse curtíssimo espaço de tempo (todos os bebês que nasceram junto com o primeiro computador eletrônico do mundo ainda podem estar vivos) já mudou e mudou e mudou. Ainda estamos aprendendo a usar essa ferramenta. Já tentamos construir sistemas usando as mesmas técnicas de Alvenaria, e vimos que não funciona. Faz vinte anos que estamos testando outra abordagem e parece estar indo melhor.
Ainda falta muito para descobrir (ou para termos certeza) de qual é a maneira correta de se construir sistemas e desenvolver soluções informatizadas.
Agora, e com dados? Pior ainda!! Se erramos com desenvolvimento por décadas, imagine com dados, que está por aí há metade desse tempo!
Hoje estamos vivendo a Era Ágil, que entrega melhorias e mudanças rapidamente, com menos riscos de interrupções e menos tempo entre idéia e execução.
Os projetos de dados precisam atingir o mesmo patamar. Não existe motivo para um executivo descobrir uma pergunta de negócio de manhã e não ter a resposta à tarde.
Se você almeja sustentabilidade da sua empresa, isto é, que ela dure por gerações, você precisa estar sempre um passo à frente. Para isso, precisa saber o que está acontecendo nela que, graças à informatização, é invisível aos cinco sentidos. Você precisa de dados disponíveis e analisados em horas ao invés de meses ou mesmo semanas. Não dias, horas.
Para você conseguir fazer isso você precisa colocar a Tecnologia em segundo plano e subordiná-la ao Negócio.
Vamos lá: após 30, 40 anos falando-se “Inteligência de Negócio” o termo simplesmente desgastou-se. Muita gente pensa em “BI” como um software: ora referem-se a um banco de dados (tecnicamente o armazém de dados em si) como “o BI”, enquanto que outros associam a sigla a relatórios e um terceiro grupo à painéis e assim por diante. A vida dessas duas palavrinhas é mais complicada que as Infinitas Terras da DC.
Acontece que o que eu acho não faz diferença. O mundo inteiro pensa como pensa e é isso. Eu não posso simplesmente reformatar o mundo – posso oferecer minha contribuição e ver o que vai acontecer, só.
Mesmo assim, ainda precisamos falar sobre o assunto. Ainda precisamos dar um nome à “coisa”.
“A Coisa”
E o que é “a coisa”?
Bom, é uma iniciativa com um objetivo – resolver um problema. Parte dessa coisa é perene, como a infraestrutura (computadores, redes, softwares etc.) Outra parte tem início e fim: surge uma demanda por uma solução de um problema, alguém trabalha e o problema é resolvido – início, meio e fim.
Existem entregáveis: ao final teremos gerado algo que vai resolver o tal problema (um modelo matemático, um algoritmo, uma análise), e talvez produzido outras coisas intermediárias (mais dados no DW, uma nova perna de ETL, uma nova ferramenta na infra).
Como essas são características de projetos, é razoável qualificar “a coisa” como “projeto”. Vem daí o título deste post. ;-)
Projeto do Quê?
Projeto de “Coisa”, oras! :-)
Gracinhas à parte, no nosso contexto estamos falando de projetos que buscam resolver problemas usando os dados da organização. Logo, é razoável dizer que são “projetos de dados”.
A vantagem de um termo tão amplo é que ele abarca praticamente tudo:
Vamos desenhar um painel de vendas – projeto de dados!
Vamos analisar nossos dados e descobrir porque nossas vendas caíram – projeto de dados!
Vamos criar um modelo de forecasting de vendas – projeto de dados!
Vamos criar uma API de integração com Marketing para mala-direta – projeto de dados!
E isso também é uma desvantagem: se uma só palavra descreve tudo, então no fundo ela não descreve realmente nada. As palavras tudo e nada são bons exemplos dessa questão: Projeto de Tudo, Projeto de Nada.
Logo, Projeto de Dados é uma solução aceitável, mas não é muito boa.
Uma Coisa é Uma Coisa, Outra Coisa é Outra Coisa
Um projeto que entrega um painel de dados operacionais cai dentro de uma disciplina chamada Inteligência Operacional – se você nunca ouviu esse termo, leia o post Analítico ou Operacional – aposto que vai achar interessante.
Uma análise de dados em busca de uma resposta a um problema é aplicação do método científico sobre os dados da empresa para extrair uma informação, que é a minha definição de Inteligência de Negócios.
Já um projeto que constrói um modelo matemático para automatizar a tomada de decisão aplica o método científico sobre os dados da empresa para extrair um padrão. Isso é o emprego do processo de Data Mining atrelada à minha definição de Inteligência de Negócios.
E a construção de uma API para fornecer dados eintegrar sistemas? É um projeto de integração de dados ou simplesmente um projeto de software. (Quem conhece ferramentas de EDI sabe que mudar a definição muda a implementação.)
Além disso, projetos de softwares podem ser vistos como ferramentas, o que significa um projeto de software pode ser conduzido para, por exemplo, realizar Data Mining ou construir um painel.
Resumindo, então, temos um tipo genérico de projeto, o Projeto de Dados, que pode ser subdividido em (pelo menos) quatro tipos específicos:
Projeto de Inteligência Operacional;
Projeto de Inteligência de Negócios;
Projeto de Inteligência de Negócios: Data Mining;
Projeto de Integração de Dados
E de brinde ainda temos o também genérico Projeto de Software – que pode ser usado para implementar qualquer um dos quatro tipos acima.
Conclusão
“E daí”, perguntarão vocês, “e eu kiko?”
Ok, vocês me pegaram.
Falar projeto de BI hoje em dia é quase um atestado de petróleo: “Olá, eu sou o Fábiossauro, um velho que ficou no passado, e ainda falo BI”.
Tudo bem – eu já fui chamado de velho com 15 anos. Minha irmã me chamava de velho resmungão quando eu tinha 12 anos. Pelo visto eu nasci velho. É a boa e velha vida. ;-)
Mas quando este velho aqui morrer, as coisas continuarão sendo o que são – elas não dependem de alguém para ser, para existir. As coisas têm sentido em si. Um projeto que resolve um problema aplicando o método cientifico aos dados sempre vai ser um projeto que resolve um problema aplicando o método cientifico aos dados. Podemos escolher usar o nome por extenso ou um apelido – projeto de BI.
Eu escolho o apelido (sou preguiçoso até dizer chega.)
Então, o único motivo pelo qual eu escrevi esse post inteiro, e gastei seu tempo até aqui, foi apenas para dizer que quando eu escrevo “Projeto de BI” eu estou me referindo a um certo tipo de projeto – e não é relatório, nem painel, nem DW, mesmo que envolva essas tecnologias.
Não vejo motivo para abandonar um nome apenas porque a fama dele ficou ruim. Fizemos isso com Data Mining, que virou Data Science, e não adiantou nada – Data Science já está se queimando também. Anotem o que eu estou escrevendo: já, já vem um novo “Data Science” por aí (e isso ignorando AI, ML, Deep Learning etc. etc. etc.)
Engenharia de dados é o nome que hoje se usa para indicar todas as atividades de mover e tratar dados a fim de transformá-los em recursos para os negócios. Existem definições mais precisas que isso, mas para essa basta para o que eu vou falar aqui hoje.
O Mundo Hoje
Conforme o The Phoenix Project a TI é o negócio. Assim, uma das descrições possíveis para “empresa” é “coleção de sistemas informatizados”. São esses sistemas que dão existência às operações da empresa.
De acordo com o Fundamentos de Inteligência de Negócios, toda empresa encara dois tipos de problemas: operacional e estratégico. Problemas operacionais são resolvidos no dia-a-dia e podem ou não necessitar de dados desses sistemas. A Inteligência Operacional é a disciplina que atende esse tipo de problema.
Sistemas informatizados são construídos para operacionalizar um empreendimento;
Os dados desses sistemas são necessários em aplicações diversas;
OI consome dados perto de tempo real, BI longe;
A fim de levar os dados dos sistemas transacionais para esses usos existe a Engenharia de Dados (que é o nome bacana para integração de dados – mais sobre a bacanização desse nome num post futuro.)
Assim Não Dá, Assim Não é Possível
Esse arranjo não é ideal, nem de longe. Ele envolve muito esforço, trabalho, retrabalho, desperdícios, sem contar resultados chochos em muitos casos. Basta lembrar a métrica de fracassos de projetos de dados do Gartner, que volta e meia alguém cita:
Qualquer analista de data mining digno do seu R2 pode ver claramente que a taxa de fracasso está aumentando, e que não é improvável bater em 100%.
Na verdade, se você parar para pensar, pode existir alguma empresa por aí que tem 100% de fracasso, ou seja, que nunca viu um projeto desse tipo dar certo. Nunca. O mesmo se pode dizer de profissionais: é perfeitamente razoável imaginar gente cuja carreira é um fieira de fracassos ininterruptos. Tipo, o cara deve ser um virgem de sucesso – nunca experimentou sucesso vida.
Solução a Curto Prazo
Eu já mostrei neste blog muitas alternativas que elevam taxas de sucesso a 100%. Se você está tendo problemas e quer uma luz, me chame – quem sabe podemos chegar a algum arranjo. ;-)
Passado esse vergonhoso momento de autopromoção (gasolina tá alta pra todo mundo!), a solução a curto prazo é simplesmente parar de modismo e começar a se preocupar com o que de fato interessa: resultado.
Data lakes, data mesh (sobre o que eu vou escrever em breve, depois de engenharia de dados), gestão de times, ferramentas etc. tudo isso nasceu de modismos insensatos (desde o início eu argumento que a idéia de data lake é pouco vantajosa, por exemplo). Isso quando a moda simplesmente não muda o nome das coisas, para ficar mais bacana (ninguém ainda demonstrou que data science não é Data Mining.)
Se você quer achar a saída para o labirinto dos seus projetos, a aplicação da Teoria das Restrições a BI pode te dar uma luz. (Eu adoraria saber se ajudou, ok? :-) )
O Longo Prazo
Agora, porque é que temos que esperar um sistema entrar em produção para só então começar a nos preocupar com os dados para análise? Porque o sistema já não vem com isso como uma funcionalidade default, automática e pronta?
Para entender a idéia eu preciso colocar uma coisa antes: Data Vault. Essa tecnologia resolve todos os problemas de integração, ingestão, consumo etc. e por isso ele é o caminho mais fácil e curto para um projeto de dados de sucesso. Graças a Data Vault, aliás, hoje é possível manter projetos de dados 100% automatizados, com uma só pessoa trabalhando.
A partir das premissas de Data Vault é possível desenvolver um Data Warehouse como um componente do sistema transacional, embutido no código, de saída. Graças aos paradigmas de Data Vault podemos construir uma extensão a um ORM, como o Hibernate, para gerar um DW ao compilar o código. Daí, a usando os padrões de refatoramento de bancos de dados do Martin Fowler e ferramentas como Liquibase, podemos automatizar evoluções de base em um pipeline CD/CI.
08/03/2022 Dan Linstedt: I predict a future where Operational Systems make the jump to Snowflake technology – where Snowflake builds a platform to enable operational application support for data scalability world-wide. Would be interesting to see for sure.
Ele implica o cenário em que um sistema transacional contrata uma solução de DW automatizada (que é uma das formas de operação do Snowflake). A ideia faz tanto sentido (e ele é tão próximo da Snowflake) que algo nesta linha provavelmente vai aparecer.
Eu tentei imaginar como isso seria e de repente a coisa toda cristalizou-se: dá para fazer um DW como código e embutir no próprio sistema transacional! Inclusive, isso daria incentivo à implementação de mecanismos de CDC direto no sistema!
E a coisa não pára nisso. Uma empresa raramente usa um só sistema e o normal é existir vários. De novo, graças aos paradigmas de um Data Vault, é muito simples integrar vários DWs-As-Code em um DW federado maior, sem perder escalabilidade e sem aumentar a complexidade. Dá para virar um padrão de indústria, até.
DW-As-Code: DWAC
CONSEGUI, INVENTEI UMA NOVA BUZZWORD, HAHAHAHA! VEM NI MIM, GARTNER!
Specifically, as incumbents focus on improving their products and services for their most demanding (and usually most profitable) customers, they exceed the needs of some segments and ignore the needs of others. Entrants that prove disruptive begin by successfully targeting those overlooked segments, gaining a foothold by delivering more-suitable functionality—frequently at a lower price. Incumbents, chasing higher profitability in more-demanding segments, tend not to respond vigorously. Entrants then move upmarket, delivering the performance that incumbents’ mainstream customers require, while preserving the advantages that drove their early success. When mainstream customers start adopting the entrants’ offerings in volume, disruption has occurred.
Em tradução livre e abreviada, “um desafiante, menor e com menos recursos que os maiores jogadores, escolhe focar em clientes de setores mal-servidos, onde conseguem firmar um pé ao melhorar a situação desses clientes; daí, os novatos se movem ‘mercado acima’, abocanhando setores cada vez mais valiosos, até que finalmente os clientes do mercado principal também adotam esses produtos; neste ponto dizemos que ocorreu a disrupção”.
A situação de projetos de dados hoje não é sequer uma coisa marginal – está ruim e confuso para todo mundo. Mesmo uma melhoria pequena já dá vantagens. Adicionar um DW como código a um sistema transacional é resolver um problema que nem sequer existe claramente. Fazer isso em um sistema que nem está no mercado, que está sendo desenvolvido, é ainda mais impensável.
Hoje ninguém seguirá essa direção, com certeza. Mas talvez um dia DWs sejam partes integrantes de um sistema informatizado, e o ecossistema de dados evolua para outro cenário.
E o que tem isso tudo com o nome do post, O Início da Engenharia de Dados?
Como eu disse no começo, EdD hoje é grosso modo a disciplina que monta e configura softwares e ambientes para mover dados de um lado para outro (fornecimento para análise também é mover dados de um lado para outro.) Com todo respeito, o conceito de Engenharia está para essas atividades assim como o conceito de Culinária está para bolo de caixinha. Na minha humilde e totalmente irrelevante opinião (mas minha, none the less), isso não é engenharia de dados. Para dar um exemplo, modelagem, que é uma coisa importantíssima, é um assunto marginal em EdD.
Para tentar deixar mais claro meu ponto de vista, considere o que chamamos de Engenharia de Computação, que é a carreira dentro da qual se aprende a desenvolver e programar sistemas, e compare com a Engenharia de Dados, que praticamente uma coletânea de softwares e processos.
Ao começar a tratar DW como parte de um sistema informatizado, e não como um apêndice, crescendo à parte e perpetuamente encrencado, eu entendo que estamos mudando o paradigma do campo “ETL com Python” ou talvez “Integração de Dados com Kafka”.
A partir deste ponto eu entendo que será o início de uma disciplina de Engenharia de Dados tão séria e profunda quando Engenharia de Computação.
Hoje eu vi um anúncio de vaga de emprego com estas responsabilidades:
Esse é um bom exemplo de perfil profissional da Velha Economia:
Confuso: já começa pedindo uma coisa incomum, que é a tal gestão de acesso de ferramentas. Não seria gestão de acesso às ferramentas? Ou é o controle de acesso de um conjunto de ferramentas (qual?) à bancos de dados? E o que é gestão neste caso, seria controlar as credenciais de cada ferramenta a uma outra coisa?
Barulhento: Data Wrangling é um outro nome para ETL, com a “diferença” que DW (péra, esse acrônimo já tem uso…) deixa o dado ainda cru mas reorganizado para outra aplicação. Afinal, depois de sofrer alguma transformação, ainda é dado crú?!
Quem faz tudo, não faz nada: o perfil vai fazer – nesta ordem de relevância – relatórios, levantar requisitos, especificar (o quê??), modelar (o quê???), construir painéis e (finalmente!!) ETL, mas não é Data Wrangling, que é ETL com dado crú… Q????
Fazer três coisas iguais usando nomes diferentes: OLAP (que usa MDX se for da MS), MDX (para OLAP da MS) e DAX (que é uma espécie de “linguagem” para painéis – que são análise multidimensionais em essência, que é a definição de OLAP que usa MDX…)
Especialista do assunto: além de toda essa confusão de tecnologias, buzzwords e conceitos, o feliz escolhido vai ter que fazer análise de indicadores de produtos. Em outras palavras, ele precisa conhecer o produto, conhecer o mercado, conhecer as tecnologias e analisar isso (para quê? para pendurar na parede?) E tem a tal da análise de mídia digital. Dá para intuir o que isso deve ser pela associação com análise de indicadores, mas mesmo assim, putz;
Faixa-bônus: “estruturar a coleta dados e estruturação das métricas de acompanhamento de mídia digital e CRM em todas as fases da cadeia de mídia”. Sem contar o “estruturar a estruturação”, isso não é um resumo de tudo que está escrito antes?
Vocês dirão: mas, Fábio, é só uma empresa pequena; provavelmente esse aí vai ser o “eupartamento” de BI ou a “euquipe” de dados, onde um cara só faz tudo e ainda passa o café!
Pois então, não. É uma vaga oferecida pela holding dona de uma multinacional brasileira (nativa!), com milhares de lojas pelo mundo. Então, não: é uma mega-empresa!
Como alguém pede um perfil desses? Só posso imaginar que seja um ambiente confuso, algo caótico ou que não possui valor dentro da empresa e por isso não recebe atenção e cuidado.
Vaga de Nova EcoNOmia
Pelo restante da descrição da vaga (que eu não coloquei aqui), eles procuram um analista de produto, focado no negócio. Se eu fosse pedir esse profissional, eu colocaria a lista de requisitos assim:
Perfil analítico: possuir formação em Estatística, como graduação principal, parte de outra formação (como Física ou Engenharia) ou curso livre;
Carreira desenvolvida em gestão de produto;
Usuário de ferramentas de análises de dados, como OLAP, relatórios e painéis;
Conhecimento de tecnologias e processos de construção de produtos de dados, incluindo mas não limitado à ETL, clusters Hadoop (“BigData”) Data Warehousing, Modelagem Dimensional e 6a. forma normal (Data Vault);
Experiência em processos leans e ágeis.
Esse cara está preparado para “monitorar resultados de campanhas, trabalhar dados de mídia e negócio, criar e experimentar modelos matemáticos contra o mercado para entender e monitorar a jornada do cliente, e disto extrair insights para gerar valor para o negócio”.
Repare que a lista anterior era praticamente um resumo de buzzwords soltas, desconexas: esse o mindset da empresa linear, tradicional. Empresas inovadoras, focadas no negócio e em seus valores, com clareza de propósitos, constroem descrições mais parecidas com a segunda lista.
Conclusão
A descrição da vaga inteira dá uma boa idéia de que profissional está sendo buscado. Infelizmente, a comunicação disso ainda é muito deficiente quando se desce ao nível dos traços de conhecimento e personalidade almejados. Parece aquela história, “eu sei o que é, só não sei como falar”.
Isso é ruim? Em parte sim, em parte é indiferente. Duvido que essa descrição esquisita afaste quem quer trabalhar naquela empresa. E, se o processo deles for minimamente razoável, vão encontrar quem estão buscando. Então, é só uma coisa chata, mesmo.
Mas hoje em dia ainda existe uma grande distância entre trabalhar em Inteligência de Negócios e entender o que realmente é Inteligência de Negócios.
No post Analítico ou Operacional eu proponho a existência de um campo análogo à Inteligência de Negócio chamado Inteligência Operacional. À época eu mal consegui confirmar meu ponto-de-vista, pois parece que poucos haviam realizado essa observação. Eu aprofundei aquela abordagem e, eventualmente, criei uma apresentação chamada “Cultura de Dados”, que eu transmiti ao vivo em 1/4/2020.
Hoje, assistindo um vídeo para começar a aprender sobre o Kibana, qual não foi minha surpresa ao ver que reconhecido o campo de OI!
Pode parecer besteira, mas o simples fato de relacionarem uma ferramenta à uma disciplina tem um grande efeito. Para começar, legitima o conceito. Em segundo lugar, ao oferecer um caso concreto ele ajuda a contratastar com disciplinas similares, como BI. Por último, ele dá aquela centelha na cabeça de todos, que começam a se questionar “o que mais é OI?” e “que outros casos de OI existem?”.
Em última instância, o fortalecimento do conceito de OI ajuda o debate sobre o conceito de BI, permitindo separar as duas coisas. Essa separação, por fim, permite melhorar o resultados dos projetos de ambos os tipos, já que misturar coisas diferentes piora os resultados.
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!!!
Em 2000 eu pude participar de uma conferência do SAS – como empregado, nos bastidores – e ver Bill Inmon palestrar. Por essas coisas de eventos e ranks, eu não tive a oportunidade de conhecê-lo e, no fundo, não teria sido nada tão extraordinário para mim. Lembro-me de vê-lo falando e do sentimento de reverência por estar assistindo o pai do assunto, mas nada mais que isso.
Acho que deve ser o que sentimos quando vemos um jornalista da TV na rua: ah, puxa, ele é da TV, e acaba nisso. (Muito diferente, por exemplo, de assistir o show do Robert Plant e Jimmy Page no Hollywood Rock – muuuuito diferente.)
Hoje, praticamente 20 anos depois, o destino me leva para o lado do pai do DW mais uma vez. Mas agora, na mesma página:
Literalmente na mesma página, no WWDVC 2021
He, he. Agora eu me sinto no show do Led Zeppelin. :-D No palco do show, para ser exato.
Então é isso: em 2021 eu vou apresentar uma palestra ao vivo (um case) e outra pré-gravada (Data Culture) no palco do World Wide Data Vault Consortium 2021.
Este ano ele será totalmente virtual – por isso eu consegui me inscrever como palestrante. Mas isso significa que ninguém precisa mais pagar um vôo até Vermont, e hotel, para assistir a conferência!! Interessado? Acesse a página do evento e inscreva-se!
Apesar de estar muito satisfeito em meu emprego, eu sempre dou uma olhada no que o Mercado de BI procura. Afinal, nunca é demais termos um ou dois Planos B na manga.
Algumas vagas chamam a atenção, ou porque pedem um perfil inédito até então, ou porque combinam nomes de perfis distintos e criam uma nova espécie.
Hoje eu vou examinar uma oferta de vaga que procura por um Desenvolvedor BI.
Pseudo-screenshot do LinkedIn (Achievement! Poliglota – três línguas em frase curta.)
Como eu sou adepto da idea de BI como conceito e não como produto, esse título me chamou a atenção. Eu entendo que Business Intelligence não é uma linguagem de programação, nem um tipo de framework que possa ser usado em um desenvolvimento de sistemas e muito menos um sistema pronto, algo que requeira um desenvolvedor.
A descrição fala “desenvolvemos o BI do futuro”. Legal! Ainda há muito a ser feito, parece instigante.
Depois vem a área de atuação: cientista de dados. Hmm… Cientista de dados é o termo hype para “analista de Data Mining“, que é a pessoa que resolve problemas de negócio construindo modelos matemáticos para automação de tomada de decisão. Não chega a ser um papel novo, existindo com o nome antigo já há uns 30 anos, mas é uma área onde se pode fazer muito pelo conceito de BI. Ainda mais se pensarmos que a empresa contratante está mirando em NLP.
A descrição, entretando, vira-se para o lado oposto: a função do analista de Data Mining é “desenvolver relatórios customizados para os clientes”. Ainda que um modelo matemático possa ser a base para um relatório, não constuma ser o emprego mais valioso de tais modelos. Indicadas como ferramentas para construir tais relatórios – presume-se – está R e Python. Ainda que possam realizar um trabalho muito bom, não são plataformas cuja missão é gerar relatórios. Para isso existem softwares muito mais aptos, que reduzem a carga de trabalho e entregam resultados tão bons quanto. É uma escolha bem curiosa.
Uma tarefa comum a perfis de BI é lidar com o público, o que está na vaga. Algo menos alinhado é monitorar e gerencia a saúde (qual?) dos clientes.
Seres humanos exibem a tendência de criar foco e se concentrar na tarefa à mão. Pular entre várias funções, ainda mais quando exigem mindsets diferentes, pode gerar perda de rendimento. O pensar e agir como desenvolvedor é razoalvelmente diferente do pensar e agir de um como gerente, ainda mais levando em conta a gama de ações de cada papel.
Recomendo este artigo aborda para conhecer por alto a questão do context switching.
É uma combinação impossível? Não, acredito que não. É uma boa combinação? Na minha percepção, não. Criou-se a idéia do profissional com perfil-T, que consegue exercer tanto uma atividade especialista, quanto generalista, algo muito requisitado em times ágeis e auto-organizados. Mas a vaga não parece mirar nesse tipo de profissional. O pouco que se descreve desse papel de gerente dá a entender que a descrição do trabalho inclui atuar como gerente de contas, em que o relacionamento com o cliente é a atividade central. Nesse caso, a distância entre os dois papéis (analista e gerente) é ainda maior e a tensão entre as duas atuações é ainda mais acentuada.
Estou Contratanto: Desenvolvedor & Gestor
Eu não conheço a empresa, nem seus desafios. Como eles almejam criar o futuro da Inteligência de Negócios, não posso sequer querer saber como é a vida lá, já que eu sou do passado. Sabendo que papéis que lidam com pessoas tendem a requerer perfis diferentes dos profissionais que lidam com desenvolvimento (sendo realizado em R ou Python, como desenvolvimento de software tradicional), talvez possamos descrever essa vaga de forma a buscar um profissional mais apropriado – começando por separá-la em duas.
Vaga 1: Cientista de Dados
Descrição: realizar análise de problemas de negócio e construir modelos matemáticos a partir de dados para automatizar a tomada de decisão. Necessário habilidade analítica em R ou Python.
Vaga 2: Gerente de Conta
Descrição: empregar ferramental analítico para examinar a saúde (financeira? mercadológica?) dos clientes e propor ações para reduzir riscos e mitigar problemas. Requer raciocínio lógico, habilidade de comunicação escrita, apresentação de resultados e acompanhamento de clientes. Funcionará em colaboração estreita com o Cientista de Dados, levando problemas do cliente e trazendo as soluções para estes.
Essa redação procura reaproveitar o texto original. Porém, talvez a Vaga 1 não seja para um data scientist. Me parece que esta descrição a seguir tem mais relação com o contexto “desenvolver soluções de BI usando NLP e Data Mining”:
Vaga 1′: Engenheiro de Computação
Descrição: desenvolver sistemas de Processamento de Linguagem Natural para interpretar demandas de negócio e traduzi-las em análises de dados e em processos automáticos ou semi-automáticos de Data Mining. Requisitos: dominar linguagens C++, Rust e JavaScript; familiariedade com APIs; conhecer e empregar os toolkits de IA em nuvem, como Google IA , AWS Machine Learning, TensorFlow, DataRobot e outros.
Algo conspicuamente ausente é o já habitual cabedal de proficiências contemporâneas, como algum tipo de habilidade Ágil (metodologias, ferramentas etc.), CI/CD, infra-como-código e outros quejandos. Como é uma vaga de BI e sabemos que BI é um bicho resistente à essas modernidades, talvez não seja uma ausência notável, no final.
Não Mande Seu Currículo!
… por que eu não estou contratando ;-) .
Eu comecei o blog porque eu ouvia muita opinião e precisava expressar a minha (mas ninguém queria me ouvir kkkk). Então, tudo aqui é um exercício de auto-expressão, de emitir uma opinião particular, sem intencionar um fim ou falar para alguém.
Eu fiz essa análise para registrar minha posição sobre uma oportunidade de trabalho em um mercado que, me parece, está cada vez mais confuso e bagunçado, mas longe de mim querer dizer o que é certo ou errado.
Eu tentei disfarça a vaga, mas se você – o dono desse anúncio – estiver aborrecido com estas mal-traçadas, por favor, me chame no LinkedIn e eu retirarei o post do ar no mesmo instante. Fechado? ;-)
Geek BI 