OTRS UFPA

i

UNIVERSIDADE FEDERAL DO PARÁ INSTITUTO DE TECNOLOGIA FACULDADE DE ENGENHARIA DA COMPUTAÇÃO

Harry Freitas da Cruz

Implantação de um IT Service Desk com c om a Ferramenta Livre OTRS alinhado aos Processos de Incident e Problem Management do framework ITIL: Exemplo de Aplicação na Eletronorte

Trabalho de Conclusão de Curso apresentado para obtenção do grau de Engenheiro em Engenharia da Computação, do Instituto de Tecnologia, da Faculdade de Engenharia da Computação.

ii


Este trabalho foi julgado em / / adequado para a obtenção do grau de Engenheiro da Computação, e aprovado na sua forma final pela banca examinadora que atribuiu o conceito _______________.

___________________________________________ Prof. MSc. Rafael Chaves (Orientador) Faculdade de Engenharia de Computação Universidade Federal do Pará ___________________________________________ Fernando Wilson Conceição (Co-orientador) Centrais Elétricas do Norte do Brasil ___________________________________________ Prof. Msc. Alex de Jesus Zissou (Membro) Faculdade de Sistemas de Informação Universidade Federal do Pará ____________________________________________ Prof. Dr. Gervásio Protásio dos Santos Cavalcante Diretor da Faculdade de Engenharia da Computação da Universidade Federal do Pará

ii


Este trabalho foi julgado em / / adequado para a obtenção do grau de Engenheiro da Computação, e aprovado na sua forma final pela banca examinadora que atribuiu o conceito _______________.

___________________________________________ Prof. MSc. Rafael Chaves (Orientador) Faculdade de Engenharia de Computação Universidade Federal do Pará ___________________________________________ Fernando Wilson Conceição (Co-orientador) Centrais Elétricas do Norte do Brasil ___________________________________________ Prof. Msc. Alex de Jesus Zissou (Membro) Faculdade de Sistemas de Informação Universidade Federal do Pará ____________________________________________ Prof. Dr. Gervásio Protásio dos Santos Cavalcante Diretor da Faculdade de Engenharia da Computação da Universidade Federal do Pará

iii


Banca Examinadora

Prof. MSc. Rafael Chaves

Fernando Wilson Conceição

Prof. Msc. Alex de Jesus Zissou

iv

“A primeira regra de qualquer tecnologia utilizada nos negócios é que a automação aplicada a uma operação eficiente aumentará a eficiência. A segunda é que a automação aplicada a uma operação ineficiente aumentará a ineficiência.” William Henry Gates III, 1955 Fundador da Microsoft

v

AGRADECIMENTOS Em primeiro lugar é necessário agradecer a minha família, pai João, mãe Neusa e irmã Talitha, cujo apoio em todos os sentidos, financeiro, emocional, psicológico e espiritual, sempre presente e constante, foi decisivo para tudo que fiz, faço e farei em minha vida. Tudo isto é para e por vocês! Agradeço também a todos da Eletronorte, especialmente ao Fernando, co-orientador do trabalho, Glauco, Ivaldo e Fátima, que depositaram em mim um voto de confiança. Ao Prof. Rafael, pela atenção dispensada e por todas as ótimas sugestões que enriqueceram o trabalho. A toda sociedade brasileira, cujos impostos sobre o incansável trabalho possibilitaram a mim e a tantos outros o acesso ao ensino superior, privilégio de poucos neste rico país dilacerado por desigualdades. A Sergey Brin e Larry Page, cuja fantástica ferramenta possibilitou ao autor acesso ao estado da arte das informações relativas ao tema do trabalho. And last but not least , gostaria de agradecer a todos os amigos da Exodus e da ECOMP: Ítalo, Olavo, Thiago, Hevertton, Éder, Fábio, Oscar, Bruno e Natasha. Vocês foram/são parte importante destes anos de vida, fora e dentro da Academia.

vi

LISTA DE ILUSTRAÇÕES E TABELAS Figura 3.1. Diagrama quebra-cabeça – Arquitetura do ITIL. Fonte: OGC (2005) ...... 19 Figura 3.2. Arquitetura do Service Support . Fonte: http://imasters.com.br/ ............... 21 Figura 4.1. Tela de Login do cliente.......................................................................... 27 Figura 4.2. Interface dos agentes do OTRS ............................................................. 28 Figura 4.3. FAQ do cliente........................................................................................ 29 Figura 5.1. Estrutura do Suporte. Adaptação de OGC (2005) ................................... 37 Figura 5.2. Tela de Estatísticas do OTRS ................................................................. 38 Figura 5.3. Front-end do Service Desk ELN ............................................................. 44 Figura 5.4. Topologia do Help Desk ......................................................................... 45 Figura 6.1. Criação de novo Ticket ........................................................................... 52 Figura 6.2. Encaminhamento de ticket a outra unidade ............................................ 53 Figura 6.3. Usuário cria ticket ................................................................................... 54 Figura 6.4. Tela do Cliente ....................................................................................... 54 Figura 6.5. Tempo para escalação do Ticket ........................................................... 55 Figura 6.6. Ticket escalado...................................................................................... 55 Figura 6.7. Tela de Busca de Tickets ....................................................................... 56 Figura 6.8. Tela de Resultados da Busca ................................................................. 57 Figura 6.9. Criação de uma Nova Fila ...................................................................... 58 Figura 6.10. Tela de Busca de Tickets com Escalação ............................................. 59 Figura 6.11. Criação de uma Nova Fila .................................................................... 60 Figura 6.12. Tela de novo chamado com tipo de ticket ............................................. 60 Figura 6.13. Identificando o serviço afetado com o OTRS ........................................ 61 Figura 6.14. Tela de Configurações do OTRS .......................................................... 62

vii

Tabela 5.2. Serviços da Infra-estrutura ..................................................................... 32 Tabela 5.3. Processos no Lacen .............................................................................. 33 Tabela 5.4. Serviços Prestados no TIMI ................................................................... 35 Tabela 6.1. UC1. Solicitar Serviço ............................................................................ 51 Tabela 6.2. UC1. Ticket -padrão................................................................................ 52 Tabela 6.3. UC3. Criar ticket pelo usuário, Escalação .............................................. 53 Tabela 6.4. UC 4. Busca Textual Completa .............................................................. 56 Tabela 6.5. UC 5. Escalação de Novas Filas ............................................................ 57 Tabela 6.6. UC 6. Listar Tickets Escalados .............................................................. 58 Tabela 6.7. UC 7. Diferenciar entre Incidentes, Problemas, Erros Conhecidos e Workarounds e estabelecer ligações entre eles ................................................................... 59 Tabela 6.8. UC 8. Indicar o Serviço Afetado pelo Incidente ...................................... 61 Tabela 6.9. Aderência do OTRS ao ITIL ................................................................... 62 Tabela 6.10. Análise Custo-Benefício ....................................................................... 67

Gráfico 5.1. Áreas-chave para Implementação do ITIL ............................................... 7 Gráfico 5.2. Relatório gráfico dos atendimentos por fila do OTRS ............................ 39 Gráfico 5.3. Relatório gráfico dos atendimentos por fila com Excel .......................... 40 Gráfico 6.1. Avaliação dos Critérios ITIL ................................................................... 63

viii

LISTA DE ABREVIATURAS E SIGLAS CI

Configuration Item

CMBD

Configuration Management Database

COBIT

Control Objectives for Information and related Technology

ELN

Eletronorte

ERP

Enterprise Resource Planning

FAQ

Frequently Asked Questions

HTML

Hyper Text Markup Language

IT

Information Technology

ITIL

Information Technology Infrastructure Library

ITSM

Information Technology Service Management

Lacen

Laboratório Central da Eletronorte

LDAP

Lightweight Directory Access Protocol

OGC

Office of Government Commerce

OTRS

Open Ticket Request System

RFC

Request For Change

SPOC

Single Point of Contact

TI

Tecnologia de Informação

ix

SUMÁRIO 1.

INTRODUÇÃO ................................................................................... 1

1.1.

MOTIVAÇÃO...................................................................................... 1

1.2.

OBJETIVOS ....................................................................................... 3

1.3.

METODOLOGIA................................................................................. 4

1.4.

LIMITAÇÃO DE ESCOPO .................................................................. 6

1.5.

ORGANIZAÇÃO DO TRABALHO ...................................................... 7

2.

IT SERVICE DESK ............................................................................ 9

2.1.

O QUE É UM SERVICE DESK ? ......................................................... 9

2.1.1.

CALL CENTER ............................................................................. 9

2.1.2.

HELP DESK..................................................................................9

2.1.3.

SERVICE DESK ........................................................................... 9

2.1.4.

DIFERENÇA ENTRE SERVICE DESK E HELP DESK ............... 10

2.2.

O PROBLEMA DO SUPORTE ......................................................... 10

2.3.

FUNÇÕES DO SERVICE DESK ...................................................... 11

2.4.

IMPORTÂNCIA DO SERVICE DESK ............................................... 12

2.5.

EVOLUÇÃO DO SUPORTE TÉCNICO AO IT HELP DESK ............. 13

2.5.1.

O COMEÇO ................................................................................ 13

2.5.2.

INFORMATION CENTERS ......................................................... 13

2.5.3.

O MOVIMENTO DA QUALIDADE ............................................... 14

2.5.4.

HELP DESKS PROFISSIONAIS ................................................. 14

3.

VISÃO GERAL SOBRE O ITSM E ITIL ........................................... 16

3.1.

ITSM? .............................................................................................. 16

3.1.1.

SERVIÇO.................................................................................... 16

3.1.2.

GERENCIAMENTO DE SERVIÇOS ........................................... 16

x

3.2.2.

AS VERSÕES DO ITIL ............................................................... 17

3.3.

OBJETIVOS DO ITIL ........................................................................ 18

3.4.

ARQUITETURA DO ITIL .................................................................. 18

3.5.

SERVICE SUPPORT ....................................................................... 20

3.5.1.

INCIDENT MANAGEMENT ......................................................... 21

3.5.2.

PROBLEM MANAGEMENT ........................................................ 23

4.

O TROUBLE TICKET SYSTEM OTRS ............................................ 25

4.1.

O QUE É UM TICKET SYSTEM?..................................................... 25

4.2.

CICLO DE VIDA DE UMA REQUISIÇÃO (TICKET ) ......................... 26

4.3.

CARACTERÍSTICAS GERAIS DO OTRS ........................................ 27

4.4.

CARACTERÍSTICAS TÉCNICAS DO OTRS .................................... 29

4.4.1.

LINGUAGEM DE PROGRAMAÇÃO ........................................... 29

4.4.2.

SISTEMA OPERACIONAL E BANCO DE DADOS ..................... 30

4.4.3.

ARQUITETURA .......................................................................... 30

5.

SUPORTE NA ELETRONORTE ...................................................... 31

5.1.

A EMPRESA .................................................................................... 31

5.1.1.

PARQUE TECNOLÓGICO .......................................................... 31

5.1.2.

ESTRUTURA ORGANIZACIONAL ............................................. 32

5.1.3.

STATUS QUO ............................................................................. 33

5.2.

ATIVIDADES REALIZADAS ............................................................. 34

5.2.1.

ELABORAÇÃO DO CATÁLOGO DE SERVIÇOS ....................... 34

5.2.2.

DEFINIÇÃO DA ESTRUTURA DE SUPORTE ............................ 36

5.2.3.

CRIAÇÃO DE RELATÓRIOS GERENCIAIS ............................... 38

5.2.4.

INSTALAÇÃO DA FERRAMENTA OTRS ................................... 40

5.2.5.

DEFINIÇÃO DOS ESTADOS DAS SOLICITAÇÕES................... 42 INTEGRAÇÃO DO SERVICE DESK À INTRANET

xi

6.1.

CONDIÇÕES ................................................................................... 46

6.2.

CRITÉRIOS DE AVALIAÇÃO ........................................................... 46

6.2.1.

INCIDENT MANAGEMENT ......................................................... 47

6.2.2.

PROBLEM MANAGEMENT ........................................................ 49

6.2.3.

CASOS DE USO......................................................................... 51

6.3.

ADERÊNCIA DO OTRS AO ITIL ...................................................... 62

6.4.

LIMITAÇÕES ................................................................................... 63

6.5.

BENEFÍCIOS ESPERADOS............................................................. 64

6.6.

ECONOMIA DE RECURSOS FINANCEIROS .................................. 66

7.

CONCLUSÃO .................................................................................. 68

7.1.

TRABALHOS FUTUROS ................................................................. 69

7.1.1.

MAIS ALINHAMENTO COM O ITIL ............................................ 69

7.1.2.

APLICAÇÃO EM PEQUENAS EMPRESAS ................................ 69

7.1.3.

UTILIZAÇÃO DE TÉCNICAS INTELIGENTES (IA) ..................... 69

8.

REFERÊNCIAS................................................................................ 71

APÊNDICES ................................................................................................... 74 APÊNDICE I .................................................................................................... 75 APÊNDICE II ................................................................................................... 77 APÊNDICE III .................................................................................................. 94 ANEXO I ...................................................................................................99

xii

RESUMO A gestão da Tecnologia de Informação (TI) nas organizações de forma a torná-la um diferencial competitivo para o negócio chama-se Governança de TI . A proposta deste trabalho é apresentar o processo de customização e implantação de um IT Service Desk na Eletronorte, empresa de grande porte do setor elétrico nacional, pautado pelas boas práticas para governança de TI do Information Technology Infrastructure Library (ITIL) no que se refere a Information Technology Service Management (ITSM), especialmente os processos de Incident e Problem Management . Embora existam no mercado outras opções de software que tratam desta problemática, a solução empregada para as operações do referido Service Desk será a ferramenta livre OTRS, a qual será customizada tanto para a Empresa de forma a refletir sua realidade e aumentar a aderência em relação aos processos do ITIL mencionados. Uma análise crítica da sua compatibilidade com o ITIL será também apresentada. Serão mostrados ainda os benefícios esperados no âmbito da gestão de TI que a adoção do OTRS e do ITIL poderá trazer à empresa, além de estatísticas e dados pertinentes ao escopo.

Palavras Chave: Governança de TI, Gerenciamento de Serviços, Open Ticket Request System, Information Technology Infrastructure Library.

xiii

ABSTRACT Managing Information Technology (IT) within enterprises so that it becomes a business competitive advantage is called IT Governance. This work intends to present the customization and deployment process of an IT Service Desk, which abides by the Information Technology Infrastructure Library (ITIL) best practices for IT governance regarding Information Technology Service Management (ITSM), especially those referring to the Incident and Problem Management processes, in Eletronorte, a large company operating in the Brazilian electric sector. Although in the marketplace there exist other choices addressing this set of problems, the solution to be applied in supporting the aforesaid Service Desk’s operations will be the free software OTRS (Open Ticket Request System), which will be tuned to match the Enterprise’s reality and improve its compliance relating to the mentioned ITIL processes. A critical analysis regarding its conformity to ITIL will also be presented. Prospective benefits related to IT management that the implementation of OTRS and ITIL might bring to the business, in addition to stats and data pertaining the scope, will be addressed.

Key Words: IT Governance, Service Management, Open Ticket Request System, Information Technology Infrastructure Library.

Introdução

1

1. INTRODUÇÃO 1.1. MOTIVAÇÃO Na atual era da Informação, a Tecnologia de informação desponta como fator decisivo para o sucesso de diversos tipos de empreendimentos, desde as chamadas pequenas e médias empresas até organizações de grande porte. Isto se deve ao fato de que a introdução de recursos de TI possibilita a automatização de processos, fluxo melhorado e mais rápido de informações, comunicação organizacional mais eficiente, além de prover a gerência com informações coerentes que servirão de base para a tomada de decisão. Dentro deste contexto, é importante que a infra-estrutura que sustenta os serviços de TI dentro da empresa, quer sejam eles voltados à atividade organizacional-fim, quer sejam voltados a atividades de suporte a esse fim, possibilite a maior taxa de retorno possível à empresa, no sentido de oferecer um serviço que seja confiável, rápido e eficiente, considerando os riscos envolvidos. Porém, conforme aponta Cartlidge (2007), gerentes de negócio e de TI precisam tratar de uma série de questões-chave relacionadas a esses objetivos, quais sejam: •

Planejamento estratégico de TI e do negócio;

•

Integrar e alinhar a TI os objetivos do negócio;

•

Implementar a melhoria continua;

•

Medir a eficácia e a eficiência da organização com respeito à TI;

•

Otimizar custos e o Valor Total de Propriedade (Total Cost of Ownership 1);

•

Atingir e demonstrar o Retorno sobre Investimento (Return on Investment );

•

Demonstrar o valor da TI para o negócio;

•

Desenvolver parcerias e relacionamentos tanto de negócio quanto de TI;

•

Aumentar o sucesso na entrega de projetos;

•

Terceirização (Outsourcing ), insourcing e smart sourcing 2;

•

Utilizar a TI para obter vantagem competitiva;

2

Introdução

•

Entregar os serviços de TI exigidos e justificados pelo negócio (ou seja, o que é necessário, quando necessário e a um custo previamente acordado);

•

Gerenciar as constantes mudanças de TI e de negócio;

•

Demonstrar Governança de TI apropriada.

