A empresa Amazon oferece serviços de hospedagem nas nuvens. Um de seus clientes era (isso mesmo, era), pois a parceria não durou uma semana, o famoso site Wikileaks, que faz publicações de documentos confidencias de vários governos. Sem muitas delongas e avisos a Amazon desligou e retirou do ar todo o conteúdo do site.

Tal fato poe na mesa de discussões a respeito do acordo de nível de serviço, em especial quando esse serviço está hospedados nas nuvens. Observe na fragilidade desse contrato entre Amazon e Wikileaks, ele permite que a empresa provedora do serviço encerre a qualquer momento a prestação do serviço, caso, considere a atividade do cliente ilegal e que possa prejudicar terceiros.

Agora pergunto, que SLA é esse que da tanto poder ao provedor de serviços? Essa é uma das características desses acordos para tais serviços na nuvens em favorecimento da própria empresa do que o cliente. Não houve nenhuma decisão judicial obrigando que a Amazon retirasse o site do ar. O que houve foi uma pressão de pessoas ligadas ao governo americano para retirar o site do ar. Alias o fundador do Wikileaks, Julian Assange está com voz de prisão pela Interpol.

Esse é apenas um exemplo, mas mostra a importância de um SLA, e como os termos definidos nele, podem e serão usados contra você, o cliente. Foi exatamente esse o caso, a decisão da Amazon tem valor legal e não nada que o Wikileaks possa fazer, a não ser, hospedar o site em outro provedor, que inclusive já fez.

Grande abraço.

Alexsander Oliveira

Em 2007 foi lançada a versão 3. Quem já estudou a Itil V2 e depois a V3 deve ter observado uma grande e excelente mudança na estrutura.  A V3 está organizada de uma forma muito melhor. Tem muito a oferecer aos provedores de serviços de TI, novos esquemas para certificação e está totalmente alinhada aos processos da ISO 20000.

A Itil V3 aborda os aspectos dos serviços de TI sob a visão de ciclo de vida do serviço que liga\relaciona os estágios: Estratégia do Serviço, Desenho do Serviço, Transição do Serviço, Operação do Serviço, Operação do Serviço e Melhoria Continuada dos Serviços.

Nosso objetivo nesse blog é divulgar, discutir e esclarecer o que são as boas práticas é necessário uma visão geral do que estamos falando no dia a dia. Dessa irei apresentar uma rápida visão dos livros e dos processos envolvendo essa versão.

Estratégia do Serviço (Service Strategy)
Como o nome já sugere, é onde são definidas as estratégias. O foco é se integrar e entender melhor o negócio, identificar as oportunidades no cliente, demandas, risco, financeiro, toda a tomada de decisão.
Esse estagio é composto pelos processos:

1. Estratégia de Geração
2. Gerenciamento Financeiro
3. Gerenciamento da Demanda
4. Gerenciamento do Portfólio

Desenho do Serviço (Service Design)
Como diria o poeta: é preciso ter desenhos (?sonhos?). É o momento de arquitetar o que foi definido na estratégia.
Aqui é um acordo bem famoso, que as pessoas usam erradamente para referenciar o service desk, sabe qual é? É o SLA (Service Level Agreement) – Acordo de Nível de Serviço.
Então esse estágio é que desenha os serviços de TI e o gerenciamento dos serviços de TI. É composto pelos processos:

1. Gerenciamento do Catalogo de Serviços
2. Gerenciamento de Nível de Serviço
3. Gerenciamento de Disponibilidade
4. Gerenciamento da Capacidade
5. Gerenciamento da Continuidade dos Serviços de TI
6. Gerenciamento da Segurança da Informação
7. Gerenciamento de Fornecedores

Transição do Serviço (Service Transition)
Após desenhar o serviço temos que coloca-lo em produção, planejar toda a implantação preocupando com os impactos dela no negócio. Composto pelos processos:

1. Planejamento e Suporte da Transição
2. Gerenciamento de Mudanças
3. Gerenciamento de Configuração de Ativos de Serviço
4. Gerenciamento de Liberação e Implantação
5. Teste e Validação de Serviço
6. Avaliação
7. Gerenciamento do Conhecimento

Operação do Serviço (Service Operation)
É onde de fato é reconhecido o valor do provedor de serviços. Usuários e clientes tendem a enxergar mais esse estágio (É nosso papel evidenciar ao cliente, seja interno ou externo, a importância dos outros estágios).

