Optimização / Evolução de uma plataforma CRM

(1)

Universidade de Lisboa

Faculdade de Ciˆencias

Departamento de Inform´

atica

Optimiza¸

c˜

ao/Evolu¸

c˜

ao de uma plataforma CRM

Ant´

onio Miguel Garrett Vieira

Mestrado em Engenharia Inform´

atica

(2)

(3)

Universidade de Lisboa

Faculdade de Ciˆencias

Departamento de Inform´

atica

Optimiza¸

c˜

ao/Evolu¸

c˜

ao de uma plataforma CRM

Ant´

onio Miguel Garrett Vieira

EST ´

AGIO

Projecto orientado pelo Prof. Dr. Andr´e Falc˜ao e co-orientado por Dr. Rui Rolo

Mestrado em Engenharia Inform´

atica

(4)

(5)

Declara¸

c˜

ao

António Miguel Garrett Vieira, aluno no 29075 da Faculdade de Ciências da Uni-versidade de Lisboa, declara ceder os seus direitos de cópia sobre o seu Relatório de Projecto em Engenharia Informática, intitulado ”Optimiza¸cão/Evolu¸cão de uma plataforma CRM”, realizado no ano lectivo de 2007/2008 à Faculdade de Ciências da Universidade de Lisboa para o efeito de arquivo e consulta nas suas bibliotecas e publica¸cão do mesmo em formato electrónico na Internet.

FCUL, 30 de Setembro de 2008

Dr. Rui Rolo, supervisor do projecto de António Miguel Garrett Vieira, aluno da Faculdade de Ciências da Universidade de Lisboa, declara concordar com a di-vulga¸cão do Relatório do Projecto em Engenharia Informática, intitulado ”Opti-miza¸cão/Evolu¸cão de uma plataforma CRM”.

(6)

(7)

Resumo

A forma como as organiza¸cões gerem a rela¸cão com os seus clientes é hoje recon-hecida como um factor determinante que contribui para aumentar o valor das em-presas. Assim, é importante conhecer as preferências dos clientes, os seus hábitos de compra, identificá-los e segmentá-los por múltiplos critérios de escolha para que a empresa lhes possa prestar um servi¸co de excelência em linha com as caracter´ısticas previamente identificadas. As pequenas empresas estão sempre ligadas às rela¸cões com os clientes: saber os seus nomes, conhecer as preferências e proporcionar o tipo de servi¸co amigável que os leva a voltar sempre. No entanto, à 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 gestão eficaz dessas rela¸cões com os clientes é essencial para a rentabilidade da empresa.

´

E poss´ıvel implementar uma estratégia CRM que permita ganhar vantagem com-petitiva através do conhecimento dos seus clientes, dos seus hábitos de consumo ou das suas necessidades e do valor que representam. O CRM ajuda o cliente a definir uma estratégia e a implementar sistemas que lhe permitam personalizar os seus esfor¸cos de Marketing, permitindo assim endere¸car correctamente a informa¸cão de forma mais rápida e económica e oferecer um servi¸co de qualidade apropriado a cada segmento. Este documento descreve os trabalhos realizados durante o projecto de estágio. Projecto este que foi desenvolvido para uma empresa da área farmacêutica e cujo objectivo é gerir a log´ıstica e todos os processos associados à gestão de even-tos. Todo o seu desenvolvimento foi feito utilizando a ferramenta Siebel, que é a ferramenta mais utilizada em todo o mundo, no que diz respeito ao desenvolvimento de aplica¸cões CRM.

PALAVRAS-CHAVE:

CRM, Evento, ProfEd, Siebel

(8)

(9)

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

(10)

(11)

Conte´

udo

Lista de Figuras viii

1 Introdu¸cão 1 1.1 Motiva¸cão . . . 1 1.2 Objectivos . . . 2 1.3 Organiza¸cão 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 Optimiza¸c˜ao/Evolu¸c˜ao de uma plataforma CRM 5 3.1 Customer Relationship Management (CRM) . . . 5

3.2 Arquitectura . . . 6 3.2.1 Solu¸cão Vertical . . . 6 3.2.2 Solu¸cão 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 Forma¸cão . . . 14 3.4.2 Análise . . . 15 3.4.3 Desenvolvimento . . . 15 3.4.4 Testes . . . 18 3.4.5 Documenta¸cão . . . 19 3.4.6 Apoio Pós-Produ¸cão . . . 19 4 Trabalho Desenvolvido 20 4.1 Actividades desenvolvidas . . . 20 4.1.1 Email Templates . . . 21 4.1.2 Reports . . . 23 v

(12)

4.1.3 Requisitos Siebel . . . 25

5 Conclus˜ao 27

5.1 Trabalho Desenvolvido . . . 27 5.2 Trabalho Futuro . . . 27 5.3 An´alise Cr´ıtica . . . 28

A Change Requests 29

B Test Problem Reports 31

(13)

(14)

Lista de Figuras

2.1 Planeamento do projecto de est´agio . . . 4

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

3.2 Arquitectura l´ogica . . . 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 Produ¸c˜ao - Informa¸c˜ao de um requisito . . . 16

3.9 Ambiente de Produ¸c˜ao - Informa¸c˜ao geral de um requisito . . . 17

3.10 Ambiente de Produ¸c˜ao - Informa¸c˜ao detalhada de um requisito . . . . 17

3.11 Informa¸c˜ao de desenvolvimento de um requisito 1 . . . 18

3.12 Informa¸c˜ao de desenvolvimento de um requisito 2 . . . 18

3.13 Composi¸c˜ao 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

(15)

(16)

Cap´ıtulo 1

Introdu¸

c˜

ao

O presente relatório tem como objectivo apresentar o trabalho realizado no projecto ”Optimiza¸cão/Evolu¸cão de uma plataforma CRM”na empresa Altran CIS, Altran Consulting & Information Services, enquadrado na disciplina de Projecto de Engen-haria Informática (PEI), no âmbito do Mestrado em Engenharia Informática (MEI) 2007/2008.

Este projecto foi desenvolvido para um cliente da indústria farmacêutica e visto ter exigido a confidencialidade no que diz respeito à sua identidade, deste ponto em diante será denominada por empresa cliente.

O projecto teve a dura¸cão de cerca de nove meses, nos quais se incluem a elab-ora¸cão deste relatório.

1.1 Motiva¸

