tese 3,2 mb

Título

Canalização e Visualização de dados em Data Warehouse para

Call Centers

Edgar Alexandre Gertrudes Guerreiro

Dissertação para obtenção do Grau de Mestre em

Engenharia Informática e de Computadores

Júri

Presidente: Prof. José Tribolet

Orientadora: Prof.a Helena Galhardas

Vogal: Prof.a Maribel Alves

Setembro de 2008

ResumoA crescente exigência dos clientes ao interagirem com as organizações, bem como o aumento das

pressões competitivas entre elas, leva a que se procurem soluções que optimizem os seus processos

de negócio. Uma organização onde este facto ganha especial relevo é o Call Center. Ao lidar diari-

amente com um grande número de clientes, gera-se uma enorme quantidade de dados, que têm de

ser rapidamente analisados de um modo correcto, para que continuamente se possam melhorar as

operações, quer seja na redução de custos ou no aumento da qualidade dos serviços prestados.

Nesta tese é descrito o processo de optimização de um processo de Extracção, Transformação e

Carregamento (ETL) de dados, a criação de uma componente de visualização de dados (dashboards)

que providencie aos actores do Call Center informação de um modo facilitado e simples e o desenvol-

vimento de um cubo OLAP sobre o modelo multidimensional de um sistema de Business Intelligence

(BI). Estes módulos foram desenvolvido no âmbito de um sistema de BI enquadrado num projecto da

Link Consulting, CCDM (Call Center Data Mart) que visa facilitar os processos de tomada de decisão

nos call centers.

Com os módulos criados, avaliaram-se os processos de ETL, para aferir da performance da solução

criada e sua adaptabilidade aos requisitos do negócio. Devido às métricas de benchmark serem ainda

escassas neste tipo de processos, procurou-se usar frameworks genéricas, que avaliam o sistema

criado como um todo. Com esta avaliação, foi possível ainda estudar a robustez da ferramenta usada

na criação destes processos (Microsoft Integration Services).

Palavras-chave: Call Center, Business Intelligence, ETL, Dashboards, Microsoft Integration Servi-

ces.

i

AbstractThe growing demand of customers in their interactions with organizations, as well as the growing compe-

tition between these organizations, leads the search for solutions capable of optimizing the organizations

business processes. One of these organizations where this fact is especially relevant is the Call Center.

By daily dealing with a great number of clients, a huge amount of data is generated. This data has to be

rapidly and thoroughly analyzed, so that operations can be improved, by reducing costs or by improving

service quality.

In this master thesis is described the process of optimizing a extraction, transformation and load

process (ETL), the creation of the components responsible for the presentation of the information (dash-

boards) and the development of an OLAP cube, that retrieves data from the multidimensional model of a

Business Intelligence (BI) system. These modules were created on a BI system developed by Link Con-

sulting called CCDM (Call Center Data Mart) which had the objective of facilitate the decision making at

the call centers.

With al the modules created, the ETL processes were evaluated, to determine their performance and

adaptability to the business requirements. Due to the fact that benchmark tests, are still very limited

to ETL processes, we opted for the use of generic frameworks, that evaluated the system created as a

whole. With this evaluation it was still possible to study the adaptability of Microsoft Integration Services

in creating these type of processes.

Keywords: Call Center, Business Intelligence, ETL, Dashboards, Microsoft Integration Services.

ii

AgradecimentosEmbora uma tese de mestrado seja, na sua essência, um trabalho individual, existem contributos e

apoios que não podem deixar de ser referidos. Aproveito, assim, esta oportunidade para expressar os

meus mais sinceros agradecimentos:

Antes e acima de todos, à minha irmã, que apesar de ser uma espectacular e ocupada estudante

de direito, sempre se disponibilizou para me ajudar na melhoria do conteúdo da minha tese, através de

constantes leituras e sugestões, e sem as quais possivelmente não conseguiria ter terminado esta tese

dentro do prazo estipulado.

À professora Helena Galhardas, pela sua orientação e disponibilidade demonstradas ao longo da

duração da tese. É imprescindível destacar o seu constante esforço, através de críticas construtivas e

várias sugestões, de forma a que desse de mim o meu melhor e construísse a melhor tese possível,

que na minha opinião excederam em muito aquilo que lhe era exigido. Mesmo nos momentos em que

me era mais difícil ter reuniões presenciais, a professora encontrou sempre maneiras de continuar a

orientar-me de uma forma, que apenas posso classificar como soberba. Enquanto orientadora desta

tese, penso sinceramente que não poderia ter feito uma melhor escolha.

Ao Engenheiro João Damásio, Director da unidade de CRM & Business Intelligence da Link Con-

sulting e co-orientador, pela excelente forma como me enquadrou na equipa de trabalho, bem como na

sua disponibilidade para discutir formas de estruturar o meu trabalho e constante preocupação em que

os meus resultados fossem os melhores possíveis.

À espectacular equipa da Link Consulting, especialmente à unidade de Business Intelligence, que

me acolheu de uma forma soberba e que sempre esteve pronta para me ajudar e contribuir para a

melhoria do meu trabalho, bem como providenciar um ambiente de trabalho que penso será difícil

igualar em qualquer emprego futuro que venha a ter.

À minha família, pela sua ajuda nos momentos mais difíceis, por me fazer procurar em mim o melhor,

me motivar, e sem a qual seria completamente impossível ter terminado o trabalho.

Lisboa, 30 de Setembro de 2008

Edgar Alexandre Gertrudes Guerreiro

iii

Índice

Resumo i

Abstract ii

Agradecimentos iii

Lista de Figuras ix

Lista de Tabelas x

Lista de Acrónimos xi

1 Introdução 1

1.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Os Sistemas de Business Intelligence (BI) . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2.1 Extracção, Transformação e Carregamento de dados - ETL . . . . . . . . . . . . . 6

1.2.2 Data Warehouse e Data Marts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.2.3 Cubo OLAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.2.4 Data Mining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.2.5 Relatórios e Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.3 Objectivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.4 Tecnologias Existentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.5 Tecnologia usada e Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.5.1 Metodologia Seguida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.6 Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.7 Organização da Tese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2 Trabalho Relacionado 13

2.1 Ferramentas de BI para Call Centers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.1.1 Características das Ferramentas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.1.2 Classificação das Ferramentas de BI para Call Centers . . . . . . . . . . . . . . . 15

2.2 Benchmark em Fluxos de ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3 Metodologia ETL 25

3.1 Difusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.1.1 Estrutura de dados de Controlo na Difusão . . . . . . . . . . . . . . . . . . . . . . 29

3.2 Integração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.2.1 1a Fase - Junções dos campos das tabelas do ODS em vistas . . . . . . . . . . . 31

3.2.2 2a Fase - Agrupamentos e Cálculos . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.2.3 3a Fase - Carregamento dos dados nas tabelas do modelo multidimensional . . . 36

3.2.4 Estrutura de dados de Controlo na Integração . . . . . . . . . . . . . . . . . . . . 39

iv

3.3 Relatórios de Controlo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4 Indicadores e Dashboards 45

4.1 Indicadores de Negócio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.2 Modelo Multidimensional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.3 Cubo OLAP criado a partir do modelo multidimensional . . . . . . . . . . . . . . . . . . . 47

4.4 Dashboards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.4.1 Considerações sobre os Dashboards . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.4.2 Actores dos Dashboards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.4.3 Prototipagem dos Dashboards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.4.4 Primeiro protótipo em Microsoft Sharepoint 2005 Services . . . . . . . . . . . . . 49

4.4.5 Protótipo em Microsoft Sharepoint 2005 Services usando dados do modelo multi-

dimensional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5 Validação Experimental 53

5.1 Conjunto de dados utilizado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.2 Configuração do ambiente de testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.3 Fluxo ETL do trabalho desenvolvido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.4 Testes de Eficácia da solução de ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.4.1 Eficácia na robustez da solução - Percentagem de workflows ETL retomados com

sucesso após uma falha . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.5 Testes de Eficiência da solução de ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5.5.1 Tempo de execução da solução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5.5.2 Carga adicional de recursos consumidos durante a execução da solução . . . . . 62

5.6 Considerações sobre a solução de ETL desenvolvida . . . . . . . . . . . . . . . . . . . . 63

6 Conclusão 65

6.1 Trabalho Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Referências 69

7 Anexo - Conteúdo das fontes de dados 73

7.1 Fontes de Dados - CCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

7.2 Fontes de Dados - uCI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

7.3 Fontes de Dados - Gespluri (WFM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

8 Anexo - Indicadores de Negócio 77

8.1 Indicadores de Chamadas Inbound . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

8.2 Indicadores de Tempos (Times) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

8.3 Indicadores de Agentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

8.4 Indicadores de Campanhas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

8.5 Indicadores de KPI’s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

v

8.6 Indicadores Financeiros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

8.7 Indicadores de Chamadas Outbound . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

9 Anexo - Vista F_Times_uCI_V1 83

10 Anexo - Vista F_Times_uCI_V2 85

11 Anexo - Difusão das fontes de dados CCS 87

12 Dashboards 89

13 Anexo - Modelos Dimensionais 91

vi

Lista de Figuras

1.1 Arquitectura típica de BI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2 Metodologia de Data Warehousing proposta por Ralph Kimball. . . . . . . . . . . . . . . . 9

2.1 Características distintivas entre as ferramentas de BI analisadas. . . . . . . . . . . . . . . 17

2.2 Borboleta genérica de um workflow ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.1 Arquitectura do sistema CCDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.2 Metodologia do processo de ETL seguida . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.3 Fases da etapa de Integração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.4 Subconjunto do modelo multidimensional da DW, que corresponde à estrela da tabela de

factos F_Times_uCI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.5 Estrutura das tabelas de controlo usadas na Difusão . . . . . . . . . . . . . . . . . . . . . 30

3.6 Tuplo da tabela CTRL_Diffusions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.7 Interligação das várias fontes de dados usadas para criar a vista com todos os dados

relevantes que vão popular a tabela F_Times . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.8 Expressão algébrica que traduz um Inner Join. . . . . . . . . . . . . . . . . . . . . . . . . 32

3.9 Expressão algébrica que traduz um Inner Join entre as tabelas uCI_Thread e uCI_data_context 32

3.10 Expressão algébrica que traduz um Outer Join . . . . . . . . . . . . . . . . . . . . . . . . 32

3.11 Expressão algébrica que traduz um Left Outer Join . . . . . . . . . . . . . . . . . . . . . . 33

3.12 Expressão algébrica que traduz um Right Outer Join . . . . . . . . . . . . . . . . . . . . . 33

3.13 Expressão algébrica que traduz um Outer Join entre as tabelas uCI_thread e uCI_segment

da vista F_Times_uCI_V1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.14 Filtro aplicado à vista F_Times_UCI_V1 para retirar desta vista os campos cujo nome de

utilizador (usr_name) é nulo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.15 Formatação aplicada na vista F_Times_uCI_V1 para passar o campo duration de déci-

mas de segundo para segundos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.16 Vista F_Times_uCI_V1 após a primeira fase da Integração. . . . . . . . . . . . . . . . . . 35

3.17 Cálculos efectuados na segunda fase da etapa de Integração. . . . . . . . . . . . . . . . 35

3.18 Expressão de cálculo para obter os campos TotalCallTime, TotalTalkTime e TotalWait-

Time da vista F_Times_uCI_V2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.19 Vista F_Times_uCI_V2 resultante da segunda fase da Integração. . . . . . . . . . . . . . 37

3.20 Fluxo para popular a tabela de factos F_Times_UCI . . . . . . . . . . . . . . . . . . . . . 41

3.21 Estrutura das tabelas de controlo usadas na Integração. . . . . . . . . . . . . . . . . . . . 42

3.22 Excerto da tabela CTRL_DataLog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.23 Relatório de Controlo geral, onde se mostram todas as integrações e respectivas difusões. 43

3.24 Relatório de erros para a tabela de factos F_Times_UCI. . . . . . . . . . . . . . . . . . . 44

4.1 Primeiro protótipo realizado em Microsoft Sharepoint 2005 Services para o gestor de

contas inbound. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

vii

4.2 Primeiro protótipo realizado em Microsoft Sharepoint 2005 Services para o director de

call center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.3 Protótipo realizado em Microsoft Sharepoint 2005 Services para o gestor de contas in-

bound e devidamente ligado ao modelo multidimensional. . . . . . . . . . . . . . . . . . . 51

4.4 Protótipo realizado em Microsoft Sharepoint 2005 Services para o director de call center

e devidamente ligado ao modelo multidimensional . . . . . . . . . . . . . . . . . . . . . . 52

4.5 Protótipo realizado em Microsoft Sharepoint 2005 Services para o supervisor inbound e

devidamente ligado ao modelo multidimensional . . . . . . . . . . . . . . . . . . . . . . . 52

5.1 Workflow ETL da solução de ETL desenvolvida, seguindo a abordagem do esquema em

borboleta proposta por Vassiliadis, Karagiannis, Tziovara e Simitsis [1] . . . . . . . . . . 55

5.2 Estimativa do tempo necessário para processar a quantidade de dados gerada através

dos dias pelo sistema de ETL desenvolvido. . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.3 Percentagem de tempo dispendido em cada componente da solução ETL. . . . . . . . . 60

5.4 Percentagem de tempo dispendido em cada componente da solução ETL. . . . . . . . . 62

11.1 Fluxo ETL dos ficheiros CCS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

12.1 Protótipo realizado em Microsoft Sharepoint 2005 Services para o Gestor de conta out-

bound e devidamente ligado ao modelo multidimensional . . . . . . . . . . . . . . . . . . 89

12.2 Protótipo realizado em Microsoft Sharepoint 2005 Services para o Coordenador de call

center e devidamente ligado ao modelo multidimensional . . . . . . . . . . . . . . . . . . 90

12.3 Protótipo realizado em Microsoft Sharepoint 2005 Services para o supervisor outbound

e devidamente ligado ao modelo multidimensional . . . . . . . . . . . . . . . . . . . . . . 90


factos F_Agentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91


factos F_Calls_Inbound_CCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92


factos F_Calls_Inbound_uCI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92


factos F_Calls_Outbound . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93


factos F_Campaigns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94


factos F_Finances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95


factos F_KPIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95


factos F_Times_CCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

viii


factos F_Times_uCI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

ix

Lista de Tabelas

1.1 Principais KPI’s usados nos call centers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1 Características usadas na classificação das ferramentas de BI para call centers. . . . . . 13

2.2 Ferramentas de BI para Call Centers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3 Micro-actividades e correspondentes operadores do Microsoft Integration Services 2005. 21

3.1 Ligação entre as tabelas que formam a vista F_Times_uCI_V1 . . . . . . . . . . . . . . . 31

x

Lista de AcrónimosBI Business Intelligence

CCS Call Center Supervisor

CCDM Call Center Data Mart

DIP-BENCH Data Intensive Integration Process Benchmark

DW Data Warehouse

DM Data Mart

ETL Extract, Transform and Load

KPI Key Performance Indicator

ODS Operational Data Store

OLAP Online Analytical Processing

SAD Sistemas de Apoio à Decisão

SLA Service Level Agreement

SQL Structured Query Language

SI Sistemas de Informação

THALIA Test Harness for the Assessment of Legacy Information Integration Approaches

WFM Work Force Management

xi

1 Introdução

1.1 Motivação

Um call center1 2 [2] é composto por estruturas físicas, pessoas e onde chamadas telefónicas são

efectuadas (chamadas outbound) e/ou recebidas (chamadas de inbound). Dependendo do tamanho

do Call Center, este pode ter desde algumas dezenas até centenas de operadores telefónicos e várias

campanhas a decorrer em simultâneo. Cada campanha agrega um conjunto de chamadas com objec-

tivos comuns (por exemplo, a campanha de venda de um dado produto). O call center pode existir sob

a forma de uma parcela funcional de uma organização maior ou ser ele próprio uma organização in-

dependente, prestadora de serviços em regime de outsource a outras organizações. Em qualquer dos

casos, as chamadas são efectuadas com um conjunto bem definido de clientes. No caso do call center

operar em regime de outsource este conjunto é definido pela organização que contratou os serviços do

call center. Para além do tratamento de chamadas inbound e outbound, o call center também provi-

dencia serviços de help desk (ajuda/resolução de problemas de clientes), de resposta a cartas, faxes e

e-mails.

Normalmente, um call center utiliza tecnologias com o intuito de melhorar o mais possível a perfor-

mance das suas operações. Uma dessas tecnologias é a redistribuição automática de chamadas, onde

as chamadas de inbound e/ou outbound são atribuídas aos agentes, pela ordem em que são recebidas

ou realizadas. Outra tecnologia comum é a monitorização de chamadas, onde as mesmas são selec-

cionadas aleatoriamente e, depois, monitorizadas, de forma a assegurar que os agentes cumprem os

requisitos de qualidade definidos e, consequentemente, asseguram a satisfação do cliente [3][4].

Existem os seguintes actores com intervenção relevante num call center : Agentes, Supervisor de

Campanhas Inbound, Supervisor de Campanhas Outbound, Consultor Interno, Coordenador de Call

Center, Gestor de Contas Inbound, Gestor de Contas Outbound, Gestor de Recursos Humanos e

Gestor de Call Center. Os operadores ou agentes são quem efectua ou recebe as chamadas. Um

Supervisor de Campanhas Inbound supervisiona grupos de métricas (como o tempo de chamada) bem

como métricas globais de funcionamento do call center (como o número total de chamadas recebidas)

e compara-as com os SLA’s definidos com a organização que requereu os serviços do call center. Um

Supervisor de Campanhas Outbound, tal como o supervisor de campanhas inbound, faz a monitoriza-

ção de um grupo de agentes e suas métricas, mas neste caso das métricas associadas a chamadas

de outbound (por exemplo: número de vendas). Um Consultor Interno, por sua vez, ajuda na resolu-

ção de certos problemas (como a existência de um número baixo de chamadas por hora, para dar um

exemplo), os quais os supervisores de inbound e outbound não conseguem solucionar. Um Coorde-

nador de Call Center faz análises diárias às campanhas em execução, de forma a aferir o seu sucesso

ou insucesso (analisa, por exemplo, o número de vendas ou o tempo de resolução das chamadas de

1Embora o termo call center se refira sobretudo ao tratamento de chamadas inbound e outbound, tendo o termo evoluído para

a designação contact center, que reflecte o facto de existirem mais interacções a ocorrer do que apenas as chamadas, ao longo

desta tese será usado o termo call center indiferentemente, quer se trate de um call center ou contact center [2]2Na literatura por vezes o call center aparece referenciado como call centre e o termo contact center pode aparecer como

contact centre

1

inbound); ele pode, ainda, em situações excepcionais, resolver problemas associados aos operadores,

quando os supervisores não os consigam resolver. Um Gestor de Contas Inbound faz análises diárias

ou semanais dos SLA’s mais relevantes acordados com as organizações que requereram os serviços

do call center (por exemplo: tempo médio de chamada e taxa resolução de problemas na primeira cha-

mada) para um grupo de campanhas. Um Gestor de Contas Outbound também faz analise diárias ou

semanais de grupos de campanhas, mas sobre os SLA’s referentes a chamadas outbound (por exem-

plo: vendas e taxa de sucesso). Um Gestor de Recursos Humanos ocupa-se das métricas relacionadas

com os operadores (o número de operadores necessários por campanha ou a taxa de absentismo, por

exemplo). Finalmente, um Gestor de Call Center tem a seu cargo a análise da performance global do

call center (como o número de horas trabalhadas nas campanhas ou os tempos médios de chama-

das), tomando decisões que podem afectar as operações globais do call center, numa base semanal

ou mensal.

A organização 3 que requisita os serviços do call center define com este um conjunto de métricas,

geralmente denominado Service Level Agreement (SLA), de forma a controlar o bom funcionamento

do serviço efectuado pelo call center. Estas métricas correspondem a conjuntos de valores de indi-

cadores de negócio que devem ser atingidos pelo call center. Em sistemas de apoio à decisão, estes

indicadores de negócio são normalmente denominados Key Performance Indicators (KPI’s). Jonathan

Wu [5] define um KPI como sendo um conjunto de medidas pré-definidas que providenciam informação;

esta informação é usada depois para quantificar objectivos que reflectem a performance e estratégia

da organização. Ou seja, um bom KPI deve simultaneamente, indicar um dado resultado (Indicator ),

estar relacionado com a performance do negócio da organização (Performance) e ser relevante para o

processo de decisão (Key ) [6]. Por exemplo um bom KPI no âmbito dos call centers é a taxa do número

de vendas ou inquéritos efectuados. Este KPI indica o número de vendas ou inquéritos face à totalidade

das chamadas feitas em regime de outbound (Indicator ), mede a eficiência na venda de um produto ou

inquérito (Performance) e é um factor importante nas tomadas de decisões do call center (Key ).

A tabela 1.1 lista alguns dos KPI’s usados na maior parte dos call centers[3][7][8][9].

OS KPI’s da Tabela 1.1 estão classificados segundo quatro categorias: Nível de Serviço e Processa-

mento de Chamadas, Custo, Qualidade e Agentes. O Nível de Serviço e Processamento de Chamadas

descreve os aspectos directamente relacionados com as chamadas telefónicas. O Custo descreve os

KPI’s associados a métricas de custo bem como as vendas/inquéritos efectuados. A Qualidade refere-

se às capacidades dos agentes do call center e a métricas relacionadas com a satisfação dos clientes

que interagem com o call center. Os Agentes contêm todos os aspectos relativos aos agentes, nas

suas tarefas e rotinas diárias. Algumas das métricas mais importantes identificadas, de acordo com os

requisitos do call center são [3][7][8][9]:

• Taxa de abandono: número de chamadas que foram desligadas antes de chegarem a um agente;

• Tempo médio de conversação: o tempo médio que os agentes passam em conversação com os

clientes;

3Esta organização pode significar a organização que detém o call center ou que contrata os serviços do call center em regime

de outsource

2

Nível de Serviço & Proc. de Chamadas Métricas de Qualidade

-Tempo médio de conversação -Satisfação do cliente

-Tempo médio para terminar a chamada -Satisfação do Staff

-Tempo médio de processamento de chamada -Satisfação dos parceiros/distribuidores

-Taxa de Abandono -% Chamas que necessitam de nova interacção

-Tempo médio de atendimento -Taxa de retenção dos clientes

-Taxa de primeiras resoluções -Razões das chamadas

-% Chamadas atendidas nos primeiros x segundos -Conhecimento dos produtos

-Tempo em trabalho pós-chamada -Conhecimento Técnico

-% Chamadas Transferidas -Competências de comunicação

-# chamadas feitas/recebidas -Competências na resolução de problemas

-Taxa de Bloqueios

Custo Agentes

-Custo por chamada -Ocupação

-Custo por minuto -Rotatividade dos agentes

-Custo médio por venda -Absentismo

-Total de itens vendidos -Aderência ao Script

-Horas de treino

-Aderência

-Taxa de Comparência

-Pontualidade

Tabela 1.1: Principais KPI’s usados nos call centers.

• Tempo em trabalho pós-chamada: o tempo médio que os agentes levam a terminar uma chamada;

• Tempo médio de chamada: a combinação do tempo médio de conversação e tempo em trabalho

pós-chamada;

• Tempo médio de atendimento: o tempo médio que leva a atender uma chamada;

• Taxa de primeiras resoluções: percentagem de clientes que vêem os seus problemas resolvidos

na primeira chamada que fazem;

• Taxa de Bloqueios: a percentagem de clientes que não conseguem aceder ao call center num

dado momento devido a falta de recursos do call center (sinal de ocupado)

• Aderência: o tempo que o agente passa em trabalho, comparado com o tempo que é pago;

• Taxa de comparência: taxa de comparecência dos agentes, isto é, se o agente aparece para

trabalhar nos dias em que tem trabalho;

• Ocupação: define se o número de agentes é adequado para o volume de chamadas, isto é, o

tempo que passam ocupados em chamadas sobre o tempo total de trabalho (tempo ocupado em

chamadas e tempo livre);

• Custo por chamada: o custo por cada chamada efectuada;

3

• Rotatividade dos agentes: taxa de rotatividade dos agentes, isto é, número de saídas e entradas

sobre o número de agentes empregados no call center ;

Geralmente, o call center é o primeiro ponto de contacto entre a organização e o cliente, numa comu-

nicação que se faz nos dois sentidos: por um lado, os clientes recorrem ao call center para esclarecer

dúvidas e por outro, é através do call center que a organização entra muitas vezes em contacto com os

seus clientes. Nestas comunicações com os clientes gera-se um grande volume de informação. Esta

informação engloba: dados sobre os clientes (exemplo, histórico de compras, perguntas frequentes),

pormenores sobre as chamadas (tal como, tempos de conversação e tempo dispendido após conver-

sação para terminar a chamada) e determinados pormenores sobre os agentes que fazem a chamada

(exemplo, tempo dispendido em chamadas, horas de trabalho). Toda esta informação desorganizada e

apreendida dispersamente no call center deve depois ser devidamente processada e analisada à luz

dos KPI’s predefinidos. Note-se que, aqui, a exigência crescente dos clientes (que esperam ver as suas

dúvidas rapidamente respondidas) e o maior ritmo com que os principais indicadores de negócio têm

que ser monitorizados são determinantes para que tanto a quantidade de informação como a rapidez

com que esta tem de ser processada sejam cada vez maiores. Percebe-se assim, que a capacidade

de integrar e tratar esta informação de um modo rápido e coerente seja pontos fulcrais em qualquer call

center. A necessidade constante de tratamento de informação aliada ao seu grande volume leva a que

um sistema de Business Intelligence (BI) (ver secção 1.2) possa ajudar em muito as necessidades de

um call center. O uso de um sistema de BI no call center pode trazer as seguintes vantagens:

• Optimizar as operações diárias e minimizar os riscos operacionais, através da constante moni-

torização dos principais indicadores de negócio (por exemplo; tempo de chamadas) e decidir de

acordo com estes indicadores quais as acções mais apropriadas (por exemplo, o número ideal de

agentes que devem estar a trabalhar numa dada campanha).

• Melhorar a qualidade do serviço prestado/Relações com os clientes que telefonam para o call

center, assegurando que estes vêem as suas necessidades rapidamente resolvidas (por exemplo,

maior personalização da resposta e menor tempo de espera).

• Tornar a análise dos indicadores de negócio mais robusta e facilitada, através da análise de infor-

mação detalhada sobre os clientes (como episódios passados e hábitos de compra). Melhorando

a análise dos indicadores de negócio pode-se aperfeiçoar a aferição do estado do negócio (como

vendas dos produtos oferecidos e progresso de cada campanha em execução) [10] [3].

• Identificar os perfis de agentes que melhor se adaptam às necessidades do call center [11].

• Reduzir custos, através da detecção de possíveis problemas (exemplo, campanhas com anormal

número de vendas face aos SLA’s definidos), da utilização de um menor número de agentes e

aumento de lucros operacionais (exemplo, alterar certas campanhas para melhor corresponderem

às expectativas dos clientes) [3].

4

1.2 Os Sistemas de Business Intelligence (BI)

No final dos anos 80, graças ao aumento do poder de processamento e facilidade de conectividade

entre diferentes sistemas (por exemplo, o aumento do número de ferramentas com ligação via Web)

começaram a massificar-se nas empresas aquilo que se designavam como Sistemas de Apoio à Deci-

são (SAD). Estes sistemas, por sua vez, gradualmente foram chegando a um número cada vez maior

de utilizadores dentro das organizações. Os sistemas de apoio à decisão são descritos por Keen e

Scott-Morton como "sistemas que aliam as capacidades intelectuais de indivíduos às capacidades de

sistemas computacionais, para melhorar a qualidade das decisões tomadas"[12]. Em 1989, Howard

Dresner, analista da Gartner, face à proliferação de sistemas de apoio à decisão e suas metodologias,

criou um termo unificador, o Business Intelligence [13].

Jane Griffin, consultora na Deloitte, descreve este termo como "um sistema centrado no utilizador

para a exploração de dados, relações entre dados e tendências, de forma a melhorar o processo de

tomada de decisão", e acrescenta ainda "Isso envolve um processo interactivo de acesso aos dados

e a sua análise para tirar conclusões, fazer descobertas e comunicá-las, com o objectivo de criar uma

mudança positiva na organização"[14]. O BI é assim, hoje em dia, uma componente essencial nos

Sistemas de Informação (SI) das organizações. É o BI que permite aos utilizadores analisarem as suas

operações de negócio e procurarem formas de as optimizarem, reduzindo custos e aumentando lucros

[15] [16].

A figura 1.1 [17] mostra uma arquitectura típica de BI com as suas principias componentes. Um

processo de BI comporta geralmente quatro grandes fases:

Figura 1.1: Arquitectura típica de BI.

1. Os dados que se encontram nas Fontes de Dados vão ser ser submetidos a processos de Extrac-

5

ção, Transformação e Carregamento (processos ETL, ou seja Extraction, Transformation e Load).

A área onde estes dados são submetidos aos processos de ETL é normalmente denominada

Operational Data Store (ODS) ou Área de Retenção (ou Data Staging).

2. Os dados após serem submetidos a processos de ETL, obedecem a um modelo dimensional e

são armazenados em Data Marts e Data Warehouses.

3. Depois de armazenados nos Data Marts e Warehouse, os dados podem ser manipulados por

ferramentas de BI, de modo a permitir a sua visualização em relatórios ou cubos OLAP, e serem

ainda submetidos a processos de Data Mining.

4. As ferramentas de BI apresentam os dados devidamente analisados e transformados aos utiliza-

dores finais.

1.2.1 Extracção, Transformação e Carregamento de dados - ETL

A Área de Retenção (ou Data Staging Area ou Operational Data Store - ODS) é uma área de arma-

zenamento de dados, onde estes sofrem as alterações necessárias para serem, depois, carregados

na Data Warehouse. As alterações efectuadas aos dados são realizadas por processos de ETL. A

primeira etapa de um processo de ETL é a extracção dos dados das suas várias fontes para a área

de retenção. Depois dos dados serem extraídos, sofrem um conjunto de transformações. Exemplos de

transformações normalmente efectuadas são limpeza (por exemplo: correcção de erros ortográficos),

purgação (que consiste na eliminação dos campos que não vão ser usados), combinação de fontes de

dados (agregar dados que fazem sentido estar juntos em vistas unificadas) e criação de identificadores

únicos para os objectos que se armazenam nos modelos multidimensionais. Quando a transformação

dos dados está completa, estes são carregados na data warehouse [18].

1.2.2 Data Warehouse e Data Marts

Uma Data Warehouse é uma colecção de dados orientada a um assunto, integrada, variante no tempo e

não volátil. Estes dados são depois usados para análises [18]. Um Data Mart é um subconjunto da Data

Warehouse, focado num assunto específico ou área de negócio (por exemplo: Data Mart financeiro).

1.2.3 Cubo OLAP

OLAP, Online Analytical Processing, é um tipo de actividade que permite efectuar análises e extracções

de dados a fontes de dados, de um modo rápido e fácil [18] [19]. Um Cubo OLAP é uma estrutura que

possui dados derivados da Data Warehouse e permite uma rápida análise dos dados que esta contém,

permitindo a obtenção de informação útil para o negócio a partir destes dados (como seja a tendência

de vendas de um dado produto). Este cubo é constituído por dados numéricos, chamados factos,

que estão organizados segundo várias dimensões (por exemplo, uma companhia pode querer analisar

dados financeiros sobre um dado produto, período temporal, região). Estas dimensões podem ser

depois agregadas usando hierarquias (por exemplo, países, distritos, cidades). Apesar do nome cubo,

este tipo de estruturas possuem geralmente mais do que três dimensões de análise.

6

1.2.4 Data Mining

Um dos modos de melhorar a análise dos dados é através do uso de técnicas analíticas ou Data Mining,

que permitem descobrir conhecimento novo e potencialmente útil a partir dos dados. Data Mining pode

também ser a extracção de informação sobre tendências futuras em grandes volumes de dados [20].

1.2.5 Relatórios e Dashboard

A grande quantidade de dados disponíveis e a velocidade com que estes devem ser analisados num

processo de tomada de decisão requerem formas de os sumariar e simplificar a sua visualização,

de modo a monitorizar os principais KPI’s do negócio da organização em causa. Um dos modos de

apresentar os dados de um modo sumarizado e simples é através do uso de relatórios. Relatórios são

essencialmente vistas agregadas de dados relevantes para os processos de decisão. Um Dashboard

é "uma ferramenta de relatórios que consolida agregados de dados e disponibiliza métricas (medidas

comparadas com um objectivo) (...) num único ecrã para que a informação possa ser monitorizada

