A importância da implantação conjunta do ITIL com a ISO 20000

O ITIL v3 é uma referência para que as empresas implantem uma estratégia de serviços que envolva gestão da demanda, valores financeiros previstos para os serviços e a inclusão deste pipeline no portfolio. Também abrange um projeto do serviço que considera aspectos importantes como continuidade, capacidade, segurança e níveis de serviços. Na sequência é realizada uma transição do serviços para a produção, incluindo os processos de ativos/configurações de serviços, mudanças, release, testes e avaliação. Quando o serviço está pronto e devidamente aprovado/testado, é realizada uma passagem para a produção. Nesta etapa, processos e funções como service desk, incidentes, eventos e acesso são utilizados. Finalmente é apresentada uma referência para melhoria contínua, considerando algumas práticas recomendadas por Deming.

Estaria tudo certo, não fosse um detalhe. Sendo o ITIL uma referência, como garantir a implantação de forma efetiva e a sua sustentação ao longo do tempo?. O problema da abordagem apresentada é que o ITIL não garante que os processos sejam realmente implementados nos seus requisitos mínimos. Deveria existir em algum local uma determinação do tipo “deve existir um plano de capacidade !!” que pudesse ser avaliada quanto à sua eficácia. Neste aspecto, a ISO 20000 pode complementar o ITIL. O Cobit v4.1, com seus processos de Delivery & Support, atua com propósito semelhante, porém focando em "o que fazer" sob a ótica do ciclo de vida da Governança de TI e não em Gestão da Qualidade de Serviços de TI. Idem para o eSCM que determina "o que fazer" sob a visão do ciclo de vida de Outsourcing. O Cobit v4.1 e o eSCM estão em um nível acima. É preciso arrumar a casa. Para isto existe a ISO 20000 que é um padrão internacional de qualidade, projetado para gerenciamento de serviços de TI (ITSM). Certifica a empresa e tem como base o ITIL v2 (apesar de sua estrutura já contemplar o ITIL v3 nos seus requisitos mínimos e importantes para ITSM). No Brasil temos 05 empresas certificadas e no mundo são mais de 380, lideradas pela Japão (60), Reino Unido (58), India (44), China (37) e Coréia (34).

Bem, estava outro dia lendo uma revista mensal de TI. Notei em uma matéria algumas opiniões de CIOs quanto à Qualidade de Serviços de TI. Eis três afirmações passíveis de debate:

“Na parte de processos internos e de infra-estrutura, desde o ano passado estamos nos adequando às melhores práticas do ITIL. Como a meta é fazer a adoção completa do ITIL, estamos certificando nove funcionários e vamos contratar outros três já certificados. Essa adequação implicará a revisão de processos e da documentação”.

“Na área de governança e arquitetura de TI, nos baseamos nas melhores práticas do Itil e do Cobit, pois precisamos estar em conformidade com a Sarbanes-Oxley. Isso já garante a qualidade das informações e dos processos.”

“Em segurança, seguimos a norma ISO 27001. Já em relação à qualidade dos serviços de TI, temos um scorecard com indicadores como disponibilidades dos sistemas e custos”

Nenhuma crítica maior para as declarações acima, com exceção de que são visões bem restritas de gestão de serviços de TI. Nota-se que o foco maior está em “fazer acontecer” ou “fazer aparecer”, sem um cuidado com o melhor método ou com uma análise. Vejamos um exemplo deste raciocínio. Um CIO ao afirmar que já possui processos ITIL implantados não garante que a implantação está seguindo os requisitos mínimos de qualidade em ITSM. A ISO 20000 é um complemento do ITIL, pois atesta que as melhores práticas em gestão de serviços de TI estão efetivamente implantadas. Garante também que os processos mínimos estão sendo seguidos. O fato de acionar uma entidade externa (ex. BV, DNV ou BSI) para auditoria dos processos de forma contínua e periódica, bem como utilização de avaliações internas (auditoria interna), garante que os processos e a qualidade de serviços de TI estão sendo seguidos. Para garantir a qualidade das avaliações, é importante que sejam conduzidas por pessoas com excelente nível de conhecimento e experiência em ITIL e em Sistemas de Qualidade.

Outro aspecto importante é que a ISO 20000 garante para o ITIL alguns complementos fundamentais, como por exemplo a responsabilidade da alta direção sobre o sistema de qualidade de serviços de TI, competência, treinamento e requisitos de documentação para a execução dos processos. Tudo isto é auditado quanto à sua eficácia. Outro aspecto fundamental é a inclusão dos processos do ciclo PDCA, incluindo auditoria, registros, evidências de não- conformidades e oportunidades de melhorias com suas respectivas ações preventivas e corretivas. Processos importantes de relacionamento com o cliente (incluindo gestão de reclamações) e de gestão de fornecedores são auditados e escalados. Exige-se também um processo de melhoria de serviços com atividades bem definidas, incluindo determinações claras de entradas e saídas.

Finalmente, é recomendável que as empresas e provedores de TI considerem seriamente esta implantação conjunta. Os benefícios serão maiores do que a implantação do ITIL de forma isolada para a Gestão da Qualidade em Serviços de TI. Como dizia Gary Hamel, famoso guru e estrategista: “

“Boa parte do que está mudando simplesmente não é visto de onde você está sentado. Sua visão está obstruída. É preciso levantar-se da cadeira e buscar novos conhecimentos.”

Gary Hamel

Este alinhamento entre o ITIL e a ISO 20000 tem tudo a ver com esta busca de novos paradigmas para a gestão de serviços de TI. Eis mais um bom tema para debate com os colegas do blog.

Crise financeira mundial e os erros na gestão de riscos: O que a TI pode aprender

René Stulz, professor de Finanças Corporativas da Ohio University, escreveu recentemente um brilhante artigo sobre a crise financeira mundial. Segundo ele, o estrago se deve, em parte, a falhas em sistemas convencionais de gestão de risco. O brilhante mestre aponta seis grandes erros na gestão de riscos que não foram observados. Compartilho no blog uma síntese e análise do texto, relacionando-o com situações de gestão de riscos em Tecnologia da Informação. Pode ser útil na gestão de projetos e operações pelos leitores do blog.

Bem, à medida que forem somando as perdas trazidas pela crise financeira, a gente se pergunta, aqui do nosso recanto no Brasil, como o mercado financeiro pôde ter errado tão feio. Como é que todos aqueles complicadíssimos modelos foram falhar ? aqui no Brasil, como no resto do mundo existem softwares complexos que implantam modelos como VaR (Value-at-Risk), a exemplo do Risk Metrics do JP Morgan, Corporate Risk, SAS e outros, já abordados em artigo anterior neste blog. O autor relata que é óbvio que houve uma tremenda falha na gestão de risco em quase todo o mercado.

