UNIVERSIDADE FEDERAL DE SANTA CATARINA

CENTRO TECNOLGICO
DEPARTAMENTO DE INFORMTICA E ESTATSTICA
CURSO DE GRADUAO EM SISTEMAS DE INFORMAO

CONSTRUO DE DATA MARTS PARA A AUDITORIA DO PROCESSO DE

RECEITA DE UMA OPERADORA DE TELEFONIA.

Ronivaldo Fernando Moretti

Florianpolis
2004

ii
RONIVALDO FERNANDO MORETTI

CONSTRUO DE DATA MARTS PARA A AUDITORIA DO PROCESSO DE

RECEITA DE UMA OPERADORA DE TELEFONIA.

Trabalho de Concluso de Curso apresentado ao Curso de

Graduao em Sistemas de Informao do Centro
Tecnolgico da Universidade Federal de Santa Catarina,
como requisito parcial para a obteno do grau de
Bacharel em Sistemas de Informao.
Prof. Dr. Jos Leomar Todesco Orientador

iii
CONSTRUO DE DATA MARTS PARA A AUDITORIA DO PROCESSO DE
RECEITA DE UMA OPERADORA DE TELEFONIA.

Por

RONIVALDO FERNANDO MORETTI

Trabalho de Concluso de Curso apresentado Universidade

Federal de Santa Catarina, Curso de Graduao em Sistemas
de Informao, para obteno do grau de Bacharel em
Sistemas de Informao, pela Banca Examinadora formada
por:

_________________________________________________
Presidente: Prof. Dr. Jos Leomar Todesco - Orientador, UFSC

_________________________________________________
Membro: Frank Augusto Siqueira, Dr., UFSC

_________________________________________________
Membro: Prof. Ronaldo dos Santos Mello, Dr., UFSC

iv

Dedico este trabalho.......

v
AGRADECIMENTOS

vi
RESUMO

Palavras-chave:

vii
ABSTRACT

Key-words:

viii
LISTA DE FIGURAS

Quadro 1 Matriz de relacionamento entre os data marts e as dimenses coletadas na anlise

de requisitos.
43
Erro! Indicador no definido.
Figura 1: Esquema simplificado de uma rede telefnica..........................................................14
Figura 2: Processo de receita de uma operado de telefonia......................................................16
Figura 3: Arquitetura do sistema Auditor.RA...........................................................................21
Figura 4 Ciclo de vida de um data warehouse.......................................................................30
Figura 5 Diagrama do fato da camada de teste e suas dimenses.........................................46
Figura 6 Diagrama do fato chamada bilhetada e suas dimenses..........................................47
Figura 7 Modelo fsico do fato chamada de teste..................................................................48
Figura 8 Modelo fsico do fato chamada bilhetada................................................................49
Figura 9 Plano de aquisio de informaes..........................................................................51
Figura 10 Esquema de armazenamento.................................................................................52
Figura 11 Arquitetura de front end.........................................................................................55

ix
LISTA DE QUADROS
Quadro 1 Matriz de relacionamento entre os data marts e as dimenses coletadas na anlise
de requisitos......................................................................................................................44

x
LISTA DE ABREVIATURAS

ANATEL - Agncia Nacional de Telecomunicaes

CDR - Call Detail Record
DW Data Warehouse
ETL Extract, Transformation and Load
OLAP - On Line Analytical Processing
OLTP On Line Transaction Processing
SGBD Sistema Gerenciador de Banco de Dados
SQL Structured Query Language

xi
SUMRIO

1. INTRODUO......................................................................................................................7
1.1. PROBLEMA DE PESQUISA..........................................................................................8
1.2. OBJETIVOS....................................................................................................................8
1.2.1. Objetivo geral............................................................................................................8
1.2.2. Objetivos especficos................................................................................................8
1.3. JUSTIFICATIVA.............................................................................................................9
1.4. MOTIVAO..................................................................................................................9
1.5. ORGANIZAO DOS CAPTULOS............................................................................9
2. O PROBLEMA DA AUDITORIA DO PROCESSO DE RECEITA DE TELEFONIA.......11
2.1. A TELEFONIA DO JEITO QUE CONHECEMOS E O PROCESSO DE RECEITA. .11
2.1.1. A Chamada..............................................................................................................12
2.1.2. O processo de bilhetagem.......................................................................................13
2.2. GARANTIA DA RECEITA...........................................................................................19
2.3. A AUDITORIA DO PROCESSO DE RECEITA..........................................................20
3. DATA WAREHOUSE E O PROCESSO DE AUDITORIA.................................................23
3.1. DEFINIO..................................................................................................................23
3.2. CARACTERSTICAS...................................................................................................24
3.3. COMPOSIO.............................................................................................................25
3.4. MEDOLOGIAS DE CONSTRUO...........................................................................28
3.5. O CICLO DE VIDA DE KIMBALL.............................................................................29
3.5.1. Planejamento do projeto.........................................................................................30
3.5.2. Definio dos requisitos de negcio.......................................................................30
3.5.3. Modelagem dimensional.........................................................................................31

xii
3.5.4. Projeto fsico...........................................................................................................31
3.5.5. Desenvolvimento e projeto da rea de transio.....................................................31
3.5.6. Projeto e arquitetura tcnica....................................................................................32
3.5.7. Instalao e seleo de produtos.............................................................................32
3.5.8. Especificao da aplicao do usurio final...........................................................32
3.5.9. Desenvolvimento da aplicao do usurio final.....................................................33
3.5.10. Implantao...........................................................................................................33
3.5.11. Manuteno e evoluo.........................................................................................33
3.5.12. Administrao do projeto......................................................................................33
3.6. APLICAO DE DATA WAREHOUSE EM TELEFONIA E AUDITORIA...............34
4. METODOLOGIA ADOTADA.............................................................................................35
4.1. PLANEJAMENTO DO PROJETO...............................................................................36
4.2 DEFINIO DE REQUISITOS....................................................................................37
4.2.1 Requisito Anlise das Chamadas de Teste...............................................................38
4.2.2 Requisito Anlise de Chamadas Bilhetadas.............................................................41
4.3 MODELAGEM DIMENCIONAL.................................................................................42
4.4 IMPLEMENTAO DO MODELO PROPOSTO........................................................49
4.4.1 Arquitetura de back room.........................................................................................50
4.4.2 Arquitetura de front end...........................................................................................53
4.5 APLICAO DO MODELO.........................................................................................55
5. RESULTADOS.....................................................................................................................57
6. TRABALHOS FUTUROS...................................................................................................61
7. CONCLUSO......................................................................................................................63
8. REFERNCIAS BIBLIOGRFICAS..................................................................................65
9. BIBLIOGRAFIA..................................................................................................................67

xiii

7
1. INTRODUO

A privatizao do setor de telecomunicaes no final dos anos 90 fez com que as

operadoras nacionais de telefonia experimentassem o amargo sabor da disputa de mercados,
at antes desconhecido por elas.
A acirrada concorrncia existente entre as empresas atualmente, as obriga a criarem
diferenciais ante seus concorrentes, buscando tornar-se mais atrativa aos seus clientes.
Para seus clientes, alm de tarifas justas e servios de qualidade, o grande diferencial
ainda a relao de confiana: clareza, transparncia e preciso nas informaes.
Buscando manter este bom relacionamento para com seus clientes, a rea de garantia
da receita destas operadoras tem investido cada vez mais nos ltimos anos em mecanismos de
acompanhamento e verificao de seus processos de prestao e cobrana de servios. Uma
das formas de realizar tais validaes implantar um processo de auditoria destes processos,
criando um paralelo aos mesmos e confrontando informaes.
Vendo este processo de auditoria como uma oportunidade de negcio, uma empresa
nacional iniciou em meados de 2001, o desenvolvimento de um produto de auditoria do
processo de receita de operadoras de telefonia, uma arquitetura composta de hardware,
software e servios.
E visando suprir uma demanda deste produto por informaes de confrontao de
dados do processo de auditoria que este trabalho proposto.

8
1.1. PROBLEMA DE PESQUISA

Atualmente a equipe de auditores que utiliza o produto constri tabelas e consultas

para extrair e transformar as informaes de que precisam do banco de dados operacional.
Estes procedimentos geralmente terminam em uma explorao por cruzamento e
quantificao das informaes, uma anlise exploratria.
desejvel que o processo de aquisio e transformao de informaes torne-se
automtico, em um processo mais rpido e sem a necessidade de intervenes manuais
peridicas e repetitivas na aquisio de informaes.

1.2. OBJETIVOS

1.2.1. Objetivo geral

Projetar, implementar e implantar um data warehouse (DW) que d suporte ao

processo de anlise de resultados na auditoria do processo de receita de uma operadora de
telefonia, integrando-o a um produto nacional de auditoria e certificao na rea.

1.2.2. Objetivos especficos

Inicialmente, estudar o processo de receita de operadoras de telefonia e mecanismos

de deteco de anomalias no mesmo.
Em seguida, aprimorar o conhecimento nas tcnicas de data warehousing e suas
utilizaes em telefonia e processos de auditoria.

9
E, por ltimo, somando os conhecimentos adquiridos, unificar e consolidar os atuais
mecanismos de obteno de informaes do produto, implantando um repositrio nico para
suportar o processo de anlise.

1.3. JUSTIFICATIVA

Como justificativa, v-se a afinidade do processo de anlise com as ferramentas OLAP

(On Line Analytical Processing), tido como mais produtivo hoje pela equipe de auditores
estudada. A dificuldade encontra-se atualmente no ponto de preparao das informaes para
o OLAP. Algumas experincias j apontavam para a confeco de um DW, sabida e
conhecidamente um ferramental que anda de mos dadas com as tcnicas OLAP.

1.4. MOTIVAO

A motivao para o desenvolvimento deste trabalho vem da possibilidade de aplicao

de tcnicas aprendidas ao longo do curso e estreitamente ligadas aos sistemas de informao,
alm da afinidade do autor com a rea de bancos de dados. Alm disso, o grande
conhecimento obtido na rea de auditoria nos ltimos anos por participar do desenvolvimento
do produto aqui em questo, vem consolidar o interesse na confeco deste.

1.5. ORGANIZAO DOS CAPTULOS

Inicialmente, no captulo 2 - O Problema da Auditoria do Processo de Receita de

Telefonia, ser feita uma introduo e explanao sobre o problema, apresentando as reas
envolvidas: telefonia, processo de receita e sua auditoria.

10
No captulo 3, Data Warehouse e o Processo de Auditoria, estaro sendo
apresentadas os assuntos pertinentes soluo do problema aqui proposto, como DW e suas
aplicaes no ramo de auditoria e telefonia.
Em Metodologia Adotada, captulo 4, a soluo proposta e implementada para
solucionar o problema ser apresentada.
Por ltimo, no captulo 5 - Resultados, apresentaremos uma avaliao do processo
de auditoria antes e depois deste trabalho, seguida de propostas de Trabalhos Futuros no
captulo 6 e da Concluso no captulo 7 acerca do desenvolvimento do trabalho.

11
2. O PROBLEMA DA AUDITORIA DO PROCESSO DE RECEITA DE TELEFONIA

As telecomunicaes tm experimentado ao longo das ltimas dcadas intensos

avanos. A velocidade no advindo de novas tecnologias e da prestao de novos tipos de
servios tem feito com que muitas operadoras passem a estabelecer mecanismos apurados de
controle de seus processos, desde a realizao de uma chamada por um cliente at a emisso
da fatura do mesmo.
Para este trabalho, acompanhando a linha de atuao do produto estudado,
consideraremos como servio prestado pelas operadoras de telefonia apenas as chamadas
telefnicas de voz, comuns ao dia-a-dia da maioria das pessoas, sejam elas geradas atravs de
um terminal fixo ou celular.
Para contextualizao de como esses servios so prestados e da organizao interna
das operadoras, sero utilizados modelos da realidade brasileira atual.
Para que entendamos melhor este assunto, vamos entender um pouco melhor como
funcionam as chamadas telefnicas e qual o significado de um processo de receita.

