IETEC – INSTITUTO DE EDUCAÇÃO TECNÓLOGICA
PÓS-GRADUAÇÃO LATO SENSU
GESTÃO E TECNOLOGIA DA INFORMAÇÃO
Business Inteligence: O Papel do Data Warehouse no Processo de
Suporte a Tomada de Decisão
Alexandre Antônio de Vasconcelos,
André Caribé Pinheiro,
Ivani Aparecida Alves,
Rafael Tardelli Pacheco dos Santos,
Wantuil Silva
Belo Horizonte, Setembro de 2010
2
Informações sobre os autores:
Nome: Alexandre Antônio de Vasconcelos.
Titulação Acadêmica: Tecnólogo em Análise de Redes.
Empresa/Instituição: Grupo NC.
E-mail: [email protected]
Nome: André Caribé Pinheiro.
Titulação Acadêmica: Engenheiro Eletricista.
Empresa/Instituição: FIDENS Engenharia SA
E-mail: [email protected] ou [email protected]
Nome: Ivani Aparecida Alves.
Titulação Acadêmica: Administradora de Empresas.
Empresa/Instituição: Maxis Informática Ltda.
E-mail: [email protected]
Nome: Rafael Tardelli Pacheco dos Santos.
Titulação Acadêmica: Bacharel em Ciência da Computação
Empresa/Instituição: Teradata
E-mail: [email protected]
Nome: Wantuil Silva.
Titulação Acadêmica: Tecnólogo em Redes.
Empresa/Instituição: Consite Tecnologia.
E-mail: [email protected]
3
Lista de Figuras
Figura 1: Estrutura do BI ............................................................................................. 8
Figura 2: Exemplo esquema estrela .......................................................................... 13
Figura 3: Exemplo esquema floco de neve ............................................................... 14
Figura 4: Exemplos de tabelas padronizadas e não padronizadas ........................... 15
Figura 5: Valor pontual .............................................................................................. 17
Figura 6: Plano .......................................................................................................... 17
Figura 7: Cubo........................................................................................................... 18
Figura 8: Representação dos principais conjuntos dimensionais – Modelo
dimensional hierarquizado. ....................................................................................... 19
Figura 9: Representação dos principais conjuntos dimensionais – drill-down, drill-up,
drill-across e drill-through .......................................................................................... 20
Figura 10: Estágios de um Active Data Warehousing ............................................... 21
Figura 11: Janelas ..................................................................................................... 28
Figura 12: Sistemas fonte. ........................................................................................ 29
Figura 13: Sistemas fonte. ........................................................................................ 31
Figura 14: Quadro de evolução do ambiente. ........................................................... 32
4
Sumário
1.
Resumo ................................................................................................................ 6
2.
Introdução ............................................................................................................ 7
3.
Referencial Teórico .............................................................................................. 8
3.1.
Business Intelligence (BI) ............................................................................... 8
3.2.
Sistema Transacional (OLTP – On-line Transaction Processing) .................. 9
3.3.
ETL – Extração, Transformação e Carga (Load) de Dados ......................... 10
3.4.
Data Warehouse (DW) ................................................................................. 11
3.5.
Data Marts (DM) ........................................................................................... 11
3.6.
Modelagem Dimensional de Dados ............................................................. 12
3.7.
Sistema OLAP (OLAP – On-line Analytical Processing) .............................. 15
3.8.
Operadores Dimensionais ............................................................................ 16
3.8.1. Valor Pontual (Ponto) ............................................................................ 16
3.8.2. Plano (Slicing)........................................................................................ 17
3.8.3. Cubo (Dicing) ......................................................................................... 18
3.8.4. Pivoteamento (Rotação) ........................................................................ 18
3.8.5. Drill-Down e Drill-Up (Roll-up)................................................................ 19
3.8.6. Drill-Across ............................................................................................ 19
3.8.7. Drill-Through .......................................................................................... 20
3.9.
Evolução dos Data Warehouses .................................................................. 20
3.9.1. Estágio 1: Reportando ........................................................................... 21
3.9.2. Estágio 2: Analizando ............................................................................ 22
3.9.3. Estágio 3: Predizendo............................................................................ 22
3.9.4. Estágio 4: Operacionalizando ................................................................ 22
5
3.9.5. Estágio 5: Active Data Warehousing (ADW).......................................... 23
4.
Pesquisa ............................................................................................................ 25
4.1.
Entendendo a natureza dos negócios .......................................................... 25
4.2.
Motivações para o projeto Inicial .................................................................. 26
4.3.
Implementação ............................................................................................. 27
4.4.
Active Data Warehousing ............................................................................. 30
4.5.
Retorno sobre Investimento ......................................................................... 32
5.
Conclusões ........................................................................................................ 34
6.
Referências Bibliográficas .................................................................................. 35
6
1. RESUMO
Com a globalização atual do mercado e a aplicação de metódos cada vez mais
agressivos para redução de custos, como terceirização e procura de fornecedores
externos, as empresas vêm encontrando uma concorrência cada vez mais acirrada,
e neste cenário não é possível ficar imóvel as mudanças, é preciso sempre inovar, e
para isto o conhecimento e a análise da informação se transformaram em
ferramentas chave. Utilizada cada dia mais pelas empresas para auxiliar a este fim
está a tecnologia de Business Inteligenge ou Inteligência de Negócios, que se
baseia no processo analítico de informações históricas oriundas de diversas fontes
que são armazenadas em um Data Warehouse (DW). Este, podendo ser
considerado o coração da tecnologia, precisa ter seus conceitos bem entendidos
para que seus processos sejam bem desenvolvidos e implementados. Um projeto de
DW bem realizado é a chave para o sucesso do processo de suporte a tomada de
decisão. Para mostrar o valor do DW neste processo serão apresentados seus
conceitos chave e um estudo de caso bem sucedido, em que a qualidade alcançada
na execução dos processos da empresa e o retorno sobre o investimento puderam
ser mensurados e apresentados.
Palavras chave: Análise da Informação, Tomada de Decisão, Business Inteligence,
Data Warehouse.
7
2. INTRODUÇÃO
A utilização de processos de Business Inteligence, cujo conceito segundo Barbieri
(2001) “é a utilização de várias fontes de informação para se definir estratégias de
competitividade nos negócios da empresa”, vem se tornando cada vez mais comum.
Fazendo uma analogia simples pode-se considerar o Data Warehouse (DW), ou
Armazém de Dados, que é um sistema gerenciador de banco de dados (SGBD)
destinado a sistemas de apoio a decisão, como o coração deste processo. E nele
onde serão armazenadas os dados oriundos de fontes heterogêneas em estruturas
lógicas dimensionais, o que possibilita o seu processamento analítico por
ferramentas especiais (BARBIERI, 2001). É a análise destes dados que agregará
valor a informação e guiará os negócios, portanto o cuidado no tratamento dos
dados, o objetivo que se pretende alcançar com isto e a própria análise em si devem
ser rápidas e bem realizadas.
Para isto é preciso contar com um sistema que exerça a função de suportar a
tomada de decisões. Que forneça uma resposta rápida, com informação precisa
para que a empresa aproveite as oportunidades estando no lugar correto, no
momento oportuno e com a informação correta. Para alcançar este patamar não
pode-se contar apenas com a tecnologia, mas também com técnicas de modelagem
bem realizadas, juntamente com um projeto e objetivos bem estruturados.
Como objetivos deste trabalho serão apresentadas os conceitos da tecnologia de
Data Warehousing, como modelo dimensional, processamento transacional e
analítico, operadores dimensionais e a evolução da tecnologia de DW, ou seja, todos
os elementos que devem ser estudados, projetados e bem implementados para que
seja possível alcançar o sucesso de um projeto de Busines Inteligence. Também
será apresentado um estudo de caso de uma empresa real que mostra como uma
implementação bem realizada de um Data Warehouse pode melhorar os processos
de tomada de decisão e também o retorno sobre o investimento realizado.
8
3. REFERENCIAL TEÓRICO
3.1. BUSINESS INTELLIGENCE (BI)
A história do Business Intelligence que conhecemos hoje, começa na década de 70,
quando alguns produtos de BI foram disponibilizados para os analistas de negócio.
“O grande problema era que esses produtos exigiam intensa e exaustiva
programação, não disponibilizavam informação em tempo hábil nem de forma
flexível, e além de tudo tinham alto custo de implantação” (SERAIN, 2010). Com o
surgimento dos bancos de dados relacionais, dos PC's e das interfaces gráficas
como o Windows, aliados ao aumento da complexidade dos negócios, começaram a
surgir os primeiros produtos realmente direcionados aos analistas de negócios, que
possibilitavam rapidez e uma maior flexibilidade de análise.
- Planejamento
- Estratégia Corporativa
- Scorecards
- Relatórios
- Análise e Datamining
- Data Warehouse
- Data Marts
- Cubos
- Integração de Dados
- ETL
- Dados Transacionais
- Outras Fontes de Dados
Figura 1: Estrutura do BI
Fonte: do autor
9
Business Intelligence, cujo conceito de forma geral “é a utilização de varias fontes de
informação para se definir estratégias de competitividade nos negócios da empresa”
(BARBIERI, 2001). Atualmente várias empresas possuem muitos dados, mas
poucas informações. Devido ao volume sempre crescente desses dados e da forma
que eles se encontram distribuídos na empresa, a dificuldade de se extrair
informações gerenciais para a tomada de decisões é muito grande. Para Microsoft
Business Intelligence “é uma disciplina que, junto com suas ferramentas
correspondentes, são o centro da análise da informação para a correta tomada de
decisões, permitindo que a empresa atinja seus objetivos de negócio” (MICROSOFT,
2010).
3.2. SISTEMA TRANSACIONAL (OLTP – ON-LINE TRANSACTION
PROCESSING)
A Microsoft define os sistemas OLTP como “os sistemas que capturam as
transações de um negócio e as mantêm em estruturas relacionais chamadas Banco
de Dados” (MICROSOFT, 2010). As principais características desses sistemas são
de realizar transações em tempo real, serem responsáveis pela manutenção dos
dados (acrescentando, atualizando e excluindo), serem otimizados de forma a
validar a entrada dos dados rejeitando-os caso não atendam às regras de negócio e
possuem capacidade limitada na busca de informações para tomada de decisões.
Normalmente, para o desenho de um sistema OLTP é definido um modelo de
Diagrama de Relação de Entidades (DRE). Um DRE é uma representação da
realidade através de um esquema gráfico que contém os seguintes elementos:
• Entidades: Uma Entidade é um tipo de objeto que pode ser identificado de
forma única por algum meio. Este objeto é traduzido para a estrutura física de
um banco de dados como uma tabela;
• Atributos: As características particulares que diferenciam as Entidades são
denominadas Atributos;
10
• Relações (ou Relacionamentos): vínculos existentes entre as tabelas que
servem para garantir a integridade referencial;
Para conseguir esquematizar um DRE, deve ser realizado um processo de
normalização baseado nas Formas Normais, que também garante uma otimização
do espaço utilizado no disco.
3.3. ETL – EXTRAÇÃO, TRANSFORMAÇÃO E CARGA (LOAD) DE
DADOS
Os dados que alimentam um Data Warehouse são resultantes de diferentes fontes;
estas fontes são diferentes sistemas OLTP que a empresa possui, geralmente não
homogêneos e não concordando necessariamente com o que é necessário, sendo
necessário realizar todas as adaptações pertinentes (MICROSOFT, 2010).
Ao reunir dados dos diferentes sistemas deve ser definida uma norma única para o
Data Warehouse e realizar as transformações necessárias em cada caso.
Basicamente devem ser realizadas as tarefas de estabelecer as regras que serão
utilizadas para realizar a transformação, detectar as inconsistências que podem
ocorrer ao extrair dados de diferentes fontes e planejar cuidadosamente e com
detalhes a transformação dos dados, que ofereçam como resultado final conjuntos
de dados consistentes. Nas transformações devem-se criar convenções únicas para
codificações (exemplo: sexo M/F ou 0/1 ou “masculino”/”feminino”), unidade de
medida dos atributos (exemplo: litros ou metros cúbicos ou decilitros) e formatos
(exemplo: datas nos formatos “dd/mm/aaaa” ou “mm/dd/aaaa” ou “aaaa/mm/dd”).
Pode ser necessário também armazenar o conteúdo de várias colunas de uma
tabela em uma única coluna (Exemplo: endereço ou nome e sobrenome) ou
armazenar o conteúdo de uma coluna em varias outras colunas (Exemplo: sistemas
mais antigos costumavam colocar o tipo e número de documento no mesmo campo
da tabela).
11
3.4. DATA WAREHOUSE (DW)
Carlos Barbieri define o Data Warehouse (DW) “como um banco de dados,
destinados a sistemas de apoio à decisão e cujos dados foram armazenados em
estrutura lógica dimensionais, possibilitando o seu processamento analítico por
ferramentas especiais (OLAP e Mining)” (BARBIERI, 2001). O Data Warehouse
possibilita a análise de grandes volumes de dados, coletados dos sistemas
transacionais. Por definição, os dados em um Data Warehouse não são voláteis, ou
seja, eles não mudam, exceto quando é necessário fazer correções de dados
previamente carregados. Os dados então são somente para leitura e não podem ser
alterados. As informações são armazenadas em estruturas multidimensionais,
calculando previamente todas as combinações de todos os níveis de todas as
aberturas de análise. É de forma simples, um produto cartesiano que armazena
todas as combinações.
3.5. DATA MARTS (DM)
O termo Data Mart significa “depósitos de dados que atende a certas áreas
específicas da empresa e voltados (também) para o processo decisório gerencial.
Ambos podem ser definidos como espécies do mesmo tipo, ficando a diferença entre
os dois centrada no escopo do projeto e nos limites de suas abrangências”
(BARBIERI, 2001).
A Microsoft define Data Mart como “armazéns de dados com informações de
interesse particular para um determinado setor da empresa” e Data Warehouse
como “o conjunto de armazéns de dados particulares (Data Mart) com informação de
interesse para a empresa em geral” (MICROSOFT, 2010).
12
Data Marts podem ser lógicos, quando represntam visões dentro de uma fonte única
de dados, ou físicos, quando são independentes de outros Data Marts da
corporação.
3.6. MODELAGEM DIMENSIONAL DE DADOS
O alvo das técnicas de Business Intelligence está exatamente na definição de regras
e técnicas para determinar os aspectos adequados destes pacotes de dados,
objetivando agrupá-los em depósitos estruturados de informações. A modelagem de
dados foi um artefato de verdadeira importância no desenvolvimento de estruturas
capazes de serem implantadas e entendidas pelos gerenciadores de bancos de
dados. Mas com a necessidade que surge do aspecto competitivo e busca de
diferenciais de negócio fez com que este método se tornasse inadequado. As suas
características de campos por tabelas normalizadas se mostram imperfeitas para os
processamentos das visões dimensionais.
A estrutura dimensional modifica a ordem da distribuição de campos das tabelas,
possibilitando uma estrutura voltada para os diversos pontos de entradas as
chamadas dimensões. Com isso os dados estarão em uma forma quase estrelar,
onde varias dimensões estão relacionadas com algumas poucas tabelas, criando
uma notação mais objetiva. O produto da modelagem Dimensional é um modelo
conceitual dimensional, formado por tabelas Fato e tabelas Dimensão.
“As tabelas Fato servem para armazenar medidas numéricas associadas a eventos
de negócio. Uma tabela Fato contém vários fatos, correspondentes a cada uma de
suas linhas. Cada fato pode armazenar um ou mais medidas numéricas, que
constituem os valores objetos da análise dimensional. Possuem como chaveprimária, normalmente um campo multi-key, formado pelas chaves-primárias das
dimensões que com ela se relacionam. Normalmente armazenam muito mais linhas
que as tabelas Dimensão, e merecem cuidado especial em função ao seu alto
volume. Contém dados normalmente aditivos (manipulados por soma, média, etc.) e
relativamente estáticos. As tabelas Dimensão representam entidades de negócios e
constituem as estruturas de entradas que servem para armazenar informações como
13
tempo, geografia, produto, cliente, etc. As tabelas Dimensão têm uma relação 1:N
com a tabela Fato, e possuem um número significativamente menor de linhas do que
as tabelas Fato. Possuem múltiplas colunas de informação, algumas das quais
representam sua hierarquia. Apresentam sempre uma chave primária, que lhes
confere unicidade, chave essa que participa das tabelas Fato, como parte da sua
chave múltipla. Devem ser entendidas como as tabelas que realizam os filtros de
valores aplicados na manipulação dos fatos e por onde as consultas entram no
ambiente do DW/DM.” (BARBIERI, 2001).
Para facilitar a análise, o DW/DM tem seus dados organizados em uma estrutura
chamada estrutura estrela. Essa estrutura é formada por uma tabela central (tabela
de Fatos) e um conjunto de tabelas organizadas ao seu redor (tabelas de
Dimensões). São características desse esquema:
• O centro da estrela é a tabela de Fatos;
• As pontas da estrela são as tabelas de Dimensões;
• Cada esquema está formado por apenas uma tabela de Fatos;
• Geralmente é um esquema totalmente não normalizado e pode estar
parcialmente normalizado nas tabelas de Dimensões.
Na Figura 2 é apresentada uma estrutura estrela considerando a necessidade de
analisar como evolui a Admissão de Pacientes (Fato) por serviço, pacientes e região
geográfica (Dimensões) ao longo do tempo.
Figura 2: Exemplo esquema estrela
Fonte: do autor
14
A estrutura floco de neve é uma variação da estrutura estrela onde alguma ponta da
estrela explode em mais tabelas. Nesta estrutura, as tabelas de Dimensão floco de
neve estão normalizadas para eliminar redundância de dados.
Diferente da estrutura estrela, nesta estrutura os dados das dimensões são
distribuídos em múltiplas tabelas. Como vantagem destaca-se a economia de
espaço no armazenamento em disco, porém com um aumento na quantidade de
tabelas.
As características a seguir são parte de uma estrutura floco de neve:
• A Dimensão é normalizada;
• Os diferentes níveis estão armazenados em tabelas separadas;
• Verifica-se economia de espaço.
Na Figura 3Figura 2 é apresentado um exemplo onde a dimensão “Região
Geográfica” apresenta uma estrutura floco de neve.
Figura 3: Exemplo esquema floco de neve
Fonte: do autor
15
Na Figura 4 é apresentado um exemplo de tabela normalizada e tabela não
normalizada. Na tabela normalizada os dados “nome do país” e “nome do estado”
aparecerão apenas uma vez nas tabelas “País” e “Estado”, respectivamente,
enquanto na tabela não normalizada, ocorrerão redundâncias de informações, pois
os dados de País e Estado serão repetidos para cada Cidade.
Tabela Padronizada
Tabela não Padronizada
Cidade
Cidade1
ID_Cidade
ID_Estado
Cidade
ID_Pais
Pais
ID_Estado
Estado
ID_Cidade
Cidade
Estado
ID_Estado
Estado
ID_Pais
Estado1
ID_Pais
Pais
Figura 4: Exemplos de tabelas padronizadas e não padronizadas
Fonte: do autor
3.7. SISTEMA
OLAP
(OLAP
–
ON-LINE
ANALYTICAL
PROCESSING)
Os sistemas OLAP (On-Line Analytical Processing, ou Processamento Analítico Online) oferecem uma alternativa aos sistemas transacionais, proporcionando uma
visão dos dados orientada à análise, além de uma navegação rápida e flexível
(MICROSOFT, 2010).
As principais características da tecnologia OLAP são:
16
• Bancos de dados com um esquema otimizado para que os resultados das
consultas sejam entregues rapidamente;
• Os cubos OLAP armazenam vários níveis de dados formados por estruturas
altamente otimizadas que atendem às expectativas de negócio da empresa;
• Um sistema OLAP está preparado para realizar relatórios complexos de uma
forma simples;
• O OLAP proporciona uma visão multidimensional dos dados. Os cubos
oferecem uma visão multidimensional dos dados que vai além da análise de
duas dimensões, oferecida por uma simples planilha de cálculo utilizada como
tal;
• Os usuários podem modificar facilmente as filas, as colunas e as páginas nos
relatórios do OLAP, sendo possível visualizar a informação da forma que seja
mais conveniente para análise;
3.8. OPERADORES DIMENSIONAIS
Após ter apresentado as técnicas de modelagem dimensional e o conceito inicial de
OLAP, é importante realizar uma pequena introdução ao conceito de Operadores
Dimensionais, que são técnicas de manuseio dos dados dimensionais que serão
usualmente utilizadas em consultas OLAP.
3.8.1. VALOR PONTUAL (PONTO)
Este valor apresenta a interseção de valores da tabela fato em relação aos três
eixos, ou dimensões.
17
Figura 5: Valor pontual
Fonte: do autor
3.8.2. PLANO (SLICING)
O plano representa uma fatia do Cubo, em que duas dimensões variam com uma
outra dimensão fixa.
Figura 6: Plano
18
Fonte: do autor
3.8.3. CUBO (DICING)
O conceito de Dicing apresenta os valores com todas as dimensões variando.
Figura 7: Cubo
Fonte: do autor
3.8.4. PIVOTEAMENTO (ROTAÇÃO)
No pivoteamento, ou rotação, ocorre a mudança dos eixos das dimensões para fins
de visualização. Deve-se lembrar que para fins de representação só foram
mostradas trê dimensões, mas um modelo real pode possuir n dimensões.
19
3.8.5. DRILL-DOWN E DRILL-UP (ROLL-UP).
O conceito de Drill-Down está relacionado com a ação de sair do topo de uma
hierarquia em direção ao dado mais detalhado, como por exemplo mudar a consulta
do total de vendas de determinado produto por mês para o total de vendas por dia.
Drill-Up representa o caminho inverso (Figura 8).
Figura 8: Representação dos principais conjuntos dimensionais – Modelo
dimensional hierarquizado.
Fonte: Barbieri, 2001, p. 42.
3.8.6. DRILL-ACROSS
Trata da iteração entre diferentes tabelas fato. Isso só será possível se ambos
possuírem alguma dimensão em comum.
20
Figura 9: Representação dos principais conjuntos dimensionais – drill-down,
drill-up, drill-across e drill-through
Fonte: Barbieri, 2001, p. 43, 44.
3.8.7. DRILL-THROUGH
Referente à necessidade de obter informações em um nível de detalhes menor do
que o expressado na tabela fato. Normalmente obtido com consultas diretas nas
tabelas do modelo relacional, quando estas também são carregadas do DW (Figura
9).
3.9. EVOLUÇÃO DOS DATA WAREHOUSES
Atualmente está acontecendo uma evolução da informação nos ambientes de DW.
Mudanças nos requerimentos de negócios demandam que as tecnologias de DW
realizem terefas mais rapidamente. Data Warehouses estão passando de sistemas
que processam consultas analíticas para sistemas que realizam processos
operacionais críticos para os negócios, suportando CRMs, operações de marketing e
decisões em tempo real. A Teratada (2008), líder no mercado de DW, define um
21
Active Data Warehouse como um “conjunto integrado e logicamente consistente de
dados atualizados detalhados disponibilizados para o suporte a decisão estratégico,
tático e guiado por eventos.” Também define estas decisões tomadas no
gerenciamento do dia-a-dia como Suporte a Decisão Tática, e apresenta os estágios
que devem ser alcançados para se atingir o nível de um Active Data Warehouse, ou
seja, um DW que suporta a tomada de decisão em tempo real (Figura 10).
Figura 10: Estágios de um Active Data Warehousing
Fonte: Adaptação de TERADATA (2008)
3.9.1. ESTÁGIO 1: REPORTANDO
O estágio inicial tipicamente foca em relatórios de uma única fonte para guiar o
suporte à decisão através das fronteiras funcionais ou de produtos/serviços.
Questões normalmente são conhecidas antecipadamente, como por exemplo um
relatório de vendas semanal.
22
3.9.2. ESTÁGIO 2: ANALIZANDO
O foco está no porque algo aconteceu, como por exemplo, na resposta do por que
as vendas foram baixas ou no descobrimento de padrões dos hábitos de compra dos
clientes. Usuários realizam análises Ad Hoc, Slicing e Dicing em dados detalhados.
Questões não são conhecidas antecipadamente como a soma das vendas de
determinada semana por exemplo.
3.9.3. ESTÁGIO 3: PREDIZENDO
Análises pesadas e sofisticadas são realizadas no ambiente para trazer informações
preditivas sobre o que acontecerá em seguida nos negócios. Este tipo de informação
irá auxiliar o gerenciamento pró-ativo da estratégia da organização. Este estágio
requer ferramentas de Data Mining e a construção de modelos preditivos usando
informações históricas detalhadas. Como exemplo os analistas podem criar um
modelo da geografia dos clientes para realizar marketing estratégico.
3.9.4. ESTÁGIO 4: OPERACIONALIZANDO
Este estágio provê acesso imediato à informação para os tomadores de decisão da
empresa. Estágios de 1 a 3 focam em decisões estratégicas dentro da organização.
O estágio 4 foca no suporte a decisão tático. Suporte a decisão tática não é focada
no desenvolvimento da estratégia corporativa, mas sim no suporte as pessoas nos
campos que a executam. Exemplo:
• Gerenciamento de inventório com substituições just-in-time;
• Agendamento e roteamento de entrega de pacotes;
• Alteração de campanhas com base em resultados correntes.
23
3.9.5. ESTÁGIO 5: ACTIVE DATA WAREHOUSING (ADW)
Quanto maior o papel do ADW nos aspectos operacionais de suporte a decisão,
maior é o incentivo dos negócios para a automação de processos decisórios. Podese automatizar a tomada de decisão quando um cliente interage com um site web.
CRM interativo em um site disponibilizado para o cliente ou iterações com um caixa
eletrônico podem disparar decisões para otimizar o relacionamento com o cliente
através de oferta de produtos, preços especiais, entrega de envio de informações
específicas e assim por diante. Com o desenvolvimento da tecnologia, mais e mais
decisões são tomadas pelo acionamento de gatilhos (triggers) baseados em
eventos, como por exemplo, determinar a melhor oferta para um cliente específico
baseada num evento em tempo real, como um depósito significante em um caixa
eletrônico.
Para suportar este novo tipo de decisão dos negócios de hoje em dia, é preciso mais
do que apenas uma abordagem estratégica na implementação de um Data
Warehouse. É necessário um uso mais efetivo da informação para decisões que
podem ser tomadas centenas de vezes durante o dia
O
conceito
de
Active
Data
Warehouse
surgiu
com
a
necessidade
do
armazenamaneto e disponibilização em tempo quase real de dados detalhados para
análise do negócio e tomada de decisião (TERADATA, 2008). Estes processos são
suplementares as funcionalidades típicas de um DW. Por exemplo, o mix típico de
trabalho processado em um ambiente de DW continua contendo consultas analíticas
(OLAP), mas é expandido para processar consultas táticas curtas, carga de dados
em segundo-plano (background) e possivelmente atualizações baseadas em
eventos, tudo ao mesmo tempo. O volume de dados e a concorrência de usuários no
ambiente pode com isto crescer muito acima das expectativas. Isto faz com que o
SGBD tenha que possuir recursos tecnológicos para realizar uma administração
eficiente dos processos em execução já que consultas curtas em dados detalhados,
apesar de não serem importantes em uma análise analítica agora podem ser muito
importantes, pois podem disparar um evento de compra de ações na bolsa de
24
valores por exemplo. Com isto os SGBDs utilizados para processos de Data
Warehouse no mercado têm que estar cada vez mais preparados para lidar com os
seguintes itens:
• Cargas de trabalho mistas (consultas táticas e estratégicas) para aplicativos
de missão crítica;
• Grandes volumes de dados detalhados;
• Grande número de usuários concorrentes.
25
4. PESQUISA
Para mostrar o valor que um projeto de BI pode agregar aos negócios pelo seu
poder de suporte a decisão, será apresentado um estudo de caso real de
implementação de um Data Warehouse em uma compania aérea de grande porte, e
o retorno obtido com este projeto (TERADATA, 2010).
A compania em questão é a Continental Airlines. A quinta maior compania aérea
americana e uma das maiores do mundo, que no ano de 2010 anunciou fusão com
outra grande compania aérea americada, a United Airlines. A continental opera vôos
para localidades nas Américas, Europa, Ásia e Oceania, transportando mais de 50
milhões de passageiros por ano.
4.1. ENTENDENDO A NATUREZA DOS NEGÓCIOS
A Continental, hoje uma empresa conceituada com mais de 49.000 empregados,
passou por sérias dificuldades nos anos 80, o que levou a uma completa
reformulação de suas estratégias de negócios. Como ponto chave desta nova
estratégia, criou um plano divido em 4 partes interrelacionadas que lidam com
produtos, finanças, mercado, pessoas e que guiam a empresa até os dias de hoje:
• Voar para vencer.
• Entender quais produtos os clientes desejam e quanto desejam pagar por
eles.
• Financiar o Futuro
• Gerenciar custos e caixa para que a compania continue a operar
• Fazer da rentabilidade uma realidade
• Levar os clientes em seus destinos com segurança, no tempo esperado e
com sua bagagem.
• Trabalhar Juntos
26
• Criar uma cultura em que pessoas tenham satisfação com o trabalho.
Em meados dos anos 90 a empresa já estava num patamar muito diferente do
passado, mas para continuar se transformando e se adaptando as mudanças de
mercado, assim como outras empresas, o suporte da área de TI se tornou
fundamental.
Em 1995 a empresa possuia apenas um relatório de performance diário, fornecido
por empresa terceirizada, sem detalhes financeiros e com dados detalhados
históricos inacessíveis. Cada área possuia seu próprio gerenciamento dos dados, o
que os tornava inconcistentes, e não existia estrutura corporativa que permitisse a
usuários importantes, acesso rápido as informações chave dos negócios da
empresa. Com a visão de que a compania deveria disponibilizar acesso rápido a
toda a informação de que os funcionários necessitavam, e acreditando que com a
informação certa, as pessoas não apenas tomariam melhores decisões mas também
descobririam novas oportunidades, a direção da empresa decidiu investir num Data
Warehouse corporativo (EDW – Enterprise Data Warehouse), construído e
administrado internamente.
4.2. MOTIVAÇÕES PARA O PROJETO INICIAL
A etapa incial da implementação, partiu da área de Gestão da Receita (Revenue
Assurance). A Análise da receita de um vôo era restrita a demanda de apenas um
trecho, os seja, a empresa não conseguia rastrear um itenerário da origem ao
destino se houvesse mais de uma escala. Isto ocorria por não haver acesso à
informação integrada detalhada como agendamento, reservas, dados do cliente,
inventório, tabelas de valor de mercado, etc. Os dados históricos eram inferiores a
um ano, portanto análises de tendências eram ineficazes. Devido a estas
particularidades esta área foi implementada no DW como o primeiro Data Mart da
companhia.
Um item importante na continuidade da expansão do Data Warehouse, foi a criação
de uma equipe de Marketing de Relacionamento com os Clientes (Customer
Relationship Marketing). Até a implementação do DW, não era possível determinar
27
quão valiosos os clientes eram e como predizer ou influenciar seu comportamento.
Quando um cliente entrava em contato com o setor de vendas de passagens, não
havia como os atendentes saberem se era um cliente ocasional ou um cliente
especial, nem mesmo informações sobre agendamentos ou histórico da bagagem. A
informação era limitada e muitas vezes incorreta.
A implementação da gestão da receita juntamente com o relacionamento do cliente
começaram a mostrar o valor do EDW, valores que dependendo do planejamento e
implementação do projeto podem ser difíceis de serem percebidos, portanto como
era de se esperar o projeto começou a crescer
4.3. IMPLEMENTAÇÃO
Para suportar o ambiente do Data Warehouse foi escolhido o SGBD Teradata, líder
de mercado neste segmento. Um ambiente inical de 8TB, suportando 1292 usuários
que acessam 42 áreas e 29 aplicações.
O primeiro Data Mart implementado, como visto anteriormente, foi o de gestão da
receita. Para este trabalho, após um grande esforço de melhoria na qualidade dos
dados, como o tratamento da entrada de informações nos aplicativos, as principais
tabelas dos sistemas fonte foram mapeadas e carregadas no DW em sua forma
normalizada. O modelo dimensional era criado e mantido carregado para algumas
consultas frequentes, para fins de desempenho, ou apenas criado e carregado
dinamicamente por meio de tabelas temporárias para análises Ad Hoc. Este tipo de
recurso economiza tempo devido aos dados normalizados estarem carregados no
DW.
Após a implementação do primeiro Data Mart e dos ganhos percebidos, o ambiente
começou a evoluir.
Dados de 25 sistemas operacionais internos e de duas fontes externas passaram a
ser carregados no ambiente. Para utilizar estes dados um grande projeto de ETL
teve de ser realizado. Mais uma vez os dados foram avaliados a fim de garantir sua
qualidade ao serem carregados do DW.
28
Algumas fontes disponibilizavam os dados para serem carregados quase em tempo
real, funcionalidade permitida pelo software Tpump do Teradata, que permite que se
estipule uma letência no carregamento, colocando assim o mínimo de travas
necessários nas tabelas alvo, a fim de permitirem que análises possam rodar sem
impactos durante as cargas. Já alguns sistemas disponibilizavam os dados para
serem carregados no modo Batch. Estas abordagens foram baseadas nas
capacidades dos sistema fonte para disponibilização dos dados e nos requerimentos
dos negócios para atendimentos de metas de tempo. Para separar os dados Batch
das consultas de usuários, foram criadas duas janelas, a de consulta (User Window)
e de carga (Batch Window). O SGBD utilizado pode gerênciar os pesos e restrições
a serem aplicados de acordo com a janela.
Janela
Usuário
Batch
(User)
(Carga)
08:00
- 20:01
Período 20:00
07:59
Figura 11: Janelas
Fonte: dados da pesquisa
-
29
Alguns dos principais sistemas fonte podem ser vistos na figura a seguir.
Sistemas fonte
Schedules
Inventory
Reservations
Airline tickets
Airline revenue flown information
SOCC(Systems
Operation
Coordination Center)
One Pass (frequent flyer program)
Customer profiles and demographics
Aircraft maintenance
Alliance data
Employee and crew payroll
Customer care
Figura 12: Sistemas fonte.
Fonte : dados da pesquisa
Com a inclusão de mais Data Marts, mais aplicações foram desenvolvidas, entre
elas:
• Gerenciamento de Receita: Provê projeções de receita em tempo real para
qualquer vôo baseado em dados detalhados. Com isto decisões de preço e
agendamento podem ser tomadas e a associação entre rotas e aeronaves
pode ser otimizada.
30
• Customer Relationship Management: Provê uma visão única e integrada de
cada cliente, apresentando com isto uma visualização apurada e atualizada
da importância de cada cliente.
• Flight Management Dashboard: Rastreamento de cada vôo e mapeamento
dos vôos atrasados, informação base para decisões que influenciam
diretamente na satisfação dos clientes e no rendimento da compania.
• Detecção de Fraude: Identifica reservas não tarifadas e comprimento de
contratos, assim como reservas suspeitas e transações de bilhetes.
4.4. ACTIVE DATA WAREHOUSING
Disponibilizar a informação em tempo real foi uma peça chave na estratégia dos
negócios da empresa. Esta decisão veio do fato de que a Continental percebeu que
se os dados operacionais tivessem mesmo que um dia de “idade”, situações críticas
não poderiam ser analizadas e encaminhadas para as áreas responsáveis no
decorrer do dia. Clientes especiais não poderiam ser identificados e tratados como
deveriam para que continuassem leais a compania e aos negócios. Respostas a
atrasos e novas reservas de vôos de conexão não poderiam ser feitas rápido o
suficiente. Aviões com muitos lugares vagos poderiam decolar enquando
passageiros poderiam ser impedidos de embarcar devido à overbooking. Com
informações atualizadas (quase) em tempo real, muitos destes problemas logísticos
e operacionais poderiam ser resolvidos a tempo.
Graças a esta visão a arquitetura de demanda do ambiente de DW foi planejada
desde as primeiras fases de design na introdução do ambiente. Processos de ETL
foram planejados, automatizados e monitorados por uma equipe de 15 pessoas
especialistas em TI.
Em meados de 2001 os dados em tempo real foram finalmente disponibilizados ao
DW para todas as aplicações vistas anteriormente. Enquanto isto consultas
estratégicas utilizando dados históricos também eram utilizadas. Na Figura 13 podese observar uma visão macro do ambiente de DW.
31
Figura 13: Sistemas fonte.
Fonte: dados da pesquisa
Devido à importância que o DW passou a ter para a empresa foi decidido que o
ambiente passasse a operar na escala 24x7 (24 horas, 7 dias da semana) com
recursos de alta disponibilidade como redundância de servidores para evitar
paradas. Na Figura 14 pode-se visualizar a evolução do ambiente.
32
Ano
1998
2001
2010
Usuários
45
968
1292
Tabelas
754
5851
16226
Marts)
11
33
42
Aplicações
0
12
29
Equipe DW
9
15
15
Áreas
(Data
Figura 14: Quadro de evolução do ambiente.
Fonte: dados da pesquisa
4.5. RETORNO SOBRE INVESTIMENTO
Uma das terafas mais complicadas em projetos de TI é a parte de avaliação do
Retorno sobre o Investimento realizado (ROI – Return Over Investment). Muitas
vezes
é
possível
obter
uma
percepção
de
melhoria
com
determinada
implementação, seja ela na velocidade com que os processos são executados ou na
própria organização dos mesmos, mas dependendo de sua natureza, a tarefa de
mensurar esta percepção em valores exatos é árdua e muitas vezes até impossível.
Isto se deve ao fato de normalmente não possuirmos um cenário bem controlado
antes da implementação ou até mesmo devido ao fato da própria empresa não
realizar este levantamentamento após a implementação.
Esta dificuldade torna-se um pouco menos árdua, ou pelo menos um pouco mais
precisa quanto a implementação do projeto de BI na emresa desta pesquisa, devido
ao fato das informações táticas ou estratégicas, afetarem em tempo real os
processos da empresa, como por exemplo, na distribuição de passageiros entre as
aeronaves.
33
Devido a esta característica, e também ao esforço realizado para isto, foi possível
mapear e estipular na Continental Airlines, o retorno sobre o investimento realizado
no projeto de BI, com destaque especial para os itens apresentados a seguir:
• Economia de U$ 20 milhões em capital e de U$ 15 milhões em utilização de
Data Centers.
• Economia anual de U$ 31 milhões em operações do negócio como resultado
direto da utilização do EDW.
• Aumento de receita estimado em U$ 40 milhões em 2002 devido as novas
aplicações de Gerenciamento de Receita, Detecção de Fraude, Folha de
pagamento da tripulação e CRM.
• U$ 5 milhões de incremento de receita com o mapeamento e previsão de
demanda conforme origem e destino.
• Economia anual de U$ 10 milhões como resultado do aperfeiçoamento da
habilidade de medir o impacto da venda de tarifas.
• Economia de U$ 20 milhões devido a mellhoria do suporte a decisão e
sistemas de agendamento baseados em demanda e overbooking.
• U$ 30 milhões economizados em 3 anos devido a prevenção de fraudes e 7
milhões reembolsados.
• De U$ 15 a U$ 18 milhões economizados e de aumento de receita como
resultado de promoções melhor planejadas.
Nos primeiros cinco anos de operação, conforme informado pela empresa, o EDW
alcançou um ROI de mais de 1000% em relação aos U$ 25 milhões investidos
inicialmente. A empresa não só obteve um substâncial retorno quantitativo direto
sobre seu investimento como também obteve reconhecimento do mercado por meio
de prémios e ótimas avaliações.
Estes foram alguns valores possíveis de se mensurar e que mostram diretamento o
benefício de um projeto bem realizado de Busines Inteligence. É necessário manter
em mente que também são agregados valores qualitativos difíceis de mensurar mas
34
muito importantes para os negócios, como melhoria na qualidade do atendimento,
aumento da satisfação dos clientes e dos próprios funcionários entre outros.
5. CONCLUSÕES
Este trabalho apresentou os conceitos de BI e de Data Warehouse, coração desta
tecnologia. Foi mostrado a importância de um bom planejamento, do correto
entendimento dos negócios da empresa juntamente com um estudo de caso bem
sucedido no qual foi possível mensurar o retorno sobre o investimento da
implementação. Devido ao tempo necessário para o projeto, implementação e
avaliação dos resultados obtidos com um DW, não foi possível apresentar na parte
de pesquisa deste trabalho um estudo de caso de implementação realizado pelos
autores, tendo os mesmos que optar pela apresentação de um estudo de caso de
uma grande empresa do ramo de Data Warehouse.
Para que implementações de BI sejam bem sucedidas como a apresentada, é
importante que todos os fatores vistos sejam bem avaliados e planejados, assim
como o objetivo que se pretende alcançar com a implementação em si.
Valores agregados com a implementação, como satisfação e qualidade são por
vezes difíceis de mensurar e isso torna difícil a afirmação de que a implementação
foi bem sucedida quando estes são os únicos valores adquiridos.
A integração da tecnologia de BI com outros sistemas, como o CRM, é vista como
muito benéfica e é cada vez mais adotada pelas empresas que querem melhorar
seus processos de tomada de decisão.
Um projeto de BI demanda recursos financeiros e de mão de obra qualificada e
também tempo razoável entre o estágio de levantamento de requisitos até o estágio
de elaboração de relatórios gerenciais e de um Active Data Warehouse, tornando o
apoio da alta direção um dos fatores fundamentais para o sucesso.
35
6. REFERÊNCIAS BIBLIOGRÁFICAS
BARBIERI, Carlos. BI – Business Intelligence: Modelagem & Tecnologia. Rio de
Janeiro: Editora Axcel Books, 2001.
Microsoft. Academia Microsoft Technet - Business Intelligence. Disponível em:
<http://www.technetbrasil.com.br/academia2007/bi/Secure/Mod1.aspx>. Acesso em:
14 de julho de 2010.
SERAIN, João Sidemar. Por que Business Intelligence? Disponível em:
<http://imasters.uol.com.br/artigo/5415/bi/por_que_business_intelligence>.
Acesso
em: 14 de julho de 2010.
TERADATA.
Introduction
to
the
Teradata
Database.
Disponível
em:
<http://www.teradatau.courses.teradata.com/learning/BLADE%5FMS/legacy/18109%
5FIntrotoTeradata/wbt-printmod00.htm>. Acesso (restrito) em: 10 de março de 2008.
TERADATA. Case Study > Data Warehousing: Continental Airlines. Disponível em:
<http://www.teradata.com/t/case-studies/Continental-Airlines-Case-Studyeb4349/?type=CS>. Acesso em: 01 de setembro de 2010.
36
Autorização de Divulgação de Trabalho Técnico
AUTORIZAÇÃO DE PUBLICAÇÃO
AUTORIZAMOS A PUBLICAÇÃO DE NOSSO TRABALHO NA
INTERNET, JORNAIS E REVISTAS TÉCNICAS DO IETEC.
NÃO AUTORIZAMOS A PUBLICAÇÃO OU DIVULGAÇÃO DO
NOSSO TRABALHO.
BELO HORIZONTE, 16/09/2010
CURSO: GESTÃO E TECNOLOGIA DA INFORMAÇÃO
SEMESTRE/ANO: 1º DE 2010
TURMA: 15
TÍTULO DO TRABALHO: BUSINESS INTELIGENCE: O PAPEL DO
DATA WAREHOUSE NO PROCESSO DE SUPORTE A TOMADA DE
DECISÃO
NOME DOS PARTICIPANTES
Alexandre Antônio de Vasconcelos
André Caribé Pinheiro
Ivani Aparecida Alves
Rafael Tardelli Pacheco dos Santos
Wantuil Silva
ASSINATURA