Sobre Business Intelligence e Dados

Muitas empresas vislumbram em um projeto de Business Intelligence (BI) a resolução de todos os seus males e dificuldades com relação à exploração e análise de dados, sem ao menos terem ideia do que realmente precisam fazer para que um projeto desses seja efetivo e que lhes entregue valor.

Nos últimos anos as empresas têm sido bombardeadas por uma enxurrada de produtos de BI "mágicos", promovidos por fornecedores com objetivos particulares: aumentar as próprias vendas e faturar com o hype. O mercado de ferramentas de BI vêm sendo soterrado com soluções de BI, com promessas - ilusórias - de resolver os problemas com não mais que meia-dúzia de clicks, no padrão NEXT-NEXT-FINISH.

Um projeto de BI de sucesso depende de muitos aspectos e alguns destes são desconhecidos para quem não pertence à área de Inteligência de Negócios. Muitos, aliás, acreditam que BI e TI são a mesma coisa e que, portanto, a mera adoção de uma ferramenta é o bastante. Não é. Projetos de BI são sofisticados, com etapas que precisam ser realizadas antes de se poder contar com os dados para resolver problemas através de uma solução de BI corporativo, funcional e que entregue valor. Etapas como a de identificação dos problemas e das fontes de informação são negligenciadas e a consequência desta falta de cuidado é muitas vezes refletida na má qualidade da solução corporativa.

Neste artigo passaremos uma visão geral das necessidades mais importantes que identificamos em projetos de BI com relação a coleta de dados em sistemas empresariais, sejam eles ERPs, bancos de dados relacionais, arquivos TXT, planilhas eletrônicas, etc. E procuramos detalhar estas necessidades para auxiliar na tomada de decisão auxiliando o papel de um arquiteto de solução em suas tarefas e por onde e como começar.

As fontes de informação

Não mais importantes que as análises de dados que resolvem problemas, mas a mais estratégica para o sucesso de qualquer iniciativa de BI estão as fontes de informação. Quando se pretende fazer uso da informação para gerar valor é necessário identificar quais as fontes de informação serão utilizadas para responder às perguntas de negócio que o ambiente de BI usará. O mapeamento destas fontes de informação têm papel fundamental na estratégia de um projeto de BI.

CRMs, ERPs, planilhas, arquivos texto, banco de dados são algumas das fontes de informação normalmente conhecidas para muitas pessoas relacionadas com a geração de insights que levam à tomada de decisões com capacidade de gerar impacto, normalmente financeiro, para uma empresa.

Quando nos referimos a realizar o mapeamento destas fontes de informação, não nos referimos apenas a identificar os tipos de tecnologias onde estas informações estão armazenadas, mas também a entender a o que diz respeito estas informações.

Imagine um cenário onde seja necessário conhecer todos os documentos de transporte (DTs) em uma operação logística. Esses documentos é que são utilizados para movimentar mercadorias de uma empresa - dentro ou fora. Nestes documentos constam informações como o número da nota fiscal, o número de remessa, quantidade de volumes, o destinatário, o endereço do destinatário entre outras coisas. Este insumo permite responder perguntas de negócio de um planejador como, por exemplo, "como reduzir o custo do frete?" ou "como aumentar a margem de segurança no tempo de entrega?", ou seja, a partir desse insumo um planejador pode consolidar informações e analisar os dados para descobrir arranjos que possam auxiliar sua área a definir uma melhor estrutura ou melhores processos, para aumentar a produtividade e, na maioria das vezes, aumentar o rendimento financeiro da empresa. Por exemplo, um controle do Picking - coleta no armazém dos produtos constantes na ordem de encomenda (DTs) dos clientes - bem realizado pode auxiliar um planejador de um armazém ou de estoque a identificar lacunas existentes no processo com relação a, por exemplo, a qualidade da separação e do carregamento de mercadorias para entrega aos clientes.

