UNIVERSIDADE DE LISBOA Faculdade de Ciências Departamento de Informática

Transcrição

1 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

2

3 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

4

5 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.

6

7 Hélio Jonilson Van-Dúnen Filipe.

8

9 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. i

10 ii

11 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. iii

12 iv

13 Conteúdo Lista de Figuras... viii Lista de Acrónimos... xi Capítulo 1 Introdução Motivação Objectivos Âmbito de actuação Contribuição Formações e arranque do projecto Enquadramento Institucional Organização do Projecto Estrutura do documento... 7 Capítulo 2 Metodologia e Planeamento Framework ITIL ITIL v Plataforma de desenvolvimento - OutSystems Visão geral Componentes da plataforma OutSystems Metodologia de desenvolvimento - SCRUM Papéis Reuniões Artefactos Sprint Plano de Trabalhos Plano de Trabalhos Inicial Plano de Trabalhos Final Capítulo 3 Contexto teórico dos processos implementados Knowledge Management Request Fulfillment Outros processos Incident Management v

14 3.3.2 Problem Management Change Management Release & Deployment Management Service Asset & Configuration Management Service Level Management Capítulo 4 Análise do problema e desenho da solução Trabalho relacionado Benchmark de mercado Modelo de avaliação Apresentação de resultados Definição de requisitos Desenho do modelo conceptual Modelo de casos de uso Modelo de domínio Capítulo 5 Solução implementada Knowledge Management Painel de administração Criação de registos de conhecimento Aprovação Validação Classificação de registos de conhecimento Consultar FAQ Request Fulfillment Painel de administração Criação de pedidos de serviço Pick-up de pedidos de serviço Tratamento de pedidos de serviço Encaminhamento de pedidos de serviço Fecho de pedido de serviço vi

15 5.3 Avaliação da solução Capítulo 6 Discussão Apreciação final Capítulo 7 Bibliografia vii

16 Lista de Figuras Figura 1 Organograma do projecto... 6 Figura 2 Ciclo de vida um serviço Figura 3 Descrição da plataforma ágil OutSystems Figura 4 Descrição da plataforma ágil Figura 5 SCRUM Agile Methodology Figura 6 Calendário de alto-nível Figura 7 Planeamento final Figura 8 Processos da ITIL v3 implementados e respectivo mapeamento Figura 9 O fluxo de data para wisdom Figura 10 Relação entre CMDB, CMS e SKMS Figura 11 - The Forrester Wave: Service Desk Management Tools Apr Figura 12 - Gartner Magic Quadrant ITSM Oct Figura 13 - Representação gráfica do modelo de avaliação Figura 14 Avaliação das soluções por dimensão Figura 15 Avaliação dos requisitos de funcionais Figura 16 Avaliação de requisitos de integração Figura 17 Diagrama de Casos de Uso do processo de Knowledge Mgmt Figura 18 - Diagrama de Casos de Uso do processo de Request Fulfillment Figura 19 Lista de campos adicionais Figura 20 Janela de criação/edição de campos adicionais Figura 21 Grupos de aprovação de registos de conhecimento Figura 22 Pagina de criação/edição dos grupos de aprovação Figura 23 Fluxo de aprovação dos registos de conhecimento Figura 24 Lista de estados de registos de conhecimento Figura 25 Janela de popup de criação/edição de um novo estado Figura 26 Lista de perguntas da FAQ Figura 27 Janela de popup para criação/edição de pergunta da FAQ Figura 28 Página de pesquisa de registos de conhecimento Figura 29 Resultados de pesquisa de registos de conhecimento Figura 30 - Formulário de registo de conhecimento Figura 31 Lista dos registos de conhecimento do utilizador autenticado viii

17 Figura 32 Registo de conhecimento para aprovar Figura 33 Registo de conhecimento para aprovação Figura 34 Pop-up de rejeição de registo de conhecimento Figura 35 - Registo de conhecimento para validar Figura 36 Histórico do registo de conhecimento Figura 37 Registos de conhecimento e activos associados Figura 38 Janela de pop-up para adicionar activos ao registo de conhecimento 54 Figura 39 Registo de conhecimento para classificação Figura 40 Lista de perguntas mais frequentes Figura 41 Lista de categorias de 1º, 2º e 3º nível 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 Figura 44 Página de criação/edição de um serviço Figura 45 Lista de pacotes de serviços Figura 46 Página de criação/edição de um pacote de serviços Figura 47 Lista de campos adicionais Figura 48 Página de criação/edição de campos adicionais Figura 49 Lista de grupos de suporte de pedidos de serviço Figura 50 Página de criação/edição dos grupos de suporte Figura 51 Tabela de regras de encaminhamento de pedidos de serviço Figura 52 Lista de estados dos pedidos de serviço Figura 53 Janela de popup de criação/edição de um estado Figura 54 Matriz de prioridade de pedidos de serviço Figura 55 Catálogo de serviços do menu lateral Figura 56 Menu do Catálogo de serviços Figura 57 Formulário de registo de um pedido de serviço Figura 58 Pedidos de serviço para tratar Figura 59 1º separador da página do pedido de serviço em resolução 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 Figura 62 Popup de mudança de estado Figura 63 Popup de geração de pedido de release Figura 64-2º separador da página do pedido de serviço em resolução Figura 65 Janela de encaminhamento do helpdesker ix

18 Figura 66 Lista de pedidos de serviço para encaminhar Figura 67 - Janela de encaminhamento do Incident Manager 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 x

19 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. xi

20 xii

21 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 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 1

22 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 CMDB 1 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. Pretendeuse 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. 2

23 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 infraestruturas 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. 3

24 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-ofbreed 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 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 Para fazer face às exigências do mercado, a Maksen é composta por três divisões complementares: 4

25 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. 5

