faculdade de ci^encias - repositorio.ul.ptrepositorio.ul.pt/bitstream/10451/4322/1/ulfc... ·...

Universidade de LisboaFaculdade de Ciencias

Departamento de Informatica

Optimizacao/Evolucao de uma plataforma CRM

Antonio Miguel Garrett Vieira

Mestrado em Engenharia Informatica

2008

Universidade de LisboaFaculdade de Ciencias

Departamento de Informatica

Optimizacao/Evolucao de uma plataforma CRM

Antonio Miguel Garrett Vieira

ESTAGIO

Projecto orientado pelo Prof. Dr. Andre Falcaoe co-orientado por Dr. Rui Rolo

Mestrado em Engenharia Informatica

2008

Declaracao

Antonio Miguel Garrett Vieira, aluno no 29075 da Faculdade de Ciencias da Uni-

versidade de Lisboa, declara ceder os seus direitos de copia sobre o seu Relatorio

de Projecto em Engenharia Informatica, intitulado ”Optimizacao/Evolucao de uma

plataforma CRM”, realizado no ano lectivo de 2007/2008 a Faculdade de Ciencias

da Universidade de Lisboa para o efeito de arquivo e consulta nas suas bibliotecas

e publicacao do mesmo em formato electronico na Internet.

FCUL, 30 de Setembro de 2008

Dr. Rui Rolo, supervisor do projecto de Antonio Miguel Garrett Vieira, aluno

da Faculdade de Ciencias da Universidade de Lisboa, declara concordar com a di-

vulgacao do Relatorio do Projecto em Engenharia Informatica, intitulado ”Opti-

mizacao/Evolucao de uma plataforma CRM”.

Lisboa, 30 de Setembro de 2008

Resumo

A forma como as organizacoes gerem a relacao com os seus clientes e hoje recon-

hecida como um factor determinante que contribui para aumentar o valor das em-

presas. Assim, e importante conhecer as preferencias dos clientes, os seus habitos de

compra, identifica-los e segmenta-los por multiplos criterios de escolha para que a

empresa lhes possa prestar um servico de excelencia em linha com as caracterısticas

previamente identificadas. As pequenas empresas estao sempre ligadas as relacoes

com os clientes: saber os seus nomes, conhecer as preferencias e proporcionar o tipo

de servico amigavel que os leva a voltar sempre. No entanto, a medida que uma

empresa cresce, essa capacidade de relacionamento a nıvel pessoal com cada cliente

torna-se cada vez mais difıcil. Todavia, uma gestao eficaz dessas relacoes com os

clientes e essencial para a rentabilidade da empresa.

E possıvel implementar uma estrategia CRM que permita ganhar vantagem com-

petitiva atraves do conhecimento dos seus clientes, dos seus habitos de consumo ou

das suas necessidades e do valor que representam. O CRM ajuda o cliente a definir

uma estrategia e a implementar sistemas que lhe permitam personalizar os seus

esforcos de Marketing, permitindo assim enderecar correctamente a informacao de

forma mais rapida e economica e oferecer um servico de qualidade apropriado a cada

segmento. Este documento descreve os trabalhos realizados durante o projecto de

estagio. Projecto este que foi desenvolvido para uma empresa da area farmaceutica

e cujo objectivo e gerir a logıstica e todos os processos associados a gestao de even-

tos. Todo o seu desenvolvimento foi feito utilizando a ferramenta Siebel, que e a

ferramenta mais utilizada em todo o mundo, no que diz respeito ao desenvolvimento

de aplicacoes CRM.

PALAVRAS-CHAVE:

CRM, Evento, ProfEd, Siebel

i

Abstract

The way organizations manage the relation with their customers, is recognized as

a main factor that contributes to raise the companies profits. So, it is important

to know the customers preferences, identify and segment them by multiple choice

criteria, so that the company can offer the best services that go with the identified

characteristics. The small companies are always connected to the relations with the

customers: know their names, know their preferences and create the type of service

which will make them to always come back. Even though, and as the company

grows, the personal relation with the client becomes more difficult. But, an effec-

tive management of the relations with the customers is essential for the profitability.

It is possible to implement a CRM strategy, which allows gaining competitive ad-

vantage through the knowledge of their customers, their habits of consumption or

of their needs and the value they represent. CRM helps the customer to define

a strategy and implement systems that allow customizing the marketing efforts, to

address the information more quickly and economically and provide a quality service

appropriate to each segment. This document describes the work done during the

internship. This project was developed for a company of the pharmaceutical area,

its aim is to create and add information to define the scope, activities and budget

for an event. It was developed using Siebel, which is the most used tool in whole

world, regarding the development of CRM applications

KEYWORDS:

CRM, Event, ProfEd, Siebel

iii

Conteudo

Lista de Figuras viii

1 Introducao 1

1.1 Motivacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Objectivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Organizacao do documento . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Enquadramento 3

2.1 A Empresa de acolhimento . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 A Empresa Cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.3 O Projecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3 Optimizacao/Evolucao de uma plataforma CRM 5

3.1 Customer Relationship Management (CRM) . . . . . . . . . . . . . . 5

3.2 Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.2.1 Solucao Vertical . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.2.2 Solucao Horizontal . . . . . . . . . . . . . . . . . . . . . . . . 6

3.3 Ferramentas Utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.3.1 Siebel 7.7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.3.2 Actuate Report . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.4 Metodologia Utilizada . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.4.1 Formacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.4.2 Analise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.4.3 Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . 15

3.4.4 Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.4.5 Documentacao . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.4.6 Apoio Pos-Producao . . . . . . . . . . . . . . . . . . . . . 19

4 Trabalho Desenvolvido 20

4.1 Actividades desenvolvidas . . . . . . . . . . . . . . . . . . . . . . . . 20

4.1.1 Email Templates . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.1.2 Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

v

4.1.3 Requisitos Siebel . . . . . . . . . . . . . . . . . . . . . . . . . 25

5 Conclusao 27

5.1 Trabalho Desenvolvido . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.2 Trabalho Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.3 Analise Crıtica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

A Change Requests 29

B Test Problem Reports 31

Bibliografia 33

vi

Lista de Figuras

2.1 Planeamento do projecto de estagio . . . . . . . . . . . . . . . . . . . 4

3.1 Siebel Life Sciences - Siebel Operating Architecture . . . . . . . . . . 8

3.2 Arquitectura logica . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.3 Componentes internas de funcionamento do Siebel . . . . . . . . . . . 10

3.4 Siebel Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.5 Siebel Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.6 Actuate e.Report Designer Professional . . . . . . . . . . . . . . . . . 14

3.7 Fases do projecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.8 Ambiente de Producao - Informacao de um requisito . . . . . . . . . 16

3.9 Ambiente de Producao - Informacao geral de um requisito . . . . . . 17

3.10 Ambiente de Producao - Informacao detalhada de um requisito . . . . 17

3.11 Informacao de desenvolvimento de um requisito 1 . . . . . . . . . . . 18

3.12 Informacao de desenvolvimento de um requisito 2 . . . . . . . . . . . 18

3.13 Composicao da fase de Testes . . . . . . . . . . . . . . . . . . . . . . 19

4.1 Email Template - Observer Invite . . . . . . . . . . . . . . . . . . . . 22

4.2 Email Template - Esquema . . . . . . . . . . . . . . . . . . . . . . . . 23

