Como implementar o ITIL em pequenas e médias empresas – Parte 1

Salve, salve, pessoal do Cooperati, hoje vou começar um

série de posts sobre ITIL, mas voltado para pequenas e

médias empresas, mas não no Beaba de sempre,  e sim como

utilizar ela na prática, coisa que é dificil de se enxergar

quando faz algum curso ou leitura sobre o assunto, as coisas

ficam muito amplas, nesse primeiro post falarei sobre como

definir o nível de maturidade que quer chegar dando alguns

exemplos para isso, então vamos lá.

Como sabemos, gerenciar os serviços de TI não é uma tarefa

simples, para tentar facilitar essas atividades foram criados

vários frameworks de gerenciamento, porém um dos mais

utilizados e divulgados no momento é o ITIL que se encontra

em sua terceira versão, contendo muitos conceitos e técnicas

para realizar as “Melhores Práticas” em serviços de TI.

Mas uma das grandes dificuldades para a sua implementação

é a grande variedade de conceitos técnicos que ela possui e a

não explicação de como empregá-los. Sua implementação em

pequenas e até mesmo em médias empresas não é muito

convencional, pois muitas dessas empresas não tem a

estrutura para implementá-los, outro problema é que ela só

diz o que deve ser feito, exatamente como um guia e não

como faze-lo, então muitos ficam perdidos na sua

implementação.

Mas mesmo que os argumentos citados sejam verdadeiros

não podem ser uma barreira para a sua implementação e

digo o porque, o ITIL foi desenvolvido para dar uma rota as

melhores práticas, mas ele pode ser adaptável a sua

estrutura, pois se ele for engessado, sua implementação

realmente será muito difícil e outra se você usar um modulo,

ou função que esteja escrito nele, você automaticamente

estará usando o mesmo.

Outra coisa, o ITIL contém níveis de maturidade, então se

você estiver em um nível que condiz com a sua realidade,

você terá implementado o ITIL na sua empresa, não precisa

estar no nível mais alto em tudo, pois sabemos que para

chegar a esse nível, muitas coisas além do mundo da Ti

precisam acontecer e também não precisa implementar todos

os módulos pois, como já disse, nem toda empresa tem

estrutura para todos. Mas você deve estar perguntando-se:

“Qual seria o nível que condiz com a minha realidade?”, para

responder a essa pergunta vamos aos níveis em si:

 1º – Inexistente: Preciso dizer algo? Um exemplo simples

para esse nível é: Um gerente de uma empresa pergunta ao

funcionário da TI: “Quais são os maiores problemas que

possuo na minha empresa em relação a TI?” e ele responde:

“Faço a mínima ideia”.

 2º – Inicial: Existe uma noção do que acontece na empresa,

mas as tarefas realizadas são informais e bem

desorganizadas, geralmente cada pessoa do setor de TI sabe

algo da estrutura, mas não é documentado. Continuando o

nosso exemplo, o gerente faz a mesma pergunta e o

profissional responde: “Bom, EU atendo muitos chamados de

mau uso do software mas não sei porque isso acontece e não

sei te dizer se é o principal, pois não sigo um padrão, vou

tentando adivinhar na hora que vou resolver.”

3º – Repetitivo: Esse nível existe uma ampliação do que

acontece na empresa por parte da TI, a informação ainda fica

centralizada em uma única pessoa, porém existem

procedimentos padrões para realização das tarefas, mas

todos reativos o problema ocorre vai lá é soluciona.

Continuando a linha dos nossos exemplos, o gerente faz de

novo a mesma pergunta e o profissional de Ti responde

“Bom, EU atendo muitos chamados de mau uso do software,

e sei disso pois sigo uma linha de raciocínio que desenvolvi

de tanto atender esses chamados, mas não sei te dizer

porque isso acontece, só vou lá e resolvo.” E o gerente faz

outra pergunta “Os outros sabem lidar com esse problema?”

e o profissional responde “Não sei, provavelmente não,

desenvolvi essa técnica sozinho e ainda não passei para

ninguém.”

Vamos dar uma pausa aqui, antes de continuar, como

podemos observar os níveis citados acima, não são níveis

aceitáveis em qualquer tipo de empresa, pois se caso o

funcionário, usado no exemplo acima, sair da empresa, todo o

processo que ele criou, será perdido e a empresa terá que

criá-lo novamente. A partir de agora os níveis já são

aceitáveis dependendo do nível da empresa.

4º – Definido: Esse nível os processos são documentados e

todos os participantes do processo são avisados das

mudanças e quando depararem com alguma anomalia no

processo pode detectar e consultar a documentação do

mesmo, além de poder evoluí-lo com alguma descoberta feita

que possa melhorar o processo, além de tentarem evitar que

o problema aconteça: Seguindo o raciocínio do nosso

exemplo o gerente faz a pergunta “Quais são os maiores

problemas que possuo na minha empresa em relação a TI?” e

o profissional de Ti responde: “Bom, segundo a nossa

documentação e comunicação interna, o maior problema é o

mau uso do software, pois recebemos muitos chamados dele

aqui, como sabemos disso já temos um padrão definido para

ele e tentamos evitá-lo realizando as tarefas preventivas”, e o

gerente faz nova pergunta “Você sabe porque isso acontece?”

e o profissional responde “Infelizmente não temos essa

informação”

5º – Gerenciado: Nesse nível todos os processos são

gerenciados e medidos, com isso os relatórios são mais

elaborados e a detecção de erros são mais fácil de encontrar,

o processo fica gerenciável, mas para tornar isso possível,

toda uma estrutura deve ser construída e atingir esse nível

não é fácil. Dando prosseguimento ao exemplo que estamos

vendo a resposta dada pelo profissional de TI para a

pergunta do gerente é a seguinte: “Bom, segundo a nossa

documentação e comunicação interna, o maior problema é o

mau uso do software, pois recebemos muitos chamados dele

aqui, como sabemos disso já temos um padrão definido para

ele e medindo o índice de chamadas verificamos que a

grande causa disso é devido a um mau treinamento no

software, pois as pessoas não estão usando-o da maneira

correta”.

6º – Otimizado: Nesse nível tudo é executado usando as

melhores práticas e com um adicional, o processo sempre

está evoluindo, segue tipo o dito popular “Nada não é tão

bom que não possa melhorar”. Seguindo a linha do nosso

exemplo, em vez do gerente vir até o profissional, o processo

é inverso é o profissional que vai até o gerente e ainda

emitindo um relatório onde está o problema do mau uso do

software e dizendo a ele que para melhorar isso a empresa

deve investir no treinamento do pessoal para melhorar a

produtividade.

Sentiram a diferença entre os níveis? Como podemos ver

cada empresa, pelo seu estilo, deve ter um nível que lhe

atenda. Na minha visão uma pequena empresa tem que ter

como meta inicial o nível Definido, pois quem trabalha nesse

segmento sabe que os recursos são escassos e geralmente

não se tem uma equipe ideal para cuidar desse setor e um

funcionário pode desempenhar várias funções, desde nível de

usuário a servidor.

Então se ela tem os processos definidos e documentados as

tarefas ficam até mais simples, pois permite passar para o

nível Gerenciado mais facilmente, apesar de que sem dar ao

departamento de TI as ferramentas necessárias, tanto de

maquinário como de pessoal, chegar ao novo nível é difícil.

Mas tendo um nível Definido bem executado já é uma

vantagem, pois evita o desgaste de troca de funcionário que é

comum nelas, pois o treinamento do novo torna-se mais fácil.

Para uma empresa de médio porte, o nível aceitável já passa

a ser o gerenciado, pois nesse tipo de empresa, a empresa já

tem uma certa dependência da TI e se os processos não estão

correndo certinho, as chances de um pequeno problema

tornar-se grande são enormes, um exemplo disso é se um

processo de restauração de um sistema critico para a

empresa não tiver documentado e sendo feito de acordo com

os padrões da empresa, o prejuízo financeiro será

incalculável (se for executado erroneamente), além do mais

os funcionários de TI tem sempre que estarem monitorando

os processos para ver se eles estão em níveis satisfatórios

para poder remediar o problema sem ele ter que acontecer.

E para as grandes empresas, nem precisa falar que o

aceitável é o Otimizado, porém todos sabem que até para

elas isso é bem difícil de chegar, pois precisa de uma união

grande de vários setores e todos precisam estar bem

alinhados, mas elas possuem mais recursos para isso

acontecer do que as pequenas e medias e por isso esse é o

aconselhável, mas elas não são o foco dessa série de artigos

Outro fator que devemos considerar é que no ITIL existem

vários módulos das fases dos processos e cada módulo pode

ter um nível de maturidade e é nisso que vamos focar, quais

são os processos que devem estar no mínimo no nível de

maturidade Definido para as pequenas e médias empresas é

que não é nenhum bicho de sete cabeças de ser

implementado.

No próximo post falarei dos processos que o ITIL cobre e que

podem ser facilmente implementados na sua empresa além

de falar de ferramentas que estão disponíveis de graça para

você. Para exemplificar o que estou dizendo, vamos seguir

com os nossos exemplos. As ferramentas que o nosso

profissional de TI pode ter usado para detectar esse

problema seria o OCOMON, para gerenciar os chamados,

além de poder ter criado um base de conhecimentos através

de wiki tais como o MediaWiki para documentar os

problemas enfrentados para mitigá-los e poder ser usado

para dar o treinamento para os usuários do sistema que está

dando defeito.

Isso é só uma amostra do que pode ser feito então até o

próximo post.

Como implementar ITIL em pequenas e médias empresas – Parte 2

Salve, salve, pessoal do Cooperati, vamos hoje dar

prosseguimento a nossa série sobre como implementar ITIL

em pequenas e médias empresas. Como dito no post anterior,

para você implementar a ITIL não precisa que ela seja usada

nas supra-sumos das técnicas de melhores práticas e que ela

é dividida em níveis de maturidade, outra coisa também que

vale ser relembrado é que ITIL é uma série de boas práticas,

mas nem todas elas podem adequar-se a sua estrutura da

maneira como é relatada no Guia, ou até mesmo se servem

para ser implementadas.

Algo que tem que ficar bem claro é que ela é dividida em

fases e cada uma tem a sua importância e dentro de cada

uma existem processos a serem desenvolvidos. Para

avançarmos ao assunto desse tópico, temos que entender um