As fontes de informação necessariamente atenderão a uma unidade de negócio ou área de uma empresa e seu mapeamento precisa ser realizado não apenas por pessoal de tecnologia da informação, mas também por conhecedores do negócio e que fazem o dia a dia da empresa acontecer.

Este mapeamento de fontes de informação pode ser facilmente coordenado em uma iniciativa de inceptions com uma abordagem fluída e já conhecida e que é capaz de deixar os participantes se sentindo inseridos no contexto, apresentando soluções e situações similares com o objetivo de desenhar algo que seja de consenso de todos, desta forma mostrando a eles que fazem parte do processo.

Ao final deste processo, com todas as fontes de informação identificadas e o valor de cada informação já conhecido, sabendo onde se aplica cada um, um mapeamento como o descrito a seguir poderá ser construído, seguindo o estilo de um dicionário de dados.

O processo de extração de dados

Extrair dados das fontes de informação quando estamos falando de Business Intelligence diz respeito a capturar as informações previamente mapeadas na fase anterior por meio de um processo chamado ETL e jogá-los em um banco de destino para análise posterior. Este banco de destino é escolhido em função da necessidade analítica ou de historiamento (acumulação de histórico) e pode ser um SGDB como um dos das origens de dados, um ambiente NoSQL como Hadoop ou MongoDB, ou até mesmo um banco de dados colunar, tais como Vertica ou Teradata. A escolha do local de armazenamento depende de alguns fatores e tem relação direta com as tecnologias utilizadas pela empresa, com o volume de dados analisado (não necessariamente o volume coletado) e com as análises que se pretende fazer.

Normalmente em grandes empresas, onde naturalmente a seleção de tecnologias passa por longos processos, a primeira escolha é a utilização do SGDB homologado corporativamente, já que esse caminho é o mais fácil e atende a uma boa gama de necessidades. Em empresas menores, onde há maior liberdade para escolha de tecnologias, é natural que a primeira escolha, devido às experiências vividas com baixa performance com SGDBs relacionais e dada a sua natureza de não ser suficiente para a finalidade de um BI performático, tende-se a utilizar algum armazenamento com tecnologias colunares, como Vertica, Sybase IQ ou Teradata. Agora, quando o volume de dados a ser analisado cai na casa das dezenas de bilhões de linhas, e o instrumento de análise é Data Mining, as melhores opções são bancos NoSQL altamente escaláveis, como Hadoop.

Uma vez que a tecnologia de armazenamento para as primeiras extrações foi definido, podemos então nos ocupar com a seleção da ferramenta para essas extrações. Estamos falando dos ETLs, como mostrado no artigo anterior, onde demos uma visão geral de como utilizar o Pentaho PDI para extrair dados de um banco de dados de origem e copiar estes dados em um banco de dados de destino. Daniel Cesário, um dos autores, ilustra alguns casos de extração e coleta de dados que envolvem inclusive APIs Rest.

A extração dos dados é uma das fases mais importantes de um projeto de BI. Um ETL basicamente deve oferecer:

• Alta performance na captura dos dados;
• Estabilidade;
• Capacidade de expansão;
• Capacidade de processar altos volumes de dados (na casa das centenas de milhões de registros);
• Processos de fácil manutenção;
• Possuir documentação eficiente para todos os processos criados;
• Abranger uma lista de capacidades razoáveis, para diminuir ou eliminar a necessidade de se criar processos ordinários do zero. Por exemplo, ser capaz de ler e/ou escrever diversas fontes de informação, incluindo ERPs, bancos de dados relacionais (RDBMS), bancos colunares, NoSQL (como estruturas de Big Data), integração com APIs, integração com serviços em nuvem como AWS, Google Cloud, Azure etc.

Armazém de Dados