num rápido relance"[21]. Um dashboard pode ainda providenciar avisos, sugerir próximas acções e

sumarizar certas condições de negócio (como por exemplo, as margens de lucros de um dado negócio

e sua evolução). Os dashboards são normalmente dinâmicos, orientados para tecnologias Web e

fornecem a possibilidade de serem ligados a ferramentas analíticas [22][23].

1.3 Objectivos

O trabalho realizado está enquadrado no âmbito de um projecto de desenvolvimento de um sistema de

BI para call centers levado a cabo na Link Consulting [24] de nome CCDM (Call Center Data Mart) que

visa facilitar os processos de tomada de decisão nos call centers. Os objectivos de desenvolvimento

deste projecto foram:

1. Criação de um modelo multidimensional para os principais indicadores do negócio do call center

em questão.

2. Construção de um sistema de ETL eficaz, que extraísse os dados das respectivas fontes e os

canalizasse para o modelo multidimensional criado.

3. Visualização dos dados presentes no modelo multidimensional, nomeadamente a criação de um

conjunto de dashboards que permita a fácil monitorização de indicadores de negócio relevantes

por parte dos vários intervenientes nas operações do call center.

Esta tese focou-se principalmente no segundo e terceiro pontos enunciados.

No segundo ponto, Construção de um sistema de ETL, salienta-se a identificação dos dados re-

levantes, que necessitavam de ser integrados a partir da grande quantidade de dados disponível nos

sistemas fonte. Destaca-se ainda a determinação de como os dados integrados deviam ser transfor-

mados de forma a se calcularem os indicadores de negócio pretendidos pelo call center (fórmulas de

cálculo dos indicadores). O modo de cálculo é especialmente relevante pois implicou a necessidade

de se perceber claramente os indicadores pretendidos e como estes poderiam ser obtidos a partir dos

7

dados disponibilizados pelo call center. Realça-se também a criação dos fluxos na ferramenta Microsoft

Integration Services [25] que permitiam o cálculo destes indicadores e sua passagem para o modelo

multidimensional. Por fim é de destacar a optimização efectuada a este processo de ETL, onde se

procurou perceber a carga temporal e de recursos computacionais sobre o sistema, imposta por cada

módulo deste componente e de acordo diminuir o tempo de execução do processo, tornando-o mais

eficiente.

No terceiro ponto, Criação de um conjunto de dashboards, sublinha-se o cuidado na concepção de

dashboards que permitissem a visualização dos indicadores de uma forma rápida, simples, respon-

dendo às necessidades de quem os ia consultar e de acordo com as melhores práticas de desenho

destes componentes [26]. Sobre este ponto destaca-se ainda a criação de um cubo OLAP sobre o qual

os dashboards iam buscar a informação. A criação deste cubo permitiu não só a obtenção de informa-

ção por parte dos dashboards mais facilitada e rápida, como providenciou mecanismos aos utilizadores

de fazerem as suas próprias pesquisas de um modo simples.

1.4 Tecnologias Existentes

No mercado de BI existem várias ferramentas específicas para call centers. Existe também um número

considerável de ferramentas que facilmente se adaptam às necessidades de BI de um call center,

isto é, ferramentas de fabricantes, que não sendo exclusivas para o domínio do call center possuem

módulos específicos para este domínio. Dos fabricantes de ferramentas de BI específicas ou facilmente

adaptáveis para call centers destacam-se a Genesys, Avaya, Business Objects e Oracle de acordo

com estudos da Gartner [27] [28] [29] e Forrester Wave [30]. Embora cada call center tenha as suas

necessidades específicas no que diz respeito a sistemas de BI, as ferramentas aqui citadas suprimem

as necessidades da maioria dos call centers.

Apesar deste tipo de ferramentas ser bastante útil na construção de sistemas de BI para call centers,

elas possuem algumas desvantagens, nomeadamente:

• Preço elevado.

• Pouca documentação disponível, de forma gratuita, que facilite o processo de escolha de entre as

várias ferramentas existentes.

Na construção deste sistema de BI em que se concentrou esta tese, optou-se pelo desenvolvimento

de uma solução de raiz, ao invés de se recorrer a uma já existente. Na base desta decisão esteve,

essencialmente, o facto do cliente da solução não ter manifestado vontade na compra de uma destas

ferramentas.

1.5 Tecnologia usada e Metodologia

O processo de ETL e os dashboards para visualização de dados foram desenvolvidos, recorrendo a

tecnologia Microsoft, nomeadamente:

8

• Microsoft SQL Server 2005 [31] e módulo Integration Services 2005 [25] do SQL Server 2005

para a construção das componentes de ETL.

• Microsoft Sharepoint 2005 Services [32], módulo Microsoft Reporting Services 2005 [33] do SQL

Server 2005 e Microsoft Excel 2007 [34] para a construção dos dashboards.

Como base de desenvolvimento das soluções de Microsoft enunciadas, foi utilizado o Microsoft

Visual Studio 2005 [35].

1.5.1 Metodologia Seguida

A metodologia seguida no desenvolvimento desta solução seguiu em parte a definida por Ralph Kimball

[18]. Esta metodologia centra-se sobretudo no ciclo de vida de um projecto de Data Warehouse e

compreende três fases: a vertente que define o projecto do Data Warehouse, a vertente de gestão

do projecto e a vertente que explicita passo a passo quais as tarefas a desempenhar de forma a que

consigamos implementar correctamente a Data Warehouse. Na Figura 1.2 pode-se ver a metodologia

proposta por este autor. Como se pode observar nesta abordagem é essencial perceber os requisitos

do negócio, tais como as necessidades dos utilizadores, nomeadamente a rapidez com que precisam

de ter os dados e principais indicadores de negócio para tomada de decisões, factores importantes

tendo em conta as necessidades do call center [16].

Figura 1.2: Metodologia de Data Warehousing proposta por Ralph Kimball.

As fases de desenvolvimento da solução foram as seguintes:

1. Identificação dos principais indicadores de negócio (de acordo com os utilizadores do sistema)

e seu modo de cálculo, segundo o conhecimento adquirido sobre o negócio dos call centers. A

definição do modo de cálculo de cada um dos indicadores foi um processo que sofreu algumas

iterações, à medida que ia sendo validado.

2. Definição da arquitectura da solução de ETL e implementação desta arquitectura.

3. Definição das interfaces de cada um dos dashboards que correspondia às necessidades dos

actores identificados. Estas interfaces, pela impossibilidade de serem validadas directamente

com os utilizadores, foram validadas com especialistas da Link Consulting. Este foi um processo

iterativo, com constantes melhorias das interfaces desenvolvidas e consequentes validações.

9

4. Criação de um cubo OLAP sobre o modelo multidimensional existente.

5. Ligação dos dashboards ao cubo OLAP, já com os dados providenciados pela solução de ETL.

6. Validação experimental dos componentes desenvolvidos, com especial ênfase na componente

de ETL. Na componente de ETL procurou-se principalmente aferir da performance da solução

desenvolvida, no que diz respeito à capacidade de integrar e calcular grandes quantidades de

dados gerados pelo call center de uma forma eficiente e rápida (testes de bechmarking).

1.6 Contribuições

Dado que a tese se enquadrou num projecto de engenharia de BI, a primeira contribuição foi respon-

der aos objectivos enunciados na secção 1.3, ou seja desenhar e implementar o processo de ETL e

componente de dashboards.

Em segundo lugar, procedeu-se à avaliação do módulo de ETL, procurando-se optimizar este pro-

cesso, tornando-o mais eficiente e rápido. Ao avaliar este processo seguiu-se e extendeu-se uma

framework de avaliação de processos de ETL genérica, devido ao facto dos benchmarks deste tipo

de processos serem ainda escassos. Avaliou-se ainda o Integration Services do Microsoft SQL Server

2005 [25] como ferramenta de ETL. Utilizando o sistema de BI para call centers em causa como caso

de estudo, avaliou-se a capacidade do Microsoft Integration Services [25] em três vertentes:

1. expressividade dos operadores para desenhar o processo de ETL necessário;

2. eficiência do Microsoft Integration Services para tratar grandes volumes de dados; e

3. metodologia de ETL usada na Link Consulting [24].

Em terceiro lugar, elaborou-se um estudo que reflecte o estado da arte das ferramentas de BI com

aplicação em call centers. Este estudo encontra-se detalhado no Capítulo 2.

Finalmente, como consequência do modelo dimensional criado permite-se que através de ferramen-

tas como o Microsoft Excel 2007 [34], os utilizadores finais a que se destina o sistema criado possam

de um modo facilitado criar as suas próprias tabelas e gráficos com dados relevantes sobre o call center

onde operam. Permite-se assim que estes utilizadores não tenham de limitar a sua análise apenas aos

dashboards providenciados, podendo criar os seus próprios relatórios e dashboards se assim acharem

necessário.

1.7 Organização da Tese

Esta dissertação encontra-se organizada da seguinte maneira. O Capítulo 2 apresenta as principais

soluções de BI para call centers existentes no mercado. Neste capítulo apresenta-se ainda um estudo

sobre benchmarks de processos de ETL. O Capítulo 3 descreve a metodologia usada para construir

o processo ETL, tal como é utilizado na Link Consulting [24]. O Capítulo 4 apresenta os dashboards

desenvolvidos e explica as decisões tomadas na sua concepção. O Capítulo 5 reporta os resultados

dos testes efectuados sobre o processo de ETL construído no Microsoft Integration Services [25] e

discute as principais vantagens e desvantagens enquanto ferramenta de ETL, aplicada a este caso de

10

estudo. No Capítulo 6, são expostas as principais conclusões desta tese e possíveis desenvolvimentos

futuros.

11

2 Trabalho Relacionado

Este capítulo incide sobre dois tópicos que estão relacionados com o trabalho realizado. Primeira-

mente, são estudadas as ferramentas de BI para Call Centers disponíveis no mercado. Em seguida,

apresentamos um estudo sobre Benchmarks em fluxos de ETL. Ambos estes tópicos são importan-

tes no âmbito do trabalho desenvolvido. No que diz respeito à ferramentas de BI para Call Centers é

importante perceber quais as suas funcionalidades e quais as ferramentas que melhor se adaptam às

necessidades do call center a que a solução a desenvolver se destina. Quanto aos Benchmarks em

fluxos de ETL são importantes, pois é fundamental arranjar mecanismos que permitam aferir da perfor-

mance da componente de ETL da solução desenvolvida, para verificar se esta serve as necessidades

dos call centers.

2.1 Ferramentas de BI para Call Centers

2.1.1 Características das Ferramentas

Para classificar as ferramentas de BI disponíveis, tomam-se em consideração as características [36]

(ver tabela 2.1):

Funcionalidades Compatibilidade

-Dashboards -Sistemas Legados

-Data Mining (motor analítico) -Produtos/Tecnologias comuns nos Call Centers

-Data Mart -Produtos BI mais usados

-Relatórios Predefinidos -Standards da industria

-Acesso Via Internet

-Multi-plataforma/Integração Facilidade de Modificação

-Suporte Directo a consultas -Relatórios

-Gestão dos Recursos Humanos -Dashboards

-KPI’s pré-definidos

Facilidade de Uso Interface Gráfica

-Pelos criadores dos sistemas de BI -Graficamente Familiar

-Pelos utilizadores finais -Graficamente Apelativo

Serviços/Suporte do fabricante da ferramenta

Tabela 2.1: Características usadas na classificação das ferramentas de BI para call centers.

As funcionalidades, expressam as capacidades genéricas das ferramentas. Para dar um exemplo,

um determinado call center pode não necessitar da funcionalidade data marts, por esta já ter sido

implementada por outra ferramenta.

• Dashboards: os dashboards providenciados e suas componentes (por exemplo: gráficos disponi-

bilizados).

13

• Data Mining (motor analítico): as técnicas de data mining providenciadas (como sejam árvores de

decisão e clustering).

• Data Mart : se a ferramenta tem um repositório para guardar a informação relevante do call center.

• Relatórios Pré-definidos: os relatórios pré-definidos providenciados pela ferramenta para uso di-

recto com um esforço mínimo de alterações/adaptações às necessidades específicas do call cen-

ter (dois exemplos de relatórios pré-definidos são: Performance do Call Center, Performance dos

Agentes).

• Acesso via Internet : capacidade de aceder à ferramenta remotamente. Note-se que esta é uma

característica fundamental para um call center. De facto, o elevado número médio de empregados

justifica que o melhor modo de acederem a relatórios e dashboards é via uma interface web;

• Multi-plataforma/Integração: capacidade de integrar dados de múltiplas fontes, para reunir infor-

mação sobre o negócio do call center.

• Suporte Directo a consultas: capacidade de se fazerem consultas directas aos dados, via lingua-

gens específicas, como SQL.

• Gestão de Recursos Humanos: módulos que permitam a gestão dos recursos humanos (como

a previsão das necessidades do call center relativamente ao número de agentes que melhor se

adequam a uma certa campanha, por exemplo);

• KPI’s pré-definidos - o conjunto de KPI’s providenciados directamente pela ferramenta (por exem-

plo, os tempos de conversação e de chamada, as vendas, entre outros), os quais permitem uma

mais rápida instalação da ferramenta, através da simplificação no uso dos principais indicadores

monitorizados pelos call centers.

Compatibilidade: a capacidade que a ferramenta tem para se integrar com os sistemas legados

existentes no call center e com os principais vendedores de soluções para call centers disponíveis no

mercado. Note-se que é, também, tida em consideração a capacidade de implementação da ferramenta

dos standards da indústria. Também se tem em consideração se o vendedor da ferramenta é um dos

principais distribuidores deste tipo de soluções, de acordo com a pesquisa efectuada pelo Gartner

Research [29];

Facilidade de Modificação: a facilidade com que se podem alterar as características da ferramenta

na criação de relatórios e dashboards, por exemplo, de acordo com as necessidades do utilizador.

Facilidade de Uso: a facilidade com que a ferramenta é utilizada, quer pelos responsáveis do

desenvolvimento da solução de BI, quer pelos utilizadores finais desta;

Interface Gráfica: a interface gráfica da ferramenta diz respeito, principalmente, às componentes

dos dashboards (visto serem estas as mais contempladas nas representações gráficas). A interface

gráfica pode ser classificada de duas maneiras:

• Graficamente Familiar: se os dados apresentados pelos dashboards são de fácil leitura pelos

utilizadores finais e os componentes para a sua criação são facilmente entendidos.

• Graficamente Apelativo: se os dashboards apelam ao utilizador, através do uso de vários arte-

factos, que ao mesmo tempo que atraem a atenção do utilizador, não o distraem das principais