2.1. A TELEFONIA DO JEITO QUE CONHECEMOS E O PROCESSO DE RECEITA

A realizao de uma chamada telefnica h muito tempo tornou-se algo simples e

comum ao dia-a-dia do cidado em todo o mundo. No Brasil, com o advindo das
privatizaes, verificamos uma inundao de grande parte dos lares com telefones fixos, algo
at ento praticamente impossvel devido ao preo proibitivo para a maioria dos cidados.

12
Alm disso, nos ltimos anos a popularizao dos aparelhos celulares permitiu que o nmero
de terminais mveis crescesse de forma meterica.
Mas a facilidade de utilizao destes servios esconde uma complexa infra-estrutura
de prestao do mesmo, que deve permitir, por um lado, um acesso de qualidade aos usurios,
e por outro que os operadores sejam corretamente remunerados pela prestao.
A seguir, apresentado o processo de gerao e tratamento de chamadas telefnicas.

2.1.1. A Chamada

A chamada, que a unidade de prestao do servio telefnico de voz, definida por

Newton (1999), como a comunicao realizada entre duas entidades utilizando-se de uma
linha telefnica.
Uma viso melhor deste evento dada pela ANATEL (Agncia Nacional de
Telecomunicaes), que define chamada como a ao realizada pela origem com objetivo de
estabelecer comunicao com o destino.
Como origem, entende-se o usurio que iniciou a chamada e que pretende estabelecer
uma comunicao, tendo discado para um outro usurio. comumente tambm definido
como originador, chamador ou assinante A (SOUZA, 2002).
O destino o usurio que recebe a chamada, a quem quer se alcanar e com quem se
quer estabelecer a comunicao, segundo a ANATEL. Souza (2002) define como chamado ou
assinante B.
Mas, para que a comunicao possa se estabelecer entra em cena a figura das centrais
telefnicas de comutao, s quais os assinantes, tanto a origem como o destino, esto
conectados. Estes equipamentos desempenham duas funes bsicas: comutao e controle
(SORTICA, 1999).

13
A primeira, comutao permite que se estabelea, atravs de circuitos, uma conexo
entre a origem e o destino, permitindo a comunicao. A segunda, controle, comanda atravs
de dispositivos as aes de identificao, superviso e registro de uma chamada.
Geralmente, os assinantes do servio telefnico esto conectados a uma central
comutadora que chamada de local. Sua funo concentrar os assinantes de uma
determinada regio, abrangendo um raio de poucos quilmetros, permitindo a comunicao
entre eles.
Em grande parte dos casos, porm, os assinantes envolvidos no processo no esto
fisicamente conectados mesma central, podendo estar a milhares de quilmetros de distncia
um do outro e a provedores de servio distintos. Para que a comunicao seja possvel, ento,
as vrias centrais encontram-se interconectadas, permitindo o estabelecimento de um caminho
entre a origem e o destino. a chamada rede telefnica (DEPAULA apud SORTICA, 1999 p.
56).

2.1.2. O processo de bilhetagem

At agora, viu-se como funciona o estabelecimento das chamadas. Isto atende, de um

lado, s necessidades dos clientes. Por outro lado, no entanto, existem as prestadoras de
servio telefnico, que precisam ser remuneradas pelo servio que prestam.
A remunerao pelos servios pode se dar de diversas formas. No entanto, hoje,
excetuando-se as mensalidades e assemelhados que garantem o uso da linha telefnica, a
forma mais comum de remunerao pelos servios prestados cobrana do consumo
realizado pelo terminal. Para que isso possa ocorrer, h a necessidade de que todas as
chamadas realizadas pelo cliente fiquem registradas de alguma forma, permitindo que o
prestador do servio efetue a cobrana e que o cliente saiba o que est pagando.

14
Como normalmente as centrais locais no possuem a capacidade de registrar as
chamadas comutadas por ela, h centrais especficas dentro da rede telefnica que
desempenham este papel. So as chamadas centrais bilhetadoras. Geralmente, se encontram
em pontos estratgicos da rede, centralizando o registro de chamadas de vrias centrais locais
que a ela esto conectadas, podendo abranger um bairro, uma cidade ou at mesmo vrias. A
este processo de registro das chamadas d-se o nome de bilhetagem.
A Figura 1, a seguir, apresenta de forma superficial e simples a arquitetura de uma
rede telefnica.

Figura 1: Esquema simplificado de uma rede telefnica.

Fonte: Adaptado de SORTICA, Eduardo. Redes de telecomunicaes, TMN e gerncia integrada de redes e
servios. 1. ed. Salvador: [s.n], 1999, p.56.

O nome bilhetagem vem do registro da chamada, comumente chamado de CDR, sigla

para o termo ingls Call Detail Record, o Registro Detalhado da Chamada ou simplesmente
bilhete.
Basicamente, as principais informaes de registro de uma chamada telefnica so o
nmero do telefone de origem e de destino, a data e a hora em que ela foi iniciada, a sua

15
durao total, do atendimento por parte do recebedor at a seu encerramento, e o sucesso ou
no na realizao da chamada. H muitas variaes deste modelo, dependentes basicamente
da poltica da operadora e do fabricante das centrais, mas que no influenciam no que aqui se
quer apresentar. Assim, milhares ou at milhes de chamadas passam por estas centrais todos
os dias, ficando armazenadas at o momento em que sejam resgatadas.
Como era de se esperar, cada central possui um limite de armazenamento destas
chamadas. Respeitando estes limites, cabe operadora buscar periodicamente estes registros
em suas centrais. nelas que est registrada praticamente toda a sua receita de prestao de
servios.
Mas, em sua maioria esmagadora, estes registros no esto prontos para chegar
fatura do cliente. Sequer esto agrupados por cliente. Geralmente esta extrao resulta em
arquivos contendo todos os registro do perodo, ordenadas por data de ocorrncia do evento,
chamadas completadas e chamadas no completadas esto misturadas. Isso ainda agravado
pelo formato com que estas informaes esto dispostas nestes arquivos.
Cada fabricante define um formato para suas centrais. Se considerarmos que uma
operadora pode ter de algumas poucas unidades a centenas de centrais bilhetadoras em sua
rede, a possibilidade de que haja centrais de fabricantes distintos grande. Por isso, h dentro
dos operadores toda uma infra-estrutura de sistemas capaz de tratar estes registros e fazer com
que cheguem at a fatura do cliente.
A Figura 2, em seguida, apresenta de forma simplificada o funcionamento de toda esta
infra-estrutura.

16

Figura 2: Processo de receita de uma operado de telefonia.

Fonte: Adaptado de DE LUCCA, Sandro Daros. Identificao de problemas no fluxo de faturamento das
operadoras de telecomunicaes: uma aborgagem empregando lgica fuzzi e regras de produo. 2002. 108 f.
Dissertao (Mestrado em Cincias da Computao) Centro Tecnolgico, Universidade Federal de Santa
Catarina, Florianpolis, 2002, p. 24.

Basicamente, todo o processo iniciado pelo cliente. Como j citado anteriormente,

ele dispe de um terminal de assinante, do qual faz uso ao longo do tempo, e este terminal
est conectado a uma rede telefnica que registra estes consumos.
Esses registros so ento coletados das centrais pelo sistema de mediao. The Phillips
Group (2001) define como mediao o processo de busca dos registros das chamadas nas
centrais e a sua padronizao de formato, uma fez que salvas raras excees, cada fabricante
de centrais telefnicas adota um formato proprietrio. Sua funo ainda eliminar chamadas
que apresentam dados inconsistentes ou que no so plausveis de cobrana, como chamadas

17
de curta durao ou no completadas, e ao final destes processamentos encaminhar as
chamadas colhidas e tratadas aos sistemas de tarifao e faturamento, tambm ilustrados
acima.
Por fim, os sistemas de tarifao e faturamento desempenham a funo de dar valor s
chamadas realizadas. Na prtica, percebe-se que no h uma separao clara entre as funes
do sistema de tarifao e de faturamento. Em sua essncia, a tarifao consiste em aplicar
valor s chamadas individualmente, cabendo ao sistema de faturamento aplicar planos de
descontos e demais tarifas e impostos fatura do cliente. Ao final deste processo, a fatura do
cliente emitida e enviada para cobrana.
Todo esse caminho percorrido pela chamada dentro da operadora chamado de
Processo de Receita.
Observando este tratamento dado aos bilhetes coletados das centrais, verifica-se que
h um longo caminho a ser percorrido desde o instante em que ele foi gerado at que a sua
cobrana chegue s mos do cliente.
Este caminho, por muitas vezes, nem sempre harmonioso. Toda e qualquer
manipulao de dados, seja ela feita por mquinas ou pelo prprio homem suscetvel de
falha. E neste caso, uma falha pode tanto significar uma perda de receita por parte da
operadora bem como uma cobrana indevida ao cliente.
O relatrio do The Phillips Group (2001) sobre Planejamento de Garantia da Receita,
enumera uma srie de problemas que podem ocorrer ao longo deste processo.
Ainda durante a chamada, um erro na central pode evitar a gerao do seu registro,
ocasionando uma perda para a prestadora do servio. Sobrecargas em horrios de pico ou
problemas de integridade com o registro (nmero do telefone de origem corrompido, por
exemplo) podem ocasionar o mesmo problema. Por outro lado, erros na gerao de

18
informaes como a data e hora do incio da chamada ou durao podem levar cobrana
incorreta da chamada.
Mais adiante, nos sistema de mediao, h outro leque de problemas a se trabalhar. O
primeiro pode ocorrer ainda na busca dos registros na central. Uma falha de comunicao
pode ocasionar o comprometimento da integridade ou at mesmo a perda de um arquivo.
Conseqentemente, em alguns casos, um dia inteiro de chamadas pode ser perdido.
O processo de leitura e converso de formatos tambm pode ocasionar divergncias.
Um arredondamento de durao ou horrio da chamada pode refletir mais frente em uma
valorao incorreta da chamada. H casos ainda em que a chamada pode ser registrada em
dois pontos (ou at mais) da rede, por exemplo, na central de origem e na de destino da
chamada. A inabilidade do sistema de mediao em detectar que estes registros referem-se ao
mesmo evento pode gerar uma cobrana dupla ao cliente.
E, por ltimo, os sistemas de tarifao e faturamento podem ser suscetveis a falhas
tanto quanto os demais. Erros no cadastramento de planos de tarifas e de clientes podem
incorrer na tarifao desacertada das chamadas, podendo tanto ocasionar uma perda de receita
para a operadora como uma cobrana acima do esperado ao cliente. H registros de descartes
sumrios de chamadas ocorridos por erros em regras de validao das mesmas, planos novos
de servio no testados apropriadamente que entram em operao sem serem cobrados, alm
de uma srie de outros problemas.
Como se observa, os pontos de falhas podem ser muitos, e elas podem gerar problemas
tanto para as prestadoras de servios telefnicos como para seus clientes em si. Excetuando-se
os problemas de imagem e credibilidade que so intangveis, as perdas financeiras podem ser
da casa de centavos para um cliente ou de milhes de reais para uma operadora que possua
uma falha de maiores propores.

19
A viso que se tem de que a operadora de telefonia sempre tem a perder, seja qual for
a natureza do desvio. Na pior das hipteses, uma cobrana a maior de um cliente, que
momentaneamente lhe trs uma maior receita, pode manchar sua imagem por muito tempo,
ocasionando inclusive a perda de clientes, atuais ou potenciais.
lgico que como todo processo de propores gigantescas como o da prestao de
servios telefnicos encerra perdas e desvios, de forma praticamente inevitvel. O objetivo
que estes sejam conhecidos e contidos em nveis aceitveis.
Pensando nisto, as empresas do ramo de telecomunicaes acoplaram sua estrutura
organizacional uma entidade chamada comumente de Garantia da Receita, que includa de
diversas formas na hierarquia da empresa.

2.2. GARANTIA DA RECEITA

A funo da Garantia da Receita dentro de uma operadora, segundo o The Phillips