Este último elemento, a Governança de TI (IT Governance ), termo relativamente novo no âmbito da tecnologia, vem exatamente ao encontro destes anseios empresarias. Governos, empresas e demais entidades desenvolveram diferentes, mas em muitos casos complementares, abordagens que tratam desta questão. Como exemplos, têm-se COBIT (Control Objectives for Information Technology ), a norma ISO/IEC 20000 e o ITIL (Information Technology Infrastructure Library ). O sumário executivo do COBIT oferece talvez a melhor definição do que seria o objetivo da governança de TI: “[A Governança de IT] integra e institucionaliza boas práticas para assegurar que a TI do empreendimento ofereça suporte aos objetivos de negócio. Possibilita à empresa aproveitar ao máximo suas informações, maximizando benefícios, capitalizando oportunidades, e ganhando vantagem competitiva” (ISACA, 2005, p. 5)

De tal definição, percebe-se que a governança de TI ocupa-se, prioritariamente, de agregar valor ao papel que desempenha a TI no contexto empresarial, possibilitando ao negócio extrair-lhe o máximo valor, ao mesmo tempo em que trata os riscos envolvidos, que são intrínsecos a qualquer atividade empresarial. Conforme salienta Spafford (2003), de maneira geral, as empresas podem abordar o problema da governança de forma ad hoc 3 e criar seus próprios frameworks 4 , ou podem adotar padrões (como os já citados) que foram desenvolvidos e aperfeiçoados através da experiência combinada de centenas de organizações e pessoas. Ao adotar um framework padrão para governança de TI, as empresas podem obter uma série de benefícios, especialmente no que se refere à economia de tempo (que seria necessário para elaborar um modelo de gestão de TI próprio), e ao acúmulo de expertise de diversos grupos e empresas de forma estruturada. No âmbito deste trabalho, o framework de escolha, o qual servirá como base para

Introdução

3

Tesouro britânico que regula os processos de licitações, o qual reuniu as melhores práticas na gestão de TI adotadas pelas maiores companhias daquele país, criando um conjunto de recomendações para qualquer empresa que deseje gerenciar com qualidade seus serviços. O conceito de “serviço” está relacionado a qualquer processo através do qual algum tipo de valor é gerado para o cliente (solicitante do serviço), que o ajudará a atingir seus fins. No caso específico da TI, o funcionário de uma empresa (cliente interno5), ao solicitar a liberação de sua conta para acesso à rede corporativa, está, efetivamente, requisitando a prestação de um serviço, a fim de que possa passar a produzir valor par a empresa. Este trabalho está inserido, portanto, no contexto do Gerenciamento de Serviços de TI – ITSM (Information Technology Service Management ), conjunto de iniciativas que visam a garantir que o máximo valor seja entregue aos clientes que solicitam os serviços com o mínimo de custos para a empresa prestadora, o que significa, conseqüentemente, aumentar o nível de satisfação dos clientes e aumentar os lucros da organização. Especificamente, os processos do ITIL que serão objeto de estudo são o Incident Management e o Problem Management . O chamado Service Desk constitui a interface entre o cliente (interno ou externo) que solicita tais serviços e os agentes encarregados de executá-los. É o assim chamado Single Point of Contact (SPOC), unidade coesa, de tal forma projetada, que a estrutura necessária para efetivar os serviços é transparente ao usuário, ao qual, efetivamente, maiores informações sobre o modus operandi do processo são irrelevantes. Como exemplo de aplicação, será mostrado como a ferramenta OTRS está alinhada com o ITIL no que diz respeito a Incident e Problem Management e as perspectivas de impacto que a utilização de tais abordagens poderá propiciar à Eletronorte com respeito à ao seu status quo 6 no âmbito do Gerenciamento de Serviços de TI.

1.2. OBJETIVOS Considerando-se a necessidade de gerenciar os serviços de TI com eficiência e as boas práticas recomendadas pelo ITIL, objetiva-se implantar no âmbito de uma empresa de grande porte do setor elétrico nacional, a Eletronorte, um IT Service Desk , customizado para a Empresa e que esteja adaptado aos padrões de ITSM do ITIL para Incident e Problem Management . A fim de estimar quantitativamente o grau de aderência do referido IT Service

4

Introdução

Desk às boas práticas do ITIL, serão utilizados diferentes critérios de avaliação, além de casos de uso ilustrando a aplicação de tais critérios.

De forma específica, objetiva-se: I. Mapear os serviços de TI prestados no ambiente do exemplo de aplicação, a Eletronorte, sua estrutura de funcionamento e dependências, além de caracterizar o seu parque tecnológico. II. Definir o grau de aderência da ferramenta OTRS às boas práticas do framework ITIL, explicitando pontos em que alterações sejam necessárias ou que simplesmente não sejam contemplados pela ferramenta. III. Implementar um IT Service Desk na Eletronorte, baseado na ferramenta OTRS, customizado para a Empresa, segundo os padrões do ITIL para Incident e Problem Management ; IV. Identificar os impactos esperados para a situação atual da empresa no que diz respeito ao Gerenciamento de Serviços a partir da introdução do IT Service Desk .

1.3. METODOLOGIA Para atingir os objetivos propostos pelo trabalho, será feito extenso uso da literatura já publicada sobre o ITIL e seus critérios de avaliação para ferramentas que visam a suportá-lo. Além disso, será necessário acumular conhecimento sobre servidores Windows 2003, ambiente no qual a ferramenta será instalada em razão de ser essa a tecnologia adotada no âmbito da empresa que será o exemplo de aplicação, a Eletronorte. Como a ferramenta em questão, o OTRS, é Web, para a sua customização serão utilizadas tecnologias de desenvolvimento para a internet, como ASP.NET, Javascript, XHTML e CSS. Dada a natureza do trabalho, que envolve processos organizacionais, significativa parte do esforço estará direcionada ao levantamento, identificação e análise das necessidades de diferentes stakeholders 7 da empresa, atividades essas ligadas à área de Engenharia de Requisitos. Diversas técnicas para o levantamento de requisitos estão disponíveis, e cada uma possui suas vantagens e desvantagens, sendo normalmente melhor adequadas a

5

Introdução

determinados domínios de aplicação. Como exemplo, existem as técnicas de grupo, prototipação, direcionadas a modelo (model-driven ), cognitivas e contextuais. No escopo deste trabalho, serão adotadas as técnicas tradicionais, que de acordo com Nuseibeh (2000), compreendem o uso de questionários e pesquisas, entrevistas, e análise da documentação existente, diagramas organizacionais, modelos de processos e padrões, manuais de usuário ou outros manuais de sistemas. A Tabela 1.1 abaixo apresenta de maneira mais detalhada como se pretende atingir os objetivos previamente apresentados do trabalho: Tabela 1.1. Metodologia do Trabalho

Objetivo

Método/Atividade Entrevistas com colaboradores da Empresa (funcionários, gerentes, gestores de rede, etc.)

I

Análise de sistemas existentes (como SIGLacen, R3 e SGestor 8) Consulta de documentação existente sobre o parque tecnológico da Eletronorte. Elaborar documento com a estrutura de suporte presente na empresa, identificando os processos existentes, pessoas e recursos envolvidos.

II

Consulta à literatura existente sobre ITIL e seus parâmetros de avaliação. Elaborar checklist de funcionalidades que as ferramentas devem atender para serem ditas compatíveis com os critérios do ITIL. Definir casos de uso e mostrar que eles podem (ou não) ser realizados através do OTRS. Definição para cada aspecto do ITIL, o percentual de atendimento do OTRS. Estabelecimento de possíveis alterações que aumentariam o grau de compatibilidade do OTRS com o ITIL. Instalação do OTRS em ambiente de testes na empresa.

III

Transporte para o OTRS da estrutura de suporte previamente obtida em I, estipulando os serviços prestados, estados de solicitações, etc. Implementação na ferramenta algumas das alterações propostas em II. Realização de treinamento para a equipe de suporte que utilizará o sistema. Geração de Instruções Técnicas9 pertinentes à operação e instalação do sistema.

IV

Identificação de pontos possíveis de melhoria no Gerenciamento de Serviços de TI da Empresa que podem ser contemplados pela utilização do IT Service Desk . Estabelecimento de relações entre os pontos anteriormente identificados e os benefícios esperados pela introdução do IT Service Desk .

Introdução

6

1.4. LIMITAÇÃO DE ESCOPO Antes de iniciar o processo de implementação, foi aplicado um checklist elaborado em Minnesota (2008), o qual indica se a organização detém os requisitos necessários para implantar com sucesso o ITIL e seus processos, levando o implementador a refletir se determinadas ações ou tarefas já foram completadas. Minnesota (2008) apresenta questões-chave nas seguintes áreas: 1. Apoio da organização 2. Avaliação do status quo (baseline assessment ) 3. Escopo de Implementação 4. Estratégia de Treinamento 5. Estratégia de Implementação 6. Estratégia de Certificação 7. Comunicação 8. Recursos 9. Relatórios 10. Medição e métricas 11. Garantia do sucesso atual A utilização do checklist proposto em Minnesota (2008) ilustra as limitações intrínsecas ao processo descrito neste trabalho, no sentido de que ele não possui pretensões de se estabelecer como uma ação de implementação efetiva do ITIL, que é um processo demorado e que requer investimentos e comprometimento integral da organização. O Gráfico 1.1 abaixo mostra o grau em que as áreas-chave de implementação do ITIL estão sendo atendidas em escala percentual. A análise do gráfico mostra que, embora haja limitações, a implantação do ITIL torna-se viável, pelo menos em parte, em razão de haver comprometimento do setor no qual ele será implantado, de ter sido executada antes uma avaliação dos processos até então vigentes e de o processo como um todo estar sendo comunicado ao restante da

7

Introdução

associados. Para efeito de ilustração, o curso ITIL v3 Foundation, primeiro nível de certificação, conforme referência em Consulting (2008) custa R$ 2.650,00 e a prova de certificação é da ordem de R$ 300,00, de acordo com EXIN (2008). No Capítulo 6, além da avaliação de aderência do OTRS ao ITIL serão mostrados os benefícios esperados que a Empresa poderá obter, mesmo com a implementação nãointegral do ITIL e demais restrições.

Gráfico 1.1. Áreas-chave para Implementação do ITIL. Fonte: Autor

1.5. ORGANIZAÇÃO DO TRABALHO Este trabalho foi organizado em oito capítulos, estando os iniciais voltados à fundamentação teórica necessária e os posteriores às atividades efetivamente desenvolvidas. O Capítulo 1 mostra a motivação que deu origem ao trabalho, os objetivos e a metodologia aplicada e a fundamentação teórica preliminar necessária. No Capítulo 2 explica-se o que é um IT Service Desk , suas funções, importância e evolução.

Introdução

8

No Capítulo 4, tem-se uma visão geral sobre a ferramenta OTRS, especialmente no que diz respeito aos seus recursos e à tecnologia utilizada. No Capítulo 5 a estrutura de suporte à TI na Eletronorte é mostrada, no que diz respeito à sua organização em entidades hierárquicas e processos. Será feita também uma avaliação do status quo da Empresa na área de Gerenciamento de Serviços de TI, além de serem mostrados também os resultados do processo de levantamento e análise das informações necessárias para a customização da ferramenta OTRS e demais atividades realizadas. O Capítulo 6 procura mostrar quantitativamente como a ferramenta OTRS customizada para a Eletronorte está alinhada com o framework ITIL no que concerne à Incident e Problem Management , pontos em que alterações/configurações se fizeram necessárias e limitações da ferramenta, além de casos de uso ilustrando a aplicação. Os benefícios esperados para o Gerenciamento de Serviços de TI com a introdução do IT Service Desk serão apresentados neste capítulo. No Capítulo 7, a conclusão e perspectivas futuras são apresentadas, ao lado de dados estatísticos com respeito ao cenário de ITSM no Brasil. Enfim, no Capítulo 8, serão apresentadas as referências sobre as quais o trabalho se baseou.

IT Service Desk

9

2. IT SERVICE DESK Este capítulo explica o que é um IT Service Desk , a problemática envolvida neste contexto, sua importância, funções e evolução.

2.1. O QUE É UM SERVICE DESK ? A fim de prestar suporte a seus clientes, tanto os internos quanto externos, muitas organizações implementaram um ponto central de contato para tratar questões relacionadas a clientes e usuários, função essa conhecida sob diversos nomes: •

Call Center

•

Help Desk

•

Service Desk

Cada um dos termos citados será mais bem esclarecido nas seções seguintes:

2.1.1. Call Center Neste modelo, a ênfase é dada ao gerenciamento de grandes volumes de ligações, geralmente associadas à venda de produtos/serviços que atingem grande público, como por exemplo, serviços bancários, seguros, assinaturas de revistas, telemarketing , etc.

2.1.2. Help Desk Termo freqüentemente utilizado como sinônimo para o Service Desk , é necessário também esclarecer o papel do chamado Help Desk . Prioritariamente utilizado como sinônimo para serviços de suporte ou ajuda a usuários de software ou hardware , ele não é utilizado exclusivamente no âmbito da TI, mas em diversos setores de prestação de serviços. Ele possui no sentido literal uma função puramente relacionada à ajuda e serve como ponto de contato para os clientes.

2.1.3. Service Desk Termo fundamental no contexto do trabalho, de acordo com Härtl (2007), um Service Desk garante a disponibilidade da TI para a organização. Ele é a única interface de contato para o usuário (Single Point of Contact ) e garante que ele possa continuar executando suas atividades normais, ou seja, viabiliza ao solicitante que ele permaneça criando valor para a

IT Service Desk

10

Ele coordena as diferentes unidades de suporte e assume tarefas de outros processos do ITIL, como Incident Management , Change Management , Configuration Management . No contexto deste trabalho, o Service Desk será utilizado em conjunto com os processos de Gestão de Problemas e Incidentes. No Capítulo 3, aspectos relevantes sobre o ITIL serão abordados. O Service Desk não é um processo, mas uma função, ele realiza, portanto, uma tarefa. Ele documenta, entre outros, as requisições de clientes (Trouble Tickets ) e inspeciona o seu processamento. No contexto do trabalho, como os serviços em questão dizem efetivamente respeito aos que serão executados no âmbito da TI, o termo IT Service Desk é também empregado. No Capítulo 3, o ITIL e seus processos serão abordados de forma mais abrangente, possibilitando uma visão geral de cada um deles.

2.1.4. Diferença entre Service Desk e Help Desk Freqüentemente a diferença entre ambos não é facilmente estabelecida. Isto se deve ao fato de que na prática os campos de atividades de ambas as estruturas se sobrepõem fortemente e, além disso, não raro um Service Desk é puramente concebido como um Help Desk e da mesma forma um assim chamado Help Desk tão somente coordena em si serviços do âmbito de um Service Desk . Porém, o framework ITIL para Service Desk foi estabelecido como padrão de facto , quando da utilização de um Help Desk no âmbito do ITSM. No escopo deste trabalho, os termos Help Desk e Service Desk serão utilizados como sinônimos, em razão de no uso corrente da língua ambos serem freqüentemente utilizados com valor semântico equivalente.

2.2. O PROBLEMA DO SUPORTE Prover serviços de TI com qualidade, e da mesma forma, prestar suporte a tais serviços, tem sido um fator que tem preocupado as empresas, exatamente em razão dos custos associados. Conforme é dado a conhecer em OGC (2005), muitos departamentos de suporte das organizações estão sob constante pressão para melhorar os serviços e diminuir os custos, em razão de clientes que querem resultados cada vez mais rápidos e com mais qualidade e

IT Service Desk

11

Eles tendem, porém, a trabalhar de forma reativa, como uma coleção dispersa de grupos, gastando vasta quantidade de tempo “apagando incêndios”. A situação atual em muitas empresas inclui: •

Ausência de mecanismo estruturado de suporte ao cliente;

•

Confiança baixa do cliente quanto aos serviços

•

Sistema defasado de suporte ao cliente;

•

Mau-gerenciamento dos recursos de suporte;

•

Contínuo “apagar de incêndios” (firefighting );

•

Mesmos problemas sendo resolvidos continuamente sem que a real causa seja identificada;

•

Freqüentemente movidos por interrupções;

•

Dependência demasiada em pessoas-chave;

•

Falta de foco;

•

Mudanças não-coordenadas e não registradas acontecem;

•

Incapacidade de lidar como mudanças no negócio;

•

Pessoal/recursos necessários não estão claros;

•

Baixa qualidade nas respostas ao cliente e no tempo de resposta;

•

Informações gerenciais indisponíveis (decisões baseadas em “eu acho” ao invés de “eu sei”)

Para conciliar estes interesses conflitantes, em que, de um lado, estão clientes querendo melhores serviços e, do outro, negócios almejando lucros mais expressivos, é necessário desenvolver métodos estruturados de trabalho, que propugnem pela definição de processos e estejam apoiados em boas práticas da indústria.

2.3. FUNÇÕES DO SERVICE DESK Conforme já esclarecido, o Service Desk desempenha papel chave na organização, tanto do ponto de vista do cliente, já que a este representa um SPOC, como do ponto de vista dos outros processos ITIL, que consomem informação gerada pelo Service Desk . Ele

IT Service Desk

•

•

•

•

•

•

12

Registrar e rastrear incidentes e reclamações; Manter os usuários informações sobre o status e progresso de suas solicitações; Fazer avaliação inicial das requisições, tentando resolvê-las ou encaminhálas a alguém que possa, baseado nos níveis de serviço acordados; Gerenciar o ciclo de vida da requisição, incluindo o fechamento e verificação; Comunicar aos clientes mudanças planejadas e de curto-prazo dos níveis de serviço acordados. Coordenar as outras unidades de suporte, como a de suporte do 2º nível ou grupos de suporte de terceiros;

•