pouco dessas fases.

A primeira é ligada a estratégia, muitos não dão importância

a ela, principalmente nós brasileiros que preferimos logo

botar a mão na massa, mas ela é muito importante, pois nela

que vão ser definidos o que vai ser implementado e como vai

ser feito o acesso, ou seja, definir os recursos do projeto.

A segunda fase é a de desenho que é a parte que, depois da

definição do que vai ser implementado, diz o que vai precisar

para funcionar e definir os responsáveis.

A terceira fase é a de transição, onde define como o projeto

deve ser implementado, pois depois que você define o que vai

ser implementado e o que vai precisar, será necessário um

manual de utilização do mesmo, nessa fase que os testes

serão feitos para que as tarefas sejam executadas das

melhores formas possíveis.

A quarta fase diz respeito a operação do projeto, essa parte é

onde os profissionais de Ti mais gostam de trabalhar, porque

é onde as coisas acontecem, porém para chegar-se aqui, as

outras três fases precisam estar bem consolidadas para a sua

realidade, pois não adianta você colocar algo que você não

vai usar por um longo tempo e principalmente pecar pela

falta de informação, mesmo que seu processo seja pequeno,

uma falta de informação pode levar a ruína.

A quinta e última fase, fala sobre uma das partes mais

importantes do processo que é a monitoração do serviço, ou

seja, saber se ele está correndo de acordo com o que foi

estabelecido nas três primeiras etapas, já que não adianta

você executar as tarefas e ela estar errada e caso isso esteja

ocorrendo é aqui que define se ele precisa ser refeito ou ter

somente ajustes pontuais.

Agora que explicamos um pouco sobre as fases vamos ir ao

assunto que nos interessa que é colocar a mão na massa,

para isso, vamos seguir um exemplo de uma nova aplicação

que precisa ser implementada, com isso precisará ser feito

toda uma infra para ele, compra de novos equipamentos,

utilização do produto e etc.

Como disse, a primeira etapa que é a parte de estratégia é

uma parte que muitos não dão muita importância, por ter que

ser calculado e medido com uma boa margem de certeza,

nela você definirá quais são os recursos que o seu serviço

precisará ter e o que será disponibilizado, nessa etapa

existem 3 processos: Portfólio de Serviços, Gerenciamento de

Demanda e Gerenciamento Financeiro.

No nosso exemplo essas 3 etapas precisariam ser executadas

de uma maneira geral da seguinte forma. A primeira delas,

eu prefiro que seja a de Gerenciamento de Demanda, pois ela

que defini quem vai acessar a aplicação e quais os recursos

que essa aplicação usa quando está em produção.

Ela é importante pois se você definir errado como os recursos

serão alocados, você terá duas situações:

A primeira é a falta de recursos que acaba comprometendo

diretamente no uso da aplicação, porque a resposta não

será em tempo hábil com isso impactará diretamente no

negócio, gerando perda de rendimento e

consequentemente dinheiro. Sentiram o drama?

A segunda é a sobra de recursos: ela não é tão grave igual

a falta, mas também gera problemas, e digo porque, todos

nós temos mania de colocar um pouco a mais para dar a

famosa sobra para algum eventual problema ou mudança

de roteiro, isso não é totalmente errado, porém o errado é

que muitas vezes colocamos essa sobra MUITO maior do

que ela realmente precisa, com isso se o seu projeto for

aprovado, você não terá problemas de capacidade e todos

ficarão felizes, até o belo dia que alguém do financeiro da

empresa, descobre que você usou recursos a mais e vai te

questionar se isso era realmente necessário, ai o problema

maior aparecerá, as chances de você conseguir aprovar

um novo projeto que precisa de um bom honorário será

bem menores, pois eles sempre ficarão com um pé atrás

quanto ao seu planejamento. (Isso é realmente ruim e

acreditem acontece e principalmente em pequenas

empresas onde o gasto que você pediu poderia ser usado

em outro setor).

Mas você deve estar perguntando-se como saber se os meus

recursos ficarão de acordo com o que preciso? Realmente

isso não é uma tarefa simples, mas temos que ter algumas

coisas em mente que não falham, a primeira delas é verificar

quantos usuários irão usar a aplicação e a segunda é verificar

quantos deles acessarão simultaneamente, pois existe uma

diferença bem simples nisso, pois nem sempre todos os

usuários acessarão a aplicação juntos e com isso gera o

primeiro erro básico de muitos, pois sempre planejamos o

pior cenário possível e com isso os gastos ficam astronômicos

e o projeto será vetado.

Outro ponto importante que precisa ser levado em conta é o

quanto essa aplicação precisa ficar ativa, ou seja, ela precisa

ficar ativa no horário comercial, somente no período diurno e

etc, tudo isso é necessário para desenhar um projeto bem

estruturado.

 

Obs: A parte de disponibilidade, não é uma etapa da fase de

estratégia em si, e sim da de Desenho, porém devido a sua

importância impactar diretamente no orçamento da

aplicação, vamos transferir somente a parte que fala de

disponibilidade para essa fase.

 

Para evitar essa sinuca, entre em contato com TODOS os

envolvidos diretamente no projeto, e pergunte a eles quantas

pessoas deverão usar a aplicação, lembre-se isso não é papel

da TI, a TI não é responsável por saber quantas pessoas

existem em um setor, esse é o outro erro comum, pois muitos

tentam adivinhar o que se passa na empresa e o erro é

inevitável.

Outro erro é que muitos querem marcar reuniões que

dependem de muitas pessoas e quase sempre as agendas não

batem, e não pensem que isso é só acontece em grandes

empresas, até em pequenas isso existe, principalmente onde

muitos funcionários executam vários cargos.

Um jeito de facilitar isso é usar uma arma que é muito mal

utilizada nesse aspecto: o e-mail. Mande um para quem é

necessário questionar e espere um pouco para a resposta,

não saia cobrando a todo instante, isso irrita e pode acabar

fazendo com que a pessoa informe algo errado, com isso o

projeto já começa errado. Mas esperar demais também não é

bom, caso a resposta demore demais, mande um outro e-mail

e caso isso repita, dê uma ligadinha e peça educadamente se

ela viu o e-mail, caso a resposta ainda demore, comunique a

um superior. Esse processo como disse é de muita

importância e qualquer erro cairá sobre a TI   .

Após as informações estarem nas mãos, ai sim a TI precisa

usar os seus conhecimentos, que é montar uma estrutura que

seja adequada a ela, para isso precisamos também consultar

o fornecedor da aplicação para que ele informe as condições

ideias para que a aplicação rode nos termos que foram

informados nos relatórios dos envolvidos.

Ciente das informações que o fornecedor te enviou, monte

uma estrutura que melhor adeque a capacidade da sua

empresa.

Obs: A parte de Gerenciamento de Capacidade também não é

da fase de Estrategia e sim da de Desenho, porém devido a

alta relação entre custo X Disponibilidade X Capacidade

também será falado nessa etapa.

Depois verifique no Catalogo de Serviços, se há alguma

aplicação que execute o que a nova irá executar e vejam

quais são as melhorias.

Após tudo está encaixado monte uma apresentação

demonstrando o que a empresa pode ganhar com o novo

recurso, essa etapa está na parte de Gerenciamento

Financeiro, mas as pessoas enganam-se pensando que essa

etapa é só para mostrar os custos, mas ela também é a hora

para mostrar que a empresa pode ganhar em pequenas e

medias empresas isso tem que ficar bem explicito, pois se

você chegar com uma apresentando só custos, as chances

disso ser vetado são BEM grandes.

Em uma apresentação para demonstrar esses dados, sempre

comece usando quais são as deficiências que a empresa

possui por causa da não utilização da aplicação, depois disso

mostre os ganhos que a empresa vai ter ao implantá-la, esses

ganhos podem ser diretamente financeiros, tais como

redução de manutenção da aplicação e a redução de tempo

de uma parada da aplicação e valores agregados, tais como a

melhoria da produção dos funcionários, pois a aplicação vai

dar informações mais detalhadas e em velocidade

melhoradas, com isso o operador pode realizar mais tarefas

com uma qualidade melhor.

Após isso, demonstre quais são os custos que isso terá, tanto

com a aquisição de novos equipamentos, custo com

treinamentos e etc. Após isso mostre quando que o valor

investido retornará a empresa lembre-se esse retorno não é

só com cortes, mas com aumento de produtividade.

Mas lembre-se não omita nada, faça um balanceamento de

tudo, pois caso você omita algo nessa etapa e precise de mais

recursos no futuro, as chances de serem negadas são bem

grandes.

Com isso fechamos a parte de planejamento do ITIL, como

podemos ver a parte de planejamento é bem importante e

precisa ser bem executada, mas ela tem que ficar bem clara e

transparente para os gestores, pois um mínimo erro pode

colocar todo um projeto em risco e também verificamos que

alguns processos de ITIL estão bem interligados e o bom

funcionamento de um depende diretamente de outro para

funcionar. Espero ter colaborado mais um pouco sobre esse

assunto e até o próximo post.

Como Implementar ITIL em pequenas e médias empresas – Parte 3

Salve, salve pessoal do Cooperati, vamos prosseguir com a

nossa série de como implementar ITIL em pequenas e médias

empresas. No último post falamos sobre a fase de estratégia

de serviço e que ela é uma fase crucial para o bom inicio dos

processos já que nela é traçado quais são as bases para um

bom funcionamento dos processos de TI para o negócio, pois

lembrando a TI não é um braço separado do negócio e sim

uma parte dele e a sua função é ajudá-lo a trabalhar na

melhor forma possível.

Como já dito anteriormente, nós temos a péssima mania de

sempre começar pelo trabalho braçal sem ter uma estratégia

traçada e com isso em alguma hora na execução das

atividades vamos ter problemas e ficaremos sem um norte e

isso já pode ocorrer na fase seguinte da ITIL que é a de

Desenho de Serviço, pois todos os processos a seguir

dependem do que foi decidido na fase anterior, um exemplo

disso vem do que foi decidido da empresa sobre o que é

critico ou não e quais são os recursos para tal.

Mas o que a criticidade tem relação com os recursos que

temos? Resposta simples, imagina você ter um recurso X

disponível para o departamento de TI e ter que utilizá-lo para

que o negócio da empresa funcione sem ter sérios problemas

de paradas, um exemplo prático seria, a empresa é do ramo

