REDISTRIBUIÇÃO diferenças entre a ITIL v2 e V3 Parte Serviços: a ponte perdida entre negócios e

REDISTRIBUIÇÃO: Você concorda que não irá copiar, redistribuir ou explorar comer-cialmente qualquer parte deste documento sem a permissão expressa do autor.

CURADORIA: Renê Chiari

ITIL® é uma Marca Comercial Registrada do AXELOS Limited.

Esta obra tem apenas como objetivo contribuir com a comunidade de profissionais de Gerenciamento de Serviços de TI. Como apoio são usadas referências de outros mate-riais sem infringir direitos autorais de terceiros

Copyright © 2014 - Todos os direitos reservados

1ª edição publicada em julho de 2014

www.mapadoitil.com.br

André Bernardo

Especialista em Gerenciamento de Projetos. Sócio-fundador da COMMUNIT. Experiência em gestão de projetos estratégicos. Certifica-dos: PMP, ITIL foundation.

André Jacobucci

Consultor de Integração e Gerenciamento de Serviços. Trabalha no setor de TI há mais de 18 anos. Sua experiência abrange vários segui-mentos, incluindo serviços financeiros (banca e seguros), Serviços de TI,

Telecom, edição e de petróleo. Possui extensa experiência em gestão de projetos, consulto-ria em ITIL, COBIT e ISO / IEC 20000 , a ad-aptação e implementação de soluções de ITSM e concepção, desenvolvimento e implantação de aplicativos.

Certificações: ITIL Expert, ITIL v2 Service Manager, ISO/IEC 20000 Consultant, COBIT Foundations

Alberto Andrade

Especialista em operações e gestão de serviços de TI. Treze anos de experiência no suporte, im-plantação e start up de projetos de outsourc-ing baseado em ambientes de suporte técnico, Helpdesk e redes de dados.

Possui as certificações ITIL Foundation, MCP Microsoft e Cisco CCNA.

Bruno Caiado

Consultor especialista em Governança e Ger-enciamento de Serviços. Especializações: ITIL®, ISO 27001, ISO/IEC 20000, COBIT, Cloud Computing, Corporate Citizenship & Corporate Affairs.

Carlos Afonso

Gerente de Operações. Especializações: Gov-ernance, Control, Assurance and Project Con-sulting in IT.

Claudia Marquesani

Consultora Sênior e instrutora especialista em Gerenciamento de Serviços de TI. É certificada ITIL, COBIT, ISO 20.000, ISO 27000 e TOGAF.

Atua há mais de 15 anos em projetos baseados em ITIL®, ISO 20.000 e governança de TI em multinacionais e empresas de grande porte. Graduada pela Fundação Getúlio Vargas, é co-fundadora do site ITSM na Prática,

Gerente de Central de Serviços e suporte é entusiasta de novas tendências de mercado e assuntos relacionados a gestão de serviços, suporte e atendimento.

Claudio Dodt

Business Continuity & Security Senior Con-sultant, atua na área de tecnologia há mais de 10 anos exercendo atividades como técnico e analista de suporte, Analista de Segurança Sr., Security Officer e Supervisor

de Infraestrutura e Segurança. Desenvolveu atividades em empresas brasileiras e multina-cionais, tendo participado no Brasil e no exte-rior em projetos de segurança de diversos seg-mentos como Educacional, Financeiro, Saúde, Agroindústria, Indústria Alimentícia, Naval, Metal-Mecânica e Têxtil.

Especializações: ITIL®, CISSP®, CISA, CRISC, ISO 27001, ISO/IEC 20000, COBIT, Cloud Computing Foundation.

Gustavo Tavares

Graduado em Administração e pós-graduado em Gestão Estratégica de TI pela FGV. Grande experiência com otimização de processos de negócio por meio da TI.

Trabalhou planejando e gerenciando os con-troles de Governança de TI e os processos de: desenho de soluções, gestão de demandas; gestão de projetos; qualidade de software; gestão de serviços de TI, gestão de contratos e gestão da segurança da informação. Atual-mente lidera as iniciativas e a equipe de TI do Comitê Paraolímpico Brasileiro.

É certificado como CBPP, PMP, ITIL Practition-er (equivalente ao atual ITIL intermediate), SOA Solution Desiner e COBIT Foundations.

Luiz Wagner Oliveria Nascimento

Especialista em outsourcing. Experiência em sistemas operacionais Windows e Linux, Im-plantação e Treinamento de pessoal em Siste-ma, Banco de Dados, Analise em Código Fonte, aplicação de boas praticas

como o ITIL, ISO20000 e sempre em buscan-do a melhoria continua e no desenvolvimento, implantação e gerência de Service Desk.

Nelson Granado Merino

Executivo de Contas. Co-fundador do ITSM na Prática. Especializações:Criação de Produtos, implantação de serviços e implementação de processos e ferramentas de gerenciamento de serviços de TI.

Renê Chiari

Consultor especialista em Governança e Ger-enciamento de Serviços de TI. Co-fundador e administrador do blog ITSM na Prática

Formado em Gestão de Ambiente Internet e Redes de Computadores, possui as certifi-cações ITIL® Service Manager, ITIL® Expert, ISO/IEC 20000 Associate/Consultant e CO-BIT 4.1. Ao longo de sua carreira profissional, passou por grandes corporações do ramo de Tecnologia de da Informação e consultorias especializadas, atuando como consultor e in-strutor em dezenas de projetos. Entusiasta do assunto Gerenciamento de Serviços de TI, é um dos fundadores do ITSM na Prática (antig-amente conhecido como ITIL na Prática). Pub-licou mais de 70 artigos e é autor do pocket book “ITIL na Prática: Gerenciando Problemas de Infraestrutura e Serviços de TI”.

Roberto Cohen

Especialista em Help Desk / Service Desk / Sup-port Center, realiza treinamento, consultoria e palestras na temática. Atua na área de suporte há 25 anos e treinou mais de cinco centenas de profissionais nos últimos quatro anos.

Pós-graduado em Especialização de Psicolo-gia nas Organizações. Associado da Sociedade Brasileira de Dinâmica dos Grupos. Membro da entidade mundial “The Association of Supporte Professionals”. Palestrante sobre suporte téc-nico, Help Desk e Service Desk. Gold Member do Help Desk Institute norte-americano des-de 1996.

Esta obra é dedicada a todos os profissionais que dedicaram seu tempo para contribuir e com sua vasta experiência no tema Gerenciamento de Serviços de TI e motivar a sua discussão em todos os âmbitos, permitindo que ao longo de mais deste período de mais de cinco anos fosse possível consolidar um material extremamente rico para a comu-nidade.

Artigos Temperados com Opiniao �� 8Adoção da ITIL: Santo de fora de casa faz milagres? �� 9BYOD explodiu o CMDB� Já era essa ITIL! �� 10Demanda instantanea por alta capacidade �� 13Gerenciamento de Serviços de TI x Boas Práticas: Uma questão de hábito �� 14ISO 20000 atestado de melhores práticas? �� 16ITIL e Outsourcing Algumas peças ainda não se encaixam �� 17ITIL e satisfacão de clientes �� 20ITIL - O que não está nos livros? �� 22ITIL para Ingles ver �� 24ITILfobia �� 26Na prática: pessoas que fazem a diferença �� 28Os fora da lei – Porque é tão dificil seguir processos? �� 30Porque é tão dificil gerenciar os serviços de TI? �� 33Quando o vilão está dentro de casa �� 35Realmente precisamos de modelos e padroes? �� 37Seguranca da Informação e a arte de no dizer não �� 40

Artigos com Altos Índices de Teoria �� 41A eterna e incendiária briga entre a Gestão de Incidentes e de Problemas �� 42A importancia do Plano de Continuidade �� 44A relação entre ITIL e ISOIEC20000 �� 46Catálogo de Serviços – O desconhecido �� 48Como o BDGCCMDB pode aumentar a eficiência dos processos de suporte a serviços �� 51Compreendendo a ITIL a partir de uma perspectiva nada convencional um show de rock �� 53Do inferno ao céu – Como o exemplo do Corinthians pode ser utilizado na Gestão de Serviços �� 55Entenda a importância da classificação do Incidente �� 57Niveis de serviço tão necessários quanto inuteis �� 59O conhecimento é meu e ninguém tasca �� 61O que é Gerenciamento de Serviços de TI? �� 63Os 10 Mandamentos da ITIL �� 65Para que serve a ISO 20000? �� 69Principais diferenças entre a ITIL v2 e V3 Parte I �� 72Principais diferenças entre a ITIL v2 e V3 Parte II �� 74Serviços: a ponte perdida entre negócios e TI �� 78Sistemas de qualidade: a ilusão da melhoria continua �� 80USMBOK o ITIL para gerenciamento de qualquer serviço �� 82

Artigos para Aquecer a Carreira �� 83Certificaçoes abrem portas mas não garantem o seu emprego �� 84Redes Sociais: 5 erros a serem evitados no LinkedIN �� 85Tirei a certificação ITIL e agora? �� 87Vale a pena investir em certificaçoes profissionais? �� 90

Artigos Para Por a Mao na Massa �� 925 dicas para a Gestão de Problemas Proativa �� 935 passos para definir um bom Acordo de Nível de Serviço SLA �� 9525 dicas infaliveis para que seu projeto de implantação da ITIL seja um fracasso �� 98Catálogo de Serviços: Para que complicar? �� 100ITIL – é preciso saber vender �� 102

Pessoas: o calcanhar de Aquiles na adoção da ITIL �� 104Problemas – como identifica-los? �� 107Profissionalizando a gestão dos projetos de TI e ITSM Parte I �� 108Profissionalizando a gestão dos projetos de TI e ITSM Parte II �� 110Profissionalizando a gestão dos projetos de TI e ITSM parte III �� 112Tempo para solucionar problemas: mais um problema ou a solução? �� 115Transformando sua poltica de segurança da informação em um ativo estratégico �� 116

Artigos com toque de tecnologia �� 121A gamificação invadiu nossa praia �� 122ITSM, redes sociais e Content Management Systems dá jogo? �� 124O que as ferramentas não fazem por voce �� 126

Artigos Exlcusivos do Chef �� 128Os desafios da criação de valor atraves da Operação de Serviços �� 129O que são incidentes, problemas, erros conhecidos e requisiçoes de serviço segundo a ITIL? �� 130Gerenciamento da Configuração e Ativos de Serviço: o processo “camarada” da ITIL® �� 133Qual a diferença entre o Gerenciamento de Mudanças e o Gerenciamento de Liberação e Implan-tação? �� 135A ITIL é uma moda? �� 1364 métricas para monitorar o desempenho de uma CMDB (Configuration Management Database) �� 137O que é um Service Desk (ou Central de Serviços)? �� 139Tipos de Service Desk, qual o mais adequado? �� 140Melhores Práticas ou Boas Práticas, qual é o certo? �� 142O que é um Plano de Capacidade? �� 143A razão pelo qual um incidente não “vira” um problema �� 14510 coisas que voce deveria saber sobre a ITIL �� 146Compreendendo os principais conceitos do COBIT 5 �� 148

Artigos Temperados com Opiniao

9ITSM na Prática - O caviar de 5 anos de postagens


Adoção da ITIL: Santo de fora de casa faz milagres?GUSTAVO TAVARES

Como profissional de gestão de TI tive várias oportunidades de trabalhar prestando consultoria. Uma grande parte planejando e implementando iniciativas baseadas em ITIL®. Uma questão que inicialmente me deixava curioso era o porquê de as empresas preferirem optar por consultores a utilizar recursos internos. Curiosidade reforçada pelo fato de que, em quase todas estas oportunidades, encontrei nas empresas às quais prestei serviços pessoas qualificadas e bem preparadas para liderar iniciativas seme-lhantes. Aos poucos a experiência foi me ensinando e finalmente consegui algumas respostas que saciaram a minha curiosidade. São muitas as vantagens da utilização de consultores externos nas iniciativas de adoção da ITIL® (existem também algumas desvantagens), mas acredito que o ponto chave seja o seu posicionamento hierárqui-co na organização. Iniciativas de planejamento e adoção da ITIL® são, fundamental-mente, iniciativas de mudança organizacional. E um profissional externo, não ligado às estruturas e controles já existentes, possui maiores chances de obter sucesso em um processo de mudança organizacional. De forma resumida, poderíamos utilizar o velho adágio para questionar: Em iniciativas de adoção da ITIL®, santo de fora de casa faz milagres? Resumidamente a resposta é sim, desde que conte com o apoio dos santos da casa.

Isto porque a eficiência de consultores externos em iniciativas de adoção da ITIL® pos-sui limites. Os consultores são peças fundamentais por que possuem o conhecimento técnico necessário e a liberdade de opiniões e críticas que pode não existir dentro da organização. Entretanto, a responsabilidade pela tomada de decisões a respeito do desenho dos processos e de alterações nas estruturas é exclusiva dos gestores. Não cabe ao consultor escolher qual o melhor processo ou qual a melhor linha de subordi-nação de determinada função dentro da organização. O consultor não está inserido na cultura organizacional da mesma forma que o gestor para entender e diagnosticar as consequências deste tipo de alteração. Seu papel, neste caso, é orientar a tomada de decisão ressaltando os riscos e os benefícios de cada opção existente. Quem possui a responsabilidade de determinar os requisitos e sua relação com os objetivos de negó-cio deve ser alguém de dentro da própria organização.

O gestor, quando transfere a responsabilidade por estas decisões ao consultor, está na verdade se abstendo de determinar o modo de funcionamento de sua área de res-ponsabilidade. Corre com isto o risco de ser responsável por gerenciar algo com o qual não concorda ou mesmo não conhece. Situação onde o sucesso do novo processo ou da nova estrutura fica comprometido, afinal , sem apoio, “nem santo de fora de casa consegue fazer milagres!”



BYOD explodiu o CMDB. Já era essa ITIL!ROBERTO COHEN

Uma consequência da disseminação dos dispositivos móveis é que os funcionários ago-ra realmente acessam dados corporativos de tudo quando é canto. Na praia, no boteco, em casa etc.

Isso já é manjado, só é novidade pra quem ainda não acordou.

E as empresas tentaram entrar na onda oferecendo Blackberrys, iPhones e iPad (e seus similares) para os funcionários. Só que as tecnologias similares – ao alcance de com-pra dos próprios funcionários – começaram a ficar muito baratas. E com isso vieram as ondas da Consumerization e Gamefication. A última tentando obter proveito desse contato mais íntimo com os devices móveis para fazer os usuários aprenderem através de games (sei lá, pense no Show do Milhão ou Quem quer ser um milionário com per-guntas contextuais a um ERP, por exemplo). E a primeira, Consumerization, um olhar atônito sobre o usuário trazendo seu Mcbook de casa e tentando conectá-lo na rede corporativa da empresa.

Bom, a situação apertou (piorou) para o suporte técnico.

Do BYOD

Agora chegou o BYOD – Bring Your Own Device. Traduzindo, Traga Seu Próprio Devi-ce. Traga seu lanche, sua maçã e o seu dispositivo móvel de preferência pro serviço!

Ou seja, as empresas sacaram o seguinte: por que vou empurrar um Samsung Galaxy III se o sujeito manja tudo de iPhone e será muito mais eficiente nesse ambiente do que o obrigando a aprender outro modelo de smartphone?

Eu também não preciso dizer que isso se torna muuuito mais barato, em termos de in-vestimento de hardware, para a empresa, hehe. Outra vantagem é que, em vez das em-presas fazerem cotação para migrar do BlackBerry versão um para versão 10 (exemplo hipotético) depois de 4 anos, os usuários estão, por sua conta, fazendo isso todo ano e aproveitando as facilidades dos planos de pontuação das empresas de telefonia celu-lar. Ou seja, estando sempre up-to-date com os releases, livrando-se da, muitas vezes, lenta burocracia das empresas.

Se quiser ler mais sobre o BYOD, visite:

en.wikipedia.org/wiki/Bring_your_own_devicePCWorld – Pros and Cons of Bringing Your Own Device to Work

Pra terem uma ideia de como isso é novo, ainda não existe o verbete em português na Wikipedia. Eu não achei, pelo menos.



Opa, e as questões legais?

Aí o cachorro morde o próprio rabo. Num artigo muito interessante publicado no IT-Web, a jovem advogada Patrícia Peck Pinheiro aponta uma série de incômodos no Bra-sil relacionada a essa tendência de “Traga seu dispositivo para o serviço”:

De quem é a responsabilidade se o device contiver conteúdo ilícito?

O acesso 24×7 num dispositivo particular (do próprio funcionário) configura sobreavi-so e hora extra, pela ótica das leis trabalhistas?

Quem é o responsável pela segurança do dispositivo?

Perdas ou extravios do dispositivo, quem responde, a empresa ou o dono?

E a coisa vai longe, bro. Leia o artigo original no blog dela dentro do ITWeb: Questões legais do BYOD – a regra tem que estar clara

E o ITIL?

Caramba, e agora?

Como organizar o CMDB (Configuration Management Database)? Como construir um banco de dados de tudo que configura um determinado serviço quando nem sabemos qual o dispositivo que o usuário comprou e utiliza? E se o “maluco” migrou para a re-cém-lançada versão do iPhone? Ou do Xoom (tablet da Motorola)? Ou sabe-se-lá o que estará na moda amanhã…

A biblioteca britânica recomenda cadastrar tudo para encontrarmos rapidamente os pontos de defeito de um serviço, por exemplo. Mas como o técnico atenderá um usuá-rio que utiliza um browser que ele nunca ouviu falar na vida?

Eu sei que nós do suporte técnico poderíamos argumentar que:

O device do usuário não está cadastrado e nem homologado pelo suporte técnico e por isso sujeito a vírus;

Isso pode aumentar o custo de operação, por que não conhecemos o mesmo e vai ge-rar treinamento, atraso no atendimento etc.;

Uhhh, a lista é gigantesca para comentar…

Mais complicações “en aire“: e se o usuário pedir suporte para questões pessoais e não propriamente corporativas, como o suporte deve se comportar? O horror é saber que a maioria dos departamentos de suporte no Brasil não especificou ainda um catálogo de serviços que, por mais banal que fosse, ajudaria o técnico e usuário a saberem o que é ou não padrão ou ofertado como auxílio.

Ihhh, e se o usuário pedir demissão? Alguém limpará as informações e aplicativos ar-mazenados no smartphone dele?



Na real, foi-se pro espaço aquele controle que desejávamos fazer sobre os itens de configuração componentes de um serviço (Alguém viu o filme “Dama de Ferro“? Não é à toa que o ITIL lá nasceu, hehe).

Nossa, existe um blá-blá-blá imenso rolando na internet sobre isso. E, como é de cos-tume, ninguém sabe muito bem o que fazer, hahahaha.

Ambientes complexos

Ao ler esses temas, magneticamente sou conduzido ao livro Pensando diferente, para lidar com a complexidade, a incerteza e a ilusão.

A ideia central do Humberto Mariotti é que achamos que podemos controlar as coi-sas� Mas muitas (a maioria) não conseguimos.

Ele faz uma diferenciação didática entre sistemas complicados (um relógio é complica-do, cheio de pecinhas, mas conseguimos ter alguma precisão) versus sistemas comple-xos (aqueles habitados por seres humanos onde dificilmente podemos projetar com certeza o futuro para daqui a uma semana).

O Humberto está numa outra fase das teorias além dos sistemas sistêmicos (Peter Senge e organizações que aprendem é um dos expoentes máximos desse conceito). É importante compreender que ele não recomenda o abandono da objetividade, metas e gestão dos processos. Só que é importante incluir nisso tudo os conceitos de erro, incerteza e ilusão.

Por que escrevo isso, ainda mais se o título era outro?

Por que é preciso aceitar a incerteza. Não vai dar para programar tudo. A incerteza vai permear o primeiro nível de atendimento que não saberá como atender um Firefox para Android ou situações parecidas.

E o gestor deve e precisa saber o que fazer (ou, ao menos, pensar sobre) as situações que apresentam novos paradigmas contestando o bê-a-bá aprendido no curso de ITIL. E agora, Manoel, o que fazer?

Smack



Demanda instantanea por alta capacidadeRENÊ CHIARI

Compra de ingressos online, clubes de compras coletivas e leilões de um centavo. O que estes serviços tem em comum?

1. A disponibilidade é a razão de ser do negócio.2. Lidam com grandes demandas em frações de segundos.

A característica principal destes serviços é de manter o site disponível mesmo com avalanches de cliques simultâneos. Nem sempre dá certo…

Manter uma infraestrutura capaz de suportar altas demandas pode sair caro demais se considerarmos que estas demandas são esporádicas. Mesmo terceirizando, a dú-vida é se os provedores de serviço de outsourcing já estão preparados para esta novo conceito de prestação de serviços. Eu particularmente apostaria neste nicho de ser-viço, que eu tomei a liberdade de chamar de “Instantaneous demand for high capacity”, ou Demanda Instantânea por Alta Capacidade. Se o nome já existir, ótimo, acertei na mosca, caso contrário vou patentear! (uma busca no Google não trouxe nenhum resul-tado hehehe…)

Algumas recomendações da ITIL® fazem sentido, e até são aplicadas. Por exemplo a “pré-venda” de ingressos para um grupo seleto de clientes de uma instituição financei-ra já é uma forma de influenciar a demanda, mesmo sabendo que o objetivo principal neste caso é trazer novos clientes, aqueles que já não aguentam mais lidar com trava-mentos de site no horário em que as vendas começam para o público “normal”.

Os leilões de centavos procuram mesclar produtos de valores altos e baixo, em horá-rios distintos, inclusive de madrugada, para influenciar a utilização constante e justifi-car o investimento na infraestrutura.

Por outro lado, a falta de maturidade em gerenciamento de serviços de TI está eviden-te nestas empresas (e muitas outras da América Latina – veja uma análise de dados do Gartner aqui) . Basta fazer uma rápida busca em sites como o Reclame Aqui para en-contrar um grande número de reclamações de Clientes que clicaram mas não ganha-ram, ou que nem sequer conseguiram clicar, pela indisponibilidade dos sites. Também existem reclamações sobre a transparência e credibilidade dos sites, mas isso é assun-to pra abordar em outro post.

Vale lembrar que a intenção deste e possíveis outros artigos não é de colocar em dis-cussão se estes são modelos de negócio bons ou ruins, confiáveis ou não. São modelos que estão ai a pleno vapor e podem influenciar a discussão de novas abordagens para gestão de TI.



Gerenciamento de Serviços de TI x Boas Práticas: Uma questão de hábitoALBERTO ANDRADE

Quando o assunto é Gerenciamento de Serviços de TI, a ITIL frequentemente apresen-ta-se como um “herói invisível”, raramente reconhecido como tal. O entendimento do framework como referência de boas práticas ainda é interpretado de forma equivoca-da por muitos profissionais que buscam em sua aplicação a solução de todos os seus problemas e frustram-se nas primeiras dificuldades de implementação, justamente por esta falha de entendimento.

Algo que ainda ouço com muita frequência são afirmações quanto à impossibilidade de aplicar as ditas “boas práticas” em cenários de produção. Igualmente comuns são aqueles que asseguram que a ITIL não tem utilidade real, o que reflete a visão limitada de muitos profissionais de TI e áreas relacionadas. Independente do cargo ou ativida-de, o que se deve ter em mente é que uma biblioteca de boas práticas segue o caminho inverso frente às metodologias tradicionais. É tudo aquilo que já foi eficiente no mer-cado e vem como sugestão de uso, por isso não é um conjunto de regras pré-estabele-cidas. Estas propostas nada mais são do que indicações perfeitamente adaptáveis de milhares de outros como nós que já percorreram o mesmo caminho e nos indicam as pedras para que não tropecemos, afinal de contas, quem quer reinventar a roda? Ge-ralmente quando um profissional com histórico de resultados satisfatórios depara-se com a ITIL®, sua primeira percepção é: “Isso tudo me parece muito familiar...”. Oportu-namente, pois foram reunidos muitos comportamentos e atitudes comuns e estes fo-ram nomeados e categorizados como processos, subprocessos e assim sucessivamen-te.

Veja o bullying, por exemplo. Esta palavra que, confesso, tive que recorrer ao Google para não falhar na grafia, nada mais significa do que os velhos atos de violência física e psicológica que muitos de nós sofremos na infância. É antigo, só não tinha nome, cada um chamava como queria (e eu sinceramente queria esquecer!). O mesmo ocorre com a ITIL®. Muita gente torce o bico, mas pratica (mesmo contra a própria vontade) todo dia. Compare com a nossa própria vida. O ser humano, em sua individualidade possui uma série de comportamentos, bons e ruins, comuns no seu cotidiano. Imagine uma biblioteca de boas práticas como um conjunto de diretrizes contendo instruções que você já exercita e outras que pode começar hoje. O sucesso não está necessariamente atrelado a pratica de todo o conteúdo destas “sugestões” e sim do uso que se faz delas. Você pode não exercitar-se, nem se alimentar bem hoje, mas sabe que é bom pra você. Se trouxer pra rotina, terá muitos ganhos. Se não trouxer, não significa necessariamen-te que irá morrer amanhã (assim espero!!!).

Portanto, boas práticas de mercado, muito mais do que mudança estrutural, exige mu-



dança de cultura e comportamento. É benchmarking, tomando referência de tudo o que funcionou e poderia igualmente funcionar em sua rotina. Desta forma, se a maio-ria dos processos é familiar a você mesmo que você nunca tenha estudado a biblioteca parabéns, provavelmente já esteja no caminho certo. Por outro lado, se não conseguir agregar nenhum destes bons frutos à sua rotina, pode ser a hora de uma quebra de paradigma. Independente do nome que se dê, bons hábitos sempre trazem benefícios e isso é indiscutível, pois, assim como afirmou Aristóteles, “somos aquilo que fazemos repetidamente, desta forma, excelência é um hábito.”



ISO 20000 atestado de melhores práticas?RENÊ CHIARI

A norma ISO/IEC 20000 foi lançada em dezembro de 2005, sendo a primeira norma ISO voltada exclusivamente para gerenciamento de serviços de TI.

Os requisitos da norma estão totalmente alinhados ao ITIL®, e em alguns momentos chegam a deixar mais claros alguns aspectos. Além disso, ela aborda temas como re-sponsabilidades da direção de forma mais incisiva (herança da ISO 9001).

Em fevereiro de 2008, a ABNT lançou a versão brasileira da norma, que tem o mesmo conteudo.Desde então, muitas empresas iniciaram a busca pela certificação.

Atualmente, de 12 a 15 empresas brasileiras possuem a certificação (não sei pq, mas o site oficial www.isoiec20000certification.com não possui informações atualizadas...).

Há uma estimativa de que em 2010, 80% dos grandes e médios provedores serão cer-tificados e várias organizações clientes estarão certificadas, enquanto 2011 será o ano da maturidade. Certificar não será mais um diferencial e sim um requisito de mercado (Fonte: consultoria Brunise).

É certo que a conquista do selo ISO 20000 tem o foco voltado principalmente para dif-erencial de mercado, melhora da confiança por parte dos investidores, satisfação dos clientes, etc...mas é possível também utilizar-se da norma como referência de quali-dade para a implantação do ITIL®, e de certa forma, atestar o sucesso da implantação, mesmo que a certificação oficial não seja almejada.

Ainda que para os céticos seja apenas mais uma moda do mercado, e que a conquista do selo não é garantia de qualidade, as empresas serão motivadas a “engrenar” e mant-er a qualidade, uma vez que as constantes manutenções da certificação obrigarão elas a agir desta forma.



ITIL e Outsourcing Algumas peças ainda não se encaixamRENÊ CHIARI

A ITIL®, apesar de ser uma das melhores referências para gestão de serviços de TI, nos deixa com vários pontos de interrogação quando abordada em um ambiente de provedores de Out-sourcing. Na verdade, a biblioteca tem um foco muito forte em organizações internas de TI, e por isso essa “lacuna”.

Recentemente fiz algumas buscas em foruns e sites sobre essa questão e descobri que não estou sozinho, e que muita gente que trabalha ou trabalhou em provedores de Outsourcing têm problemas em adequar a ITIL® neste ambiente.

Algumas das principais dificuldades apontadas são:

Processos Fim-a-fim

A ITIL® pressupõe que você tenha controle sobre todos os serviços, mesmo quando você tenha um fornecedor terceiro. Em Outsourcing geralmente existem pelo menos dois stakeholders (a TI interna do Cliente e o fornecedor de outsourcing).

Mas geralmente existem outros fornecedores e parceiros de outsourcing e uma prá-tica comum é dividir a prestação de serviços para a infra-estrutura e aplicações entre dois diferentes fornecedores.

Em situações como esta, mesmo que todos adotem ITIL®, terão sua própria adaptação dos processos, incluindo os seus próprios instrumentos, procedimentos, relatórios e gerenciamento de dados.

Isto representa um enorme potencial de conflito, pois mesmo que o cliente tenha espe-cificado o alinhamento com a ITIL® como um pré-requisito para o outsourcing, é muito difícil quando se trata de Gestão de Incidentes, Problemas e Mudanças. Por exemplo, um usuário liga para um Service Desk terceirizado, que registra um incidente na ferra-menta XPTO, que compõe a sua solução de ferramentas integradas de ITSM.

O usuário acredita que é um problema de infra-estrutura e então o incidente é atribuí-do à equipe de suporte a infra-estrutura terceirizada. Na realidade o incidente acaba por ser um erro de aplicação - portanto um chamado tem que ser registrado junto ao provedor de aplicações terceirizado, que utiliza o XYZ em sua solução integrada de ITSM.

Na transferência, os detalhes se perdem e o provedor de aplicações tem que chamar o usuário para fazer mais perguntas. O tempo de resolução do incidente é ultrapassado, e quem é o responsável por isso? Quem é o “dono” do processo fim-a-fim?

A solução para este problema deve ser uma estrutura de governança cuidadosamente



planejada e implementada que assegura que todos os fornecedores trabalhem juntos de uma maneira eficaz. A ITIL® V3 deixou claro no livro de estratégia de serviço que a responsabilidade de fazer isso cabe ao Cliente.

A menos que seja nomeado um contratado para sub-contratar todos os outros forne-cedores, o único ponto consistente de governança deve ser o próprio Cliente. Isso pre-cisa ser desenvolvido na estratégia de terceirização e gerenciado desde o início.

Onde está o meu Cliente?

Todos os processos de entrega de serviços da ITIL® supõe que você tenha um cliente comercial para trabalhar, mas muitos são os contratos de terceirização com o departa-mento de TI da organização do cliente.

Essa relação com um outro provedor de TI afeta muitos aspectos da prestação de ser-viços, mas especialmente em SLM, onde o conceito de SLA “baseado no negócio” é mui-tas vezes rejeitado por um contrato negociado por uma equipe de TI que é muito téc-nica / baseada em OLA. Como um fornecedor de outsourcing, só podemos esperar que o provedor interno de TI tenha vigente com os seus cliente internos um bom processo de SLM.

Outro aspecto é que o SLM é difícil de implementar em um ambiente comercial. Ele simplesmente não leva em conta as pressões comerciais para ‘ganhar’ o negócio.

Ligando ao ponto sobre como lidar com os departamentos de TI, isto pode significar também que os objetivos não são ainda ligados aos requisitos reais de negócio. Este tipo de má gestão das expectativas do cliente leva a sérios problemas mais tarde.

Três outros processos especialmente demandam o envolvimento ativo de Clientes de negócio: o Gerenciamento de Capacidade de Negócio, o planejamento da continuida-de do negócio e a análise de impacto sobre a empresa no Gerenciamento de Mudan-ças, respectivamente.

A solução para isso não é tão clara. Uma compreensão realista da maturidade do seu cliente, papéis funcionais e estruturas podem ajudar a identificar potenciais proble-mas. Além disso, mais esforço e empenho durante a transição para definir claramente o nível de envolvimento do cliente de negócio também vai ajudar.

A ITIL® V3, infelizmente, não oferece muita ajuda sobre este problema específico. So-mente com o claro entendimento de com quem você está lidando, e quais são suas necessidades o que ele quer irá suporta-lo, e talvez, esquecendo o SLM e procurando ajuda no Gerenciamento de Fornecedores como guia.

ITIL® é ITIL® em todos os lugares, mas ninguém entende

Muitas licitações citam a ITIL®, incluindo processos pro-ativos e de planejamento, como o Gerenciamento de Problemas Pró-ativo, Gerenciamnto de Disponibilidade e



Capacidade, mas atualmente não há um bom entendimento do que isso realmente sig-nifica.

Isto se reflete de várias formas, mas normalmente em um simples “copy and paste” de parágrafos da bibilioteca, incluindo KPI´s dos quais são transformados posteriormen-te em metas, com multas associadas.

O problema surge quando aqueles que escrevem a proposta comercial e aqueles que lêem o fazem com (no máximo) um conhecimento teórico do ITIL® e pouca compreen-são dos verdadeiros problemas associados à criação, desenvolvimento, gestão e medi-ção de tais processos.

Um exemplo comum é o requisito para estabelecer o gerenciamento de configuração com uma meta de 100% de exatidão no primeiro dia de prestação de serviços; isso em uma organização que não tenha qualquer atividade vigente de Gerenciamento de Configuração. No mundo real, leva-se de 6 a 12 meses para implementar e adequar um processo de gerenciamento de configuração eficaz, que requer um considerável inves-timento inicial e quase nunca entrega tudo com 100% de precisão.

Outro exemplo são as “produtizações” de processos ITIL®. Não é raro encontrar ser-viços onde o cliente precisa pagar para ter gestão de capacidade, sendo que esta ati-vidade intrinsicamente já deveria estar sendo coberta como um requisito básico de qualidade e entrega de serviços.

Adicionalmente, a maioria dos processos de planejamento ou estratégicos tem foco em investir para melhorar, ao invés de pagar por falhas. As implicações do mal compreen-dimento disso é das organizações verem o Outsourcing puramente como redução de custos.

Novamente, a solução para esta questão não é fácil, e a ITIL® V3 não apresenta res-postas simples. O segredo é a educação e formação para todos os envolvidos, tanto o cliente quanto o fornecedor, de modo que os motivos pelos quais a relação de terceiri-zação está sendo baseada sejam claramente compreendidos.

Conclusões

A boa notícia é que a V3 está muito mais clara, com uma abordagem mais integrada de gestão de serviços, já está reconhecendo muitas das dificuldades identificadas na V2 e sugerindo soluções. Maaas, cuidado...a ITIL® (mesmo a V3) não é uma referência a ser utilizada isoladamente. O sua utilização em um ambiente de Outsoutcing deve ser adaptada cautelosamente. Podemos usar ITIL® V3 para ajudar, mas há muito mais educação e formação necessárias a todos!



ITIL e satisfacão de clientesCLAUDIA MARQUESANI

Parece uma frase bastante pessimista para quem tem um site chamado ITIL® NA PRÁTICA , mas tenho realmente que ser realista: IMPLEMENTAR A ITIL® NÃO GARANTE A SATISFAÇÃO DO CLIENTE. Pelo contrário , dependendo do grau de insucesso, pode até influenciá-la negativamente! Utilizamos tanto a palavra ALINHAR A ESTRATÉGIA DE TI À ESTRATÉGIA DE NEGÓCIO, que realmente estou até cansada (e o mercado também!) de falar disso. Por isso resolvi brincar um pouco hoje!

