É um momento triste, mas que abre espaço para uma reflexão sobre planos de continuidade para o negócio. Cito o negócio, pois a continuidade dos serviços de T.I. somente existirá se houver um plano para continuidade do negócio.

A exemplo o porto de Itajaí que está tendo um prejuízo diário de 33,5 milhões. Um impacto enorme para o negócio e economia do Brasil.  Será que na avaliação de riscos, foi levantado como possibilidade a combinação da chuva intensa e outros fenômenos bem específicos da região que levariam a esse cenário? Essa combinação de chuvas com outras catástrofes diminui ainda mais as chances matemáticas do desastre. Apesar disso, o plano da continuidade não perde sua importância.  Além do que, imagino que um porto desse tamanho e com essa importância, deve ter planos de continuidade do negócio. Não é o foco aqui discutir isso, mas sim evidenciar a importância do tema, pois,  o quanto antes for feito restabelecido as atividades do negocio, menores serão as perdas. Parece obvio dizer isso, não é? Mas o que pode ser feito para voltar as atividades de forma mais rápida? A resposta também é obvia,  planejamento da continuidade do negócio. Um luxo ou o mínimo esperado?

Ainda a exemplo da catástrofe em SC. Em muitos casos a infra-estrutura das empresas permaneceu intacta, mas o que acontece se seus colaboradores não conseguem chegar até lá? Muitos ficaram isolados, sistemas de transporte parado, entre outros problemas. Dessa forma as pessoas não conseguem chegar ao local de trabalho. E o que vale uma empresa sem as pessoas?Pode valer muito se essa empresa permitir que seus funcionários trabalhem remotamente. Essas e outras questões devem previstas,  discutidas e documentadas no plano de continuidade.

Abaixo um diagrama que explica resumidamente esse processo.

Esse é um assunto muito interessante e o momento é sugestivo para pensar em novos planejamentos para futuros planos de continuidade, já que o que aconteceu recentemente foram situações inesperadas e de baixas probabilidades, logo fica o convite para “blogarmos” a respeito.

Alexsander Oliveira

Incorre que algumas das empresas falam exatamente como abordam a ITIL, e este post trata de elucidar e comentar sobre estas abordagens.

Pontos que acredito valham comentários no artigo da InformationWeek Brasil:

Distâncias reduzidas (página 19)

Atuando mundialmente e com 50 mil usuários de TI, Eaton investiu em ferramentas de comunicação IP e colaboração, além de cria r uma área pa ra estudar tecnologia s disruptivas.

… Para driblar a dispersão da companhia nos diversos países, o projeto de service desk batizado de “Follow the Sun” e regido sob os princípios de Itil organizou o atendimento dos chamados por fuso horário. Assim, a solução de problemas ou dúvidas pode ocorrer desde qualquer parte do mundo: resolve aquele especialista que pegar o ticket primeiro.
“Isto acelera muito o processo. A Eaton é global, então, temos de pensar em soluções que se enquadrem ao mundo todo”, justifica Miranda. São cerca de 50 mil usuários de TI…

Leia com atenção: sem adotar os preceitos da biblioteca (em especial os da disciplina de Gerenciamento de Incidentes) será que em algum momento seria possível criar e manter um serviço de suporte que ’seguisse o sol’ (aliás que termo bem bolado para cobrir o funcionamento em fusos distintos).

A TI que educa (página 25)

Fundação Bradesco consolida metodologia de inovação, investe em processos e parcerias e, assim, melhora sua posição no estudo.

…Outro ponto trabalhado entre 2007 e 2008 foi a implantação de escritórios de projetos, de processos e de estratégia, este último dividido em gestão do conhecimento e inteligência competitiva. “Minhas metas vão até 2012, mas, no curto prazo, preciso aperfeiçoar os processos, melhorar meus transacionais, montar meu dashboard e extrair as informações por meio da nossa ferramenta de BI.” Para este processo, está sendo buscada no mercado uma ferramenta de BPM e ainda a certificação de profissionais em Itil 3.0…

Pelo menos em tese o Banco se beneficia do conhecimento de processos dos profissionais em ITIL para suportar sua estratégia de inovação. Note que num mercado competitivo como o financeiro inovação e processos alinhados são premissas básicas.

Balanço em tempo real (página 33)

A Tecban processa 30 milhões de transações por mês; inclusão de BI no sistema de faturamento ajuda os executivos a corrigir rotas diariamente.

