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

Tendo em vista as inúmeras dúvidas que esta norma tem gerado, principalmente com o ITIL, este artigo mostra uma visão geral comparativa entre ambos, que tratam do mesmo assunto.

A primeira dúvida é sobre a diferença entre o ITIL e a ISO/IEC 20000.

O ITIL, acrônimo para Information Technology Infrastructure Library, que em português significa Biblioteca de Infra-estrutura de Tecnologia da Informação, é um conjunto das melhores práticas para o gerenciamento dos serviços de tecnologia da informação (TI).

A ISO 20000 é uma norma internacional que tem como objetivo regulamentar, no âmbito mundial, o padrão para o gerenciamento de serviços de tecnologia da informação.

O ITIL é flexível enquanto a norma tem uma série de exigências que devem ser seguidas para que a organização possa ser certificada.

O ITIL e a norma ISO 20000 têm em comum a meta de fornecer um conjunto de processos estruturados e com qualidade para gerenciar os serviços de TI.

Outra dúvida muito comum é quanto aos processos de certificação.

O ITIL, por meio das entidades EXIN e ISEB, fornece três níveis de certificação: O ITIL Foundation, O ITIL Practitioner e o ITIL Master. Em resumo, o ITIL capacita e certifica os profissionais de TI.

A norma ISO 20000 tem como objetivo certificar as empresas. Esta certificação se dá por meio de auditorias efetuadas por empresas certificadoras, as quais avaliam se a organização está em acordo com a norma e, em caso positivo, emite o certificado. Da mesma forma que outras normas ISO, a ISO 20000 tem como exigência a reavaliação periódica da empresa certificada, ou seja, uma vez certificada, a empresa terá que se preparar, periodicamente, para novas auditorias.

A certificação dos profissionais em ITIL, ao contrário da norma, não exige reavaliação, ou seja, uma vez certificado, a validade é definitiva.

A ISO 20000 se divide em duas partes. A ISO 20000-1, que trata da especificação para a gerência de serviços de TI e ISO 20000-2 que trata do código de prática para a gerência dos serviços de TI.
Resumidamente, a primeira parte trata dos processos que devem ser implementados e a segunda trata da avaliação do foi implementado na primeira.

Uma informação importante: No mercado já é consenso que a implantação das melhores práticas ITIL e a certificação dos profissionais nos fundamentos ITIL auxilia na obtenção da certificação ISO 20000 pela organização.

O Makro criou um quadro de regras de priorização de incidentes de TI e uma base de conhecimento documentada desses problemas, para que todo e qualquer um dos 35 funcionários da área de tecnologia possa agir e tomar a ação necessária. “Agora ninguém mais usa o ‘eu acho’. Há regras de prioridade, caracterização e grau do problema, quem deve ser chamado e o que deve ser feito”, diz Souza.

A base de conhecimento construída pela área de TI do Makro possui cerca de 150 scripts, ou roteiros de procedimentos para resolução de incidentes e demandas – desde um usuário que esqueceu a senha cadastrada, até a queda de um link de dados que tira uma loja inteira do ar.

Sem esse roteiro, se uma chamada para a TI entrar pelo caminho errado, a pessoa que a receber pode não perceber que é um problema crítico. E atrasos podem fazer a loja perder vendas ou irritar os clientes com grandes filas nos caixas que ainda funcionam.

Existe um livro da versão três (V3) do Itil (Continual Service Improvement, 2007) que trata exclusivamente desse tema. É intitulado como um guia prático em avaliação e aperfeiçoamento da qualidade dos serviços, e é indicado para pessoas ligadas as boas práticas de gerenciamento dos serviços de TI que, pretendem compreendê-las e melhorá-las continuamente. Baseado no ciclo de Deming conhecido como Plan, Do, Check and Act, o famoso PDCA.

São definidos 7 passos para o processo de melhora continua.

1 – Definir o que você deve medir.
Converse com as pessoas do negócio, clientes, gerencia de TI. Utilize o catalogo de serviços como ponto inicial bem como os requisitos de níveis de serviço de diferentes clientes. No cenário ideal, o que deveria ser medido?O que é importante para o negócio?
Faça uma lista do que você entende que deveria ser medido, mas não uma lista complexa, seja objetivo.

2 – Definir o que você pode medir.
As organizações podem encontrar limitações no que ela está medindo, o fato é que, se você não pode medir, não deve nem aparecer no acordo de nível de serviço.
Identifique as ferramentas que você usa atualmente para isso. Essas ferramentas incluem softwares de gerenciamento, monitoramentos, relatórios, investigação, entre outros. Nessa etapa é possível inclusive identificar oportunidades.

3 – Coleta de dados.
Os dados coletados devem estar baseados nas metas e objetivos. Essa coleta pode ser feita por ferramentas de gerenciamento de monitoramento. Nesse ponto a informação que vem é bruta, ainda não está transformada e trabalhada, porém é importante que esteja estruturada de padronizada.