Oferecer informações gerenciais e recomendações de melhoria;

•

Identificar um problema;

•

Destacar necessidades de educação e treinamento;

•

Fechar ticket e confirmar com o cliente;

•

Contribuir para a identificação de um problema.

2.4. IMPORTÂNCIA DO SERVICE DESK De acordo com OGC (2005), estrategicamente, o Service Desk é a função mais importante da organização. Para muitos, o Service Desk é a sua única janela para o nível de serviço e profissionalismo pela organização como um todo ou pelo departamento. A seguir, serão apontados os benefícios operacionais e de negócio advindos da adoção de um Service Desk , tal como propostos pelo ITIL em OGC (2005). •

•

Melhoria do serviço, percepção e satisfação do cliente; Acesso melhorado através de um ponto único de contato, comunicação, e informação;

•

Melhor qualidade e rotatividade de requisições de clientes;

•

Comunicação melhorada e trabalho em grupo facilitado;

IT Service Desk

•

•

•

13

Controle e infra-estrutura mais bem gerenciados; Utilização melhorada de recursos de TI e aumento da produtividade de pessoal; Informações gerenciais mais coerentes e significativas para apoio à decisão

2.5. EVOLUÇÃO DO SUPORTE TÉCNICO AO IT HELP DESK Outro aspecto relevante para o melhor entendimento do trabalho, é o processo de evolução do suporte organizacional à TI, descrito em Härtl (2007), o qual será mostrado a seguir.

2.5.1. O começo Nos anos 70, as empresas faziam muito pouco para o suporte de seus usuários com relação às tecnologias que ofereciam. Suporte era tido mais como um mal necessário, que atrapalhava o processo de produção de outros produtos. Isto se deveu ao fato de que as pessoas que se ocupavam das requisições de suporte eram as mesmas pessoas responsáveis pelo processo produtivo, de forma que tais atividades as desviavam das suas funções previamente estabelecidas. Eles respondiam freqüentemente as mesmas requisições, as quais eram para si triviais ou nada tinham a ver com seu campo de atividade, de forma que, não raro, geravam-se ao cliente respostas não-amigáveis (ou de má-vontade).

2.5.2. Information Centers Pouco mais tarde, como o crescimento do uso e das tecnologias de computador, o e não-reconhecimento por parte das empresas da necessidade de um suporte técnico organizado, o custo de suporte aumentou: desenvolvedores perdiam prazos, já que eram sobrecarregados com requisições de suporte, e não atendiam as suas tarefas originais. Por causa da então existente falta de documentação das requisições, soluções idênticas eram procuradas diversas vezes ou simplesmente esquecidas, sem falar da impossibilidade de que diferentes agentes pudessem trocar entre si informações sobre como um dado problema foi resolvido. Como através desse fato criaram-se sérios danos financeiros, as organizações passaram enfim a compreender a necessidade do suporte. Elas compreenderam que técnicos altamente qualificados deveriam ser empregados em projetos,

IT Service Desk

14

começaram a introduzir os chamados Information Centers para fornecer suporte aos seus próprios funcionários. No mesmo período, muitas empresas (dentre as quais IBM, a qual cunhou o termo Help Desk ) passaram a filtrar as requisições dos clientes e, de acordo com o caso, estas encaminhar ao respectivo setor ou pessoa responsável.

2.5.3. O Movimento da Qualidade Nos anos 80, as organizações, por diversos motivos, precisaram intensificar seu foco no suporte. Isto foi por um lado causado pela explosão das ferramentas para PC (Personal Computer ), pela consciência da qualidade e os a partir daí criados critérios de qualidade, como por exemplo, o nível de reclamações, problemas e satisfação dos usuários (ou fatores semelhantes); por outro, foi causado pela necessidade de redução dos custos totais do processo produtivo. Este processo de percepção da qualidade como fator estratégico para o contexto do negócio é conhecido em inglês como quality movement (movimento da qualidade).

2.5.4. Help Desks Profissionais Nos anos 90 soma-se o rápido desenvolvimento da Internet, o qual trouxe consigo uma nova explosão dos usuários de tecnologia computacional, a qual até hoje como as tecnologias de sistemas computacionais portáveis e integrados que a todo o momento mudam. Em face do continuamente crescente número de usuários de computador e dos pontos anteriormente citados, as empresas foram obrigadas a profissionalizar seu suporte e se tornaram mais conscientes da sua importância. Diante desse cenário, começou o desenvolvimento dos departamentos de suporte (Support Departments ) rudimentares para os Help Desks profissionais, os quais ampliaram sua própria área de responsabilidade (a de puramente responder a solicitações) ao coordenar o treinamento para novos produtos, executar instalações de hardware e software , distribuir software eletronicamente, criar relatórios, executar observações no status do sistema, cuidar da sua própria qualidade de serviço e muito mais. Os Service Desks , que a partir deste momento podem ser utilizados com o mesmo significado de Help Desks , surgem num papel proativo, visando a antecipar possíveis problemas, eliminando-os ou minimizando seus efeitos. Atualmente todas as grandes empresas e organizações possuem algum tipo de Help

IT Service Desk

15

condição de “mal necessário” dá lugar à busca de qualidade e excelência. A premiação para o Help Desk com o suporte mais amigável ao usuário torna esta tendência ainda mais clara, conforme mostra Institute (2008).

Visão Geral sobre o ITSM e ITIL

16

3. VISÃO GERAL SOBRE O ITSM E ITIL Este capítulo tem a intenção de apresentar o framework ITIL ao leitor, esclarecendo de que o mesmo trata, o contexto no qual está inserido, sua evolução e histórico.

3.1. ITSM? A fim de melhor compreender o que é Information Technology Service Management é preciso antes de tudo melhor entender o que são serviços e como o gerenciamento de serviços pode ajudar os prestadores a prover e administrar tais serviços.

3.1.1. Serviço De acordo com Cartlidge (2007), um serviço é definido como: “[Um serviço] é meio de levar valor aos clientes facilitando os resultados que eles desejam atingir sem a propriedade de custos e riscos específicos.” (CARTLIDGE, 2007, p. 7)

Um exemplo simples de um resultado facilitado através de um serviço de TI poderia a equipe de vendas poder passar mais tempo interagindo com os clientes tendo sido possibilitado por um serviço remoto que garante acesso seguro aos sistemas de venda corporativos através de um laptop . Os resultados que os clientes desejam atingir são a razão pela qual eles adquirem ou usam o serviço. O valor do serviço, por sua vez, está diretamente relacionado a quão bem ele facilita tais resultados.

3.1.2. Gerenciamento de Serviços O Service Management é o que permite um prestador compreender melhor os serviços que oferece, e assegurar que os serviços realmente facilitem aos clientes os resultados que desejam atingir, compreender o valor de seus serviços aos clientes e compreender e gerenciar os todos os custos e riscos associados com tais serviços. Ainda conforme Cartlidge (2007), o Gerenciamento de Serviços é, de forma sintética: “[Gerenciamento de serviços] é um conjunto de competências organizacionais especializadas para prover valor aos clientes sob a forma de serviços.”


17

As entradas para o Gerenciamento de Serviços são os recursos e competências que representam os ativos do prestador. As saídas são os serviços que fornecem valor aos clientes. Adotar boas práticas pode ajudar o prestador a criar um sistema eficiente de gerenciamento de serviços. Boas práticas podem ser originadas de muitas fontes, incluindo frameworks públicos (tais como ITIL, COBIT, CMMI), normas (como ISO/IEC 20000 e ISO 9000) e conhecimento proprietário de pessoas e organizações, como o MOF (Microsoft Operations Framework ) e o IBM Tivoli Service Management . Tal como anteriormente explicitado, o framework escolhido é o ITIL, o qual será mais profundamente abordado nas seções seguintes.

3.2. HISTÓRIA DO ITIL Antes de abordar os processos e boas práticas do ITIL no que diz respeito ao ITSM, é necessário esclarecer de onde veio o ITIL e as diferentes versões atualmente no mercado.

3.2.1. As Origens A Information Technology Infrastructure Library (ITIL) é uma biblioteca de boas práticas (do inglês best practices ) desenvolvida no final dos anos 80 pela CCTA (Central Computer and Telecommunications Agency ) e atualmente sob custódia da OGC (Office of Government Commerce ) da Inglaterra. O elemento que motivou o desenvolvimento foi a necessidade de uso eficiente e financeiramente responsável dos recursos de TI no governo britânico e no setor privado. De forma prática, o ITIL é um conjunto de livros que busca promover a gestão com foco no cliente e na qualidade dos serviços de tecnologia da informação (TI). É válido registrar também que o ITIL foi a base para a norma BS 15000, que se tornou um anexo da norma ISO/IEC 20000, que versa sobre gerenciamento de TI.

3.2.2. As versões do ITIL De acordo com Central (2008), a primeira versão do ITIL era originalmente chamada de GITIM, Government Information Technology Infrastructure Management . Embora diferente do ITIL atual, era conceitualmente muito similar e estava centrada no suporte e na entrega de serviços.


18

OGC, a Microsoft utilizou o ITIL como base para desenvolver sua iniciativa proprietária para Service Management , o Microsoft Operations Framework (MOF). A versão 2 do ITIL foi publicada em 2001 e os livros de Suporte de Serviços e o de Entrega de Serviços foram adaptados para volumes mais concisos e utilizáveis. Nos anos seguintes, se tornou o framework de boas práticas mais usado mundialmente para Service Management . Em maio de 2007, o ITIL v3 foi liberado ao público, priorizando uma abordagem voltada ao ciclo de vida dos serviços, com maior ênfase na integração da TI com o negócio.

3.3. OBJETIVOS DO ITIL O ITIL endereça estruturas de processos para a gestão de uma organização de TI apresentando um conjunto abrangente de processos e procedimentos gerenciais organizados em disciplinas com os quais uma organização pode fazer sua gestão tática e operacional em vista de alcançar o alinhamento estratégico com os negócios. Assim, fundamentalmente, objetivo do ITIL é possibilitar um melhor uso dos recursos de TI, incluindo: •

•

•

Aumento da satisfação dos usuários e clientes com serviços de TI; Disponibilidade de serviço melhorada, levando diretamente a aumentos nos lucros e receitas do negócio; Economia de recursos financeiros com diminuição de retrabalho e tempo desperdiçado, utilização e gerenciamento de recursos otimizados;

•

Diminuir o tempo para a introdução de novos produtos e serviços;

•

Melhora na tomada de decisões e risco otimizado.

3.4. ARQUITETURA DO ITIL As informações que seguem dizem respeito ao ITIL v2, versão na qual o trabalho está baseado. É importante esclarecer que atualmente o ITIL encontra-se na versão 3, que oferece uma nova abordagem à questão do ITSM, tratando do ciclo de vida de um serviço. Para maiores informações, pode-se consultar http://www.itil.org/ e Cartlidge (2007).


19

os quais são efetivamente volumes da biblioteca ITIL, que se sobrepõem uns aos outros, os quais foram identificados como fatores-chave para o Gerenciamento de Serviços com foco na qualidade, quais sejam: •

A perspectiva de negócio (The Business Perspective );

•

Gerenciamento de aplicações (Managing Applications );

•

Entrega de Serviços (Service Delivery )

•

Suporte a Serviços (Service Support )

•

Gerenciamento de infra-estrutura (Manage the Infrastructure )

Esta abordagem deu origem ao chamado diagrama quebra-cabeça , que pode ser observado na Figura 3.1.

Figura 3.1. Diagrama quebra-cabeça – Arquitetura do ITIL. Fonte: OGC (2005)

A Figura 3.1 ilustra bem o fato de que as diferentes perspectivas e processos abordados pelo ITIL para o Service Management não são unidades autônomas, são, ao contrário, elementos que interagem profundamente, tal como num quebra-cabeça (ou placas tectônicas). Algumas peças se encaixam perfeitamente, algumas se sobrepõem ou não encaixam. Em alto-nível não há linha de demarcação estrita. Porém, se considerarmos a analogia das placas tectônicas deslizando uma sob a outra, se unindo e se separando, então haverá pontos de instabilidade ou fricção causados pela natureza imprecisa das


20

ocorrem. É impossível impedir que problemas ocorram (assim como terremotos), mas é possível desenvolver mecanismos para lidar com eles.

3.5. SERVICE SUPPORT Para os fins deste trabalho, é de interesse o volume que se refere ao Suporte a Serviços, no qual estão descritos os processos de Incident e Problem Management , os quais se encontram em destaque na Figura 3.2. O volume em questão é o ITIL Service Support Band , OGC (2005). Ele trata de como assegurar que o cliente tenha acesso aos serviços apropriados para suportar as funções do negócio. Ele descreve como os usuários e clientes devem ter acesso aos serviços respectivamente oferecidos que servem de suporte a suas atividades. Além disso, ele trata também de que forma tal suporte deve ser oferecido. Questões discutidas em OGC (2005) incluem: •

Service Desk

•

Incident Management (Gerenciamento de Incidentes);

•

Problem Management (Gerenciamento de Problemas);

•

Configuration Management (Gerenciamento de Configuração);

•

Change Management (Gerenciamento de Mudança);

•

Release Management (Gerenciamento de Releases)

Ressalta-se que embora tratados pelo ITIL em suas publicações como elementos independentes somente para fins didáticos, na prática, o Service Desk (função ) assimila e/ou dá suporte às atividades previstas para os outros processos de Service Support do ITIL, conforme ilustra a Figura 3.2:


21

Figura 3.2. Arquitetura do Service Support . Fonte: http://imasters.com.br/

3.5.1. Incident Management O objetivo do Incident Management é restaurar a operação normal dos serviços tão rápido quanto possível e minimizar o impacto adverso sobre o negócio, de acordo com níveis de serviço previamente definidos. Um incidente, tal como definido pelo ITIL é: “[Incidente é] Qualquer evento que não é parte da operação normal de um serviço, que causa, ou que pode vir a causar uma interrupção ou redução na qualidade do serviço.” (OGC, 2005, p. 71)

Para tratar tais incidentes, o ITIL estabelece as seguintes atividades: •

Detecção e registro de incidente ; o

•

Esta atividade é responsável por identificar que houve algum evento inesperado que afetou a infra-estrutura de TI. O resultado é que o registro de incidente foi criado e existe uma descrição;

Classificação e suporte inicial ; o

Neste ponto o incidente é classificado segundo uma categoria prédefinida e possui uma prioridade associada. É necessário aqui


o

•

22

O objetivo é descobrir uma solução ou Workaround 10 para tratar um determinado incidente. Não há recomendações específicas para este ponto no ITIL, em razão de inúmeras técnicas poderem ser utilizadas. O importante é registrar todas as ações sobre o ticket e executar a escalação funcional11 quando necessário;

Resolução e recuperação ; Neste ponto a solução registrada junto ao incidente é aplicada sobre a infra-estrutura para que o serviço seja restabelecido. o

•

Fechamento do incidente ; o

•

Depois que o serviço foi restaurado e o cliente atesta o funcionamento, o ticket deve ser fechado. Isso inclui notificar o Service Desk e guardar o modo de resolução para posteriores consultas.

Propriedade, monitoração, rastreamento e comunicação do incidente . o

Esta atividade começa quando o ticket é criado e só acaba quando ele é encerrado, de forma periódica. Inclui a escalação de tickets e a notificação dos usuários sobre os eventos que acontecem sobre os mesmos.

É necessário também identificar as atividades pelas quais o Gerente de Incidentes, agente chave no processo, é responsável: •

Gerente de Incidentes o

Direcionar a eficácia e a eficiência do processo de Gerenciamento de Incidentes;

o

Produzir informações gerenciais;

o

Gerenciar o trabalho do pessoal de suporte a incidentes;

o

Monitorar a eficácia da Gestão de Incidentes e fornecer sugestões de melhoria;

o

Desenvolver e manter os sistemas de Gestão de Incidentes.


23

3.5.2. Problem Management O objetivo do Problem Management, semelhante ao do Incident Management , é minimizar o impacto para o negócio que problemas e incidentes possam ter, causados por erros na infra-estrutura de TI e prevenir a recorrência de incidentes relacionados a tais erros. Porém, ao contrário do anterior, este processo busca identificar as causas reais dos incidentes e iniciar ações para melhorar ou corrigir a situação. Seu propósito é, assim, reduzir tanto a quantidade quanto a severidade de incidentes e problemas ao negócio. A definição do ITIL para um problema é resultado do objetivo disposto acima: “[Um problema é a] Causa subjacente desconhecida de um ou mais incidentes.” (OGC, 2005, p. 92)

O Problem Management possui duas vertentes, a proativa e a reativa. Na primeira, o processo se ocupa de solucionar problemas que estejam gerando incidentes. Na segunda, o processo detecta possíveis erros na infra-estrutura antes mesmo que incidentes ocorram. O chamado Erro Conhecido (Known Error ) é um problema diagnosticado com sucesso para o qual um Workaround foi identificado. As atividades do processo são as seguintes: •

•

•

Controle de Problemas o

Identificação e registro de Problemas

o

Classificação de Problemas

o

Investigação e diagnóstico de Problemas

Controle de Erros o

Medição de erros

o

Registro da solução do erro

o

Fechamento do erro

o

Monitoração do problema e progresso de resolução de erro

Prevenção Proativa de Problemas o

Análise de Tendências Definição de ações preventivas


o

24

Executar revisão do processo de resolução, identificando o que feito certo, errado e em que se pode melhorar.

Abaixo estão discriminadas as atividades do chamado Gerente de Problemas: •