tarefas que está a realizar.

14

Serviços/Suporte do fabricante da ferramenta: os serviços providenciados pelo vendedor da

ferramenta (por exemplo: implementação da ferramenta de BI no call center e treino no uso da ferra-

menta).

2.1.2 Classificação das Ferramentas de BI para Call Centers

No estudo levado a cabo nesta tese, foram avaliadas dezanove ferramentas de BI para call centers,

ou que podem ser facilmente adaptadas para este propósito, devido a possuírem módulos específicos

para o domínio dos call centers. É importante salientar que algumas das características acima men-

cionadas, tal como a facilidade de uso ou de modificação, não foram exaustivamente testadas, visto

não possuirmos as ferramentas para experimentação. De um modo geral, a informação providenciada

pelos vendedores é muito limitada, principalmente no que se refere às componentes mais técnicas.

As ferramentas testadas podem ser consultadas na Tabela 2.2:

Ferramenta Empresa

Avaya IQ Avaya [37]

Business Objects Contact Center Analytics Business Objects [38]

AgentView Centergistics Solutions [39]

Envision Business Intelligence Envision [40]

Genesys Contact Center Software Genesys [41]

Inova Solutions Call Center Dashboard Inova Solutions Call Center Dashboard [42]

Contact Centre Solutions inDashboard inRound Innovations [43]

Latigent Cisco [44]

EyeOps LiveOps [45]

People Soft Service Dashboard Oracle [46]

Performance Management Performance Edge [47]

PilotWorks Pilot Software [48]

Right Now Reporting and Dashboards Right Now [49]

SpeedWare Call Center Solutions SpeedWare [50]

nVision Symmetrics [51]

Contact Center Solutions Vista Symon [52]

Seratel Transera [53]

Verint Contact Center Solutions Verint [54]

VPI Call Center Performance Dashboards VPI [55]

Tabela 2.2: Ferramentas de BI para Call Centers

Existe um largo número de soluções de BI para call centers, com especial ênfase na componente

dos dashboards. É importante, por isso, compreender as necessidades específicas de cada call center,

de forma a escolher a ferramenta que melhor as satisfaz. De facto, existem call centers que apenas

15

necessitam da funcionalidade de apresentação dos dashboards, orientando, por isso, a escolha da

ferramenta nesse sentido. Existem outros call centers que exigem soluções mais complexas, com mó-

dulos de data mining, data marts, gestão de recursos humanos e capacidades de integração com várias

plataformas e fontes de dados. Outros factores a considerar são os KPI’s providenciados directamente

pela solução, os relatórios pré-definidos e a facilidade de modificação e de uso.

É importante referir a existência de um conjunto de características comum às dezanove ferramentas:

acesso via web, dashboards, suporte dos principais KPI’s, um conjunto de relatórios pré-definidos,

interface gráfica e algum grau de modificação das componentes da ferramenta (relatórios, dashboards).

Este conjunto de características foi considerado como o mínimo essencial para que uma ferramenta de

BI suprima as necessidades mais básicas de um call center.

Numa primeira análise, foi encontrado um grande número de ferramentas (mais concretamente dez),

entre as dezanove estudadas, com poucas características relativamente ao número de funcionalidades,

compatibilidade e interface gráfica. Com estes dados, seleccionaram-se nove ferramentas, as quais fo-

ram, depois, submetidas a um segundo estudo mais detalhado. Na segunda análise, as características

usadas para distinguir as ferramentas foram: existência de data mart, motor analítico, serviços e suporte

providenciados, multiplataforma/integração, módulo de gestão de recursos humanos, aspecto visual e

produtos compatíveis. As nove ferramentas analisadas foram: Avaya IQ, Business Objects Contact

Center Analytics, Envision Business Intelligence, Genesys Contact Center Software, Inova Solutions

Call Center Dashboard, Oracle PeopleSoft Service Dashboards, Performance Edge Performance Ma-

nagement, Symmetrics nVision and Symon Contact Center Solutions Vista. O resultado da comparação

destas ferramentas utilizando as características acima mencionadas encontra-se na figura 2.1.

Na Figura 2.1, note-se que a coluna do Aspecto Visual refere-se à apresentação - mais ou menos

atractiva - dos dashboards da ferramenta, numa escala de 1 a 5 (sendo o 5, visualmente apelativo e o

1, pouco apelativo visualmente). É de referir que por restrições temporais esta classificação visual não

pôde ser efectuada com utilizadores de call center ou outros similares, pelo que esta classificação foi

efectuada individualmente, mas pensando sempre na óptica dos utilizadores deste tipo de soluções.

A coluna das Características Adicionais diz respeito a considerações sobre módulos adicionais ou

particularidades da ferramenta importantes de salientar (como por exemplo: módulos adicionais provi-

denciados). A coluna dos Produtos Compatíveis é referente a produtos que são compatíveis ou fáceis

de adaptar, para uso conjunto com a ferramenta em análise; para esta coluna foi tido em conta se o

fabricante da ferramenta é um dos principais fornecedores de ferramentas e materiais de call centers

(de acordo com o Gartner Research Group [29]). O conteúdo das restantes colunas é o seguinte:

• SIM- se a solução tem aquele módulo específico;

• SOLUÇÃO DO FABRICANTE - apesar da ferramenta não ter aquele módulo específico, o fabri-

cante da ferramenta tem soluções com este módulo, e logo a sua integração é relativamente fácil

(por exemplo, ainda que a ferramenta Business Objects Contact Center Analytics [38] não tenha

um data mart incluído, o fabricante da ferramenta possui data marts que podem ser ligados a esta

ferramenta);

• NÃO DISPONÍVEL - foi impossível obter informação sobre a característica em análise;

16

Figu

ra2.

1:C

arac

terís

ticas

dist

intiv

asen

treas

ferr

amen

tas

deB

Iana

lisad

as.

17

• NÃO - a ferramenta não possui aquele módulo.

Analisando a Figura 2.1 é possível identificar dois grupos de ferramentas:

• Grupo 1 - Ferramentas cuja interface gráfica vai de relativamente boa a muito boa e um número

de funcionalidades aceitável (Symon, Envision, Performance Edge, Inova Solutions);

• Grupo 2 - Ferramentas com uma interface gráfica que vai de relativamente boa a muito boa e um

grande número de funcionalidades (Oracle, Avaya IQ, Genesys, Symmetrics nVision, Business

Objects).

Comparando a figura 2.1 com o Quadrante Mágico de Gartner para Plataformas de Business Intelli-

gence [27], a ferramenta Business Objects [38] é uma das ferramentas que se destaca, providenciando

um bom número de funcionalidades aliada a uma boa interface gráfica. Isto indica que esta ferra-

menta pode ser uma boa escolha para a maior parte das necessidades do call center. Esta indicação

é reforçada pelo estudo da Forrester Wave Research em plataformas de relatórios de BI e análise (BI

Reporting And Analysis Platforms) onde a ferramenta Business Objects se destaca como uma das

soluções com uma forte estratégia e oferta[30].

É importante salientar que uma ferramenta como a Avaya IQ [37], que possui menos capacidades

gráficas que a Genesys [41] ou a Business Objects [38] e relativamente o mesmo número de funcio-

nalidades, não é uma escolha pior que estas, visto que esta escolha depende muito das necessidades

específicas do call center em questão. Da mesma forma que uma ferramenta como a Inova Solutions

[42], que tem menos funcionalidades que muitas das ferramentas analisadas, pode ser mais adequada

para um determinado call center que já tenha as restantes funcionalidades implementadas por ou-

tras ferramentas. Por outro lado, devido a restrições especiais - como monetárias ou temporais - ou

a determinadas especificidades dos requisitos pretendidos pelo call center, que não sejam facilmente

colmatados pelas ferramentas analisadas, por vezes, a resposta passa pela criação de uma solução de

BI específica para aquela situação [56].

2.2 Benchmark em Fluxos de ETL

Tal como referido na secção 1.2.1 os processos de ETL são uma parte integrante de qualquer sistema

de BI. Devido à sua importância dentro dos sistemas de BI, o número de ferramentas que disponibilizam

este tipo de processos tem vindo a aumentar. De entre as principais ferramentas que disponibilizam

processos de ETL, destacam-se a IBM, a Informatica, a Microsoft, a Oracle e a Business Objects, de

acordo com a Gartner Research [57]. Com o aumento do número deste tipo de ferramentas, aumen-

tam, também, o número de técnicas de desenho, de conjuntos de transformações e de linguagens para

modelar os processos de ETL, já que as ferramentas não seguem uma abordagem standard. Além

disto, aumenta cada vez mais o volume de dados que as organizações precisam de analisar. Torna-se,

por isso, importante perceber se face ao crescente volume de dados, é possível escalar as soluções de

ETL desenvolvidas, de forma a processarem um maior volume de dados com a máxima eficiência pos-

sível [58] bem como avaliar as soluções desenvolvidas, procurando meios de as melhorar. No entanto

apenas recentemente se começaram a denotar preocupações em analisar e optimizar os workflows

18

(isto é, a transição dos vários processos) de ETL como um todo (ao invés de se procurarem soluções

óptimas, mas específicas de cada ferramenta) bem como procurar modos de os tornar robustos con-

tra falhas [59] [1]. Tal como foi salientado no Relatório Lowell [60] é fundamental que se começam a

procurar maneiras de medir a performance de workflows ETL e definam benchmarks para este tipo de

processos. Em parte como resposta a este relatório, só agora começam a surgir métricas de Bench-

mark standards para os processos de ETL, levando a que só muito recentemente se tenham começado

a criar frameworks para experimentação destes.

Os benchmarks estudados nesta secção, e os únicos encontrados na literatura sobre workflows

ETL procuram seguir os princípios abordados por Gray para benchmarks de sistemas transaccionais e

bases de dados [61]:

• Deve ser relevante no domínio de sistemas de integração heterogéneos, tendo que ter os proces-

sos de integração mais comuns presentes nos vários sistemas de integração;

• Deve ser portável, isto é, independente das plataformas, quer a de integração, quer as plataformas

dos sistemas fonte e destino;

• Deve ser escalável de forma a poder ser aplicado a sistemas quer de grande ou pequena dimen-

são;

• Deve ser simples na sua execução e análise.

Vassiliadis, Karagiannis, Tziovara e Simitsis [1] propõem que se experimentem as soluções de ETL

desenvolvidas representando os processos de ETL de um modo comum e independente da ferramenta

onde os processos são desenvolvidos. Estes autores descrevem um workflow de ETL como um con-

junto de actividades que podem ser representadas por meio de grafos, que especificam a ordem das

extracções, transformações e carregamentos efectuados. Para explicar estes grafos, consideremos

dois tipos de entidades: os conjuntos de dados, que descrevem as fontes de dados usadas/criadas (por

exemplo, ficheiros e tabelas de modelos multidimensionais) e as actividades, que se referem a qual-

quer operação que recebe como entrada um conjunto de dados e sobre este realiza qualquer processo

de extracção, transformação ou carregamento. Assim formalmente um workflow ETL pode ser visto

como um grafo G(V,E), onde cada nó v pertencente a V é uma actividade ou conjunto de dados e cada

conjunto (a,b) pertencente a E, denota que b recebe dados de a para posterior processamento.

Estes autores [1] consideram que todos os sistemas de ETL são compostos por actividades de nível

micro (micro-level activities) e actividades de nível macro (macro-level activities). As actividades de

nível micro estão divididas em três categorias: Extracção; Transformação e Limpeza e Carregamento.

Para a actividade de Transformação e Limpeza os autores dividem estas três actividades nas seguintes

categorias operacionais:

• Operações ao nível da linha (Row-level operations) - operações localizadas sobre uma única

coluna de uma tabela;

• Operações de reencaminhamento (Router operations) - onde para cada dado de destino (output)

se decide para onde ele vai ser enviado;

• Operações de Grupo Unárias (Unary Grouper operations) - que transformam um conjunto de

linhas numa única linha;

19

• Operações Holísticas Unárias (Unary Holistic operations) - que efectuam transformações a todo

o conjunto de dados disponível;

• Operações Binárias ou N-árias (Binary or N-ary operations) - que combinam várias entradas numa

mesma saída.

Na Tabela 2.3 faz-se o mapeamento das actividades e operações aqui descritas com os operadores

disponibilizados pelo Microsoft Integration Services 2005 [25], que foi a ferramenta usada na constru-

ção do sistema de ETL abordado nas secções posteriores (ver Capítulo 3). Permite-se assim fazer o

mapeamento entre as micro-actividades descritas e os operadores que as permitem realizar usando o

Microsoft Integration Services 2005.

Os mesmos autores consideram ainda a existência de workflows de nível macro (macro level work-

flows) que descrevem o modo como as actividades individuais e os dados se conjugam para criar um

workflow complexo. Os autores introduzem o conceito de Borboletas ETL (Butterflies) (Ver Figura 2.2),

que descrevem workflows genéricos de ETL. A parte esquerda da borboleta diz respeito às actividades

de ETL típicas (extracção, transformação e carregamento). O centro da borboleta diz respeito à fonte

para onde os dados são canalizados, ou seja a DW. Finalmente a parte direita da borboleta diz respeito

às actividades que usam os dados da DW para relatórios e análises [1].

Figura 2.2: Borboleta genérica de um workflow ETL

Este benchmark pretende assim providenciar uma abordagem experimental, a ser usada para afe-

rir dos métodos ETL e respectivas ferramentas, no que diz respeito a um conjunto de medidas (ou

parâmetros) que abranjam o maior número possível de workflows.

Os autores dividem esta abordagem experimental em dois grandes objectivos que devem ser afe-

ridos: efectividade e eficiência. Na efectividade pretende-se aferir da disponibilidade dos dados, para

estarem actuais e completos aquando do seu uso em processos de tomada de decisão, pretende-se

ainda aferir da resistência do sistema a falhas ocasionais. Na eficiência pretende-se determinar a rapi-

dez de execução do workflow bem como os recursos por este consumidos.

Considerando a definição de workflows acima descrita, os autores propõem um conjunto de parâ-

metros que permitem configurar os workflows em borboleta, bem como um grupo limitado de medidas

importantes na monitorização da solução de ETL desenvolvida. Os parâmetros propostos para confi-

gurar os workflows criados são:

• tamanho do workflow, ou seja o número de nós do grafo;

20

Tabela 2.3: Micro-actividades e correspondentes operadores do Microsoft Integration Services 2005.

• estrutura do workflow, isto é, variação das actividades de cada nó e suas ligações;

• tamanho dos dados de entrada, que se traduz no número de registos dos ficheiros e bases de

dados dos sistemas fonte;

• probabilidade de ocorrerem falhas (como a solução parar o seu workflow normal de execução).

As medidas que devem ser monitorizadas e avaliadas relacionam-se com os dois principais objecti-

vos acima enunciados: efectividade e eficiência. As principais medidas de efectividade são:

• Medidas do grau de actualidade dos dados e sua completude:

– Percentagem de dados que violam as regras de negócio;

– Percentagem de dados que deviam ser colocados nos modelos multidimensionais mas não

foram.

• Medidas da capacidade de resistência a falhas:

– Percentagem de workflows retomados com sucesso após falhas.

As principais medidas de eficiência são:

21

• Velocidade de execução do processo:

– Tempo total para se completar o workflow ;

– Tempo total para se completar o workflow incluindo uma dada percentagem de falhas;

– Tempo médio de execução por tuplo.

• Recursos consumidos pela execução da solução:

– Mínimo, Máximo e Média de memória consumida pelo processo ETL nos sistemas fonte;

– Mínimo, Máximo e Média de memória consumida pelo processo ETL no modelo multidimen-

sional;

– Tempo necessário para efectuar um dado número de querys para o suporte de decisões ao

modelo multidimensional na presença do sistema de ETL desenvolvido.

– Tempo necessário para efectuar um dado número de querys para o suporte de decisões ao

modelo multidimensional na presença do sistema de ETL desenvolvido, mas considerando

falhas nos sistemas fonte ou no modelo multidimensional.

Procura-se com este benchmark estudar a solução de ETL como um todo, ao invés de procurar

medidas específicas para cada actividade integrante da solução. Providencia-se assim uma framework

comum que permite avaliar qualquer processo de ETL construído.

Böhm, Habich, Lehner e Wloka seguem uma abordagem semelhante para descrever uma framework

genérica para avaliação de workflows ETL [59]. Estes autores propõem uma framework de nome

DIP-Bench (Data Intensive Integration Process Benchmark). As principais diferenças deste benchmark

para o proposto por Vassiliadis, Karagiannis, Tziovara e Simitsis [1] prendem-se com as medidas de

avaliação da performance do benchmark e a definição de uma métrica específica de avaliação. As

medidas de performance são:

• Tamanho da fonte de dados;

• Tempo, onde se usam medidas de tempo abstractas representadas por tu, que correspondem a

0.5 milisegundos;

• Distribuição, que representa a distribuição dos valores das fontes de dados, que pode ir desde

uma distribuição uniforme até valores bastante dispares.

Por forma a determinar o custo de uma operação estes autores baseiam-se num modelo de custos com

as seguintes três categorias:

• Custos de comunicação, com os sistemas externos (por exemplo: atrasos na comunicação com

os sistemas fonte);

• Custos de gestão interna, como sejam, custos de processamento de instâncias do sistema;

• Custos de processamento, isto é, execução do workflow.

A partir destes três custos os autores propõem o uso de uma métrica que abranja todo os sistema e

que é dada pela soma de todos os custos normalizados do sistema em questão com a soma do desvio

médio positivo. A inclusão do desvio médio, deve-se a classificar com uma melhor pontuação, sistemas

com uma performance previsível (isto é, que não varie muito).

22

Por fim destaca-se ainda a framework THALIA , Test Harness for the Assessment of Legacy Infor-

mation Integration Approaches, uma das primeira frameworks de benchmark a aparecer como resposta

ao Relatório Lowell [60]. Esta framework providencia uma conjunto standard de queries a fazer a um

sistema e um conjunto de classificações a atribuir a este sistema em função dos resultados obtidos.

Esta framework é contudo menos genérica que as duas anteriores aqui apresentadas, visto não ter

em consideração a performance do processamento do sistema onde o workflow está a correr, conside-

rando apenas o número de queries respondidas correctamente e o esforço na integração das fontes de

dados.

23

3 Metodologia ETLEsta tese de mestrado inseriu-se num projecto a decorrer na Link Consulting [24] de nome CCDM - Call

Center Data Mart. Este projecto tem como objectivo a criação de um sistema de business intelligence

que sirva as necessidades de um call center. Este sistema pretende ser adaptável às mais várias

necessidades de cada call center, sendo genérico e modular o suficiente, para poder ser aplicado

na maioria dos call centers. Tendo sido desenvolvimento em torno do sistema Altitude [62], um dos

principais fornecedores de soluções para call centers, assegura-se que o sistema poderá ser facilmente

inserido na maior parte dos call centers existentes, sendo facilmente compatível com a maior parte do

software que estes usam.

A arquitectura do sistema onde esta tese se inseriu é a de uma arquitectura típica de BI, composta

pelos seguintes componentes:

1. Fontes de Dados - dados provenientes dos sistemas legados do call center ;

2. Processos de ETL - conjunto de Extracções, Transformações e Carregamentos, efectuadas sobre

os dados de origem;

3. Modelo Multidimensional - modelo onde os dados tratados nos processos de ETL vão ser arma-

zenados, segundo uma estrutura previamente definida (tabelas de factos e dimensões);

4. Cubo OLAP - cubo resultante do modelo dimensional, que agrega os dados existentes neste

modelo, segundo um conjunto de dimensões e métricas;

5. Dashboards - conjunto de dashboards criados a partir do Cubo OLAP anteriormente definido;

6. Utilizadores - os utilizadores que vão fazer uso dos Dashboards nos seus processos de tomada

de decisão.

O foco desta tese foi na melhoria dos pontos 2 e na construção dos pontos 3 e 4.

A Figura 3.1 mostra a arquitectura do sistema de BI criado.

De forma a melhor compreender os processos de ETL, os restantes capítulos serão dedicados

a esta temática. Antes de serem disponibilizados os dados para a sua exploração e utilização pelo

sistema de BI para call centers, estes têm de sofrer um processo de ETL (Extracção, Transformação e

Carregamento).

Nesta metodologia, esquematizada na Figura 3.2, distinguem-se duas grandes etapas. Na primeira

etapa, denominada Difusão, os dados são extraídos das fontes ( nos Anexos, capítulo 7 podem ser

consultadas as fontes de dados do sistema) e são armazenados num conjunto de tabelas, cujo es-

quema reflecte a estrutura dos ficheiros de origem. A este conjunto de tabelas chama-se normalmente

Operational Data Store (ODS) ou Repositório de dados operacionais. A segunda etapa tem o nome

de Integração e divide-se em três fases. Na primeira fase, são criadas vistas (recorrendo a junções

das tabelas do ODS) com o objectivo de integrar os dados origem de modo a facilitar a sua posterior

manipulação. Na segunda fase são efectuados os cálculos e agrupamentos sobre as vistas criadas

anteriormente. O resultado desta segunda fase é um conjunto de vistas que reflectem a estrutura do

modelo multidimensional. Na terceira fase, as vistas criadas são executadas de modo a inserir os regis-

tos no modelo multidimensional. Paralelamente, para controlar os mecanismos de Difusão e Integração,

são usados sistemas de controlo de forma a registar quaisquer anomalias durante as duas etapas e

25

Figura 3.1: Arquitectura do sistema CCDM

para registar quando as difusões e integrações foram efectuadas. A Figura 3.3 representa com maior

pormenor as 3 fases da etapa de Integração.

As próximas secções vão detalhar as diferentes fases da metodologia ETL. De forma a facilitar a

explicação e demonstração de exemplos, consideramos como exemplo de trabalho um dos modelos em

estrela do projecto de BI. Este modelo está centrado na tabela de factos F_Times_uCI e encontra-se

representado na Figura 3.4

Este modelo em estrela da Figura 3.4 além da tabela de factos F_Times_uCI, é composto pelas se-

guintes oito tabelas de dimensões: D_Agents, D_CallCenters, D_Clients, D_Supervisors, D_Teamleaders,

26

Figura 3.2: Metodologia do processo de ETL seguida

Figura 3.3: Fases da etapa de Integração

D_Times, D_Dates e D_Campaigns (ver secção 4.2). A tabela de factos F_Times_uCI contém medidas

sobre os vários tempos referentes às chamadas efectuadas no call center. As medidas armazenadas

são:

• TotalCallTime, que representa o tempo total das chamadas;

• TotalTalkTime, que representa o tempo total de conversação;

• TotalHoldTime, que representa o tempo total de espera do cliente durante a chamada;

• TotalWrapUpTime, que representa o tempo total que o agente levou a efectuar operações após

ter terminado a chamada;

• TotalWaitTime, que representa o tempo total na fila de espera;

• TotalWaitTimeOfReceived, que representa o tempo total em fila de espera das chamadas atendi-

das;

• Received, que representa o número de chamadas recebidas.

27

Figura 3.4: Subconjunto do modelo multidimensional da DW, que corresponde à estrela da tabela de factos

F_Times_uCI.

3.1 Difusão

Na fase da difusão, os dados dos sistemas fonte são canalizados para a ODS. Aqui, eles são colocados

em tabelas, que reflectem a estrutura dos objectos das fontes de dados de origem. Às tabelas onde os

dados dos sistemas fonte vão ser armazenados, adiciona-se depois um campo extra, o DiffusionID, que

vai desempenhar o papel de marcador da difusão dos dados. Este campo vai suportar os mecanismos

de controlo sobre a etapa de difusão.