Group (2001), assegurar que o valor a ser cobrado do cliente pela prestao de servios seja
o correto, bem como garantir que todo servio prestado seja devidamente remunerado e os
desvios sejam mantidos em nveis aceitveis.
Sua configurao e forma de atuao variam muito de operadora para operadora. H
casos em que sua atuao se estende a estudos mercadolgicos a fim de conquistar e manter
clientes, mas basicamente trabalham na qualidade do seu processo interno de receita.
Sua composio tambm variada. Geralmente engloba especialistas de vrias reas
da empresa, provendo-lhe uma boa visibilidade do negcio, uma vez que seu controle de
qualidade deve abranger desde a correta configurao do terminal do assinante at a emisso
da fatura do mesmo.

20
A sua tarefa pode por muitas vezes ser rdua e difcil de ser cumprida. A complexidade
e o tamanho das empresas e dos sistemas aqui citados, torna complicada a tarefa de
acompanhar e monitorar todo o processo de receita. A maior dificuldade, talvez, seja a prpria
identificao dos desvios no processo, uma vez que geralmente trabalham com um volume
gigantesco de informaes e no h mecanismos para a criao de paralelos que facilitem a
validao das chamadas e seu tratamento.
Verificada esta dificuldade, empresas de software tem apostado em solues de
identificao destes desvios, atravs da auditoria do processo de receita das empresas de
telefonia.
Para melhor entender como funciona a auditoria neste ramo, vamos conhecer um
produto nacional do gnero, atualmente em uso em algumas grandes operadoras nacionais de
telefonia.

2.3. A AUDITORIA DO PROCESSO DE RECEITA

O produto em questo, fruto de pesquisa e desenvolvimento genuinamente brasileiros,

trata-se de uma arquitetura de hardware, software e servios que se prope a criar um paralelo
ao processo de receita da operadora de telefonia.
Sua atuao consiste em simular um consumidor comum, realizando chamadas
telefnicas de voz normais. As chamadas realizadas por este consumidor fictcio so
registradas pelo sistema e, em momento oportuno, sero confrontadas com o registro do
evento feito pela operadora.
Esta uma explanao simplria de sua atuao. A seguir, veremos em maiores
detalhes seus componentes e funcionamento. A Fig. 3 demonstra a arquitetura do sistema.

21

Figura 3: Arquitetura do sistema Auditor.RA.

Fonte: O autor.

O sistema composto de trs elementos macros: o Gerador de Chamadas, o Servidor e

o Cliente.
O Gerador de Chamadas o equipamento responsvel por simular um consumidor e
executar as chamadas telefnicas de teste. Para isso, ele se utiliza linhas telefnicas fixas ou
mveis disponibilizadas pela operadora em questo. Realiza tambm a comunicao com a
parte servidora do sistema, lhe permitindo saber quais chamadas deve realizar e informar o
resultado.

22
A camada servidora do sistema, o Auditor.RA Server, encarregada de controlar todo
o ambiente de testes, bem como as informaes que o mesmo gera e manipula.
Sua primeira funo comandar os geradores de chamadas para que estes concretizem
os testes desejados, encaminhando-lhes as programaes de chamadas e recepcionando e
armazenando mais tarde o resultado destes testes.
Em um segundo momento, ele funciona como receptor das informaes
disponibilizadas pela operadora, para aquelas chamadas de teste que acabou de realizar. Alm
disso, o elemento responsvel por receber os registros da operadora para as chamadas que
realizou.
Por fim, a camada cliente da aplicao fornece uma interface grfica ao usurio
permitindo-lhe especificar e executar cenrios de teste propostos, bem como analisar seus
resultados ao fim do processo.

23
3. DATA WAREHOUSE E O PROCESSO DE AUDITORIA

3.1. DEFINIO

Os DWs surgiram como um dos componentes dos sistemas de apoio a deciso.

Nasceram para suprir a necessidade de informaes histricas do negcio que permitissem
tomadas de deciso. Deveriam consolidar e concentrar em um nico banco de dados todas as
informaes dos diversos sistemas transacionais. Especificamente, dentro dos Sistemas de
Suporte a Deciso, deveriam permitir aos analistas visualizar os eventos registrados pelos
diversos sistemas da empresa sob vises variadas, fornecendo-lhe ferramental para gerao de
anlises e relatrios de informaes histricas ou at mesmo recentes.
O conceito DW abordado por diversos autores, destacando-se as figuras de Inmon
(2002) e Kimball (1998), os mais respeitados na rea.
Kimball (1998) define o DW como sendo um recurso de consulta e apresentao dos
dados de negcio da empresa, construdo especificamente para este fim.
Um conceito mais amplo e que permite entender melhor o tema o de Inmon (2002),
que define os DWs como um conjunto de dados que auxiliam o processo de tomada de
deciso. Este conjunto orientado por assunto, integrado, no voltil e varia em funo do
tempo.
A orientao a assunto vem do fato de serem projetados com o objetivo de dar suporte
anlise de dados. Esta anlise invariavelmente est focada em uma determinada situao,
com um determinado objetivo. Sua construo busca responder a questionamentos como
Qual foi o meu maior cliente no ltimo ano?, o que leva a uma anlise das vendas
realizadas no perodo, o assunto neste caso.

24
A caracterstica de ser integrado vem do fato de os DWs serem estruturas
centralizadas, que recebem e agrupam informaes de vrios sistemas, tendo de concili-las e
padroniz-las, resolvendo questes como informaes conflitantes, duplicadas ou at mesmo
faltantes.
A no volatilidade diz respeito ao fato de que as informaes contidas no repositrio
esto prontas e acabadas no momento em que so trazidas para ele, sendo que no sofrero
mais mutaes. uma posio natural, uma vez que se prope a anlises do que j aconteceu.
E, por ltimo, a variao em funo do tempo vem da natureza das anlises de
negcios que sistematicamente buscam tendncias, precisando muitas vezes de anos de
informaes. E essa grande quantidade de informaes necessrias muitas vezes contrasta
com o ambiente operacional, que no armazena por muito tempo os dados e uma consulta
com um perodo muito abrangente poderia se tornar muito demorada e custosa.

3.2. CARACTERSTICAS

Na prtica, os DWs so bancos de dados especializados que agregam e consolidam as

informaes das diversas fontes geradoras de dados nas empresas.
Tecnicamente, eles possuem diversas caractersticas que os diferem dos bancos de
dados operacionais, os OLTPs (On Line Transactional Processing), presentes na maioria das
empresas e uma das principais fontes de informaes para os DWs.
Uma das primeiras diferenas diz respeito carga de trabalho, onde temos os DWs que
so projetados a fim de que atendam as mais diversas consultas, que nem sempre so
previamente conhecidas. Em contrapartida, um OLTP possui um conjunto pr-definido e
fechado de operaes, sendo otimizado para atender especificamente estas.

25
Outra diferena est na forma como as informaes so atualizadas. Nos DWs a
entrada de informaes ocorre periodicamente, por procedimentos automatizados de carga e
os usurios finais no chegam a alterar diretamente os seus dados. Em um sistema OLTP as
atualizaes so realizadas a qualquer momento com a interveno direta dos usurios finais,
responsveis pela entrada de informaes.
Na prpria modelagem dos sistemas, temos de um lado os DWs com seus modelos no
normalizados, objetivando ganhos na realizao de consultas; de outro os sistemas OLTP, com
seus bancos de dados normalizados, visando desempenho na alterao de dados e a
integridade das informaes nele contidas.
As operaes tpicas realizadas por um sistema OLTP geralmente acessam um ou
poucos registros, apenas os estritamente necessrios, um trabalho pontual. J as consultas
realizadas a um DW na maioria dos casos implicam na leitura de milhares e milhares de
registros.
Por fim, se analisarmos os dados histricos contidos em um e no outro, teremos os
DWs com anos de informaes, permitindo analises histricas e de tendncias, enquanto nos
sistemas OLTP temos apenas as informaes mais atuais, dos ltimos perodos.

3.3. COMPOSIO

A seguir, na Figura X, podemos observar um esquema bsico dos principais elementos

que constituem um DW.

26

Figura 4 Elementos bsicos de um data warehouse.

Fonte: Adaptado de KIMBALL, Ralph. The data warehouse lifecycle toolkit: expert methods for designing,
developing, and deploying data warehouses. New York: John Wiley & Sons, c1998, p.15.

No modelo bsico de elementos que compe um DW, Kimball (1998) define como
Fontes os sistemas responsveis por capturar e registrar as transaes de negcio, tambm
conhecidos como sistemas legados.
So sistemas orientados a disponibilidade e velocidade na incluso e alterao de
dados e em pequenas consultas que fazem parte das transaes. Considera-se tambm que os
mesmos possuem pequenos perodos de informaes armazenados (alguns meses, por
exemplo).
O elemento seguinte da cadeia a rea de Estagiamento de Dados. Esta se constitui
de uma rea de armazenamento, que recebe os dados extrados dos diversos sistemas legados,
e um conjunto de processos que realizam a limpeza, transformao, unificao e preparao
dos dados para serem utilizados no DW.
No h uma regra geral de como devem ser desenvolvidas estas atividades. Os autores
relatam que os processos podem trabalhar com arquivos de texto plano ou at mesmo banco
de dados normalizados que sero manipulados pelos procedimentos. Independente da forma, o

27
objetivo primordial transformar toda a gama de dados obtidos das diversas fontes em dados
prontos para serem carregados.
Formatados, os dados sero ento carregados no Servidor de Apresentao, que
segundo a definio de Kimball (1998) um servidor onde os dados do DW estaro
organizados e armazenados para serem consultados diretamente pelos usurios. E
imprescindvel que os dados estejam armazenados e sejam apresentados em um modelo
dimensional.
Neste elemento do DW, geralmente os dados sero armazenados em um banco de
dados relacional, estando as tabelas organizadas em um esquema estrela.
A modelagem dimensional anda de mos dadas com os DWs. uma disciplina de
modelagem de dados alternativa ao modelo entidade-relacionamento, possuindo as mesmas
caractersticas deste, mas organiza os dados de forma a melhorar a compreenso do modelo,
maximizar a velocidade das consultas e facilitar alteraes no modelo.
Os componentes centrais de um modelo dimensional so os fatos e as dimenses.
A tabela de fato contm as mtricas do assunto modelado, as medidas do negcio.
Usualmente um fato numrico e aditivo. A tabela de fato possui duas ou mais chaves
estrangeiras que associam o fato s suas respectivas dimenses.
Uma tabela de dimenso faz parte de um conjunto de dimenses de um fato, composta
por uma chave primria artificial, que serve para integridade dos dados e relacionamento com
a tabela de fato. composta, tambm,de um conjunto de atributos que serviro para restringir
e agrupar os fatos nas consultas realizadas.
Por fim, os Aplicativos de Usurio Final so um conjunto de ferramentas para
consultar, analisar e apresentar as informaes contidas no servidor de apresentao. Podem
fazer parte do conjunto ferramentas de acesso a dados e realizao de consultas, planilhas

28
eletrnicas, construtores de grficos e at mesmo complexos sistemas de data mining. Seu
foco facilitar o acesso e apresentao dos dados aos usurios finais.
Uma tecnologia muito utilizada por estas ferramentas o OLAP (On-Line Analytic
Processing), uma poderosa ferramenta no processo de explorao de dados. A tecnologia
consiste basicamente no acesso e apresentao das informaes contidas no DW, sendo seu
ponto forte o acesso e apresentao dos dados no mais puro estilo dimensional. Muitos
fabricantes fornecem aplicativos com esta tecnologia. Suas interfaces buscam apresentar de
forma clara ao usurio a idia das dimenses e dos fatos, permitindo com algumas operaes
cruzar e sumarizar dimenses para obter os resultados e relatrios esperados.

3.4. MEDOLOGIAS DE CONSTRUO

Atualmente, a rea de DW conta basicamente com duas formas de abordar a

