ficha de caracterização de trabalho - student.dei.uc.ptjpguerra/gsi/implementacao de...

Gestão de Sistemas de Informação Implementação de Business Intelligence nas TI

Departamento de Engenharia Informática, Universidade de Coimbra 2006/2007

Ficha de Caracterização de Trabalho

Título: Implementação de Business Intelligence nas TI

Resumo: Apresenta-se, de forma sintética, os principais conceitos relacionados com a Busi-ness Intelligence, os potenciais benefícios para a organização, a arquitectura usualmente encontrada nas soluções e os vários tipos de ferramentas existentes no mercado. Posterior-mente faz-se uma introdução ao desenvolvimento de um projecto de BI, dando particular ênfase ao passo de implementação.

URL:

http://student.dei.uc.pt/~jpguerra/gsi/Implementacao%20de%20Business%20Intelligence.pdf

Data: 17 de Novembro de 2006

Esforço: 20h

Motivação: Aquisição de conhecimentos sobre um tema que encontra grande popularidade

dentro das organizações

Aprendizagem: Conceitos mais elaborados sobre Business Intelligence, principais ferramentas

utilizadas, arquitectura das soluções e compreensão mais detalhada da estruturação de um

projecto de BI, com ênfase na implementação

Conteúdos: Business Intelligence, Data Warehouse, OLAP, ETL, Data Mining, Reporting

Sequência: Aprofundamento dos capítulos existentes, especialmente no que diz respeito ao

projecto de BI, inclusão de novos capítulos, por exemplo com exemplos reais de implementa-

ções bem sucedidas



Implementação de Business Intelligence nas TI

por João Paulo Guerra Nascimento

Sumário. Apresenta-se, de forma sintética, os principais conceitos relacionados com a Business Intelligence, os potenciais benefícios para a organização, a arquitectura usualmente encontrada nas soluções e os vários tipos de ferramentas existentes no mercado. Posteriormente faz-se uma introdução ao desenvolvimento de um projecto de BI, dando particular ênfase ao passo de implementação.

Palavras chave. Business Intelligence, BI, Data Warehouse, OLAP, ETL, Data Mining, Reporting

1. Introdução

A Business Intelligence (BI) é um conceito lato, que abrange um grande leque de aplicações e tecnologias cujas funções passem por recolher, guardar, aceder e analisar dados relativos aos vários sub-sistemas de informação de uma empresa para que os seus indivíduos possam tomar melhores decisões e ganhar assim vantagens competitivas. A obtenção desses dados de uma forma estruturada e rápida permite extrapolar informações essenciais sobre o ambien-te interno e externo de uma organização, como seja a posição desta face aos seus concorrentes, as preferências e desvios comportamentais dos clientes, os padrões de gastos, a capacidade da organização, indicadores económicos, tendências do mercado… [1]

A grande abrangência deste tópico inclui aplicações com funções muito diversas, como sistemas de apoio ao negócio, pesquisa, relatórios, processamento analítico online (OLAP), análise estatística, previsão e mineração de dados (Data Mining). Em qualquer destas aplicações, os dados da organização utilizados na BI estão normalmente contidos em Data Warehouses e/ou Data Marts. A implementação de BI numa empresa pode ser feita de uma forma estratégica e crítica para as suas operações, ou apenas de uma forma mais parcial de forma satisfazer determinado requisito, e as aplicações tanto podem ser centrais a toda a organização como abranger apenas determinado departa-mento, divisão ou projecto. A grande escalabilidade das soluções e os potenciais benefícios para o negócio revestem esta área de um grande interesse por parte das organizações, e é o objecto deste artigo, que vai incidir de forma espe-cial nos detalhes de implementação da BI numa empresa.[2]

2. Arquitectura Conceptual

Apesar de todas as soluções de BI possuírem diferenças e a sua instalação nas organizações seguirem padrões que não são sempre comuns, existe uma arquitectura conceptual que normalmente é transversal aos sistemas de BI, cuja representação se encontra na figura 1: [3]

Figura 1 - Arquitectura Conceptual de BI [3]



Os dados utilizados pela BI são armazenados em Data Warehouses (DW) ou Data Marts (DM), sendo a principal diferença entre estes conceitos o tamanho e contexto dos dados. Uma DW contém normalmente toda a informação relevante da empresa que é utilizada pelas várias ferramentas de BI, os Data Marts podem ser vistos como uma DW local a determinada área/segmento da organização, podendo ser utilizados para implementar BI a um nível mais conciso na organização, como por exemplo o departamento de facturação. Ambas as definições pressupõem bases de dados relacionais, com dados relevantes ao longo do tempo, acessíveis para leitura, e que possuam um bom nível de qualidade, ou seja, a credibilidade e honestidade dos dados não deve ser posta em causa. [4]

Estes dados são recolhidos a partir das várias bases de dados da empresa, ou mesmo de fontes externas, como relatórios industriais ou sondagens/estudos, e são depois transformados e validados antes de serem colocados na Data Warehouse através de ferramentas ETL (Extraction, Transformation, Loading) que são executadas periodicamente para adicionar novos dados à DW. Aqui, um factor essencial é a velocidade a que se obtém resultados para as pesqui-sas efectuadas, por isso, de forma a auxiliar o acesso a dados a partir de querys complexas, criou-se o conceito de “cubo” multidimensional, uma estrutura de dados eficiente e muito rápida a responder a pesquisas. [3]

Existem várias ferramentas que fazem depois uso da informação proveniente das DW/DM, para serem utilizadas pelos analistas técnicos ou do negócio. Estas ferramentas são de vários tipos: [3]