4.3 Siebel Tools - Workflow Process . . . . . . . . . . . . . . . . . . . . . 23

4.4 Siebel Client - Workflow Process . . . . . . . . . . . . . . . . . . . . . 24

4.5 Applet dos participantes de um evento . . . . . . . . . . . . . . . . . 26

4.6 Applet Retrieve PNR . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

A.1 Lista de Requisitos desenvolvidos . . . . . . . . . . . . . . . . . . . . 30

B.1 Lista de Erros corrigidos . . . . . . . . . . . . . . . . . . . . . . . . . 32

viii

Capıtulo 1

Introducao

O presente relatorio tem como objectivo apresentar o trabalho realizado no projecto

”Optimizacao/Evolucao de uma plataforma CRM”na empresa Altran CIS, Altran

Consulting & Information Services, enquadrado na disciplina de Projecto de Engen-

haria Informatica (PEI), no ambito do Mestrado em Engenharia Informatica (MEI)

2007/2008.

Este projecto foi desenvolvido para um cliente da industria farmaceutica e visto

ter exigido a confidencialidade no que diz respeito a sua identidade, deste ponto em

diante sera denominada por empresa cliente.

O projecto teve a duracao de cerca de nove meses, nos quais se incluem a elab-

oracao deste relatorio.

1.1 Motivacao

Na empresa cliente surgem com alguma frequencia eventos. O tipo de eventos pode

ser bastante diversificado, como por exemplo, conferencias, formacoes, aulas de lab-

oratorio, apresentacoes de novos produtos que, eventualmente, serao lancados no

mercado, etc. De modo a promover um evento de forma organizada e eficaz, e

necessario ter em conta varios aspectos e consequentemente, manter e gerir toda

a sua informacao. Estes aspectos, podem ir desde a gestao das salas, como por

exemplo laboratorios, ou auditorios onde os eventos irao decorrer, gestao do registo

dos participantes nos ditos eventos, gestao dos respectivos pagamentos e de toda a

logıstica associada.

Visto se tratar de uma empresa de um grande grupo internacional, estabelecida

em varios paıses de diversos continentes, surgiu entao, a necessidade de ter organi-

zada de alguma forma, toda a informacao relativa a organizacao e gestao de eventos.

1

Capıtulo 1. Introducao 2

Foi entao que, apos exposicao de varias ideias, problemas e solucoes, surgiu, ha cerca

de dois anos, o projecto ”Professional Education”, daqui em diante sera designado

por ProfEd. Trata-se de uma aplicacao bastante complexa e que agrupa os varios

processos relativos a Gestao de Eventos.

Trata-se de uma aplicacao, que ate agora apenas e usada por um cliente nos Estados

Unidos da America.

1.2 Objectivos

Uma vez que o quando o estagio teve inıcio, o projecto de ProfEd ja vinha a ser

desenvolvido ha algum tempo, os objectivos para o projecto de PEI foram desde

a implementacao de novas funcionalidades sobre a aplicacao ja existente de acordo

com os requisitos de negocio do cliente, assim como a execucao e apoio dos testes a

aplicacao, elaboracao de documentacao e apoio pos-producao ao cliente.

1.3 Organizacao do documento

Este documento esta organizado da seguinte forma. Apos uma pequena introducao, e

feito um enquadramento do projecto desenvolvido e uma breve descricao da empresa

de acolhimento e da empresa cliente. De seguida, sao apresentadas as ferramentas

utilizadas no desenvolvimento do projecto, bem como a metodologia usada na elab-

oracao do mesmo. Cada uma das fases do desenvolvimento do projecto e descrita e

e explicado o conceito de Customer Relationship Management (CRM). Finalmente

e descrito o trabalho desenvolvido ao longo do estagio. Relativamente ao trabalho

desenvolvido, sao dados alguns exemplos de requisitos desenvolvidos. Por ultimo, e

apresentada a conclusao de todo o projecto de estagio.

Capıtulo 2

Enquadramento

Neste capıtulo sao descritas as duas empresas envolvidas, a instituicao de acolhi-

mento e aquela para a qual o projecto foi desenvolvido, a empresa cliente. Sao

ainda apresentadas as fases de desenvolvimento do projecto.

2.1 A Empresa de acolhimento

A Altran CIS, nasceu em 2006 da fusao de duas empresas, a Prisma e Global N.

A Prisma foi criada em 1992 com o objectivo de ser a primeira empresa Portuguesa

a fornecer servicos de Consultoria em Tecnologias de Informacao (TI). A empresa,

apesar de ter comecado a sua actividade nas areas das TI, rapidamente diversificou

os seus negocios, assumindo a responsabilidade em projectos de organizacao, gestao

e controlo nos mais variados sectores de actividade. [1]

O grupo Global N Portugal foi criado em Maio de 2000, com o objectivo de agrupar

as empresas NCubo, NTech, NDados, NWeb e N4mation, assim como aproveitar as

sinergias do grupo em termos de economia de escala das areas importantes e comuns,

igualmente vocacionadas para as Intelligence Solutions. A Global N foi constituıda

para apresentar ao mercado uma imagem integradora e agregadora daquilo que e um

conjunto de empresas. O Brasil foi o primeiro ponto de expansao do grupo, atraves

da abertura de escritorios locais.

Aproveitando a experiencia acumulada da empresa e dos seus consultores, nasce

a Altran CIS, desenvolvendo solucoes em diversas areas, desde estudos estrategicos

e planos directores de informatica, ate consultoria especializada nas areas de sis-

temas, bases de dados e seguranca, passando inevitavelmente por todas as areas

ligadas ao desenvolvimento de aplicacoes, desde os aspectos mais funcionais ate a

implementacao final, garantindo sempre elevados padroes de qualidade.

A Altran CIS faz parte de um grande grupo internacional de consultoria e tecnolo-

3

Capıtulo 2. Enquadramento 4

gia, potenciando assim a capacidade de mobilidade de competencias para os diversos

desafios que os seus Clientes lhe colocam [2].

2.2 A Empresa Cliente

A empresa cliente, faz parte de um grupo internacional da area da saude/farmaceutica.

Estabelecida em mais de 50 paıses, contem franchises em varios segmentos de negocio

como cuidados de saude, farmaceutica, dispositivos medicos de diagnostico, etc.

Aposta na diversidade de produtos de forma a aumentar a sua participacao no mer-

cado. Em relacao aos cuidados de saude, aposta em produtos de uso diario para

todas as idades. Relativamente a dispositivos medicos de diagnostico, produz dispos-

itivos de esterilizacao de material, material de cirurgia e de suturacao, dispositivos

de monitorizacao sanguınea, etc.

Visto se tratar de um grande grupo internacional, ha que ter sistemas de gestao de

recursos humanos, material, facturacao, etc. Este projecto, incidiu numa aplicacao

que visa ajudar a empresa cliente a gerir todos os processos inerentes a gestao de

eventos.

Apesar de o conteudo do projecto e da informacao contida neste relatorio nao serem

confidenciais, a empresa cliente prefere nao divulgar a dua identidade.

2.3 O Projecto

O projecto de PEI teve inıcio a meados de Agosto de 2007, com uma fase de

formacao. Esta fase teve sensivelmente a duracao de um mes e meio. De seguida e