1. Gerenciamento de Eventos
2. Gerenciamento de Incidentes
3. Cumprimento de Requisição
4. Gerenciamento de Problemas
5. Gerenciamento de Acessos

.

Melhoria Continuada dos Serviços (Continual Service Improvement)
Esse estagio tem seu foco na qualidade. A melhoria dos serviços deve ser algo continuo. Como diria Mario Cortella, na palestra do evento C.O.R.E. Business Teclógica:
A excelência deve ser um objetivo no horizonte, deve ser sempre buscada. E é disso que se trata esse estágio, melhorar todos os outros estágios.

1. Os 7 Passos da Melhoria Continua
2. Medição de Serviço
3. Relatórios de Serviço

É isso, um breve resumo do escopo da versão 3 da Itil. Espero que tenha sido esclarecedor.

Grande abraço e comentem.

Alexsander Oliveira

O processo responsável por essa atividade é o cumprimento de requisição, já o processo de gerenciamento de nível de serviço é responsável por gerencia-la. A literatura explica que essas as críticas e elogios devem ser registrados e as partes interessadas devem ser informadas.

Desse forma, o gerente que controla o nível de serviço deve ficar atento as esses aspectos para que fique claro não apenas com números, todos os feedbacks do cliente e usuário para o provedor de serviços sobre a qualidade dos mesmos e notificação de todos os envolvidos.

Além de ser uma boa prática, pode ser um motivacional, tanto para quando recebermos críticas quanto elogios.

Grande Abraço!

Alexsander Oliveira

Seu objetivo é desenhar os aspetos relacionados aos planos de continuidade e recuperação dos serviços e tem relacionamento direto os gerenciamentos de: Risco, Disponibilidade e Segurança.

Com ajuda da área de negócio deve ser definido o que é crucial para empresa (tal análise é conhecida como Análise de Impacto de Negócio) continuar operando caso ocorra um desastre. Entenda-se que desastres seriam situações onde a empresa pode simplesmente “morrer” se o risco do desastre for realmente efetivado e não houver tais planos de continuidade.

O assunto do momento é o Cloud Computer (Computação na Nuvem) que é basicamente usar recursos (serviços) computacionais fornecidos através da internet.

A Cloud pode ser uma opção para alguns aspectos da continuidade dos serviços de TI. Você pode, por exemplo, manter serviços como: Software, Infraestrutura, Armazenamento, Plataforma de Desenvolvimento na nuvem.  Ou até mesmo usar o conceito de nuvens híbridas, que seria unir o convencional com o Cloud Computer solicitando recursos na nuvem de acordo com a demanda.

Um bom exemplo de empresa que entrega serviços na nuvem é o Google com suas ferramentas de escritório online, Google Docs.

O fato é que ter tais serviços na nuvem pode facilitar ou melhorar cenários de grandes desastres, além de poder ajudar no gerenciamento da demanda. Muitos CIOs observam esse “novidade” com cautela, e com razão. Devido ao fato dessa tecnologia estar em processo de amadurecimento e ainda existem muitas dúvidas no ar referente principalmente a segurança desses serviços. Entretanto existem outros CIOs apostam nessa “revolução”, afinal é atráves disso empresas inovadoras e que saem na frente, assumem riscos.

Toquei no assunto de forma sucinta sobre a continuidade, mas existem outros aspectos interessantes do Cloud Computer correlacionados com a biblioteca de boas práticas. Para prover tais serviços é necessário um nível altíssimo em gerenciamento de serviços de TI, posso citar como cruciais por exemplo: gerenciamento de: risco, evento, disponibilidade, capacidade segurança e por ai vai.

É isso pessoal, um abraço e comentem.

Alexsander Oliveira

O processo Demand Management faz parte do livro Service Strategy. O objetivo é basicamente influenciar toda a demanda do cliente pelos serviços, se esse permitir.  Isto somente é possível se a estratégia da TI estiver alinhada a estratégia do negócio. O que muitas vezes não acontece.

Um exemplo clássico e típico – talvez mais no passado que nos dias atuais – são os preços das ligações durante o período diurno e noturno. Observa-se que a noite, na medida em que o tempo vai passando e as coisas vão se acalmando, os valores vão ficando mais baixos, principalmente no período da madrugada.  Você se lembra da época, em que, com apenas uma ligação a partir das 00:00 conectava na internet, usando aquela linha discada e pagava o preço de apenas uma chamada local? Então, isso eram as companhias telefônicas influenciando a sua demanda.