de comercio e tem loja(s) física(s), mas também vende pela

internet, porém ¾ das vendas é feita pela internet e o

restante na loja física, onde muitas vezes o cliente vai só para

ver o produto de perto.

Mas essa informação não foi passada pela gerência quando

foi definido a estratégia do serviço, com isso ¾ dos

recursos destinados foram colocados para a(s) loja(s) física(s)

e o restante para a parte de venda na internet, e esses

recursos não são o suficiente para que algum problema nessa

área seja sanado de uma forma rápida e com isso o dia que

esse problema ocorrer as perdas serão sensíveis, porém

lembrando esse tipo de decisão não é de competência da área

de TI, mas temos que auxiliar na decisão.

Viram como uma informação faltante pode acabar com todo

um planejamento? Mas agora vamos ao que interessa, e

partindo do pressuposto que a estratégia de serviço foi

traçada corretamente, o primeiro passo é definir, a partir dos

dados chegados da gerencia, quais são os setores críticos que

merecem mais recursos para ter a capacidade no mínimo

suficiente para atender o negócio e definir qual o grau de

disponibilidade que esses recursos devem possuir.

E com isso entramos nos primeiros processos da fase de

Desenhos de Serviço que são o Gerenciamento de

Capacidade e o Gerenciamento de Disponibilidade. Esses

dois processos andam quase que de mão juntas, e isso se

deve a um motivo se a capacidade do serviço não atende aos

requisitos que ele pede, logo a disponibilidade não chegará

também ao mínimo exigido e se a disponibilidade não está

chegando ao seu mínimo e porque a capacidade não está

sendo atingida.

Mas como podemos fazer isso com recursos limitados, o que

é o caso geralmente das PMEs, a resposta parece óbvia usá-

los conscientemente, o que nem sempre é simples, vamos

pegar o exemplo da nossa loja, quando você pegou os dados

que veio da Gerencia foi dito que ¾ das vendas é feito

pela internet então o que podemos fazer concentrar nossos

investimentos nessa área, tendo um link reduntante de

internet, não precisa ter dois links dedicados com

velocidades exorbitantes , você ter um link bom que atenda

ao seu negócio e um link um pouco menor para suprir uma

possível queda do outro link, e comprar um roteador dual-

wan que faça esse balanceamento, com isso já elimina uma

boa parte dos problemas. (Todos nós sabemos como é o

serviço de internet no Brasil e o que menos podemos confiar

são neles).

Outro ponto importante é investir em um bom servidor,

ultimamente o Cooperati vem batendo bem nessa tecla e

mostrando como é bom ter algo um pouco mais caro que vai

no futuro te livrar de muitas dores de cabeça.

No começo, a alta gerencia quando você mostrar os valores

para a aquisição desses componentes talvez não vão querer

aceitar a compra e possivelmente vão falar, “Mas e os nossos

outros setores como ficarão?”, mas ai que entra o papel da

TI, mostrar para eles o quanto seria a perda que eles

sofreriam com uma queda de algum desses componentes, e

que o Investimento no futuro vai ser o menor dos custos,

inclusive com manutenção.

Outro ponto importante é mostrar quais são os custos no

futuro não somente no presente, você vai ter muito mais

credibilidade com a gerencia mostrando esses valores.

Obs: Como puderam ver o Gerenciamento de Capacidade

pertence a fase de Desenho, mas a liberação de verba vem do

Gerenciamento Financeiro, porém isso é uma prática comum

na Itil, um processo retroceder a outro quando não estão de

acordo, pois os processos sempre estão em constante revisão.

Com a aprovação para a aquisição dos componentes para

atender a capacidade, vamos ao Gerenciamento da

Disponibilidade, essa etapa define por quanto tempo um

sistema pode ficar indisponível, sem ter que afetar a

produção da empresa, e tudo isso depende da capacidade

que foi estabelecida no Gerenciamento de Capacidade.

Mas a disponibilidade não é somente medida se o sistema

está ativo, mas também se as informações são verdadeiras e

confiáveis, pois isso também pode atrapalhar na produção da

empresa.

E também cada setor da empresa pode ter o seu tempo de

disponibilidade da empresa de acordo com a criticidade.

Voltando ao exemplo da nossa loja, o setor de RH não precisa

ter o mesmo nivel de disponibilidade do que o setor de

vendas da empresa, então o setor de RH pode ter uma

disponibilidade de 95% e o de vendas 99%. O que significa

que o setor de RH precisa ter 95% do tempo do sistema deles

disponível quando for requisitado e o de vendas é 99%, mas

um outro fator também é as horas que esses setores acessam

as informações, no caso do setor de RH, somente no horário

comercial, no caso de 8 ás 18 de segunda a sexta-feira e o de

vendas no famoso esquema 24×7, 24 horas por 7 dias da

semana, então se fizermos a conta o setor de RH pode ter

uma parada de 11 horas em 220 no total do mês: 22 dias no

mês x 10 horas por dia e subtraia do tempo que ele precisa

estar disponível, 220 horas x 0.95.

Já o setor de vendas pode ter uma parada de 8 horas em 720

horas possíveis que são: 30 dias no mês x 24 horas – 720 x

0.99.

Como podemos ver isso faz uma enorme diferença, mesmo o

tempo de parada entre os dois serem quase os mesmos, mas

o máximo de tempo que eles podem estar ativos é muito

maior, então sempre leve em conta esses fatores.

Porém um outro processo que te auxilia nessa tomada de

decisão é o Gerenciamento de Nivel de Serviço, essa etapa é

de suma importância pois ele é que define em quanto tempo

um serviço indisponível precisa voltar, mas ao que muitos

pensam os contratos de nivel de serviço não são feitos

somente entre empresas, mas também entre setores da

própria empresa e é nessa etapa que muitos acabam se

enrolando, pois os próprios funcionários não fazem valer um

tempo de resposta ágil. Porém nas PMEs o setor de TI não

demanda de muitas pessoas, então isso deve ficar bem claro

entre os membros, então para isso funcionar algumas

técnicas simples podem ser usadas, uma delas é a própria

comunicação, seja ela feita verbal ou por meio de e-mail ou

qualquer outro documento, mas sempre tenha algo assinado

ou com alguma confirmação que a pessoa tem consciência

dos termos acordados e uma outra forma de verificar se os

acordos estão sendo efetuados e ver como eles podem

melhorar e fazendo uma reunião em no minimo entre 15 e 15

dias, pois mesmo em um departamento pequeno, pois você

ter um tempo exclusivo para isso, torna as coisas mais

simples do que fazer na correria do dia a dia.

E esses acordos também podem variar de setor para setor

dentro da empresa, um tempo de atendimento pode variar,

seguindo o exemplo um tempo de atendimento para o setor

de RH pode ser diferente do setor de vendas, depende do

nível de criticidade do negócio, mas também pelo qual é a

gravidade do caso.

Mas também temos os contratos de nível de serviço com

prestadores de serviço externo, e todas as empresas hoje tem

pelo menos um prestador externo e é preciso também

gerenciar isso para ter um bom funcionamento dos serviços e

para auxiliar isso existe um outro processo na ITIL que é o

Gerenciamento de Fornecedores que trata exclusivamente

desses fornecedores, para uma boa relação sempre tente te-

lo como um aliado não como um inimigo, pois se você tem a

confiança dele com certeza negociar novos contratos será

bem mais fácil.

E isso com certeza vale muito nas PMEs, pois os prestadores

de serviços que as atendem geralmente possuem bastante

contratos e as vezes os níveis de serviço não são atendidos,

caso isso seja constante, seria uma boa ideia estudar um

novo prestador de serviço.

 

OBS: Caso a sua empresa seja uma prestadora de serviço,

atente-se a esse ponto, fazer valer o Nivel de Serviço

acordado não sai caro, mas se os niveis de acordos não estão

sendo feitos tente renegociar isso com o cliente, negociar

também não sai caro.

E para o gerenciamento dos níveis de serviço com

fornecedores externos também vale algumas atividades para

os níveis de serviço interno, sabemos que marcar reuniões

com eles são dificeis, mas sempre troque informações e se

possível marque uma reunião e tente mostrar o que está

faltando, mas também mostre o que está bom, assim você

acaba ganhando esse fornecedor.

Como vimos, são algumas ações que tomamos que fazem

toda a diferença, saber planejar também faz toda a diferença,

no próximo post continuaremos a falar da fase de Desenho do

Serviço, até lá.

Como Implementar ITIL em pequenas e médias empresas – Parte 4

Salve, salve pessoal do Cooperati, vamos continuar com a

nossa série de Como Implementar ITIL em Pequenas e

Médias Empresas. No último post demos início a fase de

Desenho de Serviço, e como na fase de Estratégia de Serviço,

essa fase é mais “pensante”, ela discute como o serviço de TI

deve funcionar e quais são os suportes que ele deve ter.

Isso foi mostrado nos processos de Gerenciamento de

Capacidade, Gerenciamento de Disponibilidade,

Gerenciamento de Nível de Serviço e Gerenciamento de

Fornecedores. Esses processos são bastante interligados

entre si, um exemplo disso é que para você definir o quanto

um sistema pode ficar disponível, você precisa saber com

qual capacidade irá trabalhar, pois não adianta falar que um

sistema vai ficar 99% disponível, se os recursos que você

possui não te darão isso e de acordo com essas informações

você pode definir qual será os acordos de Nível de Serviço

pois você não pode assinar algo que não pode fazer e se caso

viu que não pode atingir os níveis desejados pela empresa,

você pode optar por serviços terceirizados e de brinde você

terá que gerenciar os seus fornecedores para ver se eles

estão te atendendo ou não.

Mas a fase de Desenho de Serviço, não se limita somente a

esses processos, ela possui mais 3 processos sendo 2

altamente ligados: o Gerenciamento de Segurança da

Informação e o Gerenciamento de Continuidade do Serviço e

como podem ver os próprios nomes já falam por si só e são

dois processos importantíssimos, pois eles lidam diretamente

com a segurança da informação.

Porém, como a Continuidade do Serviço, tem ligação com a

Segurança? Simples, a segurança é baseada em 3 pilares que

juntos são chamados de CID (Confidencialidade, Integridade

e Disponibilidade) e a Continuidade lida diretamente com a

Disponibilidade e Integridade dos dados. Mas como assim?