com duracao similar, teve lugar a fase de Analise. Analisados todos os requisitos de

negocio, surgiu a maior fase do projecto, com uma duracao de cerca de quatro meses,

o Desenvolvimento. De seguida teve lugar a fase de Testes e respectivas correccoes e

a elaboracao de Documentacao. Na imagem seguinte 2.1, e possıvel ter uma melhor

percepcao das fases do projecto bem como a respectiva duracao.

Figura 2.1: Planeamento do projecto de estagio

Capıtulo 3

Optimizacao/Evolucao de umaplataforma CRM

Neste capıtulo, e explicado o conceito de Customer Relationship Management ou

CRM. Sao descritas ainda as solucoes vertical e horizontal bem como as ferramentas

utilizadas ao longo do projecto para o desenvolvimento da aplicacao. Por ultimo e

descrita a metodologia utilizada para o desenvolvimento do projecto, assim como o

objectivo de cada uma das fases do desenvolvimento.

3.1 Customer Relationship Management (CRM)

A forma como as organizacoes se relacionam com os seus clientes, e reconhecida

hoje em dia como um factor determinante, que contribui para aumentar o valor

da empresa, assim como o seu market-share, ou seja, a sua participacao no mer-

cado. Assim e importante conhecer as preferencias dos clientes, os seus habitos de

compra, identifica-los e segmenta-los por multiplos criterios de escolha para que a

empresa lhes possa prestar um servico de excelencia em linha com as caracterısticas

previamente identificadas. Desta forma nao so se atinge o desıgnio da qualidade e

consistencia do servico prestado ao Cliente como se criam oportunidades que em si

geram mais valor para a empresa.[3]

O CRM e um sistema integrado de gestao com foco no cliente, constituıdo por

um conjunto de procedimentos/processos organizados e integrados num modelo de

gestao de negocios. O seu objectivo principal e auxiliar as organizacoes a angariar

e fidelizar clientes procurando atingir a sua satisfacao total, atraves de uma melhor

compreensao das suas necessidades e expectativas e formacao de uma visao global

dos ambientes de marketing.

O CRM abrange, na generalidade, tres grandes areas, tais como, a automatizacao

da gestao de marketing, automatizacao da gestao comercial, dos canais de comu-

5

Capıtulo 3. Optimizacao/Evolucao de uma plataforma CRM 6

nicacao e vendas, bem como a gestao dos servicos ao cliente. Os processos e sistemas

de gestao de relacionamento com o cliente permitem que se tenha controlo e con-

hecimento das informacoes sobre os clientes de maneira integrada, principalmente

atraves do acompanhamento e registo de todas as interaccoes com o cliente, que

podem ser consultadas e comunicadas a diversas partes da empresa que necessitem

desta informacao para guiar as tomadas de decisoes. Uma das actividades do CRM

implica registar os contactos realizados, de forma centralizada. Os registos nao de-

pendem do canal de comunicacao que o cliente utilizou (voz, fax, e-mail, SMS, MMS,

etc.) e servem para que se tenham informacoes uteis e catalogaveis sobre os clientes.

Qualquer informacao relevante para as tomadas de decisoes podem ser registadas e

analisadas periodicamente, de forma a produzir relatorios de gestao. [4]

3.2 Arquitectura

O projecto proposto para o estagio, consistiu na Optimizacao/Evolucao de uma

plataforma CRM. Trata-se de um projecto bastante complexo, constituıdo por varios

modulos independentes, em que todo o seu desenvolvimento foi feito utilizando a

ferramenta Siebel.

A plataforma Siebel tem diversas solucoes para as mais variadas industrias. Mas

mesmo estas solucoes ja desenvolvidas, necessitam sempre de alteracoes, de modo a

servir o melhor possıvel o cliente.

3.2.1 Solucao Vertical

Neste projecto, e por se tratar de um projecto para a area medica/farmaceutica,

a solucao vertical adoptada para o seu desenvolvimento foi a solucao Siebel Life

Sciences.

Esta solucao vem ja com algumas funcionalidades implementadas, como por ex-

emplo a gestao de contactos que suporta varios tipos de contactos como medicos,

enfermeiros, tecnicos, entre outros, gestao de clientes, gestao de oportunidades,

gestao de eventos, gestao de vendas de produtos, etc. Mas como quase todas as

aplicacoes, ha sempre a necessidade de ajustar, criar e reformular outras funcional-

idades necessarias e que ainda nao estao disponıveis. E porque cada negocio e um

negocio, ha que criar a aplicacao de acordo com os requisitos do cliente, de modo a

servi-lo da melhor maneira [5].

3.2.2 Solucao Horizontal

Dado a area de negocio deste projecto, a solucao adoptada foi a ”Siebel Medical”. No

ambito deste projecto, o modulo que utiliza esta solucao tem o nome de ProfEd. Este


modulo vem ja com algumas funcionalidades implementadas, como por exemplo:

• Criacao de Eventos e de Planos de Eventos;

• Registo de participantes nos Eventos;

• Gestao de contactos;

• Gestao e Calendarizacao de Eventos;

• Criacao de Sessoes.

Como ja foi referido anteriormente, muitas outras funcionalidades tiveram de ser

implementadas para a aplicacao ficar de acordo com o que o tinha sido pedido pelo

cliente.

3.3 Ferramentas Utilizadas

Durante a implementacao do projecto foram utilizadas maioritariamente duas ferra-

mentas. Em relacao a aplicacao, esta foi toda desenvolvida utilizando a plataforma

Siebel. Ja a elaboracao de relatorios foi feita utilizando a ferramenta Actuate

e.Report Designer.

3.3.1 Siebel 7.7

O Siebel e nos dias de hoje, uma referencia em software CRM, vocacionado para o

desenho, desenvolvimento, marketing e suporte de aplicacoes empresariais que dao

suporte a organizacoes. Tem solucoes identificadas e desenvolvidas que se adaptam

as industrias existentes. A estas solucoes da-se o nome de solucoes verticais, sendo

assim cada solucao vertical identifica uma industria. [6]

Permite a cada organizacao gerir, sincronizar e coordenar as suas vendas, marketing

e servicos a clientes em todos os canais de comunicacao e em pontos de contacto

como a Web, o call-center, vendas e servicos no terreno e canais de revenda. O

que faz com que contribua para um aumento da produtividade das organizacoes,

melhoria da satisfacao do cliente e a maximizacao das receitas.

O Siebel faculta tambem a gestao de actividades e informacao dos clientes atraves do

e-mail, telefone, fax, Web ou outro metodo de comunicacao. A informacao encontra-

se sincronizada num unico repositorio central de informacao baseado numa unica

Base de Dados com um conjunto unico de ferramentas e uma arquitectura unica.

Esta aplicacao estende as solucoes CRM a todas as pessoas aos empregados duma

empresa, a parceiros da organizacao e a clientes da organizacao.


Sobre cada solucao vertical, existem solucoes ja desenvolvidas que permitem a uti-

lizacao imediata desta, por parte das organizacoes. Estas solucoes sao designadas

solucoes out of the box. Mas, de um forma natural, estas solucoes necessitam de

alteracoes para que correspondam as necessidades de cada organizacao. Existem

tambem solucoes horizontais que sao comuns a muitas das solucoes verticais, como

por exemplo solucoes de Vendas, Call-Center.

