Upload
roberto-klayton-m-barros
View
235
Download
6
Embed Size (px)
Citation preview
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á.