ITIL V3 – Coffee Break 2 – Feliz 2012!

Caros leitores, gostaria de agradecer a todos que acompanharam o nosso humilde blog durante esse ano de 2011!!! A todos vocês, um ano de 2012 cheio de paz, saúde e felicidade!!

Espero que no próximo ano possamos continuar disseminando o conhecimento em torno da gestão de TI e que vocês possam aproveitar ao máximo!!!

Ainda em tempo, gostaria de agradecer a Deus pelo ano que termina, com todas as suas alegrias e tristezas. Obrigado por me guiar todos os dias!!!

Para finalizar,

e...

Sigam-me os bons!!!!

ITIL V3 - Operação do Serviço - Conceitos e Definições – Solução de Contorno

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.

Continuemos, na próxima postagem, com os nossos conceitos e definições...

Vamos juntos?

ITIL V3 – Operação do Serviço – Conceitos e Definições – Incidentes e Problemas

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.

Vamos em frente que atrás vem gente!!!

ITIL V3 - Operação do Serviço - Conceitos e Definições - Evento e Alerta

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?



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.

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

Sigam-me os bons!!!

100 Postagens!!!

Caros amigos, atingimos nesta postagem uma marca importante: A nossa centésima postagem!!! Quando iniciamos o blog não tínhamos ideia que a coisa iria tão longe!!! Fazendo um pequeno flashback, coloco abaixo um quadro com a quantidade de postagens por assunto, até o momento.

Assunto	Qtd Postagens
Diversos	11
Governança de TI	15
PMBOK	30
ITIL	44
Total	100

Vamos juntos na busca de mais 100 postagens, pois ainda temos muitos assuntos relevantes para que as empresas possam ter uma GESTÃO INTELIGENTE DE TI!!!

Valeu!!! e...

Sigam-me os bons!!!

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

Sigam-me os bons!!!

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.

Na próxima postagem, finalizaremos os processos da etapa de Transição do Serviço com o processo de Gerenciamento do Conhecimento. Vocês não perdem por esperar!!

ITIL V3 – Transição do Serviço – Processos - Gerenciamento de Configuração e Ativos 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 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.

Falaremos na próxima postagem do processo de Gerenciamento de Liberação e Implantação que também faz parte da fase de Transição do Serviço. Não percam e...

Sigam-me os bons!!!

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

Seguiremos nas próximas postagens com os outros processos da fase de Transição do Serviço. Não percam!!!!

ITIL V3 – Coffee Break 1 – Amenidades?

Queridos leitores, estive viajando com minha família na semana do dia da criança e acabei me atolando em trabalho nas últimas semanas. Para aproveitar esse “relaxamento” vamos postar mais um coffee break, já que faz tempo que não o fazemos.

• Copa 2014 – Depois da divulgação da tabela da Copa de 2014, realmente percebi como neste assunto as coisas estão mais voltadas para a política do que para as questões técnicas. Fica apenas a esperança, já meio desestimulada, de ver algum legado para as cidades sedes. Será?


• Grécia e o Capitalismo Selvagem – Meu irmão, estudioso dedicado sobre modelos de econômicos e relação trabalho-capital, vem me dizendo a algum tempo o que os jornais têm comprovado nos últimos meses. O capitalismo como conhecemos está acabando!!! Se isso é algo bom ou ruim vai da convicção de cada um. O que não podemos fazer é fechar os olhos para o crescente movimento das populações na Europa e nos Estados Unidos contra o modelo do capitalismo baseado no mercado financeiro. A Grécia está falida e começa a demonstrar ao mundo que o modelo capitalista tende a autofagia.


• Estamos destruindo o planeta? - As vezes me pergunto se o homem é capaz de destruir o paneta com o desmatamento, extinção de espécies, poluição, etc,etc,etc. Acho que o homem é capaz de se autodestruir, isso sim. O planeta já passou por impactos de cometas, separação de continentes, eras glaciais e sobreviveu. Talvez nós não sobreviveremos às respostas da natureza em relação às nossas ações, mas o planeta aguentaria numa boa passar por mais mil anos de uma nova era glacial, com o derretimento das calotas polares. Já pensou nisso? Proponho trocar o slogan: “Salvem o Planeta, não destrua a natureza”, para “Salvem os homens (deles mesmos...), não ataque a natureza”.

A partir da próxima postagem, entraremos nos processos da fase de Transição do Serviço!

Sigam-me os bons!!!

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.

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!

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

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


Sigamos na busca do conhecimento de ITIL V3...

Sigam-me os bons!!!

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

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

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

Na próxima postagem, colocaremos o último conceito da fase de Transição do Serviço...

Sigam-me os bons!!!

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.

Mais adiante, estaremos explorando o processo de Gerenciamento de Mudança. Quando chegarmos lá, aprofundaremos um pouco mais os conceitos definidos nesta postagem.

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

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

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!

Seguiremos na próxima postagem com os próximos processos desta fase do ciclo de vida do serviço.

Sigam-me os bons!!!

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.

Vamos continuar a nossa viagem pelos processos da fase de Desenho de Serviço nas próximas postagens. 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 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.

Seguiremos na próxima postagem com os próximos processos desta fase do ciclo de vida do serviço.

Sigam-me os bons!!!

ITIL 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	Subcategoria
Requisitos	Requisitos de Negócio Aplicabilidade de Serviço Contatos de Serviço
Desenho de Serviços	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	Diagnóstico de prontidão organizacional
Plano de Ciclo de Vida de Serviço	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 – 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.

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.

Continuaremos a passear pelas ferramentas do Desenho do Serviço nas próximas postagens... Não percam!!!

Sigam-me os bons!!!

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

Sigam-me os bons!!!

ITIL V3 – Conceitos e Definições – ANO e Contratos Subjacentes

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.

Na próxima postagem, finalizaremos a parte de conceitos e definições do Desenho do Serviço.
Não percam!!!!

ITIL V3 – Desenho do Serviço – Conceitos e Definições – ANS

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?

Vamos fazer o seguinte, na próxima postagem em respondo a esta intrigante pergunta, certo? Não percam os próximos capítulos... …vocês terão explicações reveladoras!!!

eu agarancho!!!! (como dizia seu Creisson do finado programa Casseta e Planeta)

Sigam-me os bons!!!!

ITIL V3 – Desenho do Serviço – Conceitos e Definições – Cinco Aspectos 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?

Dica: Nesta postagem tocamos no nome deste conceito...

Aguardem os próximos capítulos e...
…sigam-me os bons!!!!

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

Continuaremos a falar de mais conceitos e definições importantes para o desenho do serviço nas próximas postagens, vocês não perdem por esperar!!!!!

Vamos nessa!!!!

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:

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

Como vocês podem perceber, estaremos falando muito sobre este estágio nas próximas postagens pois há uma série de processos que fazem parte deste livro, por isso, não desanimem e me acompanhem nesta interessante jornada!!!! Vamos lá!!!!