De um modo abstracto, a arquitectura do Siebel 3.1 consiste numa base de dados

e um sistema de ficheiros, onde sao guardados os dados de negocio. Fazem ainda

parte, um conjunto de servidores que gerem a informacao e que fornecem variados

servicos a clientes Web que acedem aos dados.

Figura 3.1: Siebel Life Sciences - Siebel Operating Architecture

Observando a arquitectura logica do Siebel 3.2, e possıvel ver que esta composta

por varios componentes. De seguida sao explicado de um modo breve os varios

componentes.

• Web Server: Identifica e encaminha os pedidos de Siebel para o Siebel Server.

Fornece ainda, as paginas HTML da aplicacao completas para o browser

cliente).

• Siebel Web Server Extension (SWSE): E uma extensao do Web Server,

que reconhece os URLs com pedidos Siebel. Encaminha os pedidos Siebel para

os componentes correctos do Siebel Server.


• Image Cache: E um componente do Siebel, que reside no Siebel Server, que

reduz os carregamentos do Siebel Server e do sistema de ficheiros. Permite

ainda, o download paralelo de imagens e guarda as imagens publicadas para o

Web Server.

Figura 3.2: Arquitectura logica

• Gateway Server: E o componente mediador, trata-se do elo de ligacao e

unico ponto de acesso ao(s) Enterprise Server(s). Regista dinamicamente a

disponibilidade dos componentes com o Siebel Server. Delega funcoes baseando-

se nos componentes requeridos pelo SWSE. Guarda ainda as definicoes dos

componentes, parametros operacionais e informacao das ligacoes. Por ultimo,

direcciona os pedidos dos clientes para os respectivos componentes.

• Siebel Server: E no Siebel Server onde sao processados os pedidos prove-

nientes dos clientes Siebel. Controla os componentes do servidor que estao a

processar numa maquina. Obtem informacao de configuracao proveniente do

Siebel Gateway. E composto por varios componentess.

• Server Component: E um tipo de programa que executa uma tarefa es-

pecıfica, sobre um Siebel Server.

• Enterprise Server: Suporta o acesso de grupos de utilizadores a uma unica

base de dados, de modo a que toda a informacao seja partilhada por todos de


modo seguro. Permite uma administracao comum e central via Siebel Server

Manager. [7]

Componentes Internas

De seguida e descrito o modo de apresentacao da informacao ao utilizador e a ligacao

entre as diferentes entidades e camadas utilizadas pelo Siebel. Este diagrama 3.3

ilustra o modo de funcionamento e de apresentacao da informacao do Siebel:

Figura 3.3: Componentes internas de funcionamento do Siebel

A partir do diagrama anterior representado 3.3 pode-se observar a organizacao das

componentes do Siebel divididas pelas suas camadas e a forma como comunicam

entre elas. Note-se que uma aplicacao Siebel e constituıda por varios ecras (Screen),

um ecra por varias vistas (View), uma vista por varias applets e uma Applet por

varios controlos (List Columns).

No nıvel User Interface, cada vista esta ligada a um Business Object que contem

varios Business Components, onde cada um destes, e composto por varios campos

(Field). Sao estes campos que contem a informacao que esta mapeada em colunas

de uma ou mais tabelas. Sao estas tabelas que fornecem a informacao aos Business

Components.

Os Business Components sao o meio que o Siebel tem para aceder a informacao

da Base de Dados, uma vez que estes sao constituıdos por um ou mais campos. Os

campos mapeiam directamente as colunas e tabelas da Base de Dados e em ultima

analise com o repositorio onde se encontra a informacao.


Modelacao e Configuracao

Para modelar a aplicacao e necessaria uma ferramenta, o Siebel Tools 3.4. E no

Siebel Tools onde e feita toda a configuracao, como por exemplo, a criacao de novos

Business Objects, Business Components, Applets, Views, Screens, etc, de modo a

optimizar a aplicacao as necessidades do cliente. E no Siebel Tools que se criam

as applets que irao compor a aplicacao, e a respectiva disposicao da informacao.

O Siebel Tools e um ambiente integrado para configurar todos os aspectos de uma

aplicacao Siebel, de modo a que com uma unica configuracao, a aplicacao suporte

varias lınguas, tenha actualizacoes automaticas para futuras versoes do Siebel e que

a sua manutencao seja facilitada.

Figura 3.4: Siebel Tools

A navegacao no Siebel Tools, e feita principalmente atraves de duas vertentes. Uma

delas e atraves do Object Manager, que utiliza uma estrutura semelhante a uma

arvore hierarquica, semelhante a do Microsoft Windows Explorer, que permite que

o utilizador tenha acesso a todos os tipos de objectos armazenados no repositorio

do Siebel. A segunda vertente, o Object List Editor, mostra os objectos individuais

no repositorio Siebel. Ainda na segunda vertente e possıvel definir as caracterısticas

dos objectos assim como definir propriedades do comportamento dos mesmos. Por

exemplo, se o objectivo for, definir uma applet que apresente os dados ordenados de


algum modo, basta definir a sort spefication da applet, caso seja necessario restringir

os dados apresentados, e possıvel definir uma search spefication. Por vezes, alguns

objectos tem um comportamento muito especıfico, o qual nao e possıvel definir nas

suas propriedades. Para tal e muito comum recorrer a programacao desses mesmos

comportamentos. A linguagem de programacao utilizada no Siebel Tools e o eScript,

muito semelhante a VB Script.

O Siebel Client representado na figura 3.5 e a aplicacao resultante das alteracoes

elaboradas no Siebel Tools. Nesta aplicacao o utilizador tem a capacidade de fazer

algumas alteracoes ao nıvel de configuracao, mas a sua principal funcao e aceder a

toda a informacao dos seus clientes finais, tendo a possibilidade de adicionar, apagar

e modificar essa informacao. Pode ainda fazer pesquisas sobre os dados presentes

na base de dados e ainda tem a possibilidade de gerar Reports.

Figura 3.5: Siebel Client

3.3.2 Actuate Report

O Actuate e.Report Designer Professional 3.6 e um meio de desenvolvimento bas-

tante potente, onde e possıvel criar relatorios (Reports) altamente flexıveis, para

qualquer aplicacao web-enabled. Neste caso, os relatorios sao gerados a partir do

Siebel. Com a utilizacao do Actuate e.Report Designer Professional, as equipas


de desenvolvimento podem criar rapidamente relatorios, desenhos, graficos ou es-

tatısticas provenientes de qualquer fonte de dados. O relatorio pode ser gerado em

qualquer formato e a disposicao dos seus conteudos pode ser apresentada em qual-

quer esquema concebıvel, nao importa o quao complexa graficamente.

Ha ainda a possibilidade de exportar o relatorio para outros ambientes, como por

exemplo, para o formato PDF, ou por exemplo caso o relatorio se trate de uma

tabela, ha a possibilidade de ser exportado para Excel, ou caso se trate de um doc-

umento de texto, podera ser exportado para Word, de modo a ser editado.

A aplicacao Actuate Report divide-se em duas grandes areas. Numa temos a es-

trutura hierarquica dos objectos presentes no nosso relatorio, como por exemplo

os DataStreams, que sao os objectos que dao acesso aos dados provenientes do

Siebel. Ha ainda uma grande variedade de objectos como campos de texto, que