Bom ele lida, como o nome diz, com a continuidade dos

serviços, principalmente com a recuperação de desastres, ou

seja, caso algo falhe na sua empresa é esse processo que irá

decidir o que deve ser feito para que tudo volte o mais rápido

possível, então a disponibilidade está diretamente ligada a

esse fator.

Contudo temos que tomar cuidado com uma coisa, quando

fala-se em desastre, logo vem a cabeça: “Meu Deus, o predio

da empresa caiu!”, mas não é bem assim, um desastre no

conceito de TI pode ser um servidor de aplicação que caiu,

por causa de um desligamento indevido, e esse servidor é o

que tem a liberação dos pagamentos da empresa e esse fato

ocorre justamente no dia do pagamento, então a sua volta

tem que ser feita rapidamente, se esse servidor tivesse caido

um dia depois, talvez a criticidade não fosse tão alta. Então

um “desastre” no conceito da Continuidade de Serviço e algo

que afeta diretamente o funcionamento da empresa e pode

causar um grande dano seja ele financeiro ou a sua imagem.

Para implementar esse processo em uma pequena ou média

empresa, a primeira coisa a se fazer e ter um backup, pois

em caso de perda de dados (um dos maiores “desastres” que

pode ter), você está precavido. E ter uma solução de backup

hoje não custa muito caro, hoje pequenos storages estão com

preços bastante acessíveis, (no Cooperati já foi falado de um

micro server da HP, onde pode ser instalado o FreeNas nele

e ser transformado em um storage) e junto com o software de

backup Bacula, que possui um ótimo gerenciamento do que

foi feito, te informando logs, tempo de retenção do backup, e

realização dos vários niveis de backup (normal, diferencial e

incremental), formam uma solução bem robusta. Para

usuários de Windows a versão Server 2003, possui o

NTBackup, está certo que não é uma ferramenta completa de

backup, mas pelo menos os recursos básicos de realização e

restauração de backup ele faz e no Windows Server 2008

também existe um ferramenta de backup, mas se você

possuir uma licença do Server 2003 que está encostada,

convém instalá-la para usar esse servidor como gerenciador

de Backup, pois a ferramenta nativa do 2008 tem muitos

poucos recursos (menos ainda que o NTBackup). Mas

lembre-se o importante é ter um.

Contudo um backup feito em uma mídia somente, pode não

ser o suficiente, já que esta pode falhar, então a continuidade

lida com isso, ditando outras técnicas que podem ser feitas,

entre elas estão o armazenamento em mais de um dispositivo

e até mesmo fora da localidade, e nesse quesito uma simples

prática pode ser eficaz que é o caso de entregá-lo para

alguém do alto escalão, e melhor se for um reserva, pois caso

realmente um desastre aconteça como o prédio cair, a

empresa não perderá tudo, e caso esta opção seja adotada a

pessoa que sair com o backup, tem que assinar um termo que

ele está sob responsabilidade dela. Uma outra técnica que

está ganhando bastante adeptos é colocar os dados na nuvem

porém o preço de armazenamento talvez não seja atrativo e

outro fator é o caso da confidencialidade, pois se os dados

não estão em suas mãos você não tem como controlá-los.

Outro fator que o processo de Continuidade de Serviço

também lida é testar as soluções para quando realmente elas

precisam ser usadas vão funcionar. Todos nós sabemos que

em pequenas e medias empresas, as vezes isso é dificil, mas

isso é de vital importância pois lida com o segundo pilar da

segurança que é a integridade, pois se o dado não está

consistente tudo o que foi feito anteriormente não terá valido

de nada. No caso das soluções de backups, uma data propicia

para ser realizado esses testes e no final de semana, onde

você poderá deixar rodado uma restauração em um local de

testes (pode até ser um pc velho) e quando chegar ao

trabalho verificar se tudo saiu conforme era esperado.

Um ponto importante também é a documentação do que é

considerado um desastre, e tudo isso deve estar bem

explicado em um documento, porém nas PMEs isso é

complicado, pois os recursos são escassos, mas uma forma de

mitigar isso é fazer um documento por tópicos dando uma

breve explicação do que pode ser feito e quais os

procedimentos (mas isso é claro se você não tem como

detalhar o processo do inicio ao fim, pois quanto mais

detalhado maiores são as chances de sucesso), outro ponto

importante é ter uma cópia desse documento impresso e não

só em versão digital, pois imagina se algo acontece e o

servidor onde está guardado a cópia é o que precisa ser

restaurado? E também avise mais de uma pessoa sobre os

procedimentos, mesmo que o departamento de TI seja o EU-

TI-smo. Caso isso seja a sua situação o escolhido pode ser

alguém perto do departamento que conheça algo de TI.

E não se esqueça, tudo isso deve passar pela aprovação da

alta gestão, porque se você não tiver a aceitação deles as

chances da implantação dar certa é quase nula.

Com isso podemos ver que o processo de Continuidade do

Serviço é um processo muito importante, pois lida com casos

extremos de paralisações nos serviços, além de cuidar da

segurança dos métodos de como elas são guardadas e

restauradas e o outro processo que segue essa linha é o

Gerenciamento de Segurança da Informação, que como o

nome diz cuida da segurança dos dados da empresa.

Nesse processo além de determinar como as informações

devem ser protegidas ele lida também como elas devem ser

usadas.

Como todos nós sabemos a segurança é um tópico que está

em alta e deve ser gerenciada de forma correta, pois o nível

dela é medido pelo elo mais fraco que ela possui, ou seja,

fazendo uma analogia, não adianta você ter uma casa ultra

protegida se a chave da porta de entrada está escondida

debaixo do tapete de entrada. Além como dito anteriormente

não adianta você ter implantado, mas não sabe se está

funcionando.

O primeiro passo para gerenciar a segurança dos serviços é

definir quais são as informações mais sensíveis da empresa e

categorizar por níveis, onde o nível mínimo é que a

informação é do caráter público e o máximo o nível é

confidencial onde somente alguns membros da empresa

saberão que ela existe.

Nota: Essa categorização é exemplo e você pode escolher o

seu.

Um bom inicio para deixar bem claro como as pessoas devem

funcionar no quesito da segurança é definir um modelo de

segurança, onde será descrito quais são as políticas de

segurança, a maneira como deverá ser usado os recursos da

empresa de uma maneira que não comprometa os dados,

guias para auxiliar na adoção de maneiras seguras de

proteger os dados e etc.

E você pode ter vários modelos de segurança dentro da sua

empresa, um para o público em geral, dividido por setores e

os para a área de TI, assim você pode colocar de uma forma

clara para cada um, assim as informações chegam claras a

quem elas precisam chegar. Um exemplo: um modelo de

segurança para pessoas não técnicas deve ter uma

linguagem mais simples e de fácil entendimento tal que, as

para o setor de TI pode já ter mais recursos técnicos que

explica de uma forma mais detalhada como a segurança

funciona.

Mas tudo isso deve ser baseado no CID (Confidencialidade,

Integridade e Disponibilidade), pois se uma informação for

acessada por uma pessoa não autorizada ou vir com dados

errados ou não estar disponível na hora que for requisitada

pode causar um enorme estrago.

Mas uma coisa no processo de Segurança da Informação não

será implantado a segurança por si só, neste processo será

somente definido como será a estrategia de segurança da

empresa e definir os rumos para isso, a segurança será

implantada na fase de Operação de Serviço.

Com isso, finalizamos quase todos os processos da fase de

Desenho, faltando somente o Gerenciamento do Catálogo de

Serviços, que são onde os serviços que a empresa possui são

apresentados e disponíveis ao público, a principio esse

processo pode ser um pouco simples, mas ele é de suma

importância, pois ele evita casos de contratações de serviços

que já existem na empresa.

Um exemplo disso, seria o setor financeiro possui um sistema

de pagamentos e ele queira implementar um serviço de

débito automático em suas contas, porém ele tenta fazer no

sistema atual e não consegue, então ele mesmo faz os

contatos com outras empresas que possuem isso, adquirem e

chega no departamento de TI para implementar, só que o

sistema que eles usam executa essa função, mas não estava

documentado no catálogo de serviço.

Viram como um catalogo bem atualizado pode livrar de

vários problemas? E também ele é dividido em duas formas:

um catálogo de negócios, onde estará todos os produtos que

existe na empresa e suas funções e um catálogo técnico que

é voltada para o setor de TI, onde consta como são feitas as

funções ou seja o que cada uma faz para chegar ao resultado

que o usuário quer chegar.

Um jeito simples de fazer um catálogo de serviços é usar uma

intranet, pois ela é de fácil acesso a todos, além de ser uma

forma centralizada de informação.

Uma ferramenta bem eficaz para isso é o Sharepoint e não

precisa ser a versão server, já que para as PMEs não

necessita de muitos recursos e a versão Foundation dele

possui recursos bastante uteis além de que se você possui um

Windows Server 2008 licenciado você pode instalá-lo sem

custo adicional algum.

Caso você queira partir para uma solução totalmente grátis,

pode usar uma ferramenta que cria uma wiki, tais como o

Dokuwiki ou o MediaWiki, falado aqui também no Cooperati,

mas independente da ferramenta, lembre de sempre ter ele

atualizado e de uma forma clara.

Depois desse processo fechamos a fase de Desenho de

Serviço, que é a fase onde os procedimentos começam a

tomar uma forma e de vital importância pois qualquer coisa

desenhada errada pode gerar enormes problemas no futuro,

já que as próximas fases simplesmente coletam as

informações vindas dela e as transformam em real valor para

o cliente. Então pessoal até o próximo post onde iniciaremos

a fase de Transição do Serviço, onde tudo que foi desenhado

será testado para ver se nada está errado e se tiver voltar

para ser melhor feito.

Como Implementar ITIL nas pequenas e medias empresas – Parte 5

Salve, salve pessoal do Cooperati, vamos dar prosseguimento

a nossa série sobre Como Implementar ITIL nas pequenas e

medias empresas. No último post terminamos a fase de

Desenho do Serviço, que é a fase onde os processos são

estruturados e definidos, como serão implementados na

empresa e, principalmente, como serão suportados através

de nivel de serviços e gerenciando qual será a capacidade e a

demanda para que eles possam rodar sem sobrar nem faltar

recursos.

A próxima fase é a Transição de Serviços, que nada mais é

que a fase onde são testados os processos, se eles precisam

