U
NIVERSIDADE DE
L
ISBOA
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
U
NIVERSIDADE DE
L
ISBOA
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
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.
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
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,
Conteúdo
Lista de Figuras ... viii
Lista de Acrónimos ... xi Capítulo 1 Introdução ... 1 1.1 Motivação ... 1 1.2 Objectivos ... 1 1.3 Âmbito de actuação ... 2 1.4 Contribuição ... 3
1.5 Formações e arranque do projecto ... 3
1.6 Enquadramento Institucional ... 4
1.7 Organização do Projecto ... 5
1.8 Estrutura do documento ... 7
Capítulo 2 Metodologia e Planeamento ... 8
2.1 Framework ITIL® ... 8
2.1.1 ITIL® v3 ... 9
2.2 Plataforma de desenvolvimento - OutSystems ... 13
2.2.1 Visão geral... 15
2.2.2 Componentes da plataforma OutSystems ... 16
2.3 Metodologia de desenvolvimento - SCRUM ... 18
2.3.1 Papéis ... 18
2.3.2 Reuniões ... 19
2.3.3 Artefactos ... 20
2.3.4 Sprint ... 20
2.4 Plano de Trabalhos ... 21
2.4.1 Plano de Trabalhos Inicial ... 21
2.4.2 Plano de Trabalhos Final ... 23
Capítulo 3 Contexto teórico dos processos implementados ... 24
3.1 Knowledge Management ... 25
3.2 Request Fulfillment ... 27
3.3 Outros processos ... 27
3.3.2 Problem Management ... 28
3.3.3 Change Management... 28
3.3.4 Release & Deployment Management ... 29
3.3.5 Service Asset & Configuration Management ... 29
3.3.6 Service Level Management... 29
Capítulo 4 Análise do problema e desenho da solução ... 30
4.1 Trabalho relacionado ... 30
4.1.1 Benchmark de mercado ... 30
4.1.2 Modelo de avaliação... 32
4.1.3 Apresentação de resultados ... 33
4.2 Definição de requisitos ... 35
4.3 Desenho do modelo conceptual ... 37
4.3.1 Modelo de casos de uso ... 37
4.3.2 Modelo de domínio ... 39
Capítulo 5 Solução implementada ... 40
5.1 Knowledge Management ... 40
5.1.1 Painel de administração ... 41
5.1.2 Criação de registos de conhecimento ... 46
5.1.3 Aprovação ... 49
5.1.4 Validação ... 52
5.1.5 Classificação de registos de conhecimento ... 55
5.1.6 Consultar FAQ ... 56
5.2 Request Fulfillment ... 57
5.2.1 Painel de administração ... 57
5.2.2 Criação de pedidos de serviço ... 67
5.2.3 Pick-up de pedidos de serviço ... 69
5.2.4 Tratamento de pedidos de serviço ... 70
5.3 Avaliação da solução ... 80
Capítulo 6 Discussão ... 81
6.1 Apreciação final ... 83
Lista de Figuras
Figura 1 – Organograma do projecto ... 6
Figura 2 – Ciclo de vida um serviço ... 10
Figura 3 – Descrição da plataforma ágil OutSystems ... 16
Figura 4 – Descrição da plataforma ágil. ... 17
Figura 5 – SCRUM Agile Methodology ... 18
Figura 6 – Calendário de ―alto-nível‖ ... 22
Figura 7 – Planeamento final ... 23
Figura 8 – Processos da ITIL® v3 implementados e respectivo mapeamento ... 24
Figura 9 – O fluxo de data para wisdom ... 26
Figura 10 – Relação entre CMDB, CMS e SKMS ... 26
Figura 11 - The Forrester Wave: Service Desk Management Tools Apr-2008... 31
Figura 12 - Gartner Magic Quadrant ITSM Oct-2008 ... 31
Figura 13 - Representação gráfica do modelo de avaliação ... 33
Figura 14 – Avaliação das soluções por dimensão ... 34
Figura 15 – Avaliação dos requisitos de funcionais... 34
Figura 16 – Avaliação de requisitos de integração ... 35
Figura 17 – Diagrama de Casos de Uso do processo de Knowledge Mgmt ... 38
Figura 18 - Diagrama de Casos de Uso do processo de Request Fulfillment ... 38
Figura 19 – Lista de campos adicionais ... 41
Figura 20 – Janela de criação/edição de campos adicionais ... 42
Figura 21 – Grupos de aprovação de registos de conhecimento ... 43
Figura 22 – Pagina de criação/edição dos grupos de aprovação ... 43
Figura 23 – Fluxo de aprovação dos registos de conhecimento ... 44
Figura 24 – Lista de estados de registos de conhecimento ... 44
Figura 25 – Janela de popup de criação/edição de um novo estado ... 45
Figura 26 – Lista de perguntas da FAQ ... 45
Figura 27 – Janela de popup para criação/edição de pergunta da FAQ ... 46
Figura 28 – Página de pesquisa de registos de conhecimento ... 46
Figura 29 – Resultados de pesquisa de registos de conhecimento ... 47
Figura 30 - Formulário de registo de conhecimento ... 48
Figura 32 – Registo de conhecimento para aprovar ... 49
Figura 33 – Registo de conhecimento para aprovação... 51
Figura 34 – Pop-up de rejeição de registo de conhecimento ... 51
Figura 35 - Registo de conhecimento para validar... 52
Figura 36 – Histórico do registo de conhecimento ... 53
Figura 37 – Registos de conhecimento e activos associados ... 53
Figura 38 – Janela de pop-up para adicionar activos ao registo de conhecimento 54 Figura 39 – Registo de conhecimento para classificação... 56
Figura 40 – Lista de perguntas mais frequentes ... 57
Figura 41 – Lista de categorias de 1º, 2º e 3º nível ... 58
Figura 42 – Janela de popup para a criação/edição de categorias ... 59
Figura 43 – Lista de serviços para a categorização ―Geral – Geral - Geral‖ ... 59
Figura 44 – Página de criação/edição de um serviço ... 60
Figura 45 – Lista de pacotes de serviços ... 61
Figura 46 – Página de criação/edição de um pacote de serviços ... 61
Figura 47 – Lista de campos adicionais ... 62
Figura 48 – Página de criação/edição de campos adicionais ... 62
Figura 49 – Lista de grupos de suporte de pedidos de serviço... 63
Figura 50 – Página de criação/edição dos grupos de suporte... 64
Figura 51 – Tabela de regras de encaminhamento de pedidos de serviço ... 64
Figura 52 – Lista de estados dos pedidos de serviço ... 65
Figura 53 – Janela de popup de criação/edição de um estado ... 66
Figura 54 – Matriz de prioridade de pedidos de serviço ... 66
Figura 55 – Catálogo de serviços do menu lateral ... 67
Figura 56 – Menu do Catálogo de serviços ... 67
Figura 57 – Formulário de registo de um pedido de serviço... 68
Figura 58 – Pedidos de serviço para tratar ... 69
Figura 59 – 1º separador da página do pedido de serviço em resolução ... 71
Figura 60 - 2º separador da página do pedido de serviço em resolução ... 72
Figura 61 – Popup de adição/edição de tarefas ... 72
Figura 62 – Popup de mudança de estado ... 73
Figura 63 – Popup de geração de pedido de release ... 74
Figura 64 - 2º separador da página do pedido de serviço em resolução ... 75
Figura 66 – Lista de pedidos de serviço para encaminhar ... 77
Figura 67 - Janela de encaminhamento do Incident Manager ... 78
Figura 68 – Lista de perguntas do inquérito de satisfação ... 79
Figura 69 – Lista de níveis de satisfação. ... 79
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.
Capítulo 1
Introdução
O presente capítulo introduz o projecto desenvolvido no âmbito da disciplina de PEI do 2º ano, com vista ao desenvolvimento da tese de Mestrado em Engenharia Informática. O projecto teve início no dia 02 de Setembro de 2010 na empresa Maksen, com o objectivo de analisar e desenvolver uma solução de Service Desk Management, segundo as melhores práticas advogadas pela ITIL® v3, tendo o seu término acontecido a 31 de Maio de 2011.
Ao longo deste capítulo serão descritos os objectivos deste projecto, o seu âmbito de actuação, contribuições em organizações/empresas de consultoria, a instituição onde foi desenvolvido, a organização do projecto, e por fim, a estrutura do presente documento.
1.1 Motivação
A motivação geral para a adopção de soluções de SDM está associada à cada vez maior complexidade dos ambientes de TI distribuídos que, aliada ao aumento da dependência da tecnologia por parte das empresas, criou os alicerces para uma sucedida gestão de serviços. Os helpdesks reactivos e autónomos já não são suficientes. Para satisfazer as exigências empresariais em termos de serviços de tecnologia fiáveis, as empresas de TI necessitam de processos de gestão de serviços integrados que vejam os componentes da tecnologia como partes inter-relacionadas dos serviços de TI prestados às empresas.
1.2 Objectivos
O objectivo deste projecto consistiu na implementação de uma ferramenta de suporte de TI aberta que permita uma utilização global, regional e/ou local, quer pela
Maksen, quer pelos seus clientes. A solução final deve actuar como um único ponto de contacto para os pedidos de utilizador, incidentes submetidos pelo mesmo e incidentes gerados nas infra-estruturas. Os seus workflows ITIL® flexíveis e com as melhores práticas deverão acelerar a restauração do serviço normal, ajudar a prevenir futuros eventos com impacto adverso no negócio e aumentar a eficiência dos recursos de TI.
Estes workflows devem capturar e localizar relações do início do incidente à correlação do problema, radicar a investigação da causa, dos erros conhecidos e pedidos de alterações. A solução inclui um knowledge management que oferece authoring rico, pesquisa de linguagem natural e serviço autónomo para reduzir o volume de incidentes e permitir uma maior resolução de suporte de primeiro nível. A CMDB1 refere quais os serviços empresariais e os utilizadores afectados e ajuda a diagnosticar a causa através da visibilidade para as dependências da infra-estrutura.
1.3 Âmbito de actuação
No âmbito deste projecto, pretendeu-se desenvolver uma solução que automatizasse e desse resposta aos processos de Service Desk, Gestão de Incidentes, Gestão de Problemas, Gestão de Alterações e Gestão de Activos e Serviços. Pretendeu-se ainda que esta solução unificasPretendeu-se uma baPretendeu-se 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.
As actividades desenvolvidas, no contexto do projecto, foram: organização e planeamento de projecto, definição de requisitos, desenho do modelo conceptual, especificação funcional e técnica, configuração/implementação, formação de utilizadores e testes de aceitação, e roll-out e documentação, bem como actividades transversais de gestão de Projecto e controlo de qualidade.
A orientação e coordenação académica deste processo foram desempenhadas pelo Prof. Doutor João Carlos Balsa da Silva, docente do Departamento de Informática da FCUL, e Eng. Miguel Ramos, Operational Manager da Maksen.
1.4 Contribuição
A solução final tem como objectivos ajudar a aumentar a disponibilidade dos sistemas críticos das empresas de consultoria ou clientes destas, acelerando a resolução de incidentes e problemas, bem como reduzir a duração e os volumes das chamadas de suporte.
Além disso, pretende-se aumentar a produtividade dos agentes de service desks, apoiar os recursos de TI e os utilizadores, aumentar a disponibilidade das infra-estruturas de TI das empresas e encaminhar rapidamente os pedidos para o suporte correcto.
Por fim, com a solução desenvolvida deseja-se identificar as causas core para eliminar os incidentes recorrentes e estabelecer uma solução comum para a comunidade de consultoria ou clientes desta, de suporte de TI que permita uma utilização de forma global, regional e/ou local.
1.5 Formações e arranque do projecto
Como mencionado no Relatório Preliminar [25], numa fase inicial definiu-se o plano das tarefas a executar ao longo do projecto e o seu modelo de acompanhamento, bem como se realizaram formações na framework ITIL®, através da plataforma e-learning SkillPort, e na plataforma de desenvolvimento OutSystems.
A primeira das formações dividiu-se em duas partes, ―ITIL® v2 Foundation‖ e ―IT Infrastructure Library (ITIL) v3 Foundation Syllabus v4.2 exam‖, referentes às frameworks ITIL® v2 e ITILv3, respectivamente.
Por outro lado, a formação de OutSystems decompôs-se em três cursos: ―OutSystems Developer – Course 1‖, ―OutSystems Developer – Course 2‖ e ―OutSystems Developer – Course 3.
Após as formações e o levantamento dos requisitos da solução implementada no âmbito deste projecto, procedeu-se a uma análise comparativa de soluções SDM best-of-breed de mercado, sendo esta abordada no quarto capítulo.
No decorrer da primeira fase do projecto, realizou-se uma reunião de Kick-Off, a qual pretendeu oferecer aos seus intervenientes uma visão geral da solução desenvolvida. Deste modo, referiram-se os objectivos, o âmbito da actuação, o planeamento e organização, bem como o modelo de acompanhamento do projecto, identificando-se os factores críticos para o seu sucesso.
1.6 Enquadramento Institucional
O projecto foi realizado em parceria com a Maksen, inicialmente GMS – Global Management Solutions. Esta instituição foi criada no início de 2003 e centra a sua actividade na prestação de serviços de consultoria de negócio, de sistemas de informação e de engenharia/redes de comunicações.
Em termos globais, a Maksen conta com uma rede global e acesso a mais de 1.000 profissionais, que contribuem com as suas competências, talento, motivação e sentido de missão para a criação de valores dos seus clientes, trabalhando em conjunto com estes, de forma a superar, sempre que possível, os objectivos estabelecidos. O seu crescimento e reconhecimento no mercado ao longo dos anos devem-se a uma consultoria inovadora, perseverante e com uma orientação muito vincada para ―fazer acontecer‖.
As boas práticas de gestão da Maksen têm vindo recorrentemente a ser distinguidas pela multinacional Great Place to Work Institute, incluindo prémios especiais como ―Melhor empresa Portuguesa para Trabalhar‖ (2010), ―Melhor empresa para Jovens‖ (2010 e 2011) e ―Melhor empresa para Executivos‖ (2009). Além destas distinções, a Maksen é a primeira consultora em Portugal a possuir simultaneamente as certificações ISO 9001 e 27001.
Para fazer face às exigências do mercado, a Maksen é composta por três divisões complementares:
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.
As principais responsabilidades desses elementos e respectivos comités são os seguintes:
Comité de Acompanhamento – aprovação dos produtos intermédios e finais do Projecto, confirmação da adequação do trabalho desenvolvido face aos objectivos definidos e coordenação e facilitação da integração das decisões de carácter estratégico com os princípios gerais de gestão;
Comité Operacional – validação dos produtos intermédios e finais do Projecto e da adequação do trabalho desenvolvido face aos objectivos definidos e coordenação da Equipa de Projecto;
Sponsor de Projecto – dinamização do Projecto internamente,
contribuindo de forma determinante para o sucesso da solução na resposta às necessidades específicas;
Controlo de Qualidade – é política da Maksen, para a realização de qualquer Projecto, incluir nas equipas de trabalho uma figura de controlo da qualidade, que tem como responsabilidade principal validar os outputs do Projecto face às expectativas e necessidades; e
Gestão de Projecto – disponibilização dos recursos humanos, logísticos, técnicos e funcionais da Maksen necessários ao desenvolvimento do Projecto, intermediação de contactos e reuniões necessárias ao
desenvolvimento do Projecto e participação na execução de tarefas planeadas com a restante equipa de trabalho; e
Equipa Core de Projecto – execução das actividades de Projecto planeadas ao nível da Gestão de Projecto. Como anteriormente
mencionado, este projecto foi realizado em parceria com o PEI do aluno Ricardo Reis, tendo estado a seu cargo, para além dos quatro processos comuns, os processos de Request Fulfillment e Service Level Management (SLM).
1.8 Estrutura do documento
O presente relatório encontra-se estruturado em sete capítulos:
Capítulo 2 – Metodologia e Planeamento: tem como objectivo descrever as metodologias e ferramentas que suportam o desenvolvimento da
solução de SDM, bem como o plano de trabalhos;
Capítulo 3 – Contexto teórico dos processos implementados: descrição teórica dos seis processos implementados no âmbito deste PEI;
Capítulo 4 – Análise do problema e desenho da solução: referência ao trabalho relacionado com a solução desenvolvida, avaliando soluções best-of-breed de mercado face aos requisitos disponibilizados pela Maksen, aos requisitos implementados e ao modelo conceptual da solução;
Capítulo 5 – Solução implementada: descrição detalhada da
implementação dos processos foco do projecto e dos testes efectuados aos mesmos;
Capítulo 6 – Discussão: tem como objectivo apresentar uma análise crítica e factores críticos de sucesso ao trabalho; e
Capítulo 7 – Bibliografia: indicação das referências bibliográficas usadas para a elaboração deste relatório.
Capítulo 2
Metodologia e Planeamento
O desenvolvimento da solução no âmbito deste Projecto obedeceu a standards metodológicos e respeitou as melhores práticas advogadas pelo itSMF.
A implementação desta solução foi feita na plataforma OutSystems Agile Platform, pela facilidade de desenvolvimento e tempo de projecto reduzido, adoptando a metodologia advogada pelo fabricante do software, a SCRUM Agile Methodology.
2.1 Framework ITIL®
Information Technology Infrastructure Library (ITIL®) [16] é a abordagem mais adoptada para a gestão de serviços de TI, fornecendo uma framework prática para identificação, planeamento, entrega e suporte de serviços TI para o negócio.
A framework foi desenhada e desenvolvida no final da década de 1980 pela Central Computer and Telecommunications Agency (CCTA) e actualmente está sob a custódia da OGC (Office for Government Commerce) da Inglaterra. Em 2000/2001, com o intuito de tornar a ITIL® mais acessível, a versão inicial foi revista e substituída pela ITIL® v2 (versão 2), que consiste em sete volumes, tornando-se a base padrão para a norma BS 15000, um anexo da norma ISO 20000. Mais recentemente, em 2007, foi lançada a versão 3 da ITIL® (também conhecida como a ITIL Refresh Project) que consiste em vinte e seis processos e funções, agrupados em cinco volumes e arranjados sobre os conceitos de uma estrutura de ciclo de vida dos serviços.
Esta framework defende que os serviços TI devem estar alinhados com as necessidades do negócio e sustentar os principais processos, dando orientações às organizações sobre o modo de usar as TI para facilitar a mudança nos negócios, a sua transformação e o seu crescimento. A ITIL® fornece ainda compreensivas orientações
de boas práticas para todos os aspectos de ―end-to-end‖ de service management, padronizando a totalidade do espectro de pessoas, processos e produtos.
Por outro lado, fornece uma descrição detalhada sobre importantes práticas de TI com checklists, tarefas e procedimentos que uma organização de TI pode adaptar às suas necessidades.
A framework ITIL® deve ser implementada seguindo uma abordagem ―adopt and adapt‖, de modo a que processos efectivos e apropriados sejam postos em prática. A sua adopção pode oferecer aos utilizadores uma enorme gama de benefícios que incluem:
Melhoria de serviços de TI;
Custos reduzidos;
Satisfação do cliente melhorada através de uma abordagem mais profissional na prestação do serviço;
Melhoria da produtividade;
Melhoria no uso das habilidades e experiência; e
Melhoria da prestação de serviços a terceiros.
Para entender o que é a gestão de serviços, é necessário perceber o que são serviços. Estes são um meio de entregar valor aos clientes, facilitando os resultados que estes desejam obter, sem assumirem os custos e riscos específicos.
Assim, pode-se afirmar que a gestão de serviços é o que permite que uma organização compreenda os serviços que presta, garanta que os serviços realmente facilitam os resultados que os seus clientes querem obter, compreenda o valor dos serviços, e perceba e trate todos os custos e riscos associados a esses serviços.
2.1.1 ITIL® v3
A framework ITIL® v3 [12] (também conhecida como ITIL® Refresh Project) é uma nova abordagem, com base no ciclo de vida dos serviços e uma nova estrutura, usada para diferenciar as práticas essenciais do modelo com novos processos, tendo uma visão integrada de TI, negócios e fornecedores.
Existem dois conceitos chaves sobre a versão 3 da ITIL®, entre eles:
Serviço de TI – ―Um serviço é um meio para entregar valor aos clientes, propiciando os resultados que eles queiram alcançar sem que eles tenham que assumir custos e riscos específicos‖; e
Gestão de Serviços de TI – ―Gestão de serviços é um conjunto de capacidades organizacionais específicas (processos, métodos, funções, papéis e actividades) para prover valor aos clientes sob a forma de serviços‖.
A figura 2 mostra o ciclo de vida de um serviço de TI, sendo que cada uma das fases desse ciclo é descrita de seguida:
Service Strategy [8] – descreve a primeira fase do ciclo de vida de um serviço e consiste em assegurar que as organizações estão em posição de lidar com os custos e riscos associados ao Portfolio de Serviços. As decisões tomadas, no que diz respeito à Service Strategy, têm consequências a longo prazo, incluindo aquelas de efeito retardado. Ainda nesta fase, os requisitos de negócio são identificados e os resultados esperados são acordados num SLP (Service Level Package), que
representa um determinado nível de utilidade pública e de garantia para um determinado pacote de serviços, sendo desenhado para atender as necessidades de um determinado padrão de negócio.
A estratégia de serviço de qualquer organização deve ser baseada num conhecimento fundamental de que os seus clientes não compram produtos, mas apenas compram a satisfação de necessidades específicas. Portanto,
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;
o Processos (Processes) - os processos, papéis e actividades envolvidas no fornecime nto de serviços de TI; e
o Sócios (Partners) - os vendedores, fabricantes e fornecedores usados na assistência e suporte do fornecimento de serviços de TI.
Service Transition [9] – descreve a terceira fase do ciclo de vida de um serviço, na qual o seu papel é a entrega de serviços necessários ao negócio para uso operacional. A Service Transition oferece isto ao receber o SDP da etapa anterior, entregando-o na etapa Service Operation sempre que um elemento necessário é exigido para a operação contínua e de suporte desse serviço.
O foco desta fase é a implementação de todos os aspectos do serviço, não apenas na aplicação e como ela é usada em circunstâncias ―normais‖, sendo necessário assegurar que a mesma pode operar em circunstâncias extremamente imprevisíveis ou anormais, e que o suporte para falhas ou erros está disponível. A implementação do serviço é acompanhada, testada e validada, e o SKMS2 (Service Knowledge Management System) é
actualizado com as informações do ambiente de produção.
Esta etapa está organizada pelos processos de ―Change Management‖, ―Service Asset and Configuration Management‖ (SACM), ―Knowledge Management‖, ―Release and Deployment Management‖, ―Transition Planning and Support‖, ―Service Validation and Testing‖ e ―Evaluation‖.
Service Operation [11] – representa a quarta etapa do ITIL® v3 e cujo propósito é oferecer níveis de acordados de serviço para utilizadores e clientes, e gerir as aplicações, tecnologia e infra-estrutura que suportam a oferta dos serviços. É apenas durante esta etapa do ciclo de vida que os serviços realmente acrescentam valor ao negócio, e é sua responsabilidade assegurar que este valor seja entregue.
Aqui, o serviço é mantido em funcionamento de acordo com o SLA (Service Level Agreement) estabelecido, para fornecer os resultados esperados.
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
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.
2.2.1 Visão geral
A plataforma OutSystems destina-se principalmente ao desenvolvimento de aplicações empresariais com uma estrutura web-based3. Além disso, tem suporte para redes móveis e de e-mail e permite a integração com os sistemas legacy4 normalmente existentes nas organizações actuais. A grande diferença entre esta plataforma e outras ferramentas semelhantes assenta na metodologia de desenvolvimento proposta e na flexibilidade apresentada.
Apoiando-se na metodologia ágil, a OutSystems promove uma aproximação built-to-change, na qual, independentemente da fase do ciclo de vida das aplicações, novas funcionalidades podem ser facilmente adicionadas, erros corrigidos e comentários analisados, com riscos reduzidos e sem graves consequências para o negócio.
A plataforma OutSystems, por se apoiar nessa metodologia ágil, aborda a actual necessidade de rápido desenvolvimento e contínua mudança das aplicações desenvolvidas, permitindo a criação de aplicações que respeitem, quer as necessidades tecnológicas, quer as necessidades de negócio das organizações. Desta forma, esta metodologia surgiu da adaptação dos conceitos da SCRUM Agile Methodology5, às características da plataforma criada.
Esta plataforma de desenvolvimento aposta num estilo de programação visual drag’n’drop sendo possível a criação de aplicações ―sem ter de se escrever qualquer linha de código‖. Desde o desenho do modelo de dados, criação de Interfaces, definição de lógica de negócio ou instalação, tudo pode ser feito visualmente.
3 Sistemas web-based são aqueles executados através de páginas, tais como Firefox ou Internet
Explorer.
4 É uma tecnologia antiga que continua a ser usada, normalmente porque ainda continua a
funcionar para as necessidades do utilizador, apesar de nova tecnologia ou métodos mais eficazes de executar uma tarefa já estarem disponíveis.
5
Figura 3 – Descrição da plataforma ágil OutSystems
A Figura 3 representa a relação entre os componentes base com o Hub Server, descrita na secção 2.2.2.
2.2.2 Componentes da plataforma OutSystems
A plataforma OutSystems é constituída por quatro componentes que suportam toda a criação, alteração e manutenção de aplicações web:
Service Studio - componente de desenvolvimento visual, destinado à criação, alteração e instalação das aplicações web desenvolvidas,
denominadas por eSpaces6. Este componente permite o desenvolvimento de interfaces de utilizador, modelo de dados, web services, regras de segurança, integração com componentes e agendamento de actividades. Através de um processo 1-Click Publish, o qual verifica, guarda, efectua o upload no componente de execução, compila e instala a aplicação. O componente Service Studio é um ambiente de desenvolvimento,
tecnologicamente independente da infra-estrutura que aloja as aplicações, e baseado em ―.Net‖ ou Java, sendo ―.oml7‖ a extensão dos ficheiros construídos.
Integration Studio - componente que permite criar componentes personalizados (extensões) para integrar com diversos sistemas legacy. Estas extensões disponibilizam módulos, codificados em C# ou Java, e
acesso a base de dados externas (que não a do Hub Server) que podem ser reutilizados pelos eSpaces. Uma vez publicadas, estas extensões podem ser utilizadas na componente de desenvolvimento como blocos visuais para permitir a interacção das aplicações com os sistemas existentes, sendo ―xif‖ 8
a extensão dos ficheiros produzidos pelo Integration Studio.
Service Center - permite a monitorização e a gestão das aplicações, oferecendo acesso centralizado à informação relativa a todos os recursos da plataforma, tais como versões de aplicações, auditorias, monitorização e criação de relatórios em tempo de execução. Com estas funcionalidades torna-se mais fácil o acompanhamento e o controlo da execução das aplicações.
Hub Server - componente central responsável pela execução. Este orquestra todas as compilações, instalações e qualquer actividade que decorra em tempo de execução, sendo o local onde todos os objectos desenvolvidos necessitam de ser publicados antes da sua utilização. Neste componente, os eSpaces são traduzidos para código ―.Net” ou Java, compilados e disponibilizados ao utilizador final.
As empresas ou prestadores de serviços operam centralmente sobre o Hub Server para suportar o desenvolvimento de aplicações empresariais.
8
Extension and Integration Framework.
A figura 4 apresenta o percurso efectuado pelas aplicações e extensões até ao repositório de dados para depois serem disponibilizados. Os eSpaces são criados no Service Studio e as extensões no Integration Studio.
2.3 Metodologia de desenvolvimento - SCRUM
A metodologia usada para este projecto foi a SCRUM Agile Methodology[15]. Esta consiste num processo iterativo e incremental para o desenvolvimento do produto e para a gestão de tarefas. A agilidade que suporta esta metodologia de gestão e planeamento, traz uma nova dimensão de capacidade de resposta, adequabilidade, eficácia e eficiência na gestão actual dos processos.
A figura 5 ilustra como funciona o SCRUM. Depois do Product backlog e do Sprint backlog, descritos na secção 2.3.3, ocorrem iterações de 2 a 4 semanas, com reuniões diárias, para que no final de cada uma das iterações exista como resultado um produto para demonstração.
2.3.1 Papéis
A SCRUM Agile Methodology é um esqueleto do processo que contém grupos de práticas e papéis predefinidos, onde se destacam:
Scrum Master: papel sem responsabilidade por gerir a equipa, mas sim por garantir que não existe impedimentos para que se consiga alcançar os objectivos do sprint (referido na secção 2.3.4). Caso existam várias
nas reuniões com os restantes Scrum Masters, representando também a sua equipa e os seus interesses perante o Product Owner.
Product Owner: papel responsável pelo produto e com maior
responsabilidade. Tem como tarefas definir, priorizar e estimar todas as funcionalidades, através do preenchimento do product backlog. Este também é o responsável por comunicar à equipa os interesses dos
stakeholders, efectuar reuniões de planeamento e demonstrar as entregas efectuadas.
Team Member: o papel com a responsabilidade de desenvolver e entregar as funcionalidades do produto. As equipas organizam-se entre elas para conseguirem da melhor maneira alcançar os objectivos do sprint.
2.3.2 Reuniões
Esta metodologia compreende um conjunto de reuniões com o intuito de definir as actividades a realizar, monitorizar o seu progresso e manter todos os envolvidos ao corrente desse progresso. Entre as reuniões[14] associadas a esta metodologia, destacam-se:
Sprint Planning Meeting: reunião realizada antes do início de cada sprint (descrito na secção 2.3.4), e onde o Product Owner e a equipa negoceiam que requisitos serão tratados pela equipa naquele sprint. Nesta reunião, o Product Owner decide que requisitos são de elevada prioridade para a release e quais irão gerar o maior valor de negócio, tendo a equipa o poder de afastar as preocupações ou impedimentos.
Daily Scrum Meeting: reunião diária entre a equipa de trabalho, com o objectivo de perceber o estado do projecto. Durante esta reunião, cada membro da equipa responde a 3 questões: ―O que fiz desde a última reunião?‖, ―O que vou fazer até à próxima reunião?‖ e ―Quais os impedimentos que prevejo até à próxima reunião?‖.
Sprint Review Meeting reunião onde é revisto o trabalho completo e o trabalho não completo. O trabalho completo é apresentado aos
Sprint Retrospective Meeting é a reflexão efectuada no final de cada sprint sobre a forma de como este correu, identificando possíveis
melhorias sobre forma de trabalhar. Além disso, o SCRUM Master poderá identificar restrições ao progresso de equipa e trabalhar na sua mitigação.
2.3.3 Artefactos
A metodologia SCRUM relaciona-se com um conjunto de artefactos[18] úteis ao desenvolvimento de uma solução. Os artefactos são:
Product backlog ou Scrum backlog: documento de análise detalhado que apresenta todos os requisitos para um sistema, projecto ou produto. De uma maneira mais simples, este termo podia ser descrito como sendo uma lista de tarefas a realizar, expressa em ordem de prioridade com base no valor comercial que cada peça de trabalho irá gerar. Filosoficamente, o scrum backlog é o motor do negócio, decompondo a visão geral do produto em incrementos de trabalho que se podem gerir, chamados de Product Backlog Items (PBIs). Apesar de ser da responsabilidade da equipa a conclusão do trabalho, o Product Owner é o único que consegue priorizar o mesmo num scrum backlog.
Sprint backlog: representa o resultado das planning meetings.
Essencialmente, é uma lista de tarefas que a equipa precisa de completar durante o sprint, a fim de transformar um conjunto seleccionado de itens do product backlog num aumento da funcionalidade. Ao contrário dos PBIs, as tarefas do sprint backlog têm um tempo estimado, sendo responsabilidade das equipas manter o sprint backlog actualizado. Este artefacto mostra o que está completo e o que falta fazer, ajudando os membros da equipa a realizarem uma daily scrum meeting eficaz.
2.3.4 Sprint
Esta metodologia é destinada a projectos compostos por uma sequência de iterações (sprints), as quais poderão ter uma duração de duas a quatro semanas, sendo que, no final de cada iteração, um conjunto de funcionalidades do produto final deverá ser apresentado.
Em cada sprint, é implementado um conjunto de requisitos, descriminados no sprint backlog, o qual foi determinado durante a reunião de planeamento do sprint. Durante o mesmo, não é possível alterar esse conjunto de requisitos, uma vez que o Product Owner deve respeitar a capacidade da equipa para criar o seu plano de acção, não podendo sobrecarregá-la de mais trabalho até à reunião de planeamento do próximo sprint.
Devido ao desenvolvimento das actividades ser timeboxed9, a iteração deve terminar no tempo previsto. No entanto, se os requisitos não são implementados por algum motivo, então são descartados e reconsiderados em futuras iterações.
Uma vez concluída cada iteração, a equipa realiza uma demonstração do software, sendo que, no final de todas as elas, obtém-se um sistema com a totalidade das funcionalidades implementadas, as quais foram sendo testadas, adaptadas e aprovadas paralelamente com o seu desenvolvimento.
2.4 Plano de Trabalhos
Durante o tempo de estágio, o projecto encontrou complexidades relacionadas com a logística do servidor, o incumprimento de requisitos e inexperiência no uso da plataforma de Outsystems, o que levou a um atraso na entrega da solução final. A existência de um plano de mitigação não foi suficiente para a resolução de todos os obstáculos.
2.4.1 Plano de Trabalhos Inicial
De acordo com a solução implementada, é de seguida indicado o faseamento inicialmente proposto para o projecto, organizado pelos componentes desenvolvidos.
9 Técnica comum de gestão de tempo em planeamento de projectos, onde o calendário é dividido
num número de períodos de tempo distintos (timeboxes), com cada parte a ter o seu próprio prazo, orçamento e outputs.
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 /
documentação da solução‖, as quais se encontravam compreendidas entre Dezembro de 2010 e Maio de 2011.
2.4.2 Plano de Trabalhos Final
O planeamento final, apresentado na figura seguinte, reflecte o incumprimento por completo da metodologia SCRUM Agile.
O planeamento final do projecto apresenta os últimos meses de estágio, que em nada corresponde ao plano inicial. Na figura 7 é possível verificar que o projecto não foi concluído dentro dos 9 meses de estágio, derrapando até ao mês de Julho.
A duração de 7 meses (Dezembro - Junho) da Etapa III – OUTPUT, em vez dos 5 meses (Dezembro - Abril) estipulados no plano inicial, causou o atraso na conclusão do PEI. Para o atraso anteriormente mencionado, contribuíram vários factores, dos quais se destacam o elevado número de requisitos a implementar, a falta de experiência no desenvolvimento de aplicações na plataforma Outsystems, bem como alguns problemas técnicos no servidor onde a aplicação estava a ser implementada.
Capítulo 3
Contexto teórico dos processos implementados
Este Projecto de Engenharia Informática constituiu na implementação de seis processos disponibilizados pela ITIL® v3, no que diz respeito à solução de Service Desk Management desenvolvida.
A figura 8 ilustra os processos disponibilizados pela ITIL® v3, suportados pelas cinco fases do ciclo de vida de um serviço. Dos seis processos implementados neste Projecto, os de Incident Management, Problem Management, Change Management e Release & Deployment Management representam o tronco comum à solução a desenvolver, e os de Knowledge Management e Request Fulfillment reflectem os processos específicos deste PEI.
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.
O processo de Knowledge Management estará centrado no Service Knowledge Management System (SKMS), que é um repositório central dos dados de TI de uma organização, informação e conhecimento. Subjacente a este conhecimento estará uma quantidade considerável de dados, que serão armazenados num repositório lógico central ou num CMS e CMDB, como ilustrado na figura 10.
O papel de Knowledge manager designa alguém com habilidades versáteis e que esteja confortável com os conceitos de comportamento/cultura organizacional, processos, branding & marketing e tecnologia.
Figura 9 – O fluxo de data para wisdom
3.2 Request Fulfillment
O processo de Request Fulfillment, integrado no livro Service Operation, é um dos dois processos que foram explorados com mais detalhe ao longo deste projecto.
Os grandes objectivos deste processo passam essencialmente por:
Dar a possibilidade aos utilizadores de requisitarem e receberem serviços standard;
Criar e prestar esses serviços;
Fornecer informação aos utilizadores e clientes sobre os serviços disponíveis e os procedimentos para os obter; e
Auxiliar o utilizador com informações gerais, queixas e comentários.
Um pedido de serviço[11] é um pedido de um utilizador por informações ou conselhos, por uma alteração standard, ou por acesso a um serviço de TI.
Todos os pedidos devem ser registados e o seu ciclo de vida devidamente acompanhado. Este processo deve incluir procedimentos adequados de aprovação dos pedidos antes de estes serem satisfeitos.
3.3 Outros processos
Nesta subsecção serão apresentados os processos comuns ao projecto supramencionado.
3.3.1 Incident Management
É o processo[11] que se enquadra na fase de Service Operation, e lida com todos os incidentes, o que pode incluir falhas ou questões reportadas pelos utilizadores, através da equipa técnica, ou automaticamente detectado e relatado por ferramentas de monitorização de eventos.
O principal objectivo deste processo é restaurar a normal operação do serviço tão rápido quanto possível e minimizar o impacto adverso nas operações de negócio, garantindo assim que os melhores níveis possíveis de qualidade de serviço e disponibilidade são mantidos.
Os incidentes são normalmente detectados pelo processo de Event Management ou por utilizadores que contactam o service desk. Os incidentes são categorizados para
identificar quem deve trabalhar neles e para a análise de tendências, e são priorizados de acordo com a urgência e o impacto no negócio.
Se um incidente não consegue ser resolvido rapidamente, então deve ser escalado. Um escalonamento funcional passa o incidente para uma equipa de suporte técnico com habilidades mais apropriadas, no entanto um escalonamento hierárquico envolve níveis apropriados de gestão.
Depois de um incidente ter sido investigado e diagnosticado, e a resolução tenha sido testada, o Service Desk deve assegurar que o utilizador esteja satisfeito antes de o incidente ser fechado.
3.3.2 Problem Management
O processo de Problem Management[11] está inserido na fase de Service Operation, e é responsável por gerir o ciclo de vida de todos os problemas. Os objectivos primários do Problem Management são prevenir problemas e incidentes resultantes de acontecer, eliminar incidentes recorrentes e minimizar o impacto de incidentes que não podem ser prevenidos.
Um problema é uma causa de um ou mais incidentes. A causa não é normalmente conhecida aquando de um registo de problema ser criado, de modo que o processo de Problem Management é responsável pela sua investigação.
O Problem Management inclui diagnosticar causas de incidentes, determinar a sua resolução, e assegurar que a mesma é implementada. Este processo também mantém informação sobre problemas, soluções adequadas e resoluções.
Os problemas são categorizados numa forma similar aos incidentes, mas o objectivo é perceber as causas, documentar soluções e pedidos de alterações para, permanentemente, resolver os problemas. As soluções são documentadas numa Known Error Database10 (KEDB), que aumenta a eficiência e eficácia da Gestão de Incidentes.
3.3.3 Change Management
Este processo[9] está incluído na etapa de Service Transition, e assegura que as alterações são registadas, avaliadas, autorizadas, priorizadas, planeadas, testadas, implementadas, documentadas e revistas numa maneira controlada. O propósito deste processo é assegurar que métodos padronizados são usados para o tratamento rápido e
eficiente de todas as alterações, que as mesmas são registadas num Configuration Management System11 (CMS) e que o risco geral do negócio é minimizado.
O Change Management abrange as alterações de serviços. Uma alteração de um serviço é a adição, modificação ou remoção de um serviço autorizado, planeado ou suportado ou de uma componente do serviço e a sua documentação associada.
O processo em questão proporciona, ao negócio, redução de erros nos serviços novos ou alterados e implementação mais rápida, mais precisa de mudança, permitindo limitar os fundos e recursos para se concentrar sobre essas mudanças, de modo a conseguir maiores benefícios para o negócio.
3.3.4 Release & Deployment Management
O processo de Release & Deployment Management[9] faz parte da fase de Service Transition, tendo como fim construir, testar e prestar os serviços especificados pelo Service Design de modo a cumprir as exigências dos stakeholders e alcançar os objectivos pretendidos.
O objectivo deste processo é implementar releases em produção e estabelecer o uso eficaz do serviço, a fim de distribuir valor ao cliente e ser capaz de transmitir os serviços operacionais.
3.3.5 Service Asset & Configuration Management
Este processo foi implementado no âmbito de outro Projecto que decorreu na mesma empresa, e que teve como foco a solução desenvolvida.
3.3.6 Service Level Management
Este processo foi implementado no âmbito de outro Projecto que decorreu na mesma firma, e que teve como foco a solução desenvolvida.
11 A CMS é um modelo lógico coerente da infra-estrutura da organização de TI, tipicamente
Capítulo 4
Análise do problema e desenho da solução
Este capítulo descreve o trabalho relacionado, a análise de requisitos e o desenho da solução desenvolvida.
Após o levantamento dos requisitos da solução implementada no âmbito deste projecto, procedeu-se a uma análise comparativa de soluções SDM best-of-breed de mercado. De seguida, efectuou-se uma análise dos requisitos implementados, o desenho e especificação dos casos de uso da aplicação e o modelo de domínio da mesma.
4.1 Trabalho relacionado
A presente secção descreve o processo de análise do trabalho relacionado com a solução âmbito deste projecto. Para isso, realizou-se um levantamento dos requisitos a implementar e, com base em estudos de mercado efectuados pela Forrester Research, Inc e Gartner, Inc, procedeu-se a uma análise comparativa de soluções de SDM best-of-breed de mercado.
4.1.1 Benchmark de mercado
Para a análise comparativa das soluções de SDM best-of-breed de mercado, foram tidos em conta os estudos realizados pela Forrester Research, Inc[19] e a Gartner, Inc[20]. Estas são líderes em pesquisa de informação de TI e de consultoria, fornecendo conselhos pragmáticos e com visão de futuro para os líderes mundiais em tecnologia e negócio, eventos e programas executivos peer-to-peer.
Segundo a Forrester, as ferramentas da BMC, CA, HP e IBM são as soluções líderes de mercado, constituindo-se como aquelas que se consideraram para o desenvolvimento da solução implementada. De acordo com o estudo, as ferramentas da BMC e da HP apresentam uma oferta de soluções e uma estratégica de mercado fortes, tendo deste modo uma presença bastante relevante no mercado mundial. As ferramentas da CA e IBM encontram-se noutros quadrantes, lutando para terem também uma maior presença no mercado.
Segundo a Gartner, as ferramentas da BMC e da HP encontram-se no quadrante das soluções líderes de mercado, ou seja, são aquelas que evidenciam uma visão de negócio e uma capacidade de execução dessa visão mais consolidadas.
Através da experiência que a Maksen tem com soluções deste tipo, e por serem as que têm maior presença no mercado português, foram avaliadas as ferramentas BMC Software – Remedy IT Service Management e CA Unicenter Service Desk, de forma avaliar o comportamento das mesmas face aos requisitos disponibilizados.
A primeira ferramenta, pertencente à organização BMC, foca-se em reduzir a complexidade dos processos, tornando o suporte ao cliente, gestão de alterações, activos e pedidos, num processo contínuo e integrado. A segunda, propriedade da CA Technologies, tem como pontos fortes a automatização da gestão de incidentes, problemas, e conhecimento, o suporte on-line interactivo e a análise avançada da causa raiz dos problemas.
Figura 12 - Gartner Magic Quadrant ITSM Oct-2008 Figura 11 - The Forrester Wave: Service Desk Management Tools