serao preenchidos com dados provenientes dos DataStreams, labels, objectos de or-

denacao de dados, objectos que permitem que os dados sejam agrupados segundo

chaves escolhidas pela utilizador, etc. A outra area e a de desenho, onde os ob-

jectos sao dispostos da forma desejada. E nesta area que sao definidas todas as

caracterısticas do comportamento que cada objecto ira ter, como por exemplo a sua

cor, largura da linha, tipo de letra, posicao, alinhamento do texto, distancia das

margens, etc.

3.4 Metodologia Utilizada

Este projecto utiliza a metodologia Sarbanes Oxley (SOX) compliant, adoptada in-

ternacionalmente pelo cliente. Esta metodologia baseia-se numa lei (SOX), cujo

objectivo e aperfeicoar os controlos financeiros das empresas, a fim de evitar que

acontecam desvios e prejuızos para as mesmas. A lei visa garantir a transparencia

na gestao financeira das organizacoes, credibilidade na contabilidade, auditoria e

a seguranca das informacoes para que sejam realmente confiaveis, evitando assim

fraudes, fuga de capitais, etc.

Neste projecto a metodologia escolhida (processo em espiral) e composta por um

processo de cinco fases principais 3.7. Neste caso particular, a fase da formacao an-

tecedeu o processo das cinco fases principais. Por ordem, surgem as seguintes fases,

Formacao, Analise, Desenvolvimento, Testes, Documentacao e Apoio Pos-Producao.

De seguida e apresentada uma pequena descricao de cada uma das fases do processo.

[8]


Figura 3.6: Actuate e.Report Designer Professional

Figura 3.7: Fases do projecto

3.4.1 Formacao

Foi a primeira fase do estagio. Nesta fase foram adquiridas as competencias tecnicas

sobre a plataforma Siebel, assim como o Modelo de Dados e metodologias de tra-

balho. A formacao consistiu na leitura da bibliografia recomendada, neste caso, dos

tres volumes Siebel 7 Essentials, Students Guide e na resolucao de alguns exercıcios

presentes em ”Siebel 7 Essentials, Labs”, onde foram compreendidos os fundamen-

tos da ferramenta, a sua arquitectura, o seu publico alvo, o seu funcionamento, a

forma de disponibilizacao de informacao, metodo de instalacao e configuracao, entre

outros assuntos.


3.4.2 Analise

Na fase de analise foi feito o levantamento de requisitos de negocio, definiu-se do

scope do projecto, onde foi feita uma analise do impacto dos novos requisitos. Apos

serem conhecidos todos os requisitos, cada chefe de equipa estimou o numero de

dias que cada requisito necessitava para ser desenvolvido, assim como a respectiva

complexidade e prioridade. Com os requisitos todos estimados, cada chefe de equipa

procedeu a sua distribuicao pelos elementos da respectiva equipa.

3.4.3 Desenvolvimento

E a maior fase do processo e basicamente e a fase onde os requisitos sao imple-

mentados. Nesta fase, e com o trabalho previamente distribuıdo, cada membro e

responsavel por desenvolver os requisitos que lhe foram atribuidos inicialmente. To-

dos os requisitos, apesar de diferentes, cada um com a sua informacao, tem um

processo de elaboracao semelhante. Este processo, foi uniformizado e centralizado

de forma a manter organizada toda a informacao referente ao desenvolvimento dos

requisitos de cada release.

Neste projecto existem varios ambientes de trabalho, cada um com um objectivo

bem especıfico. Estes ambientes sao semelhantes, no entanto a medida em que se

avanca nas fases de desenvolvimento do projecto, o grau de importancia dos seus

dados vai aumentando e o seu acesso vai sendo cada vez mais restrito.

Durante a fase de desenvolvimento todo o trabalho decorre num ambiente de De-

senvolvimento (DEV) onde sao possıveis fazer todas as alteracoes, nao ha dados

importantes, e possıvel fazer qualquer tipo de testes. Apos ter sido desenvolvido um

requisito, e comum testar as alteracoes em DEV, de modo a ver se o resultado do

requisito e o esperado. Na fase de testes, antes da aplicacao ser testada pelo cliente

num ambiente proprio de testes, UAT (User Acceptance Tests), toda a aplicacao

ainda e testada pela equipa de desenvolvimento num ambiente chamado SIT (Sys-

tem Integrated Test). Antes de passar para o ambiente de Producao (PROD), onde

ja estao presentes os dados reais de negocio, a aplicacao ainda passa por outro am-

biente, designada por ambiente de Training (TRA). Este ambiente, contem copias

dos dados reais, e serve para que seja possıvel, por parte do cliente, dar formacao

sobre a nova aplicacao aos seus colaboradores.

Ainda em relacao ao ambiente de PROD, existe uma area onde apenas a equipa

de desenvolvimento tem acesso. E nessa area que e mantida toda a informacao ref-

erente aos requisitos. Como acima foi referido, todos os requisitos tem um processo


de elaboracao semalhante, e que segue os seguintes passos:

• Ler a descricao, objectivo e comportamento esperado do requisito

• Ver na aplicacao final, o que necessita de ser alterado

• Fazer check-out do(s) projecto(s), do servidor, necessario(s) alterar, para a

elaboracao do requisito. Fazer check-out de um projecto, nao e mais do que,

reescrever localmente o projecto com uma copia do mesmo, proveniente do

servidor. Ao fazer check-out de um projecto, o mesmo fica bloqueado no servi-

dor, ou seja, enquanto o projecto nao for libertado, mais nenhum utilizador o

pode utilizar.

• Fazer SIF (Siebel Import File) de check-out de cada projecto necessario para

elaborar a alteracao, para no caso de algo correr mal, ser possıvel repor o pro-

jecto sem as alteracoes feitas. O SIF e um ficheiro que guarda as definicoes dos

objectos de Siebel e e usado para importar e exportar definicoes de objectos.

• Fazer as alteracoes necessarias nos projectos, de modo elaborar o requisito,

compilar os projectos alterados e testar com base de dados local

Figura 3.8: Ambiente de Producao - Informacao de um requisito


• Caso o resultado seja o esperado, fazer check-in dos projectos para o servidor,

caso seja necessario corrigir alguma coisa, refazer, recompilar e voltar a testar.

Ao fazer check-in de um projecto, uma copia do projecto e enviada para o

servidor e o projecto e desbloqueado no servidor.

• Fazer SIF de check-in

• Actualizar a informacao do requisito, com datas de inıcio e fim da sua elab-

oracao, descricao da alteracao, duracao da alteracao, etc.

Toda a informacao relativa aos requisitos e guardada numa base de dados e e possıvel

ser actualizada atraves do ambiente PROD 3.8. De seguida e possıvel ver como e

que este ambiente esta estruturado.

Na figura 3.8 estao assinaladas 4 grupos de informacao. Na figura 3.9 e possıvel ver a

informacao geral do requisito, como o seu codigo, uma breve descricao do problema,

o estado em que se encontra o requisito, etc.

Figura 3.9: Ambiente de Producao - Informacao geral de um requisito

Na figura 3.10 temos a informacao detalhada do requisito. Aqui e possıvel ver quem

criou o requisito, isto e, quem encontrou uma erro ou falha e achou que era necessaria

uma alteracao, qual seria o comportamento esperado apos a correccao do erro, a que

