Fonte: GEEK BI
Quem acompanha o blog sabe que eu tenho uma divergência conceitual com partes do mercado de ferramentas de BI. Em geral eu questiono a idéia de analisar dados operacionais. Mais especificamente, eu venho cutucando o conceito de Data Discovery.
Acredito que finalmente entendi a confusão e vou dividir com vocês a minha opinião. Como sempre, vale o disclaimer: é a minha opinião, logo você não é obrigado a gostar dela ou concordar. Terei prazer em ouvir críticas ou outras opiniões, mas no final – como diz o Homer Simpson – a opinião é minha e faço com ela o que quiser, certo?
Fundamentação
Primeiro vamos estabelecer o terreno no qual eu colocarei meu argumento. Esse “terreno” é o uso que BI tem para uma empresa, uma organização. Como eu sempre digo, a definição de BI varia selvagemente e que o único consenso é que não há consenso sobre o que é BI. Porém, todas as técnicas e ferramentas da indústria de BI compartilham mais ou menos o mesmo discurso, a mesma promessa de valor: analisar os dados da organização para melhorar seu desempenho. Esse, então, é o chão do meu argumento:
BI trata de gerar valor a partir dos dados de uma organização.
Se concordarmos com isso – e você não é obrigado a concordar, lembre-se – então a próxima questão é “como isso acontece?” Olhemos para o mundo real: em que situações ter conhecimento dos dados gera valor para a empresa?
Empresas como uma Net ou uma Americanas.com vendem algo. A Net vende serviços e aAmericanas.com é uma loja de comércio eletrônico. Algo em comum a ambas é o processo de reclamações: sempre que um dos clientes dessas empresas tem um problema, esse cliente aciona a empresa e registra uma demanda. Essa demanda é tratada, indo e voltando dentro da empresa, até que ser resolvida.
Uma forma de os dados nestas organizações serem usados para gerar valor é responder perguntas da gerência desse departamento. Por exemplo:
- Quantas demandas temos em aberto, agora?
- Que porcentagem dessas são urgentes?
- Qual é o tempo médio de resolução de demandas?
- Quais são as dez (ou vinte ou quantas você quiser) demandas mais antigas?
E assim por diante.
Outra maneira gerar valor para a empresa com esses dados é responder a estas perguntas:
- O número de demandas em aberto está aumentando ao longo do tempo?
- Como está variando a porcentagem de demandas urgentes em relação ao total, ao longo do tempo?
- A “idade” das nossas demandas tem aumentado ou diminuído?
Uma Coisa é Uma Coisa, Outra Coisa é Outra Coisa!
O primeiro grupo de perguntas gera valor para a empresa porque está dando pistas sobre que ações tomar a seguir:
- Quantas demandas temos em aberto, agora? Se sabemos qual é nossa capacidade de atendimento, sabemos imediatamente se estamos enrascados;
- Que porcentagem dessas são urgentes? Caso haja um número excessivo de demandas urgentes, as urgentes delongam o atendimento das normais, que viram atrasadas e depois urgentes, gerando um círculo vicioso até o caos total;
- Qual é o tempo médio de resolução de demandas? Se estiver fora da meta, precisamos nos mexer para voltar a ela;
- Quais são as dez (ou vinte ou quantas você quiser) demandas mais antigas? Traduzindo: quem precisamos resolver antes?
As perguntas deste tipo estão voltadas para o aqui e agora. Elas são instrumentos para ações operacionais, ações que cuidam do dia-a-dia da empresa. Mesmo assim, essas perguntas dependem de um conjunto maior de conhecimentos para poder ajudar de verdade. Quer um exemplo?
- Quantas demandas temos em aberto, agora? Inútil saber isso se não sabemos qual é nossa capacidade;
- Que porcentagem dessas são urgentes? Em que ponto temos demandas urgentes em excesso?
- Qual é o tempo médio de resolução de demandas? Qual é a meta?
- Quais são as dez (ou vinte ou quantas você quiser) demandas mais antigas? Precisamos resolver antes quem está aberto há mais tempo ou quem tem um valor maior envolvido? Ou combinação desses dois parâmetros e mais alguns outros?
Enfim, tomar decisões operacionais a partir dos dados do momento dependem de conhecimento sobre o negócio. Os dados, por si só, não trazem esse conhecimento.
Já o segundo grupo está olhando o negócio ao longo do tempo, para ajudar a decidir que rumo tomar. São perguntas que refletem um anseio de melhorar a gestão, de evitar riscos e ter mais segurança nas ações. Cada pergunta daquelas nasceu de uma vontade de evitar problemas e melhorar o rendimento (fazer mais gastando menos) da empresa. Veja:
- O número de demandas em aberto está aumentando ao longo do tempo? Traduzindo: se tudo está bem e estamos atendendo bem ao nosso cliente, então o número de demandas abertas deve estar caindo de um período (semana, mês etc.) para outro. Está? Se a quantidade de demandas está aumentando ao longo do tempo, o que está causando esse aumento?
- Como está variando a porcentagem de demandas urgentes em relação ao total, ao longo do tempo? Tradução: nossa equipe, processos e ferramentas estão adequados para nossa realidade? Em que ponto perderemos o controle?
- O gerente perguntou “A ‘idade’ das nossas demandas tem aumentado ou diminuído?” mas ele queria ter perguntado “Nossos clientes nos vêem como eficazes?”, ou talvez “Vamos perder algum cliente por atrito com o atendimento”?
Acredito que, a esta altura, meu argumento se auto-evidenciou:
Existem duas demandas distintas por análises de dados dentro uma organização: operacional e estratégico.
E Daí?
O berro que eu acredito ter ouvido de vocês é “descobriu a América, tontão! Todo mundo sabe disso!”
É mesmo?
Se todo mundo sabe que existem duas demandas distintas por dados, então porque é que ambas são chamadas pelo mesmo nome?
Toda e qualquer análise de dados, de qualquer tipo, em qualquer situação, tem respondindo por apenas um nome nestes últimos 20, 30 anos: Inteligência de Negócios.
Bom, se João é Pedro, então tanto faz chamá-lo de Pedro ou João. Agora, se João é diferente de Pedro, então João não é Pedro e por isso não podemos chamar João e Pedro pelo mesmo nome.
Deixe-me traduzir: eu não posso usar o mesmo nome para duas coisas distintas, ou não seriam distintas!
Admito que isso acontece em muitas situações na nossa vida, mas vocês hão de convir que, quando isso acontece, em geral sabemos que temos mais de um significado em jogo, e também sabemos a qual destes significados estamos nos referindo. Tem um exemplo no seu bolso, ou em cima da sua mesa: olhe ali, seu celular.
Não sacou?
Oras, celular é o que o seu avô usava. O nome correto destes novos aparelhos de telefonia móvel é smartphone! Chamamos tudo de celular porque é mais fácil, todo mundo entende e, bom, quem ainda usa um celular das antigas? E que diferença faria usar o nome certo? Os antigos aparelhos estão sumindo…
Eu estudei piano por um tempo e, apesar de ter um em casa, meu acabou me presenteando com um teclado da Casio. Chamei meus amigos (músicos, boa parte deles) para mostrar a novidade e tasquei: “olha só, o orgão que meu pai me trouxe!” Meu amigos caíram na gargalhada e eu, goiaba que só, não entendi nada. “Cara”, um deles falou, “orgão é seu *****, isso aí é um teclado eletrônico!!!”
Voltando à vaca fria, ao considerar que duas coisas distintas são a mesma, quando não são, estamos abrindo a porta para uma confusão danada. Essa confusão tem causado consequências problemáticas, que nem sempre são claras.
E, olha só!, produtos que se auto-categorizam como “de Data Discovery” são voltados precisamente para o exame de dados operacionais. Se não, vejamos:
- Prometem acessar o dado diretamente nos sistemas de origem;
- Prometem dispensar um DW, descartando com isso o exame de dados ao longo do tempo;
- Oferecem uma vasta gama de opções de visualização de dados;
- Focam em “velocidade de análise”.
Conclusão
Toda empresa depende de uma série de projetos de TI (e Negócios) para se manter viva. Projetos como ERP, BPMS e BI são o feijão-com-arroz para qualquer organização no século XXI, e o sucesso da execução destes e de vários outros projetos tem um impacto direto na saúde da organização.
Basta olharmos para a propaganda de empresas do espaço de Data Discovery para notar que seus produtos são voltados a atender necessidades de acesso e manuseio de dados operacionais. Percebemos que são projetos de TI distintos ao compararmos alguns aspectos entre produtos deData Discovery e de BI:
| Aspecto | Estratégico | Operacional |
|---|---|---|
| Ciclo de vida dos dados | Histórico | Vivos, quase tempo-real |
| Origem dos dados | Armazém de Dados | Sistema de origem |
| Velocidade de manuseio dos dados | Não é crítica | Crítica |
| Funcionalidade mais importante | Data Mining | Formas de visualizar os dados |
É perigoso, se não cabalmente daninho para uma empresa, adotar como solução de um problema o produto adequado a outro. Você teria coragem de assinar a compra de um ERP para montar uma solução de workflow? Não, né? E olhe que há uma semelhança razoável entre ERP e BPMS para nos tentar a usar só o ERP para as duas coisas!
Solucionar as necessidades de dados operacionais com um projeto de BI é contraproducente:
- Sai mais caro, já que embute pelo menos um projeto extra, o de DW
- Frustra os usuários:
- Se vêem forçados a usar ferramentas inadequadas à sua necessidade;
- São obrigado a viver em um ciclo de projeto mais longo do que o necessário, pois embute a revisão do DW quando uma simples mudança na camada de apresentação já teria sido suficiente.
Da mesma fora é danoso à empresa adotar ferramentas de DD para necessidades de BI: descartar o histórico dos dados compromete as análises de causa e efeito, anulando a capacidade de compreensão e planejamento.
É uma sutileza, mas o usuário de BI também se frustra com ferramentas para manuseio de dados operacionais, pois as ferramentas voltadas para análises operacionais não são o mesmo que ferramentas OLAP.
Se temos duas necessidades claramente distintas, com público-alvo, premissas e técnicas diferentes uma da outra, e uma delas chama-se BI, a outra não pode ser BI. Por falta de um nome melhor, chamerei o não-BI de Inteligência Operacional, OI.
Não gostei muito de OI, mas a alternativa me soa ainda pior: Não é BI!
Ter claro em mente que existem demandas distintas é fundamental para atender ambas corretamente. Mesmo que compartilhem algo, como máquinas e alguns tipos de software, a simples diferença de público-alvo já justifica um atendimento em separado – no mínimo com relação aos dados que cada projeto usa. O preço de atender cada projeto com a solução errada vai de um mero desconforto entre os usuários a consequências severas para a organização.
0 comentários:
Postar um comentário