ITIL V3 – Transição do Serviço – Conceitos e Definições – IC – Item de Configuração

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.


• 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).

Sigamos em frente com outros conceitos importantes para a fase da Transição do Serviço.

Sigam-me os bons!!!

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. É 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.


• Melhorar a satisfação do cliente, assim como o da equipe do gerenciamento de serviços.


• 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...

Não percam as cenas dos próximos capítulos e...

Sigam-me os bons!!!

ITIL V3 – Desenho do Serviço – Tecnologia e Arquitetura

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 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.

Vocês não perdem por esperar!!!

ITIL 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 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.

Sigam-me os bons!!!

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 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.

Na próxima postagem estaremos finalizando a parte de processos do Desenho do Serviço, não percam!!!

ITIL 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.

Não desanimem, pois temos muitas coisas interessantes pela frente!!!!

ITIL V3 – Desenho do Serviço – Processos – Gerenciamento da Segurança da Informação

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.

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.

Continuaremos a falar de outros processos da etapa do Desenho do Serviço nas próximas postagens!
Vamos em frente que atrás vem gente!!!