Qualquer semelhança com a PRÁTICA é uma mera coincidência��rsrs

Tantas e tantas vezes as melhores práticas são implementadas sem levar em conta a estratégia de negócio e as características da organização , que realmente a cena acima não é irreal! O que devemos fazer então para que a implementação da ITIL® seja um sucesso e traga valor para o negócio?

OUÇA (REALMENTE) O CLIENTE�

Sim, eu sei que é difícil� Mais que ouvir, é preciso conhecer o seu negócio, ENTENDER o que ele está dizendo , infuenciar positivamente as tomadas de decisão... Não é uma tarefa fácil, mas por isso que foi feita especialmente para os profissionais envolvidos no gerenciamento de serviços de TI!!! :D

ADOTE E ADAPTE as melhores práticas ás necessidades da sua organização e ouça seu cliente para montar a estratégia dessa adaptação.

Para finalizar (como estamos de bom humor hoje), uma piadinha para descontrair... es-pero que gostem.

A VOZ DO CLIENTE

No aeroporto o pessoal estava na sala de espera esperando a chamada para embarcar. Apa-rece então o Co -piloto, todo uniformizado, de óculos escuros e de bengala, tateando pelo caminho. A atendente da companhia o encaminha até o avião e assim que volta, explica que, apesar dele ser cego, é o melhor Co-piloto da companhia.

Alguns minutos depois, chega outro funcionário também uniformizado,de óculos escuros, de bengala branca e amparado por duas aeromoças.

A atendente mais uma vez informa que, apesar dele ser cego, é o melhor piloto da empresa e, tanto ele quanto o Co-piloto fazem a melhor dupla da companhia.

Todos os passageiros embarcam no avião preocupados com os pilotos.

O comandante avisa que o avião vai levantar vôo e começa a correr pela pista, cada vez com mais velocidade. Todos os passageiros se olham, suando, com muito medo da situação. O



avião vai aumentando a velocidade e nada de levantar vôo. A pista está quase acabando e nada do avião sair do chão. Todos começam ficar cada vez mais preocupados. O avião cor-rendo e a pista acabando. O desespero toma conta de todo mundo.

Começa uma gritaria histérica no avião.

Nesse exato momento o avião decola, ganhando o céu e subindo suavemente.

O piloto vira para o Co-piloto e diz:

- Se algum dia o pessoal não gritar, a gente tá F... (tradução: ferrado)!!!!!!

Moral da história:

OUVIR OS CLIENTES É FUNDAMENTAL!!!



ITIL - O que não está nos livros?GUSTAVO TAVARES

Embora seja promovido como o padrão “de facto” para as operações de TI, muitas são as dúvidas a respeito da eficiência e do sucesso na adoção da ITIL® nas organizações. E isto não sou eu quem está dizendo. Uma das maiores consultorias mundiais espe-cializada nas boas práticas já fez reclamações a respeito. Particularmente, apesar de não contar com informações para comprovar, eu apostaria que mais da metade das iniciativas de adoção da ITIL® no Brasil não obtém o sucesso esperado. Isto a despeito de serem realizadas por profissionais com certificação de fundamentos, praticante ou gerente (foundations, practitioner e manager).

A razão dos insucessos? Eu não saberia responder ao certo. Mas acredito que um fator em específico tem um peso muito grande. E é a este fator que o post esta relacionado.

A ITIL® passou por uma evolução recente. A versão anterior (2) era focada exclusiva-mente nas operações de TI. Embora quando considerado em seu total ela contemplava uma análise geral da área de TI das organizações, na prática do mercado ela se con-centrava na entrega e no suporte aos serviços de TI; atividades exclusivas da parte de operações. A evolução para a versão corrente (3) trouxe uma reorganização das áreas de conhecimento. Reforçando a intenção inicial de contemplar a visão geral da área de TI, ela chegou a estender o modelo para as áreas de posicionamento e formulação das estratégias. Embora as duas versões possuam grandes diferenças, ambas possuem também um conjunto de características fundamentais. E uma destas características é que as duas versões são baseadas em processos. Apesar de a versão corrente possuir uma orientação para o ciclo de vida dos serviços, ela ainda tem como base os proces-sos de TI.

Por ser baseada em processos, a adoção da ITIL® é um pouco mais complexa do que é descrito nos livros e ensinado nos cursos de formação. A implementação de processos em um ambiente de TI ou “de negócios” demanda uma ecologia organizacional que dif-ere da ecologia tradicional. Os comportamentos, sistemas de recompensa e estruturas tradicionais são, na maioria das vezes, incompatíveis com as práticas necessárias para gerenciar processos. Por tradicional – no sentido deste post – podemos entender as estruturas funcionais departamentalizadas e baseadas em uma hierarquia claramente definida.

Apesar da própria literatura reconhecer a necessidade de um ambiente que favoreça a adoção de processos (Service Strategy, seção 2.6), as implementações baseadas na ITIL® quase sempre partem do princípio que a ecologia organizacional necessária para implementação e gerenciamento de processos existe e esta madura na organização destino. O que eu acredito ser, na realidade Brasileira, uma raridade.

Com estas considerações é importante ressaltarmos que: antes de implantar o geren-



ciamento dos serviços de TI baseado na ITIL® a organização deve necessariamente ser fluente em gestão de processos. Ela deve possuir uma ecologia organizacional re-ceptiva as práticas de gestão de processos, o que quer dizer uma estrutura organiza-cional adequada, sistemas de recompensa que reforcem os objetivos dos processos e um modelo de gestão com os estilos adequados.

É verdade que a ecologia organizacional e as práticas aqui denominadas tradicionais não impedem sempre a implementação de modelos de gerenciamento de serviços de TI baseados na ITIL®. Processos conseguem, em situações particulares, serem imple-mentados e gerenciados neste tipo de ambiente. Mas somente em situações particu-lares e onde, principalmente, as especificidades deste tipo de ecologia organizacional são consideradas no projeto de implementação.

Para quem busca mais informações a respeito da ecologia organizacional adequada à adoção de processos, sugiro uma olhada no Business Process Maturity Model – BPMM. É um modelo de maturidade, baseado no CMM, que busca medir a capacidade de or-ganização de utilizar processos.



ITIL para Ingles verGUSTAVO TAVARES

Hoje é mais raro. Mas ainda acontece. Planeja-se uma iniciativa para adoção de ITIL®, monta-se uma equipe, iniciam-se os trabalhos e alguém fala: “Este negócio de ITIL® é só para Inglês ver! Aqui na nossa empresa não funciona!”... E depois de escutar estas afirmações, se considerarmos os resultados obtidos por grande parte das empresas, acabamos ficando desconfiados se isto não seria verdade.

Como profissional com alguma experiência em iniciativas de adoção do ITIL®, eu posso afirmar que estes posicionamentos não são totalmente verdadeiros. E a palavra chave aqui é “totalmente”.

Como é de conhecimento de quase todos os profissionais que conhecem o ITIL®, sua origem é Britânica. A motivação inicial ainda está sob a névoa das lendas. Algumas dizem que está relacionada com a Guerra das Malvinas, outras dizem que tudo foi ap-enas uma idéia muito boa de uma equipe melhor ainda. Mas é certo que o ITIL® sur-giu na terra do Rei Arthur, do Beckham e do Harry Potter. E como não podia deixar de ser, acabou trazendo o que a Inglaterra tem de bom e também o que tem de mau. Eu particularmente não sei dizer que existe de ruim na Inglaterra, e também não sei o que tem de bom além da Keira Knightley e da Guinness; mas sei que a Inglaterra e o Brasil são países bem diferentes.

Mas apenas saber que são diferentes não é o suficiente. Nós, profissionais que tra-balhamos com gestão de TI, precisamos saber em que ponto estes países são difer-entes e como isto impacta as iniciativas de adoção do ITIL®. Em minha defesa como profissional, posso dizer que apesar de não saber quais são todas as diferenças eu sei quem sabe.

Em um post recente do meu blog particular eu indico um livro muito interessante para os profissionais que trabalham com ITIL®. O livro é do professor Geert Hofstede que entre 1967 e 1973 realizou uma pesquisa com empregados de 70 países da IBM. A partir desta pesquisa, ele desenvolveu um modelo de cultura organizacional dividido em cinco dimensões; que possibilita comparar como as pessoas de um país compreen-dem e respondem a diversas iniciativas gerenciais.

O modelo é direcionado às populações dos países. Não é um modelo para ser aplicado a diferentes organizações de um mesmo país. Ele busca diagnosticar quais valores e com-portamentos uma população entende e aceita como normal. Um deles, a dimensão de distância hierárquica, por exemplo, busca demonstrar o quanto as pessoas percebem como é válida a distribuição desigual do poder. Em países com alta distância hierárqui-ca um subordinado está menos propenso a questionar ou discutir as determinações de um superior. O subordinado interpreta que uma pessoa hierarquicamente supe-rior é melhor ou mais capacitada simplesmente pela sua posição. Por outro lado, em



países com baixa distância hierárquica, as pessoas acreditam que o poder não deve ser distribuído apenas pela posição no organograma. Elas consideram que outros fatores como capacitação, perfil, tempo de casa são também fonte de poder. São também mais propensas a questionar e discutir as ordens vindas de escalões superiores e acreditam que não existe nada de errado com esta atitude.

As outras dimensões são igualmente importantes na avaliação das culturas de difer-entes países. A dimensão masculinidade, por exemplo, mede o quanto os valores mas-culinos são mais relevantes que os valores femininos na população de um país. E por valores masculinos devemos entender a competição e o confronto. Por outro lado de-vemos entender os valores femininos como a colaboração e a confraternização. Um país com alto índice de masculinidade não quer dizer que existem mais homens ou mul-heres no mercado de trabalho. Quer dizer apenas que os homens e mulheres deste país ou região são mais direcionados à competição e ao confronto do que à colaboração e à confraternização.

Como é de se esperar, os índices apresentam valores diferentes para o Brasil e para a Inglaterra. Estes valores diferentes devem ser observados com cuidado pelos profissio-nais que buscam liderar iniciativas de adoção do ITIL®. Quais aspectos do framework dependem de um baixo índice de distância hierárquica? Quais iniciativas do ITIL® são baseadas em um índice alto ou baixo de masculinidade? Quais as outras dimensões do modelo do professor Hefstede devem ser consideradas? Quais adaptações ao frame-work são necessárias para ressaltar os pontos fortes da cultura Brasileira?

Quem sabe com estas preocupações nós que trabalhamos com ITIL® não façamos do framework também “um negócio para Brasileiro ver!” :)



ITILfobiaRENÊ CHIARI

Quem já participou de um projeto ou iniciativa de adoção da ITIL® sabe bem que a foto ao lado ilustra muito bem um dos maiores desafios durante a implementação: a RESISTÊNCIA!

Não importa qual o segmento da empresa, seja instituição pública ou privada, a reali-dade é exatamente a mesma. Quando há necessidade de uma mudança organizacional (e para adotar o ITIL®, geralmente é necessária essa mudança), somos recebidos com flechas!

O principal motivo que alavanca essa reatividade é o medo das pessoas em perderem posições cômodas, de não ter mais o controle individual e intelectual das informações, de ter que “zerar” todo o conhecimento adquirido, e de um dia para o outro, se deparar com uma nova realidade e uma nova forma de fazer as coisas.

Para tentar lidar com este desafio, podemos utilizar uma formula de Administração, mais precisamente de Peter Drucker: M = D + M + P > R

Onde podemos interpretar:

M=> Mudança (a necessidade de mudar)D=> Desconforto (eventos adversos, insatisfação dos Clientes, etc)M=> Modelo (qual o modelo proposto, por ex: ITIL®, CobiT, etc)P=> Plano/Projeto (qual o plano para implementar este modelo)R=> Resistência (o grau de resistência das pessoas envolvidas na mudança)

Note que a soma de D + M + P deve sempre ser maior que R. Se em um determinado momento notar que a resistência é maior, está na hora de elevar o grau dos itens prec-edentes, de preferência da direita para a esquerda, por exemplo:

P=>Revise o seu plano/projeto, pode ser que algo não foi bem definido, o plano de co-municação não está sendo eficiente, etc

M=> Reveja o modelo proposto. Será que somente ITIL® resolve tudo? Talvez seja necessário utilizar-se de outras práticas como CobiT, ISO 20.000, BSC..

D=> Esta é a última opção, se nenhuma das anteriores funcionar, gere desconforto. Se necessário , é preciso entender que as reclamações do cliente podem aumentar no primeiro momento (como na implementação de um Service Desk) , mas o COMPROM-ISSO GERENCIAL DEVE SER MANTIDO. Como na figura, se aos poucos os envolvidos pararem de remar, o barco nunca chegará ao seu destino.

Encarar de frente este desafio e MANTER O COMPROMISSO COM O PROJETO EM TODOS OS NÍVEIS GERENCIAIS é um dos fatores críticos de sucesso de uma mudança



organizacional. Implementar ITIL® não é um projeto com início , meio e fim. É uma catequese e um programa de melhoria constante, como a própria biblioteca diz: P-D-C-A (Planejar, Fazer, Checar e Agir)�



Na prática: pessoas que fazem a diferençaRENÊ CHIARI

Recentemente recebi um e-mail com o título: “Nova Era do Radar em SP - Atenção !!!”, que descrevia em detalhes os locais em São Paulo onde os novos radares serão insta-lados. A frase final me chamou a atenção:

“Retransmitam, é duro trabalhar para sustenter mais isso!!”

O mais engraçado é que as pessoas criam uma grande mobilização para “burlar” siste-mas de segurança ao invés de fazer o que tem que ser feito, que nesse caso seria sim-plesmente respeitar a leis de trânsito vigentes!!

Em nosso mundinho quadradinho de TI aconteçe o mesmo. Vários controles são cria-dos exclusivamente para identificar se as pessoas estão fazendo o que devem fazer. Uma tremenda perda de tempo que poderia ser gasta com coisas mais produtivas e com valor agregado ao negócio.

Um exemplo clássico são as auditorias. Nada contra auditores e nem contra as ISO´s, mas vamos combinar, da pra contar nos dedos o número de empresas que realmente tem uma cultura madura em relação a isso. As ISO´s deveriam ser uma referência para nortear a qualidade ideal para as empresas e serem vistas como uma forma de identi-ficar o que não está bom e melhorar (os radares tem o mesmo objetivo, não?) mas na realidade elas são utlizadas basicamente para dois fins:

• Aparecer em formato de selo no site institucional da empresa;• Apavorar funcionários mal orientados em épocas de auditoria.

A cena é sempre a mesma: dado o anúncio de uma auditoria interna, todos correm como loucos atrás de disponibilizar evidências de seus trabalhos, com o único objetivo de não ter nenhuma não conformidade, e assim “burlar” o sistema de auditoria. Se per-guntarmos pra maioria qual o real motivo dos controles, poucos saberão responder.

Um outro exemplo. Um palestrante certa vez contou sobre uma montadora de carros que anualmente abria as portas para que todos (inclusive os concorrentes) conheces-sem seus processos, políticas, sua forma de trabalhar. Um visitante questionou se aq-uilo não poderia oferecer algum risco à empresa. A resposta foi mais simples do que se podia imaginar: vocês podem copiar nossos processos, nossa forma de trabalhar, mas será difícil fazer acontecer se os seus funcionários não tiverem o mesmo comprometi-mento que nossos funcionários tem.

Talvez valha mais a pena investir em concientização, em pessoas com perfis adequa-dos as suas atividades, em metas individuais alinhadas a ganhos financeiros para os funcionários que atingirem suas metas, a automatização de processos a fim de evitar erros humanos, do que em projetos voltados exclusivamente a auditar o trabalho dos



outros.

Ao mesmo tempo, provavelmente valha mais a pena andar na velocidade permitida do que gastar dinheiro com equipamentos anti-radares e até mesmo perder a vida pisan-do muito no acelerador. Essa é uma questão que tem uma abrangência muito além de gestão de serviços e governança. É uma questão cultural!!

Investir em processos, controles, e sistemas são importantes, mas no final das contas, pessoas é que fazem diferença...



Os fora da lei – Porque é tão dificil seguir processos?CLAUDIA MARQUESANI

Hoje estou com uma incrível crise existencial. No meio de uma grande revolta, comecei a pensar : PORQUE EU DESENHO PROCESSOS E AS PESSOAS NÃO OS SEGUEM? É uma cultura do brasileiro? Será que lá fora é assim? Será que o objetivo é ficar “livre-leve-solto”? Será que achamos interessante ser “fora da lei”? Nossa cultura não gosta das “amarras” de um processo? O que será que acontece?

Vamos falar um pouco sobre PROCESSOS hoje e porque é tão difícil segui-los. Um as-sunto polêmico, mas é gerando polêmica que evoluímos...

Antes de mais nada, vamos definir o que é processo. Dentre várias definições, aí vai uma simples e direta: “Processo é uma sequência de tarefas (ou atividades) que ao ser-em executadas transformam insumos em um resultado com valor agregado.”

E pra que criamos processos?

• Para garantir a retenção e pulverização de conhecimentos individuais;• Para controlar e monitorar as atividades, podendo identificar os pontos de melho-

ria;• Para garantir que todas as atividades necessárias sejam desempenhadas para a

entrega do produto final de acordo com os critérios de qualidade estabelecidos;

Tudo isso em teoria...porque na PRÁTICA...salve-se quem puder!!!!

São procedimentos operacionais que incorretamente recebem o nome de processo e ninguém consegue enxergar o SERVIÇO por trás daquele documento enorme...

São processos “fracos”, onde seus participantes em determinado momento pensam: para que serve tudo isso mesmo que eu estou fazendo?

Aqueles processos que “lembramos” vagamente que existem...mas que nunca lemos , entendemos ou participamos a fundo. Normalmente executamos atividades realiza-das nesse processo, no “piloto- automático”, sem ter a visão do todo, dos requisitos de qualidade e de controles do necessários.

Esse tipo, muito comum e o pior de todos, é chamado de PROCESSO PARA INGLÊS VER!

O que é isso? Todos sabem que ele está lá, mas todos preferem ignorá-lo até o dia em que uma auditoria ou outra verificação do dia a dia é anunciada. Nesse momento, “O INGLÊS”, precisa ver e tudo é feito as pressas para atendê-lo. Não faz parte da cultura, não faz parte do dia a dia, faz parte de um evento isolado e distante daqueles que real-



mente deveriam entendê-lo e segui-lo.

Vou dar um exemplo, completamente fora de TI para ilustrar o que escrevi anterior-mente. Toda segunda-feira, é apresentado no Canal National Geografics, um programa chamado MAYDAY. Podem me chamar de “doente” (rsrs), mas ele trata dos principais acidentes aéreos da história da aviação mundial. O que isso tem a ver com nosso dia a dia? O processo de investigação, que mostra porque os acidentes aéreos acontecem é um verdadeiro aprendizado para quem trabalha com serviços. Falhas, são, quase sem-pre causadas por processos que poderiam ter sido melhor desenhados para evitar er-ros humanos.

Em um dos programas do mês passado, foi apresentando um acidente, onde um avião, decolou e minutos depois, o vidro da cabine estourou. O piloto foi arremessado para fora do avião e ficou preso durante 20 minutos voando com o corpo para fora da aeronave. Ele milagrosamente sobreviveu (isso nem a ITIL® explica!) . Dois tripulantes morre-ram e todos os outros passageiros (fora o susto) se salvaram após um pouso forçado.

Vários investigadores renomados foram chamados para entender porquê o vidro hav-ia estourado. Após muitas avaliações técnicas e psicológicas, finalmente descobriram.

Resumindo:

O avião tinha passado por manutenção dois dias antes e vidro da cabine havia sido substituído. E a história é longa...

Para substituir o vidro, o mecânico deveria ir até o computador, consultar o tamanho do parafuso que fixaria o vidro, buscar os parafusos corretos no estoque e utilizá-los para fixar o novo vidro na aeronave.

Sabem o que o mecânico fez ao envés de seguir esse passo a passo? Comparou o parafu-so que ele retirou do vidro que estava sendo trocado e pegou um de tamanho igual que já havia em sua oficina. Infelizmente, o parafuso que esteve fixado durante muito tempo no avião, tinha tamanho incorreto para aquele tipo de aeronave. O problema só não tinha ocorrido antes, porque o parafuso estava muito bem fixado. Ao troca-los, o mecânico estava em uma posição desconfortável e deixou frouxos aqueles parafusos que não tinham o tamanho adequado. Resultado: 5 minutos após a decolagem eles se desprenderam e causaram o acidente.

O investigador perguntou porque o mecânico não havia ido até o sistema consultar o código para selecionar os parafusos corretos para a troca. Ele obteve a seguinte res-posta: “o sistema é lento, levaria aproximadamente 20 minutos para fazer a consulta. Eu tinha que entregar a aeronave para o vôo até as 6 horas da manhã do dia seguinte. Não daria tempo de seguir um processo tão burocrático e ao mesmo tempo cumprir minhas metas”.

Depois disso, foi fixado o código de todos os parafusos nas mesas dos mecânicos, para



evitar que problemas como esses voltassem a acontecer.

Moral da história: por mais que o processo seja bem desenhado, se ele não for funcion-al, esqueçam! Eles devem estar adequados as necessídades do NEGÓCIO (no caso, agilidade para trocar o vidro com a máxima segurança). Também devem estar bem di-vulgados e devem ser redivulgados constantemente...

Pensando bem, será que a “culpa” de processos que nunca são seguidos e de serviços prestados com baixa qualidade, não está nas mãos de quem desenha os processos, di-vulga e deveria patrociná-los (nossos gestores) ??? Quem são os verdadeiros “fora-da-lei” aqueles que não sabem ouvir e desenhar o que é necessário, aqueles que não di-vulgam adequadamente aquilo que necessita ser seguido ou aqueles que se recusam a seguir algo que é totalmente burocrático e sem sentido? Pensem nisso...



Porque é tão dificil gerenciar os serviços de TI?CLAUDIA MARQUESANI

Um aluno meu do curso de manager me disse uma frase que acabou virando este post… ele disse: “Quando a TI perceberá que não vale a pena fazer milagres? Tudo que o negócio pede a TI se mata para entregar, quase sempre sem planejamento e a qualquer custo…”

Vamos falar um pouco sobre isso…

Quem é o cidadão que trabalha com TI que nunca se sentiu em uma pastelaria, en-tregando pasteis do sabor que o cliente quer, quando quer (mesmo que o oleo não es-teja na temperatura correta para deixar um pastel crocante) , inventando sabores de ultima hora a pedido do cliente? O fato é que , a maioria das organizações ainda trabalha de forma bastante desplanejada e a TI acaba entrando nesse círculo vicioso.

A cena é mais ou menos a seguinte: a pessoa de negócios chama a pessoa responsável por TI (normalmente o CIO) e diz : PRECISO DE UM PROJETO XYZ PARA ONTEM!!! O CIO de cara diz que não é possível para a data solicitada , porque precisa avaliar a estratégia, desenhar o projeto adequadamente , transicionar e operacionalizar a idéia. Então, a área de negócios insiste: preciso disso para ontem!!! E enfim, o responsável por TI concorda com a data totalmente inadequada para a realização de um projeto do porte solicitado.

Então ele sai quase sempre tendo uma síncope da sala , resmungando e depois trans-forma o resmungo em um grande brado para seus subordinados (insourcing ou out-sourcing, dependendo do caso): “PRECISAMOS DO PROJETO XYZ PARA ONTEM! FAÇAM ACONTECER” E assim a roda gira (nem sempre redondinha). São projetos e mais projetos quadrados, que quando entram em produção já entram com problemas no desenho de disponibilidade, capacidade, falhas no processo de atendimento de in-cidentes e mudanças e com um service desk totalmente despreparado para manter o novo serviço. excessão

Sim, podem me chamar de pessimista, mas duvido que pelo menos uma vez, ninguém nunca tenha participado de um projeto assim. Porque isso ocorre?

Primeiro, porque salvo raras exceções, a organização de TI de uma empresa nem sem-pre é respeitada. É vista como um custo (muito alto, diga-se de passagem), para a área de negócios e uma “área-problema”.

Segundo, porque o ciclo de vida de um serviço não é respeitado. A ITIL® v3 deixa isso muito bem organizado citando em cada um de seus livros uma fase do ciclo: estratégia, desenho do serviço, transição, operação e melhoria contínua. Antes de dizer se é pos-sível fazer ou não, é preciso entender e possuir uma estratégia de TI alinhada, incor-porada a estratégia de negócios. TI não deve mais ser vista como uma área problema e sim como parte da estratégia do negócio de uma organização, pois as organizações



dependem cada vez mais de TI para obter eficiência e eficácia em suas operações.

Se não é possível entregar um projeto no prazo, ou nas condições desejadas, é preci-so negociar, explicar, mostrar tecnicamente que se isso for feito, o projeto não irá cri-ar VALOR para o negócio. Para criar valor, TI precisa apresentar duas características no serviço prestado: garantia (serviço com qualidade na entrega) e utilidade (cliente percebe o serviço com um efeito positivo).

TI só poderá se surpreender com um pedido se estiver longe do negócio, se não es-tiver focando e definindo suas estratégias para aquilo que realmente agrega VALOR para o cliente. Não existe MILAGRE em tecnologia, existe PLANEJAMENTO, ORGAN-IZAÇÃO e GESTÃO.

Como conseguir isso? Implementando um bom gerenciamento de serviços de TI, utili-zando a ITIL® como melhor prática e combinando-o com outros frameworks que apói-em a governança, como por exemplo, o COBIT. Nem sempre vale a pena FAZER MILA-GRES, entregar as coisas correndo, sem planejamento, sem um desenho adequado e com uma qualidade duvidosa. Para fugir desse “mundo de horrores” é necessário im-plementar uma TI que tenha visão voltada para o negócio e para como Ela poderá aux-iliar para que ele atinja seus objetivos.

Obviamente, se hoje você trabalha em uma organização onde não existe nada, se você está bem distante de todas essas palavras bonitas escritas nos livros, saiba que isso é absolutamente normal. Para se atingir um nível adequado de gestão de serviços e gov-ernança é preciso antes de mais nada COMEÇAR. Não espere atingir o mundo perfeito em meses. A realidade é diferente, existe a cultura das pessoas que precisa ser altera-da e uma mudança comportamental rumo à gestão de serviços é lenta e gradual. Mas com certeza, implementando alguns processos de gestão ganhos rápidos virão, que poderão trazer benefícios não somente para a TI, mas principalmente para o negócio.

Mãos a obra? Abaixo os MILAGRES e vamos rumo a Gestão e governança. Cada vez mais organizações têm ciência disso e iniciam projetos de implementação de proces-sos ITIL®, CoBIT, ISO20000. Não dá para imaginar uma organização competitiva que não faça a gestão de seus serviços de forma eficiente e eficaz. E o nome disso não é mi-lagre, é futuro!



Quando o vilão está dentro de casaCLAUDIO DODT

Uma pesquisa recente da Venafi apontou um sério risco que, infelizmente, é cada vez mais comum em organizações de qualquer vertical ou porte: Uma boa parcela (esti-mada em 40%) dos colaboradores de TI admite poder causar sérios problemas, leia-se caos completo, nos serviços/infraestrutura da organização.

O caso específico abordado pela pesquisa reflete dados sobre falta de gerenciamento de chaves de criptografia associada a lacunas controles internos e pouca segregação de funções. Entretanto, existem incontáveis outros cenários onde um único colabora-dor pode tornar a organização sua refém e indiscutivelmente causar prejuízos na casa dos milhões como em um caso ocorrido na prefeitura de São Francisco em 2008 que teve sua WAN seqüestrada por 12 dias (leia mais).

Esse assunto não é nenhuma novidade e já foi amplamente discutido. O problema é que em boa parte das empresas com que já tive contato vejo pouca ou nenhuma ini-ciativa para contornar essa situação chegando ao ponto onde em alguns casos é tido como algo “normal”.

Se você vivencia este tipo de problema em sua organização existem algumas práticas simples que podem ajudar bastante:

1� Uma boa política de segurança da informaçao é essencial: Se seus colaboradores estão conscientes das implicações legais de suas ações eles certamente vão pensar duas vezes antes de cometer um ilícito. No pior cenário se um incidente severo ocor-rer você vai estar protegido e legalmente preparado para tomar as ações cabíveis.

2� Segregaçao de funções (SoD): Provavelmente você sabe que SoD é um método para reduzir o risco de que uma única pessoa possa acessar, modificar ou usar serviços sem a devida autorização ou detecção. O que talvez você não saiba é que, de acordo com o Public Company Accounting Oversight Board, em 83% das organizações a causa de fragilidades materiais estava diretamente relacionada com ausência de Segregação de Funções. Uma boa matriz de segregação (ver exemplo) associada à rotação de cargos e funções pode ajudar a evitar incidentes e apoiar na distribuição conhecimento.

3� Documentaçao, documentaçao e documentaçao: Manter uma documentação atua-lizada é essencial para proteger o conhecimento institucional. Infelizmente, existe uma notória resistência por parte da maioria profissionais de TI que acabam deixando algo tão importante completamente de lado. Cabe aos gestores entender a importância e exigir que uma parcela do tempo da equipe seja dedicada exclusivamente a elaboração de documentação e procedimentos operacionais.

4� Use a tecnologia a seu favor, mas nao se torne dependente: Desde gerenciamento de chaves de criptografia até a sistemas de auditoria e análise do comportamento é



possível dizer que existe uma solução tecnológica para quase tudo. Saber aplicar a tec-nologia a seu favor é reconhecer que não podemos ser completamente dependentes. Busque soluções completas que englobem não apenas um produto, mas procedimen-tos, normas e até mesmo as pessoas necessárias para criar uma solução eficiente.

5� TTTO (Talk to the Ogre): Muitos dos profissionais que gostam de se sentir insubsti-tuíveis o fazem por uma nítida insegurança. Manter um canal de dialogo aberto e, em casos extremos, até mesmo um acompanhamento psicológico pode ajudar e muito na redução de riscos e incidentes. Um bom gestor consegue perceber um problema de re-lacionamento logo no início , onde sua solução é razoavelmente simples. Um mau ges-tor pode fechar os olhos e até mesmo ser conivente com a situação. Nesse ultimo caso certamente vale a máxima: Quem planta vento, colhe tempestade!

A lista acima certamente não é completa, mas espero que essas dicas práticas ajudem a lidar com os Shreks mal entendidos que residem dentro da TI.

Links e referências:

drupal.sfexaminer.com/local/crime/2011/05/judge-orders-former-city-worker-ter-ry-childs-pay-san-francisco-15mwww.net-security.org/secworld.php?id=11062www.itilnapratica.com.br/o-conhecimento-e-meu-e-ninguem-tasca/pcaobus.org/Pages/default.aspxwww.isaca.org/Images/journal/jrnlv4-07-common-ground-1.jpg



Realmente precisamos de modelos e padroes?BRUNO CAIADO

Os homens adoram modelos e padrões. Prestem atenção nas escolas e vocês verão uma infinidade de referências tentando explicar como o mundo, com toda a sua beleza e complexidade, funcionou, funciona, deveria funcionar ou irá funcionar. Isso ocorre em coisas simples como a forma como classificamos períodos históricos e vai até a compli-cados modelos matemáticos e probabilísticos para comportamentos sociais, econômi-cos e até planetários. O Universo se expande ou se contrai de acordo com alguns mod-elos e não se comportar de acordo com eles mostra que ou o modelo inteiro está errado ou existem outras variáveis ainda não consideradas. Até o comportamento de tribos indígenas está sujeito a modelos segundo alguns estudos. Um estudo conduzido por um antropólogo americano tentou demonstrar que brigas e agressões aparentemente aleatórias entre índios seguiam um “padrão” que obedecia a regras codificadas em seus genes. E até mesmo a aparente desordem do mundo também parece seguir uma or-dem subjacente guiada por modelos descritos, por exemplo, pela teoria do caos. Nem de dentro, nem de fora, conseguimos fugir de um “enquadramento”.

Pois então fico aqui com algumas perguntas que me assombram:

• Será que somos meros agentes que seguem padrões definidos ou mesmo progra-máveis?

• Será que modelos e padrões são capazes de descrever ou controlar tudo o que realmente precisamos fazer?

• Será que modelos servem para descrever ou controlar coisas “abstratas” como ser-viços ou estamos em um exaustivo trabalho tentanto controlar as coisas erradas ou da forma errada?

Vamos para um exemplo simples. O gerenciamento de disponibilidade descreve um “momento da verdade” que é o próprio momento da indisponibilidade. Esse momen-to não é simplesmente um “gatilho para você executar um troubleshooting”, mas uma grande oportunidade para você demonstrar uma atitude em relação à falha. Sim, at-itude, que se traduz em demonstrar ao cliente, de diversas maneiras, que você está tomando todas as ações necessárias, que você está atento às necessidades dele e que você está tentando minimizar ao máximo o impacto causado pela falha. Ou seja, afinal de contas que você se importa com ele. Mas espera aí, eu não estou implantando um processo? Como vou garantir uma “atitude” correta usando um processo? Se por “at-itude’ você entende dizer “tenha um bom dia” no final de uma compra em um super-mercado, com um sorriso amarelo no rosto, então sim, você consegue fazer isso com um processo. Se por atitude você entende um desejo genuíno em servir, que afinal é a essência da prestação de um “serviço”, então provavelmente não.

Pois essa é uma questão que envolve a própria natureza pessoal do que chamamos de



“serviço”. Um bom relacionamento entre cliente e prestador e uma boa atitude ao pre-star o serviço podem minimizar enormemente o impacto de falhas ou até ser o princi-pal fator de satisfação, maior inclusive que a qualidade técnica do entregável em si. E isso se aplica a qualquer contexto de prestação de serviços. Uma pesquisa feita junto a pacientes e médicos mostrou que os pacientes que tinham um bom relacionamento com seus médicos tinham pouquíssima pré-disposição a processá-los, mesmo em caso de falhas muito graves. Pacientes que recebiam “pouca atenção” dos médicos tinham uma tendência a serem muito mais rigorosos e críticos, com uma pré-disposição a pro-cessá-los mesmo em caso de falhas menos graves ou mesmo nenhuma falha “técnica”.

A conclusão é estarrecedora. Mesmo que você implante um modelo rigoroso de prestação de serviços, baseado em práticas como ITIL, você pode estar falhando miser-avelmente em prestar um bom serviço na perspectiva do cliente. Isso significa que os aspectos “soft” da prestação de serviços podem estar sendo severamente negligen-ciados em detrimento do compliance a modelos ou padrões, o lado “hard”. Entenda-se como aspectos “soft” a atitude, o bom relacionamento, a conscientização, o engaja-mento, o alinhamento por consenso, o comportamento guiado por princípios e não pela obrigação, o equilíbrio, a justiça e a capacidade inata em servir.