• OLAP (On-line Analytical Processing): permite acesso ao “cubo” multidimensional, para análise preditiva e em várias dimensões da informação, que é explorada livremente, permitindo assim detectar tendências e relações entre os dados mais facilmente.

• Emissão de relatórios estáticos/dinâmicos: permite analisar determinada informação, ordenada segundo algum critério, como as vendas no 2º trimestre do ano, por exemplo. É possível gerar relatórios complexos de uma forma simples, e no caso dos relatórios dinâmicos os utilizadores podem até manipular a informação e ace-der a níveis de detalhe muito elevados.

• Balanced Scorecarding: permite medir de uma forma frequente e relevante a performance individual e das equipas de acordo com um determinado conjunto de objectivos da empresa.

• Orçamentação e Previsão: a utilização de BI permite uma melhor previsão e consolidação dos orçamentos dentro dos vários departamentos da organização, que estão assim em linha com as realidades do negócio.

• Mineração de Dados (Data Mining): permite reconhecer padrões e relações que não são facilmente identifi-cáveis por métodos de análise simples. Descreve normalmente as características de entidades (por exemplo, os compradores), ou prevê o valor de alguma variável.

• Excepções e Notificações: permite agir de forma automática quando certas medidas de performance forem ultrapassadas, por exemplo quando se exceder determinado limite de horas extra de trabalho pode ser enviado pelo software um e-mail a quem essa informação tenha interesse.

3. Antes de se iniciar um projecto de BI

As organizações passam normalmente muito tempo a pensar em como proceder à implementação de soluções de BI sem que antes tenham sido respondidas questões muito importantes, como: [5]

• Que informação é necessária? É necessário haver um alinhamento dos dados, e refinar as suas necessidades. Para tal devem ser seguidos vários passos. Deve ser criada uma checklist com os relatórios que se encontram presentemente a ser utilizados dentro da organização, os dados que são utilizados e a proveniência dos mesmos. Deve-se identificar as funções do negócio e começar a partir de baixo a determinar os requisitos presentes e futu-ros dos relatórios para os vários utilizadores intervenientes nessas funções. Deve ser deliberado conjuntamente com os utilizadores do negócio a relevância das várias informações dos relatórios para análise, e retirar o que não for importante. Devem ser identificados também os relatórios e dados que não foram utilizados durante um determinado período de tempo e marcá-los para racionalização. Deve ser estabelecida e concordada a frequência de actualização de informação utilizada nos relatórios e definido um período de tempo mínimo e máximo para manter o histórico de dados.

• Como é que será recolhida essa informação? Com a utilização de uma solução de BI, o formato dos relató-rios poderá ser alterado. Deste modo, é importante desde o início ter em conta a categorização de informação a ser utilizada em análises online e a necessária para os relatórios periódicos. Deve-se ter já uma noção de como será feita a visualização dos dados e de como salientar acontecimentos de excepção nos relatórios que os utiliza-dores tenham de ter em atenção.



• Quem deve ter acesso a que informação? É necessário identificar os conjuntos de informação que devem ter um acesso restrito, assim como mapear os vários utilizadores com os tipos de acesso que cada um pode ter.

• Como devem os utilizadores prepararem-se para utilizar a nova solução de BI? A gestão de mudança é necessária em qualquer projecto, e os de Business Intelligence não são excepção. Para evitar que a solução falhe devido à falta de aceitação por parte dos utilizadores, estes devem ser encorajados logo no início a participar na fase preparatória de adopção de BI, identificando os utilizadores-chave de cada função do negócio que irão ter como função comunicar aos outros utilizadores da sua área de responsabilidade a mensagem de mudança.

Os dados vão desempenhar um papel fundamental numa solução de BI. Será difícil utilizar a BI como suporte a uma boa decisão, se os dados que suportam essa decisão forem incoerentes, incompletos ou indisponíveis, daí que o acesso a dados de alta qualidade e o estabelecimento de um programa formal de qualidade deve estar na base no projecto. [6]

A relação entre o departamento de TI e o projecto de BI tem também de ser observada mesmo antes de começar a sua implementação. As tecnologias por detrás das soluções que vão ser utilizadas não são, muitas vezes, dominadas pelo pessoal de TI, e este departamento costuma saber à partida que caber-lhe-á resolver muitos dos problemas que depois surjam com as aplicações de BI. No entanto, se a empresa desenvolver uma estratégia organizacional para estas aplicações e conseguir aliar a TI como parceiro essencial, criando a consciência que o papel das tecnologias de informação estará ligado com o sucesso do negócio, os riscos de problemas internos são mais reduzidos. Deve-se no entanto ter cuidado para não colocar nas mãos das TI a análise das questões e funções que são necessárias, pois regra geral esta análise não será orientada para os problemas e objectivos do negócio, mas sim para questões puramente técnicas. [7]

O sucesso da implementação de BI depende em muito da atitude e capacidade das organizações. De seguida apresentam-se alguns factos de empresas que não estão preparadas para iniciar um projecto deste tipo: [8]

• Falta de compreensão da complexidade de um projecto de BI

• Falta de reconhecimento de um projecto de BI como uma iniciativa transversal à organização e que é diferente das soluções stand-alone

• Falta de representantes do negócio, ou falta de vontade destes para participar no projecto

• Falta de financiadores do projecto, ou que não têm uma posição de autoridade suficientemente alta na organi-zação

• Falta de pessoal para o desenvolvimento do projecto, ou sem as capacidades necessárias para a sua realização

• Estrutura/Dinâmica da equipa de projecto desapropriada

• Não existência de um método de desenvolvimento iterativo

• Não existência de uma estrutura de divisão de tarefas

• Gestão de projecto pouco eficiente

• Não contemplação de uma análise do negócio

