Category: Certificação ITIL

Simulados ITIL e referências

 

Encontrei este site aqui que disponibiliza simulados ITIL e informações básicas sobre vários dos processos do ITIL v2 e v3.Este outro site disponibiliza simulado mediante cadastro. Como não gosto da idéia de cadastros, deixo aqui minha ressalva.

Quer mais dicas sobre ITIL?

– Simulados preparatórios para a certificação? Aqui, Aqui, Aqui e Aqui.

– Dicas para o Catálogo de Serviços

–  Sky vs ITIL: como não fazer o Gerenciamento de Incidentes e Fornecedores!

– ITIL Assessment: como fazer um diagnóstico rápido da situação da governança de TI na sua empresa?

– Indicadores e mais indicadores: o que a Pink Elephant recomenda?

Gostou? Então você já sabe que Investir na Certificação ITIL é o único caminho para se tornar um profissional melhor e alcançar cargos de gestão, certo?

Quer saber quais as certificações mais desejadas do mercado?
Há algumas que você deve estar atento, além da certificação ITIL, como por exemplo a certificação VMware, em Segurança da Informação e Big Data.

ITIL: sua Central de Serviços/Chamados/Help Desk é (IR)relevante?

ITIL 2011 - Central de Serviços irrelevante ?

Recebi um texto muito bacana numa das (muitas!) listas e grupos que participo, de autoria do Robert Stroud, tratando sobre Central de Serviços, ou Service Desk, e como isto está se tornando irrelevante em certas organizações.

O texto me fez (re)pensar alguns conceitos, e ver sob outro ângulo a postura que temos diante das demandas do negócio para o departamento de TI.
Vejamos algumas considerações do texto.
Já no subtítulo, a menção aos aspectos de colaboração social e compartilhamento de conhecimento entre a “Geração Y” sugere que a Central de Serviços que temos hoje deve ser repensada.
E continua.
“Como você resolve falhas em serviços e outros problemas? Você imediatamente pega o telefone e liga para a central de atendimento ou você, como eu, imediatamente recorre à web para descobrir como resolver o problema por conta própria?

Pensando sobre viajar de avião, eu sei que não fico feliz quando não consigo mudar meus vôos online, mesmo que isso me custe dinheiro. Eu não estou dizendo que os representantes não são úteis. Eles são. Mas eu prefiro a auto-empoderamento de trabalhar numa solução eu mesmo ao invés de ter que chamar um help desk central.”
É verdade que este cenário pode não se aplicar a todo mundo, em especial empresas que contem com parcela significativa dos usuários em idade avançada, não adaptados a este novo mundo onde tudo se resolve online.
Mas certamente é algo que deve ser considerado como uma tendência forte nos últimos anos. O empoderamento do usuário é um caminho que deve ser perseguido, dentro das políticas e diretrizes de cada organização, é claro, mas tendo a consciência de que isso tem boa chance de aumentar a satisfação das áreas de negócio com a TI.
Outro aspecto interessante abordado no texto trata da idéia de ponto único de contato (SPOC).
“Por muitos anos, a boa prática teve o service desk fornecendo um único ponto de contato para a comunidade de usuários. Mas lidar com todas as chamadas ou pedidos através de um único ponto de contato tem limitações.

Por um longo tempo tem havido uma busca para educar a comunidade de usuários sobre o balcão de atendimento e como ele funciona, quando na verdade tudo que o usuário precisa saber é como entrar em contato – e isso é apenas quando outros métodos não funcionam.