de algum ajuste para poder entrar em execução e, se

precisar, voltar para o processo anterior.

Nessa fase, também são realizadas também as requisições,

aprovações e planejamento para realização de mudanças no

ambiente, ou seja se algo precisa de alteração a etapa é aqui

e para isso acontecer uma requisição deve ser feita, nesta

requisição devem conter: quem requisitou, qual recurso

mudar, o motivo para essa mudança e quais as melhorias que

essa mudança irá causar. Esse é o passo inicial, pois assim a

avaliação ficará mais fácil para ser aprovada ou não, pois os

motivos estarão mais centralizados e detalhados, pois

imagina chegar uma requisição de mudança escrita da

seguinte forma: “Troquem o monitor”. Bom essa requisição

só atende a um requisito, que é: qual recurso mudar. Mas

todas as outras não e com certeza se você tivesse que

aprovar essa requisição teria que procurar saber, no mínimo,

quem requisitou e o motivo para ver se é aprovava ou não, e

isso demandaria um tempo que poderia ser precioso para

realizar outras tarefas, ou então você excluiria o pedido sem

saber do que se tratava, porém se não tiver algo que te

respalde de fazer isso, você poderia ter sérios problemas em

ter eliminado ela sem aviso prévio e o motivo para tal, em

que, no caso da requisição, era não conter os dados mínimos

para realizar uma mudança.

E para isso, o primeiro passo é ter um modelo de requisição

de mudança publicado na rede, ou ter um sistema para tal e

também um documento dizendo que todas as mudanças só

serão aceitas se estiverem no padrão desse modelo.

Após você ter um modelo pronto, você precisa saber quais

mudanças precisam de uma validação para aprovação ou se

já são automaticamente aprovadas ou comumente chamando

de mudanças padrões, o motivo para isso é que se todas as

mudanças que forem solicitadas tiverem que passarem por

um período de avaliação, o andamento do negocio da

empresa pode ter uma parada não programada, que pode

acarretar em sérios problemas a empresa e um tipo de

mudança padrão é a alteração de senha ou troca de tonner

de impressora, que sabemos que são mudanças rotineiras.

Mas independente de uma mudança ser padrão ou não, o que

não pode deixar de acontecer é o registro de qualquer

mudança feita na área de TI e o motivo para isso é bem

simples, para em um futuro poder avaliar quais são as

mudanças que são mais rotineiras e talvez transforma-las em

uma mudança padrão, isso se não impactar diretamente no

negocio da empresa.

Outro fator importante no Gerenciamento de Mudanças é que

as mudanças que precisam de avaliação, não podem ser

tomadas por uma única pessoa, sempre bom ter mais de uma

para poder discutir e verificar as melhores opções, como já

foi dito em artigos anteriores sabemos que em muitas

empresas o EU-TI-SMO impera, mas algumas mudanças

precisam ser levadas para os responsáveis pela empresa,

então NUNCA decida algo sozinho em que pode afeta-la, mas

caso a mudança é de caráter técnico e você possuir mais de

uma pessoa na equipe, sempre discuta essa mudança com

ela(s), pois algum detalhe que você não prestou atenção pode

ser levado em conta, outro ponto, mesmo que a mudança não

necessite da intervenção do alto escalão da empresa, sempre

mantenha-os informado, para que eles saibam o que está

acontecendo e não chegarem e falar “mas eu não sabia que

isso estava acontecendo”.

Após ser feita a avaliação e autorização da mudança é

necessário ter um documento detalhando como a mudança

deve ser executada, pois se algo sair errado a mudança

poderá ser uma catástrofe e falando nesse assunto, você

também tem que estar preparado para mudanças

emergenciais, onde não há tempo hábil para avaliar a

mudança, já que ela impacta diretamente a empresa, caso

isso aconteça, tente informar o máximo POSSIVEL de

pessoas da realização desse tipo de mudança, mas tente

informar necessariamente as pessoas chaves e não todas que

precisariam saber.

Outro elemento importante na fase de transição de serviços e

que também está ligado ao Gerenciamento de Mudanças é o

Gerenciamento de Configuração e Ativos de Serviço.

Esse processo lida diretamente com o que a sua empresa

possui, falando em miúdos o hardware e o software, pois

imagina você precisar saber em qual hardware um

determinado software está rodando para resolver um

problema e não saber, isso geraria um outro problema, então

ter documentado o que a sua empresa possui é de

fundamental importância.

A ITIL chama tudo que a empresa possui na área de TI de IC

(Itens de Configuração), geralmente as pessoas pensam que

um IC é ligado com o hardware, mas um software de Banco

de Dados também é um IC, pois ele é um item configurável

que está relacionado a um servidor.

Então tenha sempre em mãos um mapa que diz, onde

determinado IC está instalado ou localizado e também um

inventário de fácil acesso para tal, outro ponto importante

que esse processo cobre é: sempre ter estoques de ICs da

sua empresa para trocas emergenciais, pois imagine queimar

um monitor de um funcionario e o mesmo ter que esperar a

aquisição de um outro para ter que trabalhar? Isso não seria

uma boa ideia. Mantenha um estoque minimo de peças, para

o tamanho da sua empresa, para essas situações, outro

detalhe crucial é ter um local para armazenar os softwares

que ela possui, para que a instalação ou troca do mesmo, não

torne-se um processo dispendioso.

Outro ponto é ter uma base de configuração dos seus ICs,

pois imagina você ter que configurar uma máquina sem saber

o que ela deve ter ou os requisitos minimos para tal? E essa

base não precisa ser só de máquinas pode ser de software

também, pois implementar um, também tem que ter um guia

e os requisitos.

Essa base também pode variar de setor para setor, pois uma

máquina que é configurada para o Financeiro não é a mesmo

que vai para o de Vendas, e o seu sistema de Banco pode ser

configurado de uma maneira para o Financeiro e outro para o

de Vendas.

A base também pode ser utilizada para retornar a um ponto

inicial para resolver um problema ou comparar com um

estado atual de um IC. Pois imagina você não ter um ponto

inicial para saber o que está certo ou errado?

E um ponto chave é saber as ligações de cada IC tem um com

o outro, pois nenhum deles trabalha sozinho e saber qual a

relação que eles possuem é de suma importância para

resolução de vários problemas.

Mas falando um pouco de como implementar vou falar

rapidamente de dois softwares MUITO uteis nesse quesito e

que interligam entre si, um é o OCS um software de

inventário Open Source que te dá todas as informações dos

ICs presentes na sua empresa.

Esse software possui um agente que ao instalar em uma

máquina puxa todas as informações contidas nele, tais como

software instalado, configurações de componentes, como

processador, memória, HD e etc, e também quem é o usuário

que está vinculado a ele, além de te fornecer relatórios sobre

tais, além de fácil implementação.

E outro software que falaremos bastante aqui é o GLPI, que

tem integração direta com o OCS. Mas o que isso me

ajudaria? Eu respondo em muita coisa.

O GLPI é um software voltado quase todo para as técnicas do

ITIL, ele possui um sistema de abertura de chamados em que

você pode abrir requisições de mudanças e junto com a

integração ao OCS, o usuário pode vincular diretamente o

componente que ele quer mudar a sua requisição e isso

porque você pode importar do OCS os componentes e

vincular ao usuário correspondente. Além também de ter um

histórico de vida do componente e também do usuário para

detectar quais as mudanças que mais são abertas. Além de

poder cadastrar as peças sobressalentes e assim que forem

utilizadas dar baixa e importa-lo do OCS.

Então pessoal mostramos um pouco de processos bem

interligados da fase de Transição de Serviços e como eles

podem nos ajudar a desvendar o nosso parque de TI no nosso

próximo post falaremos sobre os testes e liberação de

serviços e como gerenciar o conhecimento da sua empresa,

até lá.

PS: Link com mais detalhes sobre o OCS

Como Implementar ITIL nas pequenas e médias empresas – Parte 6

Salve, salve pessoal do Cooperati, continuando nossa série

sobre Como Implementar ITIL nas pequenas e médias

empresas, vamos dar prosseguimento a Fase de Transição de

Serviço. No post anterior falamos de dois processos dele e

que são intimamente ligados: o Gerenciamento de Mudanças

e o Gerenciamento de Configuração e Ativos de Serviços.

Estes processos lidam com o processo de mudança do parque

de TI da empresa, o primeiro abre, avalia e vê se a mudança

solicitada deve ser atendida e o segundo é um auxilio para o

primeiro já que nele é listado todos os ativos da empresa

(sejam eles hardware ou software), com isso o departamento

de TI pode verificar se a mudança deve ser feita, baseada nos

ativos atuais, além de poder solicitar uma atualização do

parque e armazenar peças para reposição.

Mas o que fazer, caso a mudança seja realmente aprovada?

Liberar de uma vez? Óbvio que não! Deve testar antes. Mas

depois que testar, liberar tudo de uma vez? Só se o alvo

forem poucas pessoas ou não tiver outra pessoa. Essas e

outras perguntas são respondidas no Processo de

Gerenciamento de Liberação e Implantação. Esse processo

lida, com os testes, métodos de liberação e implementação

dos projetos e mudanças.

O primeiro passo desse processo é a parte de testes, neste

caso o principio básico é ter um ambiente de testes

preparados e simule alguns testes. Como venho falando ao

longo desta série algumas empresas não possuem ambientes

adequados para tal, e as vezes o setor de TI tem que se virar

com o que tem, então algumas dicas talvez ajudem: no caso

de teste de software hoje contamos com a virtualização para

nos ajudar, hoje máquinas conseguem fazer esse processo

perfeitamente, então não é necessário que fiquem máquinas

exclusivas para esse fim. Então use e abuse desse recurso,

que ajuda bastante. Programas free para isso é que não

faltam, para ambientes desktops temos o virtual box e caso

você tiver um servidor disponível para esse fim é o VMWare

ESXi e se você tiver uma licença de Windows Server

sobrando temos o Hyper-V que agora também virá no

Windows 8.

Com essas ferramentas é possível simular o seu ambiente e

ver exatamente o que a aquisição ou mudança do software

pode causar. Repetindo use e abuse desse recurso.

No caso de hardware, separe um lugar para poder testar se

eles estão funcionando corretamente, esse espaço não

precisa ser uma sala, que muitas empresas não possuem,

pode ser uma pequena mesa que comporte o espaço para

