Escolar Documentos
Profissional Documentos
Cultura Documentos
2022
Fundamentos do Bootcamp
Bootcamp: Desenvolvedor Business Intelligence
Daniel de Oliveira Capanema
© Copyright do Instituto de Gestão e Tecnologia da Informação.
Todos os direitos reservados.
2
Sumário
Histórico .......................................................................................................... 6
Definição ......................................................................................................... 7
Justificativa ................................................................................................... 30
Planejamento ................................................................................................ 31
Análise .......................................................................................................... 32
Design ........................................................................................................... 33
Construção .................................................................................................... 34
Implantação .................................................................................................. 35
3
Premissas ................................................................................................. 43
BI Operacional .............................................................................................. 61
Dashboards ................................................................................................... 65
Operadores ................................................................................................... 74
4
Data Warehouse e Data Marts ...................................................................... 76
Referências…… ............................................................................................... 85
5
Capítulo 1. Definição e Fundamentos de BI
Neste primeiro capítulo será feita uma introdução ao Business Intelligence (BI,
ou Inteligência de Negócios, em português). Além disso, serão apresentados os
conceitos e definições fundamentais para o entendimento da disciplina.
Histórico
6
Década de 1990: ferramentas de Business Intelligence. O termo e as técnicas
se tornam comercializáveis e atualizados através do uso de relatórios de processamento
em lote. Surgimento de ERPs.
Definição
7
MOSS e ATRE: O BI não é um produto nem um sistema. É uma arquitetura e
uma coleção de aplicações e bancos de dados com acesso facilitado aos dados e que
provê suporte à tomada de decisão.
8
• Preferências de clientes.
• Condições de mercado.
Arquitetura Básica
9
Figura 1 – Arquitetura básica de um processo de BI.
Fonte: wikimedia.org.
10
Armazém de Dados ou Data Warehouse
11
discrepâncias entre unidades de medida. Espera-se que um Data Warehouse
seja totalmente integrado.
Data Marts
12
antes. Eles garantem que o usuário final visualize a mesma versão de dados acessada
por todos os outros usuários do Data Warehouse. O alto custo deste último limita seu
uso às grandes empresas. Como alternativa, muitas empresas usam uma versão de Data
Warehouse reduzida em custo e escala, denominada Data Mart independente.
13
Data Staging Area: parte do Data Warehouse responsável pelo
armazenamento e pela execução de um conjunto de processos normalmente
denominados como extração, transformação e Carga (ETL – extract, transformation,
load) dos dados. A área de Staging encontra-se entre os sistemas operacionais e a
camada de apresentação. É considerada a “cozinha do restaurante”, que está fora do
acesso dos usuários.
14
Capítulo 2. Maturidade para BI
A maioria dos projetos de BI não obtém sucesso por não terem a maturidade
necessária. De acordo com pesquisa do IDC (2011), 70% das aplicações de BI no Brasil
ainda se referem à geração de relatórios, o que demonstra a falta de maturidade e a
falta de foco dos programas de BI.
Moore (2003) define modelo de maturidade como sendo uma estrutura para
caracterizar a evolução de um sistema de um estado menos ordenado e menos efetivo
para um estado mais ordenado e altamente eficaz. Isso evidencia que há graus
evolutivos de maturidade no processo.
O modelo TDWI
15
mundo, interessados em informações sobre as estratégias, técnicas e ferramentas
necessárias para projetar, construir e manter soluções de BI e DW. O modelo TDWI de
maturidade em BI foi criado em 2004 com o objetivo de auxiliar os profissionais e
empresas a entender melhor os programas de BI, proporcionar a possibilidade de se
comparar com outros negócios e traçar metas para melhorar a maturidade.
16
Os cinco estágios do modelo de maturidade TDWI
Estágio 1 – Inexistente
Este estágio é formado por duas fases que estão interligadas: relatórios
operacionais e spreadmarts.
O golfo
17
• Percepções executivas: executivos nesse estágio igualam BI a relatórios
operacionais e não se preocupam de gastar mais dinheiro na entrega de
informações.
18
Estágio 2 – Preliminar
Estágio 3 – Repetido
Neste estágio, o trabalho passa a ser mais amplo, saindo de Data Marts não
integrados para um modelo mais consolidado em um único DW. Isso gera economia,
maior consistência nas informações utilizadas, maior análise do negócio e
consequentemente maior compreensão dos dados. Neste estágio, é utilizado um
modelo padrão de projeto e desenvolvimento de metodologias que incorpora as
melhores práticas adquiridas com iniciativas anteriores e consultores externos.
O abismo
19
• Volatilidade do negócio: mudanças estratégicas na empresa (como fundir-se
à outra), novos executivos ou outras reestruturações podem comprometer o
BI. Agilidade nos processos, arquitetura flexível e alinhamento de TI ao negócio
são fundamentais para a gestão da volatilidade dos negócios.
20
para semana e de mês para mês, devido ao ambiente dinâmico em que as
empresas estão inseridas. Por isso, a arquitetura de BI precisa ser flexível para
responder solicitações de mudanças dos usuários e para apoiar processos de
desenvolvimento ágeis que possam criar novos aplicativos rapidamente.
Estágio 4 – Gerenciado
• Entrega just in time: o DW integra-se aos dados em tempo real para suportar
aplicações operacionais que requerem uma entrega just in time da informação
analítica.
21
• Análise preditiva: no estágio gerenciado as organizações começam a usar
previsões mais sofisticadas e ferramentas de modelagem para antecipar, em
vez de reagir aos movimentos do negócio.
Estágio 5 – Otimizado
22
vantagem competitiva, consolidando relações com fornecedores. A empresa
enxerga a importância de manter os níveis elevados de atendimento ao
cliente, e o número de usuários interessados em utilizar a ferramenta dispara.
Todos esses fatores fazem com que o programa de BI receba investimentos
significativos para criar e manter uma solução forte de BI, sempre atendendo
os níveis de serviço exigidos.
23
Escopo
24
Patrocinador
Apoio financeiro
25
Retorno
Arquitetura
Dados
26
acessibilidade dos dados pode ir de alta dificuldade até a alta acessibilidade, quando os
usuários conseguem acessar facilmente todos os dados necessários.
Desenvolvimento
27
tempo de implantação, o número de projetos executados e o grau de padrões de
desenvolvimento e de documentação.
Entrega
Pode-se dizer que essa dimensão avalia o produto do programa de BI, dando a
ideia do grau de intensidade em que este é aplicado. Conforme Barbieri (2011),
A entrega dos dados também pode ser avaliada segundo o perfil de usuários. A
quantidade de usuários constantes ser maior do que os usuários casuais demonstram a
maturidade de um programa de BI. Além disso, o aumento do número de usuários que
utilizam o sistema acessando os dados ou mesmo recebendo relatórios padrões ou
dashboards parametrizados demonstra a intensidade com a qual a empresa aplica o BI
corporativo.
28
Figura 4 – Instruções de valor do modelo de maturidade TDWI.
29
Capítulo 3. Etapas do Projeto de BI
Neste capítulo serão apresentadas as etapas de todo processo de BI, desde sua
concepção até a entrega, que geralmente são divididos em 6 etapas iterativas, que como
podemos verificar abaixo.
Justificativa
Nesta fase, são avaliadas as necessidades de negócios que dão origem ao novo
projeto.
30
O problema de negócio ou oportunidade de negócio é definido, e uma solução
de BI é proposta. Cada versão do aplicativo de BI deve ser justificada por custos e deve
definir claramente seus benefícios de resolver um problema de negócios ou tirar
proveito de uma oportunidade de negócio.
Planejamento
31
• A infraestrutura não-técnica, que inclui padrões de metadados, metodologias,
diretrizes, procedimentos de teste e de gerenciamento de problemas,
processos de controle de mudanças, e assim por diante.
Análise
Definir o escopo é uma das tarefas mais difíceis nos projetos de suporte à
decisão de BI e um dos aspectos mais importantes da negociação dos requisitos para
cada entrega. As equipes devem esperar que esses requisitos mudem ao longo do ciclo
de desenvolvimento, pois os empresários aprendem mais sobre as possibilidades e as
limitações da tecnologia de BI durante o projeto.
32
limites da tecnologia, o que lhes dá a oportunidade de ajustar os requisitos do projeto e
suas expectativas.
Ter mais ferramentas significa ter mais metadados técnicos, além dos
metadados do negócio, que geralmente são capturados em uma ferramenta de
modelagem de engenharia de software auxiliada por computador. Os metadados
técnicos precisam ser mapeados para os metadados do negócio, e todas as metadados
devem ser armazenadas em um repositório de metadados.
Design
33
Construção
34
Implantação
35
Capítulo 4. Planejamento do Projeto de BI
• Envolvimento do Negócio:
• Escopo do projeto:
36
‒ Podemos implementar o escopo solicitado, considerando o cronograma
e os recursos disponíveis?
• Análise de custo-benefício:
• A infraestrutura:
• Pessoal e Habilidades:
37
‒ O gerente de projeto é atribuído à este projeto em tempo integral? Ou
tem outras responsabilidades administrativas?
Gerenciamento do Projeto de BI
38
tempo o definindo, para entender claramente os requisitos, riscos, restrições e
pressupostos relacionados.
Definição do Projeto de BI
Metas e objetivos
39
esse problema de negócios causa? Quais são os objetivos comerciais estratégicos? Os
objetivos do projeto de BI se enquadram nos objetivos de negócios estratégicos, ou o
projeto é um desejo pessoal de alguém?
Escopo do Projeto
Riscos de projeto
Todo projeto está sujeito a alguns riscos, e os riscos são inevitáveis. Eles podem
afetar severamente o cronograma e os resultados do projeto, dependendo da
probabilidade de que os estes se materializem e do impacto que terão. Portanto, a
40
avaliação de risco deve ser revisada e expandida, se necessário. O gerente do projeto
deve identificar disparadores para cada risco e incorporar um plano de mitigação, bem
como um plano de contingência, no plano do projeto.
41
indisponível, mudanças constantes de negócios, gerenciamento de projeto ineficaz,
escalabilidade limitada.
Restrições do projeto
42
Felizmente, as organizações têm controle total sobre mudar a prioridade das
restrições do projeto. Insistir que o tempo e o escopo sejam as duas principais restrições
é aceitável somente em projetos que tenham requisitos relacionados aos regulamentos
impostos pelo governo. É recomendado que você retire qualidade do fundo da pilha e
coloque o escopo lá, porque o escopo pode e continuamente será expandido e alterado
à medida que o projeto avance. A figura abaixo mostra a ordem recomendada de
restrições do projeto.
Premissas
43
Premissa 1: "O fornecedor promete entregar um novo servidor de banco de
dados em maio e, até o final de junho, a equipe de TI instalará e testará um novo produto
de sistema de gerenciamento de banco de dados (SGBD) nesse servidor. Isso permite
muito tempo antes do prazo final, que é 30 de setembro, o final do ano fiscal ".
Existe um modelo mental tradicionalista que prega que "A mudança é ruim - os
empresários devem ser responsabilizados por suas decisões". Uma vez que os
aplicativos de BI devem ser catalisadores para uma melhor tomada de decisão, o modelo
mental deve mudar para "Mudança é boa - as pessoas de negócios devem refinar e
melhorar suas decisões". No entanto, mudanças descontroladas ainda podem acabar
com um projeto.
44
A solução é gerenciá-las. Muitas organizações acompanham suas solicitações
de mudança registrando a data do pedido de alteração, o nome do solicitante, a
mudança desejada, para quem foi atribuído e quando foi implementado. Essa é uma boa
prática.
Para gerenciar uma mudança, você precisa começar com uma linha de base - o
acordo entre o patrocinador comercial e a equipe de TI, conforme documentado na
carta do projeto. Toda solicitação de alteração, uma vez registrada, passa por uma
análise de impacto de custo-benefício para determinar seus efeitos no projeto. As
mudanças, a menos que sejam minúsculas, terão sempre impacto nas restrições de
esforço, tempo, escopo e qualidade. Algumas também afetam as outras duas restrições
(orçamento e recursos). Quando uma restrição muda, as restantes devem ser
renegociadas.
• Estender o prazo;
45
• Eliminar transformações complicadas, verificações e testes, o que afetará a
qualidade do produto.
Planejamento do Projeto de BI
O planejamento de projetos não é uma atividade única. Uma vez que um plano
de projeto é baseado em estimativas, que muitas vezes não são mais do que as melhores
suposições, estes devem ser ajustados constantemente. O primeiro sinal de que um
projeto não está sendo propriamente gerenciado é um plano estático no qual as
estimativas e os marcos nunca mudaram desde o primeiro dia do desenvolvimento.
46
• Crie uma estrutura de repartição do trabalho listando atividades, tarefas e
subtarefas.
Atividades e tarefas
Os projetos de BI são compostos por muitas atividades, cada uma com uma
longa lista de tarefas. O gerente do projeto deve contar com uma lista pré-existente que
seja abrangente das atividades mais necessárias. Naturalmente, nem todas as atividades
devem ser realizadas em todos os projetos, e nem mesmo cada passo deve ser realizado
em todos os projetos. O gerente seleciona o número mínimo de etapas e atividades
necessárias para produzir um produto aceitável sob as restrições impostas.
47
isso e refletir no cronograma. A maneira mais fácil de planejar essas iterações internas
é usar o conceito de "looping" ou "refatoração", dividindo o projeto em múltiplos
subprojetos pequenos, cada um com um produto, embora não completo. Em seguida,
cada entrega é revisada, e são adicionados mais dados e mais funcionalidades até que o
aplicativo de BI inteiro seja concluído com a entrega desejada.
Técnicas de estimativa
As três técnicas de estimativa listadas acima esperam que você tenha alguma
experiência anterior de projeto.
48
A técnica de estimativa intuitiva espera que você preveja, com base em sua
experiência, quanto tempo demorará para completar uma atividade, mas
possivelmente você nunca realizou uma atividade similar.
Atribuição de recursos
49
Dependências de tarefas
Nem todas as atividades e tarefas devem ser realizadas em série. Muitas podem
ser realizadas em paralelo, desde que haja pessoal suficiente. O primeiro passo para
determinar quais tarefas podem ser realizadas em paralelo é identificar as dependências
entre elas e desenvolver o caminho crítico. A maioria das ferramentas de planejamento
de projetos suporta quatro tipos de dependências de tarefas:
Término - Início: Nesta situação uma atividade é finalizada para outra ser
iniciada. A Atividade 2 para ser iniciada depende que a Atividade 1 seja finalizada.
Início - Início: Este tipo de conexão é utilizada quando duas ou mais atividades
iniciam ao mesmo tempo. Atividade 2 não depende da Atividade 1 para iniciar, e ambas
serão iniciadas simultâneamente.
50
Término - Término: Nesta conexão as duas atividades são finalizadas
igualmente. A Atividade 1 e a Atividade 2 dependem uma da outra para serem
concluídas de maneira uniforme.
Início - Término: Neste caso uma atividade não poderá ser finalizada até que a
outra atividade tenha sido começada. A Atividade 2 não pode ser finalizada até que a
Atividade 1 tenha sido iniciada.
Dependências de recursos
51
Figura 10 – Método do Caminho Crítico.
Horários do projeto
52
Figura 11 – Gráfico de Gantt.
53
Capítulo 5. Ciclo Analítico da Inteligência de Negócios
Esse ciclo deve ser explicitamente aplicado a cada aplicativo construído, sob
pena de não se ter os resultados esperados caso isso não seja realizado.
54
Monitoramento de atividades
Um erro muito comum é acreditar que apenas essa fase é suficiente para uma
solução de BI. Muitas vezes as implementações param nesse estágio e se julgam bem-
sucedidas.
É importante dar ênfase aos pontos mais relevantes das informações. Mais
importante do que mostrar todos os dados, nesse caso, é dar relevância aos que se
comportam de maneira diferente.
As exceções podem gerar alarmes nos sistemas de BI, alertando seus usuários
da condição identificada. Sistemas integrados a avisos por e-mail, SMS e Push
Notification são bastante comuns nesses casos.
55
Determinação dos fatores causais
A integração dos dados dos sistemas internos da empresa à fontes externas que
contenham indicadores que possam ter impacto no negócio, e o conhecimento do meio
ambiente no qual se está inserido, é uma forma importante de não se equivocar na
determinação das reais causas da exceção.
Modelagem de alternativas
56
Para que isso seja possível, pode ser necessário que o DW seja capaz de acessar
a linha operacional, de alterar os modelos dimensionais ou de criar bancos de
acompanhamento de desempenho para que sejam guardadas as decisões de negócio
tomadas e as métricas impactadas por elas para, então, serem definidas aquelas que
tiveram um resultado satisfatório ou aquelas que não atingiram seus objetivos.
57
Capítulo 6. Tipos de soluções de BI
Existem três tipos de análise com diferentes propósitos, cada um deles com sua
devida importância.
58
O sistema de informação operacional é formado por operações rotineiras, e
normalmente trabalha com um grande volume de operações de entrada e saída. A
maioria dos sistemas de informação estão neste nível e são caracterizados pela
existência de muitos formulários de cadastros, relatórios e outras operações rotineiras.
Geralmente são provenientes dos sistemas transacionais das empresas com relatórios
estáticos e apoiam em tomadas de decisões de pequeno impacto, mas de grande
frequência. Exemplos: formulários de cadastros, relatórios de conferência de dados,
listagens, consultas e modificações de dados.
59
Consultas de Acesso Direto
60
Relatórios padrão
BI Operacional
Aplicativos analíticos
61
Seu uso costuma ser mais complexo que os relatórios padrão. Aplicativos
analíticos podem incluir algoritmos ou modelos de mineração de dados para
encontrarem informações ocultas nos dados.
Gestão do conhecimento
62
ferramentas a serem utilizadas na comunicação e organização de determinado
conteúdo.
Inteligência competitiva
63
inteligência de negócios pode se utilizar de informações externas e também de
informações obtidas através de dados do processo da gestão do conhecimento.
Data Mining
• Modelagem preditiva: criação de modelos para variável alvo como função das
variáveis independentes. Podemos prever, por exemplo, que o consumidor X
irá gastar 8000 este ano.
64
• Análise de clusters: identificação de grupos de registros que apresentem uma
similaridade significativa entre si. Por exemplo, consumidor A é do tipo X, e
consumidor B é do tipo Y.
Dashboards
65
Figura 14 – Dashboards.
Balanced Scorecards
66
crescimento. Portanto, ao planejar alguma ação ou estratégia para a empresa, elas
devem perpassar por estes quatro níveis, e aí que está o balanceamento do processo.
Como podemos ver na figura anterior, para cada perspectiva a ser analisada é
preciso definir os seguintes pontos:
67
• Indicadores: Indicam o desempenho da empresa referente a cada objetivo
definido.
• Perspectiva do Cliente - Objetivos: Ter uma loja mais atraente para os clientes.
Metas: Aumentar em 20% a média de visitas diárias à loja. Indicadores:
Contagem de clientes. Iniciativas: Melhorar a exposição das joias nas vitrines e
investir em mídias sociais.
68
Capítulo 7. Modelagem Dimensional
69
Tabelas Fato e Dimensão
70
Figura 16 – Modelo estrela (acima) e modelo floco de neve (abaixo).
71
É importante que os dados hierárquicos sejam armazenados na mesma tabela
para facilitar e agilizar a visualização dos dados.
• Definição da granularidade.
72
Figura 17 – Data Warehouse Bus Matrix.
73
Operadores
Existem diversas operações que usualmente são utilizadas na maior parte das
ferramentas de BI, são elas:
74
Outras ações também são possíveis mas menos usuais, nas ferramentas de
exibição de cubos:
75
Figura 19 – Dados Operacionais X Dados Informacionais.
76
• Apresenta as informações da organização de forma consistente.
• Os Data Marts têm o escopo mais limitado e são mais identificados com grupos
de necessidades dos usuários, o que se traduz em esforço/equipe
concentrados.
77
• Os departamentos autônomos e as pequenas unidades de negócios
frequentemente preferem construir o seu próprio sistema de apoio à decisões
via Data Marts.
78
Capítulo 8. Construção do Modelo Dimensional
• Parte destes dados são então extraídos para BDs menores, criando BDs
departamentais denominadas Data Mart (DM), onde os utilizadores finais
exploram os dados e criam relatórios.
79
• Menores taxas de crescimento do volume de dados.
Abordagem Kimball
O modelo proposto por Kimball é o bottom up, onde são criados os DMs e
expandindo para o DW. Este é o modelo mais indicado e amplamente utilizado
atualmente.
80
• Infraestrutura mais adequada às exigências de um sistema de apoio à decisão.
81
• Alterações ao nível dos sistemas operacionais implicam alterações em
procedimentos dedicados a diferentes esquemas, em estrelas de diferentes
granularidades.
82
Seleção do processo de negócio
Definição do grão
Cada grão de tabela de fatos proposto resulta em uma tabela física separada.
Grãos diferentes não devem ser misturados na mesma tabela de fatos.
83
Escolha das dimensões
Sempre que possível, uma dimensão deve ser de valor único quando associada
a uma determinada linha de fato. As tabelas de dimensão às vezes são chamadas de
“alma” do data warehouse, porque contêm pontos de entrada e rótulos descritivos que
permitem que o sistema DW / BI seja alavancado para análise de negócios. Uma
quantidade desproporcional de eficiência é colocada na governança de dados e no
desenvolvimento de tabelas de dimensões, porque elas são as direções da experiência
de BI do usuário.
84
Referências
GARTNER GROUP. Disponível em: < https://www.gartner.com/en >. Acesso em: 22 dez.
2021.
KIMBALL et al. The Data Warehouse Lifecycle Toolkit. 2. ed. Indianapolis: John Wiley &
Sons Inc., 2008.
KIMBALL, Ralph; ROSS, Margy. The Data Warehouse Toolkit: The Definitive Guide to
Dimensional Modeling, Third Edition. Indianapolis: John Wiley & Sons Inc., 2013.
MOSS, Larissa; ATRE, Shaku. Business Intelligence Roadmap: The Complete Project
Lifecycle for Decision-Support Applications. Addison-Wesley Professional, 2003.
85
2011. Dissertação (Mestrado) – Universidade Federal de Santa Catarina, Programa de
Pós-Graduação em Engenharia e Gestão do Conhecimento, Florianópolis, 2011
TURBAN, E.; SHARDA, R.; ARONSON, E.; KING, David. Business Intelligence: Um Enfoque
Gerencial. Bookman, 2009.
XAVIER, Fabrício; PEREIRA, L. SQL dos conceitos. Rio de Janeiro: Ciência Moderna, 2009.
86