Levando o gerenciamento de serviços de volta aos princípios básicos, me pus a pensar por que os usuários entram em contato com a TI. Primeiramente, é porque eles querem alguma coisa. Poderia ser um aplicativo, hardware, de redefinição de senha, ou alguma outra forma de ajuda. Pensando sobre as minhas experiências em execução de gerenciamento de mudanças para uma grande organização financeira, posso dizer-lhe que nós sofríamos cada vez que havia uma grande mudança implementada, e quase sempre o desafio era a falta de capacitação, e um aplicativo não-intuitivo estava envolvido. Raramente foi um grande erro de processamento.”
Veja que interessante.
Raramente os problemas enfrentados pelos usuários envolvem uma questão realmente grave de infraestrutura de TI, sendo muito mais comuns situações de dúvida, solicitações de serviços simples e, em casos mais complexos, dificuldades com aplicações.
Perceba que estas questões, que devem responder por 90% ou mais (empiricamente falando 🙂 das dificuldades dos usuários, poderiam ser resolvidas com aplicações mais intuitivas e  facilitadores para que os usuários pudessem lidar sozinhos com estas situações.
Só pra exemplificar, tomemos uma empresa que adota os serviços do Google na nuvem para comunicação (Gmail), colaboração (Gdocs) e armazenamento (Gdrive). Eu imagino que o índice de reclamações dos usuários destes serviços na empresa seja baixíssimo, até porque, segundo diz a lenda, uma das coisas mais difíceis para os clientes da Big G é conseguir falar com um ser humano :). E se, por um lado, isto tem um caráter humorístico, por outro fica claro que há um investimento massivo em facilitadores para a solução de problemas pelo usuário, através de informações online e aplicações extremamente intuitivas.
O que nos leva ao próximo ponto do texto do Robert.
Estaria a “Geração Y” tornando as centrais de serviço irrelevantes ?
“Pense em como a ‘Geração Y’ resolve questões. Meus filhos, por exemplo, usam seus contatos nas redes sociais para resolver problemas, obter indicações de restaurantes e até mesmo coletar opiniões.

Dirigindo para casa a partir do escritório na neve esta semana, passei por um jovem piloto na beira da estrada trocando um pneu furado, com base num vídeo do YouTube.

Com esta abordagem rapidamente se tornando onipresente, o service desk tradicional torna-se irrelevante?

A realidade é que o service desk tradicional tem de se adaptar em face da capacidade de entrega de conhecimento e colaboração de hoje. Além disso, a funcionalidade deve ser entregue no contexto do utilizador. Nada me irrita mais do que chamar uma companhia aérea para alterar vôos, e eles não sabem quem eu sou, o que significa que eu preciso me autenticar. No entanto, quando eu chamo pelo meu iphone, certamente os meus dados devem aparecer diretamente na frente do agente que está me ajudando.”
Está claro que precisamos nos adaptar na forma de atender as demandas dos usuários, considerando seu nível de conhecimento e outras características e compondo um perfil que sirva de base para roteiros de atendimento distintos que se adequem à diversidade de pessoas que recorrem à TI.
O que nos leva a um ponto crítico, na minha opinião: (falta de) conhecimento.
“Se você pensar sobre o acesso ao conhecimento disponível hoje, o atendente deve ser capaz de fazer a triagem de minha situação, não apenas “log and flog” (referência a um primeiro atendimento rápido, mas cuja continuidade não apresenta eficiência, mascarando os indicadores de qualidade). Isso exige que os atendentes sejam melhor treinados, que o roteamento inteligente de chamadas esteja em vigor, e que os atendentes tenham conhecimento disponível na ponta dos dedos para fazer a triagem da solicitação. Idealmente, numa única ligação deve-se resolver o problema.

Um exemplo recente foi excelente quando liguei para minha companhia aérea favorita para relatar uma operação fracassada que foi erroneamente cobrada no meu cartão de crédito. O atendente validou a transação, registrou o erro, confirmou que era um problema conhecido que estava sendo trabalhado e me deu um processo para lidar com isso no futuro. Eles ainda agendaram um crédito para o meu cartão de crédito. Este atendente não apenas foi o único ponto de contato, mas estava armado com o conhecimento necessário para conduzir o processo até a conclusão.”
Confesso que havia pensado na falta de conhecimento apenas em termos de “bagagem técnica” dos atendentes, mas agora vejo claramente que o conhecimento sobre o caminho até a solução definitiva da solicitação do usuário é fundamental para que o atendente (em especial o de primeiro nível) tenha condições de ser mais eficaz no encaminhamento de uma solução rápida e definitiva para a situação.
Interessante observar que munir os atendentes com o conhecimento necessário pode não ser suficiente, sendo também necessário muní-lo com a “autonomia” necessária para lidar com a situação do usuário fim a fim. E aqui vejo um dos maiores problemas a enfrentar, pois se trata de delegar atividades que podem estar com uma equipe de segundo, terceiro nível, e que pode ter razões para não querer esta delegação, por questões de segurança, ou simplesmente por temer perder a “autoridade” sobre a situação. Além disso, a equipe de primeiro nível precisa estar preparada para lidar com estas novas responsabilidades, tanto em termos de conhecimento quanto de organização.
Concluindo, o Robert menciona mais um caso interessante.
“Eu tive uma outra grande experiência com serviço de empresa aérea recentemente envolvendo um voo cancelado. O app no ​​meu celular me notificou do cancelamento, em seguida, imediatamente me deu opções para reagendamento, juntamente com um botão para ligar imediatamente para a central de reservas caso essas opções não fossem aceitáveis.