eles, sempre teste se os equipamentos estão funcionando,

pois a pior coisa que existe e você colocar um aparelho para

um usuário e 5 min você recebe uma reclamação dizendo “O

equipamento não está funcionando!”. Está certo que as vezes

as mudanças de hardware para usuários, tem que ser

imediatas e não há tempo de testar, então voltando ao tópico

anterior, sempre tenha peças reservas e quando elas

chegarem teste-as para evitar conflitos.

Após os testes serem realizados, temos que partir para a

liberação e implementação da mudança. Na parte de

liberação temos que definir como elas serão feitas e isso não

é uma decisão isolada, ela depende muito do que vai ser

liberado. Por exemplo, se você vai liberar uma nova versão

de software, se caso essa mudança não afetar o BD atual e

pode conviver sociavelmente com a versão antiga, escolha

algumas pessoas dentro da empresa para verificar se algum

problema não foi visto nos testes. (Todos nós sabemos que

um erro ou outro passa durante a parte de testes, então

nunca é bom fazer uma liberação total). Caso a mudança

impacte no Banco e com isso as versões não possam

coexistir, a liberação tem que ser feita para todo mundo,

neste caso os testes tem que serem bem mais rigorosos, pois

qualquer erro afeta todo o sistema da empresa e outra coisa

sempre tenha um backup para voltar em casos de pane geral,

isso tem que estar bem relacionado com o Gerenciamento da

Continuidade de Serviços de TI, este tipo de mudança são

chamados de Por Fases ou Big Bang, respectivamente.

Obs: Este tipo de liberação pode ser usada tanto para

software quanto hardware.

Para a liberação de software, existem outros métodos de

liberação que podem ser usados em conjuntos com os citados

anteriormente, entre eles estão o modo manual ou

automático, que o próprio nome diz como funciona, ou você

libera a atualização indo pessoalmente nas máquinas ou cria

um modo automatizado, através de scripts, programas de

atualização e etc.

E o outro modelo de liberação é o “Empurra e puxa”, que

significa, a atualização é empurrada para um ponto central e

depois os alvos que serão atingidos por essa liberação puxam

desse ponto central. Este tipo de modo é usado comumente

com o modo de liberação automático em que um pacote é

enviado a um servidor e a aplicação a ser atualizada ao

iniciar verifica se a versão que ele usa é igual a versão que

está no servidor se não ele, baixa e atualiza a sua aplicação.

Então utilizando usando esses modelos de liberação,

separadamente ou em conjunto, temos uma gama de formas

para melhor fazer a atualização das mudanças no ambiente

de TI.

Então para encerrar essa parte de liberação, temos um

último ponto em comum com o Gerenciamento de Mudança,

uma Requisição de Mudança só deve ser fechada após a

implantação da mudança ser completamente executada,

então o Gerenciamento de Liberação e Implantação está

dentro do Gerenciamento de Mudanças, mas sendo processos

em separado.

E o último processo dessa fase é o Gerenciamento de

Conhecimento, que lida diretamente com a documentação da

TI. Este processo é muito importante, pois ele que dirá aonde

a informação deve ser guardada e através de relacionamento

com outros processos você terá uma base de conhecimento

bem grande.

Neste processo, uma base das coisas é: registre tudo o que

foi feito! Isto se dá pois você nunca saberá quando vai

precisar de uma informação de algo que aconteceu a por

exemplo 6 meses atrás ou então saber como configurar uma

aplicação que foi implementada a 1 ano e terá que ser

reconfigurada novamente e uma das mais utilizadas funções

desse processo é a base de conhecimento para resolução de

problemas, que será discutido nos próximos posts.

O Gerenciamento de Conhecimento talvez seja o processo

mais ligado com todos os outros, pois tudo que é registrado

nos processos recai aqui, ele engloba: a relação dos ICs

(Itens de configuração) do ambiente, as requisições de

mudança, o plano de contingência para recuperação de

desastres, os contratos de SLA, os modos para resolução de

problemas e etc.

OBS: Um famoso caso de Gerenciamento de Conhecimento

são os famosos Knowlegde Base ou os KBs da Microsoft, onde

todo um guia para a resolução de problemas estão nele e

todos sabemos que eles são inúmeros que juntos formam a

Base de Conhecimento.

Como podem ver o Gerenciamento de Conhecimento é um

núcleo principal da ITIL, um modo bem importante para fazê-

lo funcionar é montando uma intranet na sua empresa, onde

todos os usuários tem um fácil acesso a informação e podem

através dela resolver o seu problema, sem ter que abrir um

chamado no setor de TI.

Outro ponto também importante é que após uma requisição

de mudança ser completada e finalizada, ela vem para a base

de conhecimento para que fique salvo tudo o que foi feito e

no futuro poder ser analisada e ver quais foram as maiores

mudanças e como foram e levantar uma estatística, como já

dito nos posts anteriores.

O Gerenciamento de Conhecimento também ajuda a

transformar um simples dado em sabedoria, pois através dele

você pode interligar várias informações sobre vários assuntos

diferentes e transforma-los em um conhecimento que possui

e passar a entender como as coisas funcionam e porque elas

acontecem.

Mas um grande mal, que não deixa as pessoas a implementar

o Gerenciamento de Conhecimento é a internet, pois tudo o

que procuramos está lá e isso é um fato, mas não imaginamos

que o site onde aquela informação está pode sair do ar e um

exemplo disso é o MegaUpload que foi retirado do ar e com

isso vários arquivos de pessoas deixaram de existir, pois

possuíam somente a cópia nele.

Um outro ponto que também pesa positivamente para a

implementação do Gerenciamento do Conhecimento é que

você terá um acesso mais rápido as informações da empresa,

sem ter que procurar em outro local, além dela estar dentro

da sua empresa e caso tenha uma queda de um link, você

ainda tem acesso a ela.

OBS: Mantenha sempre atualizado a sua Base, pois se tiver

desatualizado é a mesma coisa que não ter.

E algumas ferramentas ajudam bastante na implementação

destes processos citados acima, na fase de Gerenciamento de

Liberação e Implementação, na parte de atualização do

Windows, temos o WSUS, que usa a implementação

“empurra e puxa”, onde ele baixa as atualizações dos

servidores da Microsoft e depois distribui para as máquinas

clientes.

Outra ferramenta que pode ser utilizada são as GPOs, onde

você pode atualizar os softwares através dela, além da

família system center que possui ferramentas para gerenciar

todo um ambiente inclusive na liberação de software, com

recursos melhorados que por GPOs.

Na questão da documentação, como disse, é bom usar uma

intranet e uma ótima ferramenta para isso é o sharepoint, em

que a versão gratuita oferece grandes recursos que podem

auxiliar, uma boa estrategia para a parte de documentação é

criar categorias tais como: Máquinas Clientes e Servidores e

dentro delas colocar subcategorias, tais como resolução de

problemas, configuração de aplicativos e etc.

Uma outra opção é usar o WordPress como Base de

Conhecimento que pode ser visto neste post e também o

GLPI que possui uma parte para colocar as soluções para os

chamados, além de colocar na base de conhecimento do

próprio sistema.

Então pessoal com isso terminamos mais uma fase do ITIL e

no próximo post começaremos a parte em que a ITIL é mais

empregada que é a Operação do Serviço, que é onde as

coisas acontecem, então até lá.

Como Implementar ITIL nas pequenas e médias empresas – Parte 7

 

Salve, salve pessoal do Cooperati, vamos prosseguir

com a nossa série de Como implementar ITIL nas Pequenas e

Medias empresas, no nosso post anterior finalizamos a fase

de Transição de Serviços, que discute como deve ser feito os

testes e a documentação de todo o processo que foi

desenhado para que na hora da real implementação nada

fique despercebido ou que as chances disso ocorrer sejam a

menor possível e principalmente que quando ocorrer falhas

no sistema a sua empresa esteja munida de ferramentas para

solucioná-los o mais rápido possível.

Mas e se algo passar em branco ou se um dos

problemas que foram diagnosticados na fase anterior

acontecer, como proceder? É pensando nessa questão que

entra a Fase de Operação de Serviços, nela é citado tudo o

que ocorre na parte operacional dos sistemas de TI, e

normalmente muitos resumem a ITIL a essa etapa ou

começam a implementa-la por aqui, sem verificar as etapas

anteriores que como visto são tão importante quanto ela.

Então vamos lá, o primeiro processo dessa fase que

entra em ação quando algo acontece fora dos padrões é o

Gerenciamento de Eventos. Esse processo emite alertas de 3

tipos: Informação, Aviso e Erro.

O primeiro como dito é alguma informação do tipo, um

serviço iniciou ou parou, que alguma tarefa foi realizada com

sucesso entre ações similares, como o nome disse é uma

informação onde você pode tomar alguma ação ou ignora-la.

O segundo tipo, que é o aviso, já merece um pouco mais de

atenção, pois ele serve como um alerta de que algo talvez

não esteja funcionando da maneira correta e que pode

interferir ou não no andamento do sistema, um exemplo de

aviso é: a memória do servidor está chegando ao seu limite

ou o espaço em disco está chegando perto de um nível

critico, você pode tomar uma ação ou não, vai depender de

como você achar que deve proceder. Já o terceiro tipo pode-

se resumir em “A casa caiu”, pois como o próprio nome diz,

ocorreu um erro ou exceção e alguma coisa do sistema não

está funcionando e isso vai acarretar em mau funcionamento

do próprio, esse tipo deve ser tratado com todo o carinho

possível, pois quando ele acontece ou algo vai parar ou já

parou e sua situação está delicada.

O Gerenciamento de Evento também é um ótimo auxilio

para o Gerenciamento de Problemas e o Gerenciamento de

Incidentes que serão falados posteriormente, pois como foi

dito, eles dão a ideia exata de onde a exceção está ocorrendo

(ou pelo menos essa devia ser a função, por essa questão que

um sistema deve ser bem documentado e principalmente

mostrar as suas exceções ou erros bem detalhadas para que

a detecção e a resolução da anomalia possam ser rápidas e

indolores).

Essa etapa também tem alguns extras que merecem ser

mencionados, como falado a base para que esse processo

ocorra é ter um sistema de eventos bem detalhado ou pelo

menos de fácil entendimento e isso pode variar de sistema

para sistema, se for um sistema pequeno talvez aparecer um