• Falta de consciência do impacto de dados de pouca qualidade no negócio

• Falta de compreensão da necessidade e utilização de meta dados

• Excesso de confiança em métodos e ferramentas que se esperam erradamente que resolvam todos os proble-mas



4. Estrutura da equipa de projecto de BI

Antes de analisar a forma como é desenvolvido um projecto de BI, podemos desde já definir a estrutura ideal das equipas de pessoas que irão realizá-lo, assim como os papéis e responsabilidades que cada indivíduo deve assumir. Devem existir dois tipos de equipas, a equipa central e a equipa estendida. A equipa central é auto-organizada, e os seus indivíduos distribuem tarefas entre cada um, examinam os deliverables dos colegas, discutem, tomam decisões e dirigem o projecto em conjunto. Pode-se ainda distinguir entre os membros permanentes da equipa central e os membros permanentes da equipa central de determinada fase. O primeiro conjunto é constituído por indivíduos que dedicam todo o seu tempo ao projecto de BI desde o início ao seu término. São estes elementos que co-dirigem o projecto, idealmente 4-5 pessoas, que devem incluir um gestor de projecto, um representante do lado do negócio, um analista de negócio proveniente do departamento de TI e um elemento técnico do mesmo departamento (um progra-mador ou analista de sistemas sénior). Os membros permanentes de determinada fase também acompanham a tempo inteiro o projecto, mas só durante a(s) fase(s) em que são necessários. Na seguinte tabela podem-se visualizar os papéis e responsabilidades dos membros da equipa central de projecto: [8]

Application lead developer Projecta e supervisiona o desenvolvimento do acesso e análise de aplicações

BI infrastructure architect Estabelece e mantém a infraestructura técnica de BI

Business representative Participa em reuniões de modelação, providencia definições de dados, casos de uso, toma decisões de negócio e resolve conflitos entre unidades deste tipo

Data administrator

Faz análise de dados transversais à organização, cria os modelos lógicos de dados de projecto específicos e agrupa-os num modelo lógico de dados organiza-cional

Data mining expert Escolhe e executa a ferramenta de mineração de dados

Data quality analyst Avalia a qualidade dos dados de origem e prepara especificações de limpeza de dados que são utiliza-das no processo ETL

Database administrator Projecta, cria, monitoriza e optimiza as bases de dados utilizadas pela BI

ETL lead developer Projecta e supervisiona o processo ETL

Meta data administrator Constrói/licencia, executa e mantém o repositório de metadados

Project manager

Define, planeia, coordena, controla e analisa todas as actividades do projecto, monitorizando o progresso, resolvendo questões técnicas e do negócio, sendo o mentor da equipa e principal responsável do projecto

Subject matter expert Providencia conhecimento do negócio sobre os dados, processos e requisitos

Tabela 1 - Papéis e Responsabilidades dos Membros da Equipa Central [8]

Um indivíduo pode desempenhar mais do que um papel, no entanto alguns são mutuamente exclusivos, nomea-damente o administrador de dados/administrador de base de dados, pois enquanto o primeiro produz modelos lógicos de dados que são independentes dos processos, no segundo caso o administrador produz modelos físicos de dados dependentes de processos, e que consistem no design lógico da base de dados. Outro caso é o gestor de projecto, que não deve assumir outro papel que não seja o de liderança, pois a gestão de um projecto de BI ocupa todo o tempo disponível e não deve ser posta em causa com outro trabalho de desenvolvimento. [8]

Na equipa estendida os seus elementos têm também responsabilidades no projecto de BI, mas este não é a sua principal prioridade durante todo o tempo do mesmo. Estes elementos normalmente têm de arranjar tempo para tra-balharem com os elementos da equipa central e são também chamados quando a sua experiência pode ser útil para resolver um problema ou tomar uma decisão. Na tabela 2 podem-se observar também os papéis/responsabilidades destes elementos: [8]



Application developer(s) Codifica os programas que geram os relatórios, escreve scripts de pesquisa e desenvolve as aplicações de acesso e análise

BI support Orienta e treina a equipa de negócio

Business sponsor Promove a iniciativa de BI e remove obstáculos relacionados com o negócio à equipa de projecto

ETL developer(s) Codifica os programas ETL e/ou prepara as instruções a serem utilizadas pela ferramenta de ETL

IT auditor ou QA analyst Determina os riscos do projecto face à falta de controlo inter-no ou de forças externas

Meta data repository developer(s) Codifica os programas de migração do repositório de metada-dos que irão inserir a informação nesta base de dados. Provi-dencia ainda relatórios de metadados e ajuda online

Network services staff Mantém o ambiente da rede

Operations staff Executam os processos automáticos dos ciclos de ETL, exe-cutam a aplicação de acesso e análise e o repositório de meta-dados

Security officer Assegura que os requisitos de segurança estão definidos e que esses mecanismos são testados em todas as ferramentas e bases de dados

Stakeholders Analisa e ratifica os standards transversais a toda a organiza-ção e regras de negócio que a equipa de projecto utiliza

Strategic architect Mantém globalmente a infra-estrutura técnica da organização, incluindo a do projecto de BI

Technical services staff Mantém a infra-estrutura de hardware e sistemas operativos

Testers Testam o código criado pelos elementos que desenvolvem o ETL, aplicações e repositório de metadados

Tool administrators Instalam e supervisionam o funcionamento das ferramentas de desenvolvimento, de acesso e de análise

Web developer(s) Desenvolvem o website e criam as páginas que irão mostrar os relatórios e resultados de pesquisas

Webmaster Configura o servidor Web e a segurança do mesmo Tabela 2 - Papéis e Responsabilidades dos Membros da Equipa Estendida [8]