modulo faz parte o requisito, existe tambem uma area para comentarios adicionais,

o numero de dias estimados para a resolucao do problema, etc.

Figura 3.10: Ambiente de Producao - Informacao detalhada de um requisito

As figuras 3.11 e 3.12 mostram a informacao relativa ao desenvolvimento do requi-

sito. A figura 3.11, mostra a informacao relativa a elaboracao do requisito, tanto a


informacao estimada, como a real, como por exemplo, a data de inıcio, fim e duracao

em dias do requisito. Na figura 3.12, e possıvel ver quem esta a desenvolver e quem ja

desenvolveu alguma coisa para o requisito, e caso alguem ja tenha resolvido alguma

coisa, existe uma area de insercao de comentarios, onde cada utilizador deve registar

as alteracoes que foram feitas na aplicacao no sentido de resolver este requisito.

Figura 3.11: Informacao de desenvolvimento de um requisito 1

Figura 3.12: Informacao de desenvolvimento de um requisito 2

3.4.4 Testes

Apos a fase de desenvolvimento, tem lugar a fase de teste. Esta fase e constituıda

por pequenas sub-fases. As sub-fases de teste podem ser dois tipos, de SIT (System

Integrated Test), em que os testes sao feitos por membros da equipa do projecto,

ou de UAT (User Acceptance Test), que sao testes feitos pelos utilizadores finais

da aplicacao. As fases de teste sao seguidas por fases de correccao de erros (Fix-

ing). Na figura 3.13 e possıvel ver as diversas fases que compoem a fase de Testes.

Quando um utilizador reporta um erro, regista a informacao no ambiente de PROD,

mudando o tipo do requisito para Test Problem Report.

Esta fase tem como objectivo principal garantir a qualidade do produto final atraves

da conformidade que a solucao apresenta face aos requisitos iniciais do projecto. E

executada apenas no final da fase de implementacao, mas e planeada desde o inıcio

do projecto, de modo a assegurar uma correcta gestao de requisitos ao longo do

projecto. Esta gestao de requisitos e necessaria pois, por muito exaustiva que seja a

fase de analise, ha sempre mudancas e alteracoes de requisitos, e muitas vezes essas


mudancas sao essenciais para o sucesso do mesmo.

Figura 3.13: Composicao da fase de Testes

3.4.5 Documentacao

Com o fim da fase de testes, a aplicacao esta pronta a ir para Producao. Esta fase

tem como objectivo principal elaborar toda a documentacao necessaria. Seja docu-

mentacao tecnica, funcional e ate mesmo manuais de utilizador. O objectivo e gerir

a adaptacao dos utilizadores a nova aplicacao, como sendo um dos factores crıticos

de sucesso de uma solucao de CRM.

3.4.6 Apoio Pos-Producao

Sendo a fase final do processo, esta fase permite dar apoio apos o lancamento do

produto para o mercado. E uma fase de rapida e eficaz resolucao de problemas que

possam surgir apos lancamento de uma release da plataforma CRM. Esta e realmente

a fase crıtica do projecto, ja que e nesta fase que se assegura a continuidade dos

trabalhos, sendo necessarias varias actualizacoes, assim como alguns testes, de forma

a provar o bom funcionamento de todos os modulos instalados. Apos a passagem a

producao devera ser previsto um perıodo de verificacao/monitorizacao em Producao

onde os utilizadores deverao reportar todos os defeitos encontrados, para futuras

correccoes.

Capıtulo 4

Trabalho Desenvolvido

Durante o estagio, houve a oportunidade de participar nas diversas fases do desen-

volvimento do projecto, o que proporcionou a execucao de tarefas relativas a varias

fases do projecto. Na fase de Desenvolvimento, foram desenvolvidos os requisitos

definidos na fase de analise. De seguida, na fases de Testes, foram reportados alguns

erros que foram corrigidos nas fases seguintes. Durante a fase de documentacao,

foram elaborados o Manual de Utilizador e documentacao para todos os requisitos

desenvolvidos. Na fase de Apoio Pos-Producao ainda surgiram alguns erros que

foram corrigidos, o que fez com que surgisse a necessidade de lancar novas versoes

da aplicacao final, desta vez com os erros todos corrigidos.

4.1 Actividades desenvolvidas

Como ja foi referido, quando o estagio teve inıcio, este projecto ja vinha a ser desen-

volvido ha algum tempo. Sendo o tıtulo do projecto de estagio ”Optimizacao/Evolucao

de uma plataforma CRM”, o trabalho desenvolvido assentou essencialmente em op-

timizar e evoluir a aplicacao que ja estava desenvolvida.

Durante o projecto de estagio, foram desenvolvidos diversos requisitos, no entanto e

tendo em conta a tabela da figura A.1, e possıvel agrupar os requisitos desenvolvidos

em tres grandes grupos. O primeiro grupo seria dos requisitos relativos a todo o tra-

balho desenvolvido referente a ”Email Templates”, o segundo grande grupo relativo

a ”Reports”e o terceiro e ultimo relativo a todos os requisitos de Siebel propriamente

ditos, ou seja, todos os requisitos que foram desenvolvidos utilizando a ferramenta

Siebel Tools.

Neste projecto, os requisitos podem passar por 3 estados. Estes estados variam

com o tipo de alteracao ou correccao necessaria e a fase em que esta e reportada

a equipa de desenvolvimento. Os requisitos definidos durante a fase de analise,

20

Capıtulo 4. Trabalho Desenvolvido 21

que fazem parte do scope inicial do projecto, e que foram desenvolvidos na fase de

desenvolvimento designam-se por Change Requests (CR). Os requisitos que foram

sendo reportados e corrigidos durante a fase de testes, designam-se por Test Problem

Report (TPR). Por ultimo existem os Service Requests (SR), que foram requisitos

corrigidos durante a fase de producao. Caso um CR seja desenvolvido de forma

incorrecta, na fase de testes e reportado como um TPR. Se tiver sido corrigido de

forma tambem incorrecta e apenas detectado ja na fase de producao, entao reporta-

se o erro na forma de um SR. Ou seja, o mesmo requisito pode passar pelos 3 estados.

De seguida sao descritos, os 3 grupos de requisitos desenvolvidos ao longo do estagio.

4.1.1 Email Templates

Como ja foi referido, este projecto trata de gerir eventos e todas as suas actividades

inerentes. Umas das questoes essenciais trata-se da inscricao dos particpantes nos

respectivos eventos. Em relacao ao registo de participantes num dado evento, este

pode ter varios estados, como por exemplo, confirmado, cancelado, pendente, convi-

dado, etc. Quando ha uma alteracao no estado do registo de um participante, ou seja,

quando o estado do registo e modificado, e enviado um email para o participante,

informando-o da actualizacao do estado do seu registo, bem como a informacao rel-

evante do evento em que este esta inscrito. O email enviado e respectivo conteudo,

difere consoante o novo estado do registo do participante e tipo de participante. Por

exemplo, se o estado do registo de um participante do tipo Observer e alterado para

”Convidado”, no email que o participante ira receber 4.1 nao havera dados relativos

ao pagamento da inscricao do participante, ja que este esta apenas a ser convidado

para um evento, mas se o estado for alterado para ”Confirmado”, entao este email

tera informacao relativa ao pagamento da sua inscricao.

