GRANDE DO SUL
DCEEng – DEPARTAMENTO DE CIÊNCIAS EXATAS E ENGENHARIAS
CENTRAL DE ATENDIMENTO E SISTEMA DE CHAMADOS BASEADO NO FRAMEWORK ITIL
RICARDO PLETSCH KUNTZ
Ijuí Dezembro/201
DCEEng – DEPARTAMENTO DE CIÊNCIAS EXATAS E ENGENHARIAS
CENTRAL DE ATENDIMENTO E SISTEMA DE CHAMADOS BASEADO NO FRAMEWORK ITIL
RICARDO PLETSCH KUNTZ
Trabalho de Conclusão de Curso apresentado ao Curso de Informática - Sistemas de Informação do Departamento de Ciências Exatas e Engenharias (DCEEng), da Universidade Regional do Noroeste do Estado do Rio Grande do Sul (UNIJUÍ), como requisito para a obtenção do título Bacharel em Informática - Sistemas de Informação.
Orientador: Ms. Romário Lopes de Alcântara
Ijuí Dezembro/2011
BASEADO NO FRAMEWORK ITIL
RICARDO PLETSCH KUNTZ
Trabalho de Conclusão de Curso apresentado ao Curso de Informática - Sistemas de Informação do Departamento de Ciências Exatas e Engenharias (DCEEng), da Universidade Regional do Noroeste do Estado do Rio Grande do Sul (UNIJUÍ), como requisito para a obtenção do título Bacharel em Informática - Sistemas de Informação.
Orientador: Prof. Ms. Romário Lopes de Alcântara
BANCA EXAMINADORA
Prof. Ms. Marcos R. M. Cavalheiro
Ijuí Dezembro/2011
Primeiramente, quero agradecer a Deus por me estender a mão durante a conclusão deste trabalho, pois, apesar das dificuldades, me levantou e fez com que não desanimasse. Por ser meu alicerce e porto seguro.
À minha esposa Andressa, pelos incentivos e por não me deixar desanimar. A alegria contagiante me renova e sua dedicação e amparo me dão a certeza de que você me completa.
À minha família, que sempre esteve ao meu lado e nunca mediu esforços param me ajudar, que me colocou no rumo em todas as vezes que me desviei e me deu carinho quando precisei.
À orientação do professor e mestre Romário Lopes de Alcântara pela disponibilidade, ajuda e incentivo.
Aos demais professores e mestres que foram fundamentais no profissional que sou e irei me tornar.
Aos colegas que, mesmo durante o aprendizado foram amigos e, com certeza, são os responsáveis por deixar o ensino mais prazeroso.
“A medida de um homem não está naquilo que alcança, mas naquilo que almeja alcançar.” Kahlil Gibran
SUMÁRIO
Lista de Abreviaturas ... 9 Lista de Figuras ... 11 RESUMO ... 14 ABSTRACT ... 15 1 INTRODUÇÃO ... 16 1.1 Posicionamento ... 16 1.2 Objetivo Geral ... 17 1.3 Organização do Trabalho... 17 1.4 Local da Implantação... 18 1.4.1 Descrição da Empresa ... 18 1.4.2 Estrutura da Área de TI ... 19 1.4.3 Proposta ... 242 ASPECTOS GERAIS DA ITIL ... 25
2.1 Sobre ITIL ... 25
2.1.1 Gestão de Serviços ... 28
2.2 Ciclo de Vida de ITIL ... 28
2.3 Serviço ... 30
2.4 Processo ... 30
2.5 Central de Atendimento ... 31
2.5.1 Atribuições ... 31
2.5.3 Atividades ... 32
2.5.4 Estrutura ... 32
2.5.5 Implementação ... 33
2.6 Foco do Trabalho sobre ITIL... 35
2.6.1 Gerenciamento de Incidentes ... 35
2.6.2 Gerenciamento de Problema ... 41
2.6.3 Gerenciamento de Mudança ... 46
2.7 Ferramentas para Desenvolvimento ... 50
2.7.1 Scriptcase ... 50
2.7.2 Mysql ... 50
2.7.3 FusionCharts ... 51
3 MODELAGEM DO SISTEMA PROPOSTO ... 52
3.1 Domínio do Sistema ... 52
3.2 Descrição dos Objetivos ... 52
3.3 Lista de Requisitos ... 53 3.4 Local do Sistema ... 54 3.5 Processo de Software ... 55 3.5.1 Modelo Evolutivo ... 55 3.5.2 Modelo Cascata ... 55 3.6 Arquitetura do Sistema ... 56 3.7 Cenários ... 56 3.7.1 Cenários Primários ... 56 3.7.2 Cenários Secundários ... 57
3.8 Listagem dos Casos de Uso ... 57
3.9 Projeto Lógico das Tabelas do Sistema ... 58
3.9.1 Nome externo: chamado ... 59
3.9.2 Nome externo: chamado_mudança ... 59
3.9.3 Nome externo: ec_conhecido ... 59
3.9.4 Nome externo: especificacao ... 59
3.9.5 Nome externo: ic_conhecido ... 60
3.9.7 Nome externo: incidente_problema ... 60
3.9.8 Nome externo: matriz_prioritaria ... 60
3.9.9 Nome externo: mudanca ... 61
3.9.10 Nome externo: problema ... 61
3.9.11 Nome externo: setor ... 61
3.9.12 Nome externo: solicitacao ... 62
3.9.13 Nome externo: tipo ... 62
3.9.14 Nome externo: user ... 62
3.9.15 Nome externo: responsavel_especificacao ... 63
3.10 Diagrama de Casos de Uso ... 63
3.10.1 Caso de Uso ... 63
3.11 Diagrama de Classe ... 67
3.12 Diagrama de Estado ... 68
3.12.2 Diagrama de Estado de Mudança... 69
3.13 Relação de Programas a serem desenvolvidos ... 70
3.13.1 Programas de Cadastro: ... 70
3.13.2 Programas de Consultas: ... 70
3.13.3 Programas de Relatórios/ Indicadores: ... 70
3.14 Projetos de Entrada (Cadastros) e Saídas (Relatórios) ... 71
3.14.1 Tela de Login ... 71
3.14.2 Tela de Abertura de Chamado ... 71
3.14.3 Definição de Fluxo (Solicitação ou Incidente) ... 72
3.14.4 Responsáveis pelos Serviços ... 72
3.14.5 Matriz Prioritária ... 73
4 RESULTADOS DA IMPLANTAÇÃO DA CENTRAL DE ATENDIMENTO E SISTEMA DE CHAMADOS ... 74
CONSIDERAÇÕES FINAIS ... 78
LISTA DE ABREVIATURAS
6M’s – Mão de obra, material, meio ambiente, método, máquina e medida AJAX – Asynchronous Javascript and XML
ANS – Acordo de Nível de Serviço BD – Base de dados
BDEC – Banco de Dados de Erros Conhecidos
CCTA – Central Computing and Telecommunications Agency COBOL – Common Business Oriented Language
DB – Data Base
DBA – Data Base Administrator EC – Erros Conhecidos
EFQM – European Foundation for Quality Management HTML – Hypertext Markup Language
HTTP – Hypertext Transfer Protocol
HTTPS – Hypertext Transfer Protocol secure IC – Incidentes Conhecidos
ICT – Information and Communication Technology ISO – International Organization for Standadization IT – Information Technology
ITIL – Information Technology Infrastructure Library JSON – Javascript Object Notation
OGC – Office of Government Commerce PHP – Hypertext Preprocessor
SGBD – Sistemas Gerenciadores de Banco de Bados SIC – Sistema Interno de Comunicação
SLA – Service Level Agreement SQL – Structured Query Language TI – Tecnologia da Informação XML – Extensible Markup Language
11
LISTA DE FIGURAS
Figura 1.1- Vista aérea do parque fabril da empresa Bruning Tecnometal S.A. ... 19
Figura 1.2 – Tela inicial para abertura de chamado. ... 20
Figura 1.3 – Distribuição do chamado por área... 21
Figura 1.4 – Histórico de transferência de chamado. ... 21
Figura 1.5 – Histórico de chamados concluídos. ... 22
Figura 1.6 – Indicador de eficiência da equipe de TI. ... 23
Figura 2.1 – Livros que compõem a biblioteca ITIL (OGC)... 26
Figura 2.2 – Mapa de ITIL (ITIL, 2007). ... 27
Figura 2.3 – Fluxo do Ciclo de vida de ITIL (ITIL, 2007)... 28
Figura 2.4 – Ciclo de Vida de Serviços de TI (QUEIROZ, 2009). ... 29
Figura 2.5 – Processo (MAGALHÃES E PINHEIRO, 2010). ... 30
Figura 2.6 - Central de Serviços Centralizada (ARRUDA, 2010). ... 33
Figura 2.7 – Entradas e Saídas do processo de Gerenciamento de Incidentes (ARRUDA, 2010).35 Figura 2.8 – Ciclo de vida de um incidente (MAGALHÃES E PINHEIRO, 2010). ... 38
Figura 2.9 – Escalonamento de Incidentes (MAGALHÃES E PINHEIRO, 2010). ... 39
Figura 2.10 – Entradas e saídas principais do processo (ARRUDA, 2010). ... 43
Figura 3.1 - Tabela de abertura de chamado. ... 59
Figura 3.2 - Tabela de discriminação dos chamados afetados pela mudança ... 59
Figura 3.3 - Tabela de erros conhecidos. ... 59
Figura 3.4 - Tabela discriminada dos serviços prestados pelo TI. ... 59
Figura 3.5 - Tabela de incidentes conhecidos. ... 60
Figura 3.6 - Tabela de incidentes. ... 60
Figura 3.7 - Tabela de discriminação dos incidentes transformados em problema. ... 60
Figura 3.8 - Tabela do Acordo de Nível de serviço (ANS). ... 60
Figura 3.9 - Tabela de mudanças. ... 61
Figura 3.10 - Tabela de problemas. ... 61
Figura 3.11 - Tabela de setores. ... 61
Figura 3.12 - Tabela de solicitação de serviço. ... 62
Figura 3.13 - Tabela da área de serviços de TI. ... 62
Figura 3.14 - Tabela de usuários (equipe técnica) do sistema. ... 62
Figura 3.15 - Tabela de responsável por área de serviço. ... 63
Figura 3.16 – Diagrama de Caso de Uso do sistema de chamados. ... 63
Figura 3.17 – Diagrama de Classe. ... 67
Figura 3.18 – Diagrama de estado da abertura de chamado. ... 68
Figura 3.19 – Diagrama de estado da Mudança. ... 69
Figura 3.20 – Tela de Login. ... 71
Figura 3.21 – Abertura de Chamados ... 71
Figura 3.22 – Definição do Fluxo do Chamado (Solicitação ou Incidente). ... 72
Figura 3.23 – Responsáveis pelo serviço... 72
Figura 4.1 – Chamados Abertos no Período. ... 74
Figura 4.2 – Chamados encerrados no período (por tipo). ... 75
Figura 4.3 – Nível de atendimento por chamado... 75
Figura 4.4 – Chamados por nível de suporte. ... 76
RESUMO
A área de TI tem uma grande importância para as empresas. Seu papel é no mínimo, estar alinhado com o negócio para fornecer informações que apoiem as decisões da área executiva. Além de gerar e gerenciar a informação, é obrigação da área de TI manter o bom funcionamento dos serviços, evitando possíveis perdas competitivas. Pensando na importância e no impacto que a indisponibilidade de um serviço pode causar a uma empresa, tornaram-se necessários estudos para encontrar as melhores práticas da gestão de serviços de TI. E foi o que a OGC (Office of Government Commerce) fez criando o framework ITIL (Information Technology Infrastructure Library).
Baseado no gerenciamento de incidentes, problemas e mudanças, descrito em ITIL, este trabalho visa implantar uma central de atendimento e um sistema de chamados para a empresa Bruning Tecnometal SA. A central terá a função de centralizar os contatos com usuários e o sistema de chamados é a proposta de sistema para receber e registrar todos os contatos com o TI, desde requisições de serviço, notificação de incidentes, até a alteração de algum sistema.
15
ABSTRACT
The IT has a great importance to business. The IT's role is to be aligned with business to provide information and to support the executive's decisions. In addition to generating and managing information, the IT obligation is to maintain satisfatory service operation, in this way, avoiding losses in competition.
Furthermore, thinking about the importance and the impact that the unavailability of a service can cause to a company, it turns out to be necessary further studies to find better management practices on IT services. That is the reason why the OGC (Office of Government Commerce) created the framework called ITIL.
Moreover, ITIL work is based on incidents management, problems, and changes. Besides that, ITIL's goal is to stablish a service desk system and a call center to Bruning Tecnometal S/A company. The call center's function is to centralize the contacts with its users. On the other hand, the service desk system was created for the purpose of receiving and recording IT's contacts. It englobes service, requests, notification of incidents, and even system changes.
1 INTRODUÇÃO
1.1 Posicionamento
No atual momento, onde o cenário corporativo foca a evolução tecnológica, empresas inovam e, além da tecnologia, visam ao suporte como diferencial competitivo. Devido às constantes mudanças, torna-se necessário estar preparado para agir com rapidez e objetividade perante as falhas e imprevistos. É de consenso que independente do cliente (interno ou externo), a disponibilidade de serviços de TI deve ser prioridade e o atendimento (suporte) devem ser de qualidade.
Com o amadurecimento da consciência corporativa em relação à área de TI, ficou evidente a necessidade de alinhar a TI como negócio da empresa. Com isso, a TI passou de uma simples área de apoio, para uma área diretamente relacionada com a alta gerência, abastecendo os executivos com informações fundamentais para decisões estratégicas e gerenciais. Dessa forma, ficou evidente a necessidade de evoluir a qualidade dos serviços prestados pela área.
Muitas vezes, a ausência de informação sobre a indisponibilidade de algum serviço, somada a dificuldade de encontrar o responsável pela solução do problema causa algumas críticas por parte dos clientes. A reincidência desses problemas pode agravar a insatisfação, quando não muito, uma quebra de confiança por parte do cliente, em relação à equipe de TI.
Com o intuito de contornar esse problema, foram definidas as melhores práticas de ITIL sobre o Gerenciamento de Serviços de TI. A partir de uma metodologia baseada em processos, a ITIL visa à melhoria contínua que afeta desde pessoas até a tecnologia, tendo a redução dos custos e a agilidade dos processos como parceiros estratégicos do negócio.
1.2 Objetivo Geral
O objetivo principal deste trabalho é, a partir de uma pesquisa bibliográfica sobre as melhores práticas reunidas na ITIL, desenvolver um sistema de chamados para suporte a usuários na empresa Bruning Tecnometal SA. Esta pesquisa tem seu foco baseado em ITIL devido a casos de sucesso, onde ficou evidenciado o aumento de produtividade da área de desenvolvimento da empresa.
Um dos focos de ITIL é o Gerenciamento de Serviços de TI. Como referência, podemos usar um Service Desk, que é considerado uma evolução se comparado com o Help Desk. A diferença entre os dois é que, ao contrário do Help Desk, o Service Desk tem um canal centralizado de atendimento ao cliente. Uma das metas do Service Desk é que a grande maioria dos contatos com a área de suporte deve ser solucionada pelos responsáveis do atendimento em 1º nível, isso faz com que os técnicos e especialistas da área dediquem mais do seu tempo para a criação e mudanças. Outra atividade dos responsáveis pelo atendimento em 1º nível é deixar o cliente bem informado sobre a previsão de retorno do serviço, ou sobre a solução do problema, bem como, identificar melhorias, reforçar treinamentos e principalmente, caso não consiga solucionar um chamado, abastecer os técnicos e especialistas com informações sobre o problema.
Baseado nos resultados de outras empresas que implantaram ITIL, estima-se que o atendimento em primeiro nível possa ser responsável por 65% de todos os chamados, porém, como a implantação será exponencial, têm-se a expectativa de alcançar a margem de 50% dos chamados.
1.3 Organização do Trabalho
O capítulo 2 trabalha com o conceito de ITIL (IT Infrastructure Library), uma ferramenta desenvolvida pelo governo britânico com o objetivo de padronizar os serviços prestados pela área de TI dos departamentos do governo. Um dos tópicos será a Central de Serviços (Service Desk), na empresa Bruning será denominada Central de Atendimento, tendo a proposta de suas atribuições, bem como sua implantação e os problemas que estão sendo esperados para a implementação. Também, será apresentado o foco sobre ITIL, ao qual será incorporado na
Central de Atendimento. O Gerenciamento de Incidente, Gerenciamento de Problema e Gerenciamento de Mudanças serão os processos destacados da ITIL.
No capitulo 3 será apresentado a modelagem do sistema proposto. Nele constará o domínio do sistema, a lista de requisitos, o processo de software, a arquitetura do sistema, os casos de uso, dentre outros.
Por fim, o capítulo 4 mostrará os resultados obtidos com a pesquisa e implantação do sistema proposto. A pesquisa (capítulo 2) foi fundamental para a implantação dos processos descritos em ITIL. Já o capítulo 3 tem a importância de gerar a informação e apresentar os resultados, permitindo a conclusão sobre o sucesso do projeto.
1.4 Local da Implantação
1.4.1 Descrição da Empresa
O trabalho será realizado na empresa Bruning Tecnometal S.A. (Figura 1.1) em sua unidade fabril localizada na Rua 25 de Julho, 2305, Bairro Jaciandi, na cidade de Panambi/RS.
A empresa foi fundada em 1º de abril de 1947 pelo Sr. Ernesto Rehn, atuando no ramo metal-mecânico, fornecedora de produtos das linhas automotiva, rodoviária e agrícola, através do beneficiamento de metais utilizando tecnologias de processo nas áreas de estamparia, usinagem, soldagem e tratamentos superficiais.
Figura 1.1- Vista aérea do parque fabril da empresa Bruning Tecnometal S.A. Fonte: Bruning Tecnometal S/A
Abaixo são citadas algumas características do parque fabril da empresa: - Área: 65.000 m² construídos em uma área total de 441.000 m²;
- Número de funcionários: 3.050;
- Beneficiamento de aço: 4.600 ton. / mês;
- Faturamento: em torno de 500 milhões / ano (previsão para 2011);
1.4.2 Estrutura da Área de TI
O departamento de TI da empresa é dividida em três áreas, a área de suporte a hardware e infraestrutura, a área de desenvolvimento e suporte COBOL e a área de desenvolvimento e suporte web (intranet). No topo da estrutura está o gerente de TI que é o responsável pelas decisões estratégicas e administrativas das três áreas.
Com exceção da área de suporte, nas duas áreas de desenvolvimento os programadores são os responsáveis pelo suporte dos sistemas por eles desenvolvidos. Para qualquer dúvida que o usuário tenha ou algum problema identificado, o usuário tem acesso direto ao programador para informar ou questionar. Cientes da necessidade de registrar todos os contatos com usuários, a
área de TI desenvolveu um sistema de chamados, onde o usuário seleciona o sistema e reporta o problema ou dúvida para o programador, por ele definido, conforme figura
Figura 1.2
1.4.2.1 O Sistema de Chamados Atual
O sistema de chamados é a garantia do usuário
Nele, o usuário seleciona o tipo do problema (onde geralmente separamos as áreas), conforme figura 1.3 e especifica o problema (seleciona o sistema ou o dispositivo com problema).
área de TI desenvolveu um sistema de chamados, onde o usuário seleciona o sistema e reporta o problema ou dúvida para o programador, por ele definido, conforme figura
Figura 1.2 – Tela inicial para abertura de chamado.
O Sistema de Chamados Atual
O sistema de chamados é a garantia do usuário de que seu problema vai ser atendido. Nele, o usuário seleciona o tipo do problema (onde geralmente separamos as áreas), conforme figura 1.3 e especifica o problema (seleciona o sistema ou o dispositivo com problema).
área de TI desenvolveu um sistema de chamados, onde o usuário seleciona o sistema e reporta o problema ou dúvida para o programador, por ele definido, conforme figura 1.18.
Tela inicial para abertura de chamado.
que seu problema vai ser atendido. Nele, o usuário seleciona o tipo do problema (onde geralmente separamos as áreas), conforme figura 1.3 e especifica o problema (seleciona o sistema ou o dispositivo com problema).
Como é o usuário que define os responsáveis pelo sistema, habilitamos a possibilidade de transferir os chamados entre a equipe de TI, deixando o usuário devidamente informando sobre a transferência. Existe também, um histórico de transferência (fi
origem do chamado.
Figura 1.4
Figura 1.3 – Distribuição do chamado por área.
Como é o usuário que define os responsáveis pelo sistema, habilitamos a possibilidade de transferir os chamados entre a equipe de TI, deixando o usuário devidamente informando sobre a transferência. Existe também, um histórico de transferência (figura 1.4), onde é possível ver a
Figura 1.4 – Histórico de transferência de chamado
Como é o usuário que define os responsáveis pelo sistema, habilitamos a possibilidade de transferir os chamados entre a equipe de TI, deixando o usuário devidamente informando sobre a gura 1.4), onde é possível ver a
Há ainda, um relatório sobre chamados concluídos (figura 1.5), onde é possível verificar a data de conclusão e a informação passada ao usuár
Figura 1.5 Outra funcionalidade é
média de solicitações diárias, a média de transferências e o tempo médio para a chamado em um determinado período.
um relatório sobre chamados concluídos (figura 1.5), onde é possível verificar a data de conclusão e a informação passada ao usuário sobre a solução do problema/
Figura 1.5 – Histórico de chamados concluídos.
Outra funcionalidade é o relatório sobre a eficiência da área (figura 1.6). Nela é exibida a média de solicitações diárias, a média de transferências e o tempo médio para a
chamado em um determinado período.
um relatório sobre chamados concluídos (figura 1.5), onde é possível verificar a a solução do problema/solicitação.
relatório sobre a eficiência da área (figura 1.6). Nela é exibida a média de solicitações diárias, a média de transferências e o tempo médio para a solução do
Figura 1.6
1.4.2.2 Dificuldades Encontradas
Na atual forma de trabalho, não equipe. Para cada problema identificado exi solução é definitiva ou uma forma de contorno informação se a maioria dos cha
que o indicador de chamados concluídos e o ranking de eficiência (figura 1.6) não são suficientes para avaliar a equipe.
Figura 1.6 – Indicador de eficiência da equipe de TI.
Dificuldades Encontradas
Na atual forma de trabalho, não há uma maneira confiável de avaliar o desempenho da equipe. Para cada problema identificado existe uma solução, porém, não é possível distinguir se a
ou uma forma de contorno para restabelecer o serviço. Também, não
informação se a maioria dos chamados emitidos é de solicitação ou problema. Deixando evidente ador de chamados concluídos e o ranking de eficiência (figura 1.6) não são suficientes
Indicador de eficiência da equipe de TI.
uma maneira confiável de avaliar o desempenho da ste uma solução, porém, não é possível distinguir se a para restabelecer o serviço. Também, não existe a ou problema. Deixando evidente ador de chamados concluídos e o ranking de eficiência (figura 1.6) não são suficientes
1.4.3 Proposta
Com o intuito de melhor atender ao usuário (cliente interno) e aumentar a produtividade da área de desenvolvimento, foi identificada em ITIL uma excelente referência para as melhores práticas nos processos de atendimento. Com isso, pretende-se implantar uma central de serviços, denominada central de atendimento, onde será centralizado o contato preliminar com o cliente.
A ideia é definir os acordos de níveis de serviço e apresentar para a empresa quais serviços serão prestados pela área. Dessa forma, caberá à central fazer o filtro inicial de chamado e o atendimento preliminar ao usuário, o qual será tratado como suporte em primeiro nível.
No caso de a central não conseguir prover o suporte para determinado problema, este será encaminhado à área técnica, ao qual será tratado como suporte em segundo nível. A solução do suporte em segundo nível irá abastecer uma base de conhecimento que servirá como referência para a central em chamados futuros.
Trabalhando dessa forma, permite-se que em um determinado momento (definido pela gerência) seja feita uma análise sobre os chamados, onde será avaliada a sua reincidência e tomadas ações para que a sua solução seja definitiva.
25
2 ASPECTOS GERAIS DA ITIL
2.1 Sobre ITIL
A ITIL foi criada pela CCTA, atualmente denominada como OGC, no final da década de 1980. O OGC é um órgão do governo britânico que tem como finalidade a padronização e melhorias dos processos internos dentro dos departamentos do governo britânico. A criação da biblioteca de ITIL teve como objetivo, a melhoria dos processos específicos de TI. A partir de 1990, ITIL se expandiu para a Europa inteira e acabou recebendo contribuições no seu desenvolvimento de empresas como IBM e Microsoft (ITIL, 2011).
Tendo o foco voltado para a qualidade e na proposição de melhores práticas para o Gerenciamento de Serviços de TI, a ITIL viabiliza a implantação da certificação ISO 9000 e ao modelo europeu (EFQM). Como resultado, foi adotado também, pelos países da América do Norte, tornando-se a referencia principal para esse segmento de TI. Hoje, seu uso é explorado por empresas públicas e privadas em países de todo o mundo, tendo como base uma pesquisa realizada pela Forester Research em empresas com faturamento igual ou superior a US$ 1 bilhão (MAGALÃES E PINHEIRO, 2010):
- 13% em 2004; - 40% em 2006; - 80% em 2008;
Essa evolução na adoção das práticas de ITIL pelas empresas foi motivada, principalmente, pelo ganho dos seguintes aspectos:
- Aumento da disponibilidade dos Serviços de TI;
- Medição do retorno sobre os investimentos em TI.
- Satisfação em relação à qualidade e na relação custo/ benefício dos Serviços de TI; - Provisionamento das entregas e manutenção dos serviços;
- Segurança (desde o sentido estrutural, a disponibilidade de serviços e mudanças).
No início, a ITIL era integrada por 40 livros (por isso chamam de biblioteca). Mas a partir de 2000 ela foi reformulada, conforme figura 2.1 e reduzida para oito livros, sendo denominada como ITIL v2. As práticas defendidas por ITIL eram as seguintes:
• Service Support (Suporte ao Serviço); • Service Delivery (Entrega de Serviço);
• Planning and Implementation (Planejamento e Implementação); • Applications Management (Gerenciamento de Aplicações); • Security Manager (Gerenciamento de Segurança);
• Information and Communication Technology (ICT) Infrastructure Management (Gerenciamento da Infraestrutura de TI e de Comunicações);
• Business Perspective (Perspectiva de Negócio);
• Software Asset Management (Gerenciamento dos Ativos de Software).
Figura 2.1 – Livros que compõem a biblioteca ITIL (OGC)
Posteriormente, em maio de 2007, foi lançada uma atualização sobre a versão 2 de ITIL, denominada de ITIL v3. A comparação entre ITIL v2 e v3 mostra que os principais processos de
ITIL v2 permaneceram na v3, porém, os processos foram revisados e melhorados (CHIARI,2010).
O novo ciclo de vida dos Serviços, proposto em ITIL v3 e conforme figura 2.2, teve como foco o melhor entendimento, organizando os processos de uma forma cíclica. Dessa forma, a versão 2 é substituída por um conjunto de 5 livros:
- Service Strategies (Estratégias de Serviço); - Service Design (Desenho de Serviço); - Service Transition (Transição de Serviço); - Service Operation (Operação de Serviço);
- Continual Service Improvement (Melhoria Contínua de Serviço);
2.1.1 Gestão de Serviços
A gestão de serviços é uma estrutura de gestão que planeja, monitora e controla a qualidade do serviço. Seu objetivo é coordenar recursos específicos, técnicos e organizacionais que agreguem valor ao cliente. Dessa forma é possível obedecer às exigências dos clientes e empresas, otimizar a qualidade dos serviços prestados e reduzir os custos do serviço a longo prazo (MAGALÃES E PINHEIRO, 2010).
2.2 Ciclo de Vida de ITIL
A estrutura dos manuais é baseada no ciclo de vida dos serviços. Coube a Estratégia de serviço ser definida como o eixo de onde gira o ciclo de vida.
Figura 2.3 – Fluxo do Ciclo de vida de ITIL (ITIL, 2007).
Das ações implementadas pelos meios de serviço de Transição, Operação e Desenho, são geradas ações de melhorias que refletem o aprendizado contínuo (melhoria contínua) e ajudam a melhorar os projetos com base nos objetivos estratégicos (ITIL, 2007).
- Análise de requisitos e definição inicial, composto pelos livros de Service Strategy e Service Design. Nele são definidos os requisitos do negócio e planejados os resultados esperados, além da disponibilidade do serviço;
- Migração para o ambiente de produção, composto pelo livro de Service Transition. Durante a implementação de um novo sistema ou alteração de um sistema já existente, tem-se a responsabilidade de testar, acompanhar e validar a implementação.
- Operação e melhoria em produção, composto pelos livros de Service Operation e Continual Service Improvement. É responsável por manter a disponibilidade dos serviços, para alcançar os resultados esperados e identificar alguma oportunidade de melhoria nos serviços, respectivamente.
2.3 Serviço
Segundo o dicionário (AURÉLIO, 2008), o termo serviço pode ser definido como o desempenho de uma função obrigatória ou necessária. Para a área de TI é possível dizer que um serviço é um componente (físico ou virtual) fornecido como suporte para um ou mais processos.
Para facilitar o entendimento, um sistema contábil utiliza uma base PostgreSQL e rede. O banco PostgreSQL e a rede são serviços que atuam como suporte para que o sistema contábil funcione normalmente.
Queiroz (2009) define serviço de TI como “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”.
2.4 Processo
Magalhães e Pinheiro (2010) afirmam em seu livro "Gerenciamento de Serviços de TI na Prática" que processo é uma série de ações, atividades, mudanças, etc., conectadas entre si e realizadas por agentes com o fim de satisfazer um propósito ou alcançar uma meta.
Ainda, segundo os mesmos, os processos são o mais alto nível de definição de atividades de uma organização. Os procedimentos são mais detalhados e descrevem exatamente o que deve ser executado em determinada atividade do processo.
2.5 Central de Atendimento
A central de atendimento será fundamental para a implementação do Gerenciamento dos Serviços de TI e ao contrário do que se pensa, ela não é um processo e sim uma função. Muitos pensam que a central é um ponto de suporte aos usuários, mas mais que isso, a Central de Serviços é a interface principal de operação entre a área de TI e os usuários dos seus serviços. Ela é responsável pelo atendimento preliminar, desde um esclarecimento sobre serviços, solicitação de serviço, até para informar a ocorrência de um erro no serviço (ARRUDA, 2010).
2.5.1 Atribuições
Com a implantação da central de serviços, podemos dividir a área de suporte, da área responsável pela solução dos problemas e desenvolvimento. Com essa mudança, acredita-se que o usuário tenha o benefício de um suporte com agilidade e qualidade, proporcionando também, o aumento de produtividade da área técnica que não terá o seu trabalho interrompido com chamadas diretas dos usuários (somente se a central não conseguir solucionar o problema).
A central de serviços é considerada uma evolução em relação ao help desk devido à unificação do suporte em primeiro nível, ou seja, cabe à central tratar todas as solicitações relacionadas aos serviços prestados pela área de TI. No help desk existiam vários atendentes de diferentes níveis, fazendo com que o usuário do serviço passasse por vários níveis de atendimento sem ter o problema solucionado (MAGALHÃES E PINHEIRO, 2010).
2.5.2 Objetivos
Para Arruda (2010), são objetivos da central:
• Minimizar os contatos dos usuários com a área técnica, concluindo os chamados num primeiro nível de suporte;
• Utilizando a informação como ferramenta (base de erros conhecidos e base de conhecimento), é de responsabilidade da central ,restaurar os serviços o mais breve possível;
• Conhecer o negócio, para saber o impacto causado por cada serviço prestado pela área;
• Manter o usuário abastecido com informações sobre o agendamento das mudanças e sobre o restabelecimento do funcionamento do serviço;
• Acompanhar o incidente durante o seu ciclo de vida e deixar o usuário devidamente informado sobre a solução (provisória ou definitiva).
2.5.3 Atividades
As seguintes atividades são definidas (MAGALHÃES E PINHEIRO, 2010): • Receber e armazenas todos os contatos dos usuários;
• Acompanhar os pedidos e reclamações;
• Gerar uma avaliação inicial de todos os incidentes comunicados; • Realizar o suporte de primeiro nível;
• Encaminhar para a área técnica (segundo nível de suporte) os incidentes não solucionados, obedecendo os níveis de serviços estabelecidos (SLA).
• Monitorar os atendimentos e escalar de acordo com os níveis estabelecidos;
• Informar os usuários sobre o status do incidente e comunicar a evolução do atendimento;
• Identificar a necessidade de treinamento dos usuários; • Gerar informações gerenciais;
• Ajudar na identificação de problemas.
2.5.4 Estrutura
Como a empresa é situada em apenas uma cidade e não possui filial, utilizaremos a estrutura centralizada, onde o objetivo é centralizar todas as solicitações de suporte em um único local. Com a central de serviços centralizada há um ganho na redução de custos e otimização da utilização de recursos (ARRUDA, 2010).
Figura 2.6 - Central de Serviços Centralizada (ARRUDA, 2010).
2.5.5 Implementação
Seguindo as diretrizes de Magalhães e Pinheiro (2010), o projeto de implantação é dividido em cinco etapas:
2.5.5.1 Levantamento das informações
Para que a central de serviços tenha sucesso, é necessário que a mesma tenha uma documentação completa sobre fluxos, scripts e regras de escalonamento para qualquer incidente ou consultas feitas pelos usuários. Muita informação será complementada durante a execução do projeto, mas a organização/criação de uma base inicial de conhecimento é fundamental para que o analista tenha em que se basear e tirar as dúvidas.
O livro de ITIL destaca como fundamental nessa etapa, a definição de categorias de atendimento, prazos de solução e a estrutura para o Acordo de Nível de Serviço (ANS, ou SLA em inglês) (MAGALHÃES E PINHEIRO, 2010).
2.5.5.2 Definição de nível de habilidade necessário para manter o processo
Nesta etapa é estipulado o nível de conhecimento necessário para o atendimento. Como a central será iniciada do princípio, foi optado pela central de serviços básica. À medida que houver
uma evolução na base do conhecimento, paralela à evolução da base de dados do sistema, haverá uma qualificação nos serviços prestados pela central (MAGALHÃES E PINHEIRO, 2010).
2.5.5.3 Definição da forma mais eficaz para atender à demanda
No item 2.5.4 foi definido que a central será implantada de maneira centralizada.
2.5.5.4 Definição dos níveis de serviço
Definiremos os níveis de serviços que serão utilizados para o atendimento, focaremos no equilíbrio entre desempenho e segurança x custo e na quantidade e custo de recurso x desempenho/disponibilidade dos serviços (MAGALHÃES E PINHEIRO, 2010):
2.5.5.5 Gerenciamento do resultado
Estabelecer regras para gerenciamento das informações, transformando-as em relatórios gerenciais. Extrair indicadores de desempenho da equipe técnica e da central de serviços.
2.5.5.6 Problemas Previstos
Foram identificados alguns fatores críticos de sucesso (ARRUDA, 2010):
• Usuários tentarão acesso direto ao técnico responsável pelo serviço antes da implantação da central;
• Convencer a equipe sobre a importância de um atendimento de qualidade; • Investir na capacitação da equipe para renovar as tecnologias empregadas; • Motivação e comprometimento da equipe de atendimento;
• Certificar que toda a equipe de TI participe da definição dos acordos de nível de serviço (ANS).
• Alocar as pessoas com conhecimento e perfil adequado para a execução das diferentes tarefas.
2.6 Foco do Trabalho sobre ITIL
2.6.1 Gerenciamento de Incidentes
Para Magalhães e Pinheiro (2010), o gerenciamento de incidente tem como objetivo assegurar que após a ocorrência de um incidente, o serviço de TI afetado tenha seu funcionamento restaurado o mais breve possível, fazendo com que a indisponibilidade não tenha impactos sobre o negócio. Para que os serviços sejam restabelecidos o mais breve possível, pode ser utilizada uma solução de contorno (workaround), que faz com que o serviço afetado retorne suas funcionalidades, de maneira provisória, reduzindo o impacto do incidente no negócio.
O livro de ITIL (2007) define o incidente como a entrada principal do processo. Essa entrada deriva, não somente dos usuários, mas também de ferramentas de monitoramento (infraestrutura) e equipes de operação que podem identificar alguma instabilidade nos serviços.
Figura 2.7 – Entradas e Saídas do processo de Gerenciamento de Incidentes (ARRUDA, 2010). A central de serviços é o primeiro contato com o usuário e também é responsável por catalogar/registrar a ocorrência, ela ainda acompanha todo o ciclo de vida do incidente. Monitorando o estado e o progresso do incidente, tendo a responsabilidade de manter as áreas usuárias dos serviços informadas sobre a previsão para regularização do serviço. Para falhas ou
demora no atendimento do serviço, cabe à central rever os níveis de prioridade e alocação de recursos para o atendimento a determinado problema.
Para auxiliar a central de atendimento e fazer com que os incidentes sejam atendidos no 1º nível de suporte, é importante dispor de um BDEC (banco de dados de erros conhecidos), onde se encontra um histórico de erros já conhecidos e que podem auxiliar a central na solução do incidente o mais breve possível, evitando o escalonamento para o segundo nível.
2.6.1.1 Objetivos
ARRUDA (2010) lista alguns dos principais objetivos do processo de Gerenciamento de Incidentes:
• Resolver o incidente o mais breve possível, devolvendo a operabilidade do sistema (mesmo que seja provisório) ao usuário, respeitando a ANS;
• Diminuir o impacto causado pelo incidente sobre o negócio; • Manter o usuário informado sobre o estado do incidente/ serviço;
• A partir de um incidente, ter a capacidade de identificar as causas e se este pode tornar a acontecer.
2.6.1.2 Solicitação de Serviço
É o pedido de informação sobre o funcionamento do serviço/sistema ou um pedido de mudança em algum sistema/serviço. Sendo assim, nem todo chamado feito à central de atendimento é incidente (MAGALHÃES E PINHEIRO, 2010).
Algumas solicitações:
• Consulta sobre o funcionamento de algum aplicativo;
• Informação sobre aquisição de algum serviço e ou produto de TI; • Solicitação de adequação da infraestrutura para mudança de layout.
2.6.1.3 Erro Conhecido
Identificado a partir de análises realizadas anteriormente como sendo a causa de um problema. Esses dados já estão armazenados na BDEC e são utilizados para solucionar incidentes que tenham os mesmos sintomas de outros incidentes já registrados previamente como erro conhecido (MAGALHÃES E PINHEIRO, 2010).
A BDEC auxilia para que o incidente seja solucionado no primeiro nível de suporte (central de atendimento). Caso o incidente não tenha registros da BDEC ou não possa ser resolvido no primeiro nível, é encaminhado ao segundo nível de suporte.
2.6.1.4 Processo
Ao pesquisar a causa do incidente, o responsável pelo primeiro nível de suporte pesquisa no BDEC algum caso similar ao incidente atual. Ao identificar, deve-se aplicar a solução definitiva ou de contorno, normalizando o serviço e resolvendo o incidente. Caso não seja possível resolver, deverá encaminhar ao segundo nível de suporte. Dessa forma, o processo de gerenciamento de incidente deverá aumentar gradativamente o índice percentual dos incidentes encerrados no primeiro nível de suporte (MAGALHÃES E PINHEIRO, 2010).
Apesar de diversas atividades a serem realizadas no processo de gerenciamento de incidente, as principais são:
• Consulta ao BDEC, no objetivo de encontrar ocorrências similares que auxiliem na solução do incidente (mesmo que seja provisório) em um primeiro nível de suporte;
• Classificar os incidentes, determinando prioridade a partir de uma análise de urgência x impacto do incidente;
2.6.1.5 Ciclo de Vida
Um incidente pode ter diversos estados durante a sua vida. Dessa forma, pode-se auxiliar a central na previsão de normalização do serviço. A tabela de MAGALHÃES E PINHEIRO (2007) apresenta uma proposta de ciclo de vida.
Estado Descrição
Novo Ao ser registrado, o incidente assume o estado de "NOVO". Aceite
Após uma primeira análise e a classificação em relação à sua prioridade, o incidente passa ao estado de "ACEITO".
Programado
O incidente aceito está "PROGRAMADO" para atendimento, ou seja,
encontra-se na fila de atendimento, esperando a definição de um analista para execução do atendimento
Atribuído O incidente já foi atribuído a um técnico responsável.
Em andamento O trabalho de investigação e diagnóstico da causa do incidente já foi iniciado. Em espera
O trabalho de investigação e diagnóstico da causa do incidente foi interrompido.
Resolvido
A solução permanente ou de contorno foi implementada e o serviço de TI afetado, restabelecido.
Encerrado
A equipe de Central de Serviços contatou o usuário que comunicou o incidente e obteve a confirmação da restauração do serviço de TI. Figura 2.8 – Ciclo de vida de um incidente (MAGALHÃES E PINHEIRO, 2010).
2.6.1.6 Escalonamento
Para Magalhães e Pinheiro (2010), o escalonamento visa à solução de um incidente no menor tempo possível, disponibilizando conhecimento (escalonamento horizontal) e recursos necessários (escalonamento vertical).
No escalonamento horizontal, o incidente é tratado primeiramente pela central de serviços, responsável pelo atendimento em primeiro nível. Tendo como premissa que a solução é desconhecida (não se encontra no BDEC), ou não seja possível determinar a causa do incidente, passa-se para o atendimento em segundo nível e assim sucessivamente, conforme figura.
Figura 2.9 – Escalonamento de Incidentes (MAGALHÃES E PINHEIRO, 2010).
O escalonamento vertical consome um nível maior de suporte, mas também consome dinheiro e recursos, com o objetivo de resolver o incidente o mais breve possível. Também serve para suprir uma falha no processo do escalonamento horizontal (MAGALHÃES E PINHEIRO, 2010).
O monitoramento do progresso dos escalonamentos é fundamental para identificar possíveis erros de processo e para identificar possíveis melhorias no processo.
2.6.1.7 Relatório de Gestão
Kaplan e Norton (1997) escreverem em seu livro que “o que não é medido não é gerenciado”. Seguindo essa linha de raciocínio, por exemplo, ao acompar o processo de gerenciamento de incidentes, será possível gerar relatórios que auxiliem uma análise sobre carga de trabalho prevista e quantidade de itens de configuração sob gerenciamento.
Magalhães e Pinheiro (2010) apresenta uma proposta de estrutura para o relatório de gestão do processo de gerenciamento de incidentes, a qual pode ser reduzida ou ampliada de acordo com a necessidade de cada organização:
• Volume de atendimentos realizados;
• Distribuição dos incidentes por serviço, prioridade, etc.; • Distribuição dos incidentes por área usuária;
• Necessidade de capacitação e atualização da equipe de suporte;
• Percepção de satisfação das áreas usuárias com atendimentos realizados; • Desempenho dos fornecedores de tecnologias empregadas nos serviços de TI; • Informação sobre o acumulo de trabalho (incidentes não atendidos);
• Número de incidentes atendidos, sem a confirmação do usuário;
• Informação sobre atrasos ocorridos na execução do atendimento dos incidentes, detalhando a causa e a solução implementada.
2.6.1.8 Dificuldades Previstas
A implementação dos processos baseados nas melhores práticas reunidas na ITIL depende da mudança proposta e incorporada pela área de TI. Portanto, é necessário focar em alguns itens fundamentais para o sucesso da iniciativa (MAGALHÃES E PINHEIRO, 2010);
• Clareza em relação a necessidades do negócio;
• Alocação de recursos com conhecimento suficiente e perfil adequado para desempenhar tais tarefas;
• Motivação e comprometimento da equipe de suporte; • Definição detalhada dos objetivos e responsabilidades; • Disponibilização de ferramenta que automatize o processo.
2.6.1.9 Avaliação de Performance
ARRUDA (2010) sugere alguns indicadores de performance, para avaliar o processo: • Número total de incidentes (segmentar por área de negócio);
• Tempo médio para reparo;
• Incidentes resolvidos por nível de serviço; • Redução do tempo médio de solução;
• Incidentes resolvidos com a Base de Conhecimento (incidentes conhecidos e erros conhecidos).
2.6.2 Gerenciamento de Problema
Todos os dias, vários chamados são feitos para a área de TI solucionar problemas em sistemas ou sobre o mau funcionamento de hardware e softwares proprietários, o que acaba sobrecarregando a equipe de suporte e por vezes, até gerando gargalo na área. Por isso, é possível que muito dos problemas sejam tratados de forma provisória, fazendo com que o sistema seja restabelecido o mais rápido possível, para evitar a pressão dos usuários (OGC, 2010).
A partir da solução provisória, a área de suporte assume o risco de reincidência, alocando novamente recursos e tempo da equipe de suporte para solução. Como a equipe de suporte quase nunca tem tempo, o incidente acaba sendo “varrido para baixo do tapete”.
Para solucionar esse problema, é usado o processo de Gerenciamento de Incidentes, onde as causas não identificadas (desconsiderando os erros conhecidos) estarão catalogadas, permitindo uma análise e posterior correção, para que o incidente não torne a acontecer. Para facilitar o entendimento, pode-se considerar que um incidente tenha causa e efeito. A causa é o que motiva o erro e o efeito é o sintoma. Quando somente o efeito de um incidente é tratado, denomina-se solução de contorno (responsabilidade do gerenciamento de incidentes) e quando a causa é tratada, denomina-se solução definitiva (ARRUDA. 2010).
Ter o alinhamento entre o Gerenciamento de Problema e Gerenciamento de Mudança é muito importante, pois a partir da descoberta da solução definitiva é feita uma análise dos riscos sobre o serviço, antecedendo a implementação da mudança. A análise dos riscos antes da implementação da solução do problema previne que outros incidentes possam surgir, causando um impacto ao usuário que sofrerá com a indisponibilidade de algum serviço.
2.6.2.1 Objetivo
Foram identificados por Arruda (2010), os objetivos principais do processo de Gerenciamento de Problemas. São eles:
• Reduzir os problemas e incidentes com erros conhecidos de modo que não impacte sobre o negócio;
• Tratar pro ativamente os problemas e incidentes, de forma que não sejam recorrentes;
• Reduzir o número geral de incidentes;
2.6.2.2 Exemplo de Aplicação
De maneira bem detalhada e clara, Magalhães e Pinheiro (2010) exemplificam o Gerenciamento de Problema, baseado em fatos ocorridos em uma empresa de grande porte:
- Existe um problema em um serviço de TI que causa 50 incidentes por semana; - O tempo médio para solução desses incidentes é de 30 minutos;
- Isso quer dizer que:
• A equipe de suporte gasta 25 horas semanais para atender aos incidentes decorrentes de um problema não resolvido;
• 50 vezes por semana há um usuário que é afetado por um dos incidentes;
• Provavelmente, durante a solução do problema o usuário vai tomar café, tendo um gasto adicional de 15 minutos;
• 50 vezes por semana o usuário perde em torno de 45 minutos de produtividade; • 38 horas por semana de falta de produtividade impactam o negócio, devido aos
efeitos de um problema com causa não identificada.
Dessa forma, podemos considerar que a empresa precisa de um funcionário extra para manter a produtividade, supondo que a mesma tenha jornada de trabalho de 40 horas semanais.
2.6.2.3 Processo
A partir da relação entre incidentes, problemas e erros conhecidos, é feita uma análise com o intuito de identificar a “causa raiz” do problema. Para todo o incidente sem solução definitiva é emitido um aviso para a área de gerenciamento de problemas. De acordo com o impacto e
importância do serviço afetado, é criado um novo registro de problema, na tentativa de evitar que o problema seja reincidente (ARRUDA, 2010).
Figura 2.10 – Entradas e saídas principais do processo (ARRUDA, 2010).
Ao contrário do gerenciamento de incidentes, cujo objetivo é restabelecer o serviço da maneira mais rápida possível, o objetivo do gerenciamento de problemas é evitar que incidentes reincidam sobre o negócio.
2.6.2.4 Ciclo de Vida
Um problema poderá ser registrado por qualquer membro da equipe de TI. O problema poderá ser identificado pela central de atendimento devido à reincidência do mesmo, ou pela área especialista (inclui gerência), que avaliou que o incidente pode ter um alto impacto sobre o negócio.
Quando a causa do problema é identificada, altera-se o status para “Resolvido” e é feito o registro do que foi feito para solucionar o mesmo. Se a solução do problema não é atingida, é cancelado o registro do problema.
Após o responsável identificar a solução do problema, é feita uma análise sobre esse item de configuração. Se após análise ficar evidenciado que o problema não foi solucionado, o status é alterado para “Rejeitado” e o processo é direcionado ao início do ciclo de vida. Identificada a solução após a análise, o status do chamado é alterado para “Fechado”. A imagem 4.5 representa o diagrama do ciclo de vida (MAGALHÃES E PINHEIRO, 2010).
Figura 2.11 – Ciclo de vida de um problema (MAGALHÃES E PINHEIRO, 2010).
2.6.2.5 Método para Solução de Problema
Quando um problema é identificado, deve-se primeiramente encontrar a “causa raiz”, para em seguida tratá-lo de tal forma que o mesmo seja eliminado. O livro de Operação de Serviços indica algumas ferramentas da área de gestão da qualidade para identificar a “causa raiz” dos problemas (ITIL, 2007).
2.6.2.5.1 Diagrama de Ishikawa
Essa ferramenta foi criada em 1943 pelo engenheiro químico Kaoru Ishikawa, conforme exemplo da imagem 4.6, também é conhecida como “Diagrama de Causa e Efeito”, “Espinha de Peixe” e “Diagrama 6M”. Ela é utilizada para determinar as causas do problema. Segundo Rigoni
(2009), Ishikawa propôs uma divisão baseada em 6M’s, ou seja, as causas do problema podem ser originadas da mão de obra, material, meio ambiente, método, máquina e medida. Para cada um dos ambientes dos 6M’s é feito um Brainstorming de causas possíveis, até a identificação da “causa raiz” (RIGONI, 2009).
Figura 2.12 – Exemplo (com 5M’s) do diagrama de Ishikawa (RIGONI, 2009).
2.6.2.5.2 Análise de Krepner e Tregoe
Foi desenvolvido na década de 50 por Charles Kepner e Benjamin Tregoe. Da análise compõem-se três processos (RIGONI, 2009):
• Análise do problema (identificação da causa do problema); • Análise da Decisão (escolha de uma solução para o problema);
• Análise de Problema Potencial (planejamento da implantação da solução);
2.6.2.6 Relatório de Gestão
Da mesma forma que ocorre em todos os processos da área de TI, o Gerenciamento de Problemas precisa de um acompanhamento da gerência. Os relatórios servem para a gerência
avaliar a equipe e também para direcionar a atuação da equipe em relação aos impactos e severidade de algum problema, bem como uma nova estrutura na definição dos níveis de suporte.
São indicados alguns itens que auxiliam na gestão (MAGALHÃES E PINHEIRO, 2010): • Quantidade de atendimentos total e segmentado por serviço, impacto e status; • Comparar a demanda com meses anteriores;
• Soluções proativas x reativas;
• Incidentes atendidos por problema solucionado; • Indicador de custo/mês e custo por problema; • Indicador individual da equipe;
• Problemas não atendidos;
• Taxa de conversão (problemas solucionados x problemas gerados).
2.6.2.7 Dificuldade Prevista
O Gerenciamento de Problemas tem uma relação diretamente ligada ao Gerenciamento de Mudanças e ao Gerenciamento de Incidentes. Esse relacionamento é fundamental para o sucesso, mas alguns fatores também são importantes (ARRUDA, 2010 e MAGALHÃES E PINHEIRO, 2010):
• Ter uma equipe treinada e capacitada para solucionar os problemas; • Alimentar sempre que necessário o BDEC;
• Avaliar corretamente o impacto do problema sobre o negócio;
• Garantir que a informação originada dos incidentes seja completa e de qualidade.
2.6.3 Gerenciamento de Mudança
Mudança é o processo de mover-se de um estado definido a outro (MENDES, 2011). Como qualquer coisa da vida, mais cedo ou mais tarde será necessária uma mudança. Para os sistemas de informação e tecnologias então, é necessário ter um fluxo de mudanças que atendam as novas tendências. No gerenciamento de mudanças de ITIL está programado um
tempo considerável, para que as mudanças passem pelos seguintes processos (CLEMENTI, 2006):
• Análise e estimativa sobre o impacto que a mudança pode causar no negócio; • A partir dos problemas identificados, estabelecer mudanças para solucioná-los; • Inovações tecnológicas e ideias que beneficiem o negócio também geram
mudanças.
Tais medidas são necessárias devido ao nível de criticidade da área de TI sobre as operações, originadas da importância da área dentro do negócio. Motivada pela evolução do negócio, cabe a TI acompanhar a tendência, melhorando a capacidade dos serviços, implementando melhorias nos sistemas e atualizando as políticas de segurança.
Segundo uma pesquisa do Instituto Gartner, 80% dos problemas de indisponibilidade dos serviços de TI foram ocasionados devido a falhas de procedimento, ingerência sobre mudanças e sistemas ou atualizações mal testadas, que resultavam em uma sobrecarga nos servidores. O gerenciamento de mudanças proposto por ITIL sugere que antes de trabalhar para solucionar o problema, o mesmo seja analisado e testado, para então ser implementado no ambiente de produção (ARRUDA, 2010).
2.6.3.1 Objetivos
Este processo tem como objetivo controlar todas as mudanças, na tentativa de minimizar os impactos negativos sobe o negócio. Para isso, visa canalizar a aprovação e acompanhamento da mudança, garantindo que a área de TI e os serviços mantenham o alinhamento com os requisitos do negócio.
Para Arruda (2010), podemos separar os objetivos deste processo nos seguintes itens: • Assegurar que os métodos padronizados estão sendo usados para o tratamento
eficiente de todas as mudanças, reduzindo seus riscos e impactos; • Minimizar incidentes relacionados com as mudanças;
• Balanço entre necessidade e impacto;
2.6.3.2 Processo
Ao contrário do que se imagina, este processo não é responsável pela implementação ou execução das mudanças. Cabe ao processo, somente a decisão e o gerenciamento das mudanças, para que a implantação tenha a eficiência e eficácia necessária, sem correr riscos ou traumas por uma implantação mal planejada. A execução e implementação serão de responsabilidade da equipe técnica da área.
É proposta por Magalhães e Pinheiro (2010), uma proposta para tratamento de 3 tipos de mudanças:
• Mudança padrão: Deve ser documentada, mas não apresenta risco para a área de TI. Pode-se exemplificar a atualização de hardware e software na estação de trabalho, a configuração de firewall e alteração no banco de dados.
• Mudança normal: Destinada a projetos que alterem a infraestrutura de TI. Esse tipo de mudança pode ter um impacto sobre os serviços disponíveis ao usuário. Como exemplo, podemos utilizar a atualização da versão de algum sistema.
• Mudança emergencial: É uma mudança já prevista, mas devido à severidade e impacto, necessita ser implementada em caráter de urgência. Um exemplo é alguma alteração da legislação, onde a não implantação pode acarretar em multa.
2.6.3.3 Benefício Proposto
A vantagem mais evidente sobre o Gerenciamento de Mudanças é a facilidade de fazer mudanças de maneira organizada, minimizando os impactos negativos sobre o negócio e evitando que incidentes sejam originados da mesma.
Os principais benefícios do Gerenciamento de Mudanças são (ARRUDA, 2010): • Melhor alinhamento dos serviços de TI com o negócio;
• Aumento da visibilidade dentro da mudança. Têm-se um controle maior sobre a execução;
• Redução de impacto negativo da mudança; • Melhor avaliação do custo da mudança
• Habilidade para absorver um volume maior de mudanças.
2.6.3.4 Relatório de Gestão
Para avaliar o gerenciamento de mudanças, devem ser colocados a disposição alguns relatórios que transpareçam as atividades desempenhadas pela área. Magalhães e Pinheiro (2010) indicam uma análise sobre o monitoramento do progresso das mudanças, auditorias de atendimento e um planejamento das atividades futuras. E ainda propõem uma estrutura para o relatório, que pode ser customizada de acordo com a necessidade de cada negócio, tendo os seguintes itens:
• Volume de mudanças realizadas;
• Distribuição das mudanças por área usuária; • Informação sobre o crescimento da demanda;
• Identificação da satisfação dos usuários com as mudanças;
• Informação sobre a quantidade de mudanças implementadas, separadas por tipo de mudanças (padrão, normal e emergencial);
• Mudanças pendentes para implementação;
• Quantidade de mudanças solicitadas e consideradas inviáveis.
2.6.3.5 Dificuldades Previstas
Apesar dos benefícios evidentes, também existem problemas que precisam ser enfrentados. A burocracia necessária, mesmo em mudanças simples, aliada a falta de treinamento da equipe e a falta de autoridade do responsável pelo processo podem afetar a credibilidade e incentivar o uso incorreto dos serviços, onde é mais fácil “burlar” o sistema, do que aguardar uma alteração no mesmo (MAGALHÃES E PINHEIRO, 2010).
Dentre outros problemas, Arruda (2010) citou: • Falta de informação para análise de risco;
• Falta de ferramenta integrada aos demais processos.
• Falta de comprometimento da equipe. Se não houver o entendimento dos benefícios do processo, pode ocorrer um boicote da área por achar muito burocrático.
• Priorização de todas as mudanças. Para toda a mudança deve haver uma análise de impacto sobre o negócio, para que sejam definidas as prioridades.
2.7 Ferramentas para Desenvolvimento
2.7.1 Scriptcase
Para o desenvolvimento do sistema, será utilizada uma ferramenta case chamada Scriptcase. Essa ferramenta visa auxiliar o desenvolvimento e maximizar a produtividade da equipe de desenvolvimento. O fabricante define o Scriptcase como um ambiente de desenvolvimento de aplicações WEB (consultas, relatórios, formulários e menus), baseado em banco de dados. A facilidade de manuseio, rapidez na criação de aplicações e inúmeros recursos de programação são características diferenciais do Scriptcase.
O funcionamento do Scriptcase está condicionado a um servidor web e pode ser acessado via internet/ intranet, sendo a portabilidade outro diferencial. O único requisito para utilização da ferramenta é o conhecimento básico de SQL, mas quanto mais conhecimento em SQL, PHP e Javascript, mais pode-se explorar a ferramenta.
Como resultado do desenvolvimento, o Scriptcase gera os programas fontes em PHP, Javascript, HTML e AJAX. Os fontes gerados são completamente independentes da ferramenta, permitindo com que sejam copiados para qualquer servidor WEB. Por ser gratuito, o PHP pode ser utilizado nos ambientes Windows e Linux. (http://www.scriptcase.com.br)
2.7.2 Mysql
O MySQL será o sistema de gerenciamento de banco de dados. Atualmente o MySQL está na versão 5.5 e é mantido pela Oracle. Ele é um banco de dados relacional e de distribuição gratuita, sendo uma boa opção em relação ao custo/ benefício. (http://www.mysql.com)
2.7.3 FusionCharts
A ferramenta para exibir gráficos indicadores é a FusionCharts. Essa ferramenta está na sua terceira versão e tem uma versão light gratuita. A partir de dados formatados em XML ou JSON, a ferramenta monta os gráficos e os exibe utilizando javascript e Flash. (http://www.fusioncharts.com/free)
3 MODELAGEM DO SISTEMA PROPOSTO
3.1 Domínio do Sistema
O sistema de chamados tem como foco, a partir de uma metodologia de centralização de suporte, documentar todos os contatos feitos pelos usuários e auxiliar a central no atendimento em primeiro nível de suporte. Sua implantação será sustentada nas melhores práticas de ITIL, com ênfase no gerenciamento de problemas, gerenciamento de incidentes e no gerenciamento de mudanças.
3.2 Descrição dos Objetivos
O sistema de chamados visa documentar as requisições e notificações de problemas por parte dos usuários. A partir de uma intranet local e, munido do seu crachá, o funcionário pode acessar o sistema utilizando qualquer computador da empresa e informar algum problema nos serviços de TI, ou requisitar algum serviço.
Caso o chamado seja uma solicitação de serviço, a central avalia a necessidade de encaminhar para aprovação do gerente, havendo a possibilidade do gerente aprovar ou não a solicitação. A central também pode recusar alguma solicitação, quando a mesma não atende as regras de negócio. A solicitação pode ser atendida pela central ou pela equipe técnica.
Outra possibilidade é a notificação de um incidente. O usuário descreve o problema e a central verifica se já existe alguma solução de contorno, onde se consegue devolver a operabilidade do serviço de forma rápida. Também, pode-se pressupor que uma restrição do hardware/ software seja a origem do incidente. Dessa forma, a central pode acessar a base de
erros conhecidos e verificar se existe uma forma para retornar a operabilidade do serviço que foi atingido.
Prevendo a incapacidade de solucionar tal incidente, a central pode encaminhar o chamado para a área técnica (2º nível de atendimento). O técnico verifica o chamado e avalia se aceita ou recusa (normalmente, quando outro técnico é responsável pelo sistema). Avaliando os acordos de nível de serviço e impacto sobre o negócio, cabe ao técnico avaliar se vai dar uma solução de contorno (disponibilizando o serviço novamente, mas sem solucionar o incidente), ou se transforma o incidente em problema e soluciona definitivamente o problema (podendo referenciar outros incidentes com a mesma causa).
Após a solução do chamado (seja solução de contorno ou definitiva), é enviado um aviso ao usuário afetado, informando sobre a regularização do serviço. Também cabe aos supervisores da área avaliar os chamados e identificar melhorias e soluções para incidentes frequentes e sem solução definitiva (encerrados como solução de contorno). Desta forma, emite-se uma solicitação de mudança.
Na solicitação de mudança é levado em consideração o impacto que a mudança pode ter sobre o negócio. Nas mudanças de alto impacto, são realizadas algumas reuniões de análise crítica, onde é avaliada a forma como a mudança será implantada e se ela irá atender a necessidade. Também é avaliada a necessidade de apoio externo de especialistas. Com isso, são feitas reuniões para levantamentos de requisitos e aprovação do projeto/orçamento. Para mudanças mais simples, onde o impacto sobre o negócio é baixo. O especialista avalia a mudança e apresenta ao responsável, que aprova ou sugere mudanças para sua implantação.
O sistema tem como objetivo registrar as mudanças, avaliar a capacidade da equipe técnica e principalmente, o foco na melhoria contínua em seus serviços. Para haver harmonia entre os objetivos, cabe aos supervisores avaliarem as estatísticas e relatórios gerenciais. Muitas melhorias podem ser identificadas a partir da análise dos relatórios do sistema, cabe aos responsáveis aproveitá-los da melhor forma possível.
3.3 Lista de Requisitos
2- Definição da central de atendimento 3- Cadastro detalhado dos serviços prestados 4- Abertura do chamado
5- Central define fluxo (solicitação, incidente) 6- Alimentar base de Erros Conhecidos 7- Alimentar base de Incidentes conhecidos 8- Central define atendimento em 2º nível
9- Técnico altera status do chamado de incidente para problema 10- Encerra chamado e envia feedback para usuário
11- Emissão de solicitação de mudança
12- Supervisor aprova projeto e prazo de mudança 13- Relação de mudanças
14- Incidentes/Problemas atendidos na mudança 15- Relação de incidentes emitidos
16- Relação de incidentes por área
17- Relação de incidentes solucionados em 1º nível e 2º nível 18- Relação de problemas
19- Relação de mudança
20- Relação do impacto causado nos incidentes/problemas 21- Relação de solicitações/incidentes/problemas
3.4 Local do Sistema
O sistema será implantado na empresa Bruning Tecnometal SA, situado na rua 25 de Julho, Bairro Jaciandi, Panambi, RS.
O responsável pelo sistema será o senhor Leandro Castoldi Lopez, tendo como contato telefônico nº: 55-3376-9000, ramal:9406 e e-mail [email protected], nos turnos manhã e tarde de segunda-feira à sexta-feira.