Ainda no exemplo anterior, os colaboradores da empresa telefônica que suportavam essa infraestrutura no período da madrugada, provavelmente tinham uma ociosidade maior muito maior que o pessoal que trabalhava durante o dia, cheios de atividades, muitas vezes desgastados e já perdendo qualidade no trabalho.  Percebam de um lado o excesso do outro o desperdício.

Se fosse uma fábrica de algum produto seria fácil, não é? Bastaria estocar os produtos durante a   produção noturna, eliminando a ociosidade (Obs: É preciso ter ociosidade, mas não em excesso – O Ócio Criativo), resolvendo os problemas de demanda durante o dia : ). Entretanto, na TI, não é possível estocar serviços.

Para que isso tudo seja possível, o ITIL sugere que seja feito Business Activity Patterns (Padrões de Atividade de Negócio) e User Profiles (Perfis de Usuário), que é sumariamente conhecer as atividades referentes ao negócio e esse relacionamento com os perfis usuários.

Outra exemplo na prática sobre a influência na demanda que é comum pelas concessionárias de energia é incentivar ou penalizar, de acordo com o uso.  A partir de uma determinada faixa (Quanto maior o uso) de kWh o preço pela unidade de kWh fica mais caro.

É a partir do momento em que você começa a entender seu cliente e suas necessidades. Já é possível trabalhar junto com o negócio para influenciar a demanda. Nem sempre é necessário investir em infraestrutura, basta melhorar o uso. Se a TI e o negócio trabalharem juntos, vão conseguir encontrar a melhor solução (CustoXBenefício) para esse problemas.

Alexsander Oliveira

Atualmente quando o suporte se encontra num momento de alta demanda é extremamente complicado conciliar o fluxo de mudança o gestor de problemas hoje tem a  tarefa de mapear desde a abertura de um problema até o fechamento deste por meio da liberação da RFC (Request for Change).

É de suma importância mapear a origem desta RFC que pode ser:

• Incidente
• Problema
• Incidente gerado a partir de monitoramento
• Mudança externa (aumento de preço, regras fiscais etc…)
• Projeto (pacote de melhorias fechado em determinado projeto)

Garantir o conhecimento da origem da RFC também fecha o fluxo da mudança que vai desde a elaboração da RFC até o encerramento do registro da mudança.

A gestão de mudanças está intimamente ligada a vários outros processos, porém vamos nos ater aos processos de gestão de incidentes e problemas que são os processos mais críticos considerando um Service Desk em alta demanda conforme comentamos anteriormente.

Tomando a definição de problema que é ‘causa desconhecida de um ou mais incidentes’ para que o gestor de problemas possa fazer um gestão ideal de problemas a classificação de incidentes é primordial, pois é esta etapa da gestão de incidentes que irá definir a origem de uma possível RFC.

Hoje no suporte temos constantes envios de RFC, melhorias do cliente, melhorias externas, fornecedores enviam changes para nossa validação e envio de correções que não passaram por nosso Service Desk tornando-se um caos mapear qual verdadeira origem da RFC, é importante esta associação de uma mudança a um problema  para que nas reuniões possamos justificar ao nosso cliente que determinado problema teve sua incidência de chamados diminuída por um mudança ocorrida.

Através do ciclo PDCA (ver.: livro Melhoria de Serviço Continua)  temos uma ampla visão de quais problemas tem maior incidência e quais tiveram sua incidência reduzida, mas para o PDCA ser bem alimentado este precisa de informações exatas, uma forma de garantir isso é entendendo a importância deste processo desde a classificação do incidente até o fechamento do problema a partir do registro da RFC.

Mostrar o controle destes processos passa ao cliente uma sensação de organização e segurança de que está valendo a pena contratar o Service Desk para manter o serviço disponível.

O Service Portfolio possui informações sobre serviços já prestados, não mais usados e oferecidos para cliente. A relação com todos os outros estágios é por que o portfólio gerencia o ciclo de vida do serviço.

Está dividido basicamente em três etapas: Service Pipeline, Service Catalog e Retired Services.

Pipeline representa os serviços que são propostos ou que estão em desenvolvimento. Tem participação no Service Design e no Service Transition, necessariamente nessa ordem.

Catalog são os serviços atualmente pelos usuários, isso deve estar documentado no catalogo de serviços. Tem envolvimento Service Transition e depois com o Service Operation, exatamente nessa ordem.

Retired trata dos serviços já desativados que não são fazem parte do ambiente de produção.