Os melhores consultores de ITSM sabem disso. Mas o fato é que a pressa, a falta de sen-sibilidade ao aspecto humano, a pressão por ganhos exagerados sem um ganho de ma-turidade contínuo e natural, o pressuposto de que o software faz sozinho o “processo”, a falta de co-participação das pessoas no processo de criação do “modelo” e a preguiça em fazer melhoria contínua na ilusão de que relatórios gerados “automaticamente” irão magicamente fazer isso sozinhos acabam por minar o lado “soft” da implantação. E o resultado pode variar desde a implantações desastradas até a implantações ra-zoavelmente bem sucedidas, mas que deixam a sensação de que no fundo, “excelência em serviços” era muito mais do que aquilo que alcançamos.

Culpa do modelo? Talvez não. Modelos ainda são necessários e o ITIL é um bom exem-plo de modelo que nasceu sob o mote do “adote e adapte”, mas acabou caindo na vala dos “frameworks” encaixotados em processos pré-desenhados, ferramentas vendidas como ITIL-in-a-box e promessas mirabolantes de consultores aventureiros. No meio do caminho esqueceram do adapte e prometeram um adote rápido e indolor. Simples-mente porque é o adapte que exige o verdadeiro consultor. O adote se resume a rep-licar coisas prontas de uma referência. O adapte exige experiência, sensibilidade, con-hecimento e paciência. Coisas que o próprio negócio dos clientes às vezes ignora, mas que o verdadeiro consultor não pode ignorar deixando-se levar pelas respostas fáceis que o cliente quer ouvir. Em meio às pressões insanas que os negócios de hoje fazem em seus líderes, o verdadeiro consultor é aquele que consegue trazer os princípios chave e unir esses princípios à sua experiência, guiando estes líderes no meio do tur-bilhão para um caminho factível, mas sem respostas prontas e sem perder de vista um caminho de longo prazo.



Essa união entre “princípios” e “experiência” compõe o equilíbrio entre uma adoção rígida demais e uma adaptação excessiva em que os benefícios se perdem. Para achar esse equilíbrio é preciso entender o que é “rígido demais” e “adaptativo demais”. Na minha visão, “rígido demais” é mais fácil de identificar. Toda vez que alguém ignora ne-cessidades genuínas do cliente em prol de ser compliant com o que o ITIL “determina”, temos um caso de rigidez excessiva. O outro lado da moeda é mais sutil, porque exige que tenhamos com clareza quais são os princípios fundamentais que não podem ser ig-norados ou mesmo distorcidos. Um exemplo clássico é o CMDB. Qual o princípio chave do CMDB ou do processo de gerenciamento de configuração? Não, não vale ir lá no liv-ro e copiar a definição. Esses princípios não estão no livro, porque eles são uma “essên-cia” que é compreendida com o tempo e a experiência de cada consultor. O princípio chave é ter um único CMDB? Não. O princípio chave é a ferramenta? Não. O princípio chave é exigir que todas as tarefas do processo sejam executadas? Não. O princípio chave, baseado na minha experiência como consultor, é o seguinte: ter armazenada a informação relevante sobre os serviços para manter os serviços funcionando e proje-tar novos serviços. Tão simples quanto isso. Mas muitos estão fazendo o contrário: à partir de um modelo operacional pronto (e não de princípios chave!), estão tentando encaixar à força um modus operandi, tentando convencer as empresas de que isso é o “certo”. Esse é um erro fatal. Cada empresa tem seu modus operandi e isso precisa ser respeitado, sendo papel do consultor comparar esse modo de operação com os princí-pios chave e ir, aos poucos e de forma conjunta, criando um modo de operação guiado pelos princípios que realmente farão a diferença naquele contexto.

Notem um ponto interessante: uma série de necessidades adicionais acabam surgindo à partir do princípio chave, mas não necessariamente como princípio chave de um único processo. Um exemplo: porque precisamos compor o gerenciamento de configuração com um gerenciamento de mudanças? Porque o ITIL “mandou”? Não. Simplesmente porque sem um processo de mudanças mantendo as informações atualizadas seria im-possível que a informação se mantivesse relevante e o benefício simplesmente se per-deria. Percebam que nesse caso, uma adaptação que criasse um CMDB sem qualquer tipo de controle de mudanças seria uma distorção de princípios chave e não seria uma adaptação válida. E é exatamante aí que modelos e consultores mostram seu valor. Como guardiões de princípios chave que são fonte de evidentes benefícios e que se implementados com paciência, sensibilidade, engajamento coletivo e continuidade, podem criar não apenas serviços de excelência, mas pessoas conscientes de seu papel e capazes de prover esses serviços.



Seguranca da Informação e a arte de no dizer nãoCLAUDIO DODT

Profissionais que trabalham na área de Segurança da Informação convivem com um conflito quase diário. Se de um lado temos uma equipe focada na proteção das infor-mações, adoção de controles e preocupação com os riscos, do outro temos os usuários que muitas vezes querem simplesmente trabalhar.

Essa pequena batalha acaba criando uma falsa impressão de que a área de segurança da informação só sabe dizer não. O que acaba sendo uma verdade parcial.

O problema é que uma boa parte dos profissionais de segurança ainda tem a percep-ção de que “não se pode confiar no usuário” ou que “não adianta explicar que o usuário não vai entender”. O problema é que essa falta de diálogo faz com que os usuários se cansem e acabem por contornar ou mesmo esquecer os aspectos relacionados à segu-rança da informação.

Idealmente, um bom departamento ou profissional de segurança deve pensar como um fornecedor de soluções o que muitas vezes implica em parar de ditar o que pode ser feito e abrir espaço para o diálogo, trocar o não por um “talvez” ou “depende”.

Ouvir e entender demandas é um passo essencial para o alinhamento com usuários e buscar uma solução segura e eficiente.



Artigos com Altos Índices de Teoria



A eterna e incendiária briga entre a Gestão de Incidentes e de ProblemasCLAUDIA MARQUESANI

Não adianta. Creio que este seja um dos maiores assuntos e “calos nos pés” de quem trabalha com a gestão de serviços de TI. A eterna briga entre os participantes e os ger-entes dos processos de gerenciamento de incidentes e problemas.

Vamos as definições rápidas. Essas duas disciplinas tem interesses relativamente con-flitantes. O objetivo do gerenciamento de incidentes é restabeler a operação normal do serviço o mais rápido possível - resolver o incidente. Como dizem lá na minha terra “apagar incêndios”...

Já o objetivo do Gerenciamento de problemas é investigar as causas subjacentes (cau-sas raízes, aquelas que se resolvidas, solucionarão definitivamente o problema). Isso é feito não para todos os incidentes, mas para aqueles considerados críticos para o negócio: de grande impacto ou recorrentes. O pessoal da gestão de Problemas quer entender , investigar e descobrir “porque pegou fogo” e acompanhar a implementação de medidas para que novos incêndios não ocorram.

Mais ou menos assim: durante um incêndio, os integrantes da equipe de gestão de in-cidentes são os bombeiros. A equipe de gestão de problemas trabalha como os peritos, que entram depois (na grande maioria das vezes) que o incendio acabou, para investi-gar o que foi o causador do incêndio.

Com esse exemplo , fica bem claro entender porque tantas organizações fracassam na implementação e operação do processo de gerenciamento de problemas.

É claro, que o chefe da equipe de bombeiros e dos peritos não deve ser o mesmo. Eles tem metas e objetivos diferentes. E também é claro que um bombeiro não pode ser perito e vice versa. Imaginem o perito/bombeiro lá, investigando as causas de um in-cêndio e rapidamente é chamado para apagar fogo em outro bairro... para qual cham-ada ele dará prioridade?

Analogias a parte, é exatamente isso que acontece no dia a dia de uma equipe que precisa solucionar incidentes e ao mesmo tempo resolver problemas. O suporte téc-nico está lá, iniciando a investigação da causa raiz de problema e... rapidamente é in-terrompido para solucionar OUTRO incidente!! Obviamente a gerencia de incidentes sempre terá prioridade sobre a gerencia de problemas...principalmente se a quanti-dade de “bombeiros/peritos” for escassa.

E voltando para nosso exemplo, qual é a moral da história?

O bombeiro (A EQUIPE DE INCIDENTES) ajuda o perito (A EQUIPE DE PROBLEMAS) , com informações valiosíssimas sobre o incêndio (onde, quando começou, quais fo-



ram suas características) e INFORMAÇÕES SOBRE O INCIDENTE (classificação, pri-orização, informações sobre a atuação e encerramento).

O perito (A EQUIPE DE PROBLEMAS) ajuda o bombeiro (A EQUIPE DE INCIDENTES), investigando (OS PROBLEMAS) e levando soluções (ATRAVÉS DE MUDANÇAS) para que novos incêndios não ocorram. Também oferece, através de suas investigações, no-vas técnicas para apagar incêndios mais rapidamente e adequadamente (SOLUÇÕES DE CONTORNO MELHORES PARA AS EQUIPES DE SUPORTE TÉCNICO).

No final das contas, qual papel é mais importante? Não adianta brigar, ambos são im-portantes! Se por um lado é preciso combater todos os incêndios (INCIDENTES) , por outro não adianta observar um incêndio em cada esquina todos os dias, ocasionado pelo mesmo motivo - como por exemplo má instalação elétrica e não fazer absoluta-mente nada (PROBLEMAS que são relacionados a incidentes recorrentes, por exemp-lo).

Um deve complementar, ter sinergia, auxiliar e não entrar em conflito com o outro, porque, apesar de diferentes, os papéis do gerenciamento de incidentes e problemas são complementares. Juntos, eles trazem benefícios para a organização de TI, para os usuários e para os clientes que são tangíveis - menor desgaste da equipe de TI, maior confiança da parte do cliente e aquilo que toda organização precisa para garantir sua sobrevivência - aumento da eficiência e ECONOMIA de custos.

Uma semana “quente” para todos e até a próxima� :)



A importancia do Plano de ContinuidadeCLAUDIO DODT

Uma matéria publicada na revista ComputerWorld, edição 536, do mês de maio, cita um estudo global feito por uma empresa de segurança com 1,7 mil gestores, em 2010 en-volvendo 18 países, tinha como objetivo entender quais eram os grandes dificultado-res para recuperação em desastres. Segue alguns resultados desse estudo:

• 32% sistemas virtuais não contam com backup regular.• Apenas 1 em cada 4 entrevistados usam tecnologia de replicação para proteção.• 68% dos servidores virtuais não contam com planos para recuperação de falhas.• 51% das empresas, no Brasil, afirmam que procedimentos de backup ocorrem ape-

nas semestralmente.

Os dados dessa pesquisa, abrem espaço para falar a respeito de plano de continuidade de serviços de TI e junto com isso, até mesmo, primariamente, plano de continuidade dos negócios.

Esses dados são no mínimo curiosos e constatam uma realidade já percebida no dia a dia das empresas, as vezes parece que tem que acontecer a tragédiadesastre com a em-presa ou com organizações próximas, para que questões de continuidade de negócio, e consequentemente TI, comecem a entrar em pauta das discussões. Um exemplo clás-sico, as tragédias no vale do Itajaí em 2008. As diversas empresas, TI e outras, públicas e privadas, tinham pouquíssimos ou nenhum planejamento para continuidade. Hoje a realidade é um pouco, veja bem, um pouco diferente. Já existem planos para continui-dade em casos de tragédias que ajudam a minimizar os impactos para o negócio.

A ausência de um plano de continuidade de negócios (PCN), muitas vezes é usada como justificativa para a ausência de um plano de continuidade para serviços de TI. Essa jus-tificativa tem um certo fundo de razão, pois é o negócio é que determinará o que é real-mente crítico para o negócio e irá nortear qual deverá ser a disponibilidade esperada para os serviços de TI. Se o contrário ocorrer, continuidade dos serviços de TI, baseado apenas em TI, pode gerar custos e uso de recursos desnecessários.

Dessa forma, não existe plano de continuidade de serviços de TI, sem plano de continui-dade de negócio. É interessante, nesse momento, citar também a diferença entre ger-enciamento de disponibilidade e continuidade de serviço. O primeiro gerenciamento preocupa-se em manter o serviço funcionando da melhor maneira possível e o maior tempo possível, já a continuidade, trata das ações de recuperação e continuidade, caso aconteça algum desastre que interrompa a disponibilidade de tais serviços.

Penso que o momento atual das empresas e nossa sociedade, é oportuno para desen-volvimento e validação de planos para continuidade de negócio. A medida em aumen-tamos a dependência por serviços de tecnologia da informação, devemos aumentar



nossos planos para continuidade desses serviços em caso de interrupções graves, que podem, em muitos casos, decretar a morte da empresa.

É isso grande abraço. Até o próximo artigo.



A relação entre ITIL e ISOIEC20000LUIZ WAGNER OLIVEIRA NASCIMENTO

Atualmente, o ITIL é utilizado como referência para empresas desenvolverem estraté-gias de serviços envolvendo o planejamento e a gestão da demanda, gestão da qualidade, acompanhamento dos resultados financeiros para os serviços e a divulgação destas in-formações em seus catálogos de serviços. Verifica-se também que adoção destas práti-cas abrange também o planejamento do serviço que considera aspectos importantes como o dimensionamento da capacidade, segurança, níveis de serviço visando assegu-rar a continuidade e sustentabilidade do processo. Após realização do planejamento inicia-se a fase de implantação do processo para o ambiente de produção, incluindo os processos de ativos/configurações de serviços, mudanças, release, testes e avaliação. Quando um determinado serviço está pronto e devidamente testado e aprovado, é realizada uma passagem dos levantamentos realizados para o ambiente de produção. Os processos e funções como central de serviço, incidentes, requisições de mudança, eventos e acesso são utilizados durante este processo. Finalmente é apresentada uma referência para a melhoria contínua, considerando algumas práticas recomendadas por Deming o ciclo PDCA.

Tudo estaria correto, e funcionaria perfeitamente, se não fosse um detalhe: Como o ITIL é uma referência, de que formata garantir a efetividade, implantação e sua sustentação ao longo do tempo? A abordagem apresentada no ITIL não garante que os processos sejam efetivamente implementados em seus requisitos mínimos. O ITIL é descritivo, onde descrevemos as melhores ações a serem tomadas. Deveria existir algo que ser-visse como um guia, para determinações do tipo “deve existir um plano de capacidade!” que pudesse ser avaliada quanto à sua eficácia e eficiência. Neste aspecto, a ISO 20000 atua complementando o ITIL, o Cobit e seus processos de Delivery e Support, atua de forma parecida, porém seu foco é “o que fazer” sob a visão da Governança de TI e não em Gestão da Qualidade de Serviços de TI. Como o processo necessita ser implemen-tado de forma organizada existe a ISO 20000 que é um padrão internacional de quali-dade, projetado para gerenciamento de serviços de TI. Este framework certifica que a empresa utiliza as melhores praticas recomendadas pela ITIL. No Brasil temos poucas empresas certificadas até o momento, já no exterior está referência já é utilizada em maior escala, servindo como pré-requisitos para participação licitações de empresas como a NASA e o Governo Americano.

Pode-se observar que hoje o foco está em ‘fazer acontecer’, sem o devido cuidado com o melhor método ou com uma análise adequada. Quando um gerente de TI afirmar que já possui processos ITIL implantados porem não consegue garantir que este pro-cesso está seguindo os requisitos mínimos de qualidade. A ISO 20000 deve ser utiliza-da como um complemento do ITIL, pois atesta que as melhores práticas em gestão de serviços de TI estão efetivamente implantadas. A ISO 20000 garante também que os



processos mínimos estão sendo aplicados e seguidos. O fato de ser auditado por uma entidade externa de forma contínua e periódica, bem como auditoria interna, garante que os processos e a qualidade de serviços de TI estão sendo seguidos.

Outro aspecto importante é que a ISO 20000 garante alguns complementos fundamen-tais para o ITIL, como, por exemplo, a responsabilidade e o comprometimento da alta direção sobre o sistema de qualidade de serviços de TI, competência, treinamentos e requisitos de documentação para a devida execução dos processos. Tudo isso é audita-do quanto à sua eficácia. Outro aspecto fundamental é a inclusão dos processos do cic-lo PDCA, incluindo auditoria, registros, evidências de não conformidades e oportuni-dades de melhorias com suas ações preventivas e corretivas. Processos importantes de relacionamento com o cliente (incluindo gestão de reclamações) e de gestão de for-necedores 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 dos processos.

Devido a importância do ITIL em sincronia com o ISO 20000 recomenda-se que as empresas e provedores de TI juntamente com seus gestores considerem esta implan-tação conjunta. Sendo este processo voltado primeiramente para a obtenção de mel-hores níveis de qualidade na prestação de seus serviços. Com base nesta argumenta-ção, acredita-se que os benefícios de implantar a ISO20000 em conjunto com o ITIL serão superiores quando comparados a implantação do ITIL de forma isolada para a Gestão da Qualidade em Serviços de TI. Lembrando que o Cliente é quem sai ganhan-do com esta união.



Catálogo de Serviços – O desconhecidoBRUNO CAIADO

Atire a primeira pedra quem nunca achou que um “Catálogo de Serviços” é simples-mente uma lista de serviços. A princípio, ele pode até ser, mas esqueceram de avisar que a gestão do catálogo é um dos processos do livro Service Design. Se antes ele era um adendo da Gestão de Nível de Serviço, agora ele ganhou o corpo e a visibilidade merecidos.

Se o serviço é o meio para atingir os resultados esperados, o catálogo é a referência dos serviços oferecidos. O processo de gestão do catálogo garante a consistência e at-ualização das informações. E a pergunta é: de onde vem essas informações? Das áreas de TI? Das áreas de negócio? Da cabeça do CIO? Do CMDB? Não....nada disso. As in-formações do catálogo devem ser uma consequência de uma estratégia de portfolio de serviços.

Eu explico. Qualquer empresa deve embasar suas decisões e seus investimentos em uma estratégia que balanceie a demanda prevista e a análise do nível dos riscos identi-ficados. Em geral, quanto maior o potencial transformador de um investimento, maior o risco associado. Esses investimentos podem ser associados a categorias:

• Run the Business (RTB): para investimentos que vão simplesmente manter a em-presa funcionando. Baixo risco.

• Grow the Business (GTB): para investimentos que serão usados para aumentar o ta-manho do negócio. Médio risco.

• Transform the Business (TTB): para investimentos que irão transformar o modelo de negócio. Alto risco.

Qualquer empresa que quer se manter viva, precisa, no mínimo, de investimentos de categoria GTB. Em momentos de crise, uma possível opção é adotar uma estratégia conservadora e restringir os investimentos a um mínimo (RTB), o que aparentemente é uma opção segura, mas nem sempre pavimenta o caminho para o sucesso e a sus-tentabilidade.

Uma estratégia de portfolio deve balancear riscos e valor para o negócio para definir onde investir e quais serão os serviços oferecidos interna e externamente. Diversos fatores incluindo a prioridade do negócio, o custo-benefício e as capacidades da em-presa devem ser considerados. Lembre-se: o VALOR para o negócio não é uma enti-dade abstrata, ele é real e é medido em números!

Vamos a um exemplo simplificado. Novamente, vou usar uma empresa aérea fictícia. O ano de 2008 foi complicado para nossa empresa. As vendas não alcançaram o patamar esperado e o nível de ocupação esteve constantemente próximo ao break even (pon-to em que o número de assentos vendidos cobre as despesas incorridas para fazer a



viagem). Pesquisas indicam que os clientes vem tendo dificuldades para comprar pas-sagens pelo web-site, principalmente se estão utilizando smartphones ou outros apa-relhos móveis. Como é uma clara tendência de mercado o uso de canais móveis, fica claro que criar um serviço específico para esse canal poderá alavancar as vendas. De-cide-se investir em um web-site personalizado para smartphones, em que o processo de compras, check-in, reservas poderá ser feito de forma fácil e rápida mesmo nesses dispositivos. Um business case indica que se o investimento for de R$1M, mas as vendas aumentarem 18%, o investimento se paga em 3 meses e a empresa se consolida como líder do mercado.

Um novo serviço chamado de “canal móvel de venda” é criado e requerimentos es-pecíficos são levantados. Esses requerimentos levam em consideração tanto a ade-quação ao propósito (fit for purpose) e a adequação ao uso (fit for use). A adequação ao propósito diz, por exemplo, que esse canal deve servir para vender passagens. A ade-quação ao uso vai levar em consideração a usabilidade, o dimensionamento (de acordo com o aumento do número de passagens compradas), a segurança, a disponibilidade, entre outras especificações. Acordos de nível de serviço são então definidos levando em consideração esses requisitos.

Temos aqui um exemplo de como alimentamos nosso catálogo de serviços. E se um dia esse serviço deixar de fazer sentido para o negócio, ele deve ser retirado do catálogo? SIM! Isso mesmo. O catálogo é uma entidade viva, que contém uma referência para os serviços de TI correntes e que devem ser constantemente avaliados quanto ao valor e custo-benefício para o negócio. Quem faz essa avaliação é a estratégia de portfolio de serviços, alimentando e retirando serviços do catálogo.

A pergunta inevitável que se segue é: porque diabos os serviços do meu “catálogo” (se é que ele existe) parecem ser apenas atividades ou funções de TI, sem uma conexão direta com o negócio? Provavelmente porque esse catálogo foi feito baseado no que você faz e não no que faz sentido você fazer. Simplesmente se fez uma lista, usando algum critério como tipo de tecnologia, funcionalidade ou atividades “padrão” de uma área de tecnologia. Algo como: REDES, CORREIO ELETRÔNICO, APLICAÇÃO X, etc. Eu não diria que está errado, mas está, no mínimo, incompleto e desconectado com o negócio. Nosso objetivo deve ser deixar EXPLÍCITO como esses serviços de TI supor-tam os serviços ou processos de negócio da empresa. Para isso, algumas perguntas precisam ser feitas:

• Qual o core business da empresa?• Quais as atividades chave para manter, crescer ou transformar o negócio da em-

presa?

A primeira coisa que se diz, especialmente em empresas grandes, é: eu não tenho a menor noção da estratégia da empresa. Isso já é grave, mas mais grave ainda é dizer que você não sabe nem quais são as atividades chave para manter a empresa funcion-



ando e que a única coisa que você aprendeu é rodar uma rotina batch. Em um cenário desolador como esse, minha recomendação de emergência é:

1. Mapeie, em alto nível, quais as atividades chave que mantém a empresa funcionan-do e divida elas em grandes grupos como: VENDAS, PRODUÇÃO, FINANCEIRO, etc.

2. Mapeie serviços de TI em um nível de função, como: EMAIL, INTERNET, APLICA-ÇÃO DE VENDAS, etc.

3. Relacione quais serviços suportam quais grupos de processos de negócio.

Esse é o começo, mas não é o fim. Faça uma primeira versão, menos detalhada, com o conhecimento técnico ou de de negócio que você tem. Você pode até lançar uma versão inicial já nesse estágio. Em seguida, mãos à obra: pergunte, descubra, questione, en-tenda, conecte-se com a estratégia da sua empresa e com suas áreas de negócio. Apro-funde seu conhecimento em conceitos adicionais como o de market spaces e gerenci-amento de demanda (disponíveis no livro Service Strategy). Faça seu catálogo girar! Refine, detalhe, publique-o. Ele pode até ser uma lista, mas é também o reflexo do que a organização de TI tem a oferecer e de como ela suporta os objetivos da sua empresa. Se isso é ser apenas uma lista, é apenas uma questão de perspectiva.



Como o BDGCCMDB pode aumentar a eficiência dos processos de suporte a serviçosCLAUDIA MARQUESANI

A Gerência de configuração é um processo bastante popular dentro da biblioteca ITIL®� Porém , um dos mais difíceis de ser implementado, um dos mais importantes e aquele onde temos maior dificuldade para “vender” dentro de uma organização, por ser bastante trabalhoso.

Na prática, vocês conseguem realmente verbalizar quais são as vantagens de uma gerência de configuração para uma organização e para os outros processos de suporte a serviços? Abaixo cito alguns exemplos que podem auxiliá-los a expor essas vanta-gens para uma organização, principalmente aquelas onde alguns processos já estão implementados, mas que está sentindo uma falta “tremenda” de uma boa gerência de configurações para se apoiar. São elas:

1. Gerencia de Incidentes: utilizará o BDGC (Banco de Dados de Gerencia de Confi-gurações) para ter uma visão lógica da infraestrutura de TI e seus serviços, através dos itens de configuração e seus relacionamentos. Essa visão poderá fazer com que a gerencia de incidentes tenha maior agilidade e facilidade para solucionar incidentes. Por exemplo: maior rapidez na analise do impacto e alocação do time correto para atuação no incidente; maior rapidez na identificação dos itens de con-figuração impactados e que precisam ser agilmente substituídos ou corrigidos.

2. Gerencia de Mudanças: terá maior maior controle e agilidade no gerenciamento sobre as mudanças do ambiente, pois o uso do BDGC e a visão lógica da infraes-trutura de TI e seus serviços ( fornecida através dos itens de configuração e seus relacionamentos), mostrará de maneira clara e controlada os componentes envol-vidos na mudança e seu real impacto para o serviço. Por exemplo: terá maior agi-lidade na aprovação de mudanças, pois haverá mais facilidade para analisar o im-pacto no serviço dos itens de configuração envolvidos na mudança; poderá fazer o uso de baselines de configuração , para retornar o ambiente ao status anterior a uma mudança executada e mal sucedida.

3. Gerencia de Problemas: poderá aumentar a eficiência da gerencia de problemas, ao facilitar a análise de tendências em Itens de configuração relacionados a inci-dentes e identificar a causa básica de um ou mais incidentes. Essa informação é utilizada para evitar novos incidentes e melhorar a qualidade dos serviços.

4. Gerência de Liberações: aumentará a efetividade da gerencia de liberações, pois fará auditorias e controles permanentes para evitarão que softwares ilegais ou não autorizados sejam registrados na BSD (biblioteca de software distribuido). Au-mentará a eficiência das liberações pois utilizará baselines de configuração para salvar as informações dos ICs antes do release (atributos como versão ou status, por exemplo). Essas informações poderão auxiliar caso a liberação seja mal suce-



dida e um backup tenha que ser retornado.

Várias outras vantagens poderiam ser citadas, inclusive nos processos de entrega de serviços, mas este post certamente não terminaria hoje.

Conhecer as vantagens de um processo para o negócio de sua organização é o primeiro passo para tomar a decisão de implementá-lo , para conseguir aprovação dos “patroci-nadores do projeto” e a aderência de todos que estarão envolvidos no mesmo. Ou seja, saber as vantagens não é garantia de que o sucesso seja atingido, mas é primordial para buscá-lo. Espero ter ajudado vocês nesta busca.

Disponibilizamos uma planilha modelo de CMDB/BDGC. Para fazer o download, clique aqui. Bom divertimento! :D



Compreendendo a ITIL a partir de uma perspectiva nada convencional um show de rockRENÊ CHIARI

A ITIL® traz uma série de boas práticas de gerenciamento, organizadas para cobrir todo o ciclo de vida de um serviço, focando em cinco fases:

Estratégia de Serviço: É a fase de concepção do serviço. A pergunta mais simples que poderia ser feita neste momento é: “O que sua organização quer ser?”.

Desenho do Serviço: Nesta fase, a estratégia do serviço começa a tomar forma. Tudo o que é necessário para os requisitos do serviço vai para o papel. É hora de planejar como a organização vai se transformar no que foi proposto durante a estratégia!

Transição do Serviço: Mãos na massa! Neste momento é preciso garantir que tudo o que foi desenhado na fase anterior se torne, de fato, um serviço disponível (ou “con-sumível”), com o mínimo de riscos/impacto.

Operação do Serviço: Só os fortes sobrevivem a esta fase. Uma vez disponibilizado o serviço, agora é momento de garantir que ele funcione de acordo com o que foi previs-to na estratégia, com o mínimo de interrupções, e com o tratamento adequado para os imprevistos.

Melhoria Continuada do Serviço: Sempre há o que melhorar. Nesta fase há uma pre-ocupação em garantir que todo o ciclo de vida do serviço passe por uma avaliação cri-teriosa, e lições sejam aprendidas (em qualquer das fases).

Ok, mas qual é a relaçao da ITIL® com um show de rock?

Tendo como verdade a ideia de que um show de rock é uma das ofertas disponíveis em um serviço de entretenimento, promovido por empresas de eventos (os provedores de serviço) ao público em geral (os clientes do serviço), vamos ao seguinte cenário:

Imagine o custo total do espetáculo de uma banda mundialmente conhecida. As tone-ladas de equipamentos, a logística e a enorme quantidade de profissionais envolvidos. A responsabilidade por garantir a satisfação de 50, 100, 200 mil pessoas que pagam para ver o melhor espetáculo possível ao vivo, em um tempo relativamente curto (de 1 a 3 horas). Apesar de um pouco específicos, estes desafios podem ser identificados em quaisquer outros serviços vistos no dia a dia, sejam eles de TI ou não.

Há algum tempo atrás, a banda U2 adotou uma forma diferente de se apresentar, em um palco de 360 graus. Toda essa inovação faz parte de uma estratégia definida para introduzir um novo conceito, uma nova experiência para o público. E sabemos que fun-cionou muito bem.



Provavelmente foram necessários muitos meses de estudo, cálculos, envolvimento de engenheiros de som, arquitetos, especialistas em efeitos visuais, etc. Além disso, con-siderar quantidade máxima de público por show, valores de ingressos, limitações de locais em que este show poderia ser instalado, segurança, etc. Tudo isso para desenhar como esta nova abordagem do espetáculo poderia ser viabilizada ao público.

Você já deve ter visto aqueles profissionais que vivem correndo de um lado para o out-ro, montando e testando os equipamentos das bandas ou artistas antes de um show, trocando os instrumentos em questões de segundos, arrastando cabos de lá pra cá, e quando ocorre algum imprevisto, atua na linha de frente na tentativa de resolvê-lo o mais rápido possível�

Outro exemplo: cada equipamento, desde a ordem de ligação, configuração de parâmet-ros e informações relevantes dos equipamentos como voltagem, modelo, etc. devem ser controlados minuciosamente para que o timbre característico do artista permaneça sempre o mesmo. Provavelmente, o artista deve sempre ser consultado, e aprovar quaisquer mudanças em seus equipamentos, avaliando o impacto que elas podem trazer em uma performance ao vivo.

E se tudo der errado? Qual é o plano caso ocorra um desastre e tudo pare de funcion-ar?

Pra finalizar, tudo isso deve estar explícito nos contratos milionários fechados com os organizadores do evento, juntamente com os níveis de serviço esperados (duração do show, músicas a serem tocadas, etc).

Apenas neste pequeno cenário, já foram citados ao menos 5 processos de gerencia-mento de serviços sugeridos pela ITIL®.



Do inferno ao céu – Como o exemplo do Corinthians pode ser utilizado na Gestão de ServiçosCLAUDIA MARQUESANI

Antes de começar a escrever esse texto é bom ficar claro: sim, sou corintiana, comemo-rei muito o título e estou extremamente realizada. Porém, meu objetivo nesse texto é muito maior que falar de um time de futebol. O fato é que, com certeza, podemos aprender com a guinada que o time do Corinthians teve nos últimos anos, de time re-baixado para a 2ª divisão em 2007 para campeão do Mundo em 2012. Pouco mais de quatro anos que levaram uma das maiores torcidas do país do inferno ao céu, ou seja, satisfação TOTAL dos “clientes” do timão. A satisfação é tanta, que existe a previsão de arrecadação para o timão no próximo ano, somente em patrocínio, de mais de 390 milhões de reais.

E quem não gostaria de ter esse sucesso no nosso dia a dia? De uma Central de Serviços mal avaliada para uma Central de Serviços devidamente reconhecida como estratégi-ca para o negócio de uma empresa? De um processo de mudanças e liberações que só é visto como burocrático, para um processo devidamente reconhecido como essencial para que problemas não aconteçam na área de TI de uma organização? De uma equipe de suporte cansada, desmotivada e mal vista porque está sempre envolvida em inci-dentes e retrabalho, para um time técnico forte e respeitado?

Na prática, o que realmente costuma funcionar, no mundo do futebol, na nossa vida pessoal ou empresarial, são três ingredientes básicos e foram eles que geraram essa receita extraordinária de sucesso corintiana: estratégia, organizaçao e foco para at-ingir os objetivos.

ESTRATÉGIA significa saber onde queremos chegar e como chegaremos lá. Não é segre-do para ninguém que nenhum corintiano, incluindo os dirigentes, aguentava mais as piadinhas relacionadas à falta de um título de libertadores (“nunca serão”). Foi então que, no pior momento do time, após um rebaixamento, resolveram repensar a estraté-gia usada até então. Assumiu um forte diretor de marketing e atual vice-presidente - Luis Paulo Rosenberg, um renomado economista. E o que um economista tem a ver com futebol? Nada e por isso mesmo deu tão certo. Ele criou a rede de lojas do Podero-so Timão (fácil ver uma em cada grande shopping do Brasil), o projeto sócio-torcedor, trouxe de volta o querido ex-craque da seleção Ronaldo (um golpe de mestre para o marketing do time), ou seja, soube utilizar a paixão da torcida a favor do clube e com isso aumentou o faturamento anual de R$ 117,5 milhões para R$ 290,4 milhões. Há 3 anos, ouvi uma entrevista do ex-presidente Andrés Sanchez para uma rádio, onde ele já dizia que nos próximos 10 anos o Corinthians estaria entre os maiores do mundo... Hoje, alguém duvida dessa profecia e da estratégia que eles estão utilizando para atin-gir esse objetivo?



Portanto, se seus objetivos não estão sendo alcançados, será que a estratégia que você traçou para “chegar lá” é a mais adequada? Talvez seja necessário percorrer um camin-ho diferente do traçado inicialmente.

ORGANIZAÇÃO significa preparar-se para atingir os objetivos que foram definidos na estratégia. Contratação de bons e experientes profissionais – não adiantava quer-er ganhar a Libertadores, com toda sua pressão de jogos eliminatórios, com quem não tem experiência nesse tipo de competição. O timão buscou Chicão, Alessandro, Mano Menezes, todos com experiência. Eles já estavam lá em 2008, disputando a 2ª divisão do brasileirão, quando o Corinthians ainda sequer sonhava em disputar a copa Liber-tadores da América...

Do mesmo modo, se você quer ter serviços de qualidade, contrate profissionais de qualidade – pelo menos alguns – para conduzir esse trabalho e para preparar e treinar outros profissionais com sua experiência.

Não podemos esquecer que é preciso também estar organizado como uma equipe. Ap-enas “estrelas”, não ganham campeonato - se fosse assim o campeão mundial de 2012 seria, com certeza, o Chelsea. “Estrelas” são o máximo naquilo que fazem, mas soz-inhas não conseguem conduzir um trabalho adequadamente, não conseguem chutar e cabecear para o gol. É preciso que todos da equipe estejam organizados e preparados para buscar o objetivo principal definido lá na estratégia.

FOCO significa manter-se concentrado, organizado, preparado para a busca desses objetivos, mesmo diante das adversidades. O Corinthians contratou um líder forte, que promove o trabalho em equipe e fortaleceu-o junto ao grupo, através do apoio incondi-cional da diretoria. Nem mesmo quando, vergonhosamente, o time sob a liderança do Tite caiu ainda na fase pré-Libertadores de 2010, esse líder perdeu força. A diretoria optou por mantê-lo, para que ele continuasse seu trabalho. O resto da história nós já conhecemos.