Mais maduro: é assim que o CIO da Tecban, Lisias Lauretti, define o atual estágio do departamento que comanda. Depois de adotar a arquitetura orientada a serviços, práticas como CMMI e Itil, conexões WiMAX e GPRS para caixas eletrônicos e SMS como ferramenta de campo para técnicos, neste ano, além de contabilizar os resultados do que implementou em 2007, a TI partiu para o amadurecimento das práticas de colaboração, o acompanhamento do faturamento em tempo real, entre outros.

De fato: 30 milhões de transações por mês é um número bastante imponente penso que um SLA bem estruturado deve auxiliar a manutenção deste índice - fora isto não há como esperar algo diferente de uma instituição que precisa de processos maduros para a sustentação de seu negócio.

Questão de empatia (página 65)

Entre os projetos deste ano, a Carbocloro investiu em telemetria, ou seja, colocação de sensores que medem níveis dos produtos fornecidos na base do usuário para reposição automática.

…Ainda sob a batuta da filosofia da companhia, a TI da Henkel passou por uma iniciativa que busca uma mudança cultural de um perfil de profissional mais técnico para consultores de negócios, que Adriana conseguiu com boa dose de treinamentos. Outro projeto teve como foco reduzir a complexidade da TI, com a adoção de Itil…

Um mundo (mundo de TI, claro) sem ITIL pode ser caótico. Entendo por redução de complexidade a diferença entre um cenário apocaliptico onde nada ou pouco é feito baseando-se em processos (de preferência valorizados no mercado). Se a redução de complexidade tiver este sentido então faz-se uma verdade. Contudo, pode-se entender que simplesmente a adoção da ITIL é por si só um redutor: pode ser mentira mas algumas organizações valer-se-ão do caos para ‘manter as coisas como estão’ e a estas é muito mais simples refutar a ITIL com o discurso de complexidade.

Até a próxima, Marco Aurélio.

A InformationWeek Brasil na Edição de Outubro de 2008 traz um artigo muito interessante sobre as “100+ Inovadoras” que é uma excelente referência, em especial no que tange o uso da biblioteca ITIL.

Acompanhe o gráfico (página 13 do PDF):

A ITIL destaca-se como uma das métricas que possui o maior volume como opção de métrica de desempenho. Ficando a frente de opções consolidadas como a ISO 9000x.

Que a informação não é conclusiva é até compreensível todavia é no mínimo um dado bastante contundente.

Fica a referência.

Até a próxima, Marco Aurélio.

No que tange à área de Service Suport estabelecida nas boas práticas da ITIL, tais serviços, quando mapeados e representados na forma de Incidentes, IC’s (Itens de Configuração), Problemas, Mudanças, Versões, etc.., possuem uma natureza sistêmica pelo fato de se relacionarem conceitualmente, facilitando assim a modelagem e desenvolvimento de ferramentas no intuito específico de tornar fácil e viável o gerenciamento e uso estratégico da informação.

Por exemplo, segundo as boas práticas da ITIL, sabemos que um Incidente está intimamente associado a um Problema, que por sua vez pode estar relacionado a um ou mais Itens de Configuração. O Problema também poderá culminar em uma Mudança, que necessitará de uma nova Versão. Conforme foi mencionado, entende-se que esta associação conceitual pode ser transcrita para uma modelagem de software, culminando na construção de uma nova ferramenta de apoio.

Porém, devido às características mutáveis assim como as necessidades específicas de cada organização e serviço prestado, existirão, sem dúvidas, desafios a serem encarados na concepção destes novos sistemas, sendo que um destes desafios diz respeito à disciplina de Gerenciamento de Problemas.

Ao desenvolver um sistema que visa suprir as principais práticas apresentadas por tal disciplina, se faz necessário primeiramente controlar de forma detalhada as etapas necessárias para concluir o Ciclo de Vida do Problema, ou seja, desde a identificação de suas características fundamentais, definição do work around (contorno), investigação detalhada da causa, até a elaboração do plano de ação.

Além do detalhamento das etapas do Ciclo de Vida, é importante que a ferramenta demonstre de forma sintética a situação atual do Problema (status), ou seja, se o mesmo está em investigação, se a causa foi identificada, o plano de ação sugerido ou aplicado, etc.

Outro importante aspecto a ser considerado é a existência de uma funcionalidade destinada a relacionar imagens, mídias, e-mails e outros tipos de arquivos, anexando assim complementos que permitirão uma melhor compreensão do Problema. O ideal é que todas as informações estejam associadas a uma Base de Conhecimento, permitindo o acesso para rápida busca. Esta característica poderá se tornar extremamente importante para os técnicos do Primeiro Nível de Service/Help Desk, pois trará a funcionalidade de realizar buscas por procedimentos para solução e contorno dos Problemas (scripts), visando facilitar o tratamento eficiente e adequado dos Incidentes abertos.

