ITSM Na Pratica - O Caviar de 5 Anos de Postagens

REDISTRIBUIO: Voc concorda que no ir copiar, redistribuir ou explorar comer-
cialmente qualquer parte deste documento sem a permisso 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 profssionais de
Gerenciamento de Servios de TI. Como apoio so usadas referncias de outros mate-
riais sem infringir direitos autorais de terceiros
Copyright 2014 - Todos os direitos reservados
1 edio publicada em julho de 2014
www.mapadoitil.com.br
Andr Bernardo
Especialista em Gerenciamento de Projetos.
Scio-fundador da COMMUNIT. Experincia
em gesto de projetos estratgicos. Certifca-
dos: PMP, ITIL foundation.
Andr Jacobucci
Consultor de Integrao e Gerenciamento de
Servios. Trabalha no setor de TI h mais de 18
anos. Sua experincia abrange vrios segui-
mentos, incluindo servios fnanceiros (banca
e seguros), Servios de TI,
Telecom, edio e de petrleo. Possui extensa
experincia em gesto de projetos, consulto-
ria em ITIL, COBIT e ISO / IEC 20000 , a ad-
aptao e implementao de solues de ITSM
e concepo, desenvolvimento e implantao
de aplicativos.
Certifcaes: ITIL Expert, ITIL v2 Service
Manager, ISO/IEC 20000 Consultant, COBIT
Foundations
Alberto Andrade
Especialista em operaes e gesto de servios
de TI. Treze anos de experincia no suporte, im-
plantao e start up de projetos de outsourc-
ing baseado em ambientes de suporte tcnico,
Helpdesk e redes de dados.
Possui as certifcaes ITIL Foundation, MCP
Microsoft e Cisco CCNA.
Bruno Caiado
Consultor especialista em Governana e Ger-
enciamento de Servios. Especializaes:
ITIL, ISO 27001, ISO/IEC 20000, COBIT,
Cloud Computing, Corporate Citizenship &
Corporate Affairs.
Carlos Afonso
Gerente de Operaes. Especializaes: Gov-
ernance, Control, Assurance and Project Con-
sulting in IT.
Claudia Marquesani
Consultora Snior e instrutora especialista em
Gerenciamento de Servios de TI. certifcada
ITIL, COBIT, ISO 20.000, ISO 27000 e TOGAF.
Atua h mais de 15 anos em projetos baseados
em ITIL, ISO 20.000 e governana de TI em
multinacionais e empresas de grande porte.
Graduada pela Fundao Getlio Vargas,
co-fundadora do site ITSM na Prtica,
Gerente de Central de Servios e suporte
entusiasta de novas tendncias de mercado
e assuntos relacionados a gesto de servios,
suporte e atendimento.
Claudio Dodt
Business Continuity & Security Senior Con-
sultant, atua na rea de tecnologia h mais de
10 anos exercendo atividades como tcnico e
analista de suporte, Analista de Segurana Sr.,
Security Offcer e Supervisor
de Infraestrutura e Segurana. Desenvolveu
atividades em empresas brasileiras e multina-
cionais, tendo participado no Brasil e no exte-
rior em projetos de segurana de diversos seg-
mentos como Educacional, Financeiro, Sade,
Agroindstria, Indstria Alimentcia, Naval,
Metal-Mecnica e Txtil.
Especializaes: ITIL, CISSP, CISA, CRISC,
ISO 27001, ISO/IEC 20000, COBIT, Cloud
Computing Foundation.
Gustavo Tavares
Graduado em Administrao e ps-graduado
em Gesto Estratgica de TI pela FGV. Grande
experincia com otimizao de processos de
negcio por meio da TI.
Trabalhou planejando e gerenciando os con-
troles de Governana de TI e os processos de:
desenho de solues, gesto de demandas;
gesto de projetos; qualidade de software;
gesto de servios de TI, gesto de contratos
e gesto da segurana da informao. Atual-
mente lidera as iniciativas e a equipe de TI do
Comit Paraolmpico Brasileiro.
certifcado como CBPP, PMP, ITIL Practition-
er (equivalente ao atual ITIL intermediate),
SOA Solution Desiner e COBIT Foundations.
Luiz Wagner Oliveria Nascimento
Especialista em outsourcing. Experincia em
sistemas operacionais Windows e Linux, Im-
plantao e Treinamento de pessoal em Siste-
ma, Banco de Dados, Analise em Cdigo Fonte,
aplicao de boas praticas
como o ITIL, ISO20000 e sempre em buscan-
do a melhoria continua e no desenvolvimento,
implantao e gerncia de Service Desk.
Nelson Granado Merino
Executivo de Contas. Co-fundador do ITSM na
Prtica. Especializaes:Criao de Produtos,
implantao de servios e implementao de
processos e ferramentas de gerenciamento de
servios de TI.
Ren Chiari
Consultor especialista em Governana e Ger-
enciamento de Servios de TI. Co-fundador e
administrador do blog ITSM na Prtica
Formado em Gesto de Ambiente Internet
e Redes de Computadores, possui as certif-
caes ITIL Service Manager, ITIL Expert,
ISO/IEC 20000 Associate/Consultant e CO-
BIT 4.1. Ao longo de sua carreira profssional,
passou por grandes corporaes do ramo de
Tecnologia de da Informao e consultorias
especializadas, atuando como consultor e in-
strutor em dezenas de projetos. Entusiasta do
assunto Gerenciamento de Servios de TI,
um dos fundadores do ITSM na Prtica (antig-
amente conhecido como ITIL na Prtica). Pub-
licou mais de 70 artigos e autor do pocket
book ITIL na Prtica: Gerenciando Problemas
de Infraestrutura e Servios de TI.
Roberto Cohen
Especialista em Help Desk / Service Desk / Sup-
port Center, realiza treinamento, consultoria e
palestras na temtica. Atua na rea de suporte
h 25 anos e treinou mais de cinco centenas
de profssionais nos ltimos quatro anos.
Ps-graduado em Especializao de Psicolo-
gia nas Organizaes. Associado da Sociedade
Brasileira de Dinmica dos Grupos. Membro da
entidade mundial The Association of Supporte
Professionals. Palestrante sobre suporte tc-
nico, Help Desk e Service Desk. Gold Member
do Help Desk Institute norte-americano des-
de 1996.
Esta obra dedicada a todos os profssionais que dedicaram seu tempo para contribuir
e com sua vasta experincia no tema Gerenciamento de Servios de TI e motivar a sua
discusso em todos os mbitos, permitindo que ao longo de mais deste perodo de mais
de cinco anos fosse possvel consolidar um material extremamente rico para a comu-
nidade.
Artigos Temperados com Opinio .................................................................................................................. 8
Adoo da ITIL: Santo de fora de casa faz milagres? .................................................................................................. 9
BYOD explodiu o CMDB. J era essa ITIL! ................................................................................................................. 10
Demanda instantnea por alta capacidade ................................................................................................................. 13
Gerenciamento de Servios de TI x Boas Prticas: Uma questo de hbito ............................................... 14
ISO 20000 atestado de melhores prticas? ................................................................................................................ 16
ITIL e Outsourcing Algumas peas ainda no se encaixam ................................................................................. 17
ITIL e satisfaco de clientes ................................................................................................................................................ 20
ITIL - O que no est nos livros? ....................................................................................................................................... 22
ITIL para Ingls ver .................................................................................................................................................................. 24
ITILfobia ....................................................................................................................................................................................... 26
Na prtica: pessoas que fazem a diferena ................................................................................................................. 28
Os fora da lei Porque to difcil seguir processos? ........................................................................................... 30
Porque to difcil gerenciar os servios de TI? ....................................................................................................... 33
Quando o vilo est dentro de casa ................................................................................................................................ 35
Realmente precisamos de modelos e padres? ......................................................................................................... 37
Seguranca da Informao e a arte de no dizer no .................................................................................................. 40
Artigos com Altos ndices de Teoria ............................................................................................................ 41
A eterna e incendiria briga entre a Gesto de Incidentes e de Problemas ................................................ 42
A importncia do Plano de Continuidade .................................................................................................................... 44
A relao entre ITIL e ISOIEC20000 ............................................................................................................................. 46
Catlogo de Servios O desconhecido ...................................................................................................................... 48
Como o BDGCCMDB pode aumentar a efcincia dos processos de suporte a servios .................... 51
Compreendendo a ITIL a partir de uma perspectiva nada convencional um show de rock ................ 53
Do inferno ao cu Como o exemplo do Corinthians pode ser utilizado na Gesto de Servios .... 55
Entenda a importncia da classifcao do Incidente ............................................................................................. 57
Nveis de servio to necessrios quanto inteis ..................................................................................................... 59
O conhecimento meu e ningum tasca ...................................................................................................................... 61
O que Gerenciamento de Servios de TI? ................................................................................................................ 63
Os 10 Mandamentos da ITIL .............................................................................................................................................. 65
Para que serve a ISO 20000? ............................................................................................................................................. 69
Principais diferenas entre a ITIL v2 e V3 Parte I .................................................................................................... 72
Principais diferenas entre a ITIL v2 e V3 Parte II ................................................................................................... 74
Servios: a ponte perdida entre negcios e TI ........................................................................................................... 78
Sistemas de qualidade: a iluso da melhoria contnua ........................................................................................... 80
USMBOK o ITIL para gerenciamento de qualquer servio ................................................................................. 82
Artigos para Aquecer a Carreira ................................................................................................................... 83
Certifcaoes abrem portas mas no garantem o seu emprego ........................................................................ 84
Redes Sociais: 5 erros a serem evitados no LinkedIN ............................................................................................ 85
Tirei a certifcao ITIL e agora? ....................................................................................................................................... 87
Vale a pena investir em certifcaoes profssionais? ................................................................................................ 90
Artigos Para Por a Mo na Massa ................................................................................................................. 92
5 dicas para a Gesto de Problemas Proativa ............................................................................................................ 93
5 passos para defnir um bom Acordo de Nvel de Servio SLA ........................................................................ 95
25 dicas infalveis para que seu projeto de implantao da ITIL seja um fracasso ................................... 98
Catlogo de Servios: Para que complicar? .............................................................................................................. 100
ITIL preciso saber vender .......................................................................................................................................... 102
Pessoas: o calcanhar de Aquiles na adoo da ITIL .............................................................................................. 104
Problemas como identifca-los? .................................................................................................................................. 107
Profssionalizando a gesto dos projetos de TI e ITSM Parte I ....................................................................... 108
Profssionalizando a gesto dos projetos de TI e ITSM Parte II ..................................................................... 110
Profssionalizando a gesto dos projetos de TI e ITSM parte III .................................................................... 112
Tempo para solucionar problemas: mais um problema ou a soluo? ......................................................... 115
Transformando sua poltica de segurana da informao em um ativo estratgico .............................. 116
Artigos com toque de tecnologia ............................................................................................................... 121
A gamifcao invadiu nossa praia ................................................................................................................................. 122
ITSM, redes sociais e Content Management Systems d jogo? ..................................................................... 124
O que as ferramentas no fazem por voc ............................................................................................................... 126
Artigos Exlcusivos do Chef .......................................................................................................................... 128
Os desafos da criao de valor atraves da Operao de Servios ............................................................... 129
O que so incidentes, problemas, erros conhecidos e requisies de servio segundo a ITIL? ...... 130
Gerenciamento da Confgurao e Ativos de Servio: o processo camarada da ITIL .................. 133
Qual a diferena entre o Gerenciamento de Mudanas e o Gerenciamento de Liberao e Implan-
tao? .......................................................................................................................................................................................... 135
A ITIL uma moda? .............................................................................................................................................................. 136
4 mtricas para monitorar o desempenho de uma CMDB (Confguration Management Database) ..
137
O que um Service Desk (ou Central de Servios)? ............................................................................................ 139
Tipos de Service Desk, qual o mais adequado? ....................................................................................................... 140
Melhores Prticas ou Boas Prticas, qual o certo? ........................................................................................... 142
O que um Plano de Capacidade? ................................................................................................................................ 143
A razo pelo qual um incidente no vira um problema .................................................................................... 145
10 coisas que voc deveria saber sobre a ITIL ....................................................................................................... 146
Compreendendo os principais conceitos do COBIT 5 ....................................................................................... 148
Artgos Temperados com Opiniao
9
ITSM na Prtica - O caviar de 5 anos de postagens
Adoo da ITIL: Santo de fora de casa faz milagres?
GUSTAVO TAVARES
Como profssional de gesto de TI tive vrias oportunidades de trabalhar prestando
consultoria. Uma grande parte planejando e implementando iniciativas baseadas em
ITIL. Uma questo que inicialmente me deixava curioso era o porqu de as empresas
preferirem optar por consultores a utilizar recursos internos. Curiosidade reforada
pelo fato de que, em quase todas estas oportunidades, encontrei nas empresas s quais
prestei servios pessoas qualifcadas e bem preparadas para liderar iniciativas seme-
lhantes. Aos poucos a experincia foi me ensinando e fnalmente consegui algumas
respostas que saciaram a minha curiosidade. So muitas as vantagens da utilizao
de consultores externos nas iniciativas de adoo da ITIL (existem tambm algumas
desvantagens), mas acredito que o ponto chave seja o seu posicionamento hierrqui-
co na organizao. Iniciativas de planejamento e adoo da ITIL so, fundamental-
mente, iniciativas de mudana organizacional. E um profssional externo, no ligado s
estruturas e controles j existentes, possui maiores chances de obter sucesso em um
processo de mudana organizacional. De forma resumida, poderamos utilizar o velho
adgio para questionar: Em iniciativas de adoo 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 efcincia de consultores externos em iniciativas de adoo da ITIL pos-
sui limites. Os consultores so peas fundamentais por que possuem o conhecimento
tcnico necessrio e a liberdade de opinies e crticas que pode no existir dentro da
organizao. Entretanto, a responsabilidade pela tomada de decises a respeito do
desenho dos processos e de alteraes nas estruturas exclusiva dos gestores. No
cabe ao consultor escolher qual o melhor processo ou qual a melhor linha de subordi-
nao de determinada funo dentro da organizao. O consultor no est inserido na
cultura organizacional da mesma forma que o gestor para entender e diagnosticar as
consequncias deste tipo de alterao. Seu papel, neste caso, orientar a tomada de
deciso ressaltando os riscos e os benefcios de cada opo existente. Quem possui a
responsabilidade de determinar os requisitos e sua relao com os objetivos de neg-
cio deve ser algum de dentro da prpria organizao.
O gestor, quando transfere a responsabilidade por estas decises 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 responsvel por gerenciar algo com o qual
no concorda ou mesmo no conhece. Situao onde o sucesso do novo processo ou
da nova estrutura fca comprometido, afnal , sem apoio, nem santo de fora de casa
consegue fazer milagres!
10
BYOD explodiu o CMDB. J era essa ITIL!
ROBERTO COHEN
Uma consequncia da disseminao dos dispositivos mveis que os funcionrios 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 no acordou.
E as empresas tentaram entrar na onda oferecendo Blackberrys, iPhones e iPad (e seus
similares) para os funcionrios. S que as tecnologias similares ao alcance de com-
pra dos prprios funcionrios comearam a fcar muito baratas. E com isso vieram as
ondas da Consumerization e Gamefcation. A ltima tentando obter proveito desse
contato mais ntimo com os devices mveis para fazer os usurios aprenderem atravs
de games (sei l, pense no Show do Milho ou Quem quer ser um milionrio com per-
guntas contextuais a um ERP, por exemplo). E a primeira, Consumerization, um olhar
atnito sobre o usurio trazendo seu Mcbook de casa e tentando conect-lo na rede
corporativa da empresa.
Bom, a situao apertou (piorou) para o suporte tcnico.
Do BYOD
Agora chegou o BYOD Bring Your Own Device. Traduzindo, Traga Seu Prprio Devi-
ce. Traga seu lanche, sua ma e o seu dispositivo mvel de preferncia pro servio!
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 efciente nesse ambiente do que
o obrigando a aprender outro modelo de smartphone?
Eu tambm no 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 cotao para migrar do BlackBerry verso um para verso 10 (exemplo
hipottico) depois de 4 anos, os usurios esto, por sua conta, fazendo isso todo ano e
aproveitando as facilidades dos planos de pontuao 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 no existe o verbete em portugus na
Wikipedia. Eu no achei, pelo menos.
11
Opa, e as questes legais?
A o cachorro morde o prprio rabo. Num artigo muito interessante publicado no IT-
Web, a jovem advogada Patrcia Peck Pinheiro aponta uma srie de incmodos no Bra-
sil relacionada a essa tendncia de Traga seu dispositivo para o servio:
De quem a responsabilidade se o device contiver contedo ilcito?
O acesso 247 num dispositivo particular (do prprio funcionrio) confgura sobreavi-
so e hora extra, pela tica das leis trabalhistas?
Quem o responsvel pela segurana 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: Questes
legais do BYOD a regra tem que estar clara
E o ITIL?
Caramba, e agora?
Como organizar o CMDB (Confguration Management Database)? Como construir um
banco de dados de tudo que confgura um determinado servio quando nem sabemos
qual o dispositivo que o usurio comprou e utiliza? E se o maluco migrou para a re-
cm-lanada verso do iPhone? Ou do Xoom (tablet da Motorola)? Ou sabe-se-l o que
estar na moda amanh
A biblioteca britnica recomenda cadastrar tudo para encontrarmos rapidamente os
pontos de defeito de um servio, por exemplo. Mas como o tcnico atender um usu-
rio que utiliza um browser que ele nunca ouviu falar na vida?
Eu sei que ns do suporte tcnico poderamos argumentar que:
O device do usurio no est cadastrado e nem homologado pelo suporte tcnico e
por isso sujeito a vrus;
Isso pode aumentar o custo de operao, por que no conhecemos o mesmo e vai ge-
rar treinamento, atraso no atendimento etc.;
Uhhh, a lista gigantesca para comentar
Mais complicaes en aire: e se o usurio pedir suporte para questes pessoais e no
propriamente corporativas, como o suporte deve se comportar? O horror saber que
a maioria dos departamentos de suporte no Brasil no especifcou ainda um catlogo
de servios que, por mais banal que fosse, ajudaria o tcnico e usurio a saberem o que
ou no padro ou ofertado como auxlio.
Ihhh, e se o usurio pedir demisso? Algum limpar as informaes e aplicativos ar-
mazenados no smartphone dele?
12
Na real, foi-se pro espao aquele controle que desejvamos fazer sobre os itens de
confgurao componentes de um servio (Algum viu o flme Dama de Ferro? No
toa que o ITIL l nasceu, hehe).
Nossa, existe um bl-bl-bl imenso rolando na internet sobre isso. E, como de cos-
tume, ningum 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 iluso.
A ideia central do Humberto Mariotti que achamos que podemos controlar as coi-
sas. Mas muitas (a maioria) no conseguimos.
Ele faz uma diferenciao didtica entre sistemas complicados (um relgio complica-
do, cheio de pecinhas, mas conseguimos ter alguma preciso) versus sistemas comple-
xos (aqueles habitados por seres humanos onde difcilmente podemos projetar com
certeza o futuro para daqui a uma semana).
O Humberto est numa outra fase das teorias alm dos sistemas sistmicos (Peter
Senge e organizaes que aprendem um dos expoentes mximos desse conceito).
importante compreender que ele no recomenda o abandono da objetividade, metas
e gesto dos processos. S que importante incluir nisso tudo os conceitos de erro,
incerteza e iluso.
Por que escrevo isso, ainda mais se o ttulo era outro?
Por que preciso aceitar a incerteza. No vai dar para programar tudo. A incerteza vai
permear o primeiro nvel de atendimento que no saber como atender um Firefox
para Android ou situaes parecidas.
E o gestor deve e precisa saber o que fazer (ou, ao menos, pensar sobre) as situaes
que apresentam novos paradigmas contestando o b-a-b aprendido no curso de ITIL.
E agora, Manoel, o que fazer?
Smack
13
Demanda instantnea por alta capacidade
REN CHIARI
Compra de ingressos online, clubes de compras coletivas e leiles de um centavo. O
que estes servios tem em comum?
1. A disponibilidade a razo de ser do negcio.
2. Lidam com grandes demandas em fraes de segundos.
A caracterstica principal destes servios de manter o site disponvel mesmo com
avalanches de cliques simultneos. Nem sempre d certo
Manter uma infraestrutura capaz de suportar altas demandas pode sair caro demais
se considerarmos que estas demandas so espordicas. Mesmo terceirizando, a d-
vida se os provedores de servio de outsourcing j esto preparados para esta novo
conceito de prestao de servios. Eu particularmente apostaria neste nicho de ser-
vio, que eu tomei a liberdade de chamar de Instantaneous demand for high capacity,
ou Demanda Instantnea por Alta Capacidade. Se o nome j existir, timo, acertei na
mosca, caso contrrio vou patentear! (uma busca no Google no trouxe nenhum resul-
tado hehehe)
Algumas recomendaes da ITIL fazem sentido, e at so aplicadas. Por exemplo a
pr-venda de ingressos para um grupo seleto de clientes de uma instituio fnancei-
ra j uma forma de infuenciar a demanda, mesmo sabendo que o objetivo principal
neste caso trazer novos clientes, aqueles que j no aguentam mais lidar com trava-
mentos de site no horrio em que as vendas comeam para o pblico normal.
Os leiles de centavos procuram mesclar produtos de valores altos e baixo, em hor-
rios distintos, inclusive de madrugada, para infuenciar a utilizao constante e justif-
car o investimento na infraestrutura.
Por outro lado, a falta de maturidade em gerenciamento de servios de TI est eviden-
te nestas empresas (e muitas outras da Amrica Latina veja uma anlise de dados do
Gartner aqui) . Basta fazer uma rpida busca em sites como o Reclame Aqui para en-
contrar um grande nmero de reclamaes de Clientes que clicaram mas no ganha-
ram, ou que nem sequer conseguiram clicar, pela indisponibilidade dos sites. Tambm
existem reclamaes sobre a transparncia e credibilidade dos sites, mas isso assun-
to pra abordar em outro post.
Vale lembrar que a inteno deste e possveis outros artigos no de colocar em dis-
cusso se estes so modelos de negcio bons ou ruins, confveis ou no. So modelos
que esto ai a pleno vapor e podem infuenciar a discusso de novas abordagens para
gesto de TI.
14
Gerenciamento de Servios de TI x Boas Prticas:
Uma questo de hbito
ALBERTO ANDRADE
Quando o assunto Gerenciamento de Servios de TI, a ITIL frequentemente apresen-
ta-se como um heri invisvel, raramente reconhecido como tal. O entendimento do
framework como referncia de boas prticas ainda interpretado de forma equivoca-
da por muitos profssionais que buscam em sua aplicao a soluo de todos os seus
problemas e frustram-se nas primeiras difculdades de implementao, justamente por
esta falha de entendimento.
Algo que ainda ouo com muita frequncia so afrmaes quanto impossibilidade
de aplicar as ditas boas prticas em cenrios de produo. Igualmente comuns so
aqueles que asseguram que a ITIL no tem utilidade real, o que refete a viso limitada
de muitos profssionais de TI e reas relacionadas. Independente do cargo ou ativida-
de, o que se deve ter em mente que uma biblioteca de boas prticas segue o caminho
inverso frente s metodologias tradicionais. tudo aquilo que j foi efciente no mer-
cado e vem como sugesto de uso, por isso no um conjunto de regras pr-estabele-
cidas. Estas propostas nada mais so do que indicaes perfeitamente adaptveis de
milhares de outros como ns que j percorreram o mesmo caminho e nos indicam as
pedras para que no tropecemos, afnal de contas, quem quer reinventar a roda? Ge-
ralmente quando um profssional com histrico de resultados satisfatrios depara-se
com a ITIL, sua primeira percepo : 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 no falhar na grafa, nada mais signifca do que os velhos atos de violncia fsica e
psicolgica que muitos de ns sofremos na infncia. antigo, s no 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 prpria vontade) todo
dia. Compare com a nossa prpria vida. O ser humano, em sua individualidade possui
uma srie de comportamentos, bons e ruins, comuns no seu cotidiano. Imagine uma
biblioteca de boas prticas como um conjunto de diretrizes contendo instrues que
voc j exercita e outras que pode comear hoje. O sucesso no est necessariamente
atrelado a pratica de todo o contedo destas sugestes e sim do uso que se faz delas.
Voc pode no exercitar-se, nem se alimentar bem hoje, mas sabe que bom pra voc.
Se trouxer pra rotina, ter muitos ganhos. Se no trouxer, no signifca necessariamen-
te que ir morrer amanh (assim espero!!!).
Portanto, boas prticas de mercado, muito mais do que mudana estrutural, exige mu-
15
dana de cultura e comportamento. benchmarking, tomando referncia 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
parabns, provavelmente j esteja no caminho certo. Por outro lado, se no conseguir
agregar nenhum destes bons frutos sua rotina, pode ser a hora de uma quebra de
paradigma. Independente do nome que se d, bons hbitos sempre trazem benefcios
e isso indiscutvel, pois, assim como afrmou Aristteles, somos aquilo que fazemos
repetidamente, desta forma, excelncia um hbito.
16
ISO 20000 atestado de melhores prticas?
REN CHIARI
A norma ISO/IEC 20000 foi lanada em dezembro de 2005, sendo a primeira norma
ISO voltada exclusivamente para gerenciamento de servios de TI.
Os requisitos da norma esto totalmente alinhados ao ITIL, e em alguns momentos
chegam a deixar mais claros alguns aspectos. Alm disso, ela aborda temas como re-
sponsabilidades da direo de forma mais incisiva (herana da ISO 9001).
Em fevereiro de 2008, a ABNT lanou a verso brasileira da norma, que tem o mesmo
conteudo.Desde ento, muitas empresas iniciaram a busca pela certifcao.
Atualmente, de 12 a 15 empresas brasileiras possuem a certifcao (no sei pq, mas o
site ofcial www.isoiec20000certifcation.com no possui informaes atualizadas...).
H uma estimativa de que em 2010, 80% dos grandes e mdios provedores sero cer-
tifcados e vrias organizaes clientes estaro certifcadas, enquanto 2011 ser o ano
da maturidade. Certifcar no 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 confana por parte dos investidores, satisfao dos
clientes, etc...mas possvel tambm utilizar-se da norma como referncia de quali-
dade para a implantao do ITIL, e de certa forma, atestar o sucesso da implantao,
mesmo que a certifcao ofcial no seja almejada.
Ainda que para os cticos seja apenas mais uma moda do mercado, e que a conquista
do selo no garantia de qualidade, as empresas sero motivadas a engrenar e mant-
er a qualidade, uma vez que as constantes manutenes da certifcao obrigaro elas
a agir desta forma.
17
ITIL e Outsourcing Algumas peas ainda no se
encaixam
REN CHIARI
A ITIL, apesar de ser uma das melhores referncias para gesto de servios de TI, nos deixa
com vrios pontos de interrogao quando abordada em um ambiente de provedores de Out-
sourcing. Na verdade, a biblioteca tem um foco muito forte em organizaes internas de TI,
e por isso essa lacuna.
Recentemente fz algumas buscas em foruns e sites sobre essa questo e descobri que
no estou sozinho, e que muita gente que trabalha ou trabalhou em provedores de
Outsourcing tm problemas em adequar a ITIL neste ambiente.
Algumas das principais difculdades apontadas so:
Processos Fim-a-fm
A ITIL pressupe que voc tenha controle sobre todos os servios, 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 prestao de servios para a infra-estrutura e aplicaes entre
dois diferentes fornecedores.
Em situaes como esta, mesmo que todos adotem ITIL, tero sua prpria adaptao
dos processos, incluindo os seus prprios instrumentos, procedimentos, relatrios e
gerenciamento de dados.
Isto representa um enorme potencial de confito, pois mesmo que o cliente tenha espe-
cifcado o alinhamento com a ITIL como um pr-requisito para o outsourcing, muito
difcil quando se trata de Gesto de Incidentes, Problemas e Mudanas. Por exemplo,
um usurio liga para um Service Desk terceirizado, que registra um incidente na ferra-
menta XPTO, que compe a sua soluo de ferramentas integradas de ITSM.
O usurio acredita que um problema de infra-estrutura e ento o incidente atribu-
do equipe de suporte a infra-estrutura terceirizada. Na realidade o incidente acaba
por ser um erro de aplicao - portanto um chamado tem que ser registrado junto ao
provedor de aplicaes terceirizado, que utiliza o XYZ em sua soluo integrada de
ITSM.
Na transferncia, os detalhes se perdem e o provedor de aplicaes tem que chamar o
usurio para fazer mais perguntas. O tempo de resoluo do incidente ultrapassado,
e quem o responsvel por isso? Quem o dono do processo fm-a-fm?
A soluo para este problema deve ser uma estrutura de governana cuidadosamente
18
planejada e implementada que assegura que todos os fornecedores trabalhem juntos
de uma maneira efcaz. A ITIL V3 deixou claro no livro de estratgia de servio 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 governana deve ser o prprio Cliente. Isso pre-
cisa ser desenvolvido na estratgia de terceirizao e gerenciado desde o incio.
Onde est o meu Cliente?
Todos os processos de entrega de servios da ITIL supe que voc tenha um cliente
comercial para trabalhar, mas muitos so os contratos de terceirizao com o departa-
mento de TI da organizao do cliente.
Essa relao com um outro provedor de TI afeta muitos aspectos da prestao de ser-
vios, mas especialmente em SLM, onde o conceito de SLA baseado no negcio mui-
tas vezes rejeitado por um contrato negociado por uma equipe de TI que muito tc-
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 difcil de implementar em um ambiente comercial. Ele
simplesmente no leva em conta as presses comerciais para ganhar o negcio.
Ligando ao ponto sobre como lidar com os departamentos de TI, isto pode signifcar
tambm que os objetivos no so ainda ligados aos requisitos reais de negcio. Este
tipo de m gesto das expectativas do cliente leva a srios problemas mais tarde.
Trs outros processos especialmente demandam o envolvimento ativo de Clientes de
negcio: o Gerenciamento de Capacidade de Negcio, o planejamento da continuida-
de do negcio e a anlise de impacto sobre a empresa no Gerenciamento de Mudan-
as, respectivamente.
A soluo para isso no to clara. Uma compreenso realista da maturidade do seu
cliente, papis funcionais e estruturas podem ajudar a identifcar potenciais proble-
mas. Alm disso, mais esforo e empenho durante a transio para defnir claramente
o nvel de envolvimento do cliente de negcio tambm vai ajudar.
A ITIL V3, infelizmente, no oferece muita ajuda sobre este problema especfco. So-
mente com o claro entendimento de com quem voc est lidando, e quais so 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 ningum entende
Muitas licitaes 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 no h um bom entendimento do que isso realmente sig-
nifca.
Isto se refete de vrias formas, mas normalmente em um simples copy and paste de
pargrafos da bibilioteca, incluindo KPIs dos quais so transformados posteriormen-
te em metas, com multas associadas.
O problema surge quando aqueles que escrevem a proposta comercial e aqueles que
lem o fazem com (no mximo) um conhecimento terico do ITIL e pouca compreen-
so dos verdadeiros problemas associados criao, desenvolvimento, gesto e medi-
o de tais processos.
Um exemplo comum o requisito para estabelecer o gerenciamento de confgurao
com uma meta de 100% de exatido no primeiro dia de prestao de servios; isso
em uma organizao que no tenha qualquer atividade vigente de Gerenciamento de
Confgurao. No mundo real, leva-se de 6 a 12 meses para implementar e adequar um
processo de gerenciamento de confgurao efcaz, que requer um considervel inves-
timento inicial e quase nunca entrega tudo com 100% de preciso.
Outro exemplo so as produtizaes de processos ITIL. No raro encontrar ser-
vios onde o cliente precisa pagar para ter gesto de capacidade, sendo que esta ati-
vidade intrinsicamente j deveria estar sendo coberta como um requisito bsico de
qualidade e entrega de servios.
Adicionalmente, a maioria dos processos de planejamento ou estratgicos tem foco em
investir para melhorar, ao invs de pagar por falhas. As implicaes do mal compreen-
dimento disso das organizaes verem o Outsourcing puramente como reduo de
custos.
Novamente, a soluo para esta questo no fcil, e a ITIL V3 no apresenta res-
postas simples. O segredo a educao e formao para todos os envolvidos, tanto o
cliente quanto o fornecedor, de modo que os motivos pelos quais a relao de terceiri-
zao est sendo baseada sejam claramente compreendidos.
Concluses
A boa notcia que a V3 est muito mais clara, com uma abordagem mais integrada
de gesto de servios, j est reconhecendo muitas das difculdades identifcadas na
V2 e sugerindo solues. Maaas, cuidado...a ITIL (mesmo a V3) no uma referncia
a ser utilizada isoladamente. O sua utilizao em um ambiente de Outsoutcing deve
ser adaptada cautelosamente. Podemos usar ITIL V3 para ajudar, mas h muito mais
educao e formao necessrias a todos!
20
ITIL e satisfaco de clientes
CLAUDIA MARQUESANI
Parece uma frase bastante pessimista para quem tem um site chamado ITIL NA
PRTICA , mas tenho realmente que ser realista: IMPLEMENTAR A ITIL NO GARANTE
A SATISFAO DO CLIENTE. Pelo contrrio , dependendo do grau de insucesso, pode
at infuenci-la negativamente! Utilizamos tanto a palavra ALINHAR A ESTRATGIA
DE TI ESTRATGIA DE NEGCIO, que realmente estou at cansada (e o mercado
tambm!) de falar disso. Por isso resolvi brincar um pouco hoje!
Qualquer semelhana com a PRTICA uma mera coincidncia...rsrs
Tantas e tantas vezes as melhores prticas so implementadas sem levar em conta a
estratgia de negcio e as caractersticas da organizao , que realmente a cena acima
no irreal! O que devemos fazer ento para que a implementao da ITIL seja um
sucesso e traga valor para o negcio?
OUA (REALMENTE) O CLIENTE.
Sim, eu sei que difcil. Mais que ouvir, preciso conhecer o seu negcio, ENTENDER
o que ele est dizendo , infuenciar positivamente as tomadas de deciso... No uma
tarefa fcil, mas por isso que foi feita especialmente para os profssionais envolvidos
no gerenciamento de servios de TI!!! :D
ADOTE E ADAPTE as melhores prticas s necessidades da sua organizao e oua
seu cliente para montar a estratgia dessa adaptao.
Para fnalizar (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 ento o Co -piloto, todo uniformizado, de culos escuros e de bengala, tateando pelo
caminho. A atendente da companhia o encaminha at o avio e assim que volta, explica que,
apesar dele ser cego, o melhor Co-piloto da companhia.
Alguns minutos depois, chega outro funcionrio tambm uniformizado,de culos escuros, de
bengala branca e amparado por duas aeromoas.
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 avio preocupados com os pilotos.
O comandante avisa que o avio vai levantar vo e comea a correr pela pista, cada vez com
mais velocidade. Todos os passageiros se olham, suando, com muito medo da situao. O
21
avio vai aumentando a velocidade e nada de levantar vo. A pista est quase acabando e
nada do avio sair do cho. Todos comeam fcar cada vez mais preocupados. O avio cor-
rendo e a pista acabando. O desespero toma conta de todo mundo.
Comea uma gritaria histrica no avio.
Nesse exato momento o avio decola, ganhando o cu e subindo suavemente.
O piloto vira para o Co-piloto e diz:
- Se algum dia o pessoal no gritar, a gente t F... (traduo: ferrado)!!!!!!
Moral da histria:
OUVIR OS CLIENTES FUNDAMENTAL!!!
22
ITIL - O que no est nos livros?
GUSTAVO TAVARES
Embora seja promovido como o padro de facto para as operaes de TI, muitas so
as dvidas a respeito da efcincia e do sucesso na adoo da ITIL nas organizaes.
E isto no sou eu quem est dizendo. Uma das maiores consultorias mundiais espe-
cializada nas boas prticas j fez reclamaes a respeito. Particularmente, apesar de
no contar com informaes para comprovar, eu apostaria que mais da metade das
iniciativas de adoo da ITIL no Brasil no obtm o sucesso esperado. Isto a despeito
de serem realizadas por profssionais com certifcao de fundamentos, praticante ou
gerente (foundations, practitioner e manager).
A razo dos insucessos? Eu no saberia responder ao certo. Mas acredito que um fator
em especfco tem um peso muito grande. E a este fator que o post esta relacionado.
A ITIL passou por uma evoluo recente. A verso anterior (2) era focada exclusiva-
mente nas operaes de TI. Embora quando considerado em seu total ela contemplava
uma anlise geral da rea de TI das organizaes, na prtica do mercado ela se con-
centrava na entrega e no suporte aos servios de TI; atividades exclusivas da parte de
operaes. A evoluo para a verso corrente (3) trouxe uma reorganizao das reas
de conhecimento. Reforando a inteno inicial de contemplar a viso geral da rea
de TI, ela chegou a estender o modelo para as reas de posicionamento e formulao
das estratgias. Embora as duas verses possuam grandes diferenas, ambas possuem
tambm um conjunto de caractersticas fundamentais. E uma destas caractersticas
que as duas verses so baseadas em processos. Apesar de a verso corrente possuir
uma orientao para o ciclo de vida dos servios, ela ainda tem como base os proces-
sos de TI.
Por ser baseada em processos, a adoo da ITIL um pouco mais complexa do que
descrito nos livros e ensinado nos cursos de formao. A implementao de processos
em um ambiente de TI ou de negcios demanda uma ecologia organizacional que dif-
ere da ecologia tradicional. Os comportamentos, sistemas de recompensa e estruturas
tradicionais so, na maioria das vezes, incompatveis com as prticas necessrias para
gerenciar processos. Por tradicional no sentido deste post podemos entender as
estruturas funcionais departamentalizadas e baseadas em uma hierarquia claramente
defnida.
Apesar da prpria literatura reconhecer a necessidade de um ambiente que favorea
a adoo de processos (Service Strategy, seo 2.6), as implementaes baseadas na
ITIL quase sempre partem do princpio que a ecologia organizacional necessria para
implementao e gerenciamento de processos existe e esta madura na organizao
destino. O que eu acredito ser, na realidade Brasileira, uma raridade.
Com estas consideraes importante ressaltarmos que: antes de implantar o geren-
23
ciamento dos servios de TI baseado na ITIL a organizao deve necessariamente
ser fuente em gesto de processos. Ela deve possuir uma ecologia organizacional re-
ceptiva as prticas de gesto de processos, o que quer dizer uma estrutura organiza-
cional adequada, sistemas de recompensa que reforcem os objetivos dos processos e
um modelo de gesto com os estilos adequados.
verdade que a ecologia organizacional e as prticas aqui denominadas tradicionais
no impedem sempre a implementao de modelos de gerenciamento de servios de
TI baseados na ITIL. Processos conseguem, em situaes particulares, serem imple-
mentados e gerenciados neste tipo de ambiente. Mas somente em situaes particu-
lares e onde, principalmente, as especifcidades deste tipo de ecologia organizacional
so consideradas no projeto de implementao.
Para quem busca mais informaes a respeito da ecologia organizacional adequada
adoo 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-
ganizao de utilizar processos.
24
ITIL para Ingls ver
GUSTAVO TAVARES
Hoje mais raro. Mas ainda acontece. Planeja-se uma iniciativa para adoo de ITIL,
monta-se uma equipe, iniciam-se os trabalhos e algum fala: Este negcio de ITIL
s para Ingls ver! Aqui na nossa empresa no funciona!... E depois de escutar estas
afrmaes, se considerarmos os resultados obtidos por grande parte das empresas,
acabamos fcando desconfados se isto no seria verdade.
Como profssional com alguma experincia em iniciativas de adoo do ITIL, eu posso
afrmar que estes posicionamentos no so totalmente verdadeiros. E a palavra chave
aqui totalmente.
Como de conhecimento de quase todos os profssionais que conhecem o ITIL, sua
origem Britnica. A motivao inicial ainda est sob a nvoa das lendas. Algumas
dizem que est relacionada com a Guerra das Malvinas, outras dizem que tudo foi ap-
enas uma idia 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 no podia deixar de
ser, acabou trazendo o que a Inglaterra tem de bom e tambm o que tem de mau. Eu
particularmente no sei dizer que existe de ruim na Inglaterra, e tambm no sei o que
tem de bom alm da Keira Knightley e da Guinness; mas sei que a Inglaterra e o Brasil
so pases bem diferentes.
Mas apenas saber que so diferentes no o sufciente. Ns, profssionais que tra-
balhamos com gesto de TI, precisamos saber em que ponto estes pases so difer-
entes e como isto impacta as iniciativas de adoo do ITIL. Em minha defesa como
profssional, posso dizer que apesar de no saber quais so todas as diferenas eu sei
quem sabe.
Em um post recente do meu blog particular eu indico um livro muito interessante para
os profssionais que trabalham com ITIL. O livro do professor Geert Hofstede que
entre 1967 e 1973 realizou uma pesquisa com empregados de 70 pases da IBM. A
partir desta pesquisa, ele desenvolveu um modelo de cultura organizacional dividido
em cinco dimenses; que possibilita comparar como as pessoas de um pas compreen-
dem e respondem a diversas iniciativas gerenciais.
O modelo direcionado s populaes dos pases. No um modelo para ser aplicado a
diferentes organizaes de um mesmo pas. Ele busca diagnosticar quais valores e com-
portamentos uma populao entende e aceita como normal. Um deles, a dimenso de
distncia hierrquica, por exemplo, busca demonstrar o quanto as pessoas percebem
como vlida a distribuio desigual do poder. Em pases com alta distncia hierrqui-
ca um subordinado est menos propenso a questionar ou discutir as determinaes
de um superior. O subordinado interpreta que uma pessoa hierarquicamente supe-
rior melhor ou mais capacitada simplesmente pela sua posio. Por outro lado, em
25
pases com baixa distncia hierrquica, as pessoas acreditam que o poder no deve ser
distribudo apenas pela posio no organograma. Elas consideram que outros fatores
como capacitao, perfl, tempo de casa so tambm fonte de poder. So tambm mais
propensas a questionar e discutir as ordens vindas de escales superiores e acreditam
que no existe nada de errado com esta atitude.
As outras dimenses so igualmente importantes na avaliao das culturas de difer-
entes pases. A dimenso masculinidade, por exemplo, mede o quanto os valores mas-
culinos so mais relevantes que os valores femininos na populao de um pas. E por
valores masculinos devemos entender a competio e o confronto. Por outro lado de-
vemos entender os valores femininos como a colaborao e a confraternizao. Um
pas com alto ndice de masculinidade no quer dizer que existem mais homens ou mul-
heres no mercado de trabalho. Quer dizer apenas que os homens e mulheres deste pas
ou regio so mais direcionados competio e ao confronto do que colaborao e
confraternizao.
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 profssio-
nais que buscam liderar iniciativas de adoo do ITIL. Quais aspectos do framework
dependem de um baixo ndice de distncia hierrquica? Quais iniciativas do ITIL so
baseadas em um ndice alto ou baixo de masculinidade? Quais as outras dimenses do
modelo do professor Hefstede devem ser consideradas? Quais adaptaes ao frame-
work so necessrias para ressaltar os pontos fortes da cultura Brasileira?
Quem sabe com estas preocupaes ns que trabalhamos com ITIL no faamos do
framework tambm um negcio para Brasileiro ver! :)
26
ITILfobia
REN CHIARI
Quem j participou de um projeto ou iniciativa de adoo da ITIL sabe bem que a
foto ao lado ilustra muito bem um dos maiores desafos durante a implementao: a
RESISTNCIA!
No importa qual o segmento da empresa, seja instituio pblica ou privada, a reali-
dade exatamente a mesma. Quando h necessidade de uma mudana organizacional
(e para adotar o ITIL, geralmente necessria essa mudana), somos recebidos com
fechas!
O principal motivo que alavanca essa reatividade o medo das pessoas em perderem
posies cmodas, de no ter mais o controle individual e intelectual das informaes,
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 desafo, podemos utilizar uma formula de Administrao,
mais precisamente de Peter Drucker: M = D + M + P > R
Onde podemos interpretar:
M=> Mudana (a necessidade de mudar)
D=> Desconforto (eventos adversos, insatisfao 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=> Resistncia (o grau de resistncia das pessoas envolvidas na mudana)
Note que a soma de D + M + P deve sempre ser maior que R. Se em um determinado
momento notar que a resistncia maior, est na hora de elevar o grau dos itens prec-
edentes, de preferncia da direita para a esquerda, por exemplo:
P=>Revise o seu plano/projeto, pode ser que algo no foi bem defnido, o plano de co-
municao no est sendo efciente, etc
M=> Reveja o modelo proposto. Ser que somente ITIL resolve tudo? Talvez seja
necessrio utilizar-se de outras prticas como CobiT, ISO 20.000, BSC..
D=> Esta a ltima opo, se nenhuma das anteriores funcionar, gere desconforto.
Se necessrio , preciso entender que as reclamaes do cliente podem aumentar no
primeiro momento (como na implementao de um Service Desk) , mas o COMPROM-
ISSO GERENCIAL DEVE SER MANTIDO. Como na fgura, se aos poucos os envolvidos
pararem de remar, o barco nunca chegar ao seu destino.
Encarar de frente este desafo e MANTER O COMPROMISSO COM O PROJETO EM
TODOS OS NVEIS GERENCIAIS um dos fatores crticos de sucesso de uma mudana
27
organizacional. Implementar ITIL no um projeto com incio , meio e fm. uma
catequese e um programa de melhoria constante, como a prpria biblioteca diz: P-D-
C-A (Planejar, Fazer, Checar e Agir).
28
Na prtica: pessoas que fazem a diferena
REN CHIARI
Recentemente recebi um e-mail com o ttulo: Nova Era do Radar em SP - Ateno !!!,
que descrevia em detalhes os locais em So Paulo onde os novos radares sero insta-
lados. A frase fnal me chamou a ateno:
Retransmitam, duro trabalhar para sustenter mais isso!!
O mais engraado que as pessoas criam uma grande mobilizao para burlar siste-
mas de segurana ao invs de fazer o que tem que ser feito, que nesse caso seria sim-
plesmente respeitar a leis de trnsito vigentes!!
Em nosso mundinho quadradinho de TI acontee o mesmo. Vrios controles so cria-
dos exclusivamente para identifcar se as pessoas esto fazendo o que devem fazer.
Uma tremenda perda de tempo que poderia ser gasta com coisas mais produtivas e
com valor agregado ao negcio.
Um exemplo clssico so as auditorias. Nada contra auditores e nem contra as ISOs,
mas vamos combinar, da pra contar nos dedos o nmero de empresas que realmente
tem uma cultura madura em relao a isso. As ISOs deveriam ser uma referncia para
nortear a qualidade ideal para as empresas e serem vistas como uma forma de identi-
fcar o que no est bom e melhorar (os radares tem o mesmo objetivo, no?) mas na
realidade elas so utlizadas basicamente para dois fns:
Aparecer em formato de selo no site institucional da empresa;
Apavorar funcionrios mal orientados em pocas de auditoria.
A cena sempre a mesma: dado o anncio de uma auditoria interna, todos correm
como loucos atrs de disponibilizar evidncias de seus trabalhos, com o nico objetivo
de no ter nenhuma no conformidade, e assim burlar o sistema de auditoria. Se per-
guntarmos pra maioria qual o real motivo dos controles, poucos sabero 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, polticas, sua forma de trabalhar. Um visitante questionou se aq-
uilo no poderia oferecer algum risco empresa. A resposta foi mais simples do que se
podia imaginar: vocs podem copiar nossos processos, nossa forma de trabalhar, mas
ser difcil fazer acontecer se os seus funcionrios no tiverem o mesmo comprometi-
mento que nossos funcionrios tem.
Talvez valha mais a pena investir em concientizao, em pessoas com perfs adequa-
dos as suas atividades, em metas individuais alinhadas a ganhos fnanceiros para os
funcionrios que atingirem suas metas, a automatizao de processos a fm 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 questo que tem uma abrangncia muito alm de
gesto de servios e governana. uma questo cultural!!
Investir em processos, controles, e sistemas so importantes, mas no fnal das contas,
pessoas que fazem diferena...
30
Os fora da lei Porque to difcil seguir
processos?
CLAUDIA MARQUESANI
Hoje estou com uma incrvel crise existencial. No meio de uma grande revolta, comecei
a pensar : PORQUE EU DESENHO PROCESSOS E AS PESSOAS NO OS SEGUEM?
uma cultura do brasileiro? Ser que l fora assim? Ser que o objetivo fcar livre-
leve-solto? Ser que achamos interessante ser fora da lei? Nossa cultura no gosta
das amarras de um processo? O que ser que acontece?
Vamos falar um pouco sobre PROCESSOS hoje e porque to difcil segui-los. Um as-
sunto polmico, mas gerando polmica que evolumos...
Antes de mais nada, vamos defnir o que processo. Dentre vrias defnies, a vai
uma simples e direta: Processo uma sequncia 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 reteno e pulverizao de conhecimentos individuais;
Para controlar e monitorar as atividades, podendo identifcar os pontos de melho-
ria;
Para garantir que todas as atividades necessrias sejam desempenhadas para a
entrega do produto fnal de acordo com os critrios de qualidade estabelecidos;
Tudo isso em teoria...porque na PRTICA...salve-se quem puder!!!!
So procedimentos operacionais que incorretamente recebem o nome de processo e
ningum consegue enxergar o SERVIO por trs daquele documento enorme...
So 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- automtico, sem ter a viso do todo, dos requisitos de
qualidade e de controles do necessrios.
Esse tipo, muito comum e o pior de todos, chamado de PROCESSO PARA INGLS
VER!
O que isso? Todos sabem que ele est l, mas todos preferem ignor-lo at o dia em
que uma auditoria ou outra verifcao do dia a dia anunciada. Nesse momento, O
INGLS, precisa ver e tudo feito as pressas para atend-lo. No faz parte da cultura,
no 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 Geografcs, um programa
chamado MAYDAY. Podem me chamar de doente (rsrs), mas ele trata dos principais
acidentes areos da histria da aviao mundial. O que isso tem a ver com nosso dia a
dia? O processo de investigao, que mostra porque os acidentes areos acontecem
um verdadeiro aprendizado para quem trabalha com servios. Falhas, so, quase sem-
pre causadas por processos que poderiam ter sido melhor desenhados para evitar er-
ros humanos.
Em um dos programas do ms passado, foi apresentando um acidente, onde um avio,
decolou e minutos depois, o vidro da cabine estourou. O piloto foi arremessado para fora
do avio e fcou 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 aps um pouso forado.
Vrios investigadores renomados foram chamados para entender porqu o vidro hav-
ia estourado. Aps muitas avaliaes tcnicas e psicolgicas, fnalmente descobriram.
Resumindo:
O avio tinha passado por manuteno dois dias antes e vidro da cabine havia sido
substitudo. E a histria longa...
Para substituir o vidro, o mecnico deveria ir at o computador, consultar o tamanho
do parafuso que fxaria o vidro, buscar os parafusos corretos no estoque e utiliz-los
para fxar o novo vidro na aeronave.
Sabem o que o mecnico fez ao envs 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 ofcina. Infelizmente, o parafuso que esteve fxado durante muito
tempo no avio, tinha tamanho incorreto para aquele tipo de aeronave. O problema s
no tinha ocorrido antes, porque o parafuso estava muito bem fxado. Ao troca-los, o
mecnico estava em uma posio desconfortvel e deixou frouxos aqueles parafusos
que no tinham o tamanho adequado. Resultado: 5 minutos aps a decolagem eles se
desprenderam e causaram o acidente.
O investigador perguntou porque o mecnico no havia ido at o sistema consultar o
cdigo 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 vo at as 6 horas da manh do dia seguinte.
No daria tempo de seguir um processo to burocrtico e ao mesmo tempo cumprir
minhas metas.
Depois disso, foi fxado o cdigo de todos os parafusos nas mesas dos mecnicos, para
32
evitar que problemas como esses voltassem a acontecer.
Moral da histria: por mais que o processo seja bem desenhado, se ele no for funcion-
al, esqueam! Eles devem estar adequados as necessdades do NEGCIO (no caso,
agilidade para trocar o vidro com a mxima segurana). Tambm devem estar bem di-
vulgados e devem ser redivulgados constantemente...
Pensando bem, ser que a culpa de processos que nunca so seguidos e de servios
prestados com baixa qualidade, no est nas mos de quem desenha os processos, di-
vulga e deveria patrocin-los (nossos gestores) ??? Quem so os verdadeiros fora-da-
lei aqueles que no sabem ouvir e desenhar o que necessrio, aqueles que no di-
vulgam adequadamente aquilo que necessita ser seguido ou aqueles que se recusam a
seguir algo que totalmente burocrtico e sem sentido? Pensem nisso...
33
Porque to difcil gerenciar os servios 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 no vale a pena fazer milagres? Tudo que o negcio
pede a TI se mata para entregar, quase sempre sem planejamento e a qualquer custo
Vamos falar um pouco sobre isso
Quem o cidado 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 no 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 organizaes ainda trabalha
de forma bastante desplanejada e a TI acaba entrando nesse crculo vicioso.
A cena mais ou menos a seguinte: a pessoa de negcios chama a pessoa responsvel
por TI (normalmente o CIO) e diz : PRECISO DE UM PROJETO XYZ PARA ONTEM!!!
O CIO de cara diz que no possvel para a data solicitada , porque precisa avaliar a
estratgia, desenhar o projeto adequadamente , transicionar e operacionalizar a idia.
Ento, a rea de negcios insiste: preciso disso para ontem!!! E enfm, o responsvel
por TI concorda com a data totalmente inadequada para a realizao de um projeto do
porte solicitado.
Ento ele sai quase sempre tendo uma sncope 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!
FAAM ACONTECER E assim a roda gira (nem sempre redondinha). So projetos e
mais projetos quadrados, que quando entram em produo j entram com problemas
no desenho de disponibilidade, capacidade, falhas no processo de atendimento de in-
cidentes e mudanas e com um service desk totalmente despreparado para manter o
novo servio. excesso
Sim, podem me chamar de pessimista, mas duvido que pelo menos uma vez, ningum
nunca tenha participado de um projeto assim. Porque isso ocorre?
Primeiro, porque salvo raras excees, a organizao de TI de uma empresa nem sem-
pre respeitada. vista como um custo (muito alto, diga-se de passagem), para a rea
de negcios e uma rea-problema.
Segundo, porque o ciclo de vida de um servio no respeitado. A ITIL v3 deixa isso
muito bem organizado citando em cada um de seus livros uma fase do ciclo: estratgia,
desenho do servio, transio, operao e melhoria contnua. Antes de dizer se pos-
svel fazer ou no, preciso entender e possuir uma estratgia de TI alinhada, incor-
porada a estratgia de negcios. TI no deve mais ser vista como uma rea problema
e sim como parte da estratgia do negcio de uma organizao, pois as organizaes
34
dependem cada vez mais de TI para obter efcincia e efccia em suas operaes.
Se no possvel entregar um projeto no prazo, ou nas condies desejadas, preci-
so negociar, explicar, mostrar tecnicamente que se isso for feito, o projeto no ir cri-
ar VALOR para o negcio. Para criar valor, TI precisa apresentar duas caractersticas
no servio prestado: garantia (servio com qualidade na entrega) e utilidade (cliente
percebe o servio com um efeito positivo).
TI s poder se surpreender com um pedido se estiver longe do negcio, se no es-
tiver focando e defnindo suas estratgias para aquilo que realmente agrega VALOR
para o cliente. No existe MILAGRE em tecnologia, existe PLANEJAMENTO, ORGAN-
IZAO e GESTO.
Como conseguir isso? Implementando um bom gerenciamento de servios de TI, utili-
zando a ITIL como melhor prtica e combinando-o com outros frameworks que api-
em a governana, 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 necessrio im-
plementar uma TI que tenha viso voltada para o negcio e para como Ela poder aux-
iliar para que ele atinja seus objetivos.
Obviamente, se hoje voc trabalha em uma organizao onde no existe nada, se voc
est bem distante de todas essas palavras bonitas escritas nos livros, saiba que isso
absolutamente normal. Para se atingir um nvel adequado de gesto de servios e gov-
ernana preciso antes de mais nada COMEAR. No espere atingir o mundo perfeito
em meses. A realidade diferente, existe a cultura das pessoas que precisa ser altera-
da e uma mudana comportamental rumo gesto de servios lenta e gradual. Mas
com certeza, implementando alguns processos de gesto ganhos rpidos viro, que
podero trazer benefcios no somente para a TI, mas principalmente para o negcio.
Mos a obra? Abaixo os MILAGRES e vamos rumo a Gesto e governana. Cada vez
mais organizaes tm cincia disso e iniciam projetos de implementao de proces-
sos ITIL, CoBIT, ISO20000. No d para imaginar uma organizao competitiva que
no faa a gesto de seus servios de forma efciente e efcaz. E o nome disso no mi-
lagre, futuro!
35
Quando o vilo est dentro de casa
CLAUDIO DODT
Uma pesquisa recente da Venaf apontou um srio risco que, infelizmente, cada vez
mais comum em organizaes de qualquer vertical ou porte: Uma boa parcela (esti-
mada em 40%) dos colaboradores de TI admite poder causar srios problemas, leia-se
caos completo, nos servios/infraestrutura da organizao.
O caso especfco abordado pela pesquisa refete dados sobre falta de gerenciamento
de chaves de criptografa associada a lacunas controles internos e pouca segregao
de funes. Entretanto, existem incontveis outros cenrios onde um nico colabora-
dor pode tornar a organizao sua refm e indiscutivelmente causar prejuzos na casa
dos milhes como em um caso ocorrido na prefeitura de So Francisco em 2008 que
teve sua WAN seqestrada por 12 dias (leia mais).
Esse assunto no 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 situao chegando ao ponto onde em alguns casos tido
como algo normal.
Se voc vivencia este tipo de problema em sua organizao existem algumas prticas
simples que podem ajudar bastante:
1. Uma boa poltica de segurana da informao essencial: Se seus colaboradores
esto conscientes das implicaes legais de suas aes eles certamente vo pensar
duas vezes antes de cometer um ilcito. No pior cenrio se um incidente severo ocor-
rer voc vai estar protegido e legalmente preparado para tomar as aes cabveis.
2. Segregao de funes (SoD): Provavelmente voc sabe que SoD um mtodo para
reduzir o risco de que uma nica pessoa possa acessar, modifcar ou usar servios sem
a devida autorizao ou deteco. O que talvez voc no saiba que, de acordo com
o Public Company Accounting Oversight Board, em 83% das organizaes a causa de
fragilidades materiais estava diretamente relacionada com ausncia de Segregao de
Funes. Uma boa matriz de segregao (ver exemplo) associada rotao de cargos e
funes pode ajudar a evitar incidentes e apoiar na distribuio conhecimento.
3. Documentao, documentao e documentao: Manter uma documentao atua-
lizada essencial para proteger o conhecimento institucional. Infelizmente, existe uma
notria resistncia por parte da maioria profssionais de TI que acabam deixando algo
to importante completamente de lado. Cabe aos gestores entender a importncia e
exigir que uma parcela do tempo da equipe seja dedicada exclusivamente a elaborao
de documentao e procedimentos operacionais.
4. Use a tecnologia a seu favor, mas no se torne dependente: Desde gerenciamento
de chaves de criptografa at a sistemas de auditoria e anlise do comportamento
36
possvel dizer que existe uma soluo tecnolgica para quase tudo. Saber aplicar a tec-
nologia a seu favor reconhecer que no podemos ser completamente dependentes.
Busque solues completas que englobem no apenas um produto, mas procedimen-
tos, normas e at mesmo as pessoas necessrias para criar uma soluo efciente.
5. TTTO (Talk to the Ogre): Muitos dos profssionais que gostam de se sentir insubsti-
tuveis o fazem por uma ntida insegurana. Manter um canal de dialogo aberto e, em
casos extremos, at mesmo um acompanhamento psicolgico pode ajudar e muito na
reduo de riscos e incidentes. Um bom gestor consegue perceber um problema de re-
lacionamento logo no incio , onde sua soluo razoavelmente simples. Um mau ges-
tor pode fechar os olhos e at mesmo ser conivente com a situao. Nesse ultimo caso
certamente vale a mxima: Quem planta vento, colhe tempestade!
A lista acima certamente no completa, mas espero que essas dicas prticas ajudem
a lidar com os Shreks mal entendidos que residem dentro da TI.
Links e referncias:
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 padres?
BRUNO CAIADO
Os homens adoram modelos e padres. Prestem ateno nas escolas e vocs vero
uma infnidade de referncias 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 classifcamos perodos histricos e vai at a compli-
cados modelos matemticos e probabilsticos para comportamentos sociais, econmi-
cos e at planetrios. O Universo se expande ou se contrai de acordo com alguns mod-
elos e no se comportar de acordo com eles mostra que ou o modelo inteiro est errado
ou existem outras variveis ainda no consideradas. At o comportamento de tribos
indgenas est sujeito a modelos segundo alguns estudos. Um estudo conduzido por
um antroplogo americano tentou demonstrar que brigas e agresses aparentemente
aleatrias entre ndios seguiam um padro que obedecia a regras codifcadas em seus
genes. E at mesmo a aparente desordem do mundo tambm 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 ento fco aqui com algumas perguntas que me assombram:
Ser que somos meros agentes que seguem padres defnidos ou mesmo progra-
mveis?
Ser que modelos e padres so capazes de descrever ou controlar tudo o que
realmente precisamos fazer?
Ser que modelos servem para descrever ou controlar coisas abstratas como ser-
vios 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 prprio momento da indisponibilidade. Esse momen-
to no simplesmente um gatilho para voc executar um troubleshooting, mas uma
grande oportunidade para voc demonstrar uma atitude em relao falha. Sim, at-
itude, que se traduz em demonstrar ao cliente, de diversas maneiras, que voc est
tomando todas as aes necessrias, que voc est atento s necessidades dele e que
voc est tentando minimizar ao mximo o impacto causado pela falha. Ou seja, afnal
de contas que voc se importa com ele. Mas espera a, eu no 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 fnal de uma compra em um super-
mercado, com um sorriso amarelo no rosto, ento sim, voc consegue fazer isso com
um processo. Se por atitude voc entende um desejo genuno em servir, que afnal a
essncia da prestao de um servio, ento provavelmente no.
Pois essa uma questo que envolve a prpria natureza pessoal do que chamamos de
38
servio. Um bom relacionamento entre cliente e prestador e uma boa atitude ao pre-
star o servio podem minimizar enormemente o impacto de falhas ou at ser o princi-
pal fator de satisfao, maior inclusive que a qualidade tcnica do entregvel em si. E
isso se aplica a qualquer contexto de prestao de servios. Uma pesquisa feita junto
a pacientes e mdicos mostrou que os pacientes que tinham um bom relacionamento
com seus mdicos tinham pouqussima pr-disposio a process-los, mesmo em caso
de falhas muito graves. Pacientes que recebiam pouca ateno dos mdicos tinham
uma tendncia a serem muito mais rigorosos e crticos, com uma pr-disposio a pro-
cess-los mesmo em caso de falhas menos graves ou mesmo nenhuma falha tcnica.
A concluso estarrecedora. Mesmo que voc implante um modelo rigoroso de
prestao de servios, baseado em prticas como ITIL, voc pode estar falhando miser-
avelmente em prestar um bom servio na perspectiva do cliente. Isso signifca que os
aspectos soft da prestao de servios podem estar sendo severamente negligen-
ciados em detrimento do compliance a modelos ou padres, o lado hard. Entenda-se
como aspectos soft a atitude, o bom relacionamento, a conscientizao, o engaja-
mento, o alinhamento por consenso, o comportamento guiado por princpios e no
pela obrigao, o equilbrio, a justia 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 presso por ganhos exagerados sem um ganho de ma-
turidade contnuo e natural, o pressuposto de que o software faz sozinho o processo,
a falta de co-participao das pessoas no processo de criao do modelo e a preguia
em fazer melhoria contnua na iluso de que relatrios gerados automaticamente
iro magicamente fazer isso sozinhos acabam por minar o lado soft da implantao.
E o resultado pode variar desde a implantaes desastradas at a implantaes ra-
zoavelmente bem sucedidas, mas que deixam a sensao de que no fundo, excelncia
em servios era muito mais do que aquilo que alcanamos.
Culpa do modelo? Talvez no. Modelos ainda so necessrios 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 rpido e indolor. Simples-
mente porque o adapte que exige o verdadeiro consultor. O adote se resume a rep-
licar coisas prontas de uma referncia. O adapte exige experincia, sensibilidade, con-
hecimento e pacincia. Coisas que o prprio negcio dos clientes s vezes ignora, mas
que o verdadeiro consultor no pode ignorar deixando-se levar pelas respostas fceis
que o cliente quer ouvir. Em meio s presses insanas que os negcios de hoje fazem
em seus lderes, o verdadeiro consultor aquele que consegue trazer os princpios
chave e unir esses princpios sua experincia, guiando estes lderes no meio do tur-
bilho para um caminho factvel, mas sem respostas prontas e sem perder de vista um
caminho de longo prazo.
39
Essa unio entre princpios e experincia compe o equilbrio entre uma adoo
rgida demais e uma adaptao excessiva em que os benefcios se perdem. Para achar
esse equilbrio preciso entender o que rgido demais e adaptativo demais. Na
minha viso, rgido demais mais fcil de identifcar. Toda vez que algum ignora ne-
cessidades genunas 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 so os princpios fundamentais que no podem ser ig-
norados ou mesmo distorcidos. Um exemplo clssico o CMDB. Qual o princpio chave
do CMDB ou do processo de gerenciamento de confgurao? No, no vale ir l no liv-
ro e copiar a defnio. Esses princpios no esto no livro, porque eles so uma essn-
cia que compreendida com o tempo e a experincia de cada consultor. O princpio
chave ter um nico CMDB? No. O princpio chave a ferramenta? No. O princpio
chave exigir que todas as tarefas do processo sejam executadas? No. O princpio
chave, baseado na minha experincia como consultor, o seguinte: ter armazenada a
informao relevante sobre os servios para manter os servios funcionando e proje-
tar novos servios. To simples quanto isso. Mas muitos esto fazendo o contrrio:
partir de um modelo operacional pronto (e no de princpios chave!), esto tentando
encaixar fora 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 operao com os princ-
pios chave e ir, aos poucos e de forma conjunta, criando um modo de operao guiado
pelos princpios que realmente faro a diferena naquele contexto.
Notem um ponto interessante: uma srie de necessidades adicionais acabam surgindo
partir do princpio chave, mas no necessariamente como princpio chave de um nico
processo. Um exemplo: porque precisamos compor o gerenciamento de confgurao
com um gerenciamento de mudanas? Porque o ITIL mandou? No. Simplesmente
porque sem um processo de mudanas mantendo as informaes atualizadas seria im-
possvel que a informao se mantivesse relevante e o benefcio simplesmente se per-
deria. Percebam que nesse caso, uma adaptao que criasse um CMDB sem qualquer
tipo de controle de mudanas seria uma distoro de princpios chave e no seria uma
adaptao vlida. E exatamante a que modelos e consultores mostram seu valor.
Como guardies de princpios chave que so fonte de evidentes benefcios e que se
implementados com pacincia, sensibilidade, engajamento coletivo e continuidade,
podem criar no apenas servios de excelncia, mas pessoas conscientes de seu papel
e capazes de prover esses servios.
40
Seguranca da Informao e a arte de no dizer no
CLAUDIO DODT
Profssionais que trabalham na rea de Segurana da Informao convivem com um
confito quase dirio. Se de um lado temos uma equipe focada na proteo das infor-
maes, adoo de controles e preocupao com os riscos, do outro temos os usurios
que muitas vezes querem simplesmente trabalhar.
Essa pequena batalha acaba criando uma falsa impresso de que a rea de segurana
da informao s sabe dizer no. O que acaba sendo uma verdade parcial.
O problema que uma boa parte dos profssionais de segurana ainda tem a percep-
o de que no se pode confar no usurio ou que no adianta explicar que o usurio
no vai entender. O problema que essa falta de dilogo faz com que os usurios se
cansem e acabem por contornar ou mesmo esquecer os aspectos relacionados segu-
rana da informao.
Idealmente, um bom departamento ou profssional de segurana deve pensar como
um fornecedor de solues o que muitas vezes implica em parar de ditar o que pode
ser feito e abrir espao para o dilogo, trocar o no por um talvez ou depende.
Ouvir e entender demandas um passo essencial para o alinhamento com usurios e
buscar uma soluo segura e efciente.
41
Artgos com Altos ndices de Teoria
42
A eterna e incendiria briga entre a Gesto de
Incidentes e de Problemas
CLAUDIA MARQUESANI
No adianta. Creio que este seja um dos maiores assuntos e calos nos ps de quem
trabalha com a gesto de servios de TI. A eterna briga entre os participantes e os ger-
entes dos processos de gerenciamento de incidentes e problemas.
Vamos as defnies rpidas. Essas duas disciplinas tem interesses relativamente con-
fitantes. O objetivo do gerenciamento de incidentes restabeler a operao normal
do servio o mais rpido possvel - resolver o incidente. Como dizem l na minha terra
apagar incndios...
J o objetivo do Gerenciamento de problemas investigar as causas subjacentes (cau-
sas razes, aquelas que se resolvidas, solucionaro defnitivamente o problema). Isso
feito no para todos os incidentes, mas para aqueles considerados crticos para o
negcio: de grande impacto ou recorrentes. O pessoal da gesto de Problemas quer
entender , investigar e descobrir porque pegou fogo e acompanhar a implementao
de medidas para que novos incndios no ocorram.
Mais ou menos assim: durante um incndio, os integrantes da equipe de gesto de in-
cidentes so os bombeiros. A equipe de gesto 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 incndio.
Com esse exemplo , fca bem claro entender porque tantas organizaes fracassam na
implementao e operao do processo de gerenciamento de problemas.
claro, que o chefe da equipe de bombeiros e dos peritos no deve ser o mesmo. Eles
tem metas e objetivos diferentes. E tambm claro que um bombeiro no pode ser
perito e vice versa. Imaginem o perito/bombeiro l, investigando as causas de um in-
cndio 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 tc-
nico est l, iniciando a investigao 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 histria?
O bombeiro (A EQUIPE DE INCIDENTES) ajuda o perito (A EQUIPE DE PROBLEMAS)
, com informaes valiosssimas sobre o incndio (onde, quando comeou, quais fo-
43
ram suas caractersticas) e INFORMAES SOBRE O INCIDENTE (classifcao, pri-
orizao, informaes sobre a atuao e encerramento).
O perito (A EQUIPE DE PROBLEMAS) ajuda o bombeiro (A EQUIPE DE INCIDENTES),
investigando (OS PROBLEMAS) e levando solues (ATRAVS DE MUDANAS) para
que novos incndios no ocorram. Tambm oferece, atravs de suas investigaes, no-
vas tcnicas para apagar incndios mais rapidamente e adequadamente (SOLUES
DE CONTORNO MELHORES PARA AS EQUIPES DE SUPORTE TCNICO).
No fnal das contas, qual papel mais importante? No adianta brigar, ambos so im-
portantes! Se por um lado preciso combater todos os incndios (INCIDENTES) , por
outro no adianta observar um incndio em cada esquina todos os dias, ocasionado
pelo mesmo motivo - como por exemplo m instalao eltrica e no fazer absoluta-
mente nada (PROBLEMAS que so relacionados a incidentes recorrentes, por exemp-
lo).
Um deve complementar, ter sinergia, auxiliar e no entrar em confito com o outro,
porque, apesar de diferentes, os papis do gerenciamento de incidentes e problemas
so complementares. Juntos, eles trazem benefcios para a organizao de TI, para os
usurios e para os clientes que so tangveis - menor desgaste da equipe de TI, maior
confana da parte do cliente e aquilo que toda organizao precisa para garantir sua
sobrevivncia - aumento da efcincia e ECONOMIA de custos.
Uma semana quente para todos e at a prxima. :)
44
A importncia do Plano de Continuidade
CLAUDIO DODT
Uma matria publicada na revista ComputerWorld, edio 536, do ms de maio, cita um
estudo global feito por uma empresa de segurana com 1,7 mil gestores, em 2010 en-
volvendo 18 pases, tinha como objetivo entender quais eram os grandes difcultado-
res para recuperao em desastres. Segue alguns resultados desse estudo:
32% sistemas virtuais no contam com backup regular.
Apenas 1 em cada 4 entrevistados usam tecnologia de replicao para proteo.
68% dos servidores virtuais no contam com planos para recuperao de falhas.
51% das empresas, no Brasil, afrmam que procedimentos de backup ocorrem ape-
nas semestralmente.
Os dados dessa pesquisa, abrem espao para falar a respeito de plano de continuidade
de servios de TI e junto com isso, at mesmo, primariamente, plano de continuidade
dos negcios.
Esses dados so no mnimo curiosos e constatam uma realidade j percebida no dia a
dia das empresas, as vezes parece que tem que acontecer a tragdiadesastre com a em-
presa ou com organizaes prximas, para que questes de continuidade de negcio, e
consequentemente TI, comecem a entrar em pauta das discusses. Um exemplo cls-
sico, as tragdias no vale do Itaja em 2008. As diversas empresas, TI e outras, pblicas
e privadas, tinham pouqussimos ou nenhum planejamento para continuidade. Hoje a
realidade um pouco, veja bem, um pouco diferente. J existem planos para continui-
dade em casos de tragdias que ajudam a minimizar os impactos para o negcio.
A ausncia de um plano de continuidade de negcios (PCN), muitas vezes usada como
justifcativa para a ausncia de um plano de continuidade para servios de TI. Essa jus-
tifcativa tem um certo fundo de razo, pois o negcio que determinar o que real-
mente crtico para o negcio e ir nortear qual dever ser a disponibilidade esperada
para os servios de TI. Se o contrrio ocorrer, continuidade dos servios de TI, baseado
apenas em TI, pode gerar custos e uso de recursos desnecessrios.
Dessa forma, no existe plano de continuidade de servios de TI, sem plano de continui-
dade de negcio. interessante, nesse momento, citar tambm a diferena entre ger-
enciamento de disponibilidade e continuidade de servio. O primeiro gerenciamento
preocupa-se em manter o servio funcionando da melhor maneira possvel e o maior
tempo possvel, j a continuidade, trata das aes de recuperao e continuidade, caso
acontea algum desastre que interrompa a disponibilidade de tais servios.
Penso que o momento atual das empresas e nossa sociedade, oportuno para desen-
volvimento e validao de planos para continuidade de negcio. A medida em aumen-
tamos a dependncia por servios de tecnologia da informao, devemos aumentar
45
nossos planos para continuidade desses servios em caso de interrupes graves, que
podem, em muitos casos, decretar a morte da empresa.
isso grande abrao. At o prximo artigo.
46
A relao entre ITIL e ISOIEC20000
LUIZ WAGNER OLIVEIRA NASCIMENTO
Atualmente, o ITIL utilizado como referncia para empresas desenvolverem estrat-
gias de servios envolvendo o planejamento e a gesto da demanda, gesto da qualidade,
acompanhamento dos resultados fnanceiros para os servios e a divulgao destas in-
formaes em seus catlogos de servios. Verifca-se tambm que adoo destas prti-
cas abrange tambm o planejamento do servio que considera aspectos importantes
como o dimensionamento da capacidade, segurana, nveis de servio visando assegu-
rar a continuidade e sustentabilidade do processo. Aps realizao do planejamento
inicia-se a fase de implantao do processo para o ambiente de produo, incluindo os
processos de ativos/confguraes de servios, mudanas, release, testes e avaliao.
Quando um determinado servio est pronto e devidamente testado e aprovado,
realizada uma passagem dos levantamentos realizados para o ambiente de produo.
Os processos e funes como central de servio, incidentes, requisies de mudana,
eventos e acesso so utilizados durante este processo. Finalmente apresentada uma
referncia para a melhoria contnua, considerando algumas prticas recomendadas
por Deming o ciclo PDCA.
Tudo estaria correto, e funcionaria perfeitamente, se no fosse um detalhe: Como o ITIL
uma referncia, de que formata garantir a efetividade, implantao e sua sustentao
ao longo do tempo? A abordagem apresentada no ITIL no garante que os processos
sejam efetivamente implementados em seus requisitos mnimos. O ITIL descritivo,
onde descrevemos as melhores aes a serem tomadas. Deveria existir algo que ser-
visse como um guia, para determinaes do tipo deve existir um plano de capacidade!
que pudesse ser avaliada quanto sua efccia e efcincia. Neste aspecto, a ISO 20000
atua complementando o ITIL, o Cobit e seus processos de Delivery e Support, atua de
forma parecida, porm seu foco o que fazer sob a viso da Governana de TI e no
em Gesto da Qualidade de Servios de TI. Como o processo necessita ser implemen-
tado de forma organizada existe a ISO 20000 que um padro internacional de quali-
dade, projetado para gerenciamento de servios de TI. Este framework certifca que a
empresa utiliza as melhores praticas recomendadas pela ITIL. No Brasil temos poucas
empresas certifcadas at o momento, j no exterior est referncia j utilizada em
maior escala, servindo como pr-requisitos para participao licitaes 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 mtodo ou com uma anlise adequada. Quando um gerente de TI afrmar
que j possui processos ITIL implantados porem no consegue garantir que este pro-
cesso est seguindo os requisitos mnimos de qualidade. A ISO 20000 deve ser utiliza-
da como um complemento do ITIL, pois atesta que as melhores prticas em gesto de
servios de TI esto efetivamente implantadas. A ISO 20000 garante tambm que os
47
processos mnimos esto sendo aplicados e seguidos. O fato de ser auditado por uma
entidade externa de forma contnua e peridica, bem como auditoria interna, garante
que os processos e a qualidade de servios de TI esto 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
direo sobre o sistema de qualidade de servios de TI, competncia, treinamentos e
requisitos de documentao para a devida execuo dos processos. Tudo isso audita-
do quanto sua efccia. Outro aspecto fundamental a incluso dos processos do cic-
lo PDCA, incluindo auditoria, registros, evidncias de no conformidades e oportuni-
dades de melhorias com suas aes preventivas e corretivas. Processos importantes
de relacionamento com o cliente (incluindo gesto de reclamaes) e de gesto de for-
necedores so auditados e escalados. Exige-se tambm um processo de melhoria de
servios com atividades bem defnidas, incluindo determinaes claras de entradas e
sadas dos processos.
Devido a importncia do ITIL em sincronia com o ISO 20000 recomenda-se que as
empresas e provedores de TI juntamente com seus gestores considerem esta implan-
tao conjunta. Sendo este processo voltado primeiramente para a obteno de mel-
hores nveis de qualidade na prestao de seus servios. Com base nesta argumenta-
o, acredita-se que os benefcios de implantar a ISO20000 em conjunto com o ITIL
sero superiores quando comparados a implantao do ITIL de forma isolada para a
Gesto da Qualidade em Servios de TI. Lembrando que o Cliente quem sai ganhan-
do com esta unio.
48
Catlogo de Servios O desconhecido
BRUNO CAIADO
Atire a primeira pedra quem nunca achou que um Catlogo de Servios simples-
mente uma lista de servios. A princpio, ele pode at ser, mas esqueceram de avisar
que a gesto do catlogo um dos processos do livro Service Design. Se antes ele era
um adendo da Gesto de Nvel de Servio, agora ele ganhou o corpo e a visibilidade
merecidos.
Se o servio o meio para atingir os resultados esperados, o catlogo a referncia
dos servios oferecidos. O processo de gesto do catlogo garante a consistncia e at-
ualizao das informaes. E a pergunta : de onde vem essas informaes? Das reas
de TI? Das reas de negcio? Da cabea do CIO? Do CMDB? No....nada disso. As in-
formaes do catlogo devem ser uma consequncia de uma estratgia de portfolio
de servios.
Eu explico. Qualquer empresa deve embasar suas decises e seus investimentos em
uma estratgia que balanceie a demanda prevista e a anlise do nvel dos riscos identi-
fcados. 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 vo simplesmente manter a em-
presa funcionando. Baixo risco.
Grow the Business (GTB): para investimentos que sero usados para aumentar o ta-
manho do negcio. Mdio risco.
Transform the Business (TTB): para investimentos que iro transformar o modelo
de negcio. Alto risco.
Qualquer empresa que quer se manter viva, precisa, no mnimo, de investimentos de
categoria GTB. Em momentos de crise, uma possvel opo adotar uma estratgia
conservadora e restringir os investimentos a um mnimo (RTB), o que aparentemente
uma opo segura, mas nem sempre pavimenta o caminho para o sucesso e a sus-
tentabilidade.
Uma estratgia de portfolio deve balancear riscos e valor para o negcio para defnir
onde investir e quais sero os servios oferecidos interna e externamente. Diversos
fatores incluindo a prioridade do negcio, o custo-benefcio e as capacidades da em-
presa devem ser considerados. Lembre-se: o VALOR para o negcio no uma enti-
dade abstrata, ele real e medido em nmeros!
Vamos a um exemplo simplifcado. Novamente, vou usar uma empresa area fctcia. O
ano de 2008 foi complicado para nossa empresa. As vendas no alcanaram o patamar
esperado e o nvel de ocupao esteve constantemente prximo ao break even (pon-
to em que o nmero de assentos vendidos cobre as despesas incorridas para fazer a
49
viagem). Pesquisas indicam que os clientes vem tendo difculdades para comprar pas-
sagens pelo web-site, principalmente se esto utilizando smartphones ou outros apa-
relhos mveis. Como uma clara tendncia de mercado o uso de canais mveis, fca
claro que criar um servio especfco 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 fcil e rpida 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
lder do mercado.
Um novo servio chamado de canal mvel de venda criado e requerimentos es-
pecfcos so levantados. Esses requerimentos levam em considerao tanto a ade-
quao ao propsito (ft for purpose) e a adequao ao uso (ft for use). A adequao ao
propsito diz, por exemplo, que esse canal deve servir para vender passagens. A ade-
quao ao uso vai levar em considerao a usabilidade, o dimensionamento (de acordo
com o aumento do nmero de passagens compradas), a segurana, a disponibilidade,
entre outras especifcaes. Acordos de nvel de servio so ento defnidos levando
em considerao esses requisitos.
Temos aqui um exemplo de como alimentamos nosso catlogo de servios. E se um dia
esse servio deixar de fazer sentido para o negcio, ele deve ser retirado do catlogo?
SIM! Isso mesmo. O catlogo uma entidade viva, que contm uma referncia para os
servios de TI correntes e que devem ser constantemente avaliados quanto ao valor e
custo-benefcio para o negcio. Quem faz essa avaliao a estratgia de portfolio de
servios, alimentando e retirando servios do catlogo.
A pergunta inevitvel que se segue : porque diabos os servios do meu catlogo (se
que ele existe) parecem ser apenas atividades ou funes de TI, sem uma conexo
direta com o negcio? Provavelmente porque esse catlogo foi feito baseado no que
voc faz e no no que faz sentido voc fazer. Simplesmente se fez uma lista, usando
algum critrio como tipo de tecnologia, funcionalidade ou atividades padro de uma
rea de tecnologia. Algo como: REDES, CORREIO ELETRNICO, APLICAO X, etc.
Eu no diria que est errado, mas est, no mnimo, incompleto e desconectado com o
negcio. Nosso objetivo deve ser deixar EXPLCITO como esses servios de TI supor-
tam os servios ou processos de negcio 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 negcio da em-
presa?
A primeira coisa que se diz, especialmente em empresas grandes, : eu no tenho a
menor noo da estratgia da empresa. Isso j grave, mas mais grave ainda dizer
que voc no sabe nem quais so as atividades chave para manter a empresa funcion-
50
ando e que a nica coisa que voc aprendeu rodar uma rotina batch. Em um cenrio
desolador como esse, minha recomendao de emergncia :
1. Mapeie, em alto nvel, quais as atividades chave que mantm a empresa funcionan-
do e divida elas em grandes grupos como: VENDAS, PRODUO, FINANCEIRO,
etc.
2. Mapeie servios de TI em um nvel de funo, como: EMAIL, INTERNET, APLICA-
O DE VENDAS, etc.
3. Relacione quais servios suportam quais grupos de processos de negcio.
Esse o comeo, mas no o fm. Faa uma primeira verso, menos detalhada, com o
conhecimento tcnico ou de de negcio que voc tem. Voc pode at lanar uma verso
inicial j nesse estgio. Em seguida, mos obra: pergunte, descubra, questione, en-
tenda, conecte-se com a estratgia da sua empresa e com suas reas de negcio. Apro-
funde seu conhecimento em conceitos adicionais como o de market spaces e gerenci-
amento de demanda (disponveis no livro Service Strategy). Faa seu catlogo girar!
Refne, detalhe, publique-o. Ele pode at ser uma lista, mas tambm o refexo do que
a organizao de TI tem a oferecer e de como ela suporta os objetivos da sua empresa.
Se isso ser apenas uma lista, apenas uma questo de perspectiva.
51
Como o BDGCCMDB pode aumentar a efcincia dos
processos de suporte a servios
CLAUDIA MARQUESANI
A Gerncia de confgurao um processo bastante popular dentro da biblioteca
ITIL. Porm , um dos mais difceis de ser implementado, um dos mais importantes e
aquele onde temos maior difculdade para vender dentro de uma organizao, por
ser bastante trabalhoso.
Na prtica, vocs conseguem realmente verbalizar quais so as vantagens de uma
gerncia de confgurao para uma organizao e para os outros processos de suporte
a servios? Abaixo cito alguns exemplos que podem auxili-los a expor essas vanta-
gens para uma organizao, principalmente aquelas onde alguns processos j esto
implementados, mas que est sentindo uma falta tremenda de uma boa gerncia de
confguraes para se apoiar. So elas:
1. Gerencia de Incidentes: utilizar o BDGC (Banco de Dados de Gerencia de Conf-
guraes) para ter uma viso lgica da infraestrutura de TI e seus servios, atravs
dos itens de confgurao e seus relacionamentos. Essa viso 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 alocao do time
correto para atuao no incidente; maior rapidez na identifcao dos itens de con-
fgurao impactados e que precisam ser agilmente substitudos ou corrigidos.
2. Gerencia de Mudanas: ter maior maior controle e agilidade no gerenciamento
sobre as mudanas do ambiente, pois o uso do BDGC e a viso lgica da infraes-
trutura de TI e seus servios ( fornecida atravs dos itens de confgurao e seus
relacionamentos), mostrar de maneira clara e controlada os componentes envol-
vidos na mudana e seu real impacto para o servio. Por exemplo: ter maior agi-
lidade na aprovao de mudanas, pois haver mais facilidade para analisar o im-
pacto no servio dos itens de confgurao envolvidos na mudana; poder fazer
o uso de baselines de confgurao , para retornar o ambiente ao status anterior a
uma mudana executada e mal sucedida.
3. Gerencia de Problemas: poder aumentar a efcincia da gerencia de problemas,
ao facilitar a anlise de tendncias em Itens de confgurao relacionados a inci-
dentes e identifcar a causa bsica de um ou mais incidentes. Essa informao
utilizada para evitar novos incidentes e melhorar a qualidade dos servios.
4. Gerncia de Liberaes: aumentar a efetividade da gerencia de liberaes, pois
far auditorias e controles permanentes para evitaro que softwares ilegais ou
no autorizados sejam registrados na BSD (biblioteca de software distribuido). Au-
mentar a efcincia das liberaes pois utilizar baselines de confgurao para
salvar as informaes dos ICs antes do release (atributos como verso ou status,
por exemplo). Essas informaes podero auxiliar caso a liberao seja mal suce-
52
dida e um backup tenha que ser retornado.
Vrias outras vantagens poderiam ser citadas, inclusive nos processos de entrega de
servios, mas este post certamente no terminaria hoje.
Conhecer as vantagens de um processo para o negcio de sua organizao o primeiro
passo para tomar a deciso de implement-lo , para conseguir aprovao dos patroci-
nadores do projeto e a aderncia de todos que estaro envolvidos no mesmo. Ou seja,
saber as vantagens no garantia de que o sucesso seja atingido, mas primordial para
busc-lo. Espero ter ajudado vocs nesta busca.
Disponibilizamos uma planilha modelo de CMDB/BDGC. Para fazer o download, clique
aqui. Bom divertimento! :D
53
Compreendendo a ITIL a partir de uma perspectiva
nada convencional um show de rock
REN CHIARI
A ITIL traz uma srie de boas prticas de gerenciamento, organizadas para cobrir
todo o ciclo de vida de um servio, focando em cinco fases:
Estratgia de Servio: a fase de concepo do servio. A pergunta mais simples que
poderia ser feita neste momento : O que sua organizao quer ser?.
Desenho do Servio: Nesta fase, a estratgia do servio comea a tomar forma. Tudo o
que necessrio para os requisitos do servio vai para o papel. hora de planejar como
a organizao vai se transformar no que foi proposto durante a estratgia!
Transio do Servio: Mos na massa! Neste momento preciso garantir que tudo o
que foi desenhado na fase anterior se torne, de fato, um servio disponvel (ou con-
sumvel), com o mnimo de riscos/impacto.
Operao do Servio: S os fortes sobrevivem a esta fase. Uma vez disponibilizado o
servio, agora momento de garantir que ele funcione de acordo com o que foi previs-
to na estratgia, com o mnimo de interrupes, e com o tratamento adequado para os
imprevistos.
Melhoria Continuada do Servio: Sempre h o que melhorar. Nesta fase h uma pre-
ocupao em garantir que todo o ciclo de vida do servio passe por uma avaliao cri-
teriosa, e lies sejam aprendidas (em qualquer das fases).
Ok, mas qual a relao da ITIL com um show de rock?
Tendo como verdade a ideia de que um show de rock uma das ofertas disponveis em
um servio de entretenimento, promovido por empresas de eventos (os provedores
de servio) ao pblico em geral (os clientes do servio), vamos ao seguinte cenrio:
Imagine o custo total do espetculo de uma banda mundialmente conhecida. As tone-
ladas de equipamentos, a logstica e a enorme quantidade de profssionais envolvidos.
A responsabilidade por garantir a satisfao de 50, 100, 200 mil pessoas que pagam
para ver o melhor espetculo possvel ao vivo, em um tempo relativamente curto (de 1
a 3 horas). Apesar de um pouco especfcos, estes desafos podem ser identifcados em
quaisquer outros servios vistos no dia a dia, sejam eles de TI ou no.
H algum tempo atrs, a banda U2 adotou uma forma diferente de se apresentar, em
um palco de 360 graus. Toda essa inovao faz parte de uma estratgia defnida para
introduzir um novo conceito, uma nova experincia para o pblico. E sabemos que fun-
cionou muito bem.
54
Provavelmente foram necessrios muitos meses de estudo, clculos, envolvimento de
engenheiros de som, arquitetos, especialistas em efeitos visuais, etc. Alm disso, con-
siderar quantidade mxima de pblico por show, valores de ingressos, limitaes de
locais em que este show poderia ser instalado, segurana, etc. Tudo isso para desenhar
como esta nova abordagem do espetculo poderia ser viabilizada ao pblico.
Voc j deve ter visto aqueles profssionais 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 questes 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 rpido possvel.
Outro exemplo: cada equipamento, desde a ordem de ligao, confgurao de parmet-
ros e informaes relevantes dos equipamentos como voltagem, modelo, etc. devem ser
controlados minuciosamente para que o timbre caracterstico do artista permanea
sempre o mesmo. Provavelmente, o artista deve sempre ser consultado, e aprovar
quaisquer mudanas 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 fnalizar, tudo isso deve estar explcito nos contratos milionrios fechados com os
organizadores do evento, juntamente com os nveis de servio esperados (durao do
show, msicas a serem tocadas, etc).
Apenas neste pequeno cenrio, j foram citados ao menos 5 processos de gerencia-
mento de servios sugeridos pela ITIL.
55
Do inferno ao cu Como o exemplo do Corinthians
pode ser utilizado na Gesto de Servios
CLAUDIA MARQUESANI
Antes de comear a escrever esse texto bom fcar claro: sim, sou corintiana, comemo-
rei muito o ttulo e estou extremamente realizada. Porm, 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 diviso em 2007 para campeo do Mundo em 2012. Pouco mais de
quatro anos que levaram uma das maiores torcidas do pas do inferno ao cu, ou seja,
satisfao TOTAL dos clientes do timo. A satisfao tanta, que existe a previso
de arrecadao para o timo no prximo ano, somente em patrocnio, de mais de 390
milhes de reais.
E quem no gostaria de ter esse sucesso no nosso dia a dia? De uma Central de Servios
mal avaliada para uma Central de Servios devidamente reconhecida como estratgi-
ca para o negcio de uma empresa? De um processo de mudanas e liberaes que s
visto como burocrtico, para um processo devidamente reconhecido como essencial
para que problemas no aconteam na rea de TI de uma organizao? De uma equipe
de suporte cansada, desmotivada e mal vista porque est sempre envolvida em inci-
dentes e retrabalho, para um time tcnico forte e respeitado?
Na prtica, o que realmente costuma funcionar, no mundo do futebol, na nossa vida
pessoal ou empresarial, so trs ingredientes bsicos e foram eles que geraram essa
receita extraordinria de sucesso corintiana: estratgia, organizao e foco para at-
ingir os objetivos.
ESTRATGIA signifca saber onde queremos chegar e como chegaremos l. No segre-
do para ningum que nenhum corintiano, incluindo os dirigentes, aguentava mais as
piadinhas relacionadas falta de um ttulo de libertadores (nunca sero). Foi ento
que, no pior momento do time, aps um rebaixamento, resolveram repensar a estrat-
gia usada at ento. 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 to certo. Ele criou a rede de lojas do Podero-
so Timo (fcil ver uma em cada grande shopping do Brasil), o projeto scio-torcedor,
trouxe de volta o querido ex-craque da seleo Ronaldo (um golpe de mestre para o
marketing do time), ou seja, soube utilizar a paixo da torcida a favor do clube e com
isso aumentou o faturamento anual de R$ 117,5 milhes para R$ 290,4 milhes. H 3
anos, ouvi uma entrevista do ex-presidente Andrs Sanchez para uma rdio, onde ele
j dizia que nos prximos 10 anos o Corinthians estaria entre os maiores do mundo...
Hoje, algum duvida dessa profecia e da estratgia que eles esto utilizando para atin-
gir esse objetivo?
56
Portanto, se seus objetivos no esto sendo alcanados, ser que a estratgia que voc
traou para chegar l a mais adequada? Talvez seja necessrio percorrer um camin-
ho diferente do traado inicialmente.
ORGANIZAO signifca preparar-se para atingir os objetivos que foram defnidos
na estratgia. Contratao de bons e experientes profssionais no adiantava quer-
er ganhar a Libertadores, com toda sua presso de jogos eliminatrios, com quem no
tem experincia nesse tipo de competio. O timo buscou Chico, Alessandro, Mano
Menezes, todos com experincia. Eles j estavam l em 2008, disputando a 2 diviso
do brasileiro, quando o Corinthians ainda sequer sonhava em disputar a copa Liber-
tadores da Amrica...
Do mesmo modo, se voc quer ter servios de qualidade, contrate profssionais de
qualidade pelo menos alguns para conduzir esse trabalho e para preparar e treinar
outros profssionais com sua experincia.
No podemos esquecer que preciso tambm estar organizado como uma equipe. Ap-
enas estrelas, no ganham campeonato - se fosse assim o campeo mundial de 2012
seria, com certeza, o Chelsea. Estrelas so o mximo naquilo que fazem, mas soz-
inhas no conseguem conduzir um trabalho adequadamente, no conseguem chutar e
cabecear para o gol. preciso que todos da equipe estejam organizados e preparados
para buscar o objetivo principal defnido l na estratgia.
FOCO signifca manter-se concentrado, organizado, preparado para a busca desses
objetivos, mesmo diante das adversidades. O Corinthians contratou um lder forte, que
promove o trabalho em equipe e fortaleceu-o junto ao grupo, atravs do apoio incondi-
cional da diretoria. Nem mesmo quando, vergonhosamente, o time sob a liderana do
Tite caiu ainda na fase pr-Libertadores de 2010, esse lder perdeu fora. A diretoria
optou por mant-lo, para que ele continuasse seu trabalho. O resto da histria ns j
conhecemos.
Quantas vezes diante de um fracasso, no mudamos de rumo, a ponto de esquecer qual
era nossa estratgia inicial? No pecado algum mudar de estratgia, mas muda-la a
todo instante signifca falta de foco e perda de dinheiro (economizaram com a resciso
do Tite naquela poca e tenho certeza que no esto arrependidos disso hoje!).
Sei que muitos no corintianos vo ler esse post e pensar: que saco, at aqui no ITSM
na prtica esto falando do Corinthians!. Torcidas e coraes a parte, temos que recon-
hecer que esse tipo de ascenso serve de inspirao para qualquer profssional que
deseja crescer e buscar o sucesso. Porque no utilizar esse exemplo tambm no nosso
dia a dia? Mesmo que vocs sejam Palmeirenses, So Paulinos, Santistas...Tenho certeza
que pode dar certo! Vaiiiiiiii Corinthians! ;)
57
Entenda a importncia da classifcao do Incidente
CLAUDIA MARQUESANI
Antes de mais nada preciso entender os conceitos e a importncia dessa atividade
para a Gerncia de Incidentes e para os outros processos das melhores prticas ITIL.
O que classifcao?
CLASSIFICAO = CATEGORIA + PRIORIDADE, onde:
CATEGORIA = determina o tipo de Item de confgurao afetado no incidente (por
exemplo: Hardware/Software)
PRIORIDADE = IMPACTO + URGNCIA , sendo que:
- IMPACTO = Impacto que o incidente pode causar nos negcios;
- URGNCIA = tempo requerido para resoluo (relacionado a tempo).
Na prtica , a classifcao de um incidente pode parecer algo muito simples. Por isso ,
na maioria das vezes durante a implementao ou no dia a dia do processo no damos
a devida importncia a essa atividade.
Classifcar um incidente sim uma atividade relativamente simples, mas criar catego-
rias que possam trazer efcincia e melhorar os servios de uma organizao pode ser
bastante desafador.
Quando vamos implementar a Gerncia de incidentes das melhores prticas ITIL,
importante investir tempo planejando essa classifcao. Qual seria a melhor classif-
cao (sempre pensando no custo benefcio para o seu negcio)? importante ter em
mente que o ideal sempre o mximo de informao , com o mnimo de controle e cus-
to para mant-la.
Abaixo apresento como a correta classifcao de um incidente pode contribuir para
aumentar a efcincia de uma organizao e o fornecimento de servios .
1. A classifcao usada para defnir 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 esforos na soluo de incidentes para os quais no foram ade-
quadamente preparados.
2. A classifcao tambm usada para comparar incidentes e contribuir para me-
lhorar o tempo e qualidade da investigao e diagnstico . Atravs da classifca-
o possvel comparar incidentes que j aconteceram e aplicar diagnsticos e
solues j implementados no passado para os incidentes atuais de maneira mais
fcil , rpida e precisa.
3. A classifcao usada para identifcar a prioridade de atendimento de inciden-
tes, baseada no impacto que o incidente traz para o negcio. Com isso possvel
priorizar o atendimento daquilo que realmente causa impacto para o negcio de
58
uma organizao (perdas fnanceiras, de imagem, etc.)
4. A correta classifcao auxiliar uma organizao a defnir quais questes devem
ser feitas e checadas durante a abertura do incidente. Pode ser criado um script
de perguntas para garantir que as informaes necessrias sejam obtidas com o
usurio impactado e registradas no momento da abertura e suporte incial do inci-
dente. Isso evitar perguntas e testes descenessrios com os usurios e melhora-
r a qualidade e tempo do atendimento do incidente.
Lembre-se: classifcar corretamente est , em grande parte, ligada a QUALIDADE DOS
ITENS QUE TEMOS DISPONVEIS PARA COMPOR A CLASSIFICAO. No livro do
ITIL (Service Support) podem ser encontrados diversos exemplos de modelos de clas-
sifcao (categorizao e priorizao, respectivamente anexos 5 A e 5B do captulo de
Gesto de Incidentes). Avaliem as sugestes e melhores prticas do livro e adaptem
com cuidado e esmero para sua organizao.
Disponibilizamos em nossa rea de downloads um modelo prtico de categorizao e prior-
izao). Verifquem esse modelo e adaptem para o dia a dia de vocs.
Os ganhos podem ser realmente surpreendentes...
Boa sorte.
59
Nveis de servio to necessrios quanto inteis
BRUNO CAIADO
O ttulo parece exagerado e sensacionalista, mas no consegui pensar em nada que se
aproxime mais da realidade. Todos querem niveis de servio, mas poucos tem em mente
objetivos claros antes de comear a constru-los. O objetivo maior, claro, no poderia
ser outro a no ser o alinhamento com o negcio, uma das mximas mais exaustiva-
mente repetidas e menos efetivamente implementadas. E o motivo muito simples:
no existe mgica para isso. Nem ITIL nem qualquer sistema, metodologia ou melhor
prtica capaz de fornecer a resposta defnitiva de como obter o alinhamento com
o negcio.
De fato, essa uma pergunta aberta e que exige uma abordagem estruturada, que se
inicia no entendimento dos objetivos de negcio e se replica em diferentes nveis.
impossvel falar em alinhamento em um nico nvel. mais coerente falar em uma
cadeia de alinhamentos, que se sincronizados e mantidos atravs dos controles ade-
quados podem trazer um alinhamento efetivo.
A biblioteca ITIL no oferece uma nica disciplina para isso. Na verdade, o alinha-
mento com o negcio permeia a biblioteca. Mas se pudssemos eleger uma nica dis-
ciplina, o gerenciamento de nvel de servio (Service Level Management SLM) estaria
provavelmente em primeiro lugar. E no 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 considerao as necessidades de negcio
dos clientes. Cumprir ou no SLAs irrelevante se os acordos no refetirem necessi-
dades reais de negcio.
Mais importante que qualquer outra coisa, SLM depende de uma defnio de servios
que de fato ajudem os clientes a atingirem seus objetivos, do alinhamento de expec-
tativas em relao ao que ser entregue e da defnio de SLAs que realmente faam
alguma diferena ao serem cumpridos. Se esses passos fundamentais no forem exe-
cutados (ou no forem corretamente executados) a monitorao e cumprimento ou
no de SLAs ser uma mera formalidade contratual. E por consequncia, a confeco
de relatrios ser apenas mais uma forma de gastar papel, tinta ou recursos.
Ao invs de meros SLAs, nada mais relevante para medir a efetividade de SLM do que
a confana que o cliente tem no provedor. A confana construda a partir de um re-
lacionamento estabelecido entre cliente e provedor e no a partir de SLAs. Isso se re-
fete na seguinte pergunta: entre um provedor que cumpriu o SLA e um provedor que
no cumpriu, mas que tem um cliente satisfeito e que confa no seu trabalho, quem
executou o processo de SLM de forma mais efetiva? A resposta clara: o ltimo.
Para exemplifcar, vamos retomar nosso exemplo da empresa area. As expectativas
so altas em relao ao novo servio de canal mvel de dados, que ser usado para
60
facilitar a compra de passagens por smartphones. A expectativa de um aumento em
18% no RPK (Revenue Passenger Kilometers), que representa quilmetros de passa-
geiros pagantes (o que exclui tarifas especiais e tripulantes). Isso signifca pelo menos
400.000 passageiros a mais em um nico ms para nossa companhia area. O siste-
ma tambm 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 ocupao). Duas
funcionalidades chave para o negcio so mapeadas: a capacidade de venda de pas-
sagens, com um dimensionamento para pelo menos 400.000 transaes/ms e a in-
tegrao com o portal de indicadores. O nvel de servio acordado prev um baseline
de 1000 transaes por hora, sendo 500 simultneas, e pelo menos 1 replicao diria
das informaes para o portal. A replicao deve ocorrer antes da reunio diria da
gerncia de operaes (10:00 AM). Indisponibilidades do canal devem ser corrigidas
em no mximo 1 hora, representando a perda potencial de 1000 passageiros.
No difcil 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 negcio e os servios e SLAs oferecidos pela organizao de TI. Mas o
alinhamento no pra por a. Ele , na verdade, uma via de mo de dupla e exigir uma
cuidadosa anlise 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 fnanceiro. Depois disso, ser preciso monitorar o atingimento dos SLAs,
acompanhar perdas potenciais e efetivas e revisar continuamente o valor de negcio
que eles representam. Eventualmente, tanto a capacidade do canal ou outra caracte-
rstica podero ser revistas luz de novas necessidades de negcio. Os SLAs devem
evoluir de forma alinhada a essas necessidades e no podem ser considerados como
gravados em pedra. Para isso, os prprios acordos devem prever revises peridicas
tanto do atingimento quanto de sua adequao.
Alguns SLAs podem at ser inteis, mas aqueles criados de acordo com necessidades
de negcio especfcas, monitorados e revisados continuamente, e usados como ferra-
mentas para a construo de relacionamentos com o cliente, esses sim, so verdadei-
ros SLAs, to necessrios quanto os prprios servios prestados.
61
O conhecimento meu e ningum tasca
CARLOS AFONSO
notrio que em muitas organizaes atualmente existem pessoas que se acham por-
tadoras de um conhecimento mstico que, segundo eles, no pode ser passados aos
outros.
No contexto de uma Central de Servios, um exemplo visto naqueles que possuem o
conhecimento especfco relacionado a um ou mais componentes de um servio de TI.
O drama maior principalmente quando a organizao no possui uma documentao
adequada de seus servios, e a organizao e/ou fornecedores no possuem o mesmo
em relao 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 no
passou o seu conhecimento para ningum, e faz questo de no document-lo. Moti-
vo: ele se considera especial e indispensvel para a organizao basicamente por este
conhecimento especfco que possui.
importante ressaltar: existem duas situaes possveis. Uma aquela em que a pes-
soa no quer passar o seu conhecimento para os outros. E a segunda aquela em que a
pessoa no se importaria em pass-lo. Nos dois casos, obviamente a culpa da organ-
izao que no tem um processo efcaz de Gesto do Conhecimento.
Soube de um caso, certa vez, em que um profssional foi treinar outros dois para re-
alizar o atendimento de terceiro nvel de um sistema de faturamento. Ao fnal de dois
meses, nenhum dos dois profssionais novos tinha o conhecimento a respeito dos pro-
cessos mais crticos do sistema. E o sistema nem era to complexo assim! Ainda que a
culpa fnal seja dos responsveis pela Gesto do Conhecimento (por no ter feito um
plano de transferncia do conhecimento efcaz), era evidente a satisfao dele em ter
que ser chamado toda vez que surgiam incidentes, problemas e servios adicionais em
relao ao componente.
O principal argumento dado por ele era: eu trabalho com este sistema h uns 2 anos,
no possvel explicar todas as regras de faturamento em meses. Na verdade, o pedi-
do era que primeiramente as regras e comportamentos crticos do sistema fossem
explicados, mas mesmo assim, isso no foi feito. E, pelo tamanho do componente em
questo, um mero plano de transferncia de conhecimento cuidaria disso em questo
de poucas semanas. E ele fez esse plano, mas cuidou para que o conhecimento essen-
cial no fosse passado. Concluso: por medo de deixar de se sentir especial, ele tratou
para que o restante da sua equipe no possusse o conhecimento que ele possui para o
atendimento em relao ao componente.
62
Esse tipo de profssional, que alega a impossibilidade ou inviabilidade de se transmitir
um conhecimento especfco (e que justamente por isso ele seria especial), um dos
principais desafos para a gesto atual. Por vrios motivos, como o fato de que, se profs-
sionais em geral sentem-se valorizados e motivados quando conseguem fazer suas
atividades plenamente, eles tero sua iniciativa difcultada por que algum 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 no
sempre que este profssional estar disponvel ou ter tempo para o atendimento.
No existem benefcios organizacionais para este tipo de atitude, que, em muitos ca-
sos, chega a ser desleal com a prpria organizao e com a equipe.
Com desafos deste tipo aqueles que atuam com o processo de Gesto do Conhecimen-
to, disponvel a partir da ITIL 3.0, tero que lidar. o momento de valorizar profssio-
nais que so formadores de outros profssionais, e que, aos poucos, com sua atitude,
ajudem a diminuir o risco do atendimento no acontecer. E, aos poucos, mostrar para
aqueles que no valorizam a transmisso do conhecimento que eles no passam de fo-
cos de risco para a organizao de TI.
63
O que Gerenciamento de Servios de TI?
ANDRE JACOBUCCI
O Gerenciamento de Servios 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 Servios
de TI: o fato de ser uma prtica.
Da mesma forma que cozinhar no se aprende apenas lendo bons livros de receita
ou observando outras pessoas a cozinhar o Gerenciamento de Servios de TI uma
habilidade que s se desenvolve praticando.
Assim como na cozinha de um bom restaurante, o resultado de uma organizao de TI
tambm depende do acesso a bons ingredientes, bons fornecedores, bons equipamen-
tos, boas receitas e mtodos de trabalho corretos. Mas depende, sobretudo, de profs-
sionais competentes que no se esquecem, jamais, de que tudo isso existe porque al-
gum est esperando na mesa para satisfazer sua fome ou para ser surpreendido com
um prato delicioso.
O Gerenciamento de Servios 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 organizao de TI mais do que um grupo de profssionais especializados,
executando tarefas tcnicas isoladas dentro de suas reas de expertise, e sim com uma
viso de como tudo isso se encaixa e, principalmente, com a viso do cliente que espe-
ra na outra ponta.
Sendo assim, o Gerenciamento de Servios de TI est longe de ser apenas a implan-
tao de uma rea de atendimento aos usurios fnais erroneamente chamada de
Service Desk para que a organizao de TI possa ser comunicada das falhas, dvi-
das e difculdades que impactam a produtividade destes usurios.
O Gerenciamento de Servios de TI enxerga que todas as atividades de uma organizao
de TI do levantamento de requisitos para o desenvolvimento de um novo sistema, ao
monitoramento dos equipamentos que sustentam os sistemas j em produo esto
conectadas e devem ser gerenciadas por meio de parmetros de qualidade, tempo e
custo, para que tal organizao de TI possa atender e surpreender seus clientes.
Sendo assim, o Gerenciamento de Servios de TI tambm envolve aspectos de market-
ing, operacionais, fnanceiros e de gesto de pessoas.
O assunto no se esgota aqui, como alertei no incio deste artigo. Pelo contrrio, nos
estimula a abord-lo sob diversos outros ngulos: o ngulo operacional representa-
do pelo conjunto de processos clssicos propostos pela ITIL, o ngulo da qualidade
e da gesto sistmica proposto pela ISO 20000, o ngulo da Governana de TI re-
64
forado pelo Cobit, dentre diversos outros.
E para voc? O que o Gerenciamento de Servios de TI?
65
Os 10 Mandamentos da ITIL
CLAUDIA MARQUESANI
Quando falamos de ITIL, NO existe a obrigao para se implementar os processos
exatamente como os livros os descrevem. Um dia, vrias empresas e pessoas envolvi-
das no gerenciamento de servios de TI resolveram trocar experincias. Algum tempo
depois, elas chegaram a um consenso sobre o que eram as melhores prticas de merca-
do e posteriormente registraram isso em livros que se tornaram a famosa biblioteca
ITIL. Porm, alguns erros e gargalos na implementao dos processos so to bvios
e atrapalham tanto a prtica de implantao, que resolvi inovar e criar os 10 manda-
mentos da ITIL ( mas eles poderiam ser muito mais que 10... escrevam contribuies a
respeito nos nossos comentrios desse post). So eles:
1. Amars a ITIL com a ti mesmo.
No desista! O gerenciamento de servios de TI de uma organizao e a melhoria dos
nveis de maturidade dos processos tende a melhorar com o passar do tempo. No adi-
anta andar com a biblioteca da ITIL debaixo do brao, estudar horrores e achar que
do dia para a noite todos os stakeholders de uma organizao vo migrar de uma cul-
tura voltada a produtos para uma cultura voltada a servios. um processo lento, algu-
mas vezes solitrio e quase sempre rduo. Um processo de catequizao que levar
a mudana de cultura de uma organizao. Siga em frente, motive seu time, mostre o
valor agregado do gerenciamento de servios, aposte nos ganhos rpidos e aos poucos
essa cultura ganhar mais espao em sua organizao.
2. No achars que TI (tecnologia da informao) quem dita as regras.
Um dos principais objetivos da ITIL fazer com que a TI contribua para que a organ-
izao atinja seus objetivos de negcio. Por isso, no adianta a rea de TI assumir que
entende o que importante para a empresa e tomar as decises por si mesma. preci-
so OUVIR O CLIENTE. preciso entender quais so os objetivos de negcio. Nenhum
conhecimento tcnico ser sufciente para trazer resultados, se a TI tomar decises
que no auxiliam no atingimento das metas da organizao. Provavelmente sero fei-
tos investimentos em recursos e tecnologias desnecessrios... Hoje em dia ningum
deseja queimar dinheiro, no mesmo? Pecado mortal esse...
3. No implementars gerenciamento de confgurao sem um bom processo de
gerenciamento de mudanas para auxili-lo.
Parece simples, mas no . o gerenciamento de Mudanas quem informa ao Banco
de Dados de Gerenciamento de Confgurao o que e quais sero os itens de confg-
urao alterados durante uma alterao no ambiente de TI. Podemos, portanto, ter
o melhor Banco de Dados de Gerenciamento de confguraes do mundo, contratar
66
a mais competente consultoria para implement-lo, para defnir o escopo mais ade-
quado e contratar ferramentas perfeitas para mant-lo - sem um processo adequado
de gerenciamento de mudanas, os itens de confgurao sero alterados, novos itens
sero adicionados na infra e em pouco tempo, pouqussimo tempo mesmo, o Banco de
Dados de Gerenciamento de Confguraes estar completamente desatualizado. Se
voc j comeou um projeto de implementao de Gerencia de confguraes em sua
organizao e ainda no tem um processo de mudanas, aconselho a rever o projeto
ou tomar muito calmante para explicar para o CIO porque os benefcios que foram
vendidos com o processo no esto chegando...
4. Jamais atribuirs o papel do Gestor de Problemas e de Gestor de Incidentes para
a mesma pessoa.
Alguns processos tm interesses confitantes e esse um exemplo claro! A gerncia de
incidentes tem o objetivo de restabelecer a operao do servio o mais rpido possvel.
A gerncia de problemas tem o objetivo de investigar cuidadosamente para identifcar
a causa raiz de um incidente crtico ou vrios incidentes recorrentes, no se preocu-
pando com o tempo, mas com a qualidade da investigao. Imaginem o grande confito
de interesses, quando determinamos a mesma pessoa para ser gerente de incidentes
e problemas? Ela priorizar o atendimento de incidentes ou a investigao? Essa nem
vou responder, vou deixar para vocs pensarem...
5. Treinars o pessoal da Central de Servios periodicamente.
J foi assunto de inmeros posts, parece uma situao bem bvia, mas quase sem-
pre negligenciado. No adianta cobrar qualidade de atendimento de uma central de
servios, onde as pessoas responsveis pelo contato com o usurio no so treinadas.
Elas precisam receber, periodicamente , alm de treinamento tcnico, treinamento
comportamental, saber como atender um telefonema, como lidar com o usurio e como
responder as questes tcnicas. Precisam saber utilizar a base de conhecimento, uma
de suas principais ferramentas de trabalho. Sem treinamento, a Central de Servios
um barco a deriva, esperando um vento mais forte (ou um evento mais crtico) para
afundar.
6. No subestimars a satisfao dos usurios e dos clientes.
Oua o cliente e instigue-o a expressar sua opinio a respeito do gerenciamento de
servios de TI. Revise os nveis de servios atingidos e os no atingidos e atue na mel-
horia contnua de ambos (sim, tambm possvel melhorar o que j est bom, se isso
for interessante para o negcio). No deixe tudo parado, como se nada estivesse ac-
ontecendo. No espere seu cliente lhe procurar para manifestar sua insatisfao, per-
gunte como ele se sente! Existem dois tipos de detectores de satisfao: o termmetro
da satisfao do cliente o gerente de nvel de servio e a voz dos usurios para TI o
67
Service Desk. Utilize esses meios e atinja os melhores fns!
7. No achars que uma certifcao ser sufciente para implementar os proces-
sos na prtica.
Na teoria a prtica outra. J ouviram essa frase? Pois , essa a mais fel realidade
quando falamos de gerenciamento de servios de TI. Resumindo: somente conheci-
mento terico, diplomas e certifcados, apesar de ajudarem (e muito!), no garantem
uma boa implementao. preciso trocar experincias com pessoas que j vivenciar-
am uma implantao dos processos, preciso pesquisar , conhecer o negcio e princi-
palmente ter pacincia. como andar de bicicleta. Quanto mais voc pratica, melhor
fca. Ateno para a palavra: PRTICA.
8. No recusars 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 gesto de projetos. Atravs deles possvel obt-
er maior controle para as melhores prticas, maior entendimento e maior efcincia e
efccia na operao e entrega de servios. Pesquise como eles podem interagir. Na In-
ternet existem inmeros vdeos e publicaes a respeito e em nosso site j colocamos
alguns posts sobre esse assunto. S aplicar as melhores prticas da ITIL muito bom,
suport-las por outros controles e modelos melhor ainda!
9. No achars que a gerncia de disponibilidade serve somente para medir quan-
tas horas um recurso de TI est operando (ou no!).
Princpio 2 da Gerencia de Disponibilidade (retirado do livro verso 2 ITIL Entrega de
servios) : Reconhecer que, mesmo que as coisas dem errado, ainda assim possvel al-
canar o objetivo do negcio e a satisfao do Cliente. Um servidor caiu. Ser que mesmo
assim possvel manter a satisfao do cliente? A gerncia de disponibilidade garante
que sim, porque ela no se preocupa apenas em manter o servio operando. Quando
algo errado acontece, ela tambm cria condies e pode suportar para que esse servio
seja recuperado mais rapidamente. Que tal clusterizar um servidor que suporta um
processo crtico para o negcio aps um estudo da gerncia de disponibilidade?
Outra parte muito interessante dessa gerncia que ela tambm oferece tcnicas in-
teressantssimas para avaliar qual ser a disponibilidade projetada para um novo servio.
Essas tcnicas podem ser aplicadas inclusive para aumentar a confabilidade, disponi-
bilidade e segurana de um servio que ainda nem entrou em produo, alterando o
desenho proposto para melhor-lo. Sim, esse um processo muito nobre da nossa bib-
lioteca e muitas vezes esquecido ou subestimado...
10. No achars que o Gerenciamento Financeiro um processo chato da bibliote-
ca.
68
Eu entendo. A maior parte das pessoas que trabalham com TI, no gosta muito de f-
nanas. um mundo um pouco estranho para quem est acostumado com termos tc-
nicos, sistemas e mquinas. Mas um mal necessrio. Alis, imprescindvel. A TI pre-
cisa comear a se vender. preciso mostrar porque determinado investimento em
TI custa caro muitas vezes, o retorno que aquele investimento trar para o negcio e
como esses custos sero controlados. TI precisa profssionalizar-se, ser operada como
uma rea de negcio e no somente um processo de apoio dentro de uma organizao.
Entender termos como : Retorno sobre o investimento (ROI) e Custo Total de Proprie-
dade (TCO), no mais opcional. Afnal, voc, diretor de TI, tem idia de quanto custa
para sua organizao manter esse notebook que voc est utilizando? Pergunte ao
processo de gesto fnanceira. Ele ter a resposta.
69
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 servios de TI (Tecnologia da In-
formao).
A ISO 20000 um conjunto que defne as melhores prticas de gerenciamento de
servios de TI. O seu desenvolvimento foi baseado na BS 15000 (British Standard) e
tem a inteno de ser completamente compatvel com o ITIL (Information Technolo-
gy Infrastructure Library). A sua primeira edio ocorreu em dezembro de 2005.
As normas internacionais relacionadas com a Gesto de Servios de TI permitem a
colaborao de organizaes internacionais e fornecem directrizes valiosas que con-
tribuem para o estabelecimento da credibilidade das empresas. Uma nova norma, a
ISO 20000, agora disponvel, permite a uma organizao demonstrar aos seus clientes
e investidores que opera com integridade negocial e segurana, e que promove uma
cultura de melhoramento contnuo da qualidade no mbito da Gesto de Servios de
TI.
Por que isto to importante? importante porque a obteno da certifcao ISO
20000 pode contribuir para que as empresas alcancem uma vantagem competitiva
relativamente s empresas que no cumprem os requisitos desta norma.
O lanamento da ISO 20000 levanta uma questo s organizaes em todo o mundo:
O que necessita a organizao de fazer presentemente, relativamente ISO 20000?
Dever uma Organizao Procurar Obter Certifcao?
Conforme referido anteriormente, a certifcao ISO 20000 permite verifcar se uma
organizao emprega as melhores prticas de Gesto de Servios de TI, conforme
demonstrado por uma avaliao independente externa com base numa norma ofcial,
realizada por uma organizao de auditoria autorizada. Este nvel de validao pode
auxiliar a empresa a manter uma maior competitividade.
Ao determinar se deve ser obtida a certifcao ISO 20000, a organizao dever ter
em considerao o seguinte:
A ISO 20000 particularmente importante para organizaes de sectores indus-
triais em que a qualidade dos servios de TI essencial para o sucesso empresarial,
tais como mas no s os sectores industriais de servios fnanceiros, servios
de utilidade pblica e servios de sade. A certifcao permite a estas organiza-
es demonstrarem aos seus accionistas e clientes que possuem ambientes de TI
bem geridos.
A ISO 20000 relevante para organizaes que fornecem servios geridos e sub-
contratao de servios de TI. A certifcao permite s organizaes de servios
70
geridos garantirem aos seus clientes que os seus ambientes de TI sero bem ge-
ridos, possibilitando s organizaes de outsourcing garantirem aos clientes que
recebero servios de TI de elevada qualidade.
Estes fornecedores de servios tm que provar que documentaram as cinco reas
chave da ISO 20000 e que esto a ser cumpridos os requisitos da norma. A docu-
mentao dever incluir as polticas e planos de Gesto de Servios, Acordos de
Nvel de Servios, processos e procedimentos exigidos pela ISO 20000 e quaisquer
registos exigidos pela norma.
As organizaes devero ter em considerao as implicaes de uma certifcao
no respeitante conformidade regulamentar. Presentemente, as organizaes
necessitam de demonstrar a conformidade com um nmero 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, esto especifcamente rel-
acionados com servios de TI e Gesto de Servios de TI (ITSM). Actualmente, os au-
ditores no exigem certifcao de standards como prova de conformidade, mas no
futuro esta situao poder mudar.
Por a ISO 20000 estar especifcamente relacionada com a qualidade da ITSM, esta
poderia proporcionar um standard internacional utilizado pelos auditores com vista a
determinar a conformidade.
A certifcao ISO 20000 ser concedida apenas a organizaes com operao de ITSM
e certifcar apenas a operao de ITSM nessas organizaes. A certifcao no ser
concedida para produtos ou para servios de aconselhamento de melhores prticas
oferecidos por organizaes de consultoria. A certifcao poder tornarse um requi-
sito para realizar negcios com determinadas organizaes, tais como agncias gover-
namentais ou outsourcers.
Por a ITIL ser fundamental para a ISO 20000, importante seleccionar uma soluo
de automatizao compatvel com os processos ITIL. A soluo dever suportar pro-
cessos que abranjam todas as disciplinas de gesto de servios de TI gesto dos ac-
tivos, gesto de mudanas e confgurao, gesto de incidentes e problemas, gesto de
lanamento, gesto de capacidades, gesto de disponibilidades, gesto de fnanceira
e gesto de nveis de servios. As suites so mais adequadas do ponto de vista fnan-
ceiro, do que as aplicaes best-of-breed, que requerem um trabalho de integrao
considervel.
Alm disso, um dos principais requisitos da ITIL a integrao de processos entre as
diferentes disciplinas.
Deve ser procurada uma soluo que integre totalmente os vrios processos ITIL,
tanto do ponto de vista dos processos, como dos dados, em vez que proporcionar mer-
71
amente um mapeamento campo-a-campo.
O que mais importante compreender acerca da ISO 20000 e da ITIL que ambas
necessitam de um melhoramento contnuo, factor este que permitir aumentar a cred-
ibilidade e competitividade de uma empresa.
Referncias 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/
72
Principais diferenas entre a ITIL v2 e V3 Parte I
REN CHIARI
Uma comparao entre a ITIL v2 e V3 nos revela que todos os principais processos
da ITIL V2 permanecem na V3, com algumas mudanas substanciais. Entretanto, em
muitos casos, a ITIL v3 apresenta descries de processos revisadas e melhoradas.
A principal diferena entre a V2 e V3 a nova estrutura do Ciclo de Vida do Servios:
A ITIL V3 melhor entendida,organizando os processos de uma forma cclica. Isto
signifca que a antiga estrutura do Suporte a Servios (Service Support) e Entrega de
Servios (Service Delivery) foi substituda por um novo conjunto ncleo de cinco disci-
plinas:
Estratgia de Servio - determina quais tipos de servios devem ser oferecidos
para quais Clientes ou mercados.
Desenho do Servio - identifca necessidades do servio e idealiza novas ofertas
de servios, bem como alteraes e melhorias aos servios existentes.
Transio do Servio - constri e implementa servios novos ou modifcados.
Operao do Servio - realiza atividades operacionais
Melhoria contnua do Servio - aprende com os sucessos e fracassos do passado
e melhora continuamente a competitividade, efccia e efcincia dos servios e
processos.
A grande sacada da ITIL V3 que ela no reinventa a roda, ela complementa os pro-
cessos da ITIL V2 conhecidos com um nmero de novos processos e coloca mais n-
fase na produo de valor para o negcio. Devido a nova estrutura de ciclo de vida do
servio, todas as interfaces entre os processos ITIL foram alteradas para refetir a
nova estrutura de processo na ITIL V3, ento embora os processos da ITIL V2 e V3
sejam conceitualmente idnticos, as suas interfaces mudaram.
Muitos me perguntam qual verso da ITIL atualmente a melhor pedida. A minha
resposta : Depende!
Se o intuito somente se certifcar para ocupar um posicionamento melhor de mer-
cado, o que no considero uma boa prtica mas infelizmente a realidade do nosso
mercado, v de V3 sem pensar duas vezes.
Mas se o objetivo botar a mo na massa e atuar n pratica com implementao ou
gesto de processos ITIL, vai depender muito da maturidade atual da sua organizao.
Confesso que ainda no vi um nmero grande empresas se preocupando em imple-
mentar a V3. E digo mais, utilizar a ITIL de verdade em qualquer de suas verses j
um grande passo. Criei uma discusso em nosso grupo no LinkedIn justamente para
abrir espao para este debate. Participem!
73
No prximo artigo irei comentar de forma mais detalhada as mudanas e comparaes
entre as verses da ITIL.
74
Principais diferenas entre a ITIL v2 e V3 Parte II
REN CHIARI
Dando continuidade ao artigo sobre as principais diferenas entre as verses 2 e 3 da
ITIL sem maiores delongas, detalhamos as principais modifcaes e incluses que
ocorreram da transio da ITIL v2 para a V3.
ESTRATGIA DO SERVIO
Gerenciamento de Portflio de Servio
Gerenciar servios como portflio um conceito novo adotado na ITIL V3, in-
troduzindo uma flosofa estratgica sobre como o portflio de servios deve ser
desenvolvido.
Gerenciamento Financeiro
Sem alteraes relevantes. As atividades e objetivos do processo permanecem
idnticas nas duas verses. Este processo encontrado no livro de Entrega do Ser-
vio (Service Delivery) na V2.
H um captulo muito interessante e detalhado sobre ROI (Return of Investment).
DESENHO DO SERVIO
Gerenciamento de Catlogo de Servio
O Gerenciamento de Catlogo de Servios foi includo como um processo novo na
V3.
Na V2, h meno sobre o conceito do Catlogo de Servio, porm de forma mui-
to mais superfcial. Felizmente na V3 foi dada a ateno merecida ao Catlogo de
Servios, que ganhou um processo s pra ele!
A V3 introduz uma clara distino no Catlogo de Servios sob o ponto de vista de
Servios de Negcio (servios visveis ao Cliente, defnidos por SLAs) e Servios
de Suporte (servios visveis internamente pela organizao de TI, defnido por
OLAs ou UCs.
Gerenciamento de Nveis de Servio
Atividades e objetivos do processo permanecem os mesmos nas duas verses, po-
rm na V3 as atividades de reviso do servio so fazem parte do livro de Melhoria
Continua do Servio
Gerenciamento de Segurana de TI
A V2 fornece um guia sobre Gerenciamento de Segurana de TI em um livro sepa-
75
rado.
A V3 trata o Gerenciamento de Segurana de TI como parte do livro Desenho do
Servio, resultando em uma melhor integrao deste processo no Ciclo de Vida do
Servio.
O processo foi atualizado para contemplar novas preocupaes e desafos relacio-
nados segurana.
Gerenciamento da Arquitetura de TI
O Gerenciamento da Arquitetura de TI estava contemplado dentro do Gerencia-
mento de Aplicaes, na ITIL V2.
A V3 fornece orientaes sobre os problemas de Arquitetura de TI como parte de
um captulo 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-
vio, criando uma melhor integrao no Ciclo de Vida do Servio.
TRANSIO DO SERVIO
Gerenciamento de Mudanas
Basicamente, as atividades e objetivos do processo permanecem identicas em am-
bas as verses.
A V3 introduz o conceito de Modelos de Mudanas, defnindo com mais nfase
tipos diferentes de Mudanas e como elas podem ser direcionadas.
Gerenciamento de Projetos (Planejamento e Suporte a Transio)
O Planejamento e Suporte a Transio um processo novo na V3. A ITIL V2 abor-
dava alguns aspectos deste processo dentro do processo de Gerenciamento de Li-
beraes, mas a V3 refora consideravelmente est orientao
Gerenciamento de Liberaes e Implantao
A ITIL V3 apresenta um detalhamento maior nas reas de planejamento e teste
da liberao. Isto levou a adio de dois processos dedicados na V3, que na verso
anterior estavam sob o processo de Gerenciamento de Liberaes:
- Gerenciamento de Projetos (Planejamento de Transio e Suporte)
- Validao e Teste do Servio
Validao e Teste do Servio
O processo de Validao e Teste do Servio novo na V3. A V2 abordava alguns
aspectos sobre testes de liberaes dentro do processo de Gerenciamento de Li-
76
beraes mas a V3 refora consideravelmente este aspecto.
Os principais adendos na V3 esto nos detalhamentos durante os estgios de tes-
tes durante a Transio do Servio e descries 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 esto coberto por vrios
processos na V2 por exemplo, o Gerenciamento de Problemas era (e continua
sendo na V3) o responsvel por gerenciar a base de Erros Conhecidos.
Na V3, entretanto, o Gerenciamento do Conhecimento defnido como nico pro-
cesso responsvel por centralizar e prover conhecimento para todos os outros pro-
cessos de ITSM.
OPERAO DO SERVIO
Gerenciamento de Eventos
O Gerenciamento de Eventos parte do livro ICT Infrastructure Management na
ITIL V2.
As atividades e objetivos do processo so praticamente idnticos 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 idnticos nas
duas verses.
A ITIL V3 faz distino entre Incidentes (interrupes no servio) e Requisies
de Servio (solicitaes padres oriundas de usurios, ex: reset de senha).
Requisies de Servio no so mais atendidas via processo de Gerenciamento de
Incidentes, para isso existe na V3 um novo processo chamado Cumprimento de
Requisio.
H agora um processo dedicado para lidar com emergncias (Incidentes Crticos).
Foi adicionada uma interface entre os processos de Gerenciamento de Eventos e
Gerenciamento de Incidentes. Eventos signifcantes so agora considerados como
gatilho para a criao de um Incidente.
Cumprimento de Requisio
O Cumprimento de Requisio foi adicionado como um novo processo na V3 com
o objetivo de lidar de forma dedicada com Requisies de Servios. Esta mudana
77
foi motivada claramente pela distino mais do que bem-vinda feita na V3 entre
Incidentes e Requisies de Servios.
Na V2, o Cumprimento de Requisies 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 deciso de incluir este processo dedicado foi motivada por razes de segurana
de TI, como garantir acesso a servios de TI e aplicaes somente para usurios
autorizados
Gerenciamento de Problemas
Atividades e objetivos do processo permanecem praticamente idnticos nas duas
verses, porm um novo sub-processo chamado Reviso de Problemas Graves
foi introduzido para revisar o histrico de soluo de Problemas graves buscando
a preveno de recorrncias e obter lies aprendidas para o futuro.
MELHORIA CONTNUA DO SERVIO
A V2 continha algumas atividades de Melhora Contnua do Servio dentro do pro-
cesso de Gerenciamento de Nvel de Servio, por exemplo as Revises do Servio
e gesto de um Plano de Melhoria do Servio.
A ITIL V3 expande esta abordagem em um livro completamente novo, introdu-
zindo processos dedicados para a avaliao e melhoria de servios e processos.
78
Servios: a ponte perdida entre negcios e TI
BRUNO CAIADO
No difcil notar que a principal mudana entre as verses 2 e 3 da biblioteca ITIL
o estabelecimento do ciclo do servio. Se antes o servio fcava meio tmido perto
dos robustos processos de entrega e suporte, agora ele foi defnitivamente empossa-
do como o astro principal. E no por acaso: o servio o cerne do VALOR entregue
ao cliente, como mostra a sua prpria defnio (em traduo livre):
Servio 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 especfcos.
Parece complicado, mas no . Signifca que o cliente no quer fazer ele mesmo, mas
contratar algum para tal. O como responsabilidade deste algum (o provedor) e
o cliente espera apenas o deliverable acordado. uma forma diferente de dizer que o
servio uma caixinha preta com interfaces bem defnidas e que os mecanismos inter-
nos so uma responsabilidade exclusiva do provedor.
Por exemplo, pense numa mquina que vende latinhas de refrigerante. O cliente no
quer (e nem precisa) saber como o fabricante faz a manuteno da mquina ou como
so os mecanismos internos dela. O objetivo dele to simples quanto ter um refrig-
erante gelado, no momento desejado. Esse o resultado que o cliente quer atingir
como descrito na defnio do servio e esse resultado que determina o deliverable
do servio e at nveis de servio. Portanto:
RESULTADO ESPERADO PELO CLIENTE: um refrigerante gelado, no momento
desejado
MEIO QUE FACILITA O ATINGIMENTO DOS RESULTADOS (servio): Mquina
de refrigerante
NVEIS DE SERVIO: Disponibilidade: 24x7 (afnal de contas, qualquer hora hora
de um refrigerante) / Temperatura: 8
Parece simplrio, mas so os mesmos conceitos que esto embutidos no ciclo do servio
do ITIL. Da estratgia, passando pelo design, transio, operao e melhoria contnua,
o foco um s: QUAL O RESULTADO QUE MEU CLIENTE ESPERA ATINGIR? E por
consequncia, como eu defno uma estratgia e toda a minha operao para que ela
entregue os servios esperados e que iro suportar o meu cliente no atingimento dos
seus objetivos e resultados.
O servio parece to ridiculamente bvio que ningum sabe mais qual ou sente a ne-
cessidade de defni-lo. A conexo entre o servio e os resultados de negcio que o
cliente quer atingir se perdeu no meio do caminho. Enquanto isso, as organizaes de
TI continuam a prestar os servios bvios: suporte UNIX, correio eletrnico ou pro-
cessamento BATCH, s pra dar alguns exemplos. Nesse contexto, nveis de servio di-
79
fcilmente vo dizer algo para o negcio e a organizao de TI vai continuar como uma
conta contbil pra alocar despesas de tecnologia. E s. No ser o parceiro estratgico
que entende quais so os resultados que o negcio quer atingir e molda seus servios
de acordo com eles.
Vamos dar um exemplo. Pense numa empresa de transportes areos. O que acontece-
ria se o website que vende passagens parasse? A venda atravs da web e conseqen-
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 servio. Dentro do
ciclo, essa defnio comea na estratgia de TI e toda a estrutura da organizao de
TI desenhada e operada para garantir que esses servios sejam atendidos. O fato de
ela ser tambm desenhada (e no apenas operada) signifca que esse trabalho proa-
tivo e inclui desde a arquitetura dos componentes, a dimensionamento de equipes e
defnio de mtricas. No estamos falando de um foco total (mas reativo) quando um
website cai e o gerente grita pedindo a restaurao do servio imediatamente. Esta-
mos falando em estratgia, coordenao, sincronizao e gesto.
Para que essa estratgia seja efetiva, uma defnio de servios alinhada com os obje-
tivos de negcio um passo fundamental. Usar aplicaes crticas pode ser um bom
comeo, mas no por si s uma estratgia estruturada e coerente. preciso pensar
em processos de negcio e KPIs (Key Performance Indicators) operacionais e fnan-
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
depreciao e amortizao de ativos. No caso especfco do web-site, ele se insere em
um processo de gerao 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 no garantir 99,99999% de disponibilidade de um web-
site, mas sim facilitar o atingimento, por parte do negcio, de seus objetivos de receita
por canal de venda. Isso signifca, 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 comea de cima e deve permear a organizao, comeando do en-
tendimento por parte do CIO dos objetivos da corporao, passando por um desen-
ho e arquitetura adequados e chegando at ao atendimento veloz, gentil e orientado a
servio 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 gesto. Para chegar a esse estado, a implantao de processos
ITIL apenas o comeo de uma jornada sem fm, cujo objetivo no chegar, mas mel-
horar continuamente em busca da excelncia.
80
Sistemas de qualidade: a iluso da melhoria
contnua
BRUNO CAIADO
Todo mundo quer qualidade. O fornecedor, o cliente, o dono da empresa ou at os
prprios funcionrios das empresas. O que poucos sabem responder com convico e
segurana : o que afnal de contas qualidade? fcil pedir um servio de qualidade,
o difcil tanto defnir, quanto fornecer e ainda ter que melhorar continuamente a tal
qualidade.
Para exemplifcar, vamos recorrer a quem colocou em prtica com maestria o concei-
to de melhoria contnua em linhas de produo: a Toyota. De forma bem simplifcada,
o conceito adotado pela Toyota (e por milhares de outras empresas nos dias de hoje)
busca uma otimizao entre no-conformidades e custo de produo, sendo no-con-
formidade qualquer evento que no se enquadre em uma faixa de referncia. O fato
de estarmos falando de uma faixa de valores um ponto chave: quer dizer que exces-
so de qualidade uma no-conformidade tambm!
Um caso emblemtico ocorreu na Nissan antes da revoluo promovida pelo brasilei-
ro Carlos Ghosn, hoje considerado uma referncia mundial na gesto de grandes em-
presas. A fbrica japonesa tinha orgulho da perfeio com que fabricava seus faris: os
recortes da superfcie eram to perfeitos, to perfeitos, que apenas engenheiros com
um microscpio conseguiam reconhecer sua qualidade superior. Os clientes no da-
vam mnima para os faris, mas os custos evidentemente iam s alturas. A questo
acabava sendo: o que adiantava ter qualidade na viso dos engenheiros se quem iria
usar os carros no reconhecia essa qualidade? E pior: no estava comprando os carros
e ainda achava os carros da concorrncia melhores!
O pessoal de marketing veio tona para tentar descobrir o que os clientes queriam de
verdade. No foi nada surpreendente descobrir que os clientes queriam carros con-
fveis, com design moderno e com preos razoveis. Depois de descobrir o bvio ulu-
lante, os engenheiros voltaram s pranchetas e focaram na confabilidade dos faris e
no na preciso dos recortes da superfcie. O resultado? Faris mais baratos, mas que
iluminavam to bem quanto os primeiros. Esse princpio foi empregado no apenas
nos faris, mas no design, no desempenho, no espao interno e o resultado foi um au-
mento espetacular nas vendas, na receita e, pasme, na satisfao dos clientes. E mais:
a melhoria contnua passou a se concentrar em um ajuste fno entre um atendimento
cada vez mais prximo dos desejos dos clientes e os custos de produo, o que parece
bvio, mas simplesmente a frmula mgica para a prosperidade nos negcios. O que
nos leva a um conceito de qualidade ligado sustentabilidade do negcio, que contin-
uamente se ajusta para:
Atender aos clientes em termos de preo e adequao s suas necessidades e ex-
81
pectativas;
Estabelecer uma relao coerente entre preo e custo;
Isso signifca que qualidade no uma referncia absoluta, mas uma relao entre
preo e expectativa! A pergunta natural que se segue : porque ento precisamos de
referncias como os sistemas de qualidade ISO 9000, 20000, 27000, etc? A resposta
simples: para que serve uma referncia de qualidade sem uma estrutura de acom-
panhamento e ajuste? Implementar um sistema de qualidade no defnir padres ab-
solutos, mas estabelecer os pontos de controle necessrios para que os produtos e
servios entregues estejam dentro das faixas de qualidade defnidas. 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. Especifcamente
para servios de TI, o sistema de qualidade ISO 20000 mostra o mnimo necessrio (e
tambm o desejvel) para que um servio seja entregue de acordo com os acordos e
expectativas dos clientes, sejam l quais forem estas expectativas. E justamente a
que entra a iluso de sistemas de qualidade mal implementados. Se uma empresa for
certifcada como aderente ISO 20000, mas:
No defnir sua faixa de qualidade de forma coerente e sustentvel;
No implementar um sistema gerencial que leve a srio as referncias de qualida-
de e REALMENTE promova os ajustes necessrios continuamente;
No quebrar as barreiras e silos organizacionais com seus prprios e peculiares
conceitos de qualidade;
No promover uma viso de servio em sua organizao, fazendo das expectativas
e necessidades dos clientes sua principal referncia na busca pela excelncia.
.....ento, a certifcao ISO 20000 ser mais um belo quadro pendurado em sua pare-
de.
E tenho dito!
82
USMBOK o ITIL para gerenciamento de qualquer
servio
REN CHIARI
Enquanto a ITIL vem evoluindo do contexto de infraestrutura de TI para servios de TI,
o USMBOK faz o caminho contrrio, partindo do negcio.
sabido que os conceitos preconizados pelas boas prticas de gerenciamento de TI,
particularmente a ITIL, poderiam ser aplicveis em qualquer outro contexto de geren-
ciamento de servios. E quando eu digo outro contexto, me refro a servios no-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 refexes e mtodos do gerenciamento de servios, uni-
versalmente aplicveis a qualquer empresa de servios, incluindo uma organizao de
TI que gerenciada como um fornecedor de servios. Com seus conceitos e mto-
dos enraizados no gerenciamento de produtos, universalmente aplicvel em todos
os setores de servios e tambm pode atuar como um mtodo de transformao para
qualquer organizao que queira mudar e operar como um prestador de servios, es-
pecialmente em uma organizao de TI.
A base para o USMBOK e como ele aborda o gerenciamento de servio est profun-
damente enraizada nos conceitos de gesto 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 defnio de gerenciamento de servios e os elementos da estrutura de
gerenciamento de servio detalhados no USMBOK so elaborados a partir de refex-
es sobre a gesto de negcios. 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 organizaes de TI. Nas mais
recentes atualizaes amadureceu para um modelo de processo com foco no gerenci-
amento de ciclo de vida de um servio, o que um bom sinal.
Minha opinio que, em algum momento, USMBOK e ITIL podero ser referncias
complementares. Uma partindo dos padres da indstria 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
Artgos para Aquecer a Carreira
84
Certifcaoes abrem portas mas no garantem o
seu emprego
REN CHIARI
A verdade que as certifcaes vo dar destaque ao currculo, e em muitos casos sero
de fato o passaporte para um emprego. Mas uma coisa conseguir um emprego, a out-
ra se manter nele. Para isso sero necessrios mais que papis com chancelas, PINs
e assinaturas bonitinhas. Competncias e habilidades pessoais devero ser demon-
stradas no dia a dia.
Antes de entrar em uma bela enrascada, recomendo refetir sobre os seguintes pontos:
1. Antes de se candidatar a uma vaga, procure entender quais sero suas atividades,
a sua rotina, principalmente se voc estiver mudando de uma funo tcnica para
uma funo de gesto. Em alguns casos a mudana bem agressiva e vai exigir al-
guns meses para adaptao. Levei trs meses para aterrissar e entender o que de
fato eu estava fazendo naquela funo quando migrei da rea tcnica para a rea
de gesto. Corri um risco enorme pois no consultei ningum antes. No cometa o
mesmo erro.
2. Seja prudente, no minta. Assumir coisas que nunca fez e depois fcar com uma
tremenda saia justa por no ter a minma ideia de como realiza-las pode custar o
seu emprego, e pior, a sua reputao. O mundo de TI muito pequeno, no vale a
pena correr este risco. Se voc tem apenas um certifcado na mo e nenhuma ex-
perincia, v em frente. Muitas empresas preferem contratar profssionais mais
crus e transforma-los nos moldes da empresa.
3. Evite passar a imagem de sabe-tudo. Quando acumulamos um certo nmero de
certifcaes e experincia prtica tendemos a achar que conseguimos lidar com
todos os desafos facilmente. No caia nessa. Me recordo de no mnimo trs mo-
mentos da minha carreira onde conclui que no sabia nada de ITIL. Manter a hu-
mildade e estar sempre aberto a novos pontos de vista uma boa forma de no
prejudicar um projeto importante e como consequncia ser convidado a procurar
outra empresa.
4. Por ultimo e no 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 no foram poucas mudanas. Estar atualizado pode ser o pulo do gato e garantir
os poucos centsimos de pontos que o classifcam em uma seleo de emprego.
Alm disso, a vivncia prtica de outros pode servir como bagagem para futuros
desafos em sua carreira.
Bem, mas se voc leu este artigo at aqui, ou acompanha as discusses no LinkedIN e
outros fruns sobre o assunto, ento j sinal de que essa dica voc j considerou! ;-)
85
Redes Sociais: 5 erros a serem evitados no LinkedIN
REN CHIARI
Eu costumo separar as redes sociais em dois tipos: as sociais pessoais e as sociais profs-
sionais. Das profssionais, fco com o Linkedin sem sombra de dvidas. Alm 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 profssionais de TI, que acabam crian-
do alguns jarges totalmente desnecessrios e acabam banalizando funcionalidades
bacanas dentro do Linkedin. Ai vo as principais atitudes que devem ser evitadas:
Assinatura Sopa de Letrinhas - Voc j deve ter visto alguns profssionais que in-
corporam ttulos conquistados em seus nomes. Por exemplo: Zezinho, PMP, ITIL,
CISA, CISM, Black Belt...alm de ser uma tremenda poluio visual, mesmo que
tenha boas intenes voc pode ser considerado um mala.
Que tal ser um pouco mais discreto? O Linkedin permite que voc adicione suas espe-
cializaes em seu perfl. Alm disso, j existe um app chamado box.net que permite
que voc insira arquivos ao seu perfl. Inserir os seus certifcados em PDF em uma past-
inha discreta fca muito mais profssional.
Caador de Recomendaes - As recomedaes so extremamente importantes
aos olhos de recrutadores e possveis parceiros de negcio. Nada como ganhar
aquela recomendao de seu ex-gerente ou de um Cliente. Mas cuidado com os
exageros, tenha sempre em mente que uma boa (e sincera) recomendao vale
mais do que 30 recomendaes estilo Linha de produo. a mesma coisa que
vender alfnete de plastico no leilo online s pra ter um nmero maior de qualif-
caes positivas.
Cuidado com a auto-promoo - sempre interessante anunciar uma nova con-
quista profssional, seja uma certifcao, um novo emprego, etc, mas importan-
te ter bom senso nessas horas. Fazer da rede uma espcie de Twitter e comentar
cada passo de sua vida profssional pode tornar a leitura de suas notas cansativas,
e mais uma vez, voc corre o risco de virar o mala. O Linkedin tem sees muito
bem diferenciadas para que voc divulgue uma novidade, uma atualizao de seu
perfl, uma nova discusso 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 perfl em um processo seleti-
vo. O que? Acha mesmo que as empresas de RH no 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! ;-)
86
Obs: j ouvi vrios casos de contrataes para cargos executivos onde a seleo foi fei-
ta atravs do Linkedin. Vale a dica!
Use o Linkedin estritamente para fns profssionais - A proposta da rede social
muito clara: uma rede social voltada para profssionais! 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 confgurando a privacidade do seu
perfl e evitar futuros constrangimentos, por exemplo, o seu chefe recebendo uma
atualizao do seu Facebook informando que voc acabou de atacar uma mfa,
em pleno horrio de expediente...
Com estes pequenos cuidados voc garante um perfl clean e atraente em uma das re-
des sociais voltadas a profssionais mais promissoras da atualidade.
J tem uma conta no Linkedin? Ento aproveite para visitar e fazer parte do grupo
ITIL na Prtica
87
Tirei a certifcao ITIL e agora?
GUSTAVO TAVARES
Antes de qualquer coisa Parabns. Se vc possui uma certifcao ITIL voc comprovou,
por meio de um sistema de avaliao confvel, que possui os conhecimentos necessri-
os para implantar e gerenciar as prticas do ITIL em uma organizao. Existem, cla-
ro, diferentes nveis de conhecimento. Um profssional com uma certifcao de funda-
mentos no possui as mesmas comprovaes de conhecimento do que um profssional
certifcado como ITIL Manager. Mas a despeito do nvel de conhecimento, ambos so
profssionais preparados para implantar e gerenciar o ITIL em uma organizao? No
necessariamente...
Antes de responder diretamente esta pergunta, me permita buscar auxlio nas teorias
modernas de recursos humanos. Nestas teorias existe um conceito muito relevante
que o conceito de competncia pessoal. Uma competncia pessoal pode ser enten-
dida como um atributo de determinado profssional que o possibilita atingir determi-
nado objetivo. Ao dizermos ento que um profssional possui preparo para implantar
e gerenciar o ITIL em uma organizao estamos tambm dizendo que o profssional
possui a competncia 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 so as competncias.
As competncias so atributos do profssional compostas de trs elementos: conhec-
imentos, habilidades e atitudes. Cada competncia possui uma diferente combinao
dos trs elementos. E os trs elementos devem, obrigatoriamente, estar presentes para
que um profssional possa ser possuidor de determinada competncia. As certifcaes
profssionais, sejam acadmicas ou emitidas por instituies de classe, comprovam
que um profssional possui os conhecimentos exigidos para exercer determinada ativ-
idade. Mas elas no comprovam que o profssional possui as habilidades ou atitudes
necessrias para atingir os objetivos relacionados quela atividade. E no teria como
ser diferente. As habilidades e atitudes relacionadas a uma competncia so direta-
mente relacionadas ao contexto onde a competncia ser aplicada. Embora os conhe-
cimentos tenham um carter mais universal, as habilidades e atitudes para aplicar os
conhecimentos em um ambiente militar so totalmente diferentes das habilidades e
atitudes necessrias para aplicar os conhecimentos em um ambiente privado. Mesmo
em um ambiente privado (ou militar) as especifcidades de uma organizao exigem
habilidades e atitudes diferentes de outra. Criar um sistema de avaliao que seja ca-
paz de medir habilidades e atitudes de forma padronizada um exerccio que tende
ao fracasso, seja por questes metodolgicas ou por questes de abrangncia de situ-
aes possveis.
Desta forma, voc que um profssional certifcado em ITIL precisa descobrir quais
habilidades e atitudes so necessrias para obter sucesso na implantao e no geren-
88
ciamento de processos baseados no ITIL e deve se preocupar em desenvolver esta
competncia. O certifcado foi o seu primeiro passo; existem outros a frente. E se quer
saber, os prximos no sero to fceis como foi a certifcao. A parte ruim que vc
no vai conseguir uma lista de todas as habilidades e atitudes que so necessrias para
adquirir ou desenvolver sua competncia. Isto porque esta lista no existe. Como j
falamos, cada ambiente ou situao 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 gesto de operaes de TI, temos um conjun-
to de papis que so defnidos no framework. E na maior parte estes papis j trazem
um conjunto de habilidades e atitudes relacionadas. Mas e as habilidades e atitudes do
profssional que vai implantar e gerenciar uma iniciativa de adoo do ITIL? Eu tenho
alguns palpites sobre as habilidades necessrias:
1. Deve saber ouvir e interpretar as pessoas: iniciativas de adoo do ITIL envol-
vem mudanas na maneira de trabalhar das pessoas. Mas o modo atual de traba-
lho de uma organizao no ruim simplesmente porque no aderente ao ITIL.
Na verdade, existem inmeros casos onde o modelo de trabalho atual melhor
do que o prescrito no ITIL. Um profssional com competncias de implantao e
gerenciamento de iniciativas de ITIL deve ser capaz de ouvir as restries e re-
clamaes das pessoas envolvidas e deve ser capaz de avaliar quando as prticas
atuais so mais adequados ou mesmo melhores do que as prticas prescritas no
ITIL;
2. Deve ser capaz de entender o contexto da organizao: iniciativas de adoo do
ITIL ocorrem em um ambiente cheio de restries e infuenciadores. As pres-
cries do ITIL so perfeitas para serem aplicadas ipses literis em um ambiente
perfeito. Ambientes imperfeitos exigem adaptaes das prescries s limitaes
e infuenciadores existentes. Um profssional com competncia em implantao e
gerenciamento de iniciativas de ITIL deve ser capaz de interpretar estas limita-
es e descartar prescries do ITIL que no sejam compatveis com a organiza-
o;
3. Deve ser capaz de imaginar solues alternativas: Como j conversamos, existem
inmeras restries e infuenciadores determinando como uma iniciativa de ado-
o do ITIL evolui. Em alguns casos estes limitadores chegam ao ponto de inviabi-
lizar a adoo de determinadas prticas fundamentais para o sucesso da iniciativa
como um todo. Nestas situaes, o profssional com competncia em implantar e
gerenciar iniciativas de ITIL deve conseguir formular solues alternativas que
garantam o sucesso do projeto mesmo que uma ou mais das suas partes crticas
tenham sido descartadas.
A lista pode continuar por muitos itens ainda. E olha que eu nem comecei a falar das
atitudes. Arrogncia, impacincia, falta de fexibilidade so algumas, por exemplo, que
no combinam com um profssional de ITIL. Na verdade, quando estas atitudes esto
89
presentes elas se tornam uma das causas do insucesso dos projetos. O pior so os ca-
sos em que um profssional, ao obter os conhecimentos e comprovar que possui estes
conhecimentos por meio de uma certifcao, se torna arrogante por conta do novo
ttulo e passa a levar seus projetos ao fracasso. Infelizmente ainda acontece muito.
Mas estas so as excees. Se vc se certifcou recentente, desejo sucesso no desenvolvi-
mento da sua competncia em implantar e gerenciar iniciativas baseadas no ITIL. Se
vc j se certifcou h mais tempo, tambm desejo sucesso no desenvolvimento de sua
competncia, porque esta uma atividade que no acaba nunca.
90
Vale a pena investir em certifcaoes profssionais?
CLAUDIA MARQUESANI
Um colega me perguntou um dia desses: o que mais importante para ter sucesso
profssional ser certifcado ou ter experincia prtica em gesto de servios?
Gostaria de falar um pouco sobre CARREIRA e a busca pelo sucesso
apenas uma opinio (extremamente pessoal), mas acredito que: o importante para
ter sucesso profssional ter COMPETNCIA para fazer aquilo o que voc se props.
O QUE COMPETNCIA?
COMPETNCIA = CONHECIMENTO + HABILIDADE + ATITUDE
CONHECIMENTO ter formao. Imaginem um mdico. Ele precisa do diploma univer-
sitrio para exercer a medicina. Precisa estar formado. Ter conhecimento investir em
uma boa universidade, em certifcaes, em cursos tcnicos, ps graduao, MBA, at-
ualizaes constantes que todos ns estamos cansados de saber que so necessrios,
mas que no so sufcientes por si s. E porque ser que sozinho CONHECIMENTO
no diz nada?
De que vale ter todo o CONHECIMENTO do mundo, se no tivermos HABILIDADE?
Quantas pessoas no passam anos estudando e quando se aventuram no mercado
de trabalho, no tem nenhuma experincia, nenhuma vivncia PRTICA para exercer
determinada funo. Como investiram na carreira durante anos (e esse investimento
sempre muito alto), querem o retorno imediato e muito difcil que isso acontea. Ns
investimentos muito tempo e dinheiro nessas formaes e o mercado de trabalho no
segue esse ritmo. No adianta achar que voc vai fazer a maior certifcao em ITIL
ou segurana e que com isso seu salrio dobrar. D para imaginar um mdico sem ha-
bilidade? Um mdico que no fez residencia? Um residente ganhando um salrio alts-
simo? Vamos com calma
Se voc tem CONHECIMENTO e HABILIDADE, meio caminho andado. Mas tambm
no sufciente. Durante um processo seletivo ou uma avaliao de promoo, sua
ATITUDE tambm ser avaliada. E digo com TODA CERTEZA DO MUNDO: s vezes
isso mais importante para quem ir tomar a deciso do que conhecimento ou hab-
ilidade. Atitudes so habilidades interpessoais, como por exemplo: a capacidade de
ser positivo diante de presses, a capacidade de trabalhar em equipe, sua resilincia
(trabalhar normalmente mesmo diante de situaes adversas) enfm, sua forma de
encarar o trabalho e de fazer dele algo positivo, construtivo e bem sucedido. Imagi-
nem o mdico que entra em pnico quando seu paciente, na sala de cirurgia , sofre uma
parada cardaca ? O que ele faz? Sai correndo? Comea a chorar? Ou toma a frente e
tenta ressuscitar o paciente? Essa diferena de comportamento se chama atitude!
91
Ento quando sou perguntada se vale a pena investir em certifcaes, eu respondo:
SIM!!!
Agora se me perguntarem se s isso sufciente, eu digo com toda certeza : NO!!!
preciso muito mais que um diploma colado na parede para ser um bom profssional.
necessrio ter CONHECIMENTOs, HABILIDADEs e ATITUDEs sufcientes para ex-
ercer sua funo . Eu realmente acredito que um profssional de sucesso aquele que
tem a sabedoria para equilibrar essas trs variveis.
Seja voc um deles. Comear a investir em si mesmo, alm de dar um prazer enorme,
aumenta a auto estima e as possibilidades de sucesso em sua carreira. Digo possibili-
dades, porque tem uma quarta varivel , uma coisinha que s vezes ningum se lembra
, mas que tambm pode fazer toda a diferena, A SORTE!
S que no vamos falar dela hoje porque est fcando tarde e eu quero curtir meu
feriado Mas que d um assunto para outro post, isso d! Pensem nisso!
Artgos Para Por a Mao na Massa
93
5 dicas para a Gesto de Problemas Proativa
REN CHIARI
Uma das principais atividades do processo de Gerncia de Problemas identifcar
tendncias, atravs do sub processo de gesto proativa de Problemas.
No dia a dia, esse conceito acaba se perdendo, pois a gesto de problemas acaba sem-
pre demandando quase 100% de seu tempo a identifcar a causa raiz dos problemas
relacionados a incidentes crticos (super reativos!). Isso se d de forma desesperada e
sob forte presso. A alta administrao exige que as causas e solues de contorno se-
jam identifcadas rapidamente e isso muitas vezes ocasionam respostas inefcazes, de
um processo onde tempo est diretamente relacionado a qualidade da investigao e
soluo proposta.
Ou seja, no sobra tempo para analisar tendncias de capacidade , de disponibilidade
e de incidentes recorrentes. Fica quase impossvel 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 anlise de problemas proativa podem ser:
Operacionais: ao analisar a tendncia de incidentes e identifcar que a soluo de
incidentes recorrentes ir benefcia 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 incndio).
O detalhe que isso acaba sendo um benefcio indireto para o negcio tambm. Por
exemplo: Imaginem que o Service Desk gasta aproximadamente 10% de seu tempo, em
uma pequena empresa, resolvendo incidentes em primeiro nvel de senha bloqueada.
A gerencia de problemas poder investigar a causa raiz desses incidentes e resolve-los
defnitivamente. Com isso sobra mais tempo para o Service Desk atender ligaes,
maior disponibilidade para o usurio, aumento da efcincia e refexo na satisfao do
usurio e do negcio.
Negcio: quando uma anlise de tendncias inibem e previnem incidentes que po-
deriam vir a acontecer e trazer impacto direto ao negcio. Por exemplo: junto com
a disciplina de gerenciamento de capacidade, utilizar ferramentas para a identif-
cao de tendncias e atuar para evitar que incidentes relacionados a capacidade
ocorram.
A seguir, listo algumas sugestes para implementar esta atividade:
1. No simples fazer uma anlise proativa de problemas. Identifque as disciplinas
parceiras:
94
- Incidentes poder apresentar tendencia de incidentes recorrentes que devero
ser investigados pela gesto de problemas.
- Disponibilidade poder identifcar tendncias de issues relacionados a disponi-
blidade e atuar em conjunto com o gerenciamento de problemas para solucio-
n-los.
- Capacidade tambm possui tcnicas para que issues de capacidade sejam iden-
tifcados e poder contar com a gerencia de problemas para trat-los.
Lembre-se : a gerencia de problemas sozinha no nada. um processo extremamente
dependente dos outros.
2. Defna os papeis e responsabilidades. Escolha sempre os tcnicos mais experien-
tes, que conheam muito bem tanto o ambiente quanto o negcio 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. Defna o que voc quer fazer (e o que j consegue imediatamente) , a metodolo-
gia e periodicidade. Far uma anlise de incidentes recorrentes? Uma anlise de
tendncias de relatrios de capacidade? Uma anlise de issues de disponibilida-
de? Ser aplicada alguma tcnica ou metodologia especfca? Sero feitas reunies
com as equipes tcnicas para discutir os problemas? Quantas vezes? Qual ser o
meio de comunicao?
4. Defnir quais sero os controles de performance e resultados desta atividade. De-
fna alguns controles para saber se as atividades esto sendo desempenhadas sa-
tisfatriamente, e se os resultados esperados esto sendo atingidos. Ex: % de re-
duo de incidentes recorrentes , # de incidentes evitados atravs da investigao
e soluo defnitiva de problemas.
5. A quinta e principal dica : No acelere o processo e defna equipes separadas para
a gesto proativa e reativa de problemas. A gesto proativa de problemas precisa
de tempo para investigar, analisar cada varivel envolvida no processo. A gesto
reativa sofre presses para explicaces e solues , sejam elas de contorno ou de-
fnitivas. O tempo da gesto de problemas reativa mais curto, infelizmente. Se as
duas equipes tiverem o mesmo papel dentro de uma organizao, a gesto de pro-
blema proativa simplesmente fcar em segundo plano e deixar de ser feita.
95
5 passos para defnir um bom Acordo de Nvel de
Servio SLA
REN CHIARI
Apesar do SLA ter se tornado um jargo bastante conhecido e utilizado, comum en-
contrar documentos mal escritos, com falta de informaes e defnies confusas at
para o prprio provedor de servios. Isso no bom nem para o provedor, e nem para
o cliente, pois d margem para discusses que podem comprometer o bom relacion-
amento entre as partes, e em casos mais graves at causar uma resciso contratual
(no caso de provedores de servio externos) ou a deciso pelo outsourcing (no cado de
provedores de servio internos).
preciso entender que um acordo de nvel de servio muito mais do que um docu-
mento descrevendo prazos de atendimento e resoluo de chamados. Trata-se de um
acordo que deve deixar claro todas as garantias que o provedor de servio oferece em
relao aos servios que foram contratados, e a forma como estes nveis de servio
sero medidos, reportados e melhorados continuamente.
Para resumir: o (bem) combinado no 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 comeo. L na ITIL
(Service Design) voc vai encontrar um modelo bastante robusto de um Acordo de
Nvel de Servio. O que eu estou sugerindo adiante uma abordagem mais simples e
realista.
Pergunta 1: O que?
Qual o servio que est sendo objeto deste acordo? Contextualizar o servio j no
primeiro captulo uma boa pedida. Aqui tambm pode-se fazer referncia ao Catlo-
go de Servios.
Importante incluir as excluses, que so as situaes em que este acordo de nvel de
servio no aplicvel. Isto evita uma srie de aborrecimentos futuros. Um dos assun-
tos mais comumente esquecidos o Stop SLA (ou pausa no SLA), onde so consider-
ados os perodos em que os casos esto sob tratamento de suporte do prprio cliente,
ou seja, o provedor de TI no deveria assumir o nus por este perodo de tempo.
Pergunta 2: Quando?
Quando o servio deve ser fornecido? Deveria ser includo no mnimo, o percentual de
disponibilidade do servio, o horrio do servio (perodo em que deve estar disponvel,
por exemplo: em horrio comercial, 24x7, etc), o horrio do suporte ao servio (Service
Desk por exemplo). Importantssimo tambm considerar condies de exceo, como
feriados, fnais de semana, etc.
96
Pergunta 3: Quanto?
Esta pergunta no tem relao com valor a ser pago pelo servio, que normalmente j
defnido no Catlogo de Servios, e sim em qual quantidade e com qual desempenho o
servio ser entregue. Ou seja, requisitos de capacidade.
Pode-se incuir por exemplo: Taxas de resposta, nmero mximo de transaes si-
multneas, usurios concorrentes, etc.
Outra boa sacada considerar lotes e franquias de requisies de servios. Por ex-
emplo: considerar um lote mximo de requisies simultneas do tipo X. Caso a quan-
tidade ultrapasse o limite, ser necessrio como uma mudana (exige aprovao e um
projeto associado). Em outros casos possvel acordar cobrana adicional quando a
franquia de requisies for atingida, como forme de infuenciar o comportamento dos
usurios.
Pergunta 4: Como?
Talvez este seja o captulo mais extenso, e com direito a incluir alguns tpicos:
Papeis e responsabilidades
Uma boa prestao de servio exige que no somente o provedor, mas tambm o cli-
ente, cumpram alguns deveres. Se engana quem acha que o cliente (e os usurios) no
tm responsabilidades.
Suporte ao Cliente
Neste tpico, algumas informaes importantes como os possveis canais de contato
do cliente com o Service Desk, os tempos de resposta para cada tipo de caso de acordo
com os critrios de priorizao, matriz de escalonamento, etc, podem ser includas.
Reporte e anlise crtica do servio
A maioria dos Acordos de Nvel de Servio no deixam claro a periodicidade e a forma
como os nveis de servio sero medidos, reportados, analisados criticamente junto ao
Cliente e continuamente melhorados. Este momento uma excelente oportunidade
no s para identifcar os pontos falhos na entrega de servios, mas tambm oportuni-
dades de novos negcios. Vale lembrar que este item , inclusive, um requisito da nor-
ma ISO/IEC 200000.
Canal de Reclamao
Seja l qual for o nome mais adequado: ombudsman, ouvidoria, etc. O importante
mencionar um canal onde o cliente possa reclamar caso no esteja satisfeito com o
servio, e garantir que ser dado um tratamento adequado a esta reclamao.
Pergunta 5: E se der $%@&... ??
97
Como dizem os americanos: coisas acontecem...
O provedor deve estar preparado para imprevistos de grande magnitude. O Acordo
de Nvel de Servio pode deixar claro para o Cliente a existncia de um plano de con-
tinuidade, ou consideraes que evidenciem que o provedor gerencia os riscos de seus
servios, endereando respostas adequadas para cada um deles.
Ao ler este artigo, defnir um Acordo de Nvel de Servio pode parecer fcil mas est
longe disso. Estes so apenas alguns dos ingredientes bsicos de uma atividade que
leva tempo, e muita discusso.
98
25 dicas infalveis para que seu projeto de
implantao da ITIL seja um fracasso
CLAUDIA 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 incrveis que podem fazer com que qualquer projeto de gesto
de servios afunde. So elas:
1. No trate o projeto como um projeto. No utilize nenhuma metodologia para
acompanhamento. Implementar gerenciamento de servios em uma organizao
fcil, rpido e nem precisa de muito esforo. 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 negcio. Voc est gerenciando
servios de TI - nada a ver com o negcio!
4. No envolva o cliente na defnio de critrios de qualidade. Qualidade voc
que sabe o que , afnal voc O CARA de TI! Pensando bem, critrios de qualida-
de... quem precisa deles?
5. Comece o processo de gerenciamento de servios , sem ter claro o entendimen-
to do que realmente um servio 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 fnanceiros em segundo
plano (afnal, qualidade o que interessa, o resto no tem pressa).
7. Coloque um Z Ningum (tipo este com cara de perdido da fgura ao lado) para
ser gerente de nvel de servios.
8. Coloque um gerente fnanceiro que no entenda de TI ou vice versa, um gerente
de TI que no entenda de fnanas.
9. No invista em treinamentos: Faa somente um treinamento quando o processo
entrar em produo. Afnal, treinamentos so direcionados a pessoas e a parte im-
portante mesmo da ITIL so os processos e as ferramentas.
10. No comunique as pessoas na profundidade e abrangncia necessrias: campa-
nhas de conscientizao para que todos saibam o valor agregado de um bom ge-
renciamneto de servios completamente opcional. Um luxoooo!
11. Avise que os ganhos demoooooooram para aparecer.... no defna quick wins,
porque essa palavrinha em Ingles muito difcil de ser lembrada.
12. Escreva todos os processos pensando em entreg-los rapidamente. Afnal , 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.
99
14. Como complicado confgurar ferramentas, comece pela confgurao delas an-
tes de defnir adequadamente o processo.
15. Todos os processos devem emitir relatrios, mas quanto mais eles tiverem ter-
mos tcnicos e complexidade, mais isso mostrar o valor agregado de TI. Afnal,
o cliente sabe tudo de TI, n?
16. Ache que processos ITIL so procedimentos que indicam como as pessoas de-
vem executar suas tarefas dirias.
17. Utilize exatamente os fuxogramas sugeridos pela ITIL, assim vc no corre o ris-
co de alguem falar que vc no est em Compliance.
18. Adote e adapte. Pode adaptar a vontade. Faa adaptaes at no entender mais
qual era a proposta inicial. Afnal a ITIL diz: ADOTE E ADAPTE.
19. Se estiver difcil defnir um dono para um processo, divida em duas bolas: assim
voc vira o amigo da galera.
20. Desenhar processos, mas seguir a regra de quem grita mais alto ou quem seu
amigo ou quem tem mais infuncia para decidir o que fazer.
21. Desenhar um manual de processos lindo, mas to utilizado que no fnal ele vai
virar um suporte de um monitor velho. Legal, ergonomia tambm importante,
certo?
22. Melhoria contnua. Fcil.... Vamos promov-la baseando-nos em critrios obscu-
ros, que mudam a cada dia ou baseados simplesmente na intuio.
23. ITIL coisa S de Infraestrutura. Logo, sua equipe de desenvolvimento de soft-
wares ou fornecedores no tem NADA a ver com ITIL.
24. Achar que o presidente da sua empresa tambm no tem NADA a ver com ITIL.
Que raios ele tem que abrir chamado no service Desk? Para ele ns atendemos na
hora, sem prazos, sem classifcaes, sem processo! Afnal, ele VIP.
25. Controlar o processo e esquecer do servio. As vezes o trabalho para manter um
processo to intenso que o servio e sua qualidade fcam em segundo plano. Quem
nunca passou por isso?
Algum se lembra de mais alguma dica para o FRACASSO?
Se sim, vale a pena citar, porque na prtica tudo isso acontece e bom ser PREVINIDO!
Por isso to difcil ter sucesso na implementao do gerenciamento de servios...
Quem sabe eu no transformo as 25 dicas em 50?
100
Catlogo de Servios: Para que complicar?
CLAUDIO DODT
Nos projetos de gerenciamento de servios de TI em que participei um quickwin cer-
to sempre foi o catlogo de servios. Afnal, nada mais difcil que prestar servios aos
usurios sem que eles saibam o que h disponvel.
Mas por que criamos tanta difculdade em adotar essa ferramenta se isso algo com
o que 90% das pessoas tem um contato quase dirio? Qualquer pessoa que j foi a um
restaurante e pediu o velho e bom menu acabou de receber um catlogo de servios.
Um bom catlogo deve ser exatamente isso, uma lista dos servios prestados pela TI
funcionando da mesma forma que um cardpio de restaurante e permitindo que o for-
necedor de servios demonstre para seus clientes quais so as opes disponveis, os
modos como estas so entregues e, quando pertinente, os custos envolvidos.
Catlogo de Servios - apenas uma parte do portflio e deve ser controlado atravs
do gerenciamento do conhecimento.
Um ponto importante ao qual nem sempre damos a devida ateno separar o catlo-
go de negcios do catlogo tcnico e at mesmo da viso do usurio. Excesso de infor-
mao pode causar tanta confuso quanto falta da mesma.
Imagine explicar para um usurio que o correio eletrnico depende de vrios itens de
confgurao que vo desde um cluster de servidores, anti-spam, antivrus de borda,
banco de dados, roteadores, frewalls e assim por diante. Essas informaes podem
ser vitais para a equipe de suporte na hora de solucionar incidentes e problemas, mas
o usurio quer simplesmente saber como acessar o email.
As diferentes vises do catlogo de servios
Entender o negcio e equilibrar a quantidade de informaes correta que vai permitir
ao seu cliente utilizar o servio de forma adequada a receita de sucesso de um catlo-
go de servios efciente. Um bom exemplo pode ser visto nos produtos e servios da
Google, que foi desenhado de forma minimalista e extremamente efciente.
Catlogo de produtos da google - Viso do usurio
Outros modelos de catlogo bastante interessantes podem ser vistos aqui e aqui, com
diferentes graus de detalhamento, mas com certeza bastante efcientes para o seu p-
blico alvo, o cliente.
Uma boa dica, especialmente se voc no tem um sponsor, a metodologia KISS, com-
ece simples! Uma planilha no Excel se for bem organizada e divulgada pode se tornar
um excelente catlogo de servios.
Links e referencias:
101
www.google.com.br/intl/pt-BR/options/
www.itap.purdue.edu/service/catalog/alpha/
its.ucsc.edu/service_catalog/index.php
102
ITIL preciso saber vender
CLAUDIA MARQUESANI
Que o ITIL - este famosoconjunto de melhores prticas para prestao de servios
em TI -traz ganhos para a TI e para o negcio a longo prazo, isso a maioria sabe. A
maioria tambm tem conhecimento que isso acontece porque , o principal benefcio
do Gerenciamento de Servios tornar a TI mais alinhada aos requisitos de negcio.
Isso faz com que a rea de tecnologia da informao exera realmente sua funo den-
tro de uma empresa: que contribuir para que a organizao atinja seus objetivos de
negcio. Parece fcil falar, mas no fcil mostrar o ganho associado a implementao
do ITIL para uma organizao . S quem j tentou vender uma idia relacionada a
implementao de ITIL para altos executivos, tem idia da difculdade que mostrar
os benefcios e o valor agregado (fnanceiro??) de um projeto desse porte. O que fazer
ento para conseguir vender o ITIL para sua organizao?
Existem algumas dicas que podem ser bastante teis na implementao (e tambm na
venda) e espero contribuir para quem estiver passando por esta rdua fase.
So elas:
1. Identifque qual a VISO, tenha claro, em qualquer implementao, qual o real
OBJETIVO buscado e os ganhos que essa meta ao ser alcanada trar para seu ne-
gcio. No h vento favorvel para aqueles que no sabem para onde ir, mas voc
precisa tambm saber o que far (resultados que voc espera obter) quando che-
gar l!
2. Lgico, veja se esses OBJETIVOS so REALISTAS. No adianta dizer que ir imple-
mentar uma central de servios e que no primeiro ms reduzir 90% das horas de
trabalho da equipe de TI com solues em primeiro nvel 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 organizao!!!
3. Transforme a grande viagem da implementao, em pequenas viagens. Defna
GANHOS RPIDOS. Fica mais fcil dessa forma vender seu projeto. Quer rede-
senhar a infraestrutura para aumentar a disponibilidade de algo vital para seu ne-
gcio? Isso demora, no ? No seria mais rpido aplicar tcnicas da gerncia de
disponibilidade como o TOP (Technical Observation Post) para que em prazo cur-
tssimo alguma melhoria fosse visualizada? Devo esperar a implementao com-
pleta de um banco de dados de gerencia de confgurao (que pode demorar de 6
meses a 1 ano e meio , dependendo do tamanho da organizao) ou comear a ali-
mentar meu banco de dados por aquilo que mais vital para meu negcio? Faa a
implementao em fases.
4. Infelizmente no tem como fugir. O que toda organizao busca no fnal (a no
ser que seja uma ONG) LUCRO, DINHEIRO! A frase que voc ouvir : o que
103
eu ganharei ao investir meu dinheiro nisso? Porque eu deveria investir? Ento, se
voc deseja vender um projeto ITIL e ter segurana 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 tambm nesse as-
pecto (nem pessimista demais, nem otimista demais). Lembre-se: ganhos rpidos
tambm 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 situao atual. Ter
completo entendimento da real situao ir facilitar a implementao de qualquer
processo e de qualquer melhoria associada a ele.
6. Trace planos que o levaro at seu objetivo. Como voc CHEGAR AT L? Uma
dica: Identifque quais so os pontos vitais para seu negcio, onde esto as maio-
res oportunidades de melhoria e comece a implementao por eles. Por exemplo:
No existe ponto nico de contato? Os recursos de TI perdem horas de trabalho
ao ser interrompidos por usurios ? Que tal implementar uma central de servios
para os servios mais crticos para seu negcio, para aqueles que tero 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 no mede nunca conseguir saber se os ganhos esperados fo-
ram atingidos, quem no mede no consegue saber onde est, quem no mede
como se fosse um avio 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 Servios de TI
justamente a melhoria contnua. Caminhe sempre nesse sentido!
Enfm, espero ter ajudado aqueles que como eu, j tiveram alguma difculdade em en-
tender por onde comear, como defnir e obter ganhos rpidos e como mostrar o val-
or agregado do gerenciamento de servios para TI. O ITIL apenas um conjunto de
melhores prticas. Adote e adapte sempre utilizando o bom senso e acreditem: bom
senso no mercado atual deve ser guiado por trs pilares: tica, qualidade e RETORNO
FINANCEIRO! Este ltimo se vier depressa, melhor ainda!
104
Pessoas: o calcanhar de Aquiles na adoo da ITIL
ALBERTO ANDRADE
Todos sabemos que a implantao da ITIL pode trazer mais maturidade operacion-
al ao departamento de TI, agregando valor ao negcio e obtendo maior satisfao do
usurio. Tambm sabemos a necessidade de participao da rea estratgica da em-
presa para sucesso no envolvimento das reas. Estes e outros benefcios da biblioteca
so mais que conhecidos por ns, fis seguidores das boas prticas. Mas ser que ap-
enas treinamento, palestras e contedo terico so sufcientes para o envolvimento
da fora motriz da implementao, ou seja, as pessoas?
Implantei processos ITIL nas verses V2 e V3 do framework em alguns projetos em
que trabalhei e gostaria de dividir algumas experincias neste assunto. Quanto aos pro-
cessos, estes apresentam seu grau de difculdade, 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 prticas no so regras, portanto
podem (e devem) ser adaptadas, melhor se enquadra fome vontade de comer. Para
o desenrolar da prtica, o PDCA tambm no mero assunto de qualidade. Use-o com
sabedoria e seja feliz. A recomendao anterior vale para o quesito produtos (tecnolo-
gia) e parceiros, onde dadas as peculiaridades que merecem devida ateno, a metod-
ologia tende a ocasionalmente repetir-se, implantao aps implantao.
O assunto aqui o calcanhar de Aquiles de todas as minhas implantaes, o ponto da
entrega de servio de TI onde no h manual, nem regra, nem diretriz pr-determinada:
As pessoas. Asseguro sem hesitar que, em todo o processo de implementao, de to-
dos os projetos, o que demandou mais esforo e energia foi este pilar. Afnal, no por
menos. O ser humano complexo, tem comportamento instvel, tendncia individual-
ista e demanda constante motivao. Entendo ser este o alicerce mais frgil de toda a
implantao. O time tem que comprar a idia, antes de coloc-la em prtica. O que mais
tenho ouvido de pessoas envolvidas em projetos de ITIL so murmuraes de profs-
sionais que tem de parar seus afazeres para agregar processos que eles acreditam no
servirem pra nada. Desta forma, coloco abaixo alguns pontos que acho serem cruciais
para arrebatar o maior nmero de seguidores da biblioteca de boas prticas:
1. Necessidades satisfeitas no geram motivao: Esta uma premissa da motiva-
o humana. Agregar valor ao negcio importante para voc, gestor, talvez no
seja para o seu operacional, aqueles que vo colocar a mo na massa. Busque refe-
rncia em sites, revistas, vdeos e outros pontos. Deixe claro que o conhecimento
do framework importante tambm em termos de carreira. Converta o benefcio
para eles, gere o brilho nos olhos. Pode ser que o time ainda no esteja engajado
por estar pensando: Que vantagem Maria leva nesse tal de ITIL?
2. Gere viso de negcio: Este um complemento ao primeiro tpico. A equipe s
conseguir ver com seus olhos a partir do momento em que a maturidade neste
105
sentido tiver avano. Seus funcionrios s vo querer aproximar TI do negcio se
identifcarem algum sentido (e benefcio) em faz-lo.
3. Gerencie o overhead de trabalho: No 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 ps-implantao valer todo o esforo
aplicado nesta fase. Desta forma, use e abuse do discurso e argumentao e no
esquea: Motivao sempre.
4. Treinamento inicial bom, reciclagem melhor ainda: Geralmente, o treinamento
inicial em ITIL ministrado aps um workshop e palestra iniciais. Neste perodo,
muitos ainda esto desinteressados. Portanto, agende uma reciclagem, voltada
para os processos em implantao na empresa. Aborde casos de uso e situaes
prticas. Deixe que as pessoas dividam as suas experincias e tirem suas dvidas.
5. Defnir 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, defna (sempre alinhado estratgia de negcio) como
ser a entrega de servios futura. Assim, as pessoas sero norteadas por este ob-
jetivo.
6. Brainstorm peridico: As pessoas chave do processo no podem deixar de contri-
buir com idias, sugestes e criticas. Reserve tempo na agenda para a dissemina-
o de idias. Muitas coisas, certamente, voc no pensou.
7. Quick wins: Defna metas intermedirias e divida com todos (no s com seu che-
fe, entendeu?). Desta forma, todos sabero que a implantao tem obtido xitos
parciais.
8. Autoridade funciona, mas saiba que em algumas ocasies, o poder ser necessrio:
Se voc um lder infuente, 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 juzo. o tal do poder versus autoridade. O poder
pode ser entregue a qualquer um. Por defnio, qualquer chefe tem poder, mas
nem todos tem autoridade. Isso verdadeiro, no entanto, sabemos que o quadro
de funcionrios de qualquer empresa est repleto de ervas - daninhas. Portanto,
seja um grande lder, inspirador em seu discurso, apaixonado pelo que faz, dedi-
cado e atencioso com seus liderados. Vai funcionar pra maioria das pessoas. Pra
quem no funcionar, bem, j sabe...
9. Escolha um brao direito na equipe: Sempre haver aquele que vai comprar melhor
a idia, se dedicar mais e corresponder melhor aos processos ITIL. Tenha nesta
pessoa um termmetro da equipe como um todo. Desenvolva sua capacidade de
liderana e persuaso, este recurso ser muito til durante todas as fases da im-
plantao.
10. Ningum consegue entregar o que no tem: Se os lideres da sua equipe no com-
praram o ITIL, no vo conseguir vender aos demais. Infelizmente quanto a isso,
no tem remdio (se houver, algum me informe!). A disseminao de uma nova
cultura de trabalho, bem como a quebra de paradigmas tem que ser acompanha-
106
do e supervisionados no dia-a-dia, pois so 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 lderes j fzerem parte
do quadro de funcionrios, insista e s avance no processo quando tiver convico
do engajamento de 100% dos supervisores e coordenadores de equipe. Isso fun-
damental.
Evidente que o tpico pessoas por ser extremamente complexo, possui uma srie de
outros pormenores a serem tratados cautelosamente. Mas espero que os passos aci-
ma possam ser um bom incio para uma implantao menos confituosa e com maiores
ganhos.
107
Problemas como identifca-los?
REN CHIARI
Hoje quero trazer algumas dicas prticas de critrios para identifcao de problemas,
pois considero este um dos segredos de um bom processo de gerenciamento de prob-
lemas.
Seguem alguns dos critrios de identifcao mais comuns:
Incidentes graves. Via de regra, incidentes graves so aqueles que exigem uma
grande mobilizao de toda TI, envolvimento da SWAT da TI e so acompanha-
dos de perto pela Direo e Clientes. o tipo de incidente que deve ser evitado o
mximo possvel. A dica : gerar um problema para cada incidente grave.
Reincidentes ou eventos recorrentes. Falhas ou alarmes de monitorao de im-
pacto baixo/mdio e que ocorrem frequentemente consomem recursos desneces-
srios. Por exemplo, uma rotina que falha diriamente, exigindo 25 minutos de um
analista para intervir e concluir a operao. Ao fm do ms so 8 horas desperdia-
das. um dia de trabalho que poderia estar sendo dispensado em algo mais produ-
tivo. Uma sugesto seria: a cada 5 reincidentes/eventos do mesmo tipo, na mesma
semana, registra-se um problema.
Incidentes direcionados para equipes especializadas. No to 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
profssional de alto custo ($$) . Isso signifca que as equipes de primeiro atendi-
mento no tm informaes sufcientes para tratar este incidente. uma forma de
assegurar que as equipes de suporte especializado (ou fornecedores), no mnimo,
proponham solues de contorno (ou defnitivas) 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-
nifca ter incidentes classifcados e categorizados corretamente, garantindo assim en-
tradas confveis ao processo de gerenciamento de problemas.
108
Profssionalizando a gesto dos projetos de TI e
ITSM Parte I
ANDR BERNARDO
Quando falamos em boas prticas em gesto de projetos, podemos estar falando da con-
struo de um submarino, reforma de um apartamento, implantao de uma soluo
(software) de gesto de servios 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 operao, ongoing, relacionado a um ciclo de melhoria
continua. J um projeto tem inicio, fm e escopo bem defnidos.
Citando o PMBoK: Projeto um esforo TEMPORRIO empreendido para criar um
produto, servio ou resultado EXCLUSIVO. (PMBoK 4a ed. Pag. 05)
Dito isto, e pensando em melhorar nossas a qualidade dos projetos de TI e ITSM, que
tal iniciar um pacote de discusses sobre BOAS PRATICAS EM GESTO DE PROJE-
TOS?
Ento, como diria o sbio, 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 servio)
2. Demanda regulatria ou jurdica (Ex. Lei de atendimento do call center)
3. Necessidade organizacional (Ex. Melhoria de processos para reduo de custos
com impresso)
4. Avano tecnolgico (Ex. Atualizao de S.O. do parque de computadores da em-
presa para Win 8.0)
5. Solicitao de cliente (Ex. Implantao de um Service Desk exclusivo para projeto
de outsourcing)
6. Necessidade social (Ex. Projeto de reciclagem de material)
Com a necessidade identifcada, vale a pena checar se voc tem realmente um projeto
ou se uma demanda operacional nas mos. Reforando o que falamos logo ai acima:
Tem inicio e fm bem defnido?
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?
109
Ento voc tem um Projeto!
Vocs vero que em alguns casos a linha tnue entre um projeto e uma demanda op-
eracional, por isso importante voc ter regras defnidas na sua empresa sobre o que
pode ser considerado um projeto (Que precisar de um Gerente de Projetos e toda
uma estrutura de gesto para concluso das entregas) e o que deve ser um processo
(Que acontece rotineiramente e todos j sabem como fazer).
Que tal um exemplo?
Atualizao do Windows Vista para o Windows 7 um projeto?
Voc: Eu coloco o CD, digito o cdigo de registro, dou next, next, fnish e pronto. En-
to s uma ao, no um projeto.
Eu: Concordo com voc!
Eu novamente: Agora e se voc tiver que atualizar o Windows de toda organizao,
10.000 computadores e notebooks, na matriz e em 17 fliais espalhadas em 15 capitais
no Brasil e mais 2 fliais na Europa e Estados Unidos at o fnal do ano?
Entendeu? Mudou a complexidade, aumentou o risco e delimitou o escopo.
Voc ter uma rotina para ser executada, a atualizao de 10.000 computadores, porm,
voc ter que lidar com uma srie de restries que no teria se estivesse falando da
atualizao de apenas um PC.
Voc: Ok, agora como eu organizo isso para dizer que tenho um projeto?
Eu com cara de contedo: Boa pergunta! Com uma resposta looonga!! Que tal se eu
explicar em uma srie de 5 artigos? Projeto do inicio ao fm, onde teremos um artigo
para iniciao de um projeto, um artigo s para planejamento, um para execuo, um
para monitorao e um para encerramento?
Nesta srie, baseada no PMBoK e na PRTICA de gesto de projetos vamos descrever
de forma resumida os principais elementos necessrios para voc estruturar e entre-
gar o seu projeto com maiores chances de sucesso, e as interfaces que estas prticas
podero ter com as prticas de gerenciamento de servios. Afnal, da mistura de bons in-
gredientes, na dose certa, que temos uma bela refeio, concordam?
110
ITSM Parte II
ANDR BERNARDO
Dando continuidade a srie de artigos baseada no PMBoK e na PRTICA de gesto
de projetos, agora que voc j sabe que tem um projeto, precisamos comear a organ-
iza-lo de forma profssional.
O ciclo de vida de gesto de projetos tem 5 fases:
1. Iniciao,
2. Planejamento,
3. Execuo,
4. Monitorao e controle,
5. Encerramento.
A Iniciao 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 importncia deste documento NA PRTICA? Nele voc documenta importantes
defnies que sero seguidas do inicio ao fm do projeto. O Termo de Abertura do Pro-
jeto aponta o Alvo e quem sero os responsveis por apontar as fechas.
O que deve conter um Termo de Abertura do Projeto, no mnimo:
1. O Patrocinador ou Sponsor (Quem tem infuencia para promover o projeto na or-
ganizao),
2. O Gerente de Projeto (Responsvel por integrar o trabalho do projeto e agir como
facilitador do time. o principal responsvel 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 Capacitao, 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 identifcados (Voc dever identifcar e controlar riscos du-
rante todo projeto!!)
7. As Restries (O que restringe a realizao do projeto? Ex. disponibilizao de
equipe ou oramento)
8. As Premissas (Algo que vamos assumir como verdadeiro e que no geral, foge ao
controle do projeto. Ex. Premissa que o dolar no ultrapasse 2,50)
9. Os Indicadores - KPIs (Objetivo quantitativo - Pelo que ser medido o sucesso do
111
seu projeto? Aumentar a rentabilidade? Diminuir incidentes? Melhorar a disponi-
bilidade?)
Com este documento em mos, o Gerente de Projetos j tem autonomia para iniciar
a mobilizao do time de trabalho e iniciar a agenda de reunies para elaborao do
Plano do Projeto que falaremos no prximo artigo.
Se voc no sabe onde quer chegar, qualquer caminho serve! - Gato Risonho, Alice
no Pas das Maravilhas
Ento o papel deste documento formalizar aonde voc quer chegar. Assim voc traar
durante o planejamento o melhor caminho para chegar at l, aumentando suas chanc-
es de sucesso!
112
ITSM parte III
ANDR BERNARDO
Enfm, entramos no meu grupo de processos de Gesto de Projetos preferido. Plane-
jamento!!
Quando voc faz uma viagem de frias para um determinado lugar pela primeira vez,
voc tem uma determinada dinmica e uma forma de aproveitar o lugar, que talvez no
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 regio.
Esse o milagre que o planejamento faz por ns. Quando voc planeja bem uma ao
antes de execut-la, como se voc j tivesse realizado a tarefa uma vez (durante o
planejamento), ento, na segunda vez (execuo) 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 no podemos nos dar ao luxo do teste x acerto. A no ser que isso esteja
no planejamento, com os riscos mapeados, custos, critrios de qualidade, etc.
Todas as reas de conhecimento em projetos devero ter um planejamento acurado.
No consigo em um post entrar to a fundo quanto gostaria para falar de planejamen-
to, ento serei sucinto e focado nos principais fatores de sucesso.
Vamos ao planejamento!
1. Escopo
a. 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
no escopo do projeto.
b. Um projeto de sucesso o projeto que entrega tudo que foi solicitado e nada
alm do que foi solicitado. Por isso a importncia to grande deste tpico.
c. Projetos com uma delimitao de escopo pobre acabam virando os famosos
projetos sem fm.
2. Tempo
a. Outro item de extrema importncia nos projetos a delimitao de tempo do
projeto.
b. Durante este processo voc ir determinar quais atividades devero ser reali-
zadas, em qual sequncia, por quais recursos, com qual durao e determinar
113
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 oramento do projeto so entregas deste processo.
b. b. Voc dever considerar o custo para realizao das atividades previstas para
cumprir o escopo, alm de uma margem de contingencia que deve ser atrelada
a algum risco identifcado no planejamento.
4. Comunicao
a. 90% do trabalho do gerente de projetos comunicao, ento este item tam-
bm deve estar muito bem planejado.
b. Voc deve considerar aqui, principalmente, as expectativas das partes interes-
sadas em receber informao 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-
ro 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 Humanos
a. a. Projetos so feitos por pessoas e se as mesmas no estiverem engajadas com
o trabalho o resultado ser medocre.
b. b. Neste processo voc ir planejar como lidar com as questes de RH do proje-
to.
c. c. Como ser o relacionamento hierrquico entre o grupo? Como manter o pes-
soal motivado? Como acelerar a sinergia da equipe?
7. Aquisies
a. Muitas vezes aquisies devem ser realizadas no projeto.
b. Neste processo voc determinar a forma de contrato, critrios de SLA, como
ser realizado o processo de compras, alm de delimitar o que ser comprado e
o que ser feito em casa.
8. Riscos
a. Outro processo de extrema importncia, que muitas vezes no recebe a devida
ateno de muitos gerentes de projeto.
b. Neste processo voc far o exerccio de prever tudo que pode dar errado no
projeto, classifcar estes riscos de acordo com o impacto do mesmo, a probabili-
dade dele acontecer e estabelecer um plano de ao para os riscos classifcados
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.
114
Lembre-se, seja o projeto viagem, projeto casamento, projeto casa nova, ou projeto de
implantao do sistema de reatores nucleares, quanto melhor for o seu planejamento,
maiores a chance de garantir o sorriso nos rostos de todos os envolvidos.
115
Tempo para solucionar problemas: mais um
problema ou a soluo?
REN CHIARI
A teoria clara:o foco principal da gerncia de incidentes resolver o mais rpido pos-
svel, enquanto o foco principal da gerncia de problemas resolver defnitivamente.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 difculdade na diferenciao entre o que um Incidente e o que um Problema.
Na verdade este pode ser considerado um paradoxo, j que a gerncia de problemas
precisa de um tempo maior para conseguir fazer uma anlise estruturada de um prob-
lema e com isso estabelecer uma soluo defnitiva. Mas na prtica, sabemos que no
estabelecer controles de tempo para problemas pode ser um risco, j que as equipes
no iro se preocupar com algo que no tenha um deadline.
O desafo justamente equilibrar velocidade x efetividade. Para Eduardo Abrileri, Team
Leader de Problem Management da IBM do Brasil, a introduo de prazos para identi-
fcao de causa raiz de problemas trouxe resultados positivos ao processo:
Aps a implementao de um tempo mximo para identifcao de causa raiz, observamos
que o nmero de problemas com a causa raiz identifcada aumentou em 35%. Essa melhora
ocorreu porque passado algum tempo, as evidncias do problema podiam ser perdidas (logs
sobrescritas, envolvimento do tcnico em outro incidente e perda de histrico), impedindo a
identifcao da causa.
Abrileri complementa que o ndice de comprometimento dos tcnicos na atuao em
problemas melhorou, pois com metas acordadas de atendimento a problemas, incluin-
do escalonamento para prazos rompidos, os tcnicos passaram a dar mais ateno aos
Problemas. O resultado de tudo isso veio em forma de feedbacks positivos de Clientes.
A ITIL faz uma recomendao para organizaes que tm 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
poltica clara de ateno e tempo de atendimento a problemas essa recomendao
seja vivel? NA PRTICA, o que realmente acontece?
Criamos uma enquete no site e uma discusso em nosso grupo do Linkedin para que
os leitores troquem experincias sobre este tema, que com certeza est no dia a dia de
todos que trabalham com suporte tcnico e gesto de servios. Participem!
116
Transformando sua poltica de segurana da
informao em um ativo estratgico
CLAUDIO DODT
Polticas de segurana da informao (PSI) so documentos estratgicos que defnem
as regras que devem ser observadas durante o uso da informao de uma organizao
com o intuito de resguardar tanto os pilares bsicos (Confdencialidade, Integridade,
Disponibilidade) como seus derivados (e.g. Autenticidade, No-Repdio, Propriedade).
Se voc j passou pela rdua tarefa de criar e manter uma cultura institucional de pro-
teo aos dados corporativos sabe que nada mais distante da idia de simplesmente
baixar um modelo da internet (sim, existem muitos e alguns com razovel qualidade)
que a aplicao de regras de segurana em um ambiente vivo, em que segurana da in-
formao muitas vezes percebida pelos usurios, gestores ou mesmo diretores como
simples burocracia ou at um empecilho ao negocio.
A elaborao de uma PSI efciente requer um grande nvel de clareza, especialmente
no quesito alinhamento com os objetivos do negcio. Entretanto, mesmo uma poltica
efciente no passa de um apanhado de material impresso ou disponibilizado na pgi-
na institucional se no for bem utilizada no dia-a-dia.
Os oito passos a seguir podem ajudar bastante na hora de transformar sua PSI em um
ativo estratgico efciente, alinhado ao negcio e que vai ser muito mais efciente em
proteger as informaes corporativas e, dependendo do caso, bem at o seu empre-
go :)
Vamos lista:
1. Segurana da informao no Tecnologia da Informao
Algumas vezes os termos acima so confundidos como sinnimos, e isto pode preju-
dicar drasticamente um projeto de PSI. Muitas vezes a mesma informao tem a ca-
pacidade de ser apresentada em diversos formatos diferentes, sejam estes eletrnic-
os, fsicos ou at mesmo armazenados no conhecimento dos nossos colaboradores. De
acordo com a ISO 27002 Seja qual for a forma apresentada ou o meio atravs do qual
a informao compartilhada ou armazenada, recomendado que ela seja sempre
protegida adequadamente.
Criar uma PSI exclusivamente para TI pode ter como conseqncia um escopo perigo-
samente mope. A ISO 27001 oferece 133 controles em seu Anexo A e basta uma rp-
ida anlise para chegar a seguinte concluso:
Relacionados TI: 46%
Relacionados organizao/documentao: 30%
117
Segurana fsica: 9%
Proteo jurdica: 6%
Relao com fornecedores e compradores: 5%
Gesto de recursos humanos: 4%
Um projeto de PSI que um esforo apenas de TI esta fadado a enfrentar uma grande
resistncia dos demais setores. Entender quais so as reas crticas e pessoas chave
bem como seu funcionamento em conjunto essencial na defnio do que segurana
da informao para sua organizao.
2. Obtenha o apoio da alta direo
O famoso apoio da alta direo um fator crucial para o sucesso de qualquer projeto
que pretende uma mudana signifcativa na cultura institucional. J vi vrios projetos
onde uma poltica j concluda era apresentada pela TI para a diretoria. Geralmente o
documento era imediatamente aprovado e sistematicamente guardado em uma gave-
ta trancada no poro mais escuro da organizao.
Sem um sponsor de alto nvel a fora do projeto da PSI pode ser completamente mina-
da. Neste momento surgem os usurios que no sabem criar uma senha complexa ou
que garantem que o seu email pessoal ou um IM pblico so essenciais para seu tra-
balho e ai comeam a surgir s excees que em pouco tempo se tornam a regra.
Um ponto muito importante e exposto de forma excelente no artigo Desmistifcando o
apoio da alta direo entender quem realmente so as pessoas chave, os tomadores
de deciso e especialmente quem vai fcar do seu lado quando a coisa comear a fcar
feia!
3. Converse com o negcio
Conforme previamente mencionado, um projeto de PSI de sucesso difcilmente um
esforo apenas da TI. Conversar com as demais reas e at mesmo criar um comit de
segurana multidisciplinar traz uma viso muito mais ampla, imparcial e alinhada aos
objetivos de negcio da organizao.
Alm disso, geralmente tira de TI o estigma de vilo da histria. Pense nisso!
4. Adote uma postura formal
A poltica de segurana da informao normalmente um documento de distribuio
apenas interna ou que encaminhada para clientes e fornecedores. Obviamente es-
sencial que este documento seja de fcil entendimento, mas isso no requer uma abor-
dagem informal.
118
necessrio lembrar que a PSI um contrato entre a organizao e os usurios da in-
formao e que muitas vezes pode ser levada perante ao judicirio. Diferenas sutis
em termos como, por exemplo, correio eletrnico ou e-mail podem ter implicaes ju-
rdicas inesperadas.
A PSI um contrato e deve seguir uma postura formal, clara e no deixar espaos para
dvida. Nesse momento pode ser importante o apoio de seu departamento legal ou
mesmo de uma consultoria jurdica especializada.
5. Atenha-se a sua realidade, mas pense no futuro
Obviamente sua PSI no ser talhada em mrmore. No se preocupe em prever toda e
qualquer mudana na tecnologia, processos ou estratgias da organizao.
Uma boa prtica atualizar polticas pelo menos anualmente, nesse momento voc
pode analisar novamente o cenrio corporativo, o negcio e as novas tendncias de
tecnologia e segurana da informao. Obviamente, mudanas extraordinrias quan-
do for necessrio no esto descartadas.
Neste momento TI, que em geral faz a redao da maior parte da PSI, pode ser muito
bem ajudada pelas demais reas envolvidas. Ater-se a realidade essencial para uma
poltica funcional.
Exigir que, por exemplo, toda comunicao telefnica da diretoria seja criptografada
fca muito bonito no papel, mas se voc no tiver uma tecnologia ou um procedimento
de apoio ser apenas mais um ponto da sua poltica que nunca vai ser seguido.
6. No proba, controle!
Conforme mencionei em Segurana da Informao e a arte de no dizer no dialogar
com o negcio essencial. Muitas vezes quando implantamos uma PSI o documento
fnal vem carregado de no, proibido e outras referencias que passam ao usurio a
idia 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 usurio vai abrir mo de sua comodidade em prol da segurana
da informao uma receita bem comum para a ocorrncia de incidentes.
Ningum reclama quando um jogador de futebol utiliza as mos e recebe um carto
amarelo ou mesmo expulso. Certo, algumas vezes fcamos at com raiva da deciso
do juiz, mas no fundo sabemos que ele est apenas aplicando as regras do jogo e bem..
bola pra frente.
Usurios devem compreender que as regras existem por um motivo claro, que pro-
tegem o negcio e muitas vezes at eles mesmos. A PSI e a rea de segurana da infor-
mao representam apenas as regras do jogo e o juiz, respectivamente.
119
Tente explicar aos usurios os comos e os porqus da segurana da informao ao
invs de dar um simples no.
7. Crie um bom programa de conscientizao e avaliao do conhecimento
A poltica deve demonstrar claramente o apoio e comprometimento da organizao
com a segurana da informao. Dito isso, no adianta ter o melhor dos documentos
se este no for adequadamente comunicado e, especialmente, entendido pelos usuri-
os da informao.
Conforme mencionado acima, a PSI normalmente deve ter um carter formal. Isto
muito bom do ponto de vista jurdico, mas muitas vezes torna a leitura do documento
maante e o jargo tcnico pode ser totalmente incompreensvel para a maior parte
dos usurios da informao.
Participei de excelentes iniciativas onde TI trabalhava junto dos departamentos pes-
soais e de marketing em campanhas que se utilizavam do ldico para garantir que os
usurios fxariam pelo menos o essencial da PSI. Utilize-se de cartilhas, palestras, apre-
sentaes teatrais, jogos, simulaes e qualquer outro recurso que esteja disponvel
para sua organizao.
Lembre-se: a freqncia, a repetio, a repetio, a repetio isto treinamento. Voc
no precisa de um calendrio muito extenso. Eventos a cada trs meses podem tornar a
equipe menos disciplinadas em colaboradores conscientes de suas responsabilidades
e caso isso falhe.. bem, o que mesmo eles ainda esto fazendo na sua empresa?
E que tal tornar sua campanha realmente efciente? Nada melhor que medir o nvel
de conhecimento dos usurios antes e aps a campanha. Essa informao pode servir
como um termmetro do seu estado atual e direcionamento para futuros eventos e
melhorias.
8. Consultoria ou no? Eis a questo!
Existem inmeras vantagens em utilizar consultores especializados para apoio no de-
senvolvimento da PSI. Consultores experientes possuem uma vivncia maior e nor-
malmente participaram de projetos similares em diferentes segmentos. Esse o tipo
de inteligncia que pode reduzir drasticamente o tempo do projeto, ajudar na aceit-
ao pelos usurios e evitar showstopers.
Em especial se segurana da informao no a sua especialidade ou se voc no tem
recurso humano disponvel o uso de uma boa consultoria pode sair bem mais barato
do que voc pensa tanto em termos de tempo como fnanceiros ou at mesmo dores
de cabea.
A lista acima obviamente no exaustiva e talvez nem todos sejam adequados para
sua organizao. Mas se voc quer que sua poltica de segurana da informao seja
120
mais do que apenas um simples papel encaminhado uma vez ou outra para a auditoria,
pense em utilizar parte desses conceitos.
Links e referncias:
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/
Artgos com toque de tecnologia
122
A gamifcao invadiu nossa praia
REN CHIARI
Voc j ouviu falar em gamifcao (gamifcation)?
Trata-se do uso de mecnicas de jogos e pensamentos orientados a jogos para enri-
quecer contextos diversos normalmente no relacionados a jogos. Essa tcnica pode
encorajar as pessoas a realizar tarefas que elas normalmente considerariam chatas,
como completar questionrios, formulrios, ler algum contedo especfco, etc.
OK, deram nome a algo que sempre existiu (assim como o bullying). J sabiamos que
era mais divertido aprender geografa e histria jogando WAR e tentando capturar a
Carmen Sandiego do que fazendo cpia 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 inovao adotaro prticas de gamifcao
em seu dia a dia e 70% das duas mil maiores corporaes do mundo tero ao menos um
aplicativo desse tipo. No sou eu quem estou dizendo isso, o Gartner.
E o que isso tem a ver com ITSM? Muita coisa.
Algumas empresas j esto comeando a surfar por estas ondas com suas ferramen-
tas. o caso da InvGate, que incorporou em sua suite um mdulo especfco para gam-
ifcation, que inclui pontuao e badges de acordo com o engajamento dos analistas.
www.youtube.com/watch?v=ro5Msyp1s1w
Na rea de capacitao no difcil encontrar jogos complementares aos treinamen-
tos padres de ITIL, por exemplo. So simuladores que estimulam os alunos/jogadores
a praticarem os conceitos aprendidos na sala de aula em situaes reais, como no
funcionamento de um aeroporto, uma usina elica, uma estao espacial, entre outros
cenrios.
Pensando em um sistema de pontuao/premiao/reconhecimento por engajamento,
que um dos objetivos principais da aplicao dos conceitos de gamifcao, seguem
algumas sugestes que poderiam funcionar em alguns processos de gerenciamento de
servios:
Gerenciamento de Incidentes
5 pontos por incidente registrado e categorizado corretamente
5 pontos por incidente resolvido em primeiro nvel
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 satisfao
20 pontos para tempo mdio de atendimento semanal dentro do prazo
123
Gerenciamento de Problemas
1 pontos por problema registrado de acordo com os critrios estabelecidos
2 pontos por artigo inserido na base de erros conhecidos
10 pontos por problema com causa raiz identifcada
10 pontos por incidente resolvido atravs de um artigo da base de erros conheci-
dos
50 pontos por problema resolvido defnitivamente (ex: 3 meses sem incidentes re-
lacionados)
-20 pontos por problema encerrado sem causa raiz identifcada
-5 pontos por cada incidente relacionado a problema j encerrado
Gerenciamento de Mudanas
1 para cada requisio formal de mudana registrada
50 pontos por mudana concluda com sucesso
5 pontos por mudana aprovada
-15 pontos por mudana implementada sem registro formal ou aprovao
-1 ponto por mudana cancelada
-10 pontos por mudana emergencial
-50 pontos por mudana com falha
E o que fazer com estes pontos acumulados? Algumas recompensas reais so sempre
bem-vindas, como folga, viagem, bnus salarial. Tambm podem ser atribudos badg-
es para quem conquistar nveis satisfatrios de desempenho.
Obviamente os exemplos no param por aqui. O ITSM na Prtica tambm incorporou
alguns conceitos de gamifcao (bem menos sofsticados). Saiba mais.
124
ITSM, redes sociais e Content Management Systems
d jogo?
REN CHIARI
Se no pode vencer as redes sociais, junte-se a elas
No h mais o que ser contestado, as redes sociais vieram pra fcar. E no importa quan-
tas barreiras sejam impostas, os usurios vo acessa-ls de um jeito ou de outro.
O lado bom que a prpria TI pode se benefciar nessa histria. 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 Servios de TI.
Alm de serem ferramentas intuitivas e de fcil utilizao, fazem o gosto do pblico
(usurios), e no necessrio grandes esforos em treinamentos, afnal, 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 so bem conhecidas, e outras nem tanto, mas vale a pena conferir cada uma
delas (e outras tambm) com mais detalhes.
Twitter - pode ser um grande aliado para comunicaes como alertas e atualizaes
de incidentes graves e mudanas emergenciais, agenda de mudanas ou qualquer
outra notifcao relevante e/ou urgente que se possa fazer com at 140 caracte-
res. A propsito, o Twitter pode ser utilizado de forma privada.
Wiki - As caractersticas nativas do Wiki, como publicao, controle de alteraes,
permisses de edio, visualizao , e etc so um ambiente perfeito para a criao
de base de conhecimento, base de erros conhecidos, gerenciamento de documen-
tao (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 prprio
ITIL na Prtica roda em cima de um CMS (Wordpress). Mas eu me surpreendo a
cada dia. J existem alguns temas e plugins especfcos criados em cima dos frame-
works dos CMSs para transformar um simples blog/site em uma ferramenta para
gesto de tickets ou projetos bem convincente, dadas as devidas limitaes dos
frameworks e o prprio perfl dos desenvolvedores, que no so especializados
em ITSM.
Yammer - uma cpia escandalosa do Facebook, verso empresarial. Para empre-
sas que ainda esto acanhadas de se expor no mundo pblico do Facebook, esta
pode ser uma tima ferramenta para compartilhar (e reter) conhecimento na or-
ganizao, e principalmente gerenciar reclamaes e assuntos ligados a satisfao
dos clientes.
125
Facebook - muitas empresas j esto se expondo no Facebook, e considerando
ele como um dos principais canais de relacionamento com os Clientes. Porque no
tentar?
Para alguns de vocs estas idias podem parecer bobas. De fato as idias so voltadas
as necessidades mais bsicas de gerenciamento de servios. Mas basta dar uma olha-
da na ltima enquete disponibilizada aqui no ITIL na Prtica e verifcar que 56% dos
participantes disseram que no tem uma ferramenta ITSM. Ou seja, para quem no
tem nada, um timo comeo a custos baixssimos.
Nos prximos artigos pretendo escrever sobre cada um deles de uma forma mais de-
talhada, inclusive custos.
126
O que as ferramentas no fazem por voc
REN CHIARI
No h o que questionar: as ferramentas vieram para facilitar (e muito!) a nossa vida.
Mas ao contrrio do que parece, as ferramentas nem sempre conseguem atingir o ob-
jetivo proposto, que trazer agilidade e qualidade na gesto de servios.
A falha pode ter dois vieses:
o fornecedor que muitas vezes est mais preocupado com a quantidade de mdu-
los que sero vendidos, do que com a real necessidade do Cliente;
o Cliente pode no saber o que quer, e exigir que o fornecedor adivinhe e o satis-
faa, entregando o que no essencial para o negcio. Isso exige experincia do
fornecedor em entender de fato, qual a necessidade ou recomendar solues 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 operao: Como
vou registrar tantas informaes requeridas pelos critrios de qualidade e mesmo as-
sim garantir que isso seja feito em tempo de no afetar a minha meta de atendimento?.
A questo talvez seja resolvida com a aquisio de uma ferramenta que automatize
este processo, mas antes seria interessante perguntar: Porque estamos registrando
todas essas informaes?.
Penso que essa questo tem algumas possveis respostas:
Ahh... porque est escrito na ITIL que precisamos fazer isso! - a ITIL no nos
obriga a fazer tudo o que cita. Se voc est registrando ou pretende registrar in-
formaes que no agregam em nada, no continue! Isso pode inclusive infuen-
ciar um fornecedor de ferramentas a vender customizaes adicionais, que geral-
mente saem muito caras para atender uma necessidade que pode nem fazer tanta
diferena assim no resultado fnal.
Para quem acabou de adquirir uma ferramenta, seria: Bem, a nossa nova e ultra
espetacular ferramenta exige que sejam preenchidos todos estes vrios campos
antes de direcionar para o grupo solucionador. E essa ferramenta esta alinhada
com as boas prticas da ITIL!! - Essa uma das falhas mais comuns em projetos
que envolvem implantao de processos e ferramentas. Conheo casos de proje-
tos que extrapolaram a concluso, 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 - Desconfe de ferramen-
tas com selos de compliance com a ITIL. Isso torna a ferramenta muito mais
cara, e dependendo de como o negcio 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 of-
127
cializar um modelo de certifcao de ferramentas compliance com ITIL, mas eu
sinceramente no acredito que isso v trazer algum benefcio para o Cliente fnal.
Esses cuidados se aplicam em qualquer contexto e no somente a um processo espe-
cfco. O importante lembrar que as ferramentas no devem governar os processos
- justamente o contrrio!
Artgos Exlcusivos do Chef
129
Os desafos da criao de valor atraves da Operao
de Servios
REN CHIARI
Cada estgio no ciclo de vida do servio tem o seu papel na criao de valor. Por ex-
emplo, o valor do servio modelado na Estratgia de Servio; o custo do servio
desenhado, prescrito e validado no Desenho de Servio e Transio de Servio; e os
indicadores para melhoria so identifcados na Melhoria Continuada do Servio. A op-
erao de servio entra em cena quando estes planos, desenhos e melhorias so im-
plementados. Do ponto de vista de um cliente, na operao de servio em que o valor
percebido de fato.
Ao contrrio do que parece, a operao de servio no pode restringir o seu foco so-
mente na operao do dia a dia e entrega de servios para criar valor. Existem desafos
fora deste contexto que podem oferecer riscos criao de valor, por exemplo:
Poucas organizaes planejam efetivamente os custos do gerenciamento de servios
ao entrarem em produo. muito fcil identifcar custos de um projeto, mas muito
difcil quantifcar quanto um servio ir custar depois de alguns anos de operao.
comum que somente aps algum tempo que o servio est em operao as falhas dos
estgios anteriores (estratgia, desenho e transio de servio) sejam visveis. Con-
tudo, difcil justifcar investimentos para corrigir falhas de projeto ou requisitos no
previstos, porque isso no faz parte da proposio de valor original.
Tambm h difculdade em obter investimento adicional em aes de melhoria da op-
erao de servio, como aquisio de ferramentas ou treinamentos. Por um lado, isto
ocorre porque estes investimentos no esto diretamente relacionados funcionali-
dade de um servio especfco e, por outro lado, porque h uma expectativa do cliente
que estes custos deveriam ser embutidos aos custos do servio desde o comeo, e no
aps o servio entrar em operao.
Quando um servio est em operao por muito tempo, ele se torna parte do que o
negcio considera como normal para um servio de TI. Este sentimento difculta jus-
tifcar aes de melhoria do servio, pois o sucesso destas iniciativas s percebido
pelo cliente se o servio tiver um histrico nebuloso de falhas.
O estgio de Operao de Servio sugere vrios processos, funes e mensuraes
que endeream estes desafos.
130
O que so incidentes, problemas, erros conhecidos
e requisies de servio segundo a ITIL?
REN CHIARI
Para compreender melhor estes conceitos, como de costume, convidamos voc a sair
da caixa. Preparado?
Ento, imagine que, de uma hora para outra, voc comea a fcar febril. Este um com-
portamento no esperado e indica que algo no est bem com o seu organismo, certo?
Para a ITIL, isso um incidente. Em outras palavras, qualquer acontecimento que no
faa parte do comportamento padro e que cause, ou possa causar, uma interrupo
ou reduo da qualidade de um servio. No nosso exemplo, entenda como a reduo
da qualidade de vida ou mesmo a morte!
A forma de tratar um incidente resolver o sintoma o mais rpido possvel. Sendo as-
sim, voc procura uma farmcia e toma um remdio por conta, ou procura um posto de
sade e passa por uma consulta com um clnico geral.
Agora imagine que esta febre volte a ocorrer duas, trs 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 investigao profunda em busca da
causa raiz. Para isto, voc vai precisar de um mdico especialista. Isso vai levar mais
tempo e provavelmente custar mais.
Atravs da avaliao dos resultados de exames, possvel chegar a um diagnstico e,
a partir da, identifcar a forma de resolver defnitivamente (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 soluo de contorno.
Considerando que a causa desta febre j conhecida e o mdico especialista j sabe
como trat-la de forma defnitiva, ele recomenda a voc tomar uma injeo com um
medicamento especfco para este fm.
Este procedimento bastante comum e de conhecimento de todos os profssionais de
sade em geral. Alm disto, tambm um procedimento pr-autorizado pelas autori-
dades de sade.
Na ITIL, isso seria considerado como uma Requisio de Servio, ou seja, a descrio
genrica de vrios tipos de demanda colocados pelos usurios para o departamento
de TI. Muitas destas requisies so pequenas e de baixo risco, e ocorrem com grande
frequncia.
131
Principais abordagens para liberao e implantao
REN CHIARI
Neste artigo, voc ir conhecer as opes mais comuns para a liberao e implantao
de servios de TI.
A escolha da abordagem mais adequada para uma liberao depende de uma boa com-
preenso dos padres de atividades de negcio e perfs de usurios durante o planeja-
mento e desenho destas liberaes.
A opo selecionada ter um impacto signifcativo nos recursos de gerenciamento de
liberao e implantao, assim como nos resultados do negcio.
As duas opes de liberao mais comuns para cenrios de mltiplas localidades so:
Big Bang
O servio implementado para todos os usurios de uma s vez. Esta opo geralmente
utilizada em mudanas de aplicaes em que a consistncia do servio considerada
importante para toda a organizao.
Algumas vantagens desta opo so:
O tempo de implementao menor
As difculdades de implementao so condensadas;
Os custos de implementao so menores;
Os usurios devem estar treinados apenas para o novo servio e no para o pero-
do de mudana;
A implementao ocorre em um nico dia e todos os usurios sabem a data.
Por outro lado, as desvantagens so:
Detalhes podem ser negligenciados com a pressa de mudana;
Os usurios tm menos tempo para conhecer (e aprender) o novo servio;
Uma falha em uma parte do servio pode afetar outras.
Abordagem faseada
O servio implementado para uma parte da base de usurios e, depois, esta operao
repetida para as bases de usurios subsequentes, conforme uma agenda planejada
de liberaes. Esta abordagem pode ser dividida em trs:
Implementao faseada por mdulo os mdulos do servio so implementados
um a um, comeando pelos mais importantes;
Implementao faseada por unidade de negcio a implementao feita em uma
unidade de negcio por vez;
Implementao faseada por geografa para organizaes com mltiplos locais.
132
As vantagens desta opo so:
A organizao ganha conhecimento durante a implementao inicial, que pode
ser aplicada nas fases seguintes;
Com a transio a ocorrer em partes, existe tempo para ajustes e correes;
Existe mais tempo para os usurios se adaptarem ao servio novo ou modifcado;
A equipe tcnica pode concentrar os esforos em uma parte do servio ou em um
grupo de usurios.
E algumas das desvantagens:
No to focada como na abordagem Big Bang;
Pode haver inconsistncia de informaes, uma vez que cada mdulo contm in-
formaes importantes sobre outros mdulos;
A durao do projeto mais longa que a abordagem Big Bang.
Empurrar e puxar (Push and pull)
A opo empurrar (push) utilizada quando o componente do servio implantado
a partir de um ponto central de distribuio e empurrado para as localidades. Em
termos de implantao de servios, entregar os componentes atualizados do servio
para todos os usurios seja com a abordagem Big Bang ou faseada signifca em-
purrar, uma vez que o servio novo ou modifcado disponibilizado no ambiente dos
usurios em um momento no escolhido por eles.
A opo puxar (pull) utilizada em liberaes de software, nas quais o programa
disponibilizado em um ponto central de distribuio, mas os usurios so livres para
fazer o download para sua localidade no momento em que escolherem ou quando uma
estao de trabalho de usurio reiniciada.
Um bom exemplo prtico do uso de abordagens e opes de liberao a funcion-
alidade Windows Update, nativa nos sistemas operacionais da Microsoft. As atual-
izaes so disponibilizadas simultaneamente para todos os usurios (abordagem Big
Bang). Os usurios decidem pela opo empurrar ou puxar, de acordo com sua
preferncia.
133
Gerenciamento da Confgurao e Ativos de
Servio: o processo camarada da ITIL
REN CHIARI
Conhea as suas principais interfaces e suporte ao aumento da efcincia de outros
processos de Gerenciamento de Servios.
Nenhuma empresa pode ser totalmente efcaz e efciente se no gerenciar bem os seus
ativos, principalmente aqueles que so vitais para manter a operao dos seus proces-
sos de negcio. O processo da ITIL que enderea este tema o de Gerenciamento da
Confgurao e Ativos de Servio.
Sua misso assegurar que os ativos necessrios para entregar servios sejam contro-
lados apropriadamente, e que informaes confveis e ntegras sobre os ativos sejam
disponibilizadas quando e onde necessrio.
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 Confgurao e Ativos
de Servio suportar os processos de Gerenciamento de Servios fornecendo infor-
maes precisas da confgurao, permitindo, assim, uma tomada de deciso mais as-
sertiva e em tempo hbil por exemplo, para autorizao de mudanas e liberaes ou
resolver incidentes e problemas.
Destacamos algumas das principais contribuies do processo de Gerenciamento da
Confgurao e Ativos de Servio com demais processos de Gerenciamento de Servios:
Gerenciamento de Incidentes: o processo utilizar a CMDB (Confguration Manage-
ment Database ou Banco de Dados do Gerenciamento da Confgurao) para ter uma
viso lgica da infraestrutura de TI e seus servios atravs dos itens de confgurao
e seus relacionamentos. Essa viso poder fazer com que o gerenciamento de
incidentes tenha maior agilidade e facilidade para solucionar incidentes.
Por exemplo: maior rapidez na anlise do impacto e alocao do time correto para
atuao no incidente; maior rapidez na identifcao dos itens de confgurao im-
pactados e que precisam ser rapidamente substitudos ou corrigidos.
Gerenciamento de Mudanas: maior controle e agilidade no gerenciamento sobre
as mudanas do ambiente, pois o uso da CMDB e a viso lgica da infraestrutura
de TI e seus servios (fornecida atravs dos itens de confgurao e seus relaciona-
mentos) mostraro de maneira clara e controlada os componentes envolvidos na
mudana e seu real impacto para o servio.
Por exemplo: maior agilidade e assertividade na aprovao de mudanas, pois ha-
ver mais facilidade para analisar o impacto no servio dos itens de confgurao
envolvidos na mudana. Tambm poder ser feito o uso de baselinesde confgura-
134
o para retornar o ambiente ao status anterior a uma mudana executada e mal
sucedida.
Gerenciamento de Problemas: aumento da efcincia do Gerenciamento de
Problemas, ao facilitar a anlise de tendncias em itens de confgurao relacionados
a incidentes e identifcar a causa bsica de um ou mais incidentes. Essa informao
utilizada para evitar novos incidentes e melhorar a qualidade dos servios.
Gerenciamento de Liberao e Implantao: aumento da efetividade do geren-
ciamento de liberao e implantao, pois far auditorias e controles permanentes
para evitar que softwares ilegais ou no autorizados sejam registrados. Tambm
poder aumentar a efcincia das liberaes com o uso de baselines de confgurao
para salvar as informaes dos itens de confgurao antes da liberao (atributos
como verso ou status, por exemplo). Essas informaes podero auxiliar caso a
liberao seja mal sucedida e um backup tenha que ser retornado.
Em resumo, conhecer as vantagens de um processo para o negcio de sua empresa o
primeiro passo para tomar a deciso de adot-lo. Esperamos que com este artigo voc
possa compreender melhor a importncia do processo de Gerenciamento da Confgu-
rao e Ativos de Servio e o motivo dele ser considerado um dos que mais oferecem
suporte aos demais processos de Gerenciamento de Servios.
135
Qual a diferena entre o Gerenciamento de
Mudanas e o Gerenciamento de Liberao e
Implantao?
REN CHIARI
Existem vrios elementos discretos no ciclo de vida da Transio do Servio que po-
dem ser facilmente perdidos quando estes dois processos so olhados como um s.
A separao dos processos de Gerenciamento de Mudanas e Gerenciamento de Lib-
erao e Implantao tem sido um tema constante de debates e discusses. A primeira
impresso que a separao destes processos serve apenas para criar uma confuso
desnecessria. Mas no bem por a.
O Gerenciamento de Mudanas o processo que garante que todas as mudanas pas-
sem por um processo slido de avaliao e aprovao. Tambm rene informaes
relevantes sobre cada mudana no servio (porque, quem pediu, foi aprovado?). Por
outro lado, o Gerenciamento de Liberao e Implantao o processo que agrupa as
mudanas (quando necessrio) e se preocupa com o cronograma, a comunicao, tre-
inamento etc.
Em termos mais simples, uma mudana nada mais do que compreender e aprovar o
que, enquanto a liberao se preocupa com como e quando.
Um dos erros no uso destes processos , por exemplo, o fato de que a maioria das re-
unies do CAB (Comit de Mudanas) costuma ser focada apenas na avaliao e vali-
dao testes e aprovao da agenda de mudanas. No que esta seja uma atividade
incorreta, afnal, o Gerenciamento de Mudanas que de fato aprova a implantao
(ou liberao) de uma mudana. Mas neste caminho comum perder a oportunidade
de avaliar se a mudana deve ou no ser feita, mas de um ponto de vista de benefcio
do negcio, risco e custo. Ou seja, as mudanas devem ser vistas a partir de uma per-
spectiva de valor de negcio antes de se tomar a deciso de investir recursos em seu
desenvolvimento.
Tanto na ITIL, quanto em outras referncias de prticas de Gerenciamento de Servios
de TI, como o COBIT e a norma ISO/IEC20000, as atividades de mudanas e liber-
aes so descritas em processos distintos, o que refora ainda mais a existncia de
elementos diferentes entre estes dois processos. Ironicamente, a separao 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?
136
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 prticas de mercado, fca a dvida se a
ITIL realmente est com os seus dias contados.
Para refetir sobre esta dvida, vamos destacar alguns fatos importantes:
A ITIL foi criada no Reino Unido em 1989.
Seus termos, conceitos e processos so to populares que a tornou uma refern-
cia adotada por empresas em todo o mundo. Hoje em dia muito comum no meio
de TI as expresses Incidentes, Problemas, SLA, etc.
Teve duas grandes atualizaes, e a verso atual (v3) teve uma atualizao em 2011.
A norma ISO/IEC 20000, que tem como foco atestar a qualidade da prestao de
servios de TI (e um tema para um artigo exclusivo) foi baseado na ITIL.
Outros frameworks de governana importantes, como o COBIT, tambm citam a
ITIL como referncia complementar.
Possui um esquema estruturado de certifcao profssional, que vai do nvel bsi-
co (fundamentos) at os nveis mais avanados (intermedirios, Expert e Master).
O nmero de profssionais certifcados, s no Brasil, beira aos 100 mil.
Considerando os fatos acima citados, podemos concluir que:
Um dos mais claros sinais da evoluo da ITIL que a prpria defnio do acr-
nimo ITIL j est defasada em relao ao seu foco atual. O nome (Biblioteca da
Infraestrutura de TI) traz, na verdade, melhores prticas paraGerenciamento de
Servios de TI (IT Service Management ITSM).
H conhecimento acumulado, praticado e discutido h mais de 20 anos. E com a
chegada da verso 3, que d mais nfase a assuntos como estratgia de servios,
desenho de servios e melhoria continuada, a ITIL deixa a sua fase de adolescncia
e entra na fase adulta.
Tambm podemos dizer que a ITIL reconhecida como um padro de facto, inclu-
sive por outras instituies importantes que desenvolvem outras referncias para
governana e gerenciamento de TI, como a ISACA, que desenvolve o COBIT e a
prpria ISO, que desenvolve a ISO200000.
Costuma-se dizer que contra fatos no h argumentos. E os fatos so bem signifca-
tivos, no?
137
4 mtricas para monitorar o desempenho de uma
CMDB (Confguration Management Database)
REN CHIARI
Sabemos o quanto desafador implantar uma CMDB. Mas, uma tarefa to desafadora
quanto manter a sua integridade. Neste artigo, apresentamos 4 mtricas para acom-
panhar a sade de uma CMDB.
Objetivo: Identifcar e gerenciar as informaes da infraestrutura e seus relacionamentos
de forma acurada e efciente.
Mtrica #1 Nmero de licenas no utilizadas.
A CMDB possui um registro de todas as licenas de software e quando foram distribu-
das. Sendo assim, um relatrio de licenas no utilizadas pode ser produzido.
Por que utilizar esta mtrica?
J esperada a existncia de algumas licenas sobressalentes. Mas, um nmero muito
alto de licenas subutilizadas remete a uma possvel falha no planejamento da Capaci-
dade, provavelmente pelo uso insufciente das informaes da CMDB pelo processo
de Gerenciamento de Capacidade. Esta mtrica encoraja o Gerenciamento da Confg-
urao a garantir que as informaes sobre licenas estejam corretas e como reduzir
o nmero de licenas no utilizadas para o mnimo possvel.
Mtrica #2 Nmero de incidentes originados a partir de mudanas mal sucedidas
causadas por Itens de Confgurao (CI) mal documentados.
Mudanas so aprovadas com base nas informaes registradas na CMDB. Se uma
mudana falha, devido a uma informao incorreta sobre um componente do servio
(Item de Confgurao), a responsabilidade deve ser atribuda ao processo de Geren-
ciamento da Confgurao.
A informao de um Item de Confgurao na CMDB deve ser correta. Com isto, a prob-
abilidade de mudanas mal sucedidas ir diminuir, e consequentemente, o surgimento
de incidentes ocasionados por estas.
Objetivo: Assegurar que CMDB fornece informaes corretas e integras a outros processos
de gerenciamento de servios.
Mtrica #3 Nmero de Requisies de Mudana sem a atualizao do(s) Item(s) de
Confgurao correspondente(s).
Sempre que um Item de Confgurao sofre uma alterao, deve haver uma Requisio
de Mudana correspondente autorizada, seguida de uma atualizao na CMDB para
138
refetir a concluso desta Mudana autorizada. Durante uma possvel auditoria, a in-
formao de uma Requisio de Mudana deve ser comparada (e correspondida) com
a informao de status da confgurao na CMDB.
Garante informaes acuradas e autorizadas na CMDB. Denomina aderncia ao pro-
cesso.
Mtrica #4 Percentual de Itens de Confgurao com informaes incorretas.
Todas as correes de informaes de Itens de Confgurao deveriam ser contabiliza-
das para contribuir com esta mtrica.
A razo de ser do processo de Gerenciamento da Confgurao garantir a infor-
mao correta dos Itens de Confgurao.
139
O que um Service Desk (ou Central de Servios)?
REN CHIARI
O Service Desk uma unidade funcional (funo) composta por uma equipe dedicada,
responsvel por uma variedade de atividades relacionadas aos servios de TI que so
fornecidos por um provedor de servios (seja interno ou externo). Normalmente, a in-
terface com o Service Desk atravs de telefone, web, ou notifcaes automticas
geradas por eventos da infraestrutura.
O Service Desk o ponto nico de contato para os usurios de TI. Ele no trata somente
incidentes, requisies e dvidas de usurios, como tambm pode ser a interface para
outras atividades, como a comunicao durante mudanas em servios ou servios no-
vos liberados no ambiente de produo, manuteno de contratos, administrao de
licenas de software, etc.
Em outras palavras, o Service Desk a vitrine da TI. O seu valor no pode ser, nunca,
subestimado!
Um bom Service Desk pode compensar as defcincias internas de uma organizao
de TI (que no so visveis aos usurios e clientes), porm um Service Desk inefciente
(ou a falta de um) pode trazer uma m impresso sobre a efcincia geral de uma or-
ganizao de TI.
Veja outros benefcios que um Service Desk pode trazer para uma organizao de TI:
Melhora na percepo e satisfao dos clientes sobre os servios fornecidos;
Aumento da acessibilidade atravs de um ponto nico de contato, comunicao e
informao;
Melhor qualidade e agilidade no tratamento de requisies de clientes e usurios;
Melhora na comunicao e trabalho em equipe;
Utilizao otimizada dos recursos de suporte de TI e aumento da produtividade
do negcio;
Informaes gerenciais mais signifcativas para apoio tomada de deciso
140
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 necessrio para uma organizao im-
plementar uma estrutura que combine uma ou mais destas opes, a fm de atender
completamente as necessidades do negcio.
Service Desk Local
Nesta estrutura, o Service Desk est fsicamente localizado prximo comunidade de
usurios suportados. Esta opo facilita a comunicao, o que agrada alguns usurios,
mas pode ser injustifcvel manter um grupo de recursos de suporte que sazonalmente
pode estar ocioso, espera de incidentes e requisies de servio locais, enquanto em
outros sites (localidades) a coisa pode estar pegando.
Algumas razes para se adotar a estrutura de um Service Desk local so:
Diferenas polticas, culturais e de idiomas;
Diferentes fuso-horrios;
Grupos especializados de usurios;
Existncia de servios customizados ou especializados, que requerem conheci-
mento especializado;
Usurios crticos ou VIP.
Service Desk Virtual
Calma, no se trata de uma central de atendimento robotizada.
Atravs do uso de tecnologia, particularmente a internet, e outras ferramentas corpo-
rativas de suporte, possvel dar a impresso de um Service Desk nico e centralizado,
quando de fato os recursos podem estar distribudos em locais fsicos variados.
Com isso, algumas opes tornam-se viveis, como o home working, offshoring ou out-
sourcing. Porm, importante preservar a consistncia e uniformidade na qualidade
do servio e termos culturais.
Follow the Sun
No 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 organizaes com atuao global podem combinar dois ou mais Service Desk
distribudos para oferecer uma estrutura de suporte 24 horas. Esta opo pode otimizar
os custos de um Service Desk full-time, pois evita-se despesas adicionais com adicional
141
noturno ou hora extra, por exemplo.
Por outro lado, esta estrutura pode oferecer alguns desafos, como manter os proces-
sos, ferramentas e banco de dados de informaes 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 organizaes pode ser interessante criar um grupo de suporte especializa-
do dentro da estrutura do Service Desk (em alguns lugares o nome clula de suporte
utilizado). Desta forma, os incidentes relacionados a um determinado servio de TI
podem ser encaminhados diretamente para um grupo de suporte especializado. Isso
permite uma resoluo muito mais rpida e assertiva destes incidentes.
Um exemplo clssico desta abordagem quando ligamos para uma central de atendi-
mento de operadoras de Telecom ou TV a cabo e somos orientados a digitar um nmero
para cada assunto especfco, por exemplo, suporte tcnico, faturamento, reclamaes,
novos servios, etc.
Contudo, neste mesmo exemplo podemos notar que eventualmente h certo exagero
destas organizaes, oferecendo muitas opes de atendimento especializado, o que
pode fazer com que a experincia do usurio se torne muito cansativa.
Agora que voc j conhece as principais estruturas de Service Desk, fca muito mais
fcil refetir sobre uma estrutura adequada a sua organizao.
142
Melhores Prticas ou Boas Prticas, qual o certo?
Boas prticas e melhores prticas so jarges amplamente utilizados em nossa rea.
Porm, sempre fca uma dvida: qual o termo correto a se utilizar?
As duas esto corretas. Mas a seguir voc entender melhor qual a melhor forma de
utiliz-las.
No contexto do Gerenciamento de Servios, o termo prtica utilizado para descrever
um conjunto de habilidades e competncias, um mtodo reconhecido ou uma atividade
padro. Uma prtica pode ser unicamente responsvel por um ou mais processos,
embora os processos tipicamente trabalhem atravs de toda uma unidade funcional.
Sendo assim, vamos a algumas defnies:
Melhor prtica
Uma melhor prtica pode ser considerada como uma prtica geralmente aceita,
que necessita uma comprovao emprica de um resultado especfco e proposto por
uma comunidade de prtica como um padro ou o mnimo necessrio para ser consid-
erado como uma prtica. A melhor prtica transformada em boa prtica atravs
de sua aplicao para ajudar a alcanar um ou mais resultados desejados.
Boa prtica
Uma boa prtica o resultado da aplicao de uma melhor prtica em um contexto
ou situao especfca de uma organizao, uma adaptao para atender a requisitos
locais. Uma boa prtica pode ser defnida como atividades desenhadas para atingir
um resultado desejado, utilizando um conjunto de aes comprovado, recomendado
e aprovado. A palavra-chave aqui comprovar o senso de prtica atravs de sua apli-
cao, no teoria.
A boa prtica pode ser considerada como um consenso geral sobre a correta aplicao
de determinados conceitos, termos e tcnicas que podem melhorar a visibilidade e o
controle gerencial que uma organizao provedora de servio tem sobre a qualidade
e o custo dos servios que fornece.
O ITIL apresenta-se como uma boa prtica e suas caractersticas incluem:
Ser um padro genrico disponvel no mercado (diferentemente de metodologias
proprietrias);
Pode ser aplicado em vrios ambientes e situaes empresas de grande ou pe-
queno porte, pblicas ou privadas, de diversos setores da economia
143
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 aceitveis para aten-
der os requisitos atuais e futuros dos clientes e usurios;
Manter o balanceamento entre custos x capacidade proviso x demanda;
Reconhecer novas tecnologias e investir apropriadamente para entregar os requi-
sitos de negcio;
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 considerao os principais re-
cursos envolvidos na entrega do servio:
Recursos humanos: >> Ex.: Equipes de suporte, desenvolvedores, administrado-
res de rede etc;
Recursos Tcnicos: >> Ex.: banco de dados, link (banda), servidor (CPU, memria,
storage);
Recursos Financeiros.
Para o desenvolvimento do plano, tambm devem ser considerados alguns ele-
mentos, como:
Demanda atual e prevista (futura) por servios. Pode-se considerar como deman-
da futura, por exemplo, um novo cliente para o prximo ms, com uma demanda
esperada de consumo de mais de 500 acessos simultneos ao sistema comercial.
Ou, uma data comemorativa, que ir aumentar as compras de um site de e-com-
merce em quase 40%;
Limitaes (thresholds). Em outras palavras, os limites aceitveis de uso da capaci-
dade em relao a um servio ou componente do servio. Por exemplo, mximo de
100 transaes por minuto, mximo de 80% de consumo de memria e/ou CPU,
bem como os procedimentos de resposta caso estes limites sejam ultrapassados;
Custos de atualizao/manuteno da capacidade do servio;
Impactos potenciais em questes regulatrias ou contratuais;
Procedimentos que permitam a anlise preditiva.
Por fm, a organizao de TI deve monitorar o uso da capacidade e realizar ajustes de
desempenho quando necessrio.
importante ressaltar que o plano de capacidade deve ser revisado no mnimo anual-
mente. Considerando que no mundo de hoje a Tecnologia da Informao deixou de ser
um fator irrelevante e passou a ser uma questo de sobrevivncia das empresas, os
requisitos de capacidade (assim como outros requisitos de nvel de servio) passaram
144
a ser muito mais dinmicos.
145
A razo pelo qual um incidente no vira um
problema
REN CHIARI
Um dos mais incompreendidos relacionamentos entre processos de gerenciamento de
servios propostos pela ITIL est, sem dvida, entre o Gerenciamento de Incidentes e
o Gerenciamento de Problemas.
Incompreendido porque ainda comum ouvir a expresso um incidente que vira um
problema nos corredores das organizaes de TI.
A razo pelo qual um incidente no vira um problema a mesma pela qual uma febre no
vira uma gripe. Gripes causam febres, dores no corpo. Problemas causam incidentes. E
no o contrrio.
Incidentes e Problemas so duas entidades distintas, cada uma com o seu prprio cic-
lo de vida e tratadas por dois processos com objetivos bastante distintos: o Gerenci-
amento de Incidentes, que busca resolver o mais rpido possvel e no se preocupa
muito com as circunstncias da causa, e o Gerenciamento de Problemas, que busca a
identifcao da causa raiz e uma soluo defnitiva, 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.
146
10 coisas que voc deveria saber sobre a ITIL
REN CHIARI
H alguns anos atrs, ningum conhecia a ITIL. Agora, difcil encontrar uma revista,
portal ou blog sobre gesto de TI sem que o termo ITIL seja mencionado. Apesar da
fama, muitos profssionais de TI no entendem completamente o que ITIL. Seguem a
seguir 10 coisas que voc deveria saber:
#1: ITIL signifca Biblioteca de Infraestrutura de Tecnologia da Informao (Infor-
mation Technology Infrastructure Library).
A biblioteca ITIL contm um conjunto de boas prticas que so usadas para desenvolv-
er e executar gerenciamento de servios de TI. Ela oferece um nmero de benefcios,
incluindo o aumento da vantagem competitiva atravs da reduo de custos, cresci-
mento e agilidade, mais efcincia corporativa atravs da racionalizao de processos
de TI; melhor valor da TI atravs do alinhamento do negcio com a TI, e melhor satis-
fao de clientes e usurios.
#2: A organizao que suporta a ITIL chama-se AXELOS.
Atravs de um processo de licenciamento sobre a propriedade intelectual do ITIL e
Prince2, foi estabelecido uma joint venture entre o Cabinet Offce (UK) com a empre-
sa de servios britnica Capita. Esta iniciativa levou a criao de uma nova empresa,
chamada Axelos.
#3: A biblioteca ITIL consiste em uma srie de livros que fornecem orientaes e
recomendaes.
Dentre todas as publicaes, incluem-se as seguintes principais:
Estratgia de Servio;
Desenho de Servio;
Transio de Servio;
Operao de Servio;
Melhoria de Servio Continuada.
#4: Para permitir uma implantao bem sucedida de prticas de gerenciamento de
servios, a ITIL enfatiza a necessidade de um forte patrocnio da alta direo.
A implementao de prticas de gerenciamento de servios recomendadas pela ITIL
uma iniciativa que envolve mudana cultural. Pessoas iro questionar sobre terem
que fazer coisas diferentes do que sempre fzeram. Portanto, necessrio apoio de um
patrocinador da alta direo para infuenciar a mudana. Sem um bom patrocinador,
melhor nem tentar ou ao menos estar ciente de que o sucesso ser limitado.
#5: ITIL no gesto de projetos.
147
A ITIL no est concentrada na criao de coisas (produtos) como comumente o foco
de projetos. A ITIL concentra-se em prticas para o fornecimento de servios de TI
para a empresa, que so organizadas em processos de gerenciamento de servios de
TI.
#6: Apesar de sua popularidade, nem todas as respostas e contedos esto disponveis
na ITIL.
A ITIL um conjunto de abordagens e melhores prticas. um guia de referncia para
gerenciamento de servios de TI. Ela contm alguns processos e templates, mas no
uma metodologia e no contm todos os detalhes de uma implementao. Organ-
izaes que queiram usar a ITIL podem seguir as orientaes gerais e a partir da de-
senvolver processos mais detalhados que faam sentido para a prpria organizao.
#7: ITIL no uma ferramenta.
Voc pode implementar muitos aspectos da ITIL usando ferramentas, mas ferramen-
tas no so impostas/requeridas. Para organizaes pequenas, planilhas e templates
simples podem dar conta do recado. Para organizaes maiores, provavelmente ser
necessrio encontrar ferramentas apropriadas para suportar o gerenciamento de
servios de TI.
#8: ITIL no uma proposio tudo ou nada.
A partir do princpio de que a ITIL uma srie de abordagens em reas distintas, uma
organizao pode implementar parte destas abordagens, ou todas elas. No h regras
impondo que tudo deve ser implementado. Adapte e adote!
#9: Prticas da ITIL podem ser implementadas em estgios.
No h regras que enfatizem a necessidade de todas as prticas descritas na ITIL ser-
em implementadas de uma s vez. Muitas organizaes implementam estas prticas
em fases, durante perodos determinados.
#10: Voc (profssional) pode se certifcar em ITIL. A sua empresa no!
Existe um programa de certifcao em ITIL para profssionais, divididos basicamente
em trs nveis: nvel bsico (fundamentos, nvel intermedirio (capability / lifecycle
modules) e nvel avanado (Expert, Master).
No existe certifcao ITIL para empresas. A norma internacional ISO/IEC20000 o
caminho para atestar a qualidade de servios de TI fornecidos e operados por empre-
sas. Em outras palavras, a forma de atestar que as empresas aplicam, de fato, as prin-
cipais recomendaes da biblioteca ITIL
148
Compreendendo os principais conceitos do COBIT 5
REN CHIARI
O COBIT 5 a mais recente verso do framework de boas prticas de governana
e gerenciamento empresarial de TI, que incorpora muitos conceitos e teorias ampla-
mente aceitos.
Nesta serie de artigos, vamos explorar os princpios fundamentais do framework,
servindo como uma referncia para a aplicao do COBIT 5 em sua organizao.
A Governana Empresarial de TI e o COBIT 5
Informao (no sentido mais abrangente da palavra) e tecnologias relacionadas esto
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 posio central dentro das empresas. O
papel realado da TI na criao de valor e gerenciamento de risco empresarial, veio
acompanhado por uma crescente nfase na Governana e Gerenciamento Empresar-
ial de TI. Os stakeholders anseiam por assegurar que a TI cumpra as metas empresar-
iais.
A Governana e Gerenciamento Empresarial de TI parte integral de toda a gover-
nana corporativa. Ela enderea a defnio e implementao de processos, estruturas
e mecanismos relacionais dentro da empresa, que permitem ao pessoal de negcio e
da TI executarem suas responsabilidades para suportar a criao e sustentabilidade
do valor ao negcio. A Governana e Gerenciamento Empresarial de TI complexa e
multifacetada. Membros do comit de governana e a alta direo, tipicamente precis-
am de assistncia para implement-la. Atravs dos anos, frameworks de boas prticas
foram desenvolvidos e promovidos para auxiliar neste processo.
Lanado em 2012, o COBIT 5 foi construdo e integrado com base em 20 anos de de-
senvolvimento neste campo de atuao. Desde o seus primrdios, centrado na comu-
nidade de auditoria de TI, o COBIT se tornou um framework de Governana 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 endereava processos de negcio e responsabilidades na
criao de valor empresarial e o Risk IT fornecia uma viso de negcio holstica sobre
o gerenciamento de riscos. Agora, ambos esto incorporados ao COBIT 5.
O framework COBIT 5 construdo em torno de cinco princpios fundamentais:
1. Satisfazer necessidades das partes interessadas;
2. Cobrir a organizao de ponta a ponta;
3. Aplicar um framework integrado e nico;
149
4. Possibilitar uma viso holstica;
5. Separar Governana do Gerenciamento.
Dando sequncia srie de artigos sobre os principais conceitos do COBIT 5, neste
artigo iremos apresentar o primeiro princpio do COBIT 5:
Satisfazer necessidades das partes interessadas.
O primeiro princpio implica que o COBIT 5 fornece todos os processos e habilitadores
necessrios para suportar a criao de valor atravs do uso da TI (pode-se interpretar
criao de valor como gerao de benefcios). Este princpio est intimamente alinha-
do com o conceito de longa data chamado alinhamento estratgico. A convico de
que um componente ncleo da governana de TI atingir o alinhamento estratgico
entre TI e o resto da organizao um elemento crtico do COBIT. Entretanto, sabe-
mos que h um contnuo desafo para as organizaes em descobrir como atingir o tal
alinhamento.
Para auxiliar as organizaes a alavancar o alinhamento estratgico, os desenvolve-
dores do COBIT realizaram uma pesquisa para fornecer orientaes na compreenso
de como as metas empresariais direcionam metas de TI relacionadas e vice-versa. Esta
pesquisa foi baseada em entrevistas detalhadas e avaliaes especializadas em difer-
entes setores. Ento, uma lista genrica 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 organizaes devam comear analisando o alinhamento estratgico/TI atravs da
defnio e correlao 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 no a lucro, e governamentais. Adicional-
mente, o COBIT 5 fala sobre metas de TI.
No COBIT 5, a importncia das metas de TI caminham para o foco principal nos seus
habilitadores, como processos de gerenciamento e governana.
Dando sequncia ao artigo anterior da srie sobre os principais conceitos do COBIT
5, neste artigo vamos falar sobre o uso do balanced scorecard (BSC) como facilitador
de um processo de medio para verifcar se as necessidades das partes interessadas
esto sendo atendidas.
Para verifcar se as necessidades das partes interessadas (stakeholders) esto sendo
atendidas, deve ser estabelecido um processo de medio slido. Os mtodos de de-
sempenho atuais, como o Retorno sobre o Investimento (ROI), capturam os benefcios
dos projetos e sistemas de TI, mas refetem somente uma parte limitada (tangvel) do
150
valor que pode ser entregue pela TI.
Para facilitar um processo mais abrangente de medio, o desenvolvimento do CO-
BIT 5 incorporou conceitos do balanced scorecard. Em um dos apndices do COBIT 5
as metas empresariais e metas de TI associadas esto agrupadas sob as perspectivas
do balanced scorecard. O COBIT 5 tambm fornece exemplos de mtricas para medir
cada uma destas metas e construir um scorecard para as atividades relacionadas TI.
Alm disso, o COBIT 5 fornece medies de resultado no nvel dos 37 processos de-
talhados do framework. Logicamente, estas metas e mtricas de processos no podem
ser simplesmente comunicadas s partes interessadas, pois estes seriam sobrecarre-
gados de informao. Preferencialmente, as metas e mtricas de processos devem ser
consolidadas e agregadas de uma forma que facilite o balanced scorecard utilizvel e
compreensvel para todo o ambiente de TI. Desta maneira, obalanced scorecard per-
mite que a organizao determine se as necessidades das partes interessadas esto
sendo atendidas.
Dando sequncia a srie de artigos sobre os principais conceitos do COBIT 5, neste ar-
tigo iremos apresentar o segundo princpio do COBIT 5: Cobrir a organizao de pon-
ta a ponta.
Este princpio considera que o COBIT 5 cobre todas as funes e processo de uma
organizao. O COBIT 5 no foca somente na funo de TI, mas trata a informao e
tecnologias relacionadas como ativos que precisam ser tratados como qualquer outro
ativo da organizao.
Desta forma, os gerentes de negcio deveriam se responsabilizar por gerenciar os seus
ativos relacionados a TI assim como o fazem para outros ativos, como plantas fsicas,
recursos fnanceiros e humanos, dentro de suas prprias unidades organizacionais e
funcionais. O negcio deve assumir a responsabilidade, e prestar contas, governando
o uso da TI na criao de valor a partir dos investimentos em TI como alavanca para o
negcio.
O foco em cobrir a organizao de ponta a ponta implica em uma mudana crucial na
flosofa dos gestores de TI e de negcio. Ele compreende uma mudana do gerencia-
mento de TI como um custo para o gerenciamento de TI como um ativo. Esta mudana
um elemento essencial na criao de valor ao negcio. Se os gestores no assumirem
a responsabilidade pela TI, a empresa inevitavelmente ir jogar o oramento de TI em
mltiplas iniciativas sem uma viso clara do impacto destas iniciativas na capacidade
da organizao. Desta forma, a TI deixa de se tornar um ativo estratgico.
O COBIT 5 cobre as responsabilidades de TI e de negcios relacionados a TI. Como
demonstrao, o COBIT 5fornece grfcos matrizes de responsabilidades (RACI) para
seus processos, dos quais papeis de TI e negcio esto includos.
151
Dando sequncia a srie de artigos sobre os principais conceitos do COBIT 5, neste
artigo apresentamos seu terceiro princpio: Aplicar um framework integrado e nico.
Este princpio descreve o alinhamento em alto nvel do COBIT 5 com outros padres e
frameworks relevantes, servindo como um framework abrangente para a Governana
Empresarial de TI.
A ISACA realizou um grande esforo durante os anos para alinhar o COBIT com out-
ros frameworks, como COSO, ITIL, PMBOK, TOGAF, PRINCE2, etc. Muitos processos
do COBIT 5 so inspirados pelas orientaes destes frameworks. Por outro lado, seus
processos e prticas tambm so relacionados e alinhados com um ou mais frame-
works desta rea.
Para trabalhar efetivamente com o COBIT 5 e outros frameworks, a publicao COBIT
5: Enabling Processes inclui um mapeamento de alto nvel de cada um dos processos
do COBIT 5. Considerando que o COBIT 5 tambm integra os frameworks Risk IT e
o Val IT, torna-se uma referncia nica que inclui em seus escopos, tanto orientaes
anteriores da ISACA, quanto orientaes de outros padres e frameworks desta rea
de atuao.
Nesta abordagem ampla, o COBIT 5 identifca um conjunto de habilitadores da gov-
ernana e do gerenciamento que inclui 37 processos. Na camada de governana, h
cinco processos agrupados no domnio: avaliar, direcionar e monitorar (Evaluate, Di-
rect and Monitor EDM). Estes processos ditam as responsabilidades da alta direo
para a avaliao, direcionamento e monitorao do uso dos ativos de TI para a criao
de valor. Este domnio cobre a defnio de um framework de governana, o estabe-
lecimento das responsabilidades em termos de valor para a organizao (ex. critrios
de investimento), fatores de risco (ex. apetite ao risco) e recursos (ex. otimizao de
recursos), alm da transparncia da TI para as partes interessadas (stakeholders).
A camada de gerenciamento defnida por quatro domnios: 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 domnio APO (Alinhar, Planejar e Organizar) diz respeito identifcao de como a
TI pode contribuir melhor com os objetivos de negcio. Processos especfcos do dom-
nio APO esto relacionados com a estratgia e tticas de TI, arquitetura empresarial,
inovao e gerenciamento de portflio.
Outros processos importantes endeream o gerenciamento de oramentos e custos,
recursos humanos, relacionamentos, acordos de servios, fornecedores, qualidade, ri-
sco, e segurana. O domnio BAI (Construir, Adquirir e Implementar) torna a estrat-
gia de TI concreta, identifcando os requisitos para a TI e gerenciando o programa de
investimentos em TI e projetos associados. Este domnio tambm enderea o geren-
ciamento da capacidade; mudana organizacional; gerenciamento de mudanas (TI);
aceite e transio; e gerenciamento de ativos, confgurao e conhecimento.
O domnio DSS (Entregar, Servir e Suportar) se refere a entrega dos servios de TI
necessrios para atender aos planos tticos e estratgicos. O domnio inclui processos
para gerenciar operaes, requisies de servios e incidentes, assim como o gerenci-
amento de problemas, continuidade, segurana e controle de processos de negcio.

ITSM Na Pratica - O Caviar de 5 Anos de Postagens

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

ITSM Na Pratica - O Caviar de 5 Anos de Postagens

Загружено:

Авторское право:

Доступные форматы

REDISTRIBUIO: Voc concorda que no ir copiar, redistribuir ou explorar comer-

cialmente qualquer parte deste documento sem a permisso expressa do autor.

Вам также может понравиться