Itil conceitos obtidos em blogs e sites

  • 231 views
Uploaded on

ITIL - Uma forma inteligente de gerenciar serviços de TI. Compilado de definições, textos e conceitos obtidos em sites e blogs do assunto. Muito bom !

ITIL - Uma forma inteligente de gerenciar serviços de TI. Compilado de definições, textos e conceitos obtidos em sites e blogs do assunto. Muito bom !

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
231
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
20
Comments
0
Likes
3

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. ITIL V3 – Introdução e Conceitos – Histórico do ITIL Começamos a partir desta postagem uma grande viagem por uma das mais espetaculares bibliotecas de melhores práticas para gerenciamento de serviços de TI!!! A biblioteca ITIL!!! Aliás, o correto, em português, seria dizer a ITIL e não o ITIL, uma vez que a mesma é uma biblioteca, mas não vamos ficar brigando com aqueles (inclusive eu mesmo) que tratam como o ITIL, como é mais utilizado pelo mercado (alguns dizem que é o modelo de melhores práticas, o framework, etc,etc,etc). O ITIL, ou a ITIL, nasceu há 20 anos na Inglaterra (oficialmente tem 20 anos de vida, mas as práticas de gerenciamento existem a muito mais tempo). Na década de 80, a primeira ministra daquele país, Margareth Thatcher, mais conhecida como a Dama de Ferro (pense numa mulher bruta...) iniciou uma mudança na estrutura do governo inglês com a privatização de algumas empresas estatais, as famosas British --alguma coisa-- (BP – British Pretolium, British Airways, etc). Para gerenciar o funcionamento dos mercados que estavam sendo privatizados, foram criadas as agências reguladoras. Uma delas, a CCTA (uma espécie de ANATEL britânica), reuniu empresas públicas, privadas, fundações, entre outras organizações e poderes públicos para identificar quais seriam as melhores práticas no gerenciamento de serviços de TI. Desta reunião saiu a versão 1 do ITIL, em 1990. A biblioteca foi, aos poucos, conquistando o mercado europeu, especialmente a Alemanha, França e Holanda. Apenas no final dos anos 90, o ITIL entrou nos Estados Unidos. Em 2000 foi lançada a versão 2 da biblioteca. Nesta versão foram feitos resumos e integrações dos vários processos descritos na versão anterior. A versão 2 da ITIL ganhou o mundo e se popularizou como o framework de melhores práticas no gerenciamento de entrega de serviços em TI mais utilizados pelas organizações (existem muitas outras). A CCTA passou a se chamar OGC (Office of Govermment Commerce), cujo foco é 1
  • 2. adotar práticas para a eficiência da gestão pública. A OGC é a detentora da marca ITIL, porém ela não se interessa em montar cursos, fazer exames de certificação, implementar a ITIL mundo afora, etc. Isso fica a cargo de uma estrutura que rodeia as decisões tomadas pela OGC Em 2007 foi lançada a versão 3 do ITIL. Esta versão tem uma visão mais ampla de governança de TI, já que, nas versões anteriores o foco principal era a parte de infraestrutura de TI. Como o tempo médio de vida de uma versão do ITIL é de 7 a 10 anos, acredito que o estudo da V3, ao invés da V2 será mais útil para os nossos leitores e para as empresas que pensam em gerenciar os serviços de TI com base nos processos descritos no ITIL. ITIL V3 – Introdução e Conceitos – O que é um serviço? Para o ITIL, na sua terceira versão, a definição oficial de serviço é a seguinte: “Um serviço é um meio de entregar valor ao cliente, facilitando a obtenção dos resultados que os clientes querem alcançar sem que estes assumam a propriedade dos custos e riscos inerentes.” Achou complicado? Não entendeu nada? Calma, calma... Vamos por partes. Esta definição possui uma série de coisas importantes descritas de forma sucinta que precisamos nos atentar principalmente quando fornecemos serviços de TI. A primeira informação importante, destacada no texto, diz respeito a expressão “entregar valor”. Entregar valor tem o sentido de fornecer um benefício que é compreendido pelo cliente, algo como o serviço de telefonia fixa e celular, os correios, etc. Este benefício deve ajudar o cliente, segundo termo em destaque, a alcançar um determinado objetivo definido por ele. O terceiro trecho destacado diz respeito à propriedade dos custos e riscos inerentes ao serviço oferecido ao cliente. Quando contratamos um serviço não nos importamos com os riscos e custos inerentes a ele, vamos exemplificar para melhor explicar o que queremos dizer. Os Correios oferecem dois serviços distintos, o SEDEX e o SEDEX 10. Consideremos, numa hipótese fictícia, duas empresas que fazem vendas pela internet, uma vende livros e a outra medicamentos. Ambas enxergam o correio como uma provedora de serviços e cada uma escolhe o benefício, ou serviço, que irá ajudá-la a alcançar os seus objetivos da forma mais eficiente. A empresa que vende medicamentos prefere utilizar o serviço de SEDEX 10, devido a natureza do produto que comercializa, enquanto a empresa que vende livro prefere utilizar o SEDEX normal. Os riscos associados a logística de entrega do SEDEX 10 provavelmente são diferentes dos riscos do SEDEX normal, mas isso não é um problema das empresas que utilizam os serviços e sim dos Correios. Os custos para a produção do serviço também são de responsabilidade dos Correios, que negocia um valor para as empresas que avaliam as suas necessidades e escolhem pela alternativa que melhor os atenda. Hoje em dia quase tudo é comercializado na forma de serviços. As pessoas contratam os níveis de serviço e não o produto simplesmente, ou seja, você deseja as características de um determinado produto e não uma caixa fechada. Sacou quão longe o pessoal da OGC pensou? Essa é uma das razões do ITIL ter se tornado tão conhecido mundialmente e tão utilizado pelas empresas de TI. Na próxima postagem veremos os conceitos de boas práticas e gerenciamento de serviços. Sigam-me os bons!!!! ITIL V3 – Introdução e Conceitos – Boas Práticas e Gerenciamento de Serviço 2
  • 3. Já vimos como o ITIL define um serviço de TI, agora vamos passar pelas definições de Boas Práticas e de Gerenciamento de Serviço. Boas Práticas Prática, na visão do ITIL, é uma maneira de se trabalhar, ou melhor, uma forma como o trabalho deve ser feito. As práticas incluem, normalmente, atividades, processos, funções, modelos e orientações. Tendo esta definição em mente, podemos concluir que Boas Práticas são atividades ou processos comprovados e utilizados com sucesso por diversas organizações. ITIL é um exemplo de Boa Prática. Todavia, não podemos confundir Boa Prática com Norma. A Norma é algo obrigatório, as Boas Práticas não. Na verdade, o uso de Boas Práticas garantem naturalmente a execução das Normas. O ITIL define-se como sendo uma boa prática onde cada empresa deve adotar e adaptar à sua realidade no que diz respeito a serviços de TI. Gerenciamento de Serviço Existem inúmeras definições no mercado para gerenciamento de serviço, porém na visão do ITIL, Gerenciamento de Serviço é um conjunto de habilidades organizacionais especializadas (entenda-se processos, conhecimento, etc) para prover valor aos clientes na forma de serviços. O gerenciamento de serviços enfrenta quatro desafios, que na verdade são características dos serviços, que influenciam de forma determinante como as empresas devem atuar para gerenciá-los. Descrevemos abaixo estes quatro desafios do gerenciamento de serviços ou quatro características dos serviços de TI: Intangibilidade – Um serviço é mais difícil de medir, de definir fronteiras e de definir expectativas do que produtos. Exemplo: Na compra de uma passagem aérea, a compra não é da passagem (papel ou e-mail) e sim da viagem. Esta viagem possui várias variáveis, que dependem não apenas na empresa, mas também de quem compra na hora de definir se atendeu as expectativas, etc. Inseparabilidade – Este termo refere-se a relação entre o consumo e a entrega de um serviço. O momento da produção e do consumo do serviço não podem ser separados. Diferente de um produto, onde há esta divisão clara (produção e consumo), um serviço, ao mesmo tempo que está sendo produzido está sendo consumido. Tomemos como exemplo o serviço de disponibilizar uma Rede. O serviço de rede ao mesmo tempo que está sendo produzido, é consumido pelos usuários. Variabilidade – O mesmo serviço pode ser entregue de formas diferentes. Voltemos ao exemplo da viagem aérea. Dependendo do dia e do horário, uma mesma companhia pode ter atraso ou não, pode ter fila ou não e vai atender suas expectativas de forma diferente cada vez que o serviço for consumido. Pericibilidade – Um serviço não pode ser estocado. No exemplo acima, após o avião decolar aquele serviço de viagem não consegue ser reutilizado para o mesmo voo, caso um passageiro não consiga embarcar. Será necessário um outro serviço de viagem para atender a sua necessidade. ITIL V3 – Introdução e Conceitos – Funções e Processos 3
  • 4. Continuando o alinhamento dos conceitos iniciais do ITIL V3, veremos nesta postagem mais duas definições importantes desta biblioteca de melhores práticas: funções e processos. Funções Na visão do ITIL, funções são “unidades da organização especializadas em executar determinados tipos de trabalho e são responsáveis por resultados específicos”. Elas são independentes e autosuficientes em habilidades e recursos necessários para o seu desempenho. Estamos falando de um conceito lógico, mais genérico, como as estruturas organizacionais dotadas de pessoas, conhecimento e recurso para execução de uma tarefa. Existe uma distinção importante entre Função, Grupos, Equipes, Departamentos, Divisões e Papéis. A definição de Função já foi descrita no parágrafo anterior, já os Grupos referem-se a uma ou mais pessoas que possuem um propósito comum, não obrigatoriamente da mesma área. Equipe é algo mais formal do que o Grupo, pois tem responsabilidades mais estruturadas. Departamento e Divisões são estruturas formais. Normalmente, uma Divisão possui um ou mais Departamentos. Por fim, Papéis, que serão melhor aprofundado em outra postagem, são as atividades ou lista de atribuições de uma determinada pessoa, grupo ou equipe. Para o ITIL, quem define os papéis são os processos. Processos Na visão clássica, também seguida pelo ITIL, processo é “um conjunto estruturado de atividades destinadas a cumprir um objetivo específico” que recebem uma ou mais entradas definidas(os chamados inputs) e as transformam em resultados definidos(os chamados outputs). Normalmente um processo não existe sozinho. Na verdade, ele interage com uma série de outros processos. No caso do ITIL, os processos são aplicados durante todo o Ciclo de Vida do Serviço (não se apavorem com este termo, entraremos em mais detalhes em futuras postagens!). Sob este aspecto faz-se necessário considerar o processo todo ou como um processo se encaixa em outro processo. Tendo uma visão genérica sobre um modelo de processo do ITIL, todo processo deve ter um dono, normas ou políticas bem definidas, objetivos (pelo menos um) para ser alcançado, ser documentado e possuir indicadores que permitam medir seu desempenho. Além disso, para que possa ser executado, um processo deve definir as suas atividades, procedimentos e instruções, suas métricas, seus papéis e uma forma de identificar melhorias contínuas. Por fim, para que possam ser viabilizados, os processos devem contar com recursos e habilidades ou capacidades para que funcionem adequadamente. Neste modelo genérico de processo, o ITIL identifica quatro importante características de processos que descrevemos abaixo: Mensurável: Todo processo deve ser capaz de ser medido de forma relevante. Entrega resultados específicos: Os processos devem entregar resultados previsíveis, dentro do objetivo para o qual foi criado. Entrega resultados primariamente para clientes ou stakeholders: Todo processo deve ter o foco principal no cliente, que pode ser interno ou externo. Responde a um evento específico: Todo processo possui um ou mais gatilhos ou agentes que fazem com que o mesmo aconteça. ITIL V3 – Introdução e Conceitos – Papéis e Matriz RACI Nesta postagem estaremos finalizando a parte de introdução e conceitos iniciais do ITIL V3 com dois assuntos muito importantes para esta biblioteca de melhores práticas: os papéis e a famosa Matriz 4
  • 5. RACI. Papéis Cada processo do ITIL pode definir quantos papéis forem necessários para sua execução, mas existem dois papéis, definidos como “papéis genéricos”, que são vitais para qualquer processo do ITIL: o papel de Dono do Processo e o papel de Dono do Serviço. A seguir, vamos detalhar melhor cada um desses papéis. Dono do Processo Cada processo deve ter apenas um dono. Este dono é responsável por garantir que seu processo esteja sendo executado segundo o que foi acordado e documentado e está alcançando os objetivos definidos no próprio processo. Existem tarefas que são de responsabilidade do dono do processo, dentre elas podemos citar as seguintes: documentar e divulgar o processo, definir os Principais Indicadores de Desempenho (PIDs ou KPIs), melhorar a eficiência e eficácia do processo, fornecer entradas para o Plano de Melhoria do Serviço, garantir que toda a equipe tenha recebido o treinamento necessário sobre o processo e garantir que o processo seja regularmente revisado e reexaminado. No mundo real das organizações, o dono do processo tem que ter, no mínimo, uma certa influência para que possa garantir que seu processo esteja sendo executado corretamente. Em outras palavras, processos cujos donos são “oreias secas” (como se diz lá no cerrado) tendem a não conseguir com que seus processos sejam executados dentro da organização. Uma observação importante: Dono do Processo é diferente de Gerente do Processo. Este é um braço operacional que fará com que aquele alcance os objetivos do processo. Dono do Serviço Cada serviço deve ter apenas um dono. Este é “o cara” em relação a um determinado serviço. Na verdade, este papel é quem responde pela qualidade final do serviço e presta contas sobre o mesmo. O Dono do Serviço enxerga o serviço como um todo e, assim como o Dono do Processo, possui uma série de responsabilidades, como por exemplo: fornecer aos atributos do serviço (desempenho, disponibilidade, etc.), ser o ponto de escalação para incidentes maiores, representar o serviço em reuniões do Comitê Consultivo de Mudanças, participar em reuniões externas para revisões de serviços com as áreas de negócio, etc. 5
  • 6. É importante salientar que o Dono do Serviço não é, obrigatoriamente, quem faz o gerenciamento de nível de serviço. Matriz RACI A matriz RACI é um modelo usado para ajudar a definir papéis e responsabilidades. RACI é um acrônico para as quatro funções principais. Pera aí!!!! acrônico??? Essa eu fui longe não??? Mas vamos seguir adiante... hehehe. Bom, como estávamos dizendo, as quatro funções principais são: Responsável → Pessoa(s) responsável(eis) por fazer com que o trabalho seja feito. São os que colocam a mão na massa! Accountable → É quem presta conta pela atividade. Consultado → Pessoas que são consultadas antes da execução da tarefa pois suas opiniões são importantes para a execução da atividade. Informado → Pessoas que se mantêm atualizadas constantemente. Normalmente são informadas depois da execução da atividade. Na Matriz RACI, representada na figura acima, podemos verificar que uma série de informações estão 6
  • 7. dispostas em forma de tabela, o que facilita a identificação dos responsáveis por cada tarefa dentro de cada processo do ITIL. Apesar disso, existem potenciais problemas relacionados ao modelo RACI que devem ser tratados. Dentre eles podemos citar: ter mais de uma pessoa que presta conta (Accountable) por um processo (na prática, processo com dois donos na verdade não tem nenhum), delegação de responsabilidade ou prestação de contas sem autoridade necessária para tanto, foco na correlação de processos e atividades com os departamentos, etc. Finalizamos assim os conceitos iniciais, a partir das próximas postagens falaremos genericamente do ciclo de vida do serviço para depois entrarmos com tudo em cada uma das etapas deste ciclo. Não desanimem!!!! ITIL V3 – Ciclo de Vida do Serviço No retorno das férias, daremos início aos trabalhos do nosso blog com um tema que será utilizado praticamente em todas as postagens referentes ao ITIL daqui por diante, o ciclo de vida do serviço (representado na figura abaixo). A biblioteca ITIL divide o ciclo de vida do serviço em dois componentes básicos: Núcleo do ITIL: onde estão as orientações sobre as melhores práticas aplicáveis a todos os tipos de organizações que prestam serviços ao negócio. Guias complementares do ITIL: um conjunto complementar de publicações com orientações específicas para setores da indústria, tipos de organização, modelos operacionais e arquiteturas de tecnologia. 7
  • 8. O Núcleo do ITIL é representado, na figura acima, por todas as fases que vão desde o centro até o anel amarelo, ou seja, compreende as fases de Estratégia do Serviço (Service Strategy), Desenho do Serviço (Service Design), Transição de Serviço (Service Transition), Operação de Serviço (Service Operation) e Melhoria de Serviço Continuada (Continual Service Improvement). Cada uma das fases do Núcleo do ITIL se tornou uma publicação dentro da biblioteca e será alvo de nossas futuras interações. Por enquanto faremos uma contextualização de cada uma dessas fases para que possamos aprofundar mais nas próximas postagens, mas antes disso é importante dizer que o outro componente básico da biblioteca, os Guias Complementares, representados pelo anel cinza, são divididos em publicações complementares, como livros, artigos, etc. e serviços de suporte web, como portais, templates, etc. Estratégia do Serviço – Nesta fase são fornecidas orientações úteis para o desenvolvimento de políticas e objetivos de gerenciamento do serviço através do seu ciclo de vida. Os processos desta fase ajudam a organização na implementação do gerenciamento do serviço, na identificação do dono do serviço e dos donos dos processos além de verificar a viabilidade e a importância da criação do serviço. Desenho do Serviço – Possui processos que orientam o desenho e o desenvolvimento do serviço assim como o desenho dos processos de gerenciamento do mesmo. Ele inclui as alterações e melhorias necessárias para aumentar ou manter o valor do serviço para os clientes, a sua continuidade, o atingimento de níveis de serviço e a conformidade com as normas e regulamentos. Transição do Serviço – Esta fase fornece orientações para o desenvolvimento e melhorias das habilidades necessárias para fazer a transição de novos serviços ou serviços alterados para a operação. Operação do Serviço – Esta fase incorpora práticas ao gerenciamento de operações de serviços. Ela inclui orientações para alcançar eficiência e eficácia na entrega e suporte de serviços, assegurando assim o valor para o cliente e para o provedor de serviço. Melhoria de Serviço Continuada – Possui processo que fornece orientações para a criação e manutenção de valor aos clientes por meio da melhoria do desenho, implantação e operação do serviço, além da revisão estratégica se o serviço é realmente importante ou não. ITIL V3 – Estratégia do Serviço – Metas e Objetivos 8
  • 9. A partir desta postagem iremos tratar cada uma das fases do ciclo de vida do serviço, que na verdade se transformaram em livros na biblioteca ITIL. Para melhor compreensão e devido a excelente didática, iremos copiar a técnica utilizada no curso oficial do ITIL V3 que tive o prazer de fazer com a Rhino Consulting. Esta técnica consiste em dividir os assuntos de cada livro ou fase do ciclo de vida do serviço nos seguintes tópicos: Metas e Objetivos; Conceitos e Definições; Técnicas, Ferramentas e Modelos; Processos e por fim Tecnologia e Arquitetura. O primeiro livro que iremos explorar é o de Estratégia do Serviço (Service Strategy). Este livro pode nos parecer um pouco mais difícil de entender uma vez que trata de assuntos que estão mais ligados com a parte estratégica da organização, mas, na verdade, a Estratégia do Serviço é um livro muito importante pois ele embasa todas as outras fases do ciclo de vida do serviço além de ser o responsável pelo alinhamento entre o serviço prestado e os objetivos da empresa. Conforme técnica de aprendizado mencionada acima, iremos “iniciar os trabalhos” tratando das Metas e Objetivos da Estratégia do Serviço (Service Strategy). Sei que alguns podem estar se perguntando, mas qual a diferença entre Meta e Objetivo? Então, para que tenhamos um conhecimento uniforme passo abaixo a diferença entre os dois: Meta - É o propósito para o qual um esforço é direcionado; Normalmente de longo prazo; Não pode ser medido; intangível; Representa uma ação genérica. Como exemplo podemos dizer que uma Meta seria o seguinte texto:”Eu quero obter sucesso no campo de pesquisa genética e fazer o que ninguém nunca fez.” Objetivo - É a coisa para a qual um esforço ou ação é pretendida a alcançar ou realizar; normalmente de curto prazo; pode ser medido; tangível; representa uma ação específica. Utilizando o mesmo exemplo da Meta, teríamos o seguinte texto:”Eu quero lhe dar a tese em pesquisa genética em até um mês.” Entendido a diferença entre os dois termos, podemos fazer a seguinte classificação de Metas e 9
  • 10. Objetivos da Estratégia do Serviço descrita no ITIL. Meta: Suportar provedores de serviço para desenvolver a habilidade de pensar e agir de maneira estratégica. Em outras palavras, a meta da Estratégia do Serviço é fazer com que as pessoas ou empresas que irão prover serviços em TI, saiam do mundinho apenas da TI e pensem de forma estratégica, no negócio e como a TI pode suportar o negócio (alinhamento estratégico). Objetivos: A partir da Meta, o ITIL lista uma série de objetivos para a Estratégia do Serviço, entre as principais estão: Definir o que os serviços devem oferecer e para quem. Diferenciar-se das alternativas competitivas. Criar Valor para os clientes e capturar Valor para as partes interessadas (stakeholders). Fazer um Caso de Negócio para investimentos estratégicos. Definir como o gerenciamento financeiro pode promover visibilidade e controle sobre a criação de valor. Definir a qualidade do serviço. Escolher entre diferentes caminhos para melhorar a qualidade do serviço. Usar eficientemente a alocação de recursos através de um portfólio de serviços. Resolver conflitos em demandas por recursos compartilhados. Percebam que a partir dos objetivos, alguns conceitos devem ser explorados para que se tenha um completo entendimento. Assim, surgem termos importantes como: que serviços oferecer; criar valor para os clientes, retorno financeiro, qualidade (fazer o que foi combinado/requisitado) e alocação de recursos. Trataremos deste assunto nas próximas postagens. ITIL V3 – Estratégia do Serviço – Conceitos e Definições – Criação de Valor Seguindo a didática proposta para explorar cada um dos livros do ITIL V3, iniciaremos a verificação dos conceitos e definições que serão importantes para o entendimento dos processos da Estratégia do Serviço. Nesta postagem vamos ver o conceito de Criação de Valor. Segundo o ITIL, o valor do serviço não está apenas nos resultados de negócio do cliente, ele também é altamente dependente da percepção pessoal do cliente. Esta percepção é influenciada diretamente pela expectativa que o mesmo cria em relação ao serviço que será prestado. Mas como se faz para entender e especialmente atender as expectativas de nossos clientes? O ITIL sugere que os gerentes de TI tenham uma mentalidade de marketing. Isso mesmo! Uma mentalidade de marketing. Fácil! Mas... o que é uma mentalidade de marketing? Segundo o ITIL, por meio de uma mentalidade de marketing é possível entender os componentes de valor de acordo com as perspectivas do cliente, em outras palavras, é necessário conhecer como é feito o serviço ou produto ofertado. Entender o seu cliente, o que ele valoriza, qual é a sua necessidade e aspiração. Como exemplo para melhor entender, o Gartner Group disse, em uma de suas pesquisas, que até 2014, 70% dos acessos à internet serão feitos por dispositivos móveis. Essa pesquisa mostra a expectativa dos clientes em relação ao uso dos dispositivos móveis. As empresas que vendem aplicações ou serviços na web devem estar preparadas para atender essa expectativa ou visão de valor que o cliente gostaria de ver no serviço que ele consome. Tendo isso em mente, podemos dizer que a composição do Valor, na visão do cliente, consiste em dois elementos primários: 10
  • 11. Utilidade (O que o usuário receberá): é percebida pelo cliente a partir dos atributos que tem um efeito positivo no desempenho de tarefas que estão associadas às suas necessidades ou redução/remoção de restrições no desempenho das tarefas que também possuem um efeito positivo para o cliente. Como exemplo, podemos citar a criação dos sites de Internet Banking. Essas aplicações melhoram o desempenho de tarefas e remove a restrição de horário do funcionamento das agências. Garantia (Como é entregue ao usuário): é derivado do efeito positivo de estar disponível, quando necessário, com a capacidade suficiente e de forma confiável em termos de continuidade e segurança. Utilizando o mesmo exemplo do Internet Banking, o uso dessa ferramenta só é percebida como boa para o cliente devido à segurança, disponibilidade, capacidade, etc. Moral da história: Para se ter valor para o cliente, o serviço deve ter Utilidade para o mesmo e ter Garantia que vai funcionar ou dar os resultados esperados. A figura acima mostra uma versão gráfica de como se criar valor para o cliente. O que temos que ter em mente é que Utilidade é o que o cliente adquire e garantia é como isso é entregue. TIL V3 – Estratégia do Serviço – Conceitos e Definições –Ativos de Serviço Dando continuidade aos conceitos e definições da Estratégia do Serviço, veremos nesta postagem quais são, na visão do ITIL V3, os Ativos de Serviço. O ITIL define Ativos de Serviço como sendo qualquer Habilidade ou Recurso, utilizado por um provedor de serviço, que contribui para a entrega de um determinado serviço. Em outras palavras, as organizações utilizam Habilidades e Recursos para criar valor em forma de bens e serviços. Os Recursos são coisas tangíveis, como por exemplo: Capital Financeiro, Infraestrutura, Aplicativos, Informação e Pessoas (no sentido de recurso humano). Já as Habilidades são coisas intangíveis e representam competências organizacionais para coordenar, controlar e implementar recursos, ou seja, as Habilidades são usadas para transformar os Recursos. Como exemplo de Habilidades, o ITIL enumera as seguintes: Gerenciamento, Organização, Processos, Conhecimento e Pessoas. Pera aí!!! Pessoas de novo? Sim, caro leitor, pessoas, no contexto de Habilidades, refere-se às habilidades individuais das pessoas (os famosos skills), enquanto que pessoas como Recurso é apenas o material humano (quantidade de pessoas alocadas), sacou a diferença? 11
  • 12. ITIL V3 – Estratégia do Serviço – Conceitos e Definições – Provedor de Serviço Fechando os conceitos e definições do livro de Estratégia do Serviço, veremos nesta postagem como o ITIL trabalha a questão do provedor de serviço. A biblioteca define três arquétipos de modelos de negócio de provedores de serviço, a saber: Tipo I, Tipo II e Tipo III. Como esta classificação não diz absolutamente nada, descreveremos abaixo cada um deles: Tipo I - Este tipo de provedor de serviço é conhecido como Provedor de Serviço Interno. São tipicamente funções que fazem parte das unidades de negócio que pertencem. Tipo II – Descrita como Unidade de Serviços Compartilhados, são áreas que podem atender muitas unidades ou até empresas, como por exemplo: área de RH, contabilidade, logística, etc. Tipo III – Provedor de Serviço Externo. Eventualmente as estratégias de negócio requerem habilidades prontamente disponíveis por provedor de serviço externo. Os Fornecedores, como também são conhecidos, representam um terceiro responsável por fornecer bens e serviços requeridos para entregar serviços de TI. Os fornecedores podem ser de Hardware e Software, de Rede e Telecom e de organização de Outsourcing. Bem, finalizamos os Conceitos e Definições da Estratégia do Serviço. Elas nos serão úteis no prosseguir da nossa viagem por esse importante livro da biblioteca ITIL!!! Na próxima postagem, conforme metodologia adotada, iremos ver as técnicas, ferramentas e modelos utilizados pela Estratégia do Serviço, antes de entrarmos nos processos propriamente ditos. ITIL V3 – Estratégia do Serviço – Técnicas, Ferramentas e Modelos – Portfólio de Serviço Iniciando um novo tópico, falaremos nesta postagem sobre o Portfólio de Serviço. Existem algumas vertentes que tratam de diferentes maneiras o termo Portfólio de Serviço. Como estamos passeando pelo mundo ITIL, vamos nos restringir a verificar a visão sob os olhares desta biblioteca. O Portfólio de Serviço é visto pelo ITIL como uma ferramenta para priorizar investimentos e melhorar a alocação dos recursos. Em empresas privadas, os portfólios requerem uma certa disciplina financeira com o intuito de evitar investimentos que não irão gerar valor. Já no mundo público, outras variáveis também devem ser consideradas, como por exemplo: a política, o resultado social (que nem sempre é o melhor resultado financeiro), etc. Esta importante ferramenta é dividida em três fases: o Funil de Serviço, o Catálogo de Serviço e os Serviços Obsoletos. A seguir detalharemos cada uma dessas fases, mas antes é interessante verificar que o Catálogo de Serviço é, na verdade, apenas uma parte do Portfólio de Serviço (as pessoas costumam confundir esses dois termos!). É importante lembrar, também, que o Portfólio de Serviço ajuda os gestores a esclarecer algumas questões estratégicas, como por exemplo: Por que um cliente compraria esse serviço? Por que eles comprariam de nós?, etc. Vocês podem estar se perguntando: como o portfólio ajuda a esclarecer as questões estratégicas, certo? Não se preocupem que eu respondo. Não podemos tirar das nossas mentes que o Portfólio de Serviço representa o comprometimento e investimentos feitos por um provedor de serviços a todos os clientes e a todos os espaços de mercado (Espaço de Mercado = oportunidade). Como o objetivo final do Portfólio de Serviço é maximizar o valor minimizando os riscos e custos, então ele deve ser utilizado de forma intensa para definições estratégicas... 12
  • 13. Bem, voltando a definição das três fases do Portfólio de Serviços, na figura acima verificamos as fases que compõem o Portfólio (detalhadas abaixo) e também podemos perceber que o mesmo é parte integrante de um grande Sistema de Gerenciamento do Conhecimento do Serviço (SGCS). Funil de Serviço - Consiste nos serviços que estão em desenvolvimento ou sendo viabilizados para um determinado cliente ou espaço de mercado. O Funil reflete a extensão com que os novos conceitos e ideias de qualificação dos serviços são levados adiante pela Estratégia do Serviço, Desenho do Serviço e Qualificação Continuada do Serviço. Resumindo, o Funil representa a visão estratégica de crescimento do provedor de serviços para o futuro. Catálogo de Serviços - É uma base de dados ou documentos estruturados que possuem as informações sobre todos os serviços de TI em operação ou em vias de entrar em produção. O Catálogo de Serviço é a única parte do Portfólio de Serviço disponível para visualização por parte do cliente. Além disso, ele é dividido em duas porções: uma mais voltada para o cliente e outra mais voltada para as áreas técnicas. Serviços Obsoletos - Alguns serviços no Catálogo ficam obsoletos ou são aposentados. As informações desses serviços, apesar de estarem aposentados, podem ser de grande valia para a tomada de decisão de investimento futuros (as famosas “Lições aprendidas” do PMBOK). Normalmente, os serviços obsoletos não estão disponíveis para novos clientes ou novos contratos. 13
  • 14. ITIL V3 – Estratégia do Serviço – Técnicas, Ferramentas e Modelos – Caso de Negócio Após termos visto como funciona o Portfólio de Serviços, vamos ver nesta postagem uma outra ferramenta utilizada na definição da Estratégia do Serviço, o Caso de Negócio. O Caso de Negócio deve documentar o impacto de um determinado serviço para os negócios ou os benefícios que o mesmo poderá trazer. Este documento é, exatamente, o insumo necessário para a análise que é efetuada no Funil do Portfólio de Serviços (ver postagem anterior para mais detalhes sobre o Funil e o Portfólio de Serviços). Ao desenvolver um Caso de Negócio, o foco não deveria estar limitado apenas na possibilidade de lucrabilidade e retorno do investimento (famoso ROI), mas também ao valor de negócio que uma melhoria de um determinado serviço, ou um novo serviço, poderia trazer para o negócio e para seus clientes. Normalmente um Caso de Negócio tem a seguinte estrutura: serviço. Introdução – Apresenta os objetivos do negócio que devem ser atendidos pelo Métodos e Hipóteses – Define os limites do Caso de Negócio, como tempo, custo e benefícios. Impacto de Negócio – É o estudo que mostra os resultados financeiros e não financeiros (apelo político, sociais, etc.) do Caso de Negócio. Riscos e Contingências – A probabilidade de desvios aparecerem com resultados alternativos aos inicialmente esperados. Recomendações – Ações específicas que devem ser recomendadas. Seguiremos na próxima postagem com as definições das técnicas, ferramentas e modelos utilizados na Estratégia de Serviços. Valendo um doce para quem acertar qual seria a próxima técnica a ser descrita aqui no blog! Alguém se atreve a tentar descobrir? Uma dica... ...este tema é tratado por praticamente todas as metodologias... TIL V3 – Estratégia do Serviço – Técnicas, Ferramentas e Modelos – Riscos Finalizando as técnicas, ferramentas e modelos da Estratégia do Serviço, veremos nesta postagem 14
  • 15. uma técnica que é utilizada por praticamente todas as metodologias que conheço, a análise e o gerenciamento de Riscos. Risco, na visão do ITIL, é definido como a incerteza de um determinado resultado. Se é uma oportunidade então o risco é positivo. Se é uma ameaça, então o risco é negativo. Gerenciar risco diz respeito à identificação e ao controle da exposição de uma empresa ao risco. É certo dizer que de alguma forma as empresas gerenciam os seus riscos, porém nem sempre de um modo explícito, controlado e consistentemente aplicável para suportar as tomadas de decisão que irão influenciar os negócios da organização. É por isso que devemos utilizar o gerenciamento de riscos, já que, sua missão principal é garantir que a organização utilize um processo com um conjunto de passos bem definidos, permitindo a melhor tomada de decisão possível após o entendimento dos riscos e de seus impactos. A OCG (“pai” do ITIL) criou a figura do MOR. O MOR é um guia que é destinado a ajudar empresas a criar um framework efetivo para ajudar nas tomadas de decisões a respeito dos riscos que afetam seus objetos por todas as atividades organizacionais. Nesta visão, risco é dividido em duas fases distintas: a análise de riscos, responsável pela identificação, avaliação das ameaças e vulnerabilidades e o gerenciamento de risco, que o ITIL não considera como processo da Estratégia do Serviço, mas que envolve a monitoração dos riscos e do acesso às informações confiáveis e atualizadas sobre os mesmos. ITIL V3 – Estratégia do Serviço – Processos – Gerenciamento de Portfólio de Serviço Começamos a partir desta postagem a ver os processos do ITIL V3 referentes à Estratégia do Serviço. Oficialmente, o ITIL fala sobre quatro processos para este livro, a saber: Geração da Estratégia, Gerenciamento de Portfólio de Serviço, Gerenciamento Financeiro e Gerenciamento de Demanda. A Geração da Estratégia é um processo que nos remete ao BSC (Balanced Scorecard). Como não estamos tratando do BSC neste momento, vamos pular este processo e passar para o Gerenciamento de Portfólio de Serviço. Já falamos em outra postagem sobre Portfólio de Serviço, assim, para não ficarmos com postagens muito extensas, sugiro que, se alguém tiver alguma dúvida sobre esta ferramenta, leia a publicação referente a este assunto antes de prosseguir com a leitura sobre o processo de Gerenciamento de Portfólio de Serviço (postagem de sexta-feira, 11 de março de 2011, intitulada ITIL V3 – Estratégia do Serviço – Técnicas, Ferramentas e Modelos – Portfólio de Serviço), mas para aqueles que já leram e não querem navegar pelas postagens, lembro que um Portfólio de Serviço descreve os serviços de um provedor em termos de valor ao negócio. O Gerenciamento de Portfólio de Serviço é um processo dinâmico e continuado que deve seguir as seguintes atividades: Definir – Com base na Estratégia do Serviço, o gerenciamento de Portfólio de Serviço deve conhecer o que se tem atualmente na empresa, deve montar os Casos de Negócio e validar os dados do portfólio. Analisar – A análise representa o Funil do Portfólio e deve ser feita com o objetivo de maximizar o valor do portfólio. A análise também é responsável por alinhar, priorizar e balancear oferta e demanda. Aprovar – Esta atividade aprova o portfólio proposto, autorizando serviços e recursos para sua implementação. 15
  • 16. Contratar – Esta atividade significa a identificação que um Caso de Negócio saiu do Funil e deve ir para a parte de Desenho do Serviço. ITIL V3 – Estratégia do Serviço – Processos – Gerenciamento da Demanda Vamos explorar o processo de Gerenciamento da Demanda do livro de Estratégia do Serviço do ITIL V3? Vamos lá! Este processo trabalha junto com o gerenciamento do Portfólio de Serviço e tem os objetivos claros de entender e, principalmente, influenciar a demanda de clientes para Serviços, além de entender e também influenciar a capacidade ofertada para atender a essas demandas. Para não ficar dúvida, este processo, na verdade, tem que entender quais são as características do serviço na visão do negócio e tentar influenciar a demanda a fim de utilizar de forma mais otimizada os seus recursos. Um exemplo de influência de demanda de serviço é a ideia implementada pelas empresas aéreas no que diz respeito à oferta de voos à noite (ou tarde da noite) por preços mais baratos. A equação é simples: avião no pátio é custo, no ar é lucro (ou menos prejuízo). Assim, as empresas começaram a influenciar a demanda por voos domésticos, ofertando-os a noite, onde antes não era tão comum, por um preço mais barato. A influência também pode ser negativa, ou seja, tentar diminuir o consumo de um determinado serviço em um determinado horário, por exemplo, sobretaxando o serviço naquele horário indesejado. É importante deixar claro que o processo de Gerenciamento da Demanda é um aspecto crítico do gerenciamento de serviços, especialmente porque se faz necessário o entendimento do processo de negócio, o que pode se configurar como um verdadeiro desafio. Um Gerenciamento da Demanda mal feito ou negligenciado é uma enorme fonte de riscos para o provedor de serviço de TI devido à incerteza da demanda. As técnicas de Gerenciamento da Demanda, tais como precificação reduzida, descontos por volume e níveis de serviços diferenciados podem influenciar a demanda em padrões específicos, contudo devemos lembrar que não é possível produzir e estocar serviço para demandas posteriores. Assim, entender a capacidade, gerar insumo para o planejamento da mesma e saber entender as necessidades do negócio são atividades primordiais para o Gerenciamento da Demanda. ITIL V3 – Estratégia do Serviço – Processos – Gerenciamento Financeiro Fechando os processos da Estratégia do Serviço, falaremos nesta postagem do Gerenciamento Financeiro. Este importante processo tem o objetivo de prover ao negócio e à área de TI a quantificação, em termos monetários, dos serviços a serem prestados, ou seja, tem o objetivo de estimar quanto custa o serviço de TI a ser ofertado. Além disso, este processo é responsável por gerenciar os requisitos necessários para orçar o serviço, gerenciar a contabilidade dos gastos e a cobrança propriamente dita. Existem alguns mecanismos/metodologias e conceitos utilizados pelo Gerenciamento Financeiro na identificação do orçamento, na contabilização dos custos e na cobrança dos provedores de serviços de TI que facilitam o trabalho desta gerência. A seguir detalharemos estes mecanismos e conceitos: Custo – Conceito que significa o montante de dinheiro gasto em uma atividade específica, em uma unidade de negócio ou em um serviço de TI. CTP – Custo Total de Propriedade (famoso TCO em inglês – Total Cost of Ownership) – Este conceito permite avaliar todo o ciclo de vida do custo de propriedade de 16
  • 17. um item de configuração. Para aqueles que nunca ouviram falar em TCO, ou TCP na língua pátria, poderíamos dizer que a identificação do TCO vai além do valor produto ou serviço propriamente dito, ele contabiliza as coisas que não são tangíveis e conseguem avaliar o quanto o mesmo vale em todo seu período de vida útil. CTU – Custo Total de Utilização (TCU in English – Total Cost of Utilization) – Avalia todo o Ciclo de Vida do Custo da utilização do serviço de TI pelo cliente. É importante notar que, para que se tenha o CTU, é necessário se ter um histórico do uso do serviço que está sendo medido. RDI – Retorno do Investimento (ROI para os íntimos – Return of Investment) – É uma medição que relata o benefício esperado de um determinado investimento, ou melhor, mede o tempo que demora para recuperar o investimento feito em algum serviço ou produto. A partir do uso desses conceitos, a Gerência Financeira consegue fazer o orçamento, controlar a contabilidade e efetuar a cobrança dos provedores de serviços de TI. Algumas coisas interessantes saltam aos olhos quando olhamos para esses conceitos. Se percebemos bem, devemos fazer sempre antes o CTP e só depois o CTU, uma vez que o primeiro é uma metodologia utilizada para ajudar na tomada de decisão sobre investimento, enquanto que a segunda é uma metodologia utilizada para ajudar na tomada de decisão sobre investimento e “sourcing” do serviço. Se pudéssemos simplificar as coisas e ler tudo em uma única respirada, eu diria que a interação entre os processos vistos até o momento seria da seguinte maneira (pausa para respirar fundo e começar a leitura, sem gaguejar, por favor) : a necessidade do cliente são internalizadas por meio de requisitos que estarão sendo gerenciados pelo Gerenciamento do Portfólio de Serviços. Esta gerência verifica junto ao Gerenciamento de Demandas como isso poderá ser ofertado. A Gerência de Demandas retorna os insumos para que a Gerência de Portfólios de Serviços possa colocar o novo serviço dentro do funil do portfólio. Além disso esta gerência envia para o Gerenciamento Financeiro solicitando a análise, utilizando os conceitos e mecanismos descritos acima, para identificar em termos monetários o que significa a requisição feita pelo cliente. A gerência Financeira responde ao Gerenciamento de Portfólios de Serviços que verifica se continua ou não com a construção do serviço de TI (OK ou NOK – não OK)... ufa!!!! sacaram... simples e eficiente (nem tanto)... Finalizamos aqui os processos do livro Estratégia dos Serviços. Lembrem-se que dentro do ciclo de vida do serviço, aqueles que forem passar pelo Funil do Portfólio serão encaminhados para a próxima fase, o Desenho do Serviço... Não percam as cenas dos próximos capítulos. ITIL V3 – Estratégia do Serviço – Tecnologia eArquitetura –Automação do Serviço Antes de entrarmos no Desenho do Serviço, ficou faltando, conforme metodologia proposta para o tema ITIL V3, falarmos sobre a tecnologia e arquitetura da Estratégia do Serviço. Para este livro em específico é mais difícil elencarmos tecnologias e arquiteturas, pois o propósito aqui seria entender como a automação do serviço suportaria a integração entre os processos de gerenciamento do serviço e a Estratégia do Serviço. Sob esta ótica ficaria claro dizer que primeiro se faz necessário a definição de processos e depois das ferramentas para automação, pois, desta forma o alinhamento estratégico estaria mais protegido e garantido. De qualquer maneira, a automação deve sempre ser considerada a fim de melhorar a utilidade e a garantia dos serviços (rever postagem sobre utilidade e garantia para maiores informações). Algumas áreas do gerenciamento de serviços que poderiam se beneficiar com a automação seriam: 17
  • 18. Catálogo de Serviços. Classificação, priorização e encaminhamento dos requisitos. Desenho e modelagem dos requisitos e dos processos, etc. Bem pessoal, com esta postagem finalizamos a fase de Estratégia do Serviço dentro do ciclo de vida do serviço proposta pelo ITIL V3. A partir da próxima postagem entraremos no livro Desenho do Serviço com tudo!!! Não percam!!! ITIL V3 – Desenho do Serviço – Metas e Objetivos Caros leitores, sejam bem-vindos ao estágio do ciclo de vida do Serviço denominado de Desenho do Serviço (Service Design) do ITIL V3. Assim como fizemos na Estratégia do Serviço, estaremos fazendo uma viagem por este estágio verificando as Metas e Objetivos, os Conceitos e Definições, as Técnicas/Ferramentas e Modelos, os Processos e finalmente a Tecnologia e Arquitetura. Nesta postagem estaremos tratando das Metas e Objetivos deste importante livro da biblioteca ITIL. O Desenho do Serviço tem como meta principal, como o próprio nome do estágio deixa transparecer, o desenho de serviços novos ou de grandes alterações em serviços para a implementação em ambiente de produção. Prestem bem atenção, pois no caso de alterações em serviços, este estágio tratará exatamente daquelas que sejam significativas para o funcionamento do serviço, ou seja, aquelas que precisam “voltar à prancheta” (sei que este termo nos dias atuais pode parecer vazio, mas não me ocorreu nenhum outro jargão que pudesse exemplificar melhor a idéia que quero passar) e não das mudanças que são corriqueiras tratadas em outro estágio do ciclo de vida do Serviço. Os serviços que vieram da Estratégia do Serviço para este estágio do ciclo de vida são trabalhados por uma série de processos que, no fim das contas, possuem os seguintes objetivos: 18
  • 19. Desenhar o serviço de forma que atenda os objetivos de negócio. Desenhar o serviço para que seja desenvolvido da forma mais fácil e eficiente possível dentro de prazos e custos apropriados. Desenhar processos eficientes e efetivos não apenas para a fase de Desenho do Serviço, mas também para a transição, operação e qualificação de serviços de TI de alta qualidade. Identificar e gerenciar riscos para que os mesmos possam ser tratados antes da implantação do Serviço. É bom lembrar que este trabalho começa a ser feito lá na Estratégia do Serviço quando da verificação da viabilidade do serviço em termos financeiros e de negócio. Desenhar a infraestrutura de TI, ambientes, aplicativos e dados/informações seguras e eficientes que possam atender as necessidades atuais e futuras do negócio. Desenhar a forma de medir (métodos e métricas) a fim de avaliar a efetividade e a eficiência do desenho do processo e seus entregáveis. Produzir e manter os planos de TI, processos, políticas, arquiteturas, estruturas e documentos. Desenvolver perfil e habilidade dentro da TI, transformando atividades de estratégia e desenho em atividades operacionais. Contribuir para a qualificação geral do serviço de TI dentro das restrições de desenho impostas. Resumindo a ópera, podemos dizer que este estágio é responsável pelo desenho da arquitetura do serviço no seu sentido mais amplo, ou seja, tratará de tudo o que o serviço precisa para que possa atender as necessidades do negócio hoje e no futuro. ITIL V3 – Desenho do Serviço – Conceitos e Definições – Quatro P's O conceito que vamos abordar nesta postagem, em uma olhada mais superficial, pode parecer sem importância ou apenas algo que é colocado nas metodologias para “encher linguiça”. Na verdade os quatro P's do gerenciamento de serviços foram definidos porque os projetos, na vida real, falham por falta de planejamento e gerenciamento. Tendo isso em mente, o gerenciamento de serviço deve tratar da preparação para usar os 4p's descritos abaixo: Pessoas – Definir e gerenciar quem vai participar da geração do serviço. 19
  • 20. Processos – Planejar quais processos serão utilizados na confecção do serviço Produtos – Entende-se como produtos, os serviços, tecnologias e ferramentas a serem utilizadas na confecção do serviço. Parceiros – Definir quem serão os parceiros na confecção do serviço. Não precisamos dizer que os 4 P's são abordados por outras metodologias como o PMBOK, por exemplo. Isso apenas corrobora a ideia de que não se deve nunca perder de vista a importância desses aspectos do gerenciamento do serviço para o sucesso do empreendimento. ITIL V3 – Desenho do Serviço – Conceitos e Definições – CincoAspectos do Desenho do Serviço Se na postagem anterior verificamos os 4 P's do gerenciamento do serviço, nesta postagem veremos os Cinco aspectos que devem ser considerados na fase de Desenho de Serviço. São eles: Definição dos requisitos de serviço – Este aspecto detalha aquilo que foi colocado na Estratégia do Serviço por meio dos PNS. Esta definição resulta na criação de RNS, ou seja, os requisitos de nível de serviço, instrumento que antecede os acordos de níveis de serviço – ANS. A fonte de busca de informações sobre os requisitos de um novo serviço ou da alteração de serviços são encontrados no Portfólio de Serviço. Sistemas e ferramentas de gerenciamento de serviço – Definição das ferramentas a serem utilizadas na configuração, monitoração, incidentes, mudanças, testes e guarda de informações do serviço no catálogo. Desenho da tecnologia e da arquitetura – Trata da definição da infraestrutura e dos padrões que irão suportar os serviços. Neste caso estamos falando de ferramentas de TI e não de ferramentas de gerenciamento (definido no item anterior). Como exemplo da definição da tecnologia e da arquitetura podemos citar a definição dos sistemas, do banco de dados, da linguagem a ser utilizada, da arquitetura de rede e de infraestrutura necessária, etc. Desenho do processo – Definir os processos referentes ao gerenciamento de serviços de TI que devem ser utilizados, o workflow, etc. É importante salientar que neste momento os processos são mais genéricos, sendo aprofundados mais nas outras fases do ciclo de vida do serviço. Desenho da medição – Como só é possível gerenciar o que se consegue medir, é importantíssimo que na fase de Desenho do Serviço sejam definidos que tipo de métricas serão produzidos para a medição do serviço, de que forma as informações serão apresentadas, como serão obtidas e quais pessoas que devem acessá-las. Tendo em vista estes cinco aspectos, o estágio do Desenho do Serviço inicia o seu trabalho com o conjunto de requisitos para o novo serviço, ou a a alteração de serviço existente, e termina com o desenvolvimento de uma solução de serviço desenhado para atender as necessidades documentadas do negócio. Esta solução desenvolvida, conjuntamente com o seu Pacote de Desenho do Serviço (PDS) é passada para a fase de Transição do Serviço para que a mesma possa avaliar, construir, testar e instalar o novo serviço ou um serviço alterado. Sacaram? Na próxima postagem, introduziremos um conceito bastante utilizado pelo ITIL. Com certeza a maioria das pessoas já ouviu falar dele... Alguém tem algum palpite? ITIL V3 – Desenho do Serviço – Conceitos e Definições –ANS 20
  • 21. Caros leitores, nesta postagem estaremos falando um dos temas mais famosos do ITIL V3, o Acordo de Nível de Serviço – ANS ou o SLA para os mais íntimos (Service Level Agreement). Basicamente, um ANS é um acordo entre um provedor de serviço de TI e um cliente. Neste documento deve estar descrito o serviço de TI que será prestado, as metas a serem cumpridas e as responsabilidades tanto do provedor de serviço de TI quanto do cliente. É importante salientar que um ANS pode cobrir vários serviços de TI ou vários clientes. Assim sendo, cada organização deve achar a melhor forma de estruturar os seus ANS a fim de que os mesmos garantam que todos os serviços estejam cobertos de acordo com a necessidade do negócio. O ITIL V3 reconhece três diferentes tipos de ANS, a saber: ANS baseado em Serviço – Este tipo de ANS acontece quando o provedor de serviço de TI possui um padrão de ANS para um determinado serviço que será utilizado para todos os clientes que tiverem aquele serviço. ANS baseado em Cliente ou em Unidades de Negócio – Este tipo de ANS acontece quando os níveis de serviço são agrupados por cliente ou por unidade de negócio, embutindo neste todos os serviços que foram negociados para um determinado cliente ou unidade de negócio. ANS Multinível – Como o próprio nome sugere, este tipo de ANS é um híbrido entre várias formas, como por exemplo: Acordo de Nível Corporativo, cobrindo todos os acordos genéricos do gerenciamento de nível de serviço apropriados para cada cliente através da organização (menos volátil); nível de cliente e nível de serviço, conforme descrito nos itens anteriores. Com toda a explicação dada acima surge a seguinte pergunta na cabeça dos leitores atentos e questionadores: será que tendo um ANS bem montadinho é certeza de que a empresa estará prestando um bom serviço de TI? E aí nobres leitores, como vocês responderiam esta pergunta, hein? ITIL V3 – Conceitos e Definições –ANO e Contratos Subjacentes 21
  • 22. Finalizamos a postagem anterior com a seguinte pergunta: ter um ANS bem montadinho é certeza de que a empresa estará prestando um bom serviço de TI? Para responder esta pergunta precisamos antes de mais nada olharmos para dentro de nossas organizações e verificarmos como estamos estruturados a fim de atender as necessidades do negócio e especialmente honrar, da melhor forma possível, o que foi acordado com o cliente quando da contratação de um serviço de TI. Como diz minha mãe: “o combinado não sai caro”. Acho que foi pensando nesta pequena lei social que o ITIL criou, com o intuito de garantir a entrega do serviço com os níveis contratados, o conceito do Acordo de Níveis Operacinal (ANO), também conhecido como OLA (Operational Level Agreement) e os contratos subjacentes ou Underpinnig Contracts (UI). Por definição, um ANO é um acordo interno entre o provedor de serviço de TI e uma outra parte da mesma organização que será responsável por apoiar a entrega do todo ou de parte do serviço de TI vendido a um cliente externo. Com essa definição podemos inferir que o ANO foca nos requisitos operacionais que os serviços precisam atender. Assim, respondendo a pergunta colocada no início desta postagem, o fato de se ter um ANS que não esteja “coberto” pelo ANO representa um altíssimo risco do ANS não ser cumprido, ocasionando multas e até secção do contrato. Mas e quando a operação de um serviço de TI vendido a um cliente depende de entregas de parceiros ou fornecedores de mercado e não apenas das áreas internas do próprio provedor do serviço de TI? Para esses casos, extremamente comum nos dias de hoje, o ITIL prevê o uso dos contratos subjacentes. Contrato, em sua definição, é um acordo legal que vincula duas ou mais partes, atribuindo a cada um suas obrigações, direitos e deveres. Portanto, os contratos adjacentes são utilizados como base para acordos com fornecedores externos, sempre que um compromisso obrigatório se faz necessário. Para finalizarmos esta postagem podemos dizer, então, que ter um ANS bem montado não é garantia de entrega de serviço dentro dos parâmetros acordados. Para que isso aconteça faz-se necessário a existência de acordos internos ou com fornecedores externos que permitam cobrar, formalmente, a responsabilidade assumida por cada parte integrante na entrega do serviço. ITIL V3 – Desenho do Serviço – Conceitos e Definições – Disponibilidade Finalizando os conceitos do livro do ITIL que versa sobre o Desenho do Serviço, falaremos um pouco nesta postagem sobre o termo Disponibilidade. Para início de conversa, o ITIL considera Disponibilidade como sendo a competência de um serviço, componente ou item de configuração em 22
  • 23. executar a função acordada quando requerida. Vejam que o grande lance aqui é perceber que a Disponibilidade só deve ser calculada em relação ao que foi acordado e não em relação ao serviço como um todo. Assim, podemos considerar que, geralmente, a Disponibilidade é medida e reportada como porcentagem conforme a seguinte regra matemática: Disponibilidade (%) = [(Tempo de Serviço Acordado (TSA) – Inatividade) / Tempo de Serviço Acordado (TSA)] x 100% onde.: Inatividade → Falhas sazonais, mudanças não planejadas ou mal planejadas, erros de operacionalização, etc. Contudo, não podemos esquecer que a Disponibilidade, mais do que um simples cálculo matemático, é determinada por outros fatores que também devem ser considerados. São eles: Confiabilidade→ Medição sobre quanto tempo um serviço, componente ou IC pode executar sua função acordada sem interrupção. É medido e relatado como Tempo Médio entre Incidentes de Serviço (TMEIS) ou Tempo Médio Entre Falhas (TMEF) Sustentabilidade→ Medição de quão rápido um serviço, componente ou IC pode ser recuperado ao estado normal depois de uma falha. É medido e relatado como Tempo Médio de Recuperação do Serviço (TMRS) Funcionalidade→ Medição sobre a competência de um fornecedor externo em atender os termos do Contrato. Normalmente existem contratos subjacentes com os níveis a serem atendidos. Desempenho→ Medição das interrupções causadas por desempenho ou capacidade. Medido por processos que tratam a capacidade do serviço. Segurança→ Medição das interrupções causadas por incidentes de segurança. Medido por processos que tratam da segurança da informação. Para cada fator colocado acima também temos fórmulas matemáticas para identificá-los. Seguem abaixo algumas dessas fórmulas: Confiabilidade (TMEIS em horas) = Tempo de Disponibilidade em Horas / Número de Quebras Confiabilidade (TMEF em horas) = (Tempo de Disp. Em horas – Tempo Total de parada em horas) / Número de quebras Sustentabilidade (TMRS em horas) = Tempo Total de Paradas em horas / Número de Quebras do Serviço Esses são os itens mais importantes para serem olhados quando estamos tratando de Disponibilidade de um serviço de TI, porém pode ser que não sejam os únicos. Cada empresa pode considerar uma gama maior de indicadores ou fatores que comporão a definição de Disponibilidade do serviço. Bem, finalizados os conceitos vamos partir para as técnicas, ferramentas e modelos da fase de Desenho do Serviço! ITIL V3 – Desenho do Serviço – Técnicas, Ferramentas e Modelos – Catálogo de Serviços Caros leitores, já havíamos falado do Catálogo de Serviços dentro do Portfólio de Serviço durante as postagens referentes a etapa de Estratégia do Serviço, inclusive explicando por alto como o mesmo funciona. Agora, vamos falar de uma forma mais aprofundada como esta ferramenta é utilizada pela etapa do Desenho do Serviço. 23
  • 24. O Catálogo de Serviços é um subconjunto do Portfólio de Serviço, que por sua vez, é membro integrante do SGCS – Sistema de Gerenciamento do Conhecimento do Serviço. O Catálogo, na verdade, é a única parte do Portfólio de Serviço da empresa prestadora de serviços de TI que fica visível ao cliente. Neste ponto, aqueles que já tiveram contato ou experiência com um Catálogo de Serviços podem estar se perguntando: Será que todo o Catálogo fica visível ao cliente? Eu me lembro de coisas no Catálogo que diziam respeito apenas a parte interna da empresa. Os clientes também viam essas informações? Muito bem... muito bem! Na verdade, o Catálogo de Serviços possui dois aspectos fundamentais, conforme explicação e figura a seguir. Catálogo de Serviços de Negócio→ Esta parte do Catálogo é vista pelo cliente. Ela facilita o entendimento do cliente em relação aos benefícios e valores, pois há a relação do processo de negócio com o serviço oferecido. Catálogo de Serviços Técnicos→ Esta parte do Catálogo é vista internamente pela empresa prestadora de serviço de TI. Ajuda a identificar o que cada item de software ou hardware contribui para a produção de um determinado serviço, ou seja, mostra como o serviço é montado e o quê o compõe. É interessante verificar que o Catálogo Técnico tem uma nítida função de suportar o Catálogo de Negócio, além de ser uma importante ferramenta, como parte do Portfólio de Serviço, para a Estratégia de Serviço, uma vez que é a projeção virtual das habilidades presentes no Provedor de Serviço de TI. 24
  • 25. TIL V3 – Desenho do Serviço – Técnicas, Ferramentas e Modelos – PDS Uma outra ferramenta utilizada pelo Desenho do Serviço, conforme prega o ITIL V3, é o famoso PDS ou Pacote de Desenho de Serviço. Percebo que alguns leitores vão ler a frase anterior e dizer: famoso? Hmmm, só se for para você Breno! Ok. Acho que exagerei um pouco. Na verdade, o PDS é uma nova ferramenta implementada na versão 3 do ITIL. O PDS não passa de um conjunto de documentos que define todos os aspectos de um serviço de TI e seus requisitos. Ele agrupa todos as informações do Desenho do Serviço com todos os planos do projeto e é utilizado através de cada estágio do ciclo de vida do serviço, ou seja, é passado e consumido pelas outras fases do ciclo de vida. Um PDS deve ser construído sempre que tivermos um novo serviço de TI que passará pela fase de Desenho, mas não apenas para os novos serviços! Mudanças maiores em serviços já existentes também devem ter PDS construídos. Coloco abaixo o conteúdo do Pacote de Desenho de Serviço: Categoria Requisitos Desenho de Serviços Diagnóstico de Prontidão Organizacional Plano de Ciclo de Vida de Serviço Subcategoria Requisitos de Negócio Aplicabilidade de Serviço Contatos de Serviço Requisitos Funcionais de Serviço Requisitos de Nível de Serviço Requisitos de Gerenciamento Operacional de Serviço Desenho de Serviços e Topologia Diagnóstico de prontidão organizacional Programa de Serviço Plano de Transição de Serviços Plano de Aceitação de Operação de Serviços Critério de Aceitação de Serviço A partir da próxima postagem, estaremos tratando dos processos da fase do Desenho do Serviço. Vocês não perdem por esperar!! ITIL V3 – Desenho do Serviço – Processos – Gerenciamento do Catálogo de Serviço Amigos, a partir desta postagem entraremos no estudo dos processos do livro Desenho do Serviço do ITIL V3. Nesta fase do ciclo de vida do serviço, são previstos os seguintes processos: gerenciamento do Catálogo de Serviço, gerenciamento de Nível de Serviço, gerenciamento da disponibilidade, gerenciamento da segurança da informação, gerenciamento de fornecedores, gerenciamento da capacidade e o gerenciamento da continuidade de serviço de TI. Vamos dar o pontapé inicial com o processo de gerenciamento do Catálogo de Serviço, certo? Como já vimos em postagens anteriores, o Desenho de Serviço utiliza-se de forma constante do Catálogo de Serviço, por isso, nada mais natural que esta fase do ciclo de vida do serviço tenha um processo responsável por gerenciá-lo. O objetivo principal do processo de gerenciamento do Catálogo de Serviço é, como o próprio nome já diz, a gerência das informações existentes no Catálogo de Serviços. Na versão anterior do ITIL, esta 25
  • 26. gerência era feita como uma atividade dentro do processo de gerenciamento do Nível de Serviço, mas como o Catálogo ganhou um maior destaque na versão 3 do ITIL, uma vez que, em conjunto com o banco de dados de configuração, se tornou uma ferramenta primordial para o gerenciamento do serviço, passou a ter uma gerência própria. O gerenciamento do Catálogo de Serviço busca garantir que o catálogo seja sempre acurado e reflita os detalhes atuais, status, interfaces e dependências de todos os serviços que estão em operação ou que estão sendo preparados para entrar em operação. Além disso, existem outras atividades dentro deste processo, como por exemplo: acordo e documentação da definição de serviço com todas as partes relevantes, manter relacionamento com o gerenciamento de Portfólio de Serviço para definir e acertar o conteúdo do Portfólio de Serviço e do Catálogo de Serviço, entre outros. ITIL V3 – Desenho do Serviço – Processos – Gerenciamento de Níveis de Serviço Hoje falaremos sobre um dos mais importantes processos dentro da fase de Desenho do Serviço, o Gerenciamento de Níveis de Serviço. O foco principal deste processo está no relacionamento e na comunicação entre o provedor de serviço de TI e os clientes, ou seja, o processo de Gerenciamento de Níveis de Serviço é responsável por garantir que a TI e os clientes tenham expectativas claras e alinhadas sobre o nível de serviço a ser entregue. Os principais instrumentos que são criados e gerenciados por este processo são os, já comentados em outras postagens, Acordos de Nível de Serviço (ANS) e os Acordos de Níveis Operacionais (ANO). É importante salientar que não faz parte do trabalho do Gerenciamento de Níveis de Serviço a gestão dos contratos adjacentes. Ele se preocupará, apenas, com os níveis acordados em relação a um serviço que necessita de fornecedores externos. Não me recordo se já falei anteriormente aqui no blog, mas existe uma diferença vital que algumas pessoas confundem quando o assunto refere-se à garantia de satisfação em relação a um determinado serviço de TI. Pessoal! CLIENTE é diferente de USUÁRIO. Enquanto aquele refere-se à pessoa que paga pelo serviço, este refere-se à pessoa que utiliza o serviço. Tendo isso em mente, podemos afirmar que o Gerenciamento de Níveis de Serviço se preocupam em garantir a satisfação do CLIENTE e não do usuário. Além da criação dos ANSs e dos ANOs, o Gerenciamento de Níveis de Serviço é responsável pela elaboração de outros produtos que são importantes para a gestão do serviço. Abaixo relaciono esses produtos: RNS (Requisitos de Nível de Serviço) – Esses requisitos fazem parte do PDS (ver postagem sobre PDS). São baseados nos objetivos de negócio e usados para negociar objetivos de Níveis de Serviço. Tabela MANS (Monitoração de Acordos de Níveis de Serviço) – Esta tabela é usada para monitorar um ANS e ajuda a identificar e reportar os resultados alcançados em relação ao que foi acordado no ANS. É muito útil na gestão, uma vez que serve como instrumento de cobrança em relação às áreas internas da empresa e instrumento de comunicação e demonstração dos resultados com o cliente. Finalizando este processo, precisamos falar que o Gerenciamento de Níveis de Serviço também incentiva a criação de um PMS (Plano de Melhoria do Serviço). É papel deste processo, em conjunto com a Melhoria de Serviço Continuada, que veremos mais para frente, instigar e provocar a criação de um PMS, uma vez que tem visibilidade dos níveis acordados com os clientes, ou seja, as expectativas definidas e o resultado prático da prestação do serviço contratado. 26
  • 27. ITIL V3 – Desenho do Serviço – Processos – Gerenciamento de Disponibilidade Continuando a nossa navegação pelos mares dos processos do Desenho do Serviço, convido-os a conversarmos um pouco sobre o processo denominado de Gerenciamento de Disponibilidade. Este processo tem os seguintes objetivos: fazer e manter atualizado um Plano de Disponibilidade, garantir que o nível de disponibilidade entregues em todos os serviços atendam ou superem a necessidade de negócio acordada, prover um ponto focal de gerenciamento para todas as ações relacionadas à disponibilidade, ajudar no diagnóstico e na resolução da indisponibilidade relatada em incidentes e/ou problemas e fazer com que medidas proativas sejam tomadas a fim de melhorar a disponibilidade dos serviços, não se esquecendo, jamais, de verificar a viabilidade economica da solução. Para auxiliar todo esse trabalho do Gerenciamento de Disponibilidade, o ITIL V3 criou a figura do SIGD – Sistema de Informação do Gerenciamento de Disponibilidade. Este sistema não necessariamente deve ser composto de uma única ferramenta. Na verdade, o que se pretende é ter uma suíte de aplicações capaz de fornecer as seguintes informações relevantes para este gerenciamento: relatórios de gerenciamento de disponibilidade, plano de disponibilidade, critérios de desenho da disponibilidade, agenda de testes de disponibilidade, entre outros. É importante salientar que o processo de Gerenciamento de Disponibilidade não trata da continuidade do negócio e sim da disponibilidade dos serviços. Apesar de também pensar no futuro, o Gerenciamento de Disponibilidade está preocupado mais com o dia-a-dia das organizações e na sua capacidade de garantir a disponibilidade acordada com seus clientes. Para clarificar melhor as atividades deste processo, o ITIL organizou-as em dois grandes grupos: atividades reativas e atividades proativas. Vejamos a seguir as principais atividades desses dois grupos: Atividades reativas: monitoração da disponibilidade real entregue X metas acordadas, definição de medidas de disponibilidade, validação com o negócio em relação às metas de disponibilidade com a devida identificação de níveis de disponibilidade inaceitáveis e os seus impactos sobre o negócio e qualificação contínua de atividades para otimizar a disponibilidade. Ações proativas: identificar as funções de negócio vitais, desenhar e pospectar a disponibilidade e o plano de recuperação, entre outros. As atividades relatadas acima podem suscitar uma dúvida. Monitoração é atividade reativa? Isso mesmo meus caros amigos. Na verdade, a monitoração é reativa porque o ITIL considera que, ao identificar um problema na monitoração, de fato, o problema ocorreu! ITIL V3 – Desenho do Serviço – Processos – Gerenciamento da Segurança da Informação 27
  • 28. Antes de falarmos desse processo propriamente dito, acho que vale a pena tratarmos um pouco do assunto segurança da informação. O papo que informação é o ativo mais importante da empresa não é novo e, apesar de ser realmente uma verdade, as empresas só entenderam a mensagem apenas de alguns anos para cá. Ok, ok, sei que algumas empresas levam esse assunto a sério a algum tempo, mas não é a realidade da maioria. Quer ver? Quem conhece alguma empresa onde os funcionários deixam sobre suas mesas informações relevantes de reuniões realizadas, cópias de minutas de contrato e outras coisas que possam ser utilizadas por outras pessoas de alguma forma? Pois é... isso acontece lá no Japão e não aqui nas nossas empresas!!! (brincadeirinha...) Tendo a nítida noção de que Segurança da Informação é assunto sério e relevante, o ITIL, na versão 3, a promoveu a processo dentro do Ciclo de vida do Serviço. O processo de Gerenciamento da Segurança da Informação possui, portanto, quatro grandes objetivos, a saber: Disponibilidade: Garantir que a informação esteja disponível e utilizável quando requerida Confidencialidade: Garantir que a informação é observada e divulgada somente àqueles que têm direitos de saber. Integridade: Garantir que a informação esteja completa, acurada e protegida contra modificações não autorizadas. Autenticidade e não-repúdio: Garantir que a troca de informações comerciais entre as empresas sejam confiáveis. Vocês estão percebendo alguma semelhança do ITIL com as normas ISO (família 27000) que tratam de segurança da informação? Pois é, o ITIL se baseou exatamente nessas normas para escrever o seu processo. Assim sendo, não nos surpreende o ITIL ter adotado exatamente o mesmo ciclo PDCA descrito nas referidas normas. 28
  • 29. Para o ITIL, o processo de Gerenciamento da Segurança da Informação deveria ser o ponto focal para todas as questões de segurança da informação e deveria, insistentemente, garantir que uma Política de Segurança da Informação fosse criada, atualizada e que cobrisse todos os pontos de informações de TI. Para isso criou o SGSI – Sistema de Gerenciamento de Segurança da Informação. Assim como faz em outros processos, o ITIL não descreve o SGSI como uma ferramenta única, mas sim como um grupo de instrumentos capazes de permitir o gerenciamento. Neste caso, o ITIL sugere que o SGSI deva seguir o padrão da ISO 27001. Já que falamos da Política de Segurança, acho legal dizermos que ela não pode ser muito genérica, em que pese a possibilidade de ser inócua, nem pode ser muito densa, para evitar o engessamento da organização. Além disso, não se faz Política de Segurança sem o patrocínio do alto escalão da empresa e sem uma devida divulgação para todos, inclusive os clientes. Como sugestão, o ITIL aponta que a Política de Segurança da Informação deveria estar referenciada em todos os RNS, ANS, ANO e contratos adjacentes, além de ser revisada pelo menos uma vez ao ano. TIL V3 – Desenho do Serviço – Processos – Gerenciamento de Fornecedores O ITIL V3 especializou, como um processo a parte, as atividades relacionadas ao Gerenciamento de Fornecedores. Na versão anterior, este processo era tratado dentro do processo de Gerenciamento de Nível de Serviço, mas percebeu-se, com a maturidade do processo, que o relacionamento com fornecedores deve ser algo mais abrangente do que simplesmente definir e monitorar os níveis de serviços acordados. Tendo isso em mente, o ITIL definiu os seguintes objetivos para esse processo: garantir que os contratos adjacentes (underpinning contracts) com os fornecedores estejam alinhados com as necessidades do negócio e que tenham desempenho satisfatório durante a sua vigência, gerenciar o relacionamento com os fornecedores, criar e manter uma política de fornecimento e administrar uma Base de Dados de Fornecedor e Contrato (BDFC). Trocando em miúdos, este processo continua verificando se os níveis de serviço acordados com os fornecedores estão sendo cumpridos, mas, além disso, ele também se preocupa com outros aspectos do relacionamento com o fornecedor que vai desde a negociação do contrato, verificando se o contrato condiz realmente com que o fornecedor estará de fato entregando, até um gerenciamento integrado de todos os fornecedores baseado em um sistema e em uma política de fornecimento. Como aconteceu em outros processos e como já dissemos acima, o ITIL sugeriu a criação de um sistema chamado de BDFC – Base de Dados de Fornecedores e Contratos. Este sistema deve documentar todas as informações de contratos e fornecedores com os principais atributos necessários para garantir uma gestão dos contratos e dos fornecedores. Este sistema será parte integrante de um outro sistema maior que falaremos em postagens futuras. Sei que algumas pessoas não aguentam de curiosidade. Dessa forma, para não os matar de curiosidade, o sistema em questão, que o BDFC faz parte é o SCGS – Sistema de Conhecimento de Gerenciamento de Serviço. Gostaria de informar que estamos quase terminando os processos referentes ao Desenho do Serviço! Nas próximas postagens estaremos verificando os dois últimos processos que faltam ser vistos, a saber: o Gerenciamento de Capacidade e o Gerenciamento de Continuidade de Serviço de TI. ITIL V3 – Desenho do Serviço – Processos – Gerenciamento da Capacidade Falaremos nesta postagem do processo de Gerenciamento da Capacidade. Este processo parece ser o grande calcanhar de aquiles de muitas organizações que prestam serviços de TI. Não é raro, no 29
  • 30. mercado de serviços de TI, verificarmos empresas que vendem algo que sabem, ou pelo menos deveriam saber, que não têm condições de entregar. Isso, na minha humilde opinião, é dar um tiro no próprio pé! É claro, e não quero passar a impressão de ingenuidade, que existem outros fatores que estão ligados a venda de serviços de TI, especialmente no que tange a venda de serviços para governo, mas mesmo assim, vender algo que não se sabe se tem ou se terá capacidade de entregar é algo no mínimo arriscado, em uma visão mais eufemista. Para tentar minimizar esse problema, o ITIL disponibiliza o processo chamado de Gerenciamento da Capacidade. Este processo tem como objetivo principal confeccionar e manter um Plano de Capacidade e Desempenho adequado e atualizado, garantindo que uma capacidade de TI, financeiramente justificada, será sempre provida a todas as áreas de TI a fim de atender as necessidades do negócio (desempenho inclusive), atuais e futuras, que estejam acordadas. Chamo atenção de vocês para duas expressões importantes utilizadas no parágrafo acima: “financeiramente justificada”. Gerenciar capacidade resume-se essencialmente na habilidade em balancear os custos e a necessidade de recursos para provimento de uma determinada demanda de negócio. A capacidade tem que ser justificada financeiramente em termos das necessidades de negócio e do uso mais eficiente dos recursos. Se isso não acontecer, cairemos no erro que pode ser melhor explicado pelo trecho de uma música que diz: “todo mundo quer ir para o céu, mas ninguém quer morrer”, ou seja, todo mundo quer o que há de mais novo e moderno em termos de serviços de TI, mas poucos querem bancar por essa modernidade. “atuais e futuras”. O Gerenciamento de Capacidade não pode se ater apenas ao que está sendo entregue hoje. É primordial que esse trabalho esteja também olhando para o futuro e definindo a capacidade para o crescimento. Sob esse aspecto, entra outra habilidade essencial do Gerenciamento da Capacidade, qual seja: o saber balancear o provimento do serviço contra a demanda feita, ou seja, garantir que o provimento do serviço de TI atende as demandas feitas pelo negócio, tanto agora como no futuro. Fechando a ideia desse processo, o Gerenciamento de Capacidade deve ser o ponto central de gerenciamento para todas as questões relacionadas a capacidade e desempenho. Além do Plano de Capacidade, este processo é o responsável por fazer a gestão de três outros subprocessos: o Gerenciamento da Capacidade do Negócio, que vai estudar e entender os requisitos futuros de negócio; o Gerenciamento da Capacidade do Serviço, que trata do desempenho e da capacidade atual e o Gerenciamento da Capacidade do Componente, que trata da capacidade, utilização e desempenho dos itens de configuração. TIL V3 – Desenho do Serviço – Processos – Gerenciamento da Continuidade de Serviço de TI Amigos leitores, com essa postagem encerramos todos os processos da fase do Desenho do Serviço dentro do ciclo de vida do serviço preconizado pelo ITIL. O processo que vamos tratar aqui necessita de algumas premissas que temos que explorar. A primeira premissa é entender exatamente como o ITIL entende a palavra desastre. Quando ouvimos falar em desastre, nossa mente automaticamente faz associação com acontecimentos trágicos e de grandes proporções, como por exemplo: terremotos, enchentes, vulcões, tsunamis, acidentes, terrorismo, etc. De fato, todos os exemplos citados são considerados como desastres, porém, na visão do ITIL, o desastre pode ser qualquer acontecimento que comprometa de forma inequívoca a prestação do serviço de TI. Assim sendo, fatos mais simples e rotineiros como uma greve ou uma pane em um determinado sistema de comunicação podem ser considerados desastres dentro da ideia do ITIL. A segunda premissa que temos que ter em mente é que a continuidade do serviço de TI é uma parte 30
  • 31. integrante da continuidade do negócio, mas as duas não podem ser confundidas, uma vez que aquela é apenas um subset desta e que a continuidade de negócio englobará outros planos de continuidade como o da área de RH, de logística, financeira, entre outros. Essa diferença fica mais difícil de se entender quando o negócio da empresa é TI. Neste caso, a continuidade dos serviços de TI provavelmente será o carro-chefe de todos os planos de continuidade do negócio, pois TI, neste caso, é o negócio. Entendido essas duas premissas podemos dizer que o processo de Gerenciamento da Continuidade de Serviço de TI tem como principal objetivo manter um conjunto de Planos de Continuidade de Serviços de TI e os planos de recuperação que suportam os planos de continuidades de negócio. Ah! Já ia me esquecendo, mas não podemos deixar de dizer que Plano de Continuidade é diferente do plano de recuperação. Enquanto este se preocupa em voltar a situação do serviço de TI ao ponto anterior ao desastre, aquele se preocupa em fazer com que o serviço de TI continue, mesmo que temporariamente, durante um desastre. O processo de Gerenciamento da Continuidade de Serviço de TI, além do objetivo descrito acima, possui uma série de outros objetivos, como por exemplo: atualizar regularmente um documento chamado de AIN – Análise de Impacto no Negócio ou BIA para os mais íntimos (Business Impact Analysis); conduzir regularmente exercícios de análise e gerenciamento de riscos; fornecer aconselhamento e orientação para todas as outras áreas do negócio e de TI em todas as questões de continuidade relacionadas com a recuperação, entre outros. É bom lembrar, também, que o Gerenciamento da Continuidade de Serviço de TI é mais amplo do que o Gerenciamento de Disponibilidade, uma vez que este se preocupa com a disponibilidade do serviço no presente e no futuro, enquanto que o Gerenciamento da Continuidade de Serviço de TI tem o foco na continuidade do serviço em caso de desastre. Para terminar, gostaria de elencar as interfaces que interagem com o Gerenciamento da Continuidade de Serviço de TI. Além do BIA, já comentado acima, existem ainda: PCN – Plano de Continuidade do Negócio, que define os passos necessários para restaurar processos de negócio após um desastre; GCN – Gerenciamento da Continuidade do Negócio, responsável por gerenciar os riscos que podem afetar gravemente os negócios; Análise de Riscos, que dispensa explicações. Terminados os processos, vamos entrar agora na parte da tecnologia e da arquitetura da fase do Desenho do Serviço. ITIL V3 – Desenho do Serviço – Tecnologia eArquitetura Seguindo a estrutura de tópicos proposta quando começamos a falar do ITIL V3 e finalizado todos os processos, falaremos nesta postagem da Tecnologia e da Arquitetura para a fase do Desenho do Serviço no ciclo de vida do serviço. Para esta fase, existem várias ferramentas e técnicas que podem ser utilizadas para que os processos desta fase possam ser desempenhados com eficiência. Prestem bastante atenção no que dissemos na sentença anterior! É importante se lembrar que as ferramentas devem suportar os processos e não o contrário. Sendo assim, as ferramentas utilizadas no Desenho do Serviço devem ser capazes de habilitar o desenho de hardware, o desenho de software, o desenho dos ambientes, o desenho dos processos e o desenho dos dados. Como dissemos, existem várias alternativas de ferramentas e técnicas que podem atender às necessidades de cada empresa e, particularmente, acho que a escolha da melhor ferramenta depende do negócio e das políticas existentes. Uma boa prática na escolha da ferramenta é não esperar que 100% dos requisitos sejam atendidos. Existe uma pesquisa, acho que é do Gartner group, mas não 31
  • 32. tenho certeza, que diz o seguinte: "uma ferramenta adequada para atender a um propósito específico é aquela que antede 80% ou mais dos requisitos do negócio". Cabe aqui uma pequena ressalva, é importante salientar que dentro dos 80% dos requisitos atendidos, todos os requisitos mandatórios devem estar contemplados. Parece óbvio, mas não é... O ITIL preconiza que, seja qual for o tipo de ferramenta escolhida, o atendimento dos requisitos pode ser diferenciado entre: Padrão de Fábrica. Os benefícios que atendem aos requisitos vêm de fábrica. Configuração. A ferramenta pode ser configurada para atender o requisito e esta configuração será preservada para todas as atualizações do produto. Customização. A ferramenta tem que ser alterada para atender o requisito. As atualizações do produto podem ser alvos de outras customizações para não perder a especificidade requerida. Finalizamos a fase do Desenho do Serviço no ciclo de vida do serviço preconizado pelo ITIL V3. A partir da próxima postagem, entraremos em uma nova fase, a Transição do Serviço. ITIL V3 – Transição do Serviço – Metas e Objetivos Nesta postagem damos início a uma nova fase do ciclo de vida do serviço segundo o ITIL V3, conhecida como Transição de Serviço!! A meta principal desta fase é assegurar que tudo aquilo que foi planejado seja executado de fato. É 32
  • 33. claro que no mundo real, nem tudo o que é planejado consegue realmente ser executado, mas a Transição do Serviço deve buscar que o planejamento se torne realidade e se materialize em um serviço de TI. Essa meta ambiciosa, para que possa ser atingida, é dividida em outras metas que a ajudam na caminhada, como por exemplo: definir, alinhar e validar as expectativas dos clientes sobre o desempenho e a utilização dos novos serviços e também daqueles que foram alterados, diminuir ao máximo as variações de desempenho na transição dentro da produção, minimizar erros conhecidos a fim de controlar melhor os riscos da transição dentro da produção e garantir que o serviço possa ser utilizado de acordo com os requisitos especificados. Para atingir as metas, alguns objetivos foram definidos. Dentre eles, destaco os seguintes: Planejar e gerenciar os recursos do serviço de TI, seja ele novo ou não, no ambiente de produção. Criar planos claros que permitam que mudanças no negócio ou no cliente alinhem suas atividades com os planos de transição do serviço. serviços. Melhorar a satisfação do cliente, assim como o da equipe do gerenciamento de Garantir que haja o mínimo impacto possível para os imprevistos que ocorram no ambiente de produção (tarefa nada fácil em alguns casos!!). Bem, tendo em mente as metas e objetivos da fase de Transição do Serviço, daremos continuidade com os conceitos e definições importantes para que possamos entender os processos que compõem esta importante fase do ciclo de vida do serviço... ITIL V3 – Transição do Serviço – Conceitos e Definições – IC – Item de Configuração 33
  • 34. Inciando os conceitos e definições referentes à Transição do Serviço, falaremos nesta postagem de um conceito bem antigo do ITIL, o Item de Configuração (IC). Um Item de Configuração é qualquer componente que necessite ser administrado para que um determinado Serviço de TI possa ser entregue. Parece amplo, e é mesmo. A figura colocada nesta postagem faz uma analogia com o conceito que acabamos de falar. Imagine que o Serviço a ser prestado seja alimentar uma família de forma equilibrada. Neste exemplo, a geladeira, a comida, as bebidas, a energia, entre outros seriam os Itens de Configuração do Serviço, sacaram? Existe uma grande variedade de ICs que vão desde serviços de TI, hardware, software e ANS (acordos de níveis de serviço) até pessoas, prédios, documentação formal, entre outros. Devido a esta grande variedade, o ITIL classificou os ICs nas seguintes categorias: ICs de Ciclo de Vida de Serviço – Esses ICs formam uma visão dos serviços prestados pela empresa de serviços de TI, definem como são entregues, quais benefícios e qual o custo de produção. Como exemplo, podemos citar: Planos de Gerenciamento de Serviços, Casos de Negócio, Planos de Ciclo de Vida de Serviço, etc. ICs de Serviço – Esses ICs podem ser subdivididos em Ativos de Competência do Serviço (gerenciamento, organização, processos, conhecimentos, pessoas, etc) e em Ativos de recurso do Serviço (capital financeiro, sistemas, aplicativos, dados, infraestrutura, instalações, informações, pessoas – de novo -, etc). ICs de Organização – Dizem respeito a alguma documentação que identifique as características de um IC. ICs Internos – São os IC usados em projetos individuais da prestadora de serviços de TI, como por exemplo: data center (tangíveis) e softwares (intangíveis). São necessários para entregar e manter um determinado serviço de TI. 34
  • 35. ICs Externos – Como o próprio nome já diz, são os ICs que tratam de serviços externos além dos acordos e requisitos do cliente. ICs de Interface – São os ICs necessários para a entrega fim a fim dos serviços. Apesar de ser amplo, os ICs não são “a casa da mãe Joana”. Não podemos nos esquecer que o gerenciamento de itens de configuração será o responsável por definir o que deve entrar no escopo deste gerenciamento e o que deve ser deixado de fora. Os ICs devem ser selecionados utilizando critérios estabelecidos, agrupados, classificados e identificados de uma forma que permita a rastreabilidade e a administração dos mesmos durante todo o ciclo de vida do serviço. Além disso, é claro que os IC devem estar armazenados em um sistema, que falaremos com um pouco mais de profundidade em outra postagem, chamado de SGC (Sistema de Gerenciamento de Configuração). ITIL V3 – Transição do Serviço – Técnicas e Ferramentas – Sistemas e mais sistemas... O ITIL V3 descreveu uma série de sistemas e ferramentas para suportar os processos responsáveis pela gestão dos serviços de TI. Dentro da fase de Transição do Serviço, o ITIL elencou as seguintes ferramentas que falaremos nesta postagem: SGC (Sistema de Gerenciamento de Configuração), BDGC (Banco de Dados do Gerenciamento da Configuração), BMD (Biblioteca de Mídia Definitiva) e o SGCS (Sistema de Gerenciamento do Conhecimento do Serviço). SGC (Sistema de Gerenciamento de Configuração) O SGC é uma ampliação do famoso CMDB da versão 2.0 do ITIL. Sua principal função é criar e manter os relacionamentos dos componentes (itens de configuração) que fazem parte de um determinado serviço de TI ofertado. O SGC é composto do modelo lógico, que representa graficamente os vínculos entre os mais diversos itens de configuração responsáveis por configurar um determinado serviço de TI, e do BDGC, onde, a grosso modo, ficam registrados os atributos de cada item de configuração. BDGC (Banco de Dados do Gerenciamento da Configuração) Como dissemos acima, o BDGC registra os atributos de cada item de configuração responsável pela montagem da árvore de relacionamento para identificação de cada serviço de TI. O BDGC conta também com as bases onde estão guardados os bancos de dados de incidentes, problemas e mudanças, uma vez que possui a responsabilidade de manter as informações de configuração de cada item de configuração durante todo o ciclo de vida do serviço. BMD (Biblioteca de Mídia Definitiva) Esta biblioteca é responsável por manter a matriz de alguns sistemas. Entende-se matriz como sendo a cópia original de Software de um determinado sistema. Prestem bastante atenção nisso, o BMD preocupa-se com o software e não com o hardware necessário para o funcionamento do sistema. Sob este aspecto, devemos considerar software como sendo, não apenas o programa propriamente dito, mas também a parte de licenças de uso daquela aplicação. Outro aspecto importante sobre o BMD é que a biblioteca não deve se preocupar apenas com os softwares de serviços que estão em produção, mas sim com todos os softwares, inclusive aqueles que 35
  • 36. não estão mais em produção, caso seja necessário restaurá-los em algum momento do tempo. Cabe aqui uma pequena reflexão que o ITIL não trata. O que fazer caso o software guardado necessite de uma infraestrutura que já não existe mais no mercado nem na organização? O que fazer? Bem, na minha singela opinião, cada organização deve manter um programa de verificação anual para descarte ou transformação de alguns softwares para manter uma certa compatibilidade com a infraestrutura mínima disponível para sua execução. Essa é a minha opinião, pois o ITIL não trata este assunto de forma direta. SGCS (Sistema de Gerenciamento do Conhecimento do Serviço) O SGCS é um grande sistema montado por várias outras ferramentas. Entre elas podemos citar o próprio SGC e, como consequência, o BDGC, comentados acima. O objetivo principal deste sistema é o de administrar o conhecimento e as informações dos serviços de TI da organização. Parece simples, mas não é. Independentemente de qualquer sistema, manter o conhecimento é uma tarefa árdua, que exige planejamento de treinamentos constantes e manutenção das informações relevantes para que um serviço possa ser administrado e prestado com qualidade constante. ITIL V3 – Transição do Serviço – Conceitos e Objetivos – DICS O DICS, também conhecido como DIKW(em inglês), é a sigla utilizada para a seguinte definição: Dado - Informação - Conhecimento - Sabedoria. Na verdade, retrata o processo evolutivo que faz com que um dado se transforme em sabedoria. Vejamos como. A evolução pode ser medida em termos do Contexto e do Entendimento. Se fizermos um Gráfico, conforme a figura abaixo (colocada em Inglês), poderemos entender a evolução do conhecimento com os seguintes conceitos: Dado (Data): conjunto de fatos. O famoso dado cru. Informação (Information): é o dado contextualizado. Permite julgamento de valor e responde as perguntas: Quem? O quê? Quando? Onde? Conhecimento (Knowledge): composto de experiências, sejam elas tácitas ou não. É a informação acumulada sobre um determinado assunto. Permite identificar o “como” as 36
  • 37. coisas são feitas. Sabedoria (Wisdom): Representa o conjunto de conhecimentos e permite identificar o “porquê” as coisas devem ser feitas. Tenho nítida noção que este tipo de conceito se aproxima mais do campo filosófico do que da informática, mas ele será primordial quando tratarmos do Gerenciamento do Conhecimento, processo que trataremos mais tarde na fase de Transição do Serviço. ITIL V3 – Transição do Serviço – Conceitos e Definições – Unidade de Liberação Dando continuidade aos conceitos e definições que fazem parte da fase de Transição do Serviço, falaremos nesta postagem da famosa Unidade de Liberação. Este nome, que pode parecer complicado ao primeiro contato, significa, na verdade, um conjunto de componentes de um serviço de TI, incluindo infraestrutura e software, que é, costumeiramente, liberado em conjunto, de acordo com uma política definida pela organização. Vamos tentar melhorar o entendimento, ok? Para facilitar, disponibilizei a figura acima. Imaginemos o Sistema X que possui alguns módulos. A ideia aqui é identificar que uma Unidade de Liberação é composta pelos produtos suficientes para desempenhar plenamente uma determinada função (triângulos amarelo e verde). Assim, no exemplo utilizado, quando houver uma mudança no Módulo 1 do Sistema X, todo o triângulo amarelo deve ser avaliado antes da efetivação da mudança. É importante salientar ainda que existem áreas de intersecção entre Unidades de Liberação, como podemos ver na figura. Neste caso, a complexidade aumenta, uma vez que o trabalho de mudança necessita verificar itens que podem impactar outros módulos que não estão sendo, inicialmente, alvo da mudança. Acho que não preciso mencionar, mas para não dizer que não falei de flores: é extremamente necessário que haja um sistema de configuração bem montado para que os componentes que fazem 37
  • 38. parte de uma determinada Unidade de Liberação possam ser identificados e mapeados. Finalizando o assunto, para que se possa fazer um gerenciamento efetivo das mudanças ocorridas nas Unidades de Liberação, faz-se necessário a criação de uma Linha de Base. A Linha de Base funciona como uma referência que poderá ser usada como ponto de partida em futuras comparações. Além disso, serve também como ponto de recuperação, caso uma Mudança ou Liberação falhar e como ponto de identificação e rastreamento quando da alteração de um IC. ITIL V3 – Transição do Serviço – Conceitos e Objetivos – Mudança de Serviço Na visão do ITIL, uma mudança significa a adição, a modificação ou a remoção de um determinado serviço de TI ou ainda de um componente de um determinado serviço de TI que tenha sido autorizada, planejada ou suportada. Isso significa dizer que o escopo de uma mudança inclui todos os Serviços de TI, os itens de configuração, os processos, as documentações, etc. Vocês podem estar se perguntando: documentações? Processos? Siiimmmm caro leitor, uma mudança de um contrato, por exemplo, pode ser encarada como uma mudança do serviço de TI. Toda mudança deve ser feita por meio de uma RDM (requisição de mudança). Este documento é um pedido formal e padronizado da mudança que se pretende fazer. Uma RDM deve conter os detalhes da mudança e seguirá um rito processual de acordo com o tipo de mudança que está sendo proposto. Para facilitar o entendimento de quais atividades devem ser efetuadas, o ITIL define três diferentes tipos de mudança, a saber: Normal: É o caminho comum da mudança, ou seja, são regras gerais que valem para todas as mudanças. Padrão: é aquela executada em um serviço ou na infraestrutura para a qual é utilizada uma abordagem pré-autorizada. Normalmente acontece com mudanças de baixo impacto que possuem atividades bem conhecidas e documentadas e cuja autorização é dada antecipadamente. Emergencial: está reservado para alterações que têm o objetivo de concertar um erro em um serviço de TI que está impactando negativamente o negócio. Normalmente possuem um critério par serem feitas, como por exemplo, a necessidade de aprovação. ITIL V3 – Transição do Serviço – Técnicas e Ferramentas – Política de Liberação Nesta postagem vamos explorar uma técnica, que no final de sua utilização se torna uma ferramenta importantíssima para a administração dos ambientes de serviço de TI: a Política de Liberação. Esta política materializa-se em um documento formal que tem o papel principal de organizar a forma de liberação das versões e das distribuições dos serviços de TI. A Política de Liberação deve conter algumas informações básicas, como por exemplo: papéis e responsáveis, identificação das liberações, convenções de nomenclatura dos diferentes tipos de liberação, definição da janela a ser utilizada para liberações de versões e definição dos tipos de liberações existentes na organização. Trocando em miúdos, como dizia o meu avô, a Política de Liberação deve tratar as regras gerais para a operação dos ambientes, não apenas daqueles que estão em produção, mas também os ambientes de homologação, treinamento, desenvolvimento, testes, etc. 38
  • 39. Um aspecto importante da Política de Liberação é a estratégia para implantação de determinadas versões. Existem algumas alternativas, como por exemplo: a estratégia de implantação Faseada, onde a liberação de versões ocorre para um grupo de máquinas específico que será atualizado em um determinado momento. Nesta estratégia, novas máquinas aguardarão a próxima fase da implantação para receberem, também, as atualizações. Outra estratégia é conhecida como “Big bang”. Nesta estratégia, todas as máquinas aptas a receber a nova versão são atualizadas. A partir daí, a cada nova máquina há uma atualização individual. Existem outras estratégias que são menos importantes, mas o entendimento que queremos passar é o da importância de cada serviço ter a sua estratégia, assim sendo, cada organização deve analisar a melhor forma de fazer as liberações e as distribuições para os seus serviços de TI. A partir da próxima postagem, entraremos nos processos da fase de Transição do Serviço! ITIL V3 – Transição do Serviço – Processos – Gerenciamento de Mudanças Nessa postagem falaremos de um dos processos mais testados, discutidos, aplicados e importantes da fase de Transição do Serviço: o famosíssimo Gerenciamento de Mudanças. No ITIL V3, o Gerenciamento de Mudanças é o responsável por atender aos requisitos das mudanças que acontecem nos serviços e no negócio dos clientes sem perder de vista a busca pela maximização do valor e pela redução de incidentes, paradas não programadas e/ou retrabalhos. De certa forma, o Gerenciamento de Mudanças materializa os requisitos que estão vindo da fase de Desenho do Serviço, mas é importante salientar que não é responsabilidade do Gerenciamento de Mudanças implementar a mudança (“botar a mão na massa”). O seu papel se baseia mais na coordenação, gestão e acompanhamento do processo. Assim sendo, podemos dizer que o 39
  • 40. Gerenciamento de Mudanças visa garantir que métodos e procedimentos padronizados sejam utilizados para que as mudanças possam atingir seus objetivos. Trocando em miúdos, o Gerenciamento de Mudança zela para que as mudanças possam seguir um rito formal, mas ágil quando necessário, que vai desde o registro da mudança até a sua implementação, passando pelo planejamento, pela avaliação, pela autorização (quando necessário) e pela documentação. Não é nossa intenção descrever cada atividade do Gerenciamento de Mudanças aqui no nosso humilde blog, mas existem informações que valem a pena serem colocadas. A primeira informação que julgo relevante diz respeito ao fato de que a mudança pode ser qualquer coisa que possa ser classificada e altere um estado de um item de configuração. Isso que dizer que uma mudança pode ser de um projeto, assim como pode ser de um serviço de TI. Desta forma podemos dizer que todas as outras fases do ciclo de vida do serviço podem utilizar-se do processo de Gerenciamento de Mudança. Outra informação relevante é a de que uma mudança pode ser classificada de diferentes formas. Cada classificação indicará a forma como o processo de mudanças será conduzido. Mudanças Padrões, por exemplo, são mudanças que tem um risco baixo, são pré-aprovadas e são mais comuns do dia a dia. Mudanças mais complexas podem necessitar de análise mais profunda, criação de planos de recuperação e necessidade de validação por parte de alguns comitês. Por falar em comitês, o ITIL V3 fala dos seguintes comitês de aprovação de mudanças: CCM (Comitê Consultivo de Mudanças). Comitê composto por pessoas do negócio e pessoas da área técnica. Tem a função de aconselhar como uma determinada mudança deverá ocorrer em termos de avaliação, agendamento e priorização CCME (Comitê Consultivo de Mudanças Emergenciais). Este comitê é um subconjunto do CCM e é responsável por decidir sobre mudanças de alto impacto que sejam emergenciais. ITIL V3 – Transição do Serviço – Processos - Gerenciamento de Configuração eAtivos do Serviço Continuando a nossa viagem pelos processos da fase de Transição do Serviço do ciclo de vida dos serviços preconizado pelo ITIL V3, falaremos nesta postagem sobre o Gerenciamento de Configurações e Ativos do Serviço. Se pudéssemos resumir os objetivos desse processo em uma única palavra, essa palavra seria, sem sobra de dúvidas, CONTROLE. O Gerenciamento de Configuração é um processo base que suporta outros processos de Gerenciamento de Serviços a fim de que os Controles sobre os serviços de TI e seus ativos estejam disponíveis para os diversos processos. Apesar de parecer óbvio, é bom lembrar que o Gerenciamento de Configuração tem que ser muito bem conduzido para que ele possa prover informações sobre as configurações dos serviços de TI de forma precisa, diminuindo ao máximo problemas de qualidade e conformidade na entrega dos serviços por causa de configurações falhas dos ativos e dos próprios serviços. Sobre esse aspecto, devemos lembrar que o Gerenciamento de Configuração é muito mais complexo do que um inventário, uma vez que um inventário simples traria muita informação que não faria sentido para o serviço de TI e o Gerenciamento de Configuração tem o papel de elencar e relacionar todos os ativos, serviços e infraestrutura de forma a encadear todas as dependências entre os itens de configuração que afetam um determinado serviço de TI . Além disso, um item de configuração pode ser qualquer coisa que impacte na prestação do serviço, incluindo aí, além dos ativos mais óbvios de infraestrutura, ativos como ANS, ANO, Serviços Técnicos, Serviços de Apoio, Softwares, etc. Outra informação importante diz respeito a algumas atividades desse processo. O Gerenciamento de Configuração deve definir o escopo do que será gerenciado de forma a uniformizar o processo de gerência sobre os itens de configuração dos serviços. Mudanças que porventura venham a acontecer em uma determinada configuração de um serviço deve ser feita por meio do Gerenciamento de 40
  • 41. Mudança (ver postagem anterior para mais informações sobre esse importante processo) e finalmente, o processo de controle e aperfeiçoamento dos mecanismos deve sermpre ser melhorado, com o aumento da maturidade neste processo. ITIL V3 – Transição do Serviço – Processos – Gerenciamento de Liberação e Implantação O processo de Gerenciamento de Liberação e Implantação é o responsável por executar a instalação de pacotes de liberação. Na verdade, este processo, além de instalar, é responsável também por construir, testar e implantar os pacotes de liberação. Vocês podem estar se perguntando, mas o que é um pacote de liberação? Segundo o ITIL, um pacote de liberação é composto de todos os itens necessários para que uma determinada mudança de um serviço ou a implantação de um novo serviço possa ser feito de forma completa, ou seja, estamos falando não apenas do serviço propriamente dito, em relação a software e hardware, mas também de documentos, correlacionamentos entre serviços, etc. Pelo o que podemos perceber, a palavra chave desse processo é planejamento. O processo de Gerenciamento de Liberação e Implantação deve garantir a confecção e manutenção de planos suficientemente claros e abrangentes para que as mudanças ou implantações de novos serviços possam acontecer sem grandes impactos. Por ser um processo que “mete a mão na massa”, ele interage com uma série de outros processos do ITIL, especialmente os processos de Gerenciamento de Mudança e o Gerenciamento de Configuração. Outro ponto importante em relação ao Gerenciamento de Liberação e Implantação que não pode ser negligenciado, é o Suporte para Período de Funcionamento Experimental (SPFE). Este suporte faz, na verdade, uma operação assistida, por um determinado período tempo até que haja a estabilização do serviço que foi implementado ou que foi alterado. ITIL V3 – Transição do Serviço – Processos - Gerenciamento do Conhecimento Nesta postagem finalizamos os processos da etapa de Transição do Serviço do ITIL V3 com o processo chamado de Gerenciamento do Conhecimento. Este processo trata de um assunto onde 100 em cada 100 empresas entendem que é de suma importância para a prestação de serviço com qualidade e eficiência, mas muitas empresas continuam tendo muita dificuldade em fazer, na prática, com que seja de fato implementado. Quem nunca falou com uma empresa onde, dependendo da pessoa ou da área que te atende, a informação chega a ser oposta àquela dada por uma outra área da mesma empresa? Este tipo de problema expõe o prestador de serviço de forma extremamente negativa e tira a confiança dos clientes quanto ao serviço prestado. Por ser um processo utilizado por todos os outros processos do ITIL, o Gerenciamento do Conhecimento tem como meta principal certificar-se que a informação certa (confiável e integra) é entregue a pessoa correta (desde o atendente até o presidente) e no tempo hábil (tempestivamente) para que a mesma possa tomar decisões. Parece simples e bastante óbvio, mas na prática, a história é outra. O segredo para que a coisa toda funcione está na criação de métodos e ferramentas automatizadas de forma que a informação possa ser disseminada de forma eficiente. Existem uma série de ferramentas que prometem o paraíso, no que diz respeito à disseminação de informação, mas atentem-se que inundar a organização com informações irrelevantes pode ser tão nocivo quanto não disseminar informação alguma. Assim, os processos e responsabilidades devem estar bem descritos, para que a ferramenta possa agir de acordo com a política da empresa e seus processos e não o contrário. Segundo o ITIL, algumas informações seriam básicas para que os processos possam tomar decisões 41
  • 42. sobre um determinado serviço, entre elas podemos citar: qual o serviço, quem o está utilizando, o estado atual, as dificuldades, restrições e impactos no serviço, etc. Queridos leitores, finalizamos a fase de Transição do Serviço. A partir das próximas postagens entraremos na fase de Operações de Serviço, dentro do ciclo de vida do serviço preconizado pelo ITIL V3. Esta fase possui os processos mais maduros que vieram das versões anteriores do ITIL e acredito que grande parte dos leitores desse blog já se familiarizaram com alguns dos processos. O desafio é trazer informações novas e que sejam relevantes para uma gestão inteligente de TI... Vamos juntos? ITIL V3 – Operação do Serviço – Metas e Objetivos Iniciamos nesta postagem a falar de uma nova etapa do ciclo de vida do serviço, a Operação do Serviço. Após todo o trabalho realizado nas outras etapas (estratégia, desenho e transição), chega o momento em que o cliente, de fato, irá perceber os benefícios do serviço de TI contratado por ele. Nesta etapa do ciclo de vida, espera-se que um novo serviço ou um serviço que tenha sido alterado esteja pronto para encarar a “batalha” do dia a dia. Diante desse desafio, o ITIL definiu como metas da Operação do Serviço, a coordenação e a execução de processos e/ou atividades necessárias para que o serviço de TI contratado seja entregue e possa funcionar de acordo com os níveis de serviços acordados. Além disso, a Operação do Serviço não deve deixar de fazer a gestão da tecnologia utilizada pelos seus processos e atividades a fim de que a entrega e o suporte ao serviço sejam garantidos. Essa gestão é necessária uma vez que há um uso intensivo de ferramentas nessa etapa do ciclo de vida, já que, as mudanças no funcionamento dos serviços podem ser facilmente percebidas pelo cliente, o que torna as ações dessa etapa algo muito 42
  • 43. sensível. Além das metas descritas acima, o ITIL também definiu alguns objetivos para a fase da Operação do Serviço. Listamos abaixo alguns que julgamos mais relevantes: Monitorar Desempenho. Esse objetivo pode ser entendido como avaliar as métricas, coletar dados continuamente e confrontá-los com os níveis acordados. É bom lembrar que a Operação do Serviço é a fase responsável pela coleta de dados que irão subsidiar o trabalho do Gerenciamento do Conhecimento (transformação de dado em informação e depois em conhecimento e sabedoria, lembram?). Projetar processos para a operação do dia a dia. Parece bem óbvio, mas é importante que esteja definido por escrito que essa responsabilidade cabe a alguém dentro da fase de Operação do Serviço. Gerenciar a Disponibilidade do Serviço. Corrigir problemas. Restabelecer o funcionamento normal dos serviços que estejam com alguma falha. Gerenciar a demanda. Passaremos a trabalhar com os conceitos, técnicas, processos e ferramentas utilizadas pela Operação do Serviço a partir das próximas postagens. Vocês não perdem por esperar!!! TIL V3 - Operação do Serviço - Conceitos e Definições - Evento eAlerta Queridos leitores, antes de adentrarmos pelo mundo da Operação do Serviço, precisamos equacionar alguns conceitos que geram dúvidas nas cabeças de muitas pessoas que estão iniciando na utilização do ITIL, especialmente na versão 3. Um desses conceitos diz respeito a diferença entre Evento e Alerta. Segundo o ITIL, “um evento pode ser definido como qualquer ocorrência que possa ser detectada e que tenha um significado para a gerencia da infraestrutura de TI ou para a entrega do serviço”. Percebam que não é qualquer coisa e sim algo que tenha importância para o serviço. A partir de um evento é que se pode, ou não, gerar alertas que deverão ser tratados. Assim sendo, o alerta é um subproduto do evento, ou seja, deriva da monitoração de eventos, sacaram? 43
  • 44. Se pudéssemos colocar de uma forma mais simplificada, diríamos que, conforme figura acima, um evento pode gerar um registro informativo ou um alerta. O alerta pode virar um incidente, a ser tratado pelo processo de Gerenciamento de Incidentes ou pode necessitar de uma verificação de alguma área técnica, de forma proativa, a fim de evitar que o evento venha a se tornar um incidente de fato. A partir da análise técnica, pode ser que um determinado alerta acabe se transformando em um incidente também. É importante salientar que os eventos podem ser criados de forma eletrônica ou de forma manual, e normalmente são identificados por meio de ferramentas de monitoração. O ITIL define dois tipos de ferramentas de monitoração, a saber: Ferramentas de monitoração ativas. São ferramentas que identificam os Itens de Configuração de um determinado serviço e verificam sua disponibilidade e seu status, a fim de determinar se o seu comportamento está fugindo daquilo que é considerado normal para um determinado serviço de TI. Ferramentas de monitoração passivas. São ferramentas que detectam e correlacionam alertas ou comunicações gerados pelos itens de configuração de um determinado serviço de TI. Apenas para finalizar, consideremos que alertas identificam que um limite de algum item de configuração foi atingido ou que algo diferente do seu funcionamento normal foi alterado ou ainda, no pior caso, que uma falha ocorreu. Neste último caso, provavelmente o alerta evoluirá para um incidente. Por falar em incidente, vamos, na próxima postagem, definir o que o ITIL entende como incidente, antes mesmo de adentrarmos no processo de Gerenciamento de Incidentes propriamente dito. ITIL V3 – Operação do Serviço – Conceitos e Definições – Incidentes e Problemas 44
  • 45. Para aqueles que estão habituados com o ITIL, as definições de Incidente e Problema já estão no sangue, mas como o nosso blog é bastante democrático, vejamos como o ITIL os definem: Incidentes - “Uma interrupção não planejada de um serviço de TI ou a redução na qualidade de um serviço de TI. Falha em um item de configuração que ainda não tenha impactado o serviço é também um incidente, como por exemplo a falha de um disco em um array de discos.” Problemas - “é a causa de um ou mais incidentes.” Colocando em outras palavras, um Incidente tem uma relação muito íntima com o efeito que uma interrupção causa no serviço e um Problema tem uma relação íntima com a causa raiz que fez com que houvesse a interrupção de um determinado serviço de TI. Em postagens posteriores trataremos dos processos que o ITIL preconiza para tratar Incidentes e Problemas. Nesta postagem, o nosso objetivo é identificar os conceitos e as diferenças entre os termos para que, ao estudarmos os processos, o entendimento seja fácil e sólido, ok? Aproveitando a definição de incidente, é comum algumas pessoas que ainda não tiveram um contato mais profundo com a biblioteca ITIL, confundirem este conceito com o conceito de Requisição de Serviço (RdS). Este último é definido como qualquer demanda feita por usuários dos serviços para a área de TI que não afetam o fluxo natural da prestação do serviço e não significam interrupção ou degradação da qualidade do mesmo. Exemplos mais comuns de Requisições de Serviço são: pedidos de troca de senhas, solicitação de configuração de máquinas de novos usuários, etc. Conceitos entendidos, podemos passar para outras definições que serão úteis para o entendimento dos processos da etapa de Operação do Serviço, dentro do ciclo de vida do serviço de TI preconizado pelo ITIL. ITIL V3 - Operação do Serviço - Conceitos e Definições – Solução de Contorno 45
  • 46. Outro conceito muito interessante do ITIL diz respeito à Solução de Contorno. O Workaround, como é dito em inglês, representa uma forma não definitiva de superar alguma dificuldade ou algum incidente que está impactando a prestação de um determinado serviço de TI. Todavia, é importante salientar que o ITIL prevê soluções de contorno também para problemas e não apenas para incidentes, uma vez que, em determinadas ocasiões, o processo de Gerenciamento de Incidentes pode não ter achado uma solução de contorno e aí, quando o processo de Gerenciamento de Problemas o identifica, ele informa para que o serviço seja restaurado. Dessa forma é possível entender que a solução de contorno busca reduzir ou até mesmo eliminar o impacto de um incidente, ou de um problema, enquanto a solução definitiva ainda não foi encontrada. Fazendo uma analogia com a figura acima, poderíamos dizer, de forma bem humorada, que a pessoa achou uma solução de contorno capaz de restaurar o serviço (disponibilidade de água) mesmo sem ter uma solução definitiva para o incidente. É claro que nem sempre a solução de contorno pode ser encarada como uma “gambiarra” e em certas ocasiões ela até se torna a solução definitiva, mas, na maioria das vezes, nós da área de TI sabemos que a “gambiarra” é quem restaura de forma mais rápida o serviço, até que tenhamos a certeza em relação à solução definitiva a ser aplicada. É bom deixar claro que não há nada de errado em se implementar Soluções de Contorno, desde que seja realmente temporária e que uma solução definitiva seja buscada incessantemente, com o risco de fazer com que uma “gambiarra” piore ou até danifique de forma significativa o serviço prestado. 46
  • 47. ITIL V3 – Operação do Serviço – Conceitos e Definições – Erro Conhecido Depois de passarmos por vários conceitos, prometo que esta postagem trará o último conceito que precisamos ter em mente para entendermos os processos da fase de Operação do Serviço, ok? O que trataremos aqui é o conceito de Erro Conhecido. Para os menos avisados, pode até parecer ofensa perguntar o que é um Erro Conhecido. Como assim? Não sabe falar português? Qual a dificuldade em se entender o que quer dizer um erro conhecido? Calma! Muita calma nessa hora... Antes que alguém faça as perguntas (desaforadas) acima é importante saber que para o ITIL, um Erro Conhecido referese a um Problema (ver postagem que fala sobre Incidentes e Problemas) que tem uma causa raiz identificada e documentada, além de uma solução de contorno igualmente identificada e documentada. Se fossemos colocar a definição de Erro Conhecido em uma equação matemática, ela seria mais ou menos assim: Erro Conhecido = Problema + Identificação da Causa Raiz + Solução de Contorno. Nunca é demais falar que, obviamente, os Erros Conhecidos devem estar registrados em uma base de dados e o responsável por armazenar e atualizar essas informações é o processo de Gerenciamento de Problemas que será visto em postagens posteriores. É importante lembrar que uma Solução de Contorno, como visto na postagem anterior, pode não ser ainda a solução definitiva para o problema, porém saber que um determinado erro é conhecido, dá uma segurança maior para o usuário, pois sabe-se que há uma solução de contorno pronta para ser aplicada caso o problema ocorra. Vocês acham que isso é pouco? A Microsoft, por exemplo, costuma lançar alguns softwares com Erros Conhecidos, por motivos de competição ou momento de mercado. Coisas que se fossem esperar para serem definitivamente resolvidas poderiam representar a perda de alguns milhões de dólares. Assim, a Microsoft tem a solução de contorno já pronta para aplicar, caso seja necessário. Passado pelos conceitos, vamos verificar algumas técnicas e ferramentas e entrar nos processos da Operação do Serviço. ITIL V3 – Operação do Serviço – Técnicas e Ferramentas – Priorização de Incidentes e Problemas O ITIL indica uma regra para que os Incidentes sejam priorizados, assim como a tratativa dos problemas. É óbvio que essa indicação é apenas um guia e cada empresa pode, e deve, definir os seus critérios de priorização. Para aqueles que não pensaram nisso, a ideia criada pelo ITIL é a seguinte: a prioridade de um incidente ou de um problema é identificada por meio do produto de dois fatores importantes, o Impacto e a Urgência, ou seja, estes dois fatores determinarão o quão prioritário um incidente e/ou um problema é. 47
  • 48. E como o ITIL define Impacto e Urgência? As metodologias tratam esse assunto de forma parecida, mas cada uma tem um viés, dependendo do foco de cada uma. No ITIL, a Urgência resume-se a identificar a quantidade de tempo que um incidente pode ter até que exista um significativo impacto no negócio. Perceba que a definição de Urgência, refere-se ao Impacto que por sua vez significa saber a que ponto os Níveis de Serviço estão sendo afetados pelo incidente ou pelo problema. Assim, para ilustrarmos melhor, poderíamos dizer que na figura acima, o Impacto representa o tamanho da bomba e a Urgência representa o tamanho do pavio. Resumindo o assunto, podemos dizer que o ITIL faz a priorização dos incidentes e dos problemas por meio da seguinte equação matemática: P = I * U, onde P é a Prioridade, I é o Impacto e U é a Urgência. A partir da definição da prioridade, cada resultado de P deve ter atrelado a ele, um tempo máximo estabelecido para resolução e uma descrição (Crítico, Alto, Médio, Baixo, etc). Nesse ponto temos que ter cuidado na classificação para que não aconteça o que já vi acontecer em várias empresas que acabam descrevendo a prioridade como Altíssima, ou Super Alta, ou Mega Super Alta e assim por diante. Essa falta de cuidado em determinar corretamente a prioridade pode levar ao descrédito em relação ao tratamento dos incidentes e problemas. ITIL V3 – Operação do Serviço – Técnicas e Ferramentas – BDEC Além da técnica de priorização de incidentes e problemas, o ITIL V3 oferece uma ferramenta para ser utilizada pela Operação do Serviço, o BDEC. Já deu para perceber que o ITIL V3 abusou das siglas para representar seus Bancos de Dados e sistemas que auxiliam os processos, certo? Pois bem, BDEC significa Base de Dados de Erro Conhecido. Não é algo novo na biblioteca ITIL, nem no imaginário de todos nós que os Erros Conhecidos devam estar em uma base de dados capaz de suportar os processos, caso contrário não seriam “conhecidos”, concordam? O BDEC é mais um membro do SGCS (Sistema de Gerenciamento do Conhecimento do 48
  • 49. Serviço) e deve ser montado pelo Gerenciamento de Problemas, mas será consumido também, e por motivos óbvios, pelo Gerenciamento de Incidentes. Dito isso, acredito que a partir da próxima postagem entraremos nos Processos da Operação do Serviço. ITIL V3 – Operação do Serviço – Processos – Gerenciamento de Incidentes Como dizia o velho provérbio, “panela velha é que faz comida boa”. No ITIL V3, um processo que não sofreu alteração na passagem da versão dois para a versão três foi o processo de Gerenciamento de Incidentes. Este processo é considerado o mais expansivo dentro da organização e tem como objetivo principal, para aqueles que ainda não tiveram contato com nenhuma versão do ITIL, o restabelecimento do funcionamento normal do serviço, o mais rápido possível. Aqui cabem duas análises: a primeira diz respeito ao termo “funcionamento normal”. O que essa expressão quer dizer? Alguém se arrisca? … Bem, se considerarmos o que já vimos até agora, fica fácil dizer que para o ITIL, o funcionamento normal de um serviço é alcançado quando estamos atendendo os Níveis Acordados (ANS), mas também não podemos esquecer que, do ponto de vista interno, os ANOs também devem ser respeitados. A segunda análise diz respeito a expressão “o mais rápido possível”. A intenção aqui é minimizar o impacto negativo sobre o negócio, assegurando que os melhores níveis possíveis sejam mantidos. Falamos em melhores níveis possíveis porque em muitos casos aplica-se soluções de contorno que não resolvem a situação definitivamente. O Gerenciamento de Incidentes deve lidar com todos os tipos de incidentes, que podem vir a partir dos usuários, geralmente por meio da Central de Serviços, das equipes técnicas ou automaticamente, por meio de ferramentas de monitoração. Aliás, é inadmissível, em algumas organizações que um incidente seja de seu conhecimento apenas quando o usuário o reporta. Por ser um processo muito utilizado pelas organizações, passaremos abaixo pelas atividades que o compõe com uma breve descrição: Identificação do Incidente. Conforme dito acima, a identificação deve ser feita preferencialmente por ferramentas de monitoração dos serviços e não pelo usuário para evitar o “mico”. Apesar disso, o usuário pode reportar um problema que deve ser verificado se de fato é um problema ou é apenas falta de informação, por exemplo, o que não caracteriza um incidente. Registro do Incidente. Como tudo no ITIL, mas especialmente aqui, o registro do incidente deve ser bem detalhado, para possibilitar uma resposta mais tempestiva ao problema. Categorização do Incidente. Importante para o uso de outros processos, como por exemplo o Gerenciamento de Problemas. Priorização de Incidentes. Já falamos sobre essa técnica em postagens anteriores. Essa priorização é importantíssima, levando em consideração que existem recursos finitos nas organizações. Diagnóstico Inicial. Se o Incidente foi aberto por meio da Central de Serviços, há a necessidade da existência de scripts para que os atendentes possam executar ações básicas que tentam resolver o incidente, baseado nos erros conhecidos e em uma base de conhecimento. Caso não consiga resolver, haverá a escalação do incidente. Escalação do Incidente. Existem dois tipos de escalação, a saber: escalação funcional (horizontal), que trata da passagem do incidente que não foi resolvido pelo atendente em 1º nível para equipes especializadas, baseada na categorização do mesmo. Escalação Hierárquica (vertical), para casos de incidentes graves que fazem com que as gerências sejam notificadas para agilizar o seu tratamento ou conversar com o Cliente de 49
  • 50. forma a passar alguma satisfação. A Escalação ocorre também nas duas atividades seguintes, descritas abaixo. Investigação e Diagnóstico. Investigação de um determinado incidente na busca de uma solução de contorno, que pode, em alguns casos, até ser a solução definitiva. Resolução e Recuperação. Identificando uma solução em potencial, esta deve ser aplicada e testada. O grupo de solução, quando acha uma solução, deve passar as informações à Central de Serviços para que essa possa comunicar ao usuário. Fechamento do Incidente. Registrar de forma detalhada o que foi feito e a resolução encontrada para que possa servir de base para futuros incidentes com a mesma natureza. Passado pelo processo de Gerenciamento de Incidentes, veremos na próxima postagem outro processo bem consolidado desde a versão 2.0 do ITIL, o Gerenciamento de Problemas. Vocês não perdem por esperar!!!! ITIL V3 – Operação do Serviço – Processos – Gerenciamento de Problemas Como havíamos falado na postagem anterior, falaremos neste momento de outro processo bastante maduro dentro da biblioteca ITIL, mas que nem todas as empresas o implementam da forma como deveria. Estamos falando do famoso processo de Gerenciamento de Problemas. Este processo tem o objetivo principal de identificar a causa raiz de incidentes e definir a solução definitiva para os mesmos a fim de que os incidentes recorrentes sejam eliminados e o impacto daqueles que não podem ser evitados seja reduzido. Identificar a causa raiz dos incidentes significa dizer que, para o Gerenciamento de Problemas, o mais importante é descobrir o porquê das coisas estarem acontecendo fora do que foi acordado nos SLAs. É legal notar que este processo não deve ser apenas reativo, uma vez que, a partir de uma análise dos incidentes registrados, pode-se iniciar, proativamente, as atividades para resolver definitivamente aqueles que acontecem de forma recorrente. Dentro desse processo existem uma série de atividades que sugiro fortemente que sejam aprofundadas para quem tem o interesse em se certificar em ITIL, porém para o nosso humilde blog, nos restringiremos a identificar atividades que possam trazer informações mais relevantes ao entendimento do processo. Após a detecção do Problema, do seu registro, da categorização e da priorização, temos a atividade de investigação e diagnóstico. Esta atividade diz respeito à análise de causa raiz, que pode ser tanto reativo quanto proativo, como dito anteriormente. O fato principal aqui é que o Gerenciamento de Problemas pode encontrar não uma solução definitiva, no primeiro momento, mas soluções de contorno, que seriam uma forma temporária de superar as dificuldades que porventura um serviço possa estar passando. Neste caso, o registro do problema continua aberto e as investigações também devem continuar, uma vez que, conforme dissemos, o Gerenciamento de Problemas tem como objetivo principal a identificação da causa raiz e a solução definitiva de um grupo de incidentes, ou de um incidente que tenha se tornado um problema grave. Outra questão interessante sobre a descoberta da solução de um problema está na definição de quando se aplicar esta correção. As vezes não é possível aplicar a solução definitiva no momento em que a mesma é identificada. Assim, o Gerenciamento de Problemas, que trata de todo o ciclo de vida do Problema, deve se preocupar, também, com a abertura de requisições de mudanças para que os processos que tratam de mudanças possam agir de forma ordenada e controlada. 50
  • 51. ITIL V3 – Operação do Serviço – Processos – Gerenciamento de Eventos Caros leitores do nosso humilde blog, nesta postagem estaremos falando de um novo processo do ITIL V3, o Gerenciamento de Eventos. Este processo vem preencher um gap deixado pelo ITIL V2 e tem como principal objetivo a detecção de todos os eventos que acontecem no serviço de TI, sua contextualização e a definição das medidas adequadas de controle que possam ser tomadas. Quando falamos de todos os eventos, pode parecer algo utópico, mas para entendemos a afirmativa anterior, temos que saber o que o ITIL chama de “evento”. Assim sendo, Evento, na visão do ITIL, representa qualquer ocorrência detectável ou percebida que tenha relevância para o gerenciamento do serviço de TI. Atenção para o termo “relevância”. Não é qualquer coisa que aconteça, mas sim todas as coisas relevantes para o serviço. Estas sim devem ser capturadas pelo Gerenciamento de Eventos. É importante perceber, como consequência do objetivo desse processo, que o Gerenciamento de Eventos se torna a base para a monitoração operacional do serviço e seu controle. O ITIL V3 coloca alguns exemplos de eventos, listados abaixo, mas é bom deixar claro que os eventos não se restringem a apenas aos colocados aqui. Eventos que significam operações regulares. Exemplo: identificação que um usuário logou em um sistema, um e-mail chegou ao seu destino final ou ainda a notificação que um job agendado foi executado. Eventos que significam uma exceção. Exemplo: Um servidor está acima da faixa aceitável de utilização, uma situação não usual ocorreu em um processo de negócio, etc. Eventos que significam uma operação não usual, mas sem ser excepcional. Exemplo: A memória de um servidor está a 5% do máximo permitido, o tempo de finalização de uma transação está 10% maior do que o acordado, etc. Para finalizar, podemos dizer que o Gerenciamento de Eventos é uma das entradas para uma série de outros processos da Operação do Serviço, como por exemplo o Gerenciamento de Incidentes e o Gerenciamento de Problemas. Na próxima postagem, continuaremos na nossa viagem pelos processos da fase de Operação do Serviço do ciclo de vida proposto pelo ITIL. ITIL V3 – Operação do Serviço – Processos – Cumprimento de Requisitos Nos processos de Operação do Serviço já passamos pelos incidentes, problemas e eventos, mas e as dúvidas e solicitações do dia a dia que não indicam falha ou perda de performance no serviço de TI? O ITIL, preocupado em abranger todos os aspectos do serviço de TI e levando em consideração o próprio conceito que ele criou para serviço (“meio para que a empresa tenha valor”), preparou um processo específico para tratar desse assunto, o Cumprimento de Requisição. Concordo que o nome do processo ficou meio fora do padrão utilizado pela própria biblioteca ITIL, mas o que ele se propõe a fazer, na verdade, é disponibilizar um canal para que usuários e clientes possam solicitar e utilizar 51
  • 52. serviços padronizados que tenham um processo pré-definido de qualificação e aprovação. Para quem já tem um pouco de experiência, vai perceber que este processo utiliza-se das famosas RdS (Requisições de Serviço) para operacionalizar as entradas que são feitas pelos usuários, quase sempre pela Central de Serviço, outro elemento crítico para esse processo. Por falar na Central de Serviço, normalmente essa função terá a responsabilidade de receber, monitorar, executar, enviar e despachar as requisições que forem feitas pelos usuários. Apesar de criar um processo específico para tratamento das RdS, o ITIL deixa muito claro que a automatização de certas rotinas é muito bem-vinda, especialmente se a prestadora do serviço de TI tiver total conhecimento sobre as mesmas. Além disso, o ITIL também deixa claro que práticas de autoatendimento também são muito valiosas, pois reduzem a fila de atendimento, o que permite maior agilidade para as RdS que de fato necessitam de uma interação mais aprofundada. Por fim, não podemos nos esquecer que este processo também é o responsável por receber as reclamações, comentários e solicitações de informações gerais do serviço. Na próxima postagem, trataremos do último processo da Operação do Serviço. Vocês saberiam me dizer qual é?... ITIL V3 – Operação do Serviço – Processos – Gerenciamento deAcesso Finalizando os processos da fase de Operação do Serviço do ciclo de vida de serviços de TI preconizado pelo ITIL V3, falaremos, nesta postagem, do Gerenciamento de Acesso. Este é um novo processo do ITIL V3 para velhos assuntos que existem desde os primórdios dos sistemas informatizados. O Gerenciamento de Acesso trata, como o próprio nome sugere, dos acessos, perfis e direitos de usuários ou de grupo de usuários a um determinado serviço ou grupo de serviço de TI. Não há muito o que ser dito sobre esse processo, mas uma característica interessante é que o Gerenciamento de Acesso utiliza-se de outros processos como entrada e saída, uma vez que o fornecimento dos direitos e acessos dos clientes é feito por meio de Requisições de Serviço e as definições das políticas que são aplicadas por este processo proveem dos Gerenciamentos de Segurança e Disponibilidade da fase de Desenho do Serviço. Vocês podem então estar se perguntando, para que ele existe afinal? Bem, na minha opinião particular, o ITIL tenta abranger todos os aspectos do serviço de TI e há, em relação ao Gerenciamento de Acesso, a nítida intenção de dar ao processo uma importância maior, destacando-a de outras requisições de serviços normais (dúvidas, elogios, pedido de algum serviço, etc). Acredito que problemas de acessos indevidos têm comedido muitas empresas que prestam serviços de TI e estes acessos indevidos certamente têm causado muitos danos a várias organizações. Caro leitor, estamos nos aproximando do final da nossa viagem pelo ITIL V3. Ainda temos algumas coisas interessantes e novas dessa biblioteca, portanto, não deixem de acompanhar as próximas postagens... ITIL V3 – Operação do Serviço – Funções – Central de Serviço Caros leitores, finalizados os processos da Operação do Serviço, falaremos nesta postagem, e na 52
  • 53. próxima também, sobre as Funções descritas pelo ITIL. Antes de mais nada, temos que deixar claro que o ITIL considera Funções como “estruturas funcionais” que deveriam existir no provedor de serviço de TI. Na versão 2 da biblioteca ITIL, existia apenas a Função de Central de Serviço, que veremos nesta postagem com mais detalhes. Já na versão 3, o ITIL descreve três novas Funções, que iremos descrever na próxima postagem, mas que podemos elencá-las agora para matar a curiosidade de alguns. São elas: Gerenciamento Técnico, Gerenciamento de Aplicativos e Gerenciamento de Operações de TI. A Central de Serviços é descrita pelo ITIL como uma unidade funcional que tem o intuito de ser o ponto único de contato para os usuários de TI. Dessa afirmação podemos imaginar que esta função exerce um papel fundamental na organização de um Departamento de TI, uma vez que contará com um número dedicado de pessoas que terão como atribuições principais: receber e internalizar uma série de eventos de diferentes naturezas, como visto nos processos descritos nas postagens anteriores (incidente, evento, acesso, dúvida, etc.), além de cuidar para que o serviço volte a sua normalidade o mais rápido possível. Existem certas dúvidas sobre a Central de Serviço que devemos esclarecer para que se tenha o maior proveito de suas atribuições. Central de Serviço não é help desk! Um help desk tem como característica natural o fato de ser reativo, ou seja, agir quando provocado ou acionado. Não é esse o caso da Central de Serviço. Os sistemas/monitorações podem e devem interagir com a Central para que esta internalize, entre outros, os incidentes e as requisições de serviço de forma proativa, antes que o serviço de TI venha a ser degradado e esta degradação seja percebida pelo cliente. A Central de Serviço não recebe apenas ligações telefônicas! A Central de Serviço deve estar preparada para receber acionamentos por vários canais, a fim de permitir que de fato seja o ponto único de contato. Para finalizarmos o assunto, o ITIL classifica uma Central de Serviço em três tipos distintos, a saber: Central de Serviço Local. É a Central que se encontra fisicamente próxima dos usuários que a acionam. Tem como objetivo principal atender usuários VIPS, dirimir dificuldades referentes a língua ou a diferenças políticas e culturais e atender grupo de usuários especializados. A figura abaixo mostra um exemplo de uma Central de Serviço Local. 53
  • 54. Central de Serviço Centralizada. É a Central onde toda equipe da Central de Serviço encontra-se em uma estrutura centralizada. A figura abaixo mostra um exemplo desse tipo de Central. Normalmente, este tipo de Central é mais eficiente e com melhor custobenefício e, relação a Central de Serviço Local. TIL V3 – Operação do Serviço – Funções – Outras Funções Finalizando as Funções descritas pelo ITIL V3, já que falamos da Central de Serviço na postagem anterior, vamos ver, nesta postagem, três novas Funções que foram incorporadas nesta versão da biblioteca ITIL. São elas: Gerenciamento Técnico, Gerenciamento de Aplicativos e Gerenciamento de Operações de TI. Vale lembrar que o ITIL considera Função como sendo uma estrutura organizacional que as empresas prestadoras de serviços de TI deveriam ter. Gerenciamento Técnico – Esta estrutura deve possuir profissionais capazes de ajudar no planejamento, na implementação e na manutenção da infraestrutura de um determinado serviço de TI. Na fase de Desenho do Serviço, esta equipe é acionada para especificar os requisitos técnicos de infraestrutura. Já na fase de Transição do Serviço, essa equipe auxilia na avaliação e aprovação de mudanças na infraestrutura do serviço, além da própria implementação de mudanças aprovadas. Por fim, na fase de Operação do Serviço, esta equipe auxilia na resolução dos incidentes (2º ou 3º nível de recorrência, dependendo do serviço e da empresa) e dos problemas, entre outros. Gerenciamento de Aplicativos – Esta equipe pode ser traduzida como a equipe de desenvolvimento de software da prestadora de serviço. Deve ser criada, especialmente, para ajudar os processos de negócio da empresa no que tange a identificação de requisitos funcionais e gerenciamento do software, na fase de Desenho do Serviço; o auxílio na implantação do software desenvolvido na fase de Transição e o suporte e indicação de melhoria dos aplicativos nas fases de Operação do Serviço e de Melhoria de Serviço Continuada. Gerenciamento de Operações de TI – Esta estrutura organizacional deve ter como objetivos principais: a manutenção do patamar acordado em termos de estabilidade dos processos e das atividades do dia a dia da empresa, exame rotineiro para identificar melhorias nos processos operacionais - especialmente os que reduzem custos - e capacidade operacional de diagnosticar e intervir de forma tempestiva para resolver falhas em seus ambientes de operação. 54
  • 55. Caro leitor, com esta postagem finalizamos a fase de Operação do Serviço, a partir da próxima postagem entraremos na fase de Melhoria de Serviço Continuada. Central de Serviço Virtual. É uma Central que por meio da tecnologia tem o seu sistema centralizado, mas várias equipes distribuídas em diferentes regiões geográficas. Uma especialização deste tipo de estrutura é conhecida como Central de Serviço Follow the Sun. Nesta especialização, duas ou mais centrais dispersas sobre o globo acessam uma base de dados compartilhada e um mesmo sistema de forma a ter sempre pessoas trabalhando em horários comerciais para diminuir custos trabalhistas. É claro que o assunto Central de Serviço daria para umas dez postagens, mas para não ficarmos enfadonhos acho que as informações aqui postadas dão uma boa noção sobre essa importante Função do ITIL. Seguiremos falando das outras Funções na próxima postagem... 55
  • 56. ITIL V3 – Melhoria de Serviço Continuada – Metas e Objetivos Caros leitores, iniciamos nesta postagem a última fase do ciclo de vida do serviço conforme preconiza o ITIL V3. A fase de Melhoria de Serviço Continuada, na verdade, retroalimenta todo o ciclo de vida, uma vez que busca alinhar e realinhar incessantemente os serviços de TI às necessidades do negócio, fazendo com que a prestação do serviço de TI sempre melhore tendo em mente dois aspectos importantes: agregação de valor e maior efetividade nos custos da entrega do serviço. Quando falamos em agregar valor queremos dizer que as necessidades do negócio são as principais direcionadoras da melhoria continuada, apesar de não serem as únicas. Já em relação à efetividade ou à eficiência nos custos, queremos dizer que o prestador de serviço deve sempre tentar fazer mais com menos, ou seja, deve estar sempre fazendo um refactoring do serviço (analogia com o Refactory do XP), tornando-o cada vez mais simples, não na qualidade, mas sim na forma de administrá-lo e produzi-lo (processos, operações, etc.), ressalvado, obviamente, aqueles que possuem restrições contratuais ou que já estejam em sua forma mais “simples”. Dada a explicação acima, não é difícil de imaginar os principais objetivos desta fase do ciclo de vida do serviço. São eles: Revisar, analisar e sugerir melhorias em todas as fases do ciclo de vida do projeto. Validar os resultados alcançados em relação aos níveis de serviços acordados e verificar possibilidades de melhorias. Melhorar a eficiência em relação aos custos. 56
  • 57. Garantir que os métodos de gerenciamento da qualidade são aplicáveis. Para cumprir estes objetivos, o ITIL relacionou apenas três processos que serão vistos nas próximas postagens, mas antes teremos, como de costume, que pontuar alguns conceitos que irão facilitar o entendimento dos processos. Vamos juntos? ITIL V3 – Melhoria de Serviço Continuada – Definição e Conceitos – Diversos Alguns conceitos são fundamentais para que possamos entender o papel da Melhoria de Serviço Continuada. A primeira coisa que temos que ter em mente é a máxima do planejamento estratégico que diz o seguinte: “Você não pode gerenciar o que não pode controlar. Da mesma forma, não podemos controlar o que não podemos medir e não podemos medir o que não conseguimos definir”. Frase de efeito essa, não? Na verdade o que ela quer dizer, nos meandros, é que a TI deve estar pronta para medir um determinado serviço de ponta a ponta, ou seja, lá na fase de Desenho do serviço tenho que ser capaz de identificar os indicadores que vão verificar o serviço como um todo e não apenas itens individuais, como um servidor ou um ativo de rede ou ainda uma aplicação isolada. Mas medir por medir não quer dizer muita coisa, é necessário se ter uma Linha de Base (segundo conceito importante!!), ou seja, uma referência inicial onde é possível ser feita uma comparação visando o futuro do serviço medido. Outro conceito importante é o de Métrica. Para medir algo preciso definir o indicador que me mostrará o desempenho de um determinado serviço. Esse indicador é formado por métricas, ou seja, por valores que são factíveis de serem reconhecidos, capturados e armazenados. O ITIL define três tipos diferentes de Métricas a saber: Métricas de Tecnologia – Métricas que estão relacionadas aos componentes e aplicativos. Normalmente medem desempenho e disponibilidade. Métricas de Processo – Métricas que ajudam a identificar a saúde geral de um processo. Métricas de Serviço – Métricas que são resultantes das medições do serviço ponta a ponta. ITIL V3 – Melhoria de Serviço Continuada – Técnicas e Ferramentas – Ciclo de Deming Antes de entrarmos nos processos da fase de Melhoria de Serviço Continuada do ITIL V3, vamos explorar duas técnicas e ferramentas que o ITIL utiliza para embasar esses processos. Uma delas veremos nesta postagem, a outra, para aumentar o suspense, deixaremos para a próxima postagem. A técnica que vamos explorar nesta postagem é o famoso Ciclo de Deming. Vocês não conhecem? Tenho certeza que já ouviram falar, mas talvez com um outro nome... … que tal ciclo PDCA? Agora SIM!!! Pois é pessoal, o Ciclo de Deming ou o Ciclo PDCA (Plan, Do, Check, Act) é um ciclo composto por quatro fases que deve ser utilizado para a melhoria contínua. Este ciclo tem como base a gestão de processos, mas pode ser utilizada praticamente em qualquer ramo de atividade. O primeiro trabalho neste sentido foi atribuído a W. Edward Deming, daí o nome: Ciclo de Deming. 57
  • 58. Conforme figura acima, é possível verificar as quatro etapas do ciclo. Cada uma delas tem uma função específica na busca da melhoria contínua (abaixo listamos cada uma em particular). Além disso, é importante verificar que um determinado processo vai adquirindo maturidade cada vez que as quatro fases são executadas. Dessa forma, a cada passagem pelo ciclo, o processo consolida um nível de maturidade alcançado, representado pelo triângulo na figura. Parece algo simples e de fácil execução, mas aplicá-lo não é tão simples assim. Para que isso funcionasse dentro do ITIL, o pessoal da OGC criou o modelo MSC que veremos na próxima postagem. Por enquanto vamos focar nas fases do Ciclo PDCA. Plan (Planejar) – Desenhar ou revisar os processos que suportam os serviços de TI. Do (Fazer) – Executar o que foi planejado e gerenciar o processo. Check (Verificar) – Medir e comparar os processos e os serviços de TI em relação aos objetivos. TI. Act (Agir) – Implementar as mudanças para melhorar os processos e os serviços de Vamos complementar as técnicas e ferramentas da fase de Melhoria de Serviço Continuada na próxima postagem... ITIL V3 – Melhoria de Serviço Continuada – Técnicas e Ferramentas – Modelo MSC Fechando as técnicas e ferramentas da fase de Melhoria de Serviço Continuada do ITIL V3, vamos explorar, conforme prometido na postagem anterior, o Modelo MSC. Este modelo foi criado pelo ITIL V3 baseado em um outro modelo famoso de mercado, utilizado pela metodologia Six Sigma: o DMAIC Definir, Medir, Analisar, Melhorar(improve) e Controlar. 58
  • 59. Conforme figura acima, o Modelo MSC é composto de 6 etapas que levam a organização, ciclicamente, a promover a melhoria contínua de seus processos. A seguir destacaremos cada uma das etapas. What is the Vision? (Qual é a Visão?) – Nesta etapa é identificada a visão no entendimento do negócio para que seja possível alinhar as estratégias de TI. Where are we now? (Onde estamos agora?) - É a etapa de define um baseline para que seja possível fazer análises e comparações em relação ao posicionamento atual da organização em termos de negócio, pessoas, tecnologia, etc. Where do we want to be? (Onde queremos estar?) - É a etapa que define alvos mensuráveis para que sejam alcançados. How do we get there? (Como chegamos lá?) - Esta etapa define as melhorias necessárias para alcançar o alvo que se quer em termos de processos e serviços. Did we get there? (Chegamos lá?) - Etapa responsável por avaliar as métricas e medições realizadas para garantir que os marcos definidos foram alcançados. How do we keep the momentum going? (Como mantemos o ritmo?) - É a etapa que garante que a melhoria da qualidade continue, fechando o ciclo e reiniciando da primeira etapa. Bom pessoal, vimos as duas técnicas que são utilizadas pelos processos da fase de Melhoria de Serviço Continuada. A partir da próxima postagem, entraremos nos processos desta fase, o que significa dizer que estamos chegando ao final desta longa caminhada pelo ITIL V3, mas não fiquem tristes não, pois teremos muita coisa boa pela frente ainda, já que uma Gestão de TI inteligente não se faz aplicando apenas uma ou outra metodologia ou melhores práticas, e sim combinando uma grande variedade delas tendo o foco sempre no negócio e no cliente... ITIL V3 – Melhoria de Serviço Continuada – Processos – 7 Passos da Melhoria 59
  • 60. Iniciamos nesta postagem os processos da fase de Melhoria de Serviço Continuada. Antes de mais nada, precisamos deixar claro que há algumas divergências em relação à quantidade de processos desta fase. Alguns autores consideram que há apenas um processo, exatamente o que vamos falar nesta postagem, mas para outros e de acordo com a documentação oficial do ITIL V3, existem outros dois processos a saber: Medição do Serviço e Relatório do Serviço. A celeuma está no fato de alguns autores considerarem esses dois outros processos como técnicas ou no máximo subprocessos e não como processos do ITIL, mas para sermos o mais fiel possível à documentação oficial, vamos de três processos mesmo, combinado? O processo dos 7 Passos da Melhoria começa com um passo que não está contabilizado entre os 7. Quer dizer então que seriam 8 passos? Isso mesmo, mas este passo adicional é apenas a “fonte inspiradora” dos outros passos e o ITIL resolveu não colocá-lo na contagem (Quem somos nós para discutir com os caras...) Ficou complicado? vou explicar. Lembrando o modelo MSC (ver postagem anterior), as perguntas que são feitas nesta técnica buscam identificar a visão e a estratégia da organização e, como consequência, as metas táticas e operacionais. Essas informações são importantes para orientar as etapas do processo dos 7 Passos da Melhoria que são vistos na figura abaixo e que iremos descrever um a um. Passo 1 – Definir o que você deveria medir – Este passo, baseado no MSC, identifica o que deveria ser medido no sentido do serviço estar em uma situação ideal para o negócio e para a TI. Passo 2 – Definir o que você pode medir – Se o passo anterior visa a situação ideal para o negócio e para TI, este passo delimita, dentro da realidade da empresa, o que de fato pode ser medido em relação ao que foi definido no passo 1. Passo 3 – Coletar os dados – Este passo define os meios que a organização utilizará para conseguir coletar as informações que serão utilizados para medir e comparar os resultados. Passo 4 – Processar os dados – Este passo significa colocar os dados em um formato que permita uma perspectiva fim a fim do serviço e uma visão geral da performance 60
  • 61. alcançada pelo mesmo. São relatórios executivos, condensados a partir dos dados coletados no passo anterior. Passo 5 – Analisar os dados – Este passo visa transformar a informação coletada e processada em conhecimento no que diz respeito à organização e seus serviços. Permitem identificar as tendências, as ações corretivas, as relações internas e externas entre outros. Passo 6 – Apresentar e usar a informação, avaliação, sumário e planos de ação – Este passo significa pegar o conhecimento adquirido no passo anterior e transformá-lo em sabedoria, por meio da utilização de relatórios, planos de ação, revisões, avaliações e definição de oportunidades a serem exploradas, ou seja, é definir o que deve ser melhorado em relação ao serviço. Passo 7 – Implementar as ações corretivas – As ações corretivas identificadas são apresentadas em formas de soluções para serem implementadas pela organização. Após este passo, um novo ciclo reinicia-se. Nas próximas postagens continuaremos tratando dos processos da última fase do ITIL V3... ITIL V3 – Melhoria de Serviço Continuada – Processos - Relatório de Serviço Como já dissemos na postagem anterior, existe uma pequena dúvida em relação à quantidade de processos que fazem parte da fase de Melhoria de Serviço Continuada. Levando-se em consideração que na documentação oficial do ITIL existe um tópico que trata do Relatório de Serviço como se este fosse um processo, decidimos, por fidelidade, seguir o que a documentação oficial, apesar de respeitar as opiniões contrárias. É fato que um determinado serviço de TI é capaz de produzir uma quantidade enorme de dados que são coletados e armazenados, porém apenas um pequeno grupo dessas informações tem uma importância significativa para o negócio. Os outros dados também têm sua importância, mas para a gestão do dia a dia do serviço. O ITIL preconiza que para se ter uma abordagem correta na elaboração dos relatórios de serviço é necessário que se crie regras e políticas que definam, entre outras coisas: O público-alvo dos relatórios e as visões de negócio que estejam relacionadas ao serviço de TI. O que medir e o que estará presente no relatório. Os termos utilizados e as fronteiras dos relatórios. As regras de cálculos que o relatório possa vir a apresentar. O calendário de elaboração e envio dos relatórios. Os períodos de revisão do relatório. A forma de acesso e o meio a ser disponibilizado. Na próxima postagem, trataremos da Medição do Serviço, último processo do ITIL a ser abordado pelo nosso blog. Vocês não perdem por esperar!!! ITIL V3 – Melhoria de Serviço Continuada – Processos – Medição de Serviço 61
  • 62. Finalizando os processos da fase de Melhoria de Serviço Continuada, do ciclo de vida de serviço preconizado pela biblioteca ITIL V3, vamos falar sobre a “Medição de Serviço”. Já falamos em várias postagens da importância da medição do serviço para que possamos aferir seu desempenho, gerenciá-lo com eficiência e agregar mais valor ao mesmo, certo? Pois bem, o ITIL coloca que para os serviços de TI não bastam, simplesmente, medirmos o desempenho de itens isolados, sejam eles de infraestrutura, como um servidor de banco de dados por exemplo, ou sejam de aplicativos em operação. Na verdade, a medição de serviço deve ser capaz de medir e reportar um determinado serviço de TI de ponta a ponta, ou seja, todo o serviço e seu ciclo de vida. Mas como fazer isso? Para resolver essa equação, que não é simples, o ITIL sugere que se crie uma estrutura de medição de serviços, onde a combinação de métricas consideradas importantes para o serviço proveem uma perspectiva acurada e balanceada sobre o serviço. Assim sendo, o primeiro passo para a criação dessa estrutura de medição é entender e assimilar os processos de negócio e, a partir deles, identificar aqueles que mais contribuem para entregar valor ao negócio. A partir daí, a combinação de que falamos no parágrafo anterior refere-se a identificar, dentre as opções a seguir, quais necessidades devem ser medidas para identificar a “saúde” de um determinado serviço: serviços, componentes e processo de gerenciamento do serviço. Caros leitores do nosso humilde blog, com essa postagem finalizamos a extensa, mas interessante viagem pela biblioteca ITIL. Espero que tenha contribuído para disseminar o conhecimento sobre esse importante capítulo na nossa busca por uma Gestão de TI Inteligente. Vamos entrar em um novo assunto a partir da próxima postagem. Espero que seja tão interessante como foi este. 62