Claramente, estamos movendo a função de apoio de gestão de serviços diretamente ao consumidor, capacitando-o para triagem de seus próprios problemas. Isso resulta em maior satisfação do usuário, e também dá aos gerentes de serviços a liberdade de se envolver mais no desenvolvimento de serviços, para se tornarem melhores na gestão proativa de problemas, e para estarem mais disponíveis quando ocorrer a grande crise.

Com os negócios de hoje sendo reescritos por software, gerenciamento de serviços é uma disciplina fundamental para garantir e manter a continuidade do serviço. Há uma oportunidade para que o gerente de serviço faça o help desk tornar-se invisível por imersão dentro do processo de negócio. E onde as chamadas batem na mesa, os analistas devem ser capacitados com conhecimento para resolver a interrupção do serviço!”

Conclusão

Eu achei fantástico o trecho “negócios sendo reescritos por software“, indicando claramente que o auto-atendimento é o caminho a seguir, e portanto precisamos preparar nossas equipes de atendimento para esta nova realidade.
E você, acha que a Central de Serviços está se tornando irrelevante ?

ITIL ou DevOps? O que você precisa saber sobre dois dos métodos mais adotados do mundo!

ITIL ou DevOps? O que você precisa saber sobre dois dos métodos mais adotados do mundo! 1
Mais uma vez me deparo com uma daquelas situações em que um texto simplesmente sensacional me deixa tão entusiasmado que me vejo na obrigação de compartilhá-lo com você.
O site australiano IT News traz uma análise extremamente útil sobre os dilemas atuais que envolvem duas das siglas mais comentadas nos últimos anos: ITSM e DevOps.
Deleite-se com mais este excelente texto, em tradução e adaptação livres deste blogueiro.
Há uma batalha feroz em curso sobre a melhor maneira de abordar os negócios de TI, com duas grandes escolas de pensamento competindo pelo domínio: IT Service Management (ITSM) e DevOps.
ITSM favorece um processo formal, planejado pela organização de TI, enquanto DevOps enfatiza um estilo dinâmico, mais fluido, livre das amarras da burocracia. Eles são, se você perguntar aos defensores mais estridentes de qualquer abordagem, a antítese um do outro.
Então, quem está certo? E o que são estas abordagens, de qualquer maneira?

O que é ITSM?