Também neste caso os papéis não são exclusivos de um indivíduo, por exemplo, o Webmaster e Web developer pode ser a mesma pessoa. Há no entanto um caso em os papéis são mutuamente exclusivos: um developer nunca deve ser encarregado de ser o tester dos seus programas, sob pena da avaliação destes não ser objectiva nem impar-cial. [8]

Podemos agora ter uma noção mais exacta da importância de se possuírem os recursos-chave e dos tipos de competências que são necessárias haver para levar a bom termo um projecto de BI.



5. Estágios de desenvolvimento de um projecto de BI

À semelhança de muitos outros tipos de projectos, as soluções de BI seguem também seis estágios de desenvol-vimento, como pode ser visto na figura 2:

Figura 2 - Desenvolvimento de um Projecto de BI [8]

O primeiro estágio, “Justificação”, compreende a avaliação das necessidades do negócio que originam o desen-volvimento deste projecto. O segundo estágio, “Planeamento”, trata do desenvolvimento de planos estratégicos e tácticos que dizem como o projecto vai ser realizado, concluído e distribuído. O terceiro estágio, “Análise de Negó-cio”, refere-se à análise detalhada do problema/oportunidades do negócio de forma a delinear os requisitos do negó-cio necessários à solução. O quarto estágio, “Design”, trata da concepção de uma solução que possa assim resolver o problema do negócio ou permita atingir a oportunidade de negócio pretendida. O quinto estágio, “Construção”, como o nome indica, trata de construir o produto, dentro de determinado limite temporal preestabelecido. Por fim, o sexto estágio, “Deployment”, trata da implementação da solução, e de posteriormente medir a sua eficácia de forma a determinar se o produto cumpre os objectivos previstos. Este ciclo é iterativo, ou seja, mesmo depois do estágio de deployment, é possível iniciar uma nova iteração com vista ao melhoramento da solução, de acordo com o feedback

dos utilizadores que empregam a solução. [8]

Existem algumas características diferenciadoras de aplicações de BI relativamente aos sistemas stand-alone. As aplicações de BI são orientadas pelas oportunidades de negócio, e não pelas necessidades de negócio. Também se caracterizam por implementar uma estratégia de suporte de decisão ao nível de toda a organização e não a um nível departamental. Os requisitos por sua vez são maioritariamente requisitos de informação estratégica, ao invés de requisitos funcionais dos sistemas stand-alone. Finalmente, a análise dentro dos projectos de BI é orientada para o negócio, e não para o sistema, sendo essa análise uma actividade crucial num ambiente de BI. [8]

O desenvolvimento de um projecto de BI pode visto como tendo 16 passos, sendo que cada um desses passos incorpora-se em algum dos estágios anteriormente descritos, como pode ser observado na seguinte figura:



Figura 2 - Passos de um projecto de BI [8]

Resumidamente, cada um destes passos consiste no seguinte: [8]

1. Business Case Assessment (estágio de Justificação) – procede-se à definição do problema e/ou oportuni-dade de negócio e propõe-se uma solução de BI. A entrega de cada aplicação de BI é justificada ao nível de custo e dos benefícios de resolver um problema de negócio ou de tomar partido de uma oportunidade de negócio.

2. Enterprise Infrastructure Evaluation (estágio de Planeamento) – trata da avaliação e das necessidades potenciais de compra/desenvolvimento de componentes da infra-estrutura empresarial. Esta infra-estrutura tem dois componentes: técnico – inclui hardware, software, middleware, sistemas operativos e de gestão de base de dados, componentes de rede, repositórios de metadados… não-técnico – inclui os standards de metadados e de nomes de dados, o modelo lógico de dados da empresa, metodologias, guias, procedimentos de teste, processos de controlo de mudança, políticas para a gestão de problemas e resolução de conflitos…



3. Project Planning (estágio de Planeamento) – trata do planeamento do projecto, de detalhar tópicos como o âmbito, equipas, orçamentos, tecnologia, representantes do negócio e de monitorizar o progresso.

4. Project Requirements Definition (estágio de Análise de Negócio) – trata da definição dos requisitos de negócio e do projecto (funcionais, de dados, do histórico necessário, de performance e de segurança), de forma a gerir o âmbito do projecto. De notar que estes requisitos poderão ser alterados ao longo do desenvolvimento do projecto à medida que os indivíduos relacionados com o negócio se vão apercebendo das potencialidades e limitações das soluções de BI.

5. Data Analysis (estágio de Análise de Negócio) – trata da análise dos dados de origem da organização, tanto da sua qualidade como da sua proveniência, da modelação lógica de dados, de resolver discrepân-cias e da especificação para a limpeza dos mesmos. Este é um ponto central, pois a qualidade dos dados de origem é central para os sistemas de BI, logo este passo normalmente possui uma grande ênfase no que toca à duração total do projecto.

6. Application Prototyping (estágio de Análise de Negócio) – consiste na prototipagem de aplicações com vista a validar os requisitos previamente definidos, encontrar novos requisitos, verificar se o design e as ferramentas seleccionadas são as adequadas ao ambiente de BI, fazer os indivíduos perceberem as capa-cidades e limitações das soluções e aprovar/rejeitar conceitos e ideias.

7. Meta Data Repository Analysis (estágio de Análise de Negócio) – consiste na análise dos requisitos do repositório de metadados, incluindo os requisitos de interface, de acesso, de relatórios, e da criação do modelo lógico de metadados.

8. Database Design (estágio de Design) – trata de projectar as base de dados de BI, com origem nos requi-sitos de acesso, sumarização e agregação de dados, sendo também responsável pelo desenho das estrutu-ras físicas da BD e posterior construção das mesmas, de desenvolver mecanismos de manutenção, de monitorização e afinação dessas bases de dados e das pesquisas que serão feitas.