construo de destes repositrios de informao. Mas, antes de conhecer estas, necessrio o
conhecimento de mais um conceito, o de data mart.
Data marts so subconjuntos lgicos de um DW. Tratam um assunto especfico dentro
da organizao, abordam um tema localizado, servindo para um fim menor mas no menos
importante para o negcio, atendendo a uma nica rea e no a organizao como um todo.
Podemos entend-lo imaginando um grande DW que concentra todos os dados acerca
da organizao: vendas, compras, recursos humanos. Um data mart seria um conjunto lgico
de registros que tratam especificamente das vendas realizadas, o fato, e as suas respectivas
dimenses. Estas unidades lgicas de informao que sero a base para as duas abordagens
atualmente difundidas: a abordagem top-down e a abordagem botton-up.
Na abordagem top-down, defendida por Inmon (2002), o objetivo conquistar para
depois dividir, ou seja, inicialmente modela-se e constri-se todo o DW, contendo todas as

29
informaes acerca do negcio e da empresa e posteriormente disponibilizam-se os data
marts.
J a abordagem botton-up, defendida por Kimball (1998), segue a idia de dividir para
depois conquistar, ou seja, deve-se primeiramente construir os data marts, atendendo a
necessidades localizadas de informaes, construindo-os por prioridade para o negcio e ao
final da construo de todos os data marts eles comporo o DW como um todo.
Para este trabalho em particular, estudaremos mais a fundo a proposta bottom-up de
Kimball (1998).
Em sua metodologia de construo que ser vista a seguir, Kimball (1998) defende a
utilizao da proposta bottom-up de forma organizada, construindo fatos e dimenses
chamadas por ele de conformes, ou seja, que estejam padronizadas e modelem as informaes
da organizao como um todo, podendo ser compartilhadas por vrios data marts.
Assim, possvel construir o Data Warehouse Bus, um barramento das vrias
dimenses existentes no negcio, sobre as quais plugamos os fatos constituindo assim os data
marts.
Para todo este processo, Kimball (1998) prope uma metodologia de construo para
os DWs, o Ciclo de Vida, abordado a seguir.

3.5. O CICLO DE VIDA DE KIMBALL

Kimball (1998) defende uma metodologia prpria para o desenvolvimento de um DW.

Essa metodologia diz respeito a um ciclo de vida de um DW, que deve seguir alguns passos
para que se obtenha sucesso. Essa seqncia de passos abrange as fases de projeto,
desenvolvimento e implantao de um DW.

30
A representao, dependncia e seqncia de passos propostos pela metodolgia pode
ser observado na Fig 4.

Figura 5 Ciclo de vida de um data warehouse.

Fonte: Adaptado de KIMBALL, Ralph. The data warehouse lifecycle toolkit: expert methods for designing,
developing, and deploying data warehouses. New York: John Wiley & Sons, c1998, p.33.

3.5.1. Planejamento do projeto

De acordo com Kimball (1998), o ciclo de vida inicia com o planejamento do projeto.
Trata da definio e do escopo do projeto do DW, incluindo uma avaliao do investimento e
suas justificativas. Especificam-se os recursos, a capacidade necessria no preenchimento das
vagas do projeto, juntamente com as atribuies, durao e seqenciamento. No
planejamento, identifica-se todo o trabalho associado e as partes envolvidas ao ciclo de
negcios.

3.5.2. Definio dos requisitos de negcio

31
O sucesso de um DW est diretamente ligado ao entendimento das necessidades e
exigncias dos usurios finais. Os projetistas devem entender os fatores-chave que conduzem
o negcio, para determinar, efetivamente, os requisitos necessrios de negcio, considerandoos dentro do projeto do DW.

3.5.3. Modelagem dimensional

Projetar modelos de dados para suportar as anlises de negcios requer abordagens

diferentes das usadas para o projeto de bancos de dados operacionais. Deve-se iniciar com a
construo de uma matriz, que representa os processos-chave de negcios e suas
dimensionalidades. A partir desta matriz, faz-se um detalhamento da anlise de dados
relevantes, juntando com os requisitos de negcios levantados anteriormente, e desenvolve-se
um modelo dimensional. Este modelo identifica a granularidade das tabelas, as dimenses
associadas, atributos e fatos.

3.5.4. Projeto fsico

O projeto fsico da base de dados tem seu foco na definio das estruturas fsicas
necessrias para suportar o seu projeto lgico. Definio de padronizao de nomes, meiofsico, ndices preliminares e estratgias de particionamento so determinadas nesta fase.

3.5.5. Desenvolvimento e projeto da rea de transio

Esta fase a menosprezada no projeto de DW. Consiste em trs passos principais, que
so extrao, transformao e carga. So necessrios o projeto e desenvolvimento de duas

32
plataformas: uma para a populao inicial do DW e outra para as cargas regulares e
incrementais.

3.5.6. Projeto e arquitetura tcnica

O ambiente de DW requer uma integrao de inmeras tecnologias. Para isso, devemse considerar trs fatores, que so os requisitos de negcios, o atual ambiente fsico e o
planejamento estratgico tcnico definido pela empresa, para estabelecer o projeto de
arquitetura tcnica do DW.

3.5.7. Instalao e seleo de produtos

Nesta fase, so especificados, avaliados e selecionados os componentes de arquitetura,

como a plataforma de hardware, sistema de administrao de banco de dados, ferramentas de
transio e de acesso aos dados. Aps, os produtos so instalados e testados, para garantir
uma perfeita integrao com o ambiente do DW.

3.5.8. Especificao da aplicao do usurio final

As especificaes definem os modelos de relatrios, os parmetros operados pelos

usurios, e os clculos necessrios. Essas especificaes asseguram que o grupo de
desenvolvimento e os usurios de negcios tenham um entendimento comum sobre as
aplicaes que sero entregues.

33
3.5.9. Desenvolvimento da aplicao do usurio final

O desenvolvimento de aplicaes para usurios finais inclui ferramentas de

configurao de metadados, e a construo de ferramentas para gerao de relatrios.

3.5.10. Implantao

A implantao representa a convergncia entre tecnologia, dados, e aplicaes de

acesso na rea de trabalho. Um planejamento cuidadoso necessrio para que esse quebracabea se ajuste de forma adequada.

3.5.11. Manuteno e evoluo

Deve ser estabelecida uma prioridade de processos com os usurios e os gerentes, para
uma eficiente manuteno e a evoluo do DW. Depois que as prioridades do projeto so
identificadas, volta-se ao incio do ciclo de vida, para alavancar o que j foi estabelecido no
ambiente do DW, com o foco nas novas necessidades.

3.5.12. Administrao do projeto

A administrao do projeto assegura que as atividades do ciclo de vida dimensional

permaneam sincronizadas. Essas atividades focam no monitoramento do estado do projeto,
rastreamento dos resultados e controle de alteraes, preservando o escopo delimitado. Inclui
tambm o desenvolvimento de um plano de comunicao que trata simultaneamente do
negcio e dos sistemas de informao da organizao.

34

3.6. APLICAO DE DATA WAREHOUSE EM TELEFONIA E AUDITORIA

A utilizao de DWs na rea de telefonia no uma novidade. O prprio Kimball , em

seus livros utiliza exemplos da rea. Especificamente em seu livro The Data Warehouse
Toolkit (1998) ele dedica um captulo inteiro ao assunto, modelando uma situao real de
necessidade de informaes de trfego de uma operadora de telefonia, estabelecendo mtricas
e dimenses prximas as que sero utilizadas neste trabalho.
Dentro da prpria rea de telefonia, grande parte das concessionrias de telefonia no
Brasil se utilizam de DWs em seus processos decisrios, nos mais variados nveis
hierrquicos.
Mais especificamente na rea de investigao de fraudes em telefonia, o respeitado
grupo FML Securing Bussiness, em seu Yearbook 2003 (2003) que agrupa artigos de diversos
especialistas na rea, prope a utilizao de DWs como ferramental na identificao de
possveis fraudes dentro do sistema telefnico das operadoras.
Por fim, na rea de auditoria pouco se fala na utilizao destes repositrios de dados
como auxiliares do processo. Existem alguns produtos comerciais disponveis no mercado que
utilizam DWs para auditoria fiscal. Porm, um bom exemplo de aplicao deste tema em
processos de auditoria vem dos Estados Unidos, onde a empresa HP, em um projeto com o
Departamento de Receitas do Estado de Washington implantou um DW para auxiliar o
processo de auditoria de recolhimento de impostos, onde pode, atravs da integrao de vrias
fontes de dados, identificar o no pagamento de impostos ou o seu recolhimento com valores
inferiores aos devidos.
Assim, no captulo seguinte ser abordada a proposta concebida para o problema em
questo, unindo os trs temas: DW, auditoria e telefonia.

35
4. METODOLOGIA ADOTADA

At aqui, foram apresentados no captulo 2, uma viso do funcionamento do sistema

telefnico, suas peculiaridades, a necessidade de monitoramento do mesmo e os problemas
enfrentados neste processo de monitoramento.
No captulo seguinte, foram abordadas as tcnicas de data warehousing, apresentando
seu surgimento, suas aplicaes e formas de implementao.
Neste captulo, ser proposta uma aplicao destas tcnicas visando sanar as
dificuldades enfrentadas no processo de monitoramento do processo de receita.
A escolha pela construo de um DW passa por dois pontos principais. O primeiro o
fato de que atualmente a equipe de auditores que utiliza o produto j constri grandes tabelas
e consultas para extrair e transformar as informaes de que precisam do banco de dados
operacional. Estes procedimentos geralmente terminam em uma explorao por cruzamento e
quantificao das informaes, uma anlise exploratria parecida com o OLAP. E de
conhecimento que as anlises exploratrias por OLAP geralmente so antecedidas por um
ambiente de DW.
O segundo diz respeito ao fato de que o tema j abordado por autores no campo da
telefonia e em menor escala na rea de auditoria, conforme j mencionado neste trabalho.
A metodologia aqui aplicada trata-se de uma adaptao do modelo proposto por
Kimball visando acomod-la a realidade do projeto.

36
4.1. PLANEJAMENTO DO PROJETO

A etapa de planejamento o ponto inicial do projeto. Nela sero definidos os objetivos

a serem alcanados com o DW que se deseja construir, as necessidades e restries do projeto.
Outro ponto importante a definio das pessoas que estaro direta ou indiretamente ligadas
ao projeto e suas atribuies.
Inicialmente, em conjunto com a equipe de auditores do produto, buscou-se definir os
objetivos a serem alcanados com a construo do DW. Sua funo bsica ser a de suportar o
processo de anlise de resultados do produto. Em paralelo, essencial que ele possa fornecer
mecanismos de quantificao e verificao da qualidade dos testes realizados. Seria uma
auditoria do comportamento do prprio sistema. Logo, teramos duas situaes especficas a
serem tratadas pelo DW.
A primeira situao tem por objetivo verificar a qualidade dos testes que esto em
andamento, com a maior brevidade possvel, em termos de completamento ou no das
chamadas e da proximidade das que foram executadas com o que foi planejado.
A segunda situao deve confrontar diretamente o resultado das chamadas realizadas
com as informaes recebidas das operadoras. Este ponto essencial, pois dele que sero
tiradas as concluses de todo o processo. Apesar de algumas chamadas no sarem conforme
planejado, as que o foram realizadas corretamente serviro de base para o processo de
auditoria.
Com os objetivos estabelecidos, passou-se fase de verificao do parque tecnolgico
que servir de base para o projeto. Por imposio e necessidade da empresa, a soluo ter de
se adaptar aos atuais recursos disponibilizados para o produto. Isso implica na utilizao do
mesmo servidor onde atualmente roda o Auditor.RA. O banco de dados disponvel ser o

