universidade de lisboa -...
TRANSCRIPT
UNIVERSIDADE DE LISBOA Faculdade de Ciências Departamento de Informática
ANÁLISE E DESENVOLVIMENTO DE SOLUÇÃO DE
SERVICE DESK MANAGEMENT - KNOWLEDGE
MANAGEMENT & REQUEST FULFILLMENT
Nelson Ricardo Alves Pinto
RELATÓRIO FINAL
Versão Pública
MESTRADO EM ENGENHARIA INFORMÁTICA
Especialização em Sistemas de Informação
2011
UNIVERSIDADE DE LISBOA Faculdade de Ciências Departamento de Informática
ANÁLISE E DESENVOLVIMENTO DE SOLUÇÃO DE
SERVICE DESK MANAGEMENT - KNOWLEDGE
MANAGEMENT & REQUEST FULFILLMENT
Nelson Ricardo Alves Pinto
RELATÓRIO FINAL
ESTÁGIO
Trabalho orientado pelo Prof. Doutor João Carlos Balsa da Silva e co-orientado por
Eng. Miguel Ângelo de Jesus Pereira Ramos
MESTRADO EM ENGENHARIA INFORMÁTICA
Especialização em Sistemas de Informação
2011
Agradecimentos
Quero agradecer a todas as pessoas que, directa ou indirectamente, acompanharam
todo o meu processo de aprendizagem neste último ano e, de algum modo, ajudaram-me
no meu crescimento como Homem.
À Maksen, quero agradecer no âmbito do mestrado, pela forma como me
receberam e integraram na empresa, todo o apoio que me deram e pelos recursos que me
disponibilizaram. Em especial, quero deixar um apreço ao Miguel Ramos e ao Rui
Miguel que, sempre que possível, me acompanharam no decorrer do estágio.
Gostaria de agradecer ao meu orientador Prof. Doutor João Carlos Balsa da Silva,
pela prontidão e disponibilidade durante todo o estágio e por ter compreendido todas as
dificuldades encontradas na realização do PEI.
Ao meu colega de faculdade e de estágio, Ricardo Reis, um Muito Obrigado pela
entreajuda e companheirismo.
Por fim, mas não com menos importância, quero agradecer à minha família que
sempre me apoiou em todas as decisões, à minha namorada que me apoiou e motivou
nas alturas mais difíceis e aos meus amigos por se lembrarem de mim.
Hélio Jonilson Van-Dúnen Filipe.
i
Resumo
O presente documento refere-se à análise e desenvolvimento de uma solução de
Service Desk Management que segue as melhores práticas advogadas pela ITIL® v3.
De modo a suportar a solução desenvolvida, serão apresentados os principais
conceitos aplicados, nomeadamente, a framework ITIL® de melhores práticas de ITSM,
a plataforma de desenvolvimento OutSystems Agile Plataform, a qual adopta a
metodologia de desenvolvimento usada para este projecto, a SCRUM Agile
Methodology.
Da totalidade dos processos advogados pela ITIL® v3, o presente relatório irá
centrar-se nos processos de Incident Management, Problem Management, Change
Management, Release & Deployment Management, mas sobretudo no Knowledge
Management e Request Fulfillment.
Os processos específicos foram desenvolvidos na fase de implementação da
solução, consistindo na implementação do painel de administração, e na criação,
aprovação, validação, classificação, encaminhamento e fecho de registos de
conhecimento ou pedidos de serviço.
Após o desenvolvimento da solução, os processos implementados foram testados
por utilizadores finais, dando a sua aprovação sobre o que foi desenvolvido.
Palavras-chave: ITIL® v3, Metodologia Ágil SCRUM, Service Desk
Management, Knowledge Management, Request Fulfillment.
ii
iii
Abstract
This project is the analysis and development of a Service Desk Management
solution based on best practices advocated by ITIL® v3.
To support the developed solution, I will present the main concepts applied,
namely, the ITSM best practices ITIL® framework, the OutSystems Agile development
plataform, that adopts the development methodology to be used, the SCRUM Agile
Methodology.
This report will focus on the processes advocated by ITIL® v3: Incident
Management, Problem Management, Change Management, Release & Deployment
Management, Knowledge Management and Request Fulfillment. The first four were
implemented in partnership with another PEI and the remaining are specific to this
project.
The specific processes were developed in the implementation phase of the
solution, consisting of the implementation of the administration panel, and creation,
approval, validation, classification, routing and closure of knowledge records or service
requests.
After the development of the solution, the implemented processes have been
tested by end users, giving their approval.
Keywords: ITIL® v3, SCRUM Agile Methodology, Service Desk Management,
Knowledge Management and Request Fulfillment.
iv
v
Conteúdo
Lista de Figuras .................................................................................................... viii
Lista de Acrónimos ................................................................................................ xi
Capítulo 1 Introdução ........................................................................................... 1
1.1 Motivação ............................................................................................... 1
1.2 Objectivos ............................................................................................... 1
1.3 Âmbito de actuação ................................................................................ 2
1.4 Contribuição ............................................................................................ 3
1.5 Formações e arranque do projecto .......................................................... 3
1.6 Enquadramento Institucional .................................................................. 4
1.7 Organização do Projecto ......................................................................... 5
1.8 Estrutura do documento .......................................................................... 7
Capítulo 2 Metodologia e Planeamento ............................................................... 8
2.1 Framework ITIL® .................................................................................. 8
2.1.1 ITIL® v3 ............................................................................................. 9
2.2 Plataforma de desenvolvimento - OutSystems ..................................... 13
2.2.1 Visão geral......................................................................................... 15
2.2.2 Componentes da plataforma OutSystems ......................................... 16
2.3 Metodologia de desenvolvimento - SCRUM ........................................ 18
2.3.1 Papéis ................................................................................................ 18
2.3.2 Reuniões ............................................................................................ 19
2.3.3 Artefactos .......................................................................................... 20
2.3.4 Sprint ................................................................................................. 20
2.4 Plano de Trabalhos ................................................................................ 21
2.4.1 Plano de Trabalhos Inicial ................................................................. 21
2.4.2 Plano de Trabalhos Final ................................................................... 23
Capítulo 3 Contexto teórico dos processos implementados ............................... 24
3.1 Knowledge Management ....................................................................... 25
3.2 Request Fulfillment ............................................................................... 27
3.3 Outros processos ................................................................................... 27
3.3.1 Incident Management ........................................................................ 27
vi
3.3.2 Problem Management ....................................................................... 28
3.3.3 Change Management......................................................................... 28
3.3.4 Release & Deployment Management ................................................ 29
3.3.5 Service Asset & Configuration Management .................................... 29
3.3.6 Service Level Management................................................................ 29
Capítulo 4 Análise do problema e desenho da solução ...................................... 30
4.1 Trabalho relacionado ............................................................................ 30
4.1.1 Benchmark de mercado ..................................................................... 30
4.1.2 Modelo de avaliação.......................................................................... 32
4.1.3 Apresentação de resultados ............................................................... 33
4.2 Definição de requisitos ......................................................................... 35
4.3 Desenho do modelo conceptual ............................................................ 37
4.3.1 Modelo de casos de uso ..................................................................... 37
4.3.2 Modelo de domínio ........................................................................... 39
Capítulo 5 Solução implementada ...................................................................... 40
5.1 Knowledge Management ....................................................................... 40
5.1.1 Painel de administração ..................................................................... 41
5.1.2 Criação de registos de conhecimento ................................................ 46
5.1.3 Aprovação ......................................................................................... 49
5.1.4 Validação ........................................................................................... 52
5.1.5 Classificação de registos de conhecimento ....................................... 55
5.1.6 Consultar FAQ .................................................................................. 56
5.2 Request Fulfillment ............................................................................... 57
5.2.1 Painel de administração ..................................................................... 57
5.2.2 Criação de pedidos de serviço ........................................................... 67
5.2.3 Pick-up de pedidos de serviço ........................................................... 69
5.2.4 Tratamento de pedidos de serviço ..................................................... 70
5.2.5 Encaminhamento de pedidos de serviço ........................................... 76
5.2.6 Fecho de pedido de serviço ............................................................... 78
vii
5.3 Avaliação da solução ............................................................................ 80
Capítulo 6 Discussão .......................................................................................... 81
6.1 Apreciação final .................................................................................... 83
Capítulo 7 Bibliografia ....................................................................................... 84
viii
Lista de Figuras
Figura 1 – Organograma do projecto ...................................................................... 6
Figura 2 – Ciclo de vida um serviço ..................................................................... 10
Figura 3 – Descrição da plataforma ágil OutSystems ........................................... 16
Figura 4 – Descrição da plataforma ágil. .............................................................. 17
Figura 5 – SCRUM Agile Methodology ................................................................ 18
Figura 6 – Calendário de ―alto-nível‖ ................................................................... 22
Figura 7 – Planeamento final ................................................................................ 23
Figura 8 – Processos da ITIL® v3 implementados e respectivo mapeamento ..... 24
Figura 9 – O fluxo de data para wisdom ............................................................... 26
Figura 10 – Relação entre CMDB, CMS e SKMS ............................................... 26
Figura 11 - The Forrester Wave: Service Desk Management Tools Apr-2008..... 31
Figura 12 - Gartner Magic Quadrant ITSM Oct-2008 ......................................... 31
Figura 13 - Representação gráfica do modelo de avaliação .................................. 33
Figura 14 – Avaliação das soluções por dimensão ............................................... 34
Figura 15 – Avaliação dos requisitos de funcionais.............................................. 34
Figura 16 – Avaliação de requisitos de integração ............................................... 35
Figura 17 – Diagrama de Casos de Uso do processo de Knowledge Mgmt .......... 38
Figura 18 - Diagrama de Casos de Uso do processo de Request Fulfillment ....... 38
Figura 19 – Lista de campos adicionais ................................................................ 41
Figura 20 – Janela de criação/edição de campos adicionais ................................. 42
Figura 21 – Grupos de aprovação de registos de conhecimento ........................... 43
Figura 22 – Pagina de criação/edição dos grupos de aprovação ........................... 43
Figura 23 – Fluxo de aprovação dos registos de conhecimento ........................... 44
Figura 24 – Lista de estados de registos de conhecimento ................................... 44
Figura 25 – Janela de popup de criação/edição de um novo estado ...................... 45
Figura 26 – Lista de perguntas da FAQ ................................................................ 45
Figura 27 – Janela de popup para criação/edição de pergunta da FAQ ................ 46
Figura 28 – Página de pesquisa de registos de conhecimento .............................. 46
Figura 29 – Resultados de pesquisa de registos de conhecimento ........................ 47
Figura 30 - Formulário de registo de conhecimento ............................................. 48
Figura 31 – Lista dos registos de conhecimento do utilizador autenticado .......... 49
ix
Figura 32 – Registo de conhecimento para aprovar .............................................. 49
Figura 33 – Registo de conhecimento para aprovação.......................................... 51
Figura 34 – Pop-up de rejeição de registo de conhecimento ................................ 51
Figura 35 - Registo de conhecimento para validar................................................ 52
Figura 36 – Histórico do registo de conhecimento ............................................... 53
Figura 37 – Registos de conhecimento e activos associados ................................ 53
Figura 38 – Janela de pop-up para adicionar activos ao registo de conhecimento 54
Figura 39 – Registo de conhecimento para classificação...................................... 56
Figura 40 – Lista de perguntas mais frequentes .................................................... 57
Figura 41 – Lista de categorias de 1º, 2º e 3º nível ............................................... 58
Figura 42 – Janela de popup para a criação/edição de categorias ......................... 59
Figura 43 – Lista de serviços para a categorização ―Geral – Geral - Geral‖ ........ 59
Figura 44 – Página de criação/edição de um serviço ............................................ 60
Figura 45 – Lista de pacotes de serviços ............................................................... 61
Figura 46 – Página de criação/edição de um pacote de serviços .......................... 61
Figura 47 – Lista de campos adicionais ................................................................ 62
Figura 48 – Página de criação/edição de campos adicionais ................................ 62
Figura 49 – Lista de grupos de suporte de pedidos de serviço.............................. 63
Figura 50 – Página de criação/edição dos grupos de suporte................................ 64
Figura 51 – Tabela de regras de encaminhamento de pedidos de serviço ............ 64
Figura 52 – Lista de estados dos pedidos de serviço ............................................ 65
Figura 53 – Janela de popup de criação/edição de um estado ............................... 66
Figura 54 – Matriz de prioridade de pedidos de serviço ....................................... 66
Figura 55 – Catálogo de serviços do menu lateral ................................................ 67
Figura 56 – Menu do Catálogo de serviços ........................................................... 67
Figura 57 – Formulário de registo de um pedido de serviço................................. 68
Figura 58 – Pedidos de serviço para tratar ............................................................ 69
Figura 59 – 1º separador da página do pedido de serviço em resolução ............... 71
Figura 60 - 2º separador da página do pedido de serviço em resolução ............... 72
Figura 61 – Popup de adição/edição de tarefas ..................................................... 72
Figura 62 – Popup de mudança de estado ............................................................. 73
Figura 63 – Popup de geração de pedido de release ............................................. 74
Figura 64 - 2º separador da página do pedido de serviço em resolução ............... 75
Figura 65 – Janela de encaminhamento do helpdesker ......................................... 76
x
Figura 66 – Lista de pedidos de serviço para encaminhar .................................... 77
Figura 67 - Janela de encaminhamento do Incident Manager .............................. 78
Figura 68 – Lista de perguntas do inquérito de satisfação .................................... 79
Figura 69 – Lista de níveis de satisfação. ............................................................. 79
Figura 70 – Inquérito de satisfação ....................................................................... 79
xi
Lista de Acrónimos
BPMS – Business Process Management Suite
CA – Computer Associates;
CI – Configuration Item;
CM – Change Management;
CMDB – Configuration Management Database;
CMS – Configuration Management System;
CSI – Continual Service Improvement;
FAQ – Frequently Asked Questions
FCUL – Faculdade de Ciências da Universidade de Lisboa;
GMS – Global Management Solutions;
HP – Hewllet – Packard;
IM – Incident Manager;
ISM – Information Security Management;
ITIL – Information Technology Infrastructure Library;
ITSCM – Information Technology Service Continuity Management;
ITSM – Information Technology Service Management;
itSMF – The IT Service Management Forum;
KEDB – Know Error Database;
KM – Knowledge Management;
OGC – Office Government Commerce;
PBI – Product Backlog Item;
PEI – Projecto em Engenharia Informática;
RDM – Release & Deployment Management;
SACM – Service Asset & Configuration Management;
SCM – Service Catalogue Management;
SDM – Service Desk Management;
SDP – Service Design Package;
SKMS – Service Knowledge Management System;
SLA – Service Level Agreement;
SLM – Service Level Management;
SLP – Service Level Package; e
TI – Tecnologia de Informação.
xii
1
Capítulo 1
Introdução
O presente capítulo introduz o projecto desenvolvido no âmbito da disciplina de
PEI do 2º ano, com vista ao desenvolvimento da tese de Mestrado em Engenharia
Informática. O projecto teve início no dia 02 de Setembro de 2010 na empresa Maksen,
com o objectivo de analisar e desenvolver uma solução de Service Desk Management,
segundo as melhores práticas advogadas pela ITIL® v3, tendo o seu término acontecido
a 31 de Maio de 2011.
Ao longo deste capítulo serão descritos os objectivos deste projecto, o seu âmbito
de actuação, contribuições em organizações/empresas de consultoria, a instituição onde
foi desenvolvido, a organização do projecto, e por fim, a estrutura do presente
documento.
1.1 Motivação
A motivação geral para a adopção de soluções de SDM está associada à cada vez
maior complexidade dos ambientes de TI distribuídos que, aliada ao aumento da
dependência da tecnologia por parte das empresas, criou os alicerces para uma sucedida
gestão de serviços. Os helpdesks reactivos e autónomos já não são suficientes. Para
satisfazer as exigências empresariais em termos de serviços de tecnologia fiáveis, as
empresas de TI necessitam de processos de gestão de serviços integrados que vejam os
componentes da tecnologia como partes inter-relacionadas dos serviços de TI prestados
às empresas.
1.2 Objectivos
O objectivo deste projecto consistiu na implementação de uma ferramenta de
suporte de TI aberta que permita uma utilização global, regional e/ou local, quer pela
2
Maksen, quer pelos seus clientes. A solução final deve actuar como um único ponto de
contacto para os pedidos de utilizador, incidentes submetidos pelo mesmo e incidentes
gerados nas infra-estruturas. Os seus workflows ITIL® flexíveis e com as melhores
práticas deverão acelerar a restauração do serviço normal, ajudar a prevenir futuros
eventos com impacto adverso no negócio e aumentar a eficiência dos recursos de TI.
Estes workflows devem capturar e localizar relações do início do incidente à
correlação do problema, radicar a investigação da causa, dos erros conhecidos e pedidos
de alterações. A solução inclui um knowledge management que oferece authoring rico,
pesquisa de linguagem natural e serviço autónomo para reduzir o volume de incidentes
e permitir uma maior resolução de suporte de primeiro nível. A CMDB1 refere quais os
serviços empresariais e os utilizadores afectados e ajuda a diagnosticar a causa através
da visibilidade para as dependências da infra-estrutura.
1.3 Âmbito de actuação
No âmbito deste projecto, pretendeu-se desenvolver uma solução que
automatizasse e desse resposta aos processos de Service Desk, Gestão de Incidentes,
Gestão de Problemas, Gestão de Alterações e Gestão de Activos e Serviços. Pretendeu-
se ainda que esta solução unificasse uma base de dados de gestão de configuração
(CMDB), com um modelo de dados, plataforma de workflow e interface do utilizador.
Para a solução supramencionada foram implementados 8 processos de ITIL® v3 –
Incident Management, Problem Management, Change Management, Knowledge
Management, Release & Deployment Management, Request Fulfillment, Service Asset
& Configuration Management (SACM) e Service Level Management (SLM), dos quais
os seis primeiros foram o alvo deste projecto.
O desenvolvimento desta aplicação foi efectuado numa plataforma de
desenvolvimento rápido (OutSystems Agile Platform) com uma metodologia de
desenvolvimento SCRUM Agile. Os outputs e processos de desenvolvimento do
projecto encontram-se enquadrados no âmbito da cadeira de Projecto de Engenharia
Informática da FCUL.
1 Configuration Management Database representa a configuração autorizada de componentes
significantes do ambiente de TI. A CMDB regista os itens de configuração (CI), detalhes sobre atributos
importantes e relações entre CIs.
3
As actividades desenvolvidas, no contexto do projecto, foram: organização e
planeamento de projecto, definição de requisitos, desenho do modelo conceptual,
especificação funcional e técnica, configuração/implementação, formação de
utilizadores e testes de aceitação, e roll-out e documentação, bem como actividades
transversais de gestão de Projecto e controlo de qualidade.
A orientação e coordenação académica deste processo foram desempenhadas pelo
Prof. Doutor João Carlos Balsa da Silva, docente do Departamento de Informática da
FCUL, e Eng. Miguel Ramos, Operational Manager da Maksen.
1.4 Contribuição
A solução final tem como objectivos ajudar a aumentar a disponibilidade dos
sistemas críticos das empresas de consultoria ou clientes destas, acelerando a resolução
de incidentes e problemas, bem como reduzir a duração e os volumes das chamadas de
suporte.
Além disso, pretende-se aumentar a produtividade dos agentes de service desks,
apoiar os recursos de TI e os utilizadores, aumentar a disponibilidade das infra-
estruturas de TI das empresas e encaminhar rapidamente os pedidos para o suporte
correcto.
Por fim, com a solução desenvolvida deseja-se identificar as causas core para
eliminar os incidentes recorrentes e estabelecer uma solução comum para a comunidade
de consultoria ou clientes desta, de suporte de TI que permita uma utilização de forma
global, regional e/ou local.
1.5 Formações e arranque do projecto
Como mencionado no Relatório Preliminar [25], numa fase inicial definiu-se o
plano das tarefas a executar ao longo do projecto e o seu modelo de acompanhamento,
bem como se realizaram formações na framework ITIL®, através da plataforma e-
learning SkillPort, e na plataforma de desenvolvimento OutSystems.
A primeira das formações dividiu-se em duas partes, ―ITIL® v2 Foundation‖ e
―IT Infrastructure Library (ITIL) v3 Foundation Syllabus v4.2 exam‖, referentes às
frameworks ITIL® v2 e ITILv3, respectivamente.
4
Por outro lado, a formação de OutSystems decompôs-se em três cursos:
―OutSystems Developer – Course 1‖, ―OutSystems Developer – Course 2‖ e
―OutSystems Developer – Course 3.
Após as formações e o levantamento dos requisitos da solução implementada no
âmbito deste projecto, procedeu-se a uma análise comparativa de soluções SDM best-of-
breed de mercado, sendo esta abordada no quarto capítulo.
No decorrer da primeira fase do projecto, realizou-se uma reunião de Kick-Off, a
qual pretendeu oferecer aos seus intervenientes uma visão geral da solução
desenvolvida. Deste modo, referiram-se os objectivos, o âmbito da actuação, o
planeamento e organização, bem como o modelo de acompanhamento do projecto,
identificando-se os factores críticos para o seu sucesso.
1.6 Enquadramento Institucional
O projecto foi realizado em parceria com a Maksen, inicialmente GMS – Global
Management Solutions. Esta instituição foi criada no início de 2003 e centra a sua
actividade na prestação de serviços de consultoria de negócio, de sistemas de
informação e de engenharia/redes de comunicações.
Em termos globais, a Maksen conta com uma rede global e acesso a mais de 1.000
profissionais, que contribuem com as suas competências, talento, motivação e sentido
de missão para a criação de valores dos seus clientes, trabalhando em conjunto com
estes, de forma a superar, sempre que possível, os objectivos estabelecidos. O seu
crescimento e reconhecimento no mercado ao longo dos anos devem-se a uma
consultoria inovadora, perseverante e com uma orientação muito vincada para ―fazer
acontecer‖.
As boas práticas de gestão da Maksen têm vindo recorrentemente a ser
distinguidas pela multinacional Great Place to Work Institute, incluindo prémios
especiais como ―Melhor empresa Portuguesa para Trabalhar‖ (2010), ―Melhor empresa
para Jovens‖ (2010 e 2011) e ―Melhor empresa para Executivos‖ (2009). Além destas
distinções, a Maksen é a primeira consultora em Portugal a possuir simultaneamente as
certificações ISO 9001 e 27001.
Para fazer face às exigências do mercado, a Maksen é composta por três divisões
complementares:
5
Consulting: centra a sua actividade na prestação de serviços de consultoria
estratégica, operacional e de sistemas de informação, sendo especialista,
nomeadamente, em temas de redefinição estratégica de negócios,
transformação empresarial e processual e análises económico-financeiras;
Engineering: sendo a área de negócio vocacionada para a engenharia e
redes de comunicações, os seus serviços baseiam-se em arquitecturas de
sistemas e redes, para além da sua implementação e integração
tecnológica;
IT Management: a oferta desta divisão consiste essencialmente na
prestação de serviços continuados de consultoria e outsourcing, no âmbito
da evolução tecnológica e exploração operacional de plataformas e
sistemas de informação, tendo como principal factor diferenciador os
conhecimentos técnicos especializados e a existência de parcerias efectivas
com as equipas tecnológicas dos clientes.
1.7 Organização do Projecto
Para este projecto reuniu-se um conjunto de profissionais com conhecimento e
experiência nas áreas abrangidas, propondo a afectação de uma equipa multidisciplinar
de elementos da Maksen e FCUL, com competências de intervenção necessárias.
6
As principais responsabilidades desses elementos e respectivos comités são os
seguintes:
Comité de Acompanhamento – aprovação dos produtos intermédios e
finais do Projecto, confirmação da adequação do trabalho desenvolvido
face aos objectivos definidos e coordenação e facilitação da integração das
decisões de carácter estratégico com os princípios gerais de gestão;
Comité Operacional – validação dos produtos intermédios e finais do
Projecto e da adequação do trabalho desenvolvido face aos objectivos
definidos e coordenação da Equipa de Projecto;
Sponsor de Projecto – dinamização do Projecto internamente,
contribuindo de forma determinante para o sucesso da solução na resposta
às necessidades específicas;
Controlo de Qualidade – é política da Maksen, para a realização de
qualquer Projecto, incluir nas equipas de trabalho uma figura de controlo
da qualidade, que tem como responsabilidade principal validar os outputs
do Projecto face às expectativas e necessidades; e
Gestão de Projecto – disponibilização dos recursos humanos, logísticos,
técnicos e funcionais da Maksen necessários ao desenvolvimento do
Projecto, intermediação de contactos e reuniões necessárias ao
Figura 1 – Organograma do projecto
7
desenvolvimento do Projecto e participação na execução de tarefas
planeadas com a restante equipa de trabalho; e
Equipa Core de Projecto – execução das actividades de Projecto
planeadas ao nível da Gestão de Projecto. Como anteriormente
mencionado, este projecto foi realizado em parceria com o PEI do aluno
Ricardo Reis, tendo estado a seu cargo, para além dos quatro processos
comuns, os processos de Request Fulfillment e Service Level Management
(SLM).
1.8 Estrutura do documento
O presente relatório encontra-se estruturado em sete capítulos:
Capítulo 2 – Metodologia e Planeamento: tem como objectivo descrever
as metodologias e ferramentas que suportam o desenvolvimento da
solução de SDM, bem como o plano de trabalhos;
Capítulo 3 – Contexto teórico dos processos implementados: descrição
teórica dos seis processos implementados no âmbito deste PEI;
Capítulo 4 – Análise do problema e desenho da solução: referência ao
trabalho relacionado com a solução desenvolvida, avaliando soluções best-
of-breed de mercado face aos requisitos disponibilizados pela Maksen, aos
requisitos implementados e ao modelo conceptual da solução;
Capítulo 5 – Solução implementada: descrição detalhada da
implementação dos processos foco do projecto e dos testes efectuados aos
mesmos;
Capítulo 6 – Discussão: tem como objectivo apresentar uma análise
crítica e factores críticos de sucesso ao trabalho; e
Capítulo 7 – Bibliografia: indicação das referências bibliográficas usadas
para a elaboração deste relatório.
8
Capítulo 2
Metodologia e Planeamento
O desenvolvimento da solução no âmbito deste Projecto obedeceu a standards
metodológicos e respeitou as melhores práticas advogadas pelo itSMF.
A implementação desta solução foi feita na plataforma OutSystems Agile
Platform, pela facilidade de desenvolvimento e tempo de projecto reduzido, adoptando
a metodologia advogada pelo fabricante do software, a SCRUM Agile Methodology.
2.1 Framework ITIL®
Information Technology Infrastructure Library (ITIL®) [16] é a abordagem mais
adoptada para a gestão de serviços de TI, fornecendo uma framework prática para
identificação, planeamento, entrega e suporte de serviços TI para o negócio.
A framework foi desenhada e desenvolvida no final da década de 1980 pela
Central Computer and Telecommunications Agency (CCTA) e actualmente está sob a
custódia da OGC (Office for Government Commerce) da Inglaterra. Em 2000/2001, com
o intuito de tornar a ITIL® mais acessível, a versão inicial foi revista e substituída pela
ITIL® v2 (versão 2), que consiste em sete volumes, tornando-se a base padrão para a
norma BS 15000, um anexo da norma ISO 20000. Mais recentemente, em 2007, foi
lançada a versão 3 da ITIL® (também conhecida como a ITIL Refresh Project) que
consiste em vinte e seis processos e funções, agrupados em cinco volumes e arranjados
sobre os conceitos de uma estrutura de ciclo de vida dos serviços.
Esta framework defende que os serviços TI devem estar alinhados com as
necessidades do negócio e sustentar os principais processos, dando orientações às
organizações sobre o modo de usar as TI para facilitar a mudança nos negócios, a sua
transformação e o seu crescimento. A ITIL® fornece ainda compreensivas orientações
9
de boas práticas para todos os aspectos de ―end-to-end‖ de service management,
padronizando a totalidade do espectro de pessoas, processos e produtos.
Por outro lado, fornece uma descrição detalhada sobre importantes práticas de TI
com checklists, tarefas e procedimentos que uma organização de TI pode adaptar às suas
necessidades.
A framework ITIL® deve ser implementada seguindo uma abordagem ―adopt and
adapt‖, de modo a que processos efectivos e apropriados sejam postos em prática. A sua
adopção pode oferecer aos utilizadores uma enorme gama de benefícios que incluem:
Melhoria de serviços de TI;
Custos reduzidos;
Satisfação do cliente melhorada através de uma abordagem mais
profissional na prestação do serviço;
Melhoria da produtividade;
Melhoria no uso das habilidades e experiência; e
Melhoria da prestação de serviços a terceiros.
Para entender o que é a gestão de serviços, é necessário perceber o que são
serviços. Estes são um meio de entregar valor aos clientes, facilitando os resultados que
estes desejam obter, sem assumirem os custos e riscos específicos.
Assim, pode-se afirmar que a gestão de serviços é o que permite que uma
organização compreenda os serviços que presta, garanta que os serviços realmente
facilitam os resultados que os seus clientes querem obter, compreenda o valor dos
serviços, e perceba e trate todos os custos e riscos associados a esses serviços.
2.1.1 ITIL® v3
A framework ITIL® v3 [12] (também conhecida como ITIL® Refresh Project) é
uma nova abordagem, com base no ciclo de vida dos serviços e uma nova estrutura,
usada para diferenciar as práticas essenciais do modelo com novos processos, tendo
uma visão integrada de TI, negócios e fornecedores.
Existem dois conceitos chaves sobre a versão 3 da ITIL®, entre eles:
Serviço de TI – ―Um serviço é um meio para entregar valor aos clientes,
propiciando os resultados que eles queiram alcançar sem que eles tenham
que assumir custos e riscos específicos‖; e
10
Gestão de Serviços de TI – ―Gestão de serviços é um conjunto de
capacidades organizacionais específicas (processos, métodos, funções,
papéis e actividades) para prover valor aos clientes sob a forma de
serviços‖.
A figura 2 mostra o ciclo de vida de um serviço de TI, sendo que cada uma das
fases desse ciclo é descrita de seguida:
Service Strategy [8] – descreve a primeira fase do ciclo de vida de um
serviço e consiste em assegurar que as organizações estão em posição de
lidar com os custos e riscos associados ao Portfolio de Serviços. As
decisões tomadas, no que diz respeito à Service Strategy, têm
consequências a longo prazo, incluindo aquelas de efeito retardado.
Ainda nesta fase, os requisitos de negócio são identificados e os resultados
esperados são acordados num SLP (Service Level Package), que
representa um determinado nível de utilidade pública e de garantia para
um determinado pacote de serviços, sendo desenhado para atender as
necessidades de um determinado padrão de negócio.
A estratégia de serviço de qualquer organização deve ser baseada num
conhecimento fundamental de que os seus clientes não compram produtos,
mas apenas compram a satisfação de necessidades específicas. Portanto,
para serem bem sucedidos, os serviços prestados devem ser percebidos
Figura 2 – Ciclo de vida um serviço
11
pelo cliente para entregar valor suficiente sob a forma de resultados que
esse cliente quer atingir;
Service Design [7] – Service Design é a segunda etapa de todo o ciclo de
vida do serviço e um elemento importante dentro do processo de alteração
de negócio. O papel desta etapa dentro do processo de alteração de
negócio, pode ser definido como o desenho de apropriados e inovativos
serviços de TI, incluindo as suas arquitecturas, processos, políticas e
documentação, para atender às actuais e futuras exigências do negócio
acordado.
Com a ITIL®, o trabalho de desenhar um serviço de TI é agregado num
simples pacote de desenho de serviços (Service Design Package - SDP),
que define todos os aspectos de um serviço de TI e os requisitos de cada
etapa do seu ciclo de vida, sendo produzido com um catálogo de serviços.
Esta etapa da ITIL® v3 inclui os processos de ―Service Level
Management‖ (SLM), ―Capacity Management‖, ―Availability
Management‖, ―IT Service Continuity Management‖ (ITSCM), ―Service
Security Management‖, ―Information Management‖, ―Supplier
Management‖ e ―Service Catalogue Management‖ (SCM), tendo cinco
aspectos individuais, entre eles:
o Novas soluções de serviço ou alteradas;
o Sistemas de gestão de serviço e ferramentas, especialmente o
Portfolio de Serviços;
o Arquitecturas de tecnologia e sistemas de gestão;
o Processos, papéis e capacidades; e
o Métodos de medida e métricas.
Verifica-se que um bom desenho de serviço está dependente da utilização
efectiva e eficiente dos ―Four P’s of Design‖:
o Pessoas (People) - as pessoas, habilidades e competências
envolvidas no fornecimento de serviços de TI;
o Produtos (Products) - a tecnologia e sistemas de gestão usados na
entrega de serviços de TI;
12
o Processos (Processes) - os processos, papéis e actividades
envolvidas no fornecime nto de serviços de TI; e
o Sócios (Partners) - os vendedores, fabricantes e fornecedores
usados na assistência e suporte do fornecimento de serviços de TI.
Service Transition [9] – descreve a terceira fase do ciclo de vida de um
serviço, na qual o seu papel é a entrega de serviços necessários ao negócio
para uso operacional. A Service Transition oferece isto ao receber o SDP
da etapa anterior, entregando-o na etapa Service Operation sempre que um
elemento necessário é exigido para a operação contínua e de suporte desse
serviço.
O foco desta fase é a implementação de todos os aspectos do serviço, não
apenas na aplicação e como ela é usada em circunstâncias ―normais‖,
sendo necessário assegurar que a mesma pode operar em circunstâncias
extremamente imprevisíveis ou anormais, e que o suporte para falhas ou
erros está disponível. A implementação do serviço é acompanhada, testada
e validada, e o SKMS2 (Service Knowledge Management System) é
actualizado com as informações do ambiente de produção.
Esta etapa está organizada pelos processos de ―Change Management‖,
―Service Asset and Configuration Management‖ (SACM), ―Knowledge
Management‖, ―Release and Deployment Management‖, ―Transition
Planning and Support‖, ―Service Validation and Testing‖ e ―Evaluation‖.
Service Operation [11] – representa a quarta etapa do ITIL® v3 e cujo
propósito é oferecer níveis de acordados de serviço para utilizadores e
clientes, e gerir as aplicações, tecnologia e infra-estrutura que suportam a
oferta dos serviços. É apenas durante esta etapa do ciclo de vida que os
serviços realmente acrescentam valor ao negócio, e é sua responsabilidade
assegurar que este valor seja entregue.
Aqui, o serviço é mantido em funcionamento de acordo com o SLA
(Service Level Agreement) estabelecido, para fornecer os resultados
esperados.
2 O SKMS é o repositório central de dados da organização de TI, informação e conhecimento.
13
Esta etapa do ITIL® v3 é composta pelos processos de ―Event
Management‖, ―Incident Management‖, ―Request Fulfillment‖, ―Access
Management‖, ―Problem Management‖, e pelas funções de ―Operation
Management‖, ―Service Desk‖, ―Application Management‖, ―Technical
Management‖ e ―IT Operations Management‖.
Continual Service Improvement [10] - a finalidade da fase Continual
Service Improvement (CSI) é manter o valor para os clientes através da
avaliação contínua e o aumento da qualidade dos serviços e da maturidade
geral do ciclo de vida do ITSM e dos processos subjacentes. De modo a
gerir as melhorias, o CSI deve definir claramente o que deve ser
controlado e medido, e identificar as oportunidades de melhoria do
serviço.
A última etapa da ITIL® v3 inclui os processos de ―Service
Measurement‖, ―Service Reporting‖ e ―Service Improvement‖.
2.2 Plataforma de desenvolvimento - OutSystems
A estruturação das organizações tendo em conta os seus processos de negócio
tornou-se uma abordagem recorrente por permitir melhorar cada vez mais os processos
internos às organizações, cortando custos e maximizando a eficácia. Desta forma
aumentou o interesse na área da gestão de processos de negócio.
O principal modo pelo qual os processos oferecem a flexibilidade desejada pelas
organizações é a possibilidade de executar processos, tornando imediatamente reais as
alterações desenvolvidas durante a fase de modelação. Isto permite aos elementos das
organizações alterarem e melhorarem os seus processos sempre que necessário e ver as
suas alterações repercutidas na organização, podendo voltar a ser alteradas caso
necessário. Em última análise a fase de execução é essencial para a flexibilidade
necessária para as organizações se manterem de acordo com as inconstantes condições
de mercado.
Com o aumento do interesse na gestão de processos de negócio, surgiram várias
novas tecnologias que pretendem abordar a execução de processos de negócio. Surgiram
novas linguagens, denominadas linguagens de execução de processos de negócio, que
permitem detalhar um processo de negócio para que este possa ser executado sobre esta
14
linguagem, surgiram tecnologias úteis para o desenvolvimento de componentes de
execução de processos e surgiu um novo conjunto de ferramentas, as BPMS’s, que
abordam a execução de processos e todas as outras fases que compõem a gestão de
processos de negócio.
As BPMS’s oferecem um novo método para gerir os processos, reunindo numa
única ferramenta todas as actividades inerentes à gestão dos processos de negócio numa
organização. A principal vantagem destas ferramentas prende-se com a facilidade de
modelação e execução dos processos de negócio que se pretendem gerir e que era
desconhecida até ao momento do seu aparecimento. Com os recentes avanços nas
tecnologias de informação, têm começado a surgir novas ferramentas, com métodos de
desenvolvimento ágeis, que oferecem uma flexibilidade extrema nas suas aplicações.
Estas novas ferramentas permitem que as aplicações desenvolvidas sejam
facilmente alteradas, sempre que necessário, para fazer face às alterações da
organização. Embora baseadas em outras tecnologias, o resultado final destas
ferramentas é de certa forma semelhante ao da gestão de processos de negócio, ou seja,
conseguem dotar as organizações da flexibilidade necessária para fazer face às
condições de negócio actuais.
O facto de actualmente as organizações se encontrarem estruturadas de acordo
com os seus processos de negócio faz com que, apesar de bastante ágeis, estas
ferramentas não estejam alinhadas com as organizações. Embora as aplicações
desenvolvidas sejam bastante ágeis, não permitem endereçar os processos de negócio
que representam o modo como actualmente as organizações actuam, evoluem e em
última análise, são geridas.
A OutSystems [13] é um exemplo de uma empresa que comercializa uma destas
novas ferramentas baseadas em metodologias de desenvolvimento ágeis. Junto dos seus
clientes, surgiu a necessidade do suporte de processos de negócio de modo a
desenvolver aplicações mais orientadas ao negócio, havendo assim necessidade de dotar
a plataforma com suporte para as actividades inerentes à gestão de processos de
negócio, onde se enquadra a execução.
15
2.2.1 Visão geral
A plataforma OutSystems destina-se principalmente ao desenvolvimento de
aplicações empresariais com uma estrutura web-based3. Além disso, tem suporte para
redes móveis e de e-mail e permite a integração com os sistemas legacy4 normalmente
existentes nas organizações actuais. A grande diferença entre esta plataforma e outras
ferramentas semelhantes assenta na metodologia de desenvolvimento proposta e na
flexibilidade apresentada.
Apoiando-se na metodologia ágil, a OutSystems promove uma aproximação built-
to-change, na qual, independentemente da fase do ciclo de vida das aplicações, novas
funcionalidades podem ser facilmente adicionadas, erros corrigidos e comentários
analisados, com riscos reduzidos e sem graves consequências para o negócio.
A plataforma OutSystems, por se apoiar nessa metodologia ágil, aborda a actual
necessidade de rápido desenvolvimento e contínua mudança das aplicações
desenvolvidas, permitindo a criação de aplicações que respeitem, quer as necessidades
tecnológicas, quer as necessidades de negócio das organizações. Desta forma, esta
metodologia surgiu da adaptação dos conceitos da SCRUM Agile Methodology5, às
características da plataforma criada.
Esta plataforma de desenvolvimento aposta num estilo de programação visual
drag’n’drop sendo possível a criação de aplicações ―sem ter de se escrever qualquer
linha de código‖. Desde o desenho do modelo de dados, criação de Interfaces, definição
de lógica de negócio ou instalação, tudo pode ser feito visualmente.
3 Sistemas web-based são aqueles executados através de páginas, tais como Firefox ou Internet
Explorer. 4 É uma tecnologia antiga que continua a ser usada, normalmente porque ainda continua a
funcionar para as necessidades do utilizador, apesar de nova tecnologia ou métodos mais eficazes de
executar uma tarefa já estarem disponíveis. 5 Está referido na secção 2.3
16
Figura 3 – Descrição da plataforma ágil OutSystems
A Figura 3 representa a relação entre os componentes base com o Hub Server,
descrita na secção 2.2.2.
2.2.2 Componentes da plataforma OutSystems
A plataforma OutSystems é constituída por quatro componentes que suportam
toda a criação, alteração e manutenção de aplicações web:
Service Studio - componente de desenvolvimento visual, destinado à
criação, alteração e instalação das aplicações web desenvolvidas,
denominadas por eSpaces6. Este componente permite o desenvolvimento
de interfaces de utilizador, modelo de dados, web services, regras de
segurança, integração com componentes e agendamento de actividades.
Através de um processo 1-Click Publish, o qual verifica, guarda, efectua o
upload no componente de execução, compila e instala a aplicação. O
componente Service Studio é um ambiente de desenvolvimento,
tecnologicamente independente da infra-estrutura que aloja as aplicações,
e baseado em ―.Net‖ ou Java, sendo ―.oml7‖ a extensão dos ficheiros
construídos.
Integration Studio - componente que permite criar componentes
personalizados (extensões) para integrar com diversos sistemas legacy.
Estas extensões disponibilizam módulos, codificados em C# ou Java, e
6 Uma aplicação ou parte de aplicação que implementa um conjunto de serviços reunidos num
único projecto. 7 OutSystems Markup Language.
17
acesso a base de dados externas (que não a do Hub Server) que podem ser
reutilizados pelos eSpaces. Uma vez publicadas, estas extensões podem ser
utilizadas na componente de desenvolvimento como blocos visuais para
permitir a interacção das aplicações com os sistemas existentes, sendo
―xif‖ 8
a extensão dos ficheiros produzidos pelo Integration Studio.
Service Center - permite a monitorização e a gestão das aplicações,
oferecendo acesso centralizado à informação relativa a todos os recursos
da plataforma, tais como versões de aplicações, auditorias, monitorização
e criação de relatórios em tempo de execução. Com estas funcionalidades
torna-se mais fácil o acompanhamento e o controlo da execução das
aplicações.
Hub Server - componente central responsável pela execução. Este
orquestra todas as compilações, instalações e qualquer actividade que
decorra em tempo de execução, sendo o local onde todos os objectos
desenvolvidos necessitam de ser publicados antes da sua utilização. Neste
componente, os eSpaces são traduzidos para código ―.Net” ou Java,
compilados e disponibilizados ao utilizador final.
As empresas ou prestadores de serviços operam centralmente sobre o Hub Server
para suportar o desenvolvimento de aplicações empresariais.
8 Extension and Integration Framework.
Figura 4 – Descrição da plataforma ágil.
18
A figura 4 apresenta o percurso efectuado pelas aplicações e extensões até ao
repositório de dados para depois serem disponibilizados. Os eSpaces são criados no
Service Studio e as extensões no Integration Studio.
2.3 Metodologia de desenvolvimento - SCRUM
A metodologia usada para este projecto foi a SCRUM Agile Methodology[15].
Esta consiste num processo iterativo e incremental para o desenvolvimento do produto e
para a gestão de tarefas. A agilidade que suporta esta metodologia de gestão e
planeamento, traz uma nova dimensão de capacidade de resposta, adequabilidade,
eficácia e eficiência na gestão actual dos processos.
A figura 5 ilustra como funciona o SCRUM. Depois do Product backlog e do
Sprint backlog, descritos na secção 2.3.3, ocorrem iterações de 2 a 4 semanas, com
reuniões diárias, para que no final de cada uma das iterações exista como resultado um
produto para demonstração.
2.3.1 Papéis
A SCRUM Agile Methodology é um esqueleto do processo que contém grupos de
práticas e papéis predefinidos, onde se destacam:
Scrum Master: papel sem responsabilidade por gerir a equipa, mas sim
por garantir que não existe impedimentos para que se consiga alcançar os
objectivos do sprint (referido na secção 2.3.4). Caso existam várias
equipas, este é ainda responsável por garantir os interesses da sua equipa
Figura 5 – SCRUM Agile Methodology
19
nas reuniões com os restantes Scrum Masters, representando também a sua
equipa e os seus interesses perante o Product Owner.
Product Owner: papel responsável pelo produto e com maior
responsabilidade. Tem como tarefas definir, priorizar e estimar todas as
funcionalidades, através do preenchimento do product backlog. Este
também é o responsável por comunicar à equipa os interesses dos
stakeholders, efectuar reuniões de planeamento e demonstrar as entregas
efectuadas.
Team Member: o papel com a responsabilidade de desenvolver e entregar
as funcionalidades do produto. As equipas organizam-se entre elas para
conseguirem da melhor maneira alcançar os objectivos do sprint.
2.3.2 Reuniões
Esta metodologia compreende um conjunto de reuniões com o intuito de definir as
actividades a realizar, monitorizar o seu progresso e manter todos os envolvidos ao
corrente desse progresso. Entre as reuniões[14] associadas a esta metodologia,
destacam-se:
Sprint Planning Meeting: reunião realizada antes do início de cada sprint
(descrito na secção 2.3.4), e onde o Product Owner e a equipa negoceiam
que requisitos serão tratados pela equipa naquele sprint. Nesta reunião, o
Product Owner decide que requisitos são de elevada prioridade para a
release e quais irão gerar o maior valor de negócio, tendo a equipa o poder
de afastar as preocupações ou impedimentos.
Daily Scrum Meeting: reunião diária entre a equipa de trabalho, com o
objectivo de perceber o estado do projecto. Durante esta reunião, cada
membro da equipa responde a 3 questões: ―O que fiz desde a última
reunião?‖, ―O que vou fazer até à próxima reunião?‖ e ―Quais os
impedimentos que prevejo até à próxima reunião?‖.
Sprint Review Meeting reunião onde é revisto o trabalho completo e o
trabalho não completo. O trabalho completo é apresentado aos
stakeholders, através de demos.
20
Sprint Retrospective Meeting é a reflexão efectuada no final de cada
sprint sobre a forma de como este correu, identificando possíveis
melhorias sobre forma de trabalhar. Além disso, o SCRUM Master poderá
identificar restrições ao progresso de equipa e trabalhar na sua mitigação.
2.3.3 Artefactos
A metodologia SCRUM relaciona-se com um conjunto de artefactos[18] úteis ao
desenvolvimento de uma solução. Os artefactos são:
Product backlog ou Scrum backlog: documento de análise detalhado que
apresenta todos os requisitos para um sistema, projecto ou produto. De
uma maneira mais simples, este termo podia ser descrito como sendo uma
lista de tarefas a realizar, expressa em ordem de prioridade com base no
valor comercial que cada peça de trabalho irá gerar. Filosoficamente, o
scrum backlog é o motor do negócio, decompondo a visão geral do
produto em incrementos de trabalho que se podem gerir, chamados de
Product Backlog Items (PBIs). Apesar de ser da responsabilidade da
equipa a conclusão do trabalho, o Product Owner é o único que consegue
priorizar o mesmo num scrum backlog.
Sprint backlog: representa o resultado das planning meetings.
Essencialmente, é uma lista de tarefas que a equipa precisa de completar
durante o sprint, a fim de transformar um conjunto seleccionado de itens
do product backlog num aumento da funcionalidade. Ao contrário dos
PBIs, as tarefas do sprint backlog têm um tempo estimado, sendo
responsabilidade das equipas manter o sprint backlog actualizado. Este
artefacto mostra o que está completo e o que falta fazer, ajudando os
membros da equipa a realizarem uma daily scrum meeting eficaz.
2.3.4 Sprint
Esta metodologia é destinada a projectos compostos por uma sequência de
iterações (sprints), as quais poderão ter uma duração de duas a quatro semanas, sendo
que, no final de cada iteração, um conjunto de funcionalidades do produto final deverá
ser apresentado.
21
Em cada sprint, é implementado um conjunto de requisitos, descriminados no
sprint backlog, o qual foi determinado durante a reunião de planeamento do sprint.
Durante o mesmo, não é possível alterar esse conjunto de requisitos, uma vez que o
Product Owner deve respeitar a capacidade da equipa para criar o seu plano de acção,
não podendo sobrecarregá-la de mais trabalho até à reunião de planeamento do próximo
sprint.
Devido ao desenvolvimento das actividades ser timeboxed9, a iteração deve
terminar no tempo previsto. No entanto, se os requisitos não são implementados por
algum motivo, então são descartados e reconsiderados em futuras iterações.
Uma vez concluída cada iteração, a equipa realiza uma demonstração do software,
sendo que, no final de todas as elas, obtém-se um sistema com a totalidade das
funcionalidades implementadas, as quais foram sendo testadas, adaptadas e aprovadas
paralelamente com o seu desenvolvimento.
2.4 Plano de Trabalhos
Durante o tempo de estágio, o projecto encontrou complexidades relacionadas
com a logística do servidor, o incumprimento de requisitos e inexperiência no uso da
plataforma de Outsystems, o que levou a um atraso na entrega da solução final. A
existência de um plano de mitigação não foi suficiente para a resolução de todos os
obstáculos.
2.4.1 Plano de Trabalhos Inicial
De acordo com a solução implementada, é de seguida indicado o faseamento
inicialmente proposto para o projecto, organizado pelos componentes desenvolvidos.
9 Técnica comum de gestão de tempo em planeamento de projectos, onde o calendário é dividido
num número de períodos de tempo distintos (timeboxes), com cada parte a ter o seu próprio prazo,
orçamento e outputs.
22
O planeamento apresentado reflecte um calendário de ―alto nível‖ elaborado pela
Maksen, compreendido entre 02 de Setembro de 2010 e 31 de Maio de 2011, tendo
como referência os objectivos e âmbito mencionados no primeiro capítulo, bem como a
abordagem proposta para este projecto.
O projecto encontrava-se dividido em sete fases, distribuídas por três etapas. A
Etapa I – INPUT, compreendida entre o dia 02 de Setembro e meados de Novembro,
organizava-se em duas fases distintas, a ―Fase I - Organização e planeamento‖ e a ―Fase
II - Definição de requisitos‖.
De acordo com os métodos advogados pela SCRUM Agile Methodology, as fases
―Fase III – Desenho e modelo conceptual‖ e ―Fase IV – Especificação funcional e
técnica‖, referentes à Etapa II – CONCEPÇÃO, encontravam-se divididas em sprints
(de Novembro a Dezembro de 2010):
Sprint 1 – tinha a duração prevista de 3 semanas e compreendia as
actividades realizadas na Fase III;
Sprint 2 – a sua duração prevista era de 2 semanas e compreendia parte
das actividades da Fase IV; e
Sprint 3 – tal como a fase anterior, a sua duração prevista era de 2
semanas, compreendendo as restantes actividades da Fase IV.
A Etapa III – OUTPUT dividia-se nas fases ―Fase V – Configuração /
Implementação‖, ―Fase VI – Formação e testes de aceitação‖ e ―Fase VII – Roll-out e
Figura 6 – Calendário de “alto-nível”
23
documentação da solução‖, as quais se encontravam compreendidas entre Dezembro de
2010 e Maio de 2011.
2.4.2 Plano de Trabalhos Final
O planeamento final, apresentado na figura seguinte, reflecte o incumprimento por
completo da metodologia SCRUM Agile.
O planeamento final do projecto apresenta os últimos meses de estágio, que em
nada corresponde ao plano inicial. Na figura 7 é possível verificar que o projecto não foi
concluído dentro dos 9 meses de estágio, derrapando até ao mês de Julho.
A duração de 7 meses (Dezembro - Junho) da Etapa III – OUTPUT, em vez dos 5
meses (Dezembro - Abril) estipulados no plano inicial, causou o atraso na conclusão do
PEI. Para o atraso anteriormente mencionado, contribuíram vários factores, dos quais se
destacam o elevado número de requisitos a implementar, a falta de experiência no
desenvolvimento de aplicações na plataforma Outsystems, bem como alguns problemas
técnicos no servidor onde a aplicação estava a ser implementada.
Figura 7 – Planeamento final
24
Capítulo 3
Contexto teórico dos processos implementados
Este Projecto de Engenharia Informática constituiu na implementação de seis
processos disponibilizados pela ITIL® v3, no que diz respeito à solução de Service
Desk Management desenvolvida.
A figura 8 ilustra os processos disponibilizados pela ITIL® v3, suportados pelas
cinco fases do ciclo de vida de um serviço. Dos seis processos implementados neste
Projecto, os de Incident Management, Problem Management, Change Management e
Release & Deployment Management representam o tronco comum à solução a
desenvolver, e os de Knowledge Management e Request Fulfillment reflectem os
processos específicos deste PEI.
Figura 8 – Processos da ITIL® v3 implementados e respectivo mapeamento
25
Os processos acima mencionados foram integrados com outro projecto que
decorreu na Maksen, cujo foco principal era a implementação dos processos de Service
Asset & Configuration Management e Service Level Management no âmbito desta
solução.
De seguida serão apresentadas breves descrições sobre os processos comuns ao
outro projecto, e descrições detalhadas dos dois processos específicos do âmbito deste
projecto.
3.1 Knowledge Management
O Knowledge Management (KM)[9] é um dos processos da Service Transition, e
que abrange uma série de estratégias e práticas usadas numa organização para
identificar, criar, representar, distribuir e possibilitar a adopção de ideias e experiências.
Tais percepções e experiências incluem conhecimento, seja incorporado em indivíduos
ou incorporados nos processos organizacionais ou prática.
Tipicamente, o esforço do KM está focado nos objectivos organizacionais, tais
como melhorar o desempenho, a vantagem competitiva, a inovação, a partilha de lições
aprendidas, integração e melhoria contínua da organização. O uso deste processo pode
ajudar os indivíduos e grupos a partilharem conhecimento valioso, de modo a reduzir
trabalho redundante, o tempo de treino para novos empregados, a reter o capital
intelectual como rotatividade de colaboradores numa organização, e a se adaptar às
mudanças de ambientes e mercados.
Uma estratégia do KM envolve activamente a gestão do conhecimento. Em tal
caso, os indivíduos esforçam-se para codificar explicitamente o seu conhecimento num
repositório compartilhado de conhecimento, como uma base de dados, bem como
recuperar o conhecimento que eles necessitem que outros indivíduos tenham fornecido
ao repositório.
O coração deste processo é a estrutura Data-Information-Knowledge-Wisdom
(DIKW), tal como mostrado na figura 9. Data é um conjunto de factos discretos sobre
eventos. Information fornece contexto para os dados. Knowledge é composto por
experiências, ideias, valores e julgamentos de indivíduos. Wisdom dá o discernimento
definitivo do conhecimento, tendo a aplicação e a consciência de contexto para
proporcionar um forte julgamento do senso comum.
26
O processo de Knowledge Management estará centrado no Service Knowledge
Management System (SKMS), que é um repositório central dos dados de TI de uma
organização, informação e conhecimento. Subjacente a este conhecimento estará uma
quantidade considerável de dados, que serão armazenados num repositório lógico
central ou num CMS e CMDB, como ilustrado na figura 10.
O papel de Knowledge manager designa alguém com habilidades versáteis e que
esteja confortável com os conceitos de comportamento/cultura organizacional,
processos, branding & marketing e tecnologia.
Figura 9 – O fluxo de data para wisdom
Figura 10 – Relação entre CMDB, CMS e SKMS
27
3.2 Request Fulfillment
O processo de Request Fulfillment, integrado no livro Service Operation, é um
dos dois processos que foram explorados com mais detalhe ao longo deste projecto.
Os grandes objectivos deste processo passam essencialmente por:
Dar a possibilidade aos utilizadores de requisitarem e receberem serviços
standard;
Criar e prestar esses serviços;
Fornecer informação aos utilizadores e clientes sobre os serviços
disponíveis e os procedimentos para os obter; e
Auxiliar o utilizador com informações gerais, queixas e comentários.
Um pedido de serviço[11] é um pedido de um utilizador por informações ou
conselhos, por uma alteração standard, ou por acesso a um serviço de TI.
Todos os pedidos devem ser registados e o seu ciclo de vida devidamente
acompanhado. Este processo deve incluir procedimentos adequados de aprovação dos
pedidos antes de estes serem satisfeitos.
3.3 Outros processos
Nesta subsecção serão apresentados os processos comuns ao projecto
supramencionado.
3.3.1 Incident Management
É o processo[11] que se enquadra na fase de Service Operation, e lida com todos
os incidentes, o que pode incluir falhas ou questões reportadas pelos utilizadores,
através da equipa técnica, ou automaticamente detectado e relatado por ferramentas de
monitorização de eventos.
O principal objectivo deste processo é restaurar a normal operação do serviço
tão rápido quanto possível e minimizar o impacto adverso nas operações de negócio,
garantindo assim que os melhores níveis possíveis de qualidade de serviço e
disponibilidade são mantidos.
Os incidentes são normalmente detectados pelo processo de Event Management
ou por utilizadores que contactam o service desk. Os incidentes são categorizados para
28
identificar quem deve trabalhar neles e para a análise de tendências, e são priorizados de
acordo com a urgência e o impacto no negócio.
Se um incidente não consegue ser resolvido rapidamente, então deve ser escalado.
Um escalonamento funcional passa o incidente para uma equipa de suporte técnico com
habilidades mais apropriadas, no entanto um escalonamento hierárquico envolve níveis
apropriados de gestão.
Depois de um incidente ter sido investigado e diagnosticado, e a resolução tenha
sido testada, o Service Desk deve assegurar que o utilizador esteja satisfeito antes de o
incidente ser fechado.
3.3.2 Problem Management
O processo de Problem Management[11] está inserido na fase de Service
Operation, e é responsável por gerir o ciclo de vida de todos os problemas. Os
objectivos primários do Problem Management são prevenir problemas e incidentes
resultantes de acontecer, eliminar incidentes recorrentes e minimizar o impacto de
incidentes que não podem ser prevenidos.
Um problema é uma causa de um ou mais incidentes. A causa não é normalmente
conhecida aquando de um registo de problema ser criado, de modo que o processo de
Problem Management é responsável pela sua investigação.
O Problem Management inclui diagnosticar causas de incidentes, determinar a sua
resolução, e assegurar que a mesma é implementada. Este processo também mantém
informação sobre problemas, soluções adequadas e resoluções.
Os problemas são categorizados numa forma similar aos incidentes, mas o
objectivo é perceber as causas, documentar soluções e pedidos de alterações para,
permanentemente, resolver os problemas. As soluções são documentadas numa Known
Error Database10
(KEDB), que aumenta a eficiência e eficácia da Gestão de Incidentes.
3.3.3 Change Management
Este processo[9] está incluído na etapa de Service Transition, e assegura que as
alterações são registadas, avaliadas, autorizadas, priorizadas, planeadas, testadas,
implementadas, documentadas e revistas numa maneira controlada. O propósito deste
processo é assegurar que métodos padronizados são usados para o tratamento rápido e
10 A KEDB é uma base de dados que contém todos os registos de Erros Conhecidos, normalmente
com soluções temporárias e soluções anexadas quando elas existem.
29
eficiente de todas as alterações, que as mesmas são registadas num Configuration
Management System11
(CMS) e que o risco geral do negócio é minimizado.
O Change Management abrange as alterações de serviços. Uma alteração de um
serviço é a adição, modificação ou remoção de um serviço autorizado, planeado ou
suportado ou de uma componente do serviço e a sua documentação associada.
O processo em questão proporciona, ao negócio, redução de erros nos serviços
novos ou alterados e implementação mais rápida, mais precisa de mudança, permitindo
limitar os fundos e recursos para se concentrar sobre essas mudanças, de modo a
conseguir maiores benefícios para o negócio.
3.3.4 Release & Deployment Management
O processo de Release & Deployment Management[9] faz parte da fase de
Service Transition, tendo como fim construir, testar e prestar os serviços especificados
pelo Service Design de modo a cumprir as exigências dos stakeholders e alcançar os
objectivos pretendidos.
O objectivo deste processo é implementar releases em produção e estabelecer o
uso eficaz do serviço, a fim de distribuir valor ao cliente e ser capaz de transmitir os
serviços operacionais.
3.3.5 Service Asset & Configuration Management
Este processo foi implementado no âmbito de outro Projecto que decorreu na
mesma empresa, e que teve como foco a solução desenvolvida.
3.3.6 Service Level Management
Este processo foi implementado no âmbito de outro Projecto que decorreu na
mesma firma, e que teve como foco a solução desenvolvida.
11 A CMS é um modelo lógico coerente da infra-estrutura da organização de TI, tipicamente
composta por Configuration Management Database (CMDB) como subsistemas físicos.
30
Capítulo 4
Análise do problema e desenho da solução
Este capítulo descreve o trabalho relacionado, a análise de requisitos e o desenho
da solução desenvolvida.
Após o levantamento dos requisitos da solução implementada no âmbito deste
projecto, procedeu-se a uma análise comparativa de soluções SDM best-of-breed de
mercado. De seguida, efectuou-se uma análise dos requisitos implementados, o desenho
e especificação dos casos de uso da aplicação e o modelo de domínio da mesma.
4.1 Trabalho relacionado
A presente secção descreve o processo de análise do trabalho relacionado com a
solução âmbito deste projecto. Para isso, realizou-se um levantamento dos requisitos a
implementar e, com base em estudos de mercado efectuados pela Forrester Research,
Inc e Gartner, Inc, procedeu-se a uma análise comparativa de soluções de SDM best-of-
breed de mercado.
4.1.1 Benchmark de mercado
Para a análise comparativa das soluções de SDM best-of-breed de mercado, foram
tidos em conta os estudos realizados pela Forrester Research, Inc[19] e a Gartner,
Inc[20]. Estas são líderes em pesquisa de informação de TI e de consultoria, fornecendo
conselhos pragmáticos e com visão de futuro para os líderes mundiais em tecnologia e
negócio, eventos e programas executivos peer-to-peer.
Os estudos efectuados encontram-se ilustrados nas figuras 11 e 12.
31
Segundo a Forrester, as ferramentas da BMC, CA, HP e IBM são as soluções
líderes de mercado, constituindo-se como aquelas que se consideraram para o
desenvolvimento da solução implementada. De acordo com o estudo, as ferramentas da
BMC e da HP apresentam uma oferta de soluções e uma estratégica de mercado fortes,
tendo deste modo uma presença bastante relevante no mercado mundial. As ferramentas
da CA e IBM encontram-se noutros quadrantes, lutando para terem também uma maior
presença no mercado.
Segundo a Gartner, as ferramentas da BMC e da HP encontram-se no quadrante
das soluções líderes de mercado, ou seja, são aquelas que evidenciam uma visão de
negócio e uma capacidade de execução dessa visão mais consolidadas.
Através da experiência que a Maksen tem com soluções deste tipo, e por serem as
que têm maior presença no mercado português, foram avaliadas as ferramentas BMC
Software – Remedy IT Service Management e CA Unicenter Service Desk, de forma
avaliar o comportamento das mesmas face aos requisitos disponibilizados.
A primeira ferramenta, pertencente à organização BMC, foca-se em reduzir a
complexidade dos processos, tornando o suporte ao cliente, gestão de alterações, activos
e pedidos, num processo contínuo e integrado. A segunda, propriedade da CA
Technologies, tem como pontos fortes a automatização da gestão de incidentes,
problemas, e conhecimento, o suporte on-line interactivo e a análise avançada da causa
raiz dos problemas.
Figura 12 - Gartner Magic Quadrant ITSM Oct-2008
Figura 11 - The Forrester Wave: Service Desk Management Tools
Apr-2008
32
4.1.2 Modelo de avaliação
Com base nas soluções best-of-breed de mercado acima mencionadas, foram
analisados os requisitos requeridos neste projecto, sendo estes suportados por seis
processos implementados: Incident Management, Problem Management, Change
Management, Knowledge Management, Request Fulfillment e Release & Deployment
Management.
Para a análise comparativa entre a solução desenvolvida e as ferramentas
supramencionadas, usaram-se como fontes de informação manuais de
utilizador[21,22,23] e vídeos demonstrativos das ferramentas. No entanto, por falta de
documentação disponível, não foi possível analisar os requisitos suportados pelos
processos Knowledge Management e Release & Deployment Management.
A avaliação dos requisitos foi feita com base numa escala de maturidade, de 0 a 5,
a qual é descrita de seguida:
0 – Inexistente: ausência de evidências da implementação do requisito;
1 – Inicial: há evidências que o requisito existe e deve ser considerado;
2 – Repetitivo: o requisito foi desenvolvido, no entanto não há
documentação de que o requisito foi padronizado;
3 – Definido: o requisito foi padronizado e documentado, contudo é pouco
provável que sejam detectadas falhas. A forma como o requisito foi
implementado não é a mais sofisticada;
4 – Gerido: é possível monitorizar e medir o cumprimento do requisito.
Embora haja automatização, o requisito não está optimizado; e
5 – Optimizado: o requisito foi refinado ao nível das melhores práticas,
com base nos resultados de modelagem de maturidade com outras
ferramentas. O requisito está assim automatizado e optimizado.
33
Por outro lado, para cada requisito, procedeu-se ao seguinte modelo de avaliação:
Para a especificação do peso de cada requisito, determinou-se que este seria o
mesmo para cada um dos requisitos. Assim, com base na escala de maturidade
supramencionada, procedeu-se à avaliação do desempenho das ferramentas de SDM
face aos requisitos disponibilizados, bem como à elaboração de comentários sobre a
forma como elas os cumprem.
Como resultado dessa avaliação, obtiveram-se valores que foram usados para
efectuar o cálculo de uma média ponderada a cada processo, levando a um valor final.
4.1.3 Apresentação de resultados
Após a análise das ferramentas supramencionadas, verificou-se que a comparação
efectuada não foi a mais precisa devido à falta de documentação que possibilitasse
efectuar uma avaliação correcta de acordo com o real valor de cada ferramenta
considerada para este estudo.
Na análise final das duas ferramentas, os resultados obtidos para BMC Remedy e
CA foram de 2,67 e 2,79, respectivamente, o que representa a média dos valores de cada
requisito. Deste modo, conclui-se que, tanto a BMC Software – Remedy IT Service
Management como a CA – Unicenter Service Desk, são ferramentas cujos requisitos
estão documentados e implementados, no entanto não da forma mais sofisticada.
Os resultados supramencionados estão representados na figura 14.
Atribuição de Ponderação
Especificação do peso de cada requisito
Avaliação de ferramentas
Avaliação dos requisitos.
Comentários sobre a forma como cumpre os requisitos
.
Obtenção de resultados
Média ponderada de cada processo nos requisitos funcionais.
Média ponderada de cada processo nos requisitos de integração.
Resultado final.
Figura 13 - Representação gráfica do modelo de avaliação
34
Para cada ferramenta, procedeu-se à avaliação dos requisitos funcionais e de
integração, suportados pelos seis processos a implementar neste projecto. As figuras 15
e 16 representam gráficos que resultam da avaliação efectuada às soluções best-of-breed
de mercado.
Figura 14 – Avaliação das soluções por dimensão
Figura 15 – Avaliação dos requisitos de funcionais
35
Dessa análise, verificou-se que, a nível funcional, a ferramenta da BMC tem um
melhor desempenho nos processos de Incident Management e Change Management,
enquanto a ferramenta da CA evidencia-se em Problem Management e Request
Fulfillment.
Por outro lado, a nível de integração, a ferramenta da BMC destaca-se nos
processos de Incident Management, enquanto a ferramenta da CA salienta-se nos
processos de Problem Management, Change Management e Request Fulfillment.
Devido à falta de informação disponível, não foi possível analisar os requisitos
suportados pelos processos de KM e Release & Deployment Management.
4.2 Definição de requisitos
Num primeiro momento, identificaram-se os requisitos base deste projecto de
modo a torná-lo ITIL® compliant. Com base nesses requisitos, encontra-se detalhada no
quarto capítulo uma análise comparativa a ferramentas de SDM best-of-breed de
mercado, com o intuito de identificar o seu comportamento face a esses requisitos.
De modo a complementar o entendimento dos processos a implementar,
avaliaram-se versões trial de soluções de SDM, a ManageEngine – ServiceDesk Plus e
SysAid IT Pro, oferecendo uma visão detalhada do workflow existente em cada
Figura 16 – Avaliação de requisitos de integração
36
processo. Com base nessas ferramentas, analisou-se a forma como estão implementados
os seis processos:
Incident Management;
Problem Management;
Change Management;
Release & Deployment Management;
Knowledge Management; e
Request Fulfillment.
Para o detalhe e entendimento dos processos, utilizaram-se como fontes de
informação, para além das versões trial das ferramentas mencionadas, comentários
proferidos pelos utilizadores finais em entrevistas com os mesmos. Entre esses
utilizadores encontram-se os stakeholders Sponsor, Manager de Quality Assurance e
Gestor de Projecto, referenciados no organograma do projecto, o responsável pela área
administrativa da Maksen e dois utilizadores com perfil de administrador do sistema,
uma vez que se encontram enquadrados nos perfis de utilizadores identificados como
subjacentes à solução desenvolvida.
Após a análise das ferramentas supramencionadas, verificou-se a impossibilidade
de compreender certos processos a implementar no âmbito deste projecto. Entre estes,
encontra-se o processo de Release & Deployment Management.
De modo a mitigar este problema, realizaram-se entrevistas com futuros
utilizadores da aplicação e, segundo a sua percepção do workflow subjacente a cada um
dos processos, obteve-se informação útil à sua especificação. Assim, ao longo de cada
entrevista, foi possível obter informação complementar à especificação já existente de
cada processo.
No final de todas as entrevistas, foram compiladas as descrições obtidas em cada
uma delas, bem como as descrições baseadas em ferramentas líderes de mercado e de
versões trial, elaborando-se desta forma uma descrição final com a especificação mais
detalhada sobre cada requisito.
37
4.3 Desenho do modelo conceptual
Após a conclusão da Etapa I – INPUT, iniciou-se o desenvolvimento da Etapa II –
CONCEPÇÃO. Esta etapa encontra-se organizada pela ―Fase III – Desenho do modelo
conceptual‖ e pela ―Fase IV – Especificação funcional e técnica‖, tendo como
objectivos:
O desenvolvimento de um desenho de ―alto nível‖ da solução,
endereçando as componentes de arquitectura funcional, navegabilidade e
utilização, arquitectura de informação e integração;
O detalhe das especificações funcionais, tecnológicas e gráficas a
implementar; e
A definição do plano de implementação.
Numa primeira fase procedeu-se à elaboração do modelo de casos de uso, que
ilustra os casos de uso referentes à solução de SDM desenvolvida, seguindo-se o
desenho do modelo de domínio desta solução.
4.3.1 Modelo de casos de uso
No sentido de ilustrar os diagramas de casos de uso da solução desenvolvida,
recorreu-se à identificação dos casos de uso de cada um dos seis processos
implementados no âmbito da solução de SDM, sendo eles:
Incident Management;
Problem Management;
Change Management;
Release & Deployment Management;
Knowledge Management; e
Request Fulfillment.
Assim, estes diagramas pretendem reflectir os casos de uso inerentes a cada um
destes processos, de modo a perceber as funcionalidades implementadas, bem como os
actores envolvidos em cada uma delas. Estes actores estão de acordo com os papéis
advogados pela ITIL® v3, os quais são imutáveis, e devem ser associados aos perfis de
cada organização.
38
Com base no desenho dos casos de uso, procedeu-se a uma descrição informal do
cenário principal de utilização, assim como dos possíveis cenários alternativos para cada
desses casos de uso.
De seguida, nas figuras 17 e 18, são apresentados os diagramas de caso de uso
referentes aos processos específicos a este projecto, Knowledge Management e Request
Fulfillment.
Figura 17 – Diagrama de Casos de Uso do processo de Knowledge Mgmt
Figura 18 - Diagrama de Casos de Uso do processo de Request Fulfillment
39
Após a elaboração dos casos de uso e respectivos cenários, determinaram-se as
funcionalidades referentes a cada um dos processos implementados, os seus fluxos de
trabalho, os actores envolvidos, bem como as fronteiras do Sistema, ou seja, o que faz
parte e o que não faz parte do mesmo.
4.3.2 Modelo de domínio
Posteriormente ao modelo de casos de uso, foi elaborado um modelo de domínio
da solução desenvolvida, com o objectivo de identificar e representar as classes
conceptuais do domínio do problema, as relações conceptuais entre essas classes, e
constituir-se como uma das bases principais para a construção da base de dados
relacional da aplicação.
Deste modo, identificaram-se as classes conceptuais, através da inspecção dos
cenários de caso de uso, seguindo-se o desenho dessas classes num modelo de domínio.
Para a associação entre essas classes, foram adicionadas relações conceptuais, cujo
conhecimento é importante preservar, mesmo que seja durante pouco tempo.
Durante a implementação da solução, o modelo de domínio da mesma foi sendo
detalhado, de modo a cumprir com todos os objectivos propostos. As classes
conceptuais inerentes ao problema, bem como as relações existentes entre elas, ficaram
identificadas.
40
Capítulo 5
Solução implementada
Neste capítulo será descrito o trabalho desenvolvido para a concretização do
estágio. O trabalho consistiu no desenvolvimento de uma aplicação de Service Desk
Management, cujo objectivo era a implementação de seis processos da ITIL® v3, com
principal foco em Knowledge Management e Request Fulfillment.
Os processos implementados tiveram uma participação activa da minha parte, mas
apenas será detalhada a implementação dos processos com o foco principal.
5.1 Knowledge Management
Para o registo de um novo incidente ou de um problema, é necessária a pesquisa
de registos de conhecimento através de palavras-chave, categorização e/ou data de
aprovação destes. Neste sentido, é garantido que um utilizador não regista um novo
ticket cuja informação sobre a sua resolução já exista.
De modo a que esta informação esteja disponível, foi necessária a construção de
uma base de conhecimento que é populada após a validação de novos registos de
conhecimento por parte do Knowledge Manager. Este utilizador é responsável por toda
a monitorização e validação destes registos.
A cada registo de conhecimento está associado um nível de confidencialidade, de
modo que apenas os utilizadores autorizados possam visualizar essa informação.
Um registo de conhecimento só fica disponível para os utilizadores quando o seu
estado é ―Aprovado‖. Por outro lado, utilizadores autorizados têm a possibilidade de
arquivar o registo de conhecimento, voltar a publicá-lo (disponível na base de
conhecimento) ou apagá-lo, ou seja, o registo nunca mais fica disponível para consulta.
41
5.1.1 Painel de administração
A área de administração do processo Knowledge Management, designada por
―Registos de conhecimento‖ é configurada pelo utilizador com permissões de
administrador desta solução. Nesta área, é possível configurar campos adicionais do
registo de conhecimento, bem como, os grupos de aprovação, estados e a FAQ da
aplicação, adicionando/removendo perguntas e respostas.
O ecrã ilustrado na figura 19 representa a lista de campos adicionais a inserir no
formulário do registo de conhecimento. Os campos podem ser de quatro tipos
diferentes, entre eles, numérico, texto, data ou dropbox. De modo a pesquisar pelos
campos já adicionados, o administrador deve filtrar os mesmos por tipo de dados,
usando a lista assinalada com o número 1.
Para adicionar novos campos ao formulário de registo, o administrador deve
pressionar o botão ―Adicionar campos…‖, indicado com o número 2. Esta acção origina
a abertura da página de criação/edição dos campos adicionais. Por outro lado, é possível
remover um campo adicional, seleccionando o botão ―Remover‖ associado ao
respectivo campo.
A figura 20 representa a página de criação/edição dos campos adicionais, tal como
supramencionado.
Figura 19 – Lista de campos adicionais
1
2
42
Na figura 20 está ilustrada a página onde o administrador pode criar ou editar um
campo adicional. No máximo, é possível criar 10 campos adicionais, entre eles, três de
texto, três numéricos, 2 de data/hora e 2 do tipo dropbox.
Para a criação de um novo campo, este deve ter um rótulo e um tipo de dados,
entre os que foram supramencionados, podendo ser obrigatório e/ou editável.
Caso o campo a criar seja do tipo texto, então o número de linhas deve ser maior
que 0. No entanto, se campo for do tipo dropbox, é necessário que este tenha pelo
menos um item adicionado à lista. Todos os campos, com excepção aos do tipo
dropbox, podem ter um valor por defeito na sua criação/edição, sendo esse valor visível
na criação de um novo registo de conhecimento.
De modo a efectivar a gravação da informação inserida, o administrador pode
pressionar o botão ―Gravar e novo campo‖, sendo essa informação gravada e o
formulário de criação limpo. Para gravar a informação e voltar à lista de campos
adicionais, ilustrada na figura 19, o administrador deve pressionar o botão ―Gravar e
sair‖.
Figura 20 – Janela de criação/edição de campos adicionais
43
Os grupos de aprovação de registos de conhecimentos são definidos pela categoria
de nível 3 dos mesmos, como ilustrado na figura 21. No máximo, podem existir até
cinco grupos de aprovação, sendo que estes podem estar activos intercaladamente.
Para a criação/edição destes grupos, o administrador deve seleccionar a categoria
de nível 3 que deseja, abrindo a janela correspondente da edição dos grupos de
aprovação.
Os grupos de aprovação de registos de conhecimento podem ser editados na
página ilustrada na figura 22. Cada grupo de aprovação pode ser constituído por um ou
mais aprovadores de registos de conhecimento. A adição de aprovadores a grupos só
pode ser efectuada quando estes se encontram activos, tal como está assinalado com o
número 3.
Para gravar as alterações feitas aos grupos de aprovação e manter-se na corrente
página, o administrador deve pressionar o botão ―Gravar alterações‖, indicado com o
Figura 21 – Grupos de aprovação de registos de conhecimento
Figura 22 – Pagina de criação/edição dos grupos de aprovação
2 1
2
3
2
44
número 1. Por outro lado, caso o administrador queira gravar as alterações efectuadas e
voltar à página ilustrada na figura 21, deve pressionar o botão ―Gravar e sair‖,
assinalado com o número 2.
De modo a activar ou desactivar os grupos de aprovação de uma categorização
específica sem entrar na página de edição do respectivo grupo, o administrador deve
seleccionar o separador ―Fluxo de aprovação‖, ilustrado na figura 23, e escolher a
categoria de terceiro nível desejada.
A activação de um grupo é feita pela selecção do botão indicado o número 2. Por
outro lado, o administrador desactiva um grupo ao pressionar o ícone indicado com o
número 1.
Este utilizador pode configurar os estados dos registos de conhecimento acedendo
ao menu respectivo no painel de administração, como ilustrado na figura 24.
Na aplicação já existem estados predefinidos que não podem ser removidos e cuja
informação não pode ser editada. Por outro lado, qualquer estado adicionado pode ser
removido.
O administrador pode adicionar um novo estado caso pressione o botão
―Adicionar estado…‖, assinalado com o número 1. Esta acção origina a abertura de uma
janela de popup, ilustrada na figura 25, onde é possível adicionar o nome e a descrição
do novo estado a adicionar.
Figura 24 – Lista de estados de registos de conhecimento
1
2
1
2
2
Figura 23 – Fluxo de aprovação dos registos de conhecimento
45
O nome do estado deve ser obrigatoriamente inserido, sendo a descrição do
mesmo uma informação adicional. Para gravar a informação inserida, o administrador
pode pressionar o botão ―Gravar e Novo‖, continuando na mesma página, ou pressionar
o botão ―Gravar e sair‖, voltando à página ilustrada na figura 24. De modo a sair da
página sem gravar as alterações, o administrador deve clicar no botão ―Cancelar‖.
A figura 26 ilustra a lista de perguntas da FAQ a apresentar aos utilizadores,
caso estes desejem consultá-las. O administrador para remover uma pergunta existente
tem que pressionar o botão ―Remover‖, assinalado com o número 1. Por outro lado,
para adicionar uma nova pergunta, é necessário pressionar o botão ―Adicionar
perguntas…‖, indicado com o número 2. Esta acção despoleta a abertura da janela de
popup ilustrada na figura 27.
Figura 25 – Janela de popup de criação/edição de um novo estado
Figura 26 – Lista de perguntas da FAQ
1
2
2
2
46
Na popup ilustrada na figura 27, o administrador precisa de escrever a pergunta
e a sua resposta, para que estas possam ser adicionadas à FAQ. A mesma janela é usada
para editar perguntas e respostas que existem na FAQ.
As alterações são efectivadas quando o administrador pressionar o botão
―Gravar e Novo‖. Deste modo, a informação é gravada e uma nova pergunta pode ser
inserida. No entanto, se o administrador quiser gravar as alterações e voltar à página
ilustrada na figura 26, tem que pressionar o botão ―Gravar e sair‖. Por outro lado, caso
não deseje gravar as alterações, deve clicar no botão ―Cancelar‖.
5.1.2 Criação de registos de conhecimento
Os utilizadores com permissões para criação de um registo de conhecimento
podem fazê-lo, acedendo ao submenu ―Novo registo de conhecimento‖ que se encontra
no menu principal ―Gestão de Conhecimento‖. No entanto, antes da criação de qualquer
registo de conhecimento é necessário efectuar uma pesquisa à base de conhecimento, de
modo a impedir o registo de um registo de conhecimento cuja informação já exista.
A ilustração 28 representa a página de pesquisa de registos de conhecimento.
Figura 28 – Página de pesquisa de registos de conhecimento
Figura 27 – Janela de popup para criação/edição de pergunta da FAQ
47
Neste ecrã, o utilizador antes de efectuar um novo registo de conhecimento deve
pesquisar, através de palavras-chave, categorização e/ou datas, por informação já
existente na base de conhecimento. Deste modo, evita-se que exista mais que um registo
de conhecimento com a mesma informação.
De seguida, são apresentados os resultados de uma pesquisa pela palavra-chave
―aventail‖.
Na figura acima indicada, é possível verificar que a pesquisa pela palavra-chave
―aventail‖ retornou dois resultados. Deste modo, o clique num dos resultados, despoleta
a abertura de uma página com a informação sobre o registo de conhecimento escolhido.
Dos resultados obtidos, se algum for semelhante ao registo de conhecimento que o
utilizador pretende registar, então pode escolher a opção 1 (encontra-se a vermelho), ou
seja, um dos resultados foi útil. No entanto, caso nenhum desses resultados seja útil, o
utilizador escolhe a opção 2 (encontra-se a vermelho) e a página com o formulário de
um novo registo de conhecimento é aberta.
No formulário de registo é possível inserir o título e descrição do registo de
conhecimento, a categorização que pertence, palavras-chave associadas, comentários e
alguns anexos que suportem o novo registo.
Em qualquer momento, é possível gravar um rascunho com a informação inserida
até ao momento, cancelar o registo ou submetê-lo para aprovação. Para que o registo de
conhecimento possa ser submetido, é obrigatório o preenchimento do título, da
descrição e das palavras-chave, sendo o resto informação adicional.
2 1
Figura 29 – Resultados de pesquisa de registos de conhecimento
3
4 5 6
3
48
Na figura 30 está representado o formulário de um novo registo de conhecimento.
Como referido anteriormente, para que o registo de conhecimento possa ser submetido,
então os campos assinalados com os valores 1, 2 e 3 têm que ser obrigatoriamente
preenchidos.
O utilizador pode gravar um rascunho do formulário de registo ao seleccionar o
botão ―Gravar rascunho‖, assinalado com o número 4. Assim, sempre que esse botão for
seleccionado, uma nova versão do registo de conhecimento é gerada e guardada na
tabela ―KNOWLEDGE_RECORD‖.
Por outro lado, se o utilizador desejar cancelar o preenchimento do formulário
apenas tem que seleccionar o botão ―Cancelar‖, assinalado com o valor 6.
De modo a que o novo registo entre em aprovação, o utilizador tem que
seleccionar o botão ―Submeter registo de conhecimento‖, indicado com o número 5. De
seguida, uma nova versão do registo de conhecimento é gerada, sendo esta encaminhada
para o primeiro grupo de aprovação que esteja activo. Cada utilizador desse grupo
recebe uma notificação, indicando que um novo registo de conhecimento se encontra
para aprovação.
Os registos de conhecimento criados pelo utilizador podem ser vistos por este no
submenu ―Os meus incidentes‖, tal como mostra a figura 31.
1
2
4
1
5 6
1
Figura 30 - Formulário de registo de conhecimento
3
49
Cada registo de conhecimento é identificado univocamente pelo seu número de
registo. Este número, KM.000001.2011.01, divide-se em quatro partes distintas, entre
elas:
KM – representa o ticket gerado, cuja designação é Knowledge
Management;
000001 – representa o número do identificador do registo de
conhecimento, tendo no máximo 6 dígitos;
2011 – indica o ano em que o ticket foi gerado; e
01 – representa o número da versão do ticket, podendo existir 99 versões
de cada registo de conhecimento.
5.1.3 Aprovação
Para que um dado registo de conhecimento esteja disponível para consulta é
necessária a aprovação deste por parte de utilizadores específicos. Estes utilizadores
estão inseridos em grupos de aprovação, sendo que apenas os grupos que estejam
activos é que podem aprovar os registos de conhecimento. No máximo, devem existir
até cinco grupos de aprovação que podem ser pré-definidos no painel de administração.
2
3
1
Figura 31 – Lista dos registos de conhecimento do utilizador autenticado
Figura 32 – Registo de conhecimento para aprovar
4
50
Na figura 32 estão representadas três tabelas indicadas pelos valores 1, 2 e 3. A
primeira tabela, designada por ―Lista de registos de conhecimento‖, indica os registos
de conhecimento que estão para validação por parte do Knowlegde Manager e os que já
passaram por essa mesma validação.
Os registos de conhecimento que se encontram para aprovação por parte de um
determinado grupo encontram-se na segunda tabela, designada por ―Registos de
conhecimento submetidos‖. Para que um registo de conhecimento seja aprovado, é
necessário que um aprovador12
do grupo de aprovação em questão faça pick-up do
mesmo, seleccionando a check-box respectiva, e pressione o botão ―Tratar registo de
conhecimento‖, indicado com o número 4. Desta forma, esse registo de conhecimento
passa para a terceira tabela, designada por ―Registos de conhecimento em aprovação‖.
Para poder aprovar um registo de conhecimento, este utilizador tem que
seleccioná-lo na terceira tabela, despoletando a abertura do formulário respectivo.
Na figura 33, estão quatro botões enumerados de 1 a 4. De modo a adiar a
aprovação/rejeição do registo de conhecimento para outra altura, o aprovador deve
seleccionar o botão 4 (―Cancelar‖).
Essa aprovação sucede quando o botão 2 (―Aprovar‖) é pressionado. Esta acção
permite gerar uma nova versão do registo de conhecimento, encaminhando-a para o
próximo grupo de aprovação activo. No caso de não existir mais nenhum grupo activo,
o registo de conhecimento é encaminhado para o Knowledge Manager para o mesmo
ser validado e, dessa forma, estar disponível para consulta.
12 Utilizador específico pertencente a um determinado grupo de aprovação de registos de
conhecimento.
4
51
Por outro lado, se o aprovador pretender rejeitar o registo de conhecimento tem
que pressionar o botão 3 (―Rejeitar‖). Assim, é aberta a pop-up ilustrada na figura 34,
onde o utilizador tem que indicar os motivos para tal rejeição. No seguimento da
mesma, o requerente do registo de conhecimento recebe um email com esses motivos,
podendo editá-lo e submetê-lo novamente para aprovação.
Em alguns casos, os aprovadores podem ter permissões para apagarem o registo
de conhecimento, ou seja, estes deixam de seguir o fluxo de aprovação, passando
automaticamente para o estado ―Apagado‖ e nunca ficarão disponíveis para consulta.
Para tal, o aprovador tem que seleccionar o botão 4 (―Apagar‖) e confirmar que
pretende apagar o registo de conhecimento.
1 2 3 4
Figura 34 – Pop-up de rejeição de registo de conhecimento
Figura 33 – Registo de conhecimento para aprovação
52
5.1.4 Validação
Após a aprovação do registo de conhecimento por parte de todos os grupos de
aprovação activos, o Knowledge Manager tem que validá-lo para que possa estar
disponível para consulta.
A figura 35 ilustra o ecrã do registo de conhecimento aquando do processo de
validação por parte do Knowledge Manager. Para o responsável pela validação do
registo de conhecimento proceder à mesma, necessita pressionar o botão ―Validar‖,
indicado com o número 4. Esta acção origina o envio de uma notificação, através da
aplicação, ao requerente do registo de conhecimento sobre a aprovação do mesmo,
indicando que este se encontra disponível para consulta na base de conhecimento.
Por outro lado, e tal como os aprovadores, o Knowledge Manager pode rejeitar
um novo registo de conhecimento. Para que esta acção seja concretizada, o botão
―Rejeitar‖, assinalado com o valor 5, deve ser pressionado, abrindo a janela de pop-up
ilustrada na figura 34. Caso o Knowledge Manager confirme a rejeição do registo de
conhecimento, o requerente é notificado via email com os motivos da mesma.
No processo de aprovação e validação, o formulário do registo de conhecimento
tem visíveis três separadores, enumerados de 1 a 3, sendo o primeiro ilustrado na figura
35. Durante estes processos, tanto os aprovadores, como o Knowledge Manager podem
alterar o conteúdo do registo de conhecimento, bem como adicionar/remover activos ou
outros registos de conhecimento.
1 2
1
3
1
4 5
Figura 35 - Registo de conhecimento para validar
53
A figura 36 representa o separador que contém a informação do histórico do
registo de conhecimento em questão. Essa informação pode ser filtrada por versão e/ou
datas de início e fim. O utilizador tem a possibilidade de exportar para excel os
resultados da pesquisa efectuada.
No separador ilustrado na figura 37, designado por ―Registos de conhecimento e
activos‖, é possível pesquisar por registos de conhecimento e activos, de modo a
associá-los. A pesquisa por registos de conhecimento pode ser efectuada, filtrando por
palavras-chave, categorização e/ou datas de início e fim. Essa pesquisa pode ser feita
para registos já relacionados ou registos não relacionados.
Figura 36 – Histórico do registo de conhecimento
Figura 37 – Registos de conhecimento e activos associados
1
2
1
4 3
54
Para proceder à associação/desassociação dos registos de conhecimento, o
utilizador deve seleccionar as checkbox correspondentes, assinaladas a vermelho com o
valor 1, e de seguida pressionar o botão indicado com o valor 2.
A associação de activos é efectuada pressionando o botão ‖Adicionar activos‖,
assinalado com o número 3. Para a remoção de um activo associado, o utilizador deve
pressionar a cruz, indicada a vermelho, do activo correspondente. Por outro lado, para
pesquisar por activos já associados, o utilizador pode filtrar por tipo de componente e
modelo dos activos que se pretende visualizar. Estes filtros encontram-se assinalados
com o número 4, sendo o resultado apresentado na tabela correspondente.
Como anteriormente mencionado, para se efectivar a adesão de novos activos, o
utilizador deve pressionar o botão indicado com o número 3. Esta acção origina a
abertura de uma pop-up onde essa adesão pode ser efectuada.
Na janela ilustrada na figura 38, o utilizador pode filtrar a pesquisa de activos pelo
tipo de componente e pelo modelo dos mesmos. Os resultados da pesquisa são
apresentados numa tabela, também indicada na figura 37. Para a adesão de activos, o
utilizador autorizado deve seleccionar as checkboxs dos mesmos e pressionar o botão
―Adicionar‖. Deste modo, os activos são adicionados à tabela ―Activos Associados‖
ilustrada na figura 37.
A informação inserida/editada pelos aprovadores, ou pelo Knowledge Manager,
é guardada quando os primeiros aprovam, ou quando o segundo valida o registo de
conhecimento.
O Knowledge Manager tem permissão para alterar o estado dos registos de
conhecimento que já tenham passado por validação. Deste modo, este utilizador pode
arquivar registos de conhecimento, mudando os seus estados para ―Arquivado‖, ficando
temporariamente indisponíveis para consulta.
Figura 38 – Janela de pop-up para adicionar activos ao registo de conhecimento
55
Para além dessa permissão, o Knowledge Manager pode apagar registos de
conhecimento, alterando os seus estados para ―Apagado‖. Dessa forma, estes registos
ficam permanentemente indisponíveis para consulta. No entanto, quando voltam a ser
publicados, todos esses registos de conhecimento voltam a estar disponíveis para
consulta.
5.1.5 Classificação de registos de conhecimento
A classificação de registos de conhecimento apenas pode ser efectuada após
pesquisas à base de conhecimento. A selecção de um registo de conhecimento obtido
nessas pesquisas origina a abertura de uma nova página, onde pode ser visualizada a
informação do mesmo.
Independentemente do número de consultas que um utilizador faça a um
determinado registo de conhecimento, este só pode ser classificado uma vez por dia por
esse utilizador. Esta classificação pode ser efectuada através da selecção de uma das
cinco estrelas existentes para o efeito. Cada estrela representa um valor:
1ª estrela – ―Mau‖;
2ª estrela – ―Nada de especial‖;
3ª estrela – ―Vale a pena ver‖;
4ª estrela – ―Muito bom‖; e
5ª estrela – ―Excelente!‖.
Além dessa classificação, o utilizador pode determinar a utilidade que os registos
de conhecimento tiveram na sua consulta, mencionando se o registo em questão foi útil
ou não. A escolha dessa utilidade, bem como a sua classificação, podem ser efectuadas
em consultas diferentes. Contudo, após o utilizador classificar e/ou dizer se o registo foi
útil ou não, estas opções ficam bloqueadas até ao dia seguinte.
56
Na figura 39 é possível verificar que o registo de conhecimento consultado
apresenta o número de acessos ao registo efectuados por todos os utilizadores, a
classificação média, o número de vezes em que foi útil, bem como a data de aprovação
do mesmo. Para além desta informação, verifica-se o modo de classificação e a forma
de escolher a utilidade deste registo de conhecimento, tal como mencionado
anteriormente.
Num separador diferente, o utilizador tem a possíbilidade de verificar todo o
histórico deste registo de conhecimento, desde a sua criação até à versão corrente.
5.1.6 Consultar FAQ
A solução desenvolvida disponibiliza uma FAQ para os utilizadores da mesma.
Esta FAQ é constituída por um conjunto de perguntas e respostas adicionadas pelo
administrador da solução, tal como ilustrado nas figuras 26 e 27.
De modo a disponibilizar as perguntas mais frequentes sobre a aplicação,
implementou-se um menu que permite-se aos utilizadores consultarem essas perguntas e
suas respostas.
Figura 39 – Registo de conhecimento para classificação
57
A figura 40 ilustra a lista de perguntas mais frequentes disponibilizadas aos
utilizadores da aplicação. Neste ecrã, o utilizador, além de puder consultar essas
perguntas, pode exportar as mesmas para excel.
Ao longo da aplicação, encontra-se disponível uma funcionalidade para pesquisa
de registos de conhecimento, como indicada na figura acima. Desta forma, o utilizador
deve inserir palavras-chave, pressionando de seguida o botão ―Ok‖. Esta acção origina a
abertura da janela com os resultados da pesquisa, semelhante à que se encontra ilustrada
na figura 29.
5.2 Request Fulfillment
A solução de SDM desenvolvida permite ao utilizador comum efectuar pedidos de
serviço. Estes pedidos baseiam-se no preenchimento de um formulário de registo, no
encaminhamento para o grupo de suporte associado à categoria desse ticket e de todo o
tratamento do mesmo por parte dos helpdeskers.
Para disponibilizar um conjunto de serviços aos utilizadores, foi necessária a
implementação de um catálogo de serviços. Os serviços deste catálogo são adicionados
e geridos no painel de administração deste processo.
5.2.1 Painel de administração
A área de administração do processo Request Fulfillment, designada por ―Pedidos
de serviço‖, é configurada pelo utilizador com permissões de administrador desta
aplicação. Nesta área, é possível gerir o catálogo de serviços, configurar campos
adicionais do formulário de registo, bem como, os grupos de suporte, estados e a matriz
de prioridade.
Figura 40 – Lista de perguntas mais frequentes
58
Na figura 41 estão ilustradas as listas de categorias de três níveis diferentes. As
categorias do terceiro nível são as principais, pois todo o fluxo de encaminhamento de
tickets e grupos de suporte estão associados a estas categorias. No entanto, estas
categorias provêm de categorias de segundo nível, e estas dependem de categorias de
primeiro nível.
Durante a implementação da solução, existiu a necessidade de disponibilizar
uma categorização genérica aos utilizadores, cujo nome das categorias dos diferentes
níveis, enumeradas com os números 2, 3 e 4, é ―Geral‖. No registo de um novo ticket,
os utilizadores podem categorizá-lo por ―Geral - Geral - Geral‖ (nível 1 – nível 2 – nível
3), no caso de não saberem dar uma categorização a esse mesmo ticket.
Para a adesão de categorias de segundo ou terceiro nível, é necessária a
existência de categorias do nível superior. Deste modo, uma categoria de segundo nível
apenas pode ser adicionada se existirem categorias de primeiro nível.
O administrador ao pressionar o botão ―Adicionar categoria…‖, indicado a
vermelho com o número 1, despoleta a abertura de uma popup para o efeito. Nesta nova
janela, ilustrada na figura 42, os campos nome e descrição são de preenchimento
obrigatório.
Figura 41 – Lista de categorias de 1º, 2º e 3º nível
1
2
2
3
4
5
59
A figura indicada representa a janela de criação/edição de uma categoria de
primeiro nível. Para tal, o administrador tem que preencher obrigatoriamente os campos
de nome e descrição da categoria, e de seguida proceder à gravação dessa informação.
Durante a gravação da categoria de primeiro nível, são criadas categorias de
segundo e terceiro nível, designadas de ―Geral‖. Estas categorias representam,
respectivamente, as categorias genéricas das categorias de primeiro e segundo nível que
dependem.
Para a remoção de uma dada categoria, seja de primeiro, segundo ou terceiro
nível, o administrador deve seleccionar a cruz a vermelho, ilustrada na figura 41 com o
número 5, da categoria desejada.
Os serviços prestados aos utilizadores, bem como os pacotes de serviços, são
geridos no menu de administração. Nestas secções, o administrador pode adicionar,
remover, editar e activar/desactivar os serviços/pacotes de serviços.
A figura 43 ilustra a lista de serviços categorizados com a categorização ―Geral –
Geral - Geral‖. Cada serviço prestado deve estar associado a categorias de primeiro,
segundo e terceiro nível, de forma a disponibilizá-los no catálogo de serviços.
No catálogo mencionado, apenas estão contidos os serviços que se encontrem
activos, ou seja, que estejam disponíveis para os utilizadores. Para a pesquisa de
serviços adicionados, deve-se usar as dropboxs e o botão ―Ok‖ indicados com o número
Figura 42 – Janela de popup para a criação/edição de categorias
Figura 43 – Lista de serviços para a categorização “Geral – Geral - Geral”
1 2
3 4
5
5
6
60
1. A tabela onde os serviços são apresentados está dividida por diversas informações
sobre os mesmos, mais propriamente, pelo nome, descrição, categoria de terceiro nível,
custo e se está activo.
Para remover, editar ou activar/desactivar um serviço, o administrador deve
seleccionar os ícones assinalados com os valores 3, 4 e 5, respectivamente.
A adição de um novo serviço inicia-se quando este utilizador clica no botão
―Adicionar serviço…‖, assinalado com o número 2, despoletando a abertura da janela
de criação/edição de um serviço ilustrada na figura 44.
Um serviço é constituído obrigatoriamente por um nome, uma descrição e uma
categorização. Adicionalmente, o serviço pode ter um preço e ser prestado por um
determinado prestador de serviços13
. O administrador pode ainda referir se o serviço
fica activo ou inactivo no catálogo de serviços, bem como mencionar se um pedido
deste serviço por parte de um utilizador necessita de aprovação. Esta deve ser efectuada
externamente à aplicação, com o anexo de um ficheiro ao pedido de serviço, indicando
essa mesma aprovação.
O registo de um novo serviço não fica concluído sem que o administrador defina
qual o sumário e a descrição que devem ser atribuídos aos pedidos deste serviço. Desse
modo, os campos ―Sumário‖ e ―Descrição‖, indicados na figura 44, são de
preenchimento obrigatório, de forma que se tornem visíveis no formulário de registo
dos pedidos deste serviço.
13 Pessoa ou organização que presta determinados serviços.
Figura 44 – Página de criação/edição de um serviço
61
Nesta figura está ilustrada a lista de pacotes de serviços. Cada pacote de serviços,
disponível no catálogo de serviços, contém um ou mais serviços a serem prestados. No
catálogo mencionado, apenas estão contidos os pacotes de serviços que se encontrem
activos, ou seja, disponíveis para os utilizadores. A tabela dos pacotes de serviços está
dividida por diversas informações sobre os mesmos, mais propriamente, pelo nome,
custo e se está activo.
Para remover, editar ou activar/desactivar um pacote de serviços, o administrador
deve seleccionar os ícones assinalados com os valores 2, 3 e 4, respectivamente.
A adição de um novo pacote de serviços inicia-se quando o administrador clica no
botão ―Adicionar pacote de serviços…‖, assinalado com o número 1. Esta acção origina
a abertura da janela de criação/edição de um pacote de serviços, ilustrada na figura 46.
Um pacote de serviços é constituído obrigatoriamente por um nome, uma
descrição e pelo menos um serviço, sendo que o seu custo é a soma dos custos dos
serviços adicionados. O administrador pode referir se o pacote de serviços fica activo ou
inactivo no catálogo de serviços, bem como mencionar se um pedido deste pacote por
parte de um utilizador necessita de aprovação. Esta aprovação deve ser efectuada
externamente à aplicação, através do anexo de um ficheiro ao pedido do pacote de
serviços, comprovando essa aprovação.
Figura 45 – Lista de pacotes de serviços
1
2
1
3 4
Figura 46 – Página de criação/edição de um pacote de serviços
62
O registo de um novo pacote de serviços não fica concluído sem que o
administrador defina qual o sumário e a descrição que devem ser atribuídos aos pedidos
deste pacote. Desse modo, os campos ―Sumário‖ e ―Descrição‖, indicados na figura 46,
são de preenchimento obrigatório, de forma que se tornem visíveis no formulário de
registo dos pedidos deste pacote de serviços.
O ecrã ilustrado na figura 47 representa a lista de campos adicionais a inserir no
formulário do registo de um pedido de serviço. Os campos podem ser de quatro tipos
diferentes, entre eles, numérico, texto, data ou dropbox. De modo a pesquisar pelos
campos já adicionados, o administrador deve filtrar os mesmos por tipo de dados,
usando a lista assinalada com o número 1.
Para adicionar novos campos ao formulário de registo, este utilizador deve
pressionar o botão ―Adicionar campos…‖, assinalado com o número 2. Esta acção
origina a abertura da página de criação/edição dos campos adicionais. Por outro lado,
também é possível remover um campo adicional, seleccionando o botão ―Remover‖
associado ao respectivo campo.
A figura seguinte representa a página de criação/edição dos campos adicionais, tal
como supramencionado.
Figura 47 – Lista de campos adicionais
1 2
Figura 48 – Página de criação/edição de campos adicionais
63
A figura 48 ilustra a página onde o administrador pode criar ou editar um campo
adicional. No máximo, é possível criar 10 campos adicionais para a secção do pedido de
serviço, entre eles, três de texto, três numéricos, 2 de data/hora e 2 do tipo dropbox, e 8
novos campos para a secção do requerente, dois de cada tipo.
Para a criação de um novo campo, este deve ter um rótulo e um tipo de dados,
entre os que foram supramencionados, podendo ser obrigatório e/ou editável.
Caso o campo a criar seja do tipo texto, então o número de linhas deve ser maior
que 0. No entanto, se campo for do tipo dropbox, é necessário que este tenha pelo
menos um item adicionado à lista. Todos os campos, com excepção aos do tipo
dropbox, podem ter um valor por defeito na sua criação/edição, sendo esse valor visível
na criação de um novo registo de conhecimento.
De modo a efectivar a gravação da informação inserida, o administrador pode
pressionar o botão ―Gravar e novo campo‖, onde essa informação é gravada e o
formulário de criação de um campo adicional é limpo. Para gravar a informação e voltar
à lista de campos adicionais, ilustrada na figura 47, o administrador deve pressionar o
botão ―Gravar e sair‖.
Os grupos de suporte de registos de conhecimentos são definidos pela categoria de
nível 3 dos mesmos, como ilustrado na figura 49. Os pedidos de serviço podem ser
tratados por três grupos de suporte diferentes. Se um grupo de suporte não conseguir
tratar o pedido de serviço, então pode encaminhá-lo para o nível de suporte seguinte.
Para a criação/edição dos grupos de suporte, o administrador deve seleccionar a
categoria de nível 3 que deseja. Esta categoria está associada às categorias de primeiro e
segundo nível ilustradas pelas dropboxs da figura indicada, abrindo deste modo a janela
correspondente da edição dos grupos de suporte.
Figura 49 – Lista de grupos de suporte de pedidos de serviço
64
Os grupos de suporte de pedidos de serviço podem ser editados na página
ilustrada na figura 50. Cada grupo de suporte pode ser constituído por um ou mais
helpdeskers de pedidos de serviço. A adição destes utilizadores a grupos só pode ser
efectuada quando estes se encontram activos, tal como está assinalado com o número 3.
Para gravar as alterações feitas aos grupos de suporte e manter-se na corrente
página, o administrador deve pressionar o botão ―Gravar alterações‖, assinalado com o
número 1. Por outro lado, caso queira gravar as alterações efectuadas e voltar à página
ilustrada na figura 49, deve pressionar o botão ―Gravar e sair‖, assinalado com o
número 2.
Cada pedido de serviço deve seguir um fluxo de encaminhamento. Esse fluxo é
definido no painel de administração dos pedidos de serviços, mais propriamente no
separador ―Regras de encaminhamento‖ do menu ―Encaminhamento‖, como ilustrado
na figura 51. O administrador deve escolher as categorias dos diferentes níveis, de modo
a puder definir o fluxo de encaminhamento dos pedidos de serviço com essa
categorização.
Figura 50 – Página de criação/edição dos grupos de suporte
1
2
2
2
3
2
Figura 51 – Tabela de regras de encaminhamento de pedidos de serviço
1
65
Um pedido de serviço pode ser encaminhado no para a equipa de suporte de 1ª,
2ª ou 3ª linha, para o Incident Manager, Release Manager ou Change Manager, sendo
que as regras de encaminhamento apenas podem ser definidas para os grupos de suporte
que se encontrem activos. Para a gravação do fluxo de encaminhamento, o
administrador deve pressionar o botão ―Gravar alterações‖ que se encontra indicado
com o número 1 a vermelho.
No caso de um grupo se encontrar inactivo, todos os pedidos de serviço
encaminhados para o nível de suporte desse grupo são encaminhados para o grupo de
categoria genérica de primeiro nível que esteja activo. Assim, um pedido de serviço
com a categorização de ―Software – Geral - Geral‖ que seja encaminhado para um
grupo de suporte de segundo nível inactivo, é automaticamente encaminhado para o
grupo de primeiro nível da categorização ―Geral – Geral - Geral‖.
Excepcionalmente, um pedido de serviço pode ser encaminhado para o Incident
Manager, no caso de não existir nenhum grupo de suporte activo da categorização desse
pedido.
O administrador pode configurar os estados dos pedidos de serviço, acedendo ao
menu respectivo no painel de administração, como ilustrado na figura 52.
Inicialmente, existem estados predefinidos que não podem ser removidos e cuja
informação não pode ser editada. Por outro lado, para qualquer estado adicionado, o
administrador tem a permissão de removê-lo, pressionando o botão indicado com o
número 2.
Para a adição de um novo estado, este utilizador deve pressione o botão
―Adicionar estados…‖, assinalado com o número 1. Esta acção origina a abertura de
uma janela de popup, onde é possível adicionar o nome e a descrição do novo estado a
adicionar, como indicado na figura 53.
2
1
2
Figura 52 – Lista de estados dos pedidos de serviço
66
O nome do estado deve ser obrigatoriamente inserido, sendo a descrição do
mesmo uma informação adicional. Para gravar a informação inserida, o administrador
pode pressionar o botão ―Gravar e Novo‖, continuando na mesma página, ou pressionar
o botão ―Gravar e sair‖, voltando à página ilustrada na figura 51. De modo a sair da
página sem gravar as alterações, o administrador deve clicar no botão ―Cancelar‖.
Um pedido de serviço deve ser registado com uma prioridade, sendo esta
prioridade ―calculada‖ segundo um impacto e uma urgência, como está ilustrado na
figura 54.
O impacto é baseado no nível de perfil do requerente do pedido de serviço,
podendo ir desde o nível 1 até ao nível 5. O nível de perfil de cada utilizador deve estar
associado ao papel que este último representa para a organização, e definido pelo
administrador noutro menu do painel de administração.
No registo de um pedido de serviço, a urgência associada ao mesmo é sempre
classificada de média, podendo ser alterada pelos utilizadores de suporte durante o
processo de resolução desse pedido.
A urgência e a prioridade podem tomar até um de quatro valores, entre eles,
Baixa, Média, Alta ou Crítica, sendo que estes valores não podem ser parametrizados. A
Figura 53 – Janela de popup de criação/edição de um estado
Figura 54 – Matriz de prioridade de pedidos de serviço
1
2
2 3
67
parametrização das prioridades deve ser efectuada pelo administrador, como indicado
pelo número 3 na figura 54.
Caso o administrador desactive uma das checkboxs indicadas com o número 2, o
nível de perfil associado ao impacto é desactivado. Deste modo, um dado pedido de
serviço registado por um requerente, cujo nível de perfil se encontra desactivo, tem um
impacto inferior. Por outras palavras, se o nível de perfil 4 estiver desactivo e o nível de
perfil 3 estiver activo, então um pedido de serviço, inicialmente de impacto de nível 4,
passa a ter um impacto de nível 3.
5.2.2 Criação de pedidos de serviço
O utilizador pode efectuar a pesquisa de serviços de duas maneiras: através do
menu lateral, como mostra a figura 55, ou acedendo ao menu principal ―Catálogo de
serviços‖, ilustrado na figura 56.
O catálogo de serviços disponibilizado no menu lateral está visível em muitas
páginas da aplicação, de forma que a pesquisa de serviços seja feita mais rapidamente.
A selecção de um dado serviço, ou pacote de serviços, origina a abertura do formulário
de registo ilustrado na figura 57.
Figura 55 – Catálogo de serviços do menu lateral
Figura 56 – Menu do Catálogo de serviços
1
2
2
2
3
68
A figura 56 ilustra outra forma de pesquisar por serviços e/ou pacotes de serviços.
Desta forma, o utilizador deve seleccionar as categorias de primeiro, segundo e terceiro
nível, indicadas com o número 1, e pressionar o botão ―Pesquisar‖. Os serviços
associados a essas categorias aparecem na tabela assinalada com o número 2 e, por sua
vez, os pacotes de serviços com serviços da categorização seleccionada devem aparecer
na tabela correspondente.
O utilizador ao seleccionar um destes serviços/pacotes de serviços irá despoletar a
abertura do formulário de registo de um pedido de serviço, como mostra a figura abaixo.
O formulário indicado na figura 57 representa o registo de um pedido do serviço
com a categorização ―Software – Geral - Geral‖, mais propriamente o ―Serviço 2‖. De
modo a que o registo de um pedido de serviço possa ser submetido, os campos
assinalados com os valores 1, 2 e 3 têm que ser preenchidos obrigatoriamente. No
entanto, os dois últimos campos são previamente preenchidos na área de administração,
tal como foi mencionado na secção anterior.
Para o cancelamento do registo do pedido de serviço, o utilizador deve clicar no
botão ―Cancelar‖, assinalado com o número 5. Por outro lado, o registo do pedido de
serviço é efectivado quando o utilizador selecciona o botão ―Submeter‖, indicado com o
número 4. Esta acção despoleta a criação de um novo ticket de pedido de serviço, sendo
uma versão desse ticket guardada na tabela ―SERVICE_REQUEST‖. Automaticamente,
o pedido de serviço é encaminhado para o grupo de suporte de primeiro nível da mesma
categorização.
Figura 57 – Formulário de registo de um pedido de serviço
2
2 3
4 5
4
1
69
No entanto, o Incident Manager poderá receber o pedido de serviço para
encaminhar se não existir nenhum grupo de suporte activo. Por outras palavras, um
pedido de serviço pode ser encaminhado para o Incident Manager caso o grupo de
suporte de primeiro nível de categorização ―Geral – Geral - Geral‖ não esteja activo.
Os pedidos de serviço criados pelo utilizador autenticado podem ser vistos, por
este, no submenu ―Os meus pedidos de serviço‖, tal como mostra a figura 55.
Cada pedido de serviço é identificado univocamente pelo seu número de registo.
Este número, REQ.000001.2011.01, divide-se em quatro partes distintas, entre elas:
REQ – representa o ticket gerado, cuja designação é Request;
000001 – representa o número do identificador do pedido de serviço, tendo
no máximo 6 dígitos;
2011 – indica o ano em que o ticket foi gerado; e
01 – representa o número da versão do ticket, sendo que podem existir 99
versões de cada pedido de serviço.
5.2.3 Pick-up de pedidos de serviço
Os novos pedidos de serviço são encaminhados para um grupo de suporte, ou para
o Incident Manager. De modo a que um pedido de serviço possa ser tratado, um
helpdesker14
do grupo de suporte correspondente tem que fazer pick-up desse pedido.
Assim, esse utilizador específico fica responsável pela resolução do pedido de serviço
escolhido.
14 Técnico responsável pela resolução do pedido de serviço
Figura 58 – Pedidos de serviço para tratar
3
1
2
70
Na figura 58 estão representadas duas tabelas indicadas pelos valores 1 e 2. A
primeira tabela, designada por ―Novos pedidos de serviço‖, indica os pedidos de serviço
associados a um grupo de suporte onde o utilizador autenticado está inserido.
Por outro lado, a segunda tabela representa os pedidos de serviços que o
helpdesker se encontra a tratar. Para que os pedidos pudessem ser tratados, este
utilizador teve que fazer pick-up dos mesmos, ou seja, seleccionou-os na primeira tabela
e pressionou o botão assinalado com o número 3. Assim, os pedidos de serviços não
podem ser tratados por nenhuma pessoa do grupo de suporte, à excepção do helpdesker
que os seleccionou.
De forma a garantir o que foi mencionado anteriormente, os pedidos de serviço
ficam associados à pessoa que efectuou essa acção, aparecendo na tabela indicada com
o número 2. O conteúdo desta tabela é único para cada helpdesker, sendo que nenhum
pedido de serviço pode ser tratado por duas pessoas diferentes.
5.2.4 Tratamento de pedidos de serviço
Os helpdeskers podem encaminhar os pedidos de serviço para outros grupos de
suporte, gerar tickets de incidente, pedidos de alteração ou release, associar tarefas,
adicionar activos do requerente afectos aos pedidos de serviço, entre outros. Cada
pedido de serviço tem um tempo de resolução, sendo este definido num SLA.
O SLA encontra-se em cumprimento caso o tempo de resolução não termine antes
do fecho do pedido de serviço. Por outro lado, o SLA expira se o tempo de resolução
terminar antes do fecho do pedido de serviço.
Como mencionado anteriormente, o pedido de serviço indicado na figura 59 tem
um tempo de resolução. Este tempo de resolução ainda não terminou, por isso o SLA
encontra-se em cumprimento até que esse tempo termine antes do fecho do pedido.
71
A figura acima indica a página que é apresentada aos helpdeskers e Incident
Manager, sobre a informação dos pedidos de serviço. Esta página divide-se em três
separadores, enumerados de 1 a 3, de modo a organizar a informação dos pedidos.
O primeiro desses separadores encontra-se ilustrado na figura 59 e contém toda a
informação básica de qualquer pedido de serviço, desde sumário, descrição, requerente,
categorização, impacto, urgência, prioridade, data de criação, data de expiração e
ficheiros anexados.
Ainda neste separador, todos os tickets de incidente, pedido de alteração e
release relacionados com o pedido de serviço em questão são mostrados na tabela
indicada com o número 4. Estas relações são efectuadas quando o pedido de serviço
gera um incidente, gera um pedido de alteração, vai entrar para release ou então,
quando um incidente gera o pedido de serviço.
1 2 3
4
Figura 59 – 1º separador da página do pedido de serviço em resolução
72
A geração de tickets de incidente, pedido de alteração ou release pode ser
efectuada no separador ―Resolução‖, ilustrado na figura 60. Neste separador, o
helpdesker pode ainda pesquisar por soluções na base de conhecimento, como descrito
na secção 5.1.2, adicionar tarefas realizadas para a resolução do pedido de serviço,
encaminhar o mesmo para outro grupo de suporte ou enviar um inquérito de satisfação
ao requerente do pedido.
As tarefas que o helpdesker adiciona ao registo do pedido de serviço indicam o
que este fez para a resolução do mesmo. Estas tarefas podem ser adicionadas caso o
utilizador pressione o botão ―Adicionar tarefas…‖, assinalado com o número 7. A acção
efectuada origina a abertura de uma popup de preenchimento, ilustrada na figura 61.
Figura 60 - 2º separador da página do pedido de serviço em resolução
Figura 61 – Popup de adição/edição de tarefas
1
2
3 4
5
6
7 8
73
Como indicado na figura 61, o helpdesker deve indicar o título e descrição da
tarefa realizada, bem como a hora que começou a ser realizada e a hora de fim da
mesma. Neste caso, a hora de fim nunca pode ser igual ou inferior à hora de início da
tarefa. Para adicionar uma nova tarefa, gravando as alterações efectuadas, sem sair da
janela de popup, o utilizador deve pressionar o botão ―Gravar e Nova tarefa‖. Por outro
lado, o mesmo utilizador pode gravar as alterações e voltar à página indicada na figura
60, pressionando no botão ―Gravar e Sair‖.
As tarefas adicionadas são visíveis na tabela respectiva, indicada na figura 60.
Nesta tabela, os helpdeskers e Incident Manager podem ver qual o técnico que realizou
cada tarefa, o título desta, a hora de início e a hora de fim da realização da tarefa.
Adicionalmente, é possível monitorizar o tempo total despendido para a realização de
todas as tarefas. Este tempo é indicado em dias, horas e minutos. Cada tarefa pode ser
seleccionada na tabela, e posteriormente removida, bastando clicar no botão assinalado
com o número 8.
Durante o período de resolução do pedido de serviço, o helpdesker pode alterar o
estado do mesmo para um estado adicional, precisando pressionar o botão indicado com
o número 1. Esta acção despoleta a abertura de uma janela de popup, ilustrada na figura
62, onde o utilizador indica os motivos para a mudança de estado. Para que a urgência
do pedido de serviço seja alterada, o helpdesker deve clicar no botão assinalado com o
número 2, originando a abertura de uma janela de popup semelhante à da figura 62.
Nessa popup devem ser indicados os motivos para a mudança da urgência do pedido.
A figura acima ilustra a janela de popup usada para descrever os motivos para a
mudança de estado do pedido de serviço. A popup para indicar os motivos para a
mudança da urgência é semelhante à ilustrada na figura 62.
Figura 62 – Popup de mudança de estado
74
Como mencionado anteriormente, os pedidos de serviço podem gerar registos de
incidente, e noutros casos podem originar pedidos de alteração. Deste modo, para a
geração desses novos tickets, o helpdesker deve pressionar o botão assinalado com o
número 3, originando a abertura da janela correspondente ao formulário de registo desse
ticket. Após a submissão desse formulário, o registo gerado fica automaticamente
associado ao pedido de serviço, devendo aparecer na tabela dos registos relacionados,
ilustrada com o número 4 na figura 59.
Um pedido de serviço necessita por vezes de entrar numa release para que o(s)
serviço(s) correspondente(s) possa(m) ser implementado(s) no requerente desse pedido.
Dessa forma, o helpdesker deve explicar ao Release Manager os motivos que indiquem
a necessidade de colocar o pedido de serviço numa release.
Para se efectuar o pedido de release, o utilizador de suporte deve pressionar o
botão ―Gerar pedido de release…‖, que se encontra assinalado com o número 4. Esta
acção dá origem à abertura da janela de popup indicada na figura 63, onde devem ser
descritos os comentários a enviar, via email, ao Release Manager
O processo de encaminhamento será descrito na secção 5.2.5. No entanto, para
iniciar esse processo, o helpdesker deve pressionar o botão assinalado com o número 5.
A acção efectuada origina a abertura de uma janela de popup onde este utilizador deve
indicar os motivos do encaminhamento e para que grupo de suporte pretende
encaminhar o pedido.
Para que um pedido de serviço seja fechado, é necessário enviar um inquérito de
satisfação ao requerente do mesmo. O processo de fecho do pedido de serviço será
descrito na secção 5.2.6, sendo iniciado quando o helpdesker pressiona o botão
assinalado na figura 60 com o número 6.
Figura 63 – Popup de geração de pedido de release
75
O terceiro separador da página de resolução do pedido de serviço está ilustrado
na figura 64. Este separador apresenta todas as versões do pedido de serviço, com
excepção da última, o histórico e os activos do requerente que estão afectos a esse
pedido, bem como outros pedidos de serviço deste mesmo requerente.
A selecção de uma versão do pedido de serviço, ou de outro pedido de serviço,
origina a abertura de uma nova janela com a informação desse pedido. O helpdesker
tem a possibilidade de filtrar o histórico que pretende visualizar, seleccionando as datas
de início e fim dos registos de histórico, bem como a versão do pedido de serviço.
A figura 64 ilustra o que foi mencionado anteriormente. Na primeira tabela são
indicadas as versões do pedido de serviço em questão, com excepção da versão
corrente, sendo que na segunda tabela são apresentados todos os registos de histórico
desse mesmo pedido. A terceira tabela reflecte os activos do requerente que estão
afectos ao registo do pedido de serviço, e na última tabela são mostrados outros registos
de pedidos de serviço efectuados pela mesma pessoa.
1
2
3
4
Figura 64 - 2º separador da página do pedido de serviço em resolução
76
5.2.5 Encaminhamento de pedidos de serviço
O encaminhamento de um pedido de serviço pode ser efectuado tanto por um
helpdesker, como pelo Incident Manager. No entanto, o helpdesker apenas pode
encaminhar o pedido para o nível de suporte seguinte ou para um grupo de suporte de
outra categorização. Por seu lado, o helpdesker pode encaminhar o pedido de serviço
para outro processo, alterando a categorização, ou então para um técnico específico.
Para o encaminhamento do pedido de serviço, o helpdesker deve escrever algumas
observações para o próximo grupo de suporte, anexar ficheiros que ache relevante e
indicar para onde encaminha o pedido, se para o nível de suporte seguinte ou para um
grupo de outra categorização.
No caso do grupo de suporte para o qual o pedido de serviço foi encaminhado
pode não estar activo, o pedido de serviço é enviado para um grupo de suporte de uma
categorização genérica. Por exemplo, se o pedido estiver categorizado como ―Software
– Microsoft Office - Word ‖, então será encaminhado para ―Software – Microsoft Office
- Geral‖, e assim sucessivamente, até à categorização de ―Geral – Geral - Geral‖.
Contudo, se nenhum grupo de suporte, do fluxo de categorização mencionado
anteriormente, estiver activo, o pedido de serviço em questão é enviado
automaticamente para o Incident Manager.
Os helpdeskers do novo grupo de suporte ou o Incident Manager recebem um
email que descreve os motivos do pedido de encaminhamento, bem como os ficheiros
anexados a esse pedido.
Figura 65 – Janela de encaminhamento do helpdesker
77
Após o pedido de serviço ter sido encaminhado e uma nova versão do mesmo ter
sido gerada, o helpdesker actual deixa de ter o registo do pedido em questão na tabela
ilustrada na figura 58, que indica os pedidos de serviço que se encontra a tratar.
A tabela assinalada na figura 66 com o número 1 indica os pedidos de serviço que
o Incident Manager tem para encaminhar.
Para proceder ao encaminhamento de um pedido de serviço, o Incident Manager
deve seleccioná-lo da tabela anteriormente referida, originando a abertura do formulário
do pedido de serviço, como ilustrado na figura 59.
Como os helpdeskers, o Incident Manager pode adicionar tarefas, alterar o estado
e a urgência do pedido de serviço e, entre outras coisas, encaminhar o pedido. Este
encaminhamento inicia-se quando o utilizador referido despoleta a abertura da janela de
popup indicada na figura 67.
Figura 66 – Lista de pedidos de serviço para encaminhar
1
78
O Incident Manager, além de poder encaminhar o pedido de serviço para o
Change Manager, Release Manager, grupo de suporte de pedidos de serviço ou de
incidentes de outra categorização, pode também encaminhá-lo para uma determinada
pessoa. Para tal, deve indicar para que processo, entre IM, Request Fulfillment, CM ou
RDM, e a que pessoa (helpdesker, Change Manager ou Release Manager) deseja
encaminhar esse pedido.
O fluxo de encaminhamento para grupos de suporte de incidentes e pedidos de
serviço é efectuado da forma descrita na secção 5.2.5. Os helpdeskers do novo grupo de
suporte, Incident Manager, Change Manager ou Release Manager recebem um email
que descreve os motivos do pedido de encaminhamento, bem como os ficheiros
anexados a esse mesmo pedido.
Depois do pedido de serviço ter sido encaminhado e uma nova versão do mesmo
ter sido gerada, o Incident Manager deixa de ter o registo do pedido em questão na
tabela ilustrada na figura 66, que indica os pedidos de serviço a encaminhar.
5.2.6 Fecho de pedido de serviço
A última etapa do processo de resolução do pedido de serviço é o envio de um
inquérito de satisfação ao requerente. Além das mensagens de boas vindas e de
agradecimento, o inquérito é composto por perguntas configuradas no painel de
administração, como ilustrado na figura 68.
Figura 67 - Janela de encaminhamento do Incident Manager
79
Na figura 68 está listado o conjunto de perguntas a apresentar nos inquéritos de
satisfação. Estas perguntas podem ser de resposta aberta, ou de escolha múltipla, mas
apenas podem ser adicionadas 10 perguntas. Cada opção da escolha múltipla indica um
nível de satisfação configurável no painel de configuração, como ilustra a figura 69.
Os níveis de satisfação devem reflectir o que o requerente achou da resolução do
registo do seu pedido de serviço. Desta forma, o administrador pode definir no máximo
5 níveis, escolhendo a sua ordem de apresentação em cada pergunta.
Para que o requerente preencha o inquérito de satisfação, o helpdesker envia um
email ao mesmo com o link para esse inquérito.
Figura 68 – Lista de perguntas do inquérito de satisfação
Figura 69 – Lista de níveis de satisfação.
Figura 70 – Inquérito de satisfação
80
O requerente deve seleccionar o link enviado, originando a abertura de uma nova
página com o inquérito de satisfação ilustrado na figura 70.
Depois do preenchimento das perguntas do inquérito de satisfação, o requerente
deve dar o pedido de serviço como fechado. No caso do pedido não ser dado como
fechado, este utilizador deve escrever alguns comentários e sugestões para que seja mais
fácil efectivar a sua resolução por parte do helpdesker. Deste modo, o técnico de suporte
deve reabrir o pedido de serviço em questão e encontrar outra resolução para o mesmo.
Por outro lado, se o pedido de serviço for dado como fechado pelo requerente,
então passará automaticamente para o estado de ―Fechado‖, não podendo ser editado
por nenhum helpdesker ou Incident Manager.
5.3 Avaliação da solução
No fim da implementação dos processos descritos nas secções anteriores, foram
agendadas sessões de teste com alguns utilizadores finais da aplicação. Estas sessões
tiveram como objectivo detectar erros unitários e funcionais para futura correcção.
Ao longo dessas sessões de teste, os utilizadores finais assinalaram falhas e pontos
de melhoria, que foram prontamente corrigidos e implementados nos dias seguintes.
Após as devidas correcções feitas à solução implementada, foram realizadas novas
sessões de teste com os mesmos utilizadores.
No fim dos testes finais, os utilizadores finais deram a sua aprovação, dando como
terminado o processo de testes. No entanto, foram indicados outros pontos de melhoria
que entretanto já se encontram implementados.
81
Capítulo 6
Discussão
O presente capítulo consiste numa análise crítica ao trabalho desenvolvido até ao
momento, bem como numa abordagem às dificuldades encontradas e à forma como
estas foram mitigadas. Segundo os objectivos propostos no capítulo 1, verificou-se que,
com o trabalho desenvolvido até ao momento, a maioria desses objectivos têm sido
cumpridos.
Na análise comparativa das soluções líderes de mercado, foi necessária a
pesquisa de manuais de utilizador e de vídeos demonstrativos. No entanto, visto que as
ferramentas a analisar não estavam disponíveis em versões trial, a procura de
informação relevante para melhor compreensão dos processos a implementar foi mais
demorada do que o planeado. De modo a mitigar este problema, existiu a necessidade de
contactar outros colaboradores da Maksen, para que fosse possível trocar informação
útil à avaliação dessas soluções, nomeadamente em relação aos processos da ITIL® v3
a serem implementados neste projecto, e à forma como as ferramentas avaliadas
suportam os requisitos base desta solução de SDM.
Com base na experiência adquirida, através da análise de versões trial de
ferramentas SDM, e de estudos de mercado realizados pela Gartner e Forrester,
acredita-se que os resultados obtidos desta análise sejam meramente puristas, não
reflectindo o real valor das ferramentas líderes de mercado analisadas. Por serem
soluções de SDM best-of-breed de mercado, esse valor poderá estar compreendido entre
o 4 e 5, segundo a escala de maturidade indicada no capítulo 4, o que significa que no
mínimo, os requisitos se encontram padronizados e documentados, sendo pouco
provável a detecção de falhas.
Assim, acredita-se que após uma nova análise às ferramentas, de modo a
complementar a análise efectuada, os resultados obtidos estariam mais próximos do real
valor dessas ferramentas.
82
Nesta análise comparativa, revelou-se complexa a compreensão do processo de
Release & Deployment Management a implementar na solução âmbito. No entanto, esta
complexidade foi mitigada após os comentários proferidos em entrevistas realizadas
com os utilizadores finais da aplicação.
Na elaboração da primeira versão do Modelo de casos de uso e, apesar de esta
cumprir os objectivos propostos, existiram algumas dificuldades na identificação
correcta dos actores envolvidos, em especial no caso de uso ―Consultar FAQ‖, referente
ao processo de Knowledge Management. A complexidade residiu na diferença entre os
conceitos de ―Papel‖ e ―Perfil‖, sendo o primeiro imutável e advogado pela ITIL® v3, e
o segundo definido pela organização. De modo a diferenciar os dois termos acima
indicados, ficou acordada a utilização dos papéis ITIL® v3 para cada um dos processos
a implementar neste projecto. Assim, esses papéis poderiam ser associados aos perfis de
utilizador existentes numa organização, identificando as permissões de cada um dos
utilizadores para esta solução. Isto torna a aplicação final flexível e escalável, uma vez
que a mesma irá permitir a associação desses papéis ITIL® aos perfis da organização.
Esta solução também permitirá, a associação de mais que um papel ao mesmo perfil e,
possivelmente a adesão de novos papéis.
Após uma segunda análise ao caso de uso ―Consultar FAQ‖, constatou-se que o
papel de ―User‖ seria um papel mais geral com permissões mínimas, significando que
qualquer perfil de uma organização encontra-se associado a este papel. Deste modo, um
perfil que tenha associado o papel de ―Knowledge Manager‖ também tem a capacidade
aceder à funcionalidade de ―Consultar FAQ‖.
Para perceber os conceitos da solução final, bem como as suas relações, elaborou-
se um modelo de domínio, onde se identificaram certas ―classes conceptuais‖ sem
nenhuma relação para outra classe representada, uma vez que existiram dúvidas em
compreender se estas eram ou não conceitos do domínio do problema da aplicação.
Além disso, indicar as relações existentes entre as várias classes conceptuais suscitou
incerteza, ao ponto de não se saber se as relações conceptuais entre essas classes seriam
suficientes para suportar todos os casos de uso.
Na implementação da solução de SDM existiu a necessidade de adicionar mais
classes conceptuais às existentes no modelo de domínio, de modo a cobrir os requisitos
propostos. Nesta fase, procedeu-se à implementação dos 6 processos propostos para este
PEI, com maior foco nos processos de KM e Request Fulfillment.
83
Contudo, o desenvolvimento do processo de IM demorou mais do que o previsto,
atrasando o cumprimento dos prazos definidos no plano de trabalhos. A alteração de
conteúdo já implementado, a definição do design a atribuir ao formulário de suporte de
um técnico de incidentes, entre outros, foram factores críticos para tal incumprimento.
Por isso, todos os prazos para entrega de protótipos, documentos e testes não foram
antecipados, nem cumpridos no tempo indicado, impossibilitando a total aplicação da
metodologia ágil SCRUM.
Num cômputo geral, os objectivos iniciais foram cumpridos, estando a solução
final utilizável para a maior parte dos utilizadores e, possivelmente, o seu valor
compreendido entre o 4 e 5. Numa próxima versão, pretende-se complementar a solução
existente com alguns requisitos que não foram implementados.
6.1 Apreciação final
Terminado o projecto, é possível retirar um resultado bastante positivo, tanto a
nível académico como pessoal. Este PEI ofereceu-me a possibilidade de conhecer o
―mundo‖ da consultoria, bem como aprofundar os meus conhecimentos na área de
informática.
O trabalho realizado teve um grande impacto nas minhas competências,
permitindo-me adquirir outros conhecimentos e realçar os meus valores pessoais. No
decorrer do mesmo tive a oportunidade de contactar com a plataforma Outsystems, uma
tecnologia em expansão, aumentar a minha competência no desenvolvimento de
webservices e de reforçar o meu conhecimento sobre gerir uma base de dados
realcional.
Contudo, encontrei alguns problemas de logística, nomeadamente, problemas no
servidor de desenvolvimento. Este era utilizado por duas ou mais aplicações em
desenvolvimento, impossibilitando a correcta implementação da minha solução, não só
devido à existência de apenas uma licença OutSystems, mas também pela falta de
espaço no disco. Deste modo, por diversas vezes não me foi possível implementar,
publicar e testar a minha solução de SDM.
Por fim, e com o tempo disponível, desenvolvi uma aplicação com alguma
dimensão, juntamente com outro PEI, adquiri mais conhecimento, apliquei as minhas
competências, reforcei os meus valores pessoais, transmiti confiança à organização, por
isso o resultado final deste projecto é muito positivo.
84
Capítulo 7 Bibliografia
1. About Us: What is ITIL? OGC Web Site. [Online] APM Group Ltd, Outubro de
2007. [Citação: 19 de Novembro de 2010.]
2. Rudd, Colin. 4 The ITIL Framework. An Introductory Overview of ITIL®. s.l. :
itSMF Ltd, 2004.
3. —. Why Implement Service Management. [ed.] Alison Cartdlidge. An
Introductory Overview of ITIL®. Reading : itSMF Ltd, 2004, 3, pp. 8-9.
4. Cartlidge, Alison, et al. What is IT Service Management. [ed.] Alison
Cartlidge e Mark Lillycrop. An Introductory Overview of ITIL® v3. s.l. : The UK
Chapter of the itSMF, 2007, 2, pp. 6-7.
5. Rudd, Colin. An Introductory Overview of ITIL®. [ed.] Alison Cartlidge.
Reading : itSMF Ltd, 2004. pp. 1-40.
6. —. The ITIL Framework. [ed.] Alison Cartlidge. An Introductory Overview of
ITIL®. Reading : itSMF Ltd, 2004, 4, pp. 10 - 12.
7. Cartlidge, Alison, et al. Service Design. [ed.] Alison Cartlidge e Mark
Lillycrop. An Overview of ITIL® v3. s.l. : The UK Chapter of the itSMF, 2007, 5, pp.
18-23.
8. —. Service Strategy. [ed.] Alison Cartlidge e Mark Lillycrop. An Interview
Overview of ITIL® v3. s.l. : The UK Chapter of the itSMF, 2007, 4, pp. 12-17.
9. —. Service Transition. [ed.] Alison Cartlidge e Mark Lillycrop. An Interview
Overview of ITIL® v3. s.l. : The UK Chapter of the itSMF, 2007, 6, pp. 24-28.
10. —. Continual Service Improvement. [ed.] Alison Cartlidge e Mark Lillycrop.
An Interview Overview of ITIL® v3. s.l. : The UK Chapter of the itSMF, 2007, 8.
11. —. Service Operation. [ed.] Alison Cartlidge e Mark Lillycrop. An Interview
Overview of ITIL® v3. s.l. : The UK Chapter of the itSMF, 2007, 7, pp. 29-34.
12. —. An Introductory Overview of ITIL® v3. [ed.] Alison Cartlidge e Mark
Lillycrop. s.l. : The UKChapter of the itSMF, 2007. pp. 1-56.
85
13. ©OutSystems. Agile Development for Enterprise Web Applications |
OutSystems. [Online] [Citação: 24 de Novembro de 2010.]
http://www.outsystems.com/.
14. COLLABNET®. Scrum Sprint Planning Meeting. Scrum Sprint Planning
Meeting. [Online] [Citação: 17 de Novembro de 2010.]
http://scrummethodology.com/scrum-meetings/.
15. —. Scrum Methodology & Agile Scrum Methodologies. Scrum Methodology
& Agile Scrum Methodologies. [Online] [Citação: 17 de Novembro de 2010.]
http://scrummethodology.com/.
16. APM Group Ltd. ITIL® - What is ITIL? Official ITIL® Website. [Online]
APM Group Ltd, 2007. [Citação: 19 de Novembro de 2010.] http://www.itil-
officialsite.com/home/home.asp.
17. COLLABNET®. Scrum Sprint. Scrum Sprint. [Online] [Citação: 17 de
Novembro de 2010.] http://scrummethodology.com/scrum-sprint/.
18. —. Scrum Backlog. Scrum Backlog. [Online] [Citação: 18 de Novembro de
2010.] http://scrummethodology.com/the-scrum-backlog/.
19. Forrester Research, Inc. Forrester Research. Welcome to Forrester.com.
[Online] [Citação: 16 de Outubro de 2010.] http://www.forrester.com/FactSheet.
20. Gartner, Inc. About Gartner. Gartner Web Site. [Online] [Citação: 16 de
Outubro de 2010.] http://www.gartner.com/technology/about.jsp.
21. BMC SOftware, Inc. BMC® Service Level Management 7.0 User's Guide.
2006. p. 328.
22. BMC Software, Inc. BMC® Remedy® Service Desk: Incident Management
7.0 User'S Guide. 2006. p. 196.
23. —. BMC® Remedy® Change Management 7.0 User's Guide. 2006. p. 408.
24. Maksen. Capítulo 4 - Metodologias e Ferramentas. Projecto de Estágio -
Desenvolvimento de solução de Service Desk Management. Lisboa : Maksen, 2010.
25. Pinto, Nelson Ricardo Alves. Relatório Preliminar - Análise e
desenvolvimento de solução de Service Desk Management, aplicada à framework
ITIL® V3, com orientação aos processos de Knowledge Management e Service Asset &
Configuration Management. Lisboa : FCUL, 2010.