4 – Processamento de dados.
Nessa etapa os dados são processados de acordo com os anseios da melhora continuada do serviço e com os indicadores de desempenho. Ou seja, os dados serão processados de acordo com os objetivos de seu gerenciamento. As origens desses dados podem ser, por exemplo, de ferramentas de monitoração, relatórios, etc.

5 – Análise dos dados.
É nesse ponto que os dados são transformados em informação para identificar as lacunas nos serviços, tendências e impactos sobre os serviços.
Essa análise de dados transforma a informação em conhecimento e trás habilidades para organização.

6 – Apresentar e usar a informação.
As perguntas sobre o porquê de determinada informação foi pega e trabalhada são respondidas aqui. A idéia é apresentar exatamente os resultados que seriam obtidos com as melhorias.

7 – Implementar as ações corretivas.
O conhecimento aprendido é usado para aperfeiçoar, melhoras e corrigiradequar os serviços. O pessoal normalmente identifica os problemas e as soluções, entretanto é necessário controlaracompanhar esse processo de melhoria. As ações corretivas precisam ser tomadas para prover as melhorias necessárias ao negócio. Dessa forma cria-se uma baseline e novos ciclos são iniciados.

A melhora continuada dos serviços, trás diversas oportunidades a organização. Baseado em suas metas, objetivos e tipos de serviços prestados, você pode priorizar as atividades e iniciativas de melhorias.

Cada uma dessas etapas, integradas foram um ciclo, conforme a OGC no livro Continual Service Improvement, elas constituem uma espiral do conhecimento. Nas práticas atuais, conhecimento acumulado e sabedoria derivam desse conhecimento.

Alexsander Oliveira

Exemplos de um evento:
1 – Alerta que a memória de um servidor constantemente com 90% de uso.
2 – Aviso que o disco do servidor já está completamente cheio.
3 – Antivírus desatualizado.

É evidente que o primeiro nível de uma equipe suporte a serviço não irá monitorar todos seus 180 servidores um a um e muito menos equipe do segundo nível. Nesse contexto, destaca-se a importância de ferramentas eficientes para gerar tais eventos. Ferramentas de monitoramento ajudam e muito uma equipe ser pró-ativa. Conheço duas que fazem esse trabalho de forma eficaz,  são elas: CMDB Discovery que é inclusive gratuito por um ano e o Nagios.  Ambas as ferramentas são poderosíssimas, utilizadas também na gerencia de configuração, através do mapeamento de todos os ativos da T.I.

A ferramenta, dentro de um grande ambiente é um fator importante, porém não é o único. É a análise do evento gerado por tal ferramenta, que será feita por pessoas,  é que é um fator crucial. Nesse momento a análise poderá: indicar tendências, problemas, necessidade de mudanças no ambiente, registrar incidentes (Que provavelmente ainda nem é de conhecimento do usuário).

No caso do exemplo 1. Poderia gerar uma entrada para a gerência de mudanças. Podendo ser, por exemplo, de dois tipos: Otimização do software para melhor uso da memória ou até mesmo necessidade de mais memória para atender os requisitos de negócio.

Já no caso do exemplo 2, fica bem claro que a saída do evento será um incidente, pois o disco está cheio e precisa de uma ação paleativa o mais rápido possível pela equipe de suporte.

O uso de ferramentas poderosas, aliadas a uma equipe bem treinada, preparada e que enxerga benefícios no uso das boas práticas, gera valor para uma equipe de SLA. Meu ponto é esse. O valor para o negócio será uma conseqüência de uma equipe bem treinada e consciente. É muito melhor ser pró-ativo. Entender o impacto dos eventos na infra-estrutura é ter excelência no suporte a serviços. Esse é o grande diferencial.

Alexsander Oliveira

Tem como principais objetivos:

1. Fazer seu dinheiro ter o valor adequado e justo
2. Ajustar o arcabouço jurídico (contratos) em conformidade com as demandas do negócio
3. Gerenciar o relacionamento e a performance dos fornecedores

O Processo de Gerenciamento de Fornecedores presta atenção aos fornecedores e aos contratos de fornecimento de serviços recebidos pelo comprador. Via de regra, quanto maior a contribuição de um Fornecedor ao negócio maior o esforço dispendido no gerenciamento da relação – nao poderia ser diferente.

Resumidamente, os seguintes aspectos devem ser considerados:

• Políticas de inclusão e manutenção dos fornecedores
• Centralização (base de dados) para os contratos
• Categoriação dos fornecedores e o risco de invesitmento
• Avaliação de Contratos
• Negociação e Aprovação de Contratos
• Revisão, Renovação e Término dos Contratos

Tudo tem um começo

Parece simples quando assim descrito, mas como fazer para manter um bom ciclo de vida de um contrato? A proposição da ITIL é a de se seguir e armazenar os seguintes itens:

1. Identificação dos Requisitos
2. Seleção dos fornecedores
3. Categorização
4. Regulação
5. Gerenciamento
6. Renovação ou Término

Para que se alcance os objetivos da relação, ambas as partes devem estabelecer diretrizes com base em informações mútuas que permitam um relacionamento franco e produtivo e, para que isto se torne verdadeiro, algumas informações importantes devem ser compartilhadas, a  saber:

1. Informações sobres os negócios (Planos, Estratégias e Horizontes)
2. Estratégias de suprimento e contratos
3. Plano de Negócios Detalhado
4. Informações de Performance

Fica a breve visão a respeito, na certeza de que muito há de se explorar no tema.

Forte abraço!

Neste post comento sobre algumas das publicações disponibilizadas nos sites de ambas empresas.

Na publicação da CA, com título “Foundations of IT Service Management Based on ITIL V3” (o link contém apenas dois capítulos dos 13 disponíveis) é possível encontrar conceitos interessantes, a saber:

Benefícios e Riscos dos frameworks ITSM

Benefícios para o cliente / usuário:

1. a prestação de serviços de TI se torna cada vez mais focada nos clientes e os acordos de nível de serviços melhoraram a qualidade da relação
2. os serviços são descritos de melhor forma, na linguagem dos clientes, e com maior nível de detalhamento
3. melhor gestão da qualidade, disponibilidade, confiabilidade e o custo dos serviços são geridos de melhor forma
4. a comunicação com o departamento de TI é melhorada através da concordância sobre os pontos de contato

Benefícios para o IT organização:

1. o departamento de TI desenvolve uma estrutura mais clara, se torna mais eficiente, e está mais centrada sobre os objetivos corporativos
2. o departamento de TI está mais focada no controle da infra-estrutura e de serviços, por consequência, as mudanças se tornam mais fáceis de gerir
3. uma estrutura eficaz nos processos promove um framework efetivo para o outsourcing dos elementos dos serviços de TI
4. seguir as melhores práticas incentiva uma mudança cultural para a prestação de serviço, e apoia a introdução de sistemas de gestão da qualidade baseado na série ISO 9000 ou na ISO / IEC 20000
5. frameworks podem proporcionar coerentes conjuntos de referência para a comunicação interna e comunicação com os fornecedores, e também para a padronização e identificação dos processos

Potenciais problemas / erros:

1. a implementação pode demorar muito tempo e exigir esforço significativo, podendo exigir uma mudança da cultura na organização, e uma introdução exarcebada pode levar à frustração, já que os objetivos nunca serão atingidos
2. se a estrutura do processo tornar-se um objetivo por si só a qualidade do serviço pode ser intensamente afetada; neste cenário, o execesso de engenharia serão vistos como burocráticos e tornar-se-ão obstáculos que devem ser evitados em sua plenitude
3. não há melhorias nos serviços de TI devido a uma fundamental falta de compreensão sobre os processos relevantes que devem ser providenciados, quais indicadores de desempenho são apropirados e como os processos devem ser monitorados e controlados
4. a melhoria na prestação dos serviços e a redução dos custos podem não ser suficientemente visíveis em função da falta de baselines de comparação indisponíveis ou mesmo os objetivos foram identificados erroneamente
5. uma implementação bem sucedida exige o envolvimento e empenho do pessoal em todos os níveis da organização, deixar o desenvolvimento das estruturas dos processos um especialista (ou um departamento) pode isolar esse serviço na organização e pode-se definir uma orientação que não será aceita pelos outros departamentos
6. se investimento for insuficiente em ferramentas apoio, não haverá justiça nos processos e os serviços não serão melhorados; recursos adicionais (financeiros e pessoal) poderão ser necessários no curto prazo, se a organização já está sobrecarregado por rotinas TI advindas de framworks que não adotem as melhores práticas

Já na publicação da Van Haren, “ITIL and Software Lifecyle: Practical Strategy and Design Principles” há excelentes princípios:

Resumindo o Ciclo de Vida de Serviços

Em termos gerais, o livro salienta as necessidades de comunicação entre os clientes de Serviços de TI, desenvolvedores de software e gerentes operacionais; salienta a necessidade de cada um de forma a compreender as necessidades dos outros, e como essas requisitos são gerenciados através de um Ciclo de Vida. Ela demonstra que a criação (uso) de serviços TI não pode ser bem sucedida se as operações forem realizadas de forma unilateral, o que, tradicionalmente, tem sido o foco para projetos relacionados com ITIL.

Ainda que os trechos aqui disponibilizados sejam apenas resumos dos assuntos, fazem-se importantes já que abordam temas que em muitos casos carecem de atenção, de forma especial aqui no Brasil onde a adoção de frameworks tem se ‘alastrado’ e junto com o movimento o perigo da abordagem errônea.

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