c˜

ao

Na empresa cliente surgem com alguma frequência eventos. O tipo de eventos pode ser bastante diversificado, como por exemplo, conferências, forma¸cões, aulas de lab-oratório, apresenta¸cões de novos produtos que, eventualmente, serão lan¸cados no mercado, etc. De modo a promover um evento de forma organizada e eficaz, é necessário ter em conta vários aspectos e consequentemente, manter e gerir toda a sua informa¸cão. Estes aspectos, podem ir desde a gestão das salas, como por exemplo laboratórios, ou auditórios onde os eventos irão decorrer, gestão do registo dos participantes nos ditos eventos, gestão dos respectivos pagamentos e de toda a log´ıstica associada.

Visto se tratar de uma empresa de um grande grupo internacional, estabelecida em vários pa´ıses de diversos continentes, surgiu então, a necessidade de ter organi-zada de alguma forma, toda a informa¸cão relativa à organiza¸cão e gestão de eventos.

(17)

Cap´ıtulo 1. Introdu¸c˜ao 2

Foi então que, após exposi¸cão de várias ideias, problemas e solu¸cões, surgiu, há cerca de dois anos, o projecto ”Professional Education”, daqui em diante será designado por ProfEd. Trata-se de uma aplica¸cão bastante complexa e que agrupa os vários processos relativos a Gestão de Eventos.

Trata-se de uma aplica¸cão, que até agora apenas é usada por um cliente nos Estados Unidos da América.

1.2 Objectivos

Uma vez que o quando o estágio teve in´ıcio, o projecto de ProfEd já vinha a ser desenvolvido há algum tempo, os objectivos para o projecto de PEI foram desde a implementa¸cão de novas funcionalidades sobre a aplica¸cão já existente de acordo com os requisitos de negócio do cliente, assim como a execu¸cão e apoio dos testes à aplica¸cão, elabora¸cão de documenta¸cão e apoio pós-produ¸cão ao cliente.

1.3 Organiza¸

c˜

ao do documento

Este documento está organizado da seguinte forma. Após uma pequena introdu¸cão, é feito um enquadramento do projecto desenvolvido e uma breve descri¸cão da empresa de acolhimento e da empresa cliente. De seguida, são apresentadas as ferramentas utilizadas no desenvolvimento do projecto, bem como a metodologia usada na elab-ora¸cão do mesmo. Cada uma das fases do desenvolvimento do projecto é descrita e é explicado o conceito de Customer Relationship Management (CRM). Finalmente é descrito o trabalho desenvolvido ao longo do estágio. Relativamente ao trabalho desenvolvido, são dados alguns exemplos de requisitos desenvolvidos. Por último, é apresentada a conclusão de todo o projecto de estágio.

(18)

Cap´ıtulo 2

Enquadramento

Neste cap´ıtulo são descritas as duas empresas envolvidas, a institui¸cão de acolhi-mento e aquela para a qual o projecto foi desenvolvido, a empresa cliente. São ainda apresentadas as fases de desenvolvimento do projecto.

2.1 A Empresa de acolhimento

A Altran CIS, nasceu em 2006 da fusão 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 servi¸cos de Consultoria em Tecnologias de Informa¸cão (TI). A empresa, apesar de ter come¸cado a sua actividade nas áreas das TI, rapidamente diversificou os seus negócios, assumindo a responsabilidade em projectos de organiza¸cão, gestão 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 áreas 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 é um conjunto de empresas. O Brasil foi o primeiro ponto de expansão do grupo, através da abertura de escritórios locais.

Aproveitando a experiência acumulada da empresa e dos seus consultores, nasce a Altran CIS, desenvolvendo solu¸cões em diversas áreas, desde estudos estratégicos e planos directores de informática, até consultoria especializada nas áreas de sis-temas, bases de dados e seguran¸ca, passando inevitavelmente por todas as áreas ligadas ao desenvolvimento de aplica¸cões, desde os aspectos mais funcionais até à implementa¸cão final, garantindo sempre elevados padrões de qualidade.

(19)

tecnolo-Cap´ıtulo 2. Enquadramento 4

gia, potenciando assim a capacidade de mobilidade de competˆencias 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 área da saúde/farmacêutica. Estabelecida em mais de 50 pa´ıses, contém franchises em vários segmentos de negócio como cuidados de saúde, farmacêutica, dispositivos médicos de diagnóstico, etc. Aposta na diversidade de produtos de forma a aumentar a sua participa¸cão no mer-cado. Em rela¸cão aos cuidados de saúde, aposta em produtos de uso diário para todas as idades. Relativamente a dispositivos médicos de diagnóstico, produz dispos-itivos de esteriliza¸cão de material, material de cirurgia e de sutura¸cão, dispositivos de monitoriza¸cão sangu´ınea, etc.

Visto se tratar de um grande grupo internacional, há que ter sistemas de gestão de recursos humanos, material, factura¸cão, etc. Este projecto, incidiu numa aplica¸cão que visa ajudar a empresa cliente a gerir todos os processos inerentes à gestão de eventos.

Apesar de o conteúdo do projecto e da informa¸cão contida neste relatório não serem confidenciais, a empresa cliente prefere não 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 forma¸cão. Esta fase teve sensivelmente a dura¸cão de um mês e meio. De seguida e com dura¸cão similar, teve lugar a fase de Análise. Analisados todos os requisitos de negócio, surgiu a maior fase do projecto, com uma dura¸cão de cerca de quatro meses, o Desenvolvimento. De seguida teve lugar a fase de Testes e respectivas correçcões e a elabora¸cão de Documenta¸cão. Na imagem seguinte 2.1, é poss´ıvel ter uma melhor percep¸cão das fases do projecto bem como a respectiva dura¸cão.

(20)

Cap´ıtulo 3

Optimiza¸

c˜

ao/Evolu¸

c˜

ao de uma

plataforma CRM

Neste cap´ıtulo, é explicado o conceito de Customer Relationship Management ou CRM. São descritas ainda as solu¸cões vertical e horizontal bem como as ferramentas utilizadas ao longo do projecto para o desenvolvimento da aplica¸cão. Por último é 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 organiza¸cões se relacionam com os seus clientes, é 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 participa¸cão no mer-cado. Assim é importante conhecer as preferências dos clientes, os seus hábitos de compra, identificá-los e segmentá-los por múltiplos critérios de escolha para que a empresa lhes possa prestar um servi¸co de excelência em linha com as caracter´ısticas previamente identificadas. Desta forma não só se atinge o des´ıgnio da qualidade e consistência do servi¸co prestado ao Cliente como se criam oportunidades que em si geram mais valor para a empresa.[3]