Para que o envio dos emails seja automatico, houve varias tarefas intermedias. Para

estruturar os email templates, 4.2 o primeiro passo foi, organizar no Siebel Tools os

campos que guardavam a informacao relativa aos participantes. Esses campos fazem

parte do business component dos participantes (Attendees) e estao mapeados em col-

unas de uma ou mais tabelas. O segundo passo, e de modo a preencher os emails

(ficheiros HTML) com informacao dos participantes, proveniente do siebel, basta

colocar os nomes dos campos entre parenteses rectos no codigo HTML. Neste pro-

jecto foram feitos cerca de 50 email templates para diferentes tipos de participantes,

diferentes estados de registo e para diferentes organizacoes, como por exemplo, Es-

tados Unidos da America e alguns paıses da America Latina.

Para que um email seja enviado quando o estado do registo do participante e alter-


Figura 4.1: Email Template - Observer Invite

ado, de um modo abstracto, e necessario ter um trigger e um workflow. Um workflow

e uma sequencia de passos necessarios para a execucao de uma determinada accao,

neste caso, o envio dos email. O trigger e o que desponta a execucao do workflow,

neste caso, e a alteracao do estado do registo do participante.

De uma forma mais detalhada, foram varias as tarefas elaboradas ate que o en-

vio automatico de emails se processasse. A primeira tarefa a ser elaborada foi a

estruturacao dos ficheiros HTML (emails a serem enviados). De seguida foram cri-

ados os Workflow Processes utilizando a ferramenta Siebel Tools. No Siebel Tools

nao so e criado o objecto Workflow, mas como se definem o esquema visual 4.3 do

Workflow e os argumentos de input e output de cada um dos seus objectos internos.

Os passos seguintes sao elaborados ao nıvel da aplicacao. Para cada Workflow e

criada uma accao(Action), cujo argumento e um processo que tem o nome do Work-

flow Process criado no Siebel Tools. A accao criada, e associada a uma Workflow

Policy, que para que seja activada, todas as suas condicoes terao de ser aceites. No

caso da figura 4.4, para que o email seja enviado, o participante tera de pertencer

a organizacao dos Estados Unidos (Event Org Id = 1-1JZ-1), tem de tratar de um


Figura 4.2: Email Template - Esquema

Figura 4.3: Siebel Tools - Workflow Process

registo num evento, o novo estado tera de ser ”Confirmado”, o participante tera de

ser do tipo ”Participant”e tera de existir, ou seja o registo tera de existir na base

de dados. Se tudo isto se verificar, entao um email sera enviado para o respectivo

participante. Para cada combinacao entre tipo de participante e estado do registo,

foi definido uma Workflow Policy e respectivas condicoes, uma accao (Action) e

respectivo argumento e ainda o Workflow no Siebel Tools.

4.1.2 Reports

E frequente, na empresa cliente, surgirem situacoes onde sao necessarios relatorios,

etiquetas, folhas de registos, listagens de participantes para um dado evento, reci-

bos, etc. Tendo como por exemplo o caso em que vai decorrer uma conferencia.

A entrada da sala onde ira decorrer a conferencia, encontra-se uma pessoa da or-


Figura 4.4: Siebel Client - Workflow Process

ganizacao, com uma listagem dos nomes dos participantes inscritos na conferencia,

para que estes confirmem a sua inscricao. Assim que a sua inscricao e confirmada, e

entregue um cartao com o respectivo nome para que o participante seja facilmente

identificado durante a conferencia. Cada participante tem no seu lugar, um cartao

dobrado em cima da mesa, para que todos os outros participantes consigam ver ao

longe o seu nome.

Todos estes documentos, quer sejam folhas de inscricao, cartoes com os nomes, iden-

tificadores ou ate mesmo recibos que sejam necessarios emitir, etc, todos eles sao

Reports modelados utilizando a ferramenta, Actuate Report. Para muitos dos req-

uisitos desenvolvidos durante o estagio, a sua resolucao baseou-se na elaboracao de

Reports.

Para elaborar um Report de Actuate, em quase todos os casos era fornecido por

parte do cliente, um template base. Este template podia ser um ficheiro .pdf ou um

ficheiro Word. Com este template era possıvel saber qual a informacao necessaria no

Report e qual a disposicao da mesma. Depois de analisado o template, e necessario

ir ao Siebel Tools criar um report com os campos do Siebel pedidos no template.


Quando o report e criado no Siebel Tools, apenas se cria um ficheiro .rol (Report

Object Library) e nao o report propriamente dito.

No Actuate Report, e criado entao um ficheiro .rod (Report Object Designer), onde

e feita a modelacao do report. Aqui e adicionado o .rol gerado. Com a associacao

deste ficheiro, e possıvel mapear os campos previamente adicionados no Siebel Tools

na area de desenho da forma desejada. Nos reports mais elaborados, onde o compor-

tamento do report e algo mais complexo, nao basta adicionar os campos ao report.

Ha situacoes onde e necessario programar. A linguagem de programacao usada foi

Actuate VB Script. Quando o report esta pronto, e gerado um ficheiro .rox (Report

Object Executable) que e transferido para o servidor Actuate. Neste momento o

report esta pronto a ser executado. Para tal, basta na aplicacao gerar o report e o

.rox sera executado.

4.1.3 Requisitos Siebel

Ao longo do estagio, outra grande parte do trabalho desenvolvido foi relativo ao

desenvolvimento de requisitos Siebel. Estes requisitos (Change Requests) tanto po-

dem ser, implementar uma nova funcionalidade na aplicacao, ou ate mesmo corrigir,

optimizar algo que ja tinha sido pedido antes. Durante o estagio foram feitos varios

requisitos de Siebel, como e possıvel ver no anexo A.1.

Os primeiros requisitos desenvolvidos, como por exemplo, os requisitos 1-27XIX1

e 1-27XIWB, que estavam planeados para dia 16 de Outubro de 2007, consistiram

em pequenas alteracoes. O objectivo era mapear um campo ja criado numa ap-

plet dos planos de eventos e ordenar os campos das applet form, respectivamente.

Assim como houve requisitos simples, houve outros tambem algo elaborados, onde

foi necessario mais tempo para serem desenvolvidos, como por exemplo o requisito

1-27XF19, planeado para dia 30 de Novembro de 2007, cujo objectivo era, ter na

applet dos participantes 4.5 um botao (Send Reminder Email button) que ao ser

pressionado, era enviado um email (Reminder Email) para cada participante com

estado de registo confirmado, de modo a relembra-los que estavam inscritos no dito

evento.

Quando o botao ”Send Reminder Email”e pressionado, e enviado um email para

todos os participantes com estado de registo confirmado e automaticamente e adi-

cionada uma flag no campo ”Reminder Sent”, indicando que ja foi enviado um

email de ”Reminder”para os respectivos participantes. O email apenas e enviado

quando houver participantes confirmados, que nao tenham o campo ”Reminder


Figura 4.5: Applet dos participantes de um evento

Sent”marcado. Tambem e possıvel enviar outro email a um participante que ja

o tenha recebido antes. Para isso basta, desmarcar o campo ”Reminder Sent”desse

participante e voltar a pressionar o botao.

Outro requisito de Siebel algo elaborado que foi desenvolvido, consistiu em criar

tres botoes, ao nıvel da applet das viagens dos participantes, que, ao serem pres-