Exemplo 3.1.1 Existe uma tabela de nome uCI_e_user que vai conter os dados provenientes do fi-

cheiro e_user do sistema uCI (que por sua vez provêm de uma tabela com nome homólogo do mesmo

sistema), cujo esquema está representado na secção 7.2. No ODS a principal alteração é a adição de

28

um campo adicional DiffusionID que vai servir como marcador da data em que a difusão foi feita e que

será usado em controlos posteriores.

Durante a extracção de dados, não é efectuada qualquer tipo de validação, remetendo-se estas

operações para fases posteriores. As chaves primárias e restrições que existem nos sistemas fonte,

embora conceptualmente sejam consideradas, não vão ser validadas nem colocadas implicitamente

nas tabelas do ODS. Estas chaves e restrições vão apenas servir como guia para as integrações que

vão ocorrer na próxima etapa (Integração), e na prática, não estarão presentes nas tabelas criadas

durante a difusão. É durante a Integração que se vão validar as restrições existentes entre as tabelas,

evitando-se assim que se realizem duas fases de verificações, durante a Difusão e, posteriormente

durante a Integração.

3.1.1 Estrutura de dados de Controlo na Difusão

De forma a implementar os mecanismos de controlo das difusões são utilizadas duas tabelas adicionais:

CTRL_Diffusions e CTRL_SourceData . A Figura 3.5 mostra a estrutura destas tabelas.

A tabela CTRL_Diffusions regista para cada uma das difusões efectuadas sobre as tabelas existen-

tes (na Figura 3.6 pode-se ver um dos tuplos desta tabela) os seguintes campos:

• DiffusionID - o ID de difusão das tabelas difundidas, que corresponde a um número único que

identifica uma dada difusão. Por exemplo, suponha-se que se vão realizar duas difusões sobre

ficheiros que contêm dados sobre os utilizadores do sistema CCDM, ou seja o ficheiro e_user. Ao

efectuar a primeira difusão sobre o ficheiro e_user, vai ser atribuído aos dados daí resultantes,

um identificador único na tabela uCI_e_user do ODS. Ao efectuar a segunda difusão sobre outro

ficheiro e_user, o DiffusionID atribuído a estes dados vai ser diferente do da primeira difusão.

Neste caso a tabela uCI_e_user do ODS vai conter dados referentes a duas difusões, algo que

pode ser visível através da observação do campo DiffusionID da tabela, que vai conter o número

atribuído aquando da realização da difusão.

• SourceID - o identificador da tabela que foi difundida, que consiste numa chave estrangeira para

a tabela CTRL_SourceData;

• DiffusionDate - a data a que os dados da tabela se referem. Caso essa data não exista este

campo não é preenchido. Por exemplo se o ficheiro diz respeito a dados do dia 01-02-2008, então

esta data será a data que representa a data de difusão, isto é a data em que os dados foram

gerados nos seus sistemas fonte.

• StartDate e EndDate - A data de inicio e fim da difusão respectivamente.

• Status - o Estado da difusão, que indica se a difusão teve sucesso ou não.

• DiffusedRows - o número de linhas que foram difundidas.

• IntegrationData - a data em que a tabela foi usada numa integração.

• Error - a indicação se ocorreu algum erro ou não (0 se não ocorreu erro e 1 se ocorreu algum

erro).

A tabela CTRL_SourceData possui os seguintes campos:

29

• SourceDataID - identificador único, que vai ser usado para identificar as tabelas do ODS.

• Source - nome do ficheiro usado na difusão para uma dada tabela do ODS.

• Data - nome das tabelas do ODS que vão conter os dados difundidos.

• Description - descrição dos dados das tabelas do ODS.

Na Figura 3.6, encontra-se representado um tuplo da tabela CTRL_Diffusions que diz respeito à

fonte de dados com identificador 10 (SourceID).

Figura 3.5: Estrutura das tabelas de controlo usadas na Difusão

Figura 3.6: Tuplo da tabela CTRL_Diffusions.

O conteúdo das tabelas de controlo da difusão pode ser usado para interrogações, de modo a iden-

tificar a existência de erros ou para elaborar relatórios para manter o histórico das difusões realizadas.

A secção 3.3 representa em maior detalhe os relatórios criados.

3.2 Integração

Uma vez difundidos os dados das tabelas fonte para o ODS, estes ficam disponíveis para serem inte-

grados. Na etapa de Integração os dados sofrem as transformações necessárias, tais como cálculos

e junções de várias tabelas, de modo a poderem popular as tabelas do modelo multidimensional. Tal

como indicado na Figura 3.3, existem três grandes fases na Integração:

1. Junção dos campos das tabelas do ODS, que vai ser abordada na secção 3.2.1;

2. Agrupamentos e Cálculos sobre as junções anteriormente efectuadas, que vai ser descrita na

secção 3.2.2;

3. Carregamento dos dados no modelo multidimensional, que vai ser abordada na secção 3.2.3.

Tal como acontece na difusão, quando uma dada tabela é integrada ela vai possuir um identificador

único, o IntegrationID, que permite o controlo de todas as integrações feitas.

30

3.2.1 1a Fase - Junções dos campos das tabelas do ODS em vistas

Esta fase consiste em construir uma vista única, para juntar o conteúdo das várias tabelas do ODS

de modo a conseguir popular o modelo multidimensional. Assim, nesta fase não é realizada qualquer

grande correcção ao valor dos dados das várias tabelas, sendo estas correcções feitas em fases pos-

teriores. Nesta fase podem ser identificadas três tipos de operações principais:

1. Junções (Joins e Outer Joins);

2. Filtragem de valores;

3. Formatação de valores.

De forma a exemplificar melhor estas operações recorremos a uma das vistas criadas no sistema de-

senvolvido, a vista F_Times_uCI_V1 (o código da vista pode ser consultado no Anexo 9). Esta vista

destina-se a popular a tabela de factos referente aos tempos das chamadas provenientes do sistema

uCI, F_Times_uCI. A Figura 3.7 representa a interligação das várias tabelas do ODS cujo conteúdo

é necessário para popular a tabela F_Times_uCI. A Tabela 3.1 detalha as ligações entre cada par de

tabelas representada na Figura 3.7.

Figura 3.7: Interligação das várias fontes de dados usadas para criar a vista com todos os dados relevantes que

vão popular a tabela F_Times

Tabela 3.1: Ligação entre as tabelas que formam a vista F_Times_uCI_V1

31

3.2.1.1 Junções

Existem dois grandes tipos de Junções (Joins):

• Inner Joins;

• Outer Joins (e suas variantes, Full, Left e Right).

A operação de Inner Join é efectuada quando se pretende juntar o conteúdo de duas tabelas T1 de

estrutura (A1,B1,C1) e T2 de estrutura (A2,B2,C2) pelo atributo A1 de T1 e A2 de T2, em que existe

uma relação de "um para um"entre A1 e A2. Ou seja, para cada valor A1 de T1, existe exactamente um

valor A2 de T2 que lhe corresponde. A expressão algébrica que traduz esta operação está representada

na Figura 3.8. A semântica desta expressão é a seguinte: pretende-se obter os valores B1,C1,B2 e C2

das tabelas T1 e T2 onde A1=B1.

Figura 3.8: Expressão algébrica que traduz um Inner Join.

No caso da vista F_Times_uCI_V1, um exemplo deste tipo de operação é a relação entre a tabela

uCI_Thread e a tabela uCI_data_context. A interligação destas tabelas é representada pela seguinte

expressão algébrica (Ver Figura 3.9):

Figura 3.9: Expressão algébrica que traduz um Inner Join entre as tabelas uCI_Thread e uCI_data_context

A semântica da expressão representada na Figura 3.9 é a seguinte: pretende-se os códigos de

todas as campanhas cujo campo data_context da tabela uCI_Thread é igual ao campo code da tabela

uCI_Data_Context.

A operação de Outer Join é efectuada quando se pretende juntar o conteúdo de duas tabelas T1 de

estrutura (A1,B1,C1) e T2 de estrutura (A2,B2,C2) pelo atributo A1 de T1 e A2 de T2, em que podem

existir tuplos de T1 cujos valores de A1 não correspondem a nenhum de A2 em T2 ou então a um ou

mais valores de A2 em T2. A expressão algébrica que traduz esta operação pode ser vista na Figura

3.10.

Figura 3.10: Expressão algébrica que traduz um Outer Join

A expressão algébrica que pode ser lida na Figura 3.10 (mais propriamente um Full Outer Join)

selecciona todos os campos das tabelas T1 e T2 mesmo que estes não tenham correspondência entre

os campos A1 e A2. Esta expressão pode ter ainda ainda duas outras variantes. Na Figura 3.11

mostra-se a expressão usando um Left Outer Join e na Figura 3.12 usando um Right Outer Join. Um

32

Left Outter Join significa que devem ser seleccionados todos os campos da tabela à esquerda da união

(neste caso a tabela T1), mesmo que estes não tenham correspondência com valores da tabela à

direita (T2) através dos campos A1 e A2. Um Right Outer Join, de forma similar, significa que devem

ser seleccionados todos os campos da tabela à direita, mesmo que não exista correspondência com os

campos da tabela à esquerda.

Figura 3.11: Expressão algébrica que traduz um Left Outer Join

Figura 3.12: Expressão algébrica que traduz um Right Outer Join

Um exemplo de um Outer Join aplicado à vista F_Times_uCI_V1 é o da relação existente entre

as tabelas uCI_segment e uCI_thread. Uma thread é uma interacção (de dados ou telefónica) e um

segment é uma parte desta interacção. Desse modo, a cada tuplo de uCI_thread corresponde um

ou mais tuplos de uCI_segment. A expressão de álgebra relacional que traduz esta operação é a

representada na Figura 3.13.

Figura 3.13: Expressão algébrica que traduz um Outer Join entre as tabelas uCI_thread e uCI_segment da vista

F_Times_uCI_V1.

3.2.1.2 Filtragem de valores

Ao efectuar a junção das várias tabelas fonte, podem logo ser realizadas algumas filtragens, omitindo

valores de atributos. Estes valores omitidos referem-se a situações que não têm qualquer interesse

para fases posteriores da etapa de Integração. Por exemplo, na tabela de factos F_Times_UCI não

têm qualquer interesse os registos que correspondem a tuplos da tabela uCI_segment onde os nomes

dos utilizadores (usr_name) não estejam preenchidos. Estes registos não vão ter relevância para as

etapas posteriores da Integração, visto nestes casos ser impossível associar um utilizador a uma dada

interacção. Este filtro que se aplica à vista F_Times_UCI_V1 pode ser descrito pela expressão presente

na Figura 3.14.

É importante salientar que estas filtragens são todas efectuadas sobre as vistas construídas, ao

invés de se fazerem directamente sobre as tabelas fonte. Esta situação acontece por duas razões: (i)

por uma questão de simplicidade, pois assim todas as filtragens sobre uma vista são feitas num só

sítio e (ii) permite que se contemplem situações de filtragem mais complexas (por exemplo, ter de filtrar

sobre dois valores em simultâneo, de duas tabelas diferentes).

33

Figura 3.14: Filtro aplicado à vista F_Times_UCI_V1 para retirar desta vista os campos cujo nome de utilizador

(usr_name) é nulo.

3.2.1.3 Formatação de valores

Tal como já foi referido, na primeira etapa da fase de Integração, procura-se apenas integrar os valo-

res sem lhes aplicar qualquer tipo de cálculos. Contudo, quando estes cálculos são bastante simples,

essencialmente formatações de valores, por uma questão de simplicidade podem ser realizadas logo

nesta fase. No exemplo da construção da vista F_Times_uCI_V1, podem ser encontradas estas forma-

tações de valores. Por exemplo, o valor do campo duration da tabela uCI_segment integrante da vista

usada, que representa a duração de cada segmento, está representado em décimas de segundo. Os

cálculos que serão necessários realizar sobre este campo são efectuados quase sempre em segundos

(devido às regras de negócio impostas pelo call center ). Assim, o valor de duration de uCI_segment é

convertido para segundos na vista F_Times_uCI_V1 (o que equivale a uma simples divisão por 10). Por

exemplo no caso da passagem de décimas de segundos para segundos esta operação pode ser tra-

duzida pela expressão presente na Figura 3.15. Outro exemplo consiste na formatação das datas dos

segmentos. As datas costumam obedecer ao formato: ’2003/01/22 22:31:26’. Nos cálculos a realizar

posteriormente, é necessário separar os dias das horas. Na vista F_Times_uCI_V1, é então realizada

a separação de cada segmento da data em dois campos diferentes: ’2003/01/22 00:00:00’ e ’22:31:26’.

Figura 3.15: Formatação aplicada na vista F_Times_uCI_V1 para passar o campo duration de décimas de

segundo para segundos.

Um excerto do conteúdo da vista F_Times_uCI_V1 no final da 1a Fase (ver secção 3.2.1) de Integra-

ção, que consiste essencialmente na junção de tabelas do ODS, encontra-se exemplificado na Figura

3.16.

3.2.2 2a Fase - Agrupamentos e Cálculos

Nesta segunda fase da etapa de Integração vão ser efectuados os cálculos sobre a vista F_Times_uCI_V1,

anteriormente criada, de forma a produzir os tuplos que vão popular as tabelas do modelo multidimen-

sional. A vista resultante da aplicação destes cálculos tem o nome de F_Times_uCI_V2 (o código SQL

desta vista pode ser visto nos Anexos em 10). Estes cálculos consistem essencialmente numa suces-

são de condições e somas do tipo: se uma dada condição for verificada (por exemplo um valor ser igual

a zero) então procede-se à soma, contagem ou qualquer outra operação similar sobre os valores de

outro campo. Estes cálculos encontram-se representados na expressão da Figura 3.17.

Por exemplo, no caso da vista F_Times_uCI_V2, três dos valores que são necessários calcular são

34

Figura 3.16: Vista F_Times_uCI_V1 após a primeira fase da Integração.

Figura 3.17: Cálculos efectuados na segunda fase da etapa de Integração.

o tempo total de chamadas (TotalCallTime), o tempo total de conversação (TotalTalkTime) e o Tempo

Total de espera (TotalWaitTime). Para calcular estes valores um método simplificado pode ser descrito

pela expressão da Figura 3.18.

A necessidade de se seleccionarem campos adicionais como o agente e de agrupar os valores

obtidos segundo estes campos, decorre do facto de que as tabelas de factos se organizam deste modo,

ou seja, têm os seus valores agrupados por uma série de dimensões à qual a tabela de factos se liga.

Um exemplo da vista F_Times_uCI_V2 resultante da 2a Fase - Agrupamentos e Cálculos da etapa

de Integração encontra-se ilustrado na Figura 3.19.

35

Figura 3.18: Expressão de cálculo para obter os campos TotalCallTime, TotalTalkTime e TotalWaitTime da vista

F_Times_uCI_V2.

3.2.3 3a Fase - Carregamento dos dados nas tabelas do modelo multidimensional

Nesta fase, a vista F_Times_uCI_V2 é executada de modo a carregar as tabelas de factos da estrela

representada na Figura 3.4 da secção 3.

3.2.3.1 Carregamentos para as Tabelas de Factos

Nas tabelas de factos, o primeiro passo é a remoção de todos os registos que tenham uma data que

já esteja considerada nos novos dados que se vão integrar, isto garante assim que os dados das ta-

belas de factos são o mais actualizados possíveis. Adicionalmente, como estas tabelas, ao contrário

das tabelas de dimensões, têm chaves estrangeiras para várias tabelas, bem como os atributos destas

tabelas de factos são maioritariamente obtidos a partir de cálculos de vários campos (por exemplo, o

tempo total de chamada que é dado pelo tempo em conversação mais o tempo dispendido em opera-

ções após terminada a conversação), o seu carregamento é mais complexo comparativamente com o

que o que acontece com as tabelas de dimensões. No caso da tabela F_Times_UCI existem chaves es-

trangeiras para as seguintes tabelas de dimensões: D_Data, D_CallCenter, D_Cliente, D_Campanha,

D_Supervisor, D_Teamleader, D_Time e D_Agente. É assim necessário popular a tabela de factos não

só com os dados anteriormente calculados, mas também com estas referências (chaves estrangeiras).

Devido a ser preciso encontrar estas referências para as tabelas de dimensões, é necessário antes de

se carregarem os dados verificar se as referências que estão presentes nesses dados, são válidas face

às dimensões existentes. Assim verifica-se para cada uma das chaves estrangeiras se ela realmente

existe na tabela de dimensões e caso todas as chaves tenham referências válidas podem-se carregar

os dados na tabela de factos. Caso as referências não sejam válidas, os dados não vão ser carre-

gados na tabela de factos, e vão ser carregados em tabelas de erros. Estas tabelas de erros têm a

mesma estrutura que as tabelas de factos para onde os dados se destinavam, por exemplo a tabela de

factos F_Times_UCI vai ter uma tabela de erros de nome F_Times_UCI_Error, mas com três campos

36

Figura 3.19: Vista F_Times_uCI_V2 resultante da segunda fase da Integração.

adicionais: ErrorDescription, que se refere à descrição do erro ocorrido (por exemplo: valor da chave

estrangeira da Campanha não encontrada), ErrorDate, que se refere à data em que aconteceu o erro e

Corrected. O campo corrected existe caso se opte por manualmente corrigir o erro ocorrido, podendo

depois incluir estes dados nas vistas que vão popular as tabelas de factos numa nova iteração. O fluxo

de operações do Microsoft Integration Services 2005 [25] necessário para popular a tabela de factos

F_Times_uCI encontra-se representado na Figura 3.20.

No diagrama da Figura 3.20 podem-se identificar os seguintes passos:

1. Os dados das vista F_Times_uCI_V2 são extraídos;

2. Vai-se validar cada uma das referências para as tabelas de dimensões.

3. Caso a referência exista:

(a) Continuam-se a validar as restantes referências;

(b) Colocam-se os dados provenientes da vista F_Times_uCI_V2, na tabela de factos F_Times_uCI.

4. Caso a referência não exista:

(a) É assinalada a descrição do erro (por exemplo: Erro devido a falta de referência para a tabela

de dimensões D_Dates);

(b) Unem-se todos os tuplos onde aconteceram erros;

(c) Adiciona-se o campo que descreve que aconteceu um erro (campo Corrected, com o valor

0);

(d) Adiciona-se a data em que ocorreu o erro;

(e) Conta-se o número de erros ocorridos;

(f) Colocam-se os dados com erros na tabela F_Times_uCI_Error.

37

O esquema descrito na Figura 3.20 pode ser seguido para popular as restantes tabelas de factos,

alterando apenas as referências que devem ser encontradas nas várias tabelas de dimensões.

3.2.3.2 Carregamentos para as Tabelas de Dimensões

Neste tipo de tabelas, os carregamentos são directos a partir das tabelas criadas na segunda fase da

etapa de Integração (ver secção 3.2.2), não se recorrendo a qualquer tipo de cálculos adicionais. Pode-

se também recorrer directamente às fontes de dados provenientes da etapa de Difusão (ver secção 3.1)

caso não seja necessário qualquer tipo de integração, evitando-se assim a segunda etapa do processo

ETL (Integração).

Tome-se o exemplo da tabela da dimensão D_Campaigns, que contém informação relativa às cam-

panhas a decorrer no call center. Para popular esta tabela, basta mapear directamente o conteúdo

já existente da tabela uCI_campaigns, cuja estrutura é (diffusionId, code, shortname, fullname, cam-

paigntype, status, foreseen_start, foreseen_end, foreseen_calls, start_time, end_time), não sendo ne-

cessário qualquer tipo de integração.

Aquando da fase da Integração, é importante verificar se o tuplo que se pretende colocar na tabela

de dimensões já existe nesta e, caso isso aconteça, conferir os valores dos campos que diferem do

tuplo que se pretendia inserir; aqui, podemos deparar-nos com duas situações:

• se o campo se referir a um valor que pode ser mudado ao longo do tempo (Slowly Changing

Dimension), então este é actualizado;

• se o campo se referir a um valor que não pode ser modificado na tabela de dimensões, então

ignoramos esse tuplo que se pretendia inserir.

Considere-se a estrutura da tabela de dimensões D_Campaigns:CampaignID, CampaignNameUCI,

Type, Status, CampaignNameCCS, CampaignCodeUCI, CampaignCodeCCS, Instance. Destes cam-

pos, apenas os campos Type e Status podem mudar ao longo do tempo.

Exemplo 3.2.1 Suponha-se o seguinte tuplo da tabela D_Campaigns: (1, campanhaUCI, 0, 0, campa-

nhaCCS, 2, 3, 1). Caso se pretenda adicionar um novo tuplo (campanhaUCI_NOVA,0,0,campanhaCCS,2,3,2),

como já existe na tabela D_Campaigns um registo com os campos CampaignNameCCS, CampaignCo-

deUCI e CampaignCodeCCS iguais aos do tuplo que se pretende inserir e como o campo Campaign-

NameUCI não pode ser alterado, o tuplo que se pretende adicionar vai ser ignorado.

Exemplo 3.2.2 Suponha-se novamente o seguinte registo da tabela D_Campaigns: (1, campanhaUCI,

0, 0,campanhaCCS, 2, 3, 1) e que se pretende adicionar um novo tuplo (1, campanhaUCI, 0, 1, cam-

panhaCCS, 2, 3, 1). É visível que já existe na tabela de dimensões um tuplo com os mesmo atributos,

apenas diferindo no campo Status, como este campo pode ser modificado ao longo do tempo, o tuplo

existente na tabela de dimensões vai ser actualizado de acordo com o tuplo que se pretende inserir

para: (1, campanhaUCI, 0, 1, campanhaCCS, 2, 3 ,1).

38

3.2.4 Estrutura de dados de Controlo na Integração

De modo análogo ao processo de Difusão, também a etapa de Integração é acompanhada de um pro-

cesso de controlo (tal como representado na Figura 3.2). Para implementar os mecanismos de controlo

da integração foram criadas três tabelas adicionais: CTRL_Data, CTRL_DataLog e CTRL_Map. A

Figura 3.21 apresenta a estrutura destas tabelas.

A tabela CTRL_Data associa a cada uma das tabelas do modelo multidimensional (tabelas de factos

e dimensões) um identificador único. Possui os seguintes campos:

• DataID - identificador da tabela de factos ou dimensão;

• Description - Descrição da tabela que está a ser identificada.

A tabela CTRL_DataLog (ver Figura 3.22) regista para cada uma das integrações efectuadas, a

seguinte informação:

• IntegrationDataID - identificador único da integração efectuada.

• DataID - tabela do modelo multidimensional que deu origem à Integração. Este campo é uma

chave para o campo DataID da tabela CTRL_Data.

• StartDate - a data de início da Integração.

• EndDate - a data de fim da Integração.

• DiffusionID- o Id da tabela do ODS à qual esta integração vai buscar os dados. Regra geral, as

integrações vão buscar os dados a vistas compostos por várias tabelas do ODS. Desse modo é

possível que uma mesma integração esteja associada a várias difusões de tabelas diferentes do

ODS. Assim, por cada tabela do ODS que a integração vai usar, vai existir uma entrada na tabela

CTRL_DataLog em que os dados vão ser sempre iguais, variando apenas o ID de difusão. Por

exemplo a tabela de factos F_Times_uCI vai estar associada a oito tabelas do ODS (uCI_segment,

uCI_thread, uCI_e_user, uCI_call_thread, uCI_data_context, uCI_campaign, WFM_campaigns,

WFM_call_centers) como é visível na Figura 3.22. Deste modo a tabela CTRL_DataLog vai ter

para cada integração da tabela de factos F_Times_uCI, oito entradas iguais em que apenas os