Gerente de Problemas o

Desenvolver e manter o processo do controle de problemas;

o

Fazer a revisão da eficiência e eficácia do controle de problemas;

o

Produzir informações gerenciais;

o

Gerenciar o pessoal de suporte a problemas;

o

Alocar recursos para o esforço de suporte;

o

Monitorar a eficácia do controle de erros e fazer sugestões para sua melhoria;

o

Desenvolver e manter sistemas de controle de problemas e erros

o

Fazer a revisão da eficiência e eficácia do Gerenciamento Proativo de Problemas.

O Trouble Ticket System OTRS

25

4. O TROUBLE TICKET SYSTEM OTRS Conforme explicitado em Clauss (2006), qualquer Service Desk estruturado de forma profissional utiliza para a consecução de seus objetivos uma aplicação de software , que documenta todas as atividades e manipulações na infra-estrutura sem deixar lacunas. Aplicações deste tipo são conhecidas como Ticket Systems . No mercado diferentes empresas oferecem seus produtos, como por exemplo, a HP como o software “Open View Service Desk ” ou a Computer Associates com “Unicenter Service Plus Service Desk ”. É possível encontrar também sistemas open-source , sobre os quais não incidem custos de licenças, como, por exemplo, osTicket , Trouble Ticket eXpress ou OTRS. Como já anteriormente explicitado, neste trabalho, a ferramenta a ser explorada é o OTRS. Este capítulo se ocupa de oferecer uma visão geral sobre a ferramenta e o contexto no qual ela se insere.

4.1. O QUE É UM TICKET SYSTEM? Um Ticket System ou Trouble Ticket System é a infra-estrutura de software responsável por centralizar, registrar e tratar solicitações de clientes dentro de um contexto empresarial de prestação de serviços. No que se refere a clientes, estes podem ser tanto de natureza interna (caso em que os próprios funcionários são os solicitantes) quanto externa (solicitante não possui vínculo organizacional). É necessário também que esteja claro o conceito de Trouble Ticket ou simplesmente Ticket . Ele representa uma solicitação de serviço efetuada por um cliente interno ou externo, que possui um identificador único e que tem a capacidade de manter um histórico completo sobre o seu ciclo de vida. Isso permite que qualquer agente envolvido no processo possa dispor sem demoras de uma visão geral sobre as ações já tomadas para atender à solicitação. O ticket pode ser atendido com sucesso ou não e fica posteriormente disponível na base de dados para consulta. Neste sentido, conforme ilustra OTRS (2007) o ticket assemelha-se ao prontuário de um paciente. Ao dar entrada no hospital, um registro (prontuário) é aberto e nele ficam guardados o estado clínico do paciente e sua evolução, medicações administradas, etc. Um médico da equipe que for designado para cuidar do doente pode, de maneira rápida,

26


fechado, mas pode ser recuperado a qualquer tempo, quando for conveniente ou necessário.

4.2. CICLO DE VIDA DE UMA REQUISIÇÃO (TICKET ) No contexto do OTRS, um ticket ou requisição de cliente segue um determinado ciclo de vida, que é elucidado através do diagrama abaixo:

Open Ticket Request System Início

Criar Ticket

Cliente

Processar Solicitação do Cliente

Agente

[Sim]

Notificar Cliente e Arquivar Ticket

Solução Encontrada ou Inviável?

Fim

Diagrama 4.1. Ciclo de vida de um Ticket . Fonte: Autor

Dentro da aplicação, o cliente cria um ticket , no caso do OTRS por e-mail ou mesmo diretamente na ferramenta. O agente irá tratar a requisição feita enquanto não for encontrada uma solução ou for determinada sua inviabilidade. O cliente é notificado e o


27

4.3. CARACTERÍSTICAS GERAIS DO OTRS O OTRS, que é a abreviação para Open Ticket Request System , é um pacote de software para o rastreamento de solicitações que uma empresa, organização ou instituição pode utilizar para atribuir bilhetes para requisições feitas, facilitando assim grandemente o tratamento de chamadas de suporte e outros tráfegos gerados por clientes. A Figura 4.1 abaixo mostra a tela inicial do OTRS para o cliente. Vale observar, que embora a interface abaixo seja mostrada em inglês, o OTRS permite trocar o idioma conforme o público alvo, estando assim disponível também em português.

Figura 4.1. Tela de Login do cliente. Fonte: OTRS (2007)

Como outros Trouble Ticket Systems , o OTRS faz muito mais que simplesmente lidar com caixas de e-mail. Para cada ticket existe um histórico, mostrando o que aconteceu ao ticket durante o seu ciclo de vida. O OTRS agrupa múltiplas requisições para o mesmo incidente, tornando assim possível trabalhar sobre um incidente específico, em vez de sobre


28

ordenando e respondendo-as. O OTRS é altamente escalável, capaz de tratar milhares de tickets por dia e um número praticamente ilimitado de agentes. A Figura 4.2 mostra a interface de trabalho dos agentes do OTRS com vários tickets pendentes:

Figura 4.2. Interface dos agentes do OTRS. Fonte: OTRS (2007)

O OTRS possui funcionalidade integrada para criar, retrabalhar e fazer busca de textos de FAQ (Frequently Asked Questions ). Os textos de FAQ podem ser incorporados às respostas dos agentes aos tickets. A Figura 4.3 ilustra a tela de FAQ do OTRS:


29

Figura 4.3. FAQ do cliente. Fonte: OTRS (2007)

Através da utilização de uma interface Web com o usuário, o OTRS é acessível independentemente do respectivo sistema operacional, já que ele é manuseado a partir de um web-browser comum.

4.4. CARACTERÍSTICAS TÉCNICAS DO OTRS Esta seção discute os aspectos essencialmente técnicos relacionados à ferramenta OTRS, como sua linguagem de programação, sistema operacional, banco de dados e arquitetura.

4.4.1. Linguagem de Programação Desde seu início, o OTRS foi implementado na linguagem de programação Perl. A interface se torna mais amigável para o usuário com o uso de Javascript (que pode ser desligado por questões de segurança). As diferentes funcionalidades do OTRS podem ser


30

A interface Web utiliza seu próprio mecanismo de templates 12 chamado DTL (Dynamic Template Language ) para facilitar a exibição das saídas de dados do sistema.

4.4.2. Sistema Operacional e Banco de Dados Originalmente, o OTRS só funcionava com bases de dados MySQL. Desde esse tempo, suporte para PostgreSQL, Oracle, DB2 e Microsoft SQL Server foi adicionado. O OTRS pode ser usado em muitas plataformas UNIX ou semelhantes a ele como, Linux, Mac OS X, FreeBSD, etc., bem como em MS Windows . A escalabilidade dos sistemas OTRS pode ser aumentada utilizando mod_perl para o servidor Apache ou através da separação entre o servidor de dados e servidor web, possibilitando um grande número de agentes trabalhando simultaneamente e grandes volumes de tickets. Além disso, o OTRS utiliza o software CRONW, que serve para executar determinados scritps periodicamente, como o que verifica a caixa de e-mails destinada ao OTRS.

4.4.3. Arquitetura A arquitetura de software empregada pelo OTRS segue o estilo arquitetural em camadas, que segundo Pressman (2004), este modelo é caracterizado pela organização hierárquica, em que cada camada fornece serviços para a camada acima, servindo como cliente para a camada abaixo. No APÊNDICE I, seus componentes individuais são explicados em detalhes. Vale ressaltar que os estilos arquiteturais ainda de hoje são fortemente baseados no modelos estudados.

31

Suporte na Eletronorte

5. SUPORTE NA ELETRONORTE A estrutura de suporte à TI na Eletronorte é mostrada neste capítulo. Além disso, seu parque tecnológico será caracterizado, em conjunto com uma análise do status quo da empresa no que se refere a Service Management . Serão mostradas também as atividades realizadas para efetivar a implementação da ferramenta OTRS juntamente ao framework ITIL.

5.1. A EMPRESA Tal como consta em Eletronorte (2008), a Eletronorte (Centrais Elétricas do Norte do Brasil S.A.), sociedade anônima de economia mista e subsidiária da Eletrobrás (Centrais Elétricas Brasileiras S.A.), é uma concessionária de serviço público de energia elétrica. Criada em 20 de junho de 1973, com sede no Distrito Federal, gera e fornece energia elétrica aos nove estados da Amazônia Legal – Acre, Amapá, Amazonas, Maranhão, Mato Grosso, Pará, Rondônia, Roraima e Tocantins. Por meio do Sistema Interligado Nacional – SIN, também fornece energia a compradores das demais regiões do País.

5.1.1. Parque Tecnológico A infra-estrutura da Eletronorte (especificamente a do Lacen, a ser abordado mais adiante) possui dimensões significativas e apresenta considerável grau de dificuldade para o seu adequado gerenciamento. A Tabela 5.1 abaixo resume a infra-estrutura no que diz respeito à quantidade de computadores e infra-estrutura de rede: Tabela 5.1. Infra-estrutura física do Lacen

Item

Quantidade

Estações de trabalho Servidores de aplicação e banco de dados Switches

97 9 5 1

Roteador

Ao lado do seu parque físico, existe uma série de serviços, mostrados na Tabela 5.2,

32


Tabela 5.2. Serviços da Infra-estrutura

Descrição Internet DNS WINS E-mail Internet Active Directory Subversion Rede Wireless Suporte Software

Conforme pontua Clauss (2006), uma infra-estrutura de TI de maiores proporções, tal como a acima apresentada, quer seja num ambiente acadêmico ou comercial, representa o componente mais importante para o bom funcionamento da organização. É, de certo modo, sua artéria aorta. Uma prestadora de serviços financeiros, por exemplo, cuja criação de valor está baseada na composição e gerência de ativos, depende 100% do processamento eletrônico de dados. Caso seus sistemas não estejam disponíveis, a empresa simplesmente pára. Por este motivo, procura-se organizar a operação desses sistemas da tal forma de que o trabalho conjunto de todos os componentes envolvidos aconteça da forma mais bem definida possível e, também, que os processos através dos quais as empresas ganham dinheiro sejam possibilitados e suportados de forma ótima através do uso de TI.

5.1.2. Estrutura Organizacional A Eletronorte está organizada em diferentes unidades hierarquicamente organizadas, responsáveis por diferentes atribuições. O Lacen (Laboratório Central) é uma de tais unidades, que por sua vez possui outras estruturas organizacionais que concentram diferentes áreas de competência no escopo técnico do Laboratório. A Tabela 5.3 mostra os processos existentes no Lacen.

33


Tabela 5.3. Processos no Lacen

Processo

Responsabilidade

CAEL CAME ENEE ENEM ENQA ENSG GCTP MATI TIMI

Calibração de instrumentos elétricos Calibração de instrumentos mecânicos Ensaios Elétricos Ensaios Mecânicos Ensaios Químicos Ensaio de Equipamentos de Segurança Divisão de Pesquisa Laboratório de Manutenção de Instrumentos Tecnologia de Informação e Automação Industrial

Para o escopo deste trabalho, são especialmente de interesse o MATI – Laboratório de Manutenção de Instrumentos – e o TIMI – Tecnologia de Informação e Automação Industrial. O primeiro é responsável, como já dito, pela manutenção de computadores no Lacen. No entanto, ele limita-se às questões voltadas ao hardware somente, incluindo nobreaks , estabilizadores, dentre outros componentes. O fluxo de trabalho no MATI é gerenciado pelo software já mencionado, SIGLacen (Sistema Informatizado de Gestão do Lacen). O TIMI, além de responsável pelo desenvolvimento de soluções computacionais, fica encarregado do suporte à infra-estrutura de rede, telecomunicações e software (inclusive o próprio SIGLacen) na Eletronorte, gerando considerável carga de trabalho. As atividades atualmente desempenhadas não são passíveis de auditoria, em razão de não haver nenhuma ferramenta para o controle. É exatamente nesta lacuna que atuará o OTRS.

5.1.3. Status Quo Atualmente no TIMI ocorre um fenômeno que é comum na grande maioria das empresas. Os clientes não possuem um ponto único de contato (SPOC) e encaminham suas demandas por e-mail ao colaborador que conhecem ou que julgam ser o responsável por atender determinada solicitação. Outro fato é que os que respondem às solicitações são colaboradores que já


34

somas significativas, já que as atividades de criação direta de valor para a empresa são prejudicadas. Isso leva ao quadro em que é impossível para a gerência obter uma visão geral sobre os serviços prestados, ou saber qual a carga-horária efetiva dos colaboradores que está sendo direcionada para esforços de suporte. Além disso, é freqüente a solicitação de serviços verbalmente pelos colaboradores, o já estabelecido e informal “faz aqui pra mim, é rapidinho”, o que é deveras prejudicial para a organização, não só porque não permite registrar as solicitações, mas também porque tais informalidades podem consumir tempo considerável do colaborador em questão. De forma sintética, os problemas observados com respeito ao suporte estão especificamente relacionados aos seguintes aspectos: •

Ausência de um ponto único de contato (SPOC);

•

Necessidade de melhoria no emprego de recursos humanos;

•

Falta de informações gerenciais sobre o suporte;

•

Requisições informais de suporte não são registradas (canal de comunicação é verbal).

A implantação da ferramenta OTRS em conjunto com as boas práticas do ITIL se propõe exatamente a trazer soluções ao cenário apresentado. Este capítulo mostra como foi o processo de customização da ferramenta, as alterações necessárias, relatórios gerados.

5.2. ATIVIDADES REALIZADAS O processo de implantação e customização da ferramenta OTRS e conseqüente implantação dos processos de Incident e Incident e Problem Management do Management do framework ITIL framework ITIL envolveu tanto aspectos técnicos, quantos aspectos ligados ao levantamento de informações da Empresa e proposições de modelos para que as boas práticas do ITIL sejam atendidas. A seguir, tais atividades serão mostradas, as quais poderão servir como referência para futuros trabalhos.

5.2.1. Elaboração do Catálogo de Serviços O primeiro passo foi elaborar um catálogo com todos os serviços de TI prestados no

35


Tal catálogo, obtido a partir da análise de sistemas existentes e entrevistas com diferentes stakeholders é stakeholders é mostrado na Tabela 5.4.

Tabela 5.4. Serviços Prestados no TIMI

Categoria

Serviço Configuração de serviço de e-mail (Exchange)

Email/Internet

Configuração para acesso à internet Criação de e-mail Desbloqueio e/ou criação de contas (logins)

Rede

Compartilhamento de diretório Confecção e/ou Remanejamento de cabos de rede Configuração de impressoras Inserção de computador na rede Verificação de componentes de rede

Suporte Software

Instalação de software corporativo software corporativo Suporte ao Subversion Suporte ao Windows /Office Verificação de vírus Alteração de Senha Criação de Usuário Manutenção do Software

SIGLacen/SIGLacenWeb

Suporte ao Usuário Problema de Instalação Alteração/Problema em Relatório Exportação de dados Instalação de Infra-estrutura Teste de Canal

Telecomunicações

Teste de Enlace Teste de Equipamentos


36

5.2.2. Definição da Estrutura de Suporte A estrutura de suporte definida aplicada à Eletronorte é tal como mostrada abaixo e foi desenvolvida de acordo com os padrões estipulados pelo ITIL no Service Support Band , OGC (2005).

A estrutura de suporte está dividida em três elementos: •

1ª Linha de Suporte (Service Desk) o

•

2ª Linha de Suporte (Suporte Técnico) o

•

É o Service Desk , ponto de contato com o cliente. Responsabilidades incluem: registro do incidente, direcionar requisições de serviço a outros grupos de suporte quando eles não forem fechados, suporte inicial e classificação, propriedade, monitoria, rastreamento e comunicação, solução e recuperação de incidentes não direcionados para o grupo de 2ª Linha.

Composto por pessoal com conhecimento técnico que pode integrar o Service Desk . Envolvido em tratar requisições de serviço, monitorar os detalhes do incidente, investigação e diagnóstico (incluindo solução onde possível), detecção de possíveis problemas e encaminhamento para o Gerenciamento de Problemas, resolução e recuperação de incidentes designados.

3ª Linha de Suporte (Especialistas/Analistas) o

Grupo de suporte que investiga e resolve incidentes que estão fora do escopo de habilidade do suporte técnico. Tais incidentes podem envolver programação, reparo de hardware ou de infra-estrutura de telecomunicações.

37


É válido observar que a estrutura de suporte está de acordo com os sub-processos definidos pelo ITIL para o processo de Incident Management , explorados na Seção 3.5.1. A Figura 5.1 mostra de forma esquemática as informações anteriormente apresentadas. É válido observar o fenômeno chamado de escalação funcional , que acontece quando o grupo de suporte em questão não possui condições de tratar o incidente, encaminhando-o assim às linhas subseqüentes de suporte, com nível crescente de especialização. 1ª Linha de Suporte

2ª Linha

3ª Linha

Detectar e Registrar

Procedimento de Requisição de Serviço

Requisição

Suporte Inicial

Resolvido

Não

Investigar e Diagnosticar

Não Resolução e Recuperação

Resolvido

Investigar e Diagnosticar

Não Resolução e Recuperação

Resolvido

Resolução e Recuperação

Fechar


38

5.2.3. Criação de Relatórios Gerenciais Os relatórios que serão gerados para a gerência constituem peça fundamental da grande maioria dos softwares que se propõem a atuar num cenário corporativo. Não foi diferente com o OTRS. A partir de discussões com diretores e responsáveis, os seguintes relatórios foram concebidos: •