A seguir o professor explora em detalhe cada um dos seis caminhos do erro. Repare como estes equívocos também podem ocorrer em tecnologia da informação, guardadas as devidas diferenças:

• Depender de dados históricos. Modelos empregados na gestão de risco usam o passado para projetar o futuro, mas a rápida inovação financeira e tecnológica das últimas décadas fez da história um guia imperfeito.
• Usar indicadores limitados. Usam indicadores que não refletem totalmente o cenário para monitorar o risco. Os dados usados na montagem de modelos são apenas parte do problema. Os fundamentos oscilam.
• Ignorar riscos identificáveis. Pessoas responsáveis pela gestão do risco simplesmente ignoram muitos tipos de risco, e às vezes até criam alguns.
• Ignorar riscos ocultos. Pessoas que assume os riscos volta e meia não avisam quem precisa saber – às vezes de propósito, as vezes sem querer. Na organização o risco oculto tende a crescer.
• Falhar na comunicação. Sistemas de gestão de risco trarão pouca proteção se as pessoas responsáveis pela gestão do risco não souberem se comunicar com clareza.
• Não administrar em tempo real. Riscos podem mudar de forma brusca e acentuada com flutuações diárias dos cenários.

Em Tecnologia da Informação, o que podemos aprender com esta crise ? Para quem conhece um pouco de finanças corporativas sabe que o método mais comum de avaliar o grau de risco financeiro é o Value-at-Risk (VaR). Existem restrições em utilizar um único modelo como este. Em tecnologia da informação seria o equivalente a utilizar um único padrão como a ISO 27005, sem observar que existem padrões que o complementam e que podem ser utilizada para melhorar a gestão de riscos de TI. Um exemplo é o Risk IT do ISACA (trabalha forte com governança) e o NIST Risk. Outro equívoco seria utilizar em projetos de TI de grande porte e complexos apenas aspectos qualitativos do processo de Gerenciamento de Riscos do PMI/PMBoK, sem considerar aspectos mais sofisticados como Monte Carlo, Métodos Estatísticos, Análise de Probabilidade e Árvore de Decisão.

Outra questão importante é considerar que riscos em TI estão envolvidos apenas com controles e segurança da informação. Trata-se de uma limitação de indicador. Tive uma experiência deste tipo na implantação da norma ISO 20000, quando foi exigido que todos os riscos possíveis deveriam ser considerados na gestão da área escopo. Por exemplo, um risco de entrega de serviço ou do não cumprimento do SLA deve ser identificado e as pessoas responsáveis pela gestão do contrato não devem ignorar este fato. Uma comunicação clara deve ser realizada para o cliente e para todos os stakeholders do provedor de TI. Não avisar quem precisa saber tem sido um dos grandes problemas de derrocada de instituições financeiras do mundo e o mesmo pode acontecer em projetos de TI. O caso do Banco Barings da Inglaterra foi muito contundente neste aspecto.

Utilizar apenas dados históricos para prever possíveis problemas de venda e entrega de serviços é um equívoco. Estar sempre atento aos cenários não deve ser tarefa apenas da alta direção. Bem, esta foi uma relação rápida dos erros apontados pelo Professor René e erros possíveis em TI. Abordagens convencionais à gestão de risco embutem muitas ciladas. Em tempos de crises este tipo de abordagem pode simplesmente ruir. Podemos utilizar estas lições em tecnologia da informação. O professor denomina isto de “gestão de risco sustentável”. Mais um bom tema para debate.

Quando um processo deve ser arte, e não ciência ?

Na Harvard Business Review deste mês foi publicada uma matéria de dois professores do Dartmouth College mostrando que às vezes o movimento de padronização de processos vai longe demais. Segundo os autores, certos processos exigem o critério de um artista, e assim devem ser administrados. Gostaria de relacionar esta visão com os processos de tecnologia da informação, relatando alguns exemplos úteis para os leitores do blog.

Um processo de vendas que deu certo para infraestrutura de redes pode ser adotado para todos os serviços de TI ? ou o melhor seria que cada área tivesse seu processo específico alinhado com um processo corporativo ? faz sentido, para um provedor de TI, desenvolver e documentar um processo detalhado que siga os últimos padrões ISO ? Ou será que dar mais treinamentos e autonomia ao pessoal é o que garantiria uma qualidade superior? é possível ter mais qualidade administrando desenvolvedores de softwares como se fossem mecânicos ? É possível que um erro vire uma oportunidade de aprendizado ?