O CRM é um sistema integrado de gestão com foco no cliente, constitu´ıdo por um conjunto de procedimentos/processos organizados e integrados num modelo de gestão de negócios. O seu objectivo principal é auxiliar as organiza¸cões a angariar e fidelizar clientes procurando atingir a sua satisfa¸cão total, através de uma melhor compreensão das suas necessidades e expectativas e forma¸cão de uma visão global dos ambientes de marketing.

(21)

Cap´ıtulo 3. Optimiza¸c˜ao/Evolu¸c˜ao de uma plataforma CRM 6

nica¸cão e vendas, bem como a gestão dos servi¸cos ao cliente. Os processos e sistemas de gestão de relacionamento com o cliente permitem que se tenha controlo e con-hecimento das informa¸cões sobre os clientes de maneira integrada, principalmente através do acompanhamento e registo de todas as interaçcões com o cliente, que podem ser consultadas e comunicadas a diversas partes da empresa que necessitem desta informa¸cão para guiar as tomadas de decisões. Uma das actividades do CRM implica registar os contactos realizados, de forma centralizada. Os registos não de-pendem do canal de comunica¸cão que o cliente utilizou (voz, fax, e-mail, SMS, MMS, etc.) e servem para que se tenham informa¸cões úteis e catalogáveis sobre os clientes. Qualquer informa¸cão relevante para as tomadas de decisões podem ser registadas e analisadas periodicamente, de forma a produzir relatórios de gestão. [4]

3.2 Arquitectura

O projecto proposto para o estágio, consistiu na Optimiza¸cão/Evolu¸cão de uma plataforma CRM. Trata-se de um projecto bastante complexo, constitu´ıdo por vários módulos independentes, em que todo o seu desenvolvimento foi feito utilizando a ferramenta Siebel.

A plataforma Siebel tem diversas solu¸cões para as mais variadas indústrias. Mas mesmo estas solu¸cões já desenvolvidas, necessitam sempre de altera¸cões, de modo a servir o melhor poss´ıvel o cliente.

3.2.1 Solu¸

c˜

ao Vertical

Neste projecto, e por se tratar de um projecto para a área médica/farmacêutica, a solu¸cão vertical adoptada para o seu desenvolvimento foi a solu¸cão Siebel Life Sciences.

Esta solu¸cão vem já com algumas funcionalidades implementadas, como por ex-emplo a gestão de contactos que suporta vários tipos de contactos como médicos, enfermeiros, técnicos, entre outros, gestão de clientes, gestão de oportunidades, gestão de eventos, gestão de vendas de produtos, etc. Mas como quase todas as aplica¸cões, há sempre a necessidade de ajustar, criar e reformular outras funcional-idades necessárias e que ainda não estão dispon´ıveis. E porque cada negócio é um negócio, há que criar a aplica¸cão de acordo com os requisitos do cliente, de modo a servi-lo da melhor maneira [5].

3.2.2 Solu¸

c˜

ao Horizontal

Dado a área de negócio deste projecto, a solu¸cão adoptada foi a ”Siebel Medical”. No ˆ

(22)

módulo vem já com algumas funcionalidades implementadas, como por exemplo: • Cria¸cão de Eventos e de Planos de Eventos;

• Registo de participantes nos Eventos; • Gest˜ao de contactos;

• Gestão e Calendariza¸cão de Eventos; • Cria¸cão de Sessões.

Como j´a foi referido anteriormente, muitas outras funcionalidades tiveram de ser implementadas para a aplica¸c˜ao ficar de acordo com o que o tinha sido pedido pelo cliente.

3.3 Ferramentas Utilizadas

Durante a implementa¸cão do projecto foram utilizadas maioritariamente duas ferra-mentas. Em rela¸cão à aplica¸cão, esta foi toda desenvolvida utilizando a plataforma Siebel. Já a elabora¸cão de relatórios foi feita utilizando a ferramenta Actuate e.Report Designer.

3.3.1 Siebel 7.7