pop-up na tela passando a informação que deseja seja o

suficiente, mas se você quer incrementar o seu

gerenciamento de evento dependo da ação que o usuário

tome deva ser registrado em logs, que são a forma mais

difundida de gravação de eventos e que muitos de nós já

utilizou ou utiliza frequentemente, mas não caia na tentação

de querer gravar tudo o que ocorre, pois você terá tanta

informação que acabará se perdendo ou cansando de

procurar o que precisa, então tenha como meta: guarde

somente aquilo que será realmente necessário para você ou

para quem for dar assistência ao sistema.

Porém um bom Gerenciamento de Eventos é aquele que

possa ser programado para emitir um alerta assim que algo

de importante aconteça e para quem programa isso tenha

que por em mente que essa informação tem que chegar a

quem realmente necessita saber, não adianta disparar um e-

mail para N pessoas e nenhuma delas dará confiança ou até

precise saber, mas pensa a outra pessoa também recebe e vai

verificar isso e vice-versa, como diz um ditado “Cachorro com

2 donos morre de fome”.

E para exemplificar um sistema de Gerenciamento de

Eventos no lado Windows temos o nosso bom e velho

Visualizador de Eventos que armazena várias informações

por tipos e se bem configurado guarda aquilo que realmente

interessa, além de ter filtros para verificar somente um tipo

de evento ou quais eventos ocorreram em uma determinada

data, além de ser integrado com o Perfmon que fica verifica

se um determinado evento ocorre e dispara um aviso a quem

interessa. Juntos essas ferramentas podem evitar várias

dores de cabeça futuras.

E do lado Linux temos o arquivo messages que fica

dentro /var/log/messages que informa as mensagens de

sistema e as armazenam nele, e que podem ser gerados

scripts para verificar e filtrar determinados eventos e

executar as devidas ações, no Linux geralmente os sistemas

possuem seu próprio arquivo de eventos e cada um tem a sua

localização, mas na documentação do produto possui o

arquivo (pelo menos nos programas que se prezem) e

também podem ser tratados da mesma maneira.

Porém existem eventos que já são conhecidos e podem ser

tratados sem ter que passar por uma intervenção de nível

superior e que podem ser resolvidos pelos níveis inferiores

de atendimento e nessa etapa possuem pessoas que seguem

alguns roteiros para poder tratar esses eventos de uma

maneira mais rápida.

Esse tipo de atendimento também possui um processo

chamado de Cumprimento de Requisição, neste processo são

tratadas todas as requisições que podem ser atendidas de

uma forma rápida e que não comprometem ao bom

andamento dos negócios e funcionamento da empresa,

dentre essas requisições estão troca de senha de usuário,

instalação de softwares pré-aprovados e etc.

Uma característica especifica desse processo é que

geralmente quem trabalha nessa parte, tem um roteiro a ser

seguido e são o primeiro contato do usuário com a resolução

de problemas e em alguns locais são eles que escalonam para

onde o problema vai ser direcionado, se caso eles não

conseguirem resolver a requisição.

Este processo, repetindo, por poder ser um ponto de contato

primário ele também age como um ponto de tira-dúvidas do

sistema da empresa.

Geralmente, o setor que cumpre o papel de Cumprimento de

Requisição possui mais pessoas que os outros setores, por

justamente serem mais demandados e um outro ponto é que

a pessoa para estar nesse setor não precisa ser totalmente

técnica, sabendo operar um sistema que o guia para instruir

o usuário já é o suficiente.

Para elucidar melhor o que digo, todo mundo aqui já ligou

para uma empresa de algum sistema para poder reativa-lo ou

tirar alguma dúvida, então quem te atendeu você não sabe se

era alguém técnico ou não, mas que provavelmente resolveu

a sua requisição ou dúvida, este processo é muito importante

dentro de uma empresa, pois ele alivia os outros setores, mas

como no nosso caso estamos falando de pequenas e medias

empresas, então no caso das empresas que possuem o EU-TI-

SMO, geralmente é uma pessoa para realizar tudo, mas uma

dica para esse tipo é investir em treinamento no sistema para

que as requisições que chegarem a você sejam aquelas que

realmente precisariam chegar e não aquelas dúvidas que com

um simples treinamento poderia ser esclarecida.

Mas se possuir mais de uma pessoa no setor pode haver um

revezamento entre elas para que cada um possa realizar as

outras tarefas ou se haver uma disparidade grande de

conhecimento, deixe a que possui um pouco menos de

conhecimento fazer esse procedimento e a outra para

resolver os problemas mais sérios, e não é desmerecimento,

já que quem está realizando a função de Cumprimento de

Requisição pode aprender muito com algumas dúvidas dos

usuários.

E para auxiliar mais o processo de Cumprimento de

Requisição, uma parte da documentação gerada no processo

de Gerenciamento do Conhecimento pode ser liberada para

ele, assim a informação é passada de forma mais rápida e

com isso uma boa ferramenta para isso continua sendo o

Sharepoint Foundation ou o GLPI que possui uma sessão

somente para soluções de problemas, onde as soluções

conhecidas são liberadas.

Mas e se caso o Cumprimento de Requisição não conseguir

sanar a requisição do usuário? Como foi dito passa-se o

problema para o Gerenciamento de Incidentes ou o

Gerenciamento de Problemas, e este será o assunto do nosso

próximo post dessa série, espero que possam tirar algo de

proveito do que foi passado aqui, até a próxima.

Como Implementar ITIL em pequenas e médias empresas – Parte 8

 Salve, salve pessoal do Cooperati, vamos dar prosseguimento a nossa série de Como Implementar ITIL nas Pequenas e Médias empresas, no post anterior iniciamos a fase de Operação de Serviços, e como falado, aqui é onde as coisas acontecem, é estruturado o que fazer para que as coisas funcionem e se der algo de errado como resolver da melhor maneira possível.

Nós já falamos de dois processos dessa fase que são: Gerenciamento de Eventos e Cumprimento de requisição. O primeiro lida com os eventos gerados pelos sistemas e processos dentro da empresa e fala como lidar com eles quando aparecem, se devem tomar alguma ação ou não e o segundo é o contato inicial do usuário com o setor de TI para resolver alguma pendência na área, seja retirar uma dúvida, solicitar alguma troca que não interfira no funcionamento da empresa, ou seja, desafogar os setores dos próximos assuntos a serem falados, que são o Gerenciamento de Incidentes e o Gerenciamento de Problemas.

Estes dois processos, talvez sejam os processos mais intimamente ligados dentro de todo o ciclo da ITIL, pois um depende do outro para funcionar, mas para começarmos temos que explicar a diferença entre incidente e problema. Incidente é algo que não está funcionando em seu estado

normal, ou seja, algo que causou algum tipo de dano aos serviços de TI, seja de pequeno ou grande porte. Exemplo: um computador de um usuário parou.

Problema é a causa ainda não explicada do incidente, dando prosseguimento ao exemplo do incidente um exemplo de problema seria: um computador parou, mas a causa aparente da parada é desconhecida.

Perceberam a relação entre eles? O Gerenciamento de Incidentes tem como ponto principal, voltar à atividade normal o mais rápido possível, ou, no mínimo, dentro do prazo acordado no SLA, que foi criado no Gerenciamento do Nível de Serviço.

Geralmente esse tempo é definido por categorias, e obviamente os processos mais críticos tem que voltarem o mais rápido possível, pois se ficarem parados causarão grande dano seja a reputação ou ao financeiro da empresa.

Um bom método para definir o que deve voltar o mais rápido possível é seguir os passos: Identificar, registrar, categorizar e priorizar.

A parte de identificar consiste em ver aonde o incidente ocorreu e posteriormente registrá-lo. Completando o nosso exemplo, uma identificação seria: o computador de Fulano que fica no setor de vendas parou de funcionar, sem uma causa aparente. Esse texto já identifica o incidente e já está pronto para ser registrado, com isso a parte de categorização já ficaria facilitada, pois você poderia ter uma categoria principal chamada computador e uma sub-categoria chamada interrupção de funcionamento, onde o nosso exemplo se encaixaria e consequentemente a priorização também estará facilitada.

Nota: A forma como fazer uma boa categorização de incidentes, ficará para um post futuro, por se tratar de algo bastante extenso.

A priorização se dá por dois critérios, impacto e urgência, estes dois critérios parecem o mesmo mas não são, o impacto seria a abrangência do incidente, ou seja qual a expansão do problema e urgência e o quanto rápido este incidente deve ser resolvido, mas nem todo grande impacto é uma grande urgência e vice versa. Um exemplo de impacto alto e urgência baixa: o sistema online de cotação do dólar que o financeiro usa, não está funcionando, porém eles conseguem usar uma forma manual de coletar a cotação, então o impacto é alto pois eles terão que realizar mais de uma tarefa para conseguir o que queriam, mas irão conseguir, com isso a produção não fica totalmente parada e um exemplo de urgência alta e impacto baixo é um sistema online de ações que um gerente usa, não está funcionando corretamente, porém se ele precisar de uma informação na hora e não conseguir, o caos estará implantado, mesmo atingindo uma só pessoa a urgência é grande já que uma pequena falha elevará o impacto para alto.

Ah, não se esqueça de votar no CooperaTI para o TOP BLOG 2012 e também de participar do projeto curso grátis!

Para isso podemos montar uma tabela de impacto x urgência e definir inicialmente 3 niveis: Alto, médio e baixo e com isso ficará muito fácil definir o que deve ou não ser solucionado.

Nota: Um modelo de criação de tabela urgência x impacto pode ser visto no link:http://www.administradores.com.br/informe-se/artigos/matriz-de-priorizacao/25080/

Feito estas etapas o passo seguinte é partir para a resolução. A primeira etapa é fazer um diagnostico inicial, onde alguns procedimentos básicos serão realizados, geralmente esta etapa é realizada pelo nível mais baixo do Gerenciamento de Incidentes, pois a maioria dos incidentes que ocorrem são incidentes conhecidos e suas ações já foram documentadas, ou pelo menos deveriam estar, se você já chegou até essa etapa da ITIL, caso a resolução não for possível então começa um novo processo no Gerenciamento de Incidentes que é a etapa de escalonamento, existem dois métodos de escalonar, o escalonamento funcional, onde os problemas são passados de nível de atendimento, por exemplo, o nível 1, cuida da parte de desktop, o nível 2 da rede e o nível 3 dos servidores, onde o nível 3 é o mais alto da pirâmide e geralmente é o menos utilizado porém é mais especializado e o hierárquico onde é passado por posições ocupadas dentro da empresa, por exemplo, técnico, analista e gerente, este nível é mais utilizado onde há duvidas para onde enviar um registro de incidente e o nível superior definirá isso.