9. ETL Design (estágio de Design) – este é o processo mais complicado no projecto, pois a baixa qualidade dos dados de origem normalmente exigem muito tempo aos programas de transformação e limpeza de dados. Trata do design das ferramentas de extract/transform/load, de como escolher as aplicações correc-tas, os problemas encontrados na transformação de dados e de questões de integridade e indexação.

10. Meta Data Repository Design (estágio de Design) – trata da projecção do repositório de metadados, de questões como se a base de dados deve ser orientada a objectos ou de entidade-relacionamento, da centra-lização/descentralização da BD, do processo de avaliação de um produto deste género, ou da construção e instalação desta componente.

11. ETL Development (estágio de Construção) – trata do desenvolvimento dos programas ETL e teste dos mesmos no que toca aos módulos, performance, integração, regressão e asseguramento de qualidade. No caso de se utilizarem ferramentas ETL, trata também da escrita de extensões e scripts para a aplicação.

12. Application Development (estágio de Construção) – consiste no desenvolvimento de aplicações, seja através do aperfeiçoamento de protótipos, ou de uma forma mais robusta, utilizando ferramentas de aces-so e análise, como as de OLAP. Esta fase pode consistir em várias actividades, desde a definição final de requisitos até à projecção, construção e teste das aplicações e a criação de sessões de formação neste software aos elementos do helpdesk.

13. Data Mining (estágio de Construção) – trata da mineração de dados, ou seja, das aplicações que tentam encontrar padrões nos dados da organização e cuja informação possa ser utilizada como uma vantagem competitiva. Neste passo é feita a construção do modelo de dados analítico, que deve ter a capacidade de aprender ao longo do tempo à medida que é utilizado pela ferramenta de data mining.

14. Meta Data Repository Development (estágio de Construção) – se não for adquirido (licenciado) um repositório de metadados e for necessário construir um, este módulo está relacionado com a construção, teste, preparação para produção e formação no que toca a este componente.

15. Implementation (estágio de Deployment) – aborda a implementação de todos os componentes de BI num ambiente de produção após terem sido concluídos e testados. Debruça-se também com a formação dos indivíduos que vão usar as aplicações, com a segurança das aplicações e monitorização e afinamento de base de dados. Posteriormente vai-se retratar este passo com maior detalhe.

16. Release Evaluation (estágio de Deployment) – depois da entrega das aplicações é necessário observar as deadlines que não foram cumpridas, custos excessivos, conflitos e resolução dos mesmos, para que pos-sam ser feitos ajustamentos a este processo através da reavaliação de ferramentas, guias e técnicas antes de um novo ciclo de desenvolvimento comece.



Os passos para um projecto de BI não têm que ser feitos sequencialmente, e normalmente tal não acontece. No entanto há uma ordem natural de passagem de um estágio de desenvolvimento para o outro, logo existem algumas dependências entre determinados passos, que se podem observar na figura 3: [8]

Figura 3 – Dependências entre os vários passos de desenvolvimento de um projecto de BI [8]

Os passos que se encontram à esquerda ou à direita uns dos outros têm mais propensão para serem realizados linearmente devido às suas dependências, enquanto que os passos que se encontram alinhados verticalmente podem usualmente ser seguidos em paralelo. Uma análise mais detalhada a esta imagem permite observar que após os requi-sitos de projecto estarem definidos e antes da implementação (entre os passos 5 a 14) são seguidos pelo menos três percursos de desenvolvimento paralelo:

ETL: este percurso é referido como o back end, sendo o mais importante e complicado num projecto de BI, pos não será possível posteriormente utilizar ferramentas de OLAP para benefício da organização se as bases de dados de BI não tiverem sido projectadas devidamente ou com dados de qualidade. A função da equipa que trabalha neste caminho é assim projectar e colocar os dados nas BD de Business Intelligence.

Application: este percurso é referido como o front end, e o seu objectivo passa pela projecção e construção as aplicações de análise e acesso que vão ser empregadas pelos utilizadores.

Meta Data Repository: como o nome indica o seu objectivo passa pela projecção, construção e colocação de dados num repositório de metadados, que serve como uma ferramenta de orientação ao ambiente de BI. Os membros desta equipa têm ainda de construir as interfaces de acesso, de pesquisa e de relatórios utilizadas no repositório.

Estes três percursos distintos são considerados os principais sub-projectos de BI. Cada um tem a sua equipa e conjunto de actividades a serem cumpridas podendo no entanto haver interacções entre eles, que são mostradas na figura 4: [8]

Figura 4 - Passos de cada Caminho Paralelo de Desenvolvimento [8]



Na imagem pode-se observar quais são os passos correspondentes a cada sub-projecto de BI, e as interacções que podem ocorrer, nomeadamente nos passos 6 e 8 (Application Prototyping e Database Design) que são parcial-mente comuns entre o percurso ETL e o percurso Application.

Vamo-nos agora focar sobre o passo de implementação da solução de BI.

6. Implementação de BI

A implementação bem orientada de BI garante que o ambiente de apoio à decisão será tão seguro, robusto e estável quanto possível. É essencial que os indivíduos que estarão envolvidos neste passo saibam responder a uma série de questões: [8]