37
Oracle verso 8i, onde tambm est armazenado o banco de dados operacional do produto.
Os dispositivos de armazenamento tambm sero compartilhados.
A proximidade com a equipe de auditores tambm permitiu o estabelecimento de uma
equipe de trabalho concisa. A estrutura enxuta da empresa permitiu apoio direto ao projeto,
uma vez que o mesmo ter de correr em paralelo aos atuais trabalhos. Tambm foi obtido total
apoio, uma vez que a maior interessada a prpria equipe de auditores. Foi definido apenas o
papel de um coordenador do projeto que ser suportado em todas as atividades pelos demais
membros da equipe de desenvolvimento e de auditores, delegando ao longo do projeto as
atividades necessrias s pessoas certas.
Outra pr-condio para o DW a forma como as informaes sero apresentadas.
Atualmente na gerao dos relatrios so utilizadas planilhas do MS Excel e uma interface
cliente proprietria de realizao de consultas ao banco. desejvel que o DW possa ser
acessado por estas duas interfaces tambm quando estiver pronto. Isso minimizaria a
adaptao ao novo repositrio de dados. Futuramente podero ser incorporadas novas formas
de consulta.
Por fim, fez-se a definio das etapas do projeto, a iniciar-se pela coleta de requisitos.
Dever ser feita atravs do acompanhamento das atividades desenvolvidas junto ao produto,
atravs da anlise dos documentos gerados e das consultas executadas e por fim atravs de
conversas informais dirigidas junto ao grupo de auditores.

4.2 DEFINIO DE REQUISITOS

Segundo Kimball (1998), a definio dos requisitos do sistema a parte mais

importante de qualquer projeto de DW. Uma boa compreenso do negcio e das necessidades
que o mesmo requer nortear todos os demais passos do processo de desenvolvimento.

38
Buscou-se, ento, consolidar fortemente os conhecimentos acerca do processo de
auditoria implementado pela empresa, bem como de suas necessidades de informao para
tanto.
O trabalho inicial de planejamento permitiu identificar duas atividades distintas dentro
do processo. A primeira atividade seria de responsabilidade do analista de garantia de receita,
que define o programa e monitora os testes de consumo. Seu trabalho requer informaes
sobre o a qualidade destes testes. A segunda seria de responsabilidade do analista, que
realizar a confrontao de informaes entre os testes realizados e as informaes obtidas da
empresa de telefonia. Seu trabalho se baseia puramente na anlise das diferenas entre os
registros do produto de auditoria e os recebidos de cada um dos sistemas que compe o
processo de receita da operadora.
Optou-se ento por algumas frentes de trabalho na coleta de requisitos. Inicialmente
acompanhou-se o trabalho desenvolvido em cada uma das atividades. Posteriormente, foi feita
a anlise dos relatrios produzidos para os clientes, bem como os relatrios internos de
acompanhamento dos projetos e dos testes realizados. Por fim, entrevistas informais e
dirigidas foram feitas com a equipe de analistas e auditores, com o objetivo de validar e
incrementar a coleta de dados realizada nos dois primeiros momentos.
Consolidando todas as informaes obtidas, identificou-se os requisitos funcionais que
se seguem.

4.2.1 Requisito Anlise das Chamadas de Teste

Os analistas e auditores possuem a necessidade de conhecer e analisar o

comportamento do sistema ante os cenrios de testes realizados e programados. O processo
uma espcie de auditoria do prprio sistema, permitindo identificar ofensores de sucesso

39
dentro do ambiente de testes. Alm disto, espera-se que algumas mtricas forneam subsdios
para ajustar e melhorar o prprio sistema.
O ponto fundamental para este tipo de anlise a confrontao de informaes entre o
que foi programado para um teste e o que efetivamente foi realizado. Em um primeiro
momento analisado o sucesso ou no da chamada. Em seguida, para as que foram
efetivamente realizadas, parte-se para anlise de detalhes como a durao registrada e o
horrio de incio da chamada.
Estas anlises consistem basicamente em responder questionamentos como:

quantidade e representatividade das chamadas completadas e no completadas;

motivo do no completamento das chamadas;

os maiores ofensores do completamento das chamadas, seja o terminal de

origem e suas caractersticas, o terminal de destino e suas caractersticas ou at
mesmo o tipo de chamadas que mais causa erros;

variao verificada no registro das informaes da durao e horrio de incio

das chamadas, se compararmos a programao realizada com o que
efetivamente foi realizado.

Por fim, a equipe necessita de informaes que permitam quantificar e qualificar os

testes realizados para apresentao de resultados aos clientes. a anlise de completamento.
Antes da apresentao de resultados propriamente dita, de grande importncia
apresentar ao cliente todos os testes realizados sob diversas vises. So as chamadas
estratificaes, que permitem o entendimento e quantificao (em nmero de chamadas, em
nmeros de minutos, em valores monetrios) de todos os testes realizados.
So importantes neste momento abrir os testes por caractersticas da origem e do
destino da chamada, por servio testado, por data da realizao dos testes, etc.

40
Por isso, so essenciais as respostas aos seguintes questionamentos:

Estratificao de completamento:
o quantidade de chamadas completadas e no completadas por tipo de
servio;
o quantidade de chamadas completadas e no completadas por origem e
destino e suas respectivas caractersticas (cidade, GRC ao qual est
conectado, se um telefone fixo ou celular, etc.);
o quantidade de chamadas no completadas pelo motivo do no
completamento.

Estratificao das chamadas completadas:

o quantidade, durao e durao tarifada das chamadas completadas por
data de realizao;
o quantidade, durao e durao tarifada das chamadas por tipo de
chamada, se normal ou a cobrar;
o quantidade, durao e durao tarifada das chamadas por origem ou
suas caractersticas;
o quantidade, durao e durao tarifada das chamadas por destino ou
suas caractersticas;
o quantidade de chamadas por origem X destino;
o quantidade de chamadas por data e hora do dia de incio;
o quantidade de chamadas por tipo de dia e hora do dia de incio;
o quantidade de chamadas por faixa (intervalo) de durao.
o

41
4.2.2 Requisito Anlise de Chamadas Bilhetadas

Este requisito o primeiro a tratar do processo de auditoria em si. Suas atividades

baseiam-se nica e exclusivamente nas chamadas que foram completadas com sucesso.
Seu objetivo inicial identificar quantas chamadas apresentaram CDRs nos diversos
pontos de controle do processo de receita da operadora. Em um primeiro momento, a pesquisa
limita-se a identificar se o CDR foi encontrado ou no. Em seguida, caso hajam faltas no
explicadas, ser necessrio o cruzamento de informaes que permita identificar um perfil
para a falta, como origem ofensora, destino ofensor e servio ofensor, por exemplo.
Os questionamentos dos quais gostaria de obter-se resposta seriam:

Como foi a conciliao de chamadas por servio testado?

Como foi a conciliao de chamadas por ponto de bilhetagem?

Como foi a conciliao por caractersticas da origem e do destino?

O passo seguinte consiste em na anlise do registro da durao e do horrio de incio

das chamadas, verificando o comportamento das centrais telefnicas no registro destas duas
informaes. So consideradas nesta etapa apenas as chamadas que apresentaram CDRs na
entrada ou sada do sistema de mediao da operadora.
Pequenas variaes so tolerveis, mas o objetivo exatamente o de verificar se no
h diferenas exageradas, pois estas duas informaes influenciam diretamente no clculo do
valor da chamada que ser cobrada do cliente.
Ento, dois questionamentos so fundamentais para isto:

comparativo de diferena no registro da durao;

comparativo de diferena no registro do horrio de incio.

42
Por fim, a anlise de valorao tem por objetivo verificar se os sistemas de tarifao e
faturamento da operadora esto calculando de forma correta o valor da chamada.
Estes sistemas entregam CDRs com o valor a ser cobrado do cliente. O Auditor.RA por
sua vez, com base nas informaes do prprio CDR (origem, destino, horrio de incio e
durao) calcula tambm o valor da chamada. Estes dois valores so ento confrontados e
servem como base para esta anlise. Novamente, para situaes em que so verificadas
divergncias, as caractersticas da chamada so de grande importncia na busca de um padro
para a ocorrncia.
Por fim, aqui tambm so feitas estratificaes que tem por objetivo demonstrar o
universo de chamadas geradas e conciliadas com CDRs dos pontos de controle da tarifao e
faturamento.
So questionamentos a serem respondidos:

chamadas por diferena de valor;

chamadas por degrau tarifrio (telefonia fixa) ou valor da comunicao

(telefonia mvel);

chamadas por tipo de tarifa e tipo de chamada;

chamadas por tipo de tarifa e por tipo de dia;

chamadas por tipo de tarifa e degrau.Todos os questionamentos e requisitos

aqui relacionados serviro de base para o trabalho a ser realizado nos prximos
captulos, buscando atender os requisitos de forma a responder todos os
questionamentos da equipe de auditores.

4.3 MODELAGEM DIMENCIONAL

43
Definidos os requisitos funcionais a serem atendidos, parte-se para a fase seguinte da
metodologia adotada, onde a especificao dos requisitos serve como base para a construo
do modelo lgico-dimensional que armazenar as informaes capazes de responder os
questionamentos realizados.
Um dos primeiros passos desta atividade identificar os assuntos (data marts) e as
dimenses apontadas pelo levantamento de requisitos. Por fim, tenta-se estabelecer um
relacionamento entre estas duas entidades.
No levantamento realizado fica clara a existncia de dois assuntos principais: a anlise
das chamadas de teste e a anlise de chamadas bilhetadas. Somente estes dois data marts
foram identificados exatamente por estar realizando-se um trabalho focado no processo de
anlise realizado, sem preocupar-se com outras atividades perifricas do processo e que
poderiam evidenciar outros assuntos importantes, mas no tanto como a atividade fim do
produto.
Foram identificadas tambm uma srie de dimenses que auxiliariam diretamente o
processo de anlise. Grande parte delas compartilhada entre os dois assuntos em questo:
data e a hora de incio, a origem e o destino, o pagador, o servio testado, o tipo de tarifao
empregado, o teste ao qual pertencem as chamadas e a operadora de longa distncia escolhida.
A anlise de chamadas de teste por sua vez, ainda necessita de informaes como a
data e a hora de incio previstas e registradas no destino; o status final da chamada previsto e
o real, e o registrado na origem e no destino.
Por fim, a anlise de chamadas bilhetadas ainda exige as informaes de data e hora de
incio registradas pela operadora, informaes de conciliao das chamadas com os pontos de
controle, a central bilhetadora responsvel pelo registro da chamada e as informaes da rota
de entrada e rota de sada utilizadas por esta central.

44
Boa parte destas dimenses influenciar diretamente na resposta aos questionamentos
realizados e que devem ser respondidos. Outras por sua vez tem carter informativo e servem
como suporte e auxlio durante a anlise exploratria dos dados.
A seguir, o quadro 1 apresenta a matriz de relacionamento entre os data marts e as

Chamada de
Teste
Chamada
Bilhetada

X X X X X X
X X X

X X X
X

Conciliao

Rota Sada

Rota Entrada

Bilhetadora

Servio

Tarifao

Teste

Operadora

Status Chamada

Status Destino

Status Origem

Status Previsto

Hora Central

Hora Destino

Hora Origem

Hora Prevista

Data Central

Data Destino

Data Origem

Data Prevista

Pagador

Destino

Origem

dimenses coletadas na anlise de requisitos.

X X X X X X X X
X

X X X X X X X X

Quadro 1 Matriz de relacionamento entre os data marts e as dimenses coletadas na anlise de

requisitos.
Fonte: O autor.

Seguindo a metodologia, iniciamos os quatro passos propostos para a identificao de

qualquer tabela de fatos.
O primeiro passo consiste em escolher os data marts que sero implementados em um
primeiro momento, respeitando as prioridades estabelecidas pelo cliente. Neste caso foram
identificados dois assuntos que tero de ser tratados para atender ao processo de anlise: as
Chamadas de Teste e as Chamadas Bilhetadas.
A segunda etapa define a granularidade a ser utilizada nos data marts. outro ponto
fundamental para o sucesso do projeto. Aqui foi selecionada a Chamada como gro das
tabelas de fatos. o nvel mais detalhado possvel, possibilitando aos auditores anlises mais
refinadas de casos isolados que meream ateno especial.
O terceiro passo consiste em definir quais dimenses sero implementadas. Foram
escolhidas todas as dimenses relacionadas e apontadas durante o processo de levantamento