Possibilitar uma integração flexível com um CMDB (Configuration Management DataBase), é sem dúvida uma outra necessidade para garantir a devida coesão entre as gerências de Problema e Configuração, permitindo a associação do Problema com os respectivos IC’s afetados.

O Sistema deve prover, acima de tudo, a autonomia necessária para que o Segundo ou Terceiro Nível, possa atuar de acordo com a prioridade real necessária a cada Problema. Deve para isso disponibilizar um prático e funcional controle visando identificar quais Problemas estão pendentes para análise, e quais etapas necessitam ainda ser realizadas para finalização de seus Ciclos de Vida.

Não existindo um controle prático e funcional nem uma priorização adequada dos Problemas, certamente a ferramenta poderá ser caracterizada como deficiente, pois não estará de acordo com seu principal objetivo: disponibilizar a informação de forma gerencial e estratégica, oferecendo recursos para correta tomada de decisão, tanto pelos técnicos do Segundo e Terceiro Nível, quanto pelos responsáveis pela gestão e governança de TI.

Afinal, se não se sabe quais são os inimigos (quais Problemas estão pendentes e quais são suas prioridades), nem quais seus pontos fracos (quais etapas do Ciclo de Vida de cada Problema devem ser analisadas), como poderíamos arquitetar uma “estratégia de combate” eficiente? Citamos aqui apenas algumas características consideradas importantes, sendo certo que existem muitos outros requisitos que devemos levar em conta na construção deste tipo de ferramenta.

Para finalizar, é essencial que esta ferramenta possua integração com outros sistemas correspondentes às demais disciplinas da ITIL, conforme foi citado anteriormente em relação à gerência de Configuração e o CMDB. Só assim conseguiremos rastrear todo Ciclo de Vida do Problema, desde sua origem (em um Incidente, uma Ação Pró-ativa, etc..), até sua solução definitiva, com provável realização de uma Mudança e/ou implantação de uma nova Versão.

Pablo dos Santos Alves

A InformationWeek Brasil publicou uma matéria muito interessante, “Como um Espelho” (página 42 a 45 do PDF) que é bastante interessante e ressalta pontos que podem e devem ser levados em consideração quando da elaboração de um SLA.

Já falamos bastante sobre o SLA aqui no Mundo ITIL mas a visão que se tem no artigo é mais ampla pois trata de um prisma que por vezes é deixado de lado, em especial porque sua repercussão é eminentemente atrelada a ponto mais sensível das empresas: BOLSO.

Algumas das partes que acredito ser mais interessantes no artigo:

O dia três de julho ficou marcado para muitos profissionais de TI como a data que seus sistemas de redundância foram postos à prova. Uma pane na rede IP/MPLS da Telefônica deixou o Estado de São Paulo sem internet durante quase 40 horas.
Diversas empresas ficaram sem poder realizar atividades importantes, no entanto, aquelas que dependiam da web para sobreviver (como companhias com vendas online) foram as que mais sofreram.
Com proporções enormes, o estrago deixou um aprendizado: não há contrato de nível de serviço (SLA, na sigla em inglês) que substitua a redundância – de links, de sistemas, de data centers, de tudo.
E também deixou claro que poucas empresas têm estruturado este processo de forma adequada.

Por melhor estruturado que um SLA possa ser desenvolvido há riscos que carecem de avaliação minuiciosa e em alguns casos até mesmo um pensamento caótico na tentativa de elucidar todas as possibilidades de impacto para a empresa. Pensamento paranóico é um bom caminho.

Para não ter de estruturar o “plano B”, algumas corporações apóiam-se totalmente no contrato feito com os fornecedores diversos, acreditando que eles vão cumprir exatamente o prometido e que o SLA resolverá qualquer problema. Contudo, existem situações, como a queda na internet, citada no início desta reportagem, que nem o prestador de serviço conseguiu prever ou resolver em tempo hábil.

Ou seja: tenha em mente que por maiores que sejam as penalidades envolvidas nos contratos não será um papel que deverá conduzir a sua busca por um ambiente que mantenha o ‘negócio andando’. E claro, saiba que para cada um dos serviços ofertados será fundamental ter um índice de criticidade de forma que seja possível averiguar quais destes terão atenção especial para redundância.