O Siebel é nos dias de hoje, uma referência em software CRM, vocacionado para o desenho, desenvolvimento, marketing e suporte de aplica¸cões empresariais que dão suporte a organiza¸cões. Tem solu¸cões identificadas e desenvolvidas que se adaptam `

as indústrias existentes. A estas solu¸cões dá-se o nome de solu¸cões verticais, sendo assim cada solu¸cão vertical identifica uma indústria. [6]

Permite a cada organiza¸cão gerir, sincronizar e coordenar as suas vendas, marketing e servi¸cos a clientes em todos os canais de comunica¸cão e em pontos de contacto como a Web, o call-center, vendas e servi¸cos no terreno e canais de revenda. O que faz com que contribua para um aumento da produtividade das organiza¸cões, melhoria da satisfa¸cão do cliente e a maximiza¸cão das receitas.

O Siebel faculta também a gestão de actividades e informa¸cão dos clientes através do e-mail, telefone, fax, Web ou outro método de comunica¸cão. A informa¸cão encontra-se sincronizada num único repositório central de informa¸cão baseado numa única Base de Dados com um conjunto único de ferramentas e uma arquitectura única. Esta aplica¸cão estende as solu¸cões CRM a todas as pessoas aos empregados duma

(23)

Sobre cada solu¸cão vertical, existem solu¸cões já desenvolvidas que permitem a uti-liza¸cão imediata desta, por parte das organiza¸cões. Estas solu¸cões são designadas solu¸cões out of the box. Mas, de um forma natural, estas solu¸cões necessitam de altera¸cões para que correspondam às necessidades de cada organiza¸cão. Existem também solu¸cões horizontais que são comuns a muitas das solu¸cões verticais, como por exemplo solu¸cões 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 são guardados os dados de negócio. Fazem ainda parte, um conjunto de servidores que gerem a informa¸cão e que fornecem variados servi¸cos a clientes Web que acedem aos dados.

Figura 3.1: Siebel Life Sciences - Siebel Operating Architecture

Observando a arquitectura lógica do Siebel 3.2, é poss´ıvel ver que esta composta por vários componentes. De seguida são explicado de um modo breve os vários componentes.

• Web Server: Identifica e encaminha os pedidos de Siebel para o Siebel Server. Fornece ainda, as p´aginas HTML da aplica¸c˜ao completas para o browser cliente).

• Siebel Web Server Extension (SWSE): ´E uma extens˜ao do Web Server, que reconhece os URLs com pedidos Siebel. Encaminha os pedidos Siebel para os componentes correctos do Siebel Server.

(24)

• 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 l´ogica

• Gateway Server: ´E o componente mediador, trata-se do elo de liga¸c˜ao e ´

unico ponto de acesso ao(s) Enterprise Server(s). Regista dinamicamente a disponibilidade dos componentes com o Siebel Server. Delega fun¸cões baseando-se nos componentes requeridos pelo SWSE. Guarda ainda as defini¸cões dos componentes, parâmetros operacionais e informa¸cão das liga¸cões. Por último, direcciona os pedidos dos clientes para os respectivos componentes.

• Siebel Server: É no Siebel Server onde são processados os pedidos prove-nientes dos clientes Siebel. Controla os componentes do servidor que estão a processar numa máquina. Obtém informa¸cão de configura¸cão proveniente do Siebel Gateway. É composto por vários componentess.

• Server Component: ´E um tipo de programa que executa uma tarefa es-pec´ıfica, sobre um Siebel Server.

(25)

modo seguro. Permite uma administra¸c˜ao comum e central via Siebel Server Manager. [7]

Componentes Internas

De seguida é descrito o modo de apresenta¸cão da informa¸cão ao utilizador e a liga¸cão entre as diferentes entidades e camadas utilizadas pelo Siebel. Este diagrama 3.3 ilustra o modo de funcionamento e de apresenta¸cão da informa¸cão do Siebel:

Figura 3.3: Componentes internas de funcionamento do Siebel

A partir do diagrama anterior representado 3.3 pode-se observar a organiza¸cão das componentes do Siebel divididas pelas suas camadas e a forma como comunicam entre elas. Note-se que uma aplica¸cão Siebel é constitu´ıda por vários ecrãs (Screen), um ecrã por várias vistas (View), uma vista por várias applets e uma Applet por vários controlos (List Columns).

No n´ıvel User Interface, cada vista está ligada a um Business Object que contém vários Business Components, onde cada um destes, é composto por vários campos (Field). São estes campos que contêm a informa¸cão que está mapeada em colunas de uma ou mais tabelas. São estas tabelas que fornecem a informa¸cão aos Business Components.

Os Business Components são o meio que o Siebel tem para aceder à informa¸cão da Base de Dados, uma vez que estes são constitu´ıdos por um ou mais campos. Os campos mapeiam directamente as colunas e tabelas da Base de Dados e em última análise com o repositório onde se encontra a informa¸cão.

(26)

Modela¸c˜

ao e Configura¸c˜

ao

Para modelar a aplica¸cão é necessária uma ferramenta, o Siebel Tools 3.4. É no Siebel Tools onde é feita toda a configura¸cão, como por exemplo, a cria¸cão de novos Business Objects, Business Components, Applets, Views, Screens, etc, de modo a optimizar a aplica¸cão às necessidades do cliente. É no Siebel Tools que se criam as applets que irão compor a aplica¸cão, e a respectiva disposi¸cão da informa¸cão. O Siebel Tools é um ambiente integrado para configurar todos os aspectos de uma aplica¸cão Siebel, de modo a que com uma única configura¸cão, a aplica¸cão suporte várias l´ınguas, tenha actualiza¸cões automáticas para futuras versões do Siebel e que a sua manuten¸cão seja facilitada.

Figura 3.4: Siebel Tools

A navega¸cão no Siebel Tools, é feita principalmente através de duas vertentes. Uma delas é através do Object Manager, que utiliza uma estrutura semelhante a uma ´

arvore hierárquica, semelhante à do Microsoft Windows Explorer, que permite que o utilizador tenha acesso a todos os tipos de objectos armazenados no repositório do Siebel. A segunda vertente, o Object List Editor, mostra os objectos individuais no repositório Siebel. Ainda na segunda vertente é poss´ıvel definir as caracter´ısticas dos objectos assim como definir propriedades do comportamento dos mesmos. Por

(27)

algum modo, basta definir a sort spefication da applet, caso seja necessário restringir os dados apresentados, é poss´ıvel definir uma search spefication. Por vezes, alguns objectos têm um comportamento muito espec´ıfico, o qual não é poss´ıvel definir nas suas propriedades. Para tal é muito comum recorrer à programa¸cão desses mesmos comportamentos. A linguagem de programa¸cão utilizada no Siebel Tools é o eScript, muito semelhante a VB Script.

O Siebel Client representado na figura 3.5 é a aplica¸cão resultante das altera¸cões elaboradas no Siebel Tools. Nesta aplica¸cão o utilizador tem a capacidade de fazer algumas altera¸cões ao n´ıvel de configura¸cão, mas a sua principal fun¸cão é aceder a toda a informa¸cão dos seus clientes finais, tendo a possibilidade de adicionar, apagar e modificar essa informa¸cão. 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 é um meio de desenvolvimento bas-tante potente, onde é poss´ıvel criar relatórios (Reports) altamente flex´ıveis, para qualquer aplica¸cão web-enabled. Neste caso, os relatórios são gerados a partir do Siebel. Com a utiliza¸cão do Actuate e.Report Designer Professional, as equipas

(28)

de desenvolvimento podem criar rapidamente relatórios, desenhos, gráficos ou es-tat´ısticas provenientes de qualquer fonte de dados. O relatório pode ser gerado em qualquer formato e a disposi¸cão dos seus conteúdos pode ser apresentada em qual-quer esquema conceb´ıvel, não importa o quão complexa graficamente.

Há ainda a possibilidade de exportar o relatório para outros ambientes, como por exemplo, para o formato PDF, ou por exemplo caso o relatório se trate de uma tabela, há a possibilidade de ser exportado para Excel, ou caso se trate de um doc-umento de texto, poderá ser exportado para Word, de modo a ser editado.

A aplica¸cão Actuate Report divide-se em duas grandes áreas. Numa temos a es-trutura hierárquica dos objectos presentes no nosso relatório, como por exemplo os DataStreams, que são os objectos que dão acesso aos dados provenientes do Siebel. Há ainda uma grande variedade de objectos como campos de texto, que serão preenchidos com dados provenientes dos DataStreams, labels, objectos de or-dena¸cão de dados, objectos que permitem que os dados sejam agrupados segundo chaves escolhidas pela utilizador, etc. A outra área é a de desenho, onde os ob-jectos são dispostos da forma desejada. É nesta área que são definidas todas as caracter´ısticas do comportamento que cada objecto irá ter, como por exemplo a sua cor, largura da linha, tipo de letra, posi¸cão, alinhamento do texto, distância 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 é aperfei¸coar os controlos financeiros das empresas, a fim de evitar que aconte¸cam desvios e preju´ızos para as mesmas. A lei visa garantir a transparência na gestão financeira das organiza¸cões, credibilidade na contabilidade, auditoria e a seguran¸ca das informa¸cões para que sejam realmente confiáveis, evitando assim fraudes, fuga de capitais, etc.

Neste projecto a metodologia escolhida (processo em espiral) é composta por um processo de cinco fases principais 3.7. Neste caso particular, a fase da forma¸cão an-tecedeu o processo das cinco fases principais. Por ordem, surgem as seguintes fases, Forma¸cão, Análise, Desenvolvimento, Testes, Documenta¸cão e Apoio Pós-Produ¸cão. De seguida é apresentada uma pequena descri¸cão de cada uma das fases do processo. [8]

(29)

Figura 3.6: Actuate e.Report Designer Professional

Figura 3.7: Fases do projecto

3.4.1 Forma¸

c˜

ao

Foi a primeira fase do estágio. Nesta fase foram adquiridas as competências técnicas sobre a plataforma Siebel, assim como o Modelo de Dados e metodologias de tra-balho. A forma¸cão consistiu na leitura da bibliografia recomendada, neste caso, dos três volumes Siebel 7 Essentials, Students Guide e na resolu¸cão de alguns exerc´ıcios presentes em ”Siebel 7 Essentials, Labs”, onde foram compreendidos os fundamen-tos da ferramenta, a sua arquitectura, o seu público alvo, o seu funcionamento, a forma de disponibiliza¸cão de informa¸cão, método de instala¸cão e configura¸cão, entre outros assuntos.

(30)

3.4.2 An´

alise

Na fase de análise foi feito o levantamento de requisitos de negócio, definiu-se do scope do projecto, onde foi feita uma análise do impacto dos novos requisitos. Após serem conhecidos todos os requisitos, cada chefe de equipa estimou o número 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 à sua distribui¸cão pelos elementos da respectiva equipa.

3.4.3 Desenvolvimento

´

E a maior fase do processo e basicamente é a fase onde os requisitos são imple-mentados. Nesta fase, e com o trabalho previamente distribu´ıdo, cada membro é responsável por desenvolver os requisitos que lhe foram atribuidos inicialmente. To-dos os requisitos, apesar de diferentes, cada um com a sua informa¸cão, têm um processo de elabora¸cão semelhante. Este processo, foi uniformizado e centralizado de forma a manter organizada toda a informa¸cão referente ao desenvolvimento dos requisitos de cada release.

Neste projecto existem vários ambientes de trabalho, cada um com um objectivo bem espec´ıfico. Estes ambientes são semelhantes, no entanto à medida em que se avan¸ca nas fases de desenvolvimento do projecto, o grau de importância 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 são poss´ıveis fazer todas as altera¸cões, não há dados importantes, é poss´ıvel fazer qualquer tipo de testes. Após ter sido desenvolvido um requisito, é comum testar as altera¸cões em DEV, de modo a ver se o resultado do requisito é o esperado. Na fase de testes, antes da aplica¸cão ser testada pelo cliente num ambiente próprio de testes, UAT (User Acceptance Tests), toda a aplica¸cão ainda é testada pela equipa de desenvolvimento num ambiente chamado SIT (Sys-tem Integrated Test). Antes de passar para o ambiente de Produ¸cão (PROD), onde já estão presentes os dados reais de negócio, a aplica¸cão ainda passa por outro am-biente, designada por ambiente de Training (TRA). Este amam-biente, contém cópias dos dados reais, e serve para que seja poss´ıvel, por parte do cliente, dar forma¸cão sobre a nova aplica¸cão aos seus colaboradores.

Ainda em rela¸cão ao ambiente de PROD, existe uma área onde apenas a equipa de desenvolvimento tem acesso. É nessa área que é mantida toda a informa¸cão ref-erente aos requisitos. Como acima foi referido, todos os requisitos têm um processo

(31)

de elabora¸c˜ao semalhante, e que segue os seguintes passos:

• Ler a descri¸c˜ao, objectivo e comportamento esperado do requisito • Ver na aplica¸c˜ao final, o que necessita de ser alterado

• Fazer check-out do(s) projecto(s), do servidor, necessário(s) alterar, para a elabora¸cão do requisito. Fazer check-out de um projecto, não é mais do que, reescrever localmente o projecto com uma cópia do mesmo, proveniente do servidor. Ao fazer check-out de um projecto, o mesmo fica bloqueado no servi-dor, ou seja, enquanto o projecto não for libertado, mais nenhum utilizador o pode utilizar.

• Fazer SIF (Siebel Import File) de check-out de cada projecto necessário para elaborar a altera¸cão, para no caso de algo correr mal, ser poss´ıvel repor o pro-jecto sem as altera¸cões feitas. O SIF é um ficheiro que guarda as defini¸cões dos objectos de Siebel e é usado para importar e exportar defini¸cões de objectos. • Fazer as altera¸cões necessárias nos projectos, de modo elaborar o requisito,

compilar os projectos alterados e testar com base de dados local

(32)

• Caso o resultado seja o esperado, fazer check-in dos projectos para o servidor, caso seja necessário corrigir alguma coisa, refazer, recompilar e voltar a testar. Ao fazer check-in de um projecto, uma cópia do projecto é enviada para o servidor e o projecto é desbloqueado no servidor.

• Fazer SIF de check-in

• Actualizar a informa¸cão do requisito, com datas de in´ıcio e fim da sua elab-ora¸cão, descri¸cão da altera¸cão, dura¸cão da altera¸cão, etc.

Toda a informa¸cão relativa aos requisitos é guardada numa base de dados e é poss´ıvel ser actualizada através do ambiente PROD 3.8. De seguida é poss´ıvel ver como é que este ambiente está estruturado.

Na figura 3.8 estão assinaladas 4 grupos de informa¸cão. Na figura 3.9 é poss´ıvel ver a informa¸cão geral do requisito, como o seu código, uma breve descri¸cão do problema, o estado em que se encontra o requisito, etc.

Figura 3.9: Ambiente de Produ¸cão - Informa¸cão geral de um requisito Na figura 3.10 temos a informa¸cão detalhada do requisito. Aqui é poss´ıvel ver quem criou o requisito, isto é, quem encontrou uma erro ou falha e achou que era necessária uma altera¸cão, qual seria o comportamento esperado após a correçcão do erro, a que módulo faz parte o requisito, existe também uma área para comentários adicionais, o número de dias estimados para a resolu¸cão do problema, etc.

Figura 3.10: Ambiente de Produ¸cão - Informa¸cão detalhada de um requisito As figuras 3.11 e 3.12 mostram a informa¸cão relativa ao desenvolvimento do

(33)

requi-Cap´ıtulo 3. Optimiza¸c˜ao/Evolu¸c˜ao de uma plataforma CRM 18

informa¸cão estimada, como a real, como por exemplo, a data de in´ıcio, fim e dura¸cão em dias do requisito. Na figura 3.12, é poss´ıvel ver quem está a desenvolver e quem já desenvolveu alguma coisa para o requisito, e caso alguém já tenha resolvido alguma coisa, existe uma área de inser¸cão de comentários, onde cada utilizador deve registar as altera¸cões que foram feitas na aplica¸cão no sentido de resolver este requisito.

Figura 3.11: Informa¸c˜ao de desenvolvimento de um requisito 1

Figura 3.12: Informa¸c˜ao de desenvolvimento de um requisito 2

3.4.4 Testes

Após a fase de desenvolvimento, tem lugar a fase de teste. Esta fase é constitu´ıda por pequenas sub-fases. As sub-fases de teste podem ser dois tipos, de SIT (System Integrated Test), em que os testes são feitos por membros da equipa do projecto, ou de UAT (User Acceptance Test), que são testes feitos pelos utilizadores finais da aplica¸cão. As fases de teste são seguidas por fases de correçcão de erros (Fix-ing). Na figura 3.13 é poss´ıvel ver as diversas fases que compõem a fase de Testes. Quando um utilizador reporta um erro, regista a informa¸cão 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 através da conformidade que a solu¸cão apresenta face aos requisitos iniciais do projecto. É executada apenas no final da fase de implementa¸cão, mas é planeada desde o in´ıcio do projecto, de modo a assegurar uma correcta gestão de requisitos ao longo do projecto. Esta gestão de requisitos é necessária pois, por muito exaustiva que seja a fase de análise, há sempre mudan¸cas e altera¸cões de requisitos, e muitas vezes essas

(34)

mudan¸cas s˜ao essenciais para o sucesso do mesmo.

Figura 3.13: Composi¸c˜ao da fase de Testes

3.4.5 Documenta¸

c˜

ao

Com o fim da fase de testes, a aplica¸cão está pronta a ir para Produ¸cão. Esta fase tem como objectivo principal elaborar toda a documenta¸cão necessária. Seja docu-menta¸cão técnica, funcional e até mesmo manuais de utilizador. O objectivo é gerir a adapta¸cão dos utilizadores à nova aplica¸cão, como sendo um dos factores cr´ıticos de sucesso de uma solu¸cão de CRM.

3.4.6 Apoio P´

os-Produ¸

c˜

ao

Sendo a fase final do processo, esta fase permite dar apoio após o lan¸camento do produto para o mercado. É uma fase de rápida e eficaz resolu¸cão de problemas que possam surgir após lan¸camento de uma release da plataforma CRM. Esta é realmente a fase cr´ıtica do projecto, já que é nesta fase que se assegura a continuidade dos trabalhos, sendo necessárias várias actualiza¸cões, assim como alguns testes, de forma a provar o bom funcionamento de todos os módulos instalados. Após a passagem a produ¸cão deverá ser previsto um per´ıodo de verifica¸cão/monitoriza¸cão em Produ¸cão onde os utilizadores deverão reportar todos os defeitos encontrados, para futuras correçcões.

(35)

Cap´ıtulo 4

Trabalho Desenvolvido

Durante o estágio, houve a oportunidade de participar nas diversas fases do desen-volvimento do projecto, o que proporcionou a execu¸cão de tarefas relativas a várias fases do projecto. Na fase de Desenvolvimento, foram desenvolvidos os requisitos definidos na fase de análise. De seguida, na fases de Testes, foram reportados alguns erros que foram corrigidos nas fases seguintes. Durante a fase de documenta¸cão, foram elaborados o Manual de Utilizador e documenta¸cão para todos os requisitos desenvolvidos. Na fase de Apoio Pós-Produ¸cão ainda surgiram alguns erros que foram corrigidos, o que fez com que surgisse a necessidade de lan¸car novas versões da aplica¸cão final, desta vez com os erros todos corrigidos.

4.1 Actividades desenvolvidas

Como já foi referido, quando o estágio teve in´ıcio, este projecto já vinha a ser desen-volvido há algum tempo. Sendo o t´ıtulo do projecto de estágio ”Optimiza¸cão/Evolu¸cão de uma plataforma CRM”, o trabalho desenvolvido assentou essencialmente em op-timizar e evoluir a aplica¸cão que já estava desenvolvida.

Durante o projecto de estágio, foram desenvolvidos diversos requisitos, no entanto e tendo em conta a tabela da figura A.1, é poss´ıvel agrupar os requisitos desenvolvidos em três 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 último 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 altera¸cão ou correçcão necessária e a fase em que esta é reportada `