Information Technology Service Management (GSTI no Brasil) começou a vida dentro da IBM em 1972, fruto de oito anos de pesquisa em Information Systems Management Architecture (ISMA), que culminou com a publicação de A Management System for the Information Business in 1980.
Essas idéias foram construídas ainda em 1986 no Reino Unido, pela Agência Central de Computação e Telecomunicações (CCTA) – um órgão do governo, dada a difícil tarefa de melhorar a qualidade e eficiência de TI. A CCTA já havia desenvolvido o Structured Systems Analysis and Design Method (SSADM) para desenvolvimento de software, e o PRojects IN Controlled Environments (PRINCE) para gerenciamento de projetos.
Uma equipe liderada por Peter Skinner e John S. Stewart trabalhou com várias empresas de consultoria, incluindo IBM, para desenvolver o “pesado” Government IT Infrastructure Management Method, ou GITTMM. A IBM forneceu à equipe CCTA um conjunto de checklists para gerenciamento de serviços de TI derivados do seu trabalho sobre a referida ISMA, e a equipe expandiu esses conceitos para definir boas (“melhores”) práticas conhecidas. O princípio orientador foi, de acordo com Stewart, simples:
“A abordagem padronizada pode ser adaptada por organizações individuais como base para os seus processos próprios, repetitivos.”
O GITTMM foi mais tarde renomeado para IT Infrastructure Library (ITIL) por duas razões principais: em primeiro lugar, porque não era um método, e em segundo lugar, com a palavra “governo” o nome teria desanimado a adoção das idéias para além dos departamentos governamentais.
O ITIL define essencialmente que processo uma organização de TI deve seguir para tudo, desde como implantar um novo aplicativo, como definir a política de segurança, de como controlar licenças de software a como lidar com as chamadas de suporte. E três décadas após a necessidade de tal idéia ser reconhecida pela primeira vez, o ITIL é hoje mais ou menos onipresente. Se julgado pela concepção de Stewart do princípio central da biblioteca, o projeto teria de ser considerado um sucesso retumbante.
E ainda assim o problema original que se propôs a resolver – que os projetos de TI não estavam à altura das expectativas de alta qualidade ou de baixo custo – não parece ter sido resolvido.
Depois de quase 30 anos de ITIL na prática, ainda ainda lemos sobre falhas em rotinas de TI e em larga escala.
As páginas de iTnews estão continuamente cheias de argumentos para demonstrar porque.
O consultor Greg Ferro é um crítico ferrenho do ITIL.
“A premissa fundamental ITIL é que atividades de tecnologia podem ser segmentadas como máquinas ou funções de trabalho em uma fábrica onde cada tarefa pode ser atribuída a uma máquina, com recursos humanos fixos aplicados à tarefa e financiamento aplicado à máquina”, diz ele. “Isso simplesmente não funciona quando as máquinas e processos da fábrica sofrem mudança transformacional a cada três a cinco anos.”
“ITIL não é sobre a entrega ou excelência. Na minha experiência, ITIL e PRINCE2 evitam a excelência através de um foco em entregáveis e gestão de custos.”
Ele está convencido de que ITIL teve seu dia e que é hora de seguir em frente.
“Na última década, tenho trabalhado para dezenas de empresas que utilizam modelos ITSM/ITIL e todas elas eram locais de trabalho miseráveis ​​e infelizes”, diz ele. “Quando eu trabalhei em empresas que não usam ITIL, achei que eram ótimos lugares para trabalhar, enquanto o valor real do negócio estava sendo criado e entregue.”
“É sobre a felicidade. ITIL é igual a miséria e infelicidade. Quem quer isso?”
Leia mais enquanto explicamos a escola de pensamento oposta…

O que é DevOps?