ID’s de difusão variam .

• InsertedRows - número de linhas inseridas na tabela de factos.

• UpdatedRows - número de linhas actualizadas na tabela de factos.

• DeletedRows - número de linhas apagadas na tabela de factos.

• HistoricalInsertedRows - número de linhas inseridas no histórico (note-se que de momento este

campo não está a ser usado).

• ErrorRows - número de erros.

• Error - descrição do erro.

• ProcessingStartDate - data em que a integração começou a ser processada.

• ProcessingEndDate - data em que a integração terminou o processamento.

• ErrorDiffusionID - o ID de difusão associado à tabela de erros de cada uma das tabelas do modelo

multidimensional.

39

A tabela CTRL_Map faz o mapeamento entre quais são as tabelas do ODS que são usadas por

cada tabela do modelo multidimensional, aquando de cada integração. Os campos desta tabela são:

• DiffusionSourceID - identificador da tabela da ODS;

• IntegrationSourceID - identificador da tabela do modelo multidimensional;

3.3 Relatórios de Controlo

De modo a monitorizar o resultado das várias integrações e difusões realizadas, foram criados dois

tipos de relatórios de controlo:

• um relatório que lista todas as integrações e respectivas difusões;

• um relatório que mostra, para cada uma das integrações, a tabela de erros (quando estes exis-

tem).

A Figura 3.23 exemplifica o primeiro tipo de relatórios criados. Este relatório lista as várias integra-

ções efectuadas, a sua data de inicio e fim (Start e End), duração (Duration), número de inserções

(Inserts), inserções no histórico (Historical Inserts), actualizações (Updates) e erros (Errors). Note-se

que estes erros, quando existem, funcionam como uma hiperligação para a tabela de erros respectiva,

podendo-se assim facilmente navegar até ao relatório que apresenta os erros desta tabela. Para cada

uma destas integrações, são especificadas as difusões que a integração usou. Para estas difusões é

apresentada a data de difusão (Date), a data de inicio e fim da difusão (Start e End), a duração da

difusão (Duration), o número de linhas difundidas (Diffused) e a tabela fonte onde a difusão foi feita

(Source). Por exemplo, na Figura 3.23, é possível observar que a tabela de factos F_Times_uCI foi

integrada no dia 16-6-2008 às 15:00:00 e terminou de ser integrada no mesmo dia às 15:00:10; inseriu

39 tuplos na tabela de factos e 80 tuplos na tabela de erros F_Times_uCI_Error. Esta integração resul-

tou de 8 tabelas do ODS (uCI_segment, uCI_thread, uCI_e_user, uCI_call_thread, uCI_data_context,

uCI_campaign, WFM_campaigns, WFM_call_centers).

Na Figura 3.24 é apresentado um exemplo dos relatórios de erro criados. Estes relatórios mostram

a descrição do erro ocorrido (ErrorDescription), a data em que ocorreu o erro(ErrorDate) e se o erro

já foi ou não corrigido (Corrected, cujo valor 0 indica que ainda não foi corrigido e o valor 1 que a

correcção já teve lugar). No caso específico da Figura 3.24, observa-se, por exemplo, que os sete

tuplos apresentados dizem respeito a erros por falta de referência com a tabela de dimensões D_Agents

(visível pela descrição do erro, Agents row yielded no match during lookup). Pode-se ainda observar

que estes erros ocorreram no dia 6-16-2008 às 11:35:19 horas e que não foram ainda corrigidos (o que

se pode observar pelo campo a 0 na coluna Corrected).

40

Figu

ra3.

20:

Flux

opa

rapo

pula

rata

bela

defa

ctos

F_Ti

mes

_UC

I

41

Figura 3.21: Estrutura das tabelas de controlo usadas na Integração.

Figura 3.22: Excerto da tabela CTRL_DataLog

42

Figu

ra3.

23:

Rel

atór

iode

Con

trolo

gera

l,on

dese

mos

tram

toda

sas

inte

graç

ões

ere

spec

tivas

difu

sões

.

43

Figura3.24:

Relatório

deerros

paraa

tabelade

factosF_Tim

es_UC

I.

44

4 Indicadores e Dashboards

Neste capítulo vão ser descritos os indicadores de negócio identificados e que vão ser usados nos

dashboards desenvolvidos nesta tese de mestrado na secção 4.1, o modelo multidimensional usado

para armazenar estes indicadores será descrito na secção 4.2, na secção 4.3 será descrito o cubo

construído sobre o modelo multidimensional e finalmente na secção 4.4 serão descritos os Dashboards

criados.

4.1 Indicadores de Negócio

A partir das necessidades identificadas junto dos actores importantes do call center para o qual o

sistema de BI foi desenvolvido (Director geral, Gestor de contas inbound, Gestor de contas outbound,

supervisor inbound, supervisor outbound e Coordenador do call center ), foi identificado um conjunto

de indicadores de negócio donidreado importante monitorar. Este conjunto de indicadores pode ser

consultado nos anexos em 8.

A partir deste conjunto procurou-se agrupar os indicadores identificados segundo os processos de

negócio ou entidades a que diziam respeito. Assim, foram criados sete grupos de indicadores: Chama-

das Inbound, Tempos, Agentes, Campanhas, KPI’s, Financeiros e Chamadas Outbound. As Chamadas

Inbound dizem respeito a aspectos relativos às chamadas de entrada no call center, como seja o nú-

mero de chamadas recebidas e número de chamadas abandonadas. Os Tempos, dizem respeito a

todas as métricas temporais nas chamadas do call center (tanto de inbound como outbound), como

por exemplo, tempos médios de chamada. Os Agentes dizem respeito a operações dos agentes nas

campanhas, como o tempo de login e horas trabalhadas. As Campanhas referem-se às necessidades

das campanhas em execução no call center, como o número necessário de agentes. KPI’s diz respeito

aos KPI’s que o director geral pretende monitorizar no seu dashboard específico (por exemplo, tempo

total de conversação e número de chamadas efectuadas). Financeiros guarda informação sobre lucros

e custos das operações do call center. Chamadas Outbound referem-se aos aspectos relacionados

com as chamadas de saída efectuadas, como o número de vendas/inquéritos efectuados.

Os grupos de indicadores, foram depois usados para criar as nove tabelas de factos usadas no

modelo multidimensional criado (ver secção 4.2). Cada uma destas tabelas de factos corresponde a

um dos grupos de indicadores, com a excepção dos Tempos e Chamadas Inbound que foram separadas

em duas tabelas de factos cada, devido ao facto dos seus indicadores poderem vir de duas fontes de

dados diferentes (uCI ou CCS).

Este conjunto de indicadores tinham a necessidade de serem cruzados segundo um conjunto de

dimensões, necessárias à sua caracterização. Estas dimensões eram: Data do indicador, Call Center,

Cliente associado ao indicador, Campanha, Supervisor, Teamleader e Agente. Estas dimensões foram

depois usadas para criar as tabelas de dimensões descritas na Secção 4.2.

45

4.2 Modelo Multidimensional

Nesta secção apresentamos o modelo multidimensional criado para suportar os principais indicadores

de negócio referentes às operações de um call center.

Este modelo multidimensional é constituído por oito tabelas de dimensões e nove tabelas de factos.

As tabelas de dimensões são as seguintes:

• D_Agents - tabela que guarda a informação relativa aos agentes do call center, nomeadamente

o seu nome (AgentName) e login (AgentLogin) que usam para aceder aos sistemas;

• D_CallCenters - tabela que guarda informação sobre os escritórios do call center existentes,

nomeadamente o seu nome (CallCenterName);

• D_Clients - tabela que guarda informação sobre os clientes das campanhas dos call centers,

nomeadamente os seus nomes (ClientName);

• D_Supervisors - que guarda a informação que os supervisores dos agentes do call center usam

para aceder aos sistemas, nomeadamente o seu nome (SupervisorName) e login (SupervisorLo-

gin);

• D_Teamleaders - guarda informação que os Teamleaders dos agentes do call center usam para

aceder aos sistemas, nomeadamente o seu nome (TeamleaderName) e login (TeamleaderLogin);

• D_Times - guarda informação relativa a tempos (Time) em horas, minutos e segundos;

• D_Dates - guarda informação relativa a tempos (Time) em anos, meses e dias;

• D_Campaigns - guarda informação relativa às campanhas de um call center (por exemplo: o seu

nome, CampaignName e código, CampaignCode);

As tabelas de factos criadas são:

• F_Agents - guarda informação sobre aspectos das operações dos agentes nas várias campanhas

(como por exemplo: o número de chamadas, tempo de login).

• F_Calls_Inbound_CCS e F_Calls_Inbound_uCI - estas duas tabelas têm estruturas similares,

sendo que a maior diferença são os sistemas fonte onde vão retirar a informação (CCS ou uCI).

Estas tabelas registam dados relativos às chamadas de inbound da campanha (como seja o nú-

mero de chamadas recebidas e número de chamadas atendidas em x segundos).

• F_Calls_Outbound - esta tabela regista dados relativos às chamadas de outbound efectuadas

(como o número de chamadas em espera, número de vendas e inquéritos).

• F_Campaigns - esta tabela guarda informação sobre as campanhas em execução nos call centers

(como o número de agentes necessários por hora e o número de horas de trabalho de numa dada

campanha).

• F_Finances - esta tabela guarda informação financeira sobre as várias campanhas em execução

(por exemplo: lucro, custos).

• F_KPIs - guarda informação sobre os vários indicadores importantes a monitorar em cada campa-

nha (como o tempo total de conversação, tempo em que a campanha está disponível para receber

chamadas, número de chamadas efectuadas).

46

• F_Times_CCS e F_Times_uCI - estas duas tabelas têm estruturas similares, sendo que a maior

diferença são os sistemas fonte onde vão retirar a informação (CCS ou uCI). Estas tabelas regis-

tam dados relativos aos vários tempos que são relevantes monitorar nas campanhas (exemplo:

tempo total de chamadas, tempo total de conversação, tempo total que o agente levou a efectuar

operações após ter terminado a chamada).

Nos anexos, no capítulo 13 podem ser vistas as estrelas do modelos multidimensionais criados.

4.3 Cubo OLAP criado a partir do modelo multidimensional

OLAP usa vistas multidimensionais sobre os dados para providenciar um acesso rápido a informação

estratégica e sua posterior análise. Envolve a reestruturação específica de dados, de modo a que

questões a fontes de dados, sejam dadas de um modo rápido. Um cubo OLAP permite que utiliza-

dores acedam a dados sumariados e devidamente calculados, evitando assim que se perca tempo a

agregá-los e calculá-los ao se extrair os dados das data warehouses, facilitando o acesso e análise da

informação dos dados, que podem ser manipulados de uma forma amigável e flexível para o utilizador

[63]. Além do mais o uso de um cubo OLAP tem pouco ou nenhum impacto na reestruturações dos

processos ETL de fases anteriores de uma ferramenta de Business Intelligence pelo que a sua inte-

gração num projecto desta natureza pode, se bem efectuada, ter um impacto mínimo na alteração da

arquitectura.

Além das vantagens referidas acima outra das razões que se prendeu com a criação deste cubo

OLAP foi a necessidade da ferramenta usada na criação dos dashboards, o Microsoft Sharepoint 2005

Services [32], precisar de uma ligação a um cubo multidimensional, para que os dados do modelo

multidimensional possam ser visualizados correctamente. A estrutura deste cubo é assim em tudo

idêntica à estrutura do modelo multidimensional criado, com a adição de algumas medidas, que por

serem não-aditivas (como os tempos médios de camadas) não podiam ser agregadas ao longo das

dimensões.

A criação deste cubo possibilitou que os utilizadores pudessem utilizar mecanismos mais evoluí-

dos na pesquisa e análise dos dados existentes, podendo facilmente criar os seus próprios gráficos e

tabelas com indicadores, a partir de ferramentas de exploração como o Microsoft Excel 2007 [34].

4.4 Dashboards

Nesta secção vai abordar-se a componente que diz respeito aos Dashboards da solução desenvolvida.

Esta é a componente mais visual do sistema e na qual os utilizadores vão poder observar os vários

indicadores de negócio que se pretendem monitorizar.

A construção destes dashboards foi um processo iterativo, onde se começou por primeiro definir

protótipos em papel. Só depois de validar que os primeiros protótipos estavam de acordo com o pre-

tendido, é que se realizaram protótipos no Microsoft Sharepoint 2005 Services [32].

47

É de salientar que por impossibilidade de acesso directo aos utilizadores finais da solução, as vali-

dações foram feitas junto de especialistas da Link Consulting.

4.4.1 Considerações sobre os Dashboards

Na construção dos dashboards houve uma preocupação de os realizar de acordo com as melhores prá-

ticas de desenho deste tipo de componentes. Para tal tentou-se seguir ao máximo as regras definidas

por Stephen Few [26] [16] nomeadamente:

• Não exceder as fronteiras de um único ecrã - criar a interface do dashboard de forma a que

toda a informação esteja disponível ao utilizador sem que este tenha de ajustar o ecrã;

• Identificação do utilizador final - realizar os dashboards, pensando sempre nas necessidades

de quem os vai usar;

• Limitação do detalhe - limitar detalhe excessivo, como seja, números com demasiadas casas

decimais;

• Escolha de indicadores e gráficos - determinar antes de começar a fase de prototipagem, quais

os indicadores que vão ser apresentados e o modo como estes vão ser visualizados;

• Variedade de gráficos - evitar diversificar em demasia o uso de tipos de gráficos, apenas com o

intuito de criar uma falsa ilusão de dashboards mais interessantes;

• Adornos irrelevantes - evitar o uso de adornos irrelevantes, simplificando o máximo possível;

• Organização da informação - organizar a disposição dos indicadores de um modo que seja

útil aos utilizadores, por exemplo, colocando os indicadores mais importantes no canto superior

esquerdo e meio;

• Cores - usar cores que não cansem a vista do utilizador e que facilitem o destaque de informação

relevante de um modo natural.

Além de se ter tido em conta as regras definas por este autor, ainda foi realizada uma pesquisa,

de forma a encontrar dashboards aplicados ao negócio dos call centers, de forma a procurar criar o

sistema de acordo com o expectável numa ferramenta de BI para call centers.

4.4.2 Actores dos Dashboards

Inicialmente os dashboards foram pensados para os seguintes actores: Supervisor de Campanhas

Inbound, Supervisor de Campanhas Outbound, Consultor Interno, Coordenador de Call Center, Ges-

tor de Contas Inbound, Gestor de Contas Outbound, Gestor de Recursos Humanos e Gestor de Call

Center. Tendo-se identificado as necessidades de cada um deles, devido à especificidade dos requisi-

tos que alguns destes actores queriam ver nos dashboards, tiveram que se abandonar alguns destes

dashboards. Um destes exemplos é o do gestor de recursos humanos, que pretendia visualizar um

grande número de indicadores que simplesmente não eram disponibilizados pelo sistema, como o total

de agentes planeados por hora e taxas de pedidos de férias. No sistema final foram incorporados dash-

boards para: Supervisor de Campanhas Inbound, Supervisor de Campanhas Outbound, Coordenador

de Call Center, Gestor de Contas Inbound, Gestor de Contas Outbound e Gestor de Call Center.

48

4.4.3 Prototipagem dos Dashboards

Como já foi referido, a primeira grande fase correspondeu à realização de protótipos em papel, que

foram sofrendo melhorias e validados com especialistas da Link Consulting. Quando os protótipos

estavam numa fase onde já iam de encontro às expectativas dos utilizadores, é que se passou a desen-

volver os protótipos usando o Microsoft Sharepoint 2005 Services [32]. Apesar de os dashboards terem

sofrido várias iterações, é importante salientar duas: primeiro protótipo em Microsoft Sharepoint 2005

Services, ainda sem ligação aos dados do modelo multidimensional e protótipo em Microsoft Sharepoint

2005 Services usando os dados do modelo multidimensional.

4.4.4 Primeiro protótipo em Microsoft Sharepoint 2005 Services

Na Figura 4.1 pode ser visualizado o primeiro protótipo realizado em Microsoft Sharepoint 2005 Services

para o gestor de contas inbound e na Figura 4.2 pode ser visualizado o protótipo correspondente para

o director geral do call center.

Figura 4.1: Primeiro protótipo realizado em Microsoft Sharepoint 2005 Services para o gestor de contas inbound.

Neste protótipo o principal destaque, vai para a opção de se ter disposto os indicadores numa grelha

3*2, ou seja, três linhas e duas colunas. Como se pode observar pelos dois exemplos apresentados,

procurou-se manter a coerência a nível de cores e gráficos utilizados, bem como em manter uma

interface o mais simples possível. As principais críticas feitas a estes dashboards, foram o facto de

os filtros de selecção de dados (como a data e campanha), não estarem directamente visíveis no

dashboard, bem como não haver uma separação muita clara entre os gráficos.

49

Figura 4.2: Primeiro protótipo realizado em Microsoft Sharepoint 2005 Services para o director de call center

4.4.5 Protótipo em Microsoft Sharepoint 2005 Services usando dados do modelo multidimensi-

onal

Após algumas iterações, de acordo com os requisitos que iam sendo apontados pelos especialistas da

Link Consulting, chegou-se a uma versão final dos dashboards que iriam ser incorporados na solução.

Note-se que este processo de iteração e constante melhoria podia continuar indefinidamente, mas

considerou-se que a relação custo/benefecío, a partir desta iteração, não requereria mais iterações

adicionais.

As Figuras 4.3 e 4.4 representam respectivamente os protótipos finais para o gestor de contas

inbound e para o director de call center.

As principais diferenças face aos protótipos enunciados na secção 4.4.4 são:

• Inclusão dos filtros de uma forma visível;

• Passagem para um esquema de duas linhas e três colunas. Esta opção foi tomada pois o espaço

ocupado no topo superior pelos filtros, levava a que usando este novo esquema, os dados seriam

de muito mais fácil leitura (ao contrário do que aconteceria, se fossem usadas três linhas e duas

colunas);

• Adição de uma separador de cor azul acima de cada gráfico, por forma a melhor distinguir cada

um dos gráficos apresentados;

• Alteração de alguns dos indicadores dos gráficos;

É necessário salientar que alguns dos gráficos podiam recorrer ao uso de listas em vez de gráficos

50

Figura 4.3: Protótipo realizado em Microsoft Sharepoint 2005 Services para o gestor de contas inbound e

devidamente ligado ao modelo multidimensional.

para representar certos indicadores, devido a terem de apresentar uma quantidade de informação que

não era facilmente apresentada num gráfico. Um dos exemplos onde se verificou esta ocorrência foi no

dashboard do supervisor inbound. A Figura 4.5 mostra os indicadores SLA e Daily Summary (resumo

do dia), na forma de listas.

Nos Anexos, no capítulo 12 são apresentados os restantes dashboards desenvolvidos.

51

Figura 4.4: Protótipo realizado em Microsoft Sharepoint 2005 Services para o director de call center e

devidamente ligado ao modelo multidimensional

Figura 4.5: Protótipo realizado em Microsoft Sharepoint 2005 Services para o supervisor inbound e devidamente

ligado ao modelo multidimensional

52

5 Validação Experimental

Neste Capítulo, avaliamos a solução de ETL desenvolvida usando a ferramenta Microsoft Integration

Services 2005 [25] para o domínio especifico dos call centers. De forma a melhor organizar esta ava-

liação, seguimos a proposta de benchmark de workflows ETL proposta por Vassiliadis, Karagiannis,

Tziovara e Simitsis [1]. A avaliação à solução desenvolvida foi executada sobre dois parâmetros dis-

tintos: Eficácia e Eficiência. Eficácia diz respeito à capacidade da solução respeitar as necessidades

impostas pelas regras do negócio. Isto é, a capacidade de providenciar dados actuais e úteis para as

várias decisões tomadas no call center. Eficiência diz respeito aos recursos consumidos pela solução

desenvolvida, tal como tempo dispendido e carga no sistema (memória consumida) durante o processo

de execução da solução. Vai-se também avaliar a ferramenta Microsoft Integration Services 2005 [25]

enquanto ferramenta capaz de criar soluções de ETL eficientes e capazes de processar grandes volu-

mes de dados.

Na secção dedicado a avaliar o comportamento da solução de ETL face a objectivos específicos de

Eficácia (Ver secção 5.4) será avaliada a solução sobre duas grandes perspectivas:

1. Se a execução da solução possibilita a disponibilização de dados completos, actuais e consis-

tentes, dentro dos limites temporais (pelo menos os mínimos aceitáveis) para os processos de

tomada de decisão;

• Percentagem dos dados que cumprem e violam as regras de negócio;

• Percentagem dos dados que deveriam ser colocados na data warehouse, mas não foram.

2. Se a solução é robusta para aguentar falhas ocasionais;

• Percentagem de workflows ETL retomados com sucesso após uma falha.

Na secção dedicada à avaliação da solução desenvolvida face a objectivos relacionados com a sua

eficiência (Ver secção 5.5) vai-se ter em consideração:

1. Rapidez da execução da solução à luz de vários parâmetros (por exemplo: volume de dados);

• Tempo total para completar o workflow ETL;

• Tempo total para completar o workflow ETL, considerando uma percentagem de erros;

• Tempo médio de execução por tuplo;

• Tempo médio para completar o workflow ETL considerando o aumento de dados.

2. Carga adicional de recursos consumidos durante a execução da solução;

• Mínimos/Máximos/Média de memória consumida pelo workflow ETL nos sistemas fonte;

• Tempo necessário para completar um dado número de transacções à Data Warehouse aquando

da execução do workflow ETL;

• Tempo necessário para completar um dados número de transacções/interrogações aquando

da execução do workflow ETL que contenha falhas nos dados dos sistemas fonte;

• Mínimos/Máximos/Média de memória consumida pelo workflow ETL na Data Warehouse;

• Tempo necessário para completar um dado número de transacções/interrogações à Data

Warehouse, para auxiliar os processo de decisão, aquando da execução do workflow ETL;

53

• Tempo necessário para completar um dado número de transacções à Data Warehouse, para

auxiliar os processo de decisão, aquando da execução do workflow ETL com falhas nos

dados dos sistemas fonte ou Data Warehouse.

5.1 Conjunto de dados utilizado

Os dados utilizados no sistema desenvolvido provieram dos vários sistemas fonte usados no Call Cen-

ter. Estes dados correspondem a dados reais que reflectem as várias operações do call center entre

os anos de 2007 e 2008 (até ao mês de Agosto). Estes dados na sua maior parte não reflectem a

totalidade das campanhas executadas no call center durante este período temporal, sendo que apenas

existe um dia de operações que contém todas as campanhas a decorrer continuamente no call cen-

ter. Deste modo, apesar da maioria dos dados usados nas validações experimentais dizer respeito a

dados reais do call center onde a solução foi implementada, existem certas excepções. Uma destas

excepções relaciona-se com a necessidade de manipulação dos dados por forma a gerar falhas no

processamento, nomeadamente em alguns testes de tolerância a falhas do sistema. A outra excepção

foi a necessidade de replicar dados existentes, para simular vários dias de operações que tenham em

consideração a totalidade das campanhas a decorrer no call center. Esta última situação de replicação

dos dados, como já foi enunciado, deveu-se ao facto de muitos dos dados existentes não possuírem

informação de todas as campanhas a decorrer no call center.

5.2 Configuração do ambiente de testes

Todos os testes aqui descritos foram efectuados numa máquina virtual a executar o Windows 2003

Server, com 2500MB de RAM. Esta máquina virtual está hospedada num servidor ACPI Multiprocessor

X64-basedPC Intel(R) Xeon(R) com CPU de 1,60Ghz. Foi ainda utilizado o Microsoft SQL Server 2005