a equipa de desenvolvimento. Os requisitos definidos durante a fase de an´alise,

(36)

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 último existem os Service Requests (SR), que foram requisitos corrigidos durante a fase de produ¸cão. Caso um CR seja desenvolvido de forma incorrecta, na fase de testes é reportado como um TPR. Se tiver sido corrigido de forma também incorrecta e apenas detectado já na fase de produ¸cão, então reporta-se o erro na forma de um SR. Ou reporta-seja, o mesmo requisito pode passar pelos 3 estados. De seguida são descritos, os 3 grupos de requisitos desenvolvidos ao longo do estágio.

4.1.1 Email Templates

Como já foi referido, este projecto trata de gerir eventos e todas as suas actividades inerentes. Umas das questões essenciais trata-se da inscri¸cão dos particpantes nos respectivos eventos. Em rela¸cão ao registo de participantes num dado evento, este pode ter vários estados, como por exemplo, confirmado, cancelado, pendente, convi-dado, etc. Quando há uma altera¸cão no estado do registo de um participante, ou seja, quando o estado do registo é modificado, é enviado um email para o participante, informando-o da actualiza¸cão do estado do seu registo, bem como a informa¸cão rel-evante do evento em que este está inscrito. O email enviado e respectivo conteúdo, 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 é alterado para ”Convidado”, no email que o participante irá receber 4.1 não haverá dados relativos ao pagamento da inscri¸cão do participante, já que este está apenas a ser convidado para um evento, mas se o estado for alterado para ”Confirmado”, então este email terá informa¸cão relativa ao pagamento da sua inscri¸cão.