Quantidade mensal de serviços realizados (por ano, por colaborador);

•

Serviços por cliente (por ano, por mês....);

•

Hxh por tipo de serviço;

•

Quantidade de serviços por ano;

•

Quantidade de novos clientes por ano;

•

Quantidade de serviços por processo;

•

Tempo médio para atendimento de solicitações por serviço.

Para fins de ilustração, a Figura 5.2 mostra a tela de estatísticas (relatórios do OTRS), seguida pelo Gráfico 5.1, na qual se vê a saída resultante ao selecionar o relatório da quantidade mensal de serviços realizados (Atendimentos por Fila).


39

Gráfico 5.1. Relatório gráfico dos atendimentos por fila do OTRS. Fonte: Autor

É válido apontar também que a ferramenta OTRS apresenta grande flexibilidade para a geração de relatórios, permitindo desde a inserção de comandos na linguagem SQL até a exportação dos dados para uma planilha do Microsoft Excel. O Gráfico 5.2 gerado pelo MS Excel com os dados exportados pelo relatório mostrado na Gráfico 5.1 apresenta maior legibilidade:


40

Gráfico 5.2. Relatório gráfico dos atendimentos por fila com Excel. Fonte: Autor

5.2.4. Instalação da Ferramenta OTRS Esta seção descreverá os passos e atividades executadas que constituíram o aspecto eminentemente técnico do trabalho, no sentido da configuração de servidores, instalação de aplicativos, configuração da ferramenta e elaboração de documentação técnica. Escolha da ferramenta Nesta seção é válido esclarecer como os trabalhos com a ferramenta OTRS iniciaram. Inicialmente com o intuito de instalar na Eletronorte uma ferramenta que se propunha a servir como bug tracker 13 para as atividades de desenvolvimento de software no âmbito da Empresa, uma pesquisa sobre as ferramentas existentes no mercado foi empreendida. Na ocasião, testes em caráter piloto foram executados com as ferramentas Issue Tracker , RT3, Roundup e Trac e, por fim, OTRS. Reconhecendo-se a necessidade de não somente dispor de uma ferramenta para bug tracking , mas algo mais abrangente, que pudesse servir de suporte para monitorar e auxiliar equipes em prestar suporte ao usuário, a ferramenta escolhida foi o OTRS. A ferramenta OTRS está longe de ser simplesmente um bug tracker . Seus inúmeros


41

recomendações do ITIL (vide Capítulo 46), fizeram com que ele fosse, em detrimento das outras já citadas, o software a auxiliar as operações do IT Service Desk da Eletronorte. Instalação em cenário de testes Os passos iniciais consistiram um instalar a ferramenta OTRS, para efetuar testes de usabilidade e de aderências às necessidades em um servidor Linux, com as seguintes especificações: •

AMD 2.6 MHz

•

Memória 2GB

•

Kurumin 6

Este passo apresentou inúmeras dificuldades, já que o pacote de instalação para distribuições baseadas em Debian fornecido pelos desenvolvedores não funcionou out of the box 14 , sendo ainda necessária uma série de configurações para poder fazê-lo funcionar adequadamente, integrando-o ao banco de dados MySQL e interagindo com o servidor Microsoft Exchange da Empresa. Instalação em Servidor de Produção Uma vez terminados os testes e assegurada a possibilidade de implantação, partiuse à instalação da ferramenta em ambiente de produção. O parque de servidores da Empresa é fortemente baseado na plataforma Windows , como foi possível constatar na seção 5.1.1. A organização otrs.org fornece um instalador para plataformas baseadas em Windows , porém, ele só pode ser aplicado quando se trata de um sistema novo, exclusivamente direcionado para a ferramenta OTRS. Como no servidor destinado à ferramenta já havia diversos serviços em operação que iriam entrar em conflito caso o instalador fosse utilizado, prossegui-se, então, à instalação manual dos componentes integrantes da solução. Tal processo não fora documentado nem pela empresa otrs.org, nem em fóruns de tecnologia especializados. Foi necessário então desenvolver uma Instrução Técnica (vide APÊNDICE II) para instalação do OTRS em servidores Windows que já possuem algum tipo de serviço rodando previamente à sua instalação. No caso da Eletronorte, os seguintes serviços já se encontravam em operação: •

Servidor Web Apache 2.063


•

MySQL 4.1

•

WebAPSEE 1.2.5

42

Era necessário, assim, que a o OTRS co-existisse pacificamente com as outras aplicações pré-existentes, sob pena de submeter a organização a uma queda da qualidade de serviço, algo que, especialmente no contexto deste trabalho, não poderia ser considerado. O servidor utilizado possui as seguintes características: •

Intel Xeon 2.6 MHz

•

Memória 2GB

•

Windows 2003 Server R2

5.2.5. Definição dos Estados das Solicitações Dentro do contexto de um IT Service Desk é necessário deter um refinado mapeamento sobre os estados das solicitações. Mediante avaliação com a gerência sobre os possíveis estados chegou-se à seguinte configuração: •

Fechado com sucesso o

•

Fechado sem sucesso o

•

Ocorre quando um ticket é mesclado com outro, como quando vários usuários diferentes reportam o mesmo incidente.

Novo o

•

Indica que o solicitante não teve o serviço atendido por razão a especificar

Mesclado o

•

Indica que o solicitante teve o serviço atendido;

Ticket está presente no sistema, mas ainda não foi tratado nem está aberto.

Em progresso o

Tratamento do ticket está sendo realizado.


o

•

Indica que em uma data determinada, um lembrete será enviado ao agente com relação ao ticket .

Removido o

•

Indica que o respectivo chamado está pendente para ser fechado sem sucesso

Lembrete de Pendente o

•

Indica que o respectivo chamado está pendente para ser fechado com sucesso

Pendente Fechamento Automático – o

•

Por alguma razão o processamento do ticket não pode continuar.

Pendente Fechamento Automático + o

•

Ticket foi aberto no sistema, mas ainda não se encontra em andamento. Indica que o Service Desk está ciente do ocorrido e em breve tomará providências.

Pendente o

•

43

Situação na qual o ticket foi excluído das filas e listas da ferramenta. Mas pode ainda ser acessado através de busca.

Aguardando resposta do cliente o

Freqüentemente para a resolução do incidente, informações adicionais são demandadas pela equipe de suporte, que devem ser repassadas pelo cliente, para que ele seja então solucionado.

5.2.6. Integração do Service Desk à Intranet A fim de possibilitar aos clientes uma interface única e padronizada para efetuar suas solicitações, e ainda visando a eliminar vícios corporativos pré-existentes (vide Seção 0), foi necessário conceber dentro da intranet da Empresa uma aplicação para que clientes pudessem se comunicar com o Service Desk . No desenvolvimento houve o cuidado de manter o look and feel 15 do restante da página da intranet. A tela do front-end do Service Desk é mostrada na Figura 5.3:


44

Figura 5.3. Front-end do Service Desk ELN. Fonte: Autor

Para o desenvolvimento, foram utilizadas as seguintes tecnologias: •