Uma vez que as fontes de informação e a ferramenta de ETL a ser utilizada foram definidas, cabe agora desenhar a forma como, ao menos inicialmente, estas informações serão armazenadas, para só então alimentar as ferramentas de BI corporativo, ou subprojetos, como de Data Mining. A literatura nesta área, normalmente aborda o uso de uma área temporária inicial (stage area) na qual os dados são previamente armazenados antes de ser tratados e enviados para o Data Warehouse definitivo.

Talvez, academicamente, ou por uma questão de organização, adotar uma stage area costuma ser a abordagem mais recomendada. Porém, sabemos que no dia a dia a escassez de recursos faz com que quem executa a tarefa muitas vezes não tenha disponível tempo ou mão-de-obra para tal estrutura. Neste caso, e não entendemos que seja uma perda para o projeto, o destino passa a ser o local definitivo em que o DW será estruturado. Fanatismos não produzem resultados. Saiba que nenhuma abordagem é inválida, desde que ela atinja o resultado proposto sem explodir o débito técnico. Em uma organização, a combinação de fatores pode levar a criação de várias estruturas e, no mercado atual, entregar soluções funcionais vale muito mais que o preciosismo acadêmico com o qual muitas vezes nos deparamos nos livros-textos de DW.

Para o armazenamento dos dados poderíamos ter por exemplo, as duas abordagens abaixo:

Imagens: Fabio de Salles

Após a definição das fontes de informação, da ferramenta de ETL a ser utilizada e da estrutura de armazenamento, o próximo passo é definir como estes dados serão entregues para a organização. Usualmente, cada conjunto de dados atenderá aos interesses de uma unidade de negócios - o departamento de vendas, por exemplo.

Consumo de Dados

As necessidades de dados de uma unidade de negócios é que justificam o investimento em uma estrutura de BI. Existem ao menos três categorias:

• Análises de dados,
• Acompanhamento por meio de relatórios e
• Apresentação usando painéis de dados (Dashboards).

A análise de dados pode ocorrer por meio de ferramentas de análises multidimensionais (oferecido por quase todo fornecedor) ou de Data Mining. Relatórios têm um uso mais comum, mas menos glamoroso, que é manter os diversos consumidores de informação inteirados da situação corrente. A apresentação de painéis de dados (Dashboards) costuma servir à apresentação de grandes arcos de dados, como uma visão corporativa ou departamental, em um espaço relativamente pequeno.

Esses três desejos são os mais importantes e que pagam por toda a festa. Soluções de BIs bem consolidadas, estruturadas e eficientes entregam segurança e visibilidade dos dados para uma empresa.

Em comum a todos esses usos há os famosos Indicadores, ou KPIs (Key Performance Indicators). Esses nada mais são que a aglomeração de vários dados em uma métrica com significado de negócio. Assim, por exemplo, pedidos são dados, mas o valor médio por pedido e a quantidade de pedidos por mês são dois KPIs. Interessa ao negócio que ambos evoluam, e por isso monitoramos os KPIs, não os dados dos pedidos.

Assim, para dar um exemplo de cada categoria, podemos ter um cubo para análise multidimensional dos KPIs de venda para os analistas de negócios, um relatório com os KPIs de produtividade extrapolados para o próximo mês para os gerentes de vendas, e um painel que conjuga as duas informações para consumo da diretoria.

Como dashboards são elementos vivos e constantemente atualizados, é comum que toda unidade de negócio deseje um, pois é a partir das informações apresentadas nestes painéis que as áreas de operações "vêem" os dados e lidam com o dia a dia. Dashboards podem conter quase que qualquer tipo de informação e são capazes de atender às mais diferentes áreas como por exemplo as áreas de logística, aeroespacial, aluguel de veículos entre outras.

Mas para que a mágica de transformar dados em valiosos conhecimentos de negócio ocorra, a estrutura que alimenta essas ferramentas precisa estar sólida, eficiente, sem erros e respondendo o mais brevemente possível. E como conseguimos essa garantia de conformidade, qualidade e velocidade? A partir de uma estrutura sólida de captura de dados, armazenamento e disponibilização que só podem ser fornecidas quando todos os aspectos de captura de dados são muito bem pensados e implementados.

Este é um dos principais motivos que um arquiteto de solução deve se preocupar ao projetar ou propor uma solução de coleta de dados que viabilizam um projeto de BI de sucesso: a coleta adequada das informações e mesmo a identificação correta dos dados que alimentarão os indicadores é que darão a garantia de que todo o trabalho foi realizado com maestria e precisão. A falta de qualquer informação fatalmente levará a um descrédito da solução e com isto ao fracasso do projeto.

Gerenciamento de dados mestres (MDM)

Master Data Management - MDM - consiste na gestão de dados que são críticos para uma organização e precisam ser padronizados ao serem utilizados e/ou distribuídos em sistemas e processos distintos, gerando, assim, uma visualização confiável destas entidades. Um projeto de MDM precisa ser assertivo e eficaz mas exige um comprometimento que inclui as duas pontas de qualquer grande empresa - a alta gestão e quem efetivamente manuseia e armazena os dados. Este comprometimento se faz necessário para identificar entidades importantes para o negócio assim como as que são estratégicas para a organização.

Como exemplo podemos imaginar um grande hospital onde um paciente recebe determinado medicamento por um especialista, caso necessite de outro tratamento, em outro departamento, os dados do seu prontuário precisam estar devidamente atualizados, para que não ocorram conflitos entre os tratamentos. Em outra ponta, um sistema que gerencia o estoque de medicamentos precisa da correta atualização da utilização dos mesmos para que sejam realizados pedidos aos fornecedores corretamente. Neste exemplo pode-se citar como entidades mestre: Paciente, Prontuário e Medicamento. Ambas precisam estar corretamente atualizadas, independente do departamento ou sistema que as utilizará.

A correta gestão destes dados é de extrema importância para um projeto de BI, em especial para o processo de ETL, pois fornece informações precisas, e confiáveis, para serem carregadas em um Data Warehouse, por exemplo. Este processo, se bem definido, facilita a criação das dimensões (em um modelo de DW dimensional), pois já estão definidas todas as entidades que são chaves para descrever um determinado fato.

Veja que há uma correlação entre o papel de um MDM e de uma solução de ETL, elas se completam apesar da natureza mais abrangente que um MDM se propõe. Projetos de MDM possuem um custo elevado, são de longa duração e para que possam entregar valor precisam percorrer uma grande jornada de identificação das fontes de informações, a representatividade que cada informação possui na cadeia e a definição por um grupo formado por vários profissionais que conhecem toda a necessidade de uma empresa de como o dado será entregue para a próxima camada.

Conclusão

Apesar de o Hadoop ter nascido em 2006, foi na década de 2010 que presenciamos a explosão das tecnologias de tratamento de grandes volumes de dados. Essa tecnologia acabou tendo o efeito colateral de trazer os projetos de BI para o assento da frente. A mistura de novos e mais visíveis mercados para produtos de dados - que nada tem a ver com BI, e com os tradicionais fornecedores de ferramentas de análises de dados, que são apenas parte do mercado de BI - criou um ambiente propício à ideia de que BI é algo mágico e pode ser comprado dentro de uma caixinha de software.

Nada mais longe da verdade. Projetos de BI de sucesso requerem trabalho e dedicação. Deste trabalho todo, a parte realmente crítica é a identificação dos dados que servirão de insumo na solução dos problemas de negócio.

Este artigo mostrou uma visão geral de como lidar com o fluxo de entendimento e disponibilização dos dados: desde a identificação das fontes até a publicação para consumo, passando pelo processo de identificação dos dados de cada fonte que serão necessários.

Então, da próxima vez que um fornecedor de software te oferecer um produto mágico, lembre-se: No pain, no gain.

Sobre os Autores