Baixe aqui. - ITSM na Prática

Transcrição

REDISTRIBUIÇÃO: Você concorda que não irá copiar, redistribuir ou explorar comercialmente qualquer parte deste documento sem a permissão expressa do autor.
CURADORIA: Renê Chiari
ITIL® é uma Marca Comercial Registrada do AXELOS Limited.
Esta obra tem apenas como objetivo contribuir com a comunidade de profissionais de
Gerenciamento de Serviços de TI. Como apoio são usadas referências de outros materiais sem infringir direitos autorais de terceiros
Copyright © 2014 - Todos os direitos reservados
1ª edição publicada em julho de 2014
www.mapadoitil.com.br
André Bernardo
Claudia Marquesani
Especialista em Gerenciamento de Projetos.
Sócio-fundador da COMMUNIT. Experiência
em gestão de projetos estratégicos. Certificados: PMP, ITIL foundation.
Consultora Sênior e instrutora especialista em
Gerenciamento de Serviços de TI. É certificada
ITIL, COBIT, ISO 20.000, ISO 27000 e TOGAF.
André Jacobucci
Consultor de Integração e Gerenciamento de
Serviços. Trabalha no setor de TI há mais de 18
anos. Sua experiência abrange vários seguimentos, incluindo serviços financeiros (banca
e seguros), Serviços de TI,
Telecom, edição e de petróleo. Possui extensa
experiência em gestão de projetos, consultoria em ITIL, COBIT e ISO / IEC 20000 , a adaptação e implementação de soluções de ITSM
e concepção, desenvolvimento e implantação
de aplicativos.
Certificações: ITIL Expert, ITIL v2 Service
Manager, ISO/IEC 20000 Consultant, COBIT
Foundations
Alberto Andrade
Especialista em operações e gestão de serviços
de TI. Treze anos de experiência no suporte, implantação e start up de projetos de outsourcing baseado em ambientes de suporte técnico,
Helpdesk e redes de dados.
Possui as certificações ITIL Foundation, MCP
Microsoft e Cisco CCNA.
Bruno Caiado
Consultor especialista em Governança e Gerenciamento de Serviços. Especializações:
ITIL®, ISO 27001, ISO/IEC 20000, COBIT,
Cloud Computing, Corporate Citizenship &
Corporate Affairs.
Carlos Afonso
Gerente de Operações. Especializações: Governance, Control, Assurance and Project Consulting in IT.
Atua há mais de 15 anos em projetos baseados
em ITIL®, ISO 20.000 e governança de TI em
multinacionais e empresas de grande porte.
Graduada pela Fundação Getúlio Vargas, é
co-fundadora do site ITSM na Prática,
Gerente de Central de Serviços e suporte é
entusiasta de novas tendências de mercado
e assuntos relacionados a gestão de serviços,
suporte e atendimento.
Claudio Dodt
Business Continuity & Security Senior Consultant, atua na área de tecnologia há mais de
10 anos exercendo atividades como técnico e
analista de suporte, Analista de Segurança Sr.,
Security Officer e Supervisor
de Infraestrutura e Segurança. Desenvolveu
atividades em empresas brasileiras e multinacionais, tendo participado no Brasil e no exterior em projetos de segurança de diversos segmentos como Educacional, Financeiro, Saúde,
Agroindústria, Indústria Alimentícia, Naval,
Metal-Mecânica e Têxtil.
Especializações: ITIL®, CISSP®, CISA, CRISC,
ISO 27001, ISO/IEC 20000, COBIT, Cloud
Computing Foundation.
Gustavo Tavares
Renê Chiari
Graduado em Administração e pós-graduado
em Gestão Estratégica de TI pela FGV. Grande
experiência com otimização de processos de
negócio por meio da TI.
Consultor especialista em Governança e Gerenciamento de Serviços de TI. Co-fundador e
administrador do blog ITSM na Prática
Trabalhou planejando e gerenciando os controles de Governança de TI e os processos de:
desenho de soluções, gestão de demandas;
gestão de projetos; qualidade de software;
gestão de serviços de TI, gestão de contratos
e gestão da segurança da informação. Atualmente lidera as iniciativas e a equipe de TI do
Comitê Paraolímpico Brasileiro.
É certificado como CBPP, PMP, ITIL Practitioner (equivalente ao atual ITIL intermediate),
SOA Solution Desiner e COBIT Foundations.
Luiz Wagner Oliveria Nascimento
Especialista em outsourcing. Experiência em
sistemas operacionais Windows e Linux, Implantação e Treinamento de pessoal em Sistema, Banco de Dados, Analise em Código Fonte,
aplicação de boas praticas
como o ITIL, ISO20000 e sempre em buscando a melhoria continua e no desenvolvimento,
implantação e gerência de Service Desk.
Nelson Granado Merino
Executivo de Contas. Co-fundador do ITSM na
Prática. Especializações:Criação de Produtos,
implantação de serviços e implementação de
processos e ferramentas de gerenciamento de
serviços de TI.
Formado em Gestão de Ambiente Internet
e Redes de Computadores, possui as certificações ITIL® Service Manager, ITIL® Expert,
ISO/IEC 20000 Associate/Consultant e COBIT 4.1. Ao longo de sua carreira profissional,
passou por grandes corporações do ramo de
Tecnologia de da Informação e consultorias
especializadas, atuando como consultor e instrutor em dezenas de projetos. Entusiasta do
assunto Gerenciamento de Serviços de TI, é
um dos fundadores do ITSM na Prática (antigamente conhecido como ITIL na Prática). Publicou mais de 70 artigos e é autor do pocket
book “ITIL na Prática: Gerenciando Problemas
de Infraestrutura e Serviços de TI”.
Roberto Cohen
Especialista em Help Desk / Service Desk / Support Center, realiza treinamento, consultoria e
palestras na temática. Atua na área de suporte
há 25 anos e treinou mais de cinco centenas
de profissionais nos últimos quatro anos.
Pós-graduado em Especialização de Psicologia nas Organizações. Associado da Sociedade
Brasileira de Dinâmica dos Grupos. Membro da
entidade mundial “The Association of Supporte
Professionals”. Palestrante sobre suporte técnico, Help Desk e Service Desk. Gold Member
do Help Desk Institute norte-americano desde 1996.
Esta obra é dedicada a todos os profissionais que dedicaram seu tempo para contribuir
e com sua vasta experiência no tema Gerenciamento de Serviços de TI e motivar a sua
discussão em todos os âmbitos, permitindo que ao longo de mais deste período de mais
de cinco anos fosse possível consolidar um material extremamente rico para a comunidade.
Artigos Temperados com Opinião �� 8
Adoção da ITIL: Santo de fora de casa faz milagres? �� 9
BYOD explodiu o CMDB. Já era essa ITIL! �� 10
Demanda instantânea por alta capacidade �� 13
Gerenciamento de Serviços de TI x Boas Práticas: Uma questão de hábito �� 14
ISO 20000 atestado de melhores práticas? �� 16
ITIL e Outsourcing Algumas peças ainda não se encaixam �� 17
ITIL e satisfacão de clientes �� 20
ITIL - O que não está nos livros? �� 22
ITIL para Inglês ver �� 24
ITILfobia �� 26
Na prática: pessoas que fazem a diferença �� 28
Os fora da lei – Porque é tão difícil seguir processos? �� 30
Porque é tão difícil gerenciar os serviços de TI? �� 33
Quando o vilão está dentro de casa �� 35
Realmente precisamos de modelos e padrões? �� 37
Seguranca da Informação e a arte de no dizer não �� 40
Artigos com Altos Índices de Teoria �� 41
A eterna e incendiária briga entre a Gestão de Incidentes e de Problemas �� 42
A importância do Plano de Continuidade �� 44
A relação entre ITIL e ISOIEC20000 �� 46
Catálogo de Serviços – O desconhecido �� 48
Como o BDGCCMDB pode aumentar a eficiência dos processos de suporte a serviços �� 51
Compreendendo a ITIL a partir de uma perspectiva nada convencional um show de rock �� 53
Do inferno ao céu – Como o exemplo do Corinthians pode ser utilizado na Gestão de Serviços �� 55
Entenda a importância da classificação do Incidente �� 57
Níveis de serviço tão necessários quanto inúteis �� 59
O conhecimento é meu e ninguém tasca �� 61
O que é Gerenciamento de Serviços de TI? �� 63
Os 10 Mandamentos da ITIL �� 65
Para que serve a ISO 20000? �� 69
Principais diferenças entre a ITIL v2 e V3 Parte I �� 72
Principais diferenças entre a ITIL v2 e V3 Parte II �� 74
Serviços: a ponte perdida entre negócios e TI �� 78
Sistemas de qualidade: a ilusão da melhoria contínua �� 80
USMBOK o ITIL para gerenciamento de qualquer serviço �� 82
Artigos para Aquecer a Carreira �� 83
Certificações abrem portas mas não garantem o seu emprego �� 84
Redes Sociais: 5 erros a serem evitados no LinkedIN �� 85
Tirei a certificação ITIL e agora? �� 87
Vale a pena investir em certificações profissionais? �� 90
Artigos Para Por a Mão na Massa �� 92
5 dicas para a Gestão de Problemas Proativa �� 93
5 passos para definir um bom Acordo de Nível de Serviço SLA �� 95
25 dicas infalíveis para que seu projeto de implantação da ITIL seja um fracasso �� 98
Catálogo de Serviços: Para que complicar? �� 100
ITIL – é preciso saber vender �� 102
Pessoas: o calcanhar de Aquiles na adoção da ITIL �� 104
Problemas – como identificá-los? �� 107
Profissionalizando a gestão dos projetos de TI e ITSM Parte I �� 108
Profissionalizando a gestão dos projetos de TI e ITSM Parte II �� 110
Profissionalizando a gestão dos projetos de TI e ITSM parte III �� 112
Tempo para solucionar problemas: mais um problema ou a solução? �� 115
Transformando sua poltica de segurança da informação em um ativo estratégico �� 116
Artigos com toque de tecnologia �� 121
A gamificação invadiu nossa praia �� 122
ITSM, redes sociais e Content Management Systems dá jogo? �� 124
O que as ferramentas não fazem por você �� 126
Artigos Exlcusivos do Chef �� 128
Os desafios da criação de valor atráves da Operação de Serviços �� 129
O que são incidentes, problemas, erros conhecidos e requisições de serviço segundo a ITIL? �� 130
Gerenciamento da Configuração e Ativos de Serviço: o processo “camarada” da ITIL® �� 133
Qual a diferença entre o Gerenciamento de Mudanças e o Gerenciamento de Liberação e Implantação? �� 135
A ITIL é uma moda? �� 136
4 métricas para monitorar o desempenho de uma CMDB (Configuration Management Database) ��
137
O que é um Service Desk (ou Central de Serviços)? �� 139
Tipos de Service Desk, qual o mais adequado? �� 140
Melhores Práticas ou Boas Práticas, qual é o certo? �� 142
O que é um Plano de Capacidade? �� 143
A razão pelo qual um incidente não “vira” um problema �� 145
10 coisas que você deveria saber sobre a ITIL �� 146
Compreendendo os principais conceitos do COBIT 5 �� 148
Artigos Temperados com Opinião
Adoção da ITIL: Santo de fora de casa faz milagres?
GUSTAVO TAVARES
Como profissional de gestão de TI tive várias oportunidades de trabalhar prestando
consultoria. Uma grande parte planejando e implementando iniciativas baseadas em
ITIL®. Uma questão que inicialmente me deixava curioso era o porquê de as empresas
preferirem optar por consultores a utilizar recursos internos. Curiosidade reforçada
pelo fato de que, em quase todas estas oportunidades, encontrei nas empresas às quais
prestei serviços pessoas qualificadas e bem preparadas para liderar iniciativas semelhantes. Aos poucos a experiência foi me ensinando e finalmente consegui algumas
respostas que saciaram a minha curiosidade. São muitas as vantagens da utilização
de consultores externos nas iniciativas de adoção da ITIL® (existem também algumas
desvantagens), mas acredito que o ponto chave seja o seu posicionamento hierárquico na organização. Iniciativas de planejamento e adoção da ITIL® são, fundamentalmente, iniciativas de mudança organizacional. E um profissional externo, não ligado às
estruturas e controles já existentes, possui maiores chances de obter sucesso em um
processo de mudança organizacional. De forma resumida, poderíamos utilizar o velho
adágio para questionar: Em iniciativas de adoção da ITIL®, santo de fora de casa faz
milagres? Resumidamente a resposta é sim, desde que conte com o apoio dos santos
da casa.
Isto porque a eficiência de consultores externos em iniciativas de adoção da ITIL® possui limites. Os consultores são peças fundamentais por que possuem o conhecimento
técnico necessário e a liberdade de opiniões e críticas que pode não existir dentro da
organização. Entretanto, a responsabilidade pela tomada de decisões a respeito do
desenho dos processos e de alterações nas estruturas é exclusiva dos gestores. Não
cabe ao consultor escolher qual o melhor processo ou qual a melhor linha de subordinação de determinada função dentro da organização. O consultor não está inserido na
cultura organizacional da mesma forma que o gestor para entender e diagnosticar as
consequências deste tipo de alteração. Seu papel, neste caso, é orientar a tomada de
decisão ressaltando os riscos e os benefícios de cada opção existente. Quem possui a
responsabilidade de determinar os requisitos e sua relação com os objetivos de negócio deve ser alguém de dentro da própria organização.
O gestor, quando transfere a responsabilidade por estas decisões ao consultor, está
na verdade se abstendo de determinar o modo de funcionamento de sua área de responsabilidade. Corre com isto o risco de ser responsável por gerenciar algo com o qual
não concorda ou mesmo não conhece. Situação onde o sucesso do novo processo ou
da nova estrutura fica comprometido, afinal , sem apoio, “nem santo de fora de casa
consegue fazer milagres!”
ITSM na Prática - O caviar de 5 anos de postagens
9
BYOD explodiu o CMDB. Já era essa ITIL!
ROBERTO COHEN
Uma consequência da disseminação dos dispositivos móveis é que os funcionários agora realmente acessam dados corporativos de tudo quando é canto. Na praia, no boteco,
em casa etc.
Isso já é manjado, só é novidade pra quem ainda não acordou.
E as empresas tentaram entrar na onda oferecendo Blackberrys, iPhones e iPad (e seus
similares) para os funcionários. Só que as tecnologias similares – ao alcance de compra dos próprios funcionários – começaram a ficar muito baratas. E com isso vieram as
ondas da Consumerization e Gamefication. A última tentando obter proveito desse
contato mais íntimo com os devices móveis para fazer os usuários aprenderem através
de games (sei lá, pense no Show do Milhão ou Quem quer ser um milionário com perguntas contextuais a um ERP, por exemplo). E a primeira, Consumerization, um olhar
atônito sobre o usuário trazendo seu Mcbook de casa e tentando conectá-lo na rede
corporativa da empresa.
Bom, a situação apertou (piorou) para o suporte técnico.
Do BYOD
Agora chegou o BYOD – Bring Your Own Device. Traduzindo, Traga Seu Próprio Device. Traga seu lanche, sua maçã e o seu dispositivo móvel de preferência pro serviço!
Ou seja, as empresas sacaram o seguinte: por que vou empurrar um Samsung Galaxy
III se o sujeito manja tudo de iPhone e será muito mais eficiente nesse ambiente do que
o obrigando a aprender outro modelo de smartphone?
Eu também não preciso dizer que isso se torna muuuito mais barato, em termos de investimento de hardware, para a empresa, hehe. Outra vantagem é que, em vez das empresas fazerem cotação para migrar do BlackBerry versão um para versão 10 (exemplo
hipotético) depois de 4 anos, os usuários estão, por sua conta, fazendo isso todo ano e
aproveitando as facilidades dos planos de pontuação das empresas de telefonia celular. Ou seja, estando sempre up-to-date com os releases, livrando-se da, muitas vezes,
lenta burocracia das empresas.
Se quiser ler mais sobre o BYOD, visite:
en.wikipedia.org/wiki/Bring_your_own_device
PCWorld – Pros and Cons of Bringing Your Own Device to Work
Pra terem uma ideia de como isso é novo, ainda não existe o verbete em português na
Wikipedia. Eu não achei, pelo menos.
10
Opa, e as questões legais?
Aí o cachorro morde o próprio rabo. Num artigo muito interessante publicado no ITWeb, a jovem advogada Patrícia Peck Pinheiro aponta uma série de incômodos no Brasil relacionada a essa tendência de “Traga seu dispositivo para o serviço”:
De quem é a responsabilidade se o device contiver conteúdo ilícito?
O acesso 24×7 num dispositivo particular (do próprio funcionário) configura sobreaviso e hora extra, pela ótica das leis trabalhistas?
Quem é o responsável pela segurança do dispositivo?
Perdas ou extravios do dispositivo, quem responde, a empresa ou o dono?
E a coisa vai longe, bro. Leia o artigo original no blog dela dentro do ITWeb: Questões
legais do BYOD – a regra tem que estar clara
E o ITIL?
Caramba, e agora?
Como organizar o CMDB (Configuration Management Database)? Como construir um
banco de dados de tudo que configura um determinado serviço quando nem sabemos
qual o dispositivo que o usuário comprou e utiliza? E se o “maluco” migrou para a recém-lançada versão do iPhone? Ou do Xoom (tablet da Motorola)? Ou sabe-se-lá o que
estará na moda amanhã…
A biblioteca britânica recomenda cadastrar tudo para encontrarmos rapidamente os
pontos de defeito de um serviço, por exemplo. Mas como o técnico atenderá um usuário que utiliza um browser que ele nunca ouviu falar na vida?
Eu sei que nós do suporte técnico poderíamos argumentar que:
O device do usuário não está cadastrado e nem homologado pelo suporte técnico e
por isso sujeito a vírus;
Isso pode aumentar o custo de operação, por que não conhecemos o mesmo e vai gerar treinamento, atraso no atendimento etc.;
Uhhh, a lista é gigantesca para comentar…
Mais complicações “en aire“: e se o usuário pedir suporte para questões pessoais e não
propriamente corporativas, como o suporte deve se comportar? O horror é saber que
a maioria dos departamentos de suporte no Brasil não especificou ainda um catálogo
de serviços que, por mais banal que fosse, ajudaria o técnico e usuário a saberem o que
é ou não padrão ou ofertado como auxílio.
Ihhh, e se o usuário pedir demissão? Alguém limpará as informações e aplicativos armazenados no smartphone dele?
11
Na real, foi-se pro espaço aquele controle que desejávamos fazer sobre os itens de
configuração componentes de um serviço (Alguém viu o filme “Dama de Ferro“? Não é
à toa que o ITIL lá nasceu, hehe).
Nossa, existe um blá-blá-blá imenso rolando na internet sobre isso. E, como é de costume, ninguém sabe muito bem o que fazer, hahahaha.
Ambientes complexos
Ao ler esses temas, magneticamente sou conduzido ao livro Pensando diferente, para
lidar com a complexidade, a incerteza e a ilusão.
A ideia central do Humberto Mariotti é que achamos que podemos controlar as coisas. Mas muitas (a maioria) não conseguimos.
Ele faz uma diferenciação didática entre sistemas complicados (um relógio é complicado, cheio de pecinhas, mas conseguimos ter alguma precisão) versus sistemas complexos (aqueles habitados por seres humanos onde dificilmente podemos projetar com
certeza o futuro para daqui a uma semana).
O Humberto está numa outra fase das teorias além dos sistemas sistêmicos (Peter
Senge e organizações que aprendem é um dos expoentes máximos desse conceito). É
importante compreender que ele não recomenda o abandono da objetividade, metas
e gestão dos processos. Só que é importante incluir nisso tudo os conceitos de erro,
incerteza e ilusão.
Por que escrevo isso, ainda mais se o título era outro?
Por que é preciso aceitar a incerteza. Não vai dar para programar tudo. A incerteza vai
permear o primeiro nível de atendimento que não saberá como atender um Firefox
para Android ou situações parecidas.
E o gestor deve e precisa saber o que fazer (ou, ao menos, pensar sobre) as situações
que apresentam novos paradigmas contestando o bê-a-bá aprendido no curso de ITIL.
E agora, Manoel, o que fazer?
Smack
12
Demanda instantânea por alta capacidade
RENÊ CHIARI
Compra de ingressos online, clubes de compras coletivas e leilões de um centavo. O
que estes serviços tem em comum?
1. A disponibilidade é a razão de ser do negócio.
2. Lidam com grandes demandas em frações de segundos.
A característica principal destes serviços é de manter o site disponível mesmo com
avalanches de cliques simultâneos. Nem sempre dá certo…
Manter uma infraestrutura capaz de suportar altas demandas pode sair caro demais
se considerarmos que estas demandas são esporádicas. Mesmo terceirizando, a dúvida é se os provedores de serviço de outsourcing já estão preparados para esta novo
conceito de prestação de serviços. Eu particularmente apostaria neste nicho de serviço, que eu tomei a liberdade de chamar de “Instantaneous demand for high capacity”,
ou Demanda Instantânea por Alta Capacidade. Se o nome já existir, ótimo, acertei na
mosca, caso contrário vou patentear! (uma busca no Google não trouxe nenhum resultado hehehe…)
Algumas recomendações da ITIL® fazem sentido, e até são aplicadas. Por exemplo a
“pré-venda” de ingressos para um grupo seleto de clientes de uma instituição financeira já é uma forma de influenciar a demanda, mesmo sabendo que o objetivo principal
neste caso é trazer novos clientes, aqueles que já não aguentam mais lidar com travamentos de site no horário em que as vendas começam para o público “normal”.
Os leilões de centavos procuram mesclar produtos de valores altos e baixo, em horários distintos, inclusive de madrugada, para influenciar a utilização constante e justificar o investimento na infraestrutura.
Por outro lado, a falta de maturidade em gerenciamento de serviços de TI está evidente nestas empresas (e muitas outras da América Latina – veja uma análise de dados do
Gartner aqui) . Basta fazer uma rápida busca em sites como o Reclame Aqui para encontrar um grande número de reclamações de Clientes que clicaram mas não ganharam, ou que nem sequer conseguiram clicar, pela indisponibilidade dos sites. Também
existem reclamações sobre a transparência e credibilidade dos sites, mas isso é assunto pra abordar em outro post.
Vale lembrar que a intenção deste e possíveis outros artigos não é de colocar em discussão se estes são modelos de negócio bons ou ruins, confiáveis ou não. São modelos
que estão ai a pleno vapor e podem influenciar a discussão de novas abordagens para
gestão de TI.
13
Gerenciamento de Serviços de TI x Boas Práticas:
Uma questão de hábito
ALBERTO ANDRADE
Quando o assunto é Gerenciamento de Serviços de TI, a ITIL frequentemente apresenta-se como um “herói invisível”, raramente reconhecido como tal. O entendimento do
framework como referência de boas práticas ainda é interpretado de forma equivocada por muitos profissionais que buscam em sua aplicação a solução de todos os seus
problemas e frustram-se nas primeiras dificuldades de implementação, justamente por
esta falha de entendimento.
Algo que ainda ouço com muita frequência são afirmações quanto à impossibilidade
de aplicar as ditas “boas práticas” em cenários de produção. Igualmente comuns são
aqueles que asseguram que a ITIL não tem utilidade real, o que reflete a visão limitada
de muitos profissionais de TI e áreas relacionadas. Independente do cargo ou atividade, o que se deve ter em mente é que uma biblioteca de boas práticas segue o caminho
inverso frente às metodologias tradicionais. É tudo aquilo que já foi eficiente no mercado e vem como sugestão de uso, por isso não é um conjunto de regras pré-estabelecidas. Estas propostas nada mais são do que indicações perfeitamente adaptáveis de
milhares de outros como nós que já percorreram o mesmo caminho e nos indicam as
pedras para que não tropecemos, afinal de contas, quem quer reinventar a roda? Geralmente quando um profissional com histórico de resultados satisfatórios depara-se
com a ITIL®, sua primeira percepção é: “Isso tudo me parece muito familiar...”. Oportunamente, pois foram reunidos muitos comportamentos e atitudes comuns e estes foram nomeados e categorizados como processos, subprocessos e assim sucessivamente.
Veja o bullying, por exemplo. Esta palavra que, confesso, tive que recorrer ao Google
para não falhar na grafia, nada mais significa do que os velhos atos de violência física e
psicológica que muitos de nós sofremos na infância. É antigo, só não tinha nome, cada
um chamava como queria (e eu sinceramente queria esquecer!). O mesmo ocorre com
a ITIL®. Muita gente torce o bico, mas pratica (mesmo contra a própria vontade) todo
dia. Compare com a nossa própria vida. O ser humano, em sua individualidade possui
uma série de comportamentos, bons e ruins, comuns no seu cotidiano. Imagine uma
biblioteca de boas práticas como um conjunto de diretrizes contendo instruções que
você já exercita e outras que pode começar hoje. O sucesso não está necessariamente
atrelado a pratica de todo o conteúdo destas “sugestões” e sim do uso que se faz delas.
Você pode não exercitar-se, nem se alimentar bem hoje, mas sabe que é bom pra você.
Se trouxer pra rotina, terá muitos ganhos. Se não trouxer, não significa necessariamente que irá morrer amanhã (assim espero!!!).
Portanto, boas práticas de mercado, muito mais do que mudança estrutural, exige mu-
14
dança de cultura e comportamento. É benchmarking, tomando referência de tudo o
que funcionou e poderia igualmente funcionar em sua rotina. Desta forma, se a maioria dos processos é familiar a você mesmo que você nunca tenha estudado a biblioteca
parabéns, provavelmente já esteja no caminho certo. Por outro lado, se não conseguir
agregar nenhum destes bons frutos à sua rotina, pode ser a hora de uma quebra de
paradigma. Independente do nome que se dê, bons hábitos sempre trazem benefícios
e isso é indiscutível, pois, assim como afirmou Aristóteles, “somos aquilo que fazemos
repetidamente, desta forma, excelência é um hábito.”
15
ISO 20000 atestado de melhores práticas?
RENÊ CHIARI
A norma ISO/IEC 20000 foi lançada em dezembro de 2005, sendo a primeira norma
ISO voltada exclusivamente para gerenciamento de serviços de TI.
Os requisitos da norma estão totalmente alinhados ao ITIL®, e em alguns momentos
chegam a deixar mais claros alguns aspectos. Além disso, ela aborda temas como responsabilidades da direção de forma mais incisiva (herança da ISO 9001).
Em fevereiro de 2008, a ABNT lançou a versão brasileira da norma, que tem o mesmo
conteudo.Desde então, muitas empresas iniciaram a busca pela certificação.
Atualmente, de 12 a 15 empresas brasileiras possuem a certificação (não sei pq, mas o
site oficial www.isoiec20000certification.com não possui informações atualizadas...).
Há uma estimativa de que em 2010, 80% dos grandes e médios provedores serão certificados e várias organizações clientes estarão certificadas, enquanto 2011 será o ano
da maturidade. Certificar não será mais um diferencial e sim um requisito de mercado
(Fonte: consultoria Brunise).
É certo que a conquista do selo ISO 20000 tem o foco voltado principalmente para diferencial de mercado, melhora da confiança por parte dos investidores, satisfação dos
clientes, etc...mas é possível também utilizar-se da norma como referência de qualidade para a implantação do ITIL®, e de certa forma, atestar o sucesso da implantação,
mesmo que a certificação oficial não seja almejada.
Ainda que para os céticos seja apenas mais uma moda do mercado, e que a conquista
do selo não é garantia de qualidade, as empresas serão motivadas a “engrenar” e manter a qualidade, uma vez que as constantes manutenções da certificação obrigarão elas
a agir desta forma.
16
ITIL e Outsourcing Algumas peças ainda não se
encaixam
RENÊ CHIARI
A ITIL®, apesar de ser uma das melhores referências para gestão de serviços de TI, nos deixa
com vários pontos de interrogação quando abordada em um ambiente de provedores de Outsourcing. Na verdade, a biblioteca tem um foco muito forte em organizações internas de TI,
e por isso essa “lacuna”.
Recentemente fiz algumas buscas em foruns e sites sobre essa questão e descobri que
não estou sozinho, e que muita gente que trabalha ou trabalhou em provedores de
Outsourcing têm problemas em adequar a ITIL® neste ambiente.
Algumas das principais dificuldades apontadas são:
Processos Fim-a-fim
A ITIL® pressupõe que você tenha controle sobre todos os serviços, mesmo quando
você tenha um fornecedor terceiro. Em Outsourcing geralmente existem pelo menos
dois stakeholders (a TI interna do Cliente e o fornecedor de outsourcing).
Mas geralmente existem outros fornecedores e parceiros de outsourcing e uma prática comum é dividir a prestação de serviços para a infra-estrutura e aplicações entre
dois diferentes fornecedores.
Em situações como esta, mesmo que todos adotem ITIL®, terão sua própria adaptação
dos processos, incluindo os seus próprios instrumentos, procedimentos, relatórios e
gerenciamento de dados.
Isto representa um enorme potencial de conflito, pois mesmo que o cliente tenha especificado o alinhamento com a ITIL® como um pré-requisito para o outsourcing, é muito
difícil quando se trata de Gestão de Incidentes, Problemas e Mudanças. Por exemplo,
um usuário liga para um Service Desk terceirizado, que registra um incidente na ferramenta XPTO, que compõe a sua solução de ferramentas integradas de ITSM.
O usuário acredita que é um problema de infra-estrutura e então o incidente é atribuído à equipe de suporte a infra-estrutura terceirizada. Na realidade o incidente acaba
por ser um erro de aplicação - portanto um chamado tem que ser registrado junto ao
provedor de aplicações terceirizado, que utiliza o XYZ em sua solução integrada de
ITSM.
Na transferência, os detalhes se perdem e o provedor de aplicações tem que chamar o
usuário para fazer mais perguntas. O tempo de resolução do incidente é ultrapassado,
e quem é o responsável por isso? Quem é o “dono” do processo fim-a-fim?
A solução para este problema deve ser uma estrutura de governança cuidadosamente
17
planejada e implementada que assegura que todos os fornecedores trabalhem juntos
de uma maneira eficaz. A ITIL® V3 deixou claro no livro de estratégia de serviço que a
responsabilidade de fazer isso cabe ao Cliente.
A menos que seja nomeado um contratado para sub-contratar todos os outros fornecedores, o único ponto consistente de governança deve ser o próprio Cliente. Isso precisa ser desenvolvido na estratégia de terceirização e gerenciado desde o início.
Onde está o meu Cliente?
Todos os processos de entrega de serviços da ITIL® supõe que você tenha um cliente
comercial para trabalhar, mas muitos são os contratos de terceirização com o departamento de TI da organização do cliente.
Essa relação com um outro provedor de TI afeta muitos aspectos da prestação de serviços, mas especialmente em SLM, onde o conceito de SLA “baseado no negócio” é muitas vezes rejeitado por um contrato negociado por uma equipe de TI que é muito técnica / baseada em OLA. Como um fornecedor de outsourcing, só podemos esperar que
o provedor interno de TI tenha vigente com os seus cliente internos um bom processo
de SLM.
Outro aspecto é que o SLM é difícil de implementar em um ambiente comercial. Ele
simplesmente não leva em conta as pressões comerciais para ‘ganhar’ o negócio.
Ligando ao ponto sobre como lidar com os departamentos de TI, isto pode significar
também que os objetivos não são ainda ligados aos requisitos reais de negócio. Este
tipo de má gestão das expectativas do cliente leva a sérios problemas mais tarde.
Três outros processos especialmente demandam o envolvimento ativo de Clientes de
negócio: o Gerenciamento de Capacidade de Negócio, o planejamento da continuidade do negócio e a análise de impacto sobre a empresa no Gerenciamento de Mudanças, respectivamente.
A solução para isso não é tão clara. Uma compreensão realista da maturidade do seu
cliente, papéis funcionais e estruturas podem ajudar a identificar potenciais problemas. Além disso, mais esforço e empenho durante a transição para definir claramente
o nível de envolvimento do cliente de negócio também vai ajudar.
A ITIL® V3, infelizmente, não oferece muita ajuda sobre este problema específico. Somente com o claro entendimento de com quem você está lidando, e quais são suas
necessidades o que ele quer irá suporta-lo, e talvez, esquecendo o SLM e procurando
ajuda no Gerenciamento de Fornecedores como guia.
ITIL® é ITIL® em todos os lugares, mas ninguém entende
Muitas licitações citam a ITIL®, incluindo processos pro-ativos e de planejamento,
como o Gerenciamento de Problemas Pró-ativo, Gerenciamnto de Disponibilidade e
18
Capacidade, mas atualmente não há um bom entendimento do que isso realmente significa.
Isto se reflete de várias formas, mas normalmente em um simples “copy and paste” de
parágrafos da bibilioteca, incluindo KPI´s dos quais são transformados posteriormente em metas, com multas associadas.
O problema surge quando aqueles que escrevem a proposta comercial e aqueles que
lêem o fazem com (no máximo) um conhecimento teórico do ITIL® e pouca compreensão dos verdadeiros problemas associados à criação, desenvolvimento, gestão e medição de tais processos.
Um exemplo comum é o requisito para estabelecer o gerenciamento de configuração
com uma meta de 100% de exatidão no primeiro dia de prestação de serviços; isso
em uma organização que não tenha qualquer atividade vigente de Gerenciamento de
Configuração. No mundo real, leva-se de 6 a 12 meses para implementar e adequar um
processo de gerenciamento de configuração eficaz, que requer um considerável investimento inicial e quase nunca entrega tudo com 100% de precisão.
Outro exemplo são as “produtizações” de processos ITIL®. Não é raro encontrar serviços onde o cliente precisa pagar para ter gestão de capacidade, sendo que esta atividade intrinsicamente já deveria estar sendo coberta como um requisito básico de
qualidade e entrega de serviços.
Adicionalmente, a maioria dos processos de planejamento ou estratégicos tem foco em
investir para melhorar, ao invés de pagar por falhas. As implicações do mal compreendimento disso é das organizações verem o Outsourcing puramente como redução de
custos.
Novamente, a solução para esta questão não é fácil, e a ITIL® V3 não apresenta respostas simples. O segredo é a educação e formação para todos os envolvidos, tanto o
cliente quanto o fornecedor, de modo que os motivos pelos quais a relação de terceirização está sendo baseada sejam claramente compreendidos.
Conclusões
A boa notícia é que a V3 está muito mais clara, com uma abordagem mais integrada
de gestão de serviços, já está reconhecendo muitas das dificuldades identificadas na
V2 e sugerindo soluções. Maaas, cuidado...a ITIL® (mesmo a V3) não é uma referência
a ser utilizada isoladamente. O sua utilização em um ambiente de Outsoutcing deve
ser adaptada cautelosamente. Podemos usar ITIL® V3 para ajudar, mas há muito mais
educação e formação necessárias a todos!
19
ITIL e satisfacão de clientes
CLAUDIA MARQUESANI
Parece uma frase bastante pessimista para quem tem um site chamado ITIL® NA
PRÁTICA , mas tenho realmente que ser realista: IMPLEMENTAR A ITIL® NÃO GARANTE
A SATISFAÇÃO DO CLIENTE. Pelo contrário , dependendo do grau de insucesso, pode
até influenciá-la negativamente! Utilizamos tanto a palavra ALINHAR A ESTRATÉGIA
DE TI À ESTRATÉGIA DE NEGÓCIO, que realmente estou até cansada (e o mercado
também!) de falar disso. Por isso resolvi brincar um pouco hoje!
Qualquer semelhança com a PRÁTICA é uma mera coincidência...rsrs
Tantas e tantas vezes as melhores práticas são implementadas sem levar em conta a
estratégia de negócio e as características da organização , que realmente a cena acima
não é irreal! O que devemos fazer então para que a implementação da ITIL® seja um
sucesso e traga valor para o negócio?
OUÇA (REALMENTE) O CLIENTE.
Sim, eu sei que é difícil. Mais que ouvir, é preciso conhecer o seu negócio, ENTENDER
o que ele está dizendo , infuenciar positivamente as tomadas de decisão... Não é uma
tarefa fácil, mas por isso que foi feita especialmente para os profissionais envolvidos
no gerenciamento de serviços de TI!!! :D
ADOTE E ADAPTE as melhores práticas ás necessidades da sua organização e ouça
seu cliente para montar a estratégia dessa adaptação.
Para finalizar (como estamos de bom humor hoje), uma piadinha para descontrair... espero que gostem.
A VOZ DO CLIENTE
No aeroporto o pessoal estava na sala de espera esperando a chamada para embarcar. Aparece então o Co -piloto, todo uniformizado, de óculos escuros e de bengala, tateando pelo
caminho. A atendente da companhia o encaminha até o avião e assim que volta, explica que,
apesar dele ser cego, é o melhor Co-piloto da companhia.
Alguns minutos depois, chega outro funcionário também uniformizado,de óculos escuros, de
bengala branca e amparado por duas aeromoças.
A atendente mais uma vez informa que, apesar dele ser cego, é o melhor piloto da empresa
e, tanto ele quanto o Co-piloto fazem a melhor dupla da companhia.
Todos os passageiros embarcam no avião preocupados com os pilotos.
O comandante avisa que o avião vai levantar vôo e começa a correr pela pista, cada vez com
mais velocidade. Todos os passageiros se olham, suando, com muito medo da situação. O
20
avião vai aumentando a velocidade e nada de levantar vôo. A pista está quase acabando e
nada do avião sair do chão. Todos começam ficar cada vez mais preocupados. O avião correndo e a pista acabando. O desespero toma conta de todo mundo.
Começa uma gritaria histérica no avião.
Nesse exato momento o avião decola, ganhando o céu e subindo suavemente.
O piloto vira para o Co-piloto e diz:
- Se algum dia o pessoal não gritar, a gente tá F... (tradução: ferrado)!!!!!!
Moral da história:
OUVIR OS CLIENTES É FUNDAMENTAL!!!
21
ITIL - O que não está nos livros?
GUSTAVO TAVARES
Embora seja promovido como o padrão “de facto” para as operações de TI, muitas são
as dúvidas a respeito da eficiência e do sucesso na adoção da ITIL® nas organizações.
E isto não sou eu quem está dizendo. Uma das maiores consultorias mundiais especializada nas boas práticas já fez reclamações a respeito. Particularmente, apesar de
não contar com informações para comprovar, eu apostaria que mais da metade das
iniciativas de adoção da ITIL® no Brasil não obtém o sucesso esperado. Isto a despeito
de serem realizadas por profissionais com certificação de fundamentos, praticante ou
gerente (foundations, practitioner e manager).
A razão dos insucessos? Eu não saberia responder ao certo. Mas acredito que um fator
em específico tem um peso muito grande. E é a este fator que o post esta relacionado.
A ITIL® passou por uma evolução recente. A versão anterior (2) era focada exclusivamente nas operações de TI. Embora quando considerado em seu total ela contemplava
uma análise geral da área de TI das organizações, na prática do mercado ela se concentrava na entrega e no suporte aos serviços de TI; atividades exclusivas da parte de
operações. A evolução para a versão corrente (3) trouxe uma reorganização das áreas
de conhecimento. Reforçando a intenção inicial de contemplar a visão geral da área
de TI, ela chegou a estender o modelo para as áreas de posicionamento e formulação
das estratégias. Embora as duas versões possuam grandes diferenças, ambas possuem
também um conjunto de características fundamentais. E uma destas características é
que as duas versões são baseadas em processos. Apesar de a versão corrente possuir
uma orientação para o ciclo de vida dos serviços, ela ainda tem como base os processos de TI.
Por ser baseada em processos, a adoção da ITIL® é um pouco mais complexa do que é
descrito nos livros e ensinado nos cursos de formação. A implementação de processos
em um ambiente de TI ou “de negócios” demanda uma ecologia organizacional que difere da ecologia tradicional. Os comportamentos, sistemas de recompensa e estruturas
tradicionais são, na maioria das vezes, incompatíveis com as práticas necessárias para
gerenciar processos. Por tradicional – no sentido deste post – podemos entender as
estruturas funcionais departamentalizadas e baseadas em uma hierarquia claramente
definida.
Apesar da própria literatura reconhecer a necessidade de um ambiente que favoreça
a adoção de processos (Service Strategy, seção 2.6), as implementações baseadas na
ITIL® quase sempre partem do princípio que a ecologia organizacional necessária para
implementação e gerenciamento de processos existe e esta madura na organização
destino. O que eu acredito ser, na realidade Brasileira, uma raridade.
Com estas considerações é importante ressaltarmos que: antes de implantar o geren-
22
ciamento dos serviços de TI baseado na ITIL® a organização deve necessariamente
ser fluente em gestão de processos. Ela deve possuir uma ecologia organizacional receptiva as práticas de gestão de processos, o que quer dizer uma estrutura organizacional adequada, sistemas de recompensa que reforcem os objetivos dos processos e
um modelo de gestão com os estilos adequados.
É verdade que a ecologia organizacional e as práticas aqui denominadas tradicionais
não impedem sempre a implementação de modelos de gerenciamento de serviços de
TI baseados na ITIL®. Processos conseguem, em situações particulares, serem implementados e gerenciados neste tipo de ambiente. Mas somente em situações particulares e onde, principalmente, as especificidades deste tipo de ecologia organizacional
são consideradas no projeto de implementação.
Para quem busca mais informações a respeito da ecologia organizacional adequada à
adoção de processos, sugiro uma olhada no Business Process Maturity Model – BPMM.
É um modelo de maturidade, baseado no CMM, que busca medir a capacidade de organização de utilizar processos.
23
ITIL para Inglês ver
GUSTAVO TAVARES
Hoje é mais raro. Mas ainda acontece. Planeja-se uma iniciativa para adoção de ITIL®,
monta-se uma equipe, iniciam-se os trabalhos e alguém fala: “Este negócio de ITIL® é
só para Inglês ver! Aqui na nossa empresa não funciona!”... E depois de escutar estas
afirmações, se considerarmos os resultados obtidos por grande parte das empresas,
acabamos ficando desconfiados se isto não seria verdade.
Como profissional com alguma experiência em iniciativas de adoção do ITIL®, eu posso
afirmar que estes posicionamentos não são totalmente verdadeiros. E a palavra chave
aqui é “totalmente”.
Como é de conhecimento de quase todos os profissionais que conhecem o ITIL®, sua
origem é Britânica. A motivação inicial ainda está sob a névoa das lendas. Algumas
dizem que está relacionada com a Guerra das Malvinas, outras dizem que tudo foi apenas uma idéia muito boa de uma equipe melhor ainda. Mas é certo que o ITIL® surgiu na terra do Rei Arthur, do Beckham e do Harry Potter. E como não podia deixar de
ser, acabou trazendo o que a Inglaterra tem de bom e também o que tem de mau. Eu
particularmente não sei dizer que existe de ruim na Inglaterra, e também não sei o que
tem de bom além da Keira Knightley e da Guinness; mas sei que a Inglaterra e o Brasil
são países bem diferentes.
Mas apenas saber que são diferentes não é o suficiente. Nós, profissionais que trabalhamos com gestão de TI, precisamos saber em que ponto estes países são diferentes e como isto impacta as iniciativas de adoção do ITIL®. Em minha defesa como
profissional, posso dizer que apesar de não saber quais são todas as diferenças eu sei
quem sabe.
Em um post recente do meu blog particular eu indico um livro muito interessante para
os profissionais que trabalham com ITIL®. O livro é do professor Geert Hofstede que
entre 1967 e 1973 realizou uma pesquisa com empregados de 70 países da IBM. A
partir desta pesquisa, ele desenvolveu um modelo de cultura organizacional dividido
em cinco dimensões; que possibilita comparar como as pessoas de um país compreendem e respondem a diversas iniciativas gerenciais.
O modelo é direcionado às populações dos países. Não é um modelo para ser aplicado a
diferentes organizações de um mesmo país. Ele busca diagnosticar quais valores e comportamentos uma população entende e aceita como normal. Um deles, a dimensão de
distância hierárquica, por exemplo, busca demonstrar o quanto as pessoas percebem
como é válida a distribuição desigual do poder. Em países com alta distância hierárquica um subordinado está menos propenso a questionar ou discutir as determinações
de um superior. O subordinado interpreta que uma pessoa hierarquicamente superior é melhor ou mais capacitada simplesmente pela sua posição. Por outro lado, em
24
países com baixa distância hierárquica, as pessoas acreditam que o poder não deve ser
distribuído apenas pela posição no organograma. Elas consideram que outros fatores
como capacitação, perfil, tempo de casa são também fonte de poder. São também mais
propensas a questionar e discutir as ordens vindas de escalões superiores e acreditam
que não existe nada de errado com esta atitude.
As outras dimensões são igualmente importantes na avaliação das culturas de diferentes países. A dimensão masculinidade, por exemplo, mede o quanto os valores masculinos são mais relevantes que os valores femininos na população de um país. E por
valores masculinos devemos entender a competição e o confronto. Por outro lado devemos entender os valores femininos como a colaboração e a confraternização. Um
país com alto índice de masculinidade não quer dizer que existem mais homens ou mulheres no mercado de trabalho. Quer dizer apenas que os homens e mulheres deste país
ou região são mais direcionados à competição e ao confronto do que à colaboração e à
confraternização.
Como é de se esperar, os índices apresentam valores diferentes para o Brasil e para a
Inglaterra. Estes valores diferentes devem ser observados com cuidado pelos profissionais que buscam liderar iniciativas de adoção do ITIL®. Quais aspectos do framework
dependem de um baixo índice de distância hierárquica? Quais iniciativas do ITIL® são
baseadas em um índice alto ou baixo de masculinidade? Quais as outras dimensões do
modelo do professor Hefstede devem ser consideradas? Quais adaptações ao framework são necessárias para ressaltar os pontos fortes da cultura Brasileira?
Quem sabe com estas preocupações nós que trabalhamos com ITIL® não façamos do
framework também “um negócio para Brasileiro ver!” :)
25
ITILfobia
RENÊ CHIARI
Quem já participou de um projeto ou iniciativa de adoção da ITIL® sabe bem que a
foto ao lado ilustra muito bem um dos maiores desafios durante a implementação: a
RESISTÊNCIA!
Não importa qual o segmento da empresa, seja instituição pública ou privada, a realidade é exatamente a mesma. Quando há necessidade de uma mudança organizacional
(e para adotar o ITIL®, geralmente é necessária essa mudança), somos recebidos com
flechas!
O principal motivo que alavanca essa reatividade é o medo das pessoas em perderem
posições cômodas, de não ter mais o controle individual e intelectual das informações,
de ter que “zerar” todo o conhecimento adquirido, e de um dia para o outro, se deparar
com uma nova realidade e uma nova forma de fazer as coisas.
Para tentar lidar com este desafio, podemos utilizar uma formula de Administração,
mais precisamente de Peter Drucker: M = D + M + P > R
Onde podemos interpretar:
M=> Mudança (a necessidade de mudar)
D=> Desconforto (eventos adversos, insatisfação dos Clientes, etc)
M=> Modelo (qual o modelo proposto, por ex: ITIL®, CobiT, etc)
P=> Plano/Projeto (qual o plano para implementar este modelo)
R=> Resistência (o grau de resistência das pessoas envolvidas na mudança)
Note que a soma de D + M + P deve sempre ser maior que R. Se em um determinado
momento notar que a resistência é maior, está na hora de elevar o grau dos itens precedentes, de preferência da direita para a esquerda, por exemplo:
P=>Revise o seu plano/projeto, pode ser que algo não foi bem definido, o plano de comunicação não está sendo eficiente, etc
M=> Reveja o modelo proposto. Será que somente ITIL® resolve tudo? Talvez seja
necessário utilizar-se de outras práticas como CobiT, ISO 20.000, BSC..
D=> Esta é a última opção, se nenhuma das anteriores funcionar, gere desconforto.
Se necessário , é preciso entender que as reclamações do cliente podem aumentar no
primeiro momento (como na implementação de um Service Desk) , mas o COMPROMISSO GERENCIAL DEVE SER MANTIDO. Como na figura, se aos poucos os envolvidos
pararem de remar, o barco nunca chegará ao seu destino.
Encarar de frente este desafio e MANTER O COMPROMISSO COM O PROJETO EM
TODOS OS NÍVEIS GERENCIAIS é um dos fatores críticos de sucesso de uma mudança
26
organizacional. Implementar ITIL® não é um projeto com início , meio e fim. É uma
catequese e um programa de melhoria constante, como a própria biblioteca diz: P-DC-A (Planejar, Fazer, Checar e Agir).
27
Na prática: pessoas que fazem a diferença
RENÊ CHIARI
Recentemente recebi um e-mail com o título: “Nova Era do Radar em SP - Atenção !!!”,
que descrevia em detalhes os locais em São Paulo onde os novos radares serão instalados. A frase final me chamou a atenção:
“Retransmitam, é duro trabalhar para sustenter mais isso!!”
O mais engraçado é que as pessoas criam uma grande mobilização para “burlar” sistemas de segurança ao invés de fazer o que tem que ser feito, que nesse caso seria simplesmente respeitar a leis de trânsito vigentes!!
Em nosso mundinho quadradinho de TI aconteçe o mesmo. Vários controles são criados exclusivamente para identificar se as pessoas estão fazendo o que devem fazer.
Uma tremenda perda de tempo que poderia ser gasta com coisas mais produtivas e
com valor agregado ao negócio.
Um exemplo clássico são as auditorias. Nada contra auditores e nem contra as ISO´s,
mas vamos combinar, da pra contar nos dedos o número de empresas que realmente
tem uma cultura madura em relação a isso. As ISO´s deveriam ser uma referência para
nortear a qualidade ideal para as empresas e serem vistas como uma forma de identificar o que não está bom e melhorar (os radares tem o mesmo objetivo, não?) mas na
realidade elas são utlizadas basicamente para dois fins:
• Aparecer em formato de selo no site institucional da empresa;
• Apavorar funcionários mal orientados em épocas de auditoria.
A cena é sempre a mesma: dado o anúncio de uma auditoria interna, todos correm
como loucos atrás de disponibilizar evidências de seus trabalhos, com o único objetivo
de não ter nenhuma não conformidade, e assim “burlar” o sistema de auditoria. Se perguntarmos pra maioria qual o real motivo dos controles, poucos saberão responder.
Um outro exemplo. Um palestrante certa vez contou sobre uma montadora de carros
que anualmente abria as portas para que todos (inclusive os concorrentes) conhecessem seus processos, políticas, sua forma de trabalhar. Um visitante questionou se aquilo não poderia oferecer algum risco à empresa. A resposta foi mais simples do que se
podia imaginar: vocês podem copiar nossos processos, nossa forma de trabalhar, mas
será difícil fazer acontecer se os seus funcionários não tiverem o mesmo comprometimento que nossos funcionários tem.
Talvez valha mais a pena investir em concientização, em pessoas com perfis adequados as suas atividades, em metas individuais alinhadas a ganhos financeiros para os
funcionários que atingirem suas metas, a automatização de processos a fim de evitar
erros humanos, do que em projetos voltados exclusivamente a auditar o trabalho dos
28
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 pisando muito no acelerador. Essa é uma questão que tem uma abrangência muito além de
gestão de serviços e governança. É uma questão cultural!!
Investir em processos, controles, e sistemas são importantes, mas no final das contas,
pessoas é que fazem diferença...
29
Os fora da lei – Porque é tão difícil seguir
processos?
CLAUDIA MARQUESANI
Hoje estou com uma incrível crise existencial. No meio de uma grande revolta, comecei
a pensar : PORQUE EU DESENHO PROCESSOS E AS PESSOAS NÃO OS SEGUEM? É
uma cultura do brasileiro? Será que lá fora é assim? Será que o objetivo é ficar “livreleve-solto”? Será que achamos interessante ser “fora da lei”? Nossa cultura não gosta
das “amarras” de um processo? O que será que acontece?
Vamos falar um pouco sobre PROCESSOS hoje e porque é tão difícil segui-los. Um assunto polêmico, mas é gerando polêmica que evoluímos...
Antes de mais nada, vamos definir o que é processo. Dentre várias definições, aí vai
uma simples e direta: “Processo é uma sequência de tarefas (ou atividades) que ao serem executadas transformam insumos em um resultado com valor agregado.”
E pra que criamos processos?
• Para garantir a retenção e pulverização de conhecimentos individuais;
• Para controlar e monitorar as atividades, podendo identificar os pontos de melhoria;
• Para garantir que todas as atividades necessárias sejam desempenhadas para a
entrega do produto final de acordo com os critérios de qualidade estabelecidos;
Tudo isso em teoria...porque na PRÁTICA...salve-se quem puder!!!!
São procedimentos operacionais que incorretamente recebem o nome de processo e
ninguém consegue enxergar o SERVIÇO por trás daquele documento enorme...
São processos “fracos”, onde seus participantes em determinado momento pensam:
para que serve tudo isso mesmo que eu estou fazendo?
Aqueles processos que “lembramos” vagamente que existem...mas que nunca lemos ,
entendemos ou participamos a fundo. Normalmente executamos atividades realizadas nesse processo, no “piloto- automático”, sem ter a visão do todo, dos requisitos de
qualidade e de controles do necessários.
Esse tipo, muito comum e o pior de todos, é chamado de PROCESSO PARA INGLÊS
VER!
O que é isso? Todos sabem que ele está lá, mas todos preferem ignorá-lo até o dia em
que uma auditoria ou outra verificação do dia a dia é anunciada. Nesse momento, “O
INGLÊS”, precisa ver e tudo é feito as pressas para atendê-lo. Não faz parte da cultura,
não faz parte do dia a dia, faz parte de um evento isolado e distante daqueles que real-
30
mente deveriam entendê-lo e segui-lo.
Vou dar um exemplo, completamente fora de TI para ilustrar o que escrevi anteriormente. Toda segunda-feira, é apresentado no Canal National Geografics, um programa
chamado MAYDAY. Podem me chamar de “doente” (rsrs), mas ele trata dos principais
acidentes aéreos da história da aviação mundial. O que isso tem a ver com nosso dia a
dia? O processo de investigação, que mostra porque os acidentes aéreos acontecem é
um verdadeiro aprendizado para quem trabalha com serviços. Falhas, são, quase sempre causadas por processos que poderiam ter sido melhor desenhados para evitar erros humanos.
Em um dos programas do mês passado, foi apresentando um acidente, onde um avião,
decolou e minutos depois, o vidro da cabine estourou. O piloto foi arremessado para fora
do avião e ficou preso durante 20 minutos voando com o corpo para fora da aeronave.
Ele milagrosamente sobreviveu (isso nem a ITIL® explica!) . Dois tripulantes morreram e todos os outros passageiros (fora o susto) se salvaram após um pouso forçado.
Vários investigadores renomados foram chamados para entender porquê o vidro havia estourado. Após muitas avaliações técnicas e psicológicas, finalmente descobriram.
Resumindo:
O avião tinha passado por manutenção dois dias antes e vidro da cabine havia sido
substituído. E a história é longa...
Para substituir o vidro, o mecânico deveria ir até o computador, consultar o tamanho
do parafuso que fixaria o vidro, buscar os parafusos corretos no estoque e utilizá-los
para fixar o novo vidro na aeronave.
Sabem o que o mecânico fez ao envés de seguir esse passo a passo? Comparou o parafuso que ele retirou do vidro que estava sendo trocado e pegou um de tamanho igual
que já havia em sua oficina. Infelizmente, o parafuso que esteve fixado durante muito
tempo no avião, tinha tamanho incorreto para aquele tipo de aeronave. O problema só
não tinha ocorrido antes, porque o parafuso estava muito bem fixado. Ao troca-los, o
mecânico estava em uma posição desconfortável e deixou frouxos aqueles parafusos
que não tinham o tamanho adequado. Resultado: 5 minutos após a decolagem eles se
desprenderam e causaram o acidente.
O investigador perguntou porque o mecânico não havia ido até o sistema consultar o
código para selecionar os parafusos corretos para a troca. Ele obteve a seguinte resposta: “o sistema é lento, levaria aproximadamente 20 minutos para fazer a consulta.
Eu tinha que entregar a aeronave para o vôo até as 6 horas da manhã do dia seguinte.
Não daria tempo de seguir um processo tão burocrático e ao mesmo tempo cumprir
minhas metas”.
Depois disso, foi fixado o código de todos os parafusos nas mesas dos mecânicos, para
31
evitar que problemas como esses voltassem a acontecer.
Moral da história: por mais que o processo seja bem desenhado, se ele não for funcional, esqueçam! Eles devem estar adequados as necessídades do NEGÓCIO (no caso,
agilidade para trocar o vidro com a máxima segurança). Também devem estar bem divulgados e devem ser redivulgados constantemente...
Pensando bem, será que a “culpa” de processos que nunca são seguidos e de serviços
prestados com baixa qualidade, não está nas mãos de quem desenha os processos, divulga e deveria patrociná-los (nossos gestores) ??? Quem são os verdadeiros “fora-dalei” aqueles que não sabem ouvir e desenhar o que é necessário, aqueles que não divulgam adequadamente aquilo que necessita ser seguido ou aqueles que se recusam a
seguir algo que é totalmente burocrático e sem sentido? Pensem nisso...
32
Porque é tão difícil gerenciar os serviços de TI?
CLAUDIA MARQUESANI
Um aluno meu do curso de manager me disse uma frase que acabou virando este post…
ele disse: “Quando a TI perceberá que não vale a pena fazer milagres? Tudo que o negócio
pede a TI se mata para entregar, quase sempre sem planejamento e a qualquer custo…”
Vamos falar um pouco sobre isso…
Quem é o cidadão que trabalha com TI que nunca se sentiu em uma pastelaria, entregando pasteis do sabor que o cliente quer, quando quer (mesmo que o oleo não esteja na temperatura correta para deixar um pastel crocante) , inventando sabores de
ultima hora a pedido do cliente? O fato é que , a maioria das organizações ainda trabalha
de forma bastante desplanejada e a TI acaba entrando nesse círculo vicioso.
A cena é mais ou menos a seguinte: a pessoa de negócios chama a pessoa responsável
por TI (normalmente o CIO) e diz : PRECISO DE UM PROJETO XYZ PARA ONTEM!!!
O CIO de cara diz que não é possível para a data solicitada , porque precisa avaliar a
estratégia, desenhar o projeto adequadamente , transicionar e operacionalizar a idéia.
Então, a área de negócios insiste: preciso disso para ontem!!! E enfim, o responsável
por TI concorda com a data totalmente inadequada para a realização de um projeto do
porte solicitado.
Então ele sai quase sempre tendo uma síncope da sala , resmungando e depois transforma o resmungo em um grande brado para seus subordinados (insourcing ou outsourcing, dependendo do caso): “PRECISAMOS DO PROJETO XYZ PARA ONTEM!
FAÇAM ACONTECER” E assim a roda gira (nem sempre redondinha). São projetos e
mais projetos quadrados, que quando entram em produção já entram com problemas
no desenho de disponibilidade, capacidade, falhas no processo de atendimento de incidentes e mudanças e com um service desk totalmente despreparado para manter o
novo serviço. excessão
Sim, podem me chamar de pessimista, mas duvido que pelo menos uma vez, ninguém
nunca tenha participado de um projeto assim. Porque isso ocorre?
Primeiro, porque salvo raras exceções, a organização de TI de uma empresa nem sempre é respeitada. É vista como um custo (muito alto, diga-se de passagem), para a área
de negócios e uma “área-problema”.
Segundo, porque o ciclo de vida de um serviço não é respeitado. A ITIL® v3 deixa isso
muito bem organizado citando em cada um de seus livros uma fase do ciclo: estratégia,
desenho do serviço, transição, operação e melhoria contínua. Antes de dizer se é possível fazer ou não, é preciso entender e possuir uma estratégia de TI alinhada, incorporada a estratégia de negócios. TI não deve mais ser vista como uma área problema
e sim como parte da estratégia do negócio de uma organização, pois as organizações
33
dependem cada vez mais de TI para obter eficiência e eficácia em suas operações.
Se não é possível entregar um projeto no prazo, ou nas condições desejadas, é preciso negociar, explicar, mostrar tecnicamente que se isso for feito, o projeto não irá criar VALOR para o negócio. Para criar valor, TI precisa apresentar duas características
no serviço prestado: garantia (serviço com qualidade na entrega) e utilidade (cliente
percebe o serviço com um efeito positivo).
TI só poderá se surpreender com um pedido se estiver longe do negócio, se não estiver focando e definindo suas estratégias para aquilo que realmente agrega VALOR
para o cliente. Não existe MILAGRE em tecnologia, existe PLANEJAMENTO, ORGANIZAÇÃO e GESTÃO.
Como conseguir isso? Implementando um bom gerenciamento de serviços de TI, utilizando a ITIL® como melhor prática e combinando-o com outros frameworks que apóiem a governança, como por exemplo, o COBIT. Nem sempre vale a pena FAZER MILAGRES, entregar as coisas correndo, sem planejamento, sem um desenho adequado e
com uma qualidade duvidosa. Para fugir desse “mundo de horrores” é necessário implementar uma TI que tenha visão voltada para o negócio e para como Ela poderá auxiliar para que ele atinja seus objetivos.
Obviamente, se hoje você trabalha em uma organização onde não existe nada, se você
está bem distante de todas essas palavras bonitas escritas nos livros, saiba que isso é
absolutamente normal. Para se atingir um nível adequado de gestão de serviços e governança é preciso antes de mais nada COMEÇAR. Não espere atingir o mundo perfeito
em meses. A realidade é diferente, existe a cultura das pessoas que precisa ser alterada e uma mudança comportamental rumo à gestão de serviços é lenta e gradual. Mas
com certeza, implementando alguns processos de gestão ganhos rápidos virão, que
poderão trazer benefícios não somente para a TI, mas principalmente para o negócio.
Mãos a obra? Abaixo os MILAGRES e vamos rumo a Gestão e governança. Cada vez
mais organizações têm ciência disso e iniciam projetos de implementação de processos ITIL®, CoBIT, ISO20000. Não dá para imaginar uma organização competitiva que
não faça a gestão de seus serviços de forma eficiente e eficaz. E o nome disso não é milagre, é futuro!
34
Quando o vilão está dentro de casa
CLAUDIO DODT
Uma pesquisa recente da Venafi apontou um sério risco que, infelizmente, é cada vez
mais comum em organizações de qualquer vertical ou porte: Uma boa parcela (estimada em 40%) dos colaboradores de TI admite poder causar sérios problemas, leia-se
caos completo, nos serviços/infraestrutura da organização.
O caso específico abordado pela pesquisa reflete dados sobre falta de gerenciamento
de chaves de criptografia associada a lacunas controles internos e pouca segregação
de funções. Entretanto, existem incontáveis outros cenários onde um único colaborador pode tornar a organização sua refém e indiscutivelmente causar prejuízos na casa
dos milhões como em um caso ocorrido na prefeitura de São Francisco em 2008 que
teve sua WAN seqüestrada por 12 dias (leia mais).
Esse assunto não é nenhuma novidade e já foi amplamente discutido. O problema é
que em boa parte das empresas com que já tive contato vejo pouca ou nenhuma iniciativa para contornar essa situação chegando ao ponto onde em alguns casos é tido
como algo “normal”.
Se você vivencia este tipo de problema em sua organização existem algumas práticas
simples que podem ajudar bastante:
1. Uma boa política de segurança da informação é essencial: Se seus colaboradores
estão conscientes das implicações legais de suas ações eles certamente vão pensar
duas vezes antes de cometer um ilícito. No pior cenário se um incidente severo ocorrer você vai estar protegido e legalmente preparado para tomar as ações cabíveis.
2. Segregação de funções (SoD): Provavelmente você sabe que SoD é um método para
reduzir o risco de que uma única pessoa possa acessar, modificar ou usar serviços sem
a devida autorização ou detecção. O que talvez você não saiba é que, de acordo com
o Public Company Accounting Oversight Board, em 83% das organizações a causa de
fragilidades materiais estava diretamente relacionada com ausência de Segregação de
Funções. Uma boa matriz de segregação (ver exemplo) associada à rotação de cargos e
funções pode ajudar a evitar incidentes e apoiar na distribuição conhecimento.
3. Documentação, documentação e documentação: Manter uma documentação atualizada é essencial para proteger o conhecimento institucional. Infelizmente, existe uma
notória resistência por parte da maioria profissionais de TI que acabam deixando algo
tão importante completamente de lado. Cabe aos gestores entender a importância e
exigir que uma parcela do tempo da equipe seja dedicada exclusivamente a elaboração
de documentação e procedimentos operacionais.
4. Use a tecnologia a seu favor, mas não se torne dependente: Desde gerenciamento
de chaves de criptografia até a sistemas de auditoria e análise do comportamento é
35
possível dizer que existe uma solução tecnológica para quase tudo. Saber aplicar a tecnologia a seu favor é reconhecer que não podemos ser completamente dependentes.
Busque soluções completas que englobem não apenas um produto, mas procedimentos, normas e até mesmo as pessoas necessárias para criar uma solução eficiente.
5. TTTO (Talk to the Ogre): Muitos dos profissionais que gostam de se sentir insubstituíveis o fazem por uma nítida insegurança. Manter um canal de dialogo aberto e, em
casos extremos, até mesmo um acompanhamento psicológico pode ajudar e muito na
redução de riscos e incidentes. Um bom gestor consegue perceber um problema de relacionamento logo no início , onde sua solução é razoavelmente simples. Um mau gestor pode fechar os olhos e até mesmo ser conivente com a situação. Nesse ultimo caso
certamente vale a máxima: Quem planta vento, colhe tempestade!
A lista acima certamente não é completa, mas espero que essas dicas práticas ajudem
a lidar com os Shreks mal entendidos que residem dentro da TI.
Links e referências:
drupal.sfexaminer.com/local/crime/2011/05/judge-orders-former-city-worker-terry-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
36
Realmente precisamos de modelos e padrões?
BRUNO CAIADO
Os homens adoram modelos e padrões. Prestem atenção nas escolas e vocês verão
uma infinidade de referências tentando explicar como o mundo, com toda a sua beleza
e complexidade, funcionou, funciona, deveria funcionar ou irá funcionar. Isso ocorre em
coisas simples como a forma como classificamos períodos históricos e vai até a complicados modelos matemáticos e probabilísticos para comportamentos sociais, econômicos e até planetários. O Universo se expande ou se contrai de acordo com alguns modelos e não se comportar de acordo com eles mostra que ou o modelo inteiro está errado
ou existem outras variáveis ainda não consideradas. Até o comportamento de tribos
indígenas está sujeito a modelos segundo alguns estudos. Um estudo conduzido por
um antropólogo americano tentou demonstrar que brigas e agressões aparentemente
aleatórias entre índios seguiam um “padrão” que obedecia a regras codificadas em seus
genes. E até mesmo a aparente desordem do mundo também parece seguir uma ordem subjacente guiada por modelos descritos, por exemplo, pela teoria do caos. Nem
de dentro, nem de fora, conseguimos fugir de um “enquadramento”.
Pois então fico aqui com algumas perguntas que me assombram:
• Será que somos meros agentes que seguem padrões definidos ou mesmo programáveis?
• Será que modelos e padrões são capazes de descrever ou controlar tudo o que
realmente precisamos fazer?
• Será que modelos servem para descrever ou controlar coisas “abstratas” como serviços ou estamos em um exaustivo trabalho tentanto controlar as coisas erradas
ou da forma errada?
Vamos para um exemplo simples. O gerenciamento de disponibilidade descreve um
“momento da verdade” que é o próprio momento da indisponibilidade. Esse momento não é simplesmente um “gatilho para você executar um troubleshooting”, mas uma
grande oportunidade para você demonstrar uma atitude em relação à falha. Sim, atitude, que se traduz em demonstrar ao cliente, de diversas maneiras, que você está
tomando todas as ações necessárias, que você está atento às necessidades dele e que
você está tentando minimizar ao máximo o impacto causado pela falha. Ou seja, afinal
de contas que você se importa com ele. Mas espera aí, eu não estou implantando um
processo? Como vou garantir uma “atitude” correta usando um processo? Se por “atitude’ você entende dizer “tenha um bom dia” no final de uma compra em um supermercado, com um sorriso amarelo no rosto, então sim, você consegue fazer isso com
um processo. Se por atitude você entende um desejo genuíno em servir, que afinal é a
essência da prestação de um “serviço”, então provavelmente não.
Pois essa é uma questão que envolve a própria natureza pessoal do que chamamos de
37
“serviço”. Um bom relacionamento entre cliente e prestador e uma boa atitude ao prestar o serviço podem minimizar enormemente o impacto de falhas ou até ser o principal fator de satisfação, maior inclusive que a qualidade técnica do entregável em si. E
isso se aplica a qualquer contexto de prestação de serviços. Uma pesquisa feita junto
a pacientes e médicos mostrou que os pacientes que tinham um bom relacionamento
com seus médicos tinham pouquíssima pré-disposição a processá-los, mesmo em caso
de falhas muito graves. Pacientes que recebiam “pouca atenção” dos médicos tinham
uma tendência a serem muito mais rigorosos e críticos, com uma pré-disposição a processá-los mesmo em caso de falhas menos graves ou mesmo nenhuma falha “técnica”.
A conclusão é estarrecedora. Mesmo que você implante um modelo rigoroso de
prestação de serviços, baseado em práticas como ITIL, você pode estar falhando miseravelmente em prestar um bom serviço na perspectiva do cliente. Isso significa que os
aspectos “soft” da prestação de serviços podem estar sendo severamente negligenciados em detrimento do compliance a modelos ou padrões, o lado “hard”. Entenda-se
como aspectos “soft” a atitude, o bom relacionamento, a conscientização, o engajamento, o alinhamento por consenso, o comportamento guiado por princípios e não
pela obrigação, o equilíbrio, a justiça e a capacidade inata em servir.
Os melhores consultores de ITSM sabem disso. Mas o fato é que a pressa, a falta de sensibilidade ao aspecto humano, a pressão por ganhos exagerados sem um ganho de maturidade contínuo e natural, o pressuposto de que o software faz sozinho o “processo”,
a falta de co-participação das pessoas no processo de criação do “modelo” e a preguiça
em fazer melhoria contínua na ilusão de que relatórios gerados “automaticamente”
irão magicamente fazer isso sozinhos acabam por minar o lado “soft” da implantação.
E o resultado pode variar desde a implantações desastradas até a implantações razoavelmente bem sucedidas, mas que deixam a sensação de que no fundo, “excelência
em serviços” era muito mais do que aquilo que alcançamos.
Culpa do modelo? Talvez não. Modelos ainda são necessários e o ITIL é um bom exemplo de modelo que nasceu sob o mote do “adote e adapte”, mas acabou caindo na vala
dos “frameworks” encaixotados em processos pré-desenhados, ferramentas vendidas
como ITIL-in-a-box e promessas mirabolantes de consultores aventureiros. No meio
do caminho esqueceram do adapte e prometeram um adote rápido e indolor. Simplesmente porque é o adapte que exige o verdadeiro consultor. O adote se resume a replicar coisas prontas de uma referência. O adapte exige experiência, sensibilidade, conhecimento e paciência. Coisas que o próprio negócio dos clientes às vezes ignora, mas
que o verdadeiro consultor não pode ignorar deixando-se levar pelas respostas fáceis
que o cliente quer ouvir. Em meio às pressões insanas que os negócios de hoje fazem
em seus líderes, o verdadeiro consultor é aquele que consegue trazer os princípios
chave e unir esses princípios à sua experiência, guiando estes líderes no meio do turbilhão para um caminho factível, mas sem respostas prontas e sem perder de vista um
caminho de longo prazo.
38
Essa união entre “princípios” e “experiência” compõe o equilíbrio entre uma adoção
rígida demais e uma adaptação excessiva em que os benefícios se perdem. Para achar
esse equilíbrio é preciso entender o que é “rígido demais” e “adaptativo demais”. Na
minha visão, “rígido demais” é mais fácil de identificar. Toda vez que alguém ignora necessidades genuínas do cliente em prol de ser compliant com o que o ITIL “determina”,
temos um caso de rigidez excessiva. O outro lado da moeda é mais sutil, porque exige
que tenhamos com clareza quais são os princípios fundamentais que não podem ser ignorados ou mesmo distorcidos. Um exemplo clássico é o CMDB. Qual o princípio chave
do CMDB ou do processo de gerenciamento de configuração? Não, não vale ir lá no livro e copiar a definição. Esses princípios não estão no livro, porque eles são uma “essência” que é compreendida com o tempo e a experiência de cada consultor. O princípio
chave é ter um único CMDB? Não. O princípio chave é a ferramenta? Não. O princípio
chave é exigir que todas as tarefas do processo sejam executadas? Não. O princípio
chave, baseado na minha experiência como consultor, é o seguinte: ter armazenada a
informação relevante sobre os serviços para manter os serviços funcionando e projetar novos serviços. Tão simples quanto isso. Mas muitos estão fazendo o contrário: à
partir de um modelo operacional pronto (e não de princípios chave!), estão tentando
encaixar à força um modus operandi, tentando convencer as empresas de que isso é o
“certo”. Esse é um erro fatal. Cada empresa tem seu modus operandi e isso precisa ser
respeitado, sendo papel do consultor comparar esse modo de operação com os princípios chave e ir, aos poucos e de forma conjunta, criando um modo de operação guiado
pelos princípios que realmente farão a diferença naquele contexto.
Notem um ponto interessante: uma série de necessidades adicionais acabam surgindo
à partir do princípio chave, mas não necessariamente como princípio chave de um único
processo. Um exemplo: porque precisamos compor o gerenciamento de configuração
com um gerenciamento de mudanças? Porque o ITIL “mandou”? Não. Simplesmente
porque sem um processo de mudanças mantendo as informações atualizadas seria impossível que a informação se mantivesse relevante e o benefício simplesmente se perderia. Percebam que nesse caso, uma adaptação que criasse um CMDB sem qualquer
tipo de controle de mudanças seria uma distorção de princípios chave e não seria uma
adaptação válida. E é exatamante aí que modelos e consultores mostram seu valor.
Como guardiões de princípios chave que são fonte de evidentes benefícios e que se
implementados com paciência, sensibilidade, engajamento coletivo e continuidade,
podem criar não apenas serviços de excelência, mas pessoas conscientes de seu papel
e capazes de prover esses serviços.
39
Seguranca da Informação e a arte de no dizer não
CLAUDIO DODT
Profissionais que trabalham na área de Segurança da Informação convivem com um
conflito quase diário. Se de um lado temos uma equipe focada na proteção das informações, adoção de controles e preocupação com os riscos, do outro temos os usuários
que muitas vezes querem simplesmente trabalhar.
Essa pequena batalha acaba criando uma falsa impressão de que a área de segurança
da informação só sabe dizer não. O que acaba sendo uma verdade parcial.
O problema é que uma boa parte dos profissionais de segurança ainda tem a percepção de que “não se pode confiar no usuário” ou que “não adianta explicar que o usuário
não vai entender”. O problema é que essa falta de diálogo faz com que os usuários se
cansem e acabem por contornar ou mesmo esquecer os aspectos relacionados à segurança da informação.
Idealmente, um bom departamento ou profissional de segurança deve pensar como
um fornecedor de soluções o que muitas vezes implica em parar de ditar o que pode
ser feito e abrir espaço para o diálogo, trocar o não por um “talvez” ou “depende”.
Ouvir e entender demandas é um passo essencial para o alinhamento com usuários e
buscar uma solução segura e eficiente.
40
Artigos com Altos Índices de Teoria
41
A eterna e incendiária briga entre a Gestão de
Incidentes e de Problemas
CLAUDIA MARQUESANI
Não adianta. Creio que este seja um dos maiores assuntos e “calos nos pés” de quem
trabalha com a gestão de serviços de TI. A eterna briga entre os participantes e os gerentes dos processos de gerenciamento de incidentes e problemas.
Vamos as definições rápidas. Essas duas disciplinas tem interesses relativamente conflitantes. O objetivo do gerenciamento de incidentes é restabeler a operação normal
do serviço o mais rápido possível - resolver o incidente. Como dizem lá na minha terra
“apagar incêndios”...
Já o objetivo do Gerenciamento de problemas é investigar as causas subjacentes (causas raízes, aquelas que se resolvidas, solucionarão definitivamente o problema). Isso
é feito não para todos os incidentes, mas para aqueles considerados críticos para o
negócio: de grande impacto ou recorrentes. O pessoal da gestão de Problemas quer
entender , investigar e descobrir “porque pegou fogo” e acompanhar a implementação
de medidas para que novos incêndios não ocorram.
Mais ou menos assim: durante um incêndio, os integrantes da equipe de gestão de incidentes são os bombeiros. A equipe de gestão de problemas trabalha como os peritos,
que entram depois (na grande maioria das vezes) que o incendio acabou, para investigar o que foi o causador do incêndio.
Com esse exemplo , fica bem claro entender porque tantas organizações fracassam na
implementação e operação do processo de gerenciamento de problemas.
É claro, que o chefe da equipe de bombeiros e dos peritos não deve ser o mesmo. Eles
tem metas e objetivos diferentes. E também é claro que um bombeiro não pode ser
perito e vice versa. Imaginem o perito/bombeiro lá, investigando as causas de um incêndio e rapidamente é chamado para apagar fogo em outro bairro... para qual chamada ele dará prioridade?
Analogias a parte, é exatamente isso que acontece no dia a dia de uma equipe que
precisa solucionar incidentes e ao mesmo tempo resolver problemas. O suporte técnico está lá, iniciando a investigação da causa raiz de problema e... rapidamente é interrompido para solucionar OUTRO incidente!! Obviamente a gerencia de incidentes
sempre terá prioridade sobre a gerencia de problemas...principalmente se a quantidade de “bombeiros/peritos” for escassa.
E voltando para nosso exemplo, qual é a moral da história?
O bombeiro (A EQUIPE DE INCIDENTES) ajuda o perito (A EQUIPE DE PROBLEMAS)
, com informações valiosíssimas sobre o incêndio (onde, quando começou, quais fo-
42
ram suas características) e INFORMAÇÕES SOBRE O INCIDENTE (classificação, priorização, informações sobre a atuação e encerramento).
O perito (A EQUIPE DE PROBLEMAS) ajuda o bombeiro (A EQUIPE DE INCIDENTES),
investigando (OS PROBLEMAS) e levando soluções (ATRAVÉS DE MUDANÇAS) para
que novos incêndios não ocorram. Também oferece, através de suas investigações, novas técnicas para apagar incêndios mais rapidamente e adequadamente (SOLUÇÕES
DE CONTORNO MELHORES PARA AS EQUIPES DE SUPORTE TÉCNICO).
No final das contas, qual papel é mais importante? Não adianta brigar, ambos são importantes! Se por um lado é preciso combater todos os incêndios (INCIDENTES) , por
outro não adianta observar um incêndio em cada esquina todos os dias, ocasionado
pelo mesmo motivo - como por exemplo má instalação elétrica e não fazer absolutamente nada (PROBLEMAS que são relacionados a incidentes recorrentes, por exemplo).
Um deve complementar, ter sinergia, auxiliar e não entrar em conflito com o outro,
porque, apesar de diferentes, os papéis do gerenciamento de incidentes e problemas
são complementares. Juntos, eles trazem benefícios para a organização de TI, para os
usuários e para os clientes que são tangíveis - menor desgaste da equipe de TI, maior
confiança da parte do cliente e aquilo que toda organização precisa para garantir sua
sobrevivência - aumento da eficiência e ECONOMIA de custos.
Uma semana “quente” para todos e até a próxima. :)
43
A importância do Plano de Continuidade
CLAUDIO DODT
Uma matéria publicada na revista ComputerWorld, edição 536, do mês de maio, cita um
estudo global feito por uma empresa de segurança com 1,7 mil gestores, em 2010 envolvendo 18 países, tinha como objetivo entender quais eram os grandes dificultadores para recuperação em desastres. Segue alguns resultados desse estudo:
•
•
•
•
32% sistemas virtuais não contam com backup regular.
Apenas 1 em cada 4 entrevistados usam tecnologia de replicação para proteção.
68% dos servidores virtuais não contam com planos para recuperação de falhas.
51% das empresas, no Brasil, afirmam que procedimentos de backup ocorrem apenas semestralmente.
Os dados dessa pesquisa, abrem espaço para falar a respeito de plano de continuidade
de serviços de TI e junto com isso, até mesmo, primariamente, plano de continuidade
dos negócios.
Esses dados são no mínimo curiosos e constatam uma realidade já percebida no dia a
dia das empresas, as vezes parece que tem que acontecer a tragédiadesastre com a empresa ou com organizações próximas, para que questões de continuidade de negócio, e
consequentemente TI, comecem a entrar em pauta das discussões. Um exemplo clássico, as tragédias no vale do Itajaí em 2008. As diversas empresas, TI e outras, públicas
e privadas, tinham pouquíssimos ou nenhum planejamento para continuidade. Hoje a
realidade é um pouco, veja bem, um pouco diferente. Já existem planos para continuidade em casos de tragédias que ajudam a minimizar os impactos para o negócio.
A ausência de um plano de continuidade de negócios (PCN), muitas vezes é usada como
justificativa para a ausência de um plano de continuidade para serviços de TI. Essa justificativa tem um certo fundo de razão, pois é o negócio é que determinará o que é realmente crítico para o negócio e irá nortear qual deverá ser a disponibilidade esperada
para os serviços de TI. Se o contrário ocorrer, continuidade dos serviços de TI, baseado
apenas em TI, pode gerar custos e uso de recursos desnecessários.
Dessa forma, não existe plano de continuidade de serviços de TI, sem plano de continuidade de negócio. É interessante, nesse momento, citar também a diferença entre gerenciamento de disponibilidade e continuidade de serviço. O primeiro gerenciamento
preocupa-se em manter o serviço funcionando da melhor maneira possível e o maior
tempo possível, já a continuidade, trata das ações de recuperação e continuidade, caso
aconteça algum desastre que interrompa a disponibilidade de tais serviços.
Penso que o momento atual das empresas e nossa sociedade, é oportuno para desenvolvimento e validação de planos para continuidade de negócio. A medida em aumentamos a dependência por serviços de tecnologia da informação, devemos aumentar
44
nossos planos para continuidade desses serviços em caso de interrupções graves, que
podem, em muitos casos, decretar a morte da empresa.
É isso grande abraço. Até o próximo artigo.
45
A relação entre ITIL e ISOIEC20000
LUIZ WAGNER OLIVEIRA NASCIMENTO
Atualmente, o ITIL é utilizado como referência para empresas desenvolverem estratégias de serviços envolvendo o planejamento e a gestão da demanda, gestão da qualidade,
acompanhamento dos resultados financeiros para os serviços e a divulgação destas informações em seus catálogos de serviços. Verifica-se também que adoção destas práticas abrange também o planejamento do serviço que considera aspectos importantes
como o dimensionamento da capacidade, segurança, níveis de serviço visando assegurar a continuidade e sustentabilidade do processo. Após realização do planejamento
inicia-se a fase de implantação do processo para o ambiente de produção, incluindo os
processos de ativos/configurações de serviços, mudanças, release, testes e avaliação.
Quando um determinado serviço está pronto e devidamente testado e aprovado, é
realizada uma passagem dos levantamentos realizados para o ambiente de produção.
Os processos e funções como central de serviço, incidentes, requisições de mudança,
eventos e acesso são utilizados durante este processo. Finalmente é apresentada uma
referência para a melhoria contínua, considerando algumas práticas recomendadas
por Deming o ciclo PDCA.
Tudo estaria correto, e funcionaria perfeitamente, se não fosse um detalhe: Como o ITIL
é uma referência, de que formata garantir a efetividade, implantação e sua sustentação
ao longo do tempo? A abordagem apresentada no ITIL não garante que os processos
sejam efetivamente implementados em seus requisitos mínimos. O ITIL é descritivo,
onde descrevemos as melhores ações a serem tomadas. Deveria existir algo que servisse como um guia, para determinações do tipo “deve existir um plano de capacidade!”
que pudesse ser avaliada quanto à sua eficácia e eficiência. Neste aspecto, a ISO 20000
atua complementando o ITIL, o Cobit e seus processos de Delivery e Support, atua de
forma parecida, porém seu foco é “o que fazer” sob a visão da Governança de TI e não
em Gestão da Qualidade de Serviços de TI. Como o processo necessita ser implementado de forma organizada existe a ISO 20000 que é um padrão internacional de qualidade, projetado para gerenciamento de serviços de TI. Este framework certifica que a
empresa utiliza as melhores praticas recomendadas pela ITIL. No Brasil temos poucas
empresas certificadas até o momento, já no exterior está referência já é utilizada em
maior escala, servindo como pré-requisitos para participação licitações de empresas
como a NASA e o Governo Americano.
Pode-se observar que hoje o foco está em ‘fazer acontecer’, sem o devido cuidado com
o melhor método ou com uma análise adequada. Quando um gerente de TI afirmar
que já possui processos ITIL implantados porem não consegue garantir que este processo está seguindo os requisitos mínimos de qualidade. A ISO 20000 deve ser utilizada como um complemento do ITIL, pois atesta que as melhores práticas em gestão de
serviços de TI estão efetivamente implantadas. A ISO 20000 garante também que os
46
processos mínimos estão sendo aplicados e seguidos. O fato de ser auditado por uma
entidade externa de forma contínua e periódica, bem como auditoria interna, garante
que os processos e a qualidade de serviços de TI estão sendo seguidos.
Outro aspecto importante é que a ISO 20000 garante alguns complementos fundamentais para o ITIL, como, por exemplo, a responsabilidade e o comprometimento da alta
direção sobre o sistema de qualidade de serviços de TI, competência, treinamentos e
requisitos de documentação para a devida execução dos processos. Tudo isso é auditado quanto à sua eficácia. Outro aspecto fundamental é a inclusão dos processos do ciclo PDCA, incluindo auditoria, registros, evidências de não conformidades e oportunidades de melhorias com suas ações preventivas e corretivas. Processos importantes
de relacionamento com o cliente (incluindo gestão de reclamações) e de gestão de fornecedores são auditados e escalados. Exige-se também um processo de melhoria de
serviços com atividades bem definidas, incluindo determinações claras de entradas e
saídas dos processos.
Devido a importância do ITIL em sincronia com o ISO 20000 recomenda-se que as
empresas e provedores de TI juntamente com seus gestores considerem esta implantação conjunta. Sendo este processo voltado primeiramente para a obtenção de melhores níveis de qualidade na prestação de seus serviços. Com base nesta argumentação, acredita-se que os benefícios de implantar a ISO20000 em conjunto com o ITIL
serão superiores quando comparados a implantação do ITIL de forma isolada para a
Gestão da Qualidade em Serviços de TI. Lembrando que o Cliente é quem sai ganhando com esta união.
47
Catálogo de Serviços – O desconhecido
BRUNO CAIADO
Atire a primeira pedra quem nunca achou que um “Catálogo de Serviços” é simplesmente uma lista de serviços. A princípio, ele pode até ser, mas esqueceram de avisar
que a gestão do catálogo é um dos processos do livro Service Design. Se antes ele era
um adendo da Gestão de Nível de Serviço, agora ele ganhou o corpo e a visibilidade
merecidos.
Se o serviço é o meio para atingir os resultados esperados, o catálogo é a referência
dos serviços oferecidos. O processo de gestão do catálogo garante a consistência e atualização das informações. E a pergunta é: de onde vem essas informações? Das áreas
de TI? Das áreas de negócio? Da cabeça do CIO? Do CMDB? Não....nada disso. As informações do catálogo devem ser uma consequência de uma estratégia de portfolio
de serviços.
Eu explico. Qualquer empresa deve embasar suas decisões e seus investimentos em
uma estratégia que balanceie a demanda prevista e a análise do nível dos riscos identificados. Em geral, quanto maior o potencial transformador de um investimento, maior
o risco associado. Esses investimentos podem ser associados a categorias:
• Run the Business (RTB): para investimentos que vão simplesmente manter a empresa funcionando. Baixo risco.
• Grow the Business (GTB): para investimentos que serão usados para aumentar o tamanho do negócio. Médio risco.
• Transform the Business (TTB): para investimentos que irão transformar o modelo
de negócio. Alto risco.
Qualquer empresa que quer se manter viva, precisa, no mínimo, de investimentos de
categoria GTB. Em momentos de crise, uma possível opção é adotar uma estratégia
conservadora e restringir os investimentos a um mínimo (RTB), o que aparentemente
é uma opção segura, mas nem sempre pavimenta o caminho para o sucesso e a sustentabilidade.
Uma estratégia de portfolio deve balancear riscos e valor para o negócio para definir
onde investir e quais serão os serviços oferecidos interna e externamente. Diversos
fatores incluindo a prioridade do negócio, o custo-benefício e as capacidades da empresa devem ser considerados. Lembre-se: o VALOR para o negócio não é uma entidade abstrata, ele é real e é medido em números!
Vamos a um exemplo simplificado. Novamente, vou usar uma empresa aérea fictícia. O
ano de 2008 foi complicado para nossa empresa. As vendas não alcançaram o patamar
esperado e o nível de ocupação esteve constantemente próximo ao break even (ponto em que o número de assentos vendidos cobre as despesas incorridas para fazer a
48
viagem). Pesquisas indicam que os clientes vem tendo dificuldades para comprar passagens pelo web-site, principalmente se estão utilizando smartphones ou outros aparelhos móveis. Como é uma clara tendência de mercado o uso de canais móveis, fica
claro que criar um serviço específico para esse canal poderá alavancar as vendas. Decide-se investir em um web-site personalizado para smartphones, em que o processo
de compras, check-in, reservas poderá ser feito de forma fácil e rápida mesmo nesses
dispositivos. Um business case indica que se o investimento for de R$1M, mas as vendas
aumentarem 18%, o investimento se paga em 3 meses e a empresa se consolida como
líder do mercado.
Um novo serviço chamado de “canal móvel de venda” é criado e requerimentos específicos são levantados. Esses requerimentos levam em consideração tanto a adequação ao propósito (fit for purpose) e a adequação ao uso (fit for use). A adequação ao
propósito diz, por exemplo, que esse canal deve servir para vender passagens. A adequação ao uso vai levar em consideração a usabilidade, o dimensionamento (de acordo
com o aumento do número de passagens compradas), a segurança, a disponibilidade,
entre outras especificações. Acordos de nível de serviço são então definidos levando
em consideração esses requisitos.
Temos aqui um exemplo de como alimentamos nosso catálogo de serviços. E se um dia
esse serviço deixar de fazer sentido para o negócio, ele deve ser retirado do catálogo?
SIM! Isso mesmo. O catálogo é uma entidade viva, que contém uma referência para os
serviços de TI correntes e que devem ser constantemente avaliados quanto ao valor e
custo-benefício para o negócio. Quem faz essa avaliação é a estratégia de portfolio de
serviços, alimentando e retirando serviços do catálogo.
A pergunta inevitável que se segue é: porque diabos os serviços do meu “catálogo” (se
é que ele existe) parecem ser apenas atividades ou funções de TI, sem uma conexão
direta com o negócio? Provavelmente porque esse catálogo foi feito baseado no que
você faz e não no que faz sentido você fazer. Simplesmente se fez uma lista, usando
algum critério como tipo de tecnologia, funcionalidade ou atividades “padrão” de uma
área de tecnologia. Algo como: REDES, CORREIO ELETRÔNICO, APLICAÇÃO X, etc.
Eu não diria que está errado, mas está, no mínimo, incompleto e desconectado com o
negócio. Nosso objetivo deve ser deixar EXPLÍCITO como esses serviços de TI suportam os serviços ou processos de negócio da empresa. Para isso, algumas perguntas
precisam ser feitas:
• Qual o core business da empresa?
• Quais as atividades chave para manter, crescer ou transformar o negócio da empresa?
A primeira coisa que se diz, especialmente em empresas grandes, é: eu não tenho a
menor noção da estratégia da empresa. Isso já é grave, mas mais grave ainda é dizer
que você não sabe nem quais são as atividades chave para manter a empresa funcion-
49
ando e que a única coisa que você aprendeu é rodar uma rotina batch. Em um cenário
desolador como esse, minha recomendação de emergência é:
1. Mapeie, em alto nível, quais as atividades chave que mantém a empresa funcionando e divida elas em grandes grupos como: VENDAS, PRODUÇÃO, FINANCEIRO,
etc.
2. Mapeie serviços de TI em um nível de função, como: EMAIL, INTERNET, APLICAÇÃO DE VENDAS, etc.
3. Relacione quais serviços suportam quais grupos de processos de negócio.
Esse é o começo, mas não é o fim. Faça uma primeira versão, menos detalhada, com o
conhecimento técnico ou de de negócio que você tem. Você pode até lançar uma versão
inicial já nesse estágio. Em seguida, mãos à obra: pergunte, descubra, questione, entenda, conecte-se com a estratégia da sua empresa e com suas áreas de negócio. Aprofunde seu conhecimento em conceitos adicionais como o de market spaces e gerenciamento de demanda (disponíveis no livro Service Strategy). Faça seu catálogo girar!
Refine, detalhe, publique-o. Ele pode até ser uma lista, mas é também o reflexo do que
a organização de TI tem a oferecer e de como ela suporta os objetivos da sua empresa.
Se isso é ser apenas uma lista, é apenas uma questão de perspectiva.
50
Como o BDGCCMDB pode aumentar a eficiência dos
processos de suporte a serviços
CLAUDIA MARQUESANI
A Gerência de configuração é um processo bastante popular dentro da biblioteca
ITIL®. Porém , um dos mais difíceis de ser implementado, um dos mais importantes e
aquele onde temos maior dificuldade para “vender” dentro de uma organização, por
ser bastante trabalhoso.
Na prática, vocês conseguem realmente verbalizar quais são as vantagens de uma
gerência de configuração para uma organização e para os outros processos de suporte
a serviços? Abaixo cito alguns exemplos que podem auxiliá-los a expor essas vantagens para uma organização, principalmente aquelas onde alguns processos já estão
implementados, mas que está sentindo uma falta “tremenda” de uma boa gerência de
configurações para se apoiar. São elas:
1. Gerencia de Incidentes: utilizará o BDGC (Banco de Dados de Gerencia de Configurações) para ter uma visão lógica da infraestrutura de TI e seus serviços, através
dos itens de configuração e seus relacionamentos. Essa visão poderá fazer com
que a gerencia de incidentes tenha maior agilidade e facilidade para solucionar
incidentes. Por exemplo: maior rapidez na analise do impacto e alocação do time
correto para atuação no incidente; maior rapidez na identificação dos itens de configuração impactados e que precisam ser agilmente substituídos ou corrigidos.
2. Gerencia de Mudanças: terá maior maior controle e agilidade no gerenciamento
sobre as mudanças do ambiente, pois o uso do BDGC e a visão lógica da infraestrutura de TI e seus serviços ( fornecida através dos itens de configuração e seus
relacionamentos), mostrará de maneira clara e controlada os componentes envolvidos na mudança e seu real impacto para o serviço. Por exemplo: terá maior agilidade na aprovação de mudanças, pois haverá mais facilidade para analisar o impacto no serviço dos itens de configuração envolvidos na mudança; poderá fazer
o uso de baselines de configuração , para retornar o ambiente ao status anterior a
uma mudança executada e mal sucedida.
3. Gerencia de Problemas: poderá aumentar a eficiência da gerencia de problemas,
ao facilitar a análise de tendências em Itens de configuração relacionados a incidentes e identificar a causa básica de um ou mais incidentes. Essa informação é
utilizada para evitar novos incidentes e melhorar a qualidade dos serviços.
4. Gerência de Liberações: aumentará a efetividade da gerencia de liberações, pois
fará auditorias e controles permanentes para evitarão que softwares ilegais ou
não autorizados sejam registrados na BSD (biblioteca de software distribuido). Aumentará a eficiência das liberações pois utilizará baselines de configuração para
salvar as informações dos ICs antes do release (atributos como versão ou status,
por exemplo). Essas informações poderão auxiliar caso a liberação seja mal suce-
51
dida e um backup tenha que ser retornado.
Várias outras vantagens poderiam ser citadas, inclusive nos processos de entrega de
serviços, mas este post certamente não terminaria hoje.
Conhecer as vantagens de um processo para o negócio de sua organização é o primeiro
passo para tomar a decisão de implementá-lo , para conseguir aprovação dos “patrocinadores do projeto” e a aderência de todos que estarão envolvidos no mesmo. Ou seja,
saber as vantagens não é garantia de que o sucesso seja atingido, mas é primordial para
buscá-lo. Espero ter ajudado vocês nesta busca.
Disponibilizamos uma planilha modelo de CMDB/BDGC. Para fazer o download, clique
aqui. Bom divertimento! :D
52
Compreendendo a ITIL a partir de uma perspectiva
nada convencional um show de rock
RENÊ CHIARI
A ITIL® traz uma série de boas práticas de gerenciamento, organizadas para cobrir
todo o ciclo de vida de um serviço, focando em cinco fases:
Estratégia de Serviço: É a fase de concepção do serviço. A pergunta mais simples que
poderia ser feita neste momento é: “O que sua organização quer ser?”.
Desenho do Serviço: Nesta fase, a estratégia do serviço começa a tomar forma. Tudo o
que é necessário para os requisitos do serviço vai para o papel. É hora de planejar como
a organização vai se transformar no que foi proposto durante a estratégia!
Transição do Serviço: Mãos na massa! Neste momento é preciso garantir que tudo o
que foi desenhado na fase anterior se torne, de fato, um serviço disponível (ou “consumível”), com o mínimo de riscos/impacto.
Operação do Serviço: Só os fortes sobrevivem a esta fase. Uma vez disponibilizado o
serviço, agora é momento de garantir que ele funcione de acordo com o que foi previsto na estratégia, com o mínimo de interrupções, e com o tratamento adequado para os
imprevistos.
Melhoria Continuada do Serviço: Sempre há o que melhorar. Nesta fase há uma preocupação em garantir que todo o ciclo de vida do serviço passe por uma avaliação criteriosa, e lições sejam aprendidas (em qualquer das fases).
Ok, mas qual é a relação da ITIL® com um show de rock?
Tendo como verdade a ideia de que um show de rock é uma das ofertas disponíveis em
um serviço de entretenimento, promovido por empresas de eventos (os provedores
de serviço) ao público em geral (os clientes do serviço), vamos ao seguinte cenário:
Imagine o custo total do espetáculo de uma banda mundialmente conhecida. As toneladas de equipamentos, a logística e a enorme quantidade de profissionais envolvidos.
A responsabilidade por garantir a satisfação de 50, 100, 200 mil pessoas que pagam
para ver o melhor espetáculo possível ao vivo, em um tempo relativamente curto (de 1
a 3 horas). Apesar de um pouco específicos, estes desafios podem ser identificados em
quaisquer outros serviços vistos no dia a dia, sejam eles de TI ou não.
Há algum tempo atrás, a banda U2 adotou uma forma diferente de se apresentar, em
um palco de 360 graus. Toda essa inovação faz parte de uma estratégia definida para
introduzir um novo conceito, uma nova experiência para o público. E sabemos que funcionou muito bem.
53
Provavelmente foram necessários muitos meses de estudo, cálculos, envolvimento de
engenheiros de som, arquitetos, especialistas em efeitos visuais, etc. Além disso, considerar quantidade máxima de público por show, valores de ingressos, limitações de
locais em que este show poderia ser instalado, segurança, etc. Tudo isso para desenhar
como esta nova abordagem do espetáculo poderia ser viabilizada ao público.
Você já deve ter visto aqueles profissionais que vivem correndo de um lado para o outro, montando e testando os equipamentos das bandas ou artistas antes de um show,
trocando os instrumentos em questões de segundos, arrastando cabos de lá pra cá, e
quando ocorre algum imprevisto, atua na linha de frente na tentativa de resolvê-lo o
mais rápido possível.
Outro exemplo: cada equipamento, desde a ordem de ligação, configuração de parâmetros e informações relevantes dos equipamentos como voltagem, modelo, etc. devem ser
controlados minuciosamente para que o timbre característico do artista permaneça
sempre o mesmo. Provavelmente, o artista deve sempre ser consultado, e aprovar
quaisquer mudanças em seus equipamentos, avaliando o impacto que elas podem
trazer em uma performance ao vivo.
E se tudo der errado? Qual é o plano caso ocorra um desastre e tudo pare de funcionar?
Pra finalizar, tudo isso deve estar explícito nos contratos milionários fechados com os
organizadores do evento, juntamente com os níveis de serviço esperados (duração do
show, músicas a serem tocadas, etc).
Apenas neste pequeno cenário, já foram citados ao menos 5 processos de gerenciamento de serviços sugeridos pela ITIL®.
54
Do inferno ao céu – Como o exemplo do Corinthians
pode ser utilizado na Gestão de Serviços
CLAUDIA MARQUESANI
Antes de começar a escrever esse texto é bom ficar claro: sim, sou corintiana, comemorei muito o título e estou extremamente realizada. Porém, meu objetivo nesse texto
é muito maior que falar de um time de futebol. O fato é que, com certeza, podemos
aprender com a guinada que o time do Corinthians teve nos últimos anos, de time rebaixado para a 2ª divisão em 2007 para campeão do Mundo em 2012. Pouco mais de
quatro anos que levaram uma das maiores torcidas do país do inferno ao céu, ou seja,
satisfação TOTAL dos “clientes” do timão. A satisfação é tanta, que existe a previsão
de arrecadação para o timão no próximo ano, somente em patrocínio, de mais de 390
milhões de reais.
E quem não gostaria de ter esse sucesso no nosso dia a dia? De uma Central de Serviços
mal avaliada para uma Central de Serviços devidamente reconhecida como estratégica para o negócio de uma empresa? De um processo de mudanças e liberações que só
é visto como burocrático, para um processo devidamente reconhecido como essencial
para que problemas não aconteçam na área de TI de uma organização? De uma equipe
de suporte cansada, desmotivada e mal vista porque está sempre envolvida em incidentes e retrabalho, para um time técnico forte e respeitado?
Na prática, o que realmente costuma funcionar, no mundo do futebol, na nossa vida
pessoal ou empresarial, são três ingredientes básicos e foram eles que geraram essa
receita extraordinária de sucesso corintiana: estratégia, organização e foco para atingir os objetivos.
ESTRATÉGIA significa saber onde queremos chegar e como chegaremos lá. Não é segredo para ninguém que nenhum corintiano, incluindo os dirigentes, aguentava mais as
piadinhas relacionadas à falta de um título de libertadores (“nunca serão”). Foi então
que, no pior momento do time, após um rebaixamento, resolveram repensar a estratégia usada até então. Assumiu um forte diretor de marketing e atual vice-presidente
- Luis Paulo Rosenberg, um renomado economista. E o que um economista tem a ver
com futebol? Nada e por isso mesmo deu tão certo. Ele criou a rede de lojas do Poderoso Timão (fácil ver uma em cada grande shopping do Brasil), o projeto sócio-torcedor,
trouxe de volta o querido ex-craque da seleção Ronaldo (um golpe de mestre para o
marketing do time), ou seja, soube utilizar a paixão da torcida a favor do clube e com
isso aumentou o faturamento anual de R$ 117,5 milhões para R$ 290,4 milhões. Há 3
anos, ouvi uma entrevista do ex-presidente Andrés Sanchez para uma rádio, onde ele
já dizia que nos próximos 10 anos o Corinthians estaria entre os maiores do mundo...
Hoje, alguém duvida dessa profecia e da estratégia que eles estão utilizando para atingir esse objetivo?
55
Portanto, se seus objetivos não estão sendo alcançados, será que a estratégia que você
traçou para “chegar lá” é a mais adequada? Talvez seja necessário percorrer um caminho diferente do traçado inicialmente.
ORGANIZAÇÃO significa preparar-se para atingir os objetivos que foram definidos
na estratégia. Contratação de bons e experientes profissionais – não adiantava querer ganhar a Libertadores, com toda sua pressão de jogos eliminatórios, com quem não
tem experiência nesse tipo de competição. O timão buscou Chicão, Alessandro, Mano
Menezes, todos com experiência. Eles já estavam lá em 2008, disputando a 2ª divisão
do brasileirão, quando o Corinthians ainda sequer sonhava em disputar a copa Libertadores da América...
Do mesmo modo, se você quer ter serviços de qualidade, contrate profissionais de
qualidade – pelo menos alguns – para conduzir esse trabalho e para preparar e treinar
outros profissionais com sua experiência.
Não podemos esquecer que é preciso também estar organizado como uma equipe. Apenas “estrelas”, não ganham campeonato - se fosse assim o campeão mundial de 2012
seria, com certeza, o Chelsea. “Estrelas” são o máximo naquilo que fazem, mas sozinhas não conseguem conduzir um trabalho adequadamente, não conseguem chutar e
cabecear para o gol. É preciso que todos da equipe estejam organizados e preparados
para buscar o objetivo principal definido lá na estratégia.
FOCO significa manter-se concentrado, organizado, preparado para a busca desses
objetivos, mesmo diante das adversidades. O Corinthians contratou um líder forte, que
promove o trabalho em equipe e fortaleceu-o junto ao grupo, através do apoio incondicional da diretoria. Nem mesmo quando, vergonhosamente, o time sob a liderança do
Tite caiu ainda na fase pré-Libertadores de 2010, esse líder perdeu força. A diretoria
optou por mantê-lo, para que ele continuasse seu trabalho. O resto da história nós já
conhecemos.
Quantas vezes diante de um fracasso, não mudamos de rumo, a ponto de esquecer qual
era nossa estratégia inicial? Não é pecado algum mudar de estratégia, mas muda-la a
todo instante significa falta de foco e perda de dinheiro (economizaram com a rescisão
do Tite naquela época e tenho certeza que não estão arrependidos disso hoje!).
Sei que muitos não corintianos vão ler esse post e pensar: “que saco, até aqui no ITSM
na prática estão falando do Corinthians!”. Torcidas e corações a parte, temos que reconhecer que esse tipo de ascensão serve de inspiração para qualquer profissional que
deseja crescer e buscar o sucesso. Porque não utilizar esse exemplo também no nosso
dia a dia? Mesmo que vocês sejam Palmeirenses, São Paulinos, Santistas...Tenho certeza
que pode dar certo! Vaiiiiiiii Corinthians! ;)
56
Entenda a importância da classificação do Incidente
CLAUDIA MARQUESANI
Antes de mais nada é preciso entender os conceitos e a importância dessa atividade
para a Gerência de Incidentes e para os outros processos das melhores práticas ITIL®.
O que é classificação?
CLASSIFICAÇÃO = CATEGORIA + PRIORIDADE, onde:
• CATEGORIA = determina o tipo de Item de configuração afetado no incidente (por
exemplo: Hardware/Software)
• PRIORIDADE = IMPACTO + URGÊNCIA , sendo que:
-- IMPACTO = Impacto que o incidente pode causar nos negócios;
-- URGÊNCIA = tempo requerido para resolução (relacionado a tempo).
Na prática , a classificação de um incidente pode parecer algo muito simples. Por isso ,
na maioria das vezes durante a implementação ou no dia a dia do processo não damos
a devida importância a essa atividade.
Classificar um incidente é sim uma atividade relativamente simples, mas criar categorias que possam trazer eficiência e melhorar os serviços de uma organização pode ser
bastante desafiador.
Quando vamos implementar a Gerência de incidentes das melhores práticas ITIL®, é
importante investir tempo planejando essa classificação. Qual seria a melhor classificação (sempre pensando no custo benefício para o seu negócio)? É importante ter em
mente que o ideal é sempre o máximo de informação , com o mínimo de controle e custo para mantê-la.
Abaixo apresento como a correta classificação de um incidente pode contribuir para
aumentar a eficiência de uma organização e o fornecimento de serviços .
1. A classificação é usada para definir e/ou selecionar o melhor especialista ou grupo para lidar com o incidente. Ela auxiliará a encaminhar o incidente para os especialistas mais preparados para atendê-lo, evitando que outros grupos de suporte
gastem tempo e esforços na solução de incidentes para os quais não foram adequadamente preparados.
2. A classificação também é usada para comparar incidentes e contribuir para melhorar o tempo e qualidade da investigação e diagnóstico . Através da classificação é possível comparar incidentes que já aconteceram e aplicar diagnósticos e
soluções já implementados no passado para os incidentes atuais de maneira mais
fácil , rápida e precisa.
3. A classificação é usada para identificar a prioridade de atendimento de incidentes, baseada no impacto que o incidente traz para o negócio. Com isso é possível
priorizar o atendimento daquilo que realmente causa impacto para o negócio de
57
uma organização (perdas financeiras, de imagem, etc.)
4. A correta classificação auxiliará uma organização a definir quais questões devem
ser feitas e checadas durante a abertura do incidente. Pode ser criado um script
de perguntas para garantir que as informações necessárias sejam obtidas com o
usuário impactado e registradas no momento da abertura e suporte incial do incidente. Isso evitará perguntas e testes descenessários com os usuários e melhorará a qualidade e tempo do atendimento do incidente.
Lembre-se: classificar corretamente está , em grande parte, ligada a QUALIDADE DOS
ITENS QUE TEMOS DISPONÍVEIS PARA COMPOR A CLASSIFICAÇÃO. No livro do
ITIL® (Service Support) podem ser encontrados diversos exemplos de modelos de classificação (categorização e priorização, respectivamente anexos 5 A e 5B do capítulo de
Gestão de Incidentes). Avaliem as sugestões e melhores práticas do livro e adaptem
com cuidado e esmero para sua organização.
Disponibilizamos em nossa área de downloads um modelo prático de categorização e priorização). Verifiquem esse modelo e adaptem para o dia a dia de vocês.
Os ganhos podem ser realmente surpreendentes...
Boa sorte.
58
Níveis de serviço tão necessários quanto inúteis
BRUNO CAIADO
O título parece exagerado e sensacionalista, mas não consegui pensar em nada que se
aproxime mais da realidade. Todos querem niveis de serviço, mas poucos tem em mente
objetivos claros antes de começar a construí-los. O objetivo maior, é claro, não poderia
ser outro a não ser o “alinhamento com o negócio”, uma das máximas mais exaustivamente repetidas e menos efetivamente implementadas. E o motivo é muito simples:
não existe mágica para isso. Nem ITIL® nem qualquer sistema, metodologia ou melhor
prática é capaz de fornecer a resposta definitiva de como obter o “alinhamento” com
o negócio.
De fato, essa é uma pergunta aberta e que exige uma abordagem estruturada, que se
inicia no entendimento dos objetivos de negócio e se replica em diferentes níveis. É
impossível falar em “alinhamento” em um único nível. É mais coerente falar em uma
“cadeia de alinhamentos”, que se sincronizados e mantidos através dos controles adequados podem trazer um alinhamento efetivo.
A biblioteca ITIL® não oferece uma única disciplina para isso. Na verdade, o alinhamento com o negócio permeia a biblioteca. Mas se pudéssemos eleger uma única disciplina, o gerenciamento de nível de serviço (Service Level Management – SLM) estaria
provavelmente em primeiro lugar. E não porque SLM garanta o cumprimento de SLAs
(Service Level Agreements). Nada disso. Mas sim, porque SLM garante que acordos
sejam feitos e que esses acordos levem em consideração as necessidades de negócio
dos clientes. Cumprir ou não SLAs é irrelevante se os acordos não refletirem necessidades reais de negócio.
Mais importante que qualquer outra coisa, SLM depende de uma definição de serviços
que de fato ajudem os clientes a atingirem seus objetivos, do alinhamento de expectativas em relação ao que será entregue e da definição de SLAs que realmente façam
alguma diferença ao serem cumpridos. Se esses passos fundamentais não forem executados (ou não forem corretamente executados) a monitoração e cumprimento ou
não de SLAs será uma mera formalidade contratual. E por consequência, a confecção
de relatórios será apenas mais uma forma de gastar papel, tinta ou recursos.
Ao invés de meros SLAs, nada mais relevante para medir a efetividade de SLM do que
a confiança que o cliente tem no provedor. A confiança é construída a partir de um relacionamento estabelecido entre cliente e provedor e não a partir de SLAs. Isso se reflete na seguinte pergunta: entre um provedor que cumpriu o SLA e um provedor que
não cumpriu, mas que tem um cliente satisfeito e que confia no seu trabalho, quem
executou o processo de SLM de forma mais efetiva? A resposta é clara: o último.
Para exemplificar, vamos retomar nosso exemplo da empresa aérea. As expectativas
são altas em relação ao novo serviço de “canal móvel de dados”, que será usado para
59
facilitar a compra de passagens por smartphones. A expectativa é de um aumento em
18% no RPK (Revenue Passenger Kilometers), que representa quilômetros de passageiros pagantes (o que exclui tarifas especiais e tripulantes). Isso significa pelo menos
400.000 passageiros a mais em um único mês para nossa companhia aérea. O sistema também deve alimentar o portal que mostra o ASK (available seat kilometers, que
mede a capacidade de transporte) e o load factor (que mede a taxa de ocupação). Duas
funcionalidades chave para o negócio são mapeadas: a capacidade de venda de passagens, com um dimensionamento para pelo menos 400.000 transações/mês e a integração com o portal de indicadores. O nível de serviço acordado prevê um baseline
de 1000 transações por hora, sendo 500 simultâneas, e pelo menos 1 replicação diária
das informações para o portal. A replicação deve ocorrer antes da reunião diária da
gerência de operações (10:00 AM). Indisponibilidades do canal devem ser corrigidas
em no máximo 1 hora, representando a perda potencial de 1000 passageiros.
Não é difícil perceber o quanto os SLAs acima fazem sentido para os objetivos estratégicos relacionados ao novo canal de vendas. Isso representa um alinhamento entre as
necessidades do negócio e os serviços e SLAs oferecidos pela organização de TI. Mas o
alinhamento não pára por aí. Ele é, na verdade, uma via de mão de dupla e exigirá uma
cuidadosa análise tanto da capacidade de entrega quanto dos custos. Essa “ponte” é
feita por SLM, que precisa envolver outros gestores como os de disponibilidade, capacidade e financeiro. Depois disso, será preciso monitorar o atingimento dos SLAs,
acompanhar perdas potenciais e efetivas e revisar continuamente o valor de negócio
que eles representam. Eventualmente, tanto a capacidade do canal ou outra característica poderão ser revistas à luz de novas necessidades de negócio. Os SLAs devem
evoluir de forma alinhada a essas necessidades e não podem ser considerados como
“gravados em pedra”. Para isso, os próprios acordos devem prever revisões periódicas
tanto do atingimento quanto de sua adequação.
Alguns SLAs podem até ser inúteis, mas aqueles criados de acordo com necessidades
de negócio específicas, monitorados e revisados continuamente, e usados como ferramentas para a construção de relacionamentos com o cliente, esses sim, são verdadeiros SLAs, tão necessários quanto os próprios serviços prestados.
60
O conhecimento é meu e ninguém tasca
CARLOS AFONSO
É notório que em muitas organizações atualmente existem pessoas que se acham portadoras de um conhecimento “místico” que, segundo eles, não pode ser passados aos
outros.
No contexto de uma Central de Serviços, um exemplo é visto naqueles que possuem o
conhecimento específico relacionado a um ou mais componentes de um serviço de TI.
O drama é maior principalmente quando a organização não possui uma documentação
adequada de seus serviços, e a organização e/ou fornecedores não possuem o mesmo
em relação a esses componentes.
Um exemplo de como isso pode ser particularmente sentido é quando o Cliente liga
para o Service Desk e pede uma consulta. Até aí tudo bem. O problema é quando somente uma pessoa é capaz de atender a essa consulta. Neste caso, é aquele que não
passou o seu conhecimento para ninguém, e faz questão de não documentá-lo. Motivo: ele se considera especial e indispensável para a organização basicamente por este
conhecimento específico que possui.
É importante ressaltar: existem duas situações possíveis. Uma é aquela em que a pessoa não quer passar o seu conhecimento para os outros. E a segunda é aquela em que a
pessoa não se importaria em passá-lo. Nos dois casos, obviamente a culpa é da organização que não tem um processo eficaz de Gestão do Conhecimento.
Soube de um caso, certa vez, em que um profissional foi treinar outros dois para realizar o atendimento de terceiro nível de um sistema de faturamento. Ao final de dois
meses, nenhum dos dois profissionais novos tinha o conhecimento a respeito dos processos mais críticos do sistema. E o sistema nem era tão complexo assim! Ainda que a
culpa final seja dos responsáveis pela Gestão do Conhecimento (por não ter feito um
plano de transferência do conhecimento eficaz), era evidente a satisfação dele em ter
que ser chamado toda vez que surgiam incidentes, problemas e serviços adicionais em
relação ao componente.
O principal argumento dado por ele era: “eu trabalho com este sistema há uns 2 anos,
não é possível explicar todas as regras de faturamento em meses”. Na verdade, o pedido era que primeiramente as regras e comportamentos críticos do sistema fossem
explicados, mas mesmo assim, isso não foi feito. E, pelo tamanho do componente em
questão, um mero plano de transferência de conhecimento cuidaria disso em questão
de poucas semanas. E ele fez esse plano, mas cuidou para que o conhecimento essencial não fosse passado. Conclusão: por medo de deixar de se sentir especial, ele tratou
para que o restante da sua equipe não possuísse o conhecimento que ele possui para o
atendimento em relação ao componente.
61
Esse tipo de profissional, que alega a impossibilidade ou inviabilidade de se transmitir
um conhecimento específico (e que justamente por isso ele seria “especial”), é um dos
principais desafios para a gestão atual. Por vários motivos, como o fato de que, se profissionais em geral sentem-se valorizados e motivados quando conseguem fazer suas
atividades plenamente, eles terão sua iniciativa dificultada por que alguém está escondendo o conhecimento deles. Embora aquele que esconde o conhecimento dos outros
(guardando-o só para si), sinta-se mais “seguro” no cargo, o desempenho da equipe cai
como um todo, e os riscos do atendimento ao cliente ser prejudicado aumenta, pois não
é sempre que este profissional estará disponível ou terá tempo para o atendimento.
Não existem benefícios organizacionais para este tipo de atitude, que, em muitos casos, chega a ser desleal com a própria organização e com a equipe.
Com desafios deste tipo aqueles que atuam com o processo de Gestão do Conhecimento, disponível a partir da ITIL® 3.0, terão que lidar. É o momento de valorizar profissionais que são formadores de outros profissionais, e que, aos poucos, com sua atitude,
ajudem a diminuir o risco do atendimento não acontecer. E, aos poucos, mostrar para
aqueles que não valorizam a transmissão do conhecimento que eles não passam de focos de risco para a organização de TI.
62
O que é Gerenciamento de Serviços de TI?
ANDRE JACOBUCCI
O Gerenciamento de Serviços de TI é um daqueles temas que, por sua riqueza, só pode
ser bem apreciado quando abordado por diversas perspectivas complementares.
Por isto, neste artigo, pretendo ressaltar uma das facetas do Gerenciamento de Serviços
de TI: o fato de ser uma prática.
Da mesma forma que cozinhar não se aprende apenas lendo bons livros de receita –
ou observando outras pessoas a cozinhar – o Gerenciamento de Serviços de TI é uma
habilidade que só se desenvolve praticando.
Assim como na cozinha de um bom restaurante, o resultado de uma organização de TI
também depende do acesso a bons ingredientes, bons fornecedores, bons equipamentos, boas receitas e métodos de trabalho corretos. Mas depende, sobretudo, de profissionais competentes que não se esquecem, jamais, de que tudo isso existe porque alguém está esperando na mesa para satisfazer sua fome ou para ser surpreendido com
um prato delicioso.
O Gerenciamento de Serviços de TI envolve, antes de mais nada, entender as necessidades e expectativas do cliente, e buscar o meio mais apropriado de atendê-las. É
enxergar uma organização de TI mais do que um grupo de profissionais especializados,
executando tarefas técnicas isoladas dentro de suas áreas de expertise, e sim com uma
visão de como tudo isso se encaixa e, principalmente, com a visão do cliente que espera na outra ponta.
Sendo assim, o Gerenciamento de Serviços de TI está longe de ser apenas a implantação de uma área de atendimento aos usuários finais – erroneamente chamada de
“Service Desk” – para que a organização de TI possa ser comunicada das falhas, dúvidas e dificuldades que impactam a produtividade destes usuários.
O Gerenciamento de Serviços de TI enxerga que todas as atividades de uma organização
de TI – do levantamento de requisitos para o desenvolvimento de um novo sistema, ao
monitoramento dos equipamentos que sustentam os sistemas já em produção – estão
conectadas e devem ser gerenciadas por meio de parâmetros de qualidade, tempo e
custo, para que tal organização de TI possa atender e surpreender seus clientes.
Sendo assim, o Gerenciamento de Serviços de TI também envolve aspectos de marketing, operacionais, financeiros e de gestão de pessoas.
O assunto não se esgota aqui, como alertei no início deste artigo. Pelo contrário, nos
estimula a abordá-lo sob diversos outros ângulos: o ângulo operacional – representado pelo conjunto de processos “clássicos” propostos pela ITIL®, o ângulo da qualidade
e da gestão sistêmica – proposto pela ISO 20000, o ângulo da Governança de TI – re-
63
forçado pelo Cobit, dentre diversos outros.
E para você? O que é o Gerenciamento de Serviços de TI?
64
Os 10 Mandamentos da ITIL
CLAUDIA MARQUESANI
Quando falamos de ITIL®, NÃO existe a obrigação para se implementar os processos
exatamente como os livros os descrevem. Um dia, várias empresas e pessoas envolvidas no gerenciamento de serviços de TI resolveram trocar experiências. Algum tempo
depois, elas chegaram a um consenso sobre o que eram as melhores práticas de mercado e posteriormente registraram isso em livros que se tornaram a “famosa” biblioteca
ITIL®. Porém, alguns erros e gargalos na implementação dos processos são tão óbvios
e atrapalham tanto a prática de implantação, que resolvi inovar e criar os 10 “mandamentos” da ITIL® ( mas eles poderiam ser muito mais que 10... escrevam contribuições a
respeito nos nossos comentários desse post). São eles:
1. Amarás a ITIL® com a ti mesmo.
Não desista! O gerenciamento de serviços de TI de uma organização e a melhoria dos
níveis de maturidade dos processos tende a melhorar com o passar do tempo. Não adianta andar com a biblioteca da ITIL® debaixo do braço, estudar horrores e achar que
do dia para a noite todos os “stakeholders” de uma organização vão migrar de uma cultura voltada a produtos para uma cultura voltada a serviços. É um processo lento, algumas vezes solitário e quase sempre árduo. Um processo de “catequização” que levará
a mudança de cultura de uma organização. Siga em frente, motive seu time, mostre o
valor agregado do gerenciamento de serviços, aposte nos ganhos rápidos e aos poucos
essa cultura ganhará mais espaço em sua organização.
2. Não acharás que é TI (tecnologia da informação) quem dita as regras.
Um dos principais objetivos da ITIL® é fazer com que a TI contribua para que a organização atinja seus objetivos de negócio. Por isso, não adianta a área de TI assumir que
entende o que é importante para a empresa e tomar as decisões por si mesma. É preciso OUVIR O CLIENTE. É preciso entender quais são os objetivos de negócio. Nenhum
conhecimento técnico será suficiente para trazer resultados, se a TI tomar decisões
que não auxiliam no atingimento das metas da organização. Provavelmente serão feitos investimentos em recursos e tecnologias desnecessários... Hoje em dia ninguém
deseja “queimar” dinheiro, não é mesmo? Pecado mortal esse...
3. Não implementarás gerenciamento de configuração sem um bom processo de
gerenciamento de mudanças para auxiliá-lo.
Parece simples, mas não é. É o gerenciamento de Mudanças quem informa ao Banco
de Dados de Gerenciamento de Configuração o que e quais serão os itens de configuração alterados durante uma alteração no ambiente de TI. Podemos, portanto, ter
o melhor Banco de Dados de Gerenciamento de configurações do mundo, contratar
65
a mais competente consultoria para implementá-lo, para definir o escopo mais adequado e contratar ferramentas perfeitas para mantê-lo - sem um processo adequado
de gerenciamento de mudanças, os itens de configuração serão alterados, novos itens
serão adicionados na infra e em pouco tempo, pouquíssimo tempo mesmo, o Banco de
Dados de Gerenciamento de Configurações estará completamente desatualizado. Se
você já começou um projeto de implementação de Gerencia de configurações em sua
organização e ainda não tem um processo de mudanças, aconselho a rever o projeto
ou tomar muito calmante para explicar para o CIO porque os benefícios que foram
vendidos com o processo não estão chegando...
4. Jamais atribuirás o papel do Gestor de Problemas e de Gestor de Incidentes para
a mesma pessoa.
Alguns processos têm interesses conflitantes e esse é um exemplo claro! A gerência de
incidentes tem o objetivo de restabelecer a operação do serviço o mais rápido possível.
A gerência de problemas tem o objetivo de investigar cuidadosamente para identificar
a causa raiz de um incidente crítico ou vários incidentes recorrentes, não se preocupando com o tempo, mas com a qualidade da investigação. Imaginem o grande conflito
de interesses, quando determinamos a mesma pessoa para ser gerente de incidentes
e problemas? Ela priorizará o atendimento de incidentes ou a investigação? Essa nem
vou responder, vou deixar para vocês pensarem...
5. Treinarás o pessoal da Central de Serviços periodicamente.
Já foi assunto de inúmeros posts, parece uma situação bem óbvia, mas quase sempre é negligenciado. Não adianta cobrar qualidade de atendimento de uma central de
serviços, onde as pessoas responsáveis pelo contato com o usuário não são treinadas.
Elas precisam receber, periodicamente , além de treinamento técnico, treinamento
comportamental, saber como atender um telefonema, como lidar com o usuário e como
responder as questões técnicas. Precisam saber utilizar a base de conhecimento, uma
de suas principais ferramentas de trabalho. Sem treinamento, a Central de Serviços
é um barco a deriva, esperando um vento mais forte (ou um evento mais crítico) para
afundar.
6. Não subestimarás a satisfação dos usuários e dos clientes.
Ouça o cliente e instigue-o a expressar sua opinião a respeito do gerenciamento de
serviços de TI. Revise os níveis de serviços atingidos e os não atingidos e atue na melhoria contínua de ambos (sim, também é possível melhorar o que já está bom, se isso
for interessante para o negócio). Não deixe tudo parado, como se nada estivesse acontecendo. Não espere seu cliente lhe procurar para manifestar sua insatisfação, pergunte como ele se sente! Existem dois tipos de detectores de satisfação: o termômetro
da satisfação do cliente é o gerente de nível de serviço e a voz dos usuários para TI é o
66
Service Desk. Utilize esses meios e atinja os melhores fins!
7. Não acharás que uma certificação será suficiente para implementar os processos na prática.
Na teoria a prática é outra. Já ouviram essa frase? Pois é, essa é a mais fiel realidade
quando falamos de gerenciamento de serviços de TI. Resumindo: somente conhecimento teórico, diplomas e certificados, apesar de ajudarem (e muito!), não garantem
uma boa implementação. É preciso trocar experiências com pessoas que já vivenciaram uma implantação dos processos, é preciso pesquisar , conhecer o negócio e principalmente ter paciência. É como “andar de bicicleta”. Quanto mais você pratica, melhor
fica. Atenção para a palavra: PRÁTICA.
8. Não recusarás o suporte dos outros modelos e frameworks.
As bibliotecas da ITIL® trabalham muito bem com outros frameworks e modelos, como
o COBIT , a ISO 20000 e modelos de gestão de projetos. Através deles é possível obter maior controle para as melhores práticas, maior entendimento e maior eficiência e
eficácia na operação e entrega de serviços. Pesquise como eles podem interagir. Na Internet existem inúmeros vídeos e publicações a respeito e em nosso site já colocamos
alguns posts sobre esse assunto. Só aplicar as melhores práticas da ITIL® é muito bom,
suportá-las por outros controles e modelos é melhor ainda!
9. Não acharás que a gerência de disponibilidade serve somente para medir quantas horas um recurso de TI está operando (ou não!).
Princípio 2 da Gerencia de Disponibilidade (retirado do livro versão 2 ITIL® – Entrega de
serviços) : “Reconhecer que, mesmo que as coisas deêm errado, ainda assim é possível alcançar o objetivo do negócio e a satisfação do Cliente”. Um servidor caiu. Será que mesmo
assim é possível manter a satisfação do cliente? A gerência de disponibilidade garante
que sim, porque ela não se preocupa apenas em manter o serviço operando. Quando
algo errado acontece, ela também cria condições e pode suportar para que esse serviço
seja recuperado mais rapidamente. Que tal “clusterizar” um servidor que suporta um
processo crítico para o negócio após um estudo da gerência de disponibilidade?
Outra parte muito interessante dessa gerência é que ela também oferece técnicas interessantíssimas para avaliar qual será a disponibilidade projetada para um novo serviço.
Essas técnicas podem ser aplicadas inclusive para aumentar a confiabilidade, disponibilidade e segurança de um serviço que ainda nem entrou em produção, alterando o
desenho proposto para melhorá-lo. Sim, esse é um processo muito nobre da nossa biblioteca e muitas vezes esquecido ou subestimado...
10. Não acharás que o Gerenciamento Financeiro é um processo “chato” da biblioteca.
67
Eu entendo. A maior parte das pessoas que trabalham com TI, não gosta muito de finanças. É um mundo um pouco estranho para quem está acostumado com termos técnicos, sistemas e máquinas. Mas é um “mal” necessário. Aliás, imprescindível. A TI precisa começar a “se vender”. É preciso mostrar porque determinado investimento em
TI custa caro muitas vezes, o retorno que aquele investimento trará para o negócio e
como esses custos serão controlados. TI precisa profissionalizar-se, ser operada como
uma área de negócio e não somente um processo de apoio dentro de uma organização.
Entender termos como : Retorno sobre o investimento (ROI) e Custo Total de Propriedade (TCO), não é mais opcional. Afinal, você, diretor de TI, tem idéia de quanto custa
para sua organização manter esse notebook que você está utilizando? Pergunte ao
processo de gestão financeira. Ele terá a resposta.
68
Para que serve a ISO 20000?
NELSON GRANADO MERINO
A ISO/IEC 20000 é a primeira norma editada pela ISO (International Organization for
Standardization) que versa sobre gerenciamento de serviços de TI (Tecnologia da Informação).
A ISO 20000 é um conjunto que define as melhores práticas de gerenciamento de
serviços de TI. O seu desenvolvimento foi baseado na BS 15000 (British Standard) e
tem a intenção de ser completamente compatível com o ITIL® (Information Technology Infrastructure Library). A sua primeira edição ocorreu em dezembro de 2005.
As normas internacionais relacionadas com a Gestão de Serviços de TI permitem a
colaboração de organizações internacionais e fornecem directrizes valiosas que contribuem para o estabelecimento da credibilidade das empresas. Uma nova norma, a
ISO 20000, agora disponível, permite a uma organização demonstrar aos seus clientes
e investidores que opera com integridade negocial e segurança, e que promove uma
cultura de melhoramento contínuo da qualidade no âmbito da Gestão de Serviços de
TI.
Por que é isto tão importante? É importante porque a obtenção da certificação ISO
20000 pode contribuir para que as empresas alcancem uma vantagem competitiva
relativamente às empresas que não cumprem os requisitos desta norma.
O lançamento da ISO 20000 levanta uma questão às organizações em todo o mundo:
O que necessita a organização de fazer presentemente, relativamente à ISO 20000?
Deverá uma Organização Procurar Obter Certificação?
Conforme referido anteriormente, a certificação ISO 20000 permite verificar se uma
organização emprega as melhores práticas de Gestão de Serviços de TI, conforme
demonstrado por uma avaliação independente externa com base numa norma oficial,
realizada por uma organização de auditoria autorizada. Este nível de validação pode
auxiliar a empresa a manter uma maior competitividade.
Ao determinar se deve ser obtida a certificação ISO 20000, a organização deverá ter
em consideração o seguinte:
• A ISO 20000 é particularmente importante para organizações de sectores industriais em que a qualidade dos serviços de TI é essencial para o sucesso empresarial,
tais como — mas não só — os sectores industriais de serviços financeiros, serviços
de utilidade pública e serviços de saúde. A certificação permite a estas organizações demonstrarem aos seus accionistas e clientes que possuem ambientes de TI
bem geridos.
• A ISO 20000 é relevante para organizações que fornecem serviços geridos e subcontratação de serviços de TI. A certificação permite às organizações de serviços
69
geridos garantirem aos seus clientes que os seus ambientes de TI serão bem geridos, possibilitando às organizações de outsourcing garantirem aos clientes que
receberão serviços de TI de elevada qualidade.
• Estes fornecedores de serviços têm que provar que documentaram as cinco áreas
chave da ISO 20000 e que estão a ser cumpridos os requisitos da norma. A documentação deverá incluir as políticas e planos de Gestão de Serviços, Acordos de
Nível de Serviços, processos e procedimentos exigidos pela ISO 20000 e quaisquer
registos exigidos pela norma.
• As organizações deverão ter em consideração as implicações de uma certificação
no respeitante à conformidade regulamentar. Presentemente, as organizações
necessitam de demonstrar a conformidade com um número crescente de regulamentos governamentais.
Muitos destes regulamentos, tal como as leis Sarbanes-Oxley e HIPAA (Health Insurance Portability and Accountability Act) de 1996 nos EUA, estão especificamente relacionados com serviços de TI e Gestão de Serviços de TI (ITSM). Actualmente, os auditores não exigem certificação de standards como prova de conformidade, mas no
futuro esta situação poderá mudar.
Por a ISO 20000 estar especificamente relacionada com a qualidade da ITSM, esta
poderia proporcionar um standard internacional utilizado pelos auditores com vista a
determinar a conformidade.
A certificação ISO 20000 será concedida apenas a organizações com operação de ITSM
e certificará apenas a operação de ITSM nessas organizações. A certificação não será
concedida para produtos ou para serviços de aconselhamento de melhores práticas
oferecidos por organizações de consultoria. A certificação poderá tornarse um requisito para realizar negócios com determinadas organizações, tais como agências governamentais ou outsourcers.
Por a ITIL® ser fundamental para a ISO 20000, é importante seleccionar uma solução
de automatização compatível com os processos ITIL®. A solução deverá suportar processos que abranjam todas as disciplinas de gestão de serviços de TI — gestão dos activos, gestão de mudanças e configuração, gestão de incidentes e problemas, gestão de
lançamento, gestão de capacidades, gestão de disponibilidades, gestão de financeira
e gestão de níveis de serviços. As “suites” são mais adequadas do ponto de vista financeiro, do que as aplicações “best-of-breed”, que requerem um trabalho de integração
considerável.
Além disso, um dos principais requisitos da ITIL® é a integração de processos entre as
diferentes disciplinas.
Deve ser procurada uma solução que integre totalmente os vários processos ITIL®,
tanto do ponto de vista dos processos, como dos dados, em vez que proporcionar mer-
70
amente um mapeamento campo-a-campo.
O que é mais importante compreender acerca da ISO 20000 e da ITIL® é que ambas
necessitam de um melhoramento contínuo, factor este que permitirá aumentar a credibilidade e competitividade de uma empresa.
Referências Recomendadas:
ITIL®: www.itil.co.uk/
COBIT: www.isaca.org/Template.cfm?Section=COBIT_
BS ISO/IEC 20000-1:2005 and BS ISO/IEC 20000-2:2005: www.bsi-global.com/
71
Principais diferenças entre a ITIL v2 e V3 Parte I
RENÊ CHIARI
Uma comparação entre a ITIL® v2 e V3 nos revela que todos os principais processos
da ITIL® V2 permanecem na V3, com algumas mudanças substanciais. Entretanto, em
muitos casos, a ITIL® v3 apresenta descrições de processos revisadas e melhoradas.
A principal diferença entre a V2 e V3 é a nova estrutura do Ciclo de Vida do Serviços:
A ITIL® V3 é melhor entendida,organizando os processos de uma forma cíclica. Isto
significa que a antiga estrutura do Suporte a Serviços (Service Support) e Entrega de
Serviços (Service Delivery) foi substituída por um novo conjunto núcleo de cinco disciplinas:
• Estratégia de Serviço - determina quais tipos de serviços devem ser oferecidos
para quais Clientes ou mercados.
• Desenho do Serviço - identifica necessidades do serviço e idealiza novas ofertas
de serviços, bem como alterações e melhorias aos serviços existentes.
• Transição do Serviço - constrói e implementa serviços novos ou modificados.
• Operação do Serviço - realiza atividades operacionais
• Melhoria contínua do Serviço - aprende com os sucessos e fracassos do passado
e melhora continuamente a competitividade, eficácia e eficiência dos serviços e
processos.
A grande sacada da ITIL® V3 é que ela não reinventa a roda, ela complementa os processos da ITIL® V2 conhecidos com um número de novos processos e coloca mais ênfase na produção de valor para o negócio. Devido a nova estrutura de ciclo de vida do
serviço, todas as interfaces entre os processos ITIL® foram alteradas para refletir a
nova estrutura de processo na ITIL® V3, então embora os processos da ITIL® V2 e V3
sejam conceitualmente idênticos, as suas interfaces mudaram.
Muitos me perguntam qual versão da ITIL® atualmente é a melhor pedida. A minha
resposta é: Depende!
Se o intuito é somente se certificar para ocupar um posicionamento melhor de mercado, o que não considero uma “boa prática” mas é infelizmente a realidade do nosso
mercado, vá de V3 sem pensar duas vezes.
Mas se o objetivo é botar a mão na massa e atuar ná pratica com implementação ou
gestão de processos ITIL®, vai depender muito da maturidade atual da sua organização.
Confesso que ainda não vi um número grande empresas se preocupando em implementar a V3. E digo mais, utilizar a ITIL® de verdade em qualquer de suas versões já
é um grande passo. Criei uma discussão em nosso grupo no LinkedIn justamente para
abrir espaço para este debate. Participem!
72
No próximo artigo irei comentar de forma mais detalhada as mudanças e comparações
entre as versões da ITIL®.
73
Principais diferenças entre a ITIL v2 e V3 Parte II
RENÊ CHIARI
Dando continuidade ao artigo sobre as principais diferenças entre as versões 2 e 3 da
ITIL® sem maiores delongas, detalhamos as principais modificações e inclusões que
ocorreram da transição da ITIL® v2 para a V3.
ESTRATÉGIA DO SERVIÇO
Gerenciamento de Portfólio de Serviço
• Gerenciar serviços como portfólio é um conceito novo adotado na ITIL® V3, introduzindo uma filosofia estratégica sobre como o portfólio de serviços deve ser
desenvolvido.
Gerenciamento Financeiro
• Sem alterações relevantes. As atividades e objetivos do processo permanecem
idênticas nas duas versões. Este processo é encontrado no livro de Entrega do Serviço (Service Delivery) na V2.
• Há um capítulo muito interessante e detalhado sobre ROI (Return of Investment).
DESENHO DO SERVIÇO
Gerenciamento de Catálogo de Serviço
• O Gerenciamento de Catálogo de Serviços foi incluído como um processo novo na
V3.
• Na V2, há menção sobre o conceito do Catálogo de Serviço, porém de forma muito mais superficial. Felizmente na V3 foi dada a atenção merecida ao Catálogo de
Serviços, que ganhou um processo só pra ele!
• A V3 introduz uma clara distinção no Catálogo de Serviços sob o ponto de vista de
Serviços de Negócio (serviços visíveis ao Cliente, definidos por SLA´s) e Serviços
de Suporte (serviços visíveis internamente pela organização de TI, definido por
OLA´s ou UC´s.
Gerenciamento de Níveis de Serviço
• Atividades e objetivos do processo permanecem os mesmos nas duas versões, porém na V3 as atividades de revisão do serviço são fazem parte do livro de Melhoria
Continua do Serviço
Gerenciamento de Segurança de TI
• A V2 fornece um guia sobre Gerenciamento de Segurança de TI em um livro sepa-
74
rado.
• A V3 trata o Gerenciamento de Segurança de TI como parte do livro Desenho do
Serviço, resultando em uma melhor integração deste processo no Ciclo de Vida do
Serviço.
• O processo foi atualizado para contemplar novas preocupações e desafios relacionados à segurança.
Gerenciamento da Arquitetura de TI
• O Gerenciamento da Arquitetura de TI estava contemplado dentro do Gerenciamento de Aplicações, na ITIL® V2.
• A V3 fornece orientações sobre os problemas de Arquitetura de TI como parte de
um capítulo sobre “atividades relacionadas à tecnologia”
• Gerenciamento de Fornecedores
• Na V2 estava contemplado no livro Gerenciamento de Infra-estrutura (ICT)
• Na V3, o Gerenciamento de Fornecedores é parte do processo de Desenho do Serviço, criando uma melhor integração no Ciclo de Vida do Serviço.
TRANSIÇÃO DO SERVIÇO
Gerenciamento de Mudanças
• Basicamente, as atividades e objetivos do processo permanecem identicas em ambas as versões.
• A V3 introduz o conceito de “Modelos de Mudanças”, definindo com mais ênfase
tipos diferentes de Mudanças e como elas podem ser direcionadas.
Gerenciamento de Projetos (Planejamento e Suporte a Transição)
• O Planejamento e Suporte a Transição é um processo novo na V3. A ITIL® V2 abordava alguns aspectos deste processo dentro do processo de Gerenciamento de Liberações, mas a V3 reforça consideravelmente está orientação
Gerenciamento de Liberações e Implantação
• A ITIL® V3 apresenta um detalhamento maior nas áreas de planejamento e teste
da liberação. Isto levou a adição de dois processos dedicados na V3, que na versão
anterior estavam sob o processo de Gerenciamento de Liberações:
-- Gerenciamento de Projetos (Planejamento de Transição e Suporte)
-- Validação e Teste do Serviço
Validação e Teste do Serviço
• O processo de Validação e Teste do Serviço é novo na V3. A V2 abordava alguns
aspectos sobre testes de liberações dentro do processo de Gerenciamento de Li-
75
berações mas a V3 reforça consideravelmente este aspecto.
• Os principais adendos na V3 estão nos detalhamentos durante os estágios de testes durante a Transição do Serviço e descrições das abordagens de testes correspondentes.
Gerenciamento do Conhecimento
• O Gerenciamento do Conhecimento foi adicionado como um processo novo na
ITIL® V3.
• Muitos aspectos do Gerenciamento do Conhecimento estão coberto por vários
processos na V2 – por exemplo, o Gerenciamento de Problemas era (e continua
sendo na V3) o responsável por gerenciar a base de Erros Conhecidos.
• Na V3, entretanto, o Gerenciamento do Conhecimento é definido como único processo responsável por centralizar e prover conhecimento para todos os outros processos de ITSM.
OPERAÇÃO DO SERVIÇO
Gerenciamento de Eventos
• O Gerenciamento de Eventos é parte do livro ICT Infrastructure Management na
ITIL® V2.
• As atividades e objetivos do processo são praticamente idênticos na V2 e V3.
• A ITIL® V3 vê o Gerenciamento de Eventos como um importante gatilho para os
processos de Gerenciamento de Incidentes e Gerenciamento de Problemas.
Gerenciamento de Incidentes
• As atividades e objetivos do processo permanecem praticamente idênticos nas
duas versões.
• A ITIL® V3 faz distinção entre Incidentes (interrupções no serviço) e Requisições
de Serviço (solicitações padrões oriundas de usuários, ex: reset de senha).
• Requisições de Serviço não são mais atendidas via processo de Gerenciamento de
Incidentes, para isso existe na V3 um novo processo chamado Cumprimento de
Requisição.
• Há agora um processo dedicado para lidar com emergências (“Incidentes Críticos”).
• Foi adicionada uma interface entre os processos de Gerenciamento de Eventos e
Gerenciamento de Incidentes. Eventos significantes são agora considerados como
gatilho para a criação de um Incidente.
Cumprimento de Requisição
• O Cumprimento de Requisição foi adicionado como um novo processo na V3 com
o objetivo de lidar de forma dedicada com Requisições de Serviços. Esta mudança
76
foi motivada claramente pela distinção mais do que bem-vinda feita na V3 entre
Incidentes e Requisições de Serviços.
• Na V2, o Cumprimento de Requisições era atendido pelo processo de Gerenciamento de Incidentes.
Gerenciamento de Acessos
• O Gerenciamento de Acessos foi adicionado como um novo processo na V3.
• A decisão de incluir este processo dedicado foi motivada por razões de segurança
de TI, como garantir acesso a serviços de TI e aplicações somente para usuários
autorizados
Gerenciamento de Problemas
• Atividades e objetivos do processo permanecem praticamente idênticos nas duas
versões, porém um novo sub-processo chamado “Revisão de Problemas Graves”
foi introduzido para revisar o histórico de solução de Problemas graves buscando
a prevenção de recorrências e obter lições aprendidas para o futuro.
MELHORIA CONTÍNUA DO SERVIÇO
• A V2 continha algumas atividades de Melhora Contínua do Serviço dentro do processo de Gerenciamento de Nível de Serviço, por exemplo as Revisões do Serviço
e gestão de um Plano de Melhoria do Serviço.
• A ITIL® V3 expande esta abordagem em um livro completamente novo, introduzindo processos dedicados para a avaliação e melhoria de serviços e processos.
77
Serviços: a ponte perdida entre negócios e TI
BRUNO CAIADO
Não é difícil notar que a principal mudança entre as versões 2 e 3 da biblioteca ITIL®
é o estabelecimento do ciclo do serviço. Se antes o serviço ficava meio tímido perto
dos robustos processos de entrega e suporte, agora ele foi definitivamente empossado como o astro principal. E não é por acaso: o serviço é o cerne do VALOR entregue
ao cliente, como mostra a sua própria definição (em tradução livre):
Serviço é o meio de entregar valor ao cliente, facilitando o atingimento dos resultados
que ele quer atingir sem que ele tenha que incorrer em custos e riscos específicos.
Parece complicado, mas não é. Significa que o cliente não quer fazer ele mesmo, mas
contratar alguém para tal. O “como” é responsabilidade deste alguém (o provedor) e
o cliente espera apenas o deliverable acordado. É uma forma diferente de dizer que o
serviço é uma caixinha preta com interfaces bem definidas e que os mecanismos internos são uma responsabilidade exclusiva do provedor.
Por exemplo, pense numa máquina que vende latinhas de refrigerante. O cliente não
quer (e nem precisa) saber como o fabricante faz a manutenção da máquina ou como
são os mecanismos internos dela. O objetivo dele é tão simples quanto ter um refrigerante gelado, no momento desejado. Esse é o “resultado” que o cliente quer atingir
como descrito na definição do serviço e é esse resultado que determina o deliverable
do serviço e até níveis de serviço. Portanto:
• RESULTADO ESPERADO PELO CLIENTE: um refrigerante gelado, no momento
desejado
• MEIO QUE FACILITA O ATINGIMENTO DOS RESULTADOS (“serviço”): Máquina
de refrigerante
• NÍVEIS DE SERVIÇO: Disponibilidade: 24x7 (afinal de contas, qualquer hora é hora
de um refrigerante) / Temperatura: 8°
Parece simplório, mas são os mesmos conceitos que estão embutidos no ciclo do serviço
do ITIL®. Da estratégia, passando pelo design, transição, operação e melhoria contínua,
o foco é um só: QUAL O RESULTADO QUE MEU CLIENTE ESPERA ATINGIR? E por
consequência, como eu defino uma estratégia e toda a minha operação para que ela
entregue os serviços esperados e que irão suportar o meu cliente no atingimento dos
seus objetivos e resultados.
O serviço parece tão ridiculamente óbvio que ninguém sabe mais qual é ou sente a necessidade de defini-lo. A ”conexão” entre o “serviço” e os resultados de negócio que o
cliente quer atingir se perdeu no meio do caminho. Enquanto isso, as organizações de
TI continuam a prestar os serviços “óbvios”: suporte UNIX, correio eletrônico ou processamento BATCH, só pra dar alguns exemplos. Nesse contexto, níveis de serviço di-
78
ficilmente vão dizer algo para o negócio e a organização de TI vai continuar como uma
“conta contábil pra alocar despesas de tecnologia”. E só. Não será o parceiro estratégico
que entende quais são os resultados que o negócio quer atingir e molda seus serviços
de acordo com eles.
Vamos dar um exemplo. Pense numa empresa de transportes aéreos. O que aconteceria se o website que vende passagens parasse? A venda através da web e conseqüentemente boa parte da fonte de renda da empresa iria ser interrompida. A criticidade
do site é muito evidente e por isso mesmo, é um ótimo candidato a “serviço”. Dentro do
ciclo, essa definição começa na estratégia de TI e toda a estrutura da organização de
TI é desenhada e operada para garantir que esses serviços sejam atendidos. O fato de
ela ser também “desenhada” (e não apenas operada) significa que esse trabalho é proativo e inclui desde a arquitetura dos componentes, a dimensionamento de equipes e
definição de métricas. Não estamos falando de um foco total (mas reativo) quando um
website cai e o gerente grita pedindo a restauração do serviço imediatamente. Estamos falando em estratégia, coordenação, sincronização e gestão.
Para que essa estratégia seja efetiva, uma definição de serviços alinhada com os objetivos de negócio é um passo fundamental. Usar “aplicações críticas” pode ser um bom
começo, mas não é por si só uma estratégia estruturada e coerente. É preciso pensar
em processos de negócio e KPIs (Key Performance Indicators) operacionais e financeiros. Em qualquer empresa, existem processos chave ligados a receita, rentabilidade
(como percentual da receita), ciclo operacional de caixa (contas a pagar e a receber) e
depreciação e amortização de ativos. No caso específico do web-site, ele se insere em
um processo de geração de receita, ligado a um sub-processo de venda direta ao consumidor e por sua vez ligado a KPIs como receita por canal e receita por cliente. Nesse
contexto, o objetivo de TI não é garantir 99,99999% de disponibilidade de um website, mas sim facilitar o atingimento, por parte do negócio, de seus objetivos de receita
por canal de venda. Isso significa, por exemplo, garantir a disponibilidade do web-site,
o dimensionamento para o volume corrente e planejado de vendas e o suporte adequado durante picos sazonais e campanhas, entre outros aspectos.
Esse alinhamento começa de cima e deve permear a organização, começando do entendimento por parte do CIO dos objetivos da corporação, passando por um desenho e arquitetura adequados e chegando até ao atendimento veloz, gentil e orientado a
serviço por parte do atendente do service desk. Evidentemente, estamos falando em
uma cultura focada no cliente e em suas necessidades e que está apoiada em ferramentas e processos de gestão. Para chegar a esse estado, a implantação de processos
ITIL® é apenas o começo de uma jornada sem fim, cujo objetivo não é chegar, mas melhorar continuamente em busca da excelência.
79
Sistemas de qualidade: a ilusão da melhoria
contínua
BRUNO CAIADO
Todo mundo quer qualidade. O fornecedor, o cliente, o dono da empresa ou até os
próprios funcionários das empresas. O que poucos sabem responder com convicção e
segurança é: o que afinal de contas é qualidade? É fácil pedir um serviço de “qualidade”,
o difícil é tanto definir, quanto fornecer e ainda ter que melhorar “continuamente” a tal
qualidade.
Para exemplificar, vamos recorrer a quem colocou em prática com maestria o conceito de melhoria contínua em linhas de produção: a Toyota. De forma bem simplificada,
o conceito adotado pela Toyota (e por milhares de outras empresas nos dias de hoje)
busca uma otimização entre não-conformidades e custo de produção, sendo “não-conformidade” qualquer evento que não se enquadre em uma faixa de referência. O fato
de estarmos falando de uma faixa de valores é um ponto chave: quer dizer que “excesso de qualidade” é uma não-conformidade também!
Um caso emblemático ocorreu na Nissan antes da revolução promovida pelo brasileiro Carlos Ghosn, hoje considerado uma referência mundial na gestão de grandes empresas. A fábrica japonesa tinha orgulho da perfeição com que fabricava seus faróis: os
recortes da superfície eram tão perfeitos, tão perfeitos, que apenas engenheiros com
um microscópio conseguiam reconhecer sua qualidade “superior”. Os clientes não davam à mínima para os faróis, mas os custos evidentemente iam às alturas. A questão
acabava sendo: o que adiantava ter qualidade na visão dos engenheiros se quem iria
usar os carros não reconhecia essa qualidade? E pior: não estava comprando os carros
e ainda achava os carros da concorrência melhores!
O pessoal de marketing veio à tona para tentar descobrir o que os clientes queriam de
verdade. Não foi nada surpreendente descobrir que os clientes queriam carros confiáveis, com design moderno e com preços razoáveis. Depois de descobrir o óbvio ululante, os engenheiros voltaram às pranchetas e focaram na confiabilidade dos faróis e
não na precisão dos recortes da superfície. O resultado? Faróis mais baratos, mas que
iluminavam tão bem quanto os primeiros. Esse princípio foi empregado não apenas
nos faróis, mas no design, no desempenho, no espaço interno e o resultado foi um aumento espetacular nas vendas, na receita e, pasme, na satisfação dos clientes. E mais:
a melhoria contínua passou a se concentrar em um ajuste fino entre um atendimento
cada vez mais próximo dos desejos dos clientes e os custos de produção, o que parece
óbvio, mas é simplesmente a fórmula mágica para a prosperidade nos negócios. O que
nos leva a um conceito de qualidade ligado à sustentabilidade do negócio, que continuamente se ajusta para:
• Atender aos clientes em termos de preço e adequação às suas necessidades e ex-
80
pectativas;
• Estabelecer uma relação coerente entre preço e custo;
Isso significa que qualidade não é uma referência absoluta, mas uma relação entre
preço e expectativa! A pergunta natural que se segue é: porque então precisamos de
“referências” como os sistemas de qualidade ISO 9000, 20000, 27000, etc? A resposta
é simples: para que serve uma referência de qualidade sem uma estrutura de acompanhamento e ajuste? Implementar um sistema de qualidade não é definir padrões absolutos, mas estabelecer os pontos de controle necessários para que os produtos e
serviços entregues estejam dentro das “faixas” de qualidade definidas. Ou seja: nenhum
ISO vai lhe dizer qual é a sua faixa de qualidade, mas sim o que você precisa controlar
e documentar para garantir que seus produtos estejam dentro dela. Especificamente
para serviços de TI, o sistema de qualidade ISO 20000 mostra o mínimo necessário (e
também o desejável) para que um serviço seja entregue de acordo com os acordos e
expectativas dos clientes, sejam lá quais forem estas expectativas. E é justamente aí
que entra a “ilusão” de sistemas de qualidade mal implementados. Se uma empresa for
certificada como aderente à ISO 20000, mas:
• Não definir sua faixa de qualidade de forma coerente e sustentável;
• Não implementar um sistema gerencial que leve a sério as referências de qualidade e REALMENTE promova os ajustes necessários continuamente;
• Não quebrar as barreiras e silos organizacionais com seus próprios e peculiares
conceitos de “qualidade”;
• Não promover uma visão de serviço em sua organização, fazendo das expectativas
e necessidades dos clientes sua principal referência na busca pela excelência.
.....então, a certificação ISO 20000 será mais um belo quadro pendurado em sua parede.
E tenho dito!
81
USMBOK o ITIL para gerenciamento de qualquer
serviço
RENÊ CHIARI
Enquanto a ITIL vem evoluindo do contexto de infraestrutura de TI para serviços de TI,
o USMBOK faz o caminho contrário, partindo do negócio.
É sabido que os conceitos preconizados pelas boas práticas de gerenciamento de TI,
particularmente a ITIL, poderiam ser aplicáveis em qualquer outro contexto de gerenciamento de serviços. E quando eu digo outro contexto, me refiro a serviços ‹não-TI›.
A proposta do USMBOK (Universal Service Management Body of Knowledge) é justamente essa. O autor, Ian Clayton, que por um acaso é co-fundador do itSMF-USA, descreve o USMBOK como:
“Um conjunto completo de reflexões e métodos do gerenciamento de serviços, universalmente aplicáveis a qualquer empresa de serviços, incluindo uma organização de
TI que é gerenciada como um fornecedor de serviços. Com seus conceitos e métodos enraizados no gerenciamento de produtos, é universalmente aplicável em todos
os setores de serviços e também pode atuar como um método de transformação para
qualquer organização que queira mudar e operar como um prestador de serviços, especialmente em uma organização de TI.”
A base para o USMBOK e como ele aborda o gerenciamento de serviço está profundamente enraizada nos conceitos de gestão de produtos e da teoria de marketing de
produto, respeitando e aproveitando o trabalho de gigantes do marketing, como Theodore Levitt, Richard Chase, Richard Normann, Mary Jo Bitner, e tantos outros.
Na verdade, a definição de gerenciamento de serviços e os elementos da estrutura de
gerenciamento de serviço detalhados no USMBOK são elaborados a partir de reflexões sobre a gestão de negócios. O USMBOK foi desenvolvido usando o pensamento
‘de fora para dentro’, ou o pensamento centrado no cliente.
Já a nossa boa e velha ITIL é tradicionalmente focada em organizações de TI. Nas mais
recentes atualizações amadureceu para um modelo de processo com foco no gerenciamento de ciclo de vida de um serviço, o que é um bom sinal.
Minha opinião é que, em algum momento, USMBOK e ITIL poderão ser referências
complementares. Uma partindo dos padrões da indústria e permeando o mundo de TI,
e a outra nativa do mundo de TI e permeando horizontes mais amplos. E como um bom
curioso, já estou com o meu exemplar.
Para saber mais sobre o USMBOK, visite www.usmbok.com
82
Artigos para Aquecer a Carreira
Certificações abrem portas mas não garantem o
seu emprego
RENÊ CHIARI
A verdade é que as certificações vão dar destaque ao currículo, e em muitos casos serão
de fato o passaporte para um emprego. Mas uma coisa é conseguir um emprego, a outra é se manter nele. Para isso serão necessários mais que papéis com chancelas, PIN´s
e assinaturas bonitinhas. Competências e habilidades pessoais deverão ser demonstradas no dia a dia.
Antes de entrar em uma bela enrascada, recomendo refletir sobre os seguintes pontos:
1. Antes de se candidatar a uma vaga, procure entender quais serão suas atividades,
a sua rotina, principalmente se você estiver mudando de uma função técnica para
uma função de gestão. Em alguns casos a mudança é bem agressiva e vai exigir alguns meses para adaptação. Levei três meses para “aterrissar” e entender o que de
fato eu estava fazendo naquela função quando migrei da área técnica para a área
de gestão. Corri um risco enorme pois não consultei ninguém antes. Não cometa o
mesmo erro.
2. Seja prudente, não minta. Assumir coisas que nunca fez e depois ficar com uma
tremenda saia justa por não ter a miníma ideia de como realiza-las pode custar o
seu emprego, e pior, a sua reputação. O mundo de TI é muito pequeno, não vale a
pena correr este risco. Se você tem apenas um certificado na mão e nenhuma experiência, vá em frente. Muitas empresas preferem contratar profissionais mais
“crus” e transforma-los nos moldes da empresa.
3. Evite passar a imagem de “sabe-tudo”. Quando acumulamos um certo número de
certificações e experiência prática tendemos a achar que conseguimos lidar com
todos os desafios facilmente. Não caia nessa. Me recordo de no mínimo três momentos da minha carreira onde conclui que não sabia nada de ITIL. Manter a humildade e estar sempre aberto a novos pontos de vista é uma boa forma de não
prejudicar um projeto importante e como consequência ser convidado a procurar
outra empresa.
4. Por ultimo e não menos importante: Esteja antenado. Coisas acontecem e mudam
o tempo todo. A ITIL mudou de v2 para v3 e em 2011 já ganhou um update da v3,
e não foram poucas mudanças. Estar atualizado pode ser o pulo do gato e garantir
os poucos centésimos de pontos que o classificam em uma seleção de emprego.
Além disso, a vivência prática de outros pode servir como bagagem para futuros
desafios em sua carreira.
Bem, mas se você leu este artigo até aqui, ou acompanha as discussões no LinkedIN e
outros fóruns sobre o assunto, então já é sinal de que essa dica você já considerou! ;-)
84
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 profissionais. Das profissionais, fico com o Linkedin sem sombra de dúvidas. Além de ter um
visual muito mais clean que o Facebook (que é a moda atual), o design é totalmente
voltado para o mundo corporativo.
Ainda vejo muitos exageros dos companheiros profissionais de TI, que acabam criando alguns jargões totalmente desnecessários e acabam banalizando funcionalidades
bacanas dentro do Linkedin. Ai vão as principais atitudes que devem ser evitadas:
• Assinatura “Sopa de Letrinhas” - Você já deve ter visto alguns profissionais que incorporam títulos conquistados em seus nomes. Por exemplo: Zezinho, PMP, ITIL®,
CISA, CISM, Black Belt...além de ser uma tremenda poluição visual, mesmo que
tenha boas intenções você pode ser considerado um “mala”.
Que tal ser um pouco mais discreto? O Linkedin permite que você adicione suas especializações em seu perfil. Além disso, já existe um app chamado box.net que permite
que você insira arquivos ao seu perfil. Inserir os seus certificados em PDF em uma pastinha discreta fica muito mais profissional.
• Caçador de Recomendações - As recomedações são extremamente importantes
aos olhos de recrutadores e possíveis parceiros de negócio. Nada como ganhar
aquela recomendação de seu ex-gerente ou de um Cliente. Mas cuidado com os
exageros, tenha sempre em mente que uma boa (e sincera) recomendação vale
mais do que 30 recomendações estilo «Linha de produção». É a mesma coisa que
vender alfinete de plastico no leilão online só pra ter um número maior de qualificações positivas.
• Cuidado com a auto-promoção - É sempre interessante anunciar uma nova conquista profissional, seja uma certificação, um novo emprego, etc, mas é importante ter bom senso nessas horas. Fazer da rede uma espécie de Twitter e comentar
cada passo de sua vida profissional pode tornar a leitura de suas notas cansativas,
e mais uma vez, você corre o risco de virar “o mala”. O Linkedin tem seções muito
bem diferenciadas para que você divulgue uma novidade, uma atualização de seu
perfil, uma nova discussão e até mesmo uma vaga de emprego. Utilize-as!!
• Aqui se diz, aqui se paga - Cuidado com o que escreve por ai. Falar mal da ex-empresa ou de ex-colegas de trabalho pode ser uma atitude mal interpretada por
qualquer pessoa de RH que estiver analisando o seu perfil em um processo seletivo. O que? Acha mesmo que as empresas de RH não digitam o seu nome no Google
para saber o que você anda/andou aprontando pelo mundo virtual? Bem-vindo aos
tempos modernos da total falta de privacidade! ;-)
85
Obs: já ouvi vários casos de contratações para cargos executivos onde a seleção foi feita através do Linkedin. Vale a dica!
• Use o Linkedin estritamente para fins profissionais - A proposta da rede social é
muito clara: é uma rede social voltada para profissionais! Deixe para participar da
comunidade “Eu como pizza fria amanhecida com Toddy” em redes como Orkut
e Facebook, e lembre-se de gastar um tempo configurando a privacidade do seu
perfil e evitar futuros constrangimentos, por exemplo, o seu chefe recebendo uma
atualização do seu Facebook informando que você acabou de atacar uma máfia,
em pleno horário de expediente...
Com estes pequenos cuidados você garante um perfil clean e atraente em uma das redes sociais voltadas a profissionais mais promissoras da atualidade.
Já tem uma conta no Linkedin? Então aproveite para visitar e fazer parte do grupo
ITIL® na Prática
86
Tirei a certificação ITIL e agora?
GUSTAVO TAVARES
Antes de qualquer coisa Parabéns. Se vc possui uma certificação ITIL® você comprovou,
por meio de um sistema de avaliação confiável, que possui os conhecimentos necessários para implantar e gerenciar as práticas do ITIL® em uma organização. Existem, é claro, diferentes níveis de conhecimento. Um profissional com uma certificação de fundamentos não possui as mesmas comprovações de conhecimento do que um profissional
certificado como ITIL® Manager. Mas a despeito do nível de conhecimento, ambos são
profissionais preparados para implantar e gerenciar o ITIL® em uma organização? Não
necessariamente...
Antes de responder diretamente esta pergunta, me permita buscar auxílio nas teorias
modernas de recursos humanos. Nestas teorias existe um conceito muito relevante
que é o conceito de competência pessoal. Uma competência pessoal pode ser entendida como um atributo de determinado profissional que o possibilita atingir determinado objetivo. Ao dizermos então que um profissional possui preparo para implantar
e gerenciar o ITIL® em uma organização estamos também dizendo que o profissional
possui a competência de implantar e gerenciar processos baseados no ITIL®. Até aí
nada de novo. Mas voltando a nos sustentar nas teorias de RH, proponho entendermos um pouco mais o que são as competências.
As competências são atributos do profissional compostas de três elementos: conhecimentos, habilidades e atitudes. Cada competência possui uma diferente combinação
dos três elementos. E os três elementos devem, obrigatoriamente, estar presentes para
que um profissional possa ser possuidor de determinada competência. As certificações
profissionais, sejam acadêmicas ou emitidas por instituições de classe, comprovam
que um profissional possui os conhecimentos exigidos para exercer determinada atividade. Mas elas não comprovam que o profissional possui as habilidades ou atitudes
necessárias para atingir os objetivos relacionados àquela atividade. E não teria como
ser diferente. As habilidades e atitudes relacionadas a uma competência são diretamente relacionadas ao contexto onde a competência será aplicada. Embora os conhecimentos tenham um caráter mais universal, as habilidades e atitudes para aplicar os
conhecimentos em um ambiente militar são totalmente diferentes das habilidades e
atitudes necessárias para aplicar os conhecimentos em um ambiente privado. Mesmo
em um ambiente privado (ou militar) as especificidades de uma organização exigem
habilidades e atitudes diferentes de outra. Criar um sistema de avaliação que seja capaz de medir habilidades e atitudes de forma padronizada é um exercício que tende
ao fracasso, seja por questões metodológicas ou por questões de abrangência de situações possíveis.
Desta forma, você que é um profissional certificado em ITIL® precisa descobrir quais
habilidades e atitudes são necessárias para obter sucesso na implantação e no geren-
87
ciamento de processos baseados no ITIL® e deve se preocupar em desenvolver esta
competência. O certificado foi o seu primeiro passo; existem outros a frente. E se quer
saber, os próximos não serão tão fáceis como foi a certificação. A parte ruim é que vc
não vai conseguir uma lista de todas as habilidades e atitudes que são necessárias para
adquirir ou desenvolver sua competência. Isto porque esta lista não existe. Como já
falamos, cada ambiente ou situação requer um conjunto de habilidades e atitudes diferentes. Mas acredito que possamos discutir um pouco mais a respeito.
Se pensarmos no ITIL® como modelo de gestão de operações de TI, temos um conjunto de papéis que são definidos no framework. E na maior parte estes papéis já trazem
um conjunto de habilidades e atitudes relacionadas. Mas e as habilidades e atitudes do
profissional que vai implantar e gerenciar uma iniciativa de adoção do ITIL®? Eu tenho
alguns palpites sobre as habilidades necessárias:
1. Deve saber ouvir e interpretar as pessoas: iniciativas de adoção do ITIL® envolvem mudanças na maneira de trabalhar das pessoas. Mas o modo atual de trabalho de uma organização não é ruim simplesmente porque não é aderente ao ITIL®.
Na verdade, existem inúmeros casos onde o modelo de trabalho atual é melhor
do que o prescrito no ITIL®. Um profissional com competências de implantação e
gerenciamento de iniciativas de ITIL® deve ser capaz de ouvir as restrições e “reclamações” das pessoas envolvidas e deve ser capaz de avaliar quando as práticas
atuais são mais adequados ou mesmo melhores do que as práticas prescritas no
ITIL®;
2. Deve ser capaz de entender o contexto da organização: iniciativas de adoção do
ITIL® ocorrem em um ambiente cheio de restrições e influenciadores. As prescrições do ITIL® são perfeitas para serem aplicadas ipses literis em um ambiente
perfeito. Ambientes imperfeitos exigem adaptações das prescrições às limitações
e influenciadores existentes. Um profissional com competência em implantação e
gerenciamento de iniciativas de ITIL® deve ser capaz de interpretar estas limitações e descartar prescrições do ITIL® que não sejam compatíveis com a organização;
3. Deve ser capaz de imaginar soluções alternativas: Como já conversamos, existem
inúmeras restrições e influenciadores determinando como uma iniciativa de adoção do ITIL® evolui. Em alguns casos estes limitadores chegam ao ponto de inviabilizar a adoção de determinadas práticas fundamentais para o sucesso da iniciativa
como um todo. Nestas situações, o profissional com competência em implantar e
gerenciar iniciativas de ITIL® deve conseguir formular soluções alternativas que
garantam o sucesso do projeto mesmo que uma ou mais das suas partes críticas
tenham sido descartadas.
A lista pode continuar por muitos itens ainda. E olha que eu nem comecei a falar das
atitudes. Arrogância, impaciência, falta de flexibilidade são algumas, por exemplo, que
não combinam com um profissional de ITIL®. Na verdade, quando estas atitudes estão
88
presentes elas se tornam uma das causas do insucesso dos projetos. O pior são os casos em que um profissional, ao obter os conhecimentos e comprovar que possui estes
conhecimentos por meio de uma certificação, se torna arrogante por conta do novo
título e passa a levar seus projetos ao fracasso. Infelizmente ainda acontece muito.
Mas estas são as exceções. Se vc se certificou recentente, desejo sucesso no desenvolvimento da sua competência em implantar e gerenciar iniciativas baseadas no ITIL®. Se
vc já se certificou há mais tempo, também desejo sucesso no desenvolvimento de sua
competência, porque esta é uma atividade que não acaba nunca.
89
Vale a pena investir em certificações profissionais?
CLAUDIA MARQUESANI
Um colega me perguntou um dia desses: o que é mais importante para ter sucesso
profissional – ser certificado ou ter experiência prática em gestão de serviços?
Gostaria de falar um pouco sobre CARREIRA e a busca pelo sucesso …
É apenas uma opinião (extremamente pessoal), mas acredito que: o importante para
ter sucesso profissional é ter COMPETÊNCIA para fazer aquilo o que você se propôs.
O QUE É COMPETÊNCIA?
COMPETÊNCIA = CONHECIMENTO + HABILIDADE + ATITUDE
CONHECIMENTO é ter formação. Imaginem um médico. Ele precisa do diploma universitário para exercer a medicina. Precisa estar formado. Ter conhecimento é investir em
uma boa universidade, em certificações, em cursos técnicos, pós graduação, MBA, atualizações constantes que todos nós estamos cansados de saber que são necessários,
mas que não são suficientes por si só. E porque será que sozinho CONHECIMENTO
não diz nada?
De que vale ter todo o CONHECIMENTO do mundo, se não tivermos HABILIDADE?
Quantas pessoas não passam anos estudando e quando se “aventuram” no mercado
de trabalho, não tem nenhuma experiência, nenhuma vivência PRÁTICA para exercer
determinada função. Como investiram na carreira durante anos (e esse investimento é
sempre muito alto), querem o retorno imediato e é muito difícil que isso aconteça. Nós
investimentos muito tempo e dinheiro nessas formações e o mercado de trabalho não
segue esse ritmo. Não adianta achar que você vai fazer a maior certificação em ITIL®
ou segurança e que com isso seu salário dobrará. Dá para imaginar um médico sem habilidade? Um médico que não fez residencia? Um residente ganhando um salário altíssimo? Vamos com calma…
Se você tem CONHECIMENTO e HABILIDADE, é meio caminho andado. Mas também
não é suficiente. Durante um processo seletivo ou uma avaliação de promoção, sua
ATITUDE também será avaliada. E digo com TODA CERTEZA DO MUNDO: ás vezes
isso é mais importante para quem irá tomar a decisão do que conhecimento ou habilidade. Atitudes são habilidades interpessoais, como por exemplo: a capacidade de
ser positivo diante de pressões, a capacidade de trabalhar em equipe, sua resiliência
(trabalhar normalmente mesmo diante de situações adversas)… enfim, é sua forma de
“encarar” o trabalho e de fazer dele algo positivo, construtivo e bem sucedido. Imaginem o médico que entra em pânico quando seu paciente, na sala de cirurgia , sofre uma
parada cardíaca ? O que ele faz? Sai correndo? Começa a chorar? Ou toma a frente e
tenta ressuscitar o paciente? Essa diferença de comportamento se chama atitude!
90
Então quando sou perguntada se vale a pena investir em certificações, eu respondo:
SIM!!!
Agora se me perguntarem se só isso é suficiente, eu digo com toda certeza : NÃO!!!
É preciso muito mais que um diploma colado na parede para ser um bom profissional. É
necessário ter CONHECIMENTOs, HABILIDADEs e ATITUDEs suficientes para exercer sua função . Eu realmente acredito que um profissional de sucesso é aquele que
tem a sabedoria para equilibrar essas três variáveis.
Seja você um deles. Começar a investir em si mesmo, além de dar um prazer enorme,
aumenta a auto estima e as possibilidades de sucesso em sua carreira. Digo possibilidades, porque tem uma quarta variável , uma coisinha que ás vezes ninguém se lembra
, mas que também pode fazer toda a diferença, A SORTE!
Só que não vamos falar dela hoje porque está ficando tarde e eu quero “curtir” meu
feriado… Mas que dá um assunto para outro post, isso dá! Pensem nisso!
91
Artigos Para Por a Mão na Massa
5 dicas para a Gestão de Problemas Proativa
RENÊ CHIARI
Uma das principais atividades do processo de Gerência de Problemas é identificar
tendências, através do sub processo de gestão proativa de Problemas.
No dia a dia, esse conceito acaba se perdendo, pois a gestão de problemas acaba sempre demandando quase 100% de seu tempo a identificar a causa raiz dos problemas
relacionados a incidentes críticos (super reativos!). Isso se dá de forma desesperada e
sob forte pressão. A alta administração exige que as causas e soluções de contorno sejam identificadas rapidamente e isso muitas vezes ocasionam respostas ineficazes, de
um processo onde tempo está diretamente relacionado a qualidade da investigação e
solução proposta.
Ou seja, não sobra tempo para analisar tendências de capacidade , de disponibilidade
e de incidentes recorrentes. Fica quase impossível iniciar planos de melhorias e avaliar se a forma como estamos tratando os problemas maiores está sendo conduzida de
maneira adequada.
Os ganhos em realizar uma análise de problemas proativa podem ser:
• Operacionais: ao analisar a tendência de incidentes e identificar que a solução de
incidentes recorrentes irá beneficia o Service Desk e áreas de suporte especializados, solucionando incidentes repetitivos. Isso tratá menos carga de trabalho e
maior tempo para ser dedicado em melhorias (parar de apagar incêndio).
O detalhe é que isso acaba sendo um beneficio indireto para o negócio também. Por
exemplo: Imaginem que o Service Desk gasta aproximadamente 10% de seu tempo, em
uma pequena empresa, resolvendo incidentes em primeiro nível de senha bloqueada.
A gerencia de problemas poderá investigar a causa raiz desses incidentes e resolve-los
definitivamente. Com isso sobra mais tempo para o Service Desk atender ligações,
maior disponibilidade para o usuário, aumento da eficiência e reflexo na satisfação do
usuário e do negócio.
• Negócio: quando uma análise de tendências inibem e previnem incidentes que poderiam vir a acontecer e trazer impacto direto ao negócio. Por exemplo: junto com
a disciplina de gerenciamento de capacidade, utilizar ferramentas para a identificação de tendências e atuar para evitar que incidentes relacionados a capacidade
ocorram.
A seguir, listo algumas sugestões para implementar esta atividade:
1. Não é simples fazer uma análise proativa de problemas. Identifique as disciplinas
parceiras:
93
-- Incidentes poderá apresentar tendencia de incidentes recorrentes que deverão
ser investigados pela gestão de problemas.
-- Disponibilidade poderá identificar tendências de issues relacionados a disponiblidade e atuar em conjunto com o gerenciamento de problemas para solucioná-los.
-- Capacidade também possui técnicas para que issues de capacidade sejam identificados e poderá contar com a gerencia de problemas para tratá-los.
Lembre-se : a gerencia de problemas sozinha não é nada. É um processo extremamente
dependente dos outros.
2. Defina os papeis e responsabilidades. Escolha sempre os técnicos mais experientes, que conheçam muito bem tanto o ambiente quanto o negócio da empresa. Nem
preciso comentar que o Gestor de Problemas é o dono disso tudo, né? Documente
as principais tarefas, e seus respectivos donos. Você pode usar uma matriz RACI
para facilitar. Temos um modelo em nossa área de Downloads.
3. Defina o que você quer fazer (e o que já consegue imediatamente) , a metodologia e periodicidade. Fará uma análise de incidentes recorrentes? Uma análise de
tendências de relatórios de capacidade? Uma análise de issues de disponibilidade? Será aplicada alguma técnica ou metodologia específica? Serão feitas reuniões
com as equipes técnicas para discutir os problemas? Quantas vezes? Qual será o
meio de comunicação?
4. Definir quais serão os controles de performance e resultados desta atividade. Defina alguns controles para saber se as atividades estão sendo desempenhadas satisfatóriamente, e se os resultados esperados estão sendo atingidos. Ex: % de redução de incidentes recorrentes , # de incidentes evitados através da investigação
e solução definitiva de problemas.
5. A quinta e principal dica é: Não acelere o processo e defina equipes separadas para
a gestão proativa e reativa de problemas. A gestão proativa de problemas precisa
de tempo para investigar, analisar cada variável envolvida no processo. A gestão
reativa sofre pressões para explicacões e soluções , sejam elas de contorno ou definitivas. O tempo da gestão de problemas reativa é mais curto, infelizmente. Se as
duas equipes tiverem o mesmo papel dentro de uma organização, a gestão de problema proativa simplesmente ficará em segundo plano e deixará de ser feita.
94
5 passos para definir um bom Acordo de Nível de
Serviço SLA
RENÊ CHIARI
Apesar do SLA ter se tornado um jargão bastante conhecido e utilizado, é comum encontrar documentos mal escritos, com falta de informações e definições confusas até
para o próprio provedor de serviços. Isso não é bom nem para o provedor, e nem para
o cliente, pois dá margem para discussões que podem comprometer o bom relacionamento entre as partes, e em casos mais graves até causar uma rescisão contratual
(no caso de provedores de serviço externos) ou a decisão pelo outsourcing (no cado de
provedores de serviço internos).
É preciso entender que um acordo de nível de serviço é muito mais do que um documento descrevendo prazos de atendimento e resolução de chamados. Trata-se de um
acordo que deve deixar claro todas as garantias que o provedor de serviço oferece em
relação aos serviços que foram contratados, e a forma como estes níveis de serviço
serão medidos, reportados e melhorados continuamente.
Para resumir: o (bem) combinado não sai caro!
Se você nunca desenvolveu um SLA ou acha que o utilizado atualmente na sua empresa precisa de ajustes, responder as seguintes perguntas é um bom começo. Lá na ITIL
(Service Design) você vai encontrar um modelo bastante robusto de um Acordo de
Nível de Serviço. O que eu estou sugerindo adiante é uma abordagem mais simples e
realista.
Pergunta 1: O que?
Qual o serviço que está sendo objeto deste acordo? Contextualizar o serviço já no
primeiro capítulo é uma boa pedida. Aqui também pode-se fazer referência ao Catálogo de Serviços.
Importante incluir as exclusões, que são as situações em que este acordo de nível de
serviço não é aplicável. Isto evita uma série de aborrecimentos futuros. Um dos assuntos mais comumente esquecidos é o “Stop SLA” (ou pausa no SLA), onde são considerados os períodos em que os casos estão sob tratamento de suporte do próprio cliente,
ou seja, o provedor de TI não deveria assumir o ônus por este período de tempo.
Pergunta 2: Quando?
Quando o serviço deve ser fornecido? Deveria ser incluído no mínimo, o percentual de
disponibilidade do serviço, o horário do serviço (período em que deve estar disponível,
por exemplo: em horário comercial, 24x7, etc), o horário do suporte ao serviço (Service
Desk por exemplo). Importantíssimo também considerar condições de exceção, como
feriados, finais de semana, etc.
95
Pergunta 3: Quanto?
Esta pergunta não tem relação com valor a ser pago pelo serviço, que normalmente já
definido no Catálogo de Serviços, e sim em qual quantidade e com qual desempenho o
serviço será entregue. Ou seja, requisitos de capacidade.
Pode-se incuir por exemplo: Taxas de resposta, número máximo de transações simultâneas, usuários concorrentes, etc.
Outra boa sacada é considerar “lotes” e “franquias” de requisições de serviços. Por exemplo: considerar um lote máximo de requisições simultâneas do tipo X. Caso a quantidade ultrapasse o limite, será necessário como uma mudança (exige aprovação e um
projeto associado). Em outros casos é possível acordar cobrança adicional quando a
franquia de requisições for atingida, como forme de influenciar o comportamento dos
usuários.
Pergunta 4: Como?
Talvez este seja o capítulo mais extenso, e com direito a incluir alguns tópicos:
Papeis e responsabilidades
Uma boa prestação de serviço exige que não somente o provedor, mas também o cliente, cumpram alguns deveres. Se engana quem acha que o cliente (e os usuários) não
têm responsabilidades.
Suporte ao Cliente
Neste tópico, algumas informações importantes como os possíveis canais de contato
do cliente com o Service Desk, os tempos de resposta para cada tipo de caso de acordo
com os critérios de priorização, matriz de escalonamento, etc, podem ser incluídas.
Reporte e análise crítica do serviço
A maioria dos Acordos de Nível de Serviço não deixam claro a periodicidade e a forma
como os níveis de serviço serão medidos, reportados, analisados criticamente junto ao
Cliente e continuamente melhorados. Este momento é uma excelente oportunidade
não só para identificar os pontos falhos na entrega de serviços, mas também oportunidades de novos negócios. Vale lembrar que este item é, inclusive, um requisito da norma ISO/IEC 200000.
Canal de Reclamação
Seja lá qual for o nome mais adequado: ombudsman, ouvidoria, etc. O importante é
mencionar um canal onde o cliente possa reclamar caso não esteja satisfeito com o
serviço, e garantir que será dado um tratamento adequado a esta reclamação.
Pergunta 5: E se der $%@&... ??
96
Como dizem os americanos: “coisas” acontecem...
O provedor deve estar preparado para imprevistos de grande magnitude. O Acordo
de Nível de Serviço pode deixar claro para o Cliente a existência de um plano de continuidade, ou considerações que evidenciem que o provedor gerencia os riscos de seus
serviços, endereçando respostas adequadas para cada um deles.
Ao ler este artigo, definir um Acordo de Nível de Serviço pode parecer fácil mas está
longe disso. Estes são apenas alguns dos ingredientes básicos de uma atividade que
leva tempo, e muita discussão.
97
25 dicas infalíveis para que seu projeto de
implantação da ITIL seja um fracasso
CLAUDIA MARQUESANI
Hoje é dia 25, e para comemorar nada melhor que um manifesto contra tudo que é feito de errado por aí.
Abaixo cito 25 dicas “incríveis” que podem fazer com que qualquer projeto de gestão
de serviços afunde. São elas:
1. Não trate o projeto como um projeto. Não utilize nenhuma metodologia para
acompanhamento. Implementar gerenciamento de serviços em uma organização
é fácil, rápido e nem precisa de muito esforço. Vá tocando «o barco» como der.
2. Achar que ITIL® é um “projeto” que termina e você nunca mais vai precisar ouvir
falar dele.
3. Seja cego, surdo e mudo para as necessidades do negócio. Você está gerenciando
serviços de TI - nada a ver com o negócio!
4. Não envolva o cliente na definição de critérios de qualidade. Qualidade é você
que sabe o que é, afinal você é O CARA de TI! Pensando bem, critérios de qualidade... quem precisa deles?
5. Comece o processo de gerenciamento de serviços , sem ter claro o entendimento do que realmente é um serviço para o seu cliente. Tenha certeza: o processo
será um verdadeiro “sucesso”. Vamos gerenciar aquilo que nem mapeamos e nem
conhecemos... maravilha!
6. Destaque somente ganhos operacionais e deixe ganhos financeiros em segundo
plano (afinal, qualidade é o que interessa, o resto não tem pressa).
7. Coloque um “Zé Ninguém” (tipo este com cara de perdido da figura ao lado) para
ser gerente de nível de serviços.
8. Coloque um gerente financeiro que não entenda de TI ou vice versa, um gerente
de TI que não entenda de finanças.
9. Não invista em treinamentos: Faça somente um treinamento quando o processo
entrar em produção. Afinal, treinamentos são direcionados a pessoas e a parte importante mesmo da ITIL® são os processos e as ferramentas.
10. Não comunique as pessoas na profundidade e abrangência necessárias: campanhas de conscientização para que todos saibam o valor agregado de um bom gerenciamneto de serviços é completamente opcional. Um luxoooo!
11. Avise que os ganhos demoooooooram para aparecer.... não defina «quick wins”,
porque essa palavrinha em Ingles é muito difícil de ser lembrada.
12. Escreva todos os processos pensando em entregá-los rapidamente. Afinal , depois 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”.
98
14. Como é complicado configurar ferramentas, comece pela configuração delas antes de definir adequadamente o processo.
15. Todos os processos devem emitir relatórios, mas quanto mais eles tiverem termos técnicos e complexidade, mais isso mostrará o valor agregado de TI. Afinal,
o cliente sabe tudo de TI, né?
16. Ache que processos ITIL® são procedimentos que indicam como as pessoas devem executar suas tarefas diárias.
17. Utilize exatamente os fluxogramas sugeridos pela ITIL®, assim vc não corre o risco de alguem falar que vc não está em «Compliance”.
18. Adote e adapte. Pode adaptar a vontade. Faça adaptações até não entender mais
qual era a proposta inicial. Afinal a ITIL® diz: ADOTE E ADAPTE.
19. Se estiver dificil definir um dono para um processo, divida em “duas bolas”: assim
você vira o amigão da galera.
20. Desenhar processos, mas seguir a regra de quem “grita mais alto” ou quem “é seu
amigo” ou quem “tem mais influência” para decidir o que fazer.
21. Desenhar um manual de processos lindo, mas tão utilizado que no final ele vai
virar um suporte de um monitor velho. Legal, ergonomia também é importante,
certo?
22. Melhoria contínua. Fácil.... Vamos promovê-la baseando-nos em critérios obscuros, que mudam a cada dia ou baseados simplesmente na intuição.
23. ITIL® é coisa SÓ de Infraestrutura. Logo, sua equipe de desenvolvimento de softwares ou fornecedores não tem NADA a ver com ITIL®.
24. Achar que o presidente da sua empresa também não tem NADA a ver com ITIL®.
Que raios ele tem que abrir chamado no service Desk? Para ele nós atendemos na
hora, sem prazos, sem classificações, sem processo! Afinal, ele é VIP.
25. Controlar o processo e esquecer do serviço. As vezes o trabalho para manter um
processo é tão intenso que o serviço e sua qualidade ficam em segundo plano. Quem
nunca passou por isso?
Alguém se lembra de mais alguma dica para o FRACASSO?
Se sim, vale a pena citar, porque na prática tudo isso acontece e é bom ser PREVINIDO!
Por isso é tão difícil ter sucesso na implementação do gerenciamento de serviços...
Quem sabe eu não transformo as 25 dicas em 50?
99
Catálogo de Serviços: Para que complicar?
CLAUDIO DODT
Nos projetos de gerenciamento de serviços de TI em que participei um quickwin certo sempre foi o catálogo de serviços. Afinal, nada mais difícil que prestar serviços aos
usuários sem que eles saibam o que há disponível.
Mas por que criamos tanta dificuldade em adotar essa ferramenta se isso é algo com
o que 90% das pessoas tem um contato quase diário? Qualquer pessoa que já foi a um
restaurante e pediu o velho e bom menu acabou de receber um catálogo de serviços.
Um bom catálogo deve ser exatamente isso, uma lista dos serviços prestados pela TI
funcionando da mesma forma que um cardápio de restaurante e permitindo que o fornecedor de serviços demonstre para seus clientes quais são as opções disponíveis, os
modos como estas são entregues e, quando pertinente, os custos envolvidos.
Catálogo de Serviços - apenas uma parte do portfólio e deve ser controlado através
do gerenciamento do conhecimento.
Um ponto importante ao qual nem sempre damos a devida atenção é separar o catálogo de negócios do catálogo técnico e até mesmo da visão do usuário. Excesso de informação pode causar tanta confusão quanto à falta da mesma.
Imagine explicar para um usuário que o correio eletrônico depende de vários itens de
configuração que vão desde um cluster de servidores, anti-spam, antivírus de borda,
banco de dados, roteadores, firewalls e assim por diante. Essas informações podem
ser vitais para a equipe de suporte na hora de solucionar incidentes e problemas, mas
o usuário quer simplesmente saber como acessar o email.
As diferentes visões do catálogo de serviços
Entender o negócio e equilibrar a quantidade de informações correta que vai permitir
ao seu cliente utilizar o serviço de forma adequada é a receita de sucesso de um catálogo de serviços eficiente. Um bom exemplo pode ser visto nos produtos e serviços da
Google, que foi desenhado de forma minimalista e é extremamente eficiente.
Catálogo de produtos da google - Visão do usuário
Outros modelos de catálogo bastante interessantes podem ser vistos aqui e aqui, com
diferentes graus de detalhamento, mas com certeza bastante eficientes para o seu público alvo, o cliente.
Uma boa dica, especialmente se você não tem um sponsor, é a metodologia KISS, comece simples! Uma planilha no Excel se for bem organizada e divulgada pode se tornar
um excelente catálogo de serviços.
Links e referencias:
100
www.google.com.br/intl/pt-BR/options/
www.itap.purdue.edu/service/catalog/alpha/
its.ucsc.edu/service_catalog/index.php
101
ITIL – é preciso saber vender
CLAUDIA MARQUESANI
Que o ITIL® - este “famoso”conjunto de melhores práticas para prestação de serviços
em TI -traz ganhos para a TI e para o negócio a longo prazo, isso a maioria sabe. A
maioria também tem conhecimento que isso acontece porque , o principal benefício
do Gerenciamento de Serviços é tornar a TI mais alinhada aos requisitos de negócio.
Isso faz com que a área de tecnologia da informação exerça realmente sua função dentro de uma empresa: que é contribuir para que a organização atinja seus objetivos de
negócio. Parece fácil falar, mas não é fácil mostrar o ganho associado a implementação
do ITIL® para uma organização . Só quem já tentou “vender” uma idéia relacionada a
implementação de ITIL® para altos executivos, tem idéia da dificuldade que é mostrar
os benefícios e o valor agregado (financeiro??) de um projeto desse porte. O que fazer
então para conseguir “vender” o ITIL® para sua organização?
Existem algumas dicas que podem ser bastante úteis na implementação (e também na
venda) e espero contribuir para quem estiver passando por esta árdua fase.
São elas:
1. Identifique qual a VISÃO, tenha claro, em qualquer implementação, qual é o real
OBJETIVO buscado e os ganhos que essa meta ao ser alcançada trará para seu negócio. Não há vento favorável para aqueles que não sabem para onde ir, mas você
precisa também saber o que fará (resultados que você espera obter) quando chegar lá!
2. Lógico, veja se esses OBJETIVOS são REALISTAS. Não adianta dizer que irá implementar uma central de serviços e que no primeiro mês reduzirá 90% das horas de
trabalho da equipe de TI com soluções em primeiro nível com zero por cento de
taxa de abandono. Se souberem de alguma empresa que conseguiu esse índice assim que implementou um Service Desk, por favor, me avisem - eu quero trabalhar
para essa organização!!!
3. Transforme a grande “viagem” da implementação, em “pequenas viagens”. Defina
GANHOS RÁPIDOS. Fica mais fácil dessa forma vender seu projeto. Quer redesenhar a infraestrutura para aumentar a disponibilidade de algo vital para seu negócio? Isso demora, não é? Não seria mais rápido aplicar técnicas da gerência de
disponibilidade como o TOP (Technical Observation Post) para que em prazo curtíssimo alguma melhoria fosse visualizada? Devo esperar a implementação completa de um banco de dados de gerencia de configuração (que pode demorar de 6
meses a 1 ano e meio , dependendo do tamanho da organização) ou começar a alimentar meu banco de dados por aquilo que é mais vital para meu negócio? Faça a
implementação em fases.
4. Infelizmente não tem como fugir. O que toda organização busca no final (a não
ser que seja uma ONG) é LUCRO, DINHEIRO! A frase que você ouvirá é: “o que
102
eu ganharei ao investir meu dinheiro nisso? Porque eu deveria investir?” Então, se
você deseja vender um projeto ITIL® e ter segurança ao apresentar sua proposta , mostre como, quanto e quando você comecará a ganhar. Existem ferramentas
para auxiliá-los nisso, calculando o ROI (Return On Investiment) em um projeto –
veja um de exemplo em nossa área de downloads. Seja realista também nesse aspecto (nem pessimista demais, nem otimista demais). Lembre-se: ganhos rápidos
também devem ser calculados e apresentados: isso facilitará bastante a venda do
projeto. Quanto antes o retorno vier, mais facilmente seu projeto será aceito.
5. Tenha total certeza de ONDE VOCÊ ESTÁ AGORA, qual sua situação atual. Ter
completo entendimento da real situação irá facilitar a implementação de qualquer
processo e de qualquer melhoria associada a ele.
6. Trace planos que o levarão até seu objetivo. Como você CHEGARÁ ATÉ LÁ? Uma
dica: Identifique quais são os pontos vitais para seu negócio, onde estão as maiores oportunidades de melhoria e comece a implementação por eles. Por exemplo:
Não existe ponto único de contato? Os recursos de TI perdem horas de trabalho
ao ser interrompidos por usuários ? Que tal implementar uma central de serviços
para os serviços mais críticos para seu negócio, para aqueles que terão maior visibilidade 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Á NESSE LUGAR. Quem não mede nunca conseguirá saber se os ganhos esperados foram atingidos, quem não mede não consegue saber onde está, quem não mede é
como se fosse um avião no ar e sem contato com a torre de controle. Lembre-se:
seus objetivos foram realmente atingidos? Eles podem ser melhorados? Um dos
ganhos que o ITIL® traz para os processos de Gerenciamento de Serviços de TI é
justamente a melhoria contínua. Caminhe sempre nesse sentido!
Enfim, espero ter ajudado aqueles que como eu, já tiveram alguma dificuldade em entender por onde começar, como definir e obter ganhos rápidos e como mostrar o valor agregado do gerenciamento de serviços para TI. O ITIL® é apenas um conjunto de
melhores práticas. Adote e adapte sempre utilizando o bom senso e acreditem: bom
senso no mercado atual deve ser guiado por três pilares: ética, qualidade e RETORNO
FINANCEIRO! Este último se vier depressa, melhor ainda!
103
Pessoas: o calcanhar de Aquiles na adoção da ITIL
ALBERTO ANDRADE
Todos sabemos que a implantação da ITIL® pode trazer mais maturidade operacional ao departamento de TI, agregando valor ao negócio e obtendo maior satisfação do
usuário. Também sabemos a necessidade de participação da área estratégica da empresa para sucesso no envolvimento das áreas. Estes e outros benefícios da biblioteca
são mais que conhecidos por nós, fiéis seguidores das boas práticas. Mas será que apenas treinamento, palestras e conteúdo teórico são suficientes para o envolvimento
da força motriz da implementação, ou seja, as pessoas?
Implantei processos ITIL® nas versões V2 e V3 do framework em alguns projetos em
que trabalhei e gostaria de dividir algumas experiências neste assunto. Quanto aos processos, estes apresentam seu grau de dificuldade, que varia de acordo com a complexidade da área/projeto e da quantidade que se deseja implantar. No entanto, é fato que,
quanto mais se entende (verdadeiramente) que boas práticas não são regras, portanto
podem (e devem) ser adaptadas, melhor se enquadra “fome à vontade de comer”. Para
o desenrolar da prática, o PDCA também não é mero assunto de qualidade. Use-o com
sabedoria e seja feliz. A recomendação anterior vale para o quesito produtos (tecnologia) e parceiros, onde dadas as peculiaridades que merecem devida atenção, a metodologia tende a ocasionalmente repetir-se, implantação após implantação.
O assunto aqui é o calcanhar de Aquiles de todas as minhas implantações, o ponto da
entrega de serviço de TI onde não há manual, nem regra, nem diretriz pré-determinada:
As pessoas. Asseguro sem hesitar que, em todo o processo de implementação, de todos os projetos, o que demandou mais esforço e energia foi este pilar. Afinal, não é por
menos. O ser humano é complexo, tem comportamento instável, tendência individualista e demanda constante motivação. Entendo ser este o alicerce mais frágil de toda a
implantação. O time tem que comprar a idéia, antes de colocá-la em prática. O que mais
tenho ouvido de pessoas envolvidas em projetos de ITIL® são murmurações de profissionais que tem de parar seus afazeres para agregar processos que eles acreditam não
servirem pra nada. Desta forma, coloco abaixo alguns pontos que acho serem cruciais
para arrebatar o maior número de seguidores da biblioteca de boas práticas:
1. Necessidades satisfeitas não geram motivação: Esta é uma premissa da motivação humana. Agregar valor ao negócio é importante para você, gestor, talvez não
seja para o seu operacional, aqueles que vão colocar a mão na massa. Busque referência em sites, revistas, vídeos e outros pontos. Deixe claro que o conhecimento
do framework é importante também em termos de carreira. Converta o benefício
para eles, gere o brilho nos olhos. Pode ser que o time ainda não esteja engajado
por estar pensando: “Que vantagem Maria leva nesse tal de ITIL®?”
2. Gere visão de negócio: Este é um complemento ao primeiro tópico. A equipe só
conseguirá ver com seus olhos a partir do momento em que a maturidade neste
104
sentido tiver avanço. Seus funcionários só vão querer aproximar TI do negócio se
identificarem algum sentido (e benefício) em fazê-lo.
3. Gerencie o overhead de trabalho: Não tem jeito, a equipe vai trabalhar mais. E o
pior, nem sempre podemos negociar banco de horas ou mesmo hora-extra com a
empresa. É preciso convencer que o ganho pós-implantação valerá todo o esforço
aplicado nesta fase. Desta forma, use e abuse do discurso e argumentação e não
esqueça: Motivação sempre.
4. Treinamento inicial é bom, reciclagem é melhor ainda: Geralmente, o treinamento
inicial em ITIL® é ministrado após um workshop e palestra iniciais. Neste período,
muitos ainda estão desinteressados. Portanto, agende uma reciclagem, voltada
para os processos em implantação na empresa. Aborde casos de uso e situações
práticas. Deixe que as pessoas dividam as suas experiências e tirem suas dúvidas.
5. Definir muito bem o “Onde estamos” e o “Onde queremos chegar”: O mapeamento
dos processos em atividade é fundamental para pleno entendimento do panorama atual da área. Feito isso, defina (sempre alinhado à estratégia de negócio) como
será a entrega de serviços futura. Assim, as pessoas serão norteadas por este objetivo.
6. Brainstorm periódico: As pessoas chave do processo não podem deixar de contribuir com idéias, sugestões e criticas. Reserve tempo na agenda para a disseminação de idéias. Muitas coisas, certamente, você não pensou.
7. Quick wins: Defina metas intermediárias e divida com todos (não só com seu chefe, entendeu?). Desta forma, todos saberão que a implantação tem obtido êxitos
parciais.
8. Autoridade funciona, mas saiba que em algumas ocasiões, o poder será necessário:
Se você é um líder influente, que sabe persuadir, seduzir (sempre no bom sentido,
claro!) e motivar sua equipe, saiba que você é raro. Hoje, muito se usa o “manda
quem pode, obedece quem tem juízo”. É o tal do poder versus autoridade. O poder
pode ser entregue a qualquer um. Por definição, qualquer chefe tem poder, mas
nem todos tem autoridade. Isso é verdadeiro, no entanto, sabemos que o quadro
de funcionários de qualquer empresa está repleto de ervas - daninhas. Portanto,
seja um grande líder, inspirador em seu discurso, apaixonado pelo que faz, dedicado e atencioso com seus liderados. Vai funcionar pra maioria das pessoas. Pra
quem não funcionar, bem, já sabe...
9. Escolha um braço direito na equipe: Sempre haverá aquele que vai comprar melhor
a idéia, se dedicar mais e corresponder melhor aos processos ITIL®. Tenha nesta
pessoa um termômetro da equipe como um todo. Desenvolva sua capacidade de
liderança e persuasão, este recurso será muito útil durante todas as fases da implantação.
10. Ninguém consegue entregar o que não tem: Se os lideres da sua equipe não compraram o ITIL®, não vão conseguir vender aos demais. Infelizmente quanto a isso,
não tem remédio (se houver, alguém me informe!). A disseminação de uma nova
cultura de trabalho, bem como a quebra de paradigmas tem que ser acompanha-
105
do e supervisionados no dia-a-dia, pois são resultados de muito trabalho e, muitas
vezes, de coaching. Portanto, avalie muito bem as pessoas a serem selecionadas
para participar e sobretudo, liderar as equipes. Quando os líderes já fizerem parte
do quadro de funcionários, insista e só avance no processo quando tiver convicção
do engajamento de 100% dos supervisores e coordenadores de equipe. Isso é fundamental.
Evidente que o tópico “pessoas” por ser extremamente complexo, possui uma série de
outros pormenores a serem tratados cautelosamente. Mas espero que os passos acima possam ser um bom início para uma implantação menos conflituosa e com maiores
ganhos.
106
Problemas – como identificá-los?
RENÊ CHIARI
Hoje quero trazer algumas dicas práticas de critérios para identificação de problemas,
pois considero este um dos segredos de um bom processo de gerenciamento de problemas.
Seguem alguns dos critérios de identificação mais comuns:
• Incidentes graves. Via de regra, incidentes graves são aqueles que exigem uma
grande mobilização de toda TI, envolvimento da “SWAT” da TI e são acompanhados de perto pela Direção e Clientes. É o tipo de incidente que deve ser evitado o
máximo possível. A dica é: gerar um problema para cada incidente grave.
• Reincidentes ou eventos recorrentes. Falhas ou alarmes de monitoração de impacto baixo/médio e que ocorrem frequentemente consomem recursos desnecessários. Por exemplo, uma rotina que falha diriamente, exigindo 25 minutos de um
analista para intervir e concluir a operação. Ao fim do mês são 8 horas desperdiçadas. É um dia de trabalho que poderia estar sendo dispensado em algo mais produtivo. Uma sugestão seria: a cada 5 reincidentes/eventos do mesmo tipo, na mesma
semana, registra-se um problema.
• Incidentes direcionados para equipes especializadas. Não é tão comum, mas pode
ser uma boa sacada registrar um problema para cada incidente que foi encaminhado para um grupo de suporte especializado, principalmente se for um grupo ou um
profissional de alto custo ($$) . Isso significa que as equipes de primeiro atendimento não têm informações suficientes para tratar este incidente. É uma forma de
assegurar que as equipes de suporte especializado (ou fornecedores), no mínimo,
proponham soluções de contorno (ou definitivas) estruturadas, e principalmente,
alimentem a base de erros conhecidos.
Mas para que esta abordagem funcione, é sempre bom lembrar que o processo de gerenciamento de incidentes deve estar muito bem estruturado. Em outras palavras, significa ter incidentes classificados e categorizados corretamente, garantindo assim entradas confiáveis ao processo de gerenciamento de problemas.
107
Profissionalizando a gestão dos projetos de TI e
ITSM Parte I
ANDRÉ BERNARDO
Quando falamos em boas práticas em gestão de projetos, podemos estar falando da construção de um submarino, reforma de um apartamento, implantação de uma solução
(software) de gestão de serviços ou ainda um projeto de melhoria de processos baseado na ITIL. Podemos “encapsular” praticamente qualquer coisa dentro de um projeto,
exceto, uma rotina! Rotina é operação, ongoing, relacionado a um ciclo de melhoria
continua. Já um projeto tem inicio, fim e escopo bem definidos.
Citando o PMBoK: “Projeto é um esforço TEMPORÁRIO empreendido para criar um
produto, serviço ou resultado EXCLUSIVO”. (PMBoK 4ªa ed. Pag. 05)
Dito isto, e pensando em melhorar nossas a qualidade dos projetos de TI e ITSM, que
tal iniciar um pacote de discussões sobre BOAS PRATICAS EM GESTÃO DE PROJETOS?
Então, como diria o “sábio”, comecemos do inicio!
O que gera um projeto? Como estruturar uma iniciativa em um projeto? Como priorizar
um projeto?
Geralmente, um projeto pode ser gerado por:
1. Necessidade de mercado (Ex. Desenvolvimento de um novo produto ou serviço)
2. Demanda regulatória ou jurídica (Ex. Lei de atendimento do call center)
3. Necessidade organizacional (Ex. Melhoria de processos para redução de custos
com impressão)
4. Avanço tecnológico (Ex. Atualização de S.O. do parque de computadores da empresa para Win 8.0)
5. Solicitação de cliente (Ex. Implantação de um Service Desk exclusivo para projeto
de outsourcing)
6. Necessidade social (Ex. Projeto de reciclagem de material)
Com a necessidade identificada, vale a pena checar se você tem realmente um projeto
ou se é uma demanda operacional nas mãos. Reforçando o que falamos logo ai acima:
•
•
•
•
Tem inicio e fim bem definido?
Terá uma equipe de trabalho?
Você consegue delimitar o escopo do que será entregue?
O resultado do trabalho será único? Tendo uma entrega exclusiva com riscos e complexidades distintas de outras iniciativas?
108
Então você tem um Projeto!
Vocês verão que em alguns casos a linha é tênue entre um projeto e uma demanda operacional, por isso é importante você ter regras definidas na sua empresa sobre o que
pode ser considerado um projeto (Que precisará de um Gerente de Projetos e toda
uma estrutura de gestão para conclusão das entregas) e o que deve ser um processo
(Que acontece rotineiramente e todos já sabem como fazer).
Que tal um exemplo?
Atualização do Windows Vista para o Windows 7 é um projeto?
Você: “Eu coloco o CD, digito o código de registro, dou next, next, finish e pronto. Então é só uma ação, não é um projeto.
Eu: “Concordo com você!”
Eu novamente: “Agora e se você tiver que atualizar o Windows de toda organização,
10.000 computadores e notebooks, na matriz e em 17 filiais espalhadas em 15 capitais
no Brasil e mais 2 filiais na Europa e Estados Unidos até o final do ano?”
Entendeu? Mudou a complexidade, aumentou o risco e delimitou o escopo.
Você terá uma rotina para ser executada, a atualização de 10.000 computadores, porém,
você terá que lidar com uma série de restrições que não teria se estivesse falando da
atualização de apenas um PC.
Você: “Ok, agora como eu organizo isso para dizer que tenho um projeto?”
Eu com cara de conteúdo: “Boa pergunta! Com uma resposta looonga!! Que tal se eu
explicar em uma série de 5 artigos? Projeto do inicio ao fim, onde teremos um artigo
para iniciação de um projeto, um artigo só para planejamento, um para execução, um
para monitoração e um para encerramento?”
Nesta série, baseada no PMBoK e na PRÁTICA de gestão de projetos vamos descrever
de forma resumida os principais elementos necessários para você estruturar e entregar o seu projeto com maiores chances de sucesso, e as interfaces que estas práticas
poderão ter com as práticas de gerenciamento de serviços. Afinal, é da mistura de bons ingredientes, na dose certa, que temos uma bela refeição, concordam?
109
ITSM Parte II
ANDRÉ BERNARDO
Dando continuidade a série de artigos baseada no PMBoK e na PRÁTICA de gestão
de projetos, agora que você já sabe que tem um projeto, precisamos começar a organiza-lo de forma profissional.
O ciclo de vida de gestão de projetos tem 5 fases:
1.
2.
3.
4.
5.
Iniciação,
Planejamento,
Execução,
Monitoração e controle,
Encerramento.
A Iniciação é onde executaremos os processos para autorizar formalmente o projeto.
É daqui que sai o primeiro documento do seu plano de trabalho, o Termo de Abertura
do Projeto ou Project Charter.
Qual a importância deste documento NA PRÁTICA? Nele você documenta importantes
definições que serão seguidas do inicio ao fim do projeto. O Termo de Abertura do Projeto aponta o “Alvo” e quem serão os responsáveis por apontar as flechas.
O que deve conter um Termo de Abertura do Projeto, no mínimo:
1. O Patrocinador ou Sponsor (Quem tem influencia para promover o projeto na organização),
2. O Gerente de Projeto (Responsável por integrar o trabalho do projeto e agir como
facilitador do time. É o principal responsável pelo sucesso ou fracasso do projeto),
3. O Objetivo (Por qual motivo este projeto será realizado?),
4. O Macro Escopo e as Frentes de Trabalho (O que será realizado no projeto e como
estará organizado - Ex. Frente Sistemas, Frente Infra, Frente Capacitação, etc.)
5. O Macro Cronograma ou Cronograma de Entregas (Milestones) (O que será entregue por cada frente de trabalho e qual a expectativa de prazo do Sponsor de
realizar estas entregas)
6. Os primeiros Riscos identificados (Você deverá identificar e controlar riscos durante todo projeto!!)
7. As Restrições (O que restringe a realização do projeto? Ex. disponibilização de
equipe ou orçamento)
8. As Premissas (Algo que vamos assumir como verdadeiro e que no geral, foge ao
controle do projeto. Ex. Premissa que o dolar não ultrapasse 2,50)
9. Os Indicadores - KPIs (Objetivo quantitativo - Pelo que será medido o sucesso do
110
seu projeto? Aumentar a rentabilidade? Diminuir incidentes? Melhorar a disponibilidade?)
Com este documento em mãos, o Gerente de Projetos já tem autonomia para iniciar
a mobilização do time de trabalho e iniciar a agenda de reuniões para elaboração do
Plano do Projeto que falaremos no próximo artigo.
Se você não sabe onde quer chegar, qualquer caminho serve! - Gato Risonho, Alice
no País das Maravilhas
Então o papel deste documento é formalizar aonde você quer chegar. Assim você traçará
durante o planejamento o melhor caminho para chegar até lá, aumentando suas chances de sucesso!
111
ITSM parte III
ANDRÉ BERNARDO
Enfim, entramos no meu grupo de processos de Gestão de Projetos preferido. Planejamento!!
Quando você faz uma viagem de férias para um determinado lugar pela primeira vez,
você tem uma determinada dinâmica e uma forma de aproveitar o lugar, que talvez não
seja a mais otimizada.
Na segunda vez que você volta para o mesmo lugar, você aproveita muito mais, já conhece os “macetes” e a melhor forma de explorar a região.
Esse é o milagre que o planejamento faz por nós. Quando você planeja bem uma ação
antes de executá-la, é como se você já tivesse realizado a tarefa uma vez (durante o
planejamento), então, na segunda vez (execução) ela sairá mais bem feita.
No PMBoK, este é o grupo mais pesado, o que faz todo sentido, pois a maior responsabilidade do gerente de projetos é garantir que tudo acontece como planejado, sendo
assim, ele precisa ter tudo planejado.
Em projetos não podemos nos dar ao luxo do teste x acerto. A não ser que isso esteja
no planejamento, com os riscos mapeados, custos, critérios de qualidade, etc.
Todas as áreas de conhecimento em projetos deverão ter um planejamento acurado.
Não consigo em um post entrar tão a fundo quanto gostaria para falar de planejamento, então 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 escopo deve ser muito bem delimitado, com fronteiras claras entre o que é e o que
não é escopo do projeto.
b. Um projeto de sucesso é o projeto que entrega tudo que foi solicitado e nada
além do que foi solicitado. Por isso a importância tão grande deste tópico.
c. Projetos com uma delimitação de escopo pobre acabam virando os famosos
“projetos sem fim”.
2. Tempo
a. Outro item de extrema importância nos projetos é a delimitação de tempo do
projeto.
b. Durante este processo você irá determinar quais atividades deverão ser realizadas, em qual sequência, por quais recursos, com qual duração e determinará
112
3.
4.
5.
6.
7.
8.
o cronograma do projeto.
c. Um projeto de sucesso deve entregar o que foi determinado no escopo, dentro
do prazo previsto.
Custo
a. A estimativa de custo e o orçamento do projeto são entregas deste processo.
b. b. Você deverá considerar o custo para realização das atividades previstas para
cumprir o escopo, além de uma margem de contingencia que deve ser atrelada
a algum risco identificado no planejamento.
Comunicação
a. 90% do trabalho do gerente de projetos é comunicação, então este item também deve estar muito bem planejado.
b. Você deve considerar aqui, principalmente, as expectativas das partes interessadas em receber informação e efetuar um plano para cumprir com as mesmas.
c. O que deve ser reportado durante o andamento do projeto? Para quem? Com
qual periodicidade? Em que formato?
Qualidade
a. Como você irá garantir que as entregas estabelecidas no escopo do projeto serão entregues com a qualidade adequada, no prazo e custo estabelecido?
b. Aqui precisamos estabelecer alguns indicadores de qualidade para acompanhar
durante o andamento do projeto se o mesmo está gerando os resultados esperados.
Recursos Humanos
a. a. Projetos são feitos por pessoas e se as mesmas não estiverem engajadas com
o trabalho o resultado será medíocre.
b. b. Neste processo você irá planejar como lidar com as questões de RH do projeto.
c. c. Como será o relacionamento hierárquico entre o grupo? Como manter o pessoal motivado? Como acelerar a sinergia da equipe?
Aquisições
a. Muitas vezes aquisições devem ser realizadas no projeto.
b. Neste processo você determinará a forma de contrato, critérios de SLA, como
será realizado o processo de compras, além de delimitar o que será comprado e
o que será “feito em casa”.
Riscos
a. Outro processo de extrema importância, que muitas vezes não recebe a devida
atenção de muitos gerentes de projeto.
b. Neste processo você fará o exercício de prever tudo que pode dar errado no
projeto, classificar estes riscos de acordo com o impacto do mesmo, a probabilidade dele acontecer e estabelecer um plano de ação para os riscos classificados
com maior impacto x probabilidade.
c. Um bom planejamento de risco é ferramenta fundamental para garantir o cumprimento do escopo, prazo, custo e qualidade do projeto.
113
Lembre-se, seja o projeto viagem, projeto casamento, projeto casa nova, ou projeto de
implantação do sistema de reatores nucleares, quanto melhor for o seu planejamento,
maiores a chance de garantir o sorriso nos rostos de todos os envolvidos.
114
Tempo para solucionar problemas: mais um
problema ou a solução?
RENÊ CHIARI
A teoria é clara:o foco principal da gerência de incidentes é resolver o mais rápido possível, enquanto o foco principal da gerência de problemas é resolver definitivamente.O
tempo para resolver um incidente normalmente está descrito dentro do SLA de atendimento de incidentes, mas para um problema, é bem raro, principalmente porquê até
hoje há dificuldade na diferenciação entre o que é um Incidente e o que é um Problema.
Na verdade este pode ser considerado um paradoxo, já que a gerência de problemas
precisa de um tempo maior para conseguir fazer uma análise estruturada de um problema e com isso estabelecer uma solução definitiva. Mas na prática, sabemos que não
estabelecer controles de tempo para problemas pode ser um risco, já que as equipes
não irão se preocupar com algo que não tenha um “deadline”.
O desafio é justamente equilibrar velocidade x efetividade. Para Eduardo Abrileri, Team
Leader de Problem Management da IBM do Brasil, a introdução de prazos para identificação de causa raiz de problemas trouxe resultados positivos ao processo:
“Após a implementação de um tempo máximo para identificação de causa raiz, observamos
que o número de problemas com a causa raiz identificada aumentou em 35%. Essa melhora
ocorreu porque passado algum tempo, as evidências do problema podiam ser perdidas (logs
sobrescritas, envolvimento do técnico em outro incidente e perda de histórico), impedindo a
identificação da causa.”
Abrileri complementa que o índice de comprometimento dos técnicos na atuação em
problemas melhorou, pois com metas acordadas de atendimento a problemas, incluindo escalonamento para prazos rompidos, os técnicos passaram a dar mais atenção aos
Problemas. O resultado de tudo isso veio em forma de feedbacks positivos de Clientes.
A ITIL® faz uma recomendação para organizações que têm a mesma equipe de suporte
atuando tanto em incidentes e problemas, para gastarem 80% do tempo nos incidentes
e 20% nos problemas. Como funciona na sua empresa? Você acredita que sem uma
política clara de “atenção e tempo de atendimento a problemas” essa recomendação
seja viável? NA PRÁTICA, o que realmente acontece?
Criamos uma enquete no site e uma discussão em nosso grupo do Linkedin para que
os leitores troquem experiências sobre este tema, que com certeza está no dia a dia de
todos que trabalham com suporte técnico e gestão de serviços. Participem!
115
Transformando sua poltica de segurança da
informação em um ativo estratégico
CLAUDIO DODT
Políticas de segurança da informação (PSI) são documentos estratégicos que definem
as regras que devem ser observadas durante o uso da informação de uma organização
com o intuito de resguardar tanto os pilares básicos (Confidencialidade, Integridade,
Disponibilidade) como seus derivados (e.g. Autenticidade, Não-Repúdio, Propriedade).
Se você já passou pela árdua tarefa de criar e manter uma cultura institucional de proteção aos dados corporativos sabe que nada é mais distante da idéia de simplesmente
baixar um modelo da internet (sim, existem muitos e alguns com razoável qualidade)
que a aplicação de regras de segurança em um ambiente vivo, em que segurança da informação muitas vezes é percebida pelos usuários, gestores ou mesmo diretores como
simples burocracia ou até um empecilho ao negocio.
A elaboração de uma PSI eficiente requer um grande nível de clareza, especialmente
no quesito alinhamento com os objetivos do negócio. Entretanto, mesmo uma política
eficiente não passa de um apanhado de material impresso ou disponibilizado na página institucional se não for bem utilizada no dia-a-dia.
Os oito passos a seguir podem ajudar bastante na hora de transformar sua PSI em um
ativo estratégico eficiente, alinhado ao negócio e que vai ser muito mais eficiente em
proteger as informações corporativas e, dependendo do caso, bem… até o seu emprego :)
Vamos à lista:
1. Segurança da informação não é Tecnologia da Informação
Algumas vezes os termos acima são confundidos como sinônimos, e isto pode prejudicar drasticamente um projeto de PSI. Muitas vezes a mesma informação tem a capacidade de ser apresentada em diversos formatos diferentes, sejam estes eletrônicos, físicos ou até mesmo armazenados no conhecimento dos nossos colaboradores. De
acordo com a ISO 27002 “Seja qual for a forma apresentada ou o meio através do qual
a informação é compartilhada ou armazenada, é recomendado que ela seja sempre
protegida adequadamente.”
Criar uma PSI exclusivamente para TI pode ter como conseqüência um escopo perigosamente míope. A ISO 27001 oferece 133 controles em seu Anexo A e basta uma rápida análise para chegar a seguinte conclusão:
Relacionados à TI: 46%
Relacionados à organização/documentação: 30%
116
Segurança física: 9%
Proteção jurídica: 6%
Relação com fornecedores e compradores: 5%
Gestão de recursos humanos: 4%
Um projeto de PSI que é um esforço apenas de TI esta fadado a enfrentar uma grande
resistência dos demais setores. Entender quais são as áreas críticas e pessoas chave
bem como seu funcionamento em conjunto é essencial na definição do que é segurança
da informação para sua organização.
2. Obtenha o apoio da alta direção
O famoso “apoio da alta direção” é um fator crucial para o sucesso de qualquer projeto
que pretende uma mudança significativa na cultura institucional. Já vi vários projetos
onde uma política “já concluída” era apresentada pela TI para a diretoria. Geralmente o
documento era imediatamente aprovado e sistematicamente guardado em uma gaveta trancada no porão mais escuro da organização.
Sem um sponsor de alto nível a força do projeto da PSI pode ser completamente minada. Neste momento surgem os usuários que não “sabem” criar uma senha complexa ou
que garantem que o seu email pessoal ou um IM público são essenciais para seu trabalho e ai começam a surgir às exceções que em pouco tempo se tornam a regra.
Um ponto muito importante e exposto de forma excelente no artigo Desmistificando o
apoio da alta direção é entender quem realmente são as pessoas chave, os tomadores
de decisão e especialmente quem vai ficar do seu lado quando a coisa começar a ficar
feia!
3. Converse com o negócio
Conforme previamente mencionado, um projeto de PSI de sucesso dificilmente é um
esforço apenas da TI. Conversar com as demais áreas e até mesmo criar um comitê de
segurança multidisciplinar traz uma visão muito mais ampla, imparcial e alinhada aos
objetivos de negócio da organização.
Além disso, geralmente tira de TI o estigma de vilão da história. Pense nisso!
4. Adote uma postura formal
A política de segurança da informação normalmente é um documento de distribuição
apenas interna ou que é encaminhada para clientes e fornecedores. Obviamente é essencial que este documento seja de fácil entendimento, mas isso não requer uma abordagem informal.
117
É necessário lembrar que a PSI é um contrato entre a organização e os usuários da informação e que muitas vezes pode ser levada perante ao judiciário. Diferenças sutis
em termos como, por exemplo, correio eletrônico ou e-mail podem ter implicações jurídicas inesperadas.
A PSI é um contrato e deve seguir uma postura formal, clara e não deixar espaços para
dúvida. Nesse momento pode ser importante o apoio de seu departamento legal ou
mesmo de uma consultoria jurídica especializada.
5. Atenha-se a sua realidade, mas pense no futuro
Obviamente sua PSI não será talhada em mármore. Não se preocupe em prever toda e
qualquer mudança na tecnologia, processos ou estratégias da organização.
Uma boa prática é atualizar políticas pelo menos anualmente, nesse momento você
pode analisar novamente o cenário corporativo, o negócio e as novas tendências de
tecnologia e segurança da informação. Obviamente, mudanças extraordinárias quando for necessário não estão descartadas.
Neste momento TI, que em geral faz a redação da maior parte da PSI, pode ser muito
bem ajudada pelas demais áreas envolvidas. Ater-se a realidade é essencial para uma
política funcional.
Exigir que, por exemplo, toda comunicação telefônica da diretoria seja criptografada
fica muito bonito no papel, mas se você não tiver uma tecnologia ou um procedimento
de apoio será apenas mais um ponto da sua política que nunca vai ser seguido.
6. Não proíba, controle!
Conforme mencionei em Segurança da Informação e a arte de não dizer não dialogar
com o negócio é essencial. Muitas vezes quando implantamos uma PSI o documento
final vem carregado de “não”, “proibido” e outras referencias que passam ao usuário a
idéia que nada mais pode ser feito.
Isto pode levar a uma postura negativa ou mesmo de rebeldia. Na maioria absoluta dos
casos acreditar que o usuário vai abrir mão de sua comodidade em prol da segurança
da informação é uma receita bem comum para a ocorrência de incidentes.
Ninguém reclama quando um jogador de futebol utiliza as mãos e recebe um cartão
amarelo ou mesmo é expulso. Certo, algumas vezes ficamos até com raiva da decisão
do juiz, mas no fundo sabemos que ele está apenas aplicando as regras do jogo e bem..
bola pra frente.
Usuários devem compreender que as regras existem por um motivo claro, que protegem o negócio e muitas vezes até eles mesmos. A PSI e a área de segurança da informação representam apenas as regras do jogo e o juiz, respectivamente.
118
Tente explicar aos usuários os “comos” e os “porquês” da segurança da informação ao
invés de dar um simples não.
7. Crie um bom programa de conscientização e avaliação do conhecimento
A política deve demonstrar claramente o apoio e comprometimento da organização
com a segurança da informação. Dito isso, não adianta ter o melhor dos documentos
se este não for adequadamente comunicado e, especialmente, entendido pelos usuários da informação.
Conforme mencionado acima, a PSI normalmente deve ter um caráter formal. Isto é
muito bom do ponto de vista jurídico, mas muitas vezes torna a leitura do documento
maçante e o jargão técnico pode ser totalmente incompreensível para a maior parte
dos usuários da informação.
Participei de excelentes iniciativas onde TI trabalhava junto dos departamentos pessoais e de marketing em campanhas que se utilizavam do lúdico para garantir que os
usuários fixariam pelo menos o essencial da PSI. Utilize-se de cartilhas, palestras, apresentações teatrais, jogos, simulações e qualquer outro recurso que esteja disponível
para sua organização.
Lembre-se: a freqüência, a repetição, a repetição, a repetição… isto é treinamento. Você
não precisa de um calendário muito extenso. Eventos a cada três meses podem tornar a
equipe menos disciplinadas em colaboradores conscientes de suas responsabilidades
e caso isso falhe.. bem, o que mesmo eles ainda estão fazendo na sua empresa?
E que tal tornar sua campanha realmente eficiente? Nada melhor que medir o nível
de conhecimento dos usuários antes e após a campanha. Essa informação pode servir
como um termômetro do seu estado atual e direcionamento para futuros eventos e
melhorias.
8. Consultoria ou não? Eis a questão!
Existem inúmeras vantagens em utilizar consultores especializados para apoio no desenvolvimento da PSI. Consultores experientes possuem uma vivência maior e normalmente participaram de projetos similares em diferentes segmentos. Esse é o tipo
de inteligência que pode reduzir drasticamente o tempo do projeto, ajudar na aceitação pelos usuários e evitar showstopers.
Em especial se segurança da informação não é a sua especialidade ou se você não tem
recurso humano disponível o uso de uma boa consultoria pode sair bem mais barato
do que você pensa tanto em termos de tempo como financeiros ou até mesmo dores
de cabeça.
A lista acima obviamente não é exaustiva e talvez nem todos sejam adequados para
sua organização. Mas se você quer que sua política de segurança da informação seja
119
mais do que apenas um simples papel encaminhado uma vez ou outra para a auditoria,
pense em utilizar parte desses conceitos.
Links e referências:
blog.iso27001standard.com/pt-br/2010/12/16/seguranca-da-informacao-ou-seguranca-de-ti/
gustavares.wordpress.com/2010/11/20/apoio-da-alta-direcao/
120
Artigos com toque de tecnologia
A gamificação invadiu nossa praia
RENÊ CHIARI
Você já ouviu falar em gamificação (gamification)?
Trata-se do uso de mecânicas de jogos e pensamentos orientados a jogos para enriquecer contextos diversos normalmente não relacionados a jogos. Essa técnica pode
encorajar as pessoas a realizar tarefas que elas normalmente considerariam chatas,
como completar questionários, formulários, ler algum conteúdo específico, etc.
OK, deram nome a algo que sempre existiu (assim como o bullying). Já sabiamos que
era mais divertido aprender geografia e história jogando WAR e tentando capturar a
Carmen Sandiego do que fazendo cópia de mapas em folha vegetal ou lendo a Barsa.
Agora que você já está devidamente inserido no contexto, vamos aos fatos: em 2015,
metade das companhias que trabalham com inovação adotarão práticas de gamificação
em seu dia a dia e 70% das duas mil maiores corporações do mundo terão ao menos um
aplicativo desse tipo. Não sou eu quem estou dizendo isso, é o Gartner.
E o que isso tem a ver com ITSM? Muita coisa.
Algumas empresas já estão começando a surfar por estas ondas com suas ferramentas. É o caso da InvGate, que incorporou em sua suite um módulo específico para gamification, que inclui pontuação e “badges” de acordo com o engajamento dos analistas.
www.youtube.com/watch?v=ro5Msyp1s1w
Na área de capacitação não é difícil encontrar jogos complementares aos treinamentos padrões de ITIL, por exemplo. São simuladores que estimulam os alunos/jogadores
a praticarem os conceitos aprendidos na sala de aula em situações “reais”, como no
funcionamento de um aeroporto, uma usina eólica, uma estação espacial, entre outros
cenários.
Pensando em um sistema de pontuação/premiação/reconhecimento por engajamento,
que é um dos objetivos principais da aplicação dos conceitos de gamificação, seguem
algumas sugestões que poderiam funcionar em alguns processos de gerenciamento de
serviços:
Gerenciamento de Incidentes
•
•
•
•
•
•
5 pontos por incidente registrado e categorizado corretamente
5 pontos por incidente resolvido em primeiro nível
5 pontos por incidente resolvido dentro do prazo
1 ponto por incidente escalonado para o grupo solucionador correto
20 pontos por resultados positivos da pesquisa de satisfação
20 pontos para tempo médio de atendimento semanal dentro do prazo
122
Gerenciamento de Problemas
•
•
•
•
1 pontos por problema registrado de acordo com os critérios estabelecidos
2 pontos por artigo inserido na base de erros conhecidos
10 pontos por problema com causa raiz identificada
10 pontos por incidente resolvido através de um artigo da base de erros conhecidos
• 50 pontos por problema resolvido definitivamente (ex: 3 meses sem incidentes relacionados)
• -20 pontos por problema encerrado sem causa raiz identificada
• -5 pontos por cada incidente relacionado a problema já encerrado
Gerenciamento de Mudanças
•
•
•
•
•
•
•
1 para cada requisição formal de mudança registrada
50 pontos por mudança concluída com sucesso
5 pontos por mudança aprovada
-15 pontos por mudança implementada sem registro formal ou aprovação
-1 ponto por mudança cancelada
-10 pontos por mudança emergencial
-50 pontos por mudança com falha
E o que fazer com estes pontos acumulados? Algumas recompensas “reais” são sempre
bem-vindas, como folga, viagem, bônus salarial. Também podem ser atribuídos “badges” para quem conquistar níveis satisfatórios de desempenho.
Obviamente os exemplos não param por aqui. O ITSM na Prática também incorporou
alguns conceitos de gamificação (bem menos sofisticados). Saiba mais.
123
ITSM, redes sociais e Content Management Systems
dá jogo?
RENÊ CHIARI
Se não pode vencer as redes sociais, junte-se a elas
Não há mais o que ser contestado, as redes sociais vieram pra ficar. E não importa quantas barreiras sejam impostas, os usuários vão acessa-lás de um jeito ou de outro.
O lado bom é que a própria TI pode se beneficiar nessa história. Com um pouco mais
de criatividade, pode-se extrapolar a aplicabilidade destas ferramentas para outras
áreas de conhecimento, como ITSM. Sim, estou falando do uso de CMS (Content Managament Systems) e redes sociais no Gerenciamento de Serviços de TI.
Além de serem ferramentas intuitivas e de fácil utilização, fazem o gosto do público
(usuários), e não é necessário grandes esforços em treinamentos, afinal, todos usamos
a maioria delas em nosso dia a dia.
A lista a seguir mostra a aplicabilidade de algumas ferramentas para o mundo ITSM.
A maioria são bem conhecidas, e outras nem tanto, mas vale a pena conferir cada uma
delas (e outras também) com mais detalhes.
• Twitter - pode ser um grande aliado para comunicações como alertas e atualizações
de incidentes graves e mudanças emergenciais, agenda de mudanças ou qualquer
outra notificação relevante e/ou urgente que se possa fazer com até 140 caracteres. A propósito, o Twitter pode ser utilizado de forma privada.
• Wiki - As características nativas do Wiki, como publicação, controle de alterações,
permissões de edição, visualização , e etc são um ambiente perfeito para a criação
de base de conhecimento, base de erros conhecidos, gerenciamento de documentação (processos, procedimentos, etc), auto-ajuda e FAQ.
• CMS Content Management System (Joomla, Wordpress, Drupal, etc) - Eu sou
muito suspeito pra falar sobre essa pequena maravilha chamadas CMS. O próprio
ITIL® na Prática roda em cima de um CMS (Wordpress). Mas eu me surpreendo a
cada dia. Já existem alguns temas e plugins específicos criados em cima dos frameworks dos CMS´s para transformar um simples blog/site em uma ferramenta para
gestão de tickets ou projetos bem convincente, dadas as devidas limitações dos
frameworks e o próprio perfil dos desenvolvedores, que não são especializados
em ITSM.
• Yammer - é uma cópia escandalosa do Facebook, versão empresarial. Para empresas que ainda estão acanhadas de se expor no mundo público do Facebook, esta
pode ser uma ótima ferramenta para compartilhar (e reter) conhecimento na organização, e principalmente gerenciar reclamações e assuntos ligados a satisfação
dos clientes.
124
• Facebook - muitas empresas já estão se expondo no Facebook, e considerando
ele como um dos principais canais de relacionamento com os Clientes. Porque não
tentar?
Para alguns de vocês estas idéias podem parecer bobas. De fato as idéias são voltadas
as necessidades mais básicas de gerenciamento de serviços. Mas basta dar uma olhada na última enquete disponibilizada aqui no ITIL® na Prática e verificar que 56% dos
participantes disseram que não tem uma ferramenta ITSM. Ou seja, para quem não
tem nada, é um ótimo começo a custos baixíssimos.
Nos próximos artigos pretendo escrever sobre cada um deles de uma forma mais detalhada, inclusive custos.
125
O que as ferramentas não fazem por você
RENÊ CHIARI
Não há o que questionar: as ferramentas vieram para facilitar (e muito!) a nossa vida.
Mas ao contrário do que parece, as ferramentas nem sempre conseguem atingir o objetivo proposto, que é trazer agilidade e qualidade na gestão de serviços.
A falha pode ter dois vieses:
• o fornecedor que muitas vezes está mais preocupado com a quantidade de módulos que serão vendidos, do que com a real necessidade do Cliente;
• o Cliente pode não saber o que quer, e exigir que o fornecedor adivinhe e o satisfaça, entregando o que não é essencial para o negócio. Isso exige experiência do
fornecedor em entender de fato, qual a necessidade ou recomendar soluções já
aplicadas em outros Clientes de um mesmo segmento de mercado, por exemplo.
Em meus tempos de Help Desk havia um dilema muito discutido na operação: “Como
vou registrar tantas informações requeridas pelos critérios de qualidade e mesmo assim garantir que isso seja feito em tempo de não afetar a minha meta de atendimento?”.
A questão talvez seja resolvida com a aquisição de uma ferramenta que automatize
este processo, mas antes seria interessante perguntar: “Porque estamos registrando
todas essas informações?”.
Penso que essa questão tem algumas possíveis respostas:
• “Ahh... porque está escrito na ITIL® que precisamos fazer isso!” - a ITIL® não nos
obriga a fazer tudo o que cita. Se você está registrando ou pretende registrar informações que não agregam em nada, não continue! Isso pode inclusive influenciar um fornecedor de ferramentas a vender customizações adicionais, que geralmente saem muito caras para atender uma necessidade que pode nem fazer tanta
diferença assim no resultado final.
• Para quem acabou de adquirir uma ferramenta, seria: “Bem, a nossa nova e ultra
espetacular ferramenta exige que sejam preenchidos todos estes vários campos
antes de direcionar para o grupo solucionador. E essa ferramenta esta alinhada
com as boas práticas da ITIL®!!” - Essa é uma das falhas mais comuns em projetos
que envolvem implantação de processos e ferramentas. Conheço casos de projetos que extrapolaram a conclusão, justamente porque a ferramenta é demasiadamente complexa, causando impacto nos processos e na cultura da empresa.
• “A nossa ferramenta tem um selo de ITIL® Compliance” - Desconfie de ferramentas com “selos” de compliance com a ITIL®. Isso torna a ferramenta muito mais
cara, e dependendo de como o negócio é suportado pela TI, o Excel faz o mesmo
trabalho. Obviamente trata-se de ferramentas extremamente competentes, mas
nem sempre o Cliente precisa de tudo isso. Existe uma iniciativa da OGC em ofi-
126
cializar um modelo de “certificação de ferramentas compliance com ITIL®”, mas eu
sinceramente não acredito que isso vá trazer algum benefício para o Cliente final.
Esses cuidados se aplicam em qualquer contexto e não somente a um processo específico. O importante é lembrar que as ferramentas não devem governar os processos
- é justamente o contrário!
127
Artigos Exlcusivos do Chef
Os desafios da criação de valor atráves da Operação
de Serviços
RENÊ CHIARI
Cada estágio no ciclo de vida do serviço tem o seu papel na criação de valor. Por exemplo, o valor do serviço é modelado na Estratégia de Serviço; o custo do serviço é
desenhado, prescrito e validado no Desenho de Serviço e Transição de Serviço; e os
indicadores para melhoria são identificados na Melhoria Continuada do Serviço. A operação de serviço entra em cena quando estes planos, desenhos e melhorias são implementados. Do ponto de vista de um cliente, é na operação de serviço em que o valor
é percebido de fato.
Ao contrário do que parece, a operação de serviço não pode restringir o seu foco somente na operação do dia a dia e entrega de serviços para criar valor. Existem desafios
fora deste contexto que podem oferecer riscos à criação de valor, por exemplo:
Poucas organizações planejam efetivamente os custos do gerenciamento de serviços
ao entrarem em produção. É muito fácil identificar custos de um projeto, mas muito
difícil quantificar quanto um serviço irá custar depois de alguns anos de operação.
É comum que somente após algum tempo que o serviço está em operação as falhas dos
estágios anteriores (estratégia, desenho e transição de serviço) sejam visíveis. Contudo, é difícil justificar investimentos para corrigir falhas de projeto ou requisitos não
previstos, porque isso não faz parte da proposição de valor original.
Também há dificuldade em obter investimento adicional em ações de melhoria da operação de serviço, como aquisição de ferramentas ou treinamentos. Por um lado, isto
ocorre porque estes investimentos não estão diretamente relacionados à funcionalidade de um serviço específico e, por outro lado, porque há uma expectativa do cliente
que estes custos deveriam ser embutidos aos custos do serviço desde o começo, e não
após o serviço entrar em operação.
Quando um serviço está em operação por muito tempo, ele se torna parte do que o
negócio considera como “normal” para um serviço de TI. Este sentimento dificulta justificar ações de melhoria do serviço, pois o sucesso destas iniciativas só é percebido
pelo cliente se o serviço tiver um histórico “nebuloso” de falhas.
O estágio de Operação de Serviço sugere vários processos, funções e mensurações
que endereçam estes desafios.
129
O que são incidentes, problemas, erros conhecidos
e requisições de serviço segundo a ITIL?
RENÊ CHIARI
Para compreender melhor estes conceitos, como de costume, convidamos você a sair
da caixa. Preparado?
Então, imagine que, de uma hora para outra, você começa a ficar febril. Este é um comportamento não esperado e indica que algo não está bem com o seu organismo, certo?
Para a ITIL, isso é um incidente. Em outras palavras, qualquer acontecimento que não
faça parte do comportamento padrão e que cause, ou possa causar, uma interrupção
ou redução da qualidade de um serviço. No nosso exemplo, entenda como a redução
da qualidade de vida ou mesmo a morte!
A forma de tratar um incidente é resolver o sintoma o mais rápido possível. Sendo assim, você procura uma farmácia e toma um remédio por conta, ou procura um posto de
saúde e passa por uma consulta com um clínico geral.
Agora imagine que esta febre volte a ocorrer duas, três vezes. Apesar de continuar
tratando o sintoma com um medicamento, você quer descobrir a causa raiz. Para a
ITIL, isso é um problema. Ou seja, a causa desconhecida de um ou mais incidentes.
A forma de tratar um problema é fazendo uma investigação profunda em busca da
causa raiz. Para isto, você vai precisar de um médico especialista. Isso vai levar mais
tempo e provavelmente custará mais.
Através da avaliação dos resultados de exames, é possível chegar a um diagnóstico e,
a partir daí, identificar a forma de resolver definitivamente (ou paliativamente) este
problema.
Para a ITIL, isso é um Erro Conhecido, ou seja, a causa conhecida de um problema do
qual já se sabe ao menos qual a solução de contorno.
Considerando que a causa desta febre já é conhecida e o médico especialista já sabe
como tratá-la de forma definitiva, ele recomenda a você tomar uma injeção com um
medicamento específico para este fim.
Este procedimento é bastante comum e de conhecimento de todos os profissionais de
saúde em geral. Além disto, também é um procedimento pré-autorizado pelas autoridades de saúde.
Na ITIL, isso seria considerado como uma Requisição de Serviço, ou seja, a descrição
genérica de vários tipos de demanda colocados pelos usuários para o departamento
de TI. Muitas destas requisições são pequenas e de baixo risco, e ocorrem com grande
frequência.
130
Principais abordagens para liberação e implantação
RENÊ CHIARI
Neste artigo, você irá conhecer as opções mais comuns para a liberação e implantação
de serviços de TI.
A escolha da abordagem mais adequada para uma liberação depende de uma boa compreensão dos padrões de atividades de negócio e perfis de usuários durante o planejamento e desenho destas liberações.
A opção selecionada terá um impacto significativo nos recursos de gerenciamento de
liberação e implantação, assim como nos resultados do negócio.
As duas opções de liberação mais comuns para cenários de múltiplas localidades são:
Big Bang
O serviço é implementado para todos os usuários de uma só vez. Esta opção geralmente
é utilizada em mudanças de aplicações em que a consistência do serviço é considerada
importante para toda a organização.
Algumas vantagens desta opção são:
•
•
•
•
O tempo de implementação é menor
As dificuldades de implementação são condensadas;
Os custos de implementação são menores;
Os usuários devem estar treinados apenas para o novo serviço e não para o período de mudança;
• A implementação ocorre em um único dia e todos os usuários sabem a data.
Por outro lado, as desvantagens são:
• Detalhes podem ser negligenciados com a pressa de mudança;
• Os usuários têm menos tempo para conhecer (e aprender) o novo serviço;
• Uma falha em uma parte do serviço pode afetar outras.
Abordagem faseada
O serviço é implementado para uma parte da base de usuários e, depois, esta operação
é repetida para as bases de usuários subsequentes, conforme uma agenda planejada
de liberações. Esta abordagem pode ser dividida em três:
• Implementação faseada por módulo – os módulos do serviço são implementados
um a um, começando pelos mais importantes;
• Implementação faseada por unidade de negócio – a implementação é feita em uma
unidade de negócio por vez;
• Implementação faseada por geografia – para organizações com múltiplos locais.
131
As vantagens desta opção são:
• A organização ganha conhecimento durante a implementação inicial, que pode
ser aplicada nas fases seguintes;
• Com a transição a ocorrer em partes, existe tempo para ajustes e correções;
• Existe mais tempo para os usuários se adaptarem ao serviço novo ou modificado;
• A equipe técnica pode concentrar os esforços em uma parte do serviço ou em um
grupo de usuários.
E algumas das desvantagens:
• Não é tão focada como na abordagem “Big Bang”;
• Pode haver inconsistência de informações, uma vez que cada módulo contém informações importantes sobre outros módulos;
• A duração do projeto é mais longa que a abordagem “Big Bang”.
Empurrar e puxar (Push and pull)
A opção “empurrar” (push) é utilizada quando o componente do serviço é implantado
a partir de um ponto central de distribuição e “empurrado” para as localidades. Em
termos de implantação de serviços, entregar os componentes atualizados do serviço
para todos os usuários – seja com a abordagem “Big Bang” ou faseada – significa “empurrar”, uma vez que o serviço novo ou modificado é disponibilizado no ambiente dos
usuários em um momento não escolhido por eles.
A opção “puxar” (pull) é utilizada em liberações de software, nas quais o programa é
disponibilizado em um ponto central de distribuição, mas os usuários são livres para
fazer o download para sua localidade no momento em que escolherem ou quando uma
estação de trabalho de usuário é reiniciada.
Um bom exemplo prático do uso de abordagens e opções de liberação é a funcionalidade “Windows Update”, nativa nos sistemas operacionais da Microsoft. As atualizações são disponibilizadas simultaneamente para todos os usuários (abordagem “Big
Bang”). Os usuários decidem pela opção “empurrar” ou “puxar”, de acordo com sua
preferência.
132
Gerenciamento da Configuração e Ativos de
Serviço: o processo “camarada” da ITIL®
RENÊ CHIARI
Conheça as suas principais interfaces e suporte ao aumento da eficiência de outros
processos de Gerenciamento de Serviços.
Nenhuma empresa pode ser totalmente eficaz e eficiente se não gerenciar bem os seus
ativos, principalmente aqueles que são vitais para manter a operação dos seus processos de negócio. O processo da ITIL® que endereça este tema é o de Gerenciamento da
Configuração e Ativos de Serviço.
Sua missão é assegurar que os ativos necessários para entregar serviços sejam controlados apropriadamente, e que informações confiáveis e íntegras sobre os ativos sejam
disponibilizadas quando e onde necessário.
Neste momento você deve estar se perguntando por que se trata de um processo “camarada” da ITIL®.
Um dos principais objetivos do processo de Gerenciamento da Configuração e Ativos
de Serviço é suportar os processos de Gerenciamento de Serviços fornecendo informações precisas da configuração, permitindo, assim, uma tomada de decisão mais assertiva e em tempo hábil – por exemplo, para autorização de mudanças e liberações ou
resolver incidentes e problemas.
Destacamos algumas das principais contribuições do processo de Gerenciamento da
Configuração e Ativos de Serviço com demais processos de Gerenciamento de Serviços:
• Gerenciamento de Incidentes: o processo utilizará a CMDB (Configuration Management Database ou Banco de Dados do Gerenciamento da Configuração) para ter uma
visão lógica da infraestrutura de TI e seus serviços através dos itens de configuração
e seus relacionamentos. Essa visão poderá fazer com que o gerenciamento de
incidentes tenha maior agilidade e facilidade para solucionar incidentes.
• Por exemplo: maior rapidez na análise do impacto e alocação do time correto para
atuação no incidente; maior rapidez na identificação dos itens de configuração impactados e que precisam ser rapidamente substituídos ou corrigidos.
• Gerenciamento de Mudanças: maior controle e agilidade no gerenciamento sobre
as mudanças do ambiente, pois o uso da CMDB e a visão lógica da infraestrutura
de TI e seus serviços (fornecida através dos itens de configuração e seus relacionamentos) mostrarão de maneira clara e controlada os componentes envolvidos na
mudança e seu real impacto para o serviço.
• Por exemplo: maior agilidade e assertividade na aprovação de mudanças, pois haverá mais facilidade para analisar o impacto no serviço dos itens de configuração
envolvidos na mudança. Também poderá ser feito o uso de baselinesde configura-
133
ção para retornar o ambiente ao status anterior a uma mudança executada e mal
sucedida.
• Gerenciamento de Problemas: aumento da eficiência do Gerenciamento de
Problemas, ao facilitar a análise de tendências em itens de configuração relacionados
a incidentes e identificar a causa básica de um ou mais incidentes. Essa informação
é utilizada para evitar novos incidentes e melhorar a qualidade dos serviços.
• Gerenciamento de Liberação e Implantação: aumento da efetividade do gerenciamento de liberação e implantação, pois fará auditorias e controles permanentes
para evitar que softwares ilegais ou não autorizados sejam registrados. Também
poderá aumentar a eficiência das liberações com o uso de baselines de configuração
para salvar as informações dos itens de configuração antes da liberação (atributos
como versão ou status, por exemplo). Essas informações poderão auxiliar caso a
liberação seja mal sucedida e um backup tenha que ser retornado.
Em resumo, conhecer as vantagens de um processo para o negócio de sua empresa é o
primeiro passo para tomar a decisão de adotá-lo. Esperamos que com este artigo você
possa compreender melhor a importância do processo de Gerenciamento da Configuração e Ativos de Serviço e o motivo dele ser considerado um dos que mais oferecem
suporte aos demais processos de Gerenciamento de Serviços.
134
Qual a diferença entre o Gerenciamento de
Mudanças e o Gerenciamento de Liberação e
Implantação?
RENÊ CHIARI
Existem vários elementos discretos no ciclo de vida da Transição do Serviço que podem ser facilmente perdidos quando estes dois processos são olhados como um só.
A separação dos processos de Gerenciamento de Mudanças e Gerenciamento de Liberação e Implantação tem sido um tema constante de debates e discussões. A primeira
impressão é que a separação destes processos serve apenas para criar uma “confusão
desnecessária”. Mas não é bem por aí.
O Gerenciamento de Mudanças é o processo que garante que todas as mudanças passem por um processo sólido de avaliação e aprovação. Também reúne informações
relevantes sobre cada mudança no serviço (porque, quem pediu, foi aprovado?). Por
outro lado, o Gerenciamento de Liberação e Implantação é o processo que agrupa as
mudanças (quando necessário) e se preocupa com o cronograma, a comunicação, treinamento etc.
Em termos mais simples, uma mudança nada mais é do que compreender e aprovar “o
que”, enquanto a liberação se preocupa com “como” e “quando”.
Um dos erros no uso destes processos é, por exemplo, o fato de que a maioria das reuniões do CAB (Comitê de Mudanças) costuma ser focada apenas na avaliação e validação testes e aprovação da “agenda de mudanças”. Não que esta seja uma atividade
incorreta, afinal, é o Gerenciamento de Mudanças que de fato aprova a implantação
(ou liberação) de uma mudança. Mas neste caminho é comum perder a oportunidade
de avaliar se a mudança deve ou não ser feita, mas de um ponto de vista de benefício
do negócio, risco e custo. Ou seja, as mudanças devem ser vistas a partir de uma perspectiva de valor de negócio antes de se tomar a decisão de investir recursos em seu
desenvolvimento.
Tanto na ITIL®, quanto em outras referências de práticas de Gerenciamento de Serviços
de TI, como o COBIT® e a norma ISO/IEC20000, as atividades de mudanças e liberações são descritas em processos distintos, o que reforça ainda mais a existência de
elementos diferentes entre estes dois processos. Ironicamente, a separação destes
dois processos é o que de fato permite que as empresas consigam distinguir “o que” de
“como” e “quando”. Que tal praticar estes conceitos e descobrir as suas vantagens?
135
A ITIL é uma moda?
RENÊ CHIARI
Muitos dizem que a ITIL é uma moda, que vai acabar. O motivo: todo mundo defende
a biblioteca, mas pouca gente a usa. Será?
Com a chegada de novos frameworks e boas práticas de mercado, fica a dúvida se a
ITIL realmente está com os seus dias contados.
Para refletir sobre esta dúvida, vamos destacar alguns fatos importantes:
• A ITIL foi criada no Reino Unido em 1989.
• Seus termos, conceitos e processos são tão populares que a tornou uma referência adotada por empresas em todo o mundo. Hoje em dia é muito comum no meio
de TI as expressões “Incidentes”, “Problemas”, “SLA”, etc.
• Teve duas grandes atualizações, e a versão atual (v3) teve uma atualização em 2011.
• A norma ISO/IEC 20000, que tem como foco atestar a qualidade da prestação de
serviços de TI (e é um tema para um artigo exclusivo) foi baseado na ITIL.
• Outros frameworks de governança importantes, como o COBIT, também citam a
ITIL como referência complementar.
• Possui um esquema estruturado de certificação profissional, que vai do nível básico (fundamentos) até os níveis mais avançados (intermediários, Expert e Master).
O número de profissionais certificados, só no Brasil, beira aos 100 mil.
Considerando os fatos acima citados, podemos concluir que:
• Um dos mais claros sinais da evolução da ITIL é que a própria definição do acrônimo ITIL já está defasada em relação ao seu foco atual. O nome (“Biblioteca da
Infraestrutura de TI”) traz, na verdade, melhores práticas paraGerenciamento de
Serviços de TI (IT Service Management – ITSM).
• Há conhecimento acumulado, praticado e discutido há mais de 20 anos. E com a
chegada da versão 3, que dá mais ênfase a assuntos como estratégia de serviços,
desenho de serviços e melhoria continuada, a ITIL deixa a sua fase de adolescência
e entra na fase adulta.
• Também podemos dizer que a ITIL é reconhecida como um “padrão de facto“, inclusive por outras instituições importantes que desenvolvem outras referências para
governança e gerenciamento de TI, como a ISACA, que desenvolve o COBIT – e a
própria ISO, que desenvolve a ISO200000.
Costuma-se dizer que contra fatos não há argumentos. E os fatos são bem significativos, não?
136
4 métricas para monitorar o desempenho de uma
CMDB (Configuration Management Database)
RENÊ CHIARI
Sabemos o quanto é desafiador implantar uma CMDB. Mas, uma tarefa tão desafiadora
quanto é manter a sua integridade. Neste artigo, apresentamos 4 métricas para acompanhar a ‘saúde’ de uma CMDB.
Objetivo: Identificar e gerenciar as informações da infraestrutura e seus relacionamentos
de forma acurada e eficiente.
Métrica #1 – Número de licenças não utilizadas.
A CMDB possui um registro de todas as licenças de software e quando foram distribuídas. Sendo assim, um relatório de licenças não utilizadas pode ser produzido.
Por que utilizar esta métrica?
Já esperada a existência de algumas licenças sobressalentes. Mas, um número muito
alto de licenças subutilizadas remete a uma possível falha no planejamento da Capacidade, provavelmente pelo uso insuficiente das informações da CMDB pelo processo
de Gerenciamento de Capacidade. Esta métrica encoraja o Gerenciamento da Configuração a garantir que as informações sobre licenças estejam corretas e como reduzir
o número de licenças não utilizadas para o mínimo possível.
Métrica #2 – Número de incidentes originados a partir de mudanças mal sucedidas
causadas por Itens de Configuração (CI) mal documentados.
Mudanças são aprovadas com base nas informações registradas na CMDB. Se uma
mudança falha, devido a uma informação incorreta sobre um componente do serviço
(Item de Configuração), a responsabilidade deve ser atribuída ao processo de Gerenciamento da Configuração.
A informação de um Item de Configuração na CMDB deve ser correta. Com isto, a probabilidade de mudanças mal sucedidas irá diminuir, e consequentemente, o surgimento
de incidentes ocasionados por estas.
Objetivo: Assegurar que CMDB fornece informações corretas e integras a outros processos
de gerenciamento de serviços.
Métrica #3 – Número de Requisições de Mudança sem a atualização do(s) Item(s) de
Configuração correspondente(s).
Sempre que um Item de Configuração sofre uma alteração, deve haver uma Requisição
de Mudança correspondente autorizada, seguida de uma atualização na CMDB para
137
refletir a conclusão desta Mudança autorizada. Durante uma possível auditoria, a informação de uma Requisição de Mudança deve ser comparada (e correspondida) com
a informação de status da configuração na CMDB.
Garante informações acuradas e autorizadas na CMDB. Denomina aderência ao processo.
Métrica #4 – Percentual de Itens de Configuração com informações incorretas.
Todas as correções de informações de Itens de Configuração deveriam ser contabilizadas para contribuir com esta métrica.
A ‘razão de ser’ do processo de Gerenciamento da Configuração é garantir a informação correta dos Itens de Configuração.
138
O que é um Service Desk (ou Central de Serviços)?
RENÊ CHIARI
O Service Desk é uma unidade funcional (função) composta por uma equipe dedicada,
responsável por uma variedade de atividades relacionadas aos serviços de TI que são
fornecidos por um provedor de serviços (seja interno ou externo). Normalmente, a interface com o Service Desk é através de telefone, web, ou notificações automáticas
geradas por eventos da infraestrutura.
O Service Desk é o ponto único de contato para os usuários de TI. Ele não trata somente
incidentes, requisições e dúvidas de usuários, como também pode ser a interface para
outras atividades, como a comunicação durante mudanças em serviços ou serviços novos liberados no ambiente de produção, manutenção de contratos, administração de
licenças de software, etc.
Em outras palavras, o Service Desk é a vitrine da TI. O seu valor não pode ser, nunca,
subestimado!
Um bom Service Desk pode “compensar” as deficiências internas de uma organização
de TI (que não são visíveis aos usuários e clientes), porém um Service Desk ineficiente
(ou a falta de um) pode trazer uma má impressão sobre a eficiência geral de uma organização de TI.
Veja outros benefícios que um Service Desk pode trazer para uma organização de TI:
• Melhora na percepção e satisfação dos clientes sobre os serviços fornecidos;
• Aumento da acessibilidade através de um ponto único de contato, comunicação e
informação;
• Melhor qualidade e agilidade no tratamento de requisições de clientes e usuários;
• Melhora na comunicação e trabalho em equipe;
• Utilização otimizada dos recursos de suporte de TI e aumento da produtividade
do negócio;
• Informações gerenciais mais significativas para apoio à tomada de decisão
139
Tipos de Service Desk, qual o mais adequado?
RENÊ CHIARI
Existem muitas maneiras de estruturar um Service Desk. Neste artigo, apresentamos
as estruturas mais comuns. Contudo, pode ser necessário para uma organização implementar uma estrutura que combine uma ou mais destas opções, a fim de atender
completamente as necessidades do negócio.
Service Desk ‘Local’
Nesta estrutura, o Service Desk está fisicamente localizado próximo à comunidade de
usuários suportados. Esta opção facilita a comunicação, o que agrada alguns usuários,
mas pode ser injustificável manter um grupo de recursos de suporte que sazonalmente
pode estar ocioso, à espera de incidentes e requisições de serviço locais, enquanto em
outros sites (localidades) a coisa pode estar “pegando”.
Algumas razões para se adotar a estrutura de um Service Desk local são:
•
•
•
•
Diferenças políticas, culturais e de idiomas;
Diferentes fuso-horários;
Grupos especializados de usuários;
Existência de serviços customizados ou especializados, que requerem conhecimento especializado;
• Usuários críticos ou VIP.
Service Desk ‘Virtual’
Calma, não se trata de uma central de atendimento robotizada.
Através do uso de tecnologia, particularmente a internet, e outras ferramentas corporativas de suporte, é possível dar a impressão de um Service Desk único e centralizado,
quando de fato os recursos podem estar distribuídos em locais físicos variados.
Com isso, algumas opções tornam-se viáveis, como o home working, offshoring ou outsourcing. Porém, é importante preservar a consistência e uniformidade na qualidade
do serviço e termos culturais.
Follow the Sun
Não se espante se um dia for atendido por um indiano ao solicitar suporte de uma
grande fabricante de software (ex.: Microsoft). Trata-se de um Service Desk “Follow
The Sun”.
Algumas organizações com atuação global podem combinar dois ou mais Service Desk
distribuídos para oferecer uma estrutura de suporte 24 horas. Esta opção pode otimizar
os custos de um Service Desk full-time, pois evita-se despesas adicionais com adicional
140
noturno ou hora extra, por exemplo.
Por outro lado, esta estrutura pode oferecer alguns desafios, como manter os processos, ferramentas e banco de dados de informações padronizados e compartilhados com
todas as unidades, para que o atendimento seja uniformizado pelas diversas unidades
espalhadas pelo globo.
Grupos de Suporte Especializado
Em algumas organizações pode ser interessante criar um grupo de suporte especializado dentro da estrutura do Service Desk (em alguns lugares o nome “célula de suporte”
é utilizado). Desta forma, os incidentes relacionados a um determinado serviço de TI
podem ser encaminhados diretamente para um grupo de suporte especializado. Isso
permite uma resolução muito mais rápida e assertiva destes incidentes.
Um exemplo clássico desta abordagem é quando ligamos para uma central de atendimento de operadoras de Telecom ou TV a cabo e somos orientados a digitar um número
para cada assunto específico, por exemplo, suporte técnico, faturamento, reclamações,
novos serviços, etc.
Contudo, neste mesmo exemplo podemos notar que eventualmente há certo exagero
destas organizações, oferecendo muitas opções de atendimento especializado, o que
pode fazer com que a experiência do usuário se torne muito cansativa.
Agora que você já conhece as principais estruturas de Service Desk, fica muito mais
fácil refletir sobre uma estrutura adequada a sua organização.
141
Melhores Práticas ou Boas Práticas, qual é o certo?
“Boas práticas” e “melhores práticas” são jargões amplamente utilizados em nossa área.
Porém, sempre fica uma dúvida: qual é o termo correto a se utilizar?
As duas estão corretas. Mas a seguir você entenderá melhor qual a melhor forma de
utilizá-las.
No contexto do Gerenciamento de Serviços, o termo “prática” é utilizado para descrever
um conjunto de habilidades e competências, um método reconhecido ou uma atividade
padrão. Uma prática pode ser unicamente responsável por um ou mais “processos”,
embora os processos tipicamente trabalhem através de toda uma unidade funcional.
Sendo assim, vamos a algumas definições:
Melhor prática
Uma “melhor prática” pode ser considerada como uma prática “geralmente aceita”,
que necessita uma comprovação empírica de um resultado específico e é proposto por
uma comunidade de prática como um padrão ou o mínimo necessário para ser considerado como uma prática. A “melhor prática” é transformada em “boa prática” através
de sua aplicação para ajudar a alcançar um ou mais resultados desejados.
Boa prática
Uma “boa prática” é o resultado da aplicação de uma melhor prática em um contexto
ou situação específica de uma organização, uma adaptação para atender a requisitos
locais. Uma “boa prática” pode ser definida como atividades desenhadas para atingir
um resultado desejado, utilizando um conjunto de ações comprovado, recomendado
e aprovado. A palavra-chave aqui é comprovar o senso de prática através de sua aplicação, não teoria.
A “boa prática” pode ser considerada como um consenso geral sobre a correta aplicação
de determinados conceitos, termos e técnicas que podem melhorar a visibilidade e o
controle gerencial que uma organização provedora de serviço tem sobre a qualidade
e o custo dos serviços que fornece.
O ITIL apresenta-se como uma “boa prática” e suas características incluem:
• Ser um padrão genérico disponível no mercado (diferentemente de metodologias
proprietárias);
• Pode ser aplicado em vários ambientes e situações – empresas de grande ou pequeno porte, públicas ou privadas, de diversos setores da economia
142
O que é um Plano de Capacidade?
RENÊ CHIARI
O Plano de Capacidade é o principal produto gerado pelo processo de Gerenciamento
da Capacidade, cujo objetivo é:
• Prover capacidade de TI (tecnologia e pessoal) com recursos aceitáveis para atender os requisitos atuais e futuros dos clientes e usuários;
• Manter o balanceamento entre custos x capacidade – provisão x demanda;
• Reconhecer novas tecnologias e investir apropriadamente para entregar os requisitos de negócio;
• Gerenciar a capacidade certa, no lugar correto, no momento certo, para o cliente
certo, a custos corretos.
• Um plano de capacidade completo deve levar em consideração os principais recursos envolvidos na entrega do serviço:
• Recursos humanos: >> Ex.: Equipes de suporte, desenvolvedores, administradores de rede etc;
• Recursos Técnicos: >> Ex.: banco de dados, link (banda), servidor (CPU, memória,
storage);
• Recursos Financeiros.
• Para o desenvolvimento do plano, também devem ser considerados alguns elementos, como:
• Demanda atual e prevista (futura) por serviços. Pode-se considerar como demanda futura, por exemplo, um novo cliente para o próximo mês, com uma demanda
esperada de consumo de mais de 500 acessos simultâneos ao sistema comercial.
Ou, uma data comemorativa, que irá aumentar as compras de um site de e-commerce em quase 40%;
• Limitações (thresholds). Em outras palavras, os limites aceitáveis de uso da capacidade em relação a um serviço ou componente do serviço. Por exemplo, máximo de
100 transações por minuto, máximo de 80% de consumo de memória e/ou CPU,
bem como os procedimentos de resposta caso estes limites sejam ultrapassados;
• Custos de atualização/manutenção da capacidade do serviço;
• Impactos potenciais em questões regulatórias ou contratuais;
• Procedimentos que permitam a análise preditiva.
Por fim, a organização de TI deve monitorar o uso da capacidade e realizar ajustes de
desempenho quando necessário.
É importante ressaltar que o plano de capacidade deve ser revisado no mínimo anualmente. Considerando que no mundo de hoje a Tecnologia da Informação deixou de ser
um fator irrelevante e passou a ser uma questão de sobrevivência das empresas, os
requisitos de capacidade (assim como outros requisitos de nível de serviço) passaram
143
a ser muito mais dinâmicos.
144
A razão pelo qual um incidente não “vira” um
problema
RENÊ CHIARI
Um dos mais incompreendidos relacionamentos entre processos de gerenciamento de
serviços propostos pela ITIL está, sem dúvida, entre o Gerenciamento de Incidentes e
o Gerenciamento de Problemas.
Incompreendido porque ainda é comum ouvir a expressão “um incidente que vira um
problema” nos corredores das organizações de TI.
A razão pelo qual um incidente não vira um problema é a mesma pela qual uma febre não
vira uma gripe. Gripes causam febres, dores no corpo. Problemas causam incidentes. E
não o contrário.
Incidentes e Problemas são duas entidades distintas, cada uma com o seu próprio ciclo de vida e tratadas por dois processos com objetivos bastante distintos: o Gerenciamento de Incidentes, que busca resolver o mais rápido possível e não se preocupa
muito com as circunstâncias da causa, e o Gerenciamento de Problemas, que busca a
identificação da causa raiz e uma solução definitiva, mesmo que isso possa levar algum
tempo.
Considerar que um problema só pode ser registrado no momento em que o incidente
relacionado esteja resolvido é o mesmo que considerar que a busca pela cura de uma
gripe só pode ser iniciada quando a temperatura (febre) estiver estabilizada.
145
10 coisas que você deveria saber sobre a ITIL
RENÊ CHIARI
Há alguns anos atrás, ninguém conhecia a ITIL. Agora, é difícil encontrar uma revista,
portal ou blog sobre gestão de TI sem que o termo “ITIL” seja mencionado. Apesar da
fama, muitos profissionais de TI não entendem completamente o que é ITIL. Seguem a
seguir 10 coisas que você deveria saber:
#1: ITIL significa Biblioteca de Infraestrutura de Tecnologia da Informação (Information Technology Infrastructure Library).
A biblioteca ITIL contém um conjunto de boas práticas que são usadas para desenvolver e executar gerenciamento de serviços de TI. Ela oferece um número de benefícios,
incluindo o aumento da vantagem competitiva através da redução de custos, crescimento e agilidade, mais eficiência corporativa através da racionalização de processos
de TI; melhor valor da TI através do alinhamento do negócio com a TI, e melhor satisfação de clientes e usuários.
#2: A organização que suporta a ITIL chama-se AXELOS.
Através de um processo de licenciamento sobre a propriedade intelectual do ITIL e
Prince2, foi estabelecido uma joint venture entre o Cabinet Office (UK) com a empresa de serviços britânica Capita. Esta iniciativa levou a criação de uma nova empresa,
chamada Axelos.
#3: A biblioteca ITIL consiste em uma série de livros que fornecem orientações e
recomendações.
Dentre todas as publicações, incluem-se as seguintes principais:
•
•
•
•
•
Estratégia de Serviço;
Desenho de Serviço;
Transição de Serviço;
Operação de Serviço;
Melhoria de Serviço Continuada.
#4: Para permitir uma implantação bem sucedida de práticas de gerenciamento de
serviços, a ITIL enfatiza a necessidade de um forte patrocínio da alta direção.
A implementação de práticas de gerenciamento de serviços recomendadas pela ITIL
é uma iniciativa que envolve mudança cultural. Pessoas irão questionar sobre terem
que fazer coisas diferentes do que sempre fizeram. Portanto, é necessário apoio de um
patrocinador da alta direção para influenciar a mudança. Sem um bom patrocinador, é
melhor nem tentar – ou ao menos estar ciente de que o sucesso será limitado.
#5: ITIL não é gestão de projetos.
146
A ITIL não está concentrada na criação de coisas (produtos) como é comumente o foco
de projetos. A ITIL concentra-se em práticas para o fornecimento de serviços de TI
para a empresa, que são organizadas em processos de gerenciamento de serviços de
TI.
#6: Apesar de sua popularidade, nem todas as respostas e conteúdos estão disponíveis
na ITIL.
A ITIL é um conjunto de abordagens e melhores práticas. É um guia de referência para
gerenciamento de serviços de TI. Ela contém alguns processos e templates, mas não
é uma metodologia e não contém todos os detalhes de uma implementação. Organizações que queiram usar a ITIL podem seguir as orientações gerais e a partir daí desenvolver processos mais detalhados que façam sentido para a própria organização.
#7: ITIL não é uma ferramenta.
Você pode implementar muitos aspectos da ITIL usando ferramentas, mas ferramentas não são impostas/requeridas. Para organizações pequenas, planilhas e templates
simples podem dar conta do recado. Para organizações maiores, provavelmente será
necessário encontrar ferramentas apropriadas para suportar o gerenciamento de
serviços de TI.
#8: ITIL não é uma proposição “tudo ou nada”.
A partir do princípio de que a ITIL é uma série de abordagens em áreas distintas, uma
organização pode implementar parte destas abordagens, ou todas elas. Não há regras
impondo que tudo deve ser implementado. Adapte e adote!
#9: Práticas da ITIL podem ser implementadas em estágios.
Não há regras que enfatizem a necessidade de todas as práticas descritas na ITIL serem implementadas de uma só vez. Muitas organizações implementam estas práticas
em fases, durante períodos determinados.
#10: Você (profissional) pode se certificar em ITIL. A sua empresa não!
Existe um programa de certificação em ITIL para profissionais, divididos basicamente
em três níveis: nível básico (fundamentos, nível intermediário (capability / lifecycle
modules) e nível avançado (Expert, Master).
Não existe certificação ITIL para empresas. A norma internacional ISO/IEC20000 é o
caminho para atestar a qualidade de serviços de TI fornecidos e operados por empresas. Em outras palavras, é a forma de atestar que as empresas aplicam, de fato, as principais recomendações da biblioteca ITIL
147
Compreendendo os principais conceitos do COBIT 5
RENÊ CHIARI
O COBIT 5 é a mais recente versão do framework de boas práticas de governança
e gerenciamento empresarial de TI, que incorpora muitos conceitos e teorias amplamente aceitos.
Nesta serie de artigos, vamos explorar os princípios fundamentais do framework,
servindo como uma referência para a aplicação do COBIT 5 em sua organização.
A Governança Empresarial de TI e o COBIT 5
Informação (no sentido mais abrangente da palavra) e tecnologias relacionadas estão
se tornando fatores cruciais na sustentabilidade, crescimento e gerenciamento do valor e risco na maioria das empresas. Como resultado, a TI deixou de atuar simplesmente
no papel de suporte e passou a assumir uma posição central dentro das empresas. O
papel realçado da TI na criação de valor e gerenciamento de risco empresarial, veio
acompanhado por uma crescente ênfase na Governança e Gerenciamento Empresarial de TI. Os stakeholders anseiam por assegurar que a TI cumpra as metas empresariais.
A Governança e Gerenciamento Empresarial de TI é parte integral de toda a governança corporativa. Ela endereça a definição e implementação de processos, estruturas
e mecanismos relacionais dentro da empresa, que permitem ao pessoal de negócio e
da TI executarem suas responsabilidades para suportar a criação e sustentabilidade
do valor ao negócio. A Governança e Gerenciamento Empresarial de TI é complexa e
multifacetada. Membros do comitê de governança e a alta direção, tipicamente precisam de assistência para implementá-la. Através dos anos, frameworks de boas práticas
foram desenvolvidos e promovidos para auxiliar neste processo.
Lançado em 2012, o COBIT 5 foi construído e integrado com base em 20 anos de desenvolvimento neste campo de atuação. Desde o seus primórdios, centrado na comunidade de auditoria de TI, o COBIT se tornou um framework de Governança e Gerenciamento de TI mais abrangente, compreensivo e aceito.
O COBIT 5 foi adicionalmente complementado com os frameworks Val IT e Risk IT.
Antes do COBIT 5, o Val IT endereçava processos de negócio e responsabilidades na
criação de valor empresarial e o Risk IT fornecia uma visão de negócio holística sobre
o gerenciamento de riscos. Agora, ambos estão incorporados ao COBIT 5.
O framework COBIT 5 é construído em torno de cinco princípios fundamentais:
1. Satisfazer necessidades das partes interessadas;
2. Cobrir a organização de ponta a ponta;
3. Aplicar um framework integrado e único;
148
4. Possibilitar uma visão holística;
5. Separar Governança do Gerenciamento.
Dando sequência à série de artigos sobre os principais conceitos do COBIT 5, neste
artigo iremos apresentar o primeiro princípio do COBIT 5:
Satisfazer necessidades das partes interessadas.
O primeiro princípio implica que o COBIT 5 fornece todos os processos e habilitadores
necessários para suportar a criação de valor através do uso da TI (pode-se interpretar
criação de valor como geração de benefícios). Este princípio está intimamente alinhado com o conceito de longa data chamado alinhamento estratégico. A convicção de
que um componente núcleo da governança de TI é atingir o alinhamento estratégico
entre TI e o resto da organização é um elemento crítico do COBIT. Entretanto, sabemos que há um contínuo desafio para as organizações em descobrir como atingir o tal
alinhamento.
Para auxiliar as organizações a alavancar o alinhamento estratégico, os desenvolvedores do COBIT realizaram uma pesquisa para fornecer orientações na compreensão
de como as metas empresariais direcionam metas de TI relacionadas e vice-versa. Esta
pesquisa foi baseada em entrevistas detalhadas e avaliações especializadas em diferentes setores. Então, uma lista genérica de metas empresariais, metas de TI relacionadas e seus inter-relacionamentos foi estabelecida. Você pode consultar esta tabela
no framework COBIT 5, que é gratuito e pode ser obtido no site da ISACA, mediante
cadastro.
Este cascateamento constitui o ponto de entrada principal do COBIT 5. Ele sugere que
as organizações devam começar analisando o alinhamento estratégico/TI através da
definição e correlação de metas empresarias e metas de TI.
O COBIT 5 utiliza o termo “metas empresariais” para sinalizar explicitamente que o
framework inclui empresas orientadas, ou não a lucro, e governamentais. Adicionalmente, o COBIT 5 fala sobre metas de TI.
No COBIT 5, a importância das metas de TI caminham para o foco principal nos seus
habilitadores, como processos de gerenciamento e governança.
Dando sequência ao artigo anterior da série sobre os principais conceitos do COBIT
5, neste artigo vamos falar sobre o uso do balanced scorecard (BSC) como facilitador
de um processo de medição para verificar se as necessidades das partes interessadas
estão sendo atendidas.
Para verificar se as necessidades das partes interessadas (stakeholders) estão sendo
atendidas, deve ser estabelecido um processo de medição sólido. Os métodos de desempenho atuais, como o Retorno sobre o Investimento (ROI), capturam os benefícios
dos projetos e sistemas de TI, mas refletem somente uma parte limitada (tangível) do
149
valor que pode ser entregue pela TI.
Para facilitar um processo mais abrangente de medição, o desenvolvimento do COBIT 5 incorporou conceitos do balanced scorecard. Em um dos apêndices do COBIT 5
as metas empresariais e metas de TI associadas estão agrupadas sob as perspectivas
do balanced scorecard. O COBIT 5 também fornece exemplos de métricas para medir
cada uma destas metas e construir um scorecard para as atividades relacionadas à TI.
Além disso, o COBIT 5 fornece medições de resultado no nível dos 37 processos detalhados do framework. Logicamente, estas metas e métricas de processos não podem
ser simplesmente comunicadas às partes interessadas, pois estes seriam sobrecarregados de informação. Preferencialmente, as metas e métricas de processos devem ser
consolidadas e agregadas de uma forma que facilite o balanced scorecard utilizável e
compreensível para todo o ambiente de TI. Desta maneira, obalanced scorecard permite que a organização determine se as necessidades das partes interessadas estão
sendo atendidas.
Dando sequência a série de artigos sobre os principais conceitos do COBIT 5, neste artigo iremos apresentar o segundo princípio do COBIT 5: Cobrir a organização de ponta a ponta.
Este princípio considera que o COBIT 5 cobre todas as funções e processo de uma
organização. O COBIT 5 não foca somente na função de TI, mas trata a informação e
tecnologias relacionadas como ativos que precisam ser tratados como qualquer outro
ativo da organização.
Desta forma, os gerentes de negócio deveriam se responsabilizar por gerenciar os seus
ativos relacionados a TI assim como o fazem para outros ativos, como plantas físicas,
recursos financeiros e humanos, dentro de suas próprias unidades organizacionais e
funcionais. O negócio deve assumir a responsabilidade, e prestar contas, governando
o uso da TI na criação de valor a partir dos investimentos em TI como alavanca para o
negócio.
O foco em cobrir a organização de ponta a ponta implica em uma mudança crucial na
filosofia dos gestores de TI e de negócio. Ele compreende uma mudança do gerenciamento de TI como um custo para o gerenciamento de TI como um ativo. Esta mudança
é um elemento essencial na criação de valor ao negócio. Se os gestores não assumirem
a responsabilidade pela TI, a empresa inevitavelmente irá jogar o orçamento de TI em
múltiplas iniciativas sem uma visão clara do impacto destas iniciativas na capacidade
da organização. Desta forma, a TI deixa de se tornar um ativo estratégico.
O COBIT 5 cobre as responsabilidades de TI e de negócios relacionados a TI. Como
demonstração, o COBIT 5fornece gráficos matrizes de responsabilidades (RACI) para
seus processos, dos quais papeis de TI e negócio estão incluídos.
150
Dando sequência a série de artigos sobre os principais conceitos do COBIT 5, neste
artigo apresentamos seu terceiro princípio: Aplicar um framework integrado e único.
Este princípio descreve o alinhamento em alto nível do COBIT 5 com outros padrões e
frameworks relevantes, servindo como um framework abrangente para a Governança
Empresarial de TI.
A ISACA realizou um grande esforço durante os anos para alinhar o COBIT com outros frameworks, como COSO, ITIL, PMBOK, TOGAF, PRINCE2, etc. Muitos processos
do COBIT 5 são inspirados pelas orientações destes frameworks. Por outro lado, seus
processos e práticas também são relacionados e alinhados com um ou mais frameworks desta área.
Para trabalhar efetivamente com o COBIT 5 e outros frameworks, a publicação COBIT
5: Enabling Processes inclui um mapeamento de alto nível de cada um dos processos
do COBIT 5. Considerando que o COBIT 5 também integra os frameworks Risk IT e
o Val IT, torna-se uma referência única que inclui em seus escopos, tanto orientações
anteriores da ISACA, quanto orientações de outros padrões e frameworks desta área
de atuação.
Nesta abordagem ampla, o COBIT 5 identifica um conjunto de habilitadores da governança e do gerenciamento que inclui 37 processos. Na camada de governança, há
cinco processos agrupados no domínio: “avaliar, direcionar e monitorar (Evaluate, Direct and Monitor – EDM)”. Estes processos ditam as responsabilidades da alta direção
para a avaliação, direcionamento e monitoração do uso dos ativos de TI para a criação
de valor. Este domínio cobre a definição de um framework de governança, o estabelecimento das responsabilidades em termos de valor para a organização (ex. critérios
de investimento), fatores de risco (ex. apetite ao risco) e recursos (ex. otimização de
recursos), além da transparência da TI para as partes interessadas (stakeholders).
A camada de gerenciamento é definida por quatro domínios: alinhar, planejar e organizar (Align, Plan and Organize – APO); construir, adquirir e implementar (Build, Acquire and Implement – BAI); entregar, servir e suportar (Deliver, Service and Support
– DSS); e monitorar, analisar e avaliar (Monitor, Evaluate and Assess – MEA).
O domínio APO (Alinhar, Planejar e Organizar) diz respeito à identificação de como a
TI pode contribuir melhor com os objetivos de negócio. Processos específicos do domínio APO estão relacionados com a estratégia e táticas de TI, arquitetura empresarial,
inovação e gerenciamento de portfólio.
Outros processos importantes endereçam o gerenciamento de orçamentos e custos,
recursos humanos, relacionamentos, acordos de serviços, fornecedores, qualidade, risco, e segurança. O domínio BAI (Construir, Adquirir e Implementar) torna a estratégia de TI concreta, identificando os requisitos para a TI e gerenciando o programa de
investimentos em TI e projetos associados. Este domínio também endereça o geren-
151
ciamento da capacidade; mudança organizacional; gerenciamento de mudanças (TI);
aceite e transição; e gerenciamento de ativos, configuração e conhecimento.
O domínio DSS (Entregar, Servir e Suportar) se refere a entrega dos serviços de TI
necessários para atender aos planos táticos e estratégicos. O domínio inclui processos
para gerenciar operações, requisições de serviços e incidentes, assim como o gerenciamento de problemas, continuidade, segurança e controle de processos de negócio.

Baixe aqui. - ITSM na Prática

Transcrição

Documentos relacionados

celulite aux ultrason traitement

Gerenciamento de Mudanças

SOBRE O PROJETO DE MARCA E IDENTIDADE VISUAL S4N Qual

tendências do summer meeting aad

Correia Martins, Dr. - Hospital Privado da Trofa

Visualizar

Bem-vindo

Linx desenvolve aplicativos para redes de food service

varejistas - cloudfront.net

Portifólio Termaco - Termaco Logística

Bruit de voisinage version portugaise 2011