[31] e módulo Integration Services 2005 [25] do SQL Server 2005.

5.3 Fluxo ETL do trabalho desenvolvido

Nesta secção procurou-se esquematizar a solução desenvolvida seguindo os esquemas em borboleta

propostos por Vassiliadis, Karagiannis, Tziovara e Simitsis [1]. O fluxo da solução desenvolvida de

acordo com este esquema encontra-se representado na Figura 5.1. Neste esquema as formas triangu-

lares dizem respeito a passos do processo ETL do Capítulo 3, nomeadamente:

• F1 - corresponde à extracção das fontes de dados CCS para as tabelas do ODS (ver capítulo

3.1);

• F2 - corresponde à extracção das fontes de dados uCI para as tabelas do ODS (ver secção 3.1);

• F3 - representa a extracção das fontes de dados WFM (ou Gespluri) para as tabelas do ODS (ver

secção 3.1);

• F4 - diz respeito à etapa Junções dos campos das tabelas do ODS em vistas (ver secção 3.2.1).

54

– F4.1 - refere-se à fase de Junções descrita na secção 3.2.1.1 das tabelas do ODS;

– F4.2 - diz respeito à fase de Filtragem de Valores da secção 3.2.1.2.

– F4.3 - representa a fase de Formatação de Valores da secção 3.2.1.3.

• F5 - diz respeito à fase de Agrupamento e Cálculos da secção 3.2.2

• F6 - representa o Carregamento das Vistas nas tabelas de Dimensões e Factos da DW (ver

secção 3.2.3).

– F6.1 - diz respeito ao Carregamento das Tabelas de Dimensões da secção 3.2.3.2;

– F6.2 - refere-se ao Carregamento das Tabelas de Factos da secção 3.2.3.1;

Figura 5.1: Workflow ETL da solução de ETL desenvolvida, seguindo a abordagem do esquema em borboleta

proposta por Vassiliadis, Karagiannis, Tziovara e Simitsis [1]

5.4 Testes de Eficácia da solução de ETL

Nesta secção, será avaliada a percentagem dos dados que respeitam as limitações e regras impostas

pelo negócio do call center onde a solução foi aplicada, principalmente na disponibilidade dos dados

para serem usados nos processos de tomada de decisão.

Como foi abordado na secção 1.1 o call center necessita de ter acesso a dados actuais, de forma

a incorporá-los nos processos de tomada decisão. Desse modo torna-se essencial perceber qual a

latência mínima entre o momento em que os dados são gerados nos sistemas fonte, até serem incor-

porados num processo de tomada de decisão. No call center em questão, os processos de tomada de

decisão mais frequentes são realizados diariamente. Assume-se portanto que este período de tempo

será o mínimo aceitável para ter os dados disponíveis, a partir do momento em que são gerados pelos

sistemas fonte. Note-se porém que alguns dados (como por exemplo: margens de lucro) são usados

maioritariamente em processos de decisão semanais ou mensais, não invalidando contudo a assunção

55

anteriormente efectuada, de considerar o período mínimo de latência entre a geração dos dados e sua

disponibilidade de um dia.

Considera-se agora importante perceber o volume de dados que é gerado num dia pelo call cen-

ter e consequentemente que deverá ser processado, antes do próximo dia de trabalho no call center

começar. Em média os diferentes sistemas geram num dia:

• uCI - 1100000 entradas.

• CCS - 14000 entradas;

• Gespluri - 3700 entradas;

Estes ficheiros após sofrerem os processos das etapas de difusão e integração geram em média

58800 tuplos a inserir nas tabelas de dimensões e factos.

5.4.0.1 Percentagem dos dados que cumprem as regras de negócio

Considerando o número médio de tuplos de 58800, o sistema de ETL desenvolvido leva em média

cerca de 56 minutos a ser executado na sua totalidade (uma média de 0,057 segundos por tuplo).

Este valor, para os dados de um dia, permite afirmar que o sistema desenvolvido corresponde às

necessidades de negócio do call center, no que diz respeito à disponibilidade dos dados. Relembre-

se que as decisões com maior frequência são tomadas com base diária, pelo que é possível correr

o sistema desenvolvido durante a noite (quando o call center não está em execução) e ter os dados

disponíveis para os processos de tomada de decisão na próxima manhã de operações. No entanto é

necessário considerar outras variáveis; por exemplo um erro pode ocorrer no processamento dos dados

de um dia, levando a que no próximo dia de operações o sistema tenha de correr dados referentes a

dois dias. O gráfico da Figura 5.2 demonstra os tempos médios expectáveis por cada dia adicional de

operações a correr no sistema desenvolvido até um máximo de sete dias, um dos piores casos, que

equivale a não executar a solução durante toda uma semana operacional (considerando uma semana

de 7 dias de trabalho). É importante salientar que estes valores aqui apresentados resultam de uma

simulação efectuada com dados de teste gerados a partir de dados reais referentes a um único dia (dia

30 de Julho de 2008) de operações, devido a uma falta de dados de teste completos e sem erros.

Verifica-se pelos dados apresentados no gráfico da Figura 5.2, que mesmo supondo um caso em

que durante sete dias não se execute o processo de ETL, tendo que depois executar os dados relativos

a estes dias numa única vez, o tempo de processamento fica ligeiramente abaixo das sete horas e

meia, levando a que mesmo neste caso o fluxo ETL esteja de acordo com as necessidades temporais

impostas pelo call center. Percebe-se, contudo, que para carregamentos de dados que envolvam dados

referentes a mais do que sete dias os tempos de execução da solução deixem de estar de acordo com

as necessidades temporais do negócio, ainda que tais situações sejam raras, tendo em conta que,

normalmente o call center executa a solução diariamente.

Salienta-se, também, que aquando do primeiro carregamento da Data Warehouse com dados re-

ferentes a cerca de dezanove meses de operações, a opção tomada foi a de carregar individualmente

cada mês, levando cada um dos meses entre três a cinco horas a processar. A discrepância aqui ob-

56

Figura 5.2: Estimativa do tempo necessário para processar a quantidade de dados gerada através dos dias pelo

sistema de ETL desenvolvido.

servada entre o carregamento destes meses com os dados enunciados na Figura 5.2 prende-se com

o facto destes dados não contemplarem as fontes CCS (componente que ocupa uma larga porção da

execução do sistema, como será discutido na secção 5.5) e os meses não terem dados sobre todos os

dias (isto é, faltavam dados referentes a cerca de um quarto dos dias em todos os meses analisados).

Pode, assim, afirmar-se que para situações normais de carregamentos diários, sem erros de execu-

ção ou erros nas fontes de dados, a solução desenvolvida tem uma Eficácia bastante próxima de 100%,

cumprindo assim os requisitos temporais impostos pelo negócio (ou seja ter dados actuais no espaço

máximo de um dia).

5.4.0.2 Percentagem dos dados que deviam ser colocados na Datawarehouse mas não foram

A percentagem de dados que deviam ser colocados na Datawarehouse mas não foram, prende-se

sobretudo com a completude dos dados provenientes dos sistemas fonte. Assim se por exemplo exis-

tirem dados em falta sobre os agentes afectos às várias campanhas (tabela uCI_e_user ), a inserção

de certos tuplos nas tabelas de factos poderão não ser efectuadas por falta de referência a um agente

que devia estar afecto a este tuplo (por exemplo, a inserção na tabela F_Calls_Outbound necessita

forçosamente de ter um agente associado).

Esta percentagem varia bastante de mês para mês, consoante a informação que foi disponibilizada

naquele dado mês. Relembre-se que muitos dos meses anteriores possuíam vários dias e campanhas

em execução em falta. Como apenas o dia 30 de Julho de 2008 se encontra totalmente completo no

que diz respeito às informação do call center, vai-se considerar este mês como o representante do

número médio de tuplos que deveriam ser inseridos na Datawarehouse, mas que não o foram. Dos

58840 tuplos gerados neste dia, 30017 correspondem a tuplos que devem ser inseridos nas tabelas

de factos da Datawarehouse, e os restantes nas tabela de dimensões. Como foi descrito na secção

3.2.3.2, os tuplos das tabelas de dimensões só são inseridos caso ainda não estejam presentes nas

57

respectivas tabelas de dimensões, podendo quanto muito ser actualizados, por exemplo dos 28823

tuplos de dimensões apenas 11 foram inseridos pois os outros já existiam. Já os tuplos referentes às

tabelas de factos têm de ser sempre inseridos na Datawarehouse. Vai-se considerar assim que apenas

existe um erro, quando um tuplo que deveria ser inserido nas tabelas de factos da Datawarehouse não

foi inserido. Dos 30017 tuplos de factos que deviam ser inseridos, 22 não foram inseridos, resultando

numa percentagem de 0,073% de dados que deviam ser colocados na Datawarehouse mas não foram,

um número relativamente baixo.

5.4.1 Eficácia na robustez da solução - Percentagem de workflows ETL retomados com sucesso

após uma falha

De modo a compreender a robustez da solução é importante perceber como a solução se comporta na

eventualidade de ocorrerem erros. Os principais tipos de erros são:

1. Erros nas fontes de dados:

• Fontes de dados inexistentes;

• Dados errados nas fontes de dados.

2. Erros de execução:

• Erros de execução do próprio sistema;

• Erros durante o carregamento das tabelas de factos.

5.4.1.1 Erros nas fontes de dados

Os erros nas fontes de dados, tal como o enunciado acima, podem ser de dois tipos. Quando os erros

acontecem devido à inexistência de determinados ficheiros fonte, a reacção do sistema é de abortar o

carregamento do conjunto de ficheiros, da fonte que tinha o ficheiro ou ficheiros em falta. Assim, se

existir em falta um ficheiro do sistema uCI, por exemplo, suponhamos o ficheiro e_user, os restantes

ficheiros, que seriam carregados após o fluxo de execução de carregamento deste, são abandona-

dos. Contudo apesar de abortar este carregamento do sistema uCI, o workflow continua a carregar

os ficheiros das restantes fontes de dados (CCS e Gespluri). A decisão de dotar o sistema com este

comportamento recaiu, essencialmente, no facto de caso se falhasse o carregamento de um ficheiro

como o uCI_e_user, ainda que se carregassem os restantes ficheiros do sistema uCI, estes, nas fases

posteriores (nomeadamente, na integração), iriam dar erros de execução; isto porque faltariam dados

sobre os quais integrar, quando fosse necessária uma referência para a tabela resultante do ficheiro

em falta (uCI_e_user ). Procura-se, desta forma, compartimentar ao máximo o carregamento dos fichei-

ros; note-se, por exemplo, que se os ficheiros CCS não forem carregados, o sistema conseguirá, ainda

assim, executar a etapa de integração, usando as fontes de dados uCI e Gespluri e popular com uma

quantidade de dados aceitável as tabelas de dimensões e factos.

Quando os erros se devem à existência de dados errados nos próprios sistemas fonte (imaginemos,

por exemplo, uma campanha aparecer repetida duas vezes), a etapa de integração do workflow poderá

ter um de dois comportamentos:

58

• se o erro afectar alguma das interrogações efectuadas aquando da integração (por exemplo se-

leccionar um atributo que só deveria devolver um registo, mas que devido a dados errados devolve

dois) a execução do sistema será abortada;

• por outro lado, se o erro não violar nenhuma restrição de integridade, os dados serão colocados

nas tabelas de factos e dimensões, mas não se garante a sua coerência.

De um modo geral, quando os erros acontecem devido a erros nos próprios sistema fonte, nada

se pode garantir sobre a integridade dos dados que serão colocados na Data Warehouse, visto que o

sistema foi concebido na assunção de que os dados provenientes dos sistema fontes são coerentes

e correctos. Assim neste aspecto o sistema não é muito robusto na recuperação de grandes falhas.

O sistema como foi visto apenas consegue recuperar parcialmente de uma falha (casos em que os

ficheiros das fontes de dados são inexistentes).

5.4.1.2 Erros de execução

Os erros de execução referem-se também a dois tipos de erros. Erros de execução do próprio sistema

(como seja uma falha de energia no servidor onde está a correr ou outro evento exterior ao próprio

sistema que provoque a paragem da execução do sistema) e erros de inserção nas tabelas de factos.

Quando erros de execução do próprio sistema acontecem, embora não exista qualquer tipo de recu-

peração automática, o utilizador do sistema pode consultar os relatórios de controlo (ver secção 3.3) e

consultar qual o último módulo a ter sido executado correctamente. Por exemplo se o sistema antes de

ter falhado já tinha executado o seu fluxo até às tabelas de dimensões (algo que pode ser visto se estas

tiverem uma dada de fim de integração), o utilizador poderia optar por continuar a execução do sistema

a partir das tabelas de factos, reduzindo assim o tempo que levaria a executar o sistema novamente.

Por outro lado, os erros durante o carregamento das tabelas de factos, não causam qualquer paragem

ou erro nos dados que vão ser colocados na Data Warehouse. Estes erros ocorrem quando um dado

tuplo que se pretende inserir na tabela de factos possui chaves estrangeiras inválidas para as tabelas

de dimensões; neste caso o tuplo é colocado numa tabela de erros, onde pode ser depois corrigido

manualmente e voltar a sofrer o processo de integração (Ver secção 3.2.3.1).

5.5 Testes de Eficiência da solução de ETL

Depois de ter sido analisada a eficácia da solução desenvolvida é agora importante verificar aspectos

relacionados com a sua eficiência.

5.5.1 Tempo de execução da solução

Tal como foi dito na secção acima (Ver secção 5.4) em média a solução de ETL desenvolvida demora

56 minutos a ser executada para os dados de um dia de operações no call center. Este tempo resulta

numa média de 0,057 segundos por cada tuplo a inserir na data warehouse. Considerando esse valor,

é importante perceber onde a solução dispende mais tempo a ser executada.

59

5.5.1.1 Tempo dispendido na execução da solução em cada módulo

Utilizando as primitivas da Figura 5.1, as quais descrevem o fluxo da solução desenvolvida, vão analisar-

se os tempos médios dispendidos em cada módulo; a Figura 5.3 mostra as percentagens médias de

tempo ocupadas em cada módulo.

Figura 5.3: Percentagem de tempo dispendido em cada componente da solução ETL.

Na Figura 5.3, F1, F2 e F3 correspondem às difusões dos ficheiros dos sistemas fonte, respecti-

vamente CCS, uCI e Gespluri (ou WFM). F6.1 e F6.2 correspondem às Integrações das tabelas de

Dimensões e Factos respectivamente. É importante salientar que, nesta figura os módulos F6.1 e F6.2,

englobam os restantes módulos do Fluxo da figura 5.1, isto é, F4(F4.1,F4.2 e F4.3) e F5. Dado o fluxo

de execução da solução de F4 a F6 se realizar num único passo e sendo bastante difícil diferenciar o

tempo de cada uma das partes, considera-se que os tempos destas actividades intermédias vão ser

contabilizados nas integrações das tabelas de dimensões e factos (F6.1 e F6.2). Através da figura 5.3

observa-se que, em média 75% do tempo dispendido é realizado a fazer a difusão dos ficheiros CCS e

as principais razões para este facto são:

• Cada campanha ser representada num ficheiro diferente, no sistema fonte CCS, ao contrário do

que acontece, por exemplo, com as campanhas uCI, todas representadas num único ficheiro. Este

facto conduz à necessidade de criar uma iteração na difusão destes ficheiros, para se processar

cada uma das campanhas existentes (média de 370, por dia). Esta operação é relativamente

dispendiosa, pois cada ficheiro CCS precisa, em média, de 4 a 7 segundos para processar. Além

do mais, a própria iteração em si é complexa de implementar, usando o Microsoft Integration

Services 2005 [25].

• A razão apontada acima é agravada pela necessidade de processar duas vezes o mesmo ficheiro

CCS, visto o seu formato dificultar a extracção da informação numa só vez;

• Finalmente o facto de após a extracção estar concluída, terem de se formatar alguns campos

que vêm irregulares do próprio Excel, como por exemplo as durações que vêm num formato do

género "01-01-1989 horas:minutos segundos", sendo necessário retirar a porção inválida da data

60

e passar o formato "horas:minutos segundos"para um valor em segundos agrava ainda mais o

tempo de processamento deste tipo de ficheiros.

Nos Anexos, no capítulo 11 pode ser consultado o fluxo de difusão criado para lidar com as especifici-

dades deste tipo de ficheiros.

Outra das actividades que ocupa uma relativa porção de tempo na execução do sistema diz respeito

ao carregamento das tabelas de factos (F6.2), ocupando cerca de 16% no carregamento dos dados

operacionais relativos a um dia. Uma das razões pelas quais esta actividade demora uma relativa

quantidade de tempo, diz respeito à operação de validar as chaves estrangeiras para as tabelas de

dimensões, isto é, as operações de Lookup. Por exemplo um workflow como o usado para popular

a tabela F_Times_uCI com 19140 registos leva em média 86 segundos. Caso este fluxo seja feito

recorrendo a instruções SQL em vez de se utilizar o operador Lookup o fluxo demora em média cerca

de 10 segundos. Assim até cerca de 88% do tempo gasto no carregamento das tabelas de factos

decorre do tempo dispendido nas operações de Lookup, que demonstra que estas têm de facto uma

carga considerável no sistema de ETL desenvolvido. Outro dos locais onde se consome bastante tempo

para o carregamento das tabelas de factos, é na computação das vistas usadas para popular estas

tabelas (ver secção 3.2.1 e secção 3.2.2). Estas vistas devido a incluírem bastantes tabelas do ODS

e lidarem com um grande volume de dados, acabam por levar algum tempo a ser computadas, o que

atrasa consideravelmente o carregamento das tabelas de factos. Para além disso, se a quantidade de

dados a integrar for demasiado grande (na ordem dos milhões), as vistas podem até nem ser passíveis

de execução, assunto que será abordado em mais detalhe na secção 5.6.

5.5.1.2 Tempo dispendido na execução da solução com o aumento do volume de dados

É agora importante perceber como as actividades do fluxo ETL da solução desenvolvida se comportam

quando o volume de dados aumenta. Suponha-se a situação de se processarem sete dias de volumes

de dados de operações do call center, isto equivale a cerca de :

• 7700000 registos da fonte de dados uCI;

• 98000 registos da fonte de dados CCS;

• 26000 registos da fonte de dados Gespluri;

• 4117840 tuplos a inserir nas tabelas de factos e dimensões.

O gráfico da Figura 5.4 mostra as percentagens médias de tempo ocupadas em cada módulo para o

carregamento de sete dias de dados operacionais.

Como se pode observar pelo gráfico da Figura 5.4 continuam a ser as componentes F1 (Difusão

dos ficheiros CCS) e F6.2 (Carregamento das tabelas de factos) que voltam a dominar grande parte

do tempo de execução. Note-se que, por exemplo, a difusão dos ficheiros CCS, vai sempre crescer

proporcionalmente ao número de ficheiros, isto é, dobrando o número de ficheiros, dobra-se o número

de registos e consequentemente o tempo dispendido. Quanto às tabelas de factos o seu crescimento

vai ser um pouco abaixo do linear, revelando um comportamento bastante similar ao observado na

Figura 5.2. As tabelas de dimensões têm um comportamento que varia muito com os dados que se

61

Figura 5.4: Percentagem de tempo dispendido em cada componente da solução ETL.

pretende inserir, isto é, se muitos dos dados que se pretendem inserir já existirem na tabela, o seu

crescimento é quase nulo (pois os dados não serão inseridos); se os dados forem novos na tabela,

terão de ser inseridos, sendo o crescimento quase linear como o que acontece nas tabelas de factos.

Já as difusões revelam um crescimento bastante reduzido (à excepção do caso dos sistemas fonte

CCS). Veja-se que a difusão para uma tabela como a uCI_segment, possuindo cerca de 87000 registos

leva cerca de 3 segundos; a difusão para esta tabela a partir de um registo com 314000 entradas leva

aproximadamente 7 segundos. Assim pode-se afirmar que com o crescimento do volume de dados,

os componentes que mais recursos temporais vão consumir serão, primeiro, as difusões dos sistemas

fonte CCS (consumindo cerca de 3/4 do tempo dispendido) e segundo, os carregamentos das tabelas

de factos.

5.5.1.3 Tempo dispendido na execução da solução incluindo uma percentagem de erros

Esta métrica, devido à percentagem de erros que ocorriam ser tão reduzida, não foi contemplada nesta

Validação experimental.

5.5.2 Carga adicional de recursos consumidos durante a execução da solução

Estas medições não foram submetidas a uma validação experimental, devido a restrições temporais.

No entanto podem-se fazer algumas considerações sobre os resultados que foram observados ao longo

da concepção do sistema.

Na memória consumida pelo workflow ETL nos sistemas fonte, esta seria impossível de calcular,

pois nunca se acedia directamente aos sistemas fonte, ao invés acedia-se a ficheiros disponibilizados

pelo call center gerados por estes sistemas fonte. Deste modo não se conseguiria apurar da carga que

estes sistemas tinham ao gerar estes ficheiros.

Na memória consumida, esta em média era elevada e embora não se tenha feito um estudo exaus-

tivo sobre a sua evolução ao longo da execução do workflow ETL, em média eram consumidos cerca de

62

1500 MB de memória Ram durante a execução. Este valor representa uma grande carga no sistema.

No entanto apesar de elevado, considerando que a aplicação iria ser colocada num servidor onde não

estaria em concorrência com mais nenhuma aplicação pode-se considerar que o consumo de memória,

não iria afectar drasticamente o normal funcionamento da solução desenvolvida.

No que diz respeito ao Tempo necessário para completar um dado número de transacções à Data

Warehouse, para auxiliar os processos de decisão, aquando da execução do workflow ETL e Tempo

necessário para completar um dado número de transacções à Data Warehouse, para auxiliar os pro-

cessos de decisão, aquando da execução do workflow ETL com falhas nos dados dos sistemas fonte

ou Data Warehouse não foram efectuados testes. Ainda que, de um modo geral, seja expectável que

qualquer transacção efectuada durante a execução do workflow demore mais tempo do que a mesma

transacção efectuada isoladamente.

5.6 Considerações sobre a solução de ETL desenvolvida

Nesta secção vão ser feitas algumas considerações sobre a solução de ETL desenvolvida, nomeada-

mente no que diz respeito a aspectos potenciados pela ferramenta usada (Microsoft Integration Services

2005 [25]) e a aspectos que se relacionam com o desenho do workflow ETL desenvolvido.

No que se refere às limitações do Microsoft Integration Services 2005 [25], reforça-se a dificuldade

quando se tem de processar mais de um ficheiro a partir de uma mesma fonte, como acontece com as

fontes de dados do CCS. Este facto é agravado pelos ficheiros estarem no formato Excel, sendo que

neste caso, a obrigatoriedade de a ferramenta ter de se ligar a um ficheiro específico, ao invés de a uma

pasta, leva a que se tenham de seguir procedimentos como os descritos nos Anexos no capítulo 11,

nomeadamente o uso de pastas e ficheiros temporários, o que dificulta a utilização da ferramenta. Uma

possível solução seria a ferramenta possuir um comportamento similar ao demonstrado pelo Microsoft

Biztalk Server [64], que permite que um fluxo se ligue a uma pasta e sempre que esta recebe um

ficheiro novo, se inicie a execução do workflow.

Outra das limitações da ferramenta prende-se com a falta de operadores eficientes para realizar

operações comuns, salienta-se por exemplo a operação de Lookup, que pesquisa para uma tabela

de factos uma referência para uma tabela de dimensões. Embora esta operação tenha sido usada

