LEANDRO LOPES KÖNIG GERENCIAMENTO DE REQUISIÇÃO DE MANUTENÇÃO DE SOFTWARE: UMA PROPOSTA BASEADA NAS GERÊNCIAS DE INCIDENTES E PROBLEMAS DO ITIL JOINVILLE - SC 2009
1 UNIVERSIDADE DO ESTADO DE SANTA CATARINA CENTRO DE CIÊNCIAS TECNOLÓGICAS CCT DEPARTAMENTO DE CIÊNCIA DA COMPUTAÇÃO LEANDRO LOPES KÖNIG GERENCIAMENTO DE REQUISIÇÃO DE MANUTENÇÃO DE SOFTWARE: UMA PROPOSTA BASEADA NAS GERÊNCIAS DE INCIDENTES E PROBLEMAS DO ITIL Trabalho de conclusão de curso submetido à Universidade do Estado de Santa Catarina como parte dos requisitos para a obtenção do grau de Bacharel em Ciência da Computação Orientador: Doutor Edson Murakami JOINVILLE - SC 2009
2 LEANDRO LOPES KÖNIG GERENCIAMENTO DE REQUISIÇÃO DE MANUTENÇÃO DE SOFTWARE: UMA PROPOSTA BASEADA NAS GERÊNCIAS DE INCIDENTES E PROBLEMAS DO ITIL Trabalho de conclusão de curso aprovado como requisito para a obtenção do grau de Bacharel em Ciência da Computação no curso de graduação da Universidade do Estado de Santa Catarina. Banca Examinadora: Orientador: Doutor, Edson Murakami Membro: Doutor, Claudiomir Selner Membro: Doutor, Cristiano Damiani Vasconcellos Joinville, / /2009
3 RESUMO A atividade de manutenção de software é caracterizada pela modificação de um produto de software já entregue ao cliente. Essas mudanças podem ser requisitadas devido à correção de defeitos, melhorias de desempenho, agregação de novas funcionalidades e outros motivos, por isso as organizações acabam tendo grande dependência dos serviços da área de TI. Para obter maior eficiência e eficácia no provimento desses serviços a área de TI precisa adequar seus processos e utilizar as melhores práticas de gerenciamento dos mesmos. Com o objetivo de melhorar o processo de requisição de manutenção de software no setor de TI da empresa Ciser Parafusos e Porcas, foi proposto um novo processo para o gerenciamento de requisição de manutenção de software baseado nas melhores práticas adotadas pelo ITIL (Information Technology Infrastructure Library) como a central de serviços, gerência de incidentes e problemas. Para desenvolvimento e implantação desta proposta foram estudados conceitos de manutenção de software, central de serviços, gerência de incidentes e problemas e melhoria de processos. Os resultados da implantação são demonstrados através da análise comparativa do número de requisições feitas ao setor antes e após a implantação. E da análise de aderência do processo implantado à metodologia ITIL, através da aplicação do questionário desenvolvido pela OGC que avalia o nível de maturidade. Palavras - chave: ITIL. Gerenciamento. Manutenção. Processo. Requisição.
4 ABSTRACT The activity of software maintenance is characterized by the modification of a software product already delivered to the customer. These changes may be required to correction of defects, improvements in performance, bundling of new features and other reasons, so the organizations end up having great dependency services in the area of IT. For greater efficiency and effectiveness in providing these services the area of IT needs to adapt its processes and use best practices in management of them. Aiming to improve the process of software maintenance on the IT sector of the company Ciser Parafusos e Porcas, proposed a new process for managing requests for maintenance of software based on best practices adopted by the ITIL (Information Technology Infrastructure Library) as the central services, management of incidents and problems. Development and implementation of this proposal will be studied concepts of software maintenance, central services, management of incidents and problems and improving processes. The results of the implementation are demonstrated by comparative analysis of the number of requests made to the sector before and after deployment. And the analysis of adherence to the process implemented ITIL methodology through the application questionnaire developed by OGC which evaluates the level of maturity. Keywords: ITIL. Maintenance. Management. Process. Request.
5 LISTA DE ABREVIAÇÕES COBIT Control Objectives for Information and Related Technology ITIL Information Technology Infrastructure Library OGC Office of Government Commerce SSI Solicitação do Serviço de Informática TI Tecnologia da Informação TPI Tecnologia e Processos de Informação UML Unified Modeling Language
6 LISTA DE FIGURAS Figura 2.1 - Organograma do setor TPI... 16 Figura 2.2 - Visão geral do processo de requisição de manutenção de software... 17 Figura 2.3 - Formulário de Solicitação de Serviço de Informática... 18 Figura 2.4 - Diagrama de atividades do processo antigo... 20 Figura 3.1 Princípio básico do COBIT... 27 Figura 3.2 - Aspectos envolvidos pelo ITIL... 28 Figura 3.3 - Componentes do ITIL... 30 Figura 3.4 - Os processos de Suporte a Serviços... 30 Figura 4.1 - Visão geral do processo... 38 Figura 4.2 - Diagrama de atividades para gerenciamento de incidentes... 40 Figura 4.3 - Diagrama de atividades para gerenciamento das requisições de melhoria de software... 42 Figura 4.4 Diagrama de atividades do gerenciamento de problemas... 44 Figura 4.5 Abrindo chamado e classificando por módulo e caminho... 49 Figura 4.6 - Definindo natureza e status... 50
7 Figura 4.7 Tela de vínculo entre chamado e tarefa... 51 Figura 4.8 - Criando tarefa e definindo analista responsável... 52 Figura 4.9 - Analista assume a tarefa... 53 Figura 4.10 - Inserindo providência para solucionar a tarefa... 54 Figura 4.11 - Encerrando a tarefa... 55 Figura 4.12 - Encerrando chamado e comunicando solicitante... 56
8 LISTA DE GRÁFICOS Gráfico 4.1 - Percentual do nível de aderência por processo... 46 Gráfico 5.1 - Número de SSI no período de agosto a outubro de 2008... 58 Gráfico 5.2 - Número de solicitações após a implantação do processo... 59 Gráfico 5.3 - Número de chamados criados por email e por telefone... 60 Gráfico 5.4 - Distinção do número total de chamados pela natureza... 60 Gráfico 5.5 - Nível de maturidade: Central de Serviços... 62 Gráfico 5.6 - Nível de maturidade: Gerenciamento de Incidente... 64
9 LISTA DE TABELAS Tabela 4.1 - Aderência das atividades da proposta com as práticas do ITIL... 45 Tabela 4.2 - Justificativa da utilização parcial ou não utilização de cada prática... 46 Tabela 5.1 - Tabela de síntese da Central de Serviços... 62 Tabela 5.2 - Tabela de síntese do processo de Gerenciamento de Incidentes... 64
10 SUMÁRIO 1 INTRODUÇÃO... 13 1.1 OBJETIVOS... 14 1.2 ORGANIZAÇÃO DO TRABALHO... 14 2 PROCESSO DE GERENCIAMENTO DE REQUISIÇÃO DE MANUTENÇÃO DE SOFTWARE... 16 2.1 SETOR DE TECNOLOGIA DE PROCESSOS E INFORMAÇÃO... 16 2.2 PROCESSO DE REQUISIÇÃO DE MANUTENÇÃO DE SOFTWARE... 17 2.2.1 Fluxograma... 19 2.2.2 Problemas... 22 3 REVISÃO BIBLIOGRÁFICA... 24 3.1 MANUTENÇÃO DE SOFTWARE... 24 3.1.1 Tipos de manutenção de software... 24 3.1.2 Custo de manutenção de software... 25 3.2 MELHORIA DE PROCESSO... 26 3.3 COBIT (CONTROL OBJECTIVES FOR INFORMATION AND RELATED TECHNOLOGY)... 26 3.4 ITIL (INFORMATION TECHNOLOGY INFRASTRUCTURE LIBRARY)... 28 3.4.1 Histórico... 29 3.4.2 Componentes... 29
11 3.4.3 Central de serviços... 31 3.4.4 Gerenciamento de incidentes... 32 3.4.5 Gerenciamento de problemas... 32 3.5 AVALIAÇÃO DE MATURIDADE... 33 3.6 TRABALHOS RELACIONADOS... 34 3.6.1 Estudo do modelo ITIL e avaliação das gerências de incidentes e mudanças no contexto de um processo de negócio real... 35 3.6.2 Gerenciamento de serviços de TI e modelagem de processo de configuração ITIL em uma plataforma de serviços sensíveis a contexto... 35 3.6.3 Gerenciamento de serviços de TI: Uma proposta de integração de processos de melhoria e gestão de serviços... 35 4 UM PROCESSO DE GERENCIAMENTO DE REQUISIÇÃO DE MANUTENÇÃO DE SOFTWARE BASEADO NAS PRÁTICAS DO ITIL... 37 4.1 PROPOSTA DO PROCESSO DE GERENCIAMENTO DE REQUISIÇÃO DE MANUTENÇÃO DE SOFTWARE BASEADO NAS PRÁTICAS DO ITIL... 37 4.1.1 Processo de Gerenciamento de Requisição de Manutenção de Software baseado nas práticas do ITIL... 37 4.1.2 Fluxograma... 39 4.2 MUDANÇAS NO PROCESSO DE GERENCIAMENTO DE REQUISIÇÃO DE MANUTENÇAO DE SOFTWARE... 47 4.3 FERRAMENTA DE APOIO AO PROCESSO DE GERENCIAMENTO DE REQUISIÇÃO DE MANUTENÇAO DE SOFTWARE... 48 4.3.1 Implantação do fluxo para o gerenciamento das requisições no 0800net... 48 4.3.1.1 Abrir chamado/classificar chamado por módulo, caminho e natureza... 48 4.3.1.2 Criar tarefa/definir analista responsável... 50 4.3.1.3 Assumir tarefa... 52 4.3.1.4 Solucionar tarefa... 53 4.3.1.5 Encerrar a tarefa... 54 4.3.1.6 Encerrar chamado e comunicar solicitante... 55
12 5 RESULTADOS DA IMPLANTAÇÃO... 57 5.1 ANÁLISE DO RESULTADO... 57 5.1.1 Análise comparativa... 58 5.1.2 Análise de aderência... 61 5.1.2.1 Análise de aderência: Central de Serviços... 61 5.1.2.2 Análise de aderência: Gerenciamento de Incidentes... 63 6 CONSIDERAÇÕES FINAIS... 66 6.1 CONCLUSÕES... 66 6.2 TRABALHOS FUTUROS... 67 REFERÊNCIAS BIBLIOGRÁFICAS... 68 ANEXOS... 71
13 1 INTRODUÇÃO A atividade de manutenção de software tem um importante papel no ciclo de vida do software e ela é caracterizada pela modificação de um produto de software já entregue ao cliente [PADUELLI, 2007]. Essas mudanças podem ser requisitadas devido à correção de defeitos, melhorias de desempenho, agregação de novas funcionalidades e outros motivos, por isso as organizações acabam tendo grande dependência dos serviços da área de TI. Para obter maior eficiência e eficácia no provimento desses serviços, o setor de TI tem que buscar as melhores práticas de gerenciamento dos mesmos [MARTINS, 2006]. A manutenção de software pode ser responsável por mais de 70% de todo o esforço despendido por uma organização de software e chegar a um índice de 80% dos orçamentos de software [PRESSMAN, 2006]. Tendo como objetivo a redução destes custos com as organizações de software no quesito de manutenção de sistemas, a Ciser Parafusos e Porcas, empresa do ramo metal mecânico, possui um setor de TI responsável por suprir as necessidades de manutenção e oferecer suporte aos usuários que utilizam softwares no processo de negócios. Com o intuito de melhorar o processo de requisição de manutenção de software que não possui padronização. Este trabalho tem como objetivo definir e implantar um novo processo de gerenciamento de requisição de manutenção de software baseado nas práticas da área de Suporte a Serviços de TI do ITIL, contribuindo assim com uma melhor visão sobre os recursos do setor de TI.
14 1.1 OBJETIVOS Objetivo Geral: Definir e implantar um processo de gerenciamento de requisição de manutenção de software baseado nas práticas da área de Suporte a Serviços de TI do ITIL. Os objetivos específicos são listados abaixo: Estudar os conceitos do modelo do ITIL; Mapear o fluxo do processo atual; Definir um processo que atenda as necessidades da organização; Selecionar indicadores de melhoria de processo; Definir uma ferramenta de Workflow; Implementar, testar e registrar os resultados do novo processo. 1.2 ORGANIZAÇÃO DO TRABALHO O presente trabalho está organizado da seguinte forma: no Capítulo 1 têm-se a introdução da monografia que aborda o tema do trabalho e os objetivos almejados; no Capítulo 2 será apresentado o processo antigo de gerenciamento de requisição de manutenção de software e os problemas encontrados; no Capítulo 3 são abordados os conceitos que auxiliaram na resolução dos problemas encontrados; no Capítulo 4 são apresentadas a proposta para o processo para o gerenciamento de requisição de manutenção de software baseado na utilização da central de serviços, nas gerências de incidentes e problemas do ITIL, as mudanças na proposta para a implantação do processo e a ferramenta com o fluxo implantado; no Capítulo 5 são apresentados os resultados da implantação; no Capítulo 6 são expostas as
15 considerações finais e os trabalhos futuros; finalizando o trabalho têm-se as referências bibliográficas e os anexos.
16 2 PROCESSO DE GERENCIAMENTO DE REQUISIÇÃO DE MANUTENÇÃO DE SOFTWARE Neste capítulo é apresentado o processo de gerenciamento de requisição de manutenção de software antes das melhorias. Também serão abordados os problemas decorrentes deste processo encontrados no setor responsável por oferecer suporte a toda tecnologia de informação da Ciser Parafusos e Porcas. 2.1 SETOR DE TECNOLOGIA DE PROCESSOS E INFORMAÇÃO O setor de Tecnologia de Processos e Informação (TPI) (Figura 2.1) é responsável por oferecer suporte a toda tecnologia de informação da empresa, seja ela referente à infra-estrutura, à sistemas de informação e à micro-informática. Gerência TPI Coordenador TPI Analistas de Infra-estrutura Analistas de Sistemas Analistas de Suporte - Helpdesk Analistas de Suporte - Micro - Informática Figura 2.1 - Organograma do setor TPI
17 O setor já possuía uma central de serviços chamada de Helpdesk que utiliza o software 0800net para registrar e gerenciar todas as requisições para as áreas de Infraestrutura e Micro-informática. Este processo foi baseado nas práticas do ITIL e foi um dos fatores que influenciou a utilização destas mesmas práticas para a definição da proposta deste trabalho. O foco do presente trabalho foi melhorar o processo de requisição de manutenção de software para os analistas de sistemas inserindo-a na central de serviços juntamente com as outras áreas do setor. 2.2 PROCESSO DE REQUISIÇÃO DE MANUTENÇÃO DE SOFTWARE O escopo do trabalho dos analistas de sistemas é atender as solicitações de serviços dos usuários internos que utilizam quaisquer sistemas de informação usados na empresa (Figura 2.2). Figura 2.2 - Visão geral do processo de requisição de manutenção de software
18 As solicitações podem ser divididas em 2 tipos: Solicitações para tratamento de incidentes: Entravam no setor através de email e telefone, sendo feitas diretamente aos analistas; não possuindo registro, padrão e o conhecimento do coordenador do setor. Solicitações relacionadas à melhoria e adaptação de software: Entravam no setor através da Ordem de Serviço chamada de Solicitação de Serviço de Informática (SSI), formulário preenchido manualmente mostrado na Figura 2.3. Figura 2.3 - Formulário de Solicitação de Serviço de Informática
19 Ambas as solicitações deveriam entrar no setor através da SSI. Mas devido à urgência e prioridade do tratamento dos incidentes, os usuários entravam em contato direto com os analistas solicitando o tratamento do mesmo, sendo assim, um ponto a ser melhorado no processo. Para as solicitações de melhoria de software é utilizado um formulário. Esse formulário possui um padrão onde foi possível mapear e definir o fluxo do processo de desenvolvimento. Têm seus problemas, além de ser manual, fato que incomoda tanto solicitantes como os analistas, também não possui indicadores que mensuram o esforço despendido na solução das mesmas. Nas próximas seções é tratado o mapeamento deste processo de solicitações de melhoria de software, e também os problemas gerados com a prática dos dois tipos de solicitações para o setor de TPI. 2.2.1 Fluxograma Através de entrevistas com o coordenador do setor e com os analistas foi possível mapear o fluxo, sendo possível criar um diagrama de atividades (Figura 2.4) do processo antigo de solicitações relacionadas à melhoria e adaptação de software. Facilitando assim identificar responsabilidades e oportunidades de melhoria no processo.
20 Figura 2.4 - Diagrama de atividades do processo antigo A criação da Solicitação de Serviço de Informática (SSI) tem como início a identificação pelo usuário de um problema onde a solução trará qualquer tipo de
21 melhoria no processo envolvido, ou com a identificação de uma melhoria do processo. O usuário preenche os campos no formulário: Solicitante, Setor, Data, Data Prevista para Conclusão, Tipo de Serviço, Programa/Transação, Descrição Detalhada do Serviço, Justificativa de necessidade, Viabilidade econômica, Custo/benefício. Para validação da SSI é preciso que haja a assinatura do Coordenador e da Gerência do setor do solicitante, onde após a validação é enviada ao Coordenador do setor de TPI que é responsável pela avaliação do módulo ou área de negócios que a solicitação abrange encaminhado-a ao analista responsável do módulo. O analista ao receber a SSI faz a primeira análise levando em consideração o tamanho das alterações, a viabilidade do que está sendo solicitado, a interferência com outras áreas da empresa, a necessidade e a urgência da solicitação. Se o que está sendo solicitado tem um nível alto de complexidade fica a cargo do analista decidir a necessidade de uma reunião com o solicitante. Caso influencie em outras áreas, decidir a necessidade de reunião com os analistas responsáveis das áreas/módulos atingidos pela alteração. E se é necessária a contratação de serviços externos para desenvolvimento. Para o início do desenvolvimento se faz uma análise detalhada dos requisitos definindo o escopo do serviço e se o desenvolvimento for realizado pelo programador. O analista é responsável pela criação da documentação técnica que não possui padronização, onde dará subsídios ao desenvolvimento de projetos novos ou alterações em programas existentes. Após a fase de desenvolvimento inicia-se a fase de teste que compreende no primeiro momento, os testes unitários em ambiente de desenvolvimento. Caso não
22 sejam encontrados erros de programação, passa-se para o teste de integração com outros processos e módulos. A terceira etapa de testes consiste nos testes do usuário também em ambiente de teste ficando a cargo do mesmo a aprovação do programa. O analista, após a aprovação do usuário, encerra a SSI preenchendo os campos de Responsável, Execução, Data de Conclusão e, se necessário, o campo de Observação com uma informação relevante. Após isso, encaminha para o Coordenador do setor de TPI onde o mesmo armazena junto com outras SSI finalizadas. Com as entrevistas aos analistas e o mapeamento das atividades através do diagrama de atividades foi possível encontrar os problemas do atual processo que serão descritos na próxima seção. 2.2.2 Problemas Os problemas do processo atual de gerenciamento de requisição de manutenção de software serão listados abaixo: Analistas e solicitantes não seguem metodologia de criação de SSI tanto para solicitações de melhorias como para solicitações de tratamento de incidentes; Não há centralização na demanda de serviços da área de sistemas, com isso é complicado o gerenciamento dos esforços empregados; Coordenador de TPI não tem conhecimento de várias solicitações realizadas; Não existe metodologia de priorização das solicitações;
23 Neste capítulo foi abordado o processo antigo de gerenciamento de requisição de manutenção de software e os problemas nas atividades desse processo. As atividades foram apresentadas num diagrama de atividades da UML (Unified Modeling Language) para facilitar o entendimento. No capítulo seguinte é apresentada a revisão bibliográfica estudada que auxiliou no embasamento da proposta deste trabalho.
24 3 REVISÃO BIBLIOGRÁFICA Neste capítulo serão apresentados os conceitos que serviram de base para resolução dos problemas no processo de requisição de manutenção de software do setor TPI. Primeiramente será descrito o conceito de manutenção de software, seus tipos e o custo atrelado à atividade de manutenção de software. Depois será apresentado conceito de melhoria de processo e finalizando o capítulo será apresentada metodologia ITIL (Information Technology Infrastructure Library) com foco nos processos que serão utilizados no presente trabalho. 3.1 MANUTENÇÃO DE SOFTWARE Manutenção de software é o processo de modificação de um produto de software já entregue ao cliente [SOMMERVILLE, 2007]. As modificações podem ser mudanças simples como corrigir erros de codificação, mudanças mais extensas para correção de erros de projetos ou melhorias significativas para corrigir erros de especificação ou para acomodar novos requisitos. Baseado nessas características podemos definir os tipos de manutenção de software. 3.1.1 Tipos de manutenção de software Para Paduelli (2007) as ações ligadas a atividades de manutenção de software podem ser classificados conforme sua natureza definindo 3 tipos de manutenção:
25 Manutenção corretiva: está relacionada à correção de erros de funcionalidade, pois todo software está sujeito a falhas, seja ela no processo ou no código fonte do programa; Manutenção adaptativa: refere-se à adaptação do software a mudanças que ocorrem no ambiente externo. Por exemplo, a mudança de legislação no país que obriga a alteração no processo de emissão de notas fiscais; Manutenção perfectiva: segundo Paduelli (2007) é a adição de novos recursos, de funcionalidade ao software, sendo normalmente solicitações dos usuários. Além dos tipos de manutenção de software, há também os custos atrelados à atividade de manutenção. 3.1.2 Custo de manutenção de software Não existe um consenso sobre os custos exatos da atividade de manutenção de software, mas segundo Pressman (1995) os custos apontam para mais de 80% dos investimentos com software sendo justificado pela abrangência do significado de manutenção no contexto de software. E segundo Sommerville (2007) é mais oneroso adicionar funcionalidade depois que o sistema está em operação do que a implementação da mesma funcionalidade durante o desenvolvimento. Mas para as empresas de grande porte, os sistemas representam ativos importantes da organização e ela estará disposta a investir de maneira que mantenha a funcionalidade destes sistemas. Portanto é preciso considerar a atividade de manutenção de software como atividade necessária [Paduelli 2007].
26 3.2 MELHORIA DE PROCESSO Bon et al citado por Calvi (2007, p. 26) define um processo como: Um conjunto de atividades lógicas combinadas, a partir de entradas definidas, para atingir um objetivo ou resultado, concluindo em saídas definidas. Processos definem atividades em um nível mais alto de abstração, muitas vezes representando um padrão para toda a organização. Os processos são descritos através de procedimentos e de instruções de trabalho, que contêm mais detalhes e descrevem quem, como e quando executar certas atividades em um processo. Cada processo pode ser dividido em várias seqüências de tarefas. Cada tarefa será executada ou está sob a responsabilidade de um papel bem definido, que pode ser personificado por um ser humano ou executado por uma rotina de software. Nas organizações que possuem processos pode ser necessária a melhora contínua desses processos. Conforme Martins (2006) para atingir a melhoria de processo é preciso utilizar fases distintas e sequenciadas como: Mapear o processo para identificar as atividades e responsabilidades; Analisar o processo para identificar os problemas e buscar as soluções dos problemas; Melhorar ou redefinir o processo através de métodos e técnicas; Implantar o processo. Alguns modelos buscam a melhoria de processos dos serviços de TI como o COBIT (Control Objectives for Information and Related Technology) e o ITIL (Information Technology Infrastructure Library) que serão descritos nas próximas seções. 3.3 COBIT (CONTROL OBJECTIVES FOR INFORMATION AND RELATED TECHNOLOGY) O COBIT é um conjunto de diretrizes baseadas em auditoria para processos, práticas e controles, com intuito de auxiliar gerentes de negócios e profissionais em
27 todos os aspectos de uma empresa de TI. Suas principais características são: orientação aos negócios, orientação aos processos, orientação aos controles e mecanismos de medição [ITGI, 2007]. Nessas características são descritas os tópicos que o gerente de negócios precisa para gerenciar as atividades de TI da organização. O principio básico do COBIT (Figura 3.1) é gerenciar e controlar os recursos de TI por meio de processos estruturados que possibilitam entregar os produtos/serviços conforme o planejamento. Figura 3.1 Princípio básico do COBIT Fonte: Neves, 2007, p. 13. O COBIT é um modelo com foco principal na área de negócios, por isso não contribui de forma significativa para a definição de um processo de gerenciamento de requisição de manutenção de software.
28 Outro modelo, mas com foco de gerenciamento dos serviços de TI e que foi escolhido como referência para o presente trabalho é o ITIL, oferecendo práticas que ajudaram a melhorar e redefinir o processo definido no capítulo anterior. 3.4 ITIL (INFORMATION TECHNOLOGY INFRASTRUCTURE LIBRARY) O ITIL é uma biblioteca de melhores práticas no gerenciamento de serviços de TI, onde o escopo deste modelo é propiciar que as organizações ofereçam serviços de TI de alta qualidade baseado na metodologia de gerenciamento focada nos processos visando à melhoria contínua, envolvendo pessoas, processos e tecnologia conforme Figura 3.2 [MIURA, 2007]. Pessoas Processos Tecnologia Figura 3.2 - Aspectos envolvidos pelo ITIL Fonte: Martins, 2006, p.26 Segundo Calvi (2007, p 28), ITIL não determina cada ação a ser executada no dia-a-dia, visto que uma organização sempre difere da outra, mas, ao invés disso, sugere as melhores práticas que podem ser utilizadas, conforme a necessidade.
29 O ITIL busca mostrar os objetivos, atividades gerais, entradas e saídas dos vários processos que podem ser incorporados às organizações de TI. 3.4.1 Histórico O ITIL foi desenvolvido no final da década de 1980 pela OGC (Office of Government Commerce), centro governamental para sistemas de informações do Governo do Reino Unido para disciplinar e comparar as propostas dos diversos prestadores de serviço de TI, visando garantir um mínimo de padronização de atendimento em termos de processos, terminologia, desempenho, qualidade e custo [MAGALHÃES, PINHEIRO, 2007]. Inicialmente eram 10 livros que tratavam das áreas de Entrega e Suporte a Serviços e mais 30 livros complementares que reestruturados, agora somam 7 livros, sendo 2 sobre o núcleo da biblioteca que abrange as áreas de Entrega e Suporte a Serviços [MARTINS, 2006]. Atualmente é a norma BS-15000, anexo da ISO 9000/2000 tornando-se de fato um padrão para gerenciamento de serviços de TI. 3.4.2 Componentes Os componentes do ITIL são de Entrega e Suporte a Serviços de TI, Gerência de Aplicações, Gerência de Infraestrutura e Perspectiva de Negócio (Figura 3.3), onde cada componente é composto por vários processos. Os dois componentes principais seriam: Entrega de Serviço que preocupa-se com o planejamento e a melhoria da prestação de serviços de TI a longo prazo, e Suporte a Serviços é responsável pela operação e suporte dos serviços de TI no dia-a-dia.
30 Figura 3.3 - Componentes do ITIL Fonte: Martins, 2006, p. 29 O foco do presente trabalho é na área de Suporte a Serviços ilustrado na Figura 3.4, mais precisamente na função de Central de serviços e nos processos de Gerenciamento de Incidente e Problemas descritos nas próximas seções. Figura 3.4 - Os processos de Suporte a Serviços Fonte: Martins, 2006, p. 29
31 3.4.3 Central de serviços A Central de Serviços é a interface entre os usuários com a área de TI. A Central tem como responsabilidade atender os chamados não importando o meio de comunicação utilizado pelos usuários, classificar e encaminhar esses chamados para o processo de gerenciamento adequado [MAGALHÃES, PINHEIRO, 2007]. A maioria das atividades desenvolvidas pela Central de Serviços é de responsabilidade do processo de Gerenciamento de Incidentes e são descritas abaixo: Receber e registrar todos os chamados 1 dos usuários dos serviços de TI; Prover uma avaliação inicial de todos os incidentes comunicados; Realizar o atendimento de primeiro nível dos incidentes comunicados; Encaminhar para o suporte técnico de segundo nível os incidentes não solucionados conforme os níveis de serviços estabelecidos; Monitorar o atendimento e escalar todos os incidentes de acordo com os níveis de serviços estabelecidos; Manter os usuários dos serviços de TI informados sobre o estado atual dos incidentes comunicados e da evolução do atendimento; Produzir informações gerenciais, coletando medidas e calculando indicadores de desempenho [MAGALHÃES, PINHEIRO, 2007]. 1 Chamado: Solicitação originada por usuário
32 3.4.4 Gerenciamento de incidentes Gerenciamento de Incidentes está relacionado ao processamento de solicitações que a Central de Serviços recebeu e não conseguiu resolver seja ela uma dúvida ou uma requisição de serviço. O objetivo do gerenciamento de incidentes é resolver o incidente do modo mais rápido possível, minimizando a adversidade do impacto ocasionado pelo incidente sobre as operações do negócio [Martins, 2006]. As atividades do Gerenciamento de Incidentes são: Identificar e documentar todos os incidentes; Priorizar (determinar urgência) e categorizar (avaliar o risco); Fazer análise inicial do problema e fornecer suporte; Corrigir a falha e restaurar o serviço; Fechar e documentar o serviço Avaliar incidentes e preparar relatórios para melhoria dos serviços [Martins, 2006]. 3.4.5 Gerenciamento de problemas Gerenciamento de Problemas é o processo que estuda as causas dos incidentes, pois vários incidentes podem estar relacionados a um problema. E o objetivo do Gerenciamento de Problemas é transformar problemas em erros conhecidos, diagnosticando a causa raiz do problema, e corrigindo-o garantindo assim que os incidentes relacionados a esse problema não ocorram mais [MAGALHÃES, PINHEIRO, 2007].
33 As atividades do gerenciamento de problemas são descritas abaixo: Controle dos problemas; Controle dos erros conhecidos; Prevenção proativa de problemas; Identificação de tendências; Obtenção de informações para o gerenciamento a partir dos dados do processo de gerenciamento de problema; Revisão dos principais problemas [MAGALHÃES, PINHEIRO, 2007]. 3.5 AVALIAÇÃO DE MATURIDADE Avaliação de maturidade funciona como um guia para a organização, de tal maneira que a empresa possa identificar o nível de maturidade e conformidade dos processos em relação ao que é proposto pela metodologia seguida. O modelo de maturidade do ITIL foi desenvolvido e proposto pela OGC e é baseado num questionário de nove níveis (5 níveis principais e 4 níveis intermediários), e são aferidos aos processos relacionados às melhores práticas reunidas no ITIL. Segundo Magalhães e Pinheiro (p. 594, 2007) os níveis são: Nível 1: Pré-Requisito - Verifica se o nível mínimo de itens obrigatórios está disponível para apoiar as atividades do processo sob avaliação. O Nível 1.5: "Objetivo da Administração" estabelece se existem declarações de política organizacional, objetivos de negócios (ou provas semelhantes de objetivo) que proporcionem tanto uma finalidade quanto uma orientação à transformação ou ao uso dos itens obrigatórios. Nível 2: Capacidade do Processo - Examina as atividades que estão sendo realizadas. As perguntas visam identificar se está sendo realizado um conjunto mínimo de atividades. O Nível 2.5: "Integração Interna" busca verificar se as atividades estão suficientemente integradas para atingir os objetivos do processo sob avaliação.