Muitos que têm manifestado insatisfação com processos ITIL descobriram que o modelo DevOps – uma extensão da metodologia ágil – resolve muitas questões que ITIL e ITSM não conseguem.
DevOps como conceito ganhou destaque em 2009, principalmente com o lançamento de “DevOps Days” na Bélgica por Patrick Debois. DevOps é uma palavra que combina Desenvolvimento e Operações, que descreve o que parece ser a síntese da abordagem: desenvolvimento e operações trabalhando em conjunto.
A maior dificuldade com DevOps é que ninguém, nem mesmo seus defensores, parece bastante certo do que DevOps é exatamente. Alguns chamam de método de desenvolvimento de software, alguns uma abordagem para o gerenciamento de TI, enquanto outros o chamam de “movimento global”.
O ponto em comum na descrição DevOps é em grande parte uma reação à abordagem de silos tomada por muitas empresas quando implementam processos do ITIL.
No mundo ITIL, os desenvolvedores são responsáveis ​​por atualizações e alterações, enquanto as operações de TI são responsáveis ​​por manter tudo funcionando. Esta abordagem leva muitas vezes a incentivos incompatíveis, onde a operação é motivada a reduzir a mudança (e manter as coisas estáveis), enquanto o desenvolvimento é totalmente sobre mudar as coisas.
A ascensão da abordagem Agile para desenvolvimento de software no início de 2000 – e sua ênfase em ciclos de liberação rápida – colocou pressão sobre os processos formais de gestão de mudança e de transição de serviços recomendados pelo ITIL. Se um comitê de mudança só se reúne uma vez por semana, liberações em produção não podem acontecer mais rápido. Mas se a empresa segue Agile ao pé da letra, como muitas empresas on-line fazem, você pode liberar mudanças em produção várias vezes por dia. Os dois mundos não se encaixam muito ordenadamente.
Portanto, assim como a abordagem Agile para desenvolvimento de software substitui o método cascata SSADM, o DevOps visa substituir a formalidade lenta dos processos ITIL quando se trata de operações. DevOps requer que os desenvolvedores possuam o ciclo de vida completo de uma aplicação, desde o desenvolvimento, testes, implantação e suporte em produção, todo o caminho até o descomissionamento.
As grandes empresas online como o Flickr têm compartilhado sua abordagem de fusão de desenvolvimento e operações em diversas conferências, e a técnica tem ressoado com aqueles também com pressa para entregar valor aos clientes.
A pedra angular da abordagem DevOps é a automação. Sem ela, as grandes organizações não poderiam conceber tais ciclos de liberação rápida, sem introduzir erros. Ferramentas como o Puppet, Jenkins e Selenium são todas voltadas para automatizar tarefas que eram anteriormente centradas em humanos. Em vez de um comitê de mudança de seres humanos que se reúne uma vez por semana, um teste de software automatizado determina se um lançamento está pronto para implantação em produção.
As ferramentas de automação já existem há décadas, mas a sua utilização sempre foi um pouco limitada. O humilde utilitário UNIX make foi criado em 1976, e as ferramentas subseqüentes, mesmo internas da HP como a ferramenta MEDUSA, podem pedir antiguidade em relação a ferramentas mais recentes como Puppet, Ansible, e Jenkins.
Mas como acontece com tantas tecnologias, sem dúvida, as ferramentas anteriores chegaram muito cedo. Simplesmente não havia necessidade generalizada suficiente para serem utilizadas fora de nichos ou empresas específicas. O estilo DevOps de automação explodiu em popularidade porque o timing estava certo.
Automação tem sido muito demandada desde a virada do milênio, inicialmente para as grandes empresas online como Google, Yahoo, Facebook, entre outros. O sucesso dessas empresas dependia de economias de escala para o sucesso comercial, e ninguém podia se dar ao luxo de contratar um grande número de seres humanos para alcançá-la. As tarefas de curadoria de resultados de pesquisa, execução de leilões do AdWords, e mostrar quais dos seus amigos tornaram-se solteiros são impossíveis para seres humanos, quando se tem milhões de membros. Pagando um desenvolvedor realmente bom o triplo do salário de mercado para escrever software que substitui 15 administradores de sistemas parece um bom negócio.
A automação também cabe na cultura do desenvolvimento online da ‘era digital’. Técnicas e códigos originalmente desenvolvidos por estas grandes empresas online foram liberados para o mundo em geral (considere o Apache Hadoop e a biblioteca de interface de usuário do Yahoo!), geralmente muito tempo depois que permitiu qualquer vantagem competitiva significativa para a empresa original. É mais fácil para uma ferramenta ou prática para se tornar amplamente adotada, se muitas pessoas sabem que a ferramenta existe, e ainda mais fácil, se o custo de aquisição é baixo. Operações “digitais” de hoje dentro de bancos ou empresas de telecomunicações são frequentemente reciclagem de código desenvolvido para redes sociais uma década antes.
Até o final dos anos 2000, uma massa crítica de ferramentas e técnicas que tinham surgido começaria a desafiar seriamente o domínio do ITIL.
Mas será que isso realmente tem que ser uma escolha difícil entre ITIL ou DevOps?
Podem as duas abordagens co-existir?

Leia sobre como os líderes empresariais discutem essa opção…

Lições do passado, presente e futuro