extensivamente, ela leva algum tempo a processar os dados a inserir nos modelos multidimensionais.

Contudo, a escolha em utilizar este tipo de operador deveu-se sobretudo ao controlo que proporciona,

isto é, usando operações SQL, perante um erro por falta de referência para uma tabela de dimensões,

este registo seria reencaminhado para uma tabela de erros, com uma descrição genérica (por não ser

indicada qual das referências para as tabelas de dimensões falhara). Ao utilizar o operador Lookup é

possível distinguir cada tipo de erro, de uma forma mais facilitada, sabendo sempre qual das referências

originou o erro. Portanto neste caso optou-se por se sacrificar um pouco da eficiência do sistema em

prol dum maior controlo.

Nas principais opções de desenho é importante destacar dois pontos:

1. Utilização de vistas ao invés de tabelas materializadas;

63

2. Utilização extensiva de SQL e procedimentos ao invés dos operadores do Microsoft Integration

Services 2005 [25].

O primeiro ponto refere-se à fase de Integração (Ver secção 3.2). Nesta fase, quando se realizou a jun-

ção das várias tabelas do ODS (secção 3.2.1), optou-se por usar vistas ao invés de tabelas, para conter

os dados resultantes da junção. Esta escolha recaiu sobre o facto de que, usando vistas, facilmente se

poderiam adicionar novos atributos nas vistas, algo que usando tabelas seria impossível e, mais, que

obrigaria a que qualquer alteração conduzisse também a uma mudança em toda a estrutura da tabela).

No entanto esta opção acarreta duas grandes desvantagens. Em primeiro lugar, devido à complexidade

que integrar várias fontes de dados acarreta, o código da vista acaba por ser extremamente complicado

(ver Anexos 9 e 10) , o que torna a solução difícil de manter e escalar, caso se pretenda fazer altera-

ções estruturais. A decisão de separar as junções em duas vistas facilita um pouco a sua compreensão

(pois compartimenta as duas fases de construção (junção dos valores, secção 3.2.1 e cálculos, secção

3.2.2). Contudo, mesmo isto não impede que o código final de cada vista seja bastante complicado,

dificultando quaisquer alterações - o que curiosamente, note-se, era o propósito inicial do uso de vistas

em vez de tabelas físicas. A segunda grande desvantagem das vistas é que, por não materializarem

os dados, a sua computação, quando possuem registos na ordem dos milhões e vários cálculos asso-

ciados (como acontece com as vistas desenvolvidas), pode ser extremamente demorada, sendo, em

certos casos, mesmo impossível de realizar. Apesar de se perceberem as desvantagens das vistas,

considerando que os registos raramente estarão na casa dos milhões, o seu uso, no ambiente do call

center em questão, é relativamente seguro.

O segundo ponto refere-se ao pouco uso dado aos operadores existentes no Microsoft Integration

Services 2005 [25]. Para a maior parte das operações efectuadas optou-se por usar procedimentos

SQL, o que se deveu ao facto dos operadores não realizarem de forma rápida e eficaz certas operações,

ou não serem mesmo capazes de as executar. Por exemplo, apagar registos das tabelas, seleccionar

campos específicos, modificar registos nas tabelas bem como todas as operações relacionadas com

os mecanismos de controlo (ver secção 3.1.1 e secção 3.2.4) foram efectuadas usando procedimentos

SQL. O facto de se usarem procedimentos ao invés dos operadores existentes, requer assim que se

necessite, além de estudar o fluxo ETL criado com o Microsoft Integration Services 2005 [25], também

se tenha também de observar os procedimentos criados. No entanto, ao contrário do que acontece com

as vistas, o código aqui criado é de fácil compreensão, o que facilita a sua manutenção e uso, embora

manifestamente o seu uso acabe por levar a que não se tenham explorado todas as capacidades da

ferramenta Microsoft Integration Services 2005 [25].

64

6 Conclusão

Nesta tese avaliou-se e desenvolveram-se certas componentes de um sistema de Business Intelligence

para Call Centers. O aumento da exigência dos clientes, a par do volume de informação gerada entre

estes e as organizações, torna crítico o tratamento de uma forma eficiente, desta informação, de forma

a incorporá-la nos processos de tomada de decisão. Ao melhorar estes processos, as organizações

procuram activamente uma melhoria nos seus processos, visível quer na redução de custos, quer na

qualidade dos serviços prestados.

No Capítulo 1, vimos quais os componentes de uma organização como um Call Center, desde

estruturas, actores e principais operações. Partindo-se destes componentes procurou-se perceber os

seus requisitos no rápido tratamento de grandes volumes de informação. Neste contexto conclui-se que

o uso de um sistema de apoio à decisão, Business Intelligence, se torna essencial. Apenas com o uso

de tal sistema se pode efectuar uma eficiente monitorização de todas as métricas relevantes no Call

Center e de acordo com as suas medições, decidir quais os melhores cursos a tomar.

Para melhor compreender os sistemas de apoio à decisão aplicados ao ambiente dos Call Cen-

ters, procurou-se no Capítulo 2 desenvolver uma investigação sobre as principais ferramentas BI para

o mercado de Call Centers, procurando aferir das suas principais características. Conclui-se contudo

que é importante perceber claramente as necessidades do Call Center, no que diz respeito a uma fer-

ramenta de BI, visto estas poderem fornecer mais funcionalidades do que as desejadas, ou mesmo a

especificidade dos requisitos do Call Center levarem a que se tenha de criar de raiz uma ferramenta

deste tipo. Neste capítulo procurou-se ainda estudar como avaliar um dos componentes mais impor-

tantes de qualquer ferramenta de BI, os processos de Extracção, Transformação e Carregamento de

Dados (ETL). Neste ponto foi possível concluir que não existem ainda benchmarks standard para medir

a performance destes processos. Existem contudo abordagens, ainda que poucas, que se propõem a

designar metodologias e parâmetros, sobre os quais se pode averiguar o correcto funcionamento dessa

componente.

No Capítulo 3 esquematizam-se os processos de ETL criados, com especial cuidado em torná-

los o mais modulares possível. Procurou-se, assim, esquematizar uma abordagem que permita a

construção, de um modo facilitado, de um conjunto de processos de ETL para um sistema de BI.

Destaca-se assim, a separação por fases, Difusão e Integração, sendo cada uma delas compostas

por etapas específicas. Estas pretendem como resultado final a construção de um modelo eficiente

de suporte aos principais indicadores monitorizados no Call Center e processos de ETL que sejam

capazes de calcular estes indicadores de um modo rápido e coerente. É de salientar a opção do uso

de vistas não materializadas nas fases intermédias dos processos ETL (ao invés de tabelas físicas),

como meio de facilitar a separação entre o que eram as fases de recolha de informação e de cálculo de

informação, ainda que estas tenham vindo a revelar alguns problemas ao nível da performance.

No Capítulo 4 focamo-nos na última vertente do desenvolvimento do sistema de BI criado, a inter-

face que será apresentada aos utilizadores, os Dashboards. Neste capítulo conclui-se que o desenvol-

vimento de dashboards é um processo iterativo, acompanhado da criação e contínuo refinamento dos

protótipos criados. Aborda-se ainda a criação do Cubo OLAP, que providenciou a utilização de meca-

65

nismos mais evoluídos na pesquisa e análise dos dados existentes e facilitou a apresentação destes

dados por via dos dashboards desenvolvidos.

Finalmente, no Capítulo 5 foram efectuados testes à solução desenvolvida. Com estes testes foi

possível aferir da adaptabilidade da solução aos requisitos do negócio impostos pelo Call Center onde

ia operar. Estes requisitos passavam sobretudo por ter acesso a dados calculados de forma correcta,

nos momentos em que processos de tomada de decisão iam ser tomados. Neste aspecto o sistema

desenvolvido correspondeu aos objectivos definidos, tendo carregado e calculado dados diários, num

tempo médio de 56 minutos. Além do mais, foi também possível concluir que a solução consegue

processar grandes volumes de dados (exemplo, dados de sete dias de operações no Call Center e

mesmo assim respeitar os requisitos operacionais). Neste capítulo, estudou-se ainda a ferramenta

usada, o Microsoft Integration Services enquanto ferramenta capaz de criar e suportar processos de

ETL com um grande volume de dados. Identificaram-se assim algumas das principais limitações da

ferramenta e modos de as poder contornar. Também se teceram considerações sobre a metodologia

de ETL criada, nomeadamente no uso de vistas não materializadas, suas vantagens e desvantagens.

6.1 Trabalho Futuro

O trabalho desenvolvido, apesar de consistir um sistema completamente funcional e que se adapta às

necessidades de um Call Center, tem ainda espaço para algumas melhorias, sendo de desatacar:

1. Realização de mais testes de performance, nomeadamente na carga imposta por este sistema

sobre a data warehouse e na memória consumida. Poderiam assim procurar-se novas formas de

optimizar o sistema;

2. Utilizar tabelas físicas em vez de vistas não materializadas e aferir do aumento ou não da perfor-

mance global do sistema;

3. Implementação de mecanismos de alarmística, de forma a tornar o sistema mais pro-activo. Esta

funcionalidade poderia aumentar substancialmente a experiência de utilização dos sistema cri-

ado, pois o sistema passaria a alertar o utilizador para o aparecimento de situações anómalas,

que necessitassem de correcção, ou corrigir ele próprio algumas destas situações. Outra das

funcionalidades poderia ser a de avisar o utilizador que teria de melhorar a sua performance (por

exemplo: numero de vendas por chamada), para cumprir com os objectivos exigidos. Este seria

um ponto de grande interesse em testar na ferramenta, visto serem ainda poucos os sistemas de

BI, principalmente no âmbito dos Call Centers, que proporcionam tais mecanismos.

4. Exploração de técnicas de data mining, para retirar mais informação dos dados fornecidos, e

consequentemente melhorar os indicadores mostrados aos utilizadores;

5. Testar novas ferramentas, tanto para criar os processos ETL como para criar os Dashboards,

visto as ferramentas utilizadas apresentarem algumas limitações. Na criação dos processos de

ETL poder-se-ia aferir da adaptabilidade de outras ferramentas à criação de um sistema deste

tipo e compará-las com a ferramenta usada.

6. Finalmente seria interessante comparar a performance do sistema com a de sistemas de BI es-

66

pecíficos para Call Centers, como meio de encontrar novas formas de melhorar o sistema desen-

volvido.

67

Referências[1] P. Vassiliadis, A. Karagiannis, V. Tziovara, and A. Simitsis, “Towards a benchmark for etl workflows,”

ACM, 2007.

[2] B. Downey, “Call center vs. contact center,” Search CRM, July 2001.

[3] J. C. Abbott, “The executive guide to call center metrics,” Robert Houston Smith Publishers, 2004.

[4] RR, “What is a call center?,” Conjecture Corporation.

[5] J. Wu, “Visualization of key performance indicators,” DM Review Online, Maio 2002.

[6] A. Politano, “Chief performance officer: Measuring what matters, managing what can be measured,”

iUniverse, 2003.

[7] E. Zbikowski, “The essential call center kpis,” Call Center Magazine, Março 2007.

[8] L. Bocklund, “Qality metrics for the call center,” Search CRM, Outubro 2005.

[9] H. Baird, “Maintaining service quality in the contact center, ensuring data validity,” Telecom Directi-

ons LLC - Independent Telecom Market Analysis and Needs Assesment, Março 2004.

[10] “Business intelligence in the contact center,” Viecore, Business Consulting Services.

[11] A. C. Montefusco, H. A. Mattos, R. P. Mendonça, and M. M. Moraes, “Business intelligence: As em-

presas do segmento de call center no brasil podem ser mais eficientes na contratação e retenção

de funcionários,” FIAP, 2008.

[12] P. G. W. Keen and M. S. Scott Morton, Decision Support Systems: An Organizational Perspective.

Addison-Wesley, Reading, MA., 1978.

[13] D. Power, “A brief history of decision support systems,” DSSResources.COM, Março 2007.

[14] J. Griffin, “Delivering on the business intelligence value proposition,” Dm Review Online, Agosto

2001.

[15] C. White, “The next generation of business intelligence: Operational bi,” DM Review Online Maio

de 2005, Maio de 2005.

[16] P. Nunes, “Dashboards de gestão operacional para empresas de transportes,” Tese de Mestrado

de Engenharia Informática, Instituto Superior Técnico, 2007.

[17] “Business intelligence,” Kairon, 2003.

[18] R. Kimball, The Data Warehouse Lifecycle Toolkit. Wiley Publishing, Inc, 1998.

[19] D. Hackney, “What are the major differences between rolap and molap?,” DM Review Online, Agosto

1999.

[20] J. Chaterjee, “Using data mining for business intelligence,” MS SQL Server, Janeiro 2005.

69

[21] “Glossary,” Dm Review Online.

[22] R. Morrisey, “Dashboards, analysys mind share, and kpi’s,” Spectrum Magazine, September/Octo-

ber Edition, 2005.

[23] “Picturing performance: Dashboards and scorecards with cognos,” Cognos, Novembro 2007.

[24] Link Consulting, http://www.link.pt/.

[25] Microsoft SQL Server 2005: Integration Services, http://www.microsoft.com/sql/technologies/integration.

[26] S. Few, Information Dashboard Design. O’Reilly, Janeiro 2006.

[27] K. Schlegel, B. Hostmann, and A. Bitterer, “Magic quadrant for business intelligence platforms,”

Gartner RAS Core Research, Janeiro, 2007.

[28] J. Richardson, K. Schlegel, B. Hostmann, and N. McMurchy, “Magic quadrant for business intelli-

gence platforms,” Gartner RAS Core Research, 2008.

[29] D. Kraus and B. Elliot, “Magic quadrant for contact center infrastructure, north america,” Gartner

RAS Core Research, Agosto 2007.

[30] K. Gile, K. McNabb, C. Moore, and L. Fossner, “The forrester wave: Bi reporting and analysis

platforms, q1 2006,” Forrester, Fevereiro 2006.

[31] Microsoft SQL Server 2005, http://www.microsoft.com/SQL/default.mspx.

[32] Miscrosoft Sharepoint 2005 ,http://msdn.microsoft.com/en-us/sharepoint/default.aspx.

[33] Microsoft Reporting Services 2005 ,http://www.microsoft.com/sql/technologies/reporting.

[34] h.-b. Microsoft Excel 2007

[35] Miscrosoft Visual Studio 2005, http://msdn.microsoft.com/en-us/vs2005/default.aspx.

[36] J. Griffin, “Choosing the right business intelligence software and vendor,” DM Review Magazine,

Junho 2003.

[37] Avaya IQ, Avaya, http://www.avaya.com/.

[38] Contact Center Analytics, Business Objects, http://www.crm2day.com/library/docs/wp0192.pdf.

[39] AgentView, Centergistics Solutions, http://www.dacon.co.uk/product_pdf/pdf_26.pdf.

[40] Envision Business Intelligence, Envision, http://www.envisioninc.com/.

[41] Genesys Contac Center Software, Genesys, http://www.genesyslab.com/.

[42] Inova Solutions Call Center Dashboard, Inova Solutions, http://www.inovasolutions.com/.

[43] Contact Centre Solutions inDashboard, inRound Innovations, http://www.inround.com/.

70

[44] Latigent, Cisco, http://www.inround.com/.

[45] EyeOps, LiveOps, http://www.liveops.com/.

[46] People Soft Service Dashboard, Oracle, http://www.oracle.com/solutions/business_intelligence/.

[47] Performance Management, Performance Edge, http://www.performanceedgesuite.com/.

[48] PilotWorks, Pilot Software, www.pilotsoftware.com.

[49] Right Now Reporting and Dashboards, Right Now, http://www.rightnow.com/products/reporting-

dashboards.php.

[50] SpeedWare Call Center Solutions, SpeedWare, http://www.speedware.com/.

[51] nVision, Symmetrics, http://www.symmetrics.net/solutions/contactcenter.aspx.

[52] Contact Center Solutions Vista, Symon, http://www.symon.com/index.asp?bid=27.

[53] Seratel, Transera, http://www.transerainc.com/transera/.

[54] Verint Contact Center Solutions, Verint, http://verint.com/contact_center/index.cfm.

[55] VPI Call Center Performance Dashboards, VPI, http://www.vpi-corp.com/.

[56] J. Wu, “Web reporting capabilities: Building versus buying,” DM Review Online, DM Review Online.

[57] T. Friedman, M. A. Beyer, and A. Bitterer, “Magic quadrant for data integration tools,” Gartner RAS

Core Research, 2007.

[58] J. Alan, “High performance extract/transform/load benchmark,” RODIN Data Asset Management,

2002.

[59] M. Böhm, D. Habich, W. Lehner, and U. Wloka, “Dipbench toolsuite: A framework for benchmarking

integration systems,” Database Technology Group, Dresden University of Techology, 2008.

[60] S. Abiteboul, R. Agrawal, P. A. Bernstein, M. J. Carey, S. Ceri, W. B. Croft, D. J. DeWitt, M. J. Fran-

klin, H. G. Molina, D. Gawlick, J. Gray, L. M. Haas, A. Y. Halevy, J. M. Hellerstein, Y. E. Ioannidis,

M. L. Kersten, M. J. Pazzani, M. Lesk, D. Maier, J. F. Naughton, H. Schek, T. K. Sellis, A. Silbers-

chatz, M. Stonebraker, R. T. Snodgrass, J. D. Ullman, G. Weikum, J. Widom, , and S. B. Zdonik,

“The lowell database research self assessment,” CoRR, 2003.

[61] J. Gray, The Benchmark Handbook for Database and Transaction Systems. Morgan Kaufmann,

1993.

[62] Altitude Software uSupervisor, http://www.altitude.com/.

[63] E. Thomsen, “Construindo sistemas de informações multidimensionais,” São Paulo: Campus

2aEdição, 2002.

[64] “Microsoft biztalk server, http://www.microsoft.com/biztalk/,”

[65] Alcatel OmniPCX 4400 Série CCx, http://www.alcaphone.com.br/alcatel.htm.

71

7 Anexo - Conteúdo das fontes de dados

No sistema CCDM, foram usadas três fontes de dados:

• CCS (Call Center Supervisor ) - ficheiros disponibilizados pela central telefónica da Alcatel [65],

tipicamente em ficheiros Excel, que contêm dados referentes a chamadas de inbound de várias

campanhas;

• uCI - ficheiros disponibilizados pelo sistema de supervisão de interacções com clientes do call

center, o uSupervisor da Altitude [62]. Estes ficheiros são usados preferencialmente nas cam-

panhas de outbound. Os ficheiros contêm dados sobre a maioria das operações do call center,

nomeadamente chamadas de inbound, chamadas de outbound, campanhas, agentes;

• Gespluri (também conhecido por WFM, ou seja Work Force Management) - solução de gestão

dos agentes e campanhas que contém dados como os horários dos agentes por cada campanha

e as necessidades de cada campanha em agentes. Esta solução é proprietária do call center.

O CCS é independente das duas outras fontes de dados usadas. Já o sistema uCI pode ter várias

instâncias da mesma campanha mapeadas no sistema Gespluri. Tal facto ocorre para optimizar a uti-

lização dos servidores que alojam as campanhas do call center. Por exemplo, uma campanha A pode

estar mapeada como A1 e A2 no sistema Gespluri, e por sua vez cada uma destas duas instâncias pos-

suir uma parte dos dados da campanha A do sistema uCI. Esta situação verifica-se, sobretudo, quando

uma mesma campanha está a decorrer em mais do que uma localização diferente - por exemplo, a

decorrer nas instalações do call center em Lisboa e Setúbal, simultaneamente. Quando isto acontece,

embora a campanha seja a mesma, o sistema Gespluri representa-a dividida em duas instâncias, re-

presentativas de cada uma das localizações físicas onde a campanha está a correr. Deste modo a

carga em cada um dos servidores Gespluri é menor, facilitando a recolha dos dados. Apenas quando

estes têm de ser analisados é que existe a necessidade de integrar as várias instâncias existentes.

O conteúdo das tabelas de cada uma das três fontes de dados encontra-se descrito nas secções

abaixo (secção 7.1,secção 7.2 e secção 7.3). As chaves primárias das tabelas encontram-se sublinha-

das e a as chaves estrangeiras estão em itálico.

7.1 Fontes de Dados - CCS

O esquema destas tabelas é o seguinte:

CT_Pilots Tabela com informação sobre as chamadas efectuadas em regime de outbound

Estrutura (DiffusionID, CampaignDate, CampaignName, CampaignCode, fileName, Hora,

Calls_received_in_open_state, Calls_received_in_blocked_state,

Calls_received_in_general_forwarding_state (...))

Chaves CampaignCode:Fk WFM.Campanhas

CT_Pilots_Info Tabela com informação sobre as chamadas efectuadas em regime de outbound

Estrutura (DiffusionID, name, code, dia, mes, ano, filename, Tipo)

73

7.2 Fontes de Dados - uCI

Esquema das tabelas das fontes de dados uCI:

Ag_in_cp_log Informação sobre um login de um agente numa campanha

Estrutura (DiffusionID,code, campaign, agent, start_time, duration , op_type, reason)

Chaves Campaign:Fk uCI.Campaign; Agent :Fk uCI.Agent

Agent informação sobre o agente a trabalhar numa campanha

Estrutura (DiffusionID, underlinee_user, type, position_id, record_voice, record_data, sw_supervisor,

sys_alarm_profile)

Call_thread Uma chamada telefónica numa campanha

Estrutura (DiffusionID , code, global_call, termination_status, recording_key, el_thread_id, trunk_line,

recorder_type, recording_status, rec_failure_reason)

Chaves Global_call : Fk uCI.Global_call

Campaign Representação de uma campanha no sistema

Estrutura (DiffusionID, code, shortname, fullname , campaigntype, status, foreseen_start, fore-

seen_end, foreseen_calls, start_time, end_time)

Contact Contacto efectuado numa campanha

Estrutura (DiffusionID, code, campaign, status, agent, moment, dial_rule, priority, timezone,

is_special, ivacc_user, ntries_auto, ntries_manual)

Chaves Campaign:Fk uCI.Campaign; Agent:Fk uCI.Agent; Timezone:uCI.Timezone

Dnis Implementação dos códigos da campanha

Estrutura (DiffusionID, code, gw_switch, campaign, dnis)

Chaves Campaign:Fk uCI.Campaign; Dnis:Fk CCS.Pilots (CampaignCode), CCS.PilotsEstatisticos

(CampaignCode)

Data_context Dados associados a um segmento e a transacções

Estrutura (DiffusionID, code, campaign, contact)

Chaves Campaign:Fk uCI.Campaign; Contact:Fk uCI.Contact

Human Especialização do tipo agente, representando um agente humano

Estrutura (DiffusionID, agent, fullname, default_extension, type, motd, ivacc_user)

Chaves Agent:Fk uCI.Agent

E_user Informação sobre o agente

Estrutura (DiffusionID, code, usr_name, type, password, active, default_permission)

Chaves Usr_name: Fk WFM.Horario (login); Usr_name: Fk WFM.Avaliacoes (login)

Global_call Uma chamada telefónica usada para chamadas de inbound, outbound ou internas

Estrutura (DiffusionID, code, call_key, ph_number, dnis, contact, phone)

Chaves Dnis: Fk Dnis

Not_ready_reason Descrição dos erros ocorridos numa chamada

Estrutura (DiffusionID, code, namechar, description, is_built_in, active, id_in_switchint)

Segment Segmento de uma interacção

74

Estrutura (DiffusionID, code, e_user, team, thread, state, extension, start_time, duration, seg_order)

Chaves E_user:Fk e_user; Thread: Fk thread

Thread Uma interacção numa campanha (que pode ser uma chamada telefónica ou interacção de

dados)

Estrutura (DiffusionID, code, thread_type, data_context, start_time, origin)

Chaves Data_context:Fk data_context

Timezone Representação da zona de tempo no servidor da campanha

Estrutura (DiffusionID, code, shortname, fullname, gmt_offset, dst_active, dst_abreviation, start_nday,

start_dayofweek, start_month, start_time, end_nday, end_dayofweek, end_month, end_time,

dst_bias)

DataTransaction Representa uma transacção de dados

Estrutura (DiffusionID, code, data_context, start_time, duration, call_type, e_user, team, recor-

der_type, recording_key, site)

Chaves E_user:Fk e_user; Data_Context: Fk e_user

CallType Tipo de chamada

Estrutura (DiffusionID, code, name, description, campaign, call_type_id)

Chaves Campaign: Fk campaign

Contact_Phone Telefone associado a um contacto

Estrutura (DiffusionID, contact, phone, active, p_status, ph_number, ntries_busy, ntries_noanswer,

ntries_machine, ntries_fax, ntries_modem, ntries_rejected, ntries_invalid, ntries_lineovrflw)

Chaves Contact: Fk contact ; Phone: Fk phone

Phone Tipos de telefone

Estrutura (DiffusionID, code, name)

Dial_rule Regra de chamada associada a um contacto

Estrutura (DiffusionID,code, name, recall_tries_total )

7.3 Fontes de Dados - Gespluri (WFM)

Esquema das tabelas das fontes de dados Gespluri:

Horario Informação sobre os horários dos agentes numa campanha

Estrutura (DiffusionID, Login, campanha_id, Data, hora_inicio, hora_fim, Obs, Nmindecimal, Pa-

gar, data_criacao, criado_por, data_alteracao, alterado_por)

Chaves Campanha_id:Fk WFM.Campanhas

Campanhas Dados relativos a uma campanha em execução

Estrutura (DiffusionID, campanha_id, id_easy, camp_descricao, camp_desc_det,easy, tipo_campanha,

sub_tipo_camp, perfil_id, instancia_id, activa, paga, min_horas, max_horas, data_inicio, data_fim,

hor_fixo, tipo_hor_fixo, e_mail, e_mail_equipa, adjudicada, perc_adj, nproposta, ordem_compra,

nhoras_form, cod_cliente, cod_industria, avaliada, sucursal, iva, data_criacao, criado_por,

data_alteracao, alterado_por)

75

Chaves Sucursal: Fk WFM.CallCenters

Avaliações Informação sobre as avaliações efectuadas aos agentes pelos seus supervisores e team-

leaders

Estrutura (DiffusionID, login, campanha_id, data, cotacao, observacao, camp_id, motivo, cod_grupo,

cod_sub_grupo, msisdn_conta, handling, score, estado, camp_id2, consolidacao, num_gravacao,

aval_entre_sites, criado_por, data_criacao)

Chaves Campanha_id:Fk WFM.Campanhas

CallCenters Informação sobre os call centers em que as campanhas decorrem

Estrutura (DiffusionID, cod_call_center, call_center)

76

8 Anexo - Indicadores de Negócio

8.1 Indicadores de Chamadas Inbound

Received Número de chamadas recebidas

Received by internal transference Número de chamadas recebidas por transferência interna

Received with blocked agent Número de chamadas recebidas com o agente no estado bloqueado

Received diverted Número de chamadas redirigidas

Rejected by lack of resources Número de chamadas rejeitadas devido a haver falta de recursos

Timing overflow while calls were in queue Número de chamadas rejeitadas devido a se ter excedido

o tempo máximo permitido

Total Handled Número de chamadas atendidas

Handled within 5sec Número de chamadas atendidas nos primeiros 5 segundos




Handled within more than 60sec Número de chamadas atendidas após 60 segundos

Total Abandoned Número de chamadas abandonadas

Abandoned within 5sec Número de chamadas abandonadas nos primeiros 5 segundos




Abandoned within more than 60sec Número de chamadas abandonadas após 60 segundos

SLA Service Level Agreement

SLARefValue Valor de referência do SLA

8.2 Indicadores de Tempos (Times)

Total call time Tempo total de chamadas

Total talk time Tempo total de conversação

Total hold time Tempo total de espera do cliente durante a chamada

Total wrap-up time Tempo total que o agente levou a efectuar operações após ter terminado a cha-

mada

Total wait time Tempo total na fila de espera

Total wait time of received Tempo total em fila de espera das chamadas atendidas

Average call time Tempo médio de chamadas

Average talk time Tempo médio de conversação

Average hold time Tempo médio de espera do cliente durante a chamada

Average wrap-up time Tempo médio que o agente levou a efectuar operações após ter terminado a

chamada

77

Average wait time Tempo médio na fila de espera

Average wait time of received Tempo médio em fila de espera das chamadas atendidas

8.3 Indicadores de Agentes

isAgentLogged Indica se o agente está ligado ao sistema naquele dado instante

Total logged agents Número total de agentes ligados ao sistema

Talk time Tempo que o agente esteve em conversação

Calls on hold O número de chamadas em espera

Calls with wrap-up Número de chamadas terminadas

Total idle time Tempo que o agente estava disponível para trabalhar mas não recebeu nenhuma cha-

mada

Average idle time Tempo médio em que o agente estava disponível para trabalhar mas não recebeu

nenhuma chamada

Login time (hours) Tempo que o agente esteve ligado ao sistema

Total not-ready time Tempo total que o agente esteve numa campanha mas não pôde atender cha-

madas

Not-ready reason 1 (break) Tempo que o agente não pode receber chamadas devido a estar num

intervalo

Not-ready reason 2 (doubts) Tempo que o agente não pode receber chamadas devido a estar a es-

clarecer dúvidas

Not-ready reason 3 (break at other campaign) Tempo que o agente não pode receber chamadas de-

vido a uma falha numa campanha

Not-ready reason 4 (forced) Tempo que o agente não pode receber chamadas devido a uma falha

interna

Not-ready reason 5 (cleanup) Tempo que o agente não pode receber chamadas devido a uma lim-

peza no estado do agente

Not-ready reason 6 (sign off) Tempo que o agente não pode receber chamadas devido a ter perdido

a ligação à campanha

Work hours Horas de trabalho do agente

Absence hours Horas em que o agente esteve ausente

Evaluations Número de avaliações realizadas ao agente

Productivity rate Taxa de produtividade do agente

Incoming calls Número de chamadas de entrada atendidas pelo agente

Outgoing calls Número de chamadas de saída efectuadas pelo agente

Open time Tempo em que o agente está associado a uma campanha, embora possa não receber

chamadas

Total not-ready time rate Tempo médio que o agente esteve numa campanha mas não pôde atender

chamadas

78

Not-ready reason 1 (break) rate Tempo médio que o agente não pode receber chamadas devido a

estar num intervalo

Not-ready reason 2 (doubts) rate Tempo médio que o agente não pode receber chamadas devido a

estar a esclarecer dúvidas

Not-ready reason 3 (break at other campaign) rate Tempo médio que o agente não pode receber

chamadas devido a uma falha numa campanha

Not-ready reason 4 (forced) rate Tempo médio que o agente não pode receber chamadas devido a

uma falha interna

Not-ready reason 5 (cleanup) rate Tempo médio que o agente não pode receber chamadas devido a

uma limpeza no estado do agente

Not-ready reason 6 (sign off) rate Tempo médio que o agente não pode receber chamadas devido a

ter perdido a ligação à campanha

Ready Tempo que o agente esteve numa campanha disponível para receber chamadas

8.4 Indicadores de Campanhas

Idle Time O tempo em que a campanha esteve disponível para receber chamadas mas não recebeu

nenhuma

NumberAgents Número total de agentes

LoginTime Tempo de login total

CampaignWorkHours Número de horas de trabalho de numa dada campanha

Average login time per agent Tempo médio de login

Average idle time per agent (min) Tempo médio em que o agente esteve disponível para receber cha-

madas mas não recebeu nenhuma

Total needed agents per hour Número de agentes necessários por hora

Total logged agents per hour Número de agentes ligados a campanhas por hora

Average needed agents per hour Média de agentes necessários por hora

Average logged agents per hour Média de agentes ligados a campanhas por hora

Overbooking rate Taxa de overbooking

Vacation request rate Taxa de pedidos de férias

8.5 Indicadores de KPI’s

Open Time Tempo em que uma campanha está activa, embora possa não receber chamadas

Work Hours Número de horas de trabalho por campanha

Open / Work hours Taxa em que a campanha esteve activa sobre o número de horas trabalhadas

Ready Time Tempo em que a campanha está disponível para receber chamadas

Ready / Open Taxa em que a campanha esteve disponível para receber chamadas sobre o tempo de

actividade

79

Talk Time Tempo total de conversação

Talk / Ready Taxa do tempo de conversação sobre o tempo em que a campanha esteve dispon+ivel

para receber chamadas

NumberCalls Número de chamadas

Call Time Tempo total de chamadas

Average call time Tempo médio de chamadas

Number Supervisors Número de supervisores

Number Agents Número de agentes

Supervisors/Agents Taxa de supervisores sobre o número de agentes

Turnover Taxa de rotação

Absenteeism rate Taxa de absentismo

Average call time / Ready Tempo médio de chamada sobre o tempo de actividade da campanha

Absence Hours Número de horas ausentes dos agentes

Absence hours / Work hours Taxa de horas em que os agentes estiveram ausentes sobre o seu

tempo de trabalho

Quality rate Taxa de qualidade

Gross margin Margem de Lucro

Gross margin rate Taxa da margem de lucro

SLA SLA de cada campanha

Hours Horas de trabalho de cada campanha

8.6 Indicadores Financeiros

Revenue Lucro

Costs Custos

Rentability Rentabilidade

Margin

Phone charges Taxação telefónica

Revenue per hour Lucro por hora

Phone charges per hour Taxação telefónica por hora

Costs with phone charges Custos com telefonemas

Costs with db Custos com bases de dados

Costs with agents Custos com agentes

Costs - other Outros custos

CampaignOperationHours Número de horas de operação de cada campanha

8.7 Indicadores de Chamadas Outbound

Login Hours Tempo de login dos agentes a fazerem chamadas

80

Dials Conected Número de chamadas efectuadas

NumAgents Número de agentes a fazerem os contactos

NumCalls Número de chamadas

TalkTime Tempo total de conversação

CallTime Tempo total de chamada

Sales (or Inquiries) Número de vendas ou inquéritos

Useful contacts Número de contactos úteis

Difficulties Número de dificuldades

Not interested Número de contactos em que o destinatário disse não estar interessado

Sales per login hour Vendas por hora de login

Contacts per login hour Contactos por hora de login

Response rate Taxa de respostas

Completed contacts Número de contactos completos

Completed contacts per login hour Contactos completos por hora de login

Contacts per login hour and per agent Contactos por hora de login e agente

Difficulties rate Taxa de dificuldades

Contacts rate Taxa de contactos

Dials Número de chamadas

Dials per login time Número de chamadas por hora de login

Abandonment rate Taxa de abandonos

Pending Número de chamadas que estão em espera

Average talk time per complete contact (min) Tempo médio de conversação por contacto completo

Average talk time per sale (min) Tempo médio de conversação por venda/inquérito

Average talk time per agent (min) Tempo médio de conversação por agente

Average call time per agent (hour) Tempo médio de chamada por agente

81

9 Anexo - Vista F_Times_uCI_V1

SELECT t e rm ina t i on_s ta tus

FROM dbo . uCI_ca l l_ th read AS c

WHERE ( dbo . uCI_thread . code = code ) ) AS t e rm ina t i on_s ta tus ,