ASP.NET 2.0 (C#)

•

MySQL 4.1

•

MySQL Connector 5.1

•

XML

A tecnologia de programação de escolha foi a linguagem C# junto com o .NET Framework , em razão de a intranet da Empresa ter sido desenvolvida com tal tecnologia, o que facilitou a integração. Foi necessário conectar o .NET ao banco de dados MySQL, o que foi feito utilizando-se um componente nativo do .NET para acesso a dados em MySQL,

45


A topologia da aplicação é como segue:

Figura 5.4. Topologia do Help Desk . Fonte: Autor

A interface do Help Desk está dentro da Intranet do Lacen. Ela por sua vez, serve somente como interface para o envio de e-mails através do Servidor Exchange da Eletronorte. Os dados que mostra ao usuário, as naturezas das requisições, porém, são oriundos da base de dados MySQL utilizada pelo OTRS. Este por sua vez, possui uma caixa de e-mail dedicada para receber solicitações de clientes, recuperando tais dados diretamente do Exchange e alimentando a base de dados. O código-fonte em C# da aplicação e o código do arquivo de dados XML podem ser conferidos no APÊNDICE III.

46

OTRS e ITIL

6. OTRS e ITIL Este capítulo procura mostrar como a ferramenta OTRS está alinhada com o framework ITIL segundo critérios específicos. A avaliação será feita considerando os processos de ITIL para Incident e Problem Management . Em seguida, o atendimento ou não de tais critérios será exemplificado através da realização de casos de uso para efeito de ilustração.

6.1. CONDIÇÕES A avaliação foi conduzida em um ambiente de testes que replica a instalação do OTRS em produção na Eletronorte. As informações obtidas sobre a organização e apresentadas no capítulo anterior foram a base para a customização da ferramenta e conseqüente aplicação no ambiente empresarial. Uma avaliação final será emitida, identificando aspectos em que a ferramenta possui bom grau de compatibilidade e aqueles em que ela demonstra fraca aderência. Ressalta-se que determinados critérios (visualmente identificados ) não são atendidos com a configuração padrão do OTRS. Porém, mediante adequada customização, é possível ter o critério em questão atendido.

6.2. CRITÉRIOS DE AVALIAÇÃO Tais critérios são abordados sob três perspectivas, a saber: •

Critérios Obrigatórios

•

Critérios de Integração

•

Critérios Funcionais

Tal abordagem reflete características que devem necessariamente estar presentes em ferramentas que se propõem a trabalhar com o ITIL, levando em conta as estratégias utilizadas para a comunicação e troca de informações com os outros processos do ITIL, além de destacar aspectos eminentemente funcionais. Os critérios de avaliação foram adaptados do trabalho de Pfleger (2005) em conjunto com informações obtidas de OGC (2005), Clauss (2006), e Masters (2008).

47

OTRS e ITIL

6.2.1. Incident management s o i r ó t a g i r b O s o i r é t i r C

#

Descrição

Sim/Não

IM.1

Possibilita a supervisão e a análise do progresso da resolução do incidente?

S

IM.2

Categorias, prioridades e outras características de classificação permitidas podem ser definidas e ser escolhidas a partir de listas?

S

IM.3

Permite a execução com desempenho suficientemente satisfatório do Controle de Incidentes (Incident Control ), ou seja, a criação, classificação, coordenação, reconhecimento e solução de incidentes?

S

IM.4

Existem funcionalidades automatizadas para priorização dos incidentes?

N

IM.5

Fornece informações ao usuário afetado em intervalos definidos de tempo ou de acordo com o progresso do processamento?

S

IM.6

Possibilita entradas de texto livre para o registro, documentação e solução de um incidente?

S

IM.7

Possibilita somente a usuários autorizados a criação, modificação e fechamento de incidentes?

S

IM.8

Durante a geração do incidente são guardadas informações sobre o horário e data, número único de incidente (Ticket number) é gerado e as informações do usuário e de quem registra são preservadas?

S

IM.9

É possível em um ticket escolher-se através de uma categoria que serviço foi afetado pelo incidente?

S

IM.10

Existem indicadores que podem expressar a prioridade, os impactos e a urgência de um incidente? – Comentário: atendido de forma limitada pelo OTRS

S

IM.11

Os tickets podem ser facilmente observados e monitorados?

S

IM.12

Possibilita a criação de demonstrativos, bem como listas de tickets ou relatórios gerenciais?

S

IM.13

Permite a análise da base de tickets para reconhecer tendências?

N

IM.14

(Quase) Todas as alterações nos incidentes são gravadas e

S

48

OTRS e ITIL

como, por exemplo, por prioridade?

o ã ç a r g e t n I e d s o i r é t i r C

s i a n o i c n u F s o i r é t i r C

IM.17

Possibilita a busca de incidentes semelhantes contanto que os mesmo atributos estejam disponíveis?

S

IM.18

Grava junto o agente responsável neste momento pelo ticket ?

S

IM.19

Possibilita encaminhar um ticket a determinada unidade?

S

IM.20

Possibilita o acesso a padrões de resolução, erros conhecidos, e workarounds relacionados a um incidente?

S

IM.21

Existem mecanismos para o gerenciamento das dependências entre incidentes, workarounds, problemas e erros conhecidos?

S

IM.22

Permite fechar todos os incidentes ainda abertos quando o problema relacionado foi solucionado?

N

IM.23

Mantém uma ligação direta permanente entre incidente, erro conhecido, e problema?

S

IM.24

Disponibiliza detalhes do cliente e pode criar uma relação com entre as suas informações e serviços de diretório (LDAP)?

S

IM.25

O CMDB (se disponível) pode ser consultado para obter informações sobre um CI que sejam relevantes para um incidente? – Comentário: No modelo do OTRS não está disponível um CMBD.

N

IM.26

É possível associar CI’s com um incidente? -- Comentário: no OTRS não são previstos CI’s

N

IM.27

É possível ter acesso a informações do Gerenciamento de Mudança para se estar a par de modificações na infra-estrutura que sejam relevantes para o Gerenciamento de Incidentes?

N

IM.28

Outros processos têm acesso às informações do Gerenciamento de Incidentes, por exemplo, através de uma interface ao sistema?

N

IM.29

É possível notificar o Service Desk ou outros processos de forma automática, quando limiares relacionados aos incidentes são ultrapassados?

S

IM.30

Os limiares acima citados por ser definidos e modificados por um grupo autorizado de pessoas?

S

IM.31

Suporta mecanismos automatizados de escalação?

S

IM.32

Possibilita gerar listagem de tickets escalados?

S

Há possibilidades suficientes, de prover os usuários com

49

OTRS e ITIL

IM.34

Possibilita notificar diferentes destinatários sobre incidentes que são no momento de alta prioridade e atribuir um de tais incidentes a outra unidade?

N

IM.35

Possui integração com email?

S

6.2.2. Problem Management # s o i r ó t a g i r b O s o i r é t i r C

Descrição

Sim/Não

PM.1

Possui em princípio a capacidade de diferenciar entre incidente, problema e Workaround?

S

PM.2

Cria automaticamente registros de incidentes e problemas e lhes confere um selo de data e horário?

S

PM.3

É possível adicionar texto livre durante a criação da descrição do problema e durante todas as ações para sua resolução?

S

PM.4

Possibilita a atribuição de códigos sobre a gravidade de um problema a fim de avaliar os efeitos sobre os serviços de TI? (e.g, impacto = baixo, alto, crítico)

N

PM.5

O Gerente de Problema pode ser automaticamente informado quando os valores-limite pré-definidos forem ultrapassados?

S

PM.6

Os valores referentes à dimensão da gravidade podem ser definidos por um grupo autorizado de pessoas? – Comentário: No OTRS não é possível representar a dimensão de gravidade (veja PM.4)

N

PM.7

Categorias, prioridades e outras características de classificação permitidas podem ser definidas e ser escolhidas a partir de listas?

S

PM.8

É possível elaborar uma análise de tendência para reconhecer os problemas de forma proativa?

N

PM.9

PM.10

Possibilita aos agentes do Gerenciamento de Problemas comunicarem ao Service Desk (e Gerenciamento de Incidentes) informações sobre status e progresso, bem como soluções temporárias e workarounds? É possível associar automaticamente novos incidentes a problemas e erros conhecidos pré-existentes?

N

S

50

OTRS e ITIL

o ã ç a r g e t n I e d s o i r é t i r C

PM.12

O progresso do processamento de um problema pode ser monitorado e observado? – Comentário: no OTRS os problemas estão ligados aos respectivos incidentes

S

PM.13

É possível ter acesso a dados históricos sobre Problemas e Erros Conhecidos, utilizados pelos agentes durante a fase de resolução de problemas? Em resumo: É possível fazer busca em tickets antigos? – Comentário: no OTRS os problemas estão ligados aos respectivos incidentes

S

PM.14

É possível manter uma ligação entre um incidente e um problema? – No OTRS o tratamento do problema é feito através de um ticket de incidente

S

PM.15

Está previsto algum recurso para transferir os tickets do Gerenciamento de Incidentes para o de Problemas?

N

PM.16

Existe uma interface ao CMDB para poder completar as informações sobre os problemas e incidentes?

N

PM.17

Permite acesso seguro e monitorado às informações sobre o Gerenciamento de Mudança, como por exemplo, agendas de mudança e o histórico de mudança?

N

PM.18

Possibilita associar erros conhecidos com RFC’s (Requests For Change) (e.g., bandeja da impressora está defeituosa e necessita de troca) e manter tal associação de forma permanente?

S

PM.19

É possível fechar todos os erros conhecidos (e assim todos os incidentes ligados a ele) tão logo o respectivo problema seja tratado através de uma mudança?

N

PM.20

Possibilita acesso seguro e controlado ao CMDB para poder descobrir, modificar ou excluir dados relevantes ao problema? – Comentário: No OTRS não está previsto um CMDB

N

PM.21

Outros processos possuem acesso às informações do Gerenciamento de Problemas?

N

PM.22

Os erros conhecimentos da área de desenvolvimento de software podem ser transferidos para a base de erros do

N

Gerenciamento de Problema? n u F

s i a n o i c

PM.23

É possível elevar automaticamente a dimensão da gravidade de um problema quando o número de incidentes ou dos usuários afetados aumenta? É

N

51

OTRS e ITIL

6.2.3. Casos de Uso Nesta seção serão mostrados os casos de uso que comprovam os julgamentos acima realizados, numa abordagem mais prática, voltada ao processo de Incident Management , visto que a abordagem para Problem Management é semelhante. Conforme exposto no início do capítulo, para critérios específicos onde a ferramenta na sua configuração padrão não atender aos requisitos do ITIL, será mostrado o resultado da adaptação/configuração conduzida para que o critério em questão fosse atendido. Legenda Nas telas dos respectivos casos de uso apresentados, uma indicação com setas, círculos e rótulos textuais na cor vermelha será utilizada para facilitar a visualização do critério do ITIL em análise.

Tabela 6.1. UC1. Solicitar Serviço. Fonte: Autor

Identificação

UC 1. Solicitar Serviço

Critérios atendidos

IM.2, IM.3, IM.6, IM.8, IM.10

Descrição Este caso de uso exemplifica o cenário mais comum de utilização do OTRS como ferramenta para registro de incidentes. Aqui, por exemplo, um agente de incidentes doService Desk recebe uma ligação de um cliente solicitando a instalação de um software . Como resposta, ele é informado de que deve encaminhar um e-mail a um endereço específico. O OTRS pode tratar este cenário de forma muito transparente, como é possível notar na Figura 6.1 abaixo. É possível determinar facilmente a fila a que deve pertencer, o usuário em questão, seu status (no caso, ele é criado e na mesma hora fechado), prioridade [IM.2, IM.10] e a descrição do incidente comunicado. Muitos dos requisitos do ITIL listados na seção anterior são atendidos sem maiores esforços. Ao clicar em “Criar” (não mostrado abaixo), data e hora são salvas e um número de ticket único é gerado [IM.8]. O agente pode também utilizar texto livre para caracterizar o incidente [IM.6].

52

OTRS e ITIL

IM.6

Figura 6.1. Criação de novo Ticket . Fonte: Autor

Tabela 6.2. UC1. Ticket -padrão. Fonte: Autor

Identificação

UC 2. Encaminhar para outras unidades


IM.19

Descrição Este caso de uso é uma extensão do anteriormente apresentado e ilustra situação em um dado ticket precisa ser encaminhado para outra unidade de suporte para que seja processado. Neste caso específico, um cliente reporta que não consegue acessar nenhum serviço de rede. O agente doService Desk registra o incidente e verifica que nenhum outro computador no prédio do usuário pode ser visto pela rede. Ele encaminha então o incidente ao grupo de especialistas para providências. A situação é ilustrada na Figura 6.2.

53

OTRS e ITIL

IM.19

Figura 6.2. Encaminhamento de ticket a outra unidade. Fonte: Autor

Tabela 6.3. UC3. Criar ticket pelo usuário, Escalação. Fonte: Autor

Identificação

UC 3. Criar ticket pelo usuário, Escalação


IM.29, IM.30

Descrição No OTRS é possível que o próprio usuário se cadastre e possa então criar um chamado para o sistema. Supõe-se, por exemplo, que um usuário esteja enfrentando problemas com a impressora. Em vez de contactar o Service Desk via telefone, ele utiliza uma interface padrão, como a da Figura 6.3 abaixo, com a possibilidade de acompanhar o status da solicitação (Figura 6.4). A partir da submissão, o usuário pode a qualquer tempo acompanhar o status da sua requisição, através de outra tela. O agente aceita o chamado e parte para o local para sanar o problema. Como este é um processo geralmente demorado, o ticket em questão sofre o que se chama de escalação (escalation ), em razão de um limiar de tempo prédefinido ter sido atingido. Neste caso específico, o tempo de escalação (escalation time ) é de onze minutos, como se vê abaixo (Figura 6.5). Quando a escalação ocorre (Figura 6.6), nenhum outro ticket pode ser processado até que o chamado em questão seja fechado. Nesse processo, os agentes envolvidos podem optar por receber notificações sobre os tickets [IM.29]. As informações relativas à escalação só podem ser modificadas por usuários determinados [IM.30].

54

OTRS e ITIL

Usuário cria chamado

Figura 6.3. Usuário cria ticket . Fonte: Autor

Chamados do Usuário

55

OTRS e ITIL

IM.30

Escalação de Chamado

Figura 6.5. Tempo para escalação do Ticket . Fonte: Autor

IM.30

Chamado Escalado

56

OTRS e ITIL

Tabela 6.4. UC 4. Busca Textual Completa. Fonte: Autor

Identificação

UC 4. Busca Textual Completa


IM.15

Descrição Um dos critérios do ITIL é permitir que seja feita uma busca na base por tickets que já foram fechados, a fim de auxiliar na resolução de problemas semelhantes. O OTRS disponibiliza tela para a busca completa de tickets antigos segundo diversas chaves de busca, o que é mostrado na Figura 6.7. É possível, por exemplo, a partir da tela de busca abaixo, saber quais os tickets ainda abertos que se encontram na fila do Help Desk . O resultado de uma busca-padrão é mostrado na Figura 6.8.

IM.15 Busca Textual

Figura 6.7. Tela de Busca de Tickets. Fonte: Autor

57

OTRS e ITIL

IM.15 Resultados da Busca

Figura 6.8. Tela de Resultados da Busca. Fonte: Autor

Tabela 6.5. UC 5. Escalação de Novas Filas. Fonte: Autor

Identificação

UC 5. Escalação de Novas Filas

Critério atendido

IM.31

Descrição A escalação é um conceito muito importante que é tratado sem maiores problemas pelo OTRS. Na Figura 6.9 é possível constatar que ao cadastrar uma nova fila, é possível definir os diferentes tempos de escalação, como por exemplo, para tempo de resposta, de atualização e de resolução do incidente.

58

OTRS e ITIL

IM.31

Figura 6.9. Criação de uma Nova Fila. Fonte: Autor

Tabela 6.6. UC 6. Listar Tickets Escalados. Fonte: Autor

Identificação

UC 6. Listar Tickets Escalados

Critério Não- atendido

IM.32

Descrição Conforme acima, existe a possibilidade de busca por prioridade e outras chaves, mas não por tickets escalados.

Proposta para atender ao critério Para isso uma chave de busca adicional deve ser introduzida à tela de busca, conforme mostra a outra Figura 6.9, de forma a permitir que haja um filtro também pela informação de se um ticket escalou ou não.

59

OTRS e ITIL

IM.32

Figura 6.10. Tela de Busca de Tickets com Escalação. Fonte: Autor

Tabela 6.7. UC 7. Diferenciar entre Incidentes, Problemas, Erros Conhecidos e Workarounds e estabelecer ligações entre eles

Identificação

UC 7. Diferenciar entre Incidentes, Problemas, Erros Conhecidos e Workarounds e estabelecer ligações entre eles

Critério Atendido

IM.21


IM.23

Descrição De acordo com o ITIL é necessário é necessário que a ferramenta possua a capacidade de relacionar incidentes, Workaround e problemas entre si. No OTRS é possível associar um determinado ticket com outro já existente no sistema. A tela para tal funcionalidade (critério IM.21) é mostrada na Figura 6.11.

Proposta para atender ao critério De acordo com sua configuração-padrão, o OTRS não possui a faculdade de diferenciar entre incidentes, problemas, erros conhecidos e workarounds. Conforme se mostrou no UC 1, ao se criar um ticket , não há a opção de indicar de que tipo ele se trata. Porém, é possível configurar a ferramenta (Figura 6.14) para suportar o uso de tipos, que podem ser incidente, problema, erro conhecido, e Workaround

60

OTRS e ITIL

IM.21

Figura 6.11. Criação de uma Nova Fila. Fonte: Autor

IM.23

61

OTRS e ITIL

Tabela 6.8. UC 8. Indicar o Serviço Afetado pelo Incidente. Fonte: Autor

Identificação

UC 8. Indicar o Serviço Afetado pelo Incidente


IM.9

Descrição Com a instalação-padrão do OTRS não é possível fazer uso do conceito de “Serviços”, para identificar como a infra-estrutura está sendo afetada, requisito do ITIL.

Proposta para atender ao critério A partir de apropriada adaptação dos arquivos de configuração do OTRS (Figura 6.14) é possível fazer com que um incidente, problema, ou erro conhecido esteja relacionado com um serviço específico. No exemplo da Figura 6.13, temos um incidente com vírus que afetou o serviço de internet na empresa

IM.9

Figura 6.13. Identificando o serviço afetado com o OTRS. Fonte: Autor

62

OTRS e ITIL

Figura 6.14. Tela de Configurações do OTRS. Fonte: Autor

6.3. ADERÊNCIA DO OTRS AO ITIL A Tabela 6.9 abaixo mostra um resumo das informações apresentadas nas seções anteriores. Tabela 6.9. Aderência do OTRS ao ITIL. Fonte: Autor

Critérios Obrigatórios De Integração Funcionais

Incident Management 89% 44% 71%

Problem Management 67% 30% 50%

O Gráfico 6.1 abaixo mostra uma visão geral de como o OTRS atende aos requisitos mostrados na seção 6.2 acima de forma sintética

63

OTRS e ITIL

Gráfico 6.1. Avaliação dos Critérios ITIL. Fonte: Autor

A análise do gráfico acima mostra que o OTRS atende com grau razoavelmente satisfatório aos requisitos propostos pelo IITIL no que se refere ao processo de Incident Management . Porém, é importante ressaltar o fraco desempenho da ferramenta no quesito referente à integração com outros processos do ITIL, tendo atingido pouco mais de 20% de aderência ao ITIL nesse aspecto. No que diz respeito ao processo de Change Management , o OTRS apresenta sensível queda na sua taxa de aderência, o que foi especialmente ocasionado pela limitação que diz respeito à comunicação inter-processos no ITIL.

6.4. LIMITAÇÕES Conforme se pôde constatar na seção anterior, limitações-chave do OTRS no que diz respeito à sua compatibilidade com o ITIL estão essencialmente relacionadas a sua capacidade de obter e transmitir informações a outros processos ITIL. No contexto do Gerenciamento de Serviços de TI, os processos de Incident e Problem Management devem estar intimamente relacionados aos processos de Change e Configuration Management , já que freqüentemente os incidentes e problemas estão relacionados a CI’s pertencentes à infra-estrutura de TI da Empresa.

64

OTRS e ITIL

monitorada pelo processo de Gestão de Mudança, que por sua vez terá implicações na Gestão de Configuração. Porém, conforme recomendações do próprio ITIL, em OGC (2005), verificada a impossibilidade de implementar todos os processos do Gerenciamento de Serviços ao mesmo tempo, deve-se começar implementando a função de Service Desk juntamente com o Gerenciamento de Incidentes e Problemas, escopo deste trabalho. Vale notar que nas implementações do ITIL, esses três elementos freqüentemente encontram-se relacionados de forma sinérgica, Isso irá resultar em avanços perceptíveis e, portanto, a aceitação do processo como um todo será facilitada dentro da organização e com os clientes.

6.5. BENEFÍCIOS ESPERADOS A introdução da ferramenta OTRS em conjunto com as boas práticas do framework ITIL irá possibilitar uma série de avanços no que diz respeito ao gerenciamento de serviços de TI na Eletronorte. No Capítulo 5, foram observados alguns aspectos referentes a situações na Empresa que poderiam ser alvo de melhorias no que diz respeito à prestação de serviços de TI. A adoção do OTRS/ITIL trará consigo uma série de benefícios que combaterão o cenário anteriormente apresentado. Após a implantação da ferramenta e ampla adoção pelos colaboradores, estima-se que os seguintes benefícios serão atingidos: •

Geração de relatórios sobre produtividade; o

•

Possibilidade verificar como antigos problemas foram solucionados; o

•

Os relatórios oferecidos pela ferramenta possibilitarão à gerência informações mais precisas com relação à produtividade da equipe. Isso possibilitará à gerência identificar áreas-chave que devem ser objeto de maior atenção.

O tempo para a solução de um determinado incidente poderá diminuir sensivelmente a partir do momento em será possível à equipe de suporte verificar como determinadas situações foram corrigidas ou temporariamente solucionadas (Workaround ).

Percepção efetiva sobre os serviços realizados;

65

OTRS e ITIL

o

•

Eliminação gradual do comum “faz aí pra mim, é rapidinho”; o

•

A introdução do chamado SPOC na figura do Service Desk possibilitará aos clientes um canal centralizado para se comunicar com os prestadores de serviço. Ele não precisa mais se preocupar em identificar uma pessoa em particular. Ele simplesmente comunica ao Help Desk .

Possibilidade de contabilizar o tempo destinado aos atendimentos; o

•

Tal cultura organizacional leva a perceptíveis “vazamentos” de recursos humanos, situação na qual o profissional pode acabar sendo desviado da sua atividade-fim para atender a chamado que sequer fica registrado.

Centralização das solicitações; o

•

Informação de relevância gerencial, é de suma importância ter a certeza sobre a demanda de serviços gerada. Com o registro de todos os incidentes, será possível fornecer tal tipo de informação.

Para a gerência é importante saber quanto tempo é destinado à resolução de determinada categoria de incidentes, de forma a poder identificar situações em que tempo excessivo está sendo dedicado à solução de sucessivos incidentes, sem que o problema em questão seja tratado.

Cliente pode acompanhar de forma centralizada as solicitações realizadas . o

Para o cliente estará disponível uma interface para acompanhar as solicitações, dessa forma não será mais necessário enviar diversos emails ao colaborador responsável somente para perguntar o status da solicitação.

66

OTRS e ITIL

6.6. ECONOMIA DE RECURSOS FINANCEIROS O livro de Service Support do ITIL, em OGC (2005), oferece uma análise-exemplo da economia de recursos financeiros que a introdução dos processos de Incident, Problem, Change e Configuration Management pode gerar para uma organização. No exemplo, adaptado às condições nacionais, as seguintes suposições são feitas: •

Todos os colaboradores custam R$ 30,00 por hora;

•

A organização em questão possui 500 usuários;

•

O número total de incidentes é de 5.000 por ano;

•

A média de tempo para sanar um incidente é de 10 minutos;

•

Um ano de trabalho possui 200 dias.

Na Tabela 6.10 mostram-se os respectivos processos e a estimativa de redução de custos com a implantação do ITIL. Medida eficaz que pode mostrar as possibilidades que o ITIL traz à empresa é a financeira. No caso exemplificado, ao se implementar o ITIL numa organização tal como a acima descrita é possível obter considerável redução nos custos gerais da prestação de serviços de TI. Especificamente, a partir da introdução dos quatro processos anteriormente citados, estima-se que haverá uma economia anual da ordem de R$ 125.800,00 reais.

67

OTRS e ITIL

Tabela 6.10. Economia de Recursos Financeiros com ITIL. Adaptação de OGC (2005)

Processo

Objetivo

Incident Management

Continuidade dos A implementação da Gestão de Incidentes resultou numa queda do down-time por usuário, definido níveis de serviço Suporta as como o tempo que o usuário está no telefone com o Service Desk ou não pode trabalhar em decorrência operações do Service Desk de uma falha. Se o down-time por usuário tiver diminuído um minuto por pessoa por dia, isso teria economizado à organização: 500×200×R$30×1/60 = R$ 50.000,00 por ano. Minimizar a alteração Suponha que a implementação do Gerenciamento nos níveis de serviço de Problemas diminui a quantidade de incidentes repetitivos em 500 (10% do total) por ano. Isto significa um ganho de 500×R$30×10/60=$2.500,00 por ano. Controle de InfraSeguindo a implantação da Gestão de Configuração, o Service Desk tem uma visão muito melhor sobre o estrutura de TI Garantir que relacionamento entre usuários, CI’s e incidentes. As somente hardware e três pessoas alocadas para classificação de software autorizados incidentes podem ser reduzidas para 2, resultando estejam em uso num benefício de 200x8xR$30=R$48.300,00 por ano.

Problem Management

Configuration Management

Change Management

Tratamento eficiente de mudanças

Custo/Benefício

Duas mudanças são implementadas simultaneamente, resultando num grande problema. O suporte ao cliente falha, resultando na perda de de 50 clientes com compras medias de R$ 500. Isso custou à companhia R$ 25.000,00.

Conclusão

68

7. CONCLUSÃO Este trabalho teve por objetivo mostrar o valor que a adoção de boas práticas gerenciamento de serviços de TI e o uso de ferramentas apropriadas pode trazer para o âmbito das organizações, especialmente a Eletronorte, exemplo de aplicação. O trabalho apresentou fundamentação teórica relativamente abrangente para que o entendimento fosse o melhor possível, explorando aspectos relacionados ao contexto do ITSM e à ferramenta OTRS. Conforme dito anteriormente, existem no mercado várias opções de ferramentas que se propõem a suportar os processos ITIL. Mostrou-se que o OTRS possui boa aderência ao que é recomendado pelo OGC para os processos de Incident e Problem Management , tendo ainda a vantagem de ser uma ferramenta open-source . Como a implantação efetiva do ITIL é um processo demorado e que exige investimentos da organização, foi necessário limitar o escopo do trabalho. Uma vez definido o escopo e demais condições, foi necessário fazer uma análise da Eletronorte, exemplo de aplicação, caracterizando sua estrutura, tanto organizacional quando de suporte, identificando pontos onde fosse possível aplicar melhorias através do ITIL/OTRS. A partir de tal análise, informações adicionais foram levantadas para permitir a customização da ferramenta segundo o que prega o ITIL e de acordo com a realidade da empresa. Apesar das limitações presentes na abordagem ora tratada, estima-se que os benefícios mencionados anteriormente serão atingidos tão logo a ferramenta OTRS e a metodologia do ITIL sejam assimilados pela Eletronorte. Governança de TI no Brasil Ressalta-se também que o uso de frameworks para governança de TI já é uma realidade para as grandes empresas brasileiras. Em INFO (2007) é mostrado um estudo realizado pelo itSMF (Information Technology Service Management Forum ) Brasil, que aponta que 85% das grandes empresas brasileiras investem de alguma forma em Governança de TI, sendo o ITIL a iniciativa mais aplicada, com 33% desse total. Outro dado relevante é que 84% das empresas contratam consultorias especializadas para conduzir os projetos de governança.

Conclusão

69

A partir dos dados da pesquisa, conclui-se que a Governança de TI já é vista como fator estratégico para a grande maioria das empresas brasileiras de grande porte.

7.1. TRABALHOS FUTUROS Como o campo do ITSM é muito vasto, existem muitas possibilidades de expandir e melhorar o que foi apresentado neste trabalho. A seguir, serão listadas algumas de tais possibilidades.

7.1.1. Mais alinhamento com o ITIL De imediato é possível identificar que a implantação dos outros processos do ITIL, notavelmente Configuration e Change Management , poderia expandir ainda mais o leque de vantagens a serem auferidas pela organização. Conforme anteriormente elucidado, no contexto de Service Support do ITIL, incidentes e problemas freqüentemente estão relacionados a CI’s, que devem ser submetidos a um processo formal de modificação em caso de substituições, reparos, etc. A ferramenta OTRS, como mostrado, possui ótimo suporte aos processos de Gestão de Incidentes e Problemas, porém, não prevê a Gestão de Configuração e Mudança. Desenvolver pacotes de customização para contemplar também estes processos do ITIL constituiria significativo diferencial.

7.1.2. Aplicação em pequenas empresas Tradicionalmente o ITIL, bem como os outros frameworks para Governança de TI, tem direcionado seus esforços para grandes e médias empresas. Constitui assim um desafio adaptar a abordagem e metodologia oferecidas por eles para incluir também pequenas organizações. Há publicações no exterior tratando dessa questão, como Group (2006), mas nacionalmente o tema é pouco explorado.

7.1.3. Utilização de Técnicas Inteligentes (IA) Outra possibilidade de extensão é a utilização de sistemas inteligentes para a classificação e solução automatizada de incidentes. O uso de redes neurais para a detecção de padrões na ocorrência de incidentes se mostra promissor. O emprego de técnicas inteligentes poderia diminuir sensivelmente o tempo gasto pela equipe para atender solicitações mais comuns, para as quais já existem métodos comprovados e testados de

Conclusão

70

71

Referências

8. REFERÊNCIAS CARTLIDGE, Alison et al. Introductory Overview of ITIL V3. The IT Service Management Forum. Disponível em: http://www.itsmfi.org/files/itSMF_ITILV3_Intro_Overview.pdf. Acesso em: 24.04.2008. CENTRAL, ITIL. News and Information for ITIL. Disponível em: . Acesso em 22 de mai. 2008. CLAUSS, Christian. Beispielhafte Evaluierung der Anpassbarkeit von OTRS an Prozesse im IT Service Management am LRZ. Forgeschrittenenpraktikum. Institut für Informatik der LMU München, 2006. Disponível em: . Acesso em: 21 mar. 2008. CONSULTING, Pink Elephant. Pink Elephant ITIL v3 Foundation Training. Disponível em: . Acesso em 20 de mai. 2008. EIDE, Nils Einar et al. DIGIMIMIR: A Tool for Rapid Situation Analysis of Helpdesk and Support E-mail. Disponível em: . Acesso em 15 de jun. 2008. ELETRONORTE, Centrais Elétricas do Norte do Brasil S.A. Perfil e Estrutura da Eletronorte . Disponível em: . Acesso em 11 de mai. 2008. EXIN, Site Institucional. EXIN Exams . Disponível em: . Acesso em 20 de mai. 2008. GROUP, Info Tech Research. Adapting ITIL to Small and Mid-sized Enterprises. Whitepaper , 2006. Disponível em:

72

Referências

HÄRTL, Maximilian. Konzeption und Realisierung der technischen Unterstützung eines zentralen IT-Service-Desk mit OTRS an der TUM. Diplomarbeit. Institut für Informatik der LMU München, 2007. Disponível em: . Acesso em: 04 mai. 2008. INFO, Revista. Empresas aderem a modelos de gestão de TI. Reportagem publicada em 17/10/2007. Disponível em: . Acesso em 15 de jun. 2008. INSTITUTE, Service Desk. Service Desk and IT Support Excellence Awards. Disponível em: . Acesso em 09 de mai. 2008. ISACA, Information Systems Audit and Control Association. COBIT 4.1 Executive Summary. Disponível em: . Acesso em: 24/06/2008. MASTERS, Consulting. Fragebogen zur Selbsteinschätzung Ihrer ITOrganisation. Disponível em: . Acesso em 25 de mai. 2008. MINNESOTA, University of. Preparing to Implement IT Service Management and the ITIL Framework. A Preflight Checklist . Disponível em: . Acesso em 18 de mai. 2008. NUSEIBEH, Bashar et al. Requirements Engineering: A Roadmap. Imperial College Departament of Computing. Disponível em : . Acesso em: 04.05.2008. OGC, Office of Government Commerce. ITIL v2 Service Support Band. Stationery Office BO, ISBN 0113300158, 12ª ed., 2005.

73

Referências

PFLEGER, Bernhard. Evaluation von Werkzeugen zur Unterstüzung der ITIL Service Management Prozesse. Diplomarbeit. Institut für Informatik der LMU München, 2005. Disponível em: . Acesso em: 28 mai. 2008. PRESSMAN, Roger S. Software Engineering: A Practitioner’s Approach. McGraw-Hill Science, 6ª ed, 2004. SPAFFORD, George. The Benefits of Standard IT Governance Frameworks. ITSM Watch, Insight on IT Service Management , 2003. Disponível em: < http://www.itsmwatch.com/itil/article.php/2195051>. Acesso em: 23/04/2008.

74

Apêndices

APÊNDICES

75

Apêndices

APÊNDICE I ARQUITETURA DA FERRAMENTA OTRS A arquitetura da ferramenta OTRS é mostrada na Figura 1. O estilo arquitetural empregado pelo OTRS é o modelo em camadas. De acordo com Pressman (2004), este modelo é caracterizado pela organização hierárquica, em que cada camada fornece serviços para a camada acima, servindo como cliente para a camada abaixo. O sistema possui quatro camadas de software : •

•

•

•

Database Layer – responsável pela interação direta com o banco de dados, camada de persistência. Core Modules – são os módulos responsáveis pela lógica de negócio do sistema, que gerenciam os tickets, clientes, workflows associados, etc. Web Front-end Modules – são os componentes responsáveis pela interação com o usuário na Web, geração de formulários, sistema de templates . Web Front-end Handles – Possuem função de encapsulamento, agrupando as funcionalidades descritas.

Os outros componentes integrantes do sistema são naturalmente a base de dados, cujo projeto pode ser visto no ANEXO I. Além disso, como o OTRS funciona com uma interface através do e-mail, existe uma estrutura especializada em tratar esta interação, o CMD Frontend , que por sua vez se comunica com os Core Modules necessários. Observa-se que o sistema possui fundamentalmente três atores, o agente, o cliente e o administrador. Estes se comunicam com o sistema OTRS através tanto através e-mail, quando através da interface web adequada. Característica muito interessante possibilitada pela arquitetura em camadas do OTRS é possível escrever a adaptar sem maiores dificuldades módulos escritos pelo usuário, bem como tabelas no banco de dados, que serão manipuladas pela Database Layer . O fato de a linguagem de programação ser Perl também é um fator positivo, já que ela é uma linguagem bastante flexível e possui comunidade de desenvolvedores bastante

76

Apêndices

Figura 1. Arquitetura do OTRS 2.2. Fonte:OGC (2005)

77

Apêndices

APÊNDICE II INSTRUÇÃO TÉCNICA DE INSTALAÇÃO DO OTRS EM SERVIDORES WINDOWS

INSTALAÇÃO DO OPEN TICKET REQUEST SYSTEM EM SERVIDORES WINDOWS

LABORATÓRIO CENTRAL

SUMÁRIO 1. OBJETIVO 2. CAMPO DE APLICAÇÃO 3. REFERÊNCIAS 5. INTRODUÇÃO 6. SOFTWARES NECESSÁRIOS 7. INSTALAÇÃO AUTOMÁTICA 8. INSTALAÇÃO MANUAL 9. PRIMEIROS PASSOS 10. INSTALAÇÃO CRONW 1. OBJETIVO Definir os passos necessários para a instalação da ferramenta OTRS (Open Ticket Request System), que gerencia problema que ocorrem com os softwares e que também pode atender solicitações de naturezas diversas, em sistemas Windows . 2. CAMPO DE APLICAÇÃO Esta Instrução Técnica aplica-se aos colaboradores envolvidos na área de Tecnologia da Informação do Centro de Tecnologia da Eletronorte. 3. REFERÊNCIAS Site OTRS – http://otrs.org/ Manual OTRS – http://doc.otrs.org/2.2/en/html/ Web Site CRONw – http://CRONw.sourceforge.net/ Web site Perl – http://www.perl.com/ MySQL Site – http://www.mysql.org/ Apache 2 – http://www.apache.org/ 4. PRÉ-REQUISITOS Um computador com o sistema operacional Windows Server 2000 ou superior e os componentes Apache 2.x, MySQL 5.x, Perl 5.8, CRONw ou superior instalados. 5. INTRODUÇÃO O OTRS, que é a abreviação para Open Ticket Request System , é um pacote de software para o rastreamento de solicitações que uma empresa, organização ou instituição pode utilizar para atribuir bilhetes para requisições feitas, facilitando assim grandemente o tratamento de chamadas de suporte e outros tráfegos gerados por clientes. Como outros Trouble Ticket Systems , o OTRS faz muito mais que simplesmente lidar com caixas de e-mail. Para cada ticket existe um histórico, mostrando o que aconteceu ao ticket durante o seu ciclo de vida. O OTRS agrupa múltiplas requisições para o mesmo



ordenando e respondendo-as. O OTRS é altamente escalável, capaz de tratar milhares de tickets por dia e um número praticamente ilimitado de agentes. 6. SOFTWARES NECESSÁRIOS Para poder funcionar de maneira adequada, um servidor OTRS deve dispor dos seguintes softwares instalados e configurados: 1) Servidor Web Apache 2.x; 2) Linguagem de scripts Perl 5.8 ou superior 3) Servidor de banco de dados MySQL 5.x Agendador de tarefas para Windows CRONw 2.0 7. INSTALAÇÃO AUTOMÁTICA Se o OTRS estiver sendo instalado numa instalação nova, em que nenhum dos softwares acima descritos como dependência não estejam instalador, é possível fazer uso do instalador disponibilizado pelo site do OTRS. Basta fazer o download do installer da versão mais atual a partir do site da ferramenta OTRS em http://otrs.org/ e seguir as instruções do assistente. Tão logo ela seja finalizada, você pode pular para a seção 9, “Primeiros passos no OTRS”. Ele instalará e configurará todos os componentes necessário para a execução do OTRS. 8. INSTALAÇÃO MANUAL Quando o OTRS for instalado num sistema que já em produção, no qual alguma das ferramentas anteriormente listadas já se encontrem instaladas, é necessário proceder à instalação manual de todos os componentes necessários de forma individual. 8.1. OTRS O primeiro passo é obter a última versão da ferramenta OTRS no site http://otrs.org/ . O pacote é do tipo tar.gz, descompacte o conteúdo para o diretório c:\otrs. Um comando dir gera a seguinte saída:



