FACULDADE DE
ENGENHARIA DA
UNIVERSIDADE DO
PORTO
IPBrick - Contact Center para gestão
de suporte a clientes
Carlos José Pereira da Rocha
Mestrado Integrado em Engenharia Electrotécnica e Computadores
Orientador: Prof. André Restivo
Proponente: Eng. Telma Salgueiro - IPBrick SA
Resumo
A presente dissertação foi realizada em ambiente empresarial na IPBRICK SA e visa a integração da aplicação IPTicket no Contact Center da IPBrick.
Nos dias de hoje, nomeadamente a nível empresarial, verificamos que a eficiência e a qualidade dos serviços prestados representam os aspetos mais importantes para o sucesso das empresas. Na IPBrick, de modo a melhorar o serviço prestado aos clientes, principalmente em relação ao tempo despendido na assistência, foi proposto integrar as funcionalidades do IPTicket no Contact Center. Neste sentido, esta dissertação foi dividida em duas partes. Na primeira parte, debruçar-nos-emos sobre a revisão efetuada ao IPTicket e sobre os melhoramentos que daí decorreram. Em segundo lugar, iremos abordar os desenvolvimentos efetuados no Contact Center de modo a que esta aplicação consiga suportar a integração do IPTicket.
Como resultado, o Contact Center possui, agora, a integração do IPTicket com os melhoramentos efetuados. Esta dissertação terá como finalidade abordar o modo como a integração destas duas aplicações permitirá que a assistência aos clientes seja mais eficiente. Por outro lado, mostrará, também, que se abriu uma nova janela de oportunidades, a partir da qual mais melhoramentos serão possíveis desenvolver com a integração destas aplicações.
Abstract
This dissertation was carried out in a business environment in IPBRICK SA and aims at integrating the IPTicket application in IPBrick’s Contact Center.
Nowadays, especially at the enterprise level, we can see that the efficiency and quality of services are one of the most important points to the success of a business. IPBrick, in order to improve service to the customers, especially at the time spent in assists to resolve problemas, has proposed the integration the features of these two applications.
In this sense this thesis was divided into two parts: in the first one, is made a review of the IPTicket application and are made some necessary improvements before their integration. Secondly, there are made developments in the Contact Center to be able to support the integration of IPTicket. As a result the Contact Center now has the IPTicket integration with the improvements that were made in IPTicket. The great achievement of this work was to begin integration of these two applications, which will allow more efficient customers assists. On the other hand, also it opens a new window of opportunity, to improve and make more improvements in the integration of this two applications.
Agradecimentos
Este espaço é dedicado a todas as pessoas que de uma maneira ou de outra contribuíram para o sucesso do meu percurso académico.
Em primeiro lugar, agradeço a Deus pelo dom da vida.
Aos meus pais, porque me proporcionaram, ao longo da vida todas as condições para o meu sucesso, apoiando-me incondicionalmente.
Aos meus irmãos, pela paciência e apoio ao longo destes anos. Aos meus quatro avós, um enorme obrigado!
A toda a minha restante família, a cada um de vocês, obrigado pelo enorme incentivo que me deram ao longo deste percurso.
Aos meus amigos que de uma maneira ou de outra sempre estiveram lá.
Aos meus amigos mais íntimos que são parte integrante da minha vida e caminhada e com quem partilhei dos melhores momentos da minha vida. Eles sabem quem são.
Ao Luís,um obrigado especial, pelo exemplo, e por há mais de dez anos, me chamar à razão e não me deixar desleixar.
À Marta, a minha companheira de vida e caminhada, um obrigado do tamanho do mundo, por tudo, por estar sempre presente, fazer parte do meu sucesso e por me amar de uma forma tão genuína.
Ao Prof. Doutor André Restivo por todo o apoio que me deu para o sucesso desta dissertação. À IPBrick SA, a todos os seus colaboradores, principalmente, à Eng. Telma Salgueiro, ao Eng. Ivo Ferreira e ao Eng. Leandro Sousa pela ajuda no desenvolvimento deste trabalho.
A todos e a cada uma das pessoas que me ajudaram ao longo deste percurso, obrigado do fundo do coração.
Carlos José Pereira da Rocha
"Deus não falha!"
Luís Sousa
Conteúdo
1 Introdução 1 1.1 Enquadramento . . . 1 1.2 Objetivos . . . 1 1.3 Motivação . . . 2 1.4 Leitura da Dissertação . . . 2 1.5 Resultados . . . 3 1.6 Conclusão . . . 4 2 Estado de Arte 5 2.1 Bases Teóricas . . . 52.1.1 Gestão de Problemas Fabricante/Cliente . . . 5
2.1.2 Contact Center/Centro de Contactos - Conceito Teórico . . . 6
2.1.3 Trouble Ticket e HelpDesk . . . 6
2.1.4 Workflow . . . 6 2.1.5 Gestão Documental . . . 7 2.2 Tecnologias . . . 9 2.2.1 HTML . . . 9 2.2.2 PHP . . . 9 2.2.3 JavaScript . . . 11 2.2.4 XML . . . 11 2.2.5 AJAX . . . 12 ix
2.2.6 Bases de Dados . . . 12 2.2.7 Webservices . . . 14 2.2.8 Yii Framework . . . 15 2.3 Software . . . 16 2.3.1 IPBrick . . . 16 2.3.2 iPortalDoc . . . 18 2.3.3 IPTicket . . . 19 2.3.4 Contact Center . . . 20 2.4 Conclusão . . . 20 3 Problemas e Requisitos 21 3.1 Levantamento de Requisitos . . . 21 3.1.1 IPTicket . . . 21 3.1.2 Contact Center . . . 22 3.2 Casos de Uso . . . 23 3.3 Conclusão . . . 24
4 Arquitetura dos Sistemas e Solução 27 4.1 IPTicket . . . 27 4.1.1 Arquitetura do Sistema . . . 27 4.1.2 Base de Dados . . . 28 4.1.3 Arquitetura da Aplicação . . . 28 4.1.4 Solução . . . 31 4.2 Contact Center . . . 33 4.2.1 Arquitetura do Sistema . . . 34 4.2.2 Base de Dados . . . 34 4.2.3 Arquitetura da Aplicação . . . 35 4.2.4 Solução . . . 36
CONTEÚDO xi
4.3 Conclusão . . . 40
5 Implementação 41 5.1 Plataforma e Ferramentas de Apoio ao Desenvolvimento . . . 41
5.1.1 Plataforma . . . 41
5.1.2 Ferramentas . . . 42
5.2 IPTicket . . . 42
5.2.1 Configuração dos Graus de Satisfação . . . 42
5.2.2 Atribuição dos Graus de Configuração . . . 49
5.2.3 Apresentação e Exportação dos Graus de Configuração na Tabela Indica-dores . . . 51
5.3 Contact Center . . . 52
5.3.1 Configurações . . . 52
5.3.2 Webservices . . . 54
5.3.3 Hierarquia de Pastas e Ficheiros . . . 54
5.3.4 Pedidos de Apoio a Tratar . . . 55
5.3.5 Execução dos Pedidos de Apoio a Tratar . . . 57
5.4 Conclusão . . . 60 6 Validação 73 6.1 IPTicket . . . 73 6.2 Contact Center . . . 74 6.3 Conclusão . . . 75 7 Conclusão 83 7.1 Sumário, Resposta ao Problema e Implicações . . . 83
7.2 Limites e Trabalho Futuro . . . 84
Lista de Figuras
2.1 Exemplo de um workflow [1] . . . 7
2.2 Exemplo de código HTML [2] . . . 9
2.3 Exemplo de código PHP [3] . . . 10
2.4 Exemplo de código Javascript integrado em HTML [4] . . . 11
2.5 Exemplo de código XML [5] . . . 12
2.6 Comunicação síncrona vs assíncrona [6] . . . 13
2.7 AJAX Engine [6] . . . 14
2.8 Exemplo de uma tabela de base de dados . . . 15
2.9 Exemplo de funcionamento de um webservice [7] . . . 15
2.10 Arquitetura iPortalDoc [8] . . . 19
3.1 Bloco onde mostra as notificações que chegam do IPortalDoc . . . 24
3.2 Exemplo de campos e botões disponíveis numa ação do IPTicket . . . 25
3.3 Diagrama de caso de uso IPTicket . . . 25
3.4 Diagrama de caso de uso Contact Center . . . 26
4.1 Arquitetura do Sistema para o IPTicket . . . 28
4.2 Arquitetura da aplicação IPTicket . . . 29
4.3 Exemplo workflow IPTicket . . . 30
4.4 Esquema explicativo do papel que o utilizador tem na configuração dos graus de satisfação . . . 31
4.5 Processo associado à atribuição dos graus de satisfação . . . 32
4.6 Arquitetura das tabela de problemas . . . 33
4.7 Arquitetura da tabela graus de satisfação . . . 33
4.8 Arquitetura do Sistema para o Contact Center . . . 34
4.9 Arquitetura da aplicação Contact Center . . . 35
4.10 Comunicações efetuadas para o CC . . . 36
4.11 Acção pendente do iPortalDoc . . . 37
4.12 Notificação no Contact Center . . . 38
4.13 Interface de controlo worlflow do iPortalDoc no Contact Center . . . 39
4.14 Exemplo de quando chega um pedido a tratar ao Contact Center via iPortalDoc . 40 4.15 Arquitetura da tabela configurações do Contact Center . . . 40
5.1 Menus IPTicket . . . 43
5.2 Nova opção no "Menu Configurações" . . . 44
5.3 Tabela dos Graus de Satisfação vazia . . . 45
5.4 Estrutura tabela satisfaction_table . . . 46
5.5 Tabela satisfaction_table com um grau de satisfação configurado . . . 47
5.6 Janela para a inserção dos graus de satisfação . . . 48
5.7 Janela para a edição dos graus de satisfação . . . 48
5.8 Esquema demonstrativo do caminho entre as várias funções usadas na configura-ção dos graus de satisfaconfigura-ção . . . 62
5.9 Ligação entre a tabela satisfaction_table e a tabela problema . . . 63
5.10 Lista com os graus de satisfação ativos para classificar o problema . . . 63
5.11 Tabela "Indicadores" . . . 64
5.12 Estrutura da tabela configurações . . . 64
5.13 Dados da tabela configurações do Contact Center . . . 65
5.14 Novos campos para a configuração do IPTicket . . . 65
5.15 Hierarquia das diretorias associadas ao Contact Center . . . 66
LISTA DE FIGURAS xv
5.17 Hierarquia ficheiros e funções do bloco "pedidos de apoio a tratar" . . . 67
5.18 Layout final para o bloco dos "pedidos de apoio a tratar" . . . 67
5.19 Hierarquia ficheiros e funções do bloco de controlo e execução dos "pedidos de apoio a tratar" . . . 68
5.20 Exemplo interface controlo do estado "Classificar" . . . 69
5.21 Exemplo interface controlo do estado "Concluir" . . . 70
5.22 Exemplo de e-mail na interface de controlo na aba "E-mail" . . . 70
5.23 Arquitetura do sistema do Contact Center atualizada" . . . 71
6.1 IPTicket01: Interface Inserir Grau de Satisfação . . . 76
6.2 IPTicket02: Interface Editar Grau de Satisfação . . . 77
6.3 IPTicket03: Interface Classificar Problema . . . 78
6.4 IPTicket04: Interface Tabela "Indicadores" . . . 79
6.5 Contact_Center01: Interface Configurar IPTicket no Contact Center . . . 80
6.6 Contact_Center02: Interface "Pedidos de Apoio a Tratar" . . . 80
6.7 Contact_Center03: Interface de controlo do IPTicket no Contact Center . . . 81
Lista de Tabelas
3.1 Tabela requisitos IPTicket . . . 22
3.2 Tabela requisitos Contact Center . . . 23
Abreviaturas e Símbolos
PHP PHP: Hypertext Preprocessor AJAX Asynchronous Javascript and XML
XSLT eXtensible Stylesheet Language for Transformation XML Extensible Markup Language
W3C World Wide Web Consortium HTML HyperText Markup Language SQL Structured Query Language DML Data Manipulation Language DDL Data Definition Language DCL Data Control Language DTL Data Transaction Language DQL Data Query Language
AMA Agência para a Modernização Administrativa SOAP Simple Object Access Protocol
HTTP Hypertext Transfer Protocol CC Contact Center
Capítulo 1
Introdução
1.1
Enquadramento
Este documento realiza-se no âmbito da Dissertação de Mestrado do 5º ano do MIEEC e tem como título “IPBRick – Contact Center para gestão de suporte a clientes”. Realizou-se em ambiente empresarial, na empresa IPBrick SA, situada na rua de Passos Manuel, no Porto. Trata-se de uma startupfundada no ano 2000 pelo Prof. Dr. Raul Oliveira. Mais concretamente, é uma empresa que desenvolve e distribui Soluções de Comunicação Corporativas.
Nesta dissertação, trabalhei diretamente com o Contact Center da IPBrick, que é uma plataforma central onde todos os contactos com os clientes podem ser geridos. Este software está assente no sistema operativo IPBrick. Tal como o Contact Center, as aplicações iPortalDoc (software de ges-tão documental e workflow que permite fazer uma gesges-tão do fluxo de documentos ou proceder ao seu arquivo para futura gestão) e IPTicket (aplicação de administração e resolução de problemas) também estão assentes no mesmo software. Estas aplicações são maioritariamente desenvolvidas em PHP, com recurso à utilização de bases de dados PostgreSQL e do sistema operativo Linux.
1.2
Objetivos
A IPBrick, nomeadamente, o departamento de suporte a clientes, trabalha com várias aplicações em simultâneo. Este processo de alternância entre várias aplicações leva a perdas de tempo e à diminuição da eficiência na resolução dos problemas dos clientes. Neste sentido, para esta disser-tação foi proposto integrar funcionalidades do IPTicket no Contact Center (que já tem integração com o iPortalDoc) de modo a diminuir o tempo despendido no apoio aos clientes.
Numa primeira fase, será necessário colocar as várias aplicações a fazer trocas de informação 1
entre si, sendo essa a base para a dissertação. Numa segunda fase, após a recolha da informação da forma desejada, a partir das várias aplicações, projetar-se-á uma interface que integre as novas funcionalidades. Esta interface, a desenvolver para o Contact Center, deve ser desenvolvida de modo a que o utilizador possa usufruir das funcionalidades do IPTicket e iPortalDoc num único local.
1.3
Motivação
Hoje em dia, é cada vez mais importante não perder tempo, ou seja, urge obter soluções de modo a tornar os processos mais eficientes e rápidos. Para a IPBrick, uma maneira de melhorar a efi-ciência de processos passas por integrar funcionalidades de aplicações distintas. Os utilizadores do iPortalDoc já possuem integração desta aplicação com o Contact Center, mas os do IPTicket não. Neste sentido, para a empresa, é necessário otimizar este cenário. Esta dissertação terá, então, como objetivo apresentar uma solução para melhorar este processo, a partir da integração do IPTic-ketno Contact Center, o que, por sua vez, levará à possibilidade do controlo das funcionalidades de todas as aplicações envolvidas numa só interface.
1.4
Leitura da Dissertação
Esta dissertação divide-se em sete capítulos.
No Capítulo1, é feita uma introdução à dissertação onde se aborda o enquadramento da mesma. São apresentados os objetivos e a motivação que estiveram na sua base. Também é apresentado um guia de modo a orientar o leitor na interpretação do documento. Por fim, são apresentados os resultados atingidos com trabalho realizado.
No Capítulo2, são abordados todos os conceitos necessários à compreensão do conteúdo da dis-sertação. Em primeiro lugar, são abordadas todas as bases teóricas, sendo que, de seguida, são introduzidas as tecnologias necessárias para o desenvolvimento da mesma. Por fim, são apresen-tados todos os softwares associados a este trabalho.
No Capítulo3, são apresentados os requisitos propostos para o melhoramento do IPTicket e do Contact Center. São ainda apresentados os Casos de Uso para cada uma destas duas aplicações. No Capítulo 4, é dada a explicação da arquitetura dos sistemas em que o IPTicket e o Contact Center estão inseridos. Do mesmo modo, também é explicada a arquitetura e funcionamento destas duas aplicações. Por fim, mediante os requisitos apresentados no capítulo 3, é proposta uma solução de modo a que todos os requisitos sejam cumpridos.
1.5 Resultados 3
No Capítulo5, são apresentados todos os desenvolvimentos efetuados ao longo da dissertação. Primeiramente, são explicadas as alterações efetuadas no IPTicket e, seguidamente as alterações efetuadas no Contact Center. Também é feita uma introdução sobre a plataforma e ferramentas que suportaram o trabalho desenvolvido na empresa.
No Capítulo6, é explicado o modo como os requisitos apresentados no Capítulo3foram cumpri-dos no Capítulo5. Através das interfaces desenvolvidas ao longo da dissertação é demonstrado como cada uma delas suprime um ou mais requisitos.
No Capítulo7, é apresentado um breve sumário, a resposta à problemática proposta, as implicações que teve, os seus limites e o trabalho futuro desta dissertação.
1.5
Resultados
Nesta dissertação foram obtidos resultados como consequência do trabalho desenvolvido em duas aplicações da IPBrick: o IPTicket e o Contact Center.
No IPTicket, os desenvolvimentos efetuados resultaram nas seguintes funcionalidades:
1. Permitir ao utilizador configurar graus de satisfação de modo a que o cliente consiga classi-ficar a resolução de um determinado problema.
2. Disponibilizar no IPTicket uma forma de avaliar a resolução de problemas com graus de satisfação definidos e configurados previamente.
3. Disponibilizar a avaliação da resolução do problema (o grau de satisfação) no módulo de estatística.
4. Exportar as informações obtidas para um ficheiro Excel, caso seja necessário tê-las disponí-veis.
No Contact Center, os desenvolvimentos efetuados resultaram nas seguintes funcionalidades:
1. Permitir configurar o Contact Center de modo a integrá-lo com o IPTicket.
2. Ser possível disponibilizar os problemas pendentes a serem resolvidos no IPTicket de modo a possibilitar ao utilizador, na interface do Contact Center, a visualização dos problemas que estão pendentes sem ter de aceder ao IPTicket.
3. Conseguir controlar a resolução dos problemas do IPTicket fazendo avançar os workflows associados a cada problema na interface do Contact Center.
1.6
Conclusão
Neste capítulo, como podemos verificar, foi feita a introdução à dissertação. Abordou-se o en-quadramento, os objetivos e a motivação que estiveram na sua base. Por fim, apresentou-se um guia de leitura da dissertação e os resultados da mesma. No próximo capítulo, irá ser feita uma exposição das bases teóricas associadas a esta dissertação, bem como as tecnologias e softwares envolvidos.
Capítulo 2
Estado de Arte
No Capítulo1foi feita uma introdução à dissertação. Neste segundo capítulo tem como objetivo apresentar os conceitos teóricos, tecnologias e softwares relacionados com esta dissertação.
2.1
Bases Teóricas
2.1.1 Gestão de Problemas Fabricante/Cliente
Nos dias que correm, deixou de haver necessidade das pessoas se dirigirem, de imediato, ao local onde adquiriram determinado produto, sempre que o mesmo lhes suscita algum problema. Ao longo do tempo, foram sendo disponibilizados ao público meios para que a gestão destes casos fosse feita à distância, de modo a permitir ao cliente maior comodidade neste processo. De uma forma natural, foram sendo desenvolvidas ferramentas de administração deste tipo de sistemas, desde a criação das primeiras linhas de apoio ao cliente até ao aparecimento de plataformas mais complexas que permitem monitorizar problemas à distância.
Hoje em dia, além das ferramentas mais comuns e primárias baseadas apenas em ligações telefó-nicas, existem softwares que nem sempre estão visíveis aos clientes, mas que ajudam no processo de resolução de problemas.
2.1.2 Contact Center/Centro de Contactos - Conceito Teórico
O Contact Center é uma plataforma central a partir da qual todos os contactos com os clientes são geridos. Geralmente, este tipo de plataformas é usada em departamentos de suporte a clientes. A gestão de contactos num Contact Center é feitos maioritariamente através da linha telefónica ou da internet e é comum que estas duas formas de comunicação estejam articuladas.
Após o contacto do cliente para reportar determinado problema, é feita uma análise do mesmo (durante ou pós o atendimento) para se perceber qual será a melhor maneira de o resolver. Logo de seguida, os problemas são encaminhados para pessoas/departamentos adequados, de modo a serem solucionados.
2.1.3 Trouble Ticket e HelpDesk
Trouble Ticket(Sistema de Gestão de Problemas) é um mecanismo usado em empresas para detetar e monitorizar um problema. A maior parte destes mecanismos tem como base a internet, ou seja, utilizam-na como meio de comunicação. Este sistema é usado em contact centers e negócios baseados na venda online dos seus produtos. [9]
O HelpDesk (Balcão de Ajuda) é um termo que designa o serviço de apoio a clientes para a resolução de problemas. Este apoio pode ser realizado pessoalmente ou na empresas em contacto direto com o cliente ou, então, por meio de um serviço de contact center.
2.1.4 Workflow
Sistema de workflow [8] (Figura2.1), em português sistema de fluxo de trabalho, pode ser interpre-tado como um sistema de circulação de informação. Por outras palavras, pode definir-se workflow como um sistema, onde cada estado tem uma atividade/função associada. Se essa atividade é efe-tuada com sucesso, então, ocorre uma transição para o estado seguinte. Este modelo de gestão de processos é muito comum e proveitoso para a automatização de processos em grande escala. Todos os workflows são constituídos por:
Caminhos Caminhos entre dois ou mais estados do workflow. Podem ser lineares, paralelos ou circulares.
Regras O que é preciso acontecer para mudar de estado.
2.1 Bases Teóricas 7
Figura 2.1: Exemplo de um workflow [1]
Tarefas Ações que são conduzidas pelo workflow e que podem ser executadas pelos utilizadores ou programas/softwares definidos no caminho do workflow.
2.1.5 Gestão Documental
A Gestão de Documentos [10] [11] é essencial para o bom desempenho de uma empresa. Hoje em dia, é muito comum nas organizações empresariais haver grande volume de documentos, o que pode levar à perda de informação importante e relevante e à dificuldade de armazenar toda essa informação de forma física.
Neste sentido, foram surgindo sistemas de gestão documental que permitem que a informação seja organizada e armazenada de forma virtual, de modo a permitir uma melhor organização da mesma
sem se perderem documentos relevantes e elevando o nível de segurança. A gestão documental tem por base os seguintes conceitos:
Desmaterialização Digitalização dos documentos em formato papel, produzindo documentos eletrónicos que são classificados e disponibilizados segundo um determinado critério. Normalização de todos os tipos de documentos da empresa, métodos de classificação e de
enti-dades. Uniformização de processos utilizando sempre os mesmos procedimentos.
Indexação Catalogação e classificação dos documentos eletrónicos. Esta fase é equivalente ao processo de arquivo físico mas potenciando os benefícios dos sistemas de informação, po-dendo garantir a gestão integrada do arquivo físico e eletrónico.
Workflow Definição dos vários estados pelos quais um documento passa, incluindo publicação, aprovação, distribuição e circulação ou arquivo, possibilitando o controlo dos fluxos de circulação de documentos.
Pesquisa Motor de busca capaz de realizar pesquisas de documentos pelo seu conteúdo ou atri-butos, permitindo localizar e disponibilizar imediatamente os mesmos, quando necessário e em qualquer parte.
Redução de Custo A redução de custo advém do aumento de produtividade na procura, reenca-minhamento e gestão de documentos, redução do custo de cópias e redução das necessidades de espaço de arquivo.
Na supressão dos problemas da gestão física de documentos vão surgir as seguintes vantagens:
• Desmaterialização da documentação e dos processos de tramitação associados; • Automatização e uniformização dos processos de trabalho;
• Gestão do arquivo da empresa de uma forma centralizada;
• Normalização dos documentos, critérios de arquivo e procedimentos; • Rapidez na disponibilização, acesso e tratamento dos documentos;
• Controlo e segurança da informação e dos fluxos de informação (documentos e processos); • Ganhos de eficiência administrativa e processual com consequentemente redução de custos
operacionais;
• Redução da necessidade de espaço físico para arquivo e do custo com fotocópias e impres-sões;
2.2 Tecnologias 9
2.2
Tecnologias
2.2.1 HTML
O HTML [12] é uma linguagem de programação utilizada para a criação de páginas web que pode ser lida por qualquer browser.
Para escrever documentos HTML é apenas necessário um simples editor de texto e o documento deve ser gravado com a extensão .html.
Os documentos HTML possuem tags, palavras entre parênteses angulares (< e >). Estas palavras são comandos de formatação de linguagem que vão alterar o resultado do que está associado a essa mesma tag.
Aplicando corretamente as tags, ao abrir o documento num determinado browser, este possibilita a identificação das mesmas e apresenta a página de acordo com a estrutura definida no documento HTML.
A Figura2.2mostra um exemplo de código desta mesma linguagem.
Figura 2.2: Exemplo de código HTML [2]
2.2.2 PHP
O PHP [13][14][15][16][17] é uma linguagem de programação (Figura2.3) desenvolvida, prin-cipalmente, para desenvolvimento de plataformas web, sendo facilmente integrável com HTML. Trata-se de uma linguagem extremamente modularizada o que a torna ideal para a instalação e uso
em servidores web. A nível de sintaxe, ela tem muitas semelhanças com C e C++. Esta linguagem pode ser utilizada em inúmeros sistemas operativos, como por exemplo, Linux e Windows.
Figura 2.3: Exemplo de código PHP [3]
Resumindo, o PHP tem como principais caraterísticas:
Velocidade e robustez Evita a lentidão dos servidores e, devido à sua estrutura de programação com tags, é ideal para grandes aplicações.
Orientação a objetos Linguagem de alto nível que permite um elevado grau de abstração, encap-sulamento e segurança; é recursiva e facilmente adaptável a diferentes situações.
Portabilidade É independente da plataforma onde é escrita. Ao ser escrita uma vez, é interpretada em qualquer plataforma, sem quaisquer constrangimentos.
Tipagem dinâmica Não exige declaração do tipo de dados, pois utilizam dinamicamente cada variável, podendo ser alterada ao longo do código.
Sintaxe simples Sintaxe similar a C, C++ e Perl.
OpenSource Não exige qualquer contrapartida monetária no acesso a software para programar em PHP.
2.2 Tecnologias 11
2.2.3 JavaScript
O Javascript [18] é uma linguagem de programação (Figura2.4) que foi concebida para ser exe-cutada nos browsers de forma a que os scripts possam ser executados do lado do cliente, ou seja, criar uma interação com a página web sem que o utilizador tenha a necessidade de fazer refresh à página para obter atualizações. É uma linguagem script orientada a objetos e possui capacidades de uma funcional [19]. Pode ser implementada por exemplo, em documentos html, e o seu código tem de estar entre as tags <script></script>. Neste sentido, pode funcionar como um complemento a outras linguagens tornando as páginas web mais completas e dinâmicas.
Figura 2.4: Exemplo de código Javascript integrado em HTML [4]
2.2.4 XML
O XML [20] é uma markup language (linguagem de marcação), (Figura2.5), definida pela W3C. Define um conjunto de regras para documentos de codificação num formato que é legível tanto pelo homem como pela máquina. É uma linguagem simples e muito flexível. É semelhante ao HTML. No XML há a liberdade de definir as tags de modo a descrever o conteúdo do documento da maneira que for mais conveniente ao utilizador.
2.2.4.1 XSLT
O XSL Transformations, ou XSLT [21], é uma linguagem de marcação XML usada para criar documentos XSL que, por sua vez, definem a apresentação dos documentos XML nos browsers e outros aplicativos que a suportam. É uma linguagem de transformação de documentos XML noutros documentos XML.
Figura 2.5: Exemplo de código XML [5]
2.2.5 AJAX
AJAX[22] é o uso metodológico de tecnologias, tais como, Javascript e XML/JSON, e tem como objetivo tornar páginas web mais interativas. Tal como o nome indica, Asynchronous Javascript and XML, AJAX reage a solicitações assíncronas por eventos.
O uso de AJAX faz com que seja criada uma camada que permite que, em determinadas situações, mesmo que seja necessário comunicar com o servidor, não seja necessário voltar a carregar a página.
As Figuras2.6e2.7mostram a diferença entre o modo de funcionamento de uma aplicação web clássica e outra baseada em AJAX.
2.2.6 Bases de Dados
Uma base de dados (Figura2.8) é uma ferramenta concebida para a recolha e organização de infor-mações que podem estar, ou não, relacionadas entre si. As bases de dados armazenam inforinfor-mações sobre pessoas, produtos, encomendas, etc.
Existem vários Modelos de Base de Dados: Modelo Plano, Modelo em Rede, Modelo Hierárquico, Modelo Relacional.
Para esta dissertação, utilizaram-se bases de dados relacionais. Este tipo de base de dados modela os dados de forma a que sejam percecionados pelos utilizadores como tabelas.
As colunas de uma tabela são também chamadas de atributos (por exemplo: nome, idade, sexo). Todas as bases de dados relacionais armazenam os dados em tabelas. Estas tabelas associam-se
2.2 Tecnologias 13
Figura 2.6: Comunicação síncrona vs assíncrona [6]
entre si através de regras de relacionamento. Por exemplo: uma tabela onde constem os clientes de uma loja pode ter as seguintes colunas: id (identificação interna), nome, idade. O id pode estar associado a outra tabela que mostra as encomendas do cliente.
Os identificadores que relacionam as tabelas entre si chamam-se chaves estrangeiras (foreing key). Também existem chaves primárias (primary key), um identificador exclusivo de todas as infor-mações de cada registo, dando-lhe unicidade. As chaves primárias nunca se repetem na mesma tabela.
As bases de dados, devido à sua dimensão, necessitam de uma linguagem que permita que se chegue com facilidade à informação desejada. A linguagem padrão das bases de dados relacionais é Structured Query Language (SQL).
2.2.6.1 SQL
O SQL [23] é uma linguagem de consulta estruturada em bases de dados inspirada na álgebra relacional. Esta linguagem utiliza determinados comandos e, através deles, consegue-se aceder à informação desejada.
Figura 2.7: AJAX Engine [6]
A linguagem SQL é dividida em subconjuntos de acordo com as operações que queremos efetuar sobre uma base de dados.
DML Linguagem de Manipulação de Dados - é um subconjunto da linguagem SQL que é utili-zado para realizar inclusões, consultas, alterações e exclusões de dados presentes em regis-tos. Estas tarefas podem ser executadas em vários registos de diversas tabelas ao mesmo tempo.
DDL Linguagem de Definição de Dados - define o conjunto de comandos que permitem criar e apagar tabelas.
DCL Linguagem de Controlo de Dados - o DCL controla os aspetos relativos às autorizações de dados e licenças de utilizadores. Tem como objetivo controlar o acesso à base de dados para a manipulação dos mesmos.
2.2.7 Webservices
Um webservice [24] é um serviço utilizado para a integração de aplicações diferentes. É des-crito num formato que possa ser processado por uma máquina (normalmente WSDL). A extensão .WSDL permite às aplicações enviar e receber mensagens em formato XML, onde cada aplicação tem a sua própria "linguagem".
2.2 Tecnologias 15
Figura 2.8: Exemplo de uma tabela de base de dados
Os webservices apresentam uma interface orientada a objetos, baseada na web, para uma base de dados, utilizada, por exemplo, por outro servidor Web. As bases utilizadas para criar um webser-vicesão o XML e o SOAP, onde o transporte de dados é usualmente realizado por HTTP, onde os dados são transmitidos em formato XML, encapsulados em protocolo SOAP.
A Figura 2.9 mostra o funcionamento de um sistema baseado em webservices. É recolhida a informação relativa à meteorologia e, através de um webservice, é disponibilizada para várias aplicações (sites, telemóveis, aplicações móveis).
Figura 2.9: Exemplo de funcionamento de um webservice [7]
2.2.8 Yii Framework
A Yii [25][26] é uma framework de alta performance baseada em PHP que utiliza componentes para o desenvolvimento de grandes aplicações web. Permite a reutilização de códigos de progra-mação, fazendo com que se acelere o processo de desenvolvimento das aplicações.
O Yii possui suporte para uso de outras tecnologias como HTML5, CSS3, Bootstrap e jQuery. Também suporta bases de dados PostgreSQL, MySQL, SQLite, Microsoft SQL Server e Oracle. Esta framework usa um ORM (Object Relational Mapping). A classe CActiveRecord é a classe principal que representa todos os dados relacionais e não relacionais da base de dados. Neste sentido, ela possui atributos e métodos que realizam consultas à base de dados. Desta forma, o código-fonte possui uma semântica e legibilidade mais simples, uma vez que, chamando métodos que realizam consultas SQL, o seu código torna-se mais legível, ao contrário do que aconteceria inserindo inúmeras querys SQL no mesmo.
2.3
Software
2.3.1 IPBrick
O IPBrick OS é um sistema operativo distribuído pela IPBrick SA. É uma plataforma para sistemas de servidores corporativos e é baseado em Debian Linux.
O software IPBrick OS está projetado para que três tipos de servidores sejam geridos pelo mesmo administrador. Eles são:
• Servidor de Intranet;
• Servidor de Comunicações Unificadas;
• Servidor de Segurança.
Estes servidores estão projetados para que qualquer pessoa possa fazer a configuração dos mesmos sem precisar de ajuda de pessoal especializado. Por sua vez, o IPBrick OS providencia um grande nível de integração entre pacotes de software Open Source, sendo que também é possível a sua integração com software de terceiros [27]. É simples e funcional devido à sua interface gráfica (Graphical User Interface (GUI)).
Todos as aplicações distribuídas pela IPBRick SA estão assentes no IPBrick OS. É de importante relevância perceber que, quando se fala em utilizar o sistema operativo da IPBrick, na sua base está sempre um servidor da mesma, onde estão alocadas todas as aplicações da IPBrick que um determinado cliente possui.
2.3 Software 17
2.3.1.1 IPBrick.I - Servidor de Intranet [28]
Uma intranet consiste na aplicação das tecnologias da internet às redes internas das empresas. A IPBrick.Idisponibiliza aos seus utilizadores as seguintes funcionalidades:
Correio Eletrónico e Ferramentas Colaborativas É um servidor de Correio Eletrónico e dispo-nibiliza Ferramentas Colaborativas – Agenda, Contactos e Calendário.
Controlador de Domínio Trabalha com protocolo LDAP e integra com o Active Directory, her-dando todas as configurações de contas já criadas. A passagem da tecnologia Microsoft para a tecnologia IPBrick é transparente para o utilizador.
Funcionalidades de Intranet Providencia várias funcionalidades, tais como, servidor de fichei-ros e de áreas de trabalho individuais e de grupo, servidor de terminais, impressoras e bases de dados, serviço de backup das áreas de trabalho, suporte de aplicações de negócios.
2.3.1.2 IPBrick.C - Servidor de Comunicações [29]
Por sua vez, o servidor de comunicações vai garantir as seguintes funcionalidades:
Correio eletrónico Mail Relay e webmail.
Comunicações Fax para e-mail, e-mail para fax e e-mail para SMS. Serviços de Telefonia Gateway VoIP, PBX IP e SIP Proxy.
Serviços web Servidor web, Webphone, proxy e cache HTTP/FTP.
Sistema de Mensagens Instantâneas Webchat e servidor de Instant Messaging.
Segurança de Comunicações Firewall, VPN Server, IDS (Intrusion Detection System), antivírus pré-instalado para correio eletrónico e proxy e também anti-spam pré-instalado.
2.3.1.3 IPBrick.GT [30][31]
É responsável pelos serviços de voz, fax, vídeo, email, web, SMS e Instant Messaging. Possui mecanismos para gravação de comunicações feitas por chamada, fax, Instant Messaging e e-mail. Também oferece serviços, sendo alguns deles a gestão de filas de espera (chamadas), parquea-mento e transferências de chamadas, escalonaparquea-mento e conferências de chamadas.
2.3.1.4 Outras plataformas IPBRick
A IPBrick possui ainda outras plataformas:
IPBrick.4CC Uma plataforma que permite criar, instalar e recuperar ambientes de suporte ao Cloud Computing[32].
IPBrick.H Um software para hotspots que permite gerir o acesso à Internet. Através da IPBrick.H é possível cada empresa configurar o seu hotspot conforme as suas necessidades, aplicando as tarifas que desejar, personalizar a página de acesso à Internet, fazer controlo das páginas que são consultadas, entre outras funcionalidades [33][31].
IPBrick.SCHOOL Uma tecnologia para a aprendizagem de TI (tecnologias de informação). For-nece um desktop multi-sessão e está pensada para o ambiente escolar do futuro [34]. IPBrick.LIVE Uma solução de Corporate TV, pensada para que cada empresa possa ter o seu
canal de televisão. Pode mostrar conteúdo multimédia em ecrãs e online e, simultaneamente, passa informação produzida pelo iMeter (monitorização de eletricidade) e suporta sistemas de bilhética [35].
IPBrick.SOHO Uma solução que fornece num único equipamento as funcionalidades de Intra-net, segurança e comunicações, mas para pequenos escritórios [36].
IPBrick.VDI Uma infraestrutura de desktop virtual. Está assente em tecnologia IPBRick.4CC e permite uma gestão de uma estrutura de máquinas virtuais que suportam todo o sistema implementado num único servidor [37].
2.3.2 iPortalDoc
O iPortalDoc é um sistema de gestão documental e workflow que permite fazer uma gestão do fluxo de documentos ou proceder ao seu arquivo para futura gestão. Este sistema existe para a gestão de documentos digitais, deixando assim de parte a documentação em papel.
As características mais importantes do iPortalDoc são [8]: • Facilidade de utilização e formação reduzida; • Integração no ambiente de trabalho dos utilizadores;
• Redução do paperware e controlo de processos com utilização de workflows; • Segurança no acesso e ações sobre documentos.
2.3 Software 19
O iPortalDoc não funciona de forma independente. Funciona em colaboração com o sistema operativo IPBrick. Além deste sistema operativo, o iPortalDoc precisa de uma base de dados onde possa armazenar os documentos. Também está integrado com um servidor web, um servidor de correio eletrónico, um servidor de ficheiros e, ainda, um servidor de informação e gestão de domínios. Os utilizadores que podem ter acesso a esta aplicação são criados através da aplicação de gestão de contactos da IPBrick [8]. A Figura2.10mostra a arquitetura do mesmo.
Figura 2.10: Arquitetura iPortalDoc [8]
2.3.3 IPTicket
O IPTicket é uma solução de software para administração e resolução de problemas.
O cliente denuncia um determinado problema que é reportado no IPTicket. Simultaneamente, também se desencadeia um procedimento automático que destaca pessoal para resolver o problema reportado. É gerado um workflow para guiar o processo de resolução do problema. Durante este processo, também são trocados e.mails de modo a haver um diálogo constante entre o cliente e o técnico. No IPTicket é possível definir os técnicos responsáveis para cada tarefa e, assim, quando chega um pedido de ajuda, tudo funciona com mais celeridade. Caso existam, pode-se também fazer registo das assistências técnicas associadas a um problema.
No final, o técnico e o cliente podem receber relatórios produzidos pelo IPTicket e saber, por exemplo, quanto tempo levou a ser resolvido o problema e que custos estiveram envolvidos. Além disso, esta é uma solução baseada na web, o que significa que se pode aceder em qualquer lugar do mundo [38].
2.3.4 Contact Center
O Contact Center da IPBrick é uma ferramenta que permite ir mais além que um simples Call Center. O sucesso de uma empresa, na venda de produtos ou na resolução de problemas, depende da forma de comunicação. Esta ferramenta, pelo facto de conseguir melhorar a comunicação, garante que a qualidade dos serviços cresça exponencialmente.
No Contact Center, as comunicações não se baseiam apenas em chamadas telefónicas, pois são suportadas também outras formas de comunicação, como chamadas de vídeo, fax, e-mail, entre outras. Para além disso, o Contact Center associa as comunicações que chegam à sua plataforma a uma solução de gestão documental (iPortalDoc). Desta maneira, o Contact Center, através da sua interface, consegue controlar os workflows do iPortalDoc e, assim, faz com que os processos tenham um seguimento de uma forma mais fácil e intuitiva.
Desta forma, o Contact Center da IPBrick permite aos clientes melhorar o seus processos internos e externos poupando tempo e melhorando a qualidade dos serviços. A grande vantagem do Contact Center, é que, através da sua interface, pode-se controlar os workflows do iPortalDoc e comunicar com o cliente em tempo real.
O Contact Center, atualmente, não está em uso na IPBrick, mas apenas num cliente, a AMA, sendo que inicialmente foi concebido apenas para essa empresa.
2.4
Conclusão
No Capítulo2, foi feita uma revisão sobre as bases teóricas, tecnologias e softwares associados ao trabalho desenvolvido, de modo a que no Capítulo3seja introduzida a problemática desta dis-sertação, nomeadamente, os requisitos para a implementação de melhorias no IPTicket e Contact Center.
Capítulo 3
Problemas e Requisitos
Tendo sido efetuada no Capítulo2uma revisão das bases teóricas, tecnologias e softwares asso-ciados ao trabalho realizado, é necessário agora introduzir o problema e requisitos assoasso-ciados ao mesmo. Neste capítulo, abordar-se-ão os requisitos associados ao IPTicket e ao Contact Center. Também se apresentarão os casos de uso para ambas as aplicações para que, de uma maneira mais gráfica, se perceba as alterações que precisam de ser efetuadas.
3.1
Levantamento de Requisitos
A IPBrick é uma empresa com múltiplos clientes. Neste sentido, é fácil de perceber que os pedidos de melhoria são regulares. Por sua vez, a IPBrick também faz uso dos seus produtos de maneira interna e, neste sentido, vão sendo propostos melhoramentos relativos aos produtos, pelos seus colaboradores.
Para poder projetar uma integração de aplicações o mais completa possível, é necessário perceber que problemas existem ou que melhorias se podem fazer. Desta maneira, o feedback dos clien-tes, as opiniões e sugestões internas, levaram à elaboração de vários requisitos para o trabalho posterior.
3.1.1 IPTicket
Apesar do IPTicket não ser a aplicação que vai sofrer a integração, mas sim a que vai ser integrada, foi proposto que se fizessem melhoramentos e desenvolvimentos na mesma. Estas alterações que foram propostas vêm no sentido de melhorar a aplicação para a tornar mais completa e fazer com que a sua integração com o Contact Center possua mais funcionalidades. Deste modo, foi necessário proceder à elaboração de uma lista de requisitos.
A IPBrick é uma empresa com vários colaboradores e é comum existirem sempre várias pessoas a trabalhar na mesma aplicação. Deste modo, os vários requisitos a serem implementados foram divididos por várias pessoas. Aqui, são apenas abordados os que têm uma implicação direta com esta dissertação, com o meu trabalho.
3.1.1.1 Requisitos IPTicket
No estado "Conclusão", nos workflows existentes no IPTicket para a resolução de problemas, é feita a análise do desempenho da empresa na resolução de um problema. Atualmente, é possível, através de um comentário que o cliente faça, obter feedback sobre o serviço prestado.
Para melhorar a forma do cliente expressar a sua opinião sobre o serviço prestado e a empresa ter um feedback mais concreto e objetivo sobre a satisfação dos clientes, é necessário desenvolver uma forma de que, quem esteja a usar o IPTicket na sua empresa, consiga configurar graus de satisfação de acordo com os parâmetros de avaliação do seu negócio. Estes graus de satisfação permitirão que, por sua vez, no estado "Conclusão", seja possível atribuir ao problema, além de um comentário, uma avaliação objetiva sobre a resolução do problema.
Também é necessário conseguir que a informação do problema, com a inclusão dos graus de satisfação, seja disponibilizada no módulo de estatística do IPTicket com a funcionalidade de exportação para Excel.
A Tabela3.1mostra de forma objetiva os requisitos do IPTicket. Tabela 3.1: Tabela requisitos IPTicket Requisito
IPT01 Configurar graus de satisfação
IPT02 Cliente poder classificar um problema mediante os graus de satisfação definidos IPT03 Disponibilizar a informação do problema com os graus de satisfação
na tabela indicadores e conseguir a exportação da mesma
3.1.2 Contact Center
Com base no Contact Center desenvolvido para a AMA, em tempo anterior a esta dissertação, foi projetado e concebido um protótipo de Contact Center para a IPBrick. Na versão inicial, este protótipo foi apenas desenvolvido para estar integrado com o iPortalDoc e não com o IPTicket, tal como é necessário para a IPBrick. Neste sentido, foi feito um levantamento de requisitos para o Contact Centera ser implementado na IPBrick.
3.2 Casos de Uso 23
3.1.2.1 Exposição dos Requisitos
Após o levantamento de requisitos efetuado por várias pessoas, nos vários departamentos da em-presa, e projetando as funcionalidades que o Contact Center deveria possuir, surgiu a Tabela3.2.
Tabela 3.2: Tabela requisitos Contact Center Requisito
REF01 Fazer alterações na interface de configuração do Contact Center
para funcionar integrado com o IPTicket, caso esteja configurado para tal. REF02 O layout do Contact Center deverá estar adaptado para responder às
necessidades IPTicket quando está configurado dessa forma. REF03 Conseguir apresentar as ações/problemas pendentes no IPTicket a
serem resolvidas para cada utilizador.
REF04 Fazer com que o Contact Center consiga controlar o IPTicket sem o utilizador ter de aceder à interface do mesmo.
REF05 O Contact Center não deverá perder as funcionalidades que possui da integração com o iPortalDoc, devendo poder operar em simultâneo. REF06 Caso haja um e-mail associado a um problema reportado no IPTicket,
o mesmo deverá ser disponibilizado no Contact Center.
Apesar destes requisitos, o Contact Center deverá manter as suas funcionalidades iniciais, de acordo com o modo como foi projetado, mas com a possibilidade de integrar uma nova aplicação. Neste sentido é possível tirar algumas conclusões:
• O novo layout, com as alterações que terão de ser efetuadas, deverá continuar a ser de fácil utilização para quem já o utiliza, de modo a evitar perdas de tempo na reaprendizagem da sua utilização;
• O número total de "pedidos de apoio a tratar"deverá ser a soma das duas aplicações; • O bloco onde aparecerem "pedidos de apoio a tratar"(Figura3.1) deverá ser de
manusea-mento intuitivo ao utilizador. Este bloco verificará quais são as ações existentes do IPTicket e no iPortalDoc, sendo a ordenação dessas ações realizada por antiguidade;
• A interface do Contact Center que controlará o IPTicket deverá ser semelhante à usada na própria aplicação (Figura3.2), de modo a facilitar o trabalho ao utilizador.
3.2
Casos de Uso
Os diagramas dos casos de uso são uma linguagem de modelação que pertencem ao UML (Unfied Modeling Language). A sua utilização é comum na engenharia de software e têm como vantagem
Figura 3.1: Bloco onde mostra as notificações que chegam do IPortalDoc
a facilitar a interpretação entre as várias partes do sistema. Usando UML, obtém-se uma forma normalizada de projetar um sistema. É ainda de referir que, uma das vantagens dos casos de uso, é manter a abstração a um nível mais alto.
Os modelos representados pelas Figuras3.3e3.4são demonstrativos dos casos de uso do IPTicket e do Contact Center.
É importante referir que as ações que são apresentadas pelos diagramas de casos de uso para serem realizadas pelos utilizadores do IPTicket e do Contact Center estão limitadas às permissões que cada utilizador tem nas aplicações. Neste sentido, os diagramas de casos de uso do IPTicket e do Contact Center mostram as ações passíveis de serem realizadas por um administrador, que é um utilizador que possui todas as permissões.
3.3
Conclusão
O Capítulo3contém a explanação do problema e requisitos do IPTicket e Contact Center. Numa primeira parte, foram nomeados os requisitos das duas aplicações acima referidas. Numa segunda fase, foram apresentados os diagramas de uso das duas aplicações.
Terminado esta capítulo, é essencial, no Capítulo4, abordar a arquitetura das aplicações em causa, explicando também qual será a solução a implementar para os requisitos serem suprimidos.
3.3 Conclusão 25
Figura 3.2: Exemplo de campos e botões disponíveis numa ação do IPTicket
Capítulo 4
Arquitetura dos Sistemas e Solução
No Capítulo3, foi explanado o problema e requisitos do IPTicket e Contact Center, onde foram nomeados os requisitos das duas aplicações acima referidas e apresentados os diagramas de uso das mesmas. No presente capítulo, será abordada a arquitetura e estrutura do IPTicket e do Contact Center. Será também explicado como será pensada a solução final a nível da conceptualização das aplicações de modo a ir ao encontro aos requisitos apresentados no Capítulo3.
Primeiramente, falar-se-á do IPTicket, explicando o seu funcionamento e a sua arquitetura. De seguida, apresentar-se-á o Contact Center, explicando-se também o seu funcionamento inicial com a integração com do iPortalDoc. Para ambas as aplicações, será proposta uma solução que irá ao encontro dos requisitos apresentados no Capítulo3.
4.1
IPTicket
O IPTicket é uma solução de software para administração e resolução de problemas. Nesta secção, vai ser explicado com mais detalhe, o funcionamento do mesmo e bem como uma solução para suprimir os requisitos apresentados.
4.1.1 Arquitetura do Sistema
As alterações que serão efetuadas no IPTicket não vão trazer qualquer alteração à arquitetura do sistema; no entanto, é essencial perceber como funciona esta aplicação.
O IPTicket caracteriza-se por ser uma aplicação que não requer instalação num computador. Caso uma empresa possua um sistema operativo IPBrick e, consequentemente, um servidor IPBrick,
acede à aplicação através de um browser , se tiver o IPTicket instalado no sistema operativo. A Figura4.1ilustra a arquitetura do sistema.
Figura 4.1: Arquitetura do Sistema para o IPTicket
4.1.2 Base de Dados
Uma base de dados é para qualquer aplicação e para qualquer programa um ponto fulcral do mesmo, pois é lá que é armazenada toda a informação.
O IPTicket possui uma base de dados relacional PostgreSQL onde se armazena toda a informa-ção associada à aplicainforma-ção. Esta base de dados armazena tanto os dados do IPTicket como os do iPortalDoce contém cerca de 956 tabelas.
4.1.3 Arquitetura da Aplicação
Para utilizar esta aplicação é necessário um terminal com um browser, através do qual, se acede à interface da aplicação. Executando determinadas ações, esta aplicação, acede à base de dados através do servidor IPBrick onde está alojado o IPTicket e faz retornar a informação à aplicação mencionada (Figura4.2).
4.1 IPTicket 29
Figura 4.2: Arquitetura da aplicação IPTicket
O IPTicket tem, essencialmente, duas grandes funcionalidades: resolução de problemas e registo de assistências.
Na resolução de problemas, um cliente através de um e-mail, ou acedendo ao IPTicket, reporta um determinado problema. A partir desse momento e de forma automática, é despoletado no IPTicket um processo de resolução desse mesmo problema. Os colaboradores, que tiverem permissões para tal, são notificados, para resolver a situação reportada. Para dar o seguimento correto à resolução do ticket/problema é usado um sistema de workflows que permite saber em que etapa do processo se está e garantir que são seguidas todas as etapas necessárias.
A Figura4.3mostra o exemplo de um workflow onde existem 6 estados. • Cla - Classificar;
• Obt - Obter; • Res - Resolver; • Exe - Executar; • Con - Conclusão; • Est - Estado Final;
Para cada estado, apenas os colaboradores que têm permissão para trabalhar nesse estado, podem efetuar ações sobre o mesmo.
Figura 4.3: Exemplo workflow IPTicket
No estado "Classificar", é priorizado o problema após uma análise inicial da situação. Estes níveis de prioridade podem ser configurados pela empresa que adquiriu uma licença do IPTicket. Seguindo-se para o estado "Obter", o problema fica disponível para ser resolvido pelos colabora-dores da empresa. Quem obtiver o problema assume-o e analisa-o.
No estado "Resolver"existem duas opções: ou o colaborador, efetivamente, consegue resolver o problema, ou pode encaminha-lo para que outro colega o resolva. Neste caso passa-se ao estado "Executar", para que o colaborador execute a tarefa que lhe foi atribuída. Após a execução da tarefa, retorna-se ao estado "Resolver": o colaborador inicial verifica se o problema está efetiva-mente resolvido. Se assim é, então, segue-se o estado "Conclusão". Neste estado, o cliente verifica se o problema foi resolvido e pode ser feita a avaliação dessa resolução por parte do cliente, após o que o workflow segue para o estado final, ou seja, o problema é dado como resolvido.
No que diz respeito às assistências, o seu funcionamento é simples: para ser resolvido um pro-blema de um cliente é necessária uma assistência técnica. Nesse sentido, dependendo do tipo de
4.1 IPTicket 31
intervenções que sejam necessárias fazer, cada funcionário vai poder registar a assistência que rea-lizou, bem como o número de horas despendido. Assim, a empresa saberá quanto tempo foi gasto na resolução do problema e consequentemente dos custos associados.
4.1.4 Solução
4.1.4.1 Configurações
Figura 4.4: Esquema explicativo do papel que o utilizador tem na configuração dos graus de satisfação
O utilizador, a nível de configuração, tem de conseguir efetuar três ações (Figura4.4):
• Introduzir: Inserir o grau de satisfação que pretende para que o cliente possa fazer uma avaliação da resolução de um problema;
• Modificar: Modificar os dados dos graus de satisfação previamente inseridos; • Ativar/Desativar: Ativar ou desativar o uso de determinado grau de satisfação.
Não será possível eliminar graus de satisfação pois, caso um determinado grau de satisfação já tenha sido usado, essa informação terá de ficar guardada na base de dados do IPTicket de modo a poder ser utilizada para fins estatísticos e de análise.
4.1.4.2 Aplicação
Aplicadas as configurações, no estado "Conclusão"dos workflows do IPTicket, deverão ser apre-sentados todos os graus de configuração ativos de modo a que o cliente possa escolher o desejado. Não se deverá perder a funcionalidade respeitante ao cometário de um cliente acerca da sua avali-ação sobre a resolução do problema.
A informação associada ao problema (nome, data de início, data de conclusão, data limite, pri-oridade, etc) ficará guardada na base de dados do IPTicket. O grau de satisfação associado ao problema também deverá fazer parte dessa informação. Esta mesma informação, para fins esta-tísticos, é disponibilizada numa tabela chamada "Indicadores"disponível no IPTicket. Os graus de satisfação deverão passar a fazer parte integrante desta tabela. Existe, ainda, a funcionalidade de exportar os "Indicadores"para um ficheiro Excel (sem graus de satisfação). Assim, é impor-tante que os graus de satisfação também sejam exportados num ficheiro Excel, quando se faz o downloadda tabela em causa.
A Figura4.4, premite visualizar, o processo associado à atribuição dos graus de satisfação, res-salvando que não é um processo linear, ou seja, escolher o grau de satisfação, guardá-lo na base dados, fazendo com que fique disponível na tabela "Indicadores", não implica a exportação ime-diata da tabela.
Figura 4.5: Processo associado à atribuição dos graus de satisfação
4.1.4.3 Base de dados
Para que sejam guardados os graus de satisfação na base de dados, terão de ser efetuados os seguintes procedimentos, a saber: terá de ser criada uma nova tabela que armazenará os dados
4.2 Contact Center 33
Figura 4.6: Arquitetura das tabela de problemas
relativos aos graus de satisfação, nomeadamente, o seu nome, juntamente com a indicação de se está ativo ou não; é também necessário que a tabela tenha um identificador que permita que cada grau de satisfação esteja associado a um problema (Figura4.6).
Figura 4.7: Arquitetura da tabela graus de satisfação
Na tabela problemas (Figura 4.7), terá de ser adicionado um campo que permitirá armazenar o valor do identificador do grau de satisfação atribuído a um determinado problema. Deste modo, será possível fazer a ligação à tabela que tem guardados todos os graus de satisfação.
4.2
Contact Center
A solução apresentada para a integração do Contact Center com o IPTicket é para ser usada, pelo menos numa fase inicial, apenas na IPBrick, para a gestão e suporte a clientes.
Figura 4.8: Arquitetura do Sistema para o Contact Center
4.2.1 Arquitetura do Sistema
Na Figura4.8é mostrada, com um alto nível de abstração, a forma como o Contact Center está assente no sistema operativo da IPBrick. Também é mostrado como Contact Center integra o iPortalDoc.
Como referido, o IPBick OS é um sistema operativo onde assentam todas as aplicações da IPBrick SA e, neste sentido, o sistema operativo da empresa apresenta-se no centro deste diagrama. Para o funcionamento do Contact Center é necessário que esteja instalado na IPBrick OS o iPortalDoc. O Contact Center, apesar de ter uma base de dados própria, não tem nela armazenadas as infor-mações relativas às aplicações com que se encontra integrado, neste caso com o iPortalDoc. Para tal, são utilizados webservices para aceder à base de dados da aplicação de gestão documental.
4.2.2 Base de Dados
À semelhança do IPTicket e de todas as aplicações da IPBrick, o Contact Center possui uma base de dados PostgreSQL. Mesmo trabalhando com bases de dados de outras aplicações, o Contact
4.2 Contact Center 35
Centerpossuí uma base de dados própria para guardar dados, nomeadamente, a nível das configu-rações.
4.2.3 Arquitetura da Aplicação
Figura 4.9: Arquitetura da aplicação Contact Center
Do mesmo modo que o IPTicket, para se aceder ao Contact Center, é utilizado um browser. Ace-dendo à aplicação através das credenciais de login, o utilizador terá acesso à aplicação, após o que, existem duas possibilidades de funcionamento de acesso à informação mediante as ações efe-tuadas na interface: pode ser necessário aceder à base de dados do Contact Center, por questão de configurações e, nesse caso, o acesso é feito diretamente através do servidor IPBrick; caso seja necessário aceder à base de dados de outra aplicação, o acesso à mesma far-se-á através de webservices. Em ambos os casos, os resultados retornam à interface do Contact Center (Figura
4.9).
Como podemos verificar na Figura4.10, qualquer cliente pode contactar uma empresa que possua o Contact Center por e-mail, chamada telefónica, chat ou vídeo-chamada. Ao ser detetada a comunicação, vai ser iniciado no iPortalDoc um processo que terá um workflow associado para lhe dar seguimento (Figura4.11).
Existindo então, essa ação pendente no iPortalDoc, o Contact Center vai fazer com que a mesma apareça na sua interface para que o utilizador saiba que existem "pedidos de apoio a tratar"associadas
Figura 4.10: Comunicações efetuadas para o CC
à sua conta.
Por fim, o utilizador poderá abrir o "pedido de apoio a tratar"no botão, como mostra a seta verde da Figura4.12), e, deste modo, através da interface do Contact Center, fazer avançar, o workflow até o processo estar concluído (Figura4.13).
Dependo da comunicação usada, o utilizador tem sempre na interface do Contact Center a pos-sibilidade de trocar e-mails com o cliente, caso seja necessário. Se a comunicação for efetuada por chamada telefónica, o utilizador pode estar a falar com um cliente durante a resolução do pro-cesso sendo a chamada guardada na base de dados em formato .mp3. Quando a comunicação é o chat(Instant Messaging) há uma janela de chat que permite ao utilizador dialogar com o cliente. Por fim, se se usar a vídeo-chamada aparecerá na interface do Contact Center um bloco onde é possível ver a câmara do cliente e este ver a do utilizador.
4.2.4 Solução
Efetuada uma análise dos requisitos e percebendo o modo de funcionamento do Contact Center, é proposta uma solução para o problema apresentado.
Do mesmo modo que o iPortalDoc se encontra instalado na IPBrick, o mesmo deverá acontecer com o IPTicket. Deste modo, o utilizador deverá aceder à aplicação através de um browser. Sendo esta uma aplicação com necessidade de comunicar com outra, será necessário usar webservices para que, mediante as ações e pedidos efetuados na interface do Contact Center, seja possível realizar as mesmas ações e pedidos de informação no IPTicket e na sua base de dados.
4.2 Contact Center 37
Figura 4.11: Acção pendente do iPortalDoc
Ao ser efetuada uma comunicação no iPortalDoc é despolotada uma ação. O mesmo acontece no IPTicket, ou seja, quando é reportado um problema por e-mail ou diretamente na aplicação. Sendo assim, primeiramente, é preciso fazer com que o Contact Center consiga obter a informação desejada, seja ela qual for, relativa ao IPTicket. A melhor maneira de o fazer é usar webservices, os quais servirão de ponte entre a interface do Contact Center e a base de dados do IPTicket. Deste modo, permitir-se-á que aplicações diferentes consigam comunicar entre si com mais segurança e de modo universal. Nesta dissertação, optou-se por conseguir controlar a resolução dos problemas do IPTicket no Contact Center deixando as assistências de parte.
Em suma, será necessário utilizar/desenvolver/alterar webservices para ser possível obter informa-ção relativa aos problemas a serem resolvidas no IPTicket. Esta informainforma-ção deverá conter dados relativos a:
• Descrição do problema; • Sumário do problema; • Data de registo do problema; • Prazo de de resolução; • Prioridade do problema; • ID do problema;
• ID saber a entidade a que está associado; • Informação do estado atual do workflow.
Obtida esta informação, é preciso apresentá-la no bloco de "pedidos de apoio a tratar"(Figura
Figura 4.12: Notificação no Contact Center
A partir do momento em que os pedidos estão pendentes para serem resolvidos no Contact Center, o utilizador deverá ter a possibilidade de abrir os pedidos para dar seguimento à sua resolução, tal como acontece na sua integração com o iPortalDoc. Assim sendo, será necessário obter a infor-mação de cada estado do workflow associado à resolução de um problema do IPTicket, escolhido de entre os problemas pendentes a serem resolvidos. Com a informação obtida acerca do pro-blema em causa, é preciso construir uma interface que permita controlar os estados do workflow em causa. A interface de controlo no Contact Center terá de apresentar todas as funcionalidades que estão presentes na interface de controlo do IPTicket para permitir realizar as mesmas ações que estão associadas a cada estado do workflow, na aplicação de resolução e gestão de problemas. No bloco "pedidos de apoio a tratar", à medida que se avança com cada pedido, deverá ser apre-sentada a informação atualizada de cada estado do workflow para cada problema. Vários pedidos podem ser resolvidos em simultâneo, pois ao longo do processo de resolução de problemas, co-laboradores diferentes assumem etapas diferentes no workflow. Deverá também existir, no bloco "pedidos de apoio a tratar", uma coluna que permita saber se o pedido vem do iPortalDoc ou do IPTicket, e uma outra que permita conhecer a data limite de resolução do problema do IPTicket.
4.2 Contact Center 39
Figura 4.13: Interface de controlo worlflow do iPortalDoc no Contact Center
4.2.4.1 Configurações e Base de Dados
No que diz respeito às configurações do Contact Center será necessário acrescentar um campo onde se possa inserir o WSDL URL que contém o código em XML para que seja possível aceder-se aos webaceder-services e conaceder-sequentemente à informação da baaceder-se de dados do IPTicket. Também aceder-será necessário conseguir inserir o URL do IPTicket para se aceder ao e-mail associado ao problema, caso este exista.
Para tal, será necessário acrescentar na base de dados do Contact Center, na tabela das configura-ções, (Figura4.15) os seguintes campos:
• URL IPTicket; • WSDL URL IPTicket; • Username de administrador; • Password do administrador.
Figura 4.14: Exemplo de quando chega um pedido a tratar ao Contact Center via iPortalDoc
Além dos URL e do WSDL URL, será possível adicionar o username e password do administra-dor, pois foi sugerido que seria importante a sua existência para que no futuro, caso seja necessário aceder ao IPTicket com as credenciais de administrador, essa informação ser passível de ser inse-rida. O Contact Center já se encontra programado para, com as credenciais do utilizador que está a usar a aplicação, obter informação associada aos problemas pendentes no IPTicket.
Figura 4.15: Arquitetura da tabela configurações do Contact Center
4.3
Conclusão
Em suma, neste capítulo foi feita a explicação da arquitetura do IPTicket e do Contact Center. Também foram apresentadas soluções para suprimir os requisitos apresentados no Capítulo 3. Segue-se agora o Capítulo5onde são explicados os desenvolvimentos efetuados no Contact Cen-tere no IPTicket tendo como base a solução apresentada neste capítulo.
Capítulo 5
Implementação
Tendo como base as soluções apresentadas no Capítulo4, neste capítulo serão abordadas as imple-mentações e desenvolvimentos efetuados nas aplicações da IPBrick. Também se dará uma breve explicação sobre a plataforma e ferramentas usadas para o desenvolvimento do projeto.
5.1
Plataforma e Ferramentas de Apoio ao Desenvolvimento
5.1.1 Plataforma
Esta dissertação foi desenvolvida nas instalações da IPBrick SA, onde foi cedido todo o material necessário ao seu desenvolvimento. Do mesmo modo, também foi dado todo o apoio por parte dos meus colegas para a concretização deste projeto.
O desenvolvimento foi efetuado num computador/terminal com o sistema operativo Ubuntu. Pela empresa, foram fornecidos todos os ficheiros com o código-fonte das aplicações com que foi necessário trabalhar (IPTicket, iPortalDoc, Contact Center).
Para que fosse possível ao longo da dissertação fazer a depuração das alterações efetuadas no código-fonte das aplicações, o sistema de ficheiros está alojado num servidor próprio (máquina virtual), que faz com que seja possível, em tempo real, a sincronização dos ficheiros que estão a ser modificados no posto de trabalho com os que estão instalados na IPBrick através do comando mount.