Quantas vezes diante de um fracasso, não mudamos de rumo, a ponto de esquecer qual era nossa estratégia inicial? Não é pecado algum mudar de estratégia, mas muda-la a todo instante significa falta de foco e perda de dinheiro (economizaram com a rescisão do Tite naquela época e tenho certeza que não estão arrependidos disso hoje!).

Sei que muitos não corintianos vão ler esse post e pensar: “que saco, até aqui no ITSM na prática estão falando do Corinthians!”. Torcidas e corações a parte, temos que recon-hecer que esse tipo de ascensão serve de inspiração para qualquer profissional que deseja crescer e buscar o sucesso. Porque não utilizar esse exemplo também no nosso dia a dia? Mesmo que vocês sejam Palmeirenses, São Paulinos, Santistas...Tenho certeza que pode dar certo! Vaiiiiiiii Corinthians! ;)



Entenda a importância da classificação do IncidenteCLAUDIA MARQUESANI

Antes de mais nada é preciso entender os conceitos e a importância dessa atividade para a Gerência de Incidentes e para os outros processos das melhores práticas ITIL®. O que é classificação?

CLASSIFICAÇÃO = CATEGORIA + PRIORIDADE, onde: • CATEGORIA = determina o tipo de Item de configuração afetado no incidente (por

exemplo: Hardware/Software)• PRIORIDADE = IMPACTO + URGÊNCIA , sendo que:

- IMPACTO = Impacto que o incidente pode causar nos negócios; - URGÊNCIA = tempo requerido para resolução (relacionado a tempo).

Na prática , a classificação de um incidente pode parecer algo muito simples. Por isso , na maioria das vezes durante a implementação ou no dia a dia do processo não damos a devida importância a essa atividade.

Classificar um incidente é sim uma atividade relativamente simples, mas criar catego-rias que possam trazer eficiência e melhorar os serviços de uma organização pode ser bastante desafiador.

Quando vamos implementar a Gerência de incidentes das melhores práticas ITIL®, é importante investir tempo planejando essa classificação. Qual seria a melhor classifi-cação (sempre pensando no custo benefício para o seu negócio)? É importante ter em mente que o ideal é sempre o máximo de informação , com o mínimo de controle e cus-to para mantê-la.

Abaixo apresento como a correta classificação de um incidente pode contribuir para aumentar a eficiência de uma organização e o fornecimento de serviços .

1. A classificação é usada para definir e/ou selecionar o melhor especialista ou gru-po para lidar com o incidente� Ela auxiliará a encaminhar o incidente para os espe-cialistas mais preparados para atendê-lo, evitando que outros grupos de suporte gastem tempo e esforços na soluçao de incidentes para os quais nao foram ade-quadamente preparados�

2. A classificação também é usada para comparar incidentes e contribuir para me-lhorar o tempo e qualidade da investigaçao e diagnóstico � Através da classifica-ção é possível comparar incidentes que já aconteceram e aplicar diagnósticos e soluções já implementados no passado para os incidentes atuais de maneira mais fácil , rápida e precisa.

3. A classificação é usada para identificar a prioridade de atendimento de inciden-tes, baseada no impacto que o incidente traz para o negócio� Com isso é possível priorizar o atendimento daquilo que realmente causa impacto para o negócio de



uma organização (perdas financeiras, de imagem, etc.)4. A correta classificação auxiliará uma organização a definir quais questões devem

ser feitas e checadas durante a abertura do incidente� Pode ser criado um script de perguntas para garantir que as informações necessárias sejam obtidas com o usuário impactado e registradas no momento da abertura e suporte incial do inci-dente. Isso evitará perguntas e testes descenessários com os usuários e melhora-rá a qualidade e tempo do atendimento do incidente�

Lembre-se: classificar corretamente está , em grande parte, ligada a QUALIDADE DOS ITENS QUE TEMOS DISPONÍVEIS PARA COMPOR A CLASSIFICAÇÃO� No livro do ITIL® (Service Support) podem ser encontrados diversos exemplos de modelos de clas-sificação (categorização e priorização, respectivamente anexos 5 A e 5B do capítulo de Gestão de Incidentes). Avaliem as sugestões e melhores práticas do livro e adaptem com cuidado e esmero para sua organização.

Disponibilizamos em nossa área de downloads um modelo prático de categorização e prior-ização). Verifiquem esse modelo e adaptem para o dia a dia de vocês.

Os ganhos podem ser realmente surpreendentes��

Boa sorte.



Niveis de serviço tão necessários quanto inuteisBRUNO CAIADO

O título parece exagerado e sensacionalista, mas não consegui pensar em nada que se aproxime mais da realidade. Todos querem niveis de serviço, mas poucos tem em mente objetivos claros antes de começar a construí-los. O objetivo maior, é claro, não poderia ser outro a não ser o “alinhamento com o negócio”, uma das máximas mais exaustiva-mente repetidas e menos efetivamente implementadas. E o motivo é muito simples: não existe mágica para isso. Nem ITIL® nem qualquer sistema, metodologia ou melhor prática é capaz de fornecer a resposta definitiva de como obter o “alinhamento” com o negócio.

De fato, essa é uma pergunta aberta e que exige uma abordagem estruturada, que se inicia no entendimento dos objetivos de negócio e se replica em diferentes níveis. É impossível falar em “alinhamento” em um único nível. É mais coerente falar em uma “cadeia de alinhamentos”, que se sincronizados e mantidos através dos controles ade-quados podem trazer um alinhamento efetivo.

A biblioteca ITIL® não oferece uma única disciplina para isso. Na verdade, o alinha-mento com o negócio permeia a biblioteca. Mas se pudéssemos eleger uma única dis-ciplina, o gerenciamento de nível de serviço (Service Level Management – SLM) estaria provavelmente em primeiro lugar. E não porque SLM garanta o cumprimento de SLAs (Service Level Agreements). Nada disso. Mas sim, porque SLM garante que acordos sejam feitos e que esses acordos levem em consideração as necessidades de negócio dos clientes. Cumprir ou não SLAs é irrelevante se os acordos não refletirem necessi-dades reais de negócio.

Mais importante que qualquer outra coisa, SLM depende de uma definição de serviços que de fato ajudem os clientes a atingirem seus objetivos, do alinhamento de expec-tativas em relação ao que será entregue e da definição de SLAs que realmente façam alguma diferença ao serem cumpridos. Se esses passos fundamentais não forem exe-cutados (ou não forem corretamente executados) a monitoração e cumprimento ou não de SLAs será uma mera formalidade contratual. E por consequência, a confecção de relatórios será apenas mais uma forma de gastar papel, tinta ou recursos.

Ao invés de meros SLAs, nada mais relevante para medir a efetividade de SLM do que a confiança que o cliente tem no provedor. A confiança é construída a partir de um re-lacionamento estabelecido entre cliente e provedor e não a partir de SLAs. Isso se re-flete na seguinte pergunta: entre um provedor que cumpriu o SLA e um provedor que não cumpriu, mas que tem um cliente satisfeito e que confia no seu trabalho, quem executou o processo de SLM de forma mais efetiva? A resposta é clara: o último.

Para exemplificar, vamos retomar nosso exemplo da empresa aérea. As expectativas são altas em relação ao novo serviço de “canal móvel de dados”, que será usado para



facilitar a compra de passagens por smartphones. A expectativa é de um aumento em 18% no RPK (Revenue Passenger Kilometers), que representa quilômetros de passa-geiros pagantes (o que exclui tarifas especiais e tripulantes). Isso significa pelo menos 400.000 passageiros a mais em um único mês para nossa companhia aérea. O siste-ma também deve alimentar o portal que mostra o ASK (available seat kilometers, que mede a capacidade de transporte) e o load factor (que mede a taxa de ocupação). Duas funcionalidades chave para o negócio são mapeadas: a capacidade de venda de pas-sagens, com um dimensionamento para pelo menos 400.000 transações/mês e a in-tegração com o portal de indicadores. O nível de serviço acordado prevê um baseline de 1000 transações por hora, sendo 500 simultâneas, e pelo menos 1 replicação diária das informações para o portal. A replicação deve ocorrer antes da reunião diária da gerência de operações (10:00 AM). Indisponibilidades do canal devem ser corrigidas em no máximo 1 hora, representando a perda potencial de 1000 passageiros.

Não é difícil perceber o quanto os SLAs acima fazem sentido para os objetivos estraté-gicos relacionados ao novo canal de vendas. Isso representa um alinhamento entre as necessidades do negócio e os serviços e SLAs oferecidos pela organização de TI. Mas o alinhamento não pára por aí. Ele é, na verdade, uma via de mão de dupla e exigirá uma cuidadosa análise tanto da capacidade de entrega quanto dos custos. Essa “ponte” é feita por SLM, que precisa envolver outros gestores como os de disponibilidade, ca-pacidade e financeiro. Depois disso, será preciso monitorar o atingimento dos SLAs, acompanhar perdas potenciais e efetivas e revisar continuamente o valor de negócio que eles representam. Eventualmente, tanto a capacidade do canal ou outra caracte-rística poderão ser revistas à luz de novas necessidades de negócio. Os SLAs devem evoluir de forma alinhada a essas necessidades e não podem ser considerados como “gravados em pedra”. Para isso, os próprios acordos devem prever revisões periódicas tanto do atingimento quanto de sua adequação.

Alguns SLAs podem até ser inúteis, mas aqueles criados de acordo com necessidades de negócio específicas, monitorados e revisados continuamente, e usados como ferra-mentas para a construção de relacionamentos com o cliente, esses sim, são verdadei-ros SLAs, tão necessários quanto os próprios serviços prestados.



O conhecimento é meu e ninguém tascaCARLOS AFONSO

É notório que em muitas organizações atualmente existem pessoas que se acham por-tadoras de um conhecimento “místico” que, segundo eles, não pode ser passados aos outros.

No contexto de uma Central de Serviços, um exemplo é visto naqueles que possuem o conhecimento específico relacionado a um ou mais componentes de um serviço de TI. O drama é maior principalmente quando a organização não possui uma documentação adequada de seus serviços, e a organização e/ou fornecedores não possuem o mesmo em relação a esses componentes.

Um exemplo de como isso pode ser particularmente sentido é quando o Cliente liga para o Service Desk e pede uma consulta. Até aí tudo bem. O problema é quando so-mente uma pessoa é capaz de atender a essa consulta. Neste caso, é aquele que não passou o seu conhecimento para ninguém, e faz questão de não documentá-lo. Moti-vo: ele se considera especial e indispensável para a organização basicamente por este conhecimento específico que possui.

É importante ressaltar: existem duas situações possíveis. Uma é aquela em que a pes-soa não quer passar o seu conhecimento para os outros. E a segunda é aquela em que a pessoa não se importaria em passá-lo. Nos dois casos, obviamente a culpa é da organ-ização que não tem um processo eficaz de Gestão do Conhecimento.

Soube de um caso, certa vez, em que um profissional foi treinar outros dois para re-alizar o atendimento de terceiro nível de um sistema de faturamento. Ao final de dois meses, nenhum dos dois profissionais novos tinha o conhecimento a respeito dos pro-cessos mais críticos do sistema. E o sistema nem era tão complexo assim! Ainda que a culpa final seja dos responsáveis pela Gestão do Conhecimento (por não ter feito um plano de transferência do conhecimento eficaz), era evidente a satisfação dele em ter que ser chamado toda vez que surgiam incidentes, problemas e serviços adicionais em relação ao componente.

O principal argumento dado por ele era: “eu trabalho com este sistema há uns 2 anos, não é possível explicar todas as regras de faturamento em meses”. Na verdade, o pedi-do era que primeiramente as regras e comportamentos críticos do sistema fossem explicados, mas mesmo assim, isso não foi feito. E, pelo tamanho do componente em questão, um mero plano de transferência de conhecimento cuidaria disso em questão de poucas semanas. E ele fez esse plano, mas cuidou para que o conhecimento essen-cial não fosse passado. Conclusão: por medo de deixar de se sentir especial, ele tratou para que o restante da sua equipe não possuísse o conhecimento que ele possui para o atendimento em relação ao componente.



Esse tipo de profissional, que alega a impossibilidade ou inviabilidade de se transmitir um conhecimento específico (e que justamente por isso ele seria “especial”), é um dos principais desafios para a gestão atual. Por vários motivos, como o fato de que, se profis-sionais em geral sentem-se valorizados e motivados quando conseguem fazer suas atividades plenamente, eles terão sua iniciativa dificultada por que alguém está escon-dendo o conhecimento deles. Embora aquele que esconde o conhecimento dos outros (guardando-o só para si), sinta-se mais “seguro” no cargo, o desempenho da equipe cai como um todo, e os riscos do atendimento ao cliente ser prejudicado aumenta, pois não é sempre que este profissional estará disponível ou terá tempo para o atendimento.

Não existem benefícios organizacionais para este tipo de atitude, que, em muitos ca-sos, chega a ser desleal com a própria organização e com a equipe.

Com desafios deste tipo aqueles que atuam com o processo de Gestão do Conhecimen-to, disponível a partir da ITIL® 3.0, terão que lidar. É o momento de valorizar profissio-nais que são formadores de outros profissionais, e que, aos poucos, com sua atitude, ajudem a diminuir o risco do atendimento não acontecer. E, aos poucos, mostrar para aqueles que não valorizam a transmissão do conhecimento que eles não passam de fo-cos de risco para a organização de TI.



O que é Gerenciamento de Serviços de TI?ANDRE JACOBUCCI

O Gerenciamento de Serviços de TI é um daqueles temas que, por sua riqueza, só pode ser bem apreciado quando abordado por diversas perspectivas complementares.

Por isto, neste artigo, pretendo ressaltar uma das facetas do Gerenciamento de Serviços de TI: o fato de ser uma prática.

Da mesma forma que cozinhar não se aprende apenas lendo bons livros de receita – ou observando outras pessoas a cozinhar – o Gerenciamento de Serviços de TI é uma habilidade que só se desenvolve praticando.

Assim como na cozinha de um bom restaurante, o resultado de uma organização de TI também depende do acesso a bons ingredientes, bons fornecedores, bons equipamen-tos, boas receitas e métodos de trabalho corretos. Mas depende, sobretudo, de profis-sionais competentes que não se esquecem, jamais, de que tudo isso existe porque al-guém está esperando na mesa para satisfazer sua fome ou para ser surpreendido com um prato delicioso.

O Gerenciamento de Serviços de TI envolve, antes de mais nada, entender as neces-sidades e expectativas do cliente, e buscar o meio mais apropriado de atendê-las. É enxergar uma organização de TI mais do que um grupo de profissionais especializados, executando tarefas técnicas isoladas dentro de suas áreas de expertise, e sim com uma visão de como tudo isso se encaixa e, principalmente, com a visão do cliente que espe-ra na outra ponta.

Sendo assim, o Gerenciamento de Serviços de TI está longe de ser apenas a implan-tação de uma área de atendimento aos usuários finais – erroneamente chamada de “Service Desk” – para que a organização de TI possa ser comunicada das falhas, dúvi-das e dificuldades que impactam a produtividade destes usuários.

O Gerenciamento de Serviços de TI enxerga que todas as atividades de uma organização de TI – do levantamento de requisitos para o desenvolvimento de um novo sistema, ao monitoramento dos equipamentos que sustentam os sistemas já em produção – estão conectadas e devem ser gerenciadas por meio de parâmetros de qualidade, tempo e custo, para que tal organização de TI possa atender e surpreender seus clientes.

Sendo assim, o Gerenciamento de Serviços de TI também envolve aspectos de market-ing, operacionais, financeiros e de gestão de pessoas.

O assunto não se esgota aqui, como alertei no início deste artigo. Pelo contrário, nos estimula a abordá-lo sob diversos outros ângulos: o ângulo operacional – representa-do pelo conjunto de processos “clássicos” propostos pela ITIL®, o ângulo da qualidade e da gestão sistêmica – proposto pela ISO 20000, o ângulo da Governança de TI – re-



forçado pelo Cobit, dentre diversos outros.

E para você? O que é o Gerenciamento de Serviços de TI?



Os 10 Mandamentos da ITILCLAUDIA MARQUESANI

Quando falamos de ITIL®, NÃO existe a obrigação para se implementar os processos exatamente como os livros os descrevem. Um dia, várias empresas e pessoas envolvi-das no gerenciamento de serviços de TI resolveram trocar experiências. Algum tempo depois, elas chegaram a um consenso sobre o que eram as melhores práticas de merca-do e posteriormente registraram isso em livros que se tornaram a “famosa” biblioteca ITIL®. Porém, alguns erros e gargalos na implementação dos processos são tão óbvios e atrapalham tanto a prática de implantação, que resolvi inovar e criar os 10 “manda-mentos” da ITIL® ( mas eles poderiam ser muito mais que 10... escrevam contribuições a respeito nos nossos comentários desse post). São eles:

1. Amarás a ITIL® com a ti mesmo�

Não desista! O gerenciamento de serviços de TI de uma organização e a melhoria dos níveis de maturidade dos processos tende a melhorar com o passar do tempo. Não adi-anta andar com a biblioteca da ITIL® debaixo do braço, estudar horrores e achar que do dia para a noite todos os “stakeholders” de uma organização vão migrar de uma cul-tura voltada a produtos para uma cultura voltada a serviços. É um processo lento, algu-mas vezes solitário e quase sempre árduo. Um processo de “catequização” que levará a mudança de cultura de uma organização. Siga em frente, motive seu time, mostre o valor agregado do gerenciamento de serviços, aposte nos ganhos rápidos e aos poucos essa cultura ganhará mais espaço em sua organização.

2. Nao acharás que é TI (tecnologia da informaçao) quem dita as regras�

Um dos principais objetivos da ITIL® é fazer com que a TI contribua para que a organ-ização atinja seus objetivos de negócio. Por isso, não adianta a área de TI assumir que entende o que é importante para a empresa e tomar as decisões por si mesma. É preci-so OUVIR O CLIENTE. É preciso entender quais são os objetivos de negócio. Nenhum conhecimento técnico será suficiente para trazer resultados, se a TI tomar decisões que não auxiliam no atingimento das metas da organização. Provavelmente serão fei-tos investimentos em recursos e tecnologias desnecessários... Hoje em dia ninguém deseja “queimar” dinheiro, não é mesmo? Pecado mortal esse...

3. Não implementarás gerenciamento de configuração sem um bom processo de gerenciamento de mudanças para auxiliá-lo�

Parece simples, mas não é. É o gerenciamento de Mudanças quem informa ao Banco de Dados de Gerenciamento de Configuração o que e quais serão os itens de config-uração alterados durante uma alteração no ambiente de TI. Podemos, portanto, ter o melhor Banco de Dados de Gerenciamento de configurações do mundo, contratar



a mais competente consultoria para implementá-lo, para definir o escopo mais ade-quado e contratar ferramentas perfeitas para mantê-lo - sem um processo adequado de gerenciamento de mudanças, os itens de configuração serão alterados, novos itens serão adicionados na infra e em pouco tempo, pouquíssimo tempo mesmo, o Banco de Dados de Gerenciamento de Configurações estará completamente desatualizado. Se você já começou um projeto de implementação de Gerencia de configurações em sua organização e ainda não tem um processo de mudanças, aconselho a rever o projeto ou tomar muito calmante para explicar para o CIO porque os benefícios que foram vendidos com o processo não estão chegando...

4. Jamais atribuirás o papel do Gestor de Problemas e de Gestor de Incidentes para a mesma pessoa�

Alguns processos têm interesses conflitantes e esse é um exemplo claro! A gerência de incidentes tem o objetivo de restabelecer a operação do serviço o mais rápido possível. A gerência de problemas tem o objetivo de investigar cuidadosamente para identificar a causa raiz de um incidente crítico ou vários incidentes recorrentes, não se preocu-pando com o tempo, mas com a qualidade da investigação. Imaginem o grande conflito de interesses, quando determinamos a mesma pessoa para ser gerente de incidentes e problemas? Ela priorizará o atendimento de incidentes ou a investigação? Essa nem vou responder, vou deixar para vocês pensarem...

5. Treinarás o pessoal da Central de Serviços periodicamente�

Já foi assunto de inúmeros posts, parece uma situação bem óbvia, mas quase sem-pre é negligenciado. Não adianta cobrar qualidade de atendimento de uma central de serviços, onde as pessoas responsáveis pelo contato com o usuário não são treinadas. Elas precisam receber, periodicamente , além de treinamento técnico, treinamento comportamental, saber como atender um telefonema, como lidar com o usuário e como responder as questões técnicas. Precisam saber utilizar a base de conhecimento, uma de suas principais ferramentas de trabalho. Sem treinamento, a Central de Serviços é um barco a deriva, esperando um vento mais forte (ou um evento mais crítico) para afundar.

6. Nao subestimarás a satisfaçao dos usuários e dos clientes�

Ouça o cliente e instigue-o a expressar sua opinião a respeito do gerenciamento de serviços de TI. Revise os níveis de serviços atingidos e os não atingidos e atue na mel-horia contínua de ambos (sim, também é possível melhorar o que já está bom, se isso for interessante para o negócio). Não deixe tudo parado, como se nada estivesse ac-ontecendo. Não espere seu cliente lhe procurar para manifestar sua insatisfação, per-gunte como ele se sente! Existem dois tipos de detectores de satisfação: o termômetro da satisfação do cliente é o gerente de nível de serviço e a voz dos usuários para TI é o



Service Desk. Utilize esses meios e atinja os melhores fins!

7. Não acharás que uma certificação será suficiente para implementar os proces-sos na prática�

Na teoria a prática é outra. Já ouviram essa frase? Pois é, essa é a mais fiel realidade quando falamos de gerenciamento de serviços de TI. Resumindo: somente conheci-mento teórico, diplomas e certificados, apesar de ajudarem (e muito!), não garantem uma boa implementação. É preciso trocar experiências com pessoas que já vivenciar-am uma implantação dos processos, é preciso pesquisar , conhecer o negócio e princi-palmente ter paciência. É como “andar de bicicleta”. Quanto mais você pratica, melhor fica. Atenção para a palavra: PRÁTICA.

8. Nao recusarás o suporte dos outros modelos e frameworks�

As bibliotecas da ITIL® trabalham muito bem com outros frameworks e modelos, como o COBIT , a ISO 20000 e modelos de gestão de projetos. Através deles é possível obt-er maior controle para as melhores práticas, maior entendimento e maior eficiência e eficácia na operação e entrega de serviços. Pesquise como eles podem interagir. Na In-ternet existem inúmeros vídeos e publicações a respeito e em nosso site já colocamos alguns posts sobre esse assunto. Só aplicar as melhores práticas da ITIL® é muito bom, suportá-las por outros controles e modelos é melhor ainda!

9. Nao acharás que a gerência de disponibilidade serve somente para medir quan-tas horas um recurso de TI está operando (ou nao!)�

Princípio 2 da Gerencia de Disponibilidade (retirado do livro versão 2 ITIL® – Entrega de serviços) : “Reconhecer que, mesmo que as coisas deêm errado, ainda assim é possível al-cançar o objetivo do negócio e a satisfação do Cliente”. Um servidor caiu. Será que mesmo assim é possível manter a satisfação do cliente? A gerência de disponibilidade garante que sim, porque ela não se preocupa apenas em manter o serviço operando. Quando algo errado acontece, ela também cria condições e pode suportar para que esse serviço seja recuperado mais rapidamente. Que tal “clusterizar” um servidor que suporta um processo crítico para o negócio após um estudo da gerência de disponibilidade?

Outra parte muito interessante dessa gerência é que ela também oferece técnicas in-teressantíssimas para avaliar qual será a disponibilidade projetada para um novo serviço. Essas técnicas podem ser aplicadas inclusive para aumentar a confiabilidade, disponi-bilidade e segurança de um serviço que ainda nem entrou em produção, alterando o desenho proposto para melhorá-lo. Sim, esse é um processo muito nobre da nossa bib-lioteca e muitas vezes esquecido ou subestimado...

10. Nao acharás que o Gerenciamento Financeiro é um processo “chato” da bibliote-ca�



Eu entendo. A maior parte das pessoas que trabalham com TI, não gosta muito de fi-nanças. É um mundo um pouco estranho para quem está acostumado com termos téc-nicos, sistemas e máquinas. Mas é um “mal” necessário. Aliás, imprescindível. A TI pre-cisa começar a “se vender”. É preciso mostrar porque determinado investimento em TI custa caro muitas vezes, o retorno que aquele investimento trará para o negócio e como esses custos serão controlados. TI precisa profissionalizar-se, ser operada como uma área de negócio e não somente um processo de apoio dentro de uma organização. Entender termos como : Retorno sobre o investimento (ROI) e Custo Total de Proprie-dade (TCO), não é mais opcional. Afinal, você, diretor de TI, tem idéia de quanto custa para sua organização manter esse notebook que você está utilizando? Pergunte ao processo de gestão financeira. Ele terá a resposta.



Para que serve a ISO 20000?NELSON GRANADO MERINO

A ISO/IEC 20000 é a primeira norma editada pela ISO (International Organization for Standardization) que versa sobre gerenciamento de serviços de TI (Tecnologia da In-formação).

A ISO 20000 é um conjunto que define as melhores práticas de gerenciamento de serviços de TI. O seu desenvolvimento foi baseado na BS 15000 (British Standard) e tem a intenção de ser completamente compatível com o ITIL® (Information Technolo-gy Infrastructure Library). A sua primeira edição ocorreu em dezembro de 2005.

As normas internacionais relacionadas com a Gestão de Serviços de TI permitem a colaboração de organizações internacionais e fornecem directrizes valiosas que con-tribuem para o estabelecimento da credibilidade das empresas. Uma nova norma, a ISO 20000, agora disponível, permite a uma organização demonstrar aos seus clientes e investidores que opera com integridade negocial e segurança, e que promove uma cultura de melhoramento contínuo da qualidade no âmbito da Gestão de Serviços de TI.

Por que é isto tão importante? É importante porque a obtenção da certificação ISO 20000 pode contribuir para que as empresas alcancem uma vantagem competitiva relativamente às empresas que não cumprem os requisitos desta norma.

O lançamento da ISO 20000 levanta uma questão às organizações em todo o mundo: O que necessita a organização de fazer presentemente, relativamente à ISO 20000? Deverá uma Organização Procurar Obter Certificação?

Conforme referido anteriormente, a certificação ISO 20000 permite verificar se uma organização emprega as melhores práticas de Gestão de Serviços de TI, conforme demonstrado por uma avaliação independente externa com base numa norma oficial, realizada por uma organização de auditoria autorizada. Este nível de validação pode auxiliar a empresa a manter uma maior competitividade.

Ao determinar se deve ser obtida a certificação ISO 20000, a organização deverá ter em consideração o seguinte:

• A ISO 20000 é particularmente importante para organizações de sectores indus-triais em que a qualidade dos serviços de TI é essencial para o sucesso empresarial, tais como — mas não só — os sectores industriais de serviços financeiros, serviços de utilidade pública e serviços de saúde. A certificação permite a estas organiza-ções demonstrarem aos seus accionistas e clientes que possuem ambientes de TI bem geridos.

• A ISO 20000 é relevante para organizações que fornecem serviços geridos e sub-contratação de serviços de TI. A certificação permite às organizações de serviços



geridos garantirem aos seus clientes que os seus ambientes de TI serão bem ge-ridos, possibilitando às organizações de outsourcing garantirem aos clientes que receberão serviços de TI de elevada qualidade.

• Estes fornecedores de serviços têm que provar que documentaram as cinco áreas chave da ISO 20000 e que estão a ser cumpridos os requisitos da norma. A docu-mentação deverá incluir as políticas e planos de Gestão de Serviços, Acordos de Nível de Serviços, processos e procedimentos exigidos pela ISO 20000 e quaisquer registos exigidos pela norma.

• As organizações deverão ter em consideração as implicações de uma certificação no respeitante à conformidade regulamentar. Presentemente, as organizações necessitam de demonstrar a conformidade com um número crescente de regula-mentos governamentais.

Muitos destes regulamentos, tal como as leis Sarbanes-Oxley e HIPAA (Health Insur-ance Portability and Accountability Act) de 1996 nos EUA, estão especificamente rel-acionados com serviços de TI e Gestão de Serviços de TI (ITSM). Actualmente, os au-ditores não exigem certificação de standards como prova de conformidade, mas no futuro esta situação poderá mudar.

Por a ISO 20000 estar especificamente relacionada com a qualidade da ITSM, esta poderia proporcionar um standard internacional utilizado pelos auditores com vista a determinar a conformidade.

A certificação ISO 20000 será concedida apenas a organizações com operação de ITSM e certificará apenas a operação de ITSM nessas organizações. A certificação não será concedida para produtos ou para serviços de aconselhamento de melhores práticas oferecidos por organizações de consultoria. A certificação poderá tornarse um requi-sito para realizar negócios com determinadas organizações, tais como agências gover-namentais ou outsourcers.

Por a ITIL® ser fundamental para a ISO 20000, é importante seleccionar uma solução de automatização compatível com os processos ITIL®. A solução deverá suportar pro-cessos que abranjam todas as disciplinas de gestão de serviços de TI — gestão dos ac-tivos, gestão de mudanças e configuração, gestão de incidentes e problemas, gestão de lançamento, gestão de capacidades, gestão de disponibilidades, gestão de financeira e gestão de níveis de serviços. As “suites” são mais adequadas do ponto de vista finan-ceiro, do que as aplicações “best-of-breed”, que requerem um trabalho de integração considerável.

Além disso, um dos principais requisitos da ITIL® é a integração de processos entre as diferentes disciplinas.

Deve ser procurada uma solução que integre totalmente os vários processos ITIL®, tanto do ponto de vista dos processos, como dos dados, em vez que proporcionar mer-



amente um mapeamento campo-a-campo.

O que é mais importante compreender acerca da ISO 20000 e da ITIL® é que ambas necessitam de um melhoramento contínuo, factor este que permitirá aumentar a cred-ibilidade e competitividade de uma empresa.

Referências Recomendadas:

ITIL®: www.itil.co.uk/COBIT: www.isaca.org/Template.cfm?Section=COBIT_BS ISO/IEC 20000-1:2005 and BS ISO/IEC 20000-2:2005: www.bsi-global.com/



Principais diferenças entre a ITIL v2 e V3 Parte IRENÊ CHIARI

Uma comparação entre a ITIL® v2 e V3 nos revela que todos os principais processos da ITIL® V2 permanecem na V3, com algumas mudanças substanciais. Entretanto, em muitos casos, a ITIL® v3 apresenta descrições de processos revisadas e melhoradas.

A principal diferença entre a V2 e V3 é a nova estrutura do Ciclo de Vida do Serviços: A ITIL® V3 é melhor entendida,organizando os processos de uma forma cíclica. Isto significa que a antiga estrutura do Suporte a Serviços (Service Support) e Entrega de Serviços (Service Delivery) foi substituída por um novo conjunto núcleo de cinco disci-plinas:

• Estratégia de Serviço - determina quais tipos de serviços devem ser oferecidos para quais Clientes ou mercados.

• Desenho do Serviço - identifica necessidades do serviço e idealiza novas ofertas de serviços, bem como alterações e melhorias aos serviços existentes.

• Transição do Serviço - constrói e implementa serviços novos ou modificados.• Operação do Serviço - realiza atividades operacionais• Melhoria contínua do Serviço - aprende com os sucessos e fracassos do passado

e melhora continuamente a competitividade, eficácia e eficiência dos serviços e processos.

A grande sacada da ITIL® V3 é que ela não reinventa a roda, ela complementa os pro-cessos da ITIL® V2 conhecidos com um número de novos processos e coloca mais ên-fase na produção de valor para o negócio. Devido a nova estrutura de ciclo de vida do serviço, todas as interfaces entre os processos ITIL® foram alteradas para refletir a nova estrutura de processo na ITIL® V3, então embora os processos da ITIL® V2 e V3 sejam conceitualmente idênticos, as suas interfaces mudaram.

Muitos me perguntam qual versão da ITIL® atualmente é a melhor pedida. A minha resposta é: Depende!

Se o intuito é somente se certificar para ocupar um posicionamento melhor de mer-cado, o que não considero uma “boa prática” mas é infelizmente a realidade do nosso mercado, vá de V3 sem pensar duas vezes.

Mas se o objetivo é botar a mão na massa e atuar ná pratica com implementação ou gestão de processos ITIL®, vai depender muito da maturidade atual da sua organização. Confesso que ainda não vi um número grande empresas se preocupando em imple-mentar a V3. E digo mais, utilizar a ITIL® de verdade em qualquer de suas versões já é um grande passo. Criei uma discussão em nosso grupo no LinkedIn justamente para abrir espaço para este debate. Participem!



No próximo artigo irei comentar de forma mais detalhada as mudanças e comparações entre as versões da ITIL®.



Principais diferenças entre a ITIL v2 e V3 Parte IIRENÊ CHIARI

Dando continuidade ao artigo sobre as principais diferenças entre as versões 2 e 3 da ITIL® sem maiores delongas, detalhamos as principais modificações e inclusões que ocorreram da transição da ITIL® v2 para a V3.

ESTRATÉGIA DO SERVIÇO

Gerenciamento de Portfólio de Serviço

• Gerenciar serviços como portfólio é um conceito novo adotado na ITIL® V3, in-troduzindo uma filosofia estratégica sobre como o portfólio de serviços deve ser desenvolvido.

Gerenciamento Financeiro

• Sem alterações relevantes. As atividades e objetivos do processo permanecem idênticas nas duas versões. Este processo é encontrado no livro de Entrega do Ser-viço (Service Delivery) na V2.

• Há um capítulo muito interessante e detalhado sobre ROI (Return of Investment).

DESENHO DO SERVIÇO

Gerenciamento de Catálogo de Serviço

• O Gerenciamento de Catálogo de Serviços foi incluído como um processo novo na V3.

• Na V2, há menção sobre o conceito do Catálogo de Serviço, porém de forma mui-to mais superficial. Felizmente na V3 foi dada a atenção merecida ao Catálogo de Serviços, que ganhou um processo só pra ele!

