Guia completo sobre Gerenciamento de Serviços de TI com ITIL

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çãoeimplementaçãodesoluçõesdeITSM
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
Especialistaemoperaçõesegestãodeserviços
deTI.Trezeanosdeexperiêncianosuporte,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
GerenciamentodeServiçosdeTI.É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.
ÉcertificadocomoCBPP,PMP,ITILPractition-
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,BancodeDados,AnaliseemCódigoFonte,
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
EspecialistaemHelpDesk/ServiceDesk/Sup-
portCenter,realizatreinamento,consultoriae
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
BrasileiradeDinâmicadosGrupos.Membroda
entidademundial“TheAssociationofSupporte
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ãoemtodososâmbitos,permitindoqueaolongodemaisdesteperíododemais
de cinco anos fosse possível consolidar um material extremamente rico para a comu-
nidade.

Artigos Temperados com Opinião �� 8
Adoção da ITIL: Santo de fora de casa faz milagres? �� 9
BYOD explodiu o CMDB. Já era essa ITIL! �� 10
Demanda instantânea por alta capacidade �� 13
Gerenciamento de Serviços de TI x Boas Práticas: Uma questão de hábito �� 14
ISO 20000 atestado de melhores práticas? �� 16
ITIL e Outsourcing Algumas peças ainda não se encaixam �� 17
ITIL e satisfacão de clientes �� 20
ITIL - O que não está nos livros? �� 22
ITIL para Inglês ver �� 24
ITILfobia �� 26
Na prática: pessoas que fazem a diferença �� 28
Os fora da lei – Porque é tão difícil seguir processos? �� 30
Porque é tão difícil gerenciar os serviços de TI? �� 33
Quando o vilão está dentro de casa �� 35
Realmente precisamos de modelos e padrões? �� 37
Seguranca da Informação e a arte de no dizer não �� 40
Artigos com Altos Índices de Teoria �� 41
A eterna e incendiária briga entre a Gestão de Incidentes e de Problemas �� 42
A importância do Plano de Continuidade �� 44
A relação entre ITIL e ISOIEC20000 �� 46
Catálogo de Serviços – O desconhecido �� 48
Como o BDGCCMDB pode aumentar a eficiência dos processos de suporte a serviços �� 51
Compreendendo a ITIL a partir de uma perspectiva nada convencional um show de rock �� 53
Do inferno ao céu – Como o exemplo do Corinthians pode ser utilizado na Gestão de Serviços �� 55
Entenda a importância da classificação do Incidente �� 57
Níveis de serviço tão necessários quanto inúteis �� 59
O conhecimento é meu e ninguém tasca �� 61
O que é Gerenciamento de Serviços de TI? �� 63
Os 10 Mandamentos da ITIL �� 65
Para que serve a ISO 20000? �� 69
Principais diferenças entre a ITIL v2 e V3 Parte I �� 72
Principais diferenças entre a ITIL v2 e V3 Parte II �� 74
Serviços: a ponte perdida entre negócios e TI �� 78
Sistemas de qualidade: a ilusão da melhoria contínua �� 80
USMBOK o ITIL para gerenciamento de qualquer serviço �� 82
Artigos para Aquecer a Carreira �� 83
Certificações abrem portas mas não garantem o seu emprego �� 84
Redes Sociais: 5 erros a serem evitados no LinkedIN �� 85
Tirei a certificação ITIL e agora? �� 87
Vale a pena investir em certificações profissionais? �� 90
Artigos Para Por a Mão na Massa �� 92
5 dicas para a Gestão de Problemas Proativa �� 93
5 passos para definir um bom Acordo de Nível de Serviço SLA �� 95
25 dicas infalíveis para que seu projeto de implantação da ITIL seja um fracasso �� 98
Catálogo de Serviços: Para que complicar? �� 100
ITIL – é preciso saber vender �� 102