sionados, devolvessem viagens. Na applet da figura 4.6 e possıvel verificar os 3

botoes para devolver viagens. O primeiro botao (Retrieve All) pede viagens para

todos os participantes, o segundo botao (Retrieve One) devolve viagens para o par-

ticipante que tiver seleccionado no momento em que e feito o pedido e o ultimo

botao (Retrieve Partial) devolve viagens para todos os participantes que tiverem o

campo ”Pick Attendee”marcado. Pressionando um dos tres botoes, e desencadeado

um processo que envolve mais dois sistemas, o WebMethods e o Sabre. O Sabre

e um sistema associado a uma agencia de viagens com o objectivo de de efectuar

procedimentos relativos a reserva de viagens, o WebMethods e uma plataforma de

integracao que faz a interligacao entre os sistemas Siebel e o Sabre.

Figura 4.6: Applet Retrieve PNR

Foram elaborados muitos outros requisitos Siebel, como e possıvel ver no anexo A.1,

mas acabaram por nao ser expostos em detalhe. Apenas foram explicados os difer-

entes tipos de requisitos elaborados durante o projecto de estagio, e foram dados

alguns exemplos.

Capıtulo 5

Conclusao

Neste capıtulo sao apresentadas as conclusoes relativas ao trabalho desenvolvido ao

longo do projecto de estagio, bem como, o trabalho a ser desenvolvido no futuro.

5.1 Trabalho Desenvolvido

Ao longo do projecto de estagio, em diversas fases do seu desenvolvimento, foi

possıvel aplicar alguns dos conhecimentos adquiridos durante a licenciatura e de

certo modo, amplia-los. Tive a oportunidade de passar por todas as fases do desen-

volvimento do projecto o que me deu uma ideia mais proxima da realidade. Desde

a analise de requisitos, ao desenvolvimento dos mesmos, passando pelas fases de

testes, documentacao e apoio pos-producao.

Para alem de trabalhar com a ferramenta Siebel, aprendi tambem a trabalhar com

a ferramenta Actuate eReport Designer Professional, ferramenta esta que permite a

elaboracao de qualquer tipo de relatorio. Em alguns dos relatorios elaborados, foi

necessario recorrer a linguagem de programacao de VB Script, com a qual nunca

tinha programado.

Tratando-se de uma aplicacao cujo o objectivo e gerir eventos e toda a sua in-

formacao, a quantidade de dados a manter, gerir e actualizar torna-se bastante

grande. Todos estes dados estao guardados em bases de dados Oracle. Durante

todo o estagio foi frequente a necessidade de utilizar a linguagem SQL.

5.2 Trabalho Futuro

Tratando-se de um trabalho de continuidade, isto e, o projecto nao tem prevista

uma data de fim anunciada. Trata-se de um projecto em constantes actualizacoes e

modificacoes, que vai sucessivamente tendo varias releases ao longo do tempo, daı o

27

Capıtulo 5. Conclusao 28

tıtulo do projecto de estagio ser ”Optimizacao/Evolucao de uma plataforma CRM”.

Visto ser um projecto internacional, dividido em varios modulos, cada um relativo a

uma area de negocio, e frequente a entrada de novos paıses no projecto, fazendo com

que cada um destes utilize apenas os modulos necessarios ao seu negocio. Quando

este estagio finalizou, o modulo de ProfEd apenas era utilizado por franchises dos

Estados Unidos da America e da America Latina. Na proxima release ira tambem

ser utilizado por franchises de paıses europeus como por exemplo a Alemanha. Seria

interessante ter a aplicacao desenvolvida de maneira a que, cada vez que entrasse um

paıs novo, a utilizacao da aplicacao por parte deste, fosse imediata. Neste momento

e da forma como esta a ser desenvolvida, cada vez que entra um paıs/organizacao

nova, ha ainda alteracoes a fazer, como por exemplo, a traducao de alguns textos,

listas de valores, comentarios, tıtulos, etc.

Como se trata de um projecto vasto, em que a aplicacao e utilizada na Europa,

Estados Unidos da America, America Latina e continente Africano, seria uma van-

tagem, e de modo a minimizar as alteracoes da linguagem, chegar a um acordo e

utilizar uma ou duas lınguas na aplicacao para todos os paıses.

5.3 Analise Crıtica

Tratou-se de uma experiencia muito enriquecedora, tanto a nıvel pessoal como a

nıvel profissional. Apesar de na faculdade ter feito parte de varios grupos de tra-

balho, nunca tinha tido a oportunidade de poder trabalhar numa equipa numerosa,

com cerca de 30 colaboradores.

Em termos pessoais, este estagio deu-me a conhecer a realidade de trabalhar num

projecto para o exterior, isto e, para o mundo profissional, onde existe um cliente

que espera ter uma aplicacao com certas funcionalidades pronta a utilizar numa de-

terminada data, chefes de equipa, ou seja, alguem de um nıvel superior, que por um

lado nos apoia, mas por outro, e a pessoa a quem temos de mostrar o nosso trabalho

desenvolvido e onde e necessario termos sempre presente que fazemos parte de uma

equipa, e que em cada versao da aplicacao desenvolvida, e o nome da equipa de

desenvolvimento e da entidade empregadora que esta em risco.

Outro ponto importante, foi o facto de ter trabalhado com a ferramenta Siebel,

que, e nos dias de hoje a ferramenta CRM mais utilizada em todo o mundo, com a

qual nunca tinha trabalhado antes.

Apendice A

Change Requests

Na tabela da figura A.1 e possıvel verificar o plano de desenvolvimento de todos os

requisitos elaborados (Change Requests) durante fase de desenvolvimento.

Pela tabela e possıvel verificar o numero de cada requisito (Change Request), bem

como as datas planeadas para o inıcio e fim da sua implementacao. Cada requisito

e composto ainda por uma pequena descricao e pelas suas datas reais de imple-

mentacao.

29

Apendice A. Change Requests 30

Figura A.1: Lista de Requisitos desenvolvidos

Apendice B

Test Problem Reports

A fase de Testes, foi composta por pequenas fases de testes e respectivas correccoes

dos erros que foram sendo encontrados. Estes erros, foram reportados como sendo

Test Problem Reports (TPR). Cada erro destes, e tratado do mesmo modo que um

Change Requests, apenas foram identificados em fases distintas do projecto.

Na tabela abaixo B.1 e apresentado o plano dos TPRs corrigidos durante as fases

de teste.

31

Apendice B. Test Problem Reports 32

Figura B.1: Lista de Erros corrigidos

Bibliografia

[1] http://www.altran-cis.pt/

[2] http://intranet.altran-cis.pt/, 2006

[3] http://www.ptsi.pt/ptsi/canais/solucoes/gestaoclientes/solucoescrm.htm

[4] http://pt.wikipedia.org/wiki/Customerrelationshipmanagement

[5] Siebel Labs Essentials - vols. I, II e III

[6] http://www.oracle.com/siebel/index.html

[7] Bookshelf for Siebel eBusiness Applications Version 7.7 - November 2004 Edition

[8] http://www.krollnews.com.br/artigos/042006artigo01.htm.

33

faculdade de ci^encias - repositorio.ul.ptrepositorio.ul.pt/bitstream/10451/4322/1/ulfc... ·...

Documents