Até a próxima, Marco Aurélio.

O Gerenciamento de Nível de Serviços é o processo que forma o vínculo entre o departamento de TI e os clientes. Para implementar este processo com sucesso é necessário que os outros processos da ITIL já tenham sido implementados.

O foco principal deste processo é assegurar a qualidade dos Serviços em TI que são fornecidos, ao um custo aceitável ao negócio.

Mas a questão que permanece é: quando este acordo tem de ser revisto? Até que ponto sua redação e entendimento atendem as necessidades da empresa do ponto de vista do negócio e financeiro? E mais, quem são os responsáveis por entregar idéias para seu aprimoramento?

Ser Gerente Comercial tem uma característica que me agrada muito: conhecer pessoas de diversas corporações, normalmente da área de TI, que expõem suas dificuldades e conquistas na gestão de serviços de TI. Essas trocas de experiências são fundamentais já que que ambos se beneficiam do conhecimento que partilham.

Bem, numa dessas ocasiões, visitando uma grande corporação nacional me deparei com um caos bastante interessante, que partilho nesse post.

A Coporação X (sim, o nome é fictício mesmo) o Sr. CIO (acrônimo do nome para preservar sua identidade) relatou que ainda que sua corporação dispusesse de um SLA muito bem definido, e que atendia boa parte das necessidades das partes envovlidas, o acordo havia criado uma situação bastante capciosa, explicando:

Sr. CIO: Marco, meu SLA é bastante claro para todos os envolvidos e rege a disponibilidade dos serviços dentro das minhas necessidades financeiras (custos). Porém, há momentos em que eu penso que o rigor que ele propiciou me deixa em situações complicadas.

Eu: Desta forma assertiva que expõens, parece que realmente o SLA cumpre seu papel, mas o que lhe incomoda?

Sr. CIO: Olha, desde que o serviço não necessite de melhorias (aprimoramentos no sistema) tudo funciona muito bem.

Eu: Me explique melhor.

Sr. CIO: Veja o caso de meu sistema de telefonia. Mantê-lo em funcionamento é mandatório para meu negócio, e realmente o sistema se mantêm muito estável já optamos por uma plataforma aberta (Asterisk). Todavia, quando ocorre uma mudança física, por exemplo, alguém muda-se de lugar, preciso mudar o comportamento do sistema a fim de efetivar logicamente a mudança e isto é tratado como uma melhoria.

Eu: Entendo, mas, onde está o problema? Parece-me que realmente trata-se de uma melhoria que deve precisar do apoio do CAB (Change Advisory Board)*, correto?

Sr. CIO: Pois é isto mesmo. E é aí que sinto que temos de dar muito atenção para melhorarmos. Veja, o CAB reune-se mensalmente para aprovar (ou reprovar) quais mudanças devem ser implementadas. No caso de comentei contigo veja o paradoxo que criamos: pense que quando uma nova pessoa entrar na área de contato com cliente (Comercial, por exemplo) ela terá de aguardar a reunião para que possamos modificar nosso sistema de telefonia para contemplar a entrada desta pessoa. Este trabalho, modificar o sistema de telefonia, não leva mais do que 10 minutos para ser executado. E fica a questão: por quê esperar até um mês para executar uma situação crítica sendo que em minutos ela se resolverá?

Eu: Entendi, mas porque simplesmente não muda-se a forma como as atividades foram priorizadas? Digo, porque não tratam estas ocorrências como rotineiras já que a mudança de lugar físico parece fazer parte da rotina da empresa?

Sr. CIO: Porque simplesmente nosso SLA foi constituído desta forma e até o momento não temos como modificá-lo em tempo de voo.

Eu: Entendo… (preferi não continuar o assunto já que ele parecia ficar cada vez mais irritado com o fato ocorrer mesmo após ter empregado muito fosfato para empreender o melhor para a corporação).

Resumindo: não há mágica para encontrar a melhor solução, a experiência é fundamental (e a agilidade também).

Até a próxima, Marco Aurélio.

* Change Advisory Board pode ser definido como um grupo de pessoas que aconselha a mudança, priorização e agendamento. Este conselho é normalmente constituído por representantes de todas as áreas, incluindo fornecedores.

Service Level Agreement (SLA)
Acordo de Nível de Serviço
É um acordo entre um cliente e um provedor de serviço

Service Level Management (SLM)
Gerência de Nível de Serviço
Um conjunto de métodos e procedimentos disciplinados e pró-ativos usados para assegurar que níveis adequados de serviços são oferecidos