Para que o envio dos emails seja automático, houve várias tarefas intermédias. Para estruturar os email templates, 4.2 o primeiro passo foi, organizar no Siebel Tools os campos que guardavam a informa¸cão relativa aos participantes. Esses campos fazem parte do business component dos participantes (Attendees) e estão mapeados em col-unas de uma ou mais tabelas. O segundo passo, e de modo a preencher os emails (ficheiros HTML) com informa¸cão dos participantes, proveniente do siebel, basta colocar os nomes dos campos entre parênteses rectos no código HTML. Neste pro-jecto foram feitos cerca de 50 email templates para diferentes tipos de participantes, diferentes estados de registo e para diferentes organiza¸cões, como por exemplo, Es-tados Unidos da América e alguns pa´ıses da América Latina.

(37)

Figura 4.1: Email Template - Observer Invite

ado, de um modo abstracto, é necessário ter um trigger e um workflow. Um workflow é uma sequência de passos necessários para a execu¸cão de uma determinada açcão, neste caso, o envio dos email. O trigger é o que desponta a execu¸cão do workflow, neste caso, é a altera¸cão do estado do registo do participante.

De uma forma mais detalhada, foram várias as tarefas elaboradas até que o en-vio automático de emails se processasse. A primeira tarefa a ser elaborada foi a estrutura¸cão dos ficheiros HTML (emails a serem enviados). De seguida foram cri-ados os Workflow Processes utilizando a ferramenta Siebel Tools. No Siebel Tools não só é 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 são elaborados ao n´ıvel da aplica¸cão. Para cada Workflow é criada uma açcão(Action), cujo argumento é um processo que tem o nome do Work-flow Process criado no Siebel Tools. A açcão criada, é associada a uma Workflow Policy, que para que seja activada, todas as suas condi¸cões terão de ser aceites. No caso da figura 4.4, para que o email seja enviado, o participante terá de pertencer `

(38)

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 terá de ser do tipo ”Participant”e terá de existir, ou seja o registo terá de existir na base de dados. Se tudo isto se verificar, então um email será enviado para o respectivo participante. Para cada combina¸cão entre tipo de participante e estado do registo, foi definido uma Workflow Policy e respectivas condi¸cões, uma açcão (Action) e respectivo argumento e ainda o Workflow no Siebel Tools.

4.1.2 Reports

´

E frequente, na empresa cliente, surgirem situa¸cões onde são necessários relatórios, 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 conferência.

`