8.2. Perl Em seguida, a ferramenta Perl deve ser instalada no sistema. Ela pode ser obtida no endereço \\elncpasrv05. É possível obtê-la também, juntamente com os módulos do OTRS, no endereço http://cvs.otrs.org. Trata-se de um uma pasta contendo os arquivos necessários do Perl, bem como os módulos que devem ser instalados para rodar o OTRS. Para iniciar a instalação, basta executar o arquivo em lote chamado Installer.bat. Um terminal de comando interativo será iniciado. Quando você for perguntado pela pasta de instalação, digite c:\Perl. Após a instalação do Perl, verifique se a variável de ambiente Path foi configurada corretamente. Atente para o fato de que o caminho c:\Perl\bin deve aparecer no final da string da variável de ambiente Path. Se não estiver proceda à atualização da variável de ambiente Path. Uma vez terminada a instalação, será necessário instalar os pacotes Perl necessários para que o OTRS rode adequadamente. São eles: 1) Convert-ASN1.ppd 2) DBD-mysql.ppd 3) GD.ppd 4) GDTextUtil.ppd 5) GDGraph.ppd 6) mod_perl-2.2.ppd 7) Net-IP.ppd 8) Net-DNS.ppd 9) PDF-API2.ppd 10) perl-ldap.ppd 11) TimeDate.ppd

Cada pacote deve ser instalado separadamente. Esses pacotes estão disponíveis no diretório /packages, presente na pasta a partir da qual o Perl foi instalado. Acesse esse diretório com o comando cd e para cada pacote execute o seguinte comando: > ppm install

Para testar se todos os pacotes foram corretamente instalados, é possível utilizar um script presente na pasta de instalação do OTRS, chamado otrs.Checkmodules.pl. Na pasta c:\otrs\bin\, digite o seguinte comando: > perl otrs.Checkmodules.pl

A tela de saída, deve ser semelhante a essa:



8.3. Servidor Apache 2 O próximo passo é prosseguir à instalação do servidor Web que irá disponibilizar a ferramenta OTRS para que ela seja acessada por seus usuários. Para instalar o servidor, basta seguir as instruções do assistente de instalação do Apache 2. A única recomendação é que é que a pasta de instalação do Apache seja c:\Apache2. É importante que as pastas que contém os componentes do não possuam espaços no nome, para evitar inconsistências. Uma vez instalado o Apache, precisamos configurá-lo para reconhecer o Perl e também o OTRS. Para isso, na pasta conf do diretório do apache, crie o arquivo otrs.conf e insira nele o seguinte conteúdo:



LoadFile "C:\Perl\bin\perl58.dll" LoadModule perl_module modules/mod_perl.so # agent, admin and customer frontend ScriptAlias /otrs/ "C:/otrs/bin/cgi-bin/" Alias /otrs-web/ "C:/otrs/var/httpd/htdocs/" # load all otrs modules Perlrequire "C:/otrs/scripts/apache2-perl-startup.pl" # Apache::Reload - Reload Perl Modules when Changed on Disk PerlModule PerlModule Apache2::Reload PerlInitHandler Apache2::Reload PerlModule Apache2::RequestRec # set mod_perl2 options #DirectoryIndex index.pl ErrorDocument 404 /otrs/customer.pl ErrorDocument 403 /otrs/index.pl SetHandler perl-script PerlResponseHandler ModPerl::Registry PerlOptions +ParseHeaders PerlOptions +SetupEnv Options +ExecCGI Order allow,deny Allow from all # directory settings AllowOverride None Options +ExecCGI -Includes Order allow,deny Allow from all AllowOverride None Order allow,deny Allow from all AllowOverride None Order allow,deny Allow from all

# Manual - remember to read it Alias /otrs-manual "C:/otrs/doc/manual" Options +Indexes # MaxRequestsPerChild (so no apache child will be to big!) MaxRequestsPerChild 400

Observe que no trecho acima assumimos os caminhos padrão, conforme aqui mostrados. Caso um caminho diferente tenha sido utilizado, é necessário fazer as alterações pertinentes.



#OTRS Settings Include conf/otrs.conf

Para finalizar a configuração do Apache, copie para a pasta modules do Apache o arquivo mod_perl.so (que pode ser encontrado no pacote de instalação do OTRS). Isso fará com que o OTRS seja executado de forma mais rápida. Você ainda não deve reiniciar o Apache. Esse operação resultará em erro, porque o OTRS ainda não foi configurado. Detalhes podem ser vistos mais adiante na seção 8.5. 8.4. Banco de Dados MySQL O OTRS pode ser utilizado em conjunto com uma vasta gama de servidores de bancos de dados, como PostgreSQL, Oracle, SQL Server, entre outros. Nesta IT , optou-se por utilizar o MySQL porque com ele é possível fazer uso da instalação automatizada OTRS, conforme se verá adiante. Para instalar o MySQL, basta seguir os passos propostos pelo assistente, tendo o cuidado de marcar a opção de permitir a conexão pela rede e instalar o MySQL como um serviço. Após a instalação do MySQL, você deverá criar o usuário otrs no banco de dados e lhe dar permissões totais no banco otrs, que será criado a seguir pelo instalador da ferramenta OTRS. Para isso, acesse o prompt do MySQL, digitando o seguinte comando: > mysql –u root -p

Você deve a seguir fornecer a senha do usuário instalação do MySQL.

root,

tal como indicada na

No prompt, digite os seguintes comandos, um a um: mysql> CREATE USER otrs WITH PASSWORD ‘otrs’; mysql> GRANT ALL ON otrs.* TO otrs@localhost IDENTIFIED BY ‘otrs’; mysql> FLUSH PRIVILEGES;

O primeiro comando cria o usuário otrs. No segundo, lhe conferimos todas as permissões na base otrs, quando ele estiver acessando a partir do próprio servidor e tiver o password especificado. Observe que estas configurações podem ser modificadas, no caso, por exemplo, de o servidor de banco de dados estar numa outra máquina. A última linha diz ao banco para aplicar as alterações especificadas. 8.5. Configuração do OTRS



configuração do Apache otrs.conf e serve para pré-carregar todos os módulos Perl necessário para rodar o OTRS, aumentando o desempenho. Localize a seção: # set otrs lib path! use lib "/opt/otrs/"; use lib "/opt/otrs/Kernel/cpan-lib";