Há processos que naturalmente resistem à definição e à padronização – ou seja, que são mais arte do que ciência. Geralmente quando as suas entradas são variáveis e o cliente preza a variação nos resultados. Com alguns exemplos ficará fácil entender. A padronização de processos é ensinada em cursos de administração, é parte de programas Seis Sigma e ISO, é automatizada através de ferramentas BPM como os da BEA, Tibco e Aris e utiliza alguns modelos como SIPOC, UML, IDEF0 ou BPMn. Utilizei algumas ferramentas de BPM em clientes para produzir algumas dezenas de fluxos de processos automatizados para redução de papel, padronização, agilidade e “amarração” de atividades visando um objetivo final para o negócio, não separando processos padronizáveis ou não. Lembro também que melhores práticas de padronização são defendidas por gurus da área como Michael Hammer em seu livro “A Agenda” e Thomas Davenport no seu famoso artigo de 2005 na HBR sobre “Comoditização de Processos”, cuja representação máxima está no projeto “Process Handbook” do MIT (http://ccs.mit.edu/ph/). O PH é uma biblioteca de processos já implantados com sucesso em grandes empresas e tem utilização livre. Outro bom exemplo de padronização está na Toyota, conforme relatado em publicações como “The Toyota Way” que defende o conceito de trabalho padronizado dentro do STP (Sistema Toyota de Produção), combinada com outras práticas como Just-in-time e controles visuais para detectar desvios.

Bem, esta é a minha visão. No entanto, o problema identificado pela reportagem da HBR é que a padronização de processos pode, ironicamente, minar o próprio desempenho que pretende otimizar. Muitos processos funcionam melhor quando, em vez de rigidamente controlados, são tratados como um trabalho artístico. O Gerente deve separar todo processo artístico de processos de apoio que possam ser padronizados. Um grande vendedor de serviços de TI, por exemplo, busca em processos de vendas e sistemas de relacionamento com o cliente informações básicas e coerentes (padronizável) para ajustar seu discurso de vendas a cada cliente (não padronizável).

“A padronização exime o profissional da responsabilidade e faz com que ligue o piloto automático em vez de analisar melhor os detalhes do processo.”

"Um processo artístico precisa de indicadores externos de sucesso, como o feedback de clientes. Processos padronizados são medidos e avaliados à luz de normas e parâmetros determinados e acordados (SLA ? ), ao passo que processos artísticos são avaliados por meio da interação com o cliente."

A padronização e o controle são importantes, porém a arte utilizada em processos como vendas, inovação, gestão do conhecimento, atendimento ao cliente, desenvolvimento de software e até mesmo auditoria (porque não? ) permite uma flexibilidade, uma criatividade e um dinamismo impossíveis de serem reproduzidos por uma abordagem puramente científica. Os autores defendem que o desenvolvimento de uma nova aplicação em geral exige a iteração constante com cliente e decisões de simplificar o trabalho (imagine agora com os métodos ágeis). O atendimento ao cliente em um service desk deve ter flexibilidade de abandonar o roteiro e fazer o que achar melhor para o momento (lembrem-se o que a reportagem cita: existem variações e situações diferentes nas solicitações dos clientes e que exigem flexibilidade). Quanto a este ponto, lembro de um trecho do livro “O Futuro da Competição” de C.K. Phahalad, famoso guru de estratégia”, que manifesta sua irritação pelo fato dos atendentes de service desk serem geralmente avaliados em termos de produtividade e metas estipuladas em processos, em vez do valor e do retorno do atendimento para o cliente.

Bem, os autores concluem que tanto arte como ciência têm um papel importante nos processos da empresa. Não se pode pensar apenas em ganhos de produtividade e metas sem pensar nas pessoas, inovação e relacionamento com o cliente, e vice-versa. Lembro-me das lições do STP (Sistema Toytota de Produção) sobre melhoria contínua. Quando um problema surge, qualquer profissional da equipe é responsável e dispõe de autonomia para achar uma solução. Na Toyota, espera-se que cada um aja de acordo com o acha certo. Autoridade e responsabilidade cabem ao indivíduo, e não a um cargo ou tempo de serviço. Coloca-se a responsabilidade pela qualidade nas mãos dos membros da equipe. Eles sentem a responsabilidade, eles sentem o poder. Eles sabem que são levados em consideração. Eis um bom exemplo de arte que pode ser adaptado aos processos de TI.

Desafios em contratos de outsourcing de TI

Estava no final de 2008 apresentando um artigo científico no Congresso Nacional de Engenharia de Produção (ENEGEP) no Rio. Durante o evento, mantive um debate com o Professor Marcelo Pessoa da Poli/USP sobre algumas razões de um relacionamento bem-sucedido Cliente x Provedor de TI. Chegamos à conclusão que a busca da inovação, sem perder o foco em redução de custos e melhoria contínua, é uma meta a ser buscada sempre. Estudei algumas publicações internacionais que falam sobre o mesmo assunto. Compartilho com os leitores do blog algumas reflexões. Podem comentar à vontade, relatando situações que comprovam ou não o descrito a seguir.

Uma questão fundamental neste tipo de relacionamento é a percepção clara que os valores mudam ao longo do contrato. Em um primeiro momento existe uma preocupação muito forte em redução de custos, porém mudanças ocorrem e o provedor de TI deve estar preparado para entregar outros diferenciais como qualidade e inovação. Sendo realista, o cliente está preocupado inicialmente em uma TI mais econômica, motivo pelo qual ele busca uma terceirização, tentando no mínimo manter a qualidade atual. Após ganhar a concorrência o provedor inicia a implantação do contrato, colocando em prática o que foi acordado. Repare que, do ponto de vista estratégico, o processo de outsourcing é iniciado antes mesmo da colocação e resposta a uma RFP (Request for Proposals), conforme demonstrado na figura abaixo extraída do artigo "A Negotiation Approach to Project Sales and Implementation" do Project Management Journal do PMI (disponível em http://www.pmi.org/).

Avançando um pouco nesta hipótese de redução de custos, em um relacionamento longo, o outsourcing de TI inicia-se com uma percepção da alta direção do cliente de que a TI representa uma função “non-core” ou não principal do negócio. Na realidade é enxergada como uma “commodity”, onde os custos precisam ser reduzidos por meio de contratação de um provedor de TI externo. Os contratos geralmente são ganhos neste aspecto (custo), ou seja, quando o cliente tem a evidência que poderá reduzir os custos de TI do serviço em uns 20%, por exemplo. Existem riscos para futuras iniciativas de qualidade e inovações nesta fase inicial. Pode ocorrer redução de motivação para inovar por parte das unidades de negócios, já que todo contato com o provedor de TI passa a ser do CIO e da sua área de TI. O provedor de TI, por sua vez, fica com o desafio de manter o contrato rentável apesar das pressões do cliente em redução de custos. Convive-se, em alguns casos, com infra-estrutura do cliente muito desatualizada e equipe do contrato altamente enxuta, o que eleva ainda mais a pressão. O relacionamento é dominado neste ponto por constantes negociações em torno de escopo e custo acordado, não sobrando tempo para mais nada, além de manter o operacional rodando. A TI neste ponto é mais barata, e só.

Em uma segunda fase, ocorre uma insatisfação compartilhada entre provedor e cliente com a fase anterior. Neste aspecto, os objetivos de aumento de qualidade são requisitados para que a TI possa estar mais orientada ao negócio. O cliente está disposto a rever as capacidades de TI como também negociar quais os recursos ideais para prestação de bons serviços. O provedor avalia quais as melhores plataformas de práticas, processos, hardware e software para aumento da qualidade e quem poderá financiá-los. Temas como best practices e benchmarking são citados com freqüência. Um bom exemplo disto é a implantação da ISO 20000 ou de uma ISO 9001 em um contrato de um provedor de TI. Passa a existir então uma TI melhor.

Em uma terceira e última fase existe uma clara preocupação em adicionar valor ao negócio do cliente através de inovações. Voltando à nossa realidade, podemos citar exemplos como automação de processos de negócios, introdução de um método de medição/reporte de TI baseado em metas do negócio (ex. INDG ou Balanced Scorecard), uma solução efetiva de resolução de problemas, portal de conhecimento para colaboração e busca de soluções por toda a empresa, uma base de dados de configurações (CMDB), integrada de forma automatizada com demais bases de dados de negócios e de sistemas. Tudo isto alinhado com o negócio. Passa a existir então um negócio do cliente melhor.

O quadro mostrado acima com as três visões e mais detalhes sobre o tema podem ser obtidos no trabalho “Outsourcing: From Cost Management to Innovation and Business Value” do California Management Review, disponível como estudo de caso da Harvard Business School em http://www.hbs.edu/.

Para finalizar, importante ressaltar que a sequência apresentada (custo, qualidade e inovação) deve ser bem gerenciada. Não adianta tentar implantar no inicio do contrato um serviço inovador, quando isto representará “aumento de custo” não suportado pelo contrato e difícil de negociar (principalmente em época de crise financeira). Também não se deve insistir apenas na redução de custos e na implantação de uma simples documentação dos processos sem pensar em qualidade e inovação. No longo prazo, isto não se sustenta, podendo levar à perda do contrato em clientes mais exigentes. Bem, existe um grande desafio e pressão para os provedores de TI reduzirem custos e ao mesmo tempo aumentar valor dos contratos através da qualidade e inovação, tudo isto em um tempo cada vez mais curto. Eliminar este trade-off será um desafio constante. Para citar um exemplo real, participei de uma concorrência em 2008, onde o cliente exigia respostas claras para duas questões básicas:

“Possui algum diferencial em relação ao serviço, que possa proporcionar melhorias de processos, qualidade e/ou redução de custos ?“

“Gostaria de propor funcionalidades adicionais aos requisitos apresentados, que seriam vantajosas ao nosso negócio ?“

Pretendo em um próximo artigo indicar algumas alternativas para o assunto dentro do conceito de inovação de valor. Postarei também um exemplo prático de gráfico de melhoria de qualidade baseado no modelo de Qualidade Total de Joseph Juran (classificação tempo x desempenho de contratos).

Gestão de Riscos: Uma Avaliação do Risk IT Framework do ISACA/ITGI

Risco não é um conceito novo. A Teoria Moderna das Carteiras (base do que conhecemos como riscos corporativos) originou-se do trabalho pioneiro de Markowitz por volta de 1950 e ainda é muito estudada em Finanças Corporativas e MBA’s pelo mundo afora. Esta teoria está baseada nos conceitos de retorno e risco. Risco assumiu sua justa posição de destaque somente mais recentemente, seguindo-se a escândalos internacionais, como aqueles envolvendo nomes como Barings Bank (1997), Enron (2001) e mais recentemente com o Lehman Brothers e AIG.

Os três conceitos fundamentais para qualquer investidor são retorno, incerteza e risco. Retorno pode ser entendido como a apreciação de capital ao final do horizonte de investimento. Infelizmente, existem incertezas associadas ao retorno que efetivamente será obtido ao final do período de investimento. Qualquer medida numérica desta incerteza pode ser chamada de risco. Retorno e risco estão presentes em qualquer operação no mercado financeiro e também em tecnologia da informação. Existe um ditado antigo: “no risk, no fun”. Se o retorno é alto, geralmente o risco acompanha. Enquanto a definição de retorno é intuitiva, o mesmo não se pode dizer sobre risco. Isto porque o risco é um conceito “multidimensional” que cobre quatro grandes grupos:

• Risco Operacional
• Risco de Mercado
• Risco de Crédito
• Risco Legal

Vários frameworks foram desenvolvidos para riscos corporativos, sendo os mais conhecidos o VAR – Value at Risk e o COSO Enterprise Risk Management, assim como softwares para gerenciar estes riscos. Alguns sistemas mais conhecidos e que tive contato são o Risk Metrics e Corporate Metrics do JP Morgan, utilizados pela maior parte das instituições financeiras mundiais e por empresas como a Braskem e também o Risk Navigator, utilizado no Brasil pela Vale do Rio Doce. No que se refere a riscos operacionais e, sendo mais preciso, aos riscos de tecnologia da informação, existem alguns frameworks conhecidos como o NIST Risk Management e a ISO/IEC 27005.

Eis que chega mais um modelo no mercado e que eu gostaria de compartilhar com os colegas da CPM Braxis. Trata-se do Risk IT do ISACA. Este novo framework foi lançado em fevereiro/2009 e ainda está em formato de draft para consulta e contribuição por parte dos seus associados. A audiência deste modelo são os CIOs, CSOs, CFOS e Gestores de Negócios em geral. O Risk IT inclui três áreas de conhecimento: Risk Governance, Risk Evaluation e Risk Response. O framework é bastante extenso. As três áreas de conhecimento são desdobradas em 46 processos. Uma breve descrição de cada uma delas é mostrada abaixo:

1. Risk Governance

• Estabelecer e manter uma visão comum dos riscos
• Integração com Gerenciamento de Riscos Corporativos
• Incluir consciência de riscos nas decisões de negócios

2. Risk Evaluation

• Coleta dados
• Analisar os riscos
• Manter um perfil dos riscos.

3. Risk Response

• Articular os Riscos
• Gerenciar os Riscos
• Reagir aos Eventos

Fazendo uma analogia com o modelo do NIST, Risk Evaluation (Risk IT) está bem próximo do Risk Assessment. O Risk Response (Risk IT) está alinhado com os processos de Risk Mitigation do NIST. Comparando também com a ISO 27005, o Risk Evaluation (Risk IT) está relacionado ao Risk Assesment / Risk Analysis. Já o Risk Response (Risk IT) pode ser relacionado ao Risk Treatment / Risk Acceptance. A ISO 27005 também utiliza outros processos como Risk Communication e Risk Monitoring and Review que também podem ser relacionados ao Risk Response. O interessante da ISO 27005 é que os processos são colocados dentro de um PDCA (a exemplo de outras normas ISO). O NIST Risk Management possui uma extrema facilidade de entendimento e aplicação. Já uma vantagem do Risk IT é que, seguindo a linha do CobiT, para cada processo são apresentadas metas vinculadas com indicadores de negócio, processo, e de atividades, matriz RACI, input/output etc.

A diferença maior do Risk IT em relação aos demais modelos está no conceito de Risk Governance ou alinhamento do risco de TI com os demais riscos corporativos. Outra vantagem é a sua total integração com o CobiT v4.1 (Governança de TI) e Val IT (Gestão de Valor em TI). Por trás de todas as interfaces está o know-how do ITGI/ISACA. Não percebi em outros modelos que eu conheço um nível de sinergia tão forte para tomada de decisões em riscos de TI. A área de Risk Governance envolve alguns processos como Accountability de Riscos e Adaptação dos riscos de TI com os riscos organizacionais.O processo de conectar os riscos operacionais de TI com os riscos corporativos (financeiro, crédito e legais) ajuda a formar uma visão comum da visão dos riscos. Também foram montados processos para realizar o relacionamento com o COSO ERM.

Conforme mostrado na figura acima, o relacionamento do Risk IT com o Cobit e com o Val IT funcionará da seguinte forma: As atividades de TI e os eventos relacionados são controlados pelo Cobit, os quais são avaliados quanto aos seus riscos e oportunidades, gerando informações para a Gestão dos Riscos (IT Risk) e Gestão de Valor (Val IT), responsáveis pela diretrizes. Na figura abaixo, apresento o modelo geral com todos seus processos e relacionamentos necessários.




Após as contribuições, o objetivo do ITGI / ISACA será lançar o framework ainda neste ano de 2009. Na minha opinião, será muito útil em termos de complementação aos modelos existentes. Vamos esperar para ver.

A Certificação de Engenheiro de Qualidade de Software

Saiu o ranking do ultimo exame de CSQE (Certified Software Quality Engineer) da ASQ (American Society for Quality). A prova foi realizada em dezembro/08 em vários locais do mundo, incluindo o Brasil. Esta certificação concorre de perto com a CSQA (Certified Software Quality Analyst) e a CSTE (Certified Software Tester) da QAI, bem mais conhecidas e populares, principalmente entre os indianos. O currículo do CSQE abrange o conteúdo das duas certificações da QAI e tem uma base muito forte em Qualidade Total, dada a tradição da ASQ nesta área. São apenas 4.300 CSQEs contra mais de 50.000 do CSQA/CSTE. A maior experiência requerida, prazo de validade, o currículo maior, a falta de disponibilidade no Prometrics e o fato do exame do CSQE ser realizado apenas em inglês pode explicar esta diferença. Atualmente mais de 50% dos aprovados concentram-se nos EUA.

Quanto à prova, o currículo abrange Qualidade Total, Estatística, Qualidade de Software, Custos da Qualidade, Engenharia de Requisitos, Métricas de Software, Técnicas Analíticas, Métodos Ágeis (Scrum/XP/TDD), Revisão&Inspeção, Planejamento e Projetos de Testes, Configurações, Engenharia Reversa, Reuso, Gestão de Projetos, Arquitetura de Aplicações, Sarbanes-Oxley, Lean Six Sigma (básico), CMMI, ISO 9126, ISO 12207, ISO 15504, SWEBoK e outros temas relacionados. São 160 questões em 04 horas. O tempo é muito pouco, já que existem cálculos estatísticos e matemáticos (ex. APF, Complexidade Ciclomática e Confiabilidade).

A aprovação está em torno de 50% a 60% nos EUA e menor em outros países Temos atualmente apenas cinco pessoas com esta certificação no Brasil. O curioso é que existe alto interesse pelo CSQE em outros países. Nos seis últimos exames foram 1.500 aprovados, sendo apenas uma única pessoa da nossa terra. Os números refletem bem alguns países que estão investindo fortemente em software business: Coréia, Israel, Índia, China e Japão. Alguns outros países como a Argentina e Costa Rica estão crescendo neste ranking.

Recomendo esta certificação para todos os brasileiros envolvidos ou que gostam de Qualidade de Software. O BoK, os valores detalhados, preparação e datas dos próximos exames estão disponíveis no seguinte endereço:

http://www.asq.org/certification/software-quality-engineer/index.html

O próximo exame no Brasil está previsto para 06/06/2009 e o valor da inscrição é de US$ 390.00 para os não associados da ASQ. Há necessidade de preencher um application. Recomendo também adquirir o curso CSQE Primer do Quality Council of Indiana por US$ 150.00, além de um bom livro de Qualidade Total em inglês (preferencialmente o Juran’s Quality Handbook) por US$ 120.00. Por segurança pedir emprestado em bibliotecas livros clássicos de Engenharia de Software (sempre em inglês) como o Pressman e o Sommerville e também o "Metrics and Models in Software Quality Engineering" de Stephen Kan, livro recomendado pela ASQ e que é bastante solicitado na prova.

A Crise e os Recursos Estratégicos das Empresas

Na revista Exame de fevereiro/2009 foi publicada uma matéria sobre a difícil decisão de cortar gastos em momentos de crise. Segundo a revista, a crise vem colocando uma situação algumas vezes inevitável diante dos executivos: a demissão em massa. Mas como definir rapidamente como e onde demitir sem comprometer o futuro? Desde o final do ano passado, quando os primeiros sinais da crise apareceram por aqui, executivos e empresários brasileiros reincorporaram a seu vocabulário expressões como "corte de pessoal" e "demissão em massa. A redução de cerca de 4.000 empregos em fevereiro na Embraer foi um claro sinal de que a crise chegou ao mercado real.

Diante do cenário atual, um deslize comum é a tentação de seguir o caminho mais simples e rápido e baixar metas iguais de cortes para todas as áreas da empresa. A revista diz que o preço a pagar por uma decisão tomada às pressas pode ser alto. Para determinar onde fazer os cortes de maneira eficiente, os especialistas recomendam avaliar detalhadamente toda a estrutura da companhia. Muitas empresas ainda fazem escolhas sociais - tempo de casa, pais de família, necessidades econômicas. Embora se justifiquem do ponto de vista humanitário, esses critérios não são necessariamente justos com quem dá mais resultado ou tem maior potencial. Para demitir 1 300 de seus funcionários, a Vale analisou as avaliações de desempenho de todos os funcionários das áreas atingidas pelos cortes. Os que tinham resultados mais consistentes ao longo do tempo, cumpriram ou ultrapassaram suas metas anuais e tinham características de liderança foram mantidos. Os donos das piores avaliações entraram no corte. Em geral o marketing, o contato com o cliente e desenvolvimento de produtos são áreas que não podem ser mexidas. A matéria completa da Revista Exame está disponível em:

http://portalexame.abril.com.br/revista/exame/edicoes/0937/gestao/decisao-mais-dificil-422196.html

Já a revista Harvard Business Review na sua edição de dezembro/08 publicou um artigo de Kaplan & Norton (os mesmos criadores do Balanced Scorecard) sobre o mesmo assunto. Segundo eles, em uma reação instintiva, muitos executivos cortam gastos discricionários por toda a organização durante uma crise econômica. Só que esta poda brutal e indiscriminada é um grande erro, pois não faz distinção entre programas operacionais de curto prazo e estratégicos de longo prazo. Salvo se a crise estiver ameaçando a existência da empresa, o que seus executivos devem fazer é eliminar excessos e ineficiência operacionais – e não modificar ou sacrificar iniciativas estratégicas a exemplo de inovação e gestão do conhecimento, que geram recursos para a vantagem competitiva de longo prazo.

Para ajudar a empresa a preservar e fortalecer seus programas estratégicos, os autores criaram uma uma nova categoria de despesas – despesas estratégicas (ou StratEx, no inglês) – para suplementar as categorias tradicionais de despesas de capital e despesas operacionais (OpEx). Kaplan & Norton constataram que, se não forem separadas das demais categorias e protegidas, as StratEx serão vistas como discricionárias pela diretoria. Diante de dificuldades econômicas de curto prazo, é comum a diretoria deferir ou transferir fundos de iniciativas estratégicas para honrar metas financeiras de curto prazo – um dos principais motivos da tremenda dificuldade da maioria das organizações em sustentar processos de execução da estratégia. Finalmente, criar uma categoria de financiamento de StratEx ajuda a empresa a reunir recursos para o futuro enquanto elimina os excessos do passado.

Para quem estiver interessado em maiores informações sobre o conceito de StratEx pode encontrá-lo no 4º. capítulo do livro de 2008 “A Execução Premium” de Kaplan & Norton.

Nicholas Carr e a Grande Mudança

Estou lendo o livro de Nicholas Carr, “A Grande Mudança, Reconectando o Mundo, de Thomas Edison ao Google”. Apesar de não ser tão recente (2007), e o assunto “Utility Computing” já ter sido bastante debatido, recomendo a leitura por ser um tema importante e atual. Carr descreve que o mundo da tecnologia está às vésperas de uma nova e profunda transformação.

“Em um futuro próximo, tudo o que acontece dentro do computador - desde o processamento até o armazenamento de informações - deve migrar para a internet.“

Os documentos, assim como os aplicativos usados para criar e modificar esses arquivos, estarão guardados em servidores espalhados pela internet. O PC vai ser apenas um dos meios de acessar essas informações, a qualquer hora, de qualquer lugar. Na esfera das empresas, a mudança representa o desaparecimento de grandes servidores, por exemplo. A idéia é poderosa e tem implicações profundas e imediatas para a indústria de software e hardware, na qual prosperaram potências inquestionáveis como Microsoft e IBM. No cenário delineado por Carr, ninguém mais precisará comprar um software para ter em sua máquina o programa que deseja. Ele será um serviço disponível via internet, pago em mensalidades ou até mesmo gratuito.

O mais interessante do livro é a relação que o autor faz entre esta transformação atual e o serviço de geração elétrica há um século. O grande personagem da época foi o inventor e empresário americano Thomas Edison, que no final do século 19 levou a eletricidade para dentro das casas. A visão de Edison não só transformou o funcionamento das empresas mas alterou o ritmo de vida e a cultura da sociedade.

“Inicialmente os donos das fábricas precisavam estar também no ramo de produção de energia. Após um certo tempo, podiam fazer suas máquinas funcionarem com a corrente elétrica gerada em usinas distantes por grande companhias de serviços públicos, e que chegava às suas fábricas por meio de uma rede de cabos. “

O que garantiu este triunfo não foi a tecnologia, e sim os processos econômicos. As fornecer a muito compradores a energia gerada em centrais elétricas, as companhias chegaram a uma economia de escala em termos de produção de energia, algo que não era páreo para nenhuma fábrica individual. Para os donos das indústrias, tornou-se uma necessidade competitiva plugar as fábricas à nova rede elétrica para terem acesso a uma fonte de energia mais barata.

É claro que todas as analogias e os modelos históricos têm seus limites, e a tecnologia da informação difere da eletricidade de muitas formas importantes. Mas, elas têm grandes similaridades. Não precisam ser produzidas no local em que serão usadas. É um serviço que gera inúmeros usos que adquirem vida própria. Em um plano econômico, ambas são usadas por todo o tipo de consumidor para fazer todo o tipo de coisa e fornecem imensas economias de escala. Diferente, por exemplo, ao sistema ferroviário. Depois que os trilhos são assentados, você só pode fazer uma única coisa com eles: fazer circular trens para um lado e para outro, levando carga ou passageiros.

Conceitos como Web 2.0, Wireless, Mobile Business, Computação nas Nuvens (Cloud Computing) e SaaS (Software como Serviço) já refletem, embora em um estágio inicial, a transformação preconizada por Nicholas Carr. Recomendo uma matéria sobre Google e Computação nas Nuvens que saiu no Mundo S.A. da GloboNews em 2008, disponível em:

www.youtube.com/watch?v=IdRW8FAc6IA

Problemas como segurança, latência, nível de serviço, propriedade da informação e outras restrições ainda impedem a utilização em massa do Cloud Computing. Neste aspecto, quem não se lembra dos problemas (até maiores que estes) no inicio do uso da internet ou até mesmo do internet banking (segurança). Segundo Nicholas Carr, o mesmo aconteceu com a eletricidade. No inicio, era uma força imprevisível, ainda não domesticada, e que modificava tudo em que tocava. Como no caso dos sistemas de computação atuais, todas as empresas tinham de descobrir como empregar a eletricidade em seus negócios, fazendo mudanças radicais e freqüentes em seus processos produtivos e em suas formas de organização.

“Tudo estará na grande nuvem e será mantido por empresas que serão responsáveis pela infra-estrutura operacional.”

Finalmente, a minha visão é que não chegaremos ao extremo preconizado por Nicholas Carr:“Os departamentos de TI não terão muito que fazer depois que a computação corporativa migrar de data centers privados para a nuvem”. Mas que teremos escalabilidade, redução de custos, maior retorno sobre o investimento e utilização ideal dos recursos, isto com certeza ocorrerá. O difícil cenário econômico em 2009 e dos próximos anos irá exigir dos departamentos de TI e das empresas de outsourcing ações inovadoras. Esta com certeza será uma delas.

Gerenciamento de Projetos e a Certificação IPMA

O mercado utiliza como padrão de gerenciamento de projetos a metodologia americana PMI (Project Management Institute), com seu guia de práticas PMBoK e sua certificação mais conhecida, o PMP (Project Management Professional). Existe, no entanto, outros padrões também utilizados como o IPMA (internacional) e o Prince2 (inglês). Pretendo passar para vocês uma visão do IPMA – http://www.ipma.ch/ (International Project Management Association) e suas certificações. Tenho a certificação PMP, com a qual já trabalho há algum tempo. Recentemente obtive a certificação IPMA-D (Certified Project Management Association) e passei a trabalhar também com esta prática para gerenciamento de projetos. Gostaria de compartilhar alguns conhecimentos com os leitores do blog.

O IPMA foi fundado em 1965. É um padrão europeu, com sede na Suíca e associações locais em 45 países do mundo. Por exemplo, na Inglaterra existe a APM (Association of Project Management), na Dinamarca a ADPM (Association of Danish Project Management), na China o PMRA (Project Management Research Commitee) e no Brasil temos a ABGP – http://www.abgp.org.br/ (Associação Brasileira de Gerenciamento de Projetos), com sede em Curitiba. O Congresso Mundial de 2008 foi realizado na Itália e o próximo será na Finlândia. O código de melhores práticas é o ICB (IPMA Competence Baseline 3.0), equivalente ao PMBoK, com algumas particularidades. Por exemplo, permite-se que cada país realize alterações para as certificações, adequando o manual à sua realidade. No Brasil a ABGP possui o RCB – Referencial Brasileiro de Competências, disponível na página da ABGP. Outro detalhe é que o ICB possui alguns processos diferentes em relação ao PMBoK (alguns são tratados como input ou output neste código de práticas), como por exemplo Aspectos Comportamentais do Gerente do Projeto, Gestão de Conhecimentos, Gestão de Meio-Ambiente, Gestão de Aspectos Legal e Gestão de Informática. Para quem acompanha publicações em gerenciamento de projetos, uma das revistas brasileiras mais conhecidas e que recebe patrocínio da ABGP é a Revista Mundo PM, publicada em Curitiba/PR. Reparem que na maioria das edições os artigos internacionais são provenientes da Inglaterra, Suécia, Finlândia, Noruega, França e Itália, exatamente onde o IPMA é mais forte.

Para quem estiver interessado nesta certificação, na página da ABGP constam as datas programadas das provas para 2009 (média de quatro por ano). Os exames são realizados em Curitiba e em Belo Horizonte, onde se concentram 90% das certificações brasileiras. O motivo é que a ABGP está localizada em Curitiba e em BH existem incentivos de profissionais conhecidos em gerenciamento de projetos no Brasil: Ricardo Vargas e Darci Prado (INDG).Existe expectativa do exame ser realizado em outros locais.

Bem, a certificação IPMA está projetada em quatro níveis:

A – Certified Project Director capacidade de gerenciar portfolio e programas complexos.
B – Certified Senior Project Manager: capacidade de gerenciar projetos complexos. Mínimo de 05 anos de experiência.
C – Certified Project Manager: capacidade de gerenciar projetos menos complexos. Mínimo de 03 anos de experiência.
D – Certified Project Management Associate: capacidade de aplicar conhecimentos de gerenciamento de projetos dentro dos projetos.

Fazendo uma comparação com o PMI: Na teoria, a certificação de nível A do IPMA equivaleria ao PgMP do PMI, as certificações de níveis B/C equivaleriam ao PMP e a de nível D (CPMA) ao CAPM. Isto na teoria, pois na prática não é exatamente assim. Na candidatura, exige-se toda a documentação necessária, incluindo curriculum vitae completo (no PMP é por amostragem). As provas são realizadas em duas etapas: a primeira com questões objetivas (50 questões) e abertas (05 questões principais desdobradas em 20 secundárias) e a segunda etapa com uma entrevista com grau de complexidade conforme o nível da certificação (no nível D este requisito está sendo implementado aos poucos).

As questões descritivas são direcionadas para validar o real conhecimento do candidato em project management. É fornecido um tema e solicitado a criação de todo um projeto, incluindo Project Charter, Declaração de Escopo, Plano de Projeto, Plano de Riscos, WBS, Dicionário de WBS, Cronograma, Deliverables, Determinação do Caminho Crítico, Status Report, Relatório de Lições Aprendidas , Gestão de Conhecimento, Automação da Gestão do Projeto etc. Tudo isto em 04 horas de prova escrita (ainda não está disponível no Prometrics).

Atualmente não temos nenhum profissional no Brasil no nível A (no mundo são apenas 200). Temos 06 profissionais no nível B, 08 no nível C e 75 no nível D. Total de 91 profissionais certificados em IPMA no nosso país, o que é muito pouco, considerando que existem mais de 6.000 PMPs no Brasil e também pelo valor e prestígio do IPMA nos países europeus (pode fazer diferença em negócios para esta região). Para finalizar, o IPMA pode complementar o PMI de várias formas. A sua visão é mais internacional, uma vez que cada país possui o seu guia de melhores práticas em Project Management, conservando o núcleo do ICB. Também fornece visão mais clara de processos como gestão de conhecimento, tecnologia da informação, meio-ambiente, aspectos legais como também aspectos comportamentais para o gerente do projeto, assuntos fundamentais em qualquer projeto.

Open Innovation !! Open Source !! Open Choice ...

Muito se tem falado e escrito a respeito da inovação aberta e suas diversas aplicações. Henry Chesbrough, do Center for Open Innovation da Universidade de Berkeley (http://openinnovation.haas.berkeley.edu/), disseminou esta expressão através do seu livro Open Innovation (ainda sem tradução para o português). Ele afirma que o conceito de Inovação Aberta (Open Innovation) quebra o paradigma tradicional da Pesquisa & Desenvolvimento feito a portas fechadas, por uma única empresa. Este conceito trata a inovação como um sistema aberto onde tanto idéias externas e internas são debatidas e as melhores alternativas são selecionadas. Um dos grandes benefícios desse modelo é que as empresas conseguem dividir os riscos e custos do processo de inovação.

Don Tapscott em seu livro Wikinomics mostra que a nova arte e ciência se baseiam em quatro novas e poderosas idéias: abertura, peering (ausência de hierarquia) compartilhamento e ação global. Esses novos princípios estão substituindo algumas velhas doutrinas dos negócios. Empresas inovadoras como a P&G são muito diferentes das multinacionais hierárquicas, fechadas, cheias de segredos e isoladas que dominaram o século anterior.

“O objetivo é deixar que a maior parte da atividade de pesquisa aconteça nas redes cientificas. As empresas devem se ater a solucionar os difíceis problemas de orquestração dos negócios e recursos.”

Don Tapscott, Wikinomics

Já o modelo Open Source é um exemplo claro do modelo de inovação aberta, pois envolve colaboração entre empresas, comunidade de desenvolvedores, clientes e parceiros. O modelo Open Source difere do modelo tradicional em basicamente dois aspectos: o processo de desenvolvimento, que é essencialmente uma produção colaborativa e a filosofia de propriedade intelectual, que permite a livre distribuição do código fonte, bem como o direito de modificá-lo.

" O modelo Open Source é um belo exemplo de como empresas podem atuar em ecossistemas complexos combinando inovações internas e externas. "

Conforme Sergio Taurion da IBM, Open Innovation com Open Source pode se dar de várias formas. Podemos identificar o modelo de “Pooled R&D”, tipicamente representado pelos projetos Linux e Mozilla, onde diversas empresas e a comunidade pesquisam e desenvolvem o software de forma colaborativa. Outro modelo é o Spinout representado pelo Eclipse que é um exemplo prático e bem sucedido do modelo de Open Innovation, onde empresas concorrentes podem criar redes de inovação, cooperando no desenvolvimento de softwares Open Source, que servirão de base para produtos específicos (proprietários), com os quais concorrerão no mercado.

No Livro The Game-Changer ou “O Jogo da Liderança”, A.G. Lagley, CEO da P&G e o guru Ram Charam mostram como funciona a inovação aberta na Procter & Gamble. O principal radar é o portal Connect & Develop, criado em 2003. Ele está conectado com outros quatro portais: NineSigma, yet2, YourEncore e Innocentive. Segundo os autores, a principal característica do portal C&D é a disposição de todas as pessoas da P&G de se manterem psicologicamente abertas a novas idéias e levá-las a sério, independentemente de sua origem, desenvolvendo, dessa forma, uma rede de inovação aberta e global que possa se conectar com os pesquisadores ao redor do mundo e os melhores produtos para serem reaplicados. No nosso mercado de tecnologia da informação, empresas como IBM e TCS já estão bastante avançadas neste conceito. Algumas utilizam a expressão Co-Innovation (Collaboration Innovation) para denominar esta nova onda.

Em 2008 ocorreu em São Paulo o Open Innovation Seminar 2008, que deverá se repetir em 2009. Este evento contou com a presença do Henry Chessbrough e com pesquisadores de empresas nacionais e internacionais que já estão praticando em larga escala este tipo de inovação, a exemplo da Embraer, IBM e Natura. Os vídeos deste evento estão disponíveis no youtube. Recomendo o vídeo com a palestra de Cesar Taurion sobre as diversas iniciativas da IBM relacionadas com o tema (Innovation Jam, Institute for Business Value, GIO, Co-Innovation e outras), disponível em:

www.youtube.com/watch?v=ZAH2oLKY_k8&feature=PlayList&p=A9FDE113E96601D4&index=7

No youtube, também pode ser encontrado um excelente vídeo de um evento realizado na Universidade de Berkeley pela IBM e British Telecom sobre o assunto. Recomendo o vídeo sobre Open Innovation in Services com Steve Wright, Head of Strategic Research da British Telecom. É interessante o debate entre o palestrante e o brasileiro Jean Paul Jacob, cientista da IBM e professor da Caltech.

www.youtube.com/watch?v=g7eRgHWQCZc

Finalmente, diante da cada vez maior disseminação da open innovation e do open source, como também diante do atual cenário de crise mundial, é de se esperar que veremos cada vez mais artigos e cases de utilização dos dois conceitos em conjunto. É a ciência cada vez mais a serviço do negócio. Com o Open Innovation e Open Source, podemos realizar escolha (Open Choice). Como já dizia Gary Hamel, famoso estrategista, você não pode ser um inovador sem ponto de vista revolucionário. Vá além do horizonte, descobrir o não convencional, imaginar o inimaginado. Boa parte do que está mudando simplesmente não é visto de onde você está sentado. Sua visão está obstruída. É preciso levantar-se da cadeira e buscar novas experiências, ir a novos lugares, aprender novas coisas, relacionar-se com novas pessoas. Você deve tornar-se um viciado em novidades. Open Innovation e Open Source tem tudo a ver com isto.

Uma Visão Orientada a Processos do ITIL v3 Service Lifecycle

A versão 3 do ITIL aborda o conceito de Ciclo de Vida de Serviços. São agora seis livros: Service Strategy, Service Design, Service Transition, Service Operation e Service Improvement, além do Introduction to the ITIL Service Lifecycle. Nota-se uma forte influência do ciclo PDCA na construção do ciclo. Na atual versão da biblioteca novos processos foram introduzidos a exemplo de Gestão de Portfolio de Serviços, Gestão de Eventos e Gestão de Conhecimento de Serviços (SKMS). A consolidação do ITIL v3 não está tão rápida como deveria, por vários motivos. Um deles é a complexidade da nova versão que agora possui 26 processos e 04 funções. Outro é a aplicação do curso/prova da certificação ITIL Service Manager do ITIL v2 que continua valendo (possui caminho mais curto para a certificação master). Finalmente, falta a adequação total da ISO/IEC 20000 (Certificação em IT Services Management para empresas). Esta norma está fortemente alinhada com a versão v2.

No que se refere ao ciclo de vida da gestão de serviços de TI, forneço aqui uma visão orientada a processos do ITIL v3. Poderá ajudar a entender como funciona na prática a nova versão deste framework. Estes conceitos foram extraídos de experiências, apostilas de treinamentos e do livro Introduction do ITIL v3.

No estágio inicial, o provedor de serviços de TI inicia a Estratégia de Oferta do Serviço gerenciando os requisitos de negócios (Gestão de Demandas), e traduzindo isto em uma estratégia para entregar o serviço (Estratégia do Serviço), validando os custos para manter estes serviços (Gestão Financeira) e introduzindo o serviço dentro do portfólio de serviços (Gestão de Portfolio de Serviços). Neste momento TI ainda não retorna valor para o negócio.

Quando a estratégia está completa, TI inicia a segunda fase que é o Projeto do Serviço, através de atribuição de requisitos de níveis de serviços para os serviços (Gestão de Níveis de Serviços), analisando a disponibilidade e capacidade requisitada (Gestão de Capacidade e Disponibilidade), selecionando os fornecedores que realizarão o suporte dos serviços (Gestão de Fornecedores), definindo a adequada provisão de continuidade de serviços (Gestão de Continuidade dos Serviços), validando e projetando os requisitos de segurança (Gerenciamento de Segurança) e introduzindo o serviço dentro do Catálogo de Serviços (Gestão de Catálogo de Serviços).

Na terceira fase (fase de Transição dos Serviços), o serviço está pronto para ser implementado no ambiente de produção. O provedor de serviços define o plano de transição (Planejamento de Transição e Suporte) e avalia, aprova, implementa e planeja a mudança (Processo de Gestão de Mudanças). Após a implementação da mudança, o serviço é testado (Validação e Teste de Serviço) em um ambiente de homologação. Se o teste for bem sucedido, o serviço é documentado (Gestão de Conhecimento) e seus componentes são incluídos no banco de dados de ativo e configuração (Gestão de Ativos e Configuração). A última atividade é realizar a liberação no ambiente de produção (Gestão de Liberação e Instalação) e após o “go-live”, uma revisão pós-implementação deverá ser executada (Gestão de Avaliação).

Na quarta fase (Operação do Serviço), o serviço começa a ser gerenciado e suportado para que alcance o nível de serviço acordado através do gerenciamento dos chamados dos usuários (Service Desk e Gestão de Solicitações), monitorando os alertas e eventos do serviço (Gestão de Eventos), restaurando as interrupções não programadas dos serviços (Gestão de Incidentes), evitando as causas dos incidentes e reduzindo a duração de incidentes (Gestão de Problemas), gerenciando a maneira segura de utilização do serviço (Gestão de Acesso), mantendo o produto de software (Função de Gestão de Aplicação), executando as atividades diárias (Gestão de Operação) e suportando a infra-estrutura (Gestão Técnica).

A fase de Melhoria Contínua do Serviço é acionada durante todas as fases do ciclo de vida. É responsável por medir o serviços e os processos (Medição dos Serviços), e documentar os resultados (Reporte do Serviço) para que seja melhorada a qualidade do serviço e a maturidade dos processos (Melhoria do Serviço). Estas melhorias devem ser implementadas na próxima fase do ciclo de vida do serviço, iniciando-se novamente na Estratégia do Serviço e ciclo então recomeça.

Espero ter contribuído para um entendimento mais claro do ciclo de vida de serviços. O ITIL v3 é fundamental para o sucesso da certificação ISO/IEC 20000, apesar do relacionamento mais forte desta norma com o ITIL v2. Processos novos como Gestão de Eventos, Gestão de Fornecedores, Gestão de Demandas, Gestão de Catálogo de Serviços e Gestão da Operação, não existentes de forma isolada no ITIL v2, são exigidos para compliance com a norma.