(39)

or-Cap´ıtulo 4. Trabalho Desenvolvido 24

Figura 4.4: Siebel Client - Workflow Process

ganiza¸cão, com uma listagem dos nomes dos participantes inscritos na conferência, para que estes confirmem a sua inscri¸cão. Assim que a sua inscri¸cão é confirmada, é entregue um cartão com o respectivo nome para que o participante seja facilmente identificado durante a conferência. Cada participante tem no seu lugar, um cartão 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 inscri¸cão, cartões com os nomes, iden-tificadores ou até mesmo recibos que sejam necessários emitir, etc, todos eles são Reports modelados utilizando a ferramenta, Actuate Report. Para muitos dos req-uisitos desenvolvidos durante o estágio, a sua resolu¸cão baseou-se na elabora¸cão 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 informa¸cão necessária no Report e qual a disposi¸cão da mesma. Depois de analisado o template, é necessário ir ao Siebel Tools criar um report com os campos do Siebel pedidos no template.

(40)

Quando o report ´e criado no Siebel Tools, apenas se cria um ficheiro .rol (Report Object Library) e n˜ao o report propriamente dito.

No Actuate Report, é criado então um ficheiro .rod (Report Object Designer), onde é feita a modela¸cão do report. Aqui é adicionado o .rol gerado. Com a associa¸cão deste ficheiro, é poss´ıvel mapear os campos previamente adicionados no Siebel Tools na área de desenho da forma desejada. Nos reports mais elaborados, onde o compor-tamento do report é algo mais complexo, não basta adicionar os campos ao report. Há situa¸cões onde é necessário programar. A linguagem de programa¸cão usada foi Actuate VB Script. Quando o report está pronto, é gerado um ficheiro .rox (Report Object Executable) que é transferido para o servidor Actuate. Neste momento o report está pronto a ser executado. Para tal, basta na aplica¸cão gerar o report e o .rox será executado.

4.1.3 Requisitos Siebel