Estão definidas todas as bibliotecas e bases de dados de produção? Os processos de ETL diários/semanais/mensais estão agendados? Os programas regulares de criação de relatórios e do repositório de metadados estão agendados? A equipa de operações está pronta? Aprovaram os resultados dos testes de asseguramento de qualidade? É necessário criar procedimentos para a equipa de operações? Quando irão ser copiados os programas para as bibliotecas de produção? Quando irão ser carregadas as bases de dados de produção? Que medidas de segurança são necessárias? Que componentes já possuem essas medidas? As medidas de segurança envolvem encriptação/desencriptação? Quais? É necessário haver autenticação? Onde? Como é que serão protegidos os dados, aplicações, ferramentas e interfaces? Quais são os procedimentos de backup e recuperação de dados nas BD? Como será feita a monitorização de performance das BD? Quais serão as ferramentas usadas? Quem será o res-

ponsável? Como será feita a monitorização do crescimento em utilização e volume de dados? Os indivíduos do negócio receberam formação na utilização das aplicações? E no repositório de metadados? Os power-users receberam formação na construção eficiente de queries SQL? A equipa de helpdesk recebeu formação suficiente? Estão preparados para orientar as pessoas na utilização das

ferramentas de BI? Se não houver equipa de helpdesk quem irá dar apoio aos utilizadores?

6.1 Abordagem Iterativa

No planeamento da implementação deve ser utilizada uma abordagem iterativa ao invés de fazer tudo de uma só vez. Desta forma o risco de expor potenciais defeitos das aplicações de BI a toda a organização é reduzido. Além do mais, utilizando uma abordagem iterativa pode-se demonstrar a um grupo de pessoas os conceitos de BI e as caracte-rísticas das suas ferramentas de um modo informal. É recomendado: [8]

• Começar com um pequeno grupo de indivíduos da organização, sendo este grupo constituído não só pelos power-users mas também com as pessoas menos familiarizadas com tecnologia, analistas de negócio e com o representante do negócio primário que faz parte da equipa central de projecto.

• Olhar para os indivíduos como clientes, que desejamos convencer de que as soluções de BI desenvolvidas são uma mais valia para estes. Assim, deve-se fazer um esforço por haver uma implementação sem problemas, exis-tir uma formação interactiva e apoio constante às pessoas.

• Olhar para a abordagem iterativa como uma oportunidade para testar a forma de implementação, podendo ser ajustada ou podendo alterar-se a solução de BI antes da sua inauguração.

• Caso seja necessário duplicar as actividades de implementação em vários locais da organização será aconse-lhado faze-lo de uma forma faseada ao invés de tudo ao mesmo tempo.

6.2 Segurança

No que diz respeito às questões de segurança, estas devem ser testadas o mais cedo possível. Normalmente ou se dá demasiada atenção a este tópico ou então não merece qualquer observação por parte da equipa de implementação. Tipicamente isto acontece às organizações que colocam um grande ênfase na segurança ou às que têm políticas pou-co rígidas, respectivamente. Neste último caso, as organizações podem ficar expostas a falhas de segurança, espe-cialmente se informação proveniente das bases de dados de BI for disseminada pela Web. Não existe um pacote de segurança único que consiga implementar todas as medidas de segurança necessárias, no entanto este número deve



ser mantido baixo para evitar potenciais situações em que os utilizadores tenham de se autenticar em vários destes pacotes, com o inconveniente de passwords múltiplas e perda de tempo que podem provocar queixas e desmotivar o uso das aplicações de BI. [8]

Outro factor que tem de ser observado é que a implementação de medidas de segurança num ambiente centrali-zado é diferente de um ambiente que possua vários níveis (multi-tier). No primeiro caso é geralmente mais simples, pois os dados estão todos no mesmo local, logo as medidas de segurança podem ser todas focadas num único ponto. A complexidade é muito maior quando existem várias formas de aceder a dados espalhados por vários sítios. Neste último caso, quando os dados não estão armazenados num local central, podemos seguir um conjunto de passos para ter uma visão abrangente da segurança necessária. Primeiro deve-se criar um diagrama da arquitectura física da organização, determinando de seguida os caminhos de conectividade (a partir dos pontos de entrada – terminais, desktops, acesso remoto…) usados para aceder aos dados, criando um diagrama semelhante ao da figura 5: [8]

Após a criação deste diagrama e atribuição de nomes aos vários caminhos de acesso aos dados devemos então comparar esses caminhos com as medidas de segurança existentes. Se desenharmos uma matriz análoga à da figura 6, podemos observar as lacunas existentes e identificar onde é que é necessária mais segurança e qual o género desta.

Tendo ainda em conta que o acesso através de Internet às bases de dados de BI é cada vez mais comum, surgem assim outros constrangimentos ao nível da segurança do ambiente de BI em geral, e no acesso a dados das organiza-ções a partir da web. Neste caso, poderão ter de ser aplicados recursos extra de tempo e dinheiro na autentica-ção/autorização de todos os utilizadores internos/externos e se houver necessidade de transmitir dados sensíveis via web, sistemas de encriptação terão de ser considerados. A questão chave é que todos os requisitos de segurança têm de estar definidos o quanto antes para que se possam considerar todos os factores.

6.3 Backup de Dados

Apesar dos dados das BD de Business Intelligence serem criados a partir de outros sistemas, é um erro pensar-se que não é necessário haver uma política de backups, pois no caso da organização possuir bases de dados muito gran-des, os recursos necessários à reconstrução do repositório de BI são demasiado elevados. Embora este backup demo-re tempo, é preferível a voltar a carregar volumes gigantescos de dados históricos que muitas vezes as organizações já não dispõem. Assim, o backup deve ser feito de uma forma regular, podendo ser seguidas várias estratégias: [8]