Pessoas: o calcanhar de Aquiles na adoção da ITIL �� 104
Problemas – como identificá-los? �� 107
Profissionalizando a gestão dos projetos de TI e ITSM Parte I �� 108
Profissionalizando a gestão dos projetos de TI e ITSM Parte II �� 110
Profissionalizando a gestão dos projetos de TI e ITSM parte III �� 112
Tempo para solucionar problemas: mais um problema ou a solução? �� 115
Transformando sua poltica de segurança da informação em um ativo estratégico �� 116
Artigos com toque de tecnologia �� 121
A gamificação invadiu nossa praia �� 122
ITSM, redes sociais e Content Management Systems dá jogo? �� 124
O que as ferramentas não fazem por você �� 126
Artigos Exlcusivos do Chef �� 128
Os desafios da criação de valor atráves da Operação de Serviços �� 129
O que são incidentes, problemas, erros conhecidos e requisições de serviço segundo a ITIL? �� 130
Gerenciamento da Configuração e Ativos de Serviço: o processo “camarada” da ITIL® �� 133
Qual a diferença entre o Gerenciamento de Mudanças e o Gerenciamento de Liberação e Implan-
tação? �� 135
A ITIL é uma moda? �� 136
4 métricas para monitorar o desempenho de uma CMDB (Configuration Management Database) ��
137
O que é um Service Desk (ou Central de Serviços)? �� 139
Tipos de Service Desk, qual o mais adequado? �� 140
Melhores Práticas ou Boas Práticas, qual é o certo? �� 142
O que é um Plano de Capacidade? �� 143
A razão pelo qual um incidente não “vira” um problema �� 145
10 coisas que você deveria saber sobre a ITIL �� 146
Compreendendo os principais conceitos do COBIT 5 �� 148

Artigos Temperados com Opinião

9
ITSM 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
pelofatodeque,emquasetodasestasoportunidades,encontreinasempresasàsquais
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.
IstoporqueaeficiênciadeconsultoresexternoseminiciativasdeadoçãodaITIL®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!”