dbo . uCI_segment . thread , dbo . uCI_segment . s ta te , dbo . uCI_segment . du ra t i on / 10 AS dura t ion ,

dbo . uCI_segment . seg_order , dbo . uCI_segment . e_user ,

(SELECT UPPER( usr_name ) AS Expr1

FROM dbo . uCI_e_user AS b

WHERE ( code = dbo . uCI_segment . e_user ) ) AS usr_name ,

CAST(FLOOR(CAST( dbo . uCI_segment . s t a r t _ t i m e AS FLOAT ) ) AS DATETIME) AS s ta r t_da te ,

dbo . uCI_data_context . campaign AS campanha_ID_UCI , dbo . uCI_segment . d i f f u s i o n I D ,

CASE WHEN DATEPART( hh , dbo . uCI_segment . s t a r t _ t i m e )

<= 9 THEN ’ 0 ’ + CAST(DATEPART( hh , dbo . uCI_segment . s t a r t _ t i m e ) AS varchar )

ELSE CAST(DATEPART( hh , dbo . uCI_segment . s t a r t _ t i m e ) AS varchar )

END + ’ : ’ + CASE WHEN DATEPART( mi , dbo . uCI_segment . s t a r t _ t i m e ) <= 9

THEN ’ 0 ’ + CAST(DATEPART( mi , dbo . uCI_segment . s t a r t _ t i m e ) AS varchar )

ELSE CAST(DATEPART( mi , dbo . uCI_segment . s t a r t _ t i m e ) AS varchar )

END + ’ : ’ + CASE WHEN DATEPART( ss , dbo . uCI_segment . s t a r t _ t i m e )

<= 9 THEN ’ 0 ’ + CAST(DATEPART( ss , dbo . uCI_segment . s t a r t _ t i m e ) AS varchar )

ELSE CAST(DATEPART( ss , dbo . uCI_segment . s t a r t _ t i m e ) AS varchar )

END AS hora ,

dbo . uCI_segment . s ta r t _ t ime ,

(SELECT shortname

FROM dbo . uCI_campaign

WHERE ( code = dbo . uCI_data_context . campaign ) ) AS nome_campanha ,

(SELECT DISTINCT a . campanha_id

FROM dbo .WFM_campanhas AS a INNER JOIN

dbo . WFM_camp_informix AS b

ON a . id_easy = b . code AND a . campanha_id = b . campanha_id

WHERE ( dbo . uCI_data_context . campaign = a . id_easy ) ) AS campanha_ID_WFM ,

(SELECT c a l l _ c e n t e r

FROM dbo . WFM_call_centers

WHERE ( cod_ca l l_cen te r =

(SELECT WFM_campanhas_2 . sucursa l

FROM dbo .WFM_campanhas AS WFM_campanhas_2 INNER JOIN

dbo . WFM_camp_informix AS b ON WFM_campanhas_2 . campanha_id = b . campanha_id

WHERE ( dbo . uCI_data_context . campaign = WFM_campanhas_2 . id_easy )

AND ( b . code = dbo . uCI_data_context . campaign ) ) ) )

AS c a l l _ c e n t e r

FROM dbo . uCI_data_context INNER JOIN dbo . uCI_thread INNER JOIN

dbo . uCI_segment ON

dbo . uCI_thread . code = dbo . uCI_segment . thread

ON dbo . uCI_data_context . code = dbo . uCI_thread . data_context

WHERE ( dbo . uCI_thread . thread_type = 1) AND ( dbo . uCI_segment . e_user IS NOT NULL)

83

10 Anexo - Vista F_Times_uCI_V2

SELECT

SUM( Tota lCa l lT ime ) AS Tota lCal lT ime , SUM( Tota lTalkTime ) AS TotalTalkTime ,

SUM( TotalHoldTime ) AS TotalHoldTime , SUM( TotalWrapUpTime ) AS TotalWrapUpTime ,

SUM( TotalWaitTime ) AS TotalWaitTime , SUM( TotalWaitTimeOfReceived ) AS TotalWaitTimeOfReceived ,

e_user , campanha_ID_UCI , campanha_ID_WFM , s ta r t_da te ,

Cal lCenter , UPPER( agent_ log in ) AS agent_ log in , TeamLeader , d i f f u s i o n I D , hora ,

UPPER( nome_campanha ) AS nome_campanha , Received ,

(SELECT UPPER( l o g i n ) AS Expr1

FROM dbo . WFM_camp_supervisor AS a

WHERE ( campanha_id = t . campanha_ID_WFM)

AND (CONVERT( varchar ( 8 ) , data_al teracao , 112) =

SELECT CONVERT( varchar ( 8 ) , MAX( da ta_a l te racao ) , 112) AS Expr1

FROM dbo . WFM_camp_supervisor AS c

WHERE ( campanha_id = t . campanha_ID_WFM ) ) ) ) AS SupervisorLogin ,

(SELECT DISTINCT UPPER(nome) AS Expr1

FROM dbo . WFM_clientes AS a

WHERE ( codigo =

(SELECT cod_c l i en te

FROM dbo .WFM_campanhas

WHERE ( campanha_id = t . campanha_ID_WFM ) ) ) ) AS CLientName

FROM

(SELECT CASE WHEN ( s t a t e = 6 OR s ta te = 7 OR s ta te = 8) THEN SUM( du ra t i on )

ELSE 0 END AS Tota lCal lT ime ,

CASE WHEN s ta te = 6 THEN SUM( du ra t i on ) ELSE 0 END AS TotalTalkTime ,

CASE WHEN s ta te = 7 THEN SUM( du ra t i on ) ELSE 0 END AS TotalHoldTime ,

CASE WHEN s ta te = 8 THEN SUM( du ra t i on ) ELSE 0 END AS TotalWrapUpTime ,

CASE WHEN ( s t a t e = 2 OR s ta te = 3 OR s ta te = 5)

THEN SUM( du ra t i on ) ELSE 0 END AS TotalWaitTime ,

CASE WHEN ( ( s t a te = 2 OR s ta te = 3 OR s ta te = 5)

AND t e rm ina t i on_s ta tus = 1) THEN SUM( du ra t i on )

ELSE 0 END AS TotalWaitTimeOfReceived ,

CASE WHEN s ta te = 6 THEN 1 ELSE 0 END AS Received ,

e_user , campanha_ID_UCI , campanha_ID_WFM , s ta r t_da te ,

UPPER( c a l l _ c e n t e r ) AS Cal lCenter , UPPER( usr_name ) AS agent_ log in ,

NULL AS Cl ien t , NULL AS Supervisor , NULL AS TeamLeader , d i f f u s i o n I D ,

hora , nome_campanha , s t a r t _ t i m e

FROM dbo . F_Times_uCI_V1

GROUP BY e_user , s ta r t _ t ime , ca l l _cen te r , campanha_ID_UCI ,

campanha_ID_WFM , s ta r t_da te , s ta te , te rm ina t i on_s ta tus ,

d i f f u s i o n I D , hora , nome_campanha , usr_name ) AS t

GROUP BY e_user , campanha_ID_UCI , campanha_ID_WFM , s ta r t_da te , Cal lCenter ,

UPPER( agent_ log in ) , C l i en t , Supervisor , TeamLeader , d i f f u s i o n I D ,

hora , nome_campanha , Received

85

11 Anexo - Difusão das fontes de dados CCS

Esta difusão devido a especificidades do Microsoft Integration Services 2005 [25] e do próprio ficheiro

CCS teve de ser feita recorrendo a algumas operações adicionais, face ao fluxo normal de execução de

uma difusão. Alguns dos factores que levaram a que se tivessem que fazer estas operações adicionais

foram o facto de:

• existirem vários ficheiros referentes a uma mesma campanha que tinham que se processados

numa mesma difusão;

• existirem dois tipos de ficheiros bastante similares (pilotos e pilotos estatísticos) que diferem ape-

nas num campo (Maximum Number of Simultaneous Calls) que não é usado para cálculos poste-

riores;

• O processamento de ficheiros Excel ter algumas deficiências por parte do Microsoft Integration

Services 2005 [25].

As operações para realizar a difusão destas fontes vão ser descritas em seguida (os passos adicionais

são os que se encontram nos pontos 2 e 4).

1. Primeiramente faz-se o início da difusão, marcando na tabela CTRL_Diffusions a data de início

da difusão e a data da fonte que se está a difundir, procedimento que retorna o ID de difusão que

vai ser usado em todo o procedimento posterior.

2. Como esta fonte de dados tem várias fontes, uma para cada dia de uma campanha, vai ser

necessário processar na difusão todos os ficheiros das campanhas. Para tal inicialmente todos os

ficheiros que ainda não foram difundidos vão ser colocados numa pasta específica: Input. Para

cada um desses ficheiros vai-se proceder às seguintes operações:

(a) Move-se o ficheiro actual que se está a processar para uma pasta de nome: Read.

(b) Devido ao facto do Integration Services quando usa fontes do tipo Excel (como é o caso)

precisar de ter uma ligação a um ficheiro conhecido, ou seja já tem de saber qual a directoria

e nome do ficheiro, e como estes ficheiros podem variar no nome (ex: campanha_data.xls),

recorreu-se a um ficheiro adicional de nome temp.xls numa nova pasta: Temp.

(c) O ficheiro que está a ser lido vai ser copiado para a pasta Temp e substituir o ficheiro lá

existente, temp.xls. Isto garante que quando se for ler o ficheiro no Integration Services, este

vai ter um nome e localização conhecidos (Temp/temp.xls).

(d) Ao processar o ficheiro Excel, devido a este ter uma estrutura um pouco irregular, nomea-

damente no facto de ter dados como o nome da campanha e data separados do local onde

estão os dados referentes às chamadas, o ficheiro vai ser processado em duas iterações.

(e) Primeiramente vai-se processar para um ficheiro temporário de nome pilots_info.txt (que está

colocado na pasta Temp) a informação relativa ao nome do piloto, código e dia que o ficheiro

se refere.

(f) A informação no ficheiro pilots_info.txt vai depois ser colocada numa tabela da base de dados

de nome pilot_info.

(g) Seguidamente vai-se processar os dados relativos às chamadas das campanhas.

87

(h) Vai-se determinar se a campanha se refere a um piloto normal ou estatístico, de forma a

determinar se é preciso retirar o campo adicional da tabela de pilotos normais ou não.

(i) Os dados relativos às chamadas das campanhas, são depois colocados na tabela da base

de dados de nome CT_pilots, juntamente com os dados anteriormente retirados para a tabela

pilot_info juntamente com o ID de difusão calculado no passo 1.

(j) Caso o ficheiro tenha sido bem processado o ficheiro dos pilotos é movido para uma pasta

de nome Processed caso contrário para uma pasta Error.

3. Quando todos os ficheiros tiverem sido processados, a difusão é terminada, colocando na tabela

CTRL_Diffusions a data de fim de difusão e o número de linhas difundidas.

4. Finalmente devido ao ficheiro Excel colocar alguns valores como os tempos num formato de data

(Exemplo: 01-01-1989 14:00:23:00) estes valores são passados para um formato de segundos

(Exemplo: 5789).

Na Figura 11.1 pode-se ver o Fluxo ETL desenvolvido em Microsoft Integration Services 2005 [25] para

lidar com este tipo de ficheiros.

Figura 11.1: Fluxo ETL dos ficheiros CCS.

88

12 DashboardsNeste capítulo são apresentados os Dashboards criados.

Figura 12.1: Protótipo realizado em Microsoft Sharepoint 2005 Services para o Gestor de conta outbound e


89

Figura 12.2: Protótipo realizado em Microsoft Sharepoint 2005 Services para o Coordenador de call center e


Figura 12.3: Protótipo realizado em Microsoft Sharepoint 2005 Services para o supervisor outbound e


90

13 Anexo - Modelos DimensionaisNeste capítulo serão apresentadas as estrelas que compõem o modelo dimensional criado.


F_Agentes

91


F_Calls_Inbound_CCS


F_Calls_Inbound_uCI

92


F_Calls_Outbound

93


F_Campaigns

94


F_Finances


F_KPIS

95


F_Times_CCS


F_Times_uCI

96

tese 3,2 mb

Documents