Agora insira o caminho correto para o OTRS: # set otrs lib path! use lib "c:\\otrs\\"; use lib " c:\\otrs\\Kernel\\cpan-lib";

O próximo passo é criar o arquivo Config.pm na pasta Kernel da instalação do OTRS. Para isso, basta fazer uma cópia do arquivo Config.pm.dist e remover a extensão .dist. Este arquivo contém as configurações básicas para o OTRS, como a forma de acesso ao banco de dados, log, etc. As seções do arquivo que devem ser modificadas são listadas a seguir: # ---------------------------------------------------- # # database settings # # ---------------------------------------------------- # # DatabaseHost # (The database host.) $Self->{DatabaseHost} = 'localhost'; # Database # (The database name.) $Self->{Database} = 'otrs'; # DatabaseUser # (The database user.) $Self->{DatabaseUser} = 'otrs'; # DatabasePw # (The password of database user. You also can use bin/CryptPassword.pl # for crypted passwords.) $Self->{DatabasePw} = 'some-pass'; # DatabaseDSN # (The database DSN for MySQL ==> more: "man DBD::mysql") $Self->{DatabaseDSN} = "DBI:mysql:database=$Self->{Database};host=$Self>{DatabaseHost};";

Insira os dados de acesso ao banco, como o servidor em que ele está instalado, o banco de dados e a senha. Logo após a seção de comunicação com o banco de dados, é necessário que o arquivo contenha as seguintes linhas: # ---------------------------------------------------- # # fs root directory # ---------------------------------------------------- # $Self->{Home} = 'C:/otrs/';



Neste ponto configura-se a pasta raiz do OTRS e a forma como ele gerará os logs do sistema. Agora já é possível reiniciar o Apache 2. 9. PRIMEIROS PASSOS Com a finalização da instalação e configuração dos componentes necessários para instalar o OTRS, é necessário gerar as tabelas do banco de dados. Esse processo, no entanto, ao se utilizar o banco de dados MySQL é automatizado. Acesse o seguinte endereço: http://localhost/otrs/installer.pl. O endereço irá iniciar o instalador Web do OTRS. A tela inicial é mostrada abaixo:

É necessário concordar com os termos dispostos pela licença do OTRS. Em seguida, tem-se a seguinte tela:



Este passo solicita algumas informações para proceder à instalação do banco de dados, como o host que abriga o banco e a senha de root. Logo em seguida, pede que se indique qual o nome do usuário que o OTRS utilizará para acessar o banco e o nome da base de dados. Se tudo correr bem, a seguinte tela será exibida:



Os erros que acontecem neste ponto estão geralmente associados a permissões no banco de dados. Caso seja necessário, confira manualmente as permissões necessárias utilizando o comando GRANT do MySQL. Para maiores informações, acesse o manual do MySQL disponível no seu Web site (vide referências).



Neste ponto, o instalador solicita os dados finais, necessários para encerrar o processo. FQDN (Fully Qualified Domain Name) equivale ao endereço no qual o servidor está sendo instalado. Caso ele disponha de um DNS, utilize-o aqui. Caso contrário, utilize seu endereço IP. Mude a forma de log para File-LogModule e defina o caminho do arquivo de log para c:\otrs\otrs.log. Defina também o idioma padrão para português do Brasil. A próxima tela finaliza o processo de instalação e configuração.



Parabéns! O OTRS foi instalado com sucesso no servidor! ☺ O serviço não está acabado, porém. É necessário ainda configurar o CRONw, software que periodicamente roda os scripts necessários para que o OTRS rode, como por exemplo o scritp que checa se há novos e-mails na caixa de entrada que ainda não foram tratados pelo OTRS. 10. INSTALAÇÃO CRONW O OTRS possui certos scripts que devem ser executado periodicamente, de forma automática. Em sistema baseados em Unix, o software que cumpre este papel é o utilitário cron, que executa rotinas segundo configurações de tempo pré-definidas. O CRONw é a versão para Windows do aplicativo citado. O CRONw 2.0 pode ser obtido a partir do site da ferramenta (vide referências). Para instalá-lo, primeiro descompacte a pasta do CRONw para a unidade C:\. Acesse a pasta do CRONw, e no prompt de comando digite a seguinte linha:



Caso a execução do comando acima gere algum erro, verifique o arquivo installer.pl e remova -noforce –follow da linha 48, se houver. Execute novamente o comando. Esse comando irá instalar os módulos Perl necessários para que a ferramenta seja executada. São eles: 1) 2) 3) 4) 5) 6) 7) 8) 9) 10)

Win32-Daemon.ppd Number-Compare.ppd Attribute-Handlers.ppd Text-Glob.ppd File-Find-Rule.ppd Date-Manip.ppd Params-Validate.ppd Log-Dispatch.ppd Log-Log4perl.ppd Log-Dispatch-FileRotate.ppd

Em seguida, é necessário instalar o CRONw como um serviço do sistema. Para isso, execute o seguinte comando: > perl cronHelper.pl --install

Caso haja algum erro, verifique se todos os módulos foram instalados corretamente. (Verifique a listagem anterior). O comando ppm install pode ser usado para instalar manualmente algum pacote que esteja eventualmente faltando. Os pacotes encontram-se na pasta modules da instalação do CRONw. O próximo passo é criar o arquivo que contém as instruções a serem executadas pelo CRONw. Para isso, na pasta de instalação do CRONw crie o arquivo crontab.txt e insira o conteúdo especificado no ANEXO I desta IT . Observe novamente que os caminhos utilizados aqui referem-se aos que foram adotadas durante esta IT . Caso outros caminhos tenham sido aplicados, fazem-se necessárias as devidas alterações. Uma vez definido o arquivo do CRONw, já podemos iniciar o serviço do Windows com o comando: > net start CRON

Caso haja algum erro ao iniciar o serviço, verifique o log do CRONw, criado na raiz do seu diretório de instalação. Os erros que acontecem são geralmente devidos a pacotes não corretamente instalados ou erros no arquivo crontab.txt.

INSTALAÇÃO INSTALAÇÃO DO OPEN TICKET REQUEST SYSTEM EM SERVIDORES WINDOWS


A instalação do OTRS foi concluída! Acesse o endereço http://localhost/otrs/index.pl e entre com o usuário root@localhost, senha: root. Antes de ele ser utilizado, porém, é necessário configurar o envio e recebimento de e-mails. Vide procedimento descrito na documentação disponível nas referências citadas anteriormente. ANEXO I Listagem do arquivo crontab.txt # -# cron/aaa_base - base crontab package # Copyright (C) 2001-2006 OTRS GmbH, http://otrs.org/ # -# $Id: aaa_base.dist,v 1.4 2006/10/20 16:46:14 mh Exp $ # -# This software comes with ABSOLUTELY NO WARRANTY. For details, see # the enclosed file COPYING for license information (GPL). If you # did not receive this file, see http://www.gnu.org/licenses/gpl.txt. # --

# Who gets the cron emails? MAILTO="root@localhost"

# -# cron/generic_agent - GenericAgent.pl cron of the OTRS # Copyright (C) 2001-2006 OTRS GmbH, http://otrs.org/ # -# $Id: generic_agent.dist,v 1.10 2006/10/20 16:46:14 mh Exp $ # -# This software comes with ABSOLUTELY NO WARRANTY. For details, see # the enclosed file COPYING for license information (GPL). If you # did not receive this file, see http://www.gnu.org/licenses/gpl.txt. # --

# start generic agent every 20 minutes */20 * * * *

c:/Perl/bin/per l.exe c:/otrs/bin/Gen ericAgent.pl

# example to execute GenericAgent.pl on 23:00 with # Kernel::Config::GenericAgentMove job file #0

23

*

*

*

"Kernel::Config::GenericAgentMove"

# --

c:/Perl/bin/perl.exe

c:/otrs/bin/GenericAgent.pl

-c



# This software comes with ABSOLUTELY NO WARRANTY. For details, see # the enclosed file COPYING for license information (GPL). If you # did not receive this file, see http://www.gnu.org/licenses/gpl.txt. # -# start generic agent every 10 minutes */10 * * * *

c:/Perl/bin/per l.exe c:/otrs/bin/Gen ericAgent.pl -c db

# -# cron/pending_jobs - pending_jobs cron of the OTRS # Copyright (C) 2001-2006 OTRS GmbH, http://otrs.org/ # -# $Id: pending_jobs.dist,v 1.9 2006/10/20 16:46:14 mh Exp $ # -# This software comes with ABSOLUTELY NO WARRANTY. For details, see # the enclosed file COPYING for license information (GPL). If you # did not receive this file, see http://www.gnu.org/licenses/gpl.txt. # -# check every 120 min the pending jobs 45 */2 * * *

c:/Perl/bin/per l.exe c:/otrs/bin/Pen dingJobs.pl

# -# cron/postmaster - postmaster cron of the OTRS # Copyright (C) 2001-2006 OTRS GmbH, http://otrs.org/ # -# $Id: postmaster.dist,v 1.7 2006/10/20 16:46:14 mh Exp $ # -# This software comes with ABSOLUTELY NO WARRANTY. For details, see # the enclosed file COPYING for license information (GPL). If you # did not receive this file, see http://www.gnu.org/licenses/gpl.txt. # -# check daily the spool directory of OTRS #10

0

*

*

*

*

[

-e

/etc/init.d/otrs

]

&&

/etc/init.d/otrs

/etc/rc.d/init.d/otrs ] && /etc/rc.d/init.d/otrs cleanup 10 0 * * *

c:/Perl/bin/perl.exe c:/Perl/bin/pe rl.exe c:/otrs/bin/otrs.cleanup c:/otrs/bin/ot rs.cleanup

# -# cron/postmaster_pop3 - postmaster_pop3 cron of the OTRS # Copyright (C) 2001-2006 OTRS GmbH, http://otrs.org/ # -# $Id: postmaster_pop3.dist,v 1.8 2006/10/20 16:46:14 mh Exp $ # -# This software comes with ABSOLUTELY NO WARRANTY. For details, see # the enclosed file COPYING for license information (GPL). If you # did not receive this file, see http://www.gnu.org/licenses/gpl.txt. # -# fetch emails every 10 minutes

cleanup

;

[

-e



# -# $Id: rebuild_ticket _index.dist,v 1.7 2006/10/20 16:46:14 mh Exp $ _index.dist,v # -# This software comes with ABSOLUTELY NO WARRANTY. For details, see # the enclosed file COPYING for license information (GPL). If you # did not receive this file, see http://www.gnu.org/licenses/gpl.txt. # -# just every day 01 01 * * * c:/Perl/bin/perl.exe c:/otrs/bin/RebuildTicketIndex.pl # -# cron/session - delete old session ids of the OTRS # Copyright (C) 2001-2006 OTRS GmbH, http://otrs.org/ # -# $Id: session.dist,v 1.9 2006/10/20 16:46:14 mh Exp $ # -# This software comes with ABSOLUTELY NO WARRANTY. For details, see # the enclosed file COPYING for license information (GPL). If you # did not receive this file, see http://www.gnu.org/licenses/gpl.txt. # -# delete every 120 minutes old/idle session ids 55 */2 * * *

c:/Perl/bin/per l.exe c:/otrs/bin/Del eteSessionIDs.pl --expired

# -# cron/unlock - unlock old locked ticket of the OTRS # Copyright (C) 2001-2006 OTRS GmbH, http://otrs.org/ # -# $Id: unlock.dist,v 1.8 2006/10/20 16:46:14 mh Exp $ # -# This software comes with ABSOLUTELY NO WARRANTY. For details, see # the enclosed file COPYING for license information (GPL). If you # did not receive this file, see http://www.gnu.org/licenses/gpl.txt. # -# unlock every hour old locked tickets 35 * * * *

c:/Perl/bin/perl.exe c:/Perl/bin/pe rl.exe c:/otrs/bin/UnlockTickets.pl c:/otrs/bin/Un lockTickets.pl --timeout

94

Apêndices

APÊNDICE III CÓDIGO-FONTE C# DA INTERFACE DO SERVICE DESK E ARQUIVO DE DADOS XML

using using using using using using using using using using using using using using

System; System.Configuration; System.Data; System.Web; System.Web.Security; System.Web.UI; System.Web.UI.HtmlControls; System.Web.UI.WebControls; System.Web.UI.WebControls.WebParts; MySql.Data.MySqlClient; System.Collections.Generic; System.Net.Mail; System.Net; Lacen;

public partial class _Default : BasePage { MySqlConnection conn; protected void Page_Load(object sender, EventArgs e) { if (!IsPostBack) { LbService.DataSource = GetServices(); LbService.DataBind(); DdPrioridade.SelectedValue = "3 normal"; DdProcesso.SelectedValue = "TIMI"; } } protected List GetServices() { List ServiceData = GetServiceData(); List Services = new List(); foreach (string Service in ServiceData) { if (!Service.Contains("::") && Service != "Lixo") { Services.Add(Service.Split(new string[]{"::"},StringSplitOptions.None)[0]); } } return Services; }

95

Apêndices

foreach (string Service in ServiceData) { if (Service.Contains(ServiceName + "::")) { SubServices.Add(Service.Split(new string[] { "::" }, StringSplitOptions.None)[1]); } } if (SubServices.Count > 0) SubServices.Add("Outros"); return SubServices; } protected List GetServiceData() { List ServicesData = new List(); try { conn = new MySqlConnection(ConfigurationManager.AppSettings["ConnectionString"]); conn.Open(); MySqlDataReader reader = null; MySqlCommand cmd = new MySqlCommand("SELECT name FROM service WHERE valid_id = 1 ORDER BY name", conn); try { reader = cmd.ExecuteReader(); ServicesData.Clear(); while (reader.Read()) { ServicesData.Add((reader.GetString(0))); } } catch (MySqlException ex) { LbMsg.Text = ex.Message; return null; } finally { if (reader != null) reader.Close(); conn.Close(); }

} catch (MySqlException ex) { LbMsg.Text = ex.Message; } return ServicesData;

96

Apêndices

{ if (IsValid) { string RequestSubject = ""; if (LbSubService.SelectedItem != null && LbSubService.SelectedItem.Text != "Outros") { RequestSubject = LbSubService.SelectedItem.Text; } else { RequestSubject = TxtAssunto.Text; } MailMessage MyMailMessage = new System.Net.Mail.MailMessage(TxtNome.Text+"<"+TxtEmail.Text+">", ConfigurationManager.AppSettings["To"], RequestSubject,TxtIncidente.Text); MyMailMessage.IsBodyHtml = false; string Service = ""; if (LbSubService.SelectedItem != null && LbSubService.SelectedItem.Text != "Outros" && LbService.SelectedItem != null && LbService.SelectedItem.Text != "Outros") { Service = LbService.SelectedItem.Text+"::"+LbSubService.SelectedItem.Text; } else if (LbService.SelectedItem != null && LbService.SelectedItem.Text != "Outros") { Service = LbService.SelectedItem.Text; } MyMailMessage.BodyEncoding = System.Text.Encoding.UTF8; if (Service != "") { MyMailMessage.Headers.Add("X-OTRS-Service",Service); } MyMailMessage.Headers.Add("X-OTRS-TicketKey1", "Processo"); MyMailMessage.Headers.Add("X-OTRS-TicketValue1", DdProcesso.SelectedItem.Text); MyMailMessage.Headers.Add("X-OTRS-Priority", DdPrioridade.SelectedValue); MyMailMessage.Headers.Add("X-OTRS-Queue", ConfigurationManager.AppSettings["Queue"]);

NetworkCredential mailAuthentication = new NetworkCredential(ConfigurationManager.AppSettings["SmtpUser"], ConfigurationManager.AppSettings["SmtpPassword"]); System.Net.Mail.SmtpClient mailClient = new System.Net.Mail.SmtpClient(ConfigurationManager.AppSettings["SmtpServer"],int.Parse (ConfigurationManager.AppSettings["SmtpPort"])); //Enable SSL

97

Apêndices

mailClient.UseDefaultCredentials = false; mailClient.Credentials = mailAuthentication; mailClient.Send(MyMailMessage); //Clear fields PnEspecificar.Visible = false; TxtIncidente.Text = ""; DdPrioridade.SelectedValue = "3 normal"; string Cliente = ""; try { Cliente = TxtNome.Text.Split(' ')[0]; } catch { Cliente = TxtNome.Text; } TxtNome.Text = ""; TxtEmail.Text = ""; DdProcesso.SelectedValue = "TIMI"; System.Threading.Thread.Sleep(1000);

LbMsg.Text = "Caro(a) "+ Cliente +", sua solicitação foi enviada com sucesso!
O Help Desk ELN entrará em contato brevemente para solucionar seu problema."; } } catch (Exception ex) { LbMsg.Text = ex.Message; } } protected void LbService_SelectedIndexChanged(object sender, EventArgs e) { if (LbService.SelectedItem.Text == "Outros") { PnEspecificar.Visible = true; LbSubService.Visible = false; } else { List SubServices = GetSubServices(LbService.SelectedItem.Text); if (SubServices.Count > 0) { LbSubService.DataSource = SubServices; LbSubService.DataBind(); System.Threading.Thread.Sleep(1000); PnEspecificar.Visible = false; LbSubService.Visible = true; } else { LbSubService.Visible = false; } }

98

Apêndices

PnEspecificar.Visible = true; } else { PnEspecificar.Visible = false; } } }

****

OTRS UFPA

Recommend Documents