45
de requisitos, para que, da mesma forma como deseja-se uma grande refinamento na tabela de
fatos, quer-se um grande leque de possibilidade de cruzamento das informaes das
dimenses.
Para o data mart Chamada de Teste, foram selecionadas as dimenses Origem,
Destino, Pagador, Data Prevista, Data Origem, Data Destino, Hora Prevista, Hora Origem,
Hora Destino, Status Previsto, Status Origem, Status Destino, Status Chamada, Operadora,
Teste, Tarifao e Servio.
Para o data mart Chamada Bilhetada, foram selecionadas as dimenses Origem,
Destino, Pagador, Data Origem, Data Central, Hora Origem, Hora Central, Operadora, Teste,
Servio, Bilhetadora, Rota Entrada, Rota Sada e Conciliao.
Por fim, na quarta etapa so selecionados fatos, as medidas que iro compor o data
mart. Com base na definio de requisitos, sero listados as medidas de interesse para cada
um dos data marts.
Para o data mart Chamada de Teste, foram identificadas as medidas Quantidade,
Durao do Pedido, Durao na Origem, Durao no Destino, Durao Tarifada, Valor sem
Impostos, Valor com Impostos, Diferena do Horrio de Incio entre o Esperado e o
Registrado na Origem, Diferena do Horrio de Incio entre a Origem e o Destino, Diferena
da Durao Esperada para a Registrada na Origem e Diferena da Durao entre a Origem e o
Destino.
J para o data mart Chamada Bilhetada, foram identificadas as medidas Quantidade,
Durao Real do GRC, Durao Tarifada do GRC, Durao Real na Mediao, Durao
Tarifada na Tarifao, Durao Tarifada no Faturamento, Valor do GRC sem Impostos, Valor
do GRC com Impostos, Valor na Tarifao, Valor Calculado na Tarifao, Valor no
Faturamento, Valor Calculado no Faturamento, Quantidade de CDRs na Entrada da Mediao,
Quantidade de CDRs na Sada da Mediao, Quantidade de CDRs na Entrada da Tarifao,

46
Quantidade de CDRs na Sada da Tarifao, Quantidade de CDRs no Faturamento e
Quantidade de Fatias de CDR na Mediao.
De posse destas informaes, j possvel definir o diagrama da modelagem
dimensional que representa os fatos identificados.
A Fig. 5 a seguir representa o diagrama do fato Chamada de Teste e suas dimenses.

destino

status previsto

pagador

status origem

origem
status destino
data prevista
status chamada
data origem
data destino

chamada de teste
servico

hora prevista
teste
hora origem
hora destino

operadora
tarifacao

Figura 6 Diagrama do fato da camada de teste e suas dimenses

Fonte: O autor.

A Fig. 6 a seguir representa o diagrama do fato Chamada Bilhetada e suas dimenses.

47

bilhetadora

destino
pagador

rota entrada

origem

data grc

rota saida

chamada bilhetada

data mediacao

servico

teste

hora grc

operadora

hora mediacao

tarifacao

Figura 7 Diagrama do fato chamada bilhetada e suas dimenses

Fonte: O autor.

J na fase de planejamento do projeto, foram definidos como pr-requisitos a

utilizao do mesmo SGBD (Sistema Gerenciador de Banco de Dados) em que atualmente
esto armazenado os dados do banco de dados operacional.
Como se trata de um banco de dados relacional, o produto Oracle 8i, partiu-se a
definio do modelo fsico a ser implementado para os data marts em questo.
J estavam definidos os fatos e dimenses a serem tratados. Buscou-se ento por
ltimo identificar os atributos das dimenses. Utilizou-se novamente o levantamento de
requisitos como base a definio dos atributos.
Feita a definio inicial, o prximo passo foi validar estes atributos junto a equipe de
auditores, visando identificar atributos desnecessrios ou acrescentar novos atributos que
forneam vises diferenciadas dos resultados, possibilitando melhor refinamento das
pesquisas.

48
As solicitaes foram atendidas, tendo o modelo final sido validado junto ao grupo de
trabalho.
O modelo fsico resultante de todo este trabalho pode ser visto na Fig. 7 que se segue.
data

hora

data_id: NUMBER(6)

hora_id: NUMBER(6)

ano: VARCHAR2(4)
mes: VARCHAR2(2)
ano_e_mes: VARCHAR2(7)
dia: VARCHAR2(2)
ano_mes_e_dia: VARCHAR2(8)
tipo_de_dia: VARCHAR2(7)
tipo_de_dia_reduzido: VARCHAR2(3)
dia_da_semana: VARCHAR2(13)
dia_da_semana_reduzido: VARCHAR(3)

hora: VARCHAR2(2)
hora_por_extenso: VARCHAR2(3)
minuto: VARCHAR2(2)
hora_e_minuto: VARCHAR2(5)
segundo: VARCHAR2(2)
hora_minuto_e_segundo: VARCHAR2(8)

chamada_ de_ teste

assinante_id_origem: NUMBER(6)
assinante_id_destino: NUMBER(6)
assinante_id_pagador: NUMBER(6)
data_id_pedido: NUMBER(6)
hora_id_pedido: NUMBER(6)
status_id_pedido: NUMBER(6)
data_id_origem: NUMBER(6)
hora_id_origem: NUMBER(6)
status_id_origem: NUMBER(6)
data_id_destino: NUMBER(6)
hora_id_destino: NUMBER(6)
status_id_chamada: NUMBER(6)
servico_id: NUMBER(6)
tarifacao_id: NUMBER(6)
operadora_id: NUMBER(6)
teste_id: NUMBER(6)

status
status_id: NUMBER(6)
grupo_de_status: VARCHAR2(2)
status_reduzido: VARCHAR(2)
status_e_motivo: VARCHAR(4)
status_por_extenso: VARCHAR(20)

assinante
assinante_id: NUMBER(6)
rede_proprietaria: VARCHAR(50)
area_tarifaria_stfc: VARCHAR(4)
area_tarifaria_smp: VARCHAR(2)
tipo_do_terminal: VARCHAR(5)
tipo_do_contrato: VARCHAR(8)
deslocamento: VARCHAR(4)
grc_nome: VARCHAR(50)
grc_tipo_de_porta: VARCHAR(50)
pais: VARCHAR(30)
estado_sigla: VARCHAR2(2)
estado_nome: VARCHAR(30)
municipio: VARCHAR(100)
bilhetadora_nome: VARCHAR(30)
bilhetadora_tecnologia: VARCHAR(50)
central_local_nome: VARCHAR(30)
central_local_tecnologia: VARCHAR(50)
ddd: VARCHAR2(2)
prefixo: VARCHAR2(4)
ddd_e_prefixo: VARCHAR2(6)
numero: VARCHAR2(10)

quantidade: NUMBER(2)
duracao_do_pedido: NUMBER(7)
duracao_na_origem: NUMBER(7)
duracao_no_destino: NUMBER(7)
duracao_tarifada: NUMBER(7)
valor_sem_impostos: NUMBER(15,5)
valor_com_impostos: NUMBER(15,5)
diferenca_hora_pedido_origem: NUMBER(7)
diferenca_hora_origem_destino: NUMBER(7)
diferenca_duracao_pedido_orige: NUMBER(7)
diferenca_duracao_origem_desti: NUMBER(7)
operadora

servico

operadora_id: NUMBER(6)

servico_id: NUMBER(6)

discado_com_csp: VARCHAR2(3)
operadora_csp: VARCHAR2(2)
operadora_nome: VARCHAR2(50)

tipo_de_chamada: VARCHAR2(6)
tipo_dos_terminais_envolvidos: VARCHAR2(20)
servico_nome: VARCHAR2(50)
servico_bilhetado: VARCHAR2(3)
faturado_por_servico_medido: VARCHAR2(3)

tarifacao

teste

tarifacao_id: NUMBER(6)

teste_id: NUMBER(6)

degrau_ou_vc: VARCHAR2(3)
tipo_de_tarifa_reduzido: VARCHAR2(1)
tipo_de_tarifa: VARCHAR2(20)

grupo_de_teste: VARCHAR2(255)
teste_nome: VARCHAR2(255)

Figura 8 Modelo fsico do fato chamada de teste

Fonte: O autor.

O modelo fsico resultante do fato chamada bilhetada mostrado a seguir, na Fig. 8.

49
data

rota

bilhetadora

data_id: NUMBER(6) NOT NULL

rota_id: NUMBER(6) NOT NULL

bilhetadora_id: NUMBER(6) NOT NULL

ano: VARCHAR2(4) NOT NULL

mes: VARCHAR2(2) NOT NULL
ano_e_mes: VARCHAR2(7) NOT NULL
dia: VARCHAR2(2) NOT NULL
ano_mes_e_dia: VARCHAR2(8) NOT NULL
tipo_de_dia: VARCHAR2(7) NOT NULL
tipo_de_dia_reduzido: VARCHAR2(3) NOT NULL
dia_da_semana: VARCHAR2(13) NOT NULL
dia_da_semana_reduzido: VARCHAR(3) NOT NULL

rota_nome: VARCHAR2(10) NOT NULL

bilhetadora_nome: VARCHAR2(30) NOT NULL

bilhetadora_tecnologia: VARCHAR2(50) NOT NULL

hora
hora_id: NUMBER(6) NOT NULL
hora: VARCHAR2(2) NOT NULL
hora_por_extenso: VARCHAR2(3) NOT NULL
minuto: VARCHAR2(2) NOT NULL
hora_e_minuto: VARCHAR2(5) NOT NULL
segundo: VARCHAR2(2) NOT NULL
hora_minuto_e_segundo: VARCHAR2(8) NOT NULL

assinante
assinante_id: NUMBER(6) NOT NULL
rede_proprietaria: VARCHAR(50) NOT NULL
area_tarifaria_stfc: VARCHAR(4) NOT NULL
area_tarifaria_smp: VARCHAR(2) NOT NULL
tipo_do_terminal: VARCHAR(5) NOT NULL
tipo_do_contrato: VARCHAR(8) NOT NULL
deslocamento: VARCHAR(4) NOT NULL
grc_nome: VARCHAR(50) NOT NULL
grc_tipo_de_porta: VARCHAR(50) NOT NULL
pais: VARCHAR(30) NOT NULL
estado_sigla: VARCHAR2(2) NOT NULL
estado_nome: VARCHAR(30) NOT NULL
municipio: VARCHAR(100) NOT NULL
bilhetadora_nome: VARCHAR(30) NOT NULL
bilhetadora_tecnologia: VARCHAR(50) NOT NULL
central_local_nome: VARCHAR(30) NOT NULL
central_local_tecnologia: VARCHAR(50) NOT NULL
ddd: VARCHAR2(2) NOT NULL
prefixo: VARCHAR2(4) NOT NULL
ddd_e_prefixo: VARCHAR2(6) NOT NULL
numero: VARCHAR2(10) NOT NULL

chamada_ bilhetada
assinante_id_origem: NUMBER(6) NOT NULL
assinante_id_destino: NUMBER(6) NOT NULL
assinante_id_pagador: NUMBER(6) NOT NULL
data_id_grc: NUMBER(6) NOT NULL
hora_id_grc: NUMBER(6) NOT NULL
rota_id_entrada: NUMBER(6) NOT NULL
rota_id_saida: NUMBER(6) NOT NULL
bilhetadora_id: NUMBER(6) NOT NULL
servico_id: NUMBER(6) NOT NULL
conciliacao_id: NUMBER(6) NOT NULL
data_id_mediacao: NUMBER(6) NOT NULL
hora_id_mediacao: NUMBER(6) NOT NULL
operadora_id: NUMBER(6) NOT NULL
tarifacao_id: NUMBER(6) NOT NULL
teste_id: NUMBER(6) NOT NULL

conciliacao
conciliacao_id: NUMBER(6) NOT NULL
possui_cdr_saida_mediacao: VARCHAR2(3) NOT NULL
possui_cdr_entrada_tarifacao: VARCHAR2(3) NOT NULL
possui_cdr_entrada_mediacao: VARCHAR2(3) NOT NULL
possui_cdr_saida_tarifacao: VARCHAR2(3) NOT NULL
possui_cdr_faturamento: VARCHAR2(3) NOT NULL