Nas PMEs, que não adotam o EU-TI-SMO, geralmente o nível 1 também cuida do cumprimento de requisição e caso a pessoa não esteja capacitada passa para o superior e no caso

do nível hierárquico geralmente passa diretamente para os responsáveis da empresa, já que o recurso humano na TI é escasso, e geralmente eles não gostam de ser incomodados quanto a assuntos de tecnologia, para isso o processo de conscientização é primordial.

Após isso, é necessário investigar e diagnosticar o problema, esta etapa é de suma importância pois nela verifica exatamente o que está acontecendo erroneamente e diagnostica-lo, caso esse tipo de incidente já esteja registrado basta aplicar a correção mas caso não esteja registrado ou as soluções documentadas não funcionarem o Gerenciamento de Problemas é acionado, pois eles são responsáveis por fazerem a verificação da causa raiz do incidente que se tornou um problema e assim que terminar a verificação mais detalhada voltam alguma solução para o Gerenciamento de Incidentes.

Esta etapa é muito importante, pois caso realmente tenha que ser passado o problema para o Gerenciamento de Problemas, as informações que forem para lá terão de serem bem claras e objetivas, além de não serem passadas faltando detalhes, pois com isso a resolução poderá vir bem mais rápida e como existe o tempo de volta previsto em contrato, talvez uma solução seja temporária até ter uma definitiva e para isso chamamos de Solução de Contorno, que não deixa de ser uma resolução para o problema.

Assim que tiver com uma solução em mãos, seja ela definitiva ou não, é partir para a resolução do problema (lembrando nem sempre as soluções propostas podem funcionar, caso isto ocorra, como falado anteriormente, o incidente deve ser repassado para o Gerenciamento de Problemas.

No caso das PMEs, geralmente quem cuida do Gerenciamento de Problemas é o nivel mais avançado do Gerenciamento de Incidentes, pois por ter pessoal mais capacitado, eles conseguem detectar o problema com mais facilidade, então podemos ver que nesse estilo de empresa, o funcionamento da estrutura fica assim:

- Cumprimento de requisição e Gerenciamento de Incidentes de 1º nivel são colocados aos cuidados do mesmo setor.

- Gerenciamento de Incidentes de 2º e 3º nivel (se existir) e Gerenciamento de Problemas são colocados aos cuidados do mesmo setor.

Esta estrutura, na maioria dos casos, funciona em harmonia, pois quem desempenha estas funções tem que desenvolver o seu serviço em ligação com os processos citados.

O Gerenciamento de Incidentes também contém um aspecto importante para o setor de TI dentro da empresa, se as soluções são apresentadas dentro de um tempo hábil a TI estará com conceito bom, caso não, vem as dúvidas e reclamações e retirar esse pensamento será bem mais complicado então manter esse processo em conformidade é de vital importância, talvez por isso que seja o que a maioria dê mais atenção a esse setor e esquece dos outros, mas para isso funcionar da melhor maneira possível e bom usar um sistema para controlar isso e novamente poderemos usar o GLPI, pois o mesmo tem uma função especifica para controle de chamado, integração com o AD, relatório de estatísticas para verificar os chamados mais abertos, com inúmeros filtros, uma ferramenta bastante poderosa nesse quesito.

Com isso chegamos ao fim de mais um processo, no próximo post falaremos sobre o Gerenciamento de problemas e como ele deve agir até lá.

Como Implementar ITIL nas pequenas e médias empresas – Parte 9

     Salve, salve pessoal do Cooperati hoje vamos continuar a nossa série sobre Como Implementar ITIL nas pequenas e médias empresas, no post anterior falamos sobre o Gerenciamento de Incidentes e vimos que ele é de fundamental importância para que a avaliação da TI dentro da empresa seja boa e com isso ela consiga trabalhar de uma maneira mais confortável, já que, um setor de TI pressionado não consegue exercer as funções adequadamente.

       Mas para que o setor de incidentes funcione de uma maneira satisfatória, outro processo da ITIL tem que ter um funcionamento satisfatório também, estamos falando do Gerenciamento de Problemas, ele lida com os incidentes que o Gerenciamento de Incidentes não consegue resolver, pois recapitulando incidentes é algo que cause uma parada em algum serviço na empresa cujo a causa seja conhecida, caso

a causa seja desconhecida se torna um problema e quem cuida disso é o Gerenciamento de Problemas.

        O principal objetivo deste processo é eliminar que incidentes ocorram novamente ou minimizar quando eles não são conhecidos. As fases com que se lida com um problema geralmente são as mesmas que se lida com um incidente.

        A primeira etapa é a detecção, registro, categorização e priorização do problema, só que para essa etapa ser rápida e eficiente, o Gerenciamento de Incidentes tem que passar as informações necessárias e adequadas através de abertura de chamado de problema, já que é ele que define quando um incidente torna-se um problema, com estas informações o Gerenciamento de Problemas detecta qual é o caso real e logo após registrá-o para assim, começar a tomar as devidas ações.

 Nota: A maneira como fazer os procedimentos citados acima são os mesmos dos citados no post anterior.

        Logo após realizar os passos acima, começa a parte de resolução do problema, a primeira delas é investigar e diagnosticá-lo. Esta etapa é um pouco diferente da parte do Gerenciamento de Incidentes, já que neste processo não se tem uma base do que está ocorrendo e as pessoas dão as soluções através de bases de conhecimentos externas ou através da vivência na profissão.

       Nesta etapa não necessariamente tem que se dar uma solução definitiva, soluções de contorno podem ser usadas para que este problema não tome proporções maiores, já que, se existe um problema algo não está funcionando e precisa voltar a normalidade o mais rápido possível. Assim que uma solução de contorno seja encontrada, imediatamente deve ser passada ao Gerenciamento de Incidente para que eles a apliquem para mitigar os efeitos que o problema possa ter causado.Participar do projeto curso grátis!

       Se a solução de contorno funcionar, ela deve ser registrada no registro do problema e colocado como uma solução de contorno e divulgado para todos. As soluções de contorno são uma boa tática para que o Gerenciamento de

Problema possa trabalhar de uma forma mais tranquila, sem a pressão de ter que resolve-lo de uma forma definitiva, mas ele não elimina que o problema tenha que ser resolvido por definitivo. Porém se ela não funcionar o passo de investigação e diagnostico do problema tem que ser reinicializado até alguma solução ser encontrada.

       Assim que uma resolução for encontrado, seja ela de contorno ou definitiva, deve ser registrada na base de conhecimento, pois assim o Gerenciamento de Incidentes pode aplicar a correção sem passar para o Gerenciamento de Problemas.

       Se a solução definitiva for encontrada o registro do problema deve ser fechado e feito as devidas considerações, e relatado qual foi a causa raiz, se na implantação, se no desenvolvimento e etc. e colocar a descrição do que deve ser feito para que isso não ocorra novamente.

      Uma boa forma para que um Gerenciamento de Problemas possa ser feito adequadamente é colocar os profissionais mais experientes neste setor, mas como estamos falando de PMEs, como já falamos bastante aqui, o principal problema é a parte de Recursos Humanos, então se você dispõe de pouco material siga o que falei cima, caso seja um EU-TI-SMO, você vai ter que analisar e categorizar entre incidentes e problemas, uma boa dica para isso é resolver os incidentes mais simples, que você sabe que o tempo de resolução é curto e deixar os mais longos para depois, a única exceção é se o problema for de caráter emergencial onde algum serviço critico está parado, por isso uma boa categorização auxiliara bastante no seu dia a dia.

        Agora podemos falar do último processo da Fase de Operação de Serviços que é o Gerenciamento de Acesso, este processo está ligado ao Gerenciamento de Segurança, pois nesta etapa é definido quem pode acessar os recursos de TI da empresa definido nas politicas de segurança.

       Mas uma regra básica para essa parte é saber identificar e definir se a pessoa está autorizada ou não a acessar o recurso, mas muitos aqui pensam que este gerenciamento deve ser feito somente na parte de software, ou seja, somente aos sistemas, mas ele também lida com o acesso físico, pois imagina você ter um belo sistema de proteção de

sistemas mas deixa o seu servidor exposto em uma sala aberta onde qualquer um pode abrir ou até mesmo roubar o mesmo, então atente-se a essa parte e caso veja que está faltando, deve ser alertado o Gerenciamento de Segurança para incluir nas politicas de segurança a parte do acesso físico.

        Para implantar uma politica de acesso físico nas PMEs, é um pouco simples, pois são poucos lugares ou geralmente um só que deve ser protegido que é onde fica os servidores, switchs e alguns outros equipamentos e para proteger geralmente são colocadados dentro de uma sala trancada a chave, então como é o único modo de acesso, a chave tem que ser bem guardada.

       Quanto a acesso lógico em sistemas também deve ser levado em consideração, um sistema que não conta com níveis de segurança não é um sistema confiável e se existi-los tem que ser de fácil configuração se não fica inviável a sua implementação, pois você pode acabar perdendo tempo e configuração e deixar o seu sistema vulnerável a questão de acesso indevido.

      Um exemplo prático de como pode ser usado o Gerenciamento de Acesso é a questão dos Domínios de Rede, seja ele por AD ou Samba, já que eles te dão a oportunidade de criar grupos de segurança e colocar dentro desses grupos os membros que poderão ter acessos aos recursos necessários, pois liberar acessos a grupos é a forma mais simples de controle, pois você libera o acesso a eles e caso precise adicionar ou retirar alguma pessoa basta ir direto nos grupos e não ao recurso em si.

        Este recurso é tão simples que vários sistemas acabam integrando estes domínios a sua parte de segurança para facilitar a vida dos administradores de sistemas.

        Então uma dica para ter uma boa implementação desse processo é ter um AD ou Samba bem configurado.

     Bom pessoal com isso chegamos ao fim a parte dos Gerenciamento da Fase de Operação de Serviço, porém nesta fase também existem funções que devem ser implantadas na sua rede entre elas a função de Service Desk e este será o assunto do nosso próximo post até lá.