Esse é apenas um resumo do que é um Service Portfolio, mas já da pra ter uma boa ideia de como esse item é tratado no Management of Portfolio e como o Service Strategy está ligada ligado aos demais processos, trazendo a tona, a questão da importância do alinhamento entre áreas, destacando genericamente: operacional, técnica e estratégica.

Abraço até a próxima, e comentem.

Alexsander Oliveira

A publicação que me refiro no título deste post pode ser encontrada diretamente no site da editora ou então neste link alternativo.

Numa visão simplista, o Catálogo de Serviços é um artefato que as organizações criam e disponibilizam para seus colaboradores, clientes e parceiros que demonstra ‘claramente’ alguns atributos relacionados aos serviços, sendo os mais comuns:

• Uma descrição do que trata (qual função)  de determinado serviço
• Acordos de Nível de Serviço relacionados
• Privilégios de uso do serviço
• Custos associados ao uso
• Métodos de execução (requisição) de uso

Essa lista de atributos acima mencionada pode ser encontrada aqui, e pode ser complementada com mais algumas especificações:

1. Classificação ITIL
2. Atividades relacionadas à operação
3. Frequência de execução
4. Indicadores explícitos de controle
5. Matriz de Responsabilidade

Para ficar mais claro, acompanhando o Ciclo de Vida do Serviço, temos a seguinte visão:

Voltando à publicação, já no prefácio, escrito por Brian Johnson, é possível ter uma noção importante do impacto, para qualquer organização, de construir e manter um catálogo de serviços adequado.

Ainda no que tange a definição, é importante manter um conjunto de recursos que permitam entender se o catálogo de serviços:

1. É válido?
2. Está atualizado?
3. Tem escalabilidade?
4. Mantem-se relevante ao negócio?
5. Proporciona benefícios aos usuários?
6. Adapta-se as mudanças nas visões de: usuários e negócios?
7. Tem o tamanho adequado aos seus propósitos e uso?
8. Proporciona valor aos negócios e clientes?
9. Facilita a execução das operações da organização num custo acessível?
10. Vale quanto se paga? Tem ROI e VOI?

Uma referência interessante para a representação de um catálogo de serviços pode ser vista na página 17:

Como benefícios do uso adequado do Catálogo de Serviços, os principais benefícios são:

1. Promover a TI como fornecedor de serviços em detrimento ao ‘departamento de tecnologia’
2. Reduz o custo operacional
3. Incremento da produtividade dos processos
4. Propicia um entendimento claro das necessidades do negócio
5. Permite aos usuários que se escolha o serviço adequado as suas necessidades
6. Aumenta a satsifação dos usuários

Entre outros benefícios de relevância.

Bem, fica a dica de leitura.

Até a próxima, Marco Aurélio.

O WordPress.com que oferece um serviço gratuito de hospedagem teve uma pane e saiu do ar por algumas horas no dia 18/02, e deixando 10,2 milhões de blog fora ar. Mas o que isso tem haver com Itil? … Tudo!

Aproveitei a notícia apenas para ilustar alguns aspectos desse fato no mundo do Itil, tentando evidenciar na prática alguns processos dessa biblioteca de boas práticas.

O primeiro e mais evidente deles, o serviço saiu do ar, o que caracteriza um incidente, e que precisar ser resolvido no tempo mais rápido possível. Dessa forma foi contornado (work around) através de uma identificação superficial de onde estava o problema. A prioridade era restabelecer o serviço, colocando as páginas no ar novamente.

Após isso a WordPress afirma que irá investigar a fundo a causa do incidente, ou seja gerencia de problemas irá entrar em ação para identificar a causa raiz do problema ocasionou a parada no serviço.

Um terceiro aspecto é uma mudança não prevista em um roteador importante no DataCenter parceiro, quem ou qual processo fez a liberação dessa mudança no ambiente de produção? O serviço ficou fora por 110 minutos (dowtime). A partir dai já se pode pensar também em nível de serviço, e é bem provavel que existia um acordo de nível de serviço, para estipular o tempo para restabelecer um serviço em caso de incidente com prioridade crítica.

Existem mecanismos de de redundância, mas na hora “H” não funcionaram (disponibilidade e continuidade), talvez por falta de testes adequados, enfim.

A idéia não é encontrar o culpado, e sim identificar as lacunas em cada processo e aperfeiçoa-lo, é um ciclo constante por melhoras. Provavelmente além desses existem outros aspectos que possam ser abordados, caso alguém enxergue algum outro, por favor, comentem.

Um abraço!

Alexsander Oliveira

Site: www.tiexames.com.br