tarifacao
tarifacao_id: NUMBER(6) NOT NULL
degrau_ou_vc: VARCHAR2(3) NOT NULL
tipo_de_tarifa_reduzido: VARCHAR2(1) NOT NULL
tipo_de_tarifa: VARCHAR2(20) NOT NULL

quantidade: NUMBER(2) NOT NULL

duracao_real_grc: NUMBER(7) NOT NULL
duracao_tarifada_grc: NUMBER(7) NOT NULL
duracao_real_mediacao: NUMBER(7) NOT NULL
duracao_tarifada_tarifacao: NUMBER(7) NOT NULL
duracao_tarifada_faturamento: NUMBER(7) NOT NULL
valor_grc_sem_impostos: NUMBER(15,5) NOT NULL
valor_grc_com_impostos: NUMBER(15,5) NOT NULL
valor_tarifacao: NUMBER(15,5) NOT NULL
valor_calculado_tarifacao: NUMBER(15,5) NOT NULL
valor_faturamento: NUMBER(15,5) NOT NULL
valor_calculado_faturamento: NUMBER(15,5) NOT NULL
qtd_cdrs_entrada_mediacao: NUMBER(2) NOT NULL
qtd_cdrs_saida_mediacao: NUMBER(2) NOT NULL
qtd_cdrs_entrada_tarifacao: NUMBER(2) NOT NULL
qtd_cdrs_saida_tarifacao: NUMBER(2) NOT NULL
qtd_cdrs_faturamento: NUMBER(2) NOT NULL
qtd_fatias_cdr_mediacao: NUMBER(2) NOT NULL

teste
teste_id: NUMBER(6) NOT NULL
grupo_de_teste: VARCHAR2(255) NOT NULL
teste_nome: VARCHAR2(255) NOT NULL

operadora
operadora_id: NUMBER(6) NOT NULL
discado_com_csp: VARCHAR2(3) NOT NULL
operadora_csp: VARCHAR2(2) NOT NULL
operadora_nome: VARCHAR2(50) NOT NULL

servico
servico_id: NUMBER(6) NOT NULL
tipo_de_chamada: VARCHAR2(6) NOT NULL
tipo_dos_terminais_envolvidos: VARCHAR2(20) NOT NULL
servico_nome: VARCHAR2(50) NOT NULL
servico_bilhetado: VARCHAR2(3) NOT NULL
faturado_por_servico_medido: VARCHAR2(3) NOT NULL

Figura 9 Modelo fsico do fato chamada bilhetada

Fonte: O autor.

Tendo sido aprovada a modelagem conceitual realizada, foram iniciados os trabalhos

de operacionalizao do ambiente, etapa esta que ser vista a seguir.

4.4 IMPLEMENTAO DO MODELO PROPOSTO

A implementao do modelo proposto iniciou-se j com alguns pr-requisitos e

informaes definidas.
O ambiente onde seriam implementados e operacionalizados os data marts j havia
sido definido ainda na fase de planejamento do projeto, pois era uma premissa que fosse

50
utilizado o mesmo servidor e banco de dados onde atualmente encontra-se em execuo a
camada servidora do produto.
Outro ponto definido tambm na fase de planejamento eram as interfaces de
apresentao dos data marts. Era desejvel a utilizao de dois ambientes de desktop OLAP:
o MS Excel e a prpria interface cliente do produto, que possui um mdulo OLAP de
explorao de dados.
De posse destas informaes iniciais, se iniciou o planejamento das arquiteturas de
back room e front end dos data marts, j direcionadas tambm ao modelo proposto.

4.4.1 Arquitetura de back room

Uma das primeiras atividades relacionadas definio da arquitetura de back room foi
a de explorar a base de dados operacional com o auxlio dos administradores do banco de
dados, conhecendo a nica fonte de informaes de que se disporia.
Um dos objetivos era entender a dinmica de utilizao do banco de dados e as
atividades por ele desenvolvidas, uma vez que os processos de extrao, transformao, carga
e acesso aos data marts estariam sendo executados em paralelo ao banco de dados
operacional.
Ao final desta avaliao, foi traado um plano de aquisio das informaes, que pode
ser observado na Fig. 9 que se segue.

51

Figura 10 Plano de aquisio de informaes.

Fonte: O autor.

Considerando que h um nico sistema do qual obter informaes e que estar to

disponvel quanto os processos de extrao, optou-se por no criar uma rea de estagiamento
de dados propriamente dita. Devido ao volume e custo de acesso a algumas tabelas do banco
de dados operacional, uma cpia delas ser gerada a cada extrao, apenas com as
informaes necessrias ao processo, e seu tempo de vida ser igual ou menor ao de execuo
do processo de transformao. Este seria uma etapa da extrao de informaes das fontes de
dados.
A realizao desta cpia, desonerando em grande parte o processo, seguida da
continuao da extrao de informaes da base operacional de dados, agora de forma direta,
ao mesmo tempo em que a juno destas informaes passa pelo processo de transformao,
resultando em dados no formato correto para serem carregados em seus respectivos data
marts. Este passo consistiria na concluso do processo de extrao seguida da transformao
necessria aos dados.
O resultado destes passos ento deixado em uma rea de transferncia, onde podem
ser consultado e manipulados, com o objetivo de realizar a carga e modificaes necessrias
s dimenses e por fim a carga dos novos fatos.

52
O esquema de armazenamento planejado para todo este processo, pode ser observado
na Fig. 10 a seguir.

Figura 11 Esquema de armazenamento.

Fonte: O autor.

Uma vez que todo o ambiente (sistemas fonte e data marts) esto armazenados em
uma banco de dados relacional Oracle, optou-se por utilizar as ferramentas que o prprio
ambiente.
Para os processos da ETL (Extract, Transformation and Load), utilizar-se- a
linguagem SQL (Structured Query Language) na extrao, transformao e carga das
informaes, controlada por procedimentos escritos em PL/SQL, uma linguagem de
programao proprietria do Oracle utilizada para escrita de Stored Procedures,
extremamente eficiente para o fim aqui proposto.

53
Por fim, para controlar a periodicidade dos processos de ETL, se far uso dos Jobs
disponibilizados pelo Oracle, que nada mais so que agendas na quais se definem o
momento em que um determinado procedimento deve ser executado.
Devido a caractersticas independentes de cada um dos data marts aqui propostos,
convencionou-se que o data mart Chamada de Teste dever ser atualizado de hora em hora.
Em contrapartida, o data mart Chamadas Bilhetada ser atualizado uma vez ao dia, devido a
caracterstica de depender de informaes que so disponibilizadas pela operadora, o que
pode demorar algum tempo.

4.4.2 Arquitetura de front end

As interfaces de apresentao e acesso s informaes dos data marts tambm foram

um dos pr-requisitos do projeto, estabelecidos e conhecidos ainda na fase de planejamento.
Uma das interfaces seria o uso do aplicativo MS Excel, uma planilha eletrnica que
possui recursos de acesso a banco de dados.
A outra seria a utilizao de um mdulo do aplicativo cliente do produto, conhecido
como Pesquisa Avanada. Este mdulo composto por um conjunto de metadados, uma
interface de construo de consultas e uma interface de apresentao dos resultados das
consultas.
Conhecidas as ferramentas de apresentao, restou a tarefa de planejar a forma de
acesso destas aos data marts propostos.
Foi focado inicialmente o uso do aplicativo MS Excel, em teoria o mais prtico.
Este aplicativo possui um recurso denominado de Tabelas Dinmicas, uma interface OLAP de
cruzamento e explorao de informaes. Este recurso pode ser alimentado de informaes

54
sob diversas formas, dentre as quais atravs de consultas a um banco de dados ou
manipulando um cubo OLAP.
Para estes dois necessrio um outro componente anexo ao MS Excel, o MS Query,
pelo qual se pode construir consultas a bancos de dados de forma grfica, exportando o
resultado diretamente ao MS Excel ou construindo atravs da consulta um cubo OLAP que
ser mais tarde manipulado pelo aplicativo.
Para este caso, ento, ser necessrio fornecer acesso aos data marts para os usurios,
bem como as informaes de metadados para que o mesmo possa construir suas prprias
consultas. Para facilitar este trabalho, ser gerada uma tabela dinmica para cada um dos
assuntos, com todas as colunas, que poder ser atualizada a qualquer momento com apenas
um clique, atualizando as informaes desde a ltima carga.
Definidas as aes quanto a esta forma de apresentao, iniciou-se o planejamento de
como os data marts seriam acessados pela interface proprietria do produto.
O mdulo Pesquisa Avanada do Auditor.RA Client, constitui-se de uma estrutura de
metadados que informam quais dados esto disponveis para consulta no sistema e de que
forma eles devem ser acessados. As informaes de quais dados podem ser acessados so
utilizadas em uma interface grfica que permite ao usurio construir suas prprias consultas.
As informaes de acesso aos dados so utilizadas ao final do processo para construir
consultas SQL que retornem as informaes solicitadas pelo usurio. Por fim, o resultado
desta consulta pode ser exibido em forma de tabela ou servir de entrada para uma interface
OLAP, incorporada ao produto.
Fica claro ento que a estrutura de dimenses e fatos modelados ter de ser adicionada
estrutura de metadados do produto. Para que isto seja possvel, inicialmente o usurio
proprietrio do banco de dados operacional ter de ter visibilidade sobre as informaes
contidas nos data marts. Feito isto, o trabalho seguinte ser o de cadastrar todas as dimenses

55
e fatos no produto, permitindo assim que os auditores montem suas prprias consultas e as
manipulem no ambiente OLAP do prprio produto, sem necessitar recorrer a outras
ferramentas.
Desta forma, na Fig. 11 a seguir esquematizada a arquitetura de front end proposta
para este trabalho, representado as duas formas de acesso aos data marts.

Figura 12 Arquitetura de front end

Fonte: O autor.

4.5 APLICAO DO MODELO

Terminado o processo de anlise de requisitos e projeto de todo ambiente em suas

diversas atividades, da aquisio de dados a apresentao dos mesmos, todo o modelo foi
implementado e colocado em operao.
Em um primeiro momento as tabelas que acomodaro as dimenses e os fatos foram
criadas. Em seguida os procedimentos de carga das mesmas foram implementadas.

56
Uma carga inicial foi realizada para validao do modelo e dos procedimentos de
ETL. Logo aps, uma extrao permitiu verificar a qualidade das informaes confrontandoas com relatrios anteriores, verificando assim se as respostas podiam ser respondidas e se os
totais eram os mesmos, validando assim o modelo implementado.
Todas as linhas de cdigo geradas nesta etapa podem ser consultadas nos anexos ao
final deste trabalho.
Os resultados obtidos, por sua vez, podero ser observados no captulo a seguir.

57
5. RESULTADOS

Neste ponto, o esforo de modelagem e implementao do ambiente encontra-se

encerrado. Durante o processo, pequenas avaliaes dos resultados obtidos j eram validadas
junto ao grupo de auditores com o objetivo de se validar o modelo ora proposto. Ao final,
ento, espera-se que o ambiente possa responder aos questionamentos realizados ainda no
levanto de requisitos
Para isso, sero demonstradas aqui as resposta obtidas para alguns dos
questionamentos realizados, visando fornecer suporte a validao do modelo.
Como o DW foi desenvolvido com base em uma situao, utilizando as informaes
de um cliente real da empresa, as informaes aqui apresentadas que poderiam em algum
momento identificar este cliente foram alteradas, de modo a no permitir a associao dos
dados apresentados. Isto deve-se ao fato dos contratos de prestao de servios a tais clientes
possurem clusulas de confidencialidade.

5.1. REQUISITO ANLISE DE CHAMADA DE TESTE RESULTADOS OBTIDOS

Verificaremos aqui alguns resultados obtidos na anlise das chamadas de testes. As

tabelas a seguir atendem o primeiro requisito definido, implementado por intermdio do data
mart Chamada de Teste.
A Tabela 1 apresenta a quantidade de chamadas completadas e no completadas e a
respectiva representatividade de cada uma. Chamadas com Status da Chamada igual a
OK so consideradas chamadas devidamente completadas e as com Status da Chamada
igual a NOK so consideradas como no completadas.