• A V3 introduz uma clara distinção no Catálogo de Serviços sob o ponto de vista de Serviços de Negócio (serviços visíveis ao Cliente, definidos por SLA´s) e Serviços de Suporte (serviços visíveis internamente pela organização de TI, definido por OLA´s ou UC´s.

Gerenciamento de Níveis de Serviço

• Atividades e objetivos do processo permanecem os mesmos nas duas versões, po-rém na V3 as atividades de revisão do serviço são fazem parte do livro de Melhoria Continua do Serviço

Gerenciamento de Segurança de TI

• A V2 fornece um guia sobre Gerenciamento de Segurança de TI em um livro sepa-



rado.• A V3 trata o Gerenciamento de Segurança de TI como parte do livro Desenho do

Serviço, resultando em uma melhor integração deste processo no Ciclo de Vida do Serviço.

• O processo foi atualizado para contemplar novas preocupações e desafios relacio-nados à segurança.

Gerenciamento da Arquitetura de TI

• O Gerenciamento da Arquitetura de TI estava contemplado dentro do Gerencia-mento de Aplicações, na ITIL® V2.

• A V3 fornece orientações sobre os problemas de Arquitetura de TI como parte de um capítulo sobre “atividades relacionadas à tecnologia”

• Gerenciamento de Fornecedores • Na V2 estava contemplado no livro Gerenciamento de Infra-estrutura (ICT)• Na V3, o Gerenciamento de Fornecedores é parte do processo de Desenho do Ser-

viço, criando uma melhor integração no Ciclo de Vida do Serviço.

TRANSIÇÃO DO SERVIÇO

Gerenciamento de Mudanças

• Basicamente, as atividades e objetivos do processo permanecem identicas em am-bas as versões.

• A V3 introduz o conceito de “Modelos de Mudanças”, definindo com mais ênfase tipos diferentes de Mudanças e como elas podem ser direcionadas.

Gerenciamento de Projetos (Planejamento e Suporte a Transiçao)

• O Planejamento e Suporte a Transição é um processo novo na V3. A ITIL® V2 abor-dava alguns aspectos deste processo dentro do processo de Gerenciamento de Li-berações, mas a V3 reforça consideravelmente está orientação

Gerenciamento de Liberações e Implantaçao

• A ITIL® V3 apresenta um detalhamento maior nas áreas de planejamento e teste da liberação. Isto levou a adição de dois processos dedicados na V3, que na versão anterior estavam sob o processo de Gerenciamento de Liberações: - Gerenciamento de Projetos (Planejamento de Transição e Suporte) - Validação e Teste do Serviço

Validaçao e Teste do Serviço

• O processo de Validação e Teste do Serviço é novo na V3. A V2 abordava alguns aspectos sobre testes de liberações dentro do processo de Gerenciamento de Li-



berações mas a V3 reforça consideravelmente este aspecto.• Os principais adendos na V3 estão nos detalhamentos durante os estágios de tes-

tes durante a Transição do Serviço e descrições das abordagens de testes corres-pondentes.

Gerenciamento do Conhecimento

• O Gerenciamento do Conhecimento foi adicionado como um processo novo na ITIL® V3.

• Muitos aspectos do Gerenciamento do Conhecimento estão coberto por vários processos na V2 – por exemplo, o Gerenciamento de Problemas era (e continua sendo na V3) o responsável por gerenciar a base de Erros Conhecidos.

• Na V3, entretanto, o Gerenciamento do Conhecimento é definido como único pro-cesso responsável por centralizar e prover conhecimento para todos os outros pro-cessos de ITSM.

OPERAÇÃO DO SERVIÇO

Gerenciamento de Eventos

• O Gerenciamento de Eventos é parte do livro ICT Infrastructure Management na ITIL® V2.

• As atividades e objetivos do processo são praticamente idênticos na V2 e V3.• A ITIL® V3 vê o Gerenciamento de Eventos como um importante gatilho para os

processos de Gerenciamento de Incidentes e Gerenciamento de Problemas.

Gerenciamento de Incidentes

• As atividades e objetivos do processo permanecem praticamente idênticos nas duas versões.

• A ITIL® V3 faz distinção entre Incidentes (interrupções no serviço) e Requisições de Serviço (solicitações padrões oriundas de usuários, ex: reset de senha).

• Requisições de Serviço não são mais atendidas via processo de Gerenciamento de Incidentes, para isso existe na V3 um novo processo chamado Cumprimento de Requisição.

• Há agora um processo dedicado para lidar com emergências (“Incidentes Críticos”).• Foi adicionada uma interface entre os processos de Gerenciamento de Eventos e

Gerenciamento de Incidentes. Eventos significantes são agora considerados como gatilho para a criação de um Incidente.

Cumprimento de Requisiçao

• O Cumprimento de Requisição foi adicionado como um novo processo na V3 com o objetivo de lidar de forma dedicada com Requisições de Serviços. Esta mudança



foi motivada claramente pela distinção mais do que bem-vinda feita na V3 entre Incidentes e Requisições de Serviços.

• Na V2, o Cumprimento de Requisições era atendido pelo processo de Gerencia-mento de Incidentes.

Gerenciamento de Acessos

• O Gerenciamento de Acessos foi adicionado como um novo processo na V3.• A decisão de incluir este processo dedicado foi motivada por razões de segurança

de TI, como garantir acesso a serviços de TI e aplicações somente para usuários autorizados

Gerenciamento de Problemas

• Atividades e objetivos do processo permanecem praticamente idênticos nas duas versões, porém um novo sub-processo chamado “Revisão de Problemas Graves” foi introduzido para revisar o histórico de solução de Problemas graves buscando a prevenção de recorrências e obter lições aprendidas para o futuro.

MELHORIA CONTÍNUA DO SERVIÇO

• A V2 continha algumas atividades de Melhora Contínua do Serviço dentro do pro-cesso de Gerenciamento de Nível de Serviço, por exemplo as Revisões do Serviço e gestão de um Plano de Melhoria do Serviço.

• A ITIL® V3 expande esta abordagem em um livro completamente novo, introdu-zindo processos dedicados para a avaliação e melhoria de serviços e processos.



Serviços: a ponte perdida entre negócios e TIBRUNO CAIADO

Não é difícil notar que a principal mudança entre as versões 2 e 3 da biblioteca ITIL® é o estabelecimento do ciclo do serviço. Se antes o serviço ficava meio tímido perto dos robustos processos de entrega e suporte, agora ele foi definitivamente empossa-do como o astro principal. E não é por acaso: o serviço é o cerne do VALOR entregue ao cliente, como mostra a sua própria definição (em tradução livre):

Serviço é o meio de entregar valor ao cliente, facilitando o atingimento dos resultados que ele quer atingir sem que ele tenha que incorrer em custos e riscos específicos.

Parece complicado, mas não é. Significa que o cliente não quer fazer ele mesmo, mas contratar alguém para tal. O “como” é responsabilidade deste alguém (o provedor) e o cliente espera apenas o deliverable acordado. É uma forma diferente de dizer que o serviço é uma caixinha preta com interfaces bem definidas e que os mecanismos inter-nos são uma responsabilidade exclusiva do provedor.

Por exemplo, pense numa máquina que vende latinhas de refrigerante. O cliente não quer (e nem precisa) saber como o fabricante faz a manutenção da máquina ou como são os mecanismos internos dela. O objetivo dele é tão simples quanto ter um refrig-erante gelado, no momento desejado. Esse é o “resultado” que o cliente quer atingir como descrito na definição do serviço e é esse resultado que determina o deliverable do serviço e até níveis de serviço. Portanto:

• RESULTADO ESPERADO PELO CLIENTE: um refrigerante gelado, no momento desejado

• MEIO QUE FACILITA O ATINGIMENTO DOS RESULTADOS (“serviço”): Máquina de refrigerante

• NÍVEIS DE SERVIÇO: Disponibilidade: 24x7 (afinal de contas, qualquer hora é hora de um refrigerante) / Temperatura: 8°

Parece simplório, mas são os mesmos conceitos que estão embutidos no ciclo do serviço do ITIL®. Da estratégia, passando pelo design, transição, operação e melhoria contínua, o foco é um só: QUAL O RESULTADO QUE MEU CLIENTE ESPERA ATINGIR? E por consequência, como eu defino uma estratégia e toda a minha operação para que ela entregue os serviços esperados e que irão suportar o meu cliente no atingimento dos seus objetivos e resultados.

O serviço parece tão ridiculamente óbvio que ninguém sabe mais qual é ou sente a ne-cessidade de defini-lo. A ”conexão” entre o “serviço” e os resultados de negócio que o cliente quer atingir se perdeu no meio do caminho. Enquanto isso, as organizações de TI continuam a prestar os serviços “óbvios”: suporte UNIX, correio eletrônico ou pro-cessamento BATCH, só pra dar alguns exemplos. Nesse contexto, níveis de serviço di-



ficilmente vão dizer algo para o negócio e a organização de TI vai continuar como uma “conta contábil pra alocar despesas de tecnologia”. E só. Não será o parceiro estratégico que entende quais são os resultados que o negócio quer atingir e molda seus serviços de acordo com eles.

Vamos dar um exemplo. Pense numa empresa de transportes aéreos. O que acontece-ria se o website que vende passagens parasse? A venda através da web e conseqüen-temente boa parte da fonte de renda da empresa iria ser interrompida. A criticidade do site é muito evidente e por isso mesmo, é um ótimo candidato a “serviço”. Dentro do ciclo, essa definição começa na estratégia de TI e toda a estrutura da organização de TI é desenhada e operada para garantir que esses serviços sejam atendidos. O fato de ela ser também “desenhada” (e não apenas operada) significa que esse trabalho é proa-tivo e inclui desde a arquitetura dos componentes, a dimensionamento de equipes e definição de métricas. Não estamos falando de um foco total (mas reativo) quando um website cai e o gerente grita pedindo a restauração do serviço imediatamente. Esta-mos falando em estratégia, coordenação, sincronização e gestão.

Para que essa estratégia seja efetiva, uma definição de serviços alinhada com os obje-tivos de negócio é um passo fundamental. Usar “aplicações críticas” pode ser um bom começo, mas não é por si só uma estratégia estruturada e coerente. É preciso pensar em processos de negócio e KPIs (Key Performance Indicators) operacionais e finan-ceiros. Em qualquer empresa, existem processos chave ligados a receita, rentabilidade (como percentual da receita), ciclo operacional de caixa (contas a pagar e a receber) e depreciação e amortização de ativos. No caso específico do web-site, ele se insere em um processo de geração de receita, ligado a um sub-processo de venda direta ao con-sumidor e por sua vez ligado a KPIs como receita por canal e receita por cliente. Nesse contexto, o objetivo de TI não é garantir 99,99999% de disponibilidade de um web-site, mas sim facilitar o atingimento, por parte do negócio, de seus objetivos de receita por canal de venda. Isso significa, por exemplo, garantir a disponibilidade do web-site, o dimensionamento para o volume corrente e planejado de vendas e o suporte ade-quado durante picos sazonais e campanhas, entre outros aspectos.

Esse alinhamento começa de cima e deve permear a organização, começando do en-tendimento por parte do CIO dos objetivos da corporaçao, passando por um desen-ho e arquitetura adequados e chegando até ao atendimento veloz, gentil e orientado a serviço por parte do atendente do service desk. Evidentemente, estamos falando em uma cultura focada no cliente e em suas necessidades e que está apoiada em ferra-mentas e processos de gestão. Para chegar a esse estado, a implantação de processos ITIL® é apenas o começo de uma jornada sem fim, cujo objetivo não é chegar, mas mel-horar continuamente em busca da excelência.



Sistemas de qualidade: a ilusão da melhoria continuaBRUNO CAIADO

Todo mundo quer qualidade. O fornecedor, o cliente, o dono da empresa ou até os próprios funcionários das empresas. O que poucos sabem responder com convicção e segurança é: o que afinal de contas é qualidade? É fácil pedir um serviço de “qualidade”, o difícil é tanto definir, quanto fornecer e ainda ter que melhorar “continuamente” a tal qualidade.

Para exemplificar, vamos recorrer a quem colocou em prática com maestria o concei-to de melhoria contínua em linhas de produção: a Toyota. De forma bem simplificada, o conceito adotado pela Toyota (e por milhares de outras empresas nos dias de hoje) busca uma otimização entre não-conformidades e custo de produção, sendo “não-con-formidade” qualquer evento que não se enquadre em uma faixa de referência. O fato de estarmos falando de uma faixa de valores é um ponto chave: quer dizer que “exces-so de qualidade” é uma não-conformidade também!

Um caso emblemático ocorreu na Nissan antes da revolução promovida pelo brasilei-ro Carlos Ghosn, hoje considerado uma referência mundial na gestão de grandes em-presas. A fábrica japonesa tinha orgulho da perfeição com que fabricava seus faróis: os recortes da superfície eram tão perfeitos, tão perfeitos, que apenas engenheiros com um microscópio conseguiam reconhecer sua qualidade “superior”. Os clientes não da-vam à mínima para os faróis, mas os custos evidentemente iam às alturas. A questão acabava sendo: o que adiantava ter qualidade na visão dos engenheiros se quem iria usar os carros não reconhecia essa qualidade? E pior: não estava comprando os carros e ainda achava os carros da concorrência melhores!

O pessoal de marketing veio à tona para tentar descobrir o que os clientes queriam de verdade. Não foi nada surpreendente descobrir que os clientes queriam carros con-fiáveis, com design moderno e com preços razoáveis. Depois de descobrir o óbvio ulu-lante, os engenheiros voltaram às pranchetas e focaram na confiabilidade dos faróis e não na precisão dos recortes da superfície. O resultado? Faróis mais baratos, mas que iluminavam tão bem quanto os primeiros. Esse princípio foi empregado não apenas nos faróis, mas no design, no desempenho, no espaço interno e o resultado foi um au-mento espetacular nas vendas, na receita e, pasme, na satisfação dos clientes. E mais: a melhoria contínua passou a se concentrar em um ajuste fino entre um atendimento cada vez mais próximo dos desejos dos clientes e os custos de produção, o que parece óbvio, mas é simplesmente a fórmula mágica para a prosperidade nos negócios. O que nos leva a um conceito de qualidade ligado à sustentabilidade do negócio, que contin-uamente se ajusta para:

• Atender aos clientes em termos de preço e adequação às suas necessidades e ex-



pectativas;• Estabelecer uma relação coerente entre preço e custo;

Isso significa que qualidade não é uma referência absoluta, mas uma relação entre preço e expectativa! A pergunta natural que se segue é: porque então precisamos de “referências” como os sistemas de qualidade ISO 9000, 20000, 27000, etc? A resposta é simples: para que serve uma referência de qualidade sem uma estrutura de acom-panhamento e ajuste? Implementar um sistema de qualidade não é definir padrões ab-solutos, mas estabelecer os pontos de controle necessários para que os produtos e serviços entregues estejam dentro das “faixas” de qualidade definidas. Ou seja: nenhum ISO vai lhe dizer qual é a sua faixa de qualidade, mas sim o que você precisa controlar e documentar para garantir que seus produtos estejam dentro dela. Especificamente para serviços de TI, o sistema de qualidade ISO 20000 mostra o mínimo necessário (e também o desejável) para que um serviço seja entregue de acordo com os acordos e expectativas dos clientes, sejam lá quais forem estas expectativas. E é justamente aí que entra a “ilusão” de sistemas de qualidade mal implementados. Se uma empresa for certificada como aderente à ISO 20000, mas:

• Não definir sua faixa de qualidade de forma coerente e sustentável;• Não implementar um sistema gerencial que leve a sério as referências de qualida-

de e REALMENTE promova os ajustes necessários continuamente;• Não quebrar as barreiras e silos organizacionais com seus próprios e peculiares

conceitos de “qualidade”;• Não promover uma visão de serviço em sua organização, fazendo das expectativas

e necessidades dos clientes sua principal referência na busca pela excelência.

.....então, a certificação ISO 20000 será mais um belo quadro pendurado em sua pare-de.

E tenho dito!



USMBOK o ITIL para gerenciamento de qualquer serviçoRENÊ CHIARI

Enquanto a ITIL vem evoluindo do contexto de infraestrutura de TI para serviços de TI, o USMBOK faz o caminho contrário, partindo do negócio.

É sabido que os conceitos preconizados pelas boas práticas de gerenciamento de TI, particularmente a ITIL, poderiam ser aplicáveis em qualquer outro contexto de geren-ciamento de serviços. E quando eu digo outro contexto, me refiro a serviços ‹não-TI›.

A proposta do USMBOK (Universal Service Management Body of Knowledge) é justa-mente essa. O autor, Ian Clayton, que por um acaso é co-fundador do itSMF-USA, de-screve o USMBOK como:

“Um conjunto completo de reflexões e métodos do gerenciamento de serviços, uni-versalmente aplicáveis a qualquer empresa de serviços, incluindo uma organização de TI que é gerenciada como um fornecedor de serviços. Com seus conceitos e méto-dos enraizados no gerenciamento de produtos, é universalmente aplicável em todos os setores de serviços e também pode atuar como um método de transformação para qualquer organização que queira mudar e operar como um prestador de serviços, es-pecialmente em uma organização de TI.”

A base para o USMBOK e como ele aborda o gerenciamento de serviço está profun-damente enraizada nos conceitos de gestão de produtos e da teoria de marketing de produto, respeitando e aproveitando o trabalho de gigantes do marketing, como The-odore Levitt, Richard Chase, Richard Normann, Mary Jo Bitner, e tantos outros.

Na verdade, a definição de gerenciamento de serviços e os elementos da estrutura de gerenciamento de serviço detalhados no USMBOK são elaborados a partir de reflex-ões sobre a gestão de negócios. O USMBOK foi desenvolvido usando o pensamento ‘de fora para dentro’, ou o pensamento centrado no cliente.

Já a nossa boa e velha ITIL é tradicionalmente focada em organizações de TI. Nas mais recentes atualizações amadureceu para um modelo de processo com foco no gerenci-amento de ciclo de vida de um serviço, o que é um bom sinal.

Minha opinião é que, em algum momento, USMBOK e ITIL poderão ser referências complementares. Uma partindo dos padrões da indústria e permeando o mundo de TI, e a outra nativa do mundo de TI e permeando horizontes mais amplos. E como um bom curioso, já estou com o meu exemplar.

Para saber mais sobre o USMBOK, visite www.usmbok.com

Artigos para Aquecer a Carreira



Certificaçoes abrem portas mas não garantem o seu empregoRENÊ CHIARI

A verdade é que as certificações vão dar destaque ao currículo, e em muitos casos serão de fato o passaporte para um emprego. Mas uma coisa é conseguir um emprego, a out-ra é se manter nele. Para isso serão necessários mais que papéis com chancelas, PIN´s e assinaturas bonitinhas. Competências e habilidades pessoais deverão ser demon-stradas no dia a dia.

Antes de entrar em uma bela enrascada, recomendo refletir sobre os seguintes pontos:

1. Antes de se candidatar a uma vaga, procure entender quais serão suas atividades, a sua rotina, principalmente se você estiver mudando de uma função técnica para uma função de gestão. Em alguns casos a mudança é bem agressiva e vai exigir al-guns meses para adaptação. Levei três meses para “aterrissar” e entender o que de fato eu estava fazendo naquela função quando migrei da área técnica para a área de gestão. Corri um risco enorme pois não consultei ninguém antes. Não cometa o mesmo erro.

2. Seja prudente, não minta. Assumir coisas que nunca fez e depois ficar com uma tremenda saia justa por não ter a miníma ideia de como realiza-las pode custar o seu emprego, e pior, a sua reputação. O mundo de TI é muito pequeno, não vale a pena correr este risco. Se você tem apenas um certificado na mão e nenhuma ex-periência, vá em frente. Muitas empresas preferem contratar profissionais mais “crus” e transforma-los nos moldes da empresa.

3. Evite passar a imagem de “sabe-tudo”. Quando acumulamos um certo número de certificações e experiência prática tendemos a achar que conseguimos lidar com todos os desafios facilmente. Não caia nessa. Me recordo de no mínimo três mo-mentos da minha carreira onde conclui que não sabia nada de ITIL. Manter a hu-mildade e estar sempre aberto a novos pontos de vista é uma boa forma de não prejudicar um projeto importante e como consequência ser convidado a procurar outra empresa.

4. Por ultimo e não menos importante: Esteja antenado. Coisas acontecem e mudam o tempo todo. A ITIL mudou de v2 para v3 e em 2011 já ganhou um update da v3, e não foram poucas mudanças. Estar atualizado pode ser o pulo do gato e garantir os poucos centésimos de pontos que o classificam em uma seleção de emprego. Além disso, a vivência prática de outros pode servir como bagagem para futuros desafios em sua carreira.

Bem, mas se você leu este artigo até aqui, ou acompanha as discussões no LinkedIN e outros fóruns sobre o assunto, então já é sinal de que essa dica você já considerou! ;-)



Redes Sociais: 5 erros a serem evitados no LinkedINRENÊ CHIARI

Eu costumo separar as redes sociais em dois tipos: as sociais pessoais e as sociais profis-sionais. Das profissionais, fico com o Linkedin sem sombra de dúvidas. Além de ter um visual muito mais clean que o Facebook (que é a moda atual), o design é totalmente voltado para o mundo corporativo.

Ainda vejo muitos exageros dos companheiros profissionais de TI, que acabam crian-do alguns jargões totalmente desnecessários e acabam banalizando funcionalidades bacanas dentro do Linkedin. Ai vão as principais atitudes que devem ser evitadas:

• Assinatura “Sopa de Letrinhas” - Você já deve ter visto alguns profissionais que in-corporam títulos conquistados em seus nomes. Por exemplo: Zezinho, PMP, ITIL®, CISA, CISM, Black Belt...além de ser uma tremenda poluição visual, mesmo que tenha boas intenções você pode ser considerado um “mala”.

Que tal ser um pouco mais discreto? O Linkedin permite que você adicione suas espe-cializações em seu perfil. Além disso, já existe um app chamado box.net que permite que você insira arquivos ao seu perfil. Inserir os seus certificados em PDF em uma past-inha discreta fica muito mais profissional.

• Caçador de Recomendações - As recomedações são extremamente importantes aos olhos de recrutadores e possíveis parceiros de negócio. Nada como ganhar aquela recomendação de seu ex-gerente ou de um Cliente. Mas cuidado com os exageros, tenha sempre em mente que uma boa (e sincera) recomendação vale mais do que 30 recomendações estilo «Linha de produção». É a mesma coisa que vender alfinete de plastico no leilão online só pra ter um número maior de qualifi-cações positivas.

• Cuidado com a auto-promoçao - É sempre interessante anunciar uma nova con-quista profissional, seja uma certificação, um novo emprego, etc, mas é importan-te ter bom senso nessas horas. Fazer da rede uma espécie de Twitter e comentar cada passo de sua vida profissional pode tornar a leitura de suas notas cansativas, e mais uma vez, você corre o risco de virar “o mala”. O Linkedin tem seções muito bem diferenciadas para que você divulgue uma novidade, uma atualização de seu perfil, uma nova discussão e até mesmo uma vaga de emprego. Utilize-as!!

• Aqui se diz, aqui se paga - Cuidado com o que escreve por ai. Falar mal da ex--empresa ou de ex-colegas de trabalho pode ser uma atitude mal interpretada por qualquer pessoa de RH que estiver analisando o seu perfil em um processo seleti-vo. O que? Acha mesmo que as empresas de RH não digitam o seu nome no Google para saber o que você anda/andou aprontando pelo mundo virtual? Bem-vindo aos tempos modernos da total falta de privacidade! ;-)



Obs: já ouvi vários casos de contratações para cargos executivos onde a seleção foi fei-ta através do Linkedin. Vale a dica!

• Use o Linkedin estritamente para fins profissionais - A proposta da rede social é muito clara: é uma rede social voltada para profissionais! Deixe para participar da comunidade “Eu como pizza fria amanhecida com Toddy” em redes como Orkut e Facebook, e lembre-se de gastar um tempo configurando a privacidade do seu perfil e evitar futuros constrangimentos, por exemplo, o seu chefe recebendo uma atualização do seu Facebook informando que você acabou de atacar uma máfia, em pleno horário de expediente...

Com estes pequenos cuidados você garante um perfil clean e atraente em uma das re-des sociais voltadas a profissionais mais promissoras da atualidade.

Já tem uma conta no Linkedin? Então aproveite para visitar e fazer parte do grupo ITIL® na Prática



Tirei a certificação ITIL e agora?GUSTAVO TAVARES

Antes de qualquer coisa Parabéns. Se vc possui uma certificação ITIL® você comprovou, por meio de um sistema de avaliação confiável, que possui os conhecimentos necessári-os para implantar e gerenciar as práticas do ITIL® em uma organização. Existem, é cla-ro, diferentes níveis de conhecimento. Um profissional com uma certificação de funda-mentos não possui as mesmas comprovações de conhecimento do que um profissional certificado como ITIL® Manager. Mas a despeito do nível de conhecimento, ambos são profissionais preparados para implantar e gerenciar o ITIL® em uma organização? Não necessariamente...

Antes de responder diretamente esta pergunta, me permita buscar auxílio nas teorias modernas de recursos humanos. Nestas teorias existe um conceito muito relevante que é o conceito de competência pessoal. Uma competência pessoal pode ser enten-dida como um atributo de determinado profissional que o possibilita atingir determi-nado objetivo. Ao dizermos então que um profissional possui preparo para implantar e gerenciar o ITIL® em uma organização estamos também dizendo que o profissional possui a competência de implantar e gerenciar processos baseados no ITIL®. Até aí nada de novo. Mas voltando a nos sustentar nas teorias de RH, proponho entender-mos um pouco mais o que são as competências.

As competências são atributos do profissional compostas de três elementos: conhec-imentos, habilidades e atitudes. Cada competência possui uma diferente combinação dos três elementos. E os três elementos devem, obrigatoriamente, estar presentes para que um profissional possa ser possuidor de determinada competência. As certificações profissionais, sejam acadêmicas ou emitidas por instituições de classe, comprovam que um profissional possui os conhecimentos exigidos para exercer determinada ativ-idade. Mas elas não comprovam que o profissional possui as habilidades ou atitudes necessárias para atingir os objetivos relacionados àquela atividade. E não teria como ser diferente. As habilidades e atitudes relacionadas a uma competência são direta-mente relacionadas ao contexto onde a competência será aplicada. Embora os conhe-cimentos tenham um caráter mais universal, as habilidades e atitudes para aplicar os conhecimentos em um ambiente militar são totalmente diferentes das habilidades e atitudes necessárias para aplicar os conhecimentos em um ambiente privado. Mesmo em um ambiente privado (ou militar) as especificidades de uma organização exigem habilidades e atitudes diferentes de outra. Criar um sistema de avaliação que seja ca-paz de medir habilidades e atitudes de forma padronizada é um exercício que tende ao fracasso, seja por questões metodológicas ou por questões de abrangência de situ-ações possíveis.

Desta forma, você que é um profissional certificado em ITIL® precisa descobrir quais habilidades e atitudes são necessárias para obter sucesso na implantação e no geren-



ciamento de processos baseados no ITIL® e deve se preocupar em desenvolver esta competência. O certificado foi o seu primeiro passo; existem outros a frente. E se quer saber, os próximos não serão tão fáceis como foi a certificação. A parte ruim é que vc não vai conseguir uma lista de todas as habilidades e atitudes que são necessárias para adquirir ou desenvolver sua competência. Isto porque esta lista não existe. Como já falamos, cada ambiente ou situação requer um conjunto de habilidades e atitudes dif-erentes. Mas acredito que possamos discutir um pouco mais a respeito.

Se pensarmos no ITIL® como modelo de gestão de operações de TI, temos um conjun-to de papéis que são definidos no framework. E na maior parte estes papéis já trazem um conjunto de habilidades e atitudes relacionadas. Mas e as habilidades e atitudes do profissional que vai implantar e gerenciar uma iniciativa de adoção do ITIL®? Eu tenho alguns palpites sobre as habilidades necessárias:

1. Deve saber ouvir e interpretar as pessoas: iniciativas de adoção do ITIL® envol-vem mudanças na maneira de trabalhar das pessoas. Mas o modo atual de traba-lho de uma organização não é ruim simplesmente porque não é aderente ao ITIL®. Na verdade, existem inúmeros casos onde o modelo de trabalho atual é melhor do que o prescrito no ITIL®. Um profissional com competências de implantação e gerenciamento de iniciativas de ITIL® deve ser capaz de ouvir as restrições e “re-clamações” das pessoas envolvidas e deve ser capaz de avaliar quando as práticas atuais são mais adequados ou mesmo melhores do que as práticas prescritas no ITIL®;

2. Deve ser capaz de entender o contexto da organizaçao: iniciativas de adoção do ITIL® ocorrem em um ambiente cheio de restrições e influenciadores. As pres-crições do ITIL® são perfeitas para serem aplicadas ipses literis em um ambiente perfeito. Ambientes imperfeitos exigem adaptações das prescrições às limitações e influenciadores existentes. Um profissional com competência em implantação e gerenciamento de iniciativas de ITIL® deve ser capaz de interpretar estas limita-ções e descartar prescrições do ITIL® que não sejam compatíveis com a organiza-ção;

3. Deve ser capaz de imaginar soluções alternativas: Como já conversamos, existem inúmeras restrições e influenciadores determinando como uma iniciativa de ado-ção do ITIL® evolui. Em alguns casos estes limitadores chegam ao ponto de inviabi-lizar a adoção de determinadas práticas fundamentais para o sucesso da iniciativa como um todo. Nestas situações, o profissional com competência em implantar e gerenciar iniciativas de ITIL® deve conseguir formular soluções alternativas que garantam o sucesso do projeto mesmo que uma ou mais das suas partes críticas tenham sido descartadas.

A lista pode continuar por muitos itens ainda. E olha que eu nem comecei a falar das atitudes. Arrogância, impaciência, falta de flexibilidade são algumas, por exemplo, que não combinam com um profissional de ITIL®. Na verdade, quando estas atitudes estão



presentes elas se tornam uma das causas do insucesso dos projetos. O pior são os ca-sos em que um profissional, ao obter os conhecimentos e comprovar que possui estes conhecimentos por meio de uma certificação, se torna arrogante por conta do novo título e passa a levar seus projetos ao fracasso. Infelizmente ainda acontece muito.

Mas estas são as exceções. Se vc se certificou recentente, desejo sucesso no desenvolvi-mento da sua competência em implantar e gerenciar iniciativas baseadas no ITIL®. Se vc já se certificou há mais tempo, também desejo sucesso no desenvolvimento de sua competência, porque esta é uma atividade que não acaba nunca.



Vale a pena investir em certificaçoes profissionais?CLAUDIA MARQUESANI

Um colega me perguntou um dia desses: o que é mais importante para ter sucesso profissional – ser certificado ou ter experiência prática em gestão de serviços?

Gostaria de falar um pouco sobre CARREIRA e a busca pelo sucesso …

É apenas uma opinião (extremamente pessoal), mas acredito que: o importante para ter sucesso profissional é ter COMPETÊNCIA para fazer aquilo o que você se propôs.

O QUE É COMPETÊNCIA?

COMPETÊNCIA = CONHECIMENTO + HABILIDADE + ATITUDE

CONHECIMENTO é ter formação. Imaginem um médico. Ele precisa do diploma univer-sitário para exercer a medicina. Precisa estar formado. Ter conhecimento é investir em uma boa universidade, em certificações, em cursos técnicos, pós graduação, MBA, at-ualizações constantes que todos nós estamos cansados de saber que são necessários, mas que não são suficientes por si só. E porque será que sozinho CONHECIMENTO não diz nada?

De que vale ter todo o CONHECIMENTO do mundo, se não tivermos HABILIDADE? Quantas pessoas não passam anos estudando e quando se “aventuram” no mercado de trabalho, não tem nenhuma experiência, nenhuma vivência PRÁTICA para exercer determinada funçao. Como investiram na carreira durante anos (e esse investimento é sempre muito alto), querem o retorno imediato e é muito difícil que isso aconteça. Nós investimentos muito tempo e dinheiro nessas formações e o mercado de trabalho não segue esse ritmo. Não adianta achar que você vai fazer a maior certificação em ITIL® ou segurança e que com isso seu salário dobrará. Dá para imaginar um médico sem ha-bilidade? Um médico que não fez residencia? Um residente ganhando um salário altís-simo? Vamos com calma…

Se você tem CONHECIMENTO e HABILIDADE, é meio caminho andado. Mas também não é suficiente. Durante um processo seletivo ou uma avaliação de promoção, sua ATITUDE também será avaliada. E digo com TODA CERTEZA DO MUNDO: ás vezes isso é mais importante para quem irá tomar a decisão do que conhecimento ou hab-ilidade. Atitudes sao habilidades interpessoais, como por exemplo: a capacidade de ser positivo diante de pressões, a capacidade de trabalhar em equipe, sua resiliência (trabalhar normalmente mesmo diante de situações adversas)… enfim, é sua forma de “encarar” o trabalho e de fazer dele algo positivo, construtivo e bem sucedido. Imagi-nem o médico que entra em pânico quando seu paciente, na sala de cirurgia , sofre uma parada cardíaca ? O que ele faz? Sai correndo? Começa a chorar? Ou toma a frente e tenta ressuscitar o paciente? Essa diferença de comportamento se chama atitude!



Então quando sou perguntada se vale a pena investir em certificações, eu respondo: SIM!!!

Agora se me perguntarem se só isso é suficiente, eu digo com toda certeza : NÃO!!!

É preciso muito mais que um diploma colado na parede para ser um bom profissional. É necessário ter CONHECIMENTOs, HABILIDADEs e ATITUDEs suficientes para ex-ercer sua função . Eu realmente acredito que um profissional de sucesso é aquele que tem a sabedoria para equilibrar essas três variáveis.

Seja você um deles. Começar a investir em si mesmo, além de dar um prazer enorme, aumenta a auto estima e as possibilidades de sucesso em sua carreira. Digo possibili-dades, porque tem uma quarta variável , uma coisinha que ás vezes ninguém se lembra , mas que também pode fazer toda a diferença, A SORTE!

Só que não vamos falar dela hoje porque está ficando tarde e eu quero “curtir” meu feriado… Mas que dá um assunto para outro post, isso dá! Pensem nisso!

Artigos Para Por a Mao na Massa



5 dicas para a Gestão de Problemas ProativaRENÊ CHIARI

Uma das principais atividades do processo de Gerência de Problemas é identificar tendências, através do sub processo de gestão proativa de Problemas.

No dia a dia, esse conceito acaba se perdendo, pois a gestão de problemas acaba sem-pre demandando quase 100% de seu tempo a identificar a causa raiz dos problemas relacionados a incidentes críticos (super reativos!). Isso se dá de forma desesperada e sob forte pressão. A alta administração exige que as causas e soluções de contorno se-jam identificadas rapidamente e isso muitas vezes ocasionam respostas ineficazes, de um processo onde tempo está diretamente relacionado a qualidade da investigação e solução proposta.

Ou seja, não sobra tempo para analisar tendências de capacidade , de disponibilidade e de incidentes recorrentes. Fica quase impossível iniciar planos de melhorias e aval-iar se a forma como estamos tratando os problemas maiores está sendo conduzida de maneira adequada.

Os ganhos em realizar uma análise de problemas proativa podem ser:

• Operacionais: ao analisar a tendência de incidentes e identificar que a solução de incidentes recorrentes irá beneficia o Service Desk e áreas de suporte especiali-zados, solucionando incidentes repetitivos. Isso tratá menos carga de trabalho e maior tempo para ser dedicado em melhorias (parar de apagar incêndio).

O detalhe é que isso acaba sendo um beneficio indireto para o negócio também. Por exemplo: Imaginem que o Service Desk gasta aproximadamente 10% de seu tempo, em uma pequena empresa, resolvendo incidentes em primeiro nível de senha bloqueada. A gerencia de problemas poderá investigar a causa raiz desses incidentes e resolve-los definitivamente. Com isso sobra mais tempo para o Service Desk atender ligações, maior disponibilidade para o usuário, aumento da eficiência e reflexo na satisfação do usuário e do negócio.