• Backup Incremental – pode-se aproveitar uma vantagem das bases de dados de BI, que é o facto de os seus registos nunca serem actualizados, apenas são adicionados novos. Poderíamos deste modo armazenar apenas os novos registos que foram inseridos desde o último backup. Esta estratégia é realizável até para backups diários, no entanto deve-se ter em consideração que como existem usualmente várias bases de dados de BI, só quando estas forem todas salvaguardadas é que poderão voltar a ocorrer leituras.

• Backup Parcial – pode-se particionar as tabelas das bases de dados, permitindo assim que enquanto uma esteja a ser salvaguardada, todas as outras continuem disponíveis. Uma vantagem é que as BD suportam a paraleliza-ção de backups e portanto é benéfico guardar múltiplas partições ao mesmo tempo. As partições são geralmente criadas com base na data, mas daqui resulta uma desvantagem, pois no acesso aos dados estes não podem ser agrupados sob outra forma, o que terá impacto em termos de performance quando se geram relatórios.

Figura 5 – Ex. de Caminhos de Conectividade [8] Figura 6 – Ex. de Matriz de Análise de Falhas [8]



6.4 Monitorização da Utilização de Recursos

A monitorização de recursos no que diz respeito a computadores, à rede e a recursos humanos é essencial no ambiente de Business Intelligence e caso esta componente seja descurada pode haver um ou vários pontos de conges-tionamento nas aplicações de BI. É importante utilizar ferramentas de monitorização e alerta nos sistemas que supor-tam estas aplicações, pois a sua utilização geralmente cresce ao longo do tempo. Também a rede merece particular atenção, não devido ao uso diário de BI, mas porque é potencialmente um problema para o processo ETL, que preci-sa da disponibilidade de uma grande largura de banda para transmitir os dados das bases de dados de origem e inseri-los nas de BI. A utilização da rede também tem relevância em aplicações que acedem a níveis de dados mais profun-dos e detalhados (drill-down) de uma forma frequente, o mesmo acontecendo quando existe um grande número de queries por unidade de tempo, ou que impliquem devolver grandes quantidades de dados. Se a largura de banda for realmente um problema, poderá ser necessário implementar as aplicações num ambiente distribuído. Finalmente, tem de haver uma gestão da utilização de recursos humanos, pois o ambiente de BI envolve um grande grau de manuten-ção e indivíduos com competências muito distintas: a disponibilidade destes recursos tem de ser regulada. [8]

6.5 Gestão de Crescimento

A justificação para salientar este tema prende-se com a estimativa de que os dados num ambiente de BI passam a ser o dobro a cada dois anos, o mesmo acontecendo com a utilização das ferramentas ao longo do tempo. O cresci-mento de dados implica não só novos registos mas muitas vezes novas colunas e tabelas. Há medida que o volume de informação aumenta, torna-se essencial haver um planeamento para agregar e sumarizar a informação que vai “enve-lhecendo”. Como os analistas de negócio normalmente apenas exigem um grau de granularidade maior para os dados mais recentes, deve-se decrementar esse nível ao longo do tempo. Para lidar com este grande volume de dados há ainda diversas novas tecnologias a serem consideradas: bases de dados multidimensionais, novas tecnologias de indexação, ferramentas ROLAP (relational online analytical processing), ferramentas de manutenção de bases de dados distribuídas ou tecnologias que focam o paralelismo. [8]

O crescimento da utilização das aplicações de BI é algo previsível se o projecto alcançar o sucesso. O número de pessoas que acedem às bases de dados subjacentes a estas soluções podem duplicar ou triplicar anualmente, aumen-tando também o volume de dados. A consequência disto é a necessidade de actualização/compra de novo hardware, o que pode ser facilitado pelos gestores, consoante o ROI (return on investment) que adveio do aumento da utilização. [8]

O aumento em termos de hardware surge como resultado do crescimento de dados e de utilização, sendo impor-tante focar a escalabilidade da arquitectura de BI. O planeamento das necessidades deve ser feito para um horizonte temporal de 12 a 24 meses, no entanto é indispensável uma observação constante da capacidade da plataforma de BI. Quando essa capacidade deixar de ser cumprida será forçoso adicionar mais hardware para garantir que a perfor-mance do ambiente de BI se mantém em determinado nível, tomando o cuidado de verificar se há tempo suficiente para que todo o equipamento seja entregue, testado e preparado antes de ser inserido no ambiente de produção. [8]

6.6 Sub-passos na Implementação

Existe um conjunto de actividades usualmente presentes na implementação que se encontram bem definidas den-tro do âmbito de um projecto de BI, e que estão representadas na figura 7:



Figura 7 - Actividades de Implementação [8] Como se pode observar, as actividades 3 e 4 (instalação de todos os componentes das aplicações de BI e estabe-

lecimento do agendamento de produção) podem ser realizadas em paralelo. De seguida vai-se focar cada uma destas actividade em detalhe: [8]

1. Planear a implementação – define-se a data de implementação e assegura-se que todos os recursos necessários estão disponíveis. Dependendo do progresso e dificuldades que se encontrem pode-se optar por disponibilizar a apli-cação de BI de forma faseada, começando por um pequeno grupo de pessoas, e alterar se necessário a abordagem de implementação à medida que se for aprendendo com a experiência. Se a aplicação tiver algum impacto organizacio-nal deve-se ainda preparar essas mudanças organizacionais.

2. Estabelecer o ambiente de produção – inclui a preparação das bibliotecas dos programas de produção (ETL, aplicações, repositório de metadados), a criação das bases de dados de produção (BDs do repositório e de BI), a con-figuração dos níveis de acesso às bases de dados e dos níveis de acesso à execução das várias aplicações de BI por parte dos indivíduos, envolve ainda a criação de procedimentos para o grupo de operações com instruções para exe-cutar o processo ETL, o agendamento de relatórios das aplicações, a preparação de um guia de referência para o helpdesk e utilizadores das aplicações de BI e a definição dos níveis de segurança para todos os componentes.