Mudanças culturais à parte, a causa raiz do crescimento do DevOps se dá pelos benefícios acumulados através de um maior uso de automação.
Ela evita muitos dos famosos problemas de comunicação entre silos, principalmente porque, na maioria dos casos, os seres humanos que poderiam se comunicar foram substituídos por computadores. Ao contrário dos humanos, os computadores fazem exatamente o que são ditos pra fazer, então não há essa coisa de falha de comunicação. Os computadores também fazem tarefas repetitivas com grande precisão. Seria uma abordagem ITIL funcional, se a maioria dos seres humanos fossem substituídos por Jenkins, Puppet e scripts shell?
Don Meij, CEO da Domino Pizza, diz que os problemas operacionais que afligem a maioria das organizações de TI têm geralmente mais a ver com a implementação do que com a escolha da abordagem.
“Muitas empresas tornam tudo uma questão de processo”, diz ele. “CEOs se apaixonam por processos. É quase como se justifica o que se faz. É o câncer de uma organização se você não gerenciar adequadamente.”
Peter Nikoletatos, diretor de TI atuando na Universidade de New England, diz que o IT Service Management e ITIL ainda serão relevantes no futuro. Mas as organizações precisam melhorar a forma como aplicam.
“ITIL é um framework que exige adaptação”, diz ele. “A maioria das organizações erram ao buscar muita sofisticação. Isso torna as coisas muito burocráticas.”
“O entusiasmo para execução ao implementar ITIL deve ser moderado. Você precisa ter um cronograma realista. Construir os serviços de forma incremental. Comece com coisas simples: gerenciamento de incidentes e gerenciamento de problemas.”
“Do ponto zero para o ITIL totalmente implantado pode levar de dois a três anos. Isso é um investimento significativo de tempo. Você não tem que fazer tudo isso.”
“Nem todas as organizações se prestam ao Agile“, continuou ele. “ITIL é apenas uma maneira de pensar sobre um problema, mas não a única. ITIL é conveniente porque a maioria das pessoas entende. Com o Agile, ainda estamos aprendendo como usá-lo. Demora alguns anos para construir provas de que isso funciona”.
O que confunde tudo é o ritmo acelerado de mudanças no setor de TI em geral, cortesia da Lei de Moore. O tipo de automação possível hoje era impensável em meados dos anos 80, ao mesmo tempo, a explosão de dados e processamento de dados criou novos problemas que não existiam então. Com a paisagem mudando sob seus pés tanto assim, pode uma abordagem para gerenciar as coisas realmente cobrir todas as bases?
Para o deleite dos consultores em todos os lugares, a resposta sobre adotar ITIL ou DevOps parece perpetuamente ser: “Depende.”
Como a velha piada de gerenciamento de projetos: você normalmente só pode escolher duas das três variáveis ​​- rápido, barato e bom. Tanto ITIL quanto DevOps pretendem buscar os mesmos objetivos – resultados finais de negócio melhores. Poderia ser o caso de que ITIL foi otimizado para qualidade boa e barata, com menos ênfase na velocidade, enquanto DevOps oferece um ponto de otimização diferente – muito mais rápido e, invariavelmente, mais barato. A pergunta que muitos estão esperando para responder é se ele vai entregar a mesma qualidade.
Uma maneira mais construtiva de fazer uma escolha entre os dois é avaliar o custo da mudança para qualquer solução.
O software se beneficia de mudança rápida, porque o custo de mudança é baixo. Quanto mais baixo o custo da mudança, mais mudança você pode se dar ao luxo de contemplar. Mas o hardware raramente é tão fácil mudar. Aqueles que implantam hardware ainda precisam considerar as ramificações de longo prazo de suas ações, ou, pelo menos, o impacto do custo de errar e ter que mudar.
Faz sentido usar a técnica que combina a quantidade e o custo de mudanças ao seu ambiente. Algo que não muda com freqüência, e custa muito quando isso acontece, requer um planejamento cuidadoso e de gestão da mudança. Mas, para as coisas que são relativamente fáceis de mudar e não custam tanto, tentar muitas opções diferentes rapidamente faz muito mais sentido.
Nessa base, a necessidade de reinvenção é um pouco exagerada. Não há nada que diga que processos ITIL não podem ser automatizados. Ele é, afinal, apenas uma estrutura, pronta para ser adaptada às especificidades do seu negócio, enquanto continua a fornecer uma maneira padronizada de pensar sobre problemas de negócios.
Adeptos ITIL podem aprender muito emprestando idéias do DevOps, pois adeptos do DevOps tendem a reciclar seus softwares de gerenciamento de configuração e compartilhar receitas Puppet através da internet.
Compare e contraste

ITIL DevOps
Optimizado para Economia de escala Velocidade para o mercado
Despesas de execução Alta Baixa
Tempo para execução 2-3 anos 6 meses+
Níveis de pessoal necessário Médio para Alto Baixo para Médio
Estabilidade Bem estabelecida Ainda em evolução
Habilidades de mercado disponíveis Amplamente disponível Poucos, mas em rápido crescimento
Melhor para Processos padronizados, repetitivos Inovação

PREPARE-SE PARA A CERTIFICAÇÃO ITIL FOUNDATIONS (apenas R$17,00!)

Copa 2014 e ITIL: e se a seleção fosse um serviço de TI?