58
Nesta empresa em estudo, tem-se ento, um total de 1773 chamadas, com 1415
(79,8%) chamadas completadas e 358 (20,2%) chamadas no completadas.
Status da Chamada
OK
NOK
Total geral

Quantidade Representatividade
1415
79,8%
358
20,2%
1773
100,0%

Tabela 1 Quantidade e representatividade das chamadas completadas e no completadas.

Fonte: O autor.

A Tabela 2, derivada das informaes da tabela anterior considerando-se apenas as

chamadas no completadas, apresenta uma viso dos maiores ofensores do completamento
das chamadas de teste. A viso obtida pelo Tipo do telefone de origem, que diz se o
terminal utilizado para fazer a chamada era um telefone fixo ou mvel (aparelho celular). So
mtricas novamente a quantidade de chamadas e a respectiva representatividade da mesma.
Percebe-se que neste ao, a maioria das chamadas no completadas (332 92,7%) so
originadas de telefone mvel, enquanto as chamadas no completadas oriundas de telefone
fixo foram apenas 26 (7,3%).

Tipo do telefone de origem

Fixo
Mvel
Total geral

Quantidade Representatividade
26
7,3%
332
92,7%
358
100,0%

Tabela 2 Ofensores do completamento de chamadas por caracterstica do terminal de origem.

Fonte: O autor.

Na Tabela 3 outro requisito de informao atendido, atravs da demonstrao da

variao da durao das chamadas completadas quando comparamos o valor programado com
o efetivamente realizado. Toma-se como regra que o valor registrado em segundos subtrado
do valor programado, tambm em segundos. Por isso, interpreta-se que diferenas negativas
indicam que a durao efetivamente registrada inferior a que foi programada, assim como

59
diferenas positivas indicam que a durao real ultrapassou o limite programado. A dimenso
utilizada foi a origem da chamada, atravs do atributo Municpio de Origem. So
consideradas para esta anlise somente as chamadas efetivamente completadas, sendo
novamente este resultado construdo sobre uma parte das informaes contidas na Tabela 1.
No caso estudado percebe-se que num total de 1415 chamadas, teve-se uma diferena
mdia de durao das chamadas realizadas de 0,2 segundos, indicando que a durao
efetivamente registrada, no geral, foi superior programada.

Municpio de Origem
Municpio 1
Municpio 2
Municpio 3
Municpio 4
Municpio 5
Municpio 6
Municpio 7
Municpio 8
Municpio 9
Municpio 10
Total geral

Quantidade
De
Chamadas
108
109
391
104
110
107
110
37
228
111
1415

Diferena
Diferena
Diferena
Mnima de
Mdia de
Mxima de
Durao
Durao
Durao
(em segundos) (em segundos) (em segundos)
0
0,0
0
0
0,0
0
-18
0,8
5
0
0,0
0
0
0,0
0
0
0,0
0
0
0,0
0
-3
3,8
4
-67
-0,8
3
0
0,0
0
-67
0,2
5

Tabela 3 Variao da durao programada frente a efetivamente realizada por municpio de origem.
Fonte: O autor.

Para responder ao questionamento de quantas chamadas foram realizadas entre cada

par de origem e destino, foi construda a Tabela 4. Nela apresentado o nmero de chamadas
realizadas completadas entre cada um dos municpios participantes dos testes, perfazendo, de
acordo com a tabela 1, um total de 1415 chamadas efetivamente completadas.

Total geral

Municpio 10

108
0
0
0
0
0
0
0 109
0
0
0
0
0
14
8 291 12 16 10 14
0
0
0 104
0
0
0
0
0
0
0 75
0
0
0
0
0
0
0 107
0
0
0
0
0
0
0 110
0
0
0
0
0
1
0
12 16 12 12 42 14 12
0
0
0
0
0
0
0
134 133 303 128 133 132 136

Municpio 9

Municpio 1
Municpio 2
Municpio 3
Municpio 4
Municpio 5
Municpio 6
Municpio 7
Municpio 8
Municpio 9
Municpio 10
Total geral

Municpio 8

Municpio 7

Municpio 6

Municpio 5

Municpio 4

Municpio 3

Origem

Municpio 1

Destino

Municpio 2

60

0
0
0 108
0
0
0 109
0
9 17 391
0
0
0 104
0 35
0 110
0
0
0 107
0
0
0 110
36
0
0
37
0 95 13 228
0
0 111 111
36 139 141 1415

Tabela 4 Nmero de chamadas realizadas e completadas por municpio de origem e destino.

Fonte: O autor.

[Complementar com novas tabelas e vises da Pesquisa Avanada do Auditor.RA

Client]

5.2. REQUISITO ANLISE DE CHAMADA BILHETADA RESULTADOS OBTIDOS

[Complementar com as tabelas e vises da Pesquisa Avanada do Auditor.RA Client

sobre o fato Chamada Bilhetada]

61
6. TRABALHOS FUTUROS

A busca por um melhor processo de anlise, mais rpido e automatizado, terminar

muitas vezes na necessidade de correo e evoluo dos modelos aqui propostos, atividades
inclusive que fazem parte da proposta de ciclo de vida de Kimball (1998).
Uma evoluo natural ser a agregao de novos data marts visando atender a novas
necessidades e servios que j existem ou viro a existir no produto.
Conhecidamente, o produto j possui capacidade de atender servios como o de
chamadas locais que so aferidas, no por minutos de conversao registrados por bilhetes
conforme o fato Chamada Bilhetada aqui modelado, mas sim por um contador numrico
incrementado a cada intervalo de tempo pr-estabelecido, os pulsos, sendo que no h
informaes detalhadas sobre cada uma das chamadas, mas sim um valor numrico
correspondente ao consumo de um dado perodo.
Outro candidato a um novo data mart seria o processo de anlise de chamadas
originadas em telefones pblicos, onde o sistema de cobrana parecido com o da telefonia
local citado acima, sendo que o intervalo de tempo varia conforme o tipo de chamada
realizada: local, interurbana ou internacional, se para telefone fixo ou mvel e assim por
diante. H uma cadncia para cada um dos tipos de chamadas.
A telefonia celular tambm traz um grande leque de servios diferenciados, se
comparado a telefonia fixa. Um deles o servio de mensagens de texto, que tambm poderia
originar um novo data mart, uma vez que a unidade aferida a mensagem, se ele chegou ao
destinatrio ou no e em quanto tempo ela chegou.
Por fim, visando a evoluo da apresentao de dados aos usurios finais, o acrscimo
de um ambientes web de OLAP para acesso aos dados agregaria valor ao produto, j que os
navegadores tornaram-se comuns a maioria dos computadores pessoais utilizados nas

62
empresas atualmente. Os prprios clientes poderiam de uma forma mais fcil, sem depender
de aplicativos instalados, acessar as informaes de resultados dos testes solicitados.

63
7. CONCLUSO

Este trabalho se props a auxiliar o grupo de auditores que utiliza o produto da

empresa a obter resultados e relatrios sobre os testes executados, permitindo avaliar a
qualidade das chamadas executadas e por fim a auditoria do processo de receita da operadora
no que toca as chamadas bilhetadas.
Foi ento fornecido ferramental atravs da construo de dois data marts, tendo estes
suprido as necessidades e requisitos definidos como escopo de atuao deste trabalho.
Logicamente, o acompanhamento e utilizao no dia-a-dia dos produtos aqui gerados,
apontaro para manutenes e evolues necessrias, naturais a qualquer processo.
Um dos maiores mritos, no entanto, o fato de o processo de extrao e preparao
dos dados necessrios ter sido automatizado, evitando assim desgastes e repeties excessivas
de procedimentos manuais e demorados de aquisio de informaes. E melhor, as interfaces
de apresentao destes dados foram reaproveitadas, minimizando o tempo de adaptao ao
novo modelo.
Outro ponto importante vem do fato que a implementao dos data marts aqui
propostos deu-se em um ambiente um pouco mais modesto, utilizando-se do mesmo servidor
fsico e do mesmo banco de dados relacional no qual o produto j executado atualmente.
No que a literatura da rea deponha em contrrio, mas geralmente se vislumbram ambientes
ideais com grandes servidores. Aqui se utilizou a estrutura j disponvel, gerando um baixo
custo de implementao, unindo o desejo de no gerar custos adicionais vontade de aplicar
as tcnicas de data warehousing ao problema proposto, obtendo-se resultados satisfatrios.
Por fim, a metodologia aqui utilizada foi adaptada, demonstrando ser ela efetiva e
malevel, guiando o desenvolvimento sem perder suas caractersticas. Isso demonstra tambm
a necessidade de adaptar-se os mtodos s situaes nas quais eles sero empregados. Estas

64
adaptaes se mostram principalmente necessrias em situaes no to ideais de
disponibilidade de recursos humanos, financeiros e materiais. Assim, aproveita-se a sua
essncia e suas melhores tcnicas sem gerar custos excessivos e projetos que no condizem
com o tamanho da empresa na qual se quer implement-lo, evitando uma resistncia inicial
por descrdito no processo.

65
8. REFERNCIAS BIBLIOGRFICAS

ANATEL. Glossrio Termos Tcnicos de Telecomunicaes. Disponvel em:

<http://www.anatel.gov.br/AJUDA/GLOSSARIO/DEFAULT.ASP>. Acesso em: 17 de maro
de 2004.

DE LUCCA, Sandro Daros. Identificao de problemas no fluxo de faturamento das

operadoras de telecomunicaes: uma aborgagem empregando lgica fuzzi e regras de
produo. 2002. 108 f. Dissertao (Mestrado em Cincias da Computao) Centro
Tecnolgico, Universidade Federal de Santa Catarina, Florianpolis, 2002.

HP. Washington Revenue Dept. transforms audit process with hp .NET Business
Inteligence Solution for tax compliance. Washington (USA), 2003.

FML SECURING BUSINESS. The Communications Risk Management: Yearbook 2003.

Northampton (USA), 2003.

INMON, W. H. Building the Data Warehouse. 3rd ed. New York: John Wiley & Sons, 2002.

KIMBALL, Ralph. The data warehouse lifecycle toolkit: expert methods for designing,
developing, and deploying data warehouses. New York: John Wiley & Sons, c1998. 771p.

______; ROSS, Margy. The Data Warehouse Toolkit: the complete Guide do Dimensional
Modeling. 2st ed. New York: John Wiley & Sons, 2002.

66
NEWTON,

Harry.

Newtons

telecom

dictionary:

the

oficial

dictionary

of

telecommunications & the Internet. 15 ed. New York: Miller Freeman Inc., 1999.

SORTICA, Eduardo. Redes de telecomunicaes, TMN e gerncia integrada de redes e

servios. 1. ed. Salvador: [s.n], 1999.

SOUZA, Adriano de. Filtragem em dados de fluxo contnuo: uma abordagem voltada s
prestadoras de servio telefnico fixo comutado. 2002. 75 f. Dissertao (Mestrado em
Cincias da Computao) Centro Tecnolgico, Universidade Federal de Santa Catarina,
Florianpolis, 2002.

THE PHILLIPS GROUP. Managing Successful Revenue Assurance. London, 2001.

67
9. BIBLIOGRAFIA

BERSON, Alex; SMITH, Stephen J. Data warehousing, data mining and OLAP. McGrawHill, c1997. 612p.

SELL, Denilson. Uma arquitetura para distribuio de componentes tecnolgicos de

sistemas de informaes baseados em data warehouse. 2001. 100 f. Dissertao (Mestrado
em Engenharia de Produo) Centro Tecnolgico, Universidade Federal de Santa Catarina,
Florianpolis, 2002.

SILVEIRA, Amlia (coord.). et al. Roteiro bsico para apresentao e editorao de teses,
dissertaes e monografias. 2. ed. rev., atual e ampl. Blumenau: Edifurb, 2004.

SOUZA, Nilmar de. Programa de avaliao institucional: uma aplicao na Universidade

do Vale do Itaja - UNIVALI. 2002. 166 f. Dissertao (Mestrado em Engenharia de
Produo) Centro Tecnolgico, Universidade Federal de Santa Catarina, Florianpolis,
2002.