26 Figura 1 Organograma do projecto seguintes: As principais responsabilidades desses elementos e respectivos comités são os 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 6

27 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 bestof-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. 7

28 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 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 8

29 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 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 9

30 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. Figura 2 Ciclo de vida um serviço 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 10

31 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; 11

32 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 SKMS 2 (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. 12

33 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 13

34 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. 14

35 2.2.1 Visão geral A plataforma OutSystems destina-se principalmente ao desenvolvimento de aplicações empresariais com uma estrutura web-based 3. Além disso, tem suporte para redes móveis e de e permite a integração com os sistemas legacy 4 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 builtto-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 Methodology 5, à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

36 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 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 espaces 6. 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.oml 7 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. 16

37 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. Figura 4 Descrição da plataforma ágil. 8 Extension and Integration Framework. 17

38 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. Figura 5 SCRUM Agile Methodology 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 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 18

39 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 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. 19

40 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 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 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. 20

41 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 timeboxed 9, 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 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. 21

42 Figura 6 Calendário de alto-nível 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 22

43 documentação da solução, as quais se encontravam compreendidas entre Dezembro de 2010 e Maio de Plano de Trabalhos Final O planeamento final, apresentado na figura seguinte, reflecte o incumprimento por completo da metodologia SCRUM Agile. Figura 7 Planeamento final 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. 23

44 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. Figura 8 Processos da ITIL v3 implementados e respectivo mapeamento 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. 24

45 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. 25

46 Figura 9 O fluxo de data para wisdom 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. Figura 10 Relação entre CMDB, CMS e SKMS 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. 26

47 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 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 27

48 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 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 Database 10 (KEDB), que aumenta a eficiência e eficácia da Gestão de Incidentes 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. 28

49 eficiente de todas as alterações, que as mesmas são registadas num Configuration Management System 11 (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 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 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 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. 29

50 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-ofbreed de mercado 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

51 Figura 11 - The Forrester Wave: Service Desk Management Tools Apr-2008 Figura 12 - Gartner Magic Quadrant ITSM Oct-2008 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. 31

52 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. 32

53 Por outro lado, para cada requisito, procedeu-se ao seguinte modelo de avaliação: Atribuição de Ponderação Avaliação de ferramentas Obtenção de resultados Avaliação dos requisitos. Média ponderada de cada processo nos requisitos funcionais. Especificação do peso de cada requisito Média ponderada de cada processo nos requisitos de integração. Comentários sobre a forma como cumpre os requisitos. Resultado final. Figura 13 - Representação gráfica do 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 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

54 Figura 14 Avaliação das soluções por dimensão 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 15 Avaliação dos requisitos de funcionais 34

55 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. Figura 16 Avaliação de requisitos de integração 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 35

56 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. 36

57 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 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. 37

58 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 38

59 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 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. 39

60 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. 40

61 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. 1 2 Figura 19 Lista de campos adicionais 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. 41

62 Figura 20 Janela de criação/edição de campos adicionais 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. 42

63 Figura 21 Grupos de aprovação de registos de conhecimento 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 Figura 22 Pagina de criação/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 43

64 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 Figura 23 Fluxo de aprovação dos registos de conhecimento 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. 1 2 Figura 24 Lista de estados de registos de conhecimento 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. 44

65 Figura 25 Janela de popup de criação/edição de um novo estado 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. 2 2 Figura 26 Lista de perguntas da FAQ 1 2 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

66 Figura 27 Janela de popup para criação/edição de pergunta da FAQ 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 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 46

67 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. 1 2 Figura 29 Resultados de pesquisa de registos de conhecimento Na figura acima indicada, é possível 3 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. 47

68 Figura 30 - Formulário de registo de conhecimento 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

69 Figura 31 Lista dos registos de conhecimento do utilizador autenticado Cada registo de conhecimento é identificado univocamente pelo seu número de registo. Este número, KM , divide-se em quatro partes distintas, entre elas: KM representa o ticket gerado, cuja designação é Knowledge Management; 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 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 Figura 32 Registo de conhecimento para aprovar 49

70 4 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 aprovador 12 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. 50

71 Figura 33 Registo de conhecimento para aprovação 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 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. Figura 34 Pop-up de rejeição de registo de conhecimento 51

72 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 Figura 35 - Registo de conhecimento para validar 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 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. 52

73 Figura 36 Histórico do registo de conhecimento 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 Figura 37 Registos de conhecimento e activos associados 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. 53

74 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. Figura 38 Janela de pop-up para adicionar activos ao registo de conhecimento 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. 54

75 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 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. 55

76 Figura 39 Registo de conhecimento para classificação 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 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. 56

77 Figura 40 Lista de perguntas mais frequentes 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 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 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. 57

78 Figura 41 Lista de categorias de 1º, 2º e 3º nível 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. 58

79 Figura 42 Janela de popup para a criação/edição de categorias 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. 1 2 Figura 43 Lista de serviços para a categorização Geral Geral - Geral 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 59

80 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. Figura 44 Página de criação/edição de um serviço 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ços 13. 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. 60

81 1 Figura 45 Lista de pacotes de serviços 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. Figura 46 Página de criação/edição de um pacote de serviços 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. 61

82 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. 1 2 Figura 47 Lista de campos adicionais 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 48 Página de criação/edição de campos adicionais 62

83 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. Figura 49 Lista de grupos de suporte de pedidos de serviço 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. 63

84 Figura 50 Página de criação/edição dos grupos de suporte 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. 1 Figura 51 Tabela de regras de encaminhamento de pedidos de serviço 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. 64

85 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 Figura 52 Lista de estados dos pedidos de serviço 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

86 Figura 53 Janela de popup de criação/edição de um estado 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 Figura 54 Matriz de prioridade de pedidos de serviço 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 66