10
BYOD explodiu o CMDB. Já era essa ITIL!
ROBERTO COHEN
Umaconsequênciadadisseminaçãodosdispositivosmóveiséqueosfuncionáriosago-
rarealmenteacessamdadoscorporativosdetudoquandoécanto.Napraia,noboteco,
em casa etc.
Isso já é manjado, só é novidade pra quem ainda não acordou.
EasempresastentaramentrarnaondaoferecendoBlackberrys,iPhoneseiPad(eseus
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-
presasfazeremcotaçãoparamigrardoBlackBerryversãoumparaversão10(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_device
PCWorld – 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.

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

12
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

13
Demanda instantânea por alta capacidade
RENÊ 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.

14
Gerenciamento de Serviços de TI x Boas Práticas:
Uma questão de hábito
ALBERTO ANDRADE
QuandooassuntoéGerenciamentodeServiçosdeTI,aITILfrequentementeapresen-
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
problemasefrustram-senasprimeirasdificuldadesdeimplementação,justamentepor
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-

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

16
ISO 20000 atestado de melhores prá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.

17
ITIL e Outsourcing Algumas peças ainda não se
encaixam
RENÊ CHIARI
A ITIL®, apesar de ser uma das melhores referências para gestão de serviços de TI, nos deixa
comváriospontosdeinterrogaçãoquandoabordadaemumambientedeprovedoresdeOut-
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.
Istorepresentaumenormepotencialdeconflito,poismesmoqueoclientetenhaespe-
cificadooalinhamentocomaITIL®comoumpré-requisitoparaooutsourcing,é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

18
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,masespecialmenteemSLM,ondeoconceitodeSLA“baseadononegó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

19
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,amaioriadosprocessosdeplanejamentoouestratégicostemfocoem
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!

20
ITIL e satisfacão de clientes
CLAUDIA MARQUESANI
Parece uma frase bastante pessimista para quem tem um site chamado ITIL® NA
PRÁTICA,mastenhorealmentequeserrealista:IMPLEMENTARAITIL®NÃOGARANTE
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

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

22
ITIL - O que não está 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®quasesemprepartemdoprincípioqueaecologiaorganizacionalnecessáriapara
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-

23
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çãodeprocessos,sugiroumaolhadanoBusinessProcessMaturityModel–BPMM.
É um modelo de maturidade, baseado no CMM, que busca medir a capacidade de or-
ganização de utilizar processos.

24
ITIL para Inglês ver
GUSTAVO 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.
ComoprofissionalcomalgumaexperiênciaeminiciativasdeadoçãodoITIL®,euposso
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.
Omodeloédirecionadoàspopulaçõesdospaíses.Nãoéummodeloparaseraplicadoa
diferentesorganizaçõesdeummesmopaís.Elebuscadiagnosticarquaisvaloresecom-
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

25
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íscomaltoíndicedemasculinidadenãoquerdizerqueexistemmaishomensoumul-
heresnomercadodetrabalho.Querdizerapenasqueoshomensemulheresdestepaí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.Estesvaloresdiferentesdevemserobservadoscomcuidadopelosprofissio-
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!” :)

26
ITILfobia
RENÊ 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

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

28
Na prática: pessoas que fazem a diferença
RENÊ 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

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

30
Os fora da lei – Porque é tão difícil 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-

31
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,
decoloueminutosdepois,ovidrodacabineestourou.Opilotofoiarremessadoparafora
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.
Sabemoqueomecânicofezaoenvésdeseguiressepassoapasso?Comparouoparafu-
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

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

33
Porque é tão difícil gerenciar os serviços de TI?
CLAUDIA MARQUESANI
Umalunomeudocursodemanagermedisseumafrasequeacabouvirandoestepost…
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

34
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éprecisoantesdemaisnadaCOMEÇAR.Nãoespereatingiromundoperfeito
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!

35
Quando o vilão está dentro de casa
CLAUDIO 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ção é 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ção 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ção,documentaçãoedocumentação:Manterumadocumentaçãoatua-
lizadaéessencialparaprotegeroconhecimentoinstitucional.Infelizmente,existeuma
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 não se torne dependente: Desde gerenciamento
de chaves de criptografia até a sistemas de auditoria e análise do comportamento é

36
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-15m
www.net-security.org/secworld.php?id=11062
www.itilnapratica.com.br/o-conhecimento-e-meu-e-ninguem-tasca/
pcaobus.org/Pages/default.aspx
www.isaca.org/Images/journal/jrnlv4-07-common-ground-1.jpg

37
Realmente precisamos de modelos e padrões?
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
ecomplexidade,funcionou,funciona,deveriafuncionarouiráfuncionar.Issoocorreem
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-
elosenãosecomportardeacordocomelesmostraqueouomodelointeiroestá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óriasentreíndiosseguiamum“padrão”queobedeciaaregrascodificadasemseus
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áquemodelosservemparadescreveroucontrolarcoisas“abstratas”comoser-
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

38
“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çãodeserviços,baseadoempráticascomoITIL,vocêpodeestarfalhandomiser-
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.
OsmelhoresconsultoresdeITSMsabemdisso.Masofatoéqueapressa,afaltadesen-
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.

39
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-
noradosoumesmodistorcidos.UmexemploclássicoéoCMDB.Qualoprincípiochave
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
àpartirdoprincípiochave,masnãonecessariamentecomoprincípiochavedeumú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.

Guia completo sobre Gerenciamento de Serviços de TI com ITIL

Guia completo sobre Gerenciamento de Serviços de TI com ITIL

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (7)

Destaque

Destaque (8)

Semelhante a Guia completo sobre Gerenciamento de Serviços de TI com ITIL

Semelhante a Guia completo sobre Gerenciamento de Serviços de TI com ITIL (20)

Guia completo sobre Gerenciamento de Serviços de TI com ITIL