Copa 2014 e ITIL: e se a seleção fosse um serviço de TI? 2
A Copa 2014 acabou, sem o vexame máximo da Argentina campeã, mas com a marca da decepção trazida pelas partidas desastrosas da seleção canarinho contra a grande campeã Alemanha e a terceira colocada Holanda. Interessante notar o paradoxo entre as expectativas, ambas não confirmadas, de sucesso dentro e caos fora de campo. Mas vamos ao que interessa, afinal é disso que tratamos por aqui, não é mesmo ?
Desde aquela fatídica terça-feira, reflito sobre o aprendizado que poderíamos tirar dali. Afinal, toda situação ruim é uma oportunidade de aprendizado e evolução, melhoria, aprimoramento. É importante saber aproveitar, e por isso resolvi traçar um paralelo entre o que ocorreu no dia 8 de julho e a principal referência em governança de TI adotada mundialmente, o ITIL.
Deixo claro desde já que o objetivo deste texto é, essencialmente, didático, permitindo aproveitar a tragédia para tirar lições que podem ser mutio úteis no dia a dia de qualquer departamento de TI. De todo modo, fiquem à vontade para discordar e até mesmo criticar as idéias que expresso aqui. É da discussão saudável que surgem idéias e resultados melhores.
Assim, comecemos pela seguinte pergunta, que representa a analogia desejada:
E se a seleção fosse um serviço de TI que, na hora H, falha miseravelmente ?
Quais as possíveis causas para a falha ? Quais processos devem ser melhorados para evitar novas situações semelhantes ? Elegi algumas das possibilidades que julguei mais interessante analisar.

Estratégia do Serviço

Nesta fase do ciclo de vida do serviço estão os serviços que, como o nome da fase sugere, vão permitir a definição de uma estratégia para a oferta de serviços de TI na organização, bem como (em nossa analogia) da estratégia de jogo para a seleção brasileira durante a copa do mundo.
Vejo uma falha evidente aqui, identificada a partir da menção (sutil, é verdade) do ex-técnico da seleção, Luiz Felipe Scolari, na entrevista após os 7 x 1, quando disse que as seleções adversárias estavam melhor do que poderiam (eles, a competentíssima comissão técnica da seleção) imaginar.
Estudar a concorrência é uma das etapas envolvidas na construção da estratégia para o serviço, conforme diz o ITIL: “…atuais e potenciais concorrentes, e os objetivos que irão diferenciar o valor do que o prestador faz ou como faz”.
Assim, fica claro que o estudo das seleções participantes da copa do mundo não foi feito de forma adequada, gerando as surpresas desagradáveis que presenciamos.
A lição que fica é da importância de estar atento à concorrência. Há serviços no mercado equivalentes àqueles oferecidos pela empresa ? Quais as suas características, limitações e diferenciais ? Como a empresa pretende estruturar seus serviços pra lidar com estas questões ?

Desenho do Serviço

Na fase de desenho estão processos que eu classifico como de “planejamento técnico”, pois representam a especificação de um plano detalhado (o Pacote de Desenho do Serviço) que descreve todos os passos necessários para colocar em funcionamento um serviço com qualidade.
É possível identificar falhas em alguns processos desta fase, a começar pelos que considero mais críticos: Gerenciamento de Disponibilidade e Continuidade.
Claramente, a seleção não estava preparada para perder jogadores importantes (indisponibilidade), e pior, não tinha a menor condição de lidar com o “desastre” de perder seu principal craque.
Isto ilustra a importância de ter mecanismos de contingência, e deixa claro que imprevistos, mesmo os mais improváveis, acontecem, e estar preparado pra isso pode fazer uma enorme diferença. Assim como não estar preparado para um desastre levou ao fracasso da seleção, pode levar ao fracasso de uma organização.
Quem nunca ouviu a história das empresas que não tinham contingência quando do ataque terrorista de 11 de setembro de 2001, ou pior, as que tinham contingência na outra torre. Não basta ter “qualquer” contingência, portanto. É necessária uma contingência adequada para suprir as necessidades da organização.
Claro que, no caso da seleção, não dava pra deixar um “Neymar reserva” à disposição, mas acredito ser possível ter um esquema de jogo preparado (e principalmente treinado!) para jogar sem nosso maior craque. Até porque era previsível que o craque fosse caçado em campo, e naturalmente seria necessário poupá-lo ao menos em parte dos jogos.
Já o caso Thiago Silva é mais grave, pois a suspensão por cartão amarelo é algo relativamente comum em qualquer campeonato, então era natural supor que alguns dos jogadores mais importantes da seleção, notadamente os envolvidos com a marcação dos adversários, seriam advertidos com cartão amarelo e possivelmente suspensos de alguma partida.
A lição que tiramos aqui diz respeito à necessidade de avaliar os recursos críticos de TI e prover mecanismos de contingência para os mesmos. No mundo atual, onde praticamente qualquer ação envolve uso de tecnologia, contingência é palavra de ordem, pois o serviço não pode parar.
Ainda na fase de desenho, podemos considerar algumas falhas nos processos de Gerenciamento de Capacidade e Nível de Serviço.
No primeiro caso, podemos fazer uma associação com o “caso Fred”, afinal de contas, a estratégia de jogo da seleção exigia a presença de um centroavante, e portanto este “recurso” deveria ter capacidade suficiente para a necessidade do negócio (da competição, neste caso). A substituição deste recurso por outro como tentativa de ampliar a sua capacidade se mostrou ineficaz, o que demonstra que o conjunto de recursos disponível não era capaz de atender à necessidade.
No segundo caso, foi possível perceber uma falha na avaliação do desempenho de vários jogadores, que mesmo não rendendo não eram substituídos, indicando que os métodos de medição de desempenho da comissão técnica divergiam dos que são comumente utilizados. Isto pra não supor o caso extremo de “serviços” que sequer teriam SLAs definidos.