3. Instalar todos os componentes das aplicações de BI – como o nome indica, envolve colocar os programas de ETL, de aplicação e do repositório de metadados nas suas bibliotecas de produção respectivas.

4. Estabelecer o agendamento de produção – consiste em colocar na agenda de tarefas todos os programas de ETL, de geração de relatórios ou do repositório de metadados que tenham de ser executados regularmente.

5. Carregar as bases de dados de produção – trata de colocar os dados iniciais nas BD’s de Business Intelligence, executando para isso o processo encarregue desta função, seguindo-se posteriormente o processo que carrega os dados históricos. Cuida também de carregar o repositório com metadados provenientes das várias fontes da empresa.

6. Preparar o suporte à solução – envolve o agendamento do apoio de emergência, dos backups regulares, e o estabelecimento de um plano para monitorizar a performance, o crescimento, utilização e qualidade. Trata ainda de analisar regularmente planos de capacidade para o hardware.

Em resumo, no seguimento destas actividades de implementação são gerados vários deliverables, dos quais se destacam as bibliotecas de produção dos programas ETL, aplicação e repositório de metadados, assim como as bases de dados de BI, de metadados e a documentação de produção referente ao guia de referência e procedimentos de operação já descritos anteriormente.

6.7 Papéis e Responsabilidades na Implementação

Para terminar esta abordagem à implementação deve-se referir os recursos humanos necessários a este passo, e quais são as tarefas que têm de ser desempenhadas. A tabela 3 apresenta um resumo dos papéis e responsabilidades envolvidos: [8]

Application developers

Trabalham em conjunto com a equipa de operações para mover os programas de relatórios, de interface, scripts de pesquisa e programas de apoio online para a biblioteca de produção

Application lead developer

Supervisiona as actividades de implementação no que diz respeito à aplicação de BI de acesso e análise. Está também encarregue de estabelecer a biblioteca de produção, de escre-ver os procedimentos de operação, o guia de referência e



agendar os programas de relatório da aplicação

Data mining expert Trabalha com o Database Administrator para criar/rever/manter as bases de dados de mineração de dados

Database administrator

Cria as bases de dados de produção de BI, do repositório de metadados e configura os níveis de acesso correctos. É o responsável por executar o processo inicial de carregamento da BD de BI, por agendar as actividades de manutenção, de monitorização e de rever os planos de capacidade

ETL developers Trabalham em conjunto com a equipa de operações para mover os programas ETL para a biblioteca de produção

ETL lead developer

Supervisiona as actividades de implementação no que diz respeito à aplicação de BI de ETL. Trabalha com a equipa de operações para preparar o ambiente de produção e é respon-sável por estabelecer a biblioteca do programa ETL, e de escrever os procedimentos de operação e o guia de referência no que toca a esta componente. Está ainda encarregue de agendar o processo ETL.

Meta data administrator

É o responsável por mover os programas do repositório de metadados para a biblioteca de programas de produção do repositório de metadados. Está também encarregue de correr o processo que carrega esses metadados e de agendar activida-des de monitorização da qualidade dos dados

Meta data repository developers Auxiliam o Meta Data Administrator a mover os programas do repositório para a biblioteca de programas de produção

Web developers Tem a responsabilidade de mover as páginas web e scripts necessários dos servidores locais para o servidor de produção

Web master Tem como tarefa configurar o servidor de produção, traba-lhando em conjunto com a equipa de segurança para instalar e testar a firewall e/ou outras medidas extra.

Tabela 3- Papéis e Responsabilidades na Implementação [8]

7. Conclusão

A Business Intelligence assume cada vez mais um papel de destaque nas organizações, pois quando a sua imple-mentação for bem sucedida pode proporcionar grandes vantagens competitivas à organização que adquire a capaci-dade de tomar decisões bem fundamentadas nos dados proporcionados por estas aplicações. O potencial destas solu-ções para descobrirem padrões na informação da empresa com vista a esta poder aproveitar oportunidades de negócio é outra vantagem que não pode ser descurada. Foi com o objectivo de uma organização poder alcançar estes benefí-cios que se pretendeu com este artigo introduzir a BI de uma forma conceptual e realizar uma primeira abordagem aos vários passos, recomendações e cuidados que têm de ser observados no desenvolvimento de um projecto deste tipo, especialmente no que diz respeito à implementação.



Referências

1. Wikipedia, Business Intelligence, http://en.wikipedia.org/wiki/Business_intelligence

2. Whatis.com, Business Intelligence,

http://searchdatamanagement.techtarget.com/sDefinition/0,,sid91_gci213571,00.html

3. TechRepublic, Use this architecture to structure your business intelligence solutions, http://articles.techrepublic.com.com/5100-10878_11-1032206.html

4. BitPipe, Business Intelligence Overview, http://www.bitpipe.com/data/web/bp/bi/bi_overview.jsp

5. ITtoolbox, Implementing Business Intelligence – A Readiness Checklist, http://hosteddocs.ittoolbox.com/ASRK110405.pdf

6. CIO Today, Using Data to Your Business Advantage, http://www.cio-today.com/story.xhtml?story_id=0310021UMH3C&page=1

7. Biere, M. (2003). Business Intelligence for the Enterprise, Prentice Hall PTR.

8. Moss, L. T., & Atre, S. (2003). Business Intelligence Roadmap: The Complete Project Lifecycle for

Decision-Support Applications, Addison Wesley

ficha de caracterização de trabalho - student.dei.uc.ptjpguerra/gsi/implementacao de...

Documents