SLOs – Service Level Objectives
Define o nível de serviço a ser provido, conforme acordo
Define o que é para ser mensurado

SLGs – Service Level Guarantees
Define o que fazer caso o serviço falhe

SLIs – Service Level Indicators
O coração dos SLAs, para quantificação e mensuração

SLRs – Service Level Reports
O principal veículo de comunicação dos SLAs

Contrato
Define os serviços prestados e inclui uma cláusula de gestão dos serviços prestados

Caderno de Métricas
Definição dos indicadores, como são medidos, por quem, quando e definição dos limiares (thresholds)

O processo de Gerenciamento de Mudanças é responsável por decidir e coordenar as mudanças na área de TI, ou seja, controlar as mudanças para que elas sejam implantadas de forma eficiente, eficaz e assegurar que a infra-estrutura e TI permaneça alinhada aos requisitos do negócio, com o menor risco possível.

Para realizar uma análise de riscos adequada é importante o uso de uma Base de Gerenciamento da Configuração (também conhecida como CMDB – Configuration Management Database) que forneça todos os serviços e recursos relacionados ao item de configuração (CI - Configuration Item) que sofrerá a mudança.

Os principais objetivos deste gerenciamento são:

• Assegurar que os métodos padronizados estão sendo usados para o tratamento eficiente de todas as mudanças, reduzindo seus riscos e impactos;
• Minimizar incidentes relacionados com mudanças;
• Balanço entre necessidade e impacto.

Pode-se implementar esse processo isoladamente, mas é importante o apoio do Gerenciamento de Configuração para dar suporte à avaliação de impacto, indicando os itens de configuração envolvidos na mudança. Também vale ressaltar que o controle das liberações (implantação da mudança) não é de responsabilidade do Gerenciamento de Mudanças, mas sim do Gerenciamento de Liberações.

Sueli Marowski Goldacker

Problema é a causa de um ou mais incidentes. É interessante lembrar que um incidente deve ter um problema associado, toda via um problema não necessariamente deve estar associado a um incidente, já que a origem de um problema será em função de uma atividade pro-ativa ou reativa.

Como já deve ser de conhecimento, o dia-a-dia de muitas equipes de suporte é bem corrido e usualmente muitas delas trabalham apagando incêndios. Felizmente a realidade das equipes de suporte da Teclógica é diferente.

Em nossa “linha de frente” do atendimento está o primeiro nível (Service Desk), que é responsável pelo primeiro contato com o usuário, em muitos casos é até um ponto único de contato. Nesse nível são feitas análises dos incidentes registrados, coletando dados, fazendo investigações em itens de configuração, consultando base de conhecimentos, erros conhecidos e investigações para contorno. Veja, o foco está em resolver o incidente, fazendo o contorno, diminuindo o tempo de interrupção do serviço ao usuário.

Caso o primeiro nível consiga fazer o contorno resolvendo o incidente e já exista algum problema que defina a causa do incidente, o segundo nível não é acionado, se não conseguir ou for um incidente grave ou ainda conseguir contornar e não identificar a causa raiz, o segundo nível é acionado. Onde a analise poderá ser feita sem interrupções de usuário. Esse processo conhecido como escalonamento funcional.

Nesse estagio é feito um levantamento mais a fundo do problema, para descobrir a causa raiz. São feitas analises podendo envolver técnicas de resolução de problemas como: analise de Kepner e Tregoe, Brainstorming, Diagrama de Ishikawa e analise de Pareto, conforme sugestão na versão três do Itil. Após entender qual é o problema será necessário desenvolver uma solução de contorno (work around) e em seguida é direcionado para o gerenciamento de mudanças fazer a alteração necessária (Modificar fontes de sistemas, troca de servidor, etc) para que seja aplicada uma solução definitiva. O fluxo abaixo ilustra bem o inicio e fim do processo.

Incidente -> Problema -> Erro Conhecido -> Solicitação de Mudança

Após aprovada a mudança é o gerenciamento de liberações que faz a liberação para o ambiente produção e dispara um evento informando a gerencia de configuração que um determinado item de configuração foi atualizado. Mas a tarefa do gerenciamento de problemas ainda não terminou. Deve ser verificado se o problema realmente foi erradicado do ambiente de produção.

Desse modo que se percebe que existe um ciclo de vida para o problema e toda uma complexidade em gerenciá-lo. De fato, não é uma tarefa fácil, mas não é difícil perceber os excelentes resultados obtidos com essas praticas.

Alexsander Oliveira