• Negócio: quando uma análise de tendências inibem e previnem incidentes que po-deriam vir a acontecer e trazer impacto direto ao negócio. Por exemplo: junto com a disciplina de gerenciamento de capacidade, utilizar ferramentas para a identifi-cação de tendências e atuar para evitar que incidentes relacionados a capacidade ocorram.

A seguir, listo algumas sugestões para implementar esta atividade:

1. Não é simples fazer uma análise proativa de problemas. Identifique as disciplinas parceiras:



- Incidentes poderá apresentar tendencia de incidentes recorrentes que deverão ser investigados pela gestão de problemas.

- Disponibilidade poderá identificar tendências de issues relacionados a disponi-blidade e atuar em conjunto com o gerenciamento de problemas para solucio-ná-los.

- Capacidade também possui técnicas para que issues de capacidade sejam iden-tificados e poderá contar com a gerencia de problemas para tratá-los.

Lembre-se : a gerencia de problemas sozinha não é nada. É um processo extremamente dependente dos outros.

2. Defina os papeis e responsabilidades. Escolha sempre os técnicos mais experien-tes, que conheçam muito bem tanto o ambiente quanto o negócio da empresa. Nem preciso comentar que o Gestor de Problemas é o dono disso tudo, né? Documente as principais tarefas, e seus respectivos donos. Você pode usar uma matriz RACI para facilitar. Temos um modelo em nossa área de Downloads.

3. Defina o que você quer fazer (e o que já consegue imediatamente) , a metodolo-gia e periodicidade. Fará uma análise de incidentes recorrentes? Uma análise de tendências de relatórios de capacidade? Uma análise de issues de disponibilida-de? Será aplicada alguma técnica ou metodologia específica? Serão feitas reuniões com as equipes técnicas para discutir os problemas? Quantas vezes? Qual será o meio de comunicação?

4. Definir quais serão os controles de performance e resultados desta atividade. De-fina alguns controles para saber se as atividades estão sendo desempenhadas sa-tisfatóriamente, e se os resultados esperados estão sendo atingidos. Ex: % de re-dução de incidentes recorrentes , # de incidentes evitados através da investigação e solução definitiva de problemas.

5. A quinta e principal dica é: Não acelere o processo e defina equipes separadas para a gestão proativa e reativa de problemas. A gestão proativa de problemas precisa de tempo para investigar, analisar cada variável envolvida no processo. A gestão reativa sofre pressões para explicacões e soluções , sejam elas de contorno ou de-finitivas. O tempo da gestão de problemas reativa é mais curto, infelizmente. Se as duas equipes tiverem o mesmo papel dentro de uma organização, a gestão de pro-blema proativa simplesmente ficará em segundo plano e deixará de ser feita.



5 passos para definir um bom Acordo de Nível de Serviço SLARENÊ CHIARI

Apesar do SLA ter se tornado um jargão bastante conhecido e utilizado, é comum en-contrar documentos mal escritos, com falta de informações e definições confusas até para o próprio provedor de serviços. Isso não é bom nem para o provedor, e nem para o cliente, pois dá margem para discussões que podem comprometer o bom relacion-amento entre as partes, e em casos mais graves até causar uma rescisão contratual (no caso de provedores de serviço externos) ou a decisão pelo outsourcing (no cado de provedores de serviço internos).

É preciso entender que um acordo de nível de serviço é muito mais do que um docu-mento descrevendo prazos de atendimento e resolução de chamados. Trata-se de um acordo que deve deixar claro todas as garantias que o provedor de serviço oferece em relação aos serviços que foram contratados, e a forma como estes níveis de serviço serão medidos, reportados e melhorados continuamente.

Para resumir: o (bem) combinado nao sai caro!

Se você nunca desenvolveu um SLA ou acha que o utilizado atualmente na sua empre-sa precisa de ajustes, responder as seguintes perguntas é um bom começo. Lá na ITIL (Service Design) você vai encontrar um modelo bastante robusto de um Acordo de Nível de Serviço. O que eu estou sugerindo adiante é uma abordagem mais simples e realista.

Pergunta 1: O que?

Qual o serviço que está sendo objeto deste acordo? Contextualizar o serviço já no primeiro capítulo é uma boa pedida. Aqui também pode-se fazer referência ao Catálo-go de Serviços.

Importante incluir as exclusões, que são as situações em que este acordo de nível de serviço não é aplicável. Isto evita uma série de aborrecimentos futuros. Um dos assun-tos mais comumente esquecidos é o “Stop SLA” (ou pausa no SLA), onde são consider-ados os períodos em que os casos estão sob tratamento de suporte do próprio cliente, ou seja, o provedor de TI não deveria assumir o ônus por este período de tempo.

Pergunta 2: Quando?

Quando o serviço deve ser fornecido? Deveria ser incluído no mínimo, o percentual de disponibilidade do serviço, o horário do serviço (período em que deve estar disponível, por exemplo: em horário comercial, 24x7, etc), o horário do suporte ao serviço (Service Desk por exemplo). Importantíssimo também considerar condições de exceção, como feriados, finais de semana, etc.



Pergunta 3: Quanto?

Esta pergunta não tem relação com valor a ser pago pelo serviço, que normalmente já definido no Catálogo de Serviços, e sim em qual quantidade e com qual desempenho o serviço será entregue. Ou seja, requisitos de capacidade.

Pode-se incuir por exemplo: Taxas de resposta, número máximo de transações si-multâneas, usuários concorrentes, etc.

Outra boa sacada é considerar “lotes” e “franquias” de requisições de serviços. Por ex-emplo: considerar um lote máximo de requisições simultâneas do tipo X. Caso a quan-tidade ultrapasse o limite, será necessário como uma mudança (exige aprovação e um projeto associado). Em outros casos é possível acordar cobrança adicional quando a franquia de requisições for atingida, como forme de influenciar o comportamento dos usuários.

Pergunta 4: Como?

Talvez este seja o capítulo mais extenso, e com direito a incluir alguns tópicos:

Papeis e responsabilidades

Uma boa prestação de serviço exige que não somente o provedor, mas também o cli-ente, cumpram alguns deveres. Se engana quem acha que o cliente (e os usuários) não têm responsabilidades.

Suporte ao Cliente

Neste tópico, algumas informações importantes como os possíveis canais de contato do cliente com o Service Desk, os tempos de resposta para cada tipo de caso de acordo com os critérios de priorização, matriz de escalonamento, etc, podem ser incluídas.

Reporte e análise crítica do serviço

A maioria dos Acordos de Nível de Serviço não deixam claro a periodicidade e a forma como os níveis de serviço serão medidos, reportados, analisados criticamente junto ao Cliente e continuamente melhorados. Este momento é uma excelente oportunidade não só para identificar os pontos falhos na entrega de serviços, mas também oportuni-dades de novos negócios. Vale lembrar que este item é, inclusive, um requisito da nor-ma ISO/IEC 200000.

Canal de Reclamaçao

Seja lá qual for o nome mais adequado: ombudsman, ouvidoria, etc. O importante é mencionar um canal onde o cliente possa reclamar caso não esteja satisfeito com o serviço, e garantir que será dado um tratamento adequado a esta reclamação.

Pergunta 5: E se der $%@&... ??



Como dizem os americanos: “coisas” acontecem...

O provedor deve estar preparado para imprevistos de grande magnitude. O Acordo de Nível de Serviço pode deixar claro para o Cliente a existência de um plano de con-tinuidade, ou considerações que evidenciem que o provedor gerencia os riscos de seus serviços, endereçando respostas adequadas para cada um deles.

Ao ler este artigo, definir um Acordo de Nível de Serviço pode parecer fácil mas está longe disso. Estes são apenas alguns dos ingredientes básicos de uma atividade que leva tempo, e muita discussão.



25 dicas infaliveis para que seu projeto de implantação da ITIL seja um fracassoCLAUDIA MARQUESANI

Hoje é dia 25, e para comemorar nada melhor que um manifesto contra tudo que é fei-to de errado por aí.

Abaixo cito 25 dicas “incríveis” que podem fazer com que qualquer projeto de gestão de serviços afunde. São elas:

1. Nao trate o projeto como um projeto� Não utilize nenhuma metodologia para acompanhamento. Implementar gerenciamento de serviços em uma organização é fácil, rápido e nem precisa de muito esforço. Vá tocando «o barco» como der.

2. Achar que ITIL® é um “projeto” que termina e você nunca mais vai precisar ouvir falar dele.

3. Seja cego, surdo e mudo para as necessidades do negócio� Você está gerenciando serviços de TI - nada a ver com o negócio!

4. Não envolva o cliente na definição de critérios de qualidade. Qualidade é você que sabe o que é, afinal você é O CARA de TI! Pensando bem, critérios de qualida-de... quem precisa deles?

5. Comece o processo de gerenciamento de serviços , sem ter claro o entendimen-to do que realmente é um serviço para o seu cliente� Tenha certeza: o processo será um verdadeiro “sucesso”. Vamos gerenciar aquilo que nem mapeamos e nem conhecemos... maravilha!

6. Destaque somente ganhos operacionais e deixe ganhos financeiros em segundo plano (afinal, qualidade é o que interessa, o resto não tem pressa).

7. Coloque um “Zé Ninguém” (tipo este com cara de perdido da figura ao lado) para ser gerente de nível de serviços.

8. Coloque um gerente financeiro que não entenda de TI ou vice versa, um gerente de TI que não entenda de finanças.

9. Nao invista em treinamentos: Faça somente um treinamento quando o processo entrar em produção. Afinal, treinamentos são direcionados a pessoas e a parte im-portante mesmo da ITIL® são os processos e as ferramentas.

10. Nao comunique as pessoas na profundidade e abrangência necessárias: campa-nhas de conscientização para que todos saibam o valor agregado de um bom ge-renciamneto de serviços é completamente opcional. Um luxoooo!

11. Avise que os ganhos demoooooooram para aparecer�� não defina «quick wins”, porque essa palavrinha em Ingles é muito difícil de ser lembrada.

12. Escreva todos os processos pensando em entregá-los rapidamente� Afinal , de-pois de entregues você estará livre para outro projeto.

13. Escolha a ferramenta mais barata e implemente sem testar, porque o fornecedor falou que ela é “ITIL® Compliance”.



14. Como é complicado configurar ferramentas, comece pela configuração delas an-tes de definir adequadamente o processo.

15. Todos os processos devem emitir relatórios, mas quanto mais eles tiverem ter-mos técnicos e complexidade, mais isso mostrará o valor agregado de TI. Afinal, o cliente sabe tudo de TI, né?

16. Ache que processos ITIL® sao procedimentos que indicam como as pessoas de-vem executar suas tarefas diárias.

17. Utilize exatamente os fluxogramas sugeridos pela ITIL®, assim vc não corre o ris-co de alguem falar que vc não está em «Compliance”.

18. Adote e adapte� Pode adaptar a vontade� Faça adaptações até não entender mais qual era a proposta inicial. Afinal a ITIL® diz: ADOTE E ADAPTE.

19. Se estiver dificil definir um dono para um processo, divida em “duas bolas”: assim você vira o amigão da galera.

20. Desenhar processos, mas seguir a regra de quem “grita mais alto” ou quem “é seu amigo” ou quem “tem mais influência” para decidir o que fazer.

21. Desenhar um manual de processos lindo, mas tao utilizado que no final ele vai virar um suporte de um monitor velho. Legal, ergonomia também é importante, certo?

22. Melhoria contínua� Fácil�� Vamos promovê-la baseando-nos em critérios obscu-ros, que mudam a cada dia ou baseados simplesmente na intuição.

23. ITIL® é coisa SÓ de Infraestrutura� Logo, sua equipe de desenvolvimento de soft-wares ou fornecedores não tem NADA a ver com ITIL®.

24. Achar que o presidente da sua empresa também nao tem NADA a ver com ITIL®� Que raios ele tem que abrir chamado no service Desk? Para ele nós atendemos na hora, sem prazos, sem classificações, sem processo! Afinal, ele é VIP.

25. Controlar o processo e esquecer do serviço� As vezes o trabalho para manter um processo é tão intenso que o serviço e sua qualidade ficam em segundo plano. Quem nunca passou por isso?

Alguém se lembra de mais alguma dica para o FRACASSO?

Se sim, vale a pena citar, porque na prática tudo isso acontece e é bom ser PREVINIDO!

Por isso é tão difícil ter sucesso na implementação do gerenciamento de serviços...

Quem sabe eu nao transformo as 25 dicas em 50?



Catálogo de Serviços: Para que complicar?CLAUDIO DODT

Nos projetos de gerenciamento de serviços de TI em que participei um quickwin cer-to sempre foi o catálogo de serviços. Afinal, nada mais difícil que prestar serviços aos usuários sem que eles saibam o que há disponível.

Mas por que criamos tanta dificuldade em adotar essa ferramenta se isso é algo com o que 90% das pessoas tem um contato quase diário? Qualquer pessoa que já foi a um restaurante e pediu o velho e bom menu acabou de receber um catálogo de serviços.

Um bom catálogo deve ser exatamente isso, uma lista dos serviços prestados pela TI funcionando da mesma forma que um cardápio de restaurante e permitindo que o for-necedor de serviços demonstre para seus clientes quais são as opções disponíveis, os modos como estas são entregues e, quando pertinente, os custos envolvidos.

Catálogo de Serviços - apenas uma parte do portfólio e deve ser controlado através do gerenciamento do conhecimento.

Um ponto importante ao qual nem sempre damos a devida atenção é separar o catálo-go de negócios do catálogo técnico e até mesmo da visão do usuário. Excesso de infor-mação pode causar tanta confusão quanto à falta da mesma.

Imagine explicar para um usuário que o correio eletrônico depende de vários itens de configuração que vão desde um cluster de servidores, anti-spam, antivírus de borda, banco de dados, roteadores, firewalls e assim por diante. Essas informações podem ser vitais para a equipe de suporte na hora de solucionar incidentes e problemas, mas o usuário quer simplesmente saber como acessar o email.

As diferentes visões do catálogo de serviços

Entender o negócio e equilibrar a quantidade de informações correta que vai permitir ao seu cliente utilizar o serviço de forma adequada é a receita de sucesso de um catálo-go de serviços eficiente. Um bom exemplo pode ser visto nos produtos e serviços da Google, que foi desenhado de forma minimalista e é extremamente eficiente.

Catálogo de produtos da google - Visão do usuário

Outros modelos de catálogo bastante interessantes podem ser vistos aqui e aqui, com diferentes graus de detalhamento, mas com certeza bastante eficientes para o seu pú-blico alvo, o cliente.

Uma boa dica, especialmente se você não tem um sponsor, é a metodologia KISS, com-ece simples! Uma planilha no Excel se for bem organizada e divulgada pode se tornar um excelente catálogo de serviços.

Links e referencias:



www.google.com.br/intl/pt-BR/options/www.itap.purdue.edu/service/catalog/alpha/its.ucsc.edu/service_catalog/index.php



ITIL – é preciso saber venderCLAUDIA MARQUESANI

Que o ITIL® - este “famoso”conjunto de melhores práticas para prestação de serviços em TI -traz ganhos para a TI e para o negócio a longo prazo, isso a maioria sabe. A maioria também tem conhecimento que isso acontece porque , o principal benefício do Gerenciamento de Serviços é tornar a TI mais alinhada aos requisitos de negócio. Isso faz com que a área de tecnologia da informação exerça realmente sua função den-tro de uma empresa: que é contribuir para que a organização atinja seus objetivos de negócio. Parece fácil falar, mas não é fácil mostrar o ganho associado a implementação do ITIL® para uma organização . Só quem já tentou “vender” uma idéia relacionada a implementação de ITIL® para altos executivos, tem idéia da dificuldade que é mostrar os benefícios e o valor agregado (financeiro??) de um projeto desse porte. O que fazer então para conseguir “vender” o ITIL® para sua organização?

Existem algumas dicas que podem ser bastante úteis na implementação (e também na venda) e espero contribuir para quem estiver passando por esta árdua fase.

São elas:

1. Identifique qual a VISÃO, tenha claro, em qualquer implementação, qual é o real OBJETIVO buscado e os ganhos que essa meta ao ser alcançada trará para seu ne-gócio. Não há vento favorável para aqueles que não sabem para onde ir, mas você precisa também saber o que fará (resultados que você espera obter) quando che-gar lá!

2. Lógico, veja se esses OBJETIVOS são REALISTAS. Não adianta dizer que irá imple-mentar uma central de serviços e que no primeiro mês reduzirá 90% das horas de trabalho da equipe de TI com soluções em primeiro nível com zero por cento de taxa de abandono. Se souberem de alguma empresa que conseguiu esse índice as-sim que implementou um Service Desk, por favor, me avisem - eu quero trabalhar para essa organização!!!

3. Transforme a grande “viagem” da implementação, em “pequenas viagens”. Defina GANHOS RÁPIDOS. Fica mais fácil dessa forma vender seu projeto. Quer rede-senhar a infraestrutura para aumentar a disponibilidade de algo vital para seu ne-gócio? Isso demora, não é? Não seria mais rápido aplicar técnicas da gerência de disponibilidade como o TOP (Technical Observation Post) para que em prazo cur-tíssimo alguma melhoria fosse visualizada? Devo esperar a implementação com-pleta de um banco de dados de gerencia de configuração (que pode demorar de 6 meses a 1 ano e meio , dependendo do tamanho da organização) ou começar a ali-mentar meu banco de dados por aquilo que é mais vital para meu negócio? Faça a implementação em fases.

4. Infelizmente não tem como fugir. O que toda organização busca no final (a não ser que seja uma ONG) é LUCRO, DINHEIRO! A frase que você ouvirá é: “o que



eu ganharei ao investir meu dinheiro nisso? Porque eu deveria investir?” Então, se você deseja vender um projeto ITIL® e ter segurança ao apresentar sua propos-ta , mostre como, quanto e quando você comecará a ganhar. Existem ferramentas para auxiliá-los nisso, calculando o ROI (Return On Investiment) em um projeto – veja um de exemplo em nossa área de downloads. Seja realista também nesse as-pecto (nem pessimista demais, nem otimista demais). Lembre-se: ganhos rápidos também devem ser calculados e apresentados: isso facilitará bastante a venda do projeto. Quanto antes o retorno vier, mais facilmente seu projeto será aceito.

5. Tenha total certeza de ONDE VOCÊ ESTÁ AGORA, qual sua situação atual. Ter completo entendimento da real situação irá facilitar a implementação de qualquer processo e de qualquer melhoria associada a ele.

6. Trace planos que o levarão até seu objetivo. Como você CHEGARÁ ATÉ LÁ? Uma dica: Identifique quais são os pontos vitais para seu negócio, onde estão as maio-res oportunidades de melhoria e comece a implementação por eles. Por exemplo: Não existe ponto único de contato? Os recursos de TI perdem horas de trabalho ao ser interrompidos por usuários ? Que tal implementar uma central de serviços para os serviços mais críticos para seu negócio, para aqueles que terão maior vi-sibilidade pelo seu cliente? Algum outro processo pode ser implementado junto com o Service Desk ( gerencia de incidentes, por exemplo) , a hora é agora!

7. Saiba medir se VOCÊ REALMENTE CHEGOU LÁ e como você se MANTERÁ NES-SE LUGAR. Quem não mede nunca conseguirá saber se os ganhos esperados fo-ram atingidos, quem não mede não consegue saber onde está, quem não mede é como se fosse um avião no ar e sem contato com a torre de controle. Lembre-se: seus objetivos foram realmente atingidos? Eles podem ser melhorados? Um dos ganhos que o ITIL® traz para os processos de Gerenciamento de Serviços de TI é justamente a melhoria contínua. Caminhe sempre nesse sentido!

Enfim, espero ter ajudado aqueles que como eu, já tiveram alguma dificuldade em en-tender por onde começar, como definir e obter ganhos rápidos e como mostrar o val-or agregado do gerenciamento de serviços para TI. O ITIL® é apenas um conjunto de melhores práticas. Adote e adapte sempre utilizando o bom senso e acreditem: bom senso no mercado atual deve ser guiado por três pilares: ética, qualidade e RETORNO FINANCEIRO! Este último se vier depressa, melhor ainda!



Pessoas: o calcanhar de Aquiles na adoção da ITILALBERTO ANDRADE

Todos sabemos que a implantação da ITIL® pode trazer mais maturidade operacion-al ao departamento de TI, agregando valor ao negócio e obtendo maior satisfação do usuário. Também sabemos a necessidade de participação da área estratégica da em-presa para sucesso no envolvimento das áreas. Estes e outros benefícios da biblioteca são mais que conhecidos por nós, fiéis seguidores das boas práticas. Mas será que ap-enas treinamento, palestras e conteúdo teórico são suficientes para o envolvimento da força motriz da implementação, ou seja, as pessoas?

Implantei processos ITIL® nas versões V2 e V3 do framework em alguns projetos em que trabalhei e gostaria de dividir algumas experiências neste assunto. Quanto aos pro-cessos, estes apresentam seu grau de dificuldade, que varia de acordo com a complexi-dade da área/projeto e da quantidade que se deseja implantar. No entanto, é fato que, quanto mais se entende (verdadeiramente) que boas práticas não são regras, portanto podem (e devem) ser adaptadas, melhor se enquadra “fome à vontade de comer”. Para o desenrolar da prática, o PDCA também não é mero assunto de qualidade. Use-o com sabedoria e seja feliz. A recomendação anterior vale para o quesito produtos (tecnolo-gia) e parceiros, onde dadas as peculiaridades que merecem devida atenção, a metod-ologia tende a ocasionalmente repetir-se, implantação após implantação.

O assunto aqui é o calcanhar de Aquiles de todas as minhas implantações, o ponto da entrega de serviço de TI onde não há manual, nem regra, nem diretriz pré-determinada: As pessoas. Asseguro sem hesitar que, em todo o processo de implementação, de to-dos os projetos, o que demandou mais esforço e energia foi este pilar. Afinal, não é por menos. O ser humano é complexo, tem comportamento instável, tendência individual-ista e demanda constante motivação. Entendo ser este o alicerce mais frágil de toda a implantação. O time tem que comprar a idéia, antes de colocá-la em prática. O que mais tenho ouvido de pessoas envolvidas em projetos de ITIL® são murmurações de profis-sionais que tem de parar seus afazeres para agregar processos que eles acreditam não servirem pra nada. Desta forma, coloco abaixo alguns pontos que acho serem cruciais para arrebatar o maior número de seguidores da biblioteca de boas práticas:

1. Necessidades satisfeitas não geram motivação: Esta é uma premissa da motiva-ção humana. Agregar valor ao negócio é importante para você, gestor, talvez não seja para o seu operacional, aqueles que vão colocar a mão na massa. Busque refe-rência em sites, revistas, vídeos e outros pontos. Deixe claro que o conhecimento do framework é importante também em termos de carreira. Converta o benefício para eles, gere o brilho nos olhos. Pode ser que o time ainda não esteja engajado por estar pensando: “Que vantagem Maria leva nesse tal de ITIL®?”

2. Gere visão de negócio: Este é um complemento ao primeiro tópico. A equipe só conseguirá ver com seus olhos a partir do momento em que a maturidade neste



sentido tiver avanço. Seus funcionários só vão querer aproximar TI do negócio se identificarem algum sentido (e benefício) em fazê-lo.

3. Gerencie o overhead de trabalho: Não tem jeito, a equipe vai trabalhar mais. E o pior, nem sempre podemos negociar banco de horas ou mesmo hora-extra com a empresa. É preciso convencer que o ganho pós-implantação valerá todo o esforço aplicado nesta fase. Desta forma, use e abuse do discurso e argumentação e não esqueça: Motivação sempre.

4. Treinamento inicial é bom, reciclagem é melhor ainda: Geralmente, o treinamento inicial em ITIL® é ministrado após um workshop e palestra iniciais. Neste período, muitos ainda estão desinteressados. Portanto, agende uma reciclagem, voltada para os processos em implantação na empresa. Aborde casos de uso e situações práticas. Deixe que as pessoas dividam as suas experiências e tirem suas dúvidas.

5. Definir muito bem o “Onde estamos” e o “Onde queremos chegar”: O mapeamento dos processos em atividade é fundamental para pleno entendimento do panora-ma atual da área. Feito isso, defina (sempre alinhado à estratégia de negócio) como será a entrega de serviços futura. Assim, as pessoas serão norteadas por este ob-jetivo.

6. Brainstorm periódico: As pessoas chave do processo não podem deixar de contri-buir com idéias, sugestões e criticas. Reserve tempo na agenda para a dissemina-ção de idéias. Muitas coisas, certamente, você não pensou.

7. Quick wins: Defina metas intermediárias e divida com todos (não só com seu che-fe, entendeu?). Desta forma, todos saberão que a implantação tem obtido êxitos parciais.

8. Autoridade funciona, mas saiba que em algumas ocasiões, o poder será necessário: Se você é um líder influente, que sabe persuadir, seduzir (sempre no bom sentido, claro!) e motivar sua equipe, saiba que você é raro. Hoje, muito se usa o “manda quem pode, obedece quem tem juízo”. É o tal do poder versus autoridade. O poder pode ser entregue a qualquer um. Por definição, qualquer chefe tem poder, mas nem todos tem autoridade. Isso é verdadeiro, no entanto, sabemos que o quadro de funcionários de qualquer empresa está repleto de ervas - daninhas. Portanto, seja um grande líder, inspirador em seu discurso, apaixonado pelo que faz, dedi-cado e atencioso com seus liderados. Vai funcionar pra maioria das pessoas. Pra quem não funcionar, bem, já sabe...

9. Escolha um braço direito na equipe: Sempre haverá aquele que vai comprar melhor a idéia, se dedicar mais e corresponder melhor aos processos ITIL®. Tenha nesta pessoa um termômetro da equipe como um todo. Desenvolva sua capacidade de liderança e persuasão, este recurso será muito útil durante todas as fases da im-plantação.

10. Ninguém consegue entregar o que não tem: Se os lideres da sua equipe não com-praram o ITIL®, não vão conseguir vender aos demais. Infelizmente quanto a isso, não tem remédio (se houver, alguém me informe!). A disseminação de uma nova cultura de trabalho, bem como a quebra de paradigmas tem que ser acompanha-



do e supervisionados no dia-a-dia, pois são resultados de muito trabalho e, muitas vezes, de coaching. Portanto, avalie muito bem as pessoas a serem selecionadas para participar e sobretudo, liderar as equipes. Quando os líderes já fizerem parte do quadro de funcionários, insista e só avance no processo quando tiver convicção do engajamento de 100% dos supervisores e coordenadores de equipe. Isso é fun-damental.

Evidente que o tópico “pessoas” por ser extremamente complexo, possui uma série de outros pormenores a serem tratados cautelosamente. Mas espero que os passos aci-ma possam ser um bom início para uma implantação menos conflituosa e com maiores ganhos.



Problemas – como identifica-los?RENÊ CHIARI

Hoje quero trazer algumas dicas práticas de critérios para identificação de problemas, pois considero este um dos segredos de um bom processo de gerenciamento de prob-lemas.

Seguem alguns dos critérios de identificação mais comuns:

• Incidentes graves� Via de regra, incidentes graves são aqueles que exigem uma grande mobilização de toda TI, envolvimento da “SWAT” da TI e são acompanha-dos de perto pela Direção e Clientes. É o tipo de incidente que deve ser evitado o máximo possível. A dica é: gerar um problema para cada incidente grave.

• Reincidentes ou eventos recorrentes� Falhas ou alarmes de monitoração de im-pacto baixo/médio e que ocorrem frequentemente consomem recursos desneces-sários. Por exemplo, uma rotina que falha diriamente, exigindo 25 minutos de um analista para intervir e concluir a operação. Ao fim do mês são 8 horas desperdiça-das. É um dia de trabalho que poderia estar sendo dispensado em algo mais produ-tivo. Uma sugestão seria: a cada 5 reincidentes/eventos do mesmo tipo, na mesma semana, registra-se um problema.

• Incidentes direcionados para equipes especializadas� Não é tão comum, mas pode ser uma boa sacada registrar um problema para cada incidente que foi encaminha-do para um grupo de suporte especializado, principalmente se for um grupo ou um profissional de alto custo ($$) . Isso significa que as equipes de primeiro atendi-mento não têm informações suficientes para tratar este incidente. É uma forma de assegurar que as equipes de suporte especializado (ou fornecedores), no mínimo, proponham soluções de contorno (ou definitivas) estruturadas, e principalmente, alimentem a base de erros conhecidos.

Mas para que esta abordagem funcione, é sempre bom lembrar que o processo de ger-enciamento de incidentes deve estar muito bem estruturado. Em outras palavras, sig-nifica ter incidentes classificados e categorizados corretamente, garantindo assim en-tradas confiáveis ao processo de gerenciamento de problemas.



Profissionalizando a gestão dos projetos de TI e ITSM Parte IANDRÉ BERNARDO

Quando falamos em boas práticas em gestão de projetos, podemos estar falando da con-strução de um submarino, reforma de um apartamento, implantação de uma solução (software) de gestão de serviços ou ainda um projeto de melhoria de processos basea-do na ITIL. Podemos “encapsular” praticamente qualquer coisa dentro de um projeto, exceto, uma rotina! Rotina é operação, ongoing, relacionado a um ciclo de melhoria continua. Já um projeto tem inicio, fim e escopo bem definidos.

Citando o PMBoK: “Projeto é um esforço TEMPORÁRIO empreendido para criar um produto, serviço ou resultado EXCLUSIVO”. (PMBoK 4ªa ed. Pag. 05)

Dito isto, e pensando em melhorar nossas a qualidade dos projetos de TI e ITSM, que tal iniciar um pacote de discussões sobre BOAS PRATICAS EM GESTÃO DE PROJE-TOS?

Então, como diria o “sábio”, comecemos do inicio!

O que gera um projeto? Como estruturar uma iniciativa em um projeto? Como priorizar um projeto?

Geralmente, um projeto pode ser gerado por:

1. Necessidade de mercado (Ex. Desenvolvimento de um novo produto ou serviço)2. Demanda regulatória ou jurídica (Ex. Lei de atendimento do call center)3. Necessidade organizacional (Ex. Melhoria de processos para redução de custos

com impressão)4. Avanço tecnológico (Ex. Atualização de S.O. do parque de computadores da em-

presa para Win 8.0)5. Solicitação de cliente (Ex. Implantação de um Service Desk exclusivo para projeto

de outsourcing)6. Necessidade social (Ex. Projeto de reciclagem de material)

Com a necessidade identificada, vale a pena checar se você tem realmente um projeto ou se é uma demanda operacional nas mãos. Reforçando o que falamos logo ai acima:

• Tem inicio e fim bem definido?• Terá uma equipe de trabalho?• Você consegue delimitar o escopo do que será entregue?• O resultado do trabalho será único? Tendo uma entrega exclusiva com riscos e com-

plexidades distintas de outras iniciativas?



Entao você tem um Projeto!

Vocês verão que em alguns casos a linha é tênue entre um projeto e uma demanda op-eracional, por isso é importante você ter regras definidas na sua empresa sobre o que pode ser considerado um projeto (Que precisará de um Gerente de Projetos e toda uma estrutura de gestão para conclusão das entregas) e o que deve ser um processo (Que acontece rotineiramente e todos já sabem como fazer).

Que tal um exemplo?

Atualização do Windows Vista para o Windows 7 é um projeto?

Você: “Eu coloco o CD, digito o código de registro, dou next, next, finish e pronto. En-tão é só uma ação, não é um projeto.

Eu: “Concordo com você!”

Eu novamente: “Agora e se você tiver que atualizar o Windows de toda organização, 10.000 computadores e notebooks, na matriz e em 17 filiais espalhadas em 15 capitais no Brasil e mais 2 filiais na Europa e Estados Unidos até o final do ano?”

Entendeu? Mudou a complexidade, aumentou o risco e delimitou o escopo.

Você terá uma rotina para ser executada, a atualização de 10.000 computadores, porém, você terá que lidar com uma série de restrições que não teria se estivesse falando da atualização de apenas um PC.

Você: “Ok, agora como eu organizo isso para dizer que tenho um projeto?”

Eu com cara de conteúdo: “Boa pergunta! Com uma resposta looonga!! Que tal se eu explicar em uma série de 5 artigos? Projeto do inicio ao fim, onde teremos um artigo para iniciação de um projeto, um artigo só para planejamento, um para execução, um para monitoração e um para encerramento?”

Nesta série, baseada no PMBoK e na PRÁTICA de gestão de projetos vamos descrever de forma resumida os principais elementos necessários para você estruturar e entre-gar o seu projeto com maiores chances de sucesso, e as interfaces que estas práticas poderão ter com as práticas de gerenciamento de serviços. Afinal, é da mistura de bons in-gredientes, na dose certa, que temos uma bela refeição, concordam?



Profissionalizando a gestão dos projetos de TI e ITSM Parte IIANDRÉ BERNARDO

Dando continuidade a série de artigos baseada no PMBoK e na PRÁTICA de gestão de projetos, agora que você já sabe que tem um projeto, precisamos começar a organ-iza-lo de forma profissional.

O ciclo de vida de gestão de projetos tem 5 fases:

1. Iniciação,2. Planejamento,3. Execução,4. Monitoração e controle,5. Encerramento.

A Iniciaçao é onde executaremos os processos para autorizar formalmente o projeto. É daqui que sai o primeiro documento do seu plano de trabalho, o Termo de Abertura do Projeto ou Project Charter.

Qual a importância deste documento NA PRÁTICA? Nele você documenta importantes definições que serão seguidas do inicio ao fim do projeto. O Termo de Abertura do Pro-jeto aponta o “Alvo” e quem serão os responsáveis por apontar as flechas.

O que deve conter um Termo de Abertura do Projeto, no mínimo:

1. O Patrocinador ou Sponsor (Quem tem influencia para promover o projeto na or-ganização),

2. O Gerente de Projeto (Responsável por integrar o trabalho do projeto e agir como facilitador do time. É o principal responsável pelo sucesso ou fracasso do projeto),

3. O Objetivo (Por qual motivo este projeto será realizado?),4. O Macro Escopo e as Frentes de Trabalho (O que será realizado no projeto e como

estará organizado - Ex. Frente Sistemas, Frente Infra, Frente Capacitação, etc.)5. O Macro Cronograma ou Cronograma de Entregas (Milestones) (O que será en-

tregue por cada frente de trabalho e qual a expectativa de prazo do Sponsor de realizar estas entregas)

6. Os primeiros Riscos identificados (Você deverá identificar e controlar riscos du-rante todo projeto!!)

7. As Restrições (O que restringe a realização do projeto? Ex. disponibilização de equipe ou orçamento)

8. As Premissas (Algo que vamos assumir como verdadeiro e que no geral, foge ao controle do projeto. Ex. Premissa que o dolar não ultrapasse 2,50)

9. Os Indicadores - KPIs (Objetivo quantitativo - Pelo que será medido o sucesso do



seu projeto? Aumentar a rentabilidade? Diminuir incidentes? Melhorar a disponi-bilidade?)

Com este documento em mãos, o Gerente de Projetos já tem autonomia para iniciar a mobilização do time de trabalho e iniciar a agenda de reuniões para elaboração do Plano do Projeto que falaremos no próximo artigo.