Transição do Serviço

Nesta fase encontram-se os processos que apoiam a efetiva execução das ações necessárias para colocar novos serviços em funcionamento, ou ainda realizar alterações em serviços existentes, e até mesmo desativar serviços.
Assim, vamos considerar os processos desta fase à luz da principal mudança realizada na seleção durante a copa do mundo: a mudança de escalação para o jogo contra a Alemanha.
Podemos especular se os 7 R’s teriam sido considerados: requisitante, razão para a mudança, retorno esperado, riscos envolvidos, recursos necessários, responsável pela execução, relação com outras. Entendo que havia razão para as mudanças e o responsável era capaz, mas os riscos envolvidos não foram considerados devidamente, daí a não concretização do resultado esperado. A tentativa de surpreender a Alemanha se revelou uma decisão equivocada.
A lição que fica aqui é quanto à necessidade de avaliar com máximo cuidado os riscos envolvidos em qualquer mudança, de forma a garantir que serão tomadas todas as medidas necessárias para lidar com os mesmos da melhor maneira possível.

Operação do Serviço

Nesta fase estão os processos envolvidos na manutenção dos serviços em funcionamento dentro das condições desejáveis.
Entendo que poderíamos considerar incidentes a contusão de Neymar e o cartão de Thiago Silva, cuja solução exigiu a mudança na escalação que citamos anteriormente.

Melhoria Contínua do Serviço

Nesta fase está o processo que é vital para o futuro da qualidade de qualquer serviço de TI, na medida em que é através do processo de melhoria em sete etapas que se constrói a análise das situações identificadas que representam oportunidade de evoluir e aprimorar a qualidade dos serviços de TI.
Neste sentido, entendo que este é o ponto crucial para o futuro do futebol brasileiro, na medida em que a correta análise dos acontecimentos desta copa do mundo podem resultar na reformulação necessária que leve ao sucesso que tanto desejamos nas competições que se aproximam: Eliminatórias e Copa América em 2015, Copa América e Olimpíadas em 2016 e Copa do Mundo em 2018.
A lição que fica aqui é que as maiores catástrofes podem representar as melhores oportunidades para realizar mudanças importantes (às vezes drásticas) para que se amplie a qualidade dos serviços de TI.
E você ? Concorda com as opiniões que expus aqui ? Quero muito saber o que pensa a respeito!

Infográfico: ciclo de vida do serviço #ITIL

Encontrei este infográfico que resume as principais características do ITIL e as cinco fases do ciclo de vida do serviço: Estratégia, Desenho, Transição, Operação e Melhoria Contínua.
O infográfico está estruturado em torno das perguntas mais comuns que devem ser respondidas em cada fase do ciclo, como “Quem é nosso cliente ?” e “Temos condições de operar neste espaço de mercado ?” (Estratégia), “Quais os requisitos operacionais do serviço ?” e “Quais as medidas que nos indicarão o sucesso ou não do serviço ?” (Desneho), ou ainda “Quais os riscos associados com a implantação deste serviço em produção ?” (Transição) e “Como podemos validar que o serviço fornece o valor conforme planejado ?” (Operação).
Pra quem se prepara para a certificação ITIL 2011, é mais um recurso para seu arsenal de informações valiosas que podem fazer a diferença na hora da prova.

Ciclo de Vida do Serviço ITIL