Ao longo do estágio, 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 aplica¸cão, ou até mesmo corrigir, optimizar algo que já tinha sido pedido antes. Durante o estágio foram feitos vários requisitos de Siebel, como é 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 altera¸cões. O objectivo era mapear um campo já criado numa ap-plet dos planos de eventos e ordenar os campos das apap-plet form, respectivamente. Assim como houve requisitos simples, houve outros também algo elaborados, onde foi necessário 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 botão (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 relembrá-los que estavam inscritos no dito evento.

Quando o botão ”Send Reminder Email”é pressionado, é enviado um email para todos os participantes com estado de registo confirmado e automaticamente é adi-cionada uma flag no campo ”Reminder Sent”, indicando que já foi enviado um email de ”Reminder”para os respectivos participantes. O email apenas é enviado

(41)

Figura 4.5: Applet dos participantes de um evento

Sent”marcado. Também é poss´ıvel enviar outro email a um participante que já o tenha recebido antes. Para isso basta, desmarcar o campo ”Reminder Sent”desse participante e voltar a pressionar o botão.

Outro requisito de Siebel algo elaborado que foi desenvolvido, consistiu em criar três botões, ao n´ıvel da applet das viagens dos participantes, que, ao serem pres-sionados, devolvessem viagens. Na applet da figura 4.6 é poss´ıvel verificar os 3 botões para devolver viagens. O primeiro botão (Retrieve All) pede viagens para todos os participantes, o segundo botão (Retrieve One) devolve viagens para o par-ticipante que tiver seleccionado no momento em que é feito o pedido e o último botão (Retrieve Partial) devolve viagens para todos os participantes que tiverem o campo ”Pick Attendee”marcado. Pressionando um dos três botões, é desencadeado um processo que envolve mais dois sistemas, o WebMethods e o Sabre. O Sabre é um sistema associado a uma agência de viagens com o objectivo de de efectuar procedimentos relativos a reserva de viagens, o WebMethods é uma plataforma de integra¸cão que faz a interliga¸cão entre os sistemas Siebel e o Sabre.

Figura 4.6: Applet Retrieve PNR

Foram elaborados muitos outros requisitos Siebel, como é poss´ıvel ver no anexo A.1, mas acabaram por não ser expostos em detalhe. Apenas foram explicados os difer-entes tipos de requisitos elaborados durante o projecto de estágio, e foram dados alguns exemplos.

(42)

Cap´ıtulo 5

Conclus˜

ao

Neste cap´ıtulo são apresentadas as conclusões relativas ao trabalho desenvolvido ao longo do projecto de estágio, bem como, o trabalho a ser desenvolvido no futuro.

5.1 Trabalho Desenvolvido

Ao longo do projecto de estágio, em diversas fases do seu desenvolvimento, foi poss´ıvel aplicar alguns dos conhecimentos adquiridos durante a licenciatura e de certo modo, ampliá-los. Tive a oportunidade de passar por todas as fases do desen-volvimento do projecto o que me deu uma ideia mais próxima da realidade. Desde a análise de requisitos, ao desenvolvimento dos mesmos, passando pelas fases de testes, documenta¸cão e apoio pós-produ¸cão.

Para além de trabalhar com a ferramenta Siebel, aprendi também a trabalhar com a ferramenta Actuate eReport Designer Professional, ferramenta esta que permite a elabora¸cão de qualquer tipo de relatório. Em alguns dos relatórios elaborados, foi necessário recorrer à linguagem de programa¸cão de VB Script, com a qual nunca tinha programado.

Tratando-se de uma aplica¸cão cujo o objectivo é gerir eventos e toda a sua in-forma¸cão, a quantidade de dados a manter, gerir e actualizar torna-se bastante grande. Todos estes dados estão guardados em bases de dados Oracle. Durante todo o estágio foi frequente a necessidade de utilizar a linguagem SQL.

5.2 Trabalho Futuro

Tratando-se de um trabalho de continuidade, isto é, o projecto não tem prevista uma data de fim anunciada. Trata-se de um projecto em constantes actualiza¸cões e modifica¸cões, que vai sucessivamente tendo várias releases ao longo do tempo, da´ı o

(43)

Cap´ıtulo 5. Conclus˜ao 28

t´ıtulo do projecto de estágio ser ”Optimiza¸cão/Evolu¸cão de uma plataforma CRM”. Visto ser um projecto internacional, dividido em vários módulos, cada um relativo a uma área de negócio, é frequente a entrada de novos pa´ıses no projecto, fazendo com que cada um destes utilize apenas os módulos necessários ao seu negócio. Quando este estágio finalizou, o módulo de ProfEd apenas era utilizado por franchises dos Estados Unidos da América e da América Latina. Na próxima release irá também ser utilizado por franchises de pa´ıses europeus como por exemplo a Alemanha. Seria interessante ter a aplica¸cão desenvolvida de maneira a que, cada vez que entrasse um pa´ıs novo, a utiliza¸cão da aplica¸cão por parte deste, fosse imediata. Neste momento e da forma como está a ser desenvolvida, cada vez que entra um pa´ıs/organiza¸cão nova, há ainda altera¸cões a fazer, como por exemplo, a tradu¸cão de alguns textos, listas de valores, comentários, t´ıtulos, etc.

Como se trata de um projecto vasto, em que a aplica¸cão é utilizada na Europa, Estados Unidos da América, América Latina e continente Africano, seria uma van-tagem, e de modo a minimizar as altera¸cões da linguagem, chegar a um acordo e utilizar uma ou duas l´ınguas na aplica¸cão para todos os pa´ıses.

5.3 An´

alise Cr´ıtica

Tratou-se de uma experiˆencia muito enriquecedora, tanto a n´ıvel pessoal como a n´ıvel profissional. Apesar de na faculdade ter feito parte de v´arios grupos de tra-balho, nunca tinha tido a oportunidade de poder trabalhar numa equipa numerosa, com cerca de 30 colaboradores.

Em termos pessoais, este estágio deu-me a conhecer a realidade de trabalhar num projecto para o exterior, isto é, para o mundo profissional, onde existe um cliente que espera ter uma aplica¸cão com certas funcionalidades pronta a utilizar numa de-terminada data, chefes de equipa, ou seja, alguém de um n´ıvel superior, que por um lado nos apoia, mas por outro, é a pessoa a quem temos de mostrar o nosso trabalho desenvolvido e onde é necessário termos sempre presente que fazemos parte de uma equipa, e que em cada versão da aplica¸cão desenvolvida, é o nome da equipa de desenvolvimento e da entidade empregadora que está 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.

(44)

Apˆ

endice 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 é poss´ıvel verificar o número de cada requisito (Change Request), bem como as datas planeadas para o in´ıcio e fim da sua implementa¸cão. Cada requisito é composto ainda por uma pequena descri¸cão e pelas suas datas reais de imple-menta¸cão.

(45)

Apˆendice A. Change Requests 30

(46)

Apˆ

endice B

Test Problem Reports

A fase de Testes, foi composta por pequenas fases de testes e respectivas correçcões dos erros que foram sendo encontrados. Estes erros, foram reportados como sendo Test Problem Reports (TPR). Cada erro destes, é 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.

(47)

Apˆendice B. Test Problem Reports 32

(48)