Se você nao sabe onde quer chegar, qualquer caminho serve! - Gato Risonho, Alice no País das Maravilhas

Então o papel deste documento é formalizar aonde você quer chegar. Assim você traçará durante o planejamento o melhor caminho para chegar até lá, aumentando suas chanc-es de sucesso!



Profissionalizando a gestão dos projetos de TI e ITSM parte IIIANDRÉ BERNARDO

Enfim, entramos no meu grupo de processos de Gestão de Projetos preferido. Plane-jamento!!

Quando você faz uma viagem de férias para um determinado lugar pela primeira vez, você tem uma determinada dinâmica e uma forma de aproveitar o lugar, que talvez não seja a mais otimizada.

Na segunda vez que você volta para o mesmo lugar, você aproveita muito mais, já con-hece os “macetes” e a melhor forma de explorar a região.

Esse é o milagre que o planejamento faz por nós. Quando você planeja bem uma ação antes de executá-la, é como se você já tivesse realizado a tarefa uma vez (durante o planejamento), então, na segunda vez (execução) ela sairá mais bem feita.

No PMBoK, este é o grupo mais pesado, o que faz todo sentido, pois a maior responsa-bilidade do gerente de projetos é garantir que tudo acontece como planejado, sendo assim, ele precisa ter tudo planejado.

Em projetos não podemos nos dar ao luxo do teste x acerto. A não ser que isso esteja no planejamento, com os riscos mapeados, custos, critérios de qualidade, etc.

Todas as áreas de conhecimento em projetos deverão ter um planejamento acurado.

Não consigo em um post entrar tão a fundo quanto gostaria para falar de planejamen-to, então serei sucinto e focado nos principais fatores de sucesso.

Vamos ao planejamento!

1. Escopoa. Aqui você irá detalhar e documentar o que será entregue pelo projeto. O esco-

po deve ser muito bem delimitado, com fronteiras claras entre o que é e o que não é escopo do projeto.

b. Um projeto de sucesso é o projeto que entrega tudo que foi solicitado e nada além do que foi solicitado. Por isso a importância tão grande deste tópico.

c. Projetos com uma delimitação de escopo pobre acabam virando os famosos “projetos sem fim”.

2. Tempoa. Outro item de extrema importância nos projetos é a delimitação de tempo do

projeto.b. Durante este processo você irá determinar quais atividades deverão ser reali-

zadas, em qual sequência, por quais recursos, com qual duração e determinará



o cronograma do projeto.c. Um projeto de sucesso deve entregar o que foi determinado no escopo, dentro

do prazo previsto.3. Custo

a. A estimativa de custo e o orçamento do projeto são entregas deste processo.b. b. Você deverá considerar o custo para realização das atividades previstas para

cumprir o escopo, além de uma margem de contingencia que deve ser atrelada a algum risco identificado no planejamento.

4. Comunicaçãoa. 90% do trabalho do gerente de projetos é comunicação, então este item tam-

bém deve estar muito bem planejado.b. Você deve considerar aqui, principalmente, as expectativas das partes interes-

sadas em receber informação e efetuar um plano para cumprir com as mesmas.c. O que deve ser reportado durante o andamento do projeto? Para quem? Com

qual periodicidade? Em que formato?5. Qualidade

a. Como você irá garantir que as entregas estabelecidas no escopo do projeto se-rão entregues com a qualidade adequada, no prazo e custo estabelecido?

b. Aqui precisamos estabelecer alguns indicadores de qualidade para acompanhar durante o andamento do projeto se o mesmo está gerando os resultados espe-rados.

6. Recursos Humanosa. a. Projetos são feitos por pessoas e se as mesmas não estiverem engajadas com

o trabalho o resultado será medíocre.b. b. Neste processo você irá planejar como lidar com as questões de RH do proje-

to.c. c. Como será o relacionamento hierárquico entre o grupo? Como manter o pes-

soal motivado? Como acelerar a sinergia da equipe?7. Aquisições

a. Muitas vezes aquisições devem ser realizadas no projeto.b. Neste processo você determinará a forma de contrato, critérios de SLA, como

será realizado o processo de compras, além de delimitar o que será comprado e o que será “feito em casa”.

8. Riscosa. Outro processo de extrema importância, que muitas vezes não recebe a devida

atenção de muitos gerentes de projeto.b. Neste processo você fará o exercício de prever tudo que pode dar errado no

projeto, classificar estes riscos de acordo com o impacto do mesmo, a probabili-dade dele acontecer e estabelecer um plano de ação para os riscos classificados com maior impacto x probabilidade.

c. Um bom planejamento de risco é ferramenta fundamental para garantir o cum-primento do escopo, prazo, custo e qualidade do projeto.



Lembre-se, seja o projeto viagem, projeto casamento, projeto casa nova, ou projeto de implantação do sistema de reatores nucleares, quanto melhor for o seu planejamento, maiores a chance de garantir o sorriso nos rostos de todos os envolvidos.



Tempo para solucionar problemas: mais um problema ou a solução?RENÊ CHIARI

A teoria é clara:o foco principal da gerência de incidentes é resolver o mais rápido pos-sível, enquanto o foco principal da gerência de problemas é resolver definitivamente.O tempo para resolver um incidente normalmente está descrito dentro do SLA de aten-dimento de incidentes, mas para um problema, é bem raro, principalmente porquê até hoje há dificuldade na diferenciação entre o que é um Incidente e o que é um Problema.

Na verdade este pode ser considerado um paradoxo, já que a gerência de problemas precisa de um tempo maior para conseguir fazer uma análise estruturada de um prob-lema e com isso estabelecer uma solução definitiva. Mas na prática, sabemos que não estabelecer controles de tempo para problemas pode ser um risco, já que as equipes não irão se preocupar com algo que não tenha um “deadline”.

O desafio é justamente equilibrar velocidade x efetividade. Para Eduardo Abrileri, Team Leader de Problem Management da IBM do Brasil, a introdução de prazos para identi-ficação de causa raiz de problemas trouxe resultados positivos ao processo:

“Após a implementação de um tempo máximo para identificação de causa raiz, observamos que o número de problemas com a causa raiz identificada aumentou em 35%. Essa melhora ocorreu porque passado algum tempo, as evidências do problema podiam ser perdidas (logs sobrescritas, envolvimento do técnico em outro incidente e perda de histórico), impedindo a identificação da causa.”

Abrileri complementa que o índice de comprometimento dos técnicos na atuação em problemas melhorou, pois com metas acordadas de atendimento a problemas, incluin-do escalonamento para prazos rompidos, os técnicos passaram a dar mais atenção aos Problemas. O resultado de tudo isso veio em forma de feedbacks positivos de Clientes.

A ITIL® faz uma recomendação para organizações que têm a mesma equipe de suporte atuando tanto em incidentes e problemas, para gastarem 80% do tempo nos incidentes e 20% nos problemas. Como funciona na sua empresa? Você acredita que sem uma política clara de “atenção e tempo de atendimento a problemas” essa recomendação seja viável? NA PRÁTICA, o que realmente acontece?

Criamos uma enquete no site e uma discussão em nosso grupo do Linkedin para que os leitores troquem experiências sobre este tema, que com certeza está no dia a dia de todos que trabalham com suporte técnico e gestão de serviços. Participem!



Transformando sua poltica de segurança da informação em um ativo estratégicoCLAUDIO DODT

Políticas de segurança da informação (PSI) são documentos estratégicos que definem as regras que devem ser observadas durante o uso da informação de uma organização com o intuito de resguardar tanto os pilares básicos (Confidencialidade, Integridade, Disponibilidade) como seus derivados (e.g. Autenticidade, Não-Repúdio, Propriedade).

Se você já passou pela árdua tarefa de criar e manter uma cultura institucional de pro-teção aos dados corporativos sabe que nada é mais distante da idéia de simplesmente baixar um modelo da internet (sim, existem muitos e alguns com razoável qualidade) que a aplicação de regras de segurança em um ambiente vivo, em que segurança da in-formação muitas vezes é percebida pelos usuários, gestores ou mesmo diretores como simples burocracia ou até um empecilho ao negocio.

A elaboração de uma PSI eficiente requer um grande nível de clareza, especialmente no quesito alinhamento com os objetivos do negócio. Entretanto, mesmo uma política eficiente não passa de um apanhado de material impresso ou disponibilizado na pági-na institucional se não for bem utilizada no dia-a-dia.

Os oito passos a seguir podem ajudar bastante na hora de transformar sua PSI em um ativo estratégico eficiente, alinhado ao negócio e que vai ser muito mais eficiente em proteger as informações corporativas e, dependendo do caso, bem… até o seu empre-go :)

Vamos à lista:

1. Segurança da informaçao nao é Tecnologia da Informaçao

Algumas vezes os termos acima são confundidos como sinônimos, e isto pode preju-dicar drasticamente um projeto de PSI. Muitas vezes a mesma informação tem a ca-pacidade de ser apresentada em diversos formatos diferentes, sejam estes eletrônic-os, físicos ou até mesmo armazenados no conhecimento dos nossos colaboradores. De acordo com a ISO 27002 “Seja qual for a forma apresentada ou o meio através do qual a informação é compartilhada ou armazenada, é recomendado que ela seja sempre protegida adequadamente.”

Criar uma PSI exclusivamente para TI pode ter como conseqüência um escopo perigo-samente míope. A ISO 27001 oferece 133 controles em seu Anexo A e basta uma ráp-ida análise para chegar a seguinte conclusão:

Relacionados à TI: 46%

Relacionados à organização/documentação: 30%



Segurança física: 9%

Proteção jurídica: 6%

Relação com fornecedores e compradores: 5%

Gestão de recursos humanos: 4%

Um projeto de PSI que é um esforço apenas de TI esta fadado a enfrentar uma grande resistência dos demais setores. Entender quais são as áreas críticas e pessoas chave bem como seu funcionamento em conjunto é essencial na definição do que é segurança da informação para sua organização.

2. Obtenha o apoio da alta direçao

O famoso “apoio da alta direção” é um fator crucial para o sucesso de qualquer projeto que pretende uma mudança significativa na cultura institucional. Já vi vários projetos onde uma política “já concluída” era apresentada pela TI para a diretoria. Geralmente o documento era imediatamente aprovado e sistematicamente guardado em uma gave-ta trancada no porão mais escuro da organização.

Sem um sponsor de alto nível a força do projeto da PSI pode ser completamente mina-da. Neste momento surgem os usuários que não “sabem” criar uma senha complexa ou que garantem que o seu email pessoal ou um IM público são essenciais para seu tra-balho e ai começam a surgir às exceções que em pouco tempo se tornam a regra.

Um ponto muito importante e exposto de forma excelente no artigo Desmistificando o apoio da alta direção é entender quem realmente são as pessoas chave, os tomadores de decisão e especialmente quem vai ficar do seu lado quando a coisa começar a ficar feia!

3. Converse com o negócio

Conforme previamente mencionado, um projeto de PSI de sucesso dificilmente é um esforço apenas da TI. Conversar com as demais áreas e até mesmo criar um comitê de segurança multidisciplinar traz uma visão muito mais ampla, imparcial e alinhada aos objetivos de negócio da organização.

Além disso, geralmente tira de TI o estigma de vilão da história. Pense nisso!

4. Adote uma postura formal

A política de segurança da informação normalmente é um documento de distribuição apenas interna ou que é encaminhada para clientes e fornecedores. Obviamente é es-sencial que este documento seja de fácil entendimento, mas isso não requer uma abor-dagem informal.



É necessário lembrar que a PSI é um contrato entre a organização e os usuários da in-formação e que muitas vezes pode ser levada perante ao judiciário. Diferenças sutis em termos como, por exemplo, correio eletrônico ou e-mail podem ter implicações ju-rídicas inesperadas.

A PSI é um contrato e deve seguir uma postura formal, clara e não deixar espaços para dúvida. Nesse momento pode ser importante o apoio de seu departamento legal ou mesmo de uma consultoria jurídica especializada.

5. Atenha-se a sua realidade, mas pense no futuro

Obviamente sua PSI não será talhada em mármore. Não se preocupe em prever toda e qualquer mudança na tecnologia, processos ou estratégias da organização.

Uma boa prática é atualizar políticas pelo menos anualmente, nesse momento você pode analisar novamente o cenário corporativo, o negócio e as novas tendências de tecnologia e segurança da informação. Obviamente, mudanças extraordinárias quan-do for necessário não estão descartadas.

Neste momento TI, que em geral faz a redação da maior parte da PSI, pode ser muito bem ajudada pelas demais áreas envolvidas. Ater-se a realidade é essencial para uma política funcional.

Exigir que, por exemplo, toda comunicação telefônica da diretoria seja criptografada fica muito bonito no papel, mas se você não tiver uma tecnologia ou um procedimento de apoio será apenas mais um ponto da sua política que nunca vai ser seguido.

6. Nao proíba, controle!

Conforme mencionei em Segurança da Informação e a arte de não dizer não dialogar com o negócio é essencial. Muitas vezes quando implantamos uma PSI o documento final vem carregado de “não”, “proibido” e outras referencias que passam ao usuário a idéia que nada mais pode ser feito.

Isto pode levar a uma postura negativa ou mesmo de rebeldia. Na maioria absoluta dos casos acreditar que o usuário vai abrir mão de sua comodidade em prol da segurança da informação é uma receita bem comum para a ocorrência de incidentes.

Ninguém reclama quando um jogador de futebol utiliza as mãos e recebe um cartão amarelo ou mesmo é expulso. Certo, algumas vezes ficamos até com raiva da decisão do juiz, mas no fundo sabemos que ele está apenas aplicando as regras do jogo e bem.. bola pra frente.

Usuários devem compreender que as regras existem por um motivo claro, que pro-tegem o negócio e muitas vezes até eles mesmos. A PSI e a área de segurança da infor-mação representam apenas as regras do jogo e o juiz, respectivamente.



Tente explicar aos usuários os “comos” e os “porquês” da segurança da informação ao invés de dar um simples não.

7. Crie um bom programa de conscientizaçao e avaliaçao do conhecimento

A política deve demonstrar claramente o apoio e comprometimento da organização com a segurança da informação. Dito isso, não adianta ter o melhor dos documentos se este não for adequadamente comunicado e, especialmente, entendido pelos usuári-os da informação.

Conforme mencionado acima, a PSI normalmente deve ter um caráter formal. Isto é muito bom do ponto de vista jurídico, mas muitas vezes torna a leitura do documento maçante e o jargão técnico pode ser totalmente incompreensível para a maior parte dos usuários da informação.

Participei de excelentes iniciativas onde TI trabalhava junto dos departamentos pes-soais e de marketing em campanhas que se utilizavam do lúdico para garantir que os usuários fixariam pelo menos o essencial da PSI. Utilize-se de cartilhas, palestras, apre-sentações teatrais, jogos, simulações e qualquer outro recurso que esteja disponível para sua organização.

Lembre-se: a freqüência, a repetição, a repetição, a repetição… isto é treinamento. Você não precisa de um calendário muito extenso. Eventos a cada três meses podem tornar a equipe menos disciplinadas em colaboradores conscientes de suas responsabilidades e caso isso falhe.. bem, o que mesmo eles ainda estão fazendo na sua empresa?

E que tal tornar sua campanha realmente eficiente? Nada melhor que medir o nível de conhecimento dos usuários antes e após a campanha. Essa informação pode servir como um termômetro do seu estado atual e direcionamento para futuros eventos e melhorias.

8. Consultoria ou nao? Eis a questao!

Existem inúmeras vantagens em utilizar consultores especializados para apoio no de-senvolvimento da PSI. Consultores experientes possuem uma vivência maior e nor-malmente participaram de projetos similares em diferentes segmentos. Esse é o tipo de inteligência que pode reduzir drasticamente o tempo do projeto, ajudar na aceit-ação pelos usuários e evitar showstopers.

Em especial se segurança da informação não é a sua especialidade ou se você não tem recurso humano disponível o uso de uma boa consultoria pode sair bem mais barato do que você pensa tanto em termos de tempo como financeiros ou até mesmo dores de cabeça.

A lista acima obviamente não é exaustiva e talvez nem todos sejam adequados para sua organização. Mas se você quer que sua política de segurança da informação seja



mais do que apenas um simples papel encaminhado uma vez ou outra para a auditoria, pense em utilizar parte desses conceitos.

Links e referências:

blog.iso27001standard.com/pt-br/2010/12/16/seguranca-da-informacao-ou-segu-ranca-de-ti/gustavares.wordpress.com/2010/11/20/apoio-da-alta-direcao/

Artigos com toque de tecnologia



A gamificação invadiu nossa praiaRENÊ CHIARI

Você já ouviu falar em gamificação (gamification)?

Trata-se do uso de mecânicas de jogos e pensamentos orientados a jogos para enri-quecer contextos diversos normalmente não relacionados a jogos. Essa técnica pode encorajar as pessoas a realizar tarefas que elas normalmente considerariam chatas, como completar questionários, formulários, ler algum conteúdo específico, etc.

OK, deram nome a algo que sempre existiu (assim como o bullying). Já sabiamos que era mais divertido aprender geografia e história jogando WAR e tentando capturar a Carmen Sandiego do que fazendo cópia de mapas em folha vegetal ou lendo a Barsa.

Agora que você já está devidamente inserido no contexto, vamos aos fatos: em 2015, metade das companhias que trabalham com inovação adotarão práticas de gamificação em seu dia a dia e 70% das duas mil maiores corporações do mundo terão ao menos um aplicativo desse tipo. Não sou eu quem estou dizendo isso, é o Gartner.

E o que isso tem a ver com ITSM? Muita coisa�

Algumas empresas já estão começando a surfar por estas ondas com suas ferramen-tas. É o caso da InvGate, que incorporou em sua suite um módulo específico para gam-ification, que inclui pontuação e “badges” de acordo com o engajamento dos analistas.

www.youtube.com/watch?v=ro5Msyp1s1w

Na área de capacitação não é difícil encontrar jogos complementares aos treinamen-tos padrões de ITIL, por exemplo. São simuladores que estimulam os alunos/jogadores a praticarem os conceitos aprendidos na sala de aula em situações “reais”, como no funcionamento de um aeroporto, uma usina eólica, uma estação espacial, entre outros cenários.

Pensando em um sistema de pontuação/premiação/reconhecimento por engajamento, que é um dos objetivos principais da aplicação dos conceitos de gamificação, seguem algumas sugestões que poderiam funcionar em alguns processos de gerenciamento de serviços:

Gerenciamento de Incidentes

• 5 pontos por incidente registrado e categorizado corretamente• 5 pontos por incidente resolvido em primeiro nível• 5 pontos por incidente resolvido dentro do prazo• 1 ponto por incidente escalonado para o grupo solucionador correto• 20 pontos por resultados positivos da pesquisa de satisfação• 20 pontos para tempo médio de atendimento semanal dentro do prazo



Gerenciamento de Problemas

• 1 pontos por problema registrado de acordo com os critérios estabelecidos• 2 pontos por artigo inserido na base de erros conhecidos• 10 pontos por problema com causa raiz identificada• 10 pontos por incidente resolvido através de um artigo da base de erros conheci-

dos• 50 pontos por problema resolvido definitivamente (ex: 3 meses sem incidentes re-

lacionados)• -20 pontos por problema encerrado sem causa raiz identificada• -5 pontos por cada incidente relacionado a problema já encerrado

Gerenciamento de Mudanças

• 1 para cada requisição formal de mudança registrada• 50 pontos por mudança concluída com sucesso• 5 pontos por mudança aprovada• -15 pontos por mudança implementada sem registro formal ou aprovação• -1 ponto por mudança cancelada• -10 pontos por mudança emergencial• -50 pontos por mudança com falha

E o que fazer com estes pontos acumulados? Algumas recompensas “reais” são sempre bem-vindas, como folga, viagem, bônus salarial. Também podem ser atribuídos “badg-es” para quem conquistar níveis satisfatórios de desempenho.

Obviamente os exemplos não param por aqui. O ITSM na Prática também incorporou alguns conceitos de gamificação (bem menos sofisticados). Saiba mais.



ITSM, redes sociais e Content Management Systems dá jogo?RENÊ CHIARI

Se não pode vencer as redes sociais, junte-se a elas

Não há mais o que ser contestado, as redes sociais vieram pra ficar. E não importa quan-tas barreiras sejam impostas, os usuários vão acessa-lás de um jeito ou de outro.

O lado bom é que a própria TI pode se beneficiar nessa história. Com um pouco mais de criatividade, pode-se extrapolar a aplicabilidade destas ferramentas para outras áreas de conhecimento, como ITSM. Sim, estou falando do uso de CMS (Content Man-agament Systems) e redes sociais no Gerenciamento de Serviços de TI.

Além de serem ferramentas intuitivas e de fácil utilização, fazem o gosto do público (usuários), e não é necessário grandes esforços em treinamentos, afinal, todos usamos a maioria delas em nosso dia a dia.

A lista a seguir mostra a aplicabilidade de algumas ferramentas para o mundo ITSM. A maioria são bem conhecidas, e outras nem tanto, mas vale a pena conferir cada uma delas (e outras também) com mais detalhes.

• Twitter - pode ser um grande aliado para comunicações como alertas e atualizações de incidentes graves e mudanças emergenciais, agenda de mudanças ou qualquer outra notificação relevante e/ou urgente que se possa fazer com até 140 caracte-res. A propósito, o Twitter pode ser utilizado de forma privada.

• Wiki - As características nativas do Wiki, como publicação, controle de alterações, permissões de edição, visualização , e etc são um ambiente perfeito para a criação de base de conhecimento, base de erros conhecidos, gerenciamento de documen-tação (processos, procedimentos, etc), auto-ajuda e FAQ.

• CMS Content Management System (Joomla, Wordpress, Drupal, etc) - Eu sou muito suspeito pra falar sobre essa pequena maravilha chamadas CMS. O próprio ITIL® na Prática roda em cima de um CMS (Wordpress). Mas eu me surpreendo a cada dia. Já existem alguns temas e plugins específicos criados em cima dos frame-works dos CMS´s para transformar um simples blog/site em uma ferramenta para gestão de tickets ou projetos bem convincente, dadas as devidas limitações dos frameworks e o próprio perfil dos desenvolvedores, que não são especializados em ITSM.

• Yammer - é uma cópia escandalosa do Facebook, versão empresarial. Para empre-sas que ainda estão acanhadas de se expor no mundo público do Facebook, esta pode ser uma ótima ferramenta para compartilhar (e reter) conhecimento na or-ganização, e principalmente gerenciar reclamações e assuntos ligados a satisfação dos clientes.



• Facebook - muitas empresas já estão se expondo no Facebook, e considerando ele como um dos principais canais de relacionamento com os Clientes. Porque não tentar?

Para alguns de vocês estas idéias podem parecer bobas. De fato as idéias são voltadas as necessidades mais básicas de gerenciamento de serviços. Mas basta dar uma olha-da na última enquete disponibilizada aqui no ITIL® na Prática e verificar que 56% dos participantes disseram que nao tem uma ferramenta ITSM� Ou seja, para quem não tem nada, é um ótimo começo a custos baixíssimos.

Nos próximos artigos pretendo escrever sobre cada um deles de uma forma mais de-talhada, inclusive custos.



O que as ferramentas não fazem por voceRENÊ CHIARI

Não há o que questionar: as ferramentas vieram para facilitar (e muito!) a nossa vida. Mas ao contrário do que parece, as ferramentas nem sempre conseguem atingir o ob-jetivo proposto, que é trazer agilidade e qualidade na gestão de serviços.

A falha pode ter dois vieses:

• o fornecedor que muitas vezes está mais preocupado com a quantidade de módu-los que serão vendidos, do que com a real necessidade do Cliente;

• o Cliente pode não saber o que quer, e exigir que o fornecedor adivinhe e o satis-faça, entregando o que não é essencial para o negócio. Isso exige experiência do fornecedor em entender de fato, qual a necessidade ou recomendar soluções já aplicadas em outros Clientes de um mesmo segmento de mercado, por exemplo.

Em meus tempos de Help Desk havia um dilema muito discutido na operação: “Como vou registrar tantas informações requeridas pelos critérios de qualidade e mesmo as-sim garantir que isso seja feito em tempo de não afetar a minha meta de atendimento?”.

A questão talvez seja resolvida com a aquisição de uma ferramenta que automatize este processo, mas antes seria interessante perguntar: “Porque estamos registrando todas essas informações?”.

Penso que essa questão tem algumas possíveis respostas:

• “Ahh... porque está escrito na ITIL® que precisamos fazer isso!” - a ITIL® não nos obriga a fazer tudo o que cita. Se você está registrando ou pretende registrar in-formações que não agregam em nada, não continue! Isso pode inclusive influen-ciar um fornecedor de ferramentas a vender customizações adicionais, que geral-mente saem muito caras para atender uma necessidade que pode nem fazer tanta diferença assim no resultado final.

• Para quem acabou de adquirir uma ferramenta, seria: “Bem, a nossa nova e ultra espetacular ferramenta exige que sejam preenchidos todos estes vários campos antes de direcionar para o grupo solucionador. E essa ferramenta esta alinhada com as boas práticas da ITIL®!!” - Essa é uma das falhas mais comuns em projetos que envolvem implantação de processos e ferramentas. Conheço casos de proje-tos que extrapolaram a conclusão, justamente porque a ferramenta é demasiada-mente complexa, causando impacto nos processos e na cultura da empresa.

• “A nossa ferramenta tem um selo de ITIL® Compliance” - Desconfie de ferramen-tas com “selos” de compliance com a ITIL®. Isso torna a ferramenta muito mais cara, e dependendo de como o negócio é suportado pela TI, o Excel faz o mesmo trabalho. Obviamente trata-se de ferramentas extremamente competentes, mas nem sempre o Cliente precisa de tudo isso. Existe uma iniciativa da OGC em ofi-



cializar um modelo de “certificação de ferramentas compliance com ITIL®”, mas eu sinceramente não acredito que isso vá trazer algum benefício para o Cliente final.

Esses cuidados se aplicam em qualquer contexto e não somente a um processo espe-cífico. O importante é lembrar que as ferramentas não devem governar os processos - é justamente o contrário!

Artigos Exlcusivos do Chef



Os desafios da criação de valor atraves da Operação de ServiçosRENÊ CHIARI

Cada estágio no ciclo de vida do serviço tem o seu papel na criação de valor. Por ex-emplo, o valor do serviço é modelado na Estratégia de Serviço; o custo do serviço é desenhado, prescrito e validado no Desenho de Serviço e Transição de Serviço; e os indicadores para melhoria são identificados na Melhoria Continuada do Serviço. A op-eração de serviço entra em cena quando estes planos, desenhos e melhorias são im-plementados. Do ponto de vista de um cliente, é na operação de serviço em que o valor é percebido de fato.

Ao contrário do que parece, a operação de serviço não pode restringir o seu foco so-mente na operação do dia a dia e entrega de serviços para criar valor. Existem desafios fora deste contexto que podem oferecer riscos à criação de valor, por exemplo:

Poucas organizações planejam efetivamente os custos do gerenciamento de serviços ao entrarem em produção. É muito fácil identificar custos de um projeto, mas muito difícil quantificar quanto um serviço irá custar depois de alguns anos de operação.

É comum que somente após algum tempo que o serviço está em operação as falhas dos estágios anteriores (estratégia, desenho e transição de serviço) sejam visíveis. Con-tudo, é difícil justificar investimentos para corrigir falhas de projeto ou requisitos não previstos, porque isso não faz parte da proposição de valor original.

Também há dificuldade em obter investimento adicional em ações de melhoria da op-eração de serviço, como aquisição de ferramentas ou treinamentos. Por um lado, isto ocorre porque estes investimentos não estão diretamente relacionados à funcionali-dade de um serviço específico e, por outro lado, porque há uma expectativa do cliente que estes custos deveriam ser embutidos aos custos do serviço desde o começo, e não após o serviço entrar em operação.

Quando um serviço está em operação por muito tempo, ele se torna parte do que o negócio considera como “normal” para um serviço de TI. Este sentimento dificulta jus-tificar ações de melhoria do serviço, pois o sucesso destas iniciativas só é percebido pelo cliente se o serviço tiver um histórico “nebuloso” de falhas.

O estágio de Operação de Serviço sugere vários processos, funções e mensurações que endereçam estes desafios.



O que são incidentes, problemas, erros conhecidos e requisiçoes de serviço segundo a ITIL?RENÊ CHIARI

Para compreender melhor estes conceitos, como de costume, convidamos você a sair da caixa. Preparado?

Então, imagine que, de uma hora para outra, você começa a ficar febril. Este é um com-portamento não esperado e indica que algo não está bem com o seu organismo, certo?

Para a ITIL, isso é um incidente. Em outras palavras, qualquer acontecimento que não faça parte do comportamento padrão e que cause, ou possa causar, uma interrupção ou redução da qualidade de um serviço. No nosso exemplo, entenda como a redução da qualidade de vida ou mesmo a morte!

A forma de tratar um incidente é resolver o sintoma o mais rápido possível. Sendo as-sim, você procura uma farmácia e toma um remédio por conta, ou procura um posto de saúde e passa por uma consulta com um clínico geral.

Agora imagine que esta febre volte a ocorrer duas, três vezes. Apesar de continuar tratando o sintoma com um medicamento, você quer descobrir a causa raiz. Para a ITIL, isso é um problema. Ou seja, a causa desconhecida de um ou mais incidentes.

A forma de tratar um problema é fazendo uma investigação profunda em busca da causa raiz. Para isto, você vai precisar de um médico especialista. Isso vai levar mais tempo e provavelmente custará mais.

Através da avaliação dos resultados de exames, é possível chegar a um diagnóstico e, a partir daí, identificar a forma de resolver definitivamente (ou paliativamente) este problema.

Para a ITIL, isso é um Erro Conhecido, ou seja, a causa conhecida de um problema do qual já se sabe ao menos qual a solução de contorno.

Considerando que a causa desta febre já é conhecida e o médico especialista já sabe como tratá-la de forma definitiva, ele recomenda a você tomar uma injeção com um medicamento específico para este fim.

Este procedimento é bastante comum e de conhecimento de todos os profissionais de saúde em geral. Além disto, também é um procedimento pré-autorizado pelas autori-dades de saúde.

Na ITIL, isso seria considerado como uma Requisição de Serviço, ou seja, a descrição genérica de vários tipos de demanda colocados pelos usuários para o departamento de TI. Muitas destas requisições são pequenas e de baixo risco, e ocorrem com grande frequência.



Principais abordagens para liberação e implantaçãoRENÊ CHIARI

Neste artigo, você irá conhecer as opções mais comuns para a liberação e implantação de serviços de TI.

A escolha da abordagem mais adequada para uma liberação depende de uma boa com-preensão dos padrões de atividades de negócio e perfis de usuários durante o planeja-mento e desenho destas liberações.

A opção selecionada terá um impacto significativo nos recursos de gerenciamento de liberação e implantação, assim como nos resultados do negócio.

As duas opções de liberação mais comuns para cenários de múltiplas localidades são:

Big Bang

O serviço é implementado para todos os usuários de uma só vez. Esta opção geralmente é utilizada em mudanças de aplicações em que a consistência do serviço é considerada importante para toda a organização.

Algumas vantagens desta opção são:

• O tempo de implementação é menor• As dificuldades de implementação são condensadas; • Os custos de implementação são menores; • Os usuários devem estar treinados apenas para o novo serviço e não para o perío-

do de mudança; • A implementação ocorre em um único dia e todos os usuários sabem a data.

Por outro lado, as desvantagens são:

• Detalhes podem ser negligenciados com a pressa de mudança; • Os usuários têm menos tempo para conhecer (e aprender) o novo serviço; • Uma falha em uma parte do serviço pode afetar outras.

Abordagem faseada

O serviço é implementado para uma parte da base de usuários e, depois, esta operação é repetida para as bases de usuários subsequentes, conforme uma agenda planejada de liberações. Esta abordagem pode ser dividida em três:

• Implementação faseada por módulo – os módulos do serviço são implementados um a um, começando pelos mais importantes;

• Implementação faseada por unidade de negócio – a implementação é feita em uma unidade de negócio por vez;

• Implementação faseada por geografia – para organizações com múltiplos locais.



As vantagens desta opção são:

• A organização ganha conhecimento durante a implementação inicial, que pode ser aplicada nas fases seguintes;

• Com a transição a ocorrer em partes, existe tempo para ajustes e correções; • Existe mais tempo para os usuários se adaptarem ao serviço novo ou modificado; • A equipe técnica pode concentrar os esforços em uma parte do serviço ou em um

grupo de usuários.

E algumas das desvantagens:

• Não é tão focada como na abordagem “Big Bang”; • Pode haver inconsistência de informações, uma vez que cada módulo contém in-

formações importantes sobre outros módulos; • A duração do projeto é mais longa que a abordagem “Big Bang”.

Empurrar e puxar (Push and pull)

A opção “empurrar” (push) é utilizada quando o componente do serviço é implantado a partir de um ponto central de distribuição e “empurrado” para as localidades. Em termos de implantação de serviços, entregar os componentes atualizados do serviço para todos os usuários – seja com a abordagem “Big Bang” ou faseada – significa “em-purrar”, uma vez que o serviço novo ou modificado é disponibilizado no ambiente dos usuários em um momento não escolhido por eles.

A opção “puxar” (pull) é utilizada em liberações de software, nas quais o programa é disponibilizado em um ponto central de distribuição, mas os usuários são livres para fazer o download para sua localidade no momento em que escolherem ou quando uma estação de trabalho de usuário é reiniciada.

Um bom exemplo prático do uso de abordagens e opções de liberação é a funcion-alidade “Windows Update”, nativa nos sistemas operacionais da Microsoft. As atual-izações são disponibilizadas simultaneamente para todos os usuários (abordagem “Big Bang”). Os usuários decidem pela opção “empurrar” ou “puxar”, de acordo com sua preferência.



Gerenciamento da Configuração e Ativos de Serviço: o processo “camarada” da ITIL®RENÊ CHIARI

Conheça as suas principais interfaces e suporte ao aumento da eficiência de outros processos de Gerenciamento de Serviços�

Nenhuma empresa pode ser totalmente eficaz e eficiente se não gerenciar bem os seus ativos, principalmente aqueles que são vitais para manter a operação dos seus proces-sos de negócio. O processo da ITIL® que endereça este tema é o de Gerenciamento da Configuração e Ativos de Serviço.

Sua missão é assegurar que os ativos necessários para entregar serviços sejam contro-lados apropriadamente, e que informações confiáveis e íntegras sobre os ativos sejam disponibilizadas quando e onde necessário.

Neste momento você deve estar se perguntando por que se trata de um processo “ca-marada” da ITIL®.

Um dos principais objetivos do processo de Gerenciamento da Configuração e Ativos de Serviço é suportar os processos de Gerenciamento de Serviços fornecendo infor-mações precisas da configuração, permitindo, assim, uma tomada de decisão mais as-sertiva e em tempo hábil – por exemplo, para autorização de mudanças e liberações ou resolver incidentes e problemas.

Destacamos algumas das principais contribuições do processo de Gerenciamento da Configuração e Ativos de Serviço com demais processos de Gerenciamento de Serviços:

• Gerenciamento de Incidentes: o processo utilizará a CMDB (Configuration Manage-ment Database ou Banco de Dados do Gerenciamento da Configuração) para ter uma visão lógica da infraestrutura de TI e seus serviços através dos itens de configuração e seus relacionamentos. Essa visão poderá fazer com que o gerenciamento de incidentes tenha maior agilidade e facilidade para solucionar incidentes.

• Por exemplo: maior rapidez na análise do impacto e alocação do time correto para atuação no incidente; maior rapidez na identificação dos itens de configuração im-pactados e que precisam ser rapidamente substituídos ou corrigidos.

• Gerenciamento de Mudanças: maior controle e agilidade no gerenciamento sobre as mudanças do ambiente, pois o uso da CMDB e a visão lógica da infraestrutura de TI e seus serviços (fornecida através dos itens de configuração e seus relaciona-mentos) mostrarão de maneira clara e controlada os componentes envolvidos na mudança e seu real impacto para o serviço.

• Por exemplo: maior agilidade e assertividade na aprovação de mudanças, pois ha-verá mais facilidade para analisar o impacto no serviço dos itens de configuração envolvidos na mudança. Também poderá ser feito o uso de baselinesde configura-



ção para retornar o ambiente ao status anterior a uma mudança executada e mal sucedida.

• Gerenciamento de Problemas: aumento da eficiência do Gerenciamento de Problemas, ao facilitar a análise de tendências em itens de configuração relacionados a incidentes e identificar a causa básica de um ou mais incidentes. Essa informação é utilizada para evitar novos incidentes e melhorar a qualidade dos serviços.

• Gerenciamento de Liberaçao e Implantaçao: aumento da efetividade do geren-ciamento de liberação e implantação, pois fará auditorias e controles permanentes para evitar que softwares ilegais ou não autorizados sejam registrados. Também poderá aumentar a eficiência das liberações com o uso de baselines de configuração para salvar as informações dos itens de configuração antes da liberação (atributos como versão ou status, por exemplo). Essas informações poderão auxiliar caso a liberação seja mal sucedida e um backup tenha que ser retornado.

Em resumo, conhecer as vantagens de um processo para o negócio de sua empresa é o primeiro passo para tomar a decisão de adotá-lo. Esperamos que com este artigo você possa compreender melhor a importância do processo de Gerenciamento da Configu-ração e Ativos de Serviço e o motivo dele ser considerado um dos que mais oferecem suporte aos demais processos de Gerenciamento de Serviços.



Qual a diferença entre o Gerenciamento de Mudanças e o Gerenciamento de Liberação e Implantação?RENÊ CHIARI

Existem vários elementos discretos no ciclo de vida da Transiçao do Serviço que po-dem ser facilmente perdidos quando estes dois processos sao olhados como um só�

A separação dos processos de Gerenciamento de Mudanças e Gerenciamento de Lib-eração e Implantação tem sido um tema constante de debates e discussões. A primeira impressão é que a separação destes processos serve apenas para criar uma “confusão desnecessária”. Mas não é bem por aí.

O Gerenciamento de Mudanças é o processo que garante que todas as mudanças pas-sem por um processo sólido de avaliação e aprovação. Também reúne informações relevantes sobre cada mudança no serviço (porque, quem pediu, foi aprovado?). Por outro lado, o Gerenciamento de Liberação e Implantação é o processo que agrupa as mudanças (quando necessário) e se preocupa com o cronograma, a comunicação, tre-inamento etc.

Em termos mais simples, uma mudança nada mais é do que compreender e aprovar “o que”, enquanto a liberação se preocupa com “como” e “quando”.

Um dos erros no uso destes processos é, por exemplo, o fato de que a maioria das re-uniões do CAB (Comitê de Mudanças) costuma ser focada apenas na avaliação e vali-dação testes e aprovação da “agenda de mudanças”. Não que esta seja uma atividade incorreta, afinal, é o Gerenciamento de Mudanças que de fato aprova a implantação (ou liberação) de uma mudança. Mas neste caminho é comum perder a oportunidade de avaliar se a mudança deve ou não ser feita, mas de um ponto de vista de benefício do negócio, risco e custo. Ou seja, as mudanças devem ser vistas a partir de uma per-spectiva de valor de negócio antes de se tomar a decisão de investir recursos em seu desenvolvimento.

Tanto na ITIL®, quanto em outras referências de práticas de Gerenciamento de Serviços de TI, como o COBIT® e a norma ISO/IEC20000, as atividades de mudanças e liber-ações são descritas em processos distintos, o que reforça ainda mais a existência de elementos diferentes entre estes dois processos. Ironicamente, a separação destes dois processos é o que de fato permite que as empresas consigam distinguir “o que” de “como” e “quando”. Que tal praticar estes conceitos e descobrir as suas vantagens?



A ITIL é uma moda?RENÊ CHIARI

Muitos dizem que a ITIL é uma moda, que vai acabar� O motivo: todo mundo defende a biblioteca, mas pouca gente a usa� Será?

Com a chegada de novos frameworks e boas práticas de mercado, fica a dúvida se a ITIL realmente está com os seus dias contados.

Para refletir sobre esta dúvida, vamos destacar alguns fatos importantes:

• A ITIL foi criada no Reino Unido em 1989.• Seus termos, conceitos e processos são tão populares que a tornou uma referên-

cia adotada por empresas em todo o mundo. Hoje em dia é muito comum no meio de TI as expressões “Incidentes”, “Problemas”, “SLA”, etc.

• Teve duas grandes atualizações, e a versão atual (v3) teve uma atualização em 2011.• A norma ISO/IEC 20000, que tem como foco atestar a qualidade da prestação de

serviços de TI (e é um tema para um artigo exclusivo) foi baseado na ITIL.• Outros frameworks de governança importantes, como o COBIT, também citam a

ITIL como referência complementar.• Possui um esquema estruturado de certificação profissional, que vai do nível bási-

co (fundamentos) até os níveis mais avançados (intermediários, Expert e Master). O número de profissionais certificados, só no Brasil, beira aos 100 mil.

Considerando os fatos acima citados, podemos concluir que:

• Um dos mais claros sinais da evolução da ITIL é que a própria definição do acrô-nimo ITIL já está defasada em relação ao seu foco atual. O nome (“Biblioteca da Infraestrutura de TI”) traz, na verdade, melhores práticas paraGerenciamento de Serviços de TI (IT Service Management – ITSM).

• Há conhecimento acumulado, praticado e discutido há mais de 20 anos. E com a chegada da versão 3, que dá mais ênfase a assuntos como estratégia de serviços, desenho de serviços e melhoria continuada, a ITIL deixa a sua fase de adolescência e entra na fase adulta.

• Também podemos dizer que a ITIL é reconhecida como um “padrão de facto“, inclu-sive por outras instituições importantes que desenvolvem outras referências para governança e gerenciamento de TI, como a ISACA, que desenvolve o COBIT – e a própria ISO, que desenvolve a ISO200000.

Costuma-se dizer que contra fatos não há argumentos. E os fatos são bem significa-tivos, não?



4 métricas para monitorar o desempenho de uma CMDB (Configuration Management Database)RENÊ CHIARI

Sabemos o quanto é desafiador implantar uma CMDB. Mas, uma tarefa tão desafiadora quanto é manter a sua integridade. Neste artigo, apresentamos 4 métricas para acom-panhar a ‘saúde’ de uma CMDB.

Objetivo: Identificar e gerenciar as informações da infraestrutura e seus relacionamentos de forma acurada e eficiente.

Métrica #1 – Número de licenças nao utilizadas�

A CMDB possui um registro de todas as licenças de software e quando foram distribuí-das. Sendo assim, um relatório de licenças não utilizadas pode ser produzido.

Por que utilizar esta métrica?

Já esperada a existência de algumas licenças sobressalentes. Mas, um número muito alto de licenças subutilizadas remete a uma possível falha no planejamento da Capaci-dade, provavelmente pelo uso insuficiente das informações da CMDB pelo processo de Gerenciamento de Capacidade. Esta métrica encoraja o Gerenciamento da Config-uração a garantir que as informações sobre licenças estejam corretas e como reduzir o número de licenças não utilizadas para o mínimo possível.

Métrica #2 – Número de incidentes originados a partir de mudanças mal sucedidas causadas por Itens de Configuração (CI) mal documentados.

Mudanças são aprovadas com base nas informações registradas na CMDB. Se uma mudança falha, devido a uma informação incorreta sobre um componente do serviço (Item de Configuração), a responsabilidade deve ser atribuída ao processo de Geren-ciamento da Configuração.


A informação de um Item de Configuração na CMDB deve ser correta. Com isto, a prob-abilidade de mudanças mal sucedidas irá diminuir, e consequentemente, o surgimento de incidentes ocasionados por estas.

Objetivo: Assegurar que CMDB fornece informações corretas e integras a outros processos de gerenciamento de serviços.

Métrica #3 – Número de Requisições de Mudança sem a atualizaçao do(s) Item(s) de Configuração correspondente(s).

Sempre que um Item de Configuração sofre uma alteração, deve haver uma Requisição de Mudança correspondente autorizada, seguida de uma atualização na CMDB para



refletir a conclusão desta Mudança autorizada. Durante uma possível auditoria, a in-formação de uma Requisição de Mudança deve ser comparada (e correspondida) com a informação de status da configuração na CMDB.


Garante informações acuradas e autorizadas na CMDB. Denomina aderência ao pro-cesso.

Métrica #4 – Percentual de Itens de Configuração com informações incorretas.

Todas as correções de informações de Itens de Configuração deveriam ser contabiliza-das para contribuir com esta métrica.


A ‘razão de ser’ do processo de Gerenciamento da Configuração é garantir a infor-mação correta dos Itens de Configuração.



O que é um Service Desk (ou Central de Serviços)?RENÊ CHIARI

O Service Desk é uma unidade funcional (função) composta por uma equipe dedicada, responsável por uma variedade de atividades relacionadas aos serviços de TI que são fornecidos por um provedor de serviços (seja interno ou externo). Normalmente, a in-terface com o Service Desk é através de telefone, web, ou notificações automáticas geradas por eventos da infraestrutura.

O Service Desk é o ponto único de contato para os usuários de TI. Ele não trata somente incidentes, requisições e dúvidas de usuários, como também pode ser a interface para outras atividades, como a comunicação durante mudanças em serviços ou serviços no-vos liberados no ambiente de produção, manutenção de contratos, administração de licenças de software, etc.

Em outras palavras, o Service Desk é a vitrine da TI. O seu valor não pode ser, nunca, subestimado!

Um bom Service Desk pode “compensar” as deficiências internas de uma organização de TI (que não são visíveis aos usuários e clientes), porém um Service Desk ineficiente (ou a falta de um) pode trazer uma má impressão sobre a eficiência geral de uma or-ganização de TI.

Veja outros benefícios que um Service Desk pode trazer para uma organização de TI:

• Melhora na percepção e satisfação dos clientes sobre os serviços fornecidos;• Aumento da acessibilidade através de um ponto único de contato, comunicação e

informação;• Melhor qualidade e agilidade no tratamento de requisições de clientes e usuários;• Melhora na comunicação e trabalho em equipe;• Utilização otimizada dos recursos de suporte de TI e aumento da produtividade

do negócio;• Informações gerenciais mais significativas para apoio à tomada de decisão



Tipos de Service Desk, qual o mais adequado?RENÊ CHIARI

Existem muitas maneiras de estruturar um Service Desk. Neste artigo, apresentamos as estruturas mais comuns. Contudo, pode ser necessário para uma organização im-plementar uma estrutura que combine uma ou mais destas opções, a fim de atender completamente as necessidades do negócio.

Service Desk ‘Local’

Nesta estrutura, o Service Desk está fisicamente localizado próximo à comunidade de usuários suportados. Esta opção facilita a comunicação, o que agrada alguns usuários, mas pode ser injustificável manter um grupo de recursos de suporte que sazonalmente pode estar ocioso, à espera de incidentes e requisições de serviço locais, enquanto em outros sites (localidades) a coisa pode estar “pegando”.

Algumas razões para se adotar a estrutura de um Service Desk local são:

• Diferenças políticas, culturais e de idiomas;• Diferentes fuso-horários;• Grupos especializados de usuários;• Existência de serviços customizados ou especializados, que requerem conheci-

mento especializado;• Usuários críticos ou VIP.

Service Desk ‘Virtual’

Calma, não se trata de uma central de atendimento robotizada.

Através do uso de tecnologia, particularmente a internet, e outras ferramentas corpo-rativas de suporte, é possível dar a impressão de um Service Desk único e centralizado, quando de fato os recursos podem estar distribuídos em locais físicos variados.

Com isso, algumas opções tornam-se viáveis, como o home working, offshoring ou out-sourcing. Porém, é importante preservar a consistência e uniformidade na qualidade do serviço e termos culturais.

Follow the Sun

Não se espante se um dia for atendido por um indiano ao solicitar suporte de uma grande fabricante de software (ex.: Microsoft). Trata-se de um Service Desk “Follow The Sun”.

Algumas organizações com atuação global podem combinar dois ou mais Service Desk distribuídos para oferecer uma estrutura de suporte 24 horas. Esta opção pode otimizar os custos de um Service Desk full-time, pois evita-se despesas adicionais com adicional



noturno ou hora extra, por exemplo.

Por outro lado, esta estrutura pode oferecer alguns desafios, como manter os proces-sos, ferramentas e banco de dados de informações padronizados e compartilhados com todas as unidades, para que o atendimento seja uniformizado pelas diversas unidades espalhadas pelo globo.

Grupos de Suporte Especializado

Em algumas organizações pode ser interessante criar um grupo de suporte especializa-do dentro da estrutura do Service Desk (em alguns lugares o nome “célula de suporte” é utilizado). Desta forma, os incidentes relacionados a um determinado serviço de TI podem ser encaminhados diretamente para um grupo de suporte especializado. Isso permite uma resolução muito mais rápida e assertiva destes incidentes.

Um exemplo clássico desta abordagem é quando ligamos para uma central de atendi-mento de operadoras de Telecom ou TV a cabo e somos orientados a digitar um número para cada assunto específico, por exemplo, suporte técnico, faturamento, reclamações, novos serviços, etc.

Contudo, neste mesmo exemplo podemos notar que eventualmente há certo exagero destas organizações, oferecendo muitas opções de atendimento especializado, o que pode fazer com que a experiência do usuário se torne muito cansativa.

Agora que você já conhece as principais estruturas de Service Desk, fica muito mais fácil refletir sobre uma estrutura adequada a sua organização.



Melhores Práticas ou Boas Práticas, qual é o certo?“Boas práticas” e “melhores práticas” são jargões amplamente utilizados em nossa área. Porém, sempre fica uma dúvida: qual é o termo correto a se utilizar?

As duas estão corretas. Mas a seguir você entenderá melhor qual a melhor forma de utilizá-las.

No contexto do Gerenciamento de Serviços, o termo “prática” é utilizado para descrever um conjunto de habilidades e competências, um método reconhecido ou uma atividade padrão. Uma prática pode ser unicamente responsável por um ou mais “processos”, embora os processos tipicamente trabalhem através de toda uma unidade funcional.

Sendo assim, vamos a algumas definições:

Melhor prática

Uma “melhor prática” pode ser considerada como uma prática “geralmente aceita”, que necessita uma comprovação empírica de um resultado específico e é proposto por uma comunidade de prática como um padrão ou o mínimo necessário para ser consid-erado como uma prática. A “melhor prática” é transformada em “boa prática” através de sua aplicação para ajudar a alcançar um ou mais resultados desejados.

Boa prática

Uma “boa prática” é o resultado da aplicação de uma melhor prática em um contexto ou situação específica de uma organização, uma adaptação para atender a requisitos locais. Uma “boa prática” pode ser definida como atividades desenhadas para atingir um resultado desejado, utilizando um conjunto de ações comprovado, recomendado e aprovado. A palavra-chave aqui é comprovar o senso de prática através de sua apli-cação, não teoria.

A “boa prática” pode ser considerada como um consenso geral sobre a correta aplicação de determinados conceitos, termos e técnicas que podem melhorar a visibilidade e o controle gerencial que uma organização provedora de serviço tem sobre a qualidade e o custo dos serviços que fornece.

O ITIL apresenta-se como uma “boa prática” e suas características incluem:

• Ser um padrão genérico disponível no mercado (diferentemente de metodologias proprietárias);

• Pode ser aplicado em vários ambientes e situações – empresas de grande ou pe-queno porte, públicas ou privadas, de diversos setores da economia



O que é um Plano de Capacidade?RENÊ CHIARI

O Plano de Capacidade é o principal produto gerado pelo processo de Gerenciamento da Capacidade, cujo objetivo é:

• Prover capacidade de TI (tecnologia e pessoal) com recursos aceitáveis para aten-der os requisitos atuais e futuros dos clientes e usuários;

• Manter o balanceamento entre custos x capacidade – provisão x demanda;• Reconhecer novas tecnologias e investir apropriadamente para entregar os requi-

sitos de negócio;• Gerenciar a capacidade certa, no lugar correto, no momento certo, para o cliente

certo, a custos corretos.• Um plano de capacidade completo deve levar em consideração os principais re-

cursos envolvidos na entrega do serviço:• Recursos humanos: >> Ex.: Equipes de suporte, desenvolvedores, administrado-

res de rede etc;• Recursos Técnicos: >> Ex.: banco de dados, link (banda), servidor (CPU, memória,

storage);• Recursos Financeiros.• Para o desenvolvimento do plano, também devem ser considerados alguns ele-

mentos, como:• Demanda atual e prevista (futura) por serviços. Pode-se considerar como deman-

da futura, por exemplo, um novo cliente para o próximo mês, com uma demanda esperada de consumo de mais de 500 acessos simultâneos ao sistema comercial. Ou, uma data comemorativa, que irá aumentar as compras de um site de e-com-merce em quase 40%;

• Limitações (thresholds). Em outras palavras, os limites aceitáveis de uso da capaci-dade em relação a um serviço ou componente do serviço. Por exemplo, máximo de 100 transações por minuto, máximo de 80% de consumo de memória e/ou CPU, bem como os procedimentos de resposta caso estes limites sejam ultrapassados;

• Custos de atualização/manutenção da capacidade do serviço;• Impactos potenciais em questões regulatórias ou contratuais;• Procedimentos que permitam a análise preditiva.

Por fim, a organização de TI deve monitorar o uso da capacidade e realizar ajustes de desempenho quando necessário.

É importante ressaltar que o plano de capacidade deve ser revisado no mínimo anual-mente. Considerando que no mundo de hoje a Tecnologia da Informação deixou de ser um fator irrelevante e passou a ser uma questão de sobrevivência das empresas, os requisitos de capacidade (assim como outros requisitos de nível de serviço) passaram



a ser muito mais dinâmicos.



A razão pelo qual um incidente não “vira” um problemaRENÊ CHIARI

Um dos mais incompreendidos relacionamentos entre processos de gerenciamento de serviços propostos pela ITIL está, sem dúvida, entre o Gerenciamento de Incidentes e o Gerenciamento de Problemas.

Incompreendido porque ainda é comum ouvir a expressão “um incidente que vira um problema” nos corredores das organizações de TI.

A razão pelo qual um incidente não vira um problema é a mesma pela qual uma febre não vira uma gripe. Gripes causam febres, dores no corpo. Problemas causam incidentes. E não o contrário.

Incidentes e Problemas são duas entidades distintas, cada uma com o seu próprio cic-lo de vida e tratadas por dois processos com objetivos bastante distintos: o Gerenci-amento de Incidentes, que busca resolver o mais rápido possível e não se preocupa muito com as circunstâncias da causa, e o Gerenciamento de Problemas, que busca a identificação da causa raiz e uma solução definitiva, mesmo que isso possa levar algum tempo.

Considerar que um problema só pode ser registrado no momento em que o incidente relacionado esteja resolvido é o mesmo que considerar que a busca pela cura de uma gripe só pode ser iniciada quando a temperatura (febre) estiver estabilizada.



10 coisas que voce deveria saber sobre a ITILRENÊ CHIARI

Há alguns anos atrás, ninguém conhecia a ITIL. Agora, é difícil encontrar uma revista, portal ou blog sobre gestão de TI sem que o termo “ITIL” seja mencionado. Apesar da fama, muitos profissionais de TI não entendem completamente o que é ITIL. Seguem a seguir 10 coisas que você deveria saber:

#1: ITIL significa Biblioteca de Infraestrutura de Tecnologia da Informação (Infor-mation Technology Infrastructure Library)�

A biblioteca ITIL contém um conjunto de boas práticas que são usadas para desenvolv-er e executar gerenciamento de serviços de TI. Ela oferece um número de benefícios, incluindo o aumento da vantagem competitiva através da redução de custos, cresci-mento e agilidade, mais eficiência corporativa através da racionalização de processos de TI; melhor valor da TI através do alinhamento do negócio com a TI, e melhor satis-fação de clientes e usuários.

#2: A organizaçao que suporta a ITIL chama-se AXELOS�

Através de um processo de licenciamento sobre a propriedade intelectual do ITIL e Prince2, foi estabelecido uma joint venture entre o Cabinet Office (UK) com a empre-sa de serviços britânica Capita. Esta iniciativa levou a criação de uma nova empresa, chamada Axelos.

#3: A biblioteca ITIL consiste em uma série de livros que fornecem orientações e recomendações�

Dentre todas as publicações, incluem-se as seguintes principais:

• Estratégia de Serviço;• Desenho de Serviço;• Transição de Serviço;• Operação de Serviço;• Melhoria de Serviço Continuada.

#4: Para permitir uma implantaçao bem sucedida de práticas de gerenciamento de serviços, a ITIL enfatiza a necessidade de um forte patrocínio da alta direçao�

A implementação de práticas de gerenciamento de serviços recomendadas pela ITIL é uma iniciativa que envolve mudança cultural. Pessoas irão questionar sobre terem que fazer coisas diferentes do que sempre fizeram. Portanto, é necessário apoio de um patrocinador da alta direção para influenciar a mudança. Sem um bom patrocinador, é melhor nem tentar – ou ao menos estar ciente de que o sucesso será limitado.

#5: ITIL nao é gestao de projetos�



A ITIL não está concentrada na criação de coisas (produtos) como é comumente o foco de projetos. A ITIL concentra-se em práticas para o fornecimento de serviços de TI para a empresa, que são organizadas em processos de gerenciamento de serviços de TI.

#6: Apesar de sua popularidade, nem todas as respostas e conteúdos estao disponíveis na ITIL�

A ITIL é um conjunto de abordagens e melhores práticas. É um guia de referência para gerenciamento de serviços de TI. Ela contém alguns processos e templates, mas não é uma metodologia e não contém todos os detalhes de uma implementação. Organ-izações que queiram usar a ITIL podem seguir as orientações gerais e a partir daí de-senvolver processos mais detalhados que façam sentido para a própria organização.

#7: ITIL nao é uma ferramenta�

Você pode implementar muitos aspectos da ITIL usando ferramentas, mas ferramen-tas não são impostas/requeridas. Para organizações pequenas, planilhas e templates simples podem dar conta do recado. Para organizações maiores, provavelmente será necessário encontrar ferramentas apropriadas para suportar o gerenciamento de serviços de TI.

#8: ITIL nao é uma proposiçao “tudo ou nada”�

A partir do princípio de que a ITIL é uma série de abordagens em áreas distintas, uma organização pode implementar parte destas abordagens, ou todas elas. Não há regras impondo que tudo deve ser implementado. Adapte e adote!

#9: Práticas da ITIL podem ser implementadas em estágios�

Não há regras que enfatizem a necessidade de todas as práticas descritas na ITIL ser-em implementadas de uma só vez. Muitas organizações implementam estas práticas em fases, durante períodos determinados.

#10: Você (profissional) pode se certificar em ITIL. A sua empresa não!

Existe um programa de certificação em ITIL para profissionais, divididos basicamente em três níveis: nível básico (fundamentos, nível intermediário (capability / lifecycle modules) e nível avançado (Expert, Master).

Não existe certificação ITIL para empresas. A norma internacional ISO/IEC20000 é o caminho para atestar a qualidade de serviços de TI fornecidos e operados por empre-sas. Em outras palavras, é a forma de atestar que as empresas aplicam, de fato, as prin-cipais recomendações da biblioteca ITIL



Compreendendo os principais conceitos do COBIT 5RENÊ CHIARI

O COBIT 5 é a mais recente versão do framework de boas práticas de governança e gerenciamento empresarial de TI, que incorpora muitos conceitos e teorias ampla-mente aceitos.

Nesta serie de artigos, vamos explorar os princípios fundamentais do framework, servindo como uma referência para a aplicação do COBIT 5 em sua organização.

A Governança Empresarial de TI e o COBIT 5

Informação (no sentido mais abrangente da palavra) e tecnologias relacionadas estão se tornando fatores cruciais na sustentabilidade, crescimento e gerenciamento do val-or e risco na maioria das empresas. Como resultado, a TI deixou de atuar simplesmente no papel de suporte e passou a assumir uma posição central dentro das empresas. O papel realçado da TI na criação de valor e gerenciamento de risco empresarial, veio acompanhado por uma crescente ênfase na Governança e Gerenciamento Empresar-ial de TI. Os stakeholders anseiam por assegurar que a TI cumpra as metas empresar-iais.

A Governança e Gerenciamento Empresarial de TI é parte integral de toda a gover-nança corporativa. Ela endereça a definição e implementação de processos, estruturas e mecanismos relacionais dentro da empresa, que permitem ao pessoal de negócio e da TI executarem suas responsabilidades para suportar a criação e sustentabilidade do valor ao negócio. A Governança e Gerenciamento Empresarial de TI é complexa e multifacetada. Membros do comitê de governança e a alta direção, tipicamente precis-am de assistência para implementá-la. Através dos anos, frameworks de boas práticas foram desenvolvidos e promovidos para auxiliar neste processo.

Lançado em 2012, o COBIT 5 foi construído e integrado com base em 20 anos de de-senvolvimento neste campo de atuação. Desde o seus primórdios, centrado na comu-nidade de auditoria de TI, o COBIT se tornou um framework de Governança e Geren-ciamento de TI mais abrangente, compreensivo e aceito.

O COBIT 5 foi adicionalmente complementado com os frameworks Val IT e Risk IT. Antes do COBIT 5, o Val IT endereçava processos de negócio e responsabilidades na criação de valor empresarial e o Risk IT fornecia uma visão de negócio holística sobre o gerenciamento de riscos. Agora, ambos estão incorporados ao COBIT 5.

O framework COBIT 5 é construído em torno de cinco princípios fundamentais:

1. Satisfazer necessidades das partes interessadas;2. Cobrir a organização de ponta a ponta;3. Aplicar um framework integrado e único;



4. Possibilitar uma visão holística;5. Separar Governança do Gerenciamento.

Dando sequência à série de artigos sobre os principais conceitos do COBIT 5, neste artigo iremos apresentar o primeiro princípio do COBIT 5:

Satisfazer necessidades das partes interessadas�

O primeiro princípio implica que o COBIT 5 fornece todos os processos e habilitadores necessários para suportar a criação de valor através do uso da TI (pode-se interpretar criação de valor como geração de benefícios). Este princípio está intimamente alinha-do com o conceito de longa data chamado alinhamento estratégico. A convicção de que um componente núcleo da governança de TI é atingir o alinhamento estratégico entre TI e o resto da organização é um elemento crítico do COBIT. Entretanto, sabe-mos que há um contínuo desafio para as organizações em descobrir como atingir o tal alinhamento.

Para auxiliar as organizações a alavancar o alinhamento estratégico, os desenvolve-dores do COBIT realizaram uma pesquisa para fornecer orientações na compreensão de como as metas empresariais direcionam metas de TI relacionadas e vice-versa. Esta pesquisa foi baseada em entrevistas detalhadas e avaliações especializadas em difer-entes setores. Então, uma lista genérica de metas empresariais, metas de TI relacion-adas e seus inter-relacionamentos foi estabelecida. Você pode consultar esta tabela no framework COBIT 5, que é gratuito e pode ser obtido no site da ISACA, mediante cadastro.

Este cascateamento constitui o ponto de entrada principal do COBIT 5. Ele sugere que as organizações devam começar analisando o alinhamento estratégico/TI através da definição e correlação de metas empresarias e metas de TI.

O COBIT 5 utiliza o termo “metas empresariais” para sinalizar explicitamente que o framework inclui empresas orientadas, ou não a lucro, e governamentais. Adicional-mente, o COBIT 5 fala sobre metas de TI.

No COBIT 5, a importância das metas de TI caminham para o foco principal nos seus habilitadores, como processos de gerenciamento e governança.

Dando sequência ao artigo anterior da série sobre os principais conceitos do COBIT 5, neste artigo vamos falar sobre o uso do balanced scorecard (BSC) como facilitador de um processo de medição para verificar se as necessidades das partes interessadas estão sendo atendidas.

Para verificar se as necessidades das partes interessadas (stakeholders) estão sendo atendidas, deve ser estabelecido um processo de medição sólido. Os métodos de de-sempenho atuais, como o Retorno sobre o Investimento (ROI), capturam os benefícios dos projetos e sistemas de TI, mas refletem somente uma parte limitada (tangível) do



valor que pode ser entregue pela TI.

Para facilitar um processo mais abrangente de medição, o desenvolvimento do CO-BIT 5 incorporou conceitos do balanced scorecard. Em um dos apêndices do COBIT 5 as metas empresariais e metas de TI associadas estão agrupadas sob as perspectivas do balanced scorecard. O COBIT 5 também fornece exemplos de métricas para medir cada uma destas metas e construir um scorecard para as atividades relacionadas à TI.

Além disso, o COBIT 5 fornece medições de resultado no nível dos 37 processos de-talhados do framework. Logicamente, estas metas e métricas de processos não podem ser simplesmente comunicadas às partes interessadas, pois estes seriam sobrecarre-gados de informação. Preferencialmente, as metas e métricas de processos devem ser consolidadas e agregadas de uma forma que facilite o balanced scorecard utilizável e compreensível para todo o ambiente de TI. Desta maneira, obalanced scorecard per-mite que a organização determine se as necessidades das partes interessadas estão sendo atendidas.

Dando sequência a série de artigos sobre os principais conceitos do COBIT 5, neste ar-tigo iremos apresentar o segundo princípio do COBIT 5: Cobrir a organização de pon-ta a ponta.

Este princípio considera que o COBIT 5 cobre todas as funções e processo de uma organização. O COBIT 5 não foca somente na função de TI, mas trata a informação e tecnologias relacionadas como ativos que precisam ser tratados como qualquer outro ativo da organização.

Desta forma, os gerentes de negócio deveriam se responsabilizar por gerenciar os seus ativos relacionados a TI assim como o fazem para outros ativos, como plantas físicas, recursos financeiros e humanos, dentro de suas próprias unidades organizacionais e funcionais. O negócio deve assumir a responsabilidade, e prestar contas, governando o uso da TI na criação de valor a partir dos investimentos em TI como alavanca para o negócio.

O foco em cobrir a organização de ponta a ponta implica em uma mudança crucial na filosofia dos gestores de TI e de negócio. Ele compreende uma mudança do gerencia-mento de TI como um custo para o gerenciamento de TI como um ativo. Esta mudança é um elemento essencial na criação de valor ao negócio. Se os gestores não assumirem a responsabilidade pela TI, a empresa inevitavelmente irá jogar o orçamento de TI em múltiplas iniciativas sem uma visão clara do impacto destas iniciativas na capacidade da organização. Desta forma, a TI deixa de se tornar um ativo estratégico.

O COBIT 5 cobre as responsabilidades de TI e de negócios relacionados a TI. Como demonstração, o COBIT 5fornece gráficos matrizes de responsabilidades (RACI) para seus processos, dos quais papeis de TI e negócio estão incluídos.



Dando sequência a série de artigos sobre os principais conceitos do COBIT 5, neste artigo apresentamos seu terceiro princípio: Aplicar um framework integrado e único.

Este princípio descreve o alinhamento em alto nível do COBIT 5 com outros padrões e frameworks relevantes, servindo como um framework abrangente para a Governança Empresarial de TI.

A ISACA realizou um grande esforço durante os anos para alinhar o COBIT com out-ros frameworks, como COSO, ITIL, PMBOK, TOGAF, PRINCE2, etc. Muitos processos do COBIT 5 são inspirados pelas orientações destes frameworks. Por outro lado, seus processos e práticas também são relacionados e alinhados com um ou mais frame-works desta área.

Para trabalhar efetivamente com o COBIT 5 e outros frameworks, a publicação COBIT 5: Enabling Processes inclui um mapeamento de alto nível de cada um dos processos do COBIT 5. Considerando que o COBIT 5 também integra os frameworks Risk IT e o Val IT, torna-se uma referência única que inclui em seus escopos, tanto orientações anteriores da ISACA, quanto orientações de outros padrões e frameworks desta área de atuação.

Nesta abordagem ampla, o COBIT 5 identifica um conjunto de habilitadores da gov-ernança e do gerenciamento que inclui 37 processos. Na camada de governança, há cinco processos agrupados no domínio: “avaliar, direcionar e monitorar (Evaluate, Di-rect and Monitor – EDM)”. Estes processos ditam as responsabilidades da alta direção para a avaliação, direcionamento e monitoração do uso dos ativos de TI para a criação de valor. Este domínio cobre a definição de um framework de governança, o estabe-lecimento das responsabilidades em termos de valor para a organização (ex. critérios de investimento), fatores de risco (ex. apetite ao risco) e recursos (ex. otimização de recursos), além da transparência da TI para as partes interessadas (stakeholders).

A camada de gerenciamento é definida por quatro domínios: alinhar, planejar e or-ganizar (Align, Plan and Organize – APO); construir, adquirir e implementar (Build, Ac-quire and Implement – BAI); entregar, servir e suportar (Deliver, Service and Support – DSS); e monitorar, analisar e avaliar (Monitor, Evaluate and Assess – MEA).

O domínio APO (Alinhar, Planejar e Organizar) diz respeito à identificação de como a TI pode contribuir melhor com os objetivos de negócio. Processos específicos do domí-nio APO estão relacionados com a estratégia e táticas de TI, arquitetura empresarial, inovação e gerenciamento de portfólio.

Outros processos importantes endereçam o gerenciamento de orçamentos e custos, recursos humanos, relacionamentos, acordos de serviços, fornecedores, qualidade, ri-sco, e segurança. O domínio BAI (Construir, Adquirir e Implementar) torna a estraté-gia de TI concreta, identificando os requisitos para a TI e gerenciando o programa de investimentos em TI e projetos associados. Este domínio também endereça o geren-

ciamento da capacidade; mudança organizacional; gerenciamento de mudanças (TI); aceite e transição; e gerenciamento de ativos, configuração e conhecimento.

O domínio DSS (Entregar, Servir e Suportar) se refere a entrega dos serviços de TI necessários para atender aos planos táticos e estratégicos. O domínio inclui processos para gerenciar operações, requisições de serviços e incidentes, assim como o gerenci-amento de problemas, continuidade, segurança e controle de processos de negócio.

Documents

REDISTRIBUIÇÃO diferenças entre a ITIL v2 e V3 Parte Serviços: a ponte perdida entre negócios e