Estratégias de Negócios para Iniciar Projetos de Business Intelligence

A Ponte Necessária: Estratégias de Negócios para Iniciar Projetos de Business Intelligence (BI) e Colaborar Efetivamente com a TI

O cenário empresarial moderno depende intrinsecamente da capacidade de aproveitar os ativos de informação internos e externos para apoiar uma tomada de decisões aprimorada (IŞIK, 2013). O Business Intelligence (BI) é o termo genérico para o sistema que engloba metodologias, processos, arquiteturas e tecnologias que transformam dados brutos em informações significativas e úteis (IŞIK, 2013). No entanto, a materialização de um sistema de BI, seja um dashboard ou um painel de desempenho, requer uma parceria profunda e funcional com a equipe de Tecnologia da Informação (TI). O sucesso de qualquer iniciativa de Data Warehouse/Business Intelligence (DW/BI) está diretamente ligado à aceitação do usuário (KIMBALL, 2004) e é maximizado por um entendimento sólido dos requisitos de negócio.

O desafio reside em como as pessoas de negócio, que definem o valor e os objetivos (KIMBALL, 2013), podem comunicar suas necessidades de maneira que a TI possa traduzi-las em uma solução técnica eficaz e gerenciável. Para isso, o time de negócio precisa entender que o BI é um sistema de apoio à decisão composto por elementos técnicos e organizacionais, e que a TI necessita de clareza sobre o valor estratégico para justificar o investimento. A área de negócio deve articular metas gerais de longo prazo que o sistema deve alcançar, abrangendo preocupações tanto funcionais quanto não funcionais, como confiabilidade e usabilidade. O planejamento do projeto deve ser um processo integrado, pois a complexidade de um projeto DW/BI exige uma gestão detalhada, levando em conta os diversos players e tarefas envolvidas (KIMBALL, 2004).

A comunicação inicial entre o negócio e a TI deve focar em definir o problema de negócio e os critérios de sucesso de forma inequívoca. O primeiro passo em qualquer projeto de BI deve ser justificar claramente o custo e os benefícios da solução de um problema de negócio (GANGADHARAN, 2004). A equipe de negócio deve identificar os Key Performance Indicators (KPIs), que são as métricas de desempenho essenciais para medir o sucesso. É fundamental que a TI e o negócio definam o que deve ser medido e como esses resultados se traduzirão em impacto potencial nas métricas de desempenho da empresa através de um acesso aprimorado à informação. Um erro comum a ser evitado é iniciar a conversa apenas solicitando os relatórios ou painéis existentes (KIMBALL, 2013). Em vez disso, a equipe de negócio deve se concentrar em identificar os eventos de medição dos processos de negócio principais que geram esses relatórios e métricas.

A TI e os analistas de dados (incluindo o Arquiteto de Dados ou o Administrador de Dados) precisam entender o que a organização tem interesse em observar, controlar e administrar (o que se denomina minimundo ou contexto de negócio) (MACHADO, 2014). Isso é essencial porque a modelagem de dados deve se basear na realidade e nos conceitos do negócio, e não simplesmente em simular o ambiente atual ou em relatórios obsoletos. A adoção da terminologia dos envolvidos (a linguagem do negócio) e a minimização do jargão técnico são práticas vitais para a colaboração (PRESSMAN, 2021). Além disso, a TI não deve trabalhar isolada; o negócio deve fornecer definições de negócio claras (de uma a duas frases) para cada termo, que são inestimáveis para dar sentido aos dados e garantir que as informações sejam intuitivas e óbvias para o usuário. Sem esse alinhamento, a iniciativa DW/BI corre o risco de se tornar um exercício técnico fútil.

Para que a TI possa construir a arquitetura de dados subjacente, o negócio precisa entender as implicações do design para a performance e a usabilidade. Historicamente, os sistemas de banco de dados evoluíram para preservar a consistência da informação através de processos de normalização (como a 1FN, 2FN, 3FN, FNBC, 4FN e 5FN) (MACHADO, 2014). Embora a normalização seja essencial para a consistência em sistemas operacionais (OLTP) (RAMAKRISHNAN, 2021), ela requer navegação através de múltiplas tabelas para compor uma informação.

Em contraste, a TI frequentemente utiliza técnicas de modelagem dimensional (com tabelas de fatos e dimensões) para os sistemas de BI, pois essa abordagem privilegia uma estrutura de dados simples e de alto desempenho para consultas analíticas (POOLE, 2001). O conceito da modelagem de dados deve ser compreendido em três níveis: o Modelo Conceitual (descrição simples da realidade, focado em entidades e relacionamentos, facilmente compreendido pelo usuário final); o Modelo Lógico (o esquema no modelo de dados do SGBD escolhido, como o relacional); e o Modelo Físico (focado em desempenho, definindo estruturas de armazenamento, índices e agrupamento) (RAMAKRISHNAN, 2021).

O time de negócio deve se concentrar em validar a fidelidade do Modelo Conceitual, que representa a realidade das informações e as regras de negócio. Durante a modelagem, o analista deve utilizar a abstração para identificar as características e propriedades essenciais dos objetos de negócio. A TI, por sua vez, pode empregar a desnormalização ou, em projetos mais avançados, técnicas de otimização física como a indexação de colunas e o co-agrupamento (co-grouping) para atingir os requisitos de desempenho críticos definidos pelo negócio.

A fase de requisitos é, em essência, um exercício de colaboração contínua, e o negócio deve gerenciar ativamente as expectativas e o escopo. Um dos desafios é que os usuários frequentemente têm dificuldade em descrever um sistema completo antes de vê-lo em operação (PRESSMAN, 2021). Por essa razão, a prototipagem é altamente recomendada como a melhor forma de realizar a análise das entregas funcionais, dando aos usuários a oportunidade de ajustar seus requisitos e suas expectativas (GANGADHARAN, 2004). A equipe de projeto deve adotar um ciclo de desenvolvimento iterativo (KIMBALL, 2008), pois o desenvolvimento do DW/BI nunca termina. É importante reconhecer que o retrabalho (rework) é um fato intrínseco aos projetos DW/BI devido às mudanças nas condições de negócio, e não é necessariamente um sinal de falha de design. Para garantir a viabilidade e o valor do projeto, o escopo deve ser significativo e gerenciável, o que significa, idealmente, que a iteração inicial deve se limitar aos dados resultantes de um único processo de negócio.

O patrocinador do negócio deve estar ciente de que a consolidação de métricas de múltiplos sistemas de origem em um único ciclo de implementação aumenta o esforço de Extração, Transformação e Carga (ETL) exponencialmente. Além disso, a equipe de TI deve envolver os usuários de negócio na avaliação de ferramentas de BI, trabalhando lado a lado com eles em sessões curtas para obter feedback.

Finalmente, a credibilidade do sistema depende de dados de alta qualidade e de governança robusta (WATSON, 2007). A falta de dados de alta qualidade é uma das causas mais comuns de falha em projetos de BI.

O processo de ETL é fundamental para a integração e limpeza dos dados (INMON, 2002), garantindo que eles estejam consistentes (VAN DER LANS, 2012). O negócio deve fornecer as regras de negócio que a TI utilizará para testar anomalias, e cada exceção deve ser documentada e resolvida. A TI deve estabelecer uma infraestrutura de dados de apoio à decisão robusta (Data Warehouse) para mitigar a falta de dados de alta qualidade.

Além dos dados, o aspecto mais importante para o usuário é o metadado de negócio. A documentação dos metadados de negócio deve ser priorizada e estar pronta assim que o sistema for lançado (MUNDY, 2011). Esses metadados descrevem o conteúdo do DW em termos de negócio (POOLE, 2001) e suportam o maior e mais importante segmento de stakeholders do BI: os usuários, que, na maioria das vezes, não conseguem encontrar essa informação por outros meios.

Ao entender esses conceitos e participar ativamente na definição de requisitos e na validação do modelo conceitual, o público de negócios pode garantir que o projeto de BI seja orientado pelo valor de negócio e não apenas por metas técnicas, aumentando drasticamente as chances de sucesso.

Referências

GANGADHARAN, G. R.; SWAMI, Sundaravalli N. Business Intelligence Systems: Design and Implementation Strategies. In: INTERNATIONAL CONFERENCE ON INFORMATION TECHNOLOGY INTERFACES (ITI), 26., 2004, Cavtat, Croatia. Proceedings… [S.l.]: IEEE, 2004. p. 139-140.

INMON, W. H. Building the data warehouse. 3. ed. New York: John Wiley & Sons, 2002.

IŞIK, Öykü et al. Business intelligence success: The roles of BI capabilities and decision environments. Information & Management, v. 50, n. 1, p. 13–23, 2013.

KIMBALL, Ralph; CASERTA, Joe. The Data Warehouse ETL Toolkit: Practical Techniques for Extracting, Cleaning, Conforming, and Delivering Data. Indianapolis: John Wiley & Sons, 2004.

KIMBALL, Ralph; ROSS, Margy. The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling. 2. ed. New York: John Wiley & Sons, 2013.

KIMBALL, Ralph et al. The Data Warehouse Lifecycle Toolkit. 2. ed. Indianapolis: Wiley Publishing, 2008.

MACHADO, Felipe Nery Rodrigues. Banco de Dados: Projeto e Implementação. 3. ed. São Paulo: Érica, 2014.

MUNDY, Joy; THORNTHWAITE, Warren. The Microsoft Data Warehouse Toolkit: With SQL Server 2008 R2 and the Microsoft Business Intelligence Toolset. Segunda edição. Indianapolis: Wiley Publishing, Inc., 2011.

POOLE, John et al. Common warehouse metamodel: an introduction to the standard for data warehouse integration. Needham, MA: Object Management Group, 2001.

PRESSMAN, Roger S.; MAXIM, Bruce R. Engenharia de software: uma abordagem profissional. 9. ed. Porto Alegre: AMGH, 2021.

RAMAKRISHNAN, Raghu; GEHRKE, Johannes. Sistemas de Gerenciamento de Banco de Dados. Tradução da 3. ed. Porto Alegre: AMGH, 2011.

VAN DER LANS, Rick F. Data Virtualization for Business Intelligence Systems: Revolutionizing Data Integration for Data Warehouses. First Edition. Amsterdam: Morgan Kaufmann Publishers, 2012.

WATSON, Hugh J.; WIXOM, Barbara H. Enterprise agility and mature BI capabilities. Business Intelligence Journal, v. 12, n. 3, p. 13–28, 2007.

Sobre o autor

Rodrigo Zambon

Sólida experiência em Metodologias Ágeis e Engenharia de Software, com mais de 15 anos atuando como professor de Scrum e Kanban. No Governo do Estado do Espírito Santo, gerenciou uma variedade de projetos, tanto na área de TI, como em outros setores. Sou cientista de dados formado pela USP e atualmente estou profundamente envolvido na área de dados, desempenhando o